315 files changed, 387440 insertions, 0 deletions

diff --git a/third_party/heimdal/doc/Makefile.am b/third_party/heimdal/doc/Makefile.am
new file mode 100644
index 00000000000..ed95c305fe3
--- /dev/null
+++ b/third_party/heimdal/doc/Makefile.am
@@ -0,0 +1,163 @@
+# $Id$
+
+include $(top_srcdir)/Makefile.am.common
+
+AUTOMAKE_OPTIONS = no-texinfo.tex
+
+MAKEINFOFLAGS = --css-include=$(srcdir)/heimdal.css
+
+TEXI2DVI = true # ARGH, make distcheck can't be disabled to not build dvifiles
+
+info_TEXINFOS = heimdal.texi hx509.texi
+
+dxy_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
+	-e 's,[@]objdir[@],.,g' \
+	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
+
+hcrypto.dxy: hcrypto.din Makefile
+	$(dxy_subst) < $(srcdir)/hcrypto.din > hcrypto.dxy.tmp
+	chmod +x hcrypto.dxy.tmp
+	mv hcrypto.dxy.tmp hcrypto.dxy
+
+hdb.dxy: hdb.din Makefile
+	$(dxy_subst) < $(srcdir)/hdb.din > hdb.dxy.tmp
+	chmod +x hdb.dxy.tmp
+	mv hdb.dxy.tmp hdb.dxy
+
+base.dxy: base.din Makefile
+	$(dxy_subst) < $(srcdir)/base.din > base.dxy.tmp
+	chmod +x base.dxy.tmp
+	mv base.dxy.tmp base.dxy
+
+hx509.dxy: hx509.din Makefile
+	$(dxy_subst) < $(srcdir)/hx509.din > hx509.dxy.tmp
+	chmod +x hx509.dxy.tmp
+	mv hx509.dxy.tmp hx509.dxy
+
+gssapi.dxy: gssapi.din Makefile
+	$(dxy_subst) < $(srcdir)/gssapi.din > gssapi.dxy.tmp
+	chmod +x gssapi.dxy.tmp
+	mv gssapi.dxy.tmp gssapi.dxy
+
+krb5.dxy: krb5.din Makefile
+	$(dxy_subst) < $(srcdir)/krb5.din > krb5.dxy.tmp
+	chmod +x krb5.dxy.tmp
+	mv krb5.dxy.tmp krb5.dxy
+
+ntlm.dxy: ntlm.din Makefile
+	$(dxy_subst) < $(srcdir)/ntlm.din > ntlm.dxy.tmp
+	chmod +x ntlm.dxy.tmp
+	mv ntlm.dxy.tmp ntlm.dxy
+
+wind.dxy: wind.din Makefile
+	$(dxy_subst) < $(srcdir)/wind.din > wind.dxy.tmp
+	chmod +x wind.dxy.tmp
+	mv wind.dxy.tmp wind.dxy
+
+texi_subst = sed -e 's,[@]dbdir[@],$(localstatedir),g' \
+	-e 's,[@]dbtype[@],$(db_type),g' \
+	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
+
+vars.texi: vars.tin Makefile
+	$(texi_subst) < $(srcdir)/vars.tin > vars.texi.tmp
+	chmod +x vars.texi.tmp
+	mv vars.texi.tmp vars.texi
+
+PROJECTS = base hdb hx509 gssapi krb5 ntlm wind 
+
+PROJECTS += hcrypto
+
+doxyout doxygen: base.dxy hdb.dxy hx509.dxy hcrypto.dxy gssapi.dxy krb5.dxy ntlm.dxy wind.dxy
+	@test -d $(srcdir)/doxyout && \
+	find $(srcdir)/doxyout -type d ! -perm -200 -exec chmod u+w {} ';' ; \
+	rm -rf $(srcdir)/doxyout ; \
+	mkdir $(srcdir)/doxyout ; \
+	for a in $(PROJECTS) ; do \
+		echo $$a ; \
+		doxygen $$a.dxy; \
+		(cd $(srcdir)/doxyout && \
+		    find $$a/man -name '_*' -type f -print | \
+			perl -lne unlink && \
+		    find $$a/html -name 'dir_*.html' -type f -print | \
+			perl -lne unlink && \
+		 find $$a/man -type f > $$a/manpages ) ; \
+	done
+
+install-data-hook: install-doxygen-manpage
+uninstall-hook: uninstall-doxygen-manpage
+dist-hook: doxygen
+
+install-doxygen-manpage:
+	for a in $(PROJECTS) ; do \
+		f="$(srcdir)/doxyout/$$a/manpages" ; \
+		test -f $$f || continue ; \
+		echo "install $$a manual pages $$(wc -l < $$f)" ; \
+		while read x ; do \
+			section=`echo "$$x" | sed 's/.*\.\([0-9]\)/\1/'` ; \
+			$(mkinstalldirs) "$(DESTDIR)$(mandir)/man$$section" ; \
+			$(INSTALL_DATA) $(srcdir)/doxyout/$$x "$(DESTDIR)$(mandir)/man$$section" ; \
+		done < $$f ; \
+	done ; exit 0
+
+uninstall-doxygen-manpage:
+	@for a in $(PROJECTS) ; do \
+		f="$(srcdir)/doxyout/$$a/manpages" ; \
+		test -f $$f || continue ; \
+		echo "removing $$a manual pages" ; \
+		while read x ; do \
+			section=`echo "$$x" | sed 's/.*\.\([0-9]\)/\1/'` ; \
+			base=`basename $$x` ; \
+			rm "$(DESTDIR)$(mandir)/man$$section/$$base" ; \
+		done < $$f ; \
+	done
+
+
+heimdal_TEXINFOS = \
+	ack.texi \
+	apps.texi \
+	copyright.texi \
+	heimdal.texi \
+	install.texi \
+	intro.texi \
+	kerberos4.texi \
+	migration.texi \
+	misc.texi \
+	programming.texi \
+	setup.texi \
+	vars.texi \
+	whatis.texi \
+	win2k.texi
+
+EXTRA_DIST = \
+	NTMakefile \
+	doxyout \
+	footer.html \
+	gssapi.din \
+	hdb.din \
+	hcrypto.din \
+	header.html \
+	heimdal.css \
+	base.din \
+	hx509.din \
+	krb5.din \
+	ntlm.din \
+	init-creds \
+	latin1.tex \
+	layman.asc \
+	doxytmpl.dxy \
+	wind.din \
+	base.hhp \
+	heimdal.hhp \
+	hx509.hhp \
+	vars.tin
+
+CLEANFILES = \
+	hcrypto.dxy* \
+	base.dxy* \
+	hx509.dxy* \
+	hdb.dxy* \
+	gssapi.dxy* \
+	krb5.dxy* \
+	ntlm.dxy* \
+	wind.dxy* \
+	vars.texi*
diff --git a/third_party/heimdal/doc/NTMakefile b/third_party/heimdal/doc/NTMakefile
new file mode 100644
index 00000000000..0299620ac11
--- /dev/null
+++ b/third_party/heimdal/doc/NTMakefile
@@ -0,0 +1,126 @@
+########################################################################
+#
+# Copyright (c) 2009, Secure Endpoints Inc.
+# All rights reserved.
+# 
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 
+# - Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# 
+# - Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# 
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+# COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+# CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+# 
+
+RELDIR=doc 
+
+!include ../windows/NTMakefile.w32 
+
+heimdal_TEXINFOS = \
+	$(OBJ)\ack.texi \
+	$(OBJ)\apps.texi \
+	$(OBJ)\copyright.texi \
+	$(OBJ)\heimdal.texi \
+	$(OBJ)\install.texi \
+	$(OBJ)\intro.texi \
+	$(OBJ)\kerberos4.texi \
+	$(OBJ)\migration.texi \
+	$(OBJ)\misc.texi \
+	$(OBJ)\programming.texi \
+	$(OBJ)\setup.texi \
+	$(OBJ)\vars.texi \
+	$(OBJ)\whatis.texi \
+	$(OBJ)\win2k.texi
+
+hx509_TEXINFOS = \
+	$(OBJ)\hx509.texi
+
+{}.texi{$(OBJ)}.texi:
+	$(CP) $** $@
+
+{}.tin{$(OBJ)}.texi:
+	$(SED) -e "s,[@]dbdir[@],x,g"	\
+	-e "s,[@]dbtype[@],sqlite,g" < $** > $@ \
+	-e "s,[@]PACKAGE_VERSION[@],$(VER_PACKAGE_VERSION),g" < $** > $@
+
+MAKEINFOFLAGS = --css-include=$(SRCDIR)/heimdal.css
+
+!ifdef APPVEYOR
+MAKEINFO = $(PERL) C:\msys64\usr\bin\makeinfo
+!endif
+
+######################################################################
+# Build heimdal.chm
+
+# Copyrights-and-Licenses.html is where the table of contents ends up
+# when generating HTML output using makeinfo.  Same goes for
+# How-to-use-the-PKCS11-module.html below.
+
+$(OBJ)\heimdal\index.html $(OBJ)\heimdal\Copyrights-and-Licenses.html: $(heimdal_TEXINFOS)
+	cd $(OBJ)
+	$(MAKEINFO) $(MAKEINFOFLAGS) --html heimdal.texi
+	-$(MKDIR) heimdal
+	cd $(SRCDIR)
+
+$(OBJ)\heimdal\toc.hhc: $(OBJ)\heimdal\Copyrights-and-Licenses.html
+	$(PERL) $(SRC)\cf\w32-hh-toc-from-info.pl -o$@ $**
+
+$(OBJ)\heimdal\heimdal.hhp: heimdal.hhp
+	$(CP) $** $@
+
+$(DOCDIR)\heimdal.chm: $(OBJ)\heimdal\heimdal.hhp $(OBJ)\heimdal\toc.hhc
+	cd $(OBJ)\heimdal
+	-$(HHC) heimdal.hhp
+	$(CP) heimdal.chm $@
+	cd $(SRCDIR)
+
+######################################################################
+# Build hx509.chm
+
+$(OBJ)\hx509\index.html $(OBJ)\hx509\How-to-use-the-PKCS11-module.html: $(hx509_TEXINFOS)
+	cd $(OBJ)
+	$(MAKEINFO) $(MAKEINFOFLAGS) --html hx509.texi
+	-$(MKDIR) hx509
+	cd $(SRCDIR)
+
+$(OBJ)\hx509\toc.hhc: $(OBJ)\hx509\How-to-use-the-PKCS11-module.html
+	$(PERL) $(SRC)\cf\w32-hh-toc-from-info.pl -o$@ $**
+
+$(OBJ)\hx509\hx509.hhp: hx509.hhp
+	$(CP) $** $@
+
+$(DOCDIR)\hx509.chm: $(OBJ)\hx509\hx509.hhp $(OBJ)\hx509\toc.hhc
+	cd $(OBJ)\hx509
+	-$(HHC) hx509.hhp
+	$(CP) hx509.chm $@
+	cd $(SRCDIR)
+
+!ifndef NO_DOC
+all:: $(OBJ)\heimdal\index.html $(OBJ)\hx509\index.html \
+	$(DOCDIR)\heimdal.chm $(DOCDIR)\hx509.chm
+!endif
+
+clean::
+	-$(RM) $(OBJ)\heimdal\*.*
+	-$(RM) $(OBJ)\hx509\*.*
+	-$(RM) $(DOCDIR)\heimdal.chm
+	-$(RM) $(DOCDIR)\hx509.chm
+
+.SUFFIXES: .texi .tin
diff --git a/third_party/heimdal/doc/ack.texi b/third_party/heimdal/doc/ack.texi
new file mode 100644
index 00000000000..89b83c1b862
--- /dev/null
+++ b/third_party/heimdal/doc/ack.texi
@@ -0,0 +1,124 @@
+@node  Acknowledgments, Copyrights and Licenses, Migration, Top
+@comment  node-name,  next,  previous,  up
+@appendix Acknowledgments
+
+Eric Young wrote ``libdes''. Heimdal used to use libdes, without it
+kth-krb would never have existed. Since there are no longer any Eric
+Young code left in the library, we renamed it to libhcrypto.
+
+All functions in libhcrypto have been re-implemented or used available
+public domain code. The core AES function where written by Vincent
+Rijmen, Antoon Bosselaers and Paulo Barreto.  The core DES SBOX
+transformation was written by Richard Outerbridge. @code{imath} that
+is used for public key crypto support is written by Michael
+J. Fromberger.
+
+The University of California at Berkeley initially wrote @code{telnet},
+and @code{telnetd}.  The authentication and encryption code of
+@code{telnet} and @code{telnetd} was added by David Borman (then of Cray
+Research, Inc).  The encryption code was removed when this was exported
+and then added back by Juha Eskelinen.
+
+The @code{popper} was also a Berkeley program initially.
+
+Some of the functions in @file{libroken} also come from Berkeley by way
+of NetBSD/FreeBSD.
+
+@code{editline} was written by Simmule Turner and Rich Salz. Heimdal
+contains a modifed copy.
+
+The @code{getifaddrs} implementation for Linux was written by Hideaki
+YOSHIFUJI for the Usagi project.
+
+The @code{pkcs11.h} headerfile was written by the Scute project.
+
+Bugfixes, documentation, encouragement, and code has been contributed by:
+@table @asis
+@item Alexander Boström
+@item Allan McRae
+@item Andrew Bartlett
+@item Andrew Cobaugh
+@item Andrew Tridge
+@item Anton Lundin
+@item Asanka Herath
+@item Björn Grönvall
+@item Björn Sandell
+@item Björn Schlögl
+@item Brandon S. Allbery KF8NH
+@item Brian A May
+@item Buck Huppmann
+@item Cacdric Schieli
+@item Chaskiel M Grundman
+@item Christos Zoulas
+@item Cizzi Storm
+@item Daniel Kouril
+@item David Love
+@item David Markey
+@item David R Boldt
+@item Derrick J Brashear
+@item Donald Norwood
+@item Douglas E Engert
+@item Frank van der Linden
+@item Gabor Gombas
+@item Guido Günther
+@item Guillaume Rousse
+@item Harald Barth
+@item Ingo Schwarze
+@item Jacques A. Vidrine
+@item Jaideep Padhye
+@item Jan Rekorajski
+@item Jason McIntyre
+@item Jeffrey Altman
+@item Jelmer Vernooij
+@item Joerg Pulz
+@item Johan Danielsson
+@item Johan Gadsjö
+@item Johan Ihrén
+@item John Center
+@item Julian Ospald
+@item Jun-ichiro itojun Hagino
+@item KAMADA Ken'ichi
+@item Kamen Mazdrashki
+@item Karolin Seeger
+@item Ken Hornstein
+@item Love Hörnquist Åstrand
+@item Luke Howard
+@item Magnus Ahltorp
+@item Magnus Holmberg
+@item Marc Horowitz
+@item Mario Strasser
+@item Mark Eichin
+@item Martin von Gagern
+@item Matthias Dieter Wallnöfer
+@item Matthieu Patou
+@item Mattias Amnefelt
+@item Michael B Allen
+@item Michael Fromberger
+@item Michal Vocu
+@item Milosz Kmieciak
+@item Miroslav Ruda
+@item Mustafa A. Hashmi
+@item Nicolas Williams
+@item Patrik Lundin
+@item Petr Holub
+@item Phil Fisher
+@item Rafal Malinowski
+@item Ragnar Sundblad
+@item Rainer Toebbicke
+@item Richard Nyberg
+@item Roland C. Dowdeswell
+@item Roman Divacky
+@item Russ Allbery
+@item Sho Hosoda, ç´°ç”° å°†
+@item Simon Wilkinson
+@item Stefan Metzmacher
+@item Ted Percival
+@item Timothy Pearson
+@item Tom Payerle
+@item Victor Guerra
+@item Zeqing Xia
+@item Ã…ke Sandgren 
+@item and we hope that those not mentioned here will forgive us.
+@end table
+
+All bugs were introduced by ourselves.
diff --git a/third_party/heimdal/doc/apps.texi b/third_party/heimdal/doc/apps.texi
new file mode 100644
index 00000000000..98585c4d0a7
--- /dev/null
+++ b/third_party/heimdal/doc/apps.texi
@@ -0,0 +1,270 @@
+@c $Id$
+
+@node Applications, Things in search for a better place, Setting up a realm, Top
+
+@chapter Applications
+
+@menu
+* Authentication modules::
+* AFS::
+@end menu
+
+@node  Authentication modules, AFS, Applications, Applications
+@section Authentication modules
+
+The problem of having different authentication mechanisms has been
+recognised by several vendors, and several solutions have appeared. In
+most cases these solutions involve some kind of shared modules that are
+loaded at run-time.  Modules for some of these systems can be found in
+@file{lib/auth}.  Presently there are modules for Digital's SIA,
+and IRIX' @code{login} and @code{xdm} (in
+@file{lib/auth/afskauthlib}).
+
+@menu
+* Digital SIA::                 
+* IRIX::                        
+@end menu
+
+@node Digital SIA, IRIX, Authentication modules, Authentication modules
+@subsection Digital SIA
+
+How to install the SIA module depends on which OS version you're
+running. Tru64 5.0 has a new command, @file{siacfg}, which makes this
+process quite simple. If you have this program, you should just be able
+to run:
+@example
+siacfg -a KRB5 /usr/athena/lib/libsia_krb5.so
+@end example
+
+On older versions, or if you want to do it by hand, you have to do the
+following (not tested by us on Tru64 5.0):
+
+@itemize @bullet
+
+@item
+Make sure @file{libsia_krb5.so} is available in
+@file{/usr/athena/lib}. If @file{/usr/athena} is not on local disk, you
+might want to put it in @file{/usr/shlib} or someplace else. If you do,
+you'll have to edit @file{krb5_matrix.conf} to reflect the new location
+(you will also have to do this if you installed in some other directory
+than @file{/usr/athena}). If you built with shared libraries, you will
+have to copy the shared @file{libkrb.so}, @file{libdes.so},
+@file{libkadm.so}, and @file{libkafs.so} to a place where the loader can
+find them (such as @file{/usr/shlib}).
+@item
+Copy (your possibly edited) @file{krb5_matrix.conf} to @file{/etc/sia}.
+@item
+Apply @file{security.patch} to @file{/sbin/init.d/security}.
+@item
+Turn on KRB5 security by issuing @kbd{rcmgr set SECURITY KRB5} and
+@kbd{rcmgr set KRB5_MATRIX_CONF krb5_matrix.conf}.
+@item
+Digital thinks you should reboot your machine, but that really shouldn't
+be necessary.  It's usually sufficient just to run
+@kbd{/sbin/init.d/security start} (and restart any applications that use
+SIA, like @code{xdm}.)
+@end itemize
+
+Users with local passwords (like @samp{root}) should be able to login
+safely.
+
+When using Digital's xdm the @samp{KRB5CCNAME} environment variable isn't
+passed along as it should (since xdm zaps the environment). Instead you
+have to set @samp{KRB5CCNAME} to the correct value in
+@file{/usr/lib/X11/xdm/Xsession}. Add a line similar to
+@example
+KRB5CCNAME=FILE:/tmp/krb5cc`id -u`_`ps -o ppid= -p $$`; export KRB5CCNAME
+@end example
+If you use CDE, @code{dtlogin} allows you to specify which additional
+environment variables it should export. To add @samp{KRB5CCNAME} to this
+list, edit @file{/usr/dt/config/Xconfig}, and look for the definition of
+@samp{exportList}. You want to add something like:
+@example
+Dtlogin.exportList:     KRB5CCNAME
+@end example
+
+@subsubheading Notes to users with Enhanced security
+
+Digital's @samp{ENHANCED} (C2) security, and Kerberos solve two
+different problems. C2 deals with local security, adds better control of
+who can do what, auditing, and similar things. Kerberos deals with
+network security.
+
+To make C2 security work with Kerberos you will have to do the
+following.
+
+@itemize @bullet
+@item
+Replace all occurrences of @file{krb5_matrix.conf} with
+@file{krb5+c2_matrix.conf} in the directions above.
+@item
+You must enable ``vouching'' in the @samp{default} database.  This will
+make the OSFC2 module trust other SIA modules, so you can login without
+giving your C2 password. To do this use @samp{edauth} to edit the
+default entry @kbd{/usr/tcb/bin/edauth -dd default}, and add a
+@samp{d_accept_alternate_vouching} capability, if not already present.
+@item
+For each user who does @emph{not} have a local C2 password, you should
+set the password expiration field to zero. You can do this for each
+user, or in the @samp{default} table. To do this use @samp{edauth} to
+set (or change) the @samp{u_exp} capability to @samp{u_exp#0}.
+@item
+You also need to be aware that the shipped @file{login}, @file{rcp}, and
+@file{rshd}, don't do any particular C2 magic (such as checking for
+various forms of disabled accounts), so if you rely on those features,
+you shouldn't use those programs. If you configure with
+@samp{--enable-osfc2}, these programs will, however, set the login
+UID. Still: use at your own risk.
+@end itemize
+
+At present @samp{su} does not accept the vouching flag, so it will not
+work as expected.
+
+Also, kerberised ftp will not work with C2 passwords. You can solve this
+by using both Digital's ftpd and our on different ports.
+
+@strong{Remember}, if you do these changes you will get a system that
+most certainly does @emph{not} fulfil the requirements of a C2
+system. If C2 is what you want, for instance if someone else is forcing
+you to use it, you're out of luck.  If you use enhanced security because
+you want a system that is more secure than it would otherwise be, you
+probably got an even more secure system. Passwords will not be sent in
+the clear, for instance.
+
+@node IRIX, , Digital SIA, Authentication modules
+@subsection IRIX
+
+The IRIX support is a module that is compatible with Transarc's
+@file{afskauthlib.so}.  It should work with all programs that use this
+library. This should include @command{login} and @command{xdm}.
+
+The interface is not very documented but it seems that you have to copy
+@file{libkafs.so}, @file{libkrb.so}, and @file{libdes.so} to
+@file{/usr/lib}, or build your @file{afskauthlib.so} statically.
+
+The @file{afskauthlib.so} itself is able to reside in
+@file{/usr/vice/etc}, @file{/usr/afsws/lib}, or the current directory
+(wherever that is).
+
+IRIX 6.4 and newer seem to have all programs (including @command{xdm} and
+@command{login}) in the N32 object format, whereas in older versions they
+were O32. For it to work, the @file{afskauthlib.so} library has to be in
+the same object format as the program that tries to load it. This might
+require that you have to configure and build for O32 in addition to the
+default N32.
+
+Apart from this it should ``just work''; there are no configuration
+files.
+
+Note that recent Irix 6.5 versions (at least 6.5.22) have PAM,
+including a @file{pam_krb5.so} module.  Not all relevant programs use
+PAM, though, e.g.@: @command{ssh}. In particular, for console
+graphical login you need to turn off @samp{visuallogin} and turn on
+@samp{xdm} with @command{chkconfig}.
+
+@node AFS, , Authentication modules, Applications
+@section AFS
+
+@cindex AFS
+AFS is a distributed filesystem that uses Kerberos for authentication.
+
+@cindex OpenAFS
+@cindex Arla
+For more information about AFS see OpenAFS
+@url{http://www.openafs.org/} and Arla
+@url{http://www.stacken.kth.se/projekt/arla/}.
+
+@subsection kafs and afslog
+@cindex afslog
+
+@manpage{afslog,1} will obtains AFS tokens for a number of cells. What cells to get
+tokens for can either be specified as an explicit list, as file paths to
+get tokens for, or be left unspecified, in which case will use whatever
+magic @manpage{kafs,3} decides upon.
+
+If not told what cell to get credentials for, @manpage{kafs,3} will
+search for the files ThisCell and TheseCells in the locations
+specified in @manpage{kafs,3} and try to get tokens for these cells
+and the cells specified in $HOME/.TheseCells.
+
+More usefully it will look at and ~/.TheseCells in your home directory
+and for each line which is a cell get afs token for these cells.
+
+The TheseCells file defines the the cells to which applications on the
+local client machine should try to aquire tokens for. It must reside in
+the directories searched by @manpage{kafs,3} on every AFS client machine.
+
+The file is in ASCII format and contains one character string, the cell
+name, per line. Cell names are case sensitive, but most cell names
+are lower case.
+
+See manpage for @manpage{kafs,3} for search locations of ThisCell and TheseCells.
+
+@subsection How to get a KeyFile
+
+@file{ktutil -k AFSKEYFILE:KeyFile get afs@@MY.REALM}
+
+or you can extract it with kadmin
+
+@example
+kadmin> ext -k AFSKEYFILE:/usr/afs/etc/KeyFile afs@@My.CELL.NAME
+@end example
+
+You have to make sure you have a @code{des-cbc-md5} encryption type since that
+is the enctype that will be converted.
+
+@subsection How to convert a srvtab to a KeyFile
+
+You need a @file{/usr/vice/etc/ThisCell} containing the cellname of your
+AFS-cell.
+
+@file{ktutil copy krb4:/root/afs-srvtab AFSKEYFILE:/usr/afs/etc/KeyFile}.
+
+If keyfile already exists, this will add the new key in afs-srvtab to
+KeyFile.
+
+@section Using 2b tokens with AFS
+
+@subsection What is 2b ?
+
+2b is the name of the proposal that was implemented to give basic
+Kerberos 5 support to AFS in rxkad. It's not real Kerberos 5 support
+since it still uses fcrypt for data encryption and not Kerberos
+encryption types.
+
+Its only possible (in all cases) to do this for DES encryption types
+because only then the token (the AFS equivalent of a ticket) will be
+smaller than the maximum size that can fit in the token cache in the
+OpenAFS/Transarc client. It is a so tight fit that some extra wrapping
+on the ASN1/DER encoding is removed from the Kerberos ticket.
+
+2b uses a Kerberos 5 EncTicketPart instead of a Kerberos 4 ditto for
+the part of the ticket that is encrypted with the service's key. The
+client doesn't know what's inside the encrypted data so to the client
+it doesn't matter.
+
+To  differentiate between Kerberos 4 tickets and Kerberos 5 tickets, 2b
+uses a special kvno, 213 for 2b tokens and 255 for Kerberos 5 tokens.
+
+Its a requirement that all AFS servers that support 2b also support
+native Kerberos 5 in rxkad.
+
+@subsection Configuring a Heimdal kdc to use 2b tokens
+
+Support for 2b tokens in the kdc are turned on for specific principals
+by adding them to the string list option @code{[kdc]use_2b} in the
+kdc's @file{krb5.conf} file.
+
+@example
+[kdc]
+	use_2b = @{
+		afs@@SU.SE = yes
+		afs/it.su.se@@SU.SE = yes
+	@}
+@end example
+
+@subsection Configuring AFS clients for 2b support
+
+There is no need to configure AFS clients for 2b support. The only
+software that needs to be installed/upgrade is a Kerberos 5 enabled
+@file{afslog}.
diff --git a/third_party/heimdal/doc/base.din b/third_party/heimdal/doc/base.din
new file mode 100644
index 00000000000..3ef6d404a42
--- /dev/null
+++ b/third_party/heimdal/doc/base.din
@@ -0,0 +1,15 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal base library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/base
+INPUT                  = @srcdir@/../lib/base
+
+WARN_IF_UNDOCUMENTED   = YES
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/third_party/heimdal/doc/base.hhp b/third_party/heimdal/doc/base.hhp
new file mode 100644
index 00000000000..e1a3d3cf589
--- /dev/null
+++ b/third_party/heimdal/doc/base.hhp
@@ -0,0 +1,8 @@
+[OPTIONS]
+Compatibility=1.1 or later
+Compiled file=heimbase.chm
+Contents file=toc.hhc
+Default topic=index.html
+Display compile progress=No
+Language=0x409 English (United States)
+Title=Heimdal Base
diff --git a/third_party/heimdal/doc/copyright.texi b/third_party/heimdal/doc/copyright.texi
new file mode 100644
index 00000000000..d9f1a8c2e19
--- /dev/null
+++ b/third_party/heimdal/doc/copyright.texi
@@ -0,0 +1,521 @@
+
+@macro copynext{} 
+@vskip 20pt plus 1fil
+@end macro
+
+@macro copyrightstart{}
+@end macro
+
+@macro copyrightend{}
+@end macro
+
+
+@node  Copyrights and Licenses, , Acknowledgments, Top
+@comment  node-name,  next,  previous,  up
+@appendix Copyrights and Licenses
+
+@heading Kungliga Tekniska Högskolan
+
+@copyrightstart
+@verbatim
+
+Copyright (c) 1997-2011 Kungliga Tekniska Högskolan 
+(Royal Institute of Technology, Stockholm, Sweden).
+All rights reserved.
+
+Portions Copyright (c) 2009 Apple Inc. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the Institute nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading Massachusetts Institute of Technology
+
+The parts of the libtelnet that handle Kerberos.
+
+@verbatim
+
+Copyright (C) 1990 by the Massachusetts Institute of Technology
+
+Export of this software from the United States of America may
+require a specific license from the United States Government.
+It is the responsibility of any person or organization contemplating
+export to obtain such a license before exporting.
+
+WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
+distribute this software and its documentation for any purpose and
+without fee is hereby granted, provided that the above copyright
+notice appear in all copies and that both that copyright notice and
+this permission notice appear in supporting documentation, and that
+the name of M.I.T. not be used in advertising or publicity pertaining
+to distribution of the software without specific, written prior
+permission.  M.I.T. makes no representations about the suitability of
+this software for any purpose.  It is provided "as is" without express
+or implied warranty.
+
+@end verbatim
+@copynext
+
+@heading The Regents of the University of California
+
+The parts of the libroken, most of libtelnet, telnet, ftp,
+and popper.
+
+@verbatim
+
+Copyright (c) 1988, 1990, 1993
+     The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading The Regents of the University of California.
+
+libedit
+
+@verbatim
+
+Copyright (c) 1992, 1993
+ The Regents of the University of California.  All rights reserved.
+
+This code is derived from software contributed to Berkeley by
+Christos Zoulas of Cornell University.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+3. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading TomsFastMath / LibTomMath
+
+Tom's fast math (bignum support) and LibTomMath
+
+@verbatim
+
+LibTomMath is hereby released into the Public Domain.  
+
+@end verbatim 
+
+@copynext
+
+@heading Doug Rabson
+
+GSS-API mechglue layer.
+
+@verbatim
+
+Copyright (c) 2005 Doug Rabson
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading PADL Software Pty Ltd
+
+@table @asis
+@item GSS-API CFX, SPNEGO, naming extensions, API extensions.
+@item KCM credential cache.
+@item HDB LDAP backend.
+@end table
+
+@verbatim
+
+Copyright (c) 2003-2011, PADL Software Pty Ltd.
+Copyright (c) 2004, Andrew Bartlett.
+Copyright (c) 2003 - 2008, Kungliga Tekniska Högskolan
+Copyright (c) 2015, Timothy Pearson.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of PADL Software nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY PADL SOFTWARE AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL PADL SOFTWARE OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading Marko Kreen
+
+Fortuna in libhcrypto
+
+@verbatim
+
+Copyright (c) 2005 Marko Kreen
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+       notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+       notice, this list of conditions and the following disclaimer in the
+       documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.	IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading NTT (Nippon Telegraph and Telephone Corporation)
+
+Camellia in libhcrypto
+
+@verbatim
+
+Copyright (c) 2006,2007
+NTT (Nippon Telegraph and Telephone Corporation) . All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer as
+  the first lines of this file unmodified.
+2. Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in the
+  documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY NTT ``AS IS'' AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL NTT BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading The NetBSD Foundation, Inc.
+
+vis.c in libroken
+
+@verbatim
+
+Copyright (c) 1999, 2005 The NetBSD Foundation, Inc.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading Vincent Rijmen, Antoon Bosselaers, Paulo Barreto
+
+AES in libhcrypto
+
+@verbatim
+
+rijndael-alg-fst.c
+
+@version 3.0 (December 2000)
+
+Optimised ANSI C code for the Rijndael cipher (now AES)
+
+@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
+@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
+@author Paulo Barreto <paulo.barreto@terra.com.br>
+
+This code is hereby placed in the public domain.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS
+OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
+OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+@end verbatim
+@copynext
+
+@heading Apple, Inc
+
+kdc/announce.c
+
+@verbatim
+
+Copyright (c) 2008 Apple Inc.  All Rights Reserved.
+
+Export of this software from the United States of America may require
+a specific license from the United States Government.  It is the
+responsibility of any person or organization contemplating export to
+obtain such a license before exporting.
+
+WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
+distribute this software and its documentation for any purpose and
+without fee is hereby granted, provided that the above copyright
+notice appear in all copies and that both that copyright notice and
+this permission notice appear in supporting documentation, and that
+the name of Apple Inc. not be used in advertising or publicity pertaining
+to distribution of the software without specific, written prior
+permission.  Apple Inc. makes no representations about the suitability of
+this software for any purpose.  It is provided "as is" without express
+or implied warranty.
+
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+
+@end verbatim
+
+@copynext
+
+@heading Richard Outerbridge
+
+DES core in libhcrypto
+
+@verbatim
+
+D3DES (V5.09) - 
+
+A portable, public domain, version of the Data Encryption Standard.
+
+Written with Symantec's THINK (Lightspeed) C by Richard Outerbridge.
+Thanks to: Dan Hoey for his excellent Initial and Inverse permutation
+code;  Jim Gillogly & Phil Karn for the DES key schedule code; Dennis
+Ferguson, Eric Young and Dana How for comparing notes; and Ray Lau,
+for humouring me on. 
+
+Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge.
+(GEnie : OUTER; CIS : [71755,204]) Graven Imagery, 1992.
+
+
+@end verbatim
+
+@copynext
+
+@heading Secure Endpoints Inc
+
+Windows support
+
+@verbatim
+
+Copyright (c) 2009-2015, Secure Endpoints Inc.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+- Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGE.
+
+@end verbatim
+
+@copynext
+
+@heading Novell, Inc
+
+lib/hcrypto/test_dh.c
+
+@verbatim
+
+Copyright (c) 2007, Novell, Inc.
+Author: Matthias Koenig <mkoenig@suse.de>
+
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+* Neither the name of the Novell nor the names of its contributors may be used
+  to endorse or promote products derived from this software without specific
+  prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+
+@end verbatim
+
+@copyrightend
diff --git a/third_party/heimdal/doc/doxytmpl.dxy b/third_party/heimdal/doc/doxytmpl.dxy
new file mode 100644
index 00000000000..1faab2f5252
--- /dev/null
+++ b/third_party/heimdal/doc/doxytmpl.dxy
@@ -0,0 +1,248 @@
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+DOXYFILE_ENCODING      = UTF-8
+CREATE_SUBDIRS         = NO
+OUTPUT_LANGUAGE        = English
+BRIEF_MEMBER_DESC      = YES
+REPEAT_BRIEF           = YES
+ABBREVIATE_BRIEF       = "The $name class " \
+                         "The $name widget " \
+                         "The $name file " \
+                         is \
+                         provides \
+                         specifies \
+                         contains \
+                         represents \
+                         a \
+                         an \
+                         the
+ALWAYS_DETAILED_SEC    = NO
+INLINE_INHERITED_MEMB  = NO
+FULL_PATH_NAMES        = YES
+STRIP_FROM_PATH        = /Applications/
+STRIP_FROM_INC_PATH    = 
+SHORT_NAMES            = NO
+JAVADOC_AUTOBRIEF      = NO
+QT_AUTOBRIEF           = NO
+MULTILINE_CPP_IS_BRIEF = NO
+INHERIT_DOCS           = YES
+SEPARATE_MEMBER_PAGES  = NO
+TAB_SIZE               = 8
+ALIASES                = 
+OPTIMIZE_OUTPUT_FOR_C  = YES
+OPTIMIZE_OUTPUT_JAVA   = NO
+BUILTIN_STL_SUPPORT    = NO
+CPP_CLI_SUPPORT        = NO
+DISTRIBUTE_GROUP_DOC   = NO
+SUBGROUPING            = YES
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+EXTRACT_ALL            = NO
+EXTRACT_PRIVATE        = NO
+EXTRACT_STATIC         = NO
+EXTRACT_LOCAL_CLASSES  = YES
+EXTRACT_LOCAL_METHODS  = NO
+EXTRACT_ANON_NSPACES   = NO
+HIDE_UNDOC_MEMBERS     = YES
+HIDE_UNDOC_CLASSES     = YES
+HIDE_FRIEND_COMPOUNDS  = NO
+HIDE_IN_BODY_DOCS      = NO
+INTERNAL_DOCS          = NO
+CASE_SENSE_NAMES       = NO
+HIDE_SCOPE_NAMES       = NO
+SHOW_INCLUDE_FILES     = YES
+INLINE_INFO            = YES
+SORT_MEMBER_DOCS       = YES
+SORT_BRIEF_DOCS        = NO
+SORT_BY_SCOPE_NAME     = NO
+GENERATE_TODOLIST      = YES
+GENERATE_TESTLIST      = YES
+GENERATE_BUGLIST       = YES
+GENERATE_DEPRECATEDLIST= YES
+ENABLED_SECTIONS       = 
+MAX_INITIALIZER_LINES  = 30
+SHOW_USED_FILES        = YES
+FILE_VERSION_FILTER    = 
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+QUIET                  = YES
+WARNINGS               = YES
+WARN_IF_DOC_ERROR      = YES
+WARN_NO_PARAMDOC       = YES
+WARN_FORMAT            = "$file:$line: $text "
+WARN_LOGFILE           = 
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+INPUT_ENCODING         = UTF-8
+FILE_PATTERNS          = *.c \
+                         *.cc \
+                         *.cxx \
+                         *.cpp \
+                         *.c++ \
+                         *.d \
+                         *.java \
+                         *.ii \
+                         *.ixx \
+                         *.ipp \
+                         *.i++ \
+                         *.inl \
+                         *.h \
+                         *.hh \
+                         *.hxx \
+                         *.hpp \
+                         *.h++ \
+                         *.idl \
+                         *.odl \
+                         *.cs \
+                         *.php \
+                         *.php3 \
+                         *.inc \
+                         *.m \
+                         *.mm \
+                         *.dox
+RECURSIVE              = YES
+EXCLUDE                = 
+EXCLUDE_SYMLINKS       = NO
+EXCLUDE_PATTERNS       = */.svn
+EXCLUDE_SYMBOLS        = 
+EXAMPLE_PATTERNS       = *
+EXAMPLE_RECURSIVE      = NO
+IMAGE_PATH             = 
+INPUT_FILTER           = 
+FILTER_PATTERNS        = 
+FILTER_SOURCE_FILES    = NO
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+SOURCE_BROWSER         = NO
+INLINE_SOURCES         = NO
+STRIP_CODE_COMMENTS    = YES
+REFERENCED_BY_RELATION = NO
+REFERENCES_RELATION    = NO
+REFERENCES_LINK_SOURCE = YES
+USE_HTAGS              = NO
+VERBATIM_HEADERS       = NO
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+ALPHABETICAL_INDEX     = NO
+COLS_IN_ALPHA_INDEX    = 5
+IGNORE_PREFIX          = 
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+GENERATE_HTML          = YES
+HTML_OUTPUT            = html
+HTML_FILE_EXTENSION    = .html
+HTML_STYLESHEET        = 
+GENERATE_HTMLHELP      = NO
+HTML_DYNAMIC_SECTIONS  = NO
+CHM_FILE               = 
+HHC_LOCATION           = 
+GENERATE_CHI           = NO
+BINARY_TOC             = NO
+TOC_EXPAND             = NO
+DISABLE_INDEX          = NO
+ENUM_VALUES_PER_LINE   = 4
+GENERATE_TREEVIEW      = NO
+TREEVIEW_WIDTH         = 250
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+GENERATE_LATEX         = NO
+LATEX_OUTPUT           = latex
+LATEX_CMD_NAME         = latex
+MAKEINDEX_CMD_NAME     = makeindex
+COMPACT_LATEX          = NO
+PAPER_TYPE             = a4wide
+EXTRA_PACKAGES         = 
+LATEX_HEADER           = 
+PDF_HYPERLINKS         = NO
+USE_PDFLATEX           = NO
+LATEX_BATCHMODE        = NO
+LATEX_HIDE_INDICES     = NO
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+GENERATE_RTF           = NO
+RTF_OUTPUT             = rtf
+COMPACT_RTF            = NO
+RTF_HYPERLINKS         = NO
+RTF_STYLESHEET_FILE    = 
+RTF_EXTENSIONS_FILE    = 
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+GENERATE_MAN           = YES
+MAN_OUTPUT             = man
+MAN_EXTENSION          = .3
+MAN_LINKS              = YES
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+GENERATE_XML           = NO
+XML_OUTPUT             = xml
+XML_PROGRAMLISTING     = YES
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+GENERATE_AUTOGEN_DEF   = NO
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+GENERATE_PERLMOD       = NO
+PERLMOD_LATEX          = NO
+PERLMOD_PRETTY         = YES
+PERLMOD_MAKEVAR_PREFIX = 
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor   
+#---------------------------------------------------------------------------
+ENABLE_PREPROCESSING   = YES
+MACRO_EXPANSION        = NO
+EXPAND_ONLY_PREDEF     = NO
+SEARCH_INCLUDES        = YES
+INCLUDE_PATH           = 
+INCLUDE_FILE_PATTERNS  = 
+PREDEFINED             = DOXY
+EXPAND_AS_DEFINED      = 
+SKIP_FUNCTION_MACROS   = YES
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references   
+#---------------------------------------------------------------------------
+TAGFILES               = 
+GENERATE_TAGFILE       = 
+ALLEXTERNALS           = NO
+EXTERNAL_GROUPS        = YES
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool   
+#---------------------------------------------------------------------------
+CLASS_DIAGRAMS         = NO
+HIDE_UNDOC_RELATIONS   = YES
+HAVE_DOT               = YES
+CLASS_GRAPH            = YES
+COLLABORATION_GRAPH    = YES
+GROUP_GRAPHS           = YES
+UML_LOOK               = NO
+TEMPLATE_RELATIONS     = NO
+INCLUDE_GRAPH          = YES
+INCLUDED_BY_GRAPH      = YES
+CALL_GRAPH             = NO
+CALLER_GRAPH           = NO
+GRAPHICAL_HIERARCHY    = YES
+DIRECTORY_GRAPH        = YES
+DOT_IMAGE_FORMAT       = png
+DOTFILE_DIRS           = 
+DOT_GRAPH_MAX_NODES    = 50
+MAX_DOT_GRAPH_DEPTH    = 1000
+DOT_TRANSPARENT        = NO
+DOT_MULTI_TARGETS      = NO
+GENERATE_LEGEND        = YES
+DOT_CLEANUP            = YES
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine   
+#---------------------------------------------------------------------------
+SEARCHENGINE           = NO
diff --git a/third_party/heimdal/doc/footer.html b/third_party/heimdal/doc/footer.html
new file mode 100644
index 00000000000..48990aeb8f8
--- /dev/null
+++ b/third_party/heimdal/doc/footer.html
@@ -0,0 +1,4 @@
+<hr size="1"><address style="text-align: right;"><small>
+Generated on $datetime for $projectname by&nbsp;<a href="http://www.doxygen.org/index.html"><img src="doxygen.png" alt="doxygen" align="middle" border="0"></a> $doxygenversion</small></address>
+</body>
+</html>
diff --git a/third_party/heimdal/doc/gssapi.din b/third_party/heimdal/doc/gssapi.din
new file mode 100644
index 00000000000..3dd8bb61256
--- /dev/null
+++ b/third_party/heimdal/doc/gssapi.din
@@ -0,0 +1,16 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal GSS-API library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/gssapi
+INPUT                  = @srcdir@/../lib/gssapi
+
+WARN_IF_UNDOCUMENTED   = NO
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
+
diff --git a/third_party/heimdal/doc/hcrypto.din b/third_party/heimdal/doc/hcrypto.din
new file mode 100644
index 00000000000..aeea17921af
--- /dev/null
+++ b/third_party/heimdal/doc/hcrypto.din
@@ -0,0 +1,16 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = "Heimdal crypto library"
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/hcrypto
+INPUT                  = @srcdir@/../lib/hcrypto
+EXAMPLE_PATH	       = @srcdir@/../lib/hcrypto
+
+WARN_IF_UNDOCUMENTED   = YES
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/third_party/heimdal/doc/hdb.din b/third_party/heimdal/doc/hdb.din
new file mode 100644
index 00000000000..1b100f46f4c
--- /dev/null
+++ b/third_party/heimdal/doc/hdb.din
@@ -0,0 +1,15 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal hdb library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/hdb
+INPUT                  = @srcdir@/../lib/hdb
+
+WARN_IF_UNDOCUMENTED   = YES
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/third_party/heimdal/doc/header.html b/third_party/heimdal/doc/header.html
new file mode 100644
index 00000000000..b3401c8b8c8
--- /dev/null
+++ b/third_party/heimdal/doc/header.html
@@ -0,0 +1,10 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html><head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+<title>$title</title>
+<link href="$relpath$doxygen.css" rel="stylesheet" type="text/css">
+<link href="$relpath$tabs.css" rel="stylesheet" type="text/css">
+</head><body>
+<p>
+<a href="http://www.h5l.org/"><img src="http://www.h5l.org/keyhole-heimdal.png" alt="keyhole logo"/></a>
+</p>
+<!-- end of header marker -->
diff --git a/third_party/heimdal/doc/heimdal.css b/third_party/heimdal/doc/heimdal.css
new file mode 100644
index 00000000000..2e5b374f1f8
--- /dev/null
+++ b/third_party/heimdal/doc/heimdal.css
@@ -0,0 +1,53 @@
+body {
+	color: black;
+	background-color: #fdfdfd;
+	font-family: serif;
+	max-width: 40em;
+}
+h1, h2, h3 {
+	font-family: sans-serif;
+	font-weight: bold;
+}
+h1 {
+    padding: 0.5em 0 0.5em 5%;
+    color: white;
+    background: #3366cc;
+    border-bottom: solid 1px black;
+}
+h1 {
+	font-size: 200%;
+}
+h2 {
+	font-size: 150%;
+}
+h3 {
+	font-size: 120%;
+}
+h4 {
+	font-weight: bold;
+}
+pre.example {
+	margin-left: 2em;
+	padding: 1em 0em;
+	border: 2px dashed #c0c0c0;
+	background: #f0f0f0;
+}
+a:link {
+  color: blue;
+  text-decoration: none;
+}
+a:visited {
+  color: red;
+  text-decoration: none
+}
+a:hover {
+  text-decoration: underline
+}
+span.literal {
+	font-family: monospace;
+}
+hr {
+	border-style: none;
+	background-color: black;
+	height: 1px;
+}
diff --git a/third_party/heimdal/doc/heimdal.hhp b/third_party/heimdal/doc/heimdal.hhp
new file mode 100644
index 00000000000..2996baa2fa4
--- /dev/null
+++ b/third_party/heimdal/doc/heimdal.hhp
@@ -0,0 +1,8 @@
+[OPTIONS]
+Compatibility=1.1 or later
+Compiled file=heimdal.chm
+Contents file=toc.hhc
+Default topic=index.html
+Display compile progress=No
+Language=0x409 English (United States)
+Title=Heimdal
\ No newline at end of file
diff --git a/third_party/heimdal/doc/heimdal.texi b/third_party/heimdal/doc/heimdal.texi
new file mode 100644
index 00000000000..c8ef24969fb
--- /dev/null
+++ b/third_party/heimdal/doc/heimdal.texi
@@ -0,0 +1,153 @@
+\input texinfo @c -*- texinfo -*-
+@c %**start of header
+@c $Id$
+@setfilename heimdal.info
+@settitle HEIMDAL
+@iftex
+@afourpaper
+@end iftex
+@c some sensible characters, please?
+@tex
+\input latin1.tex
+@end tex
+@setchapternewpage on
+@syncodeindex pg cp
+@c %**end of header
+
+@include vars.texi
+
+@set VERSION @value{PACKAGE_VERSION}
+@set EDITION 1.0
+
+@ifinfo
+@dircategory Security
+@direntry
+* Heimdal: (heimdal).           The Kerberos 5 and PKIX distribution from KTH
+@end direntry
+@end ifinfo
+
+@c title page
+@titlepage
+@title Heimdal
+@subtitle Kerberos 5 and PKIX from KTH
+@subtitle Edition @value{EDITION}, for version @value{VERSION}
+@subtitle 2008
+@author Johan Danielsson
+@author Love Hörnquist Åstrand
+@author Assar Westerlund
+@author et al
+
+@end titlepage
+
+@macro manpage{man, section}
+@cite{\man\(\section\)}
+@end macro
+
+@c Less filling! Tastes great!
+@iftex
+@parindent=0pt
+@global@parskip 6pt plus 1pt
+@global@chapheadingskip = 15pt plus 4pt minus 2pt 
+@global@secheadingskip = 12pt plus 3pt minus 2pt
+@global@subsecheadingskip = 9pt plus 2pt minus 2pt
+@end iftex
+@ifinfo
+@paragraphindent 0
+@end ifinfo
+
+@ifnottex
+@node Top, Introduction, (dir), (dir)
+@top Heimdal
+@end ifnottex
+
+This manual for version @value{VERSION} of Heimdal.
+
+@menu
+* Introduction::                
+* What is Kerberos?::           
+* What is PKIX?::           
+* What is a Certification Authority (CA)?::           
+* What is kx509?::           
+* What is bx509?::           
+* Building and Installing::     
+* Setting up a realm::          
+* Applications::                
+* Things in search for a better place::  
+* Kerberos 4 issues::           
+* Windows compatibility::  
+* Programming with Kerberos::   
+* Migration::                   
+* Acknowledgments::             
+* Copyrights and Licenses::
+
+@detailmenu
+ --- The Detailed Node Listing ---
+
+Setting up a realm
+
+* Configuration file::          
+* Creating the database::       
+* Modifying the database::      
+* keytabs::                     
+* Remote administration::       
+* Password changing::           
+* Testing clients and servers::  
+* Slave Servers::               
+* Incremental propagation::     
+* Encryption types and salting::                     
+* Credential cache server - KCM::
+* Cross realm::                 
+* Transit policy::              
+* Setting up DNS::              
+* Using LDAP to store the database::  
+* Providing Kerberos credentials to servers and programs::  
+* Setting up PK-INIT::
+* Debugging Kerberos problems::
+
+Applications
+
+* Authentication modules::      
+* AFS::                         
+
+Authentication modules
+
+* Digital SIA::                 
+* IRIX::                        
+
+Kerberos 4 issues
+
+* Principal conversion issues::  
+* Converting a version 4 database::  
+
+Windows compatibility
+
+* Configuring Windows to use a Heimdal KDC::  
+* Inter-Realm keys (trust) between Windows and a Heimdal KDC::  
+* Create account mappings::     
+* Encryption types::            
+* Authorisation data::          
+* Quirks of Windows 2000 KDC::  
+* Useful links when reading about the Windows::  
+
+Programming with Kerberos
+
+@end detailmenu
+@end menu
+
+@include intro.texi
+@include whatis.texi
+@include install.texi
+@include setup.texi
+@include apps.texi
+@include misc.texi
+@include kerberos4.texi
+@include win2k.texi
+@include programming.texi
+@include migration.texi
+@include ack.texi
+@include copyright.texi
+
+@c @shortcontents
+@contents
+
+@bye
diff --git a/third_party/heimdal/doc/hx509.din b/third_party/heimdal/doc/hx509.din
new file mode 100644
index 00000000000..c6d02b287c1
--- /dev/null
+++ b/third_party/heimdal/doc/hx509.din
@@ -0,0 +1,15 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal x509 library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/hx509
+INPUT                  = @srcdir@/../lib/hx509
+
+WARN_IF_UNDOCUMENTED   = YES
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/third_party/heimdal/doc/hx509.hhp b/third_party/heimdal/doc/hx509.hhp
new file mode 100644
index 00000000000..bce680aa92b
--- /dev/null
+++ b/third_party/heimdal/doc/hx509.hhp
@@ -0,0 +1,8 @@
+[OPTIONS]
+Compatibility=1.1 or later
+Compiled file=hx509.chm
+Contents file=toc.hhc
+Default topic=index.html
+Display compile progress=No
+Language=0x409 English (United States)
+Title=HX509
\ No newline at end of file
diff --git a/third_party/heimdal/doc/hx509.texi b/third_party/heimdal/doc/hx509.texi
new file mode 100644
index 00000000000..0a90cb73528
--- /dev/null
+++ b/third_party/heimdal/doc/hx509.texi
@@ -0,0 +1,786 @@
+\input texinfo @c -*- texinfo -*-
+@c %**start of header
+@c $Id$
+@setfilename hx509.info
+@settitle HX509
+@iftex
+@afourpaper
+@end iftex
+@c some sensible characters, please?
+@tex
+\input latin1.tex
+@end tex
+@setchapternewpage on
+@syncodeindex pg cp
+@c %**end of header
+
+@include vars.texi
+
+@set VERSION @value{PACKAGE_VERSION}
+@set EDITION 1.0
+
+@ifinfo
+@dircategory Security
+@direntry
+* hx509: (hx509).               The X.509 distribution from KTH
+@end direntry
+@end ifinfo
+
+@c title page
+@titlepage
+@title HX509
+@subtitle X.509 distribution from KTH
+@subtitle Edition @value{EDITION}, for version @value{VERSION}
+@subtitle 2008
+@author Love Hörnquist Åstrand
+
+@iftex
+@def@copynext{@vskip 20pt plus 1fil}
+@def@copyrightstart{}
+@def@copyrightend{}
+@end iftex
+@macro copynext
+@end macro
+@macro copyrightstart
+@end macro
+@macro copyrightend
+@end macro
+
+@page
+@copyrightstart
+Copyright (c) 1994-2019 Kungliga Tekniska Högskolan
+(Royal Institute of Technology, Stockholm, Sweden).
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the Institute nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@copynext
+
+Copyright (c) 1988, 1990, 1993
+     The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+@copynext
+
+Copyright 1992 Simmule Turner and Rich Salz.  All rights reserved.
+
+This software is not subject to any license of the American Telephone
+and Telegraph Company or of the Regents of the University of California.
+
+Permission is granted to anyone to use this software for any purpose on
+any computer system, and to alter it and redistribute it freely, subject
+to the following restrictions:
+
+1. The authors are not responsible for the consequences of use of this
+   software, no matter how awful, even if they arise from flaws in it.
+
+2. The origin of this software must not be misrepresented, either by
+   explicit claim or by omission.  Since few users ever read sources,
+   credits must appear in the documentation.
+
+3. Altered versions must be plainly marked as such, and must not be
+   misrepresented as being the original software.  Since few users
+   ever read sources, credits must appear in the documentation.
+
+4. This notice may not be removed or altered.
+
+@copynext
+
+IMath is Copyright 2002-2005 Michael J. Fromberger
+You may use it subject to the following Licensing Terms:
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+@copyrightend
+@end titlepage
+
+@macro manpage{man, section}
+@cite{\man\(\section\)}
+@end macro
+
+@c Less filling! Tastes great!
+@iftex
+@parindent=0pt
+@global@parskip 6pt plus 1pt
+@global@chapheadingskip = 15pt plus 4pt minus 2pt
+@global@secheadingskip = 12pt plus 3pt minus 2pt
+@global@subsecheadingskip = 9pt plus 2pt minus 2pt
+@end iftex
+@ifinfo
+@paragraphindent 0
+@end ifinfo
+
+@ifnottex
+@node Top, Introduction, (dir), (dir)
+@top Heimdal
+@end ifnottex
+
+This manual is for version @value{VERSION} of hx509.
+
+@menu
+* Introduction::
+* What are X.509 and PKIX ?::
+* Setting up a CA::
+* CMS signing and encryption::
+* Certificate matching::
+* Software PKCS 11 module::
+* Creating a CA certificate::
+* Issuing certificates::
+* Issuing CRLs::
+* Application requirements::
+* CMS background::
+* Matching syntax::
+* How to use the PKCS11 module::
+
+@detailmenu
+ --- The Detailed Node Listing ---
+
+Setting up a CA
+
+@c * Issuing certificates::
+* Creating a CA certificate::
+* Issuing certificates::
+* Issuing CRLs::
+@c * Issuing a proxy certificate::
+@c * Creating a user certificate::
+@c * Validating a certificate::
+@c * Validating a certificate path::
+* Application requirements::
+
+CMS signing and encryption
+
+* CMS background::
+
+Certificate matching
+
+* Matching syntax::
+
+Software PKCS 11 module
+
+* How to use the PKCS11 module::
+
+@end detailmenu
+@end menu
+
+@node Introduction, What are X.509 and PKIX ?, Top, Top
+@chapter Introduction
+
+A Public Key Infrastructure (PKI) is an authentication mechanism based on
+entities having certified cryptographic public keys and corresponding private
+(secret) keys.
+
+The ITU-T PKI specifications are designated "x.509", while the IETF PKI
+specifications (PKIX) are specified by a number of Internet RFCs and are based
+on x.509.
+
+The goals of a PKI (as stated in 
+<a href="http://www.ietf.org/rfc/rfc5280.txt">RFC 5280</a>) is to meet 
+@emph{the needs of deterministic, automated identification, authentication, access control, and authorization}.
+
+The administrator should be aware of certain terminologies as explained by the aforementioned
+RFC before attemping to put in place a PKI infrastructure. Briefly, these are: 
+
+@itemize @bullet
+@item CA
+Certificate Authority
+@item RA
+Registration Authority, i.e., an optional system to which a CA delegates certain management functions.
+@item Certificate
+A binary document that names an entity and its public key and which is signed
+by an issuing CA.
+@item CRL Issuer
+An optional system to which a CA delegates the publication of certificate revocation lists.
+@item Repository
+A system or collection of distributed systems that stores certificates and CRLs 
+and serves as a means of distributing these certificates and CRLs to end entities
+@end itemize
+
+hx509 (Heimdal x509 support) is a near complete X.509/PKIX stack that can
+handle CMS messages (crypto system used in S/MIME and Kerberos PK-INIT)
+and basic certificate processing tasks, path construction, path
+validation, OCSP and CRL validation, PKCS10 message construction, CMS
+Encrypted (shared secret encrypted), CMS SignedData (certificate
+signed), and CMS EnvelopedData (certificate encrypted).
+
+hx509 can use PKCS11 tokens, PKCS12 files, PEM files, and/or DER encoded
+files.
+
+hx509 consists of a library (libhx509) and a command-line utility (hxtool), as
+well as a RESTful, HTTPS-based service that implements an online CA.
+
+@node What are X.509 and PKIX ?, Setting up a CA, Introduction, Top
+@chapter What are X.509 and PKIX, PKIX, PKCS7 and CMS ? 
+
+X.509 was created by CCITT (later ITU-T) for the X.500 directory
+service. Today, X.509 discussions and implementations commonly reference
+the IETF's PKIX Certificate and CRL Profile of the X.509 v3 certificate
+standard, as specified in RFC 3280.
+
+ITU continues to develop the X.509 standard together with the IETF in a 
+rather complicated dance.
+
+X.509 is a public key based security system that has associated data
+stored within a so called certificate. Initially, X.509 was a strict
+hierarchical system with one root. However, ever evolving requiments and
+technology advancements saw the inclusion of multiple policy roots,
+bridges and mesh solutions.
+
+x.509 can also be used as a peer to peer system, though often seen as a
+common scenario.
+
+@section Type of certificates
+
+There are several flavors of certificate in X.509.
+
+@itemize @bullet
+
+@item Trust anchors
+
+Trust anchors are strictly not certificates, but commonly stored in a
+certificate format as they become easier to manage. Trust anchors are
+the keys that an end entity would trust to validate other certificates.
+This is done by building a path from the certificate you want to
+validate to to any of the trust anchors you have.
+
+@item End Entity (EE) certificates
+
+End entity certificates are the most common types of certificates. End
+entity certificates cannot issue (sign) certificate themselves and are generally
+used to authenticate and authorize users and services.
+
+@item Certification Authority (CA) certificates
+
+Certificate authority certificates have the right to issue additional
+certificates (be it sub-ordinate CA certificates to build an trust anchors
+or end entity certificates). There is no limit to how many certificates a CA
+may issue, but there might other restrictions, like the maximum path
+depth.
+
+@item Proxy certificates
+
+Remember the statement "End Entity certificates cannot issue
+certificates"?  Well that statement is not entirely true. There is an
+extension called proxy certificates defined in RFC3820, that allows
+certificates to be issued by end entity certificates. The service that
+receives the proxy certificates must have explicitly turned on support
+for proxy certificates, so their use is somewhat limited.
+
+Proxy certificates can be limited by policies stored in the certificate to
+what they can be used for. This allows users to delegate the proxy
+certificate to services (by sending over the certificate and private
+key) so the service can access services on behalf of the user.
+
+One example of this would be a print service. The user wants to print a
+large job in the middle of the night when the printer isn't used that
+much, so the user creates a proxy certificate with the policy that it
+can only be used to access files related to this print job, creates the
+print job description and send both the description and proxy
+certificate with key over to print service. Later at night when the
+print service initializes (without any user intervention), access to the files 
+for the print job is granted via the proxy certificate. As a result of (in-place) 
+policy limitations, the certificate cannot be used for any other purposes.
+
+@end itemize
+
+@section Building a path
+
+Before validating a certificate path (or chain), the path needs to be
+constructed.  Given a certificate (EE, CA, Proxy, or any other type),
+the path construction algorithm will try to find a path to one of the
+trust anchors.
+
+The process starts by looking at the issuing CA of the certificate, by
+Name or Key Identifier, and tries to find that certificate while at the
+same time evaluting any policies in-place.
+
+@node Setting up a CA, Creating a CA certificate, What are X.509 and PKIX ?, Top
+@chapter Setting up a CA
+
+Do not let information overload scare you off! If you are simply testing
+or getting started with a PKI infrastructure, skip all this and go to
+the next chapter (see: @pxref{Creating a CA certificate}).
+
+Creating a CA certificate should be more the just creating a
+certificate, CA's should define a policy. Again, if you are simply
+testing a PKI, policies do not matter so much. However, when it comes to
+trust in an organisation, it will probably matter more whom your users
+and sysadmins will find it acceptable to trust.
+
+At the same time, try to keep things simple, it's not very hard to run a
+Certificate authority and the process to get new certificates should be simple.
+
+You may find it helpful to answer the following policy questions for
+your organization at a later stage:
+
+@itemize @bullet
+@item How do you trust your CA.
+@item What is the CA responsibility.
+@item Review of CA activity.
+@item How much process should it be to issue certificate.
+@item Who is allowed to issue certificates.
+@item Who is allowed to requests certificates.
+@item How to handle certificate revocation, issuing CRLs and maintain OCSP services.
+@end itemize
+
+@node Creating a CA certificate, Issuing certificates, Setting up a CA, Top
+@section Creating a CA certificate
+
+This section describes how to create a CA certificate and what to think
+about.
+
+@subsection Lifetime CA certificate
+
+You probably want to create a CA certificate with a long lifetime, 10
+years at the very minimum. This is because you don't want to push out the
+certificate (as a trust anchor) to all you users again when the old
+CA certificate expires. Although a trust anchor can't really expire, not all
+software works in accordance with published standards.
+
+Keep in mind the security requirements might be different 10-20 years
+into the future. For example, SHA1 is going to be withdrawn in 2010, so
+make sure you have enough buffering in your choice of digest/hash
+algorithms, signature algorithms and key lengths.
+
+@subsection Create a CA certificate
+
+This command below can be used to generate a self-signed CA certificate.
+
+@example
+hxtool issue-certificate \
+    --self-signed \
+    --issue-ca \
+    --generate-key=rsa \
+    --subject="CN=CertificateAuthority,DC=test,DC=h5l,DC=se" \
+    --lifetime=10years \
+    --certificate="FILE:ca.pem"
+@end example
+
+@subsection Extending the lifetime of a CA certificate
+
+You just realised that your CA certificate is going to expire soon and
+that you need replace it with a new CA. The easiest way to do that
+is to extend the lifetime of your existing CA certificate.
+
+The example below will extend the CA certificate's lifetime by 10 years. 
+You should compare this new certificate if it contains all the
+special tweaks as the old certificate had.
+
+@example
+hxtool issue-certificate \
+    --self-signed \
+    --issue-ca \
+    --lifetime="10years" \
+    --template-certificate="FILE:ca.pem" \
+    --template-fields="serialNumber,notBefore,subject,SPKI" \
+    --ca-private-key=FILE:ca.pem \
+    --certificate="FILE:new-ca.pem"
+@end example
+
+@subsection Subordinate CA
+
+This example below creates a new subordinate certificate authority.
+
+@example
+hxtool issue-certificate \
+    --ca-certificate=FILE:ca.pem \
+    --issue-ca \
+    --generate-key=rsa \
+    --subject="CN=CertificateAuthority,DC=dev,DC=test,DC=h5l,DC=se" \
+    --certificate="FILE:dev-ca.pem"
+@end example
+
+
+@node Issuing certificates, Issuing CRLs, Creating a CA certificate, Top
+@section Issuing certificates
+
+First you'll create a CA certificate, after that you have to deal with
+your users and servers and issue certificates to them.
+
+@c I think this section needs a bit of clarity. Can I add a separate
+@c section which explains CSRs as well?
+
+
+@itemize @bullet
+
+@item Do all the work themself
+
+Generate the key for the user. This has the problme that the the CA
+knows the private key of the user. For a paranoid user this might leave
+feeling of disconfort.
+
+@item Have the user do part of the work
+
+Receive PKCS10 certificate requests fromusers. PKCS10 is a request for a
+certificate.  The user may specify what DN they want as well as provide
+a certificate signing request (CSR).  To prove the user have the key,
+the whole request is signed by the private key of the user.
+
+@end itemize
+
+@subsection Name space management
+
+@c The explanation given below is slightly unclear. I will re-read the
+@c RFC and document accordingly
+
+What people might want to see.
+
+Re-issue certificates just because people moved within the organization.
+
+Expose privacy information.
+
+Using Sub-component name (+ notation).
+
+@subsection Certificate Revocation, CRL and OCSP
+
+Certificates that a CA issues may need to be revoked at some stage. As
+an example, an employee leaves the organization and does not bother
+handing in his smart card (or even if the smart card is handed back --
+the certificate on it must no longer be acceptable to services; the
+employee has left).
+
+You may also want to revoke a certificate for a service which is no
+longer being offered on your network. Overlooking these scenarios can
+lead to security holes which will quickly become a nightmare to deal
+with.
+
+There are two primary protocols for dealing with certificate
+revokation. Namely:
+
+@itemize @bullet
+@item Certificate Revocation List (CRL)
+@item Online Certificate Status Protocol (OCSP)
+@end itemize
+
+If however the certificate in qeustion has been destroyed, there is no
+need to revoke the certificate because it can not be used by someone
+else. This matter since for each certificate you add to CRL, the
+download time and processing time for clients are longer.
+
+CRLs and OCSP responders however greatly help manage compatible services
+which may authenticate and authorize users (or services) on an on-going
+basis. As an example, VPN connectivity established via certificates for
+connecting clients would require your VPN software to make use of a CRL
+or an OCSP service to ensure revoked certificates belonging to former
+clients are not allowed access to (formerly subscribed) network
+services.
+
+
+@node Issuing CRLs, Application requirements, Issuing certificates, Top
+@section Issuing CRLs
+
+Create an empty CRL with no certificates revoked. Default expiration
+value is one year from now.
+
+@example
+hxtool crl-sign \
+	--crl-file=crl.der \
+	--signer=FILE:ca.pem
+@end example
+
+Create a CRL with all certificates in the directory
+@file{/path/to/revoked/dir} included in the CRL as revoked.  Also make
+it expire one month from now.
+
+@example
+hxtool crl-sign \
+	--crl-file=crl.der \
+        --signer=FILE:ca.pem \
+	--lifetime='1 month' \
+        DIR:/path/to/revoked/dir
+@end example
+
+@node Application requirements, CMS signing and encryption, Issuing CRLs, Top
+@section Application requirements
+
+Application place different requirements on certificates. This section
+tries to expand what they are and how to use hxtool to generate
+certificates for those services.
+
+@subsection HTTPS - server
+
+@example
+hxtool issue-certificate \
+	  --subject="CN=www.test.h5l.se,DC=test,DC=h5l,DC=se" \
+	  --type="https-server" \
+          --hostname="www.test.h5l.se" \
+          --hostname="www2.test.h5l.se" \
+          ...
+@end example
+
+@subsection HTTPS - client
+
+@example
+hxtool issue-certificate \
+	  --subject="UID=testus,DC=test,DC=h5l,DC=se" \
+	  --type="https-client" \
+          ...
+@end example
+
+@subsection S/MIME - email
+
+There are two things that should be set in S/MIME certificates, one or
+more email addresses and an extended eku usage (EKU), emailProtection.
+
+The email address format used in S/MIME certificates is defined in
+RFC2822, section 3.4.1 and it should be an ``addr-spec''.
+
+There are two ways to specifify email address in certificates. The old
+way is in the subject distinguished name, @emph{this should not be used}. The
+new way is using a Subject Alternative Name (SAN).
+
+Even though the email address is stored in certificates, they don't need
+to be, email reader programs are required to accept certificates that
+doesn't have either of the two methods of storing email in certificates
+-- in which case, the email client will try to protect the user by
+printing the name of the certificate instead.
+
+S/MIME certificate can be used in another special way. They can be
+issued with a NULL subject distinguished name plus the email in SAN,
+this is a valid certificate. This is used when you wont want to share
+more information then you need to.
+
+hx509 issue-certificate supports adding the email SAN to certificate by
+using the --email option, --email also gives an implicit emailProtection
+eku. If you want to create an certificate without an email address, the
+option --type=email will add the emailProtection EKU.
+
+@example
+hxtool issue-certificate \
+	  --subject="UID=testus-email,DC=test,DC=h5l,DC=se" \
+	  --type=email \
+	  --email="testus@@test.h5l.se" \
+          ...
+@end example
+
+An example of an certificate without and subject distinguished name with
+an email address in a SAN.
+
+@example
+hxtool issue-certificate \
+	  --subject="" \
+	  --type=email \
+	  --email="testus@@test.h5l.se" \
+          ...
+@end example
+
+@subsection PK-INIT
+
+A PK-INIT infrastructure allows users and services to pick up kerberos
+credentials (tickets) based on their certificate. This, for example,
+allows users to authenticate to their desktops using smartcards while
+acquiring kerberos tickets in the process.
+
+As an example, an office network which offers centrally controlled
+desktop logins, mail, messaging (xmpp) and openafs would give users
+single sign-on facilities via smartcard based logins.  Once the kerberos
+ticket has been acquired, all kerberized services would immediately
+become accessible based on deployed security policies.
+
+Let's go over the process of initializing a demo PK-INIT framework:
+
+@example
+hxtool issue-certificate \
+        --type="pkinit-kdc" \
+        --pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \
+        --hostname=kerberos.test.h5l.se \
+        --ca-certificate="FILE:ca.pem,ca.key" \
+        --generate-key=rsa \
+        --certificate="FILE:kdc.pem" \
+        --subject="cn=kdc"
+@end example
+
+How to create a certificate for a user.
+
+@example
+hxtool issue-certificate \
+        --type="pkinit-client" \
+        --pk-init-principal="user@@TEST.H5L.SE" \
+        --ca-certificate="FILE:ca.pem,ca.key" \
+        --generate-key=rsa \
+        --subject="cn=Test User" \
+        --certificate="FILE:user.pem"
+@end example
+
+The --type field can be specified multiple times. The same certificate
+can hence house extensions for both pkinit-client as well as S/MIME.
+
+To use the PKCS11 module, please see the section:
+@pxref{How to use the PKCS11 module}.
+
+More about how to configure the KDC, see the documentation in the
+Heimdal manual to set up the KDC.
+
+@subsection XMPP/Jabber
+
+The jabber server certificate should have a dNSname that is the same as
+the user entered into the application, not the same as the host name of
+the machine.
+
+@example
+hxtool issue-certificate \
+	  --subject="CN=xmpp1.test.h5l.se,DC=test,DC=h5l,DC=se" \
+          --hostname="xmpp1.test.h5l.se" \
+          --hostname="test.h5l.se" \
+          ...
+@end example
+
+The certificate may also contain a jabber identifier (JID) that, if the
+receiver allows it, authorises the server or client to use that JID.
+
+When storing a JID inside the certificate, both for server and client,
+it's stored inside a UTF8String within an otherName entity inside the
+subjectAltName, using the OID id-on-xmppAddr (1.3.6.1.5.5.7.8.5).
+
+To read more about the requirements, see RFC3920, Extensible Messaging
+and Presence Protocol (XMPP): Core.
+
+hxtool issue-certificate have support to add jid to the certificate
+using the option @kbd{--jid}.
+
+@example
+hxtool issue-certificate \
+	  --subject="CN=Love,DC=test,DC=h5l,DC=se" \
+          --jid="lha@@test.h5l.se" \
+          ...
+@end example
+
+
+@node CMS signing and encryption, CMS background, Application requirements, Top
+@chapter CMS signing and encryption
+
+CMS is the Cryptographic Message System that among other, is used by
+S/MIME (secure email) and Kerberos PK-INIT. It's an extended version of
+the RSA, Inc standard PKCS7.
+
+@node CMS background, Certificate matching, CMS signing and encryption, Top
+@section CMS background
+
+
+@node Certificate matching, Matching syntax, CMS background, Top
+@chapter Certificate matching
+
+To match certificates hx509 have a special query language to match
+certifictes in queries and ACLs.
+
+@node Matching syntax, Software PKCS 11 module, Certificate matching, Top
+@section Matching syntax
+
+This is the language definitions somewhat slopply descriped:
+
+@example
+
+expr = TRUE, 
+     FALSE,
+     ! expr,
+     expr AND expr,
+     expr OR expr,
+     ( expr )
+     compare
+
+compare =
+     word == word,
+     word != word,
+     word IN ( word [, word ...])
+     word IN %@{variable.subvariable@}
+
+word =
+     STRING,
+     %@{variable@}
+
+@end example
+
+@node Software PKCS 11 module, How to use the PKCS11 module, Matching syntax, Top
+@chapter Software PKCS 11 module
+
+PKCS11 is a standard created by RSA, Inc to support hardware and
+software encryption modules. It can be used by smartcard to expose the
+crypto primitives inside without exposing the crypto keys.
+
+Hx509 includes a software implementation of PKCS11 that runs within the
+memory space of the process and thus exposes the keys to the
+application.
+
+@node How to use the PKCS11 module, , Software PKCS 11 module, Top
+@section How to use the PKCS11 module
+
+@example
+$ cat > ~/.soft-pkcs11.rc <<EOF
+mycert	cert	User certificate	FILE:/Users/lha/Private/pkinit.pem
+app-fatal	true
+EOF
+$ kinit -C PKCS11:/usr/heimdal/lib/hx509.so lha@@EXAMPLE.ORG
+@end example
+
+
+@c @shortcontents
+@contents
+
+@bye
diff --git a/third_party/heimdal/doc/init-creds b/third_party/heimdal/doc/init-creds
new file mode 100644
index 00000000000..8892d29ff40
--- /dev/null
+++ b/third_party/heimdal/doc/init-creds
@@ -0,0 +1,374 @@
+Currently, getting an initial ticket for a user involves many function
+calls, especially when a full set of features including password
+expiration and challenge preauthentication is desired.  In order to
+solve this problem, a new api is proposed.
+
+typedef struct _krb5_prompt {
+    char *prompt;
+    int hidden;
+    krb5_data *reply;
+} krb5_prompt;
+
+typedef int (*krb5_prompter_fct)(krb5_context context,
+				 void *data,
+				 const char *banner,
+				 int num_prompts,
+				 krb5_prompt prompts[]);
+
+typedef struct _krb5_get_init_creds_opt {
+    krb5_flags flags;
+    krb5_deltat tkt_life;
+    krb5_deltat renew_life;
+    int forwardable;
+    int proxiable;
+    krb5_enctype *etype_list;
+    int etype_list_length;
+    krb5_address **address_list;
+	/* XXX the next three should not be used, as they may be
+	removed later */
+    krb5_preauthtype *preauth_list;
+    int preauth_list_length;
+    krb5_data *salt;
+} krb5_get_init_creds_opt;
+
+#define KRB5_GET_INIT_CREDS_OPT_TKT_LIFE	0x0001
+#define KRB5_GET_INIT_CREDS_OPT_RENEW_LIFE	0x0002
+#define KRB5_GET_INIT_CREDS_OPT_FORWARDABLE	0x0004
+#define KRB5_GET_INIT_CREDS_OPT_PROXIABLE	0x0008
+#define KRB5_GET_INIT_CREDS_OPT_ETYPE_LIST	0x0010
+#define KRB5_GET_INIT_CREDS_OPT_ADDRESS_LIST	0x0020
+#define KRB5_GET_INIT_CREDS_OPT_PREAUTH_LIST	0x0040
+#define KRB5_GET_INIT_CREDS_OPT_SALT		0x0080
+
+void krb5_get_init_creds_opt_init(krb5_get_init_creds_opt *opt);
+
+void krb5_get_init_creds_opt_set_tkt_life(krb5_get_init_creds_opt *opt,
+					  krb5_deltat tkt_life);
+void krb5_get_init_creds_opt_set_renew_life(krb5_get_init_creds_opt *opt,
+					    krb5_deltat renew_life);
+void krb5_get_init_creds_opt_set_forwardable(krb5_get_init_creds_opt *opt,
+					     int forwardable);
+void krb5_get_init_creds_opt_set_proxiable(krb5_get_init_creds_opt *opt,
+					   int proxiable);
+void krb5_get_init_creds_opt_set_etype_list(krb5_get_init_creds_opt *opt,
+					    krb5_enctype *etype_list,
+					    int etype_list_length);
+void krb5_get_init_creds_opt_set_address_list(krb5_get_init_creds_opt *opt,
+					      krb5_address **addresses);
+void krb5_get_init_creds_opt_set_preauth_list(krb5_get_init_creds_opt *opt,
+					      krb5_preauthtype *preauth_list,
+					      int preauth_list_length);
+void krb5_get_init_creds_opt_set_salt(krb5_get_init_creds_opt *opt,
+				      krb5_data *salt);
+
+krb5_error_code
+krb5_get_init_creds_password(krb5_context context,
+			     krb5_creds *creds,
+			     krb5_principal client,
+			     char *password,
+			     krb5_prompter_fct prompter,
+			     void *data,
+			     krb5_deltat start_time,
+			     char *in_tkt_service,
+			     krb5_get_init_creds_opt *options);
+
+This function will attempt to acquire an initial ticket.  The function
+will perform whatever tasks are necessary to do so.  This may include
+changing an expired password, preauthentication.
+
+The arguments divide into two types.  Some arguments are basically
+invariant and arbitrary across all initial tickets, and if not
+specified are determined by configuration or library defaults.  Some
+arguments are different for each execution or application, and if not
+specified can be determined correctly from system configuration or
+environment.  The former arguments are contained in a structure whose
+pointer is passed to the function.  A bitmask specifies which elements
+of the structure should be used.  In most cases, a NULL pointer can be
+used.  The latter arguments are specified as individual arguments to
+the function.
+
+If a pointer to a credential is specified, the initial credential is
+filled in.  If the caller only wishes to do a simple password check
+and will not be doing any other kerberos functions, then a NULL
+pointer may be specified, and the credential will be destroyed.
+
+If the client name is non-NULL, the initial ticket requested will be
+for that principal.  Otherwise, the principal will be the username
+specified by the USER environment variable, or if the USER environment
+variable is not set, the username corresponding to the real user id of
+the caller.
+
+If the password is non-NULL, then this string is used as the password.
+Otherwise, the prompter function will be used to prompt the user for
+the password.
+
+If a prompter function is non-NULL, it will be used if additional user
+input is required, such as if the user's password has expired and
+needs to be changed, or if input preauthentication is necessary.  If
+no function is specified and input is required, then the login will
+fail.
+
+	The context argument is the same as that passed to krb5_login.
+	The data argument is passed unmodified to the prompter
+	function and is intended to be used to pass application data
+	(such as a display handle) to the prompter function.
+
+	The banner argument, if non-NULL, will indicate what sort of
+	input is expected from the user (for example, "Password has
+	expired and must be changed" or "Enter Activcard response for
+	challenge 012345678"), and should be displayed accordingly.
+	
+	The num_prompts argument indicates the number of values which
+	should be prompted for.  If num_prompts == 0, then the banner
+	contains an informational message which should be displayed to
+	the user.
+
+	The prompts argument contains an array describing the values
+	for which the user should be prompted.  The prompt member
+	indicates the prompt for each value ("Enter new
+	password"/"Enter it again", or "Challenge response").  The
+	hidden member is nonzero if the response should not be
+	displayed back to the user.  The reply member is a pointer to
+	krb5_data structure which has already been allocated.  The
+	prompter should fill in the structure with the NUL-terminated
+	response from the user.
+
+	If the response data does not fit, or if any other error
+	occurs, then the prompter function should return a non-zero
+	value which will be returned by the krb5_get_init_creds
+	function. Otherwise, zero should be returned.
+
+	The library function krb5_prompter_posix() implements
+	a prompter using a posix terminal for user in.  This function
+	does not use the data argument.
+
+If the start_time is zero, then the requested ticket will be valid
+beginning immediately.  Otherwise, the start_time indicates how far in
+the future the ticket should be postdated.
+
+If the in_tkt_service name is non-NULL, that principal name will be
+used as the server name for the initial ticket request.  The realm of
+the name specified will be ignored and will be set to the realm of the
+client name.  If no in_tkt_service name is specified,
+krbtgt/CLIENT-REALM@CLIENT-REALM will be used.
+
+For the rest of arguments, a configuration or library default will be
+used if no value is specified in the options structure.
+
+If a tkt_life is specified, that will be the lifetime of the ticket.
+The library default is 10 hours; there is no configuration variable
+(there should be, but it's not there now).
+
+If a renew_life is specified and non-zero, then the RENEWABLE option
+on the ticket will be set, and the value of the argument will be the
+the renewable lifetime.  The configuration variable [libdefaults]
+"renew_lifetime" is the renewable lifetime if none is passed in.  The
+library default is not to set the RENEWABLE option.
+
+If forwardable is specified, the FORWARDABLE option on the ticket will
+be set if and only if forwardable is non-zero.  The configuration
+variable [libdefaults] "forwardable" is used if no value is passed in.
+The option will be set if and only if the variable is "y", "yes",
+"true", "t", "1", or "on", case insensitive.  The library default is
+not to set the FORWARDABLE option.
+
+If proxiable is specified, the PROXIABLE option on the ticket will be
+set if and only if proxiable is non-zero.  The configuration variable
+[libdefaults] "proxiable" is used if no value is passed in.  The
+option will be set if and only if the variable is "y", "yes", "true",
+"t", "1", or "on", case insensitive.  The library default is not to
+set the PROXIABLE option.
+
+If etype_list is specified, it will be used as the list of desired
+encryption algorithms in the request.  The configuration variable
+[libdefaults] "default_tkt_enctypes" is used if no value is passed in.
+The library default is "des-cbc-md5 des-cbc-crc".
+
+If address_list is specified, it will be used as the list of addresses
+for which the ticket will be valid.  The library default is to use all
+local non-loopback addresses.  There is no configuration variable.
+
+If preauth_list is specified, it names preauth data types which will
+be included in the request.  The library default is to interact with
+the kdc to determine the required preauth types.  There is no
+configuration variable.
+
+If salt is specified, it specifies the salt which will be used when
+converting the password to a key.  The library default is to interact
+with the kdc to determine the correct salt.  There is no configuration
+variable.
+
+================================================================
+
+typedef struct _krb5_verify_init_creds_opt {
+    krb5_flags flags;
+    int ap_req_nofail;
+} krb5_verify_init_creds_opt;
+
+#define KRB5_VERIFY_INIT_CREDS_OPT_AP_REQ_NOFAIL	0x0001
+
+void krb5_verify_init_creds_opt_init(krb5_init_creds_opt *options);
+void krb5_verify_init_creds_opt_set_ap_req_nofail(krb5_init_creds_opt *options,
+						  int ap_req_nofail);
+
+krb5_error_code
+krb5_verify_init_creds(krb5_context context,
+		       krb5_creds *creds,
+		       krb5_principal ap_req_server,
+		       krb5_keytab ap_req_keytab,
+		       krb5_ccache *ccache,
+		       krb5_verify_init_creds_opt *options);
+
+This function will use the initial ticket in creds to make an AP_REQ
+and verify it to insure that the AS_REP has not been spoofed.
+
+If the ap_req_server name is non-NULL, then this service name will be
+used for the AP_REQ; otherwise, the default host key
+(host/hostname.domain@LOCAL-REALM) will be used.
+
+If ap_req_keytab is non-NULL, the service key for the verification
+will be read from that keytab; otherwise, the service key will be read
+from the default keytab. 
+
+If the service of the ticket in creds is the same as the service name
+for the AP_REQ, then this ticket will be used directly.  If the ticket
+is a tgt, then it will be used to obtain credentials for the service.
+Otherwise, the verification will fail, and return an error.
+
+Other failures of the AP_REQ verification may or may not be considered
+errors, as described below.
+
+If a pointer to a credential cache handle is specified, and the handle
+is NULL, a credential cache handle referring to all credentials
+obtained in the course of verifying the user will be returned.  In
+order to avoid potential setuid race conditions and other problems
+related to file system access, this handle will refer to a memory
+credential cache.  If the handle is non-NULL, then the credentials
+will be added to the existing ccache.  If the caller only wishes to
+verify the password and will not be doing any other kerberos
+functions, then a NULL pointer may be specified, and the credentials
+will be deleted before the function returns.
+
+If ap_req_nofail is specified, then failures of the AP_REQ
+verification are considered errors if and only if ap_req_nofail is
+non-zero.
+
+Whether or not AP_REQ validation is performed and what failures mean
+depends on these inputs:
+
+ A) The appropriate keytab exists and contains the named key.
+
+ B) An AP_REQ request to the kdc succeeds, and the resulting AP_REQ
+can be decrypted and verified.
+
+ C) The administrator has specified in a configuration file that
+AP_REQ validation must succeed.  This is basically a paranoid bit, and
+can be overridden by the application based on a command line flag or
+other application-specific info.  This flag is especially useful if
+the admin is concerned that DNS might be spoofed while determining the
+host/FQDN name.  The configuration variable [libdefaults]
+"verify_ap_req_nofail" is used if no value is passed in.  The library
+default is not to set this option.
+
+Initial ticket verification will succeed if and only if:
+
+ - A && B    or
+ - !A && !C
+
+================================================================
+
+For illustrative purposes, here's the invocations I expect some
+programs will use.  Of course, error checking needs to be added.
+
+kinit:
+
+    /* Fill in client from the command line || existing ccache, and,
+       start_time, and options.{tkt_life,renew_life,forwardable,proxiable}
+       from the command line.  Some or all may remain unset. */
+
+    krb5_get_init_creds(context, &creds, client,
+			krb5_initial_prompter_posix, NULL,
+			start_time, NULL, &options);
+    krb5_cc_store_cred(context, ccache, &creds);
+    krb5_free_cred_contents(context, &creds);
+
+login:
+
+    krb5_get_init_creds(context, &creds, client,
+			krb5_initial_prompter_posix, NULL,
+			0, NULL, NULL);
+    krb5_verify_init_creds(context, &creds, NULL, NULL, &vcc, NULL);
+    /* setuid */
+    krb5_cc_store_cred(context, ccache, &creds);
+    krb5_cc_copy(context, vcc, ccache);
+    krb5_free_cred_contents(context, &creds);
+    krb5_cc_destroy(context, vcc);
+
+xdm:
+
+    krb5_get_initial_creds(context, &creds, client,
+			   krb5_initial_prompter_xt, (void *) &xtstuff,
+			   0, NULL, NULL);
+    krb5_verify_init_creds(context, &creds, NULL, NULL, &vcc, NULL);
+    /* setuid */
+    krb5_cc_store_cred(context, ccache, &creds);
+    krb5_free_cred_contents(context, &creds);
+    krb5_cc_copy(context, vcc, ccache);
+    krb5_cc_destroy(context, vcc);
+
+passwd:
+
+    krb5_init_creds_opt_init(&options);
+    krb5_init_creds_opt_set_tkt_life = 300;
+    krb5_get_initial_creds(context, &creds, client,
+			   krb5_initial_prompter_posix, NULL,
+			   0, "kadmin/changepw", &options);
+    /* change password */
+    krb5_free_cred_contents(context, &creds);
+
+pop3d (simple password validator when no user interation possible):
+
+    krb5_get_initial_creds(context, &creds, client,
+			   NULL, NULL, 0, NULL, NULL);
+    krb5_verify_init_creds(context, &creds, NULL, NULL, &vcc, NULL);
+    krb5_cc_destroy(context, vcc);
+
+================================================================
+
+password expiration has a subtlety.  When a password expires and is
+changed, there is a delay between when the master gets the new key
+(immediately), and the slaves (propogation interval).  So, when
+getting an in_tkt, if the password is expired, the request should be
+reissued to the master (this kind of sucks if you have SAM, oh well).
+If this says expired, too, then the password should be changed, and
+then the initial ticket request should be issued to the master again.
+If the master times out, then a message that the password has expired
+and cannot be changed due to the master being unreachable should be
+displayed.
+
+================================================================
+
+get_init_creds reads config stuff from:
+
+[libdefaults]
+	varname1 = defvalue
+	REALM = {
+		varname1 = value
+		varname2 = value
+	}
+
+typedef struct _krb5_get_init_creds_opt {
+    krb5_flags flags;
+    krb5_deltat tkt_life;	/* varname = "ticket_lifetime" */
+    krb5_deltat renew_life;	/* varname = "renew_lifetime" */
+    int forwardable;		/* varname = "forwardable" */
+    int proxiable;		/* varname = "proxiable" */
+    krb5_enctype *etype_list;	/* varname = "default_tkt_enctypes" */
+    int etype_list_length;
+    krb5_address **address_list; /* no varname */
+    krb5_preauthtype *preauth_list; /* no varname */
+    int preauth_list_length;
+    krb5_data *salt;
+} krb5_get_init_creds_opt;
+
+
diff --git a/third_party/heimdal/doc/install.texi b/third_party/heimdal/doc/install.texi
new file mode 100644
index 00000000000..26008fcde13
--- /dev/null
+++ b/third_party/heimdal/doc/install.texi
@@ -0,0 +1,8 @@
+@node Building and Installing, Setting up a realm,  What is bx509?, Top
+@comment  node-name,  next,  previous,  up
+@chapter Building and Installing
+
+Build and install instructions are located here:
+
+@url{https://github.com/heimdal/heimdal/wiki}
+
diff --git a/third_party/heimdal/doc/intro.texi b/third_party/heimdal/doc/intro.texi
new file mode 100644
index 00000000000..c51eba02ac9
--- /dev/null
+++ b/third_party/heimdal/doc/intro.texi
@@ -0,0 +1,98 @@
+@c $Id$
+
+@node Introduction, What is Kerberos?, Top, Top
+@c @node Introduction, What is Kerberos?, Top, Top
+@comment  node-name,  next,  previous,  up
+@chapter Introduction
+
+@heading What is Heimdal?
+
+Heimdal is a free implementation of Kerberos 5. The goals are to:
+
+@itemize @bullet
+@item
+have an implementation that can be freely used by anyone
+@item
+be protocol compatible with existing implementations and, if not in
+conflict, with RFC 4120 (and any future updated RFC). RFC 4120
+replaced RFC 1510.
+@item
+be reasonably compatible with the M.I.T Kerberos V5 API
+@item
+have support for Kerberos V5 over GSS-API (RFC1964)
+@item
+include the most important and useful application programs (rsh, telnet,
+popper, etc.)
+@item
+include enough backwards compatibility with Kerberos V4
+@end itemize
+
+@heading Status
+
+Heimdal has the following features (this does not mean any of this
+works):
+
+@itemize @bullet
+@item
+a stub generator and a library to encode/decode/whatever ASN.1/DER
+stuff
+@item
+a @code{libkrb5} library that should be possible to get to work with
+simple applications
+@item
+a GSS-API library
+@item
+@file{kinit}, @file{klist}, @file{kdestroy}
+@item
+@file{telnet}, @file{telnetd}
+@item
+@file{rsh}, @file{rshd}
+@item
+@file{popper}, @file{push} (a movemail equivalent)
+@item
+@file{ftp}, and @file{ftpd}
+@item
+a library @file{libkafs} for authenticating to AFS and a program
+@file{afslog} that uses it
+@item
+some simple test programs
+@item
+a KDC that supports most things,
+@item
+simple programs for distributing databases between a KDC master and
+slaves
+@item
+a password changing daemon @file{kpasswdd}, library functions for
+changing passwords and a simple client
+@item
+some kind of administration system
+@item
+Kerberos V4 support in many of the applications.
+@end itemize
+
+@heading Bug reports
+
+If you find bugs in this software, make sure it is a genuine bug and not
+just a part of the code that isn't implemented.
+
+Bug reports should be sent to @email{heimdal-bugs@@h5l.org}. Please
+include information on what machine and operating system (including
+version) you are running, what you are trying to do, what happens, what
+you think should have happened, an example for us to repeat, the output
+you get when trying the example, and a patch for the problem if you have
+one. Please make any patches with @code{diff -u} or @code{diff -c}.
+
+Suggestions, comments and other non bug reports are also welcome.
+
+@heading Mailing list
+
+There are two mailing lists with talk about
+Heimdal. @email{heimdal-announce@@sics.se} is a low-volume announcement
+list, while @email{heimdal-discuss@@sics.se} is for general discussion.
+Send a message to @email{majordomo@@sics.se} to subscribe.
+
+@heading Heimdal source code, binaries and the manual
+
+The source code for heimdal, links to binaries and the manual (this
+document) can be found on our web-page at
+@url{http://www.pdc.kth.se/heimdal/}.
diff --git a/third_party/heimdal/doc/kerberos4.texi b/third_party/heimdal/doc/kerberos4.texi
new file mode 100644
index 00000000000..41a6508aac9
--- /dev/null
+++ b/third_party/heimdal/doc/kerberos4.texi
@@ -0,0 +1,173 @@
+@c $Id$
+
+@node Kerberos 4 issues, Windows compatibility, Things in search for a better place, Top
+@comment  node-name,  next,  previous,  up
+@chapter Kerberos 4 issues
+
+Kerberos 4 KDC and KA server have been moved.
+
+For more about AFS, see the section @xref{AFS}.
+
+@menu
+* Principal conversion issues::  
+* Converting a version 4 database::  
+@end menu
+
+@node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues
+@section Principal conversion issues
+
+First, Kerberos 4 and Kerberos 5 principals are different. A version 4
+principal consists of a name, an instance, and a realm. A version 5
+principal has one or more components, and a realm (the terms ``name''
+and ``instance'' are still used, for the first and second component,
+respectively).    Also, in some cases the name of a version 4 principal
+differs from the first component of the corresponding version 5
+principal. One notable example is the ``host'' type principals, where
+the version 4 name is @samp{rcmd} (for ``remote command''), and the
+version 5 name is @samp{host}. For the class of principals that has a
+hostname as instance, there is an other major difference, Kerberos 4
+uses only the first component of the hostname, whereas Kerberos 5 uses
+the fully qualified hostname.
+
+Because of this it can be hard or impossible to correctly convert a
+version 4 principal to a version 5 principal @footnote{the other way is
+not always trivial either, but usually easier}. The biggest problem is
+to know if the conversion resulted in a valid principal. To give an
+example, suppose you want to convert the principal @samp{rcmd.foo}.
+
+The @samp{rcmd} name suggests that the instance is a hostname (even if
+there are exceptions to this rule). To correctly convert the instance
+@samp{foo} to a hostname, you have to know which host it is referring
+to. You can to this by either guessing (from the realm) which domain
+name to append, or you have to have a list of possible hostnames. In the
+simplest cases you can cover most principals with the first rule. If you
+have several domains sharing a single realm this will not usually
+work. If the exceptions are few you can probably come by with a lookup
+table for the exceptions.
+
+In a complex scenario you will need some kind of host lookup mechanism.
+Using DNS for this is tempting, but DNS is error prone, slow and unsafe
+@footnote{at least until secure DNS is commonly available}.
+
+Fortunately, the KDC has a trump on hand: it can easily tell if a
+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
+@section Converting a version 4 database
+
+If you want to convert an existing version 4 database, the principal
+conversion issue arises too.
+
+If you decide to convert your database once and for all, you will only
+have to do this conversion once. It is also possible to run a version 5
+KDC as a slave to a version 4 KDC. In this case this conversion will
+happen every time the database is propagated.  When doing this
+conversion, there are a few things to look out for. If you have stale
+entries in the database, these entries will not be converted. This might
+be because these principals are not used anymore, or it might be just
+because the principal couldn't be converted.
+
+You might also see problems with a many-to-one mapping of
+principals. For instance, if you are using DNS lookups and you have two
+principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME
+for `bar', the resulting principals will be the same. Since the
+conversion function can't tell which is correct, these conflicts will
+have to be resolved manually.
+
+@subsection Conversion example
+
+Given the following set of hosts and services:
+
+@example
+foo.se          rcmd
+mail.foo.se     rcmd, pop
+ftp.bar.se      rcmd, ftp
+@end example
+
+you have a database that consists of the following principals:
+
+@samp{rcmd.foo}, @samp{rcmd.mail}, @samp{pop.mail}, @samp{rcmd.ftp}, and
+@samp{ftp.ftp}.
+
+lets say you also got these extra principals: @samp{rcmd.gone},
+@samp{rcmd.old-mail}, where @samp{gone.foo.se} was a machine that has
+now passed away, and @samp{old-mail.foo.se} was an old mail machine that
+is now a CNAME for @samp{mail.foo.se}.
+
+When you convert this database you want the following conversions to be
+done:
+@example
+rcmd.foo         host/foo.se
+rcmd.mail        host/mail.foo.se
+pop.mail         pop/mail.foo.se
+rcmd.ftp         host/ftp.bar.se
+ftp.ftp          ftp/ftp.bar.se
+rcmd.gone        @i{removed}
+rcmd.old-mail    @i{removed}
+@end example
+
+A @file{krb5.conf} that does this looks like:
+
+@example
+[realms]
+        FOO.SE = @{
+                v4_name_convert = @{
+                        host = @{
+                                ftp = ftp
+                                pop = pop
+                                rcmd = host
+                        @}
+                @}
+                v4_instance_convert = @{
+                        foo = foo.se
+                        ftp = ftp.bar.se
+                @}
+                default_domain = foo.se
+        @}
+@end example
+
+The @samp{v4_name_convert} section says which names should be considered
+having an instance consisting of a hostname, and it also says how the
+names should be converted (for instance @samp{rcmd} should be converted
+to @samp{host}). The @samp{v4_instance_convert} section says how a
+hostname should be qualified (this is just a hosts-file in
+disguise). Host-instances that aren't covered by
+@samp{v4_instance_convert} are qualified by appending the contents of
+the @samp{default_domain}.
+
+Actually, this example doesn't work. Or rather, it works to well. Since
+it has no way of knowing which hostnames are valid and which are not, it
+will happily convert @samp{rcmd.gone} to @samp{host/gone.foo.se}. This
+isn't a big problem, but if you have run your kerberos realm for a few
+years, chances are big that you have quite a few `junk' principals.
+
+If you don't want this you can remove the @samp{default_domain}
+statement, but then you will have to add entries for @emph{all} your hosts
+in the @samp{v4_instance_convert} section.
+
+Instead of doing this you can use DNS to convert instances. This is not
+a solution without problems, but it is probably easier than adding lots
+of static host entries. 
+
+To enable DNS lookup you should turn on @samp{v4_instance_resolve} in
+the @samp{[libdefaults]} section.
+
+@subsection Converting a database
+
+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 --source=krb4-db --master-key=/.m slave-server
+@end example
+
+This command can also be to use for converting the v4 database on the
+server:
+
+@example
+hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n
+@end example
+
diff --git a/third_party/heimdal/doc/krb5.din b/third_party/heimdal/doc/krb5.din
new file mode 100644
index 00000000000..047319bc7fc
--- /dev/null
+++ b/third_party/heimdal/doc/krb5.din
@@ -0,0 +1,16 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal Kerberos 5 library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/krb5
+INPUT                  = @srcdir@/../lib/krb5
+
+WARN_IF_UNDOCUMENTED   = NO
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
+
diff --git a/third_party/heimdal/doc/latin1.tex b/third_party/heimdal/doc/latin1.tex
new file mode 100644
index 00000000000..e683dd271dc
--- /dev/null
+++ b/third_party/heimdal/doc/latin1.tex
@@ -0,0 +1,95 @@
+% ISO Latin 1 (ISO 8859/1) encoding for Computer Modern fonts.
+% Jan Michael Rynning <jmr@nada.kth.se> 1990-10-12
+\def\inmathmode#1{\relax\ifmmode#1\else$#1$\fi}
+\global\catcode`\^^a0=\active \global\let^^a0=~		% no-break space
+\global\catcode`\^^a1=\active \global\def^^a1{!`}		% inverted exclamation mark
+\global\catcode`\^^a2=\active \global\def^^a2{{\rm\rlap/c}}	% cent sign
+\global\catcode`\^^a3=\active \global\def^^a3{{\it\$}}	% pound sign
+% currency sign, yen sign, broken bar
+\global\catcode`\^^a7=\active \global\let^^a7=\S		% section sign
+\global\catcode`\^^a8=\active \global\def^^a8{\"{}}		% diaeresis
+\global\catcode`\^^a9=\active \global\let^^a9=\copyright	% copyright sign
+% feminine ordinal indicator, left angle quotation mark
+\global\catcode`\^^ac=\active \global\def^^ac{\inmathmode\neg}% not sign
+\global\catcode`\^^ad=\active \global\let^^ad=\-		% soft hyphen
+% registered trade mark sign
+\global\catcode`\^^af=\active \global\def^^af{\={}}		% macron
+% ...
+\global\catcode`\^^b1=\active \global\def^^b1{\inmathmode\pm}	% plus minus
+\global\catcode`\^^b2=\active \global\def^^b2{\inmathmode{{^2}}}
+\global\catcode`\^^b3=\active \global\def^^b3{\inmathmode{{^3}}}
+\global\catcode`\^^b4=\active \global\def^^b4{\'{}}		% acute accent
+\global\catcode`\^^b5=\active \global\def^^b5{\inmathmode\mu}	% mu
+\global\catcode`\^^b6=\active \global\let^^b6=\P		% pilcroy
+\global\catcode`\^^b7=\active \global\def^^b7{\inmathmode{{\cdot}}}
+\global\catcode`\^^b8=\active \global\def^^b8{\c{}}		% cedilla
+\global\catcode`\^^b9=\active \global\def^^b9{\inmathmode{{^1}}}
+% ...
+\global\catcode`\^^bc=\active \global\def^^bc{\inmathmode{{1\over4}}}
+\global\catcode`\^^bd=\active \global\def^^bd{\inmathmode{{1\over2}}}
+\global\catcode`\^^be=\active \global\def^^be{\inmathmode{{3\over4}}}
+\global\catcode`\^^bf=\active \global\def^^bf{?`}		% inverted question mark
+\global\catcode`\^^c0=\active \global\def^^c0{\`A}
+\global\catcode`\^^c1=\active \global\def^^c1{\'A}
+\global\catcode`\^^c2=\active \global\def^^c2{\^A}
+\global\catcode`\^^c3=\active \global\def^^c3{\~A}
+\global\catcode`\^^c4=\active \global\def^^c4{\"A}		% capital a with diaeresis
+\global\catcode`\^^c5=\active \global\let^^c5=\AA		% capital a with ring above
+\global\catcode`\^^c6=\active \global\let^^c6=\AE
+\global\catcode`\^^c7=\active \global\def^^c7{\c C}
+\global\catcode`\^^c8=\active \global\def^^c8{\`E}
+\global\catcode`\^^c9=\active \global\def^^c9{\'E}
+\global\catcode`\^^ca=\active \global\def^^ca{\^E}
+\global\catcode`\^^cb=\active \global\def^^cb{\"E}
+\global\catcode`\^^cc=\active \global\def^^cc{\`I}
+\global\catcode`\^^cd=\active \global\def^^cd{\'I}
+\global\catcode`\^^ce=\active \global\def^^ce{\^I}
+\global\catcode`\^^cf=\active \global\def^^cf{\"I}
+% capital eth
+\global\catcode`\^^d1=\active \global\def^^d1{\~N}
+\global\catcode`\^^d2=\active \global\def^^d2{\`O}
+\global\catcode`\^^d3=\active \global\def^^d3{\'O}
+\global\catcode`\^^d4=\active \global\def^^d4{\^O}
+\global\catcode`\^^d5=\active \global\def^^d5{\~O}
+\global\catcode`\^^d6=\active \global\def^^d6{\"O}		% capital o with diaeresis
+\global\catcode`\^^d7=\active \global\def^^d7{\inmathmode\times}% multiplication sign
+\global\catcode`\^^d8=\active \global\let^^d8=\O
+\global\catcode`\^^d9=\active \global\def^^d9{\`U}
+\global\catcode`\^^da=\active \global\def^^da{\'U}
+\global\catcode`\^^db=\active \global\def^^db{\^U}
+\global\catcode`\^^dc=\active \global\def^^dc{\"U}
+\global\catcode`\^^dd=\active \global\def^^dd{\'Y}
+% capital thorn
+\global\catcode`\^^df=\active \global\def^^df{\ss}
+\global\catcode`\^^e0=\active \global\def^^e0{\`a}
+\global\catcode`\^^e1=\active \global\def^^e1{\'a}
+\global\catcode`\^^e2=\active \global\def^^e2{\^a}
+\global\catcode`\^^e3=\active \global\def^^e3{\~a}
+\global\catcode`\^^e4=\active \global\def^^e4{\"a}		% small a with diaeresis
+\global\catcode`\^^e5=\active \global\let^^e5=\aa		% small a with ring above
+\global\catcode`\^^e6=\active \global\let^^e6=\ae
+\global\catcode`\^^e7=\active \global\def^^e7{\c c}
+\global\catcode`\^^e8=\active \global\def^^e8{\`e}
+\global\catcode`\^^e9=\active \global\def^^e9{\'e}
+\global\catcode`\^^ea=\active \global\def^^ea{\^e}
+\global\catcode`\^^eb=\active \global\def^^eb{\"e}
+\global\catcode`\^^ec=\active \global\def^^ec{\`\i}
+\global\catcode`\^^ed=\active \global\def^^ed{\'\i}
+\global\catcode`\^^ee=\active \global\def^^ee{\^\i}
+\global\catcode`\^^ef=\active \global\def^^ef{\"\i}
+% small eth
+\global\catcode`\^^f1=\active \global\def^^f1{\~n}
+\global\catcode`\^^f2=\active \global\def^^f2{\`o}
+\global\catcode`\^^f3=\active \global\def^^f3{\'o}
+\global\catcode`\^^f4=\active \global\def^^f4{\^o}
+\global\catcode`\^^f5=\active \global\def^^f5{\~o}
+\global\catcode`\^^f6=\active \global\def^^f6{\"o}		% small o with diaeresis
+\global\catcode`\^^f7=\active \global\def^^f7{\inmathmode\div}% division sign
+\global\catcode`\^^f8=\active \global\let^^f8=\o
+\global\catcode`\^^f9=\active \global\def^^f9{\`u}
+\global\catcode`\^^fa=\active \global\def^^fa{\'u}
+\global\catcode`\^^fb=\active \global\def^^fb{\^u}
+\global\catcode`\^^fc=\active \global\def^^fc{\"u}
+\global\catcode`\^^fd=\active \global\def^^fd{\'y}
+% capital thorn
+\global\catcode`\^^ff=\active \global\def^^ff{\"y}
diff --git a/third_party/heimdal/doc/layman.asc b/third_party/heimdal/doc/layman.asc
new file mode 100644
index 00000000000..d4fbe64be99
--- /dev/null
+++ b/third_party/heimdal/doc/layman.asc
@@ -0,0 +1,1855 @@
+A Layman's Guide to a Subset of ASN.1, BER, and DER
+
+An RSA Laboratories Technical Note
+Burton S. Kaliski Jr.
+Revised November 1, 1993
+
+
+Supersedes June 3, 1991 version, which was also published as
+NIST/OSI Implementors' Workshop document SEC-SIG-91-17.
+PKCS documents are available by electronic mail to
+<pkcs@rsa.com>.
+
+Copyright (C) 1991-1993 RSA Laboratories, a division of RSA
+Data Security, Inc. License to copy this document is granted
+provided that it is identified as "RSA Data Security, Inc.
+Public-Key Cryptography Standards (PKCS)" in all material
+mentioning or referencing this document.
+003-903015-110-000-000
+
+
+Abstract. This note gives a layman's introduction to a
+subset of OSI's Abstract Syntax Notation One (ASN.1), Basic
+Encoding Rules (BER), and Distinguished Encoding Rules
+(DER). The particular purpose of this note is to provide
+background material sufficient for understanding and
+implementing the PKCS family of standards.
+
+
+1. Introduction
+
+It is a generally accepted design principle that abstraction
+is a key to managing software development. With abstraction,
+a designer can specify a part of a system without concern
+for how the part is actually implemented or represented.
+Such a practice leaves the implementation open; it
+simplifies the specification; and it makes it possible to
+state "axioms" about the part that can be proved when the
+part is implemented, and assumed when the part is employed
+in another, higher-level part. Abstraction is the hallmark
+of most modern software specifications.
+
+One of the most complex systems today, and one that also
+involves a great deal of abstraction, is Open Systems
+Interconnection (OSI, described in X.200). OSI is an
+internationally standardized architecture that governs the
+interconnection of computers from the physical layer up to
+the user application layer. Objects at higher layers are
+defined abstractly and intended to be implemented with
+objects at lower layers. For instance, a service at one
+layer may require transfer of certain abstract objects
+between computers; a lower layer may provide transfer
+services for strings of ones and zeroes, using encoding
+rules to transform the abstract objects into such strings.
+OSI is called an open system because it supports many
+different implementations of the services at each layer.
+
+OSI's method of specifying abstract objects is called ASN.1
+(Abstract Syntax Notation One, defined in X.208), and one
+set of rules for representing such objects as strings of
+ones and zeros is called the BER (Basic Encoding Rules,
+defined in X.209). ASN.1 is a flexible notation that allows
+one to define a variety data types, from simple types such
+as integers and bit strings to structured types such as sets
+and sequences, as well as complex types defined in terms of
+others. BER describes how to represent or encode values of
+each ASN.1 type as a string of eight-bit octets. There is
+generally more than one way to BER-encode a given value.
+Another set of rules, called the Distinguished Encoding
+Rules (DER), which is a subset of BER, gives a unique
+encoding to each ASN.1 value.
+
+The purpose of this note is to describe a subset of ASN.1,
+BER and DER sufficient to understand and implement one OSI-
+based application, RSA Data Security, Inc.'s Public-Key
+Cryptography Standards. The features described include an
+overview of ASN.1, BER, and DER and an abridged list of
+ASN.1 types and their BER and DER encodings. Sections 2-4
+give an overview of ASN.1, BER, and DER, in that order.
+Section 5 lists some ASN.1 types, giving their notation,
+specific encoding rules, examples, and comments about their
+application to PKCS. Section 6 concludes with an example,
+X.500 distinguished names.
+
+Advanced features of ASN.1, such as macros, are not
+described in this note, as they are not needed to implement
+PKCS. For information on the other features, and for more
+detail generally, the reader is referred to CCITT
+Recommendations X.208 and X.209, which define ASN.1 and BER.
+
+Terminology and notation. In this note, an octet is an eight-
+bit unsigned integer. Bit 8 of the octet is the most
+significant and bit 1 is the least significant.
+
+The following meta-syntax is used for in describing ASN.1
+notation:
+
+     BIT  monospace denotes literal characters in the type
+          and value notation; in examples, it generally
+          denotes an octet value in hexadecimal
+
+     n1   bold italics denotes a variable
+
+     []   bold square brackets indicate that a term is
+          optional
+
+     {}   bold braces group related terms
+
+     |    bold vertical bar delimits alternatives with a
+          group
+
+     ...  bold ellipsis indicates repeated occurrences
+
+     =    bold equals sign expresses terms as subterms
+
+
+2. Abstract Syntax Notation One
+
+Abstract Syntax Notation One, abbreviated ASN.1, is a
+notation for describing abstract types and values.
+
+In ASN.1, a type is a set of values. For some types, there
+are a finite number of values, and for other types there are
+an infinite number. A value of a given ASN.1 type is an
+element of the type's set. ASN.1 has four kinds of type:
+simple types, which are "atomic" and have no components;
+structured types, which have components; tagged types, which
+are derived from other types; and other types, which include
+the CHOICE type and the ANY type. Types and values can be
+given names with the ASN.1 assignment operator (::=) , and
+those names can be used in defining other types and values.
+
+Every ASN.1 type other than CHOICE and ANY has a tag, which
+consists of a class and a nonnegative tag number. ASN.1
+types are abstractly the same if and only if their tag
+numbers are the same. In other words, the name of an ASN.1
+type does not affect its abstract meaning, only the tag
+does. There are four classes of tag:
+
+     Universal, for types whose meaning is the same in all
+          applications; these types are only defined in
+          X.208.
+
+     Application, for types whose meaning is specific to an
+          application, such as X.500 directory services;
+          types in two different applications may have the
+          same application-specific tag and different
+          meanings.
+
+     Private, for types whose meaning is specific to a given
+          enterprise.
+
+     Context-specific, for types whose meaning is specific
+          to a given structured type; context-specific tags
+          are used to distinguish between component types
+          with the same underlying tag within the context of
+          a given structured type, and component types in
+          two different structured types may have the same
+          tag and different meanings.
+
+The types with universal tags are defined in X.208, which
+also gives the types' universal tag numbers. Types with
+other tags are defined in many places, and are always
+obtained by implicit or explicit tagging (see Section 2.3).
+Table 1 lists some ASN.1 types and their universal-class
+tags.
+
+    Type                     Tag number     Tag number
+                             (decimal)      (hexadecimal)
+    INTEGER                  2              02
+    BIT STRING               3              03
+    OCTET STRING             4              04
+    NULL                     5              05
+    OBJECT IDENTIFIER        6              06
+    SEQUENCE and SEQUENCE OF 16             10
+    SET and SET OF           17             11
+    PrintableString          19             13
+    T61String                20             14
+    IA5String                22             16
+    UTCTime                  23             17
+
+     Table 1. Some types and their universal-class tags.
+
+ASN.1 types and values are expressed in a flexible,
+programming-language-like notation, with the following
+special rules:
+
+     o    Layout is not significant; multiple spaces and
+          line breaks can be considered as a single space.
+
+     o    Comments are delimited by pairs of hyphens (--),
+          or a pair of hyphens and a line break.
+
+     o    Identifiers (names of values and fields) and type
+          references (names of types) consist of upper- and
+          lower-case letters, digits, hyphens, and spaces;
+          identifiers begin with lower-case letters; type
+          references begin with upper-case letters.
+
+The following four subsections give an overview of simple
+types, structured types, implicitly and explicitly tagged
+types, and other types. Section 5 describes specific types
+in more detail.
+
+
+2.1 Simple types
+
+Simple types are those not consisting of components; they
+are the "atomic" types. ASN.1 defines several; the types
+that are relevant to the PKCS standards are the following:
+
+     BIT STRING, an arbitrary string of bits (ones and
+          zeroes).
+
+     IA5String, an arbitrary string of IA5 (ASCII)
+          characters.
+
+     INTEGER, an arbitrary integer.
+
+     NULL, a null value.
+
+     OBJECT IDENTIFIER, an object identifier, which is a
+          sequence of integer components that identify an
+          object such as an algorithm or attribute type.
+
+     OCTET STRING, an arbitrary string of octets (eight-bit
+          values).
+
+     PrintableString, an arbitrary string of printable
+          characters.
+
+     T61String, an arbitrary string of T.61 (eight-bit)
+          characters.
+
+     UTCTime, a "coordinated universal time" or Greenwich
+          Mean Time (GMT) value.
+
+Simple types fall into two categories: string types and non-
+string types. BIT STRING, IA5String, OCTET STRING,
+PrintableString, T61String, and UTCTime are string types.
+
+String types can be viewed, for the purposes of encoding, as
+consisting of components, where the components are
+substrings. This view allows one to encode a value whose
+length is not known in advance (e.g., an octet string value
+input from a file stream) with a constructed, indefinite-
+length encoding (see Section 3).
+
+The string types can be given size constraints limiting the
+length of values.
+
+
+2.2 Structured types
+
+Structured types are those consisting of components. ASN.1
+defines four, all of which are relevant to the PKCS
+standards:
+
+     SEQUENCE, an ordered collection of one or more types.
+
+     SEQUENCE OF, an ordered collection of zero or more
+          occurrences of a given type.
+
+     SET, an unordered collection of one or more types.
+
+     SET OF, an unordered collection of zero or more
+          occurrences of a given type.
+
+The structured types can have optional components, possibly
+with default values.
+
+
+2.3 Implicitly and explicitly tagged types
+
+Tagging is useful to distinguish types within an
+application; it is also commonly used to distinguish
+component types within a structured type. For instance,
+optional components of a SET or SEQUENCE type are typically
+given distinct context-specific tags to avoid ambiguity.
+
+There are two ways to tag a type: implicitly and explicitly.
+
+Implicitly tagged types are derived from other types by
+changing the tag of the underlying type. Implicit tagging is
+denoted by the ASN.1 keywords [class number] IMPLICIT (see
+Section 5.1).
+
+Explicitly tagged types are derived from other types by
+adding an outer tag to the underlying type. In effect,
+explicitly tagged types are structured types consisting of
+one component, the underlying type. Explicit tagging is
+denoted by the ASN.1 keywords [class number] EXPLICIT (see
+Section 5.2).
+
+The keyword [class number] alone is the same as explicit
+tagging, except when the "module" in which the ASN.1 type is
+defined has implicit tagging by default. ("Modules" are
+among the advanced features not described in this note.)
+
+For purposes of encoding, an implicitly tagged type is
+considered the same as the underlying type, except that the
+tag is different. An explicitly tagged type is considered
+like a structured type with one component, the underlying
+type. Implicit tags result in shorter encodings, but
+explicit tags may be necessary to avoid ambiguity if the tag
+of the underlying type is indeterminate (e.g., the
+underlying type is CHOICE or ANY).
+
+
+2.4 Other types
+
+Other types in ASN.1 include the CHOICE and ANY types. The
+CHOICE type denotes a union of one or more alternatives; the
+ANY type denotes an arbitrary value of an arbitrary type,
+where the arbitrary type is possibly defined in the
+registration of an object identifier or integer value.
+
+
+3. Basic Encoding Rules
+
+The Basic Encoding Rules for ASN.1, abbreviated BER, give
+one or more ways to represent any ASN.1 value as an octet
+string. (There are certainly other ways to represent ASN.1
+values, but BER is the standard for interchanging such
+values in OSI.)
+
+There are three methods to encode an ASN.1 value under BER,
+the choice of which depends on the type of value and whether
+the length of the value is known. The three methods are
+primitive, definite-length encoding; constructed, definite-
+length encoding; and constructed, indefinite-length
+encoding. Simple non-string types employ the primitive,
+definite-length method; structured types employ either of
+the constructed methods; and simple string types employ any
+of the methods, depending on whether the length of the value
+is known. Types derived by implicit tagging employ the
+method of the underlying type and types derived by explicit
+tagging employ the constructed methods.
+
+In each method, the BER encoding has three or four parts:
+
+     Identifier octets. These identify the class and tag
+          number of the ASN.1 value, and indicate whether
+          the method is primitive or constructed.
+
+     Length octets. For the definite-length methods, these
+          give the number of contents octets. For the
+          constructed, indefinite-length method, these
+          indicate that the length is indefinite.
+
+     Contents octets. For the primitive, definite-length
+          method, these give a concrete representation of
+          the  value. For the constructed methods, these
+          give the concatenation of the BER encodings of the
+          components of the value.
+
+     End-of-contents octets. For the constructed, indefinite-
+          length method, these denote the end of the
+          contents. For the other methods, these are absent.
+
+The three methods of encoding are described in the following
+sections.
+
+
+3.1 Primitive, definite-length method
+
+This method applies to simple types and types derived from
+simple types by implicit tagging. It requires that the
+length of the value be known in advance. The parts of the
+BER encoding are as follows:
+
+Identifier octets. There are two forms: low tag number (for
+tag numbers between 0 and 30) and high tag number (for tag
+numbers 31 and greater).
+
+     Low-tag-number form. One octet. Bits 8 and 7 specify
+          the class (see Table 2), bit 6 has value "0,"
+          indicating that the encoding is primitive, and
+          bits 5-1 give the tag number.
+
+                  Class            Bit  Bit
+                                   8    7
+                  universal        0    0
+                  application      0    1
+                  context-specific 1    0
+                  private          1    1
+
+        Table 2. Class encoding in identifier octets.
+
+     High-tag-number form. Two or more octets. First octet
+          is as in low-tag-number form, except that bits 5-1
+          all have value "1." Second and following octets
+          give the tag number, base 128, most significant
+          digit first, with as few digits as possible, and
+          with the bit 8 of each octet except the last set
+          to "1."
+
+Length octets. There are two forms: short (for lengths
+between 0 and 127), and long definite (for lengths between 0
+and 21008-1).
+
+     Short form. One octet. Bit 8 has value "0" and bits 7-1
+          give the length.
+
+     Long form. Two to 127 octets. Bit 8 of first octet has
+          value "1" and bits 7-1 give the number of
+          additional length octets. Second and following
+          octets give the length, base 256, most significant
+          digit first.
+
+Contents octets. These give a concrete representation of the
+value (or the value of the underlying type, if the type is
+derived by implicit tagging). Details for particular types
+are given in Section 5.
+
+
+3.2 Constructed, definite-length method
+
+This method applies to simple string types, structured
+types, types derived simple string types and structured
+types by implicit tagging, and types derived from anything
+by explicit tagging. It requires that the length of the
+value be known in advance. The parts of the BER encoding are
+as follows:
+
+Identifier octets. As described in Section 3.1, except that
+bit 6 has value "1," indicating that the encoding is
+constructed.
+
+Length octets. As described in Section 3.1.
+
+Contents octets. The concatenation of the BER encodings of
+the components of the value:
+
+     o    For simple string types and types derived from
+          them by implicit tagging, the concatenation of the
+          BER encodings of consecutive substrings of the
+          value (underlying value for implicit tagging).
+
+     o    For structured types and types derived from them
+          by implicit tagging, the concatenation of the BER
+          encodings of components of the value (underlying
+          value for implicit tagging).
+
+     o    For types derived from anything by explicit
+          tagging, the BER encoding of the underlying value.
+
+Details for particular types are given in Section 5.
+
+
+3.3 Constructed, indefinite-length method
+
+This method applies to simple string types, structured
+types, types derived simple string types and structured
+types by implicit tagging, and types derived from anything
+by explicit tagging. It does not require that the length of
+the value be known in advance. The parts of the BER encoding
+are as follows:
+
+Identifier octets. As described in Section 3.2.
+
+Length octets. One octet, 80.
+
+Contents octets. As described in Section 3.2.
+
+End-of-contents octets. Two octets, 00 00.
+
+Since the end-of-contents octets appear where an ordinary
+BER encoding might be expected (e.g., in the contents octets
+of a sequence value), the 00 and 00 appear as identifier and
+length octets, respectively. Thus the end-of-contents octets
+is really the primitive, definite-length encoding of a value
+with universal class, tag number 0, and length 0.
+
+
+4. Distinguished Encoding Rules
+
+The Distinguished Encoding Rules for ASN.1, abbreviated DER,
+are a subset of BER, and give exactly one way to represent
+any ASN.1 value as an octet string. DER is intended for
+applications in which a unique octet string encoding is
+needed, as is the case when a digital signature is computed
+on an ASN.1 value. DER is defined in Section 8.7 of X.509.
+
+DER adds the following restrictions to the rules given in
+Section 3:
+
+     1.   When the length is between 0 and 127, the short
+          form of length must be used
+
+     2.   When the length is 128 or greater, the long form
+          of length must be used, and the length must be
+          encoded in the minimum number of octets.
+
+     3.   For simple string types and implicitly tagged
+          types derived from simple string types, the
+          primitive, definite-length method must be
+          employed.
+
+     4.   For structured types, implicitly tagged types
+          derived from structured types, and explicitly
+          tagged types derived from anything, the
+          constructed, definite-length method must be
+          employed.
+
+Other restrictions are defined for particular types (such as
+BIT STRING, SEQUENCE, SET, and SET OF), and can be found in
+Section 5.
+
+
+5. Notation and encodings for some types
+
+This section gives the notation for some ASN.1 types and
+describes how to encode values of those types under both BER
+and DER.
+
+The types described are those presented in Section 2. They
+are listed alphabetically here.
+
+Each description includes ASN.1 notation, BER encoding, and
+DER encoding. The focus of the encodings is primarily on the
+contents octets; the tag and length octets follow Sections 3
+and 4. The descriptions also explain where each type is used
+in PKCS and related standards. ASN.1 notation is generally
+only for types, although for the type OBJECT IDENTIFIER,
+value notation is given as well.
+
+
+5.1 Implicitly tagged types
+
+An implicitly tagged type is a type derived from another
+type by changing the tag of the underlying type.
+
+Implicit tagging is used for optional SEQUENCE components
+with underlying type other than ANY throughout PKCS, and for
+the extendedCertificate alternative of PKCS #7's
+ExtendedCertificateOrCertificate type.
+
+ASN.1 notation:
+
+[[class] number] IMPLICIT Type
+
+class = UNIVERSAL  |  APPLICATION  |  PRIVATE
+
+where Type is a type, class is an optional class name, and
+number is the tag number within the class, a nonnegative
+integer.
+
+In ASN.1 "modules" whose default tagging method is implicit
+tagging, the notation [[class] number] Type is also
+acceptable, and the keyword IMPLICIT is implied. (See
+Section 2.3.) For definitions stated outside a module, the
+explicit inclusion of the keyword IMPLICIT is preferable to
+prevent ambiguity.
+
+If the class name is absent, then the tag is context-
+specific. Context-specific tags can only appear in a
+component of a structured or CHOICE type.
+
+Example: PKCS #8's PrivateKeyInfo type has an optional
+attributes component with an implicit, context-specific tag:
+
+PrivateKeyInfo ::= SEQUENCE {
+  version Version,
+  privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
+  privateKey PrivateKey,
+  attributes [0] IMPLICIT Attributes OPTIONAL }
+
+Here the underlying type is Attributes, the class is absent
+(i.e., context-specific), and the tag number within the
+class is 0.
+
+BER encoding. Primitive or constructed, depending on the
+underlying type. Contents octets are as for the BER encoding
+of the underlying value.
+
+Example: The BER encoding of the attributes component of a
+PrivateKeyInfo value is as follows:
+
+     o    the identifier octets are 80 if the underlying
+          Attributes value has a primitive BER encoding and
+          a0 if the underlying Attributes value has a
+          constructed BER encoding
+
+     o    the length and contents octets are the same as the
+          length and contents octets of the BER encoding of
+          the underlying Attributes value
+
+DER encoding. Primitive or constructed, depending on the
+underlying type. Contents octets are as for the DER encoding
+of the underlying value.
+
+
+5.2 Explicitly tagged types
+
+Explicit tagging denotes a type derived from another type by
+adding an outer tag to the underlying type.
+
+Explicit tagging is used for optional SEQUENCE components
+with underlying type ANY throughout PKCS, and for the
+version component of X.509's Certificate type.
+
+ASN.1 notation:
+
+[[class] number] EXPLICIT Type
+
+class = UNIVERSAL  |  APPLICATION  |  PRIVATE
+
+where Type is a type, class is an optional class name, and
+number is the tag number within the class, a nonnegative
+integer.
+
+If the class name is absent, then the tag is context-
+specific. Context-specific tags can only appear in a
+component of a SEQUENCE, SET or CHOICE type.
+
+In ASN.1 "modules" whose default tagging method is explicit
+tagging, the notation [[class] number] Type is also
+acceptable, and the keyword EXPLICIT is implied. (See
+Section 2.3.) For definitions stated outside a module, the
+explicit inclusion of the keyword EXPLICIT is preferable to
+prevent ambiguity.
+
+Example 1: PKCS #7's ContentInfo type has an optional
+content component with an explicit, context-specific tag:
+
+ContentInfo ::= SEQUENCE {
+  contentType ContentType,
+  content
+    [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
+
+Here the underlying type is ANY DEFINED BY contentType, the
+class is absent (i.e., context-specific), and the tag number
+within the class is 0.
+
+Example 2: X.509's Certificate type has a version component
+with an explicit, context-specific tag, where the EXPLICIT
+keyword is omitted:
+
+Certificate ::= ...
+  version [0] Version DEFAULT v1988,
+...
+
+The tag is explicit because the default tagging method for
+the ASN.1 "module" in X.509 that defines the Certificate
+type is explicit tagging.
+
+BER encoding. Constructed. Contents octets are the BER
+encoding of the underlying value.
+
+Example: the BER encoding of the content component of a
+ContentInfo value is as follows:
+
+     o    identifier octets are a0
+
+     o    length octets represent the length of the BER
+          encoding of the underlying ANY DEFINED BY
+          contentType value
+
+     o    contents octets are the BER encoding of the
+          underlying ANY DEFINED BY contentType value
+
+DER encoding. Constructed. Contents octets are the DER
+encoding of the underlying value.
+
+
+5.3 ANY
+
+The ANY type denotes an arbitrary value of an arbitrary
+type, where the arbitrary type is possibly defined in the
+registration of an object identifier or associated with an
+integer index.
+
+The ANY type is used for content of a particular content
+type in PKCS #7's ContentInfo type, for parameters of a
+particular algorithm in X.509's AlgorithmIdentifier type,
+and for attribute values in X.501's Attribute and
+AttributeValueAssertion types. The Attribute type is used by
+PKCS #6, #7, #8, #9 and #10, and the AttributeValueAssertion
+type is used in X.501 distinguished names.
+
+ASN.1 notation:
+
+ANY [DEFINED BY identifier]
+
+where identifier is an optional identifier.
+
+In the ANY form, the actual type is indeterminate.
+
+The ANY DEFINED BY identifier form can only appear in a
+component of a SEQUENCE or SET type for which identifier
+identifies some other component, and that other component
+has type INTEGER or OBJECT IDENTIFIER (or a type derived
+from either of those by tagging). In that form, the actual
+type is determined by the value of the other component,
+either in the registration of the object identifier value,
+or in a table of integer values.
+
+Example: X.509's AlgorithmIdentifier type has a component of
+type ANY:
+
+AlgorithmIdentifier ::= SEQUENCE {
+  algorithm OBJECT IDENTIFIER,
+  parameters ANY DEFINED BY algorithm OPTIONAL }
+
+Here the actual type of the parameter component depends on
+the value of the algorithm component. The actual type would
+be defined in the registration of object identifier values
+for the algorithm component.
+
+BER encoding. Same as the BER encoding of the actual value.
+
+Example: The BER encoding of the value of the parameter
+component is the BER encoding of the value of the actual
+type as defined in the registration of object identifier
+values for the algorithm component.
+
+DER encoding. Same as the DER encoding of the actual value.
+
+
+5.4 BIT STRING
+
+The BIT STRING type denotes an arbitrary string of bits
+(ones and zeroes). A BIT STRING value can have any length,
+including zero. This type is a string type.
+
+The BIT STRING type is used for digital signatures on
+extended certificates in PKCS #6's ExtendedCertificate type,
+for digital signatures on certificates in X.509's
+Certificate type, and for public keys in certificates in
+X.509's SubjectPublicKeyInfo type.
+
+ASN.1 notation:
+
+BIT STRING
+
+Example: X.509's SubjectPublicKeyInfo type has a component
+of type BIT STRING:
+
+SubjectPublicKeyInfo ::= SEQUENCE {
+  algorithm AlgorithmIdentifier,
+  publicKey BIT STRING }
+
+BER encoding. Primitive or constructed. In a primitive
+encoding, the first contents octet gives the number of bits
+by which the length of the bit string is less than the next
+multiple of eight (this is called the "number of unused
+bits"). The second and following contents octets give the
+value of the bit string, converted to an octet string. The
+conversion process is as follows:
+
+     1.   The bit string is padded after the last bit with
+          zero to seven bits of any value to make the length
+          of the bit string a multiple of eight. If the
+          length of the bit string is a multiple of eight
+          already, no padding is done.
+
+     2.   The padded bit string is divided into octets. The
+          first eight bits of the padded bit string become
+          the first octet, bit 8 to bit 1, and so on through
+          the last eight bits of the padded bit string.
+
+In a constructed encoding, the contents octets give the
+concatenation of the BER encodings of consecutive substrings
+of the bit string, where each substring except the last has
+a length that is a multiple of eight bits.
+
+Example: The BER encoding of the BIT STRING value
+"011011100101110111" can be any of the following, among
+others, depending on the choice of padding bits, the form of
+length octets, and whether the encoding is primitive or
+constructed:
+
+03 04 06 6e 5d c0                               DER encoding
+
+03 04 06 6e 5d e0                       padded with "100000"
+
+03 81 04 06 6e 5d c0              long form of length octets
+
+23 09        constructed encoding: "0110111001011101" + "11"
+   03 03 00 6e 5d
+   03 02 06 c0
+
+DER encoding. Primitive. The contents octects are as for a
+primitive BER encoding, except that the bit string is padded
+with zero-valued bits.
+
+Example: The DER encoding of the BIT STRING value
+"011011100101110111" is
+
+03 04 06 6e 5d c0
+
+
+5.5 CHOICE
+
+The CHOICE type denotes a union of one or more alternatives.
+
+The CHOICE type is used to represent the union of an
+extended certificate and an X.509 certificate in PKCS #7's
+ExtendedCertificateOrCertificate type.
+
+ASN.1 notation:
+
+CHOICE {
+  [identifier1] Type1,
+  ...,
+  [identifiern] Typen }
+
+where identifier1 , ..., identifiern are optional, distinct
+identifiers for the alternatives, and Type1, ..., Typen are
+the types of the alternatives. The identifiers are primarily
+for documentation; they do not affect values of the type or
+their encodings in any way.
+
+The types must have distinct tags. This requirement is
+typically satisfied with explicit or implicit tagging on
+some of the alternatives.
+
+Example: PKCS #7's ExtendedCertificateOrCertificate type is
+a CHOICE type:
+
+ExtendedCertificateOrCertificate ::= CHOICE {
+  certificate Certificate, -- X.509
+  extendedCertificate [0] IMPLICIT ExtendedCertificate
+}
+
+Here the identifiers for the alternatives are certificate
+and extendedCertificate, and the types of the alternatives
+are Certificate and [0] IMPLICIT ExtendedCertificate.
+
+BER encoding. Same as the BER encoding of the chosen
+alternative. The fact that the alternatives have distinct
+tags makes it possible to distinguish between their BER
+encodings.
+
+Example: The identifier octets for the BER encoding are 30
+if the chosen alternative is certificate, and a0 if the
+chosen alternative is extendedCertificate.
+
+DER encoding. Same as the DER encoding of the chosen
+alternative.
+
+
+5.6 IA5String
+
+The IA5String type denotes an arbtrary string of IA5
+characters. IA5 stands for International Alphabet 5, which
+is the same as ASCII. The character set includes non-
+printing control characters. An IA5String value can have any
+length, including zero. This type is a string type.
+
+The IA5String type is used in PKCS #9's electronic-mail
+address, unstructured-name, and unstructured-address
+attributes.
+
+ASN.1 notation:
+
+IA5String
+
+BER encoding. Primitive or constructed. In a primitive
+encoding, the contents octets give the characters in the IA5
+string, encoded in ASCII. In a constructed encoding, the
+contents octets give the concatenation of the BER encodings
+of consecutive substrings of the IA5 string.
+
+Example: The BER encoding of the IA5String value
+"test1@rsa.com" can be any of the following, among others,
+depending on the form of length octets and whether the
+encoding is primitive or constructed:
+
+16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d DER encoding
+
+16 81 0d                       long form of length octets
+   74 65 73 74 31 40 72 73 61 2e 63 6f 6d
+
+36 13     constructed encoding: "test1" + "@" + "rsa.com"
+   16 05 74 65 73 74 31
+   16 01 40
+   16 07 72 73 61 2e 63 6f 6d
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+Example: The DER encoding of the IA5String value
+"test1@rsa.com" is
+
+16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
+
+
+5.7 INTEGER
+
+The INTEGER type denotes an arbitrary integer. INTEGER
+values can be positive, negative, or zero, and can have any
+magnitude.
+
+The INTEGER type is used for version numbers throughout
+PKCS, cryptographic values such as modulus, exponent, and
+primes in PKCS #1's RSAPublicKey and RSAPrivateKey types and
+PKCS #3's DHParameter type, a message-digest iteration count
+in PKCS #5's PBEParameter type, and version numbers and
+serial numbers in X.509's Certificate type.
+
+ASN.1 notation:
+
+INTEGER [{ identifier1(value1) ... identifiern(valuen) }]
+
+where identifier1, ..., identifiern are optional distinct
+identifiers and value1, ..., valuen are optional integer
+values. The identifiers, when present, are associated with
+values of the type.
+
+Example: X.509's Version type is an INTEGER type with
+identified values:
+
+Version ::= INTEGER { v1988(0) }
+
+The identifier v1988 is associated with the value 0. X.509's
+Certificate type uses the identifier v1988 to give a default
+value of 0 for the version component:
+
+Certificate ::= ...
+  version Version DEFAULT v1988,
+...
+
+BER encoding. Primitive. Contents octets give the value of
+the integer, base 256, in two's complement form, most
+significant digit first, with the minimum number of octets.
+The value 0 is encoded as a single 00 octet.
+
+Some example BER encodings (which also happen to be DER
+encodings) are given in Table 3.
+
+                    Integer   BER encoding
+                    value
+                    0         02 01 00
+                    127       02 01 7F
+                    128       02 02 00 80
+                    256       02 02 01 00
+                    -128      02 01 80
+                    -129      02 02 FF 7F
+
+      Table 3. Example BER encodings of INTEGER values.
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+
+5.8 NULL
+
+The NULL type denotes a null value.
+
+The NULL type is used for algorithm parameters in several
+places in PKCS.
+
+ASN.1 notation:
+
+NULL
+
+BER encoding. Primitive. Contents octets are empty.
+
+Example: The BER encoding of a NULL value can be either of
+the following, as well as others, depending on the form of
+the length octets:
+
+05 00
+
+05 81 00
+
+DER encoding. Primitive. Contents octets are empty; the DER
+encoding of a NULL value is always 05 00.
+
+
+5.9 OBJECT IDENTIFIER
+
+The OBJECT IDENTIFIER type denotes an object identifier, a
+sequence of integer components that identifies an object
+such as an algorithm, an attribute type, or perhaps a
+registration authority that defines other object
+identifiers. An OBJECT IDENTIFIER value can have any number
+of components, and components can generally have any
+nonnegative value. This type is a non-string type.
+
+OBJECT IDENTIFIER values are given meanings by registration
+authorities. Each registration authority is responsible for
+all sequences of components beginning with a given sequence.
+A registration authority typically delegates responsibility
+for subsets of the sequences in its domain to other
+registration authorities, or for particular types of object.
+There are always at least two components.
+
+The OBJECT IDENTIFIER type is used to identify content in
+PKCS #7's ContentInfo type, to identify algorithms in
+X.509's AlgorithmIdentifier type, and to identify attributes
+in X.501's Attribute and AttributeValueAssertion types. The
+Attribute type is used by PKCS #6, #7, #8, #9, and #10, and
+the AttributeValueAssertion type is used in X.501
+distinguished names. OBJECT IDENTIFIER values are defined
+throughout PKCS.
+
+ASN.1 notation:
+
+OBJECT IDENTIFIER
+
+The ASN.1 notation for values of the OBJECT IDENTIFIER type
+is
+
+{ [identifier] component1 ... componentn }
+
+componenti = identifieri | identifieri (valuei) | valuei
+
+where identifier, identifier1, ..., identifiern are
+identifiers, and value1, ..., valuen are optional integer
+values.
+
+The form without identifier is the "complete" value with all
+its components; the form with identifier abbreviates the
+beginning components with another object identifier value.
+The identifiers identifier1, ..., identifiern are intended
+primarily for documentation, but they must correspond to the
+integer value when both are present. These identifiers can
+appear without integer values only if they are among a small
+set of identifiers defined in X.208.
+
+Example: The following values both refer to the object
+identifier assigned to RSA Data Security, Inc.:
+
+{ iso(1) member-body(2) 840 113549 }
+{ 1 2 840 113549 }
+
+(In this example, which gives ASN.1 value notation, the
+object identifier values are decimal, not hexadecimal.)
+Table 4 gives some other object identifier values and their
+meanings.
+
+ Object identifier value       Meaning
+ { 1 2 }                       ISO member bodies
+ { 1 2 840 }                   US (ANSI)
+ { 1 2 840 113549 }            RSA Data Security, Inc.
+ { 1 2 840 113549 1 }          RSA Data Security, Inc. PKCS
+ { 2 5 }                       directory services (X.500)
+ { 2 5 8 }                     directory services-algorithms
+
+ Table 4. Some object identifier values and their meanings.
+
+BER encoding. Primitive. Contents octets are as follows,
+where value1, ..., valuen denote the integer values of the
+components in the complete object identifier:
+
+     1.   The first octet has value 40 * value1 + value2.
+          (This is unambiguous, since value1 is limited to
+          values 0, 1, and 2; value2 is limited to the range
+          0 to 39 when value1 is 0 or 1; and, according to
+          X.208, n is always at least 2.)
+
+     2.   The following octets, if any, encode value3, ...,
+          valuen. Each value is encoded base 128, most
+          significant digit first, with as few digits as
+          possible, and the most significant bit of each
+          octet except the last in the value's encoding set
+          to "1."
+
+Example: The first octet of the BER encoding of RSA Data
+Security, Inc.'s object identifier is 40 * 1 + 2 = 42 =
+2a16. The encoding of 840 = 6 * 128 + 4816 is 86 48 and the
+encoding of 113549 = 6 * 1282 + 7716 * 128 + d16 is 86 f7
+0d. This leads to the following BER encoding:
+
+06 06 2a 86 48 86 f7 0d
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+
+5.10 OCTET STRING
+
+The OCTET STRING type denotes an arbitrary string of octets
+(eight-bit values). An OCTET STRING value can have any
+length, including zero. This type is a string type.
+
+The OCTET STRING type is used for salt values in PKCS #5's
+PBEParameter type, for message digests, encrypted message
+digests, and encrypted content in PKCS #7, and for private
+keys and encrypted private keys in PKCS #8.
+
+ASN.1 notation:
+
+OCTET STRING [SIZE ({size | size1..size2})]
+
+where size, size1, and size2 are optional size constraints.
+In the OCTET STRING SIZE (size) form, the octet string must
+have size octets. In the OCTET STRING SIZE (size1..size2)
+form, the octet string must have between size1 and size2
+octets. In the OCTET STRING form, the octet string can have
+any size.
+
+Example: PKCS #5's PBEParameter type has a component of type
+OCTET STRING:
+
+PBEParameter ::= SEQUENCE {
+  salt OCTET STRING SIZE(8),
+  iterationCount INTEGER }
+
+Here the size of the salt component is always eight octets.
+
+BER encoding. Primitive or constructed. In a primitive
+encoding, the contents octets give the value of the octet
+string, first octet to last octet. In a constructed
+encoding, the contents octets give the concatenation of the
+BER encodings of substrings of the OCTET STRING value.
+
+Example: The BER encoding of the OCTET STRING value 01 23 45
+67 89 ab cd ef can be any of the following, among others,
+depending on the form of length octets and whether the
+encoding is primitive or constructed:
+
+04 08 01 23 45 67 89 ab cd ef                   DER encoding
+
+04 81 08 01 23 45 67 89 ab cd ef  long form of length octets
+
+24 0c            constructed encoding: 01 ... 67 + 89 ... ef
+   04 04 01 23 45 67
+   04 04 89 ab cd ef
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+Example: The BER encoding of the OCTET STRING value 01 23 45
+67 89 ab cd ef is
+
+04 08 01 23 45 67 89 ab cd ef
+
+
+5.11 PrintableString
+
+The PrintableString type denotes an arbitrary string of
+printable characters from the following character set:
+
+                         A, B, ..., Z
+                         a, b, ..., z
+                         0, 1, ..., 9
+               (space) ' ( ) + , - . / : = ?
+
+This type is a string type.
+
+The PrintableString type is used in PKCS #9's challenge-
+password and unstructuerd-address attributes, and in several
+X.521 distinguished names attributes.
+
+ASN.1 notation:
+
+PrintableString
+
+BER encoding. Primitive or constructed. In a primitive
+encoding, the contents octets give the characters in the
+printable string, encoded in ASCII. In a constructed
+encoding, the contents octets give the concatenation of the
+BER encodings of consecutive substrings of the string.
+
+Example: The BER encoding of the PrintableString value "Test
+User 1" can be any of the following, among others, depending
+on the form of length octets and whether the encoding is
+primitive or constructed:
+
+13 0b 54 65 73 74 20 55 73 65 72 20 31          DER encoding
+
+13 81 0b                          long form of length octets
+   54 65 73 74 20 55 73 65 72 20 31
+
+33 0f               constructed encoding: "Test " + "User 1"
+   13 05 54 65 73 74 20
+   13 06 55 73 65 72 20 31
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+Example: The DER encoding of the PrintableString value "Test
+User 1" is
+
+13 0b 54 65 73 74 20 55 73 65 72 20 31
+
+
+5.12 SEQUENCE
+
+The SEQUENCE type denotes an ordered collection of one or
+more types.
+
+The SEQUENCE type is used throughout PKCS and related
+standards.
+
+ASN.1 notation:
+
+SEQUENCE {
+  [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
+  ...,
+  [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
+
+where identifier1 , ..., identifiern are optional, distinct
+identifiers for the components, Type1, ..., Typen are the
+types of the components, and value1, ..., valuen are optional
+default values for the components. The identifiers are
+primarily for documentation; they do not affect values of
+the type or their encodings in any way.
+
+The OPTIONAL qualifier indicates that the value of a
+component is optional and need not be present in the
+sequence. The DEFAULT qualifier also indicates that the
+value of a component is optional, and assigns a default
+value to the component when the component is absent.
+
+The types of any consecutive series of components with the
+OPTIONAL or DEFAULT qualifier, as well as of any component
+immediately following that series, must have distinct tags.
+This requirement is typically satisfied with explicit or
+implicit tagging on some of the components.
+
+Example: X.509's Validity type is a SEQUENCE type with two
+components:
+
+Validity ::= SEQUENCE {
+  start UTCTime,
+  end UTCTime }
+
+Here the identifiers for the components are start and end,
+and the types of the components are both UTCTime.
+
+BER encoding. Constructed. Contents octets are the
+concatenation of the BER encodings of the values of the
+components of the sequence, in order of definition, with the
+following rules for components with the OPTIONAL and DEFAULT
+qualifiers:
+
+     o    if the value of a component with the OPTIONAL or
+          DEFAULT qualifier is absent from the sequence,
+          then the encoding of that component is not
+          included in the contents octets
+
+     o    if the value of a component with the DEFAULT
+          qualifier is the default value, then the encoding
+          of that component may or may not be included in
+          the contents octets
+
+DER encoding. Constructed. Contents octets are the same as
+the BER encoding, except that if the value of a component
+with the DEFAULT qualifier is the default value, the
+encoding of that component is not included in the contents
+octets.
+
+
+5.13 SEQUENCE OF
+
+The SEQUENCE OF type denotes an ordered collection of zero
+or more occurrences of a given type.
+
+The SEQUENCE OF type is used in X.501 distinguished names.
+
+ASN.1 notation:
+
+SEQUENCE OF Type
+
+where Type is a type.
+
+Example: X.501's RDNSequence type consists of zero or more
+occurences of the RelativeDistinguishedName type, most
+significant occurrence first:
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+BER encoding. Constructed. Contents octets are the
+concatenation of the BER encodings of the values of the
+occurrences in the collection, in order of occurence.
+
+DER encoding. Constructed. Contents octets are the
+concatenation of the DER encodings of the values of the
+occurrences in the collection, in order of occurence.
+
+
+5.14 SET
+
+The SET type denotes an unordered collection of one or more
+types.
+
+The SET type is not used in PKCS.
+
+ASN.1 notation:
+
+SET {
+  [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
+  ...,
+  [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
+
+where identifier1, ..., identifiern are optional, distinct
+identifiers for the components, Type1, ..., Typen are the
+types of the components, and value1, ..., valuen are
+optional default values for the components. The identifiers
+are primarily for documentation; they do not affect values
+of the type or their encodings in any way.
+
+The OPTIONAL qualifier indicates that the value of a
+component is optional and need not be present in the set.
+The DEFAULT qualifier also indicates that the value of a
+component is optional, and assigns a default value to the
+component when the component is absent.
+
+The types must have distinct tags. This requirement is
+typically satisfied with explicit or implicit tagging on
+some of the components.
+
+BER encoding. Constructed. Contents octets are the
+concatenation of the BER encodings of the values of the
+components of the set, in any order, with the following
+rules for components with the OPTIONAL and DEFAULT
+qualifiers:
+
+     o    if the value of a component with the OPTIONAL or
+          DEFAULT qualifier is absent from the set, then the
+          encoding of that component is not included in the
+          contents octets
+
+     o    if the value of a component with the DEFAULT
+          qualifier is the default value, then the encoding
+          of that component may or may not be included in
+          the contents octets
+
+DER encoding. Constructed. Contents octets are the same as
+for the BER encoding, except that:
+
+     1.   If the value of a component with the DEFAULT
+          qualifier is the default value, the encoding of
+          that component is not included.
+
+     2.   There is an order to the components, namely
+          ascending order by tag.
+
+
+5.15 SET OF
+
+The SET OF type denotes an unordered collection of zero or
+more occurrences of a given type.
+
+The SET OF type is used for sets of attributes in PKCS #6,
+#7, #8, #9 and #10, for sets of message-digest algorithm
+identifiers, signer information, and recipient information
+in PKCS #7, and in X.501 distinguished names.
+
+ASN.1 notation:
+
+SET OF Type
+
+where Type is a type.
+
+Example: X.501's RelativeDistinguishedName type consists of
+zero or more occurrences of the AttributeValueAssertion
+type, where the order is unimportant:
+
+RelativeDistinguishedName ::=
+  SET OF AttributeValueAssertion
+
+BER encoding. Constructed. Contents octets are the
+concatenation of the BER encodings of the values of the
+occurrences in the collection, in any order.
+
+DER encoding. Constructed. Contents octets are the same as
+for the BER encoding, except that there is an order, namely
+ascending lexicographic order of BER encoding. Lexicographic
+comparison of two different BER encodings is done as
+follows: Logically pad the shorter BER encoding after the
+last octet with dummy octets that are smaller in value than
+any normal octet. Scan the BER encodings from left to right
+until a difference is found. The smaller-valued BER encoding
+is the one with the smaller-valued octet at the point of
+difference.
+
+
+5.16 T61String
+
+The T61String type denotes an arbtrary string of T.61
+characters. T.61 is an eight-bit extension to the ASCII
+character set. Special "escape" sequences specify the
+interpretation of subsequent character values as, for
+example, Japanese; the initial interpretation is Latin. The
+character set includes non-printing control characters. The
+T61String type allows only the Latin and Japanese character
+interepretations, and implementors' agreements for directory
+names exclude control characters [NIST92]. A T61String value
+can have any length, including zero. This type is a string
+type.
+
+The T61String type is used in PKCS #9's unstructured-address
+and challenge-password attributes, and in several X.521
+attributes.
+
+ASN.1 notation:
+
+T61String
+
+BER encoding. Primitive or constructed. In a primitive
+encoding, the contents octets give the characters in the
+T.61 string, encoded in ASCII. In a constructed encoding,
+the contents octets give the concatenation of the BER
+encodings of consecutive substrings of the T.61 string.
+
+Example: The BER encoding of the T61String value "cl'es
+publiques" (French for "public keys") can be any of the
+following, among others, depending on the form of length
+octets and whether the encoding is primitive or constructed:
+
+14 0f                                           DER encoding
+   63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
+
+14 81 0f                          long form of length octets
+   63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
+
+34 15      constructed encoding: "cl'es" + " " + "publiques"
+   14 05 63 6c c2 65 73
+   14 01 20
+   14 09 70 75 62 6c 69 71 75 65 73
+
+The eight-bit character c2 is a T.61 prefix that adds an
+acute accent (') to the next character.
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+Example: The DER encoding of the T61String value "cl'es
+publiques" is
+
+14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
+
+
+5.17 UTCTime
+
+The UTCTime type denotes a "coordinated universal time" or
+Greenwich Mean Time (GMT) value. A UTCTime value includes
+the local time precise to either minutes or seconds, and an
+offset from GMT in hours and minutes. It takes any of the
+following forms:
+
+YYMMDDhhmmZ
+YYMMDDhhmm+hh'mm'
+YYMMDDhhmm-hh'mm'
+YYMMDDhhmmssZ
+YYMMDDhhmmss+hh'mm'
+YYMMDDhhmmss-hh'mm'
+
+where:
+
+     YY is the least significant two digits of the year
+
+     MM is the month (01 to 12)
+
+     DD is the day (01 to 31)
+
+     hh is the hour (00 to 23)
+
+     mm are the minutes (00 to 59)
+
+     ss are the seconds (00 to 59)
+
+     Z indicates that local time is GMT, + indicates that
+          local time is later than GMT, and - indicates that
+          local time is earlier than GMT
+
+     hh' is the absolute value of the offset from GMT in
+          hours
+
+     mm' is the absolute value of the offset from GMT in
+          minutes
+
+This type is a string type.
+
+The UTCTime type is used for signing times in PKCS #9's
+signing-time attribute and for certificate validity periods
+in X.509's Validity type.
+
+ASN.1 notation:
+
+UTCTime
+
+BER encoding. Primitive or constructed. In a primitive
+encoding, the contents octets give the characters in the
+string, encoded in ASCII. In a constructed encoding, the
+contents octets give the concatenation of the BER encodings
+of consecutive substrings of the string. (The constructed
+encoding is not particularly interesting, since UTCTime
+values are so short, but the constructed encoding is
+permitted.)
+
+Example: The time this sentence was originally written was
+4:45:40 p.m. Pacific Daylight Time on May 6, 1991, which can
+be represented with either of the following UTCTime values,
+among others:
+
+"910506164540-0700"
+
+"910506234540Z"
+
+These values have the following BER encodings, among others:
+
+17 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a
+
+17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30
+      30
+
+DER encoding. Primitive. Contents octets are as for a
+primitive BER encoding.
+
+
+6. An example
+
+This section gives an example of ASN.1 notation and DER
+encoding: the X.501 type Name.
+
+
+6.1 Abstract notation
+
+This section gives the ASN.1 notation for the X.501 type
+Name.
+
+Name ::= CHOICE {
+  RDNSequence }
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+RelativeDistinguishedName ::=
+  SET OF AttributeValueAssertion
+
+AttributeValueAssertion ::= SEQUENCE {
+   AttributeType,
+   AttributeValue }
+
+AttributeType ::= OBJECT IDENTIFIER
+
+AttributeValue ::= ANY
+
+The Name type identifies an object in an X.500 directory.
+Name is a CHOICE type consisting of one alternative:
+RDNSequence. (Future revisions of X.500 may have other
+alternatives.)
+
+The RDNSequence type gives a path through an X.500 directory
+tree starting at the root. RDNSequence is a SEQUENCE OF type
+consisting of zero or more occurences of
+RelativeDistinguishedName.
+
+The RelativeDistinguishedName type gives a unique name to an
+object relative to the object superior to it in the
+directory tree. RelativeDistinguishedName is a SET OF type
+consisting of zero or more occurrences of
+AttributeValueAssertion.
+
+The AttributeValueAssertion type assigns a value to some
+attribute of a relative distinguished name, such as country
+name or common name. AttributeValueAssertion is a SEQUENCE
+type consisting of two components, an AttributeType type and
+an AttributeValue type.
+
+The AttributeType type identifies an attribute by object
+identifier. The AttributeValue type gives an arbitrary
+attribute value. The actual type of the attribute value is
+determined by the attribute type.
+
+
+6.2 DER encoding
+
+This section gives an example of a DER encoding of a value
+of type Name, working from the bottom up.
+
+The name is that of the Test User 1 from the PKCS examples
+[Kal93]. The name is represented by the following path:
+
+                           (root)
+                              |
+                     countryName = "US"
+                              |
+          organizationName = "Example Organization"
+                              |
+                 commonName = "Test User 1"
+
+Each level corresponds to one RelativeDistinguishedName
+value, each of which happens for this name to consist of one
+AttributeValueAssertion value. The AttributeType value is
+before the equals sign, and the AttributeValue value (a
+printable string for the given attribute types) is after the
+equals sign.
+
+The countryName, organizationName, and commonUnitName are
+attribute types defined in X.520 as:
+
+attributeType OBJECT IDENTIFIER ::=
+  { joint-iso-ccitt(2) ds(5) 4 }
+
+countryName OBJECT IDENTIFIER ::= { attributeType 6 }
+organizationName OBJECT IDENTIFIER ::=
+  { attributeType 10 }
+commonUnitName OBJECT IDENTIFIER ::=
+  { attributeType 3 }
+
+
+6.2.1 AttributeType
+
+The three AttributeType values are OCTET STRING values, so
+their DER encoding follows the primitive, definite-length
+method:
+
+06 03 55 04 06                                   countryName
+
+06 03 55 04 0a                              organizationName
+
+06 03 55 04 03                                    commonName
+
+The identifier octets follow the low-tag form, since the tag
+is 6 for OBJECT IDENTIFIER. Bits 8 and 7 have value "0,"
+indicating universal class, and bit 6 has value "0,"
+indicating that the encoding is primitive. The length octets
+follow the short form. The contents octets are the
+concatenation of three octet strings derived from
+subidentifiers (in decimal): 40 * 2 + 5 = 85 = 5516; 4; and
+6, 10, or 3.
+
+
+6.2.2 AttributeValue
+
+The three AttributeValue values are PrintableString values,
+so their encodings follow the primitive, definite-length
+method:
+
+13 02 55 53                                             "US"
+
+13 14                                 "Example Organization"
+   45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
+   74 69 6f 6e
+
+13 0b                                          "Test User 1"
+   54 65 73 74 20 55 73 65 72 20 31
+
+The identifier octets follow the low-tag-number form, since
+the tag for PrintableString, 19 (decimal), is between 0 and
+30. Bits 8 and 7 have value "0" since PrintableString is in
+the universal class. Bit 6 has value "0" since the encoding
+is primitive. The length octets follow the short form, and
+the contents octets are the ASCII representation of the
+attribute value.
+
+
+6.2.3 AttributeValueAssertion
+
+The three AttributeValueAssertion values are SEQUENCE
+values, so their DER encodings follow the constructed,
+definite-length method:
+
+30 09                                     countryName = "US"
+   06 03 55 04 06
+   13 02 55 53
+
+30 1b              organizationName = "Example Organizaiton"
+   06 03 55 04 0a
+   13 14 ... 6f 6e
+
+30 12                             commonName = "Test User 1"
+   06 03 55 04 0b
+   13 0b ... 20 31
+
+The identifier octets follow the low-tag-number form, since
+the tag for SEQUENCE, 16 (decimal), is between 0 and 30.
+Bits 8 and 7 have value "0" since SEQUENCE is in the
+universal class. Bit 6 has value "1" since the encoding is
+constructed. The length octets follow the short form, and
+the contents octets are the concatenation of the DER
+encodings of the attributeType and attributeValue
+components.
+
+
+6.2.4 RelativeDistinguishedName
+
+The three RelativeDistinguishedName values are SET OF
+values, so their DER encodings follow the constructed,
+definite-length method:
+
+31 0b
+   30 09 ... 55 53
+
+31 1d
+   30 1b ... 6f 6e
+
+31 14
+   30 12 ... 20 31
+
+The identifier octets follow the low-tag-number form, since
+the tag for SET OF, 17 (decimal), is between 0 and 30. Bits
+8 and 7 have value "0" since SET OF is in the universal
+class Bit 6 has value "1" since the encoding is constructed.
+The lengths octets follow the short form, and the contents
+octets are the DER encodings of the respective
+AttributeValueAssertion values, since there is only one
+value in each set.
+
+
+6.2.5 RDNSequence
+
+The RDNSequence value is a SEQUENCE OF value, so its DER
+encoding follows the constructed, definite-length method:
+
+30 42
+   31 0b ... 55 53
+   31 1d ... 6f 6e
+   31 14 ... 20 31
+
+The identifier octets follow the low-tag-number form, since
+the tag for SEQUENCE OF, 16 (decimal), is between 0 and 30.
+Bits 8 and 7 have value "0" since SEQUENCE OF is in the
+universal class. Bit 6 has value "1" since the encoding is
+constructed. The lengths octets follow the short form, and
+the contents octets are the concatenation of the DER
+encodings of the three RelativeDistinguishedName values, in
+order of occurrence.
+
+
+6.2.6 Name
+
+The Name value is a CHOICE value, so its DER encoding is the
+same as that of the RDNSequence value:
+
+30 42
+   31 0b
+      30 09
+         06 03 55 04 06          attributeType = countryName
+         13 02 55 53                   attributeValue = "US"
+   31 1d
+      30 1b
+         06 03 55 04 0a     attributeType = organizationName
+         13 14       attributeValue = "Example Organization"
+            45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
+            74 69 6f 6e
+
+   31 14
+      30 12
+         06 03 55 04 03           attributeType = commonName
+         13 0b                attributeValue = "Test User 1"
+            54 65 73 74 20 55 73 65 72 20 31
+
+
+References
+
+PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption
+          Standard. Version 1.5, November 1993.
+
+PKCS #3   RSA Laboratories. PKCS #3: Diffie-Hellman Key-
+          Agreement Standard. Version 1.4, November 1993.
+
+PKCS #5   RSA Laboratories. PKCS #5: Password-Based
+          Encryption Standard. Version 1.5, November 1993.
+
+PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
+          Syntax Standard. Version 1.5, November 1993.
+
+PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
+          Syntax Standard. Version 1.5, November 1993.
+
+PKCS #8   RSA Laboratories. PKCS #8: Private-Key Information
+          Syntax Standard. Version 1.2, November 1993.
+
+PKCS #9   RSA Laboratories. PKCS #9: Selected Attribute
+          Types. Version 1.1, November 1993.
+
+PKCS #10  RSA Laboratories. PKCS #10: Certification Request
+          Syntax Standard. Version 1.0, November 1993.
+
+X.200     CCITT. Recommendation X.200: Reference Model of
+          Open Systems Interconnection for CCITT
+          Applications. 1984.
+
+X.208     CCITT. Recommendation X.208: Specification of
+          Abstract Syntax Notation One (ASN.1). 1988.
+
+X.209     CCITT. Recommendation X.209: Specification of
+          Basic Encoding Rules for Abstract Syntax Notation
+          One (ASN.1). 1988.
+
+X.500     CCITT. Recommendation X.500: The
+          Directory--Overview of Concepts, Models and
+          Services. 1988.
+
+X.501     CCITT. Recommendation X.501: The Directory--
+          Models. 1988.
+
+X.509     CCITT. Recommendation X.509: The Directory--
+          Authentication Framework. 1988.
+
+X.520     CCITT. Recommendation X.520: The Directory--
+          Selected Attribute Types. 1988.
+
+[Kal93]   Burton S. Kaliski Jr. Some Examples of the PKCS
+          Standards. RSA Laboratories, November 1993.
+
+[NIST92]  NIST. Special Publication 500-202: Stable
+          Implementation Agreements for Open Systems
+          Interconnection Protocols. Part 11 (Directory
+          Services Protocols). December 1992.
+
+
+Revision history
+
+
+June 3, 1991 version
+
+The June 3, 1991 version is part of the initial public
+release of PKCS. It was published as NIST/OSI Implementors'
+Workshop document SEC-SIG-91-17.
+
+
+November 1, 1993 version
+
+The November 1, 1993 version incorporates several editorial
+changes, including the addition of a revision history. It is
+updated to be consistent with the following versions of the
+PKCS documents:
+
+     PKCS #1: RSA Encryption Standard. Version 1.5, November
+          1993.
+
+     PKCS #3: Diffie-Hellman Key-Agreement Standard. Version
+          1.4, November 1993.
+
+     PKCS #5: Password-Based Encryption Standard. Version
+          1.5, November 1993.
+
+     PKCS #6: Extended-Certificate Syntax Standard. Version
+          1.5, November 1993.
+
+     PKCS #7: Cryptographic Message Syntax Standard. Version
+          1.5, November 1993.
+
+     PKCS #8: Private-Key Information Syntax Standard.
+          Version 1.2, November 1993.
+
+     PKCS #9: Selected Attribute Types. Version 1.1,
+          November 1993.
+
+     PKCS #10: Certification Request Syntax Standard.
+          Version 1.0, November 1993.
+
+The following substantive changes were made:
+
+     Section 5: Description of T61String type is added.
+
+     Section 6: Names are changed, consistent with other
+          PKCS examples.
+
+
+Author's address
+
+Burton S. Kaliski Jr., Ph.D.
+Chief Scientist
+RSA Laboratories              (415) 595-7703
+100 Marine Parkway            (415) 595-4126 (fax)
+Redwood City, CA  94065  USA  burt@rsa.com
diff --git a/third_party/heimdal/doc/mdate-sh b/third_party/heimdal/doc/mdate-sh
new file mode 100644
index 00000000000..37171f21fbd
--- /dev/null
+++ b/third_party/heimdal/doc/mdate-sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+# Get modification time of a file or directory and pretty-print it.
+# Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
+# written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, June 1995
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software Foundation,
+# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+# Prevent date giving response in another language.
+LANG=C
+export LANG
+LC_ALL=C
+export LC_ALL
+LC_TIME=C
+export LC_TIME
+
+# Get the extended ls output of the file or directory.
+# On HPUX /bin/sh, "set" interprets "-rw-r--r--" as options, so the "x" below.
+if ls -L /dev/null 1>/dev/null 2>&1; then
+  set - x`ls -L -l -d $1`
+else
+  set - x`ls -l -d $1`
+fi
+# The month is at least the fourth argument
+# (3 shifts here, the next inside the loop).
+shift
+shift
+shift
+
+# Find the month.  Next argument is day, followed by the year or time.
+month=
+until test $month
+do
+  shift
+  case $1 in
+    Jan) month=January; nummonth=1;;
+    Feb) month=February; nummonth=2;;
+    Mar) month=March; nummonth=3;;
+    Apr) month=April; nummonth=4;;
+    May) month=May; nummonth=5;;
+    Jun) month=June; nummonth=6;;
+    Jul) month=July; nummonth=7;;
+    Aug) month=August; nummonth=8;;
+    Sep) month=September; nummonth=9;;
+    Oct) month=October; nummonth=10;;
+    Nov) month=November; nummonth=11;;
+    Dec) month=December; nummonth=12;;
+  esac
+done
+
+day=$2
+
+# Here we have to deal with the problem that the ls output gives either
+# the time of day or the year.
+case $3 in
+  *:*) set `date`; eval year=\$$#
+       case $2 in
+	 Jan) nummonthtod=1;;
+	 Feb) nummonthtod=2;;
+	 Mar) nummonthtod=3;;
+	 Apr) nummonthtod=4;;
+	 May) nummonthtod=5;;
+	 Jun) nummonthtod=6;;
+	 Jul) nummonthtod=7;;
+	 Aug) nummonthtod=8;;
+	 Sep) nummonthtod=9;;
+	 Oct) nummonthtod=10;;
+	 Nov) nummonthtod=11;;
+	 Dec) nummonthtod=12;;
+       esac
+       # For the first six month of the year the time notation can also
+       # be used for files modified in the last year.
+       if (expr $nummonth \> $nummonthtod) > /dev/null;
+       then
+	 year=`expr $year - 1`
+       fi;;
+  *) year=$3;;
+esac
+
+# The result.
+echo $day $month $year
diff --git a/third_party/heimdal/doc/migration.texi b/third_party/heimdal/doc/migration.texi
new file mode 100644
index 00000000000..2fa7ede597a
--- /dev/null
+++ b/third_party/heimdal/doc/migration.texi
@@ -0,0 +1,73 @@
+@c $Id$
+
+@node Migration, Acknowledgments, Programming with Kerberos, Top
+@chapter Migration
+
+@section Migration from MIT Kerberos to Heimdal
+
+hpropd can read MIT Kerberos dump in "kdb5_util load_dump version 5" or
+version 6 format.  Simply run:
+@samp{kdb5_util dump}.
+
+To load the MIT Kerberos dump file, use the following command:
+
+@samp{/usr/heimdal/libexec/hprop --database=dump-file --master-key=/var/db/krb5kdc/mit_stash --source=mit-dump --decrypt --stdout | /usr/heimdal/libexec/hpropd --stdin}
+
+kadmin can dump in MIT Kerberos format.  Simply run:
+@samp{kadmin -l dump -f MIT}.
+
+The Heimdal KDC and kadmind, as well as kadmin -l and the libkadm5srv
+library can read and write MIT KDBs, and can read MIT stash files.  To
+build with KDB support requires having a standalone libdb from MIT
+Kerberos and associated headers, then you can configure Heildal as
+follows:
+
+@samp{./configure ... CPPFLAGS=-I/path-to-mit-db-headers LDFLAGS="-L/path-to-mit-db-object -Wl,-rpath -Wl,/path-to-mit-db-object" LDLIBS=-ldb}
+
+At this time support for MIT Kerberos KDB dump/load format and direct
+KDB access does not include support for PKINIT, or K/M key history,
+constrained delegation, and other advanced features.
+
+Heimdal supports using multiple HDBs at once, with all write going to
+just one HDB.  This allows for entries to be moved to a native HDB from
+an MIT KDB over time as those entries are changed.  Or you can use hprop
+and hpropd.
+
+@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/third_party/heimdal/doc/misc.texi b/third_party/heimdal/doc/misc.texi
new file mode 100644
index 00000000000..1ad6aaab054
--- /dev/null
+++ b/third_party/heimdal/doc/misc.texi
@@ -0,0 +1,58 @@
+@c $Id$
+
+@node Things in search for a better place, Kerberos 4 issues, Applications, 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 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
+configuration looks like the following:
+
+@example
+aaa new-model
+aaa authentication login default krb5-telnet krb5 enable
+aaa authorization exec krb5-instance
+kerberos local-realm FOO.SE
+kerberos srvtab entry host/router.foo.se 0 891725446 4 1 8 012345678901234567
+kerberos server FOO.SE 10.0.0.1
+kerberos instance map admin 15
+@end example
+
+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, 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 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,
+time stamp (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}. 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
+you don't have to send your password over the wire, but since the telnet
+connection isn't protected it's still possible for someone to steal your
+session. This won't be fixed until someone adds integrity to the telnet
+protocol.
+
+A working solution would be to hook up a machine with a real operating
+system to the console of the Cisco and then use it as a backwards
+terminal server.
diff --git a/third_party/heimdal/doc/ntlm.din b/third_party/heimdal/doc/ntlm.din
new file mode 100644
index 00000000000..71dd5ffa060
--- /dev/null
+++ b/third_party/heimdal/doc/ntlm.din
@@ -0,0 +1,16 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal ntlm library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/ntlm
+INPUT                  = @srcdir@/../lib/ntlm
+EXAMPLE_PATH	       = @srcdir@/../lib/ntlm
+
+WARN_IF_UNDOCUMENTED   = YES
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/third_party/heimdal/doc/programming.texi b/third_party/heimdal/doc/programming.texi
new file mode 100644
index 00000000000..543e425713b
--- /dev/null
+++ b/third_party/heimdal/doc/programming.texi
@@ -0,0 +1,7 @@
+@c $Id$
+
+@node Programming with Kerberos, Migration, Windows compatibility, Top
+@chapter Programming with Kerberos
+
+See the Kerberos 5 API introduction and documentation on the Heimdal
+webpage.
diff --git a/third_party/heimdal/doc/setup.texi b/third_party/heimdal/doc/setup.texi
new file mode 100644
index 00000000000..0b3a860edb1
--- /dev/null
+++ b/third_party/heimdal/doc/setup.texi
@@ -0,0 +1,1784 @@
+@c $Id$
+
+@node Setting up a realm, Applications, Building and Installing, Top
+
+@chapter Setting up a realm
+
+A
+@cindex realm
+realm is an administrative domain.  The name of a Kerberos realm is
+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.
+
+@menu
+* Configuration file::
+* Creating the database::
+* Modifying the database::
+* Checking the setup::
+* keytabs::
+* Remote administration::
+* Password changing::
+* Testing clients and servers::
+* Slave Servers::
+* Incremental propagation::
+* Encryption types and salting::
+* Credential cache server - KCM::
+* Cross realm::
+* Transit policy::
+* Setting up DNS::
+* Using LDAP to store the database::
+* Providing Kerberos credentials to servers and programs::
+* Setting up PK-INIT::
+* Debugging Kerberos problems::
+@end menu
+
+@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:
+@file{/etc/krb5.conf}. The @file{krb5.conf} file can contain many
+configuration options, some of which are described here.
+
+There is a sample @file{krb5.conf} supplied with the distribution.
+
+The configuration file is a hierarchical structure consisting of
+sections, each containing a list of bindings (either variable
+assignments or subsections). A section starts with
+@samp{[@samp{section-name}]}.  A binding consists of a left hand side, an equal sign
+(@samp{=}) and a right hand side (the left hand side tag must be
+separated from the equal sign with some whitespace). Subsections have a
+@samp{@{} as the first non-whitespace character after the equal sign. All
+other bindings are treated as variable assignments. The value of a
+variable extends to the end of the line.
+
+Configuration files can also include other files, or all files in a
+directory.  Use absolute paths in include directives.  When including a
+directoty, only files whose names consist of alphanumeric, hyphen, or
+underscore characters are allowed, though they may end in '.conf'.
+
+@example
+include /some/config/file
+includedir /some/config/directory
+[section1]
+        a-subsection = @{
+                var = value1
+                other-var = value with @{@}
+                sub-sub-section = @{
+                        var = 123
+                @}
+        @}
+        var = some other value
+[section2]
+        var = yet another value
+@end example
+
+In this manual, names of sections and bindings will be given as strings
+separated by slashes (@samp{/}). The @samp{other-var} variable will thus
+be @samp{section1/a-subsection/other-var}.
+
+For in-depth information about the contents of the configuration file, refer to
+the @file{krb5.conf} manual page. Some of the more important sections
+are briefly described here.
+
+The @samp{libdefaults} section contains a list of library configuration
+parameters, such as the default realm and the timeout for KDC
+responses. The @samp{realms} section contains information about specific
+realms, such as where they hide their KDC@. This section serves the same
+purpose as the Kerberos 4 @file{krb.conf} file, but can contain more
+information. Finally the @samp{domain_realm} section contains a list of
+mappings from domains to realms, equivalent to the Kerberos 4
+@file{krb.realms} file.
+
+To continue with the realm setup, you will have to create a configuration file,
+with contents similar to the following.
+
+@example
+[libdefaults]
+        default_realm = MY.REALM
+[realms]
+        MY.REALM = @{
+                kdc = my.kdc my.slave.kdc
+                kdc = my.third.kdc
+                kdc = 130.237.237.17
+                kdc = [2001:6b0:1:ea::100]:88
+        @}
+[domain_realm]
+        .my.domain = MY.REALM
+
+@end example
+
+If you use a realm name equal to your domain name, you can omit the
+@samp{libdefaults}, and @samp{domain_realm}, sections. If you have a DNS
+SRV-record for your realm, or your Kerberos server has DNS CNAME
+@samp{kerberos.my.realm}, you can omit the @samp{realms} section too.
+
+@cindex KRB5_CONFIG
+If you want to use a different configuration file then the default you
+can point a file with the environment variable @samp{KRB5_CONFIG}.
+
+@example
+env KRB5_CONFIG=$HOME/etc/krb5.conf kinit user@@REALM
+@end example
+
+@cindex GSS_MECH_CONFIG
+The GSS-API mechanism configuration file can also be changed from the
+default with the enviornment variable @samp{GSS_MECH_CONFIG}. Note that
+this file only configures additional plugin mechanisms: Kerberos, NTLM
+and SPNEGO are built in to the Heimdal GSS-API library.
+
+@node Creating the database, Modifying the database, Configuration file, Setting up a realm
+@section Creating the database
+
+The database library will look for the database in the directory
+@file{@value{dbdir}}, so you should probably create that directory.
+Make sure the directory has restrictive permissions.
+
+@example
+# mkdir /var/heimdal
+# chmod og-rwx /var/heimdal
+@end example
+
+Heimdal supports various database backends: lmdb (LMDB), db3 (Berkeley
+DB 3.x, 4.x, or 5.x), db1 (Berkeley DB 2.x), sqlite (SQLite3), and ldap
+(LDAP).  The default is @value{dbtype}, and is selected at build time
+from one of lmdb, db3, or db1.
+
+These defaults can be overriden in the 'database' key in the @samp{kdc}
+section of the configuration.
+
+@example
+[kdc]
+        database = @{
+                dbname = lmdb:/path/to/db-file
+                realm = REALM
+                acl_file = /path/to/kadmind.acl
+                mkey_file = /path/to/mkey
+                log_file = /path/to/iprop-log-file
+        @}
+@end example
+
+To use LDAP, see @xref{Using LDAP to store the database}.
+
+The keys of all the principals are stored in the database.  If you
+choose to, these can be encrypted with a master key.  You do not have to
+remember this key (or password), but just to enter it once and it will
+be stored in a file (@file{/var/heimdal/m-key}).  If you want to have a
+master key, run @samp{kstash} to create this master key:
+
+@example
+# kstash
+Master key:
+Verifying password - Master key:
+@end example
+
+If you want to generate a random master key you can use the
+@kbd{--random-key} flag to kstash. This will make sure you have a good key
+on which attackers can't do a dictionary attack.
+
+If you have a master key, make sure you make a backup of your master
+key file; without it backups of the database are of no use.
+
+To initialise the database use the @command{kadmin} program, with the
+@kbd{-l} option (to enable local database mode). First issue a
+@kbd{init MY.REALM} command. This will create the database and insert
+default principals for that realm. You can have more than one realm in
+one database, so @samp{init} does not destroy any old database.
+
+Before creating the database, @samp{init} will ask you some questions
+about maximum ticket lifetimes.
+
+After creating the database you should probably add yourself to it. You
+do this with the @samp{add} command. It takes as argument the name of a
+principal. The principal should contain a realm, so if you haven't set up
+a default realm, you will need to explicitly include the realm.
+
+@example
+# kadmin -l
+kadmin> init MY.REALM
+Realm max ticket life [unlimited]:
+Realm max renewable ticket life [unlimited]:
+kadmin> add me
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Attributes []:
+Password:
+Verifying password - Password:
+@end example
+
+Now start the KDC and try getting a ticket.
+
+@example
+# kdc &
+# kinit me
+me@@MY.REALMS's Password:
+# klist
+Credentials cache: /tmp/krb5cc_0
+        Principal: me@@MY.REALM
+
+  Issued           Expires          Principal
+Aug 25 07:25:55  Aug 25 17:25:55  krbtgt/MY.REALM@@MY.REALM
+@end example
+
+If you are curious you can use the @samp{dump} command to list all the
+entries in the database.  It should look something similar to the
+following example (note that the entries here are truncated for
+typographical reasons):
+
+@smallexample
+kadmin> dump
+me@@MY.REALM 1:0:1:0b01d3cb7c293b57:-:0:7:8aec316b9d1629e3baf8 ...
+kadmin/admin@@MY.REALM 1:0:1:e5c8a2675b37a443:-:0:7:cb913ebf85 ...
+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 Modifying the database, Checking the setup, Creating the database, Setting up a realm
+@section Modifying the database
+
+All modifications of principals are done with with kadmin.
+
+A principal has several attributes and lifetimes associated with it.
+
+Principals are added, renamed, modified, and deleted with the kadmin
+commands @samp{add}, @samp{rename}, @samp{modify}, @samp{delete}.
+Both interactive editing and command line flags can be used (use --help
+to list the available options).
+
+There are different kinds of types for the fields in the database;
+attributes, absolute time times and relative times.
+
+@subsection Attributes
+
+When doing interactive editing, attributes are listed with @samp{?}.
+
+The attributes are given in a comma (@samp{,}) separated list.
+Attributes are removed from the list by prefixing them with @samp{-}.
+
+@smallexample
+kadmin> modify me
+Max ticket life [1 day]:
+Max renewable life [1 week]:
+Principal expiration time [never]:
+Password expiration time [never]:
+Attributes [disallow-renewable]: requires-pre-auth,-disallow-renewable
+kadmin> get me
+            Principal: me@@MY.REALM
+[...]
+           Attributes: requires-pre-auth
+@end smallexample
+
+@subsection Absolute times
+
+The format for absolute times are any of the following:
+
+@smallexample
+never
+now
+YYYY-mm-dd
+YYYY-mm-dd HH:MM:SS
+@end smallexample
+
+
+@subsection Relative times
+
+The format for relative times are any of the following combined:
+
+@smallexample
+N year
+M month
+O day
+P hour
+Q minute
+R second
+@end smallexample
+
+@c Describe more of kadmin commands here...
+
+@node Checking the setup, keytabs, Modifying the database, Setting up a realm
+@section Checking the setup
+
+There are two tools that can check the consistency of the Kerberos
+configuration file and the Kerberos database.
+
+The Kerberos configuration file is checked using
+@command{verify_krb5_conf}. The tool checks for common errors, but
+commonly there are several uncommon configuration entries that are
+never added to the tool and thus generates ``unknown entry'' warnings.
+This is usually nothing to worry about.
+
+The database check is built into the kadmin tool. It will check for
+common configuration error that will cause problems later. Common
+check are for existence and flags on important principals. The
+database check by run by the following command :
+
+@example
+kadmin -l check REALM.EXAMPLE.ORG
+@end example
+
+@node keytabs, Remote administration, Checking the setup, 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{add}
+(using the @kbd{--random-key} flag to get a random key) and then
+extract it with @samp{ext_keytab}.
+
+@example
+kadmin> add --random-key host/my.host.name
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Attributes []:
+kadmin> ext host/my.host.name
+kadmin> exit
+# ktutil list
+Version  Type             Principal
+     1   des-cbc-md5      host/my.host.name@@MY.REALM
+     1   des-cbc-md4      host/my.host.name@@MY.REALM
+     1   des-cbc-crc      host/my.host.name@@MY.REALM
+     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, @command{kadmind}, can be started by
+@command{inetd} (which isn't recommended) or run as a normal daemon. If you
+want to start it from @command{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
+@end example
+
+You might need to add @samp{kerberos-adm} to your @file{/etc/services}
+as @samp{749/tcp}.
+
+Access to the administration server is controlled by an ACL file,
+(default @file{/var/heimdal/kadmind.acl}.) The file has the following
+syntax:
+@smallexample
+principal       [priv1,priv2,...]       [glob-pattern]
+@end smallexample
+
+The matching is from top to bottom for matching principals (and if given,
+glob-pattern).  When there is a match, the access rights of that line are
+applied.
+
+The privileges you can assign to a principal are: @samp{add},
+@samp{change-password} (or @samp{cpw} for short), @samp{delete},
+@samp{get}, @samp{list}, and @samp{modify}, or the special privilege
+@samp{all}. All of these roughly correspond to the different commands
+in @command{kadmin}.
+
+If a @var{glob-pattern} is given on a line, it restricts the access
+rights for the principal to only apply for subjects that match the
+pattern.  The patterns 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
+help desk, 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 @command{kpasswdd}.
+It is not run from @command{inetd}.
+
+You might need to add @samp{kpasswd} to your @file{/etc/services} as
+@samp{464/udp}.  If your realm is not setup to use DNS, you might also
+need to add a @samp{kpasswd_server} entry to the realm configuration
+in @file{/etc/krb5.conf} on client machines:
+
+@example
+[realms]
+        MY.REALM = @{
+                kdc = my.kdc my.slave.kdc
+                kpasswd_server = my.kdc
+        @}
+@end example
+
+@subsection Password quality assurance
+
+It is important that users have good passwords, both to make it harder
+to guess them and to avoid off-line attacks (although
+pre-authentication provides some defence against off-line attacks).
+To ensure that the users choose good passwords, you can enable
+password quality controls in @command{kpasswdd} and @command{kadmind}.
+The controls themselves are done in a shared library or an external
+program that is used by @command{kpasswdd}.  To configure in these
+controls, add lines similar to the following to your
+@file{/etc/krb5.conf}:
+
+@example
+[password_quality]
+	policies = external-check builtin:minimum-length modulename:policyname
+	external_program = /bin/false
+	policy_libraries = @var{library1.so} @var{library2.so}
+@end example
+
+In @samp{[password_quality]policies} the module name is optional if
+the policy name is unique in all modules (members of
+@samp{policy_libraries}).  All built-in policies can be qualified with
+a module name of @samp{builtin} to unambiguously specify the built-in
+policy and not a policy by the same name from a loaded module.
+
+The built-in policies are
+
+@itemize @bullet
+
+@item external-check
+
+Executes the program specified by @samp{[password_quality]external_program}.
+
+A number of key/value pairs are passed as input to the program, one per
+line, ending with the string @samp{end}.  The key/value lines are of
+the form
+@example
+principal: @var{principal}
+new-password: @var{password}
+@end example
+where @var{password} is the password to check for the previous
+@var{principal}.
+
+If the external application approves the password, it should return
+@samp{APPROVED} on standard out and exit with exit code 0.  If it
+doesn't approve the password, an one line error message explaining the
+problem should be returned on standard error and the application
+should exit with exit code 0.  In case of a fatal error, the
+application should, if possible, print an error message on standard
+error and exit with a non-zero error code.
+
+@item minimum-length
+
+The minimum length password quality check reads the configuration file
+stanza @samp{[password_quality]min_length} and requires the password
+to be at least this length.
+
+@item character-class
+
+The character-class password quality check reads the configuration
+file stanza @samp{[password_quality]min_classes}. The policy requires
+the password to have characters from at least that many character
+classes. Default value if not given is 3.
+
+The four different characters classes are, uppercase, lowercase,
+number, special characters.
+
+@item enforce_on_admin_set
+
+The enforce_on_admin_set check subjects administrative password updates to the
+password policy. An administrative password update is a create principal or
+change password request via @command{kadmind}, or a set password request via
+@command{kpasswdd}. (A set password request is one where the authenticating
+principal differs from the principal whose password is being changed.) Password
+policies are always ignored if the authenticating principal is the kadmin
+service itself, for example when running @command{kadmin} in local mode. The
+default value for enforce_on_admin_set if not given is true.
+
+@end itemize
+
+If you want to write your own shared object to check password
+policies, see the manual page @manpage{kadm5_pwcheck,3}.
+
+Code for a password quality checking function that uses the cracklib
+library can be found in @file{lib/kadm5/sample_password_check.c} in
+the source code distribution.  It requires that the cracklib library
+be built with the patch available at
+@url{ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch}.
+
+A sample policy external program is included in
+@file{lib/kadm5/check-cracklib.pl}.
+
+If no password quality checking function is configured, the only check
+performed is that the password is at least six characters long.
+
+To check the password policy settings, use the command
+@command{verify-password-quality} in @command{kadmin} program. The password
+verification is only performed locally, on the client.  It may be
+convenient to set the environment variable @samp{KRB5_CONFIG} to point
+to a test version of @file{krb5.conf} while you're testing the
+@samp{[password_quality]} stanza that way.
+
+@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 must have the same database so that
+they present the same service to the users.  The
+@pindex hprop
+@command{hprop} program, running on the master, will propagate the database
+to the slaves, running
+@pindex hpropd
+@command{hpropd} processes.
+
+Every slave needs a database directory, the master key (if it was used
+for the database) and a keytab with the principal
+@samp{hprop/@var{hostname}}.  Add the principal with the
+@pindex ktutil
+@command{ktutil} command and start
+@pindex hpropd
+@command{hpropd}, as follows:
+
+@example
+slave# ktutil get -p foo/admin hprop/`hostname`
+slave# mkdir /var/heimdal
+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 hands-on 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
+@command{hpropd} from @command{inetd} on the slave(s) and regularly run
+@pindex hprop
+@command{hprop} on the master to regularly propagate the database.
+Starting the propagation once an hour from @command{cron} is probably a
+good idea.
+
+@node Incremental propagation, Encryption types and salting, Slave Servers, Setting up a realm
+@section Incremental propagation
+
+There is also a newer 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 assigning 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 version than the oldest one in the
+log, the whole database has to be sent.
+
+Protocol-wise, all the slaves connect 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.  There is
+also a keep-alive protocol that makes sure all slaves are up and running.
+
+In addition on listening on the network to get connection from new
+slaves, the ipropd-master also listens on a status unix
+socket. kadmind and kpasswdd both open that socket when a transation
+is done and written a notification to the socket. That cause
+ipropd-master to check for new version in the log file. As a fallback in
+case a notification is lost by the unix socket, the log file is
+checked after 30 seconds of no event.
+
+@subsection Configuring incremental propagation
+
+The program that runs on the master is @command{ipropd-master} and all
+clients run @command{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 those 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
+
+@example
+slave# /usr/heimdal/sbin/ktutil get iprop/`hostname`
+@end example
+
+
+The next step is to start the @command{ipropd-master} process on the master
+server.  The @command{ipropd-master} listens on the UNIX domain 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 @command{ipropd-slave} on all the slaves:
+
+@example
+master# /usr/heimdal/libexec/ipropd-master &
+slave#  /usr/heimdal/libexec/ipropd-slave master &
+@end example
+
+To manage the iprop log file you should use the @command{iprop-log}
+command. With it you can dump, truncate and replay the logfile.
+
+@subsection Status of iprop master and slave
+
+Both the master and slave provides status of the world as they see it.
+
+The master write outs the current status of the slaves, last seen and
+their version number in @file{/var/heimdal/slaves-stats}.
+
+The slave write out the current status in @file{/var/heimdal/ipropd-slave-status}.
+
+These locations can be changed with command line options, and in the
+case of @command{ipropd_master}, the configuration file.
+
+@node Encryption types and salting, Credential cache server - KCM, Incremental propagation, Setting up a realm
+@section Encryption types and salting
+@cindex Salting
+@cindex Encryption types
+
+The encryption types that the KDC is going to assign by default is
+possible to change. Since the keys used for user authentication is
+salted the encryption types are described together with the salt
+strings.
+
+Salting is used to make it harder to pre-calculate all possible
+keys. Using a salt increases the search space to make it almost
+impossible to pre-calculate all keys. Salting is the process of mixing a
+public string (the salt) with the password, then sending it through an
+encryption type specific string-to-key function that will output the
+fixed size encryption key.
+
+In Kerberos 5 the salt is determined by the encryption type, except in
+some special cases.
+
+In @code{des} there is the Kerberos 4 salt
+(none at all) or the afs-salt (using the cell (realm in
+AFS lingo)).
+
+In @code{arcfour} (the encryption type that Microsoft Windows 2000 uses)
+there is no salt. This is to be compatible with NTLM keys in Windows
+NT 4.
+
+@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-cbc-crc, arcfour-hmac-md5, aes256-cts-hmac-sha1-96),
+@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 appended/prepended, the empty salt "" is the same thing as
+no salt at all).
+
+Common types of salting include
+
+@itemize @bullet
+@item @code{v4} (or @code{des:pw-salt:})
+
+The Kerberos 4 salting is using no salt at all. Reason there is colon
+at the end of the salt string is that it makes the salt the empty
+string (same as no salt).
+
+@item @code{v5} (or @code{pw-salt})
+
+@code{pw-salt} uses the default salt for each encryption type is
+specified for. If the encryption type @samp{etype} isn't given, all
+default encryption will be used.
+
+@item @code{afs3-salt}
+
+@code{afs3-salt} is the salt that is used with Transarc kaserver. It's
+the cell name appended to the password.
+
+@end itemize
+
+@node Credential cache server - KCM, Cross realm, Encryption types and salting, Setting up a realm
+@section Credential cache server - KCM
+@cindex KCM
+@cindex Credential cache server
+
+When KCM running is easy for users to switch between different
+kerberos principals using @file{kswitch} or built in support in
+application, like OpenSSH's GSSAPIClientIdentity.
+
+Other advantages are that there is the long term credentials are not
+written to disk and on reboot the credential is removed when kcm
+process stopps running.
+
+Configure the system startup script to start the kcm process,
+@file{/usr/heimdal/libexec/kcm} and then configure the system to use kcm in @file{krb5.conf}.
+
+@example
+[libdefaults]
+	default_cc_type = KCM
+@end example
+
+Now when you run @command{kinit} it doesn't overwrite your existing
+credentials but rather just add them to the set of
+credentials. @command{klist -l} lists the credentials and the star
+marks the default credential.
+
+@example
+$ kinit lha@@KTH.SE
+lha@@KTH.SE's Password: 
+$ klist -l
+  Name         Cache name               Expires         
+lha@@KTH.SE   0                        Nov 22 23:09:40   *
+lha@@SU.SE    Initial default ccache   Nov 22 14:14:24   
+@end example
+
+When switching between credentials you can use @command{kswitch}.
+
+@example
+$ kswitch -i
+     Principal
+1    lha@@KTH.SE
+2    lha@@SU.SE
+Select number: 2
+@end example
+
+After switching, a new set of credentials are used as default.
+
+@example
+$ klist -l
+  Name         Cache name               Expires         
+lha@@SU.SE    Initial default ccache   Nov 22 14:14:24   *
+lha@@KTH.SE   0                        Nov 22 23:09:40   
+@end example
+
+Som applications, like openssh with Simon Wilkinsons patch applied,
+support specifiying that credential to use.  The example below will
+login to the host computer.kth.se using lha@@KTH.SE (not the current
+default credential).
+
+@example
+$ ssh \
+   -o GSSAPIAuthentication=yes \
+   -o GSSAPIKeyExchange=yes \
+   -o GSSAPIClientIdentity=lha@@KTH.SE \
+   computer.kth.se
+@end example
+
+
+
+@node Cross realm, Transit policy, Credential cache server - KCM, Setting up a realm
+@section Cross realm
+@cindex Cross realm
+
+Suppose you reside in the realm @samp{MY.REALM}, how do you
+authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in
+@samp{MY.REALM} allows you to communicate with Kerberised services in that
+realm. However, the computer in the other realm does not have a secret
+key shared with the Kerberos server in your realm.
+
+It is possible to share keys between two realms that trust each
+other. When a client program, such as @command{telnet} or @command{ssh},
+finds that the other computer is in a different realm, it will try to
+get a ticket granting ticket for that other realm, but from the local
+Kerberos server. With that ticket granting ticket, it will then obtain
+service tickets from the Kerberos server in the other realm.
+
+For a two way trust between @samp{MY.REALM} and @samp{OTHER.REALM}
+add the following principals to each realm. The principals should be
+@samp{krbtgt/OTHER.REALM@@MY.REALM} and
+@samp{krbtgt/MY.REALM@@OTHER.REALM} in @samp{MY.REALM}, and
+@samp{krbtgt/MY.REALM@@OTHER.REALM} and
+@samp{krbtgt/OTHER.REALM@@MY.REALM}in @samp{OTHER.REALM}.
+
+In Kerberos 5 the trust can be configured to be one way. So that
+users from @samp{MY.REALM} can authenticate to services in
+@samp{OTHER.REALM}, but not the opposite. In the example above, the
+@samp{krbtgt/MY.REALM@@OTHER.REALM} then should be removed.
+
+The two principals must have the same key, key version number, and the
+same set of encryption types. Remember to transfer the two keys in a
+safe manner.
+
+@example
+vr$ klist
+Credentials cache: FILE:/tmp/krb5cc_913.console
+        Principal: lha@@E.KTH.SE
+
+  Issued           Expires          Principal
+May  3 13:55:52  May  3 23:55:54  krbtgt/E.KTH.SE@@E.KTH.SE
+
+vr$ telnet -l lha hummel.it.su.se
+Trying 2001:6b0:5:1095:250:fcff:fe24:dbf...
+Connected to hummel.it.su.se.
+Escape character is '^]'.
+Waiting for encryption to be negotiated...
+[ Trying mutual KERBEROS5 (host/hummel.it.su.se@@SU.SE)... ]
+[ Kerberos V5 accepts you as ``lha@@E.KTH.SE'' ]
+Encryption negotiated.
+Last login: Sat May  3 14:11:47 from vr.l.nxs.se
+hummel$ exit
+
+vr$ klist
+Credentials cache: FILE:/tmp/krb5cc_913.console
+        Principal: lha@@E.KTH.SE
+
+  Issued           Expires          Principal
+May  3 13:55:52  May  3 23:55:54  krbtgt/E.KTH.SE@@E.KTH.SE
+May  3 13:55:56  May  3 23:55:54  krbtgt/SU.SE@@E.KTH.SE
+May  3 14:10:54  May  3 23:55:54  host/hummel.it.su.se@@SU.SE
+
+@end example
+
+@node Transit policy, Setting up DNS, Cross realm, Setting up a realm
+@section Transit policy
+@cindex Transit policy
+
+Under some circumstances, you may not wish to set up direct
+cross-realm trust with every realm to which you wish to authenticate
+or from which you wish to accept authentications. Kerberos supports
+multi-hop cross-realm trust where a client principal in realm A
+authenticates to a service in realm C through a realm B with which
+both A and C have cross-realm trust relationships. In this situation,
+A and C need not set up cross-realm principals between each other.
+
+If you want to use cross-realm authentication through an intermediate
+realm, it must be explicitly allowed by either the KDCs for the realm
+to which the client is authenticating (in this case, realm C), or the
+server receiving the request. This is done in @file{krb5.conf} in the
+@code{[capaths]} section.
+
+In addition, the client in realm A need to be configured to know how
+to reach realm C via realm B. This can be done either on the client or
+via KDC configuration in the KDC for realm A.
+
+@subsection Allowing cross-realm transits
+
+When the ticket transits through a realm to another realm, the
+destination realm adds its peer to the "transited-realms" field in the
+ticket. The field is unordered, since there is no way to know if know
+if one of the transited-realms changed the order of the list. For the
+authentication to be accepted by the final destination realm, all of
+the transited realms must be listed as trusted in the @code{[capaths]}
+configuration, either in the KDC for the destination realm or on the
+server receiving the authentication.
+
+The syntax for @code{[capaths]} section is:
+
+@example
+[capaths]
+        CLIENT-REALM = @{
+                SERVER-REALM = PERMITTED-CROSS-REALMS ...
+        @}
+@end example
+
+In the following example, the realm @code{STACKEN.KTH.SE} only has
+direct cross-realm set up with @code{KTH.SE}.  @code{KTH.SE} has
+direct cross-realm set up with @code{STACKEN.KTH.SE} and @code{SU.SE}.
+@code{DSV.SU.SE} only has direct cross-realm set up with @code{SU.SE}.
+The goal is to allow principals in the @code{DSV.SU.SE} or
+@code{SU.SE} realms to authenticate to services in
+@code{STACKEN.KTH.SE}.  This is done with the following
+@code{[capaths]} entry on either the server accepting authentication
+or on the KDC for @code{STACKEN.KTH.SE}.
+
+@example
+[capaths]
+	SU.SE = @{
+                    STACKEN.KTH.SE = KTH.SE
+	@}
+	DSV.SU.SE = @{
+                    STACKEN.KTH.SE = SU.SE KTH.SE
+	@}
+@end example
+
+The first entry allows cross-realm authentication from clients in
+@code{SU.SE} transiting through @code{KTH.SE} to
+@code{STACKEN.KTH.SE}.  The second entry allows cross-realm
+authentication from clients in @code{DSV.SU.SE} transiting through
+both @code{SU.SE} and @code{KTH.SE} to @code{STACKEN.KTH.SE}.
+
+Be careful of which realm goes where; it's easy to put realms in the
+wrong place.  The block is tagged with the client realm (the realm of
+the principal authenticating), and the realm before the equal sign is
+the final destination realm: the realm to which the client is
+authenticating.  After the equal sign go all the realms that the
+client transits through.
+
+The order of the @code{PERMITTED-CROSS-REALMS} is not important when
+doing transit cross realm verification.
+
+@subsection Configuring client cross-realm transits
+
+The @code{[capaths]} section is also used for another purpose: to tell
+clients which realm to transit through to reach a realm with which
+their local realm does not have cross-realm trust.  This can be done
+by either putting a @code{[capaths]} entry in the configuration of the
+client or by putting the entry in the configuration of the KDC for the
+client's local realm.  In the latter case, the KDC will then hand back
+a referral to the client when the client requests a cross-realm ticket
+to the destination realm, telling the client to try to go through an
+intermediate realm.
+
+For client configuration, the order of @code{PERMITTED-CROSS-REALMS}
+is significant, since only the first realm in this section (after the
+equal sign) is used by the client.
+
+For example, again consider the @code{[capaths]} entry above for the
+case of a client in the @code{SU.SE} realm, and assume that the client
+or the @code{SU.SE} KDC has that @code{[capaths]} entry.  If the
+client attempts to authenticate to a service in the
+@code{STACKEN.KTH.SE} realm, that entry says to first authenticate
+cross-realm to the @code{KTH.SE} realm (the first realm listed in the
+@code{PERMITTED-CROSS-REALMS} section), and then from there to
+@code{STACKEN.KTH.SE}.
+
+Each entry in @code{[capaths]} can only give the next hop, since only
+the first realm in @code{PERMITTED-CROSS-REALMS} is used.  If, for
+instance, a client in @code{DSV.SU.SE} had a @code{[capaths]}
+configuration as above but without the first block for @code{SU.SE},
+they would not be able to reach @code{STACKEN.KTH.SE}.  They would get
+as far as @code{SU.SE} based on the @code{DSV.SU.SE} entry in
+@code{[capaths]} and then attempt to go directly from there to
+@code{STACKEN.KTH.SE} and get stuck (unless, of course, the
+@code{SU.SE} KDC had the additional entry required to tell the client
+to go through @code{KTH.SE}).
+
+@subsection Active Directory forest example
+
+One common place where a @code{[capaths]} configuration is desirable
+is with Windows Active Directory forests.  One common Active Directory
+configuration is to have one top-level Active Directory realm but then
+divide systems, services, and users into child realms (perhaps based
+on organizational unit).  One generally establishes cross-realm trust
+only with the top-level realm, and then uses transit policy to permit
+authentications to and from the child realms.
+
+For example, suppose an organization has a Heimdal realm
+@code{EXAMPLE.COM}, a Windows Active Directory realm
+@code{WIN.EXAMPLE.COM}, and then child Active Directory realms
+@code{ENGR.WIN.EXAMPLE.COM} and @code{SALES.WIN.EXAMPLE.COM}.  The
+goal is to allow users in any of these realms to authenticate to
+services in any of these realms.  The @code{EXAMPLE.COM} KDC (and
+possibly client) configuration should therefore contain a
+@code{[capaths]} section as follows:
+
+@example
+[capaths]
+	ENGR.WIN.EXAMPLE.COM = @{
+		EXAMPLE.COM = WIN.EXAMPLE.COM
+	@}
+	SALES.WIN.EXAMPLE.COM = @{
+		EXAMPLE.COM = WIN.EXAMPLE.COM
+	@}
+	EXAMPLE.COM = @{
+		ENGR.WIN.EXAMPLE.COM = WIN.EXAMPLE.COM
+		SALES.WIN.EXAMPLE.COM = WIN.EXAMPLE.COM
+	@}
+@end example
+
+The first two blocks allow clients in the @code{ENGR.WIN.EXAMPLE.COM}
+and @code{SALES.WIN.EXAMPLE.COM} realms to authenticate to services in
+the @code{EXAMPLE.COM} realm.  The third block tells the client (or
+tells the KDC to tell the client via referrals) to transit through
+@code{WIN.EXAMPLE.COM} to reach these realms.  Both sides of the
+configuration are needed for bi-directional transited cross-realm
+authentication.
+
+@c To test the cross realm configuration, use:
+@c    kmumble transit-check client server transit-realms ...
+
+@node Setting up DNS, Using LDAP to store the database, Transit policy, Setting up a realm
+@section Setting up DNS
+@cindex Setting up DNS
+
+@subsection Using DNS to find KDC
+
+If there is information about where to find the KDC or kadmind for a
+realm in the @file{krb5.conf} for a realm, that information will be
+preferred, and DNS will not be queried.
+
+Heimdal will try to use DNS to find the KDCs for a realm. First it
+will try to find a @code{SRV} resource record (RR) for the realm. If no
+SRV RRs are found, it will fall back to looking for an @code{A} RR for
+a machine named kerberos.REALM, and then kerberos-1.REALM, etc
+
+Adding this information to DNS minimises the client configuration (in
+the common case, resulting in no configuration needed) and allows the
+system administrator to change the number of KDCs and on what machines
+they are running without caring about clients.
+
+The downside of using DNS is that the client might be fooled to use the
+wrong server if someone fakes DNS replies/data, but storing the IP
+addresses of the KDC on all the clients makes it very hard to change
+the infrastructure.
+
+An example of the configuration for the realm @code{EXAMPLE.COM}:
+
+@example
+
+$ORIGIN example.com.
+_kerberos._tcp          SRV     10 1 88 kerberos.example.com.
+_kerberos._udp          SRV     10 1 88 kerberos.example.com.
+_kerberos._tcp          SRV     10 1 88 kerberos-1.example.com.
+_kerberos._udp          SRV     10 1 88 kerberos-1.example.com.
+_kpasswd._udp           SRV     10 1 464 kerberos.example.com.
+_kerberos-adm._tcp	SRV	10 1 749 kerberos.example.com.
+
+@end example
+
+More information about DNS SRV resource records can be found in
+RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).
+
+@subsection Using DNS to map hostname to Kerberos realm
+
+Heimdal also supports a way to lookup a realm from a hostname. This to
+minimise configuration needed on clients. Using this has the drawback
+that clients can be redirected by an attacker to realms within the
+same cross realm trust and made to believe they are talking to the
+right server (since Kerberos authentication will succeed).
+
+An example configuration that informs clients that for the realms
+it.example.com and srv.example.com, they should use the realm
+EXAMPLE.COM:
+
+@example
+
+$ORIGIN example.com.
+_kerberos.it		TXT     "EXAMPLE.COM"
+_kerberos.srv		TXT     "EXAMPLE.COM"
+
+@end example
+
+@node Using LDAP to store the database, Providing Kerberos credentials to servers and programs, Setting up DNS, Setting up a realm
+@section Using LDAP to store the database
+@cindex Using the LDAP backend
+
+This document describes how to install the LDAP backend for
+Heimdal. Note that before attempting to configure such an
+installation, you should be aware of the implications of storing
+private information (such as users' keys) in a directory service
+primarily designed for public information. Nonetheless, with a
+suitable authorisation policy, it is possible to set this up in a
+secure fashion. A knowledge of LDAP, Kerberos, and C is necessary to
+install this backend. The HDB schema was devised by Leif Johansson.
+
+This assumes, OpenLDAP 2.3 or later.
+
+Requirements:
+
+@itemize @bullet
+
+@item
+A current release of Heimdal, configured with
+@code{--with-openldap=/usr/local} (adjust according to where you have
+installed OpenLDAP).
+
+You can verify that you manage to configure LDAP support by running
+@file{kdc --builtin-hdb}, and checking that @samp{ldap:} is one entry
+in the list.
+
+Its also possible to configure the ldap backend as a shared module,
+see option --hdb-openldap-module to configure.
+
+@item
+Optionally configure OpenLDAP with @kbd{--enable-local} to enable the
+local transport.
+
+@item
+Add the hdb schema to the LDAP server, it's included in the source-tree
+in @file{lib/hdb/hdb.schema}. Example from slapd.conf:
+
+@example
+include /usr/local/etc/openldap/schema/hdb.schema
+@end example
+
+@item
+Configure the LDAP server ACLs to accept writes from clients. For
+example:
+
+@example
+access to *
+        by dn.exact="uid=heimdal,dc=services,dc=example,dc=com" write
+        ...
+
+authz-regexp "gidNumber=.*\\\+uidNumber=0,cn=peercred,cn=external,cn=auth''
+	"uid=heimdal,dc=services,dc=example,dc=com"
+
+@end example
+
+The sasl-regexp is for mapping between the SASL/EXTERNAL and a user in
+a tree.  The user that the key is mapped to should be have a
+krb5Principal aux object with krb5PrincipalName set so that the
+``creator'' and ``modifier'' is right in @file{kadmin}.
+
+Another option is to create an admins group and add the dn to that
+group.
+
+If a non-local LDAP connection is used, the authz-regexp is not
+needed as Heimdal will bind to LDAP over the network using
+provided credentials.
+
+Since Heimdal talks to the LDAP server over a UNIX domain socket when
+configured for ldapi:///, and uses external sasl authentication, it's
+not possible to require security layer quality (ssf in cyrus-sasl lingo).
+So that requirement has to be turned off in OpenLDAP @command{slapd}
+configuration file
+@file{slapd.conf}.
+
+@example
+sasl-secprops minssf=0
+@end example
+
+@item
+
+Start @command{slapd} with the local listener (as well as the default TCP/IP
+listener on port 389) as follows:
+
+@example
+    slapd -h "ldapi:/// ldap:///"
+@end example
+
+Note: These is a bug in @command{slapd} where it appears to corrupt the krb5Key
+binary attribute on shutdown. This may be related to our use of the V3
+schema definition syntax instead of the old UMich-style, V2 syntax.
+
+@item
+You should specify the distinguished name under which your
+principals will be stored in @file{krb5.conf}. Also you need to
+enter the path to the kadmin acl file:
+
+
+@example
+[kdc]
+	# Optional configuration
+	hdb-ldap-structural-object = inetOrgPerson
+	hdb-ldap-url = ldapi:/// (default), ldap://hostname or ldaps://hostname
+	hdb-ldap-secret-file = /path/to/file/containing/ldap/credentials
+	hdb-ldap-start-tls = false
+
+        database = @{
+                dbname = ldap:ou=KerberosPrincipals,dc=example,dc=com
+                acl_file = /path/to/kadmind.acl
+                mkey_file = /path/to/mkey
+        @}
+@end example
+
+@samp{mkey_file} can be excluded if you feel that you trust your ldap
+directory to have the raw keys inside it.  The
+hdb-ldap-structural-object is not necessary if you do not need Samba
+comatibility.
+
+If connecting to a server over a non-local transport, the @samp{hdb-ldap-url}
+and @samp{hdb-ldap-secret-file} options must be provided. The
+@samp{hdb-ldap-secret-file} must contain the bind credentials:
+
+@example
+[kdc]
+	hdb-ldap-bind-dn = uid=heimdal,dc=services,dc=example,dc=com
+	hdb-ldap-bind-password = secretBindPassword
+@end example
+
+The @samp{hdb-ldap-secret-file} and should be protected with appropriate
+file permissions
+
+@item
+Once you have built Heimdal and started the LDAP server, run kadmin
+(as usual) to initialise the database. Note that the instructions for
+stashing a master key are as per any Heimdal installation.
+
+@example
+kdc# kadmin -l
+kadmin> init EXAMPLE.COM
+Realm max ticket life [unlimited]:
+Realm max renewable ticket life [unlimited]:
+kadmin> add lukeh
+Max ticket life [1 day]:
+Max renewable life [1 week]:
+Principal expiration time [never]:
+Password expiration time [never]:
+Attributes []:
+lukeh@@EXAMPLE.COM's Password:
+Verifying password - lukeh@@EXAMPLE.COM's Password:
+kadmin> exit
+@end example
+
+Verify that the principal database has indeed been stored in the
+directory with the following command:
+
+@example
+kdc# ldapsearch -L -h localhost -D cn=manager \
+ -w secret -b ou=KerberosPrincipals,dc=example,dc=com \
+ 'objectclass=krb5KDCEntry'
+@end example
+
+@item
+Now consider adding indexes to the database to speed up the access, at
+least theses should be added to slapd.conf.
+
+@example
+index	objectClass		eq
+index	cn			eq,sub,pres
+index	uid			eq,sub,pres
+index	displayName		eq,sub,pres
+index	krb5PrincipalName	eq
+@end example
+
+@end itemize
+
+@subsection smbk5pwd overlay
+
+The smbk5pwd overlay, updates the krb5Key and krb5KeyVersionNumber
+appropriately when it receives an LDAP Password change Extended
+Operation:
+
+@url{http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/smbk5pwd/README?hideattic=1&sortbydate=0}
+
+@subsection Troubleshooting guide
+
+@url{https://sec.miljovern.no/bin/view/Info/TroubleshootingGuide}
+
+
+@subsection Using Samba LDAP password database
+@cindex Samba
+
+@c @node Using Samba LDAP password database, Providing Kerberos credentials to servers and programs, Using LDAP to store the database, Setting up a realm
+@c @section Using Samba LDAP password database
+
+The Samba domain and the Kerberos realm can have different names since
+arcfour's string to key functions principal/realm independent.  So now
+will be your first and only chance name your Kerberos realm without
+needing to deal with old configuration files.
+
+First, you should set up Samba and get that working with LDAP backend.
+
+Now you can proceed as in @xref{Using LDAP to store the database}.
+Heimdal will pick up the Samba LDAP entries if they are in the same
+search space as the Kerberos entries.
+
+@node Providing Kerberos credentials to servers and programs, Setting up PK-INIT, Using LDAP to store the database, Setting up a realm
+@section Providing Kerberos credentials to servers and programs
+
+Some services require Kerberos credentials when they start to make
+connections to other services or need to use them when they have started.
+
+The easiest way to get tickets for a service is to store the key in a
+keytab. Both ktutil get and kadmin ext can be used to get a
+keytab. ktutil get is better in that way it changes the key/password
+for the user. This is also the problem with ktutil. If ktutil is used
+for the same service principal on several hosts, they keytab will only
+be useful on the last host. In that case, run the extract command on
+one host and then securely copy the keytab around to all other hosts
+that need it.
+
+@example
+host# ktutil -k /etc/krb5-service.keytab \
+      get -p lha/admin@@EXAMPLE.ORG service-principal@@EXAMPLE.ORG
+lha/admin@@EXAMPLE.ORG's Password:
+@end example
+
+To get a Kerberos credential file for the service, use kinit in the
+@kbd{--keytab} mode. This will not ask for a password but instead fetch the
+key from the keytab.
+
+@example
+service@@host$ kinit --cache=/var/run/service_krb5_cache \
+               --keytab=/etc/krb5-service.keytab \
+       service-principal@@EXAMPLE.ORG
+@end example
+
+Long running services might need credentials longer then the
+expiration time of the tickets. kinit can run in a mode that refreshes
+the tickets before they expire. This is useful for services that write
+into AFS and other distributed file systems using Kerberos. To run the
+long running script, just append the program and arguments (if any)
+after the principal. kinit will stop refreshing credentials and remove
+the credentials when the script-to-start-service exits.
+
+@example
+service@@host$ kinit --cache=/var/run/service_krb5_cache \
+       --keytab=/etc/krb5-service.keytab \
+       service-principal@@EXAMPLE.ORG \
+       script-to-start-service argument1 argument2
+@end example
+
+
+@node Setting up PK-INIT, Debugging Kerberos problems, Providing Kerberos credentials to servers and programs, Setting up a realm
+@section Setting up PK-INIT
+
+PK-INIT leverages an existing PKI (public key infrastructure), using
+certificates to get the initial ticket (usually the krbtgt
+ticket-granting ticket).
+
+To use PK-INIT you must first have a PKI. If you don't have one, it is
+time to create it. You should first read the whole current chapter of
+the document to see the requirements imposed on the CA software.
+
+A mapping between the PKI certificate and what principals that
+certificate is allowed to use must exist. There are several ways to do
+this. The administrator can use a configuration file, store the
+principal in the SubjectAltName extension of the certificate, or store
+the mapping in the principals entry in the kerberos database.
+
+@section Certificates
+
+This and following subsection documents the requirements on the KDC
+and client certificates and the format used in the id-pkinit-san
+OtherName extension.
+
+On how to create certificates, you should read @ref{Use OpenSSL to
+create certificates}.
+
+@subsection KDC certificate
+
+The certificate for the KDC has several requirements.
+
+First, the certificate should have an Extended Key Usage (EKU)
+id-pkkdcekuoid (1.3.6.1.5.2.3.5) set. Second, there must be a
+subjectAltName otherName using OID id-pkinit-san (1.3.6.1.5.2.2) in
+the type field and a DER encoded KRB5PrincipalName that matches the
+name of the TGS of the target realm.  Also, if the certificate has a
+nameConstraints extension with a Generalname with dNSName or iPAdress,
+it must match the hostname or adress of the KDC.
+
+The client is not required by the standard to check the server
+certificate for this information if the client has external
+information confirming which certificate the KDC is supposed to be
+using. However, adding this information to the KDC certificate removes
+the need to specially configure the client to recognize the KDC
+certificate.
+
+Remember that if the client would accept any certificate as the KDC's
+certificate, the client could be fooled into trusting something that
+isn't a KDC and thus expose the user to giving away information (like
+a password or other private information) that it is supposed to keep
+secret.
+
+@subsection Client certificate
+
+The client certificate may need to have a EKU id-pkekuoid
+(1.3.6.1.5.2.3.4) set depending on the configuration on the KDC.
+
+It possible to store the principal (if allowed by the KDC) in the
+certificate and thus delegate responsibility to do the mapping between
+certificates and principals to the CA.
+
+This behavior is controlled by KDC configuration option:
+
+@example
+[kdc]
+	pkinit_principal_in_certificate = yes
+@end example
+
+@subsubsection Using KRB5PrincipalName in id-pkinit-san
+
+The OtherName extension in the GeneralName is used to do the mapping
+between certificate and principal.  For the KDC certificate, this
+stores the krbtgt principal name for that KDC.  For the client
+certificate, this stores the principal for which that certificate is
+allowed to get tickets.
+
+The principal is stored in a SubjectAltName in the certificate using
+OtherName. The OID in the type is id-pkinit-san.
+
+@example
+id-pkinit-san OBJECT IDENTIFIER ::= @{ iso (1) org (3) dod (6)
+internet (1) security (5) kerberosv5 (2) 2 @}
+@end example
+
+The data part of the OtherName is filled with the following DER
+encoded ASN.1 structure:
+
+@example
+KRB5PrincipalName ::= SEQUENCE @{
+	realm [0] Realm,
+	principalName [1] PrincipalName
+@}
+@end example
+
+where Realm and PrincipalName is defined by the Kerberos ASN.1
+specification.
+
+@section Naming certificate using hx509
+
+hx509 is the X.509 software used in Heimdal to handle
+certificates. hx509 supports several different syntaxes for specifying
+certificate files or formats. Several formats may be used:  PEM,
+certificates embedded in PKCS#12 files, certificates embedded in
+PKCS#11 devices, and raw DER encoded certificates.
+
+Those formats may be specified as follows:
+
+@table @asis
+
+@item DIR:
+
+DIR specifies a directory which contains certificates in the DER or
+PEM format.
+
+The main feature of DIR is that the directory is read on demand when
+iterating over certificates. This allows applications, in some
+situations, to avoid having to store all certificates in memory.  It's
+very useful for tests that iterate over large numbers of certificates.
+
+The syntax is:
+
+@example
+DIR:/path/to/der/files
+@end example
+
+@item FILE:
+
+FILE: specifies a file that contains a certificate or private key.
+The file can be either a PEM (openssl) file or a raw DER encoded
+certificate. If it's a PEM file, it can contain several keys and
+certificates and the code will try to match the private key and
+certificate together. Multiple files may be specified, separated by
+commas.
+
+It's useful to have one PEM file that contains all the trust anchors.
+
+The syntax is:
+
+@example
+FILE:certificate.pem,private-key.key,other-cert.pem,....
+@end example
+
+@item PKCS11:
+
+PKCS11: is used to handle smartcards via PKCS#11 drivers, such as
+soft-token, opensc, or muscle. The argument specifies a shared object
+that implements the PKCS#11 API. The default is to use all slots on
+the device/token.
+
+The syntax is:
+
+@example
+PKCS11:shared-object.so
+@end example
+
+@item PKCS12:
+
+PKCS12: is used to handle PKCS#12 files. PKCS#12 files commonly have
+the extension pfx or p12.
+
+The syntax is:
+
+@example
+PKCS12:/path/to/file.pfx
+@end example
+
+@end table
+
+@section Configure the Kerberos software
+
+First configure the client's trust anchors and what parameters to
+verify. See the subsections below for how to do that. Then, you can
+use kinit to get yourself tickets. For example:
+
+@example
+$ kinit -C FILE:$HOME/.certs/lha.crt,$HOME/.certs/lha.key lha@@EXAMPLE.ORG
+Enter your private key passphrase:
+: lha@@nutcracker ; klist
+Credentials cache: FILE:/tmp/krb5cc_19100a
+        Principal: lha@@EXAMPLE.ORG
+
+  Issued           Expires          Principal
+Apr 20 02:08:08  Apr 20 12:08:08  krbtgt/EXAMPLE.ORG@@EXAMPLE.ORG
+@end example
+
+Using PKCS#11 it can look like this instead:
+
+@example
+$ kinit -C PKCS11:/usr/heimdal/lib/hx509.so lha@@EXAMPLE.ORG
+PIN code for SoftToken (slot):
+$ klist
+Credentials cache: API:4
+        Principal: lha@@EXAMPLE.ORG
+
+  Issued           Expires          Principal
+Mar 26 23:40:10  Mar 27 09:40:10  krbtgt/EXAMPLE.ORG@@EXAMPLE.ORG
+@end example
+
+@section Configure the client
+
+@example
+[appdefaults]
+	pkinit_anchors = FILE:/path/to/trust-anchors.pem
+
+[realms]
+        EXAMPLE.COM = @{
+		pkinit_require_eku = true
+		pkinit_require_krbtgt_otherName = true
+		pkinit_win2k = no
+		pkinit_win2k_require_binding = yes
+	@}
+
+@end example
+
+@section Configure the KDC
+
+Configuration options for the KDC.
+
+@table @asis
+@item enable-pkinit = bool
+
+Enable PKINIT for this KDC.
+
+@item pkinit_identity = string
+
+Identity that the KDC will use when talking to clients. Mandatory.
+
+@item pkinit_anchors = string
+
+Trust anchors that the KDC will use when evaluating the trust of the
+client certificate. Mandatory.
+
+@item pkinit_pool = strings ...
+
+Extra certificate the KDC will use when building trust chains if it
+can't find enough certificates in the request from the client.
+
+@item pkinit_allow_proxy_certificate = bool
+
+Allow clients to use proxy certificates. The root certificate
+of the client's End Entity certificate is used for authorisation.
+
+@item pkinit_win2k_require_binding = bool
+
+Require windows clients up be upgrade to not allow cut and paste
+attack on encrypted data, applies to Windows XP and windows 2000
+servers.
+
+@item pkinit_principal_in_certificate = bool
+
+Enable the KDC to use id-pkinit-san to determine to determine the
+mapping between a certificate and principal.
+
+@end table
+
+@example
+[kdc]
+	enable-pkinit = yes
+	pkinit_identity = FILE:/secure/kdc.crt,/secure/kdc.key
+	pkinit_anchors = FILE:/path/to/trust-anchors.pem
+	pkinit_pool = PKCS12:/path/to/useful-intermediate-certs.pfx
+	pkinit_pool = FILE:/path/to/other-useful-intermediate-certs.pem
+	pkinit_allow_proxy_certificate = no
+	pkinit_win2k_require_binding = yes
+	pkinit_principal_in_certificate = no
+@end example
+
+@subsection Using pki-mapping file
+
+Note that the file contents are space sensitive.
+
+@example
+# cat /var/heimdal/pki-mapping
+# comments starts with #
+lha@@EXAMPLE.ORG:C=SE,O=Stockholm universitet,CN=Love,UID=lha
+lha@@EXAMPLE.ORG:CN=Love,UID=lha
+@end example
+
+@subsection Using the Kerberos database
+
+You can also store the subject of the certificate in the principal
+entry in the kerberos database.
+
+@example
+kadmin modify --pkinit-acl="CN=baz,DC=test,DC=h5l,DC=se" user@@REALM
+@end example
+
+@section Use hxtool to create certificates
+
+@subsection Generate certificates
+
+First, you need to generate a CA certificate. This example creates a
+CA certificate that will be valid for 10 years.
+
+You need to change --subject in the command below to something
+appropriate for your site.
+
+@example
+hxtool issue-certificate \
+    --self-signed \
+    --issue-ca \
+    --generate-key=rsa \
+    --subject="CN=CA,DC=test,DC=h5l,DC=se" \
+    --lifetime=10years \
+    --certificate="FILE:ca.pem"
+@end example
+
+The KDC needs to have a certificate, so generate a certificate of the
+type ``pkinit-kdc'' and set the PK-INIT specifial SubjectAltName to the
+name of the krbtgt of the realm.
+
+You need to change --subject and --pk-init-principal in the command
+below to something appropriate for your site.
+
+@example
+hxtool issue-certificate \
+    --ca-certificate=FILE:ca.pem \
+    --generate-key=rsa \
+    --type="pkinit-kdc" \
+    --pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \
+    --subject="uid=kdc,DC=test,DC=h5l,DC=se" \
+    --certificate="FILE:kdc.pem"
+@end example
+
+The users also needs to have certificates. For your first client,
+generate a certificate of type ``pkinit-client''. The client doesn't
+need to have the PK-INIT SubjectAltName set; you can have the Subject
+DN in the ACL file (pki-mapping) instead.
+
+You need to change --subject and --pk-init-principal in the command
+below to something appropriate for your site. You can omit
+--pk-init-principal if you're going to use the ACL file instead.
+
+@example
+hxtool issue-certificate \
+    --ca-certificate=FILE:ca.pem \
+    --generate-key=rsa \
+    --type="pkinit-client" \
+    --pk-init-principal="lha@@TEST.H5L.SE" \
+    --subject="uid=lha,DC=test,DC=h5l,DC=se" \
+    --certificate="FILE:user.pem"
+@end example
+
+@subsection Validate the certificate
+
+hxtool also contains a tool that will validate certificates according
+to rules from the PKIX document. These checks are not complete, but
+they provide a good test of whether you got all of the basic bits
+right in your certificates.
+
+@example
+hxtool validate FILE:user.pem
+@end example
+
+@section Use OpenSSL to create certificates
+@anchor{Use OpenSSL to create certificates}
+
+This section tries to give the CA owners hints how to create
+certificates using OpenSSL (or CA software based on OpenSSL).
+
+@subsection Using OpenSSL to create certificates with krb5PrincipalName
+
+To make OpenSSL create certificates with krb5PrincipalName, use an
+@file{openssl.cnf} as described below. To see a complete example of
+creating client and KDC certificates, see the test-data generation
+script @file{lib/hx509/data/gen-req.sh} in the source-tree. The
+certicates it creates are used to test the PK-INIT functionality in
+@file{tests/kdc/check-kdc.in}.
+
+To use this example you have to use OpenSSL 0.9.8a or later.
+
+@example
+
+[user_certificate]
+subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name
+
+[princ_name]
+realm = EXP:0, GeneralString:MY.REALM
+principal_name = EXP:1, SEQUENCE:principal_seq
+
+[principal_seq]
+name_type = EXP:0, INTEGER:1
+name_string = EXP:1, SEQUENCE:principals
+
+[principals]
+princ1 = GeneralString:userid
+
+@end example
+
+Command usage:
+
+@example
+openssl x509 -extensions user_certificate
+openssl ca -extensions user_certificate
+@end example
+
+
+@c --- ms certificate
+@c
+@c [ new_oids ]
+@c msCertificateTemplateName       = 1.3.6.1.4.1.311.20.2
+@c
+@c
+@c [ req_smartcard ]
+@c keyUsage                = digitalSignature, keyEncipherment
+@c extendedKeyUsage        = msSmartcardLogin, clientAuth
+@c msCertificateTemplateName       = ASN1:BMP:SmartcardLogon
+@c subjectAltName          = otherName:msUPN;UTF8:lukeh@dsg.padl.com
+@c #subjectAltName         = email:copy
+
+
+@section Using PK-INIT with Windows
+
+@subsection Client configration
+
+Clients using a Windows KDC with PK-INIT need configuration since
+windows uses pre-standard format and this can't be autodetected.
+
+The pkinit_win2k_require_binding option requires the reply for the KDC
+to be of the new, secure, type that binds the request to
+reply. Before, clients could fake the reply from the KDC. To use this
+option you have to apply a fix from Microsoft.
+
+@example
+[realms]
+        MY.MS.REALM = @{
+                pkinit_win2k = yes
+                pkinit_win2k_require_binding = no
+	@}
+@end example
+
+@subsection Certificates
+
+The client certificates need to have the extended keyusage ``Microsoft
+Smartcardlogin'' (openssl has the OID shortname msSmartcardLogin).
+
+See Microsoft Knowledge Base Article - 281245 ``Guidelines for Enabling
+Smart Card Logon with Third-Party Certification Authorities'' for a
+more extensive description of how set setup an external CA so that it
+includes all the information required to make a Windows KDC happy.
+
+@subsection Configure Windows 2000 CA
+
+To enable Microsoft Smartcardlogin for certificates in your Windows
+2000 CA, you want to look at Microsoft Knowledge Base Article - 313274
+``HOW TO: Configure a Certification Authority to Issue Smart Card
+Certificates in Windows''.
+
+@node Debugging Kerberos problems, , Setting up PK-INIT, Setting up a realm
+@section Debugging Kerberos problems
+
+To debug Kerberos client and server problems you can enable debug
+tracing by adding the following to @file{/etc/krb5.conf}. Note that the
+trace logging is sparse at the moment, but will continue to improve.
+
+@example
+[logging]
+        libkrb5 = 0-/SYSLOG:
+@end example
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-kerberos-http-00.txt b/third_party/heimdal/doc/standardisation/draft-brezak-kerberos-http-00.txt
new file mode 100644
index 00000000000..0b8dcd73010
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-kerberos-http-00.txt
@@ -0,0 +1,347 @@
+
+                                                               J.Brezak 
+Internet Draft                                                Microsoft 
+Document: draft-brezak-kerberos-http-00.txt                             
+Category: Informational                                November 17,2003 
+                                                   Expires: May 17,2003 
+ 
+ 
+              HTTP Authentication: Kerberos Authentication 
+                 As implemented in Microsoft Windows 2000 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is subject to all provisions  
+   of Section 10 of RFC2026 [1] except that the right to create 
+   derivative works is not granted. 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 describes how the Microsoft Internet Explorer (MSIE) 
+   and Internet Information Services (IIS) incorporated in Microsoft 
+   Windows 2000 use Kerberos for security enhancements of web 
+   transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of 
+   "negotiate" is defined here; when the negotiation results in the 
+   selection of Kerberos, the security services of authentication and 
+   optionally impersonation are performed. 
+    
+   This document explains how HTTP authentication utilizes the Simple 
+   and Protected GSS-API Negotiation mechanism. Details of SPNEGO 
+   implementation are not provided in this document. 
+    
+    
+2. Conventions used in this document 
+    
+   In examples, "C:" and "S:" indicate lines sent by the client and 
+   server respectively. 
+    
+   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 [1]. 
+    
+  
+Brezak                 Category - Informational                      1 
+                 HTTP Kerberos Access Authentication    November 2003 
+
+3. Introduction 
+   Microsoft has provided support for Kerberos authentication in MSIE 
+   and IIS in addition to other mechanisms. This provides the benefits 
+   of the Kerberos v5 protocol for Web applications.  
+   Support for Kerberos authentication is based on other previously 
+   defined mechanisms such as SPNEGO and the Generic Security Services 
+   Application Program Interface(GSSAPI).  
+    
+3. Access Authentication 
+    
+3.1 Reliance on the HTTP/1.1 Specification 
+ 
+   This specification is a companion to the HTTP/1.1 specification [1] 
+   and builds on the authentication mechanisms defined in [2]. It uses 
+   the augmented BNF section 2.1 of that document, and relies on both 
+   the non-terminals defined in that document and other aspects of the 
+   HTTP/1.1 specification. 
+    
+    
+4. HTTP Negotiate Authentication Scheme 
+    
+   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
+   The auth-params exchanged use data formats defined for use with the 
+   GSS-API [3].  In particular, they follow the formats set for the 
+   SPNEGO [4] and Kerberos [5] mechanisms for GSSAPI.  The "Negotiate" 
+   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
+   specific mechanism type specifies. 
+    
+   The current implementation of this protocol is limited to the use of 
+   SPNEGO with the Kerberos and Microsoft(NT Lan Manager) NTLM 
+   protocols. 
+    
+4.1 The WWW-Authenticate Response Header 
+    
+   If the server receives a request for an access-protected object, and 
+   an acceptable Authorization header has not been sent, the server 
+   responds with a "401 Unauthorized" status code, and a "WWW-
+   Authenticate:" header as per the framework described in [1]. The 
+   initial WWW-Authenticate header will not carry any gssapi-data. 
+    
+   The negotiate scheme will operate as follows: 
+    
+        challenge       = "Negotiate" auth-data 
+        auth-data       = 1#( [gssapi-data] ) 
+         
+   The meanings of the values of the directives used above are as 
+   follows: 
+    
+   gssapi-data 
+        If the gss_accept_security_context return a token for the 
+        client, this directive contains the base64 encoding of an 
+        InitialContextToken as defined in [3]. This is not present in 
+        the initial response from the server. 
+  
+  
+Brezak                 Category - Informational                      2 
+                 HTTP Kerberos Access Authentication    November 2003 
+
+   A status code 200 status response can also carry a "WWW-
+   Authenticate" response header containing the final leg of an 
+   authentication. In this case, the gssapi-data will be present. 
+   Before using the contents of the response, the gssapi-data should be 
+   processed by gss_init_security_context to determine the state of the 
+   security context. If this function indicates success, the response 
+   can be used by the application. Otherwise an appropriate action 
+   based on the authentication status should be. 
+    
+   For example the authentication could have failed on the final leg if 
+   mutual authentication was requested and the server was not able to 
+   prove its identity. In this case, the returned results are suspect. 
+   It is not always possible to mutually authenticate the server before 
+   the HTTP operation. POST methods are in this category. 
+    
+   When the Kerberos Version 5 GSSAPI mechanism [5] is being used, the 
+   HTTP server will be using a principal name of the form of 
+   "HTTP/<hostname>". 
+    
+4.2 The Authorization Request Header 
+ 
+   Upon receipt of the response containing a "WWW-Authenticate" header 
+   from the server, the client is expected to retry the HTTP request, 
+   passing a HTTP "Authorization" header line. This is defined 
+   according to the framework described in [1] utilized as follows: 
+    
+        credentials             = "Negotiate" auth-data2 
+        auth-data2              = 1#( gssapi-data ) 
+                                 
+   gssapi-data 
+        This directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [3]. 
+    
+   Any returned code other than a success 2xx code represents an 
+   authentication error. If a 401 containing a "WWW-Authenticate" 
+   header with "Negotiate" and gssapi-data is returned from the server, 
+   it is a continuation of the authentication request. 
+    
+   A client may initiate a connection to the server with an 
+   "Authorization" header containing the initial token for the server. 
+   This form will bypass the initial 401 error from the server when the 
+   client knows that the server will accept the Negotiate HTTP 
+   authentication type. 
+    
+5. Negotiate Operation Example 
+    
+   The client requests an access-protected document from server via a 
+   GET method request. The URI of the document is 
+   "http://www.nowhere.org/dir/index.html". 
+    
+        C: GET dir/index.html 
+    
+   The first time the client requests the document, no Authorization 
+   header is sent, so the server responds with: 
+  
+Brezak                 Category - Informational                      3 
+                 HTTP Kerberos Access Authentication    November 2003 
+
+    
+        S: HTTP/1.1 401 Unauthorized 
+        S: WWW-Authenticate: Negotiate 
+         
+   The client will obtain the user credentials using the SPNEGO GSSAPI 
+   mechanism type to identify generate a GSSAPI message to be sent to 
+   the server with a new request, including the following Authorization 
+   header: 
+    
+        C: GET dir/index.html 
+        C: Authorization: Negotiate a87421000492aa874209af8bc028 
+         
+   The server will decode the gssapi-data and pass this to the SPNEGO 
+   GSSAPI mechanism in the gss_accept_security_context function. If the 
+   context is not complete, the server will respond with a 401 status 
+   code with a WWW-Authenticate header containing the gssapi-data. 
+    
+        S: HTTP/1.1 401 Unauthorized 
+        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
+    
+   The client will decode the gssapi-data and pass this into 
+   gss_init_security_context and return the new gssapi-data to the 
+   server. 
+    
+        C: GET dir/index.html 
+        C: Authorization: Negotiate 89a8742aa8729a8b028 
+    
+   This cycle can continue until the security context is complete. 
+    
+   When the return value from the gss_accept_security_context function 
+   indicates that the security context is complete, it may supply final 
+   authentication data to be returned to the client. If the server has 
+   more gssapi data to send to the client to complete the context it is 
+   to be carried in WWW-Authenticate header with the final response 
+   containing the HTTP body. 
+    
+        S: HTTP/1.1 200 Success 
+        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
+         
+   The client will decode the gssapi-data and supply it to 
+   gss_init_security_context using the context for this server. If the 
+   status is successful from the final gss_init_security_context, the 
+   response can be used by the application. 
+ 
+7. Security Considerations 
+ 
+   The SPNEGO HTTP authentication facility is only used to provide 
+   authentication of a user to server. It provides no facilities for 
+   protecting the HTTP headers or data including the Authorization and 
+   WWW-Authenticate headers that are used to implement this mechanism. 
+    
+   This mechanism is not used for HTTP authentication to HTTP proxies. 
+    
+
+  
+Brezak                 Category - Informational                      4 
+                 HTTP Kerberos Access Authentication    November 2003 
+
+   If an HTTP proxy is used between the client and server, it must take 
+   care to not share authenticated connections between different 
+   authenticated clients to the same server. If this is not honored, 
+   then the server can easily lose track of security context 
+   associations. A proxy that correctly honors client to server 
+   authentication integrity will supply the "Proxy-support: Session-
+   Based-Authentication" HTTP header to the client in HTTP responses 
+   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
+   authentication mechanism through a proxy unless the proxy supplies 
+   this header with the "401 Unauthorized" response from the server. 
+    
+   When using the SPNEGO HTTP authentication facility with client 
+   supplied data such as PUT and POST, the authentication should be 
+   complete between the client and server before sending the user data. 
+   The return status from the gss_init_security_context will indicate 
+   with the security context is complete. At this point the data can be 
+   sent to the server. 
+    
+    
+8. References 
+ 
+    
+    
+10. Author's Addresses 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      5 
+                 HTTP Kerberos Access Authentication    November 2003 
+
+    
+Full Copyright Statement 
+ 
+   Copyright (C) The Internet Society (2001).  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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      6 
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-00.txt b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-00.txt
new file mode 100644
index 00000000000..96f157a5f13
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-00.txt
@@ -0,0 +1,395 @@
+
+
+Kerberos working group                                         J.Brezak 
+Internet Draft                                                Microsoft 
+Document: draft-brezak-spnego-http-00.txt                                      
+Category: Informational                                                 
+                                                         September 2001 
+ 
+ 
+           HTTP Authentication: SPNEGO Access Authentication 
+ 
+ 
+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 
+    
+   This document describes how MicrosoftÆs Internet Explorer 5.0 and 
+   Internet Information Services 5.0 use Kerberos for security 
+   enhancements of web transactions. The HTTP auth-scheme of 
+   'negotiate' is defined here; when the negotiation results in the 
+   selection of Kerberos, the security services of authentication and 
+   optionally impersonation are performed. 
+    
+    
+2. Conventions used in this document 
+    
+   In examples, "C:" and "S:" indicate lines sent by the client and 
+   server respectively. 
+    
+   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]. 
+    
+    
+3. Access Authentication 
+    
+3.1 Reliance on the HTTP/1.1 Specification 
+ 
+   This specification is a companion to the HTTP/1.1 specification [4] 
+   and builds on the authentication mechanisms defined in [5]. It uses 
+  
+Brezak                 Category û Informational                      1 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+   the augmented BNF section 2.1 of that document, and relies on both 
+   the non-terminals defined in that document and other aspects of the 
+   HTTP/1.1 specification. 
+    
+    
+4. HTTP Negotiate Authentication Scheme 
+    
+   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
+   The auth-params exchanged use data formats defined for use with the 
+   GSS-API [6].  In particular, they follow the formats set for the 
+   SPNEGO [7] and Kerberos [8] "mechanisms" for GSSAPI.  The 
+   "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens 
+   which the specific mechanism type specifies. 
+    
+4.1 The WWW-Authenticate Response Header 
+    
+   If the server receives a request for an access-protected object, and 
+   an acceptable Authorization header is not sent, the server responds 
+   with a "401 Unauthorized" status code, and a WWW-Authenticate header 
+   as per the framework described in [4]. The negotiate scheme will 
+   operate as follows: 
+    
+    
+        challenge       = "Negotiate" auth-data 
+        auth-data       = 1#( [gssapi-data] ) 
+         
+   The meanings of the values of the directives used above are as 
+   follows: 
+    
+   gssapi-data 
+        If the gss_accept_security_context return a token for the 
+        client, this directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [6]. 
+  
+   A status code 200 response can also carry a WWW-Authenticate 
+   response header containing the final leg of a authentication. Before 
+   using the contents of the response, the gssapi-data should be 
+   processed by gss_init_security_context to determine the state of the 
+   security context. If this function indicates success, the response 
+   can be used by the application. Otherwise an appropriate action 
+   based on the authentication status should be. 
+    
+   For example the authentication could have failed on the final leg if 
+   mutual authentication was requested and the server was not able to 
+   prove its identity. In this case, the returned results are suspect. 
+   It is not always possible to mutually authenticate the server before 
+   the HTTP operation. POST methods are in this category. 
+    
+   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
+   used, the HTTP server will be using a principal name of the form of 
+   "http/<hostname>". 
+    
+4.2 The Authorization Request Header 
+ 
+  
+Brezak                 Category û Informational                      2 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+   The client is expected to retry the request, passing an 
+   Authorization header line, which is defined according to the 
+   framework described in [4] utilized as follow: 
+    
+        credentials             = "Negotiate" auth-data2 
+        auth-data2              = 1#( gssapi-data ) 
+                                 
+   gssapi-data 
+        This directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [6]. 
+    
+   If a directive or its value is improper, or required directives are 
+   missing, the propose response is 400 Bad Request. If a 401 
+   Unauthorized status code is returned, the contents of the WWW-
+   Authenticate response header is used to continue the authentication 
+   as long as the opaque value is the same. 
+    
+5. Negotiate Operation Example 
+    
+   The user is logged onto realm A.COM as user@A.COM. The web server is 
+   in realm B using the principal http/server@B.COM. Realm B.COM trusts 
+   Realm A.COM  
+    
+   The client requests an access-protected document from server via a 
+   GET method request. The URI of the document is 
+   "http://www.nowhere.org/dir/index.html". 
+    
+   The first time the client requests the document, no Authorization 
+   header is sent, so the server responds with: 
+    
+        HTTP/1.1 401 Unauthorized 
+        WWW-Authenticate: Negotiate 
+         
+   The client will obtain the user credentials using the SPNEGO GSSAPI 
+   mechanism type to identify generate a GSSAPI message to be sent to 
+   the server with a new request, including the following Authorization 
+   header: 
+    
+        Authorization: Negotiate 
+        2a87421000492ade0234568ac0289eca874209af8bc028 
+         
+   The server will decode the gssapi-data and pass this to the SPNEGO 
+   GSSAPI mechanism in the gss_accept_security_context function. The 
+   return value from the gss_accept_security_context function can 
+   indicate the security context is complete and supply final 
+   authentication data to be returned to the client. If the server has 
+   more gssapi data to send to the client to complete the context it is 
+   to be carried in WWW-Authenticate header with the final response. 
+   The response will be sent to the client, including the following 
+   header: 
+    
+        HTTP/1.1 200 Success 
+        WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca 
+         
+  
+Brezak                 Category û Informational                      3 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+   The client will decode the gssapi-data and supply it to 
+   gss_init_security_context using the context for this server. If the 
+   status is successful from the final gss_init_security_context, the 
+   response can be used by the application. 
+ 
+7. Security Considerations 
+ 
+   The SPNEGO HTTP authentication facility is only used to provide 
+   authentication of a user to server. It provides no facilities for 
+   protecting the HTTP headers or data including the Authorization and 
+   WWW-Authenticate headers that are used to implement this mechanism. 
+    
+   This mechanism is not used for HTTP authentication to HTTP proxies. 
+    
+   If an HTTP proxy is used between the client and server, it must take 
+   care to not share authenticated connections between different 
+   authenticated clients to the same server. If this is not honored, 
+   then the server can easily lose track of security context 
+   associations. A proxy that correctly honors client to server 
+   authentication integrity will supply the "Proxy-support: Session-
+   Based-Authentication" HTTP header to the client in HTTP responses 
+   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
+   authentication mechanism through a proxy unless the proxy supplies 
+   this header with the 401 Unauthorized response from the server. 
+    
+    
+8. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
+      Leach, P. and T. Berners-Lee,  "Hypertext Transfer Protocol -- 
+      HTTP/1.1", RFC 2616, June 1999. 
+     
+   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
+      P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 
+      Digest Access Authentication", RFC 2617, June 1999. 
+    
+   6 Linn, J., "Generic Security Service Application Program Interface, 
+      Version 2", RFC 2078, January 1997. 
+    
+   7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 
+      Negotiation Mechanism", RFC 2478, December 1998. 
+    
+   8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 
+      June 1996. 
+    
+ 
+    
+  
+Brezak                 Category û Informational                      4 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+    
+10. Author's Addresses 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category û Informational                      5 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+    
+Full Copyright Statement 
+ 
+   Copyright (C) The Internet Society (2001).  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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category û Informational                      6 
+
+
+
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-01.txt b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-01.txt
new file mode 100644
index 00000000000..5d27f9a0c65
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-01.txt
@@ -0,0 +1,190 @@
+
+
+Kerberos working group                                         J.Brezak 
+Internet Draft                                                Microsoft 
+Document: draft-brezak-spnego-http-01.txt                                      
+Category: Informational                                                 
+                                                         September 2001 
+ 
+ 
+           HTTP Authentication: SPNEGO Access Authentication 
+ 
+ 
+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 
+    
+   This document describes how Microsoft's Internet Explorer 5.0 and 
+   Internet Information Services 5.0 use Kerberos for security 
+   enhancements of web transactions. The HTTP auth-scheme of 
+   "negotiate" is defined here; when the negotiation results in the 
+   selection of Kerberos, the security services of authentication and 
+   optionally impersonation are performed. 
+    
+    
+2. Conventions used in this document 
+    
+   In examples, "C:" and "S:" indicate lines sent by the client and 
+   server respectively. 
+    
+   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]. 
+    
+    
+3. Access Authentication 
+    
+3.1 Reliance on the HTTP/1.1 Specification 
+ 
+   This specification is a companion to the HTTP/1.1 specification [4] 
+   and builds on the authentication mechanisms defined in [5]. It uses 
+  
+Brezak                 Category - Informational                      1 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+   the augmented BNF section 2.1 of that document, and relies on both 
+   the non-terminals defined in that document and other aspects of the 
+   HTTP/1.1 specification. 
+    
+    
+4. HTTP Negotiate Authentication Scheme 
+    
+   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
+   The auth-params exchanged use data formats defined for use with the 
+   GSS-API [6].  In particular, they follow the formats set for the 
+   SPNEGO [7] and Kerberos [8] "mechanisms" for GSSAPI.  The 
+   "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens 
+   which the specific mechanism type specifies. 
+    
+4.1 The WWW-Authenticate Response Header 
+    
+   If the server receives a request for an access-protected object, and 
+   an acceptable Authorization header is not sent, the server responds 
+   with a "401 Unauthorized" status code, and a WWW-Authenticate header 
+   as per the framework described in [4]. The negotiate scheme will 
+   operate as follows: 
+    
+    
+        challenge       = "Negotiate" auth-data 
+        auth-data       = 1#( [gssapi-data] ) 
+         
+   The meanings of the values of the directives used above are as 
+   follows: 
+    
+   gssapi-data 
+        If the gss_accept_security_context return a token for the 
+        client, this directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [6]. 
+  
+   A status code 200 response can also carry a WWW-Authenticate 
+   response header containing the final leg of a authentication. Before 
+   using the contents of the response, the gssapi-data should be 
+   processed by gss_init_security_context to determine the state of the 
+   security context. If this function indicates success, the response 
+   can be used by the application. Otherwise an appropriate action 
+   based on the authentication status should be. 
+    
+   For example the authentication could have failed on the final leg if 
+   mutual authentication was requested and the server was not able to 
+   prove its identity. In this case, the returned results are suspect. 
+   It is not always possible to mutually authenticate the server before 
+   the HTTP operation. POST methods are in this category. 
+    
+   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
+   used, the HTTP server will be using a principal name of the form of 
+   "http/<hostname>". 
+    
+4.2 The Authorization Request Header 
+ 
+  
+Brezak                 Category - Informational                      2 
+
+
+
+
+
+
+
+
+                     SPNEGO Access Authentication       September 2001 
+
+   The client is expected to retry the request, passing an 
+   Authorization header line, which is defined according to the 
+   framework described in [4] utilized as follow: 
+    
+        credentials             = "Negotiate" auth-data2 
+        auth-data2              = 1#( gssapi-data ) 
+                                 
+   gssapi-data 
+        This directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [6]. 
+    
+   If a directive or its value is improper, or required directives are 
+   missing, the propose response is 400 Bad Request. If a 401 
+   Unauthorized status code is returned, the contents of the WWW-
+   Authenticate response header is used to continue the authentication 
+   as long as the opaque value is the same. 
+    
+5. Negotiate Operation Example 
+    
+   The user is logged onto realm A.COM as user@A.COM. The web server is 
+   in realm B using the principal http/server@B.COM. Realm B.COM trusts 
+   Realm A.COM  
+    
+   The client requests an access-protected document from server via a 
+   GET method request. The URI of the document is 
+   "http://www.nowhere.org/dir/index.html". 
+    
+   The first time the client requests the document, no Authorization 
+   header is sent, so the server responds with: 
+    
+        HTTP/1.1 401 Unauthorized 
+        WWW-Authenticate: Negotiate 
+         
+   The client will obtain the user credentials using the SPNEGO GSSAPI 
+   mechanism type to identify generate a GSSAPI message to be sent to 
+   the server with a new request, including the following Authorization 
+   header: 
+    
+        Authorization: Negotiate 
+        2a87421000492ade0234568ac0289eca874209af8bc028 
+         
+   The server will decode the gssapi-data and pass this to the SPNEGO 
+   GSSAPI mechanism in the gss_accept_security_context function. The 
+   return value from the gss_accept_security_context function can 
+   indicate the security context is complete and supply final 
+   authentication data to be returned to the client. If the server has 
+   more gssapi data to send to the client to complete the context it is 
+   to be carried in WWW-Authenticate header with the final response. 
+   The response will be sent to the client, including the following 
+   header: 
+    
+        HTTP/1.1 200 Success 
+        WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca 
+         
+  
+Brezak                 Category - Informational                     
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-02.txt b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-02.txt
new file mode 100644
index 00000000000..3eb8d7fce83
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-02.txt
@@ -0,0 +1,395 @@
+
+
+Kerberos working group                                         J.Brezak 
+Internet Draft                                                Microsoft 
+Document: draft-brezak-spnego-http-02.txt                               
+Category: Informational                                                 
+                                                          November 2001 
+ 
+ 
+           HTTP Authentication: SPNEGO Access Authentication 
+ 
+ 
+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 
+    
+   This document describes how Microsoft's Internet Explorer (MSIE) and 
+   Internet Information Services (IIS) incorporated in Windows 2000 use 
+   Kerberos for security enhancements of web transactions. The HTTP 
+   auth-scheme of "negotiate" is defined here; when the negotiation 
+   results in the selection of Kerberos, the security services of 
+   authentication and optionally impersonation are performed. 
+    
+   This document explains how HTTP authentication utilizes the SPNEGO 
+   [7] GSSAPI mechanism. Details of SPNEGO implementation are not 
+   provided in this document. 
+    
+    
+2. Conventions used in this document 
+    
+   In examples, "C:" and "S:" indicate lines sent by the client and 
+   server respectively. 
+    
+   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]. 
+    
+    
+3. Access Authentication 
+    
+  
+Brezak                 Category - Informational                      1 
+
+
+
+
+
+
+
+
+                  HTTP SPNEGO Access Authentication     November 2001 
+
+3.1 Reliance on the HTTP/1.1 Specification 
+ 
+   This specification is a companion to the HTTP/1.1 specification [4] 
+   and builds on the authentication mechanisms defined in [5]. It uses 
+   the augmented BNF section 2.1 of that document, and relies on both 
+   the non-terminals defined in that document and other aspects of the 
+   HTTP/1.1 specification. 
+    
+    
+4. HTTP Negotiate Authentication Scheme 
+    
+   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
+   The auth-params exchanged use data formats defined for use with the 
+   GSS-API [6].  In particular, they follow the formats set for the 
+   SPNEGO [7] and Kerberos [8] mechanisms for GSSAPI.  The "Negotiate" 
+   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
+   specific mechanism type specifies. 
+    
+   The current implementation of this protocol is limited to the use of 
+   SPNEGO with the Kerberos and Microsoft NTLM protocols. 
+    
+4.1 The WWW-Authenticate Response Header 
+    
+   If the server receives a request for an access-protected object, and 
+   an acceptable Authorization header has not been sent, the server 
+   responds with a "401 Unauthorized" status code, and a "WWW-
+   Authenticate:" header as per the framework described in [4]. The 
+   initial WWW-Authenticate header will not carry any gssapi-data. 
+    
+   The negotiate scheme will operate as follows: 
+    
+        challenge       = "Negotiate" auth-data 
+        auth-data       = 1#( [gssapi-data] ) 
+         
+   The meanings of the values of the directives used above are as 
+   follows: 
+    
+   gssapi-data 
+        If the gss_accept_security_context return a token for the 
+        client, this directive contains the base64 encoding of an 
+        InitialContextToken as defined in [6]. This is not present in 
+        the initial response from the server. 
+  
+   A status code 200 status response can also carry a "WWW-
+   Authenticate" response header containing the final leg of an 
+   authentication. In this case, the gssapi-data will be present. 
+   Before using the contents of the response, the gssapi-data should be 
+   processed by gss_init_security_context to determine the state of the 
+   security context. If this function indicates success, the response 
+   can be used by the application. Otherwise an appropriate action 
+   based on the authentication status should be. 
+    
+   For example the authentication could have failed on the final leg if 
+   mutual authentication was requested and the server was not able to 
+  
+Brezak                 Category - Informational                      2 
+
+
+
+
+
+
+
+
+                  HTTP SPNEGO Access Authentication     November 2001 
+
+   prove its identity. In this case, the returned results are suspect. 
+   It is not always possible to mutually authenticate the server before 
+   the HTTP operation. POST methods are in this category. 
+    
+   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
+   used, the HTTP server will be using a principal name of the form of 
+   "http/<hostname>". 
+    
+4.2 The Authorization Request Header 
+ 
+   Upon receipt of the response containing a "WWW-Authenticate" header 
+   from the server, the client is expected to retry the HTTP request, 
+   passing a HTTP "Authorization" header line. This is defined 
+   according to the framework described in [4] utilized as follows: 
+    
+        credentials             = "Negotiate" auth-data2 
+        auth-data2              = 1#( gssapi-data ) 
+                                 
+   gssapi-data 
+        This directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [6]. 
+    
+   Any returned code other than a success 2xx code represents an 
+   authentication error. If a 401 containing a "WWW-Authenticate" 
+   header with "Negotiate" and gssapi-data is returned from the server, 
+   it is a continuation of the authentication request. 
+    
+   A client may initiate a connection to the server with an 
+   "Authorization" header containing the initial token for the server. 
+   This form will bypass the initial 401 error from the server when the 
+   client knows that the server will accept the Negotiate HTTP 
+   authentication type. 
+    
+5. Negotiate Operation Example 
+    
+   The client requests an access-protected document from server via a 
+   GET method request. The URI of the document is 
+   "http://www.nowhere.org/dir/index.html". 
+    
+        C: GET dir/index.html 
+    
+   The first time the client requests the document, no Authorization 
+   header is sent, so the server responds with: 
+    
+        S: HTTP/1.1 401 Unauthorized 
+        S: WWW-Authenticate: Negotiate 
+         
+   The client will obtain the user credentials using the SPNEGO GSSAPI 
+   mechanism type to identify generate a GSSAPI message to be sent to 
+   the server with a new request, including the following Authorization 
+   header: 
+    
+        C: GET dir/index.html 
+        C: Authorization: Negotiate a87421000492aa874209af8bc028 
+  
+Brezak                 Category - Informational                      3 
+
+
+
+
+
+
+
+
+                  HTTP SPNEGO Access Authentication     November 2001 
+
+         
+   The server will decode the gssapi-data and pass this to the SPNEGO 
+   GSSAPI mechanism in the gss_accept_security_context function. If the 
+   context is not complete, the server will respond with a 401 status 
+   code with a WWW-Authenticate header containing the gssapi-data. 
+    
+        S: HTTP/1.1 401 Unauthorized 
+        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
+    
+   The client will decode the gssapi-data and pass this into 
+   gss_init_security_context and return the new gssapi-data to the 
+   server. 
+    
+        C: GET dir/index.html 
+        C: Authorization: Negotiate 89a8742aa8729a8b028 
+    
+   This cycle can continue until the security context is complete. 
+    
+   When the return value from the gss_accept_security_context function 
+   indicates that the security context is complete, it may supply final 
+   authentication data to be returned to the client. If the server has 
+   more gssapi data to send to the client to complete the context it is 
+   to be carried in WWW-Authenticate header with the final response 
+   containing the HTTP body. 
+    
+        S: HTTP/1.1 200 Success 
+        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
+         
+   The client will decode the gssapi-data and supply it to 
+   gss_init_security_context using the context for this server. If the 
+   status is successful from the final gss_init_security_context, the 
+   response can be used by the application. 
+ 
+7. Security Considerations 
+ 
+   The SPNEGO HTTP authentication facility is only used to provide 
+   authentication of a user to server. It provides no facilities for 
+   protecting the HTTP headers or data including the Authorization and 
+   WWW-Authenticate headers that are used to implement this mechanism. 
+    
+   This mechanism is not used for HTTP authentication to HTTP proxies. 
+    
+   If an HTTP proxy is used between the client and server, it must take 
+   care to not share authenticated connections between different 
+   authenticated clients to the same server. If this is not honored, 
+   then the server can easily lose track of security context 
+   associations. A proxy that correctly honors client to server 
+   authentication integrity will supply the "Proxy-support: Session-
+   Based-Authentication" HTTP header to the client in HTTP responses 
+   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
+   authentication mechanism through a proxy unless the proxy supplies 
+   this header with the "401 Unauthorized" response from the server. 
+    
+
+  
+Brezak                 Category - Informational                      4 
+
+
+
+
+
+
+
+
+                  HTTP SPNEGO Access Authentication     November 2001 
+
+   When using the SPNEGO HTTP authentication facility with client 
+   supplied data such as PUT and POST, the authentication should be 
+   complete between the client and server before sending the user data. 
+   The return status from the gss_init_security_context will indicate 
+   with the security context is complete. At this point the data can be 
+   sent to the server. 
+    
+    
+8. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
+      Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 
+      HTTP/1.1", RFC 2616, June 1999. 
+     
+   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
+      P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 
+      Digest Access Authentication", RFC 2617, June 1999. 
+    
+   6 Linn, J., "Generic Security Service Application Program Interface, 
+      Version 2", RFC 2078, January 1997. 
+    
+   7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 
+      Negotiation Mechanism", RFC 2478, December 1998. 
+    
+   8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 
+      June 1996. 
+    
+ 
+    
+    
+10. Author's Addresses 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      5 
+
+
+
+
+
+
+
+
+                  HTTP SPNEGO Access Authentication     November 2001 
+
+    
+Full Copyright Statement 
+ 
+   Copyright (C) The Internet Society (2001).  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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      6 
+
+
+
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-04.txt b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-04.txt
new file mode 100644
index 00000000000..9f75bbbf442
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-spnego-http-04.txt
@@ -0,0 +1,349 @@
+
+
+
+Kerberos working group                                         J.Brezak 
+Internet Draft                                                Microsoft 
+Document: draft-brezak-spnego-http-04.txt                               
+Category: Informational                                                 
+                                                           October 2002 
+ 
+ 
+           HTTP Authentication: SPNEGO Access Authentication 
+                 As implemented in Microsoft Windows 2000 
+ 
+ 
+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 
+    
+   This document describes how the Microsoft Internet Explorer (MSIE) 
+   and Internet Information Services (IIS) incorporated in Microsoft 
+   Windows 2000 use Kerberos for security enhancements of web 
+   transactions. The HTTP auth-scheme of "negotiate" is defined here; 
+   when the negotiation results in the selection of Kerberos, the 
+   security services of authentication and optionally impersonation are 
+   performed. 
+    
+   This document explains how HTTP authentication utilizes the SPNEGO 
+   [7] GSSAPI mechanism. Details of SPNEGO implementation are not 
+   provided in this document. 
+    
+    
+2. Conventions used in this document 
+    
+   In examples, "C:" and "S:" indicate lines sent by the client and 
+   server respectively. 
+    
+   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]. 
+    
+    
+  
+Brezak                 Category - Informational                      1 
+                  HTTP SPNEGO Access Authentication      October 2002 
+
+3. Access Authentication 
+    
+3.1 Reliance on the HTTP/1.1 Specification 
+ 
+   This specification is a companion to the HTTP/1.1 specification [4] 
+   and builds on the authentication mechanisms defined in [5]. It uses 
+   the augmented BNF section 2.1 of that document, and relies on both 
+   the non-terminals defined in that document and other aspects of the 
+   HTTP/1.1 specification. 
+    
+    
+4. HTTP Negotiate Authentication Scheme 
+    
+   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
+   The auth-params exchanged use data formats defined for use with the 
+   GSS-API [6].  In particular, they follow the formats set for the 
+   SPNEGO [7] and Kerberos [8] mechanisms for GSSAPI.  The "Negotiate" 
+   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
+   specific mechanism type specifies. 
+    
+   The current implementation of this protocol is limited to the use of 
+   SPNEGO with the Kerberos and Microsoft NTLM protocols. 
+    
+4.1 The WWW-Authenticate Response Header 
+    
+   If the server receives a request for an access-protected object, and 
+   an acceptable Authorization header has not been sent, the server 
+   responds with a "401 Unauthorized" status code, and a "WWW-
+   Authenticate:" header as per the framework described in [4]. The 
+   initial WWW-Authenticate header will not carry any gssapi-data. 
+    
+   The negotiate scheme will operate as follows: 
+    
+        challenge       = "Negotiate" auth-data 
+        auth-data       = 1#( [gssapi-data] ) 
+         
+   The meanings of the values of the directives used above are as 
+   follows: 
+    
+   gssapi-data 
+        If the gss_accept_security_context return a token for the 
+        client, this directive contains the base64 encoding of an 
+        InitialContextToken as defined in [6]. This is not present in 
+        the initial response from the server. 
+  
+   A status code 200 status response can also carry a "WWW-
+   Authenticate" response header containing the final leg of an 
+   authentication. In this case, the gssapi-data will be present. 
+   Before using the contents of the response, the gssapi-data should be 
+   processed by gss_init_security_context to determine the state of the 
+   security context. If this function indicates success, the response 
+   can be used by the application. Otherwise an appropriate action 
+   based on the authentication status should be. 
+    
+  
+Brezak                 Category - Informational                      2 
+                  HTTP SPNEGO Access Authentication      October 2002 
+
+   For example the authentication could have failed on the final leg if 
+   mutual authentication was requested and the server was not able to 
+   prove its identity. In this case, the returned results are suspect. 
+   It is not always possible to mutually authenticate the server before 
+   the HTTP operation. POST methods are in this category. 
+    
+   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
+   used, the HTTP server will be using a principal name of the form of 
+   "HTTP/<hostname>". 
+    
+4.2 The Authorization Request Header 
+ 
+   Upon receipt of the response containing a "WWW-Authenticate" header 
+   from the server, the client is expected to retry the HTTP request, 
+   passing a HTTP "Authorization" header line. This is defined 
+   according to the framework described in [4] utilized as follows: 
+    
+        credentials             = "Negotiate" auth-data2 
+        auth-data2              = 1#( gssapi-data ) 
+                                 
+   gssapi-data 
+        This directive contains is the base64 encoding of an 
+        InitialContextToken as defined in [6]. 
+    
+   Any returned code other than a success 2xx code represents an 
+   authentication error. If a 401 containing a "WWW-Authenticate" 
+   header with "Negotiate" and gssapi-data is returned from the server, 
+   it is a continuation of the authentication request. 
+    
+   A client may initiate a connection to the server with an 
+   "Authorization" header containing the initial token for the server. 
+   This form will bypass the initial 401 error from the server when the 
+   client knows that the server will accept the Negotiate HTTP 
+   authentication type. 
+    
+5. Negotiate Operation Example 
+    
+   The client requests an access-protected document from server via a 
+   GET method request. The URI of the document is 
+   "http://www.nowhere.org/dir/index.html". 
+    
+        C: GET dir/index.html 
+    
+   The first time the client requests the document, no Authorization 
+   header is sent, so the server responds with: 
+    
+        S: HTTP/1.1 401 Unauthorized 
+        S: WWW-Authenticate: Negotiate 
+         
+   The client will obtain the user credentials using the SPNEGO GSSAPI 
+   mechanism type to identify generate a GSSAPI message to be sent to 
+   the server with a new request, including the following Authorization 
+   header: 
+    
+  
+Brezak                 Category - Informational                      3 
+                  HTTP SPNEGO Access Authentication      October 2002 
+
+        C: GET dir/index.html 
+        C: Authorization: Negotiate a87421000492aa874209af8bc028 
+         
+   The server will decode the gssapi-data and pass this to the SPNEGO 
+   GSSAPI mechanism in the gss_accept_security_context function. If the 
+   context is not complete, the server will respond with a 401 status 
+   code with a WWW-Authenticate header containing the gssapi-data. 
+    
+        S: HTTP/1.1 401 Unauthorized 
+        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
+    
+   The client will decode the gssapi-data and pass this into 
+   gss_init_security_context and return the new gssapi-data to the 
+   server. 
+    
+        C: GET dir/index.html 
+        C: Authorization: Negotiate 89a8742aa8729a8b028 
+    
+   This cycle can continue until the security context is complete. 
+    
+   When the return value from the gss_accept_security_context function 
+   indicates that the security context is complete, it may supply final 
+   authentication data to be returned to the client. If the server has 
+   more gssapi data to send to the client to complete the context it is 
+   to be carried in WWW-Authenticate header with the final response 
+   containing the HTTP body. 
+    
+        S: HTTP/1.1 200 Success 
+        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
+         
+   The client will decode the gssapi-data and supply it to 
+   gss_init_security_context using the context for this server. If the 
+   status is successful from the final gss_init_security_context, the 
+   response can be used by the application. 
+ 
+7. Security Considerations 
+ 
+   The SPNEGO HTTP authentication facility is only used to provide 
+   authentication of a user to server. It provides no facilities for 
+   protecting the HTTP headers or data including the Authorization and 
+   WWW-Authenticate headers that are used to implement this mechanism. 
+    
+   This mechanism is not used for HTTP authentication to HTTP proxies. 
+    
+   If an HTTP proxy is used between the client and server, it must take 
+   care to not share authenticated connections between different 
+   authenticated clients to the same server. If this is not honored, 
+   then the server can easily lose track of security context 
+   associations. A proxy that correctly honors client to server 
+   authentication integrity will supply the "Proxy-support: Session-
+   Based-Authentication" HTTP header to the client in HTTP responses 
+   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
+   authentication mechanism through a proxy unless the proxy supplies 
+   this header with the "401 Unauthorized" response from the server. 
+  
+Brezak                 Category - Informational                      4 
+                  HTTP SPNEGO Access Authentication      October 2002 
+
+    
+   When using the SPNEGO HTTP authentication facility with client 
+   supplied data such as PUT and POST, the authentication should be 
+   complete between the client and server before sending the user data. 
+   The return status from the gss_init_security_context will indicate 
+   with the security context is complete. At this point the data can be 
+   sent to the server. 
+    
+    
+8. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
+      Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 
+      HTTP/1.1", RFC 2616, June 1999. 
+     
+   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
+      P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 
+      Digest Access Authentication", RFC 2617, June 1999. 
+    
+   6 Linn, J., "Generic Security Service Application Program Interface, 
+      Version 2", RFC 2078, January 1997. 
+    
+   7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 
+      Negotiation Mechanism", RFC 2478, December 1998. 
+    
+   8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 
+      June 1996. 
+    
+ 
+    
+    
+10. Author's Addresses 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      5 
+                  HTTP SPNEGO Access Authentication      October 2002 
+
+    
+Full Copyright Statement 
+ 
+   Copyright (C) The Internet Society (2001).  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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      6 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt
new file mode 100644
index 00000000000..17277611892
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt
@@ -0,0 +1,523 @@
+
+
+
+Kerberos working group                                      John Brezak 
+Internet Draft                                                Microsoft 
+Document: draft-brezak-win2k-krb-authz-01.txt                           
+Category: Informational                                   October, 2002 
+ 
+ 
+ Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for 
+                      Access Control to Resources 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is subject to all provisions  
+   of Section 10 of RFC2026 [1] except that the right to create 
+   derivative works is not granted. 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 
+    
+   Microsoft Windows 2000 includes operating system specific data in 
+   the Kerberos V5 [1] authorization data field that is used for access 
+   control. This data is used to create an NT access token. The access 
+   token is used by the system to enforce access checking when 
+   attempting to access objects. This document describes the structure 
+   of the Windows 2000 specific authorization data that is carried in 
+   that field for use by servers in performing access control. 
+    
+    
+2. Conventions used in this document 
+    
+   All defined data structures are defined using "C" style constructs 
+   unless otherwise stated. All data is encoded as little-endian. 
+    
+   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. Top-Level PAC Structure 
+    
+   The PAC is generated by the KDC under the following conditions: 
+
+  
+Brezak                 Category - Informational                      1 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+     o during an AS request that has been validated with pre-
+        authentication 
+     o during a TGS request when the client has no PAC and the target 
+        is a service in the domain or a ticket granting service 
+        (referral ticket). 
+    
+   The PAC itself is included in the IF-RELEVANT (ID 1) portion of the 
+   authorization data in a ticket. Within the IF-RELEVANT portion, it 
+   is encoded KERB_AUTH_DATA_PAC with ID 128. 
+    
+   The PAC is defined as a C data type, with integers encoded in 
+   little-endian order. The PAC itself is made up of several layers. 
+   The outer structure, contained directly in the authorization data, 
+   is as follows. The top-level structure is the PACTYPE structure: 
+    
+        typedef unsigned long ULONG; 
+        typedef unsigned short USHORT; 
+        typedef unsigned long64 ULONG64; 
+        typedef unsigned char UCHAR; 
+         
+        typedef struct _PACTYPE { 
+            ULONG cBuffers; 
+            ULONG Version;                          
+            PAC_INFO_BUFFER Buffers[1]; 
+        } PACTYPE; 
+    
+   The fields are defined as follows: 
+   cBuffers - contains the number of entries in the array Buffers 
+   Version - this is version zero 
+   Buffers - contains a conformant array of PAC_INFO_BUFFER structures 
+    
+   The PAC_INFO_BUFFER structure contains information about each piece 
+   of the PAC.  
+    
+        typedef struct _PAC_INFO_BUFFER { 
+            ULONG ulType; 
+            ULONG cbBufferSize; 
+            ULONG64 Offset; 
+        } PAC_INFO_BUFFER; 
+    
+   Type fields are defined as follows: 
+    
+   ulType - contains the type of data contained in this buffer. For 
+           Windows 2000 access control, it may be one of the following, 
+           which are explained further below: 
+            
+           #define PAC_LOGON_INFO               1 
+           #define PAC_SERVER_CHECKSUM          6 
+           #define PAC_PRIVSVR_CHECKSUM         7 
+            
+   Offset - contains the offset to the beginning of the data, in bytes, 
+           from the beginning of the PACTYPE structure. The data offset 
+           must by a multiple of 8. If the data pointed to by this 
+  
+Brezak                 Category - Informational                      2 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+           field is complex, the data is typically NDR encoded. If the 
+           data is simple (indicating it includes no pointer types or 
+           complex structures) it is a little-endian format data 
+           structure. 
+    
+4. PAC Credential Information (PAC_LOGON_INFO) 
+ 
+   PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential 
+   information for the client of the Kerberos ticket. The data itself 
+   is contained in a KERB_VALIDATION_INFO structure, which is NDR 
+   encoded. The output of the NDR encoding is placed in the 
+   PAC_INFO_BUFFER structure of type PAC_LOGON_INFO. 
+    
+        typedef struct _KERB_VALIDATION_INFO { 
+            FILETIME Reserved0; 
+            FILETIME Reserved1; 
+            FILETIME KickOffTime; 
+            FILETIME Reserved2; 
+            FILETIME Reserved3; 
+            FILETIME Reserved4; 
+            UNICODE_STRING Reserved5; 
+            UNICODE_STRING Reserved6; 
+            UNICODE_STRING Reserved7; 
+            UNICODE_STRING Reserved8; 
+            UNICODE_STRING Reserved9; 
+            UNICODE_STRING Reserved10; 
+            USHORT Reserved11; 
+            USHORT Reserved12; 
+            ULONG UserId; 
+            ULONG PrimaryGroupId; 
+            ULONG GroupCount; 
+            [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds; 
+            ULONG UserFlags; 
+            ULONG Reserved13[4]; 
+            UNICODE_STRING Reserved14; 
+            UNICODE_STRING Reserved15; 
+            PSID LogonDomainId; 
+            ULONG Reserved16[2]; 
+            ULONG Reserved17; 
+            ULONG Reserved18[7]; 
+            ULONG SidCount; 
+            [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids; 
+            PSID ResourceGroupDomainSid; 
+            ULONG ResourceGroupCount; 
+            [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP 
+        ResourceGroupIds; 
+        } KERB_VALIDATION_INFO; 
+    
+   Reserved fields are not defined in this document and are not used in 
+   the construction of access control tokens. 
+    
+   The fields are defined as follows: 
+    
+  
+Brezak                 Category - Informational                      3 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+   KickOffTime - the time at which the server should forcibly logoff 
+           the client. If the client should not be forced off, this 
+           field should be set to (0x7fffffff,0xffffffff). If a kickoff 
+           time is to be enforced, the service ticket lifetime will 
+           never exceed this value. 
+   UserId - This field contains the relative Id for the client. If 
+           zero, then the User ID is the first SID in the ExtraSids 
+           field. 
+   PrimaryGroupId - This field contains the relative ID for this 
+           clientÆs primary group. 
+   GroupCount - This field contains the number of groups, within the 
+           clientÆs domain, to which the client is a member. 
+   GroupIds - This field contains an array of the relative Ids and 
+           attributes of the groups in the clientÆs domain of which the 
+           client is a member. 
+   UserFlags - This field contains information about which fields in 
+           this structure are valid. The two bits that may be set are 
+           indicated below. Having these flags set indicates that the 
+           corresponding fields in the KERB_VALIDATION_INFO structure 
+           are present and valid. 
+            
+           #define LOGON_EXTRA_SIDS             0x0020 
+           #define LOGON_RESOURCE_GROUPS        0x0200 
+            
+   LogonDomainId - This field contains the SID of the clientÆs domain. 
+           This field is used in conjunction with the UserId, 
+           PrimaryGroupId,and GroupIds fields to create the user and 
+           group SIDs for the client. 
+   SidCount - This field contains the number of SIDs present in the 
+           ExtraSids field. This field is only valid if the 
+           LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 
+   ExtraSids - This field contains a list of SIDs for groups to which 
+           the user is a member. This field is only valid if the 
+           LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 
+   ResouceGroupCount - This field contains the number of resource 
+           groups in the ResourceGroupIds field. This field is only 
+           valid if the LOGON RESOURCE_GROUPS flag has been set in the 
+           UserFlags field._  
+   ResourceGroupDomainSid - This field contains the SID of the resource 
+           domain. This field is used in conjunction with the 
+           ResourceGroupIds field to create the group SIDs for the 
+           client. 
+   ResourceGroupIds - This field contains an array of the relative Ids 
+           and attributes of the groups in the resource domain of which 
+           the resource is a member. 
+    
+   When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 
+   FILETIME type is defined as follows: 
+    
+        typedef unsigned int DWORD; 
+         
+        typedef struct _FILETIME { 
+            DWORD dwLowDateTime; 
+  
+Brezak                 Category - Informational                      4 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+            DWORD dwHighDateTime; 
+        } FILETIME; 
+    
+   Times are encoded as the number of 100 nanosecond increments since 
+   January 1, 1601, in UTC time. 
+    
+   When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 
+   UNICODE_STRING structure is defined as: 
+    
+        typedef struct _UNICODE_STRING 
+            USHORT Length; 
+            USHORT MaximumLength; 
+            [size_is(MaximumLength / 2), length_is((Length) / 2) ] 
+        USHORT *  Buffer; 
+        } UNICODE_STRING; 
+    
+   The Length field contains the number of bytes in the string, not 
+   including the null terminator, and the MaximumLength field contains 
+   the total number of bytes in the buffer containing the string. 
+    
+   The GROUP_MEMBERSHIP structure contains the relative ID of a group 
+   and the corresponding attributes for the group. 
+    
+        typedef struct _GROUP_MEMBERSHIP { 
+            ULONG RelativeId; 
+            ULONG Attributes; 
+        } *PGROUP_MEMBERSHIP; 
+    
+   The group attributes must be: 
+    
+        #define SE_GROUP_MANDATORY              (0x00000001L) 
+        #define SE_GROUP_ENABLED_BY_DEFAULT     (0x00000002L) 
+        #define SE_GROUP_ENABLED                (0x00000004L) 
+    
+   The SID structure is defined as follows: 
+    
+         
+        typedef struct _SID_IDENTIFIER_AUTHORITY { 
+            UCHAR Value[6]; 
+        } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY; 
+         
+   The constant value for the NT Authority is  
+    
+        #define SECURITY_NT_AUTHORITY           {0,0,0,0,0,5} 
+         
+        typedef struct _SID { 
+           UCHAR Revision; 
+           UCHAR SubAuthorityCount; 
+           SID_IDENTIFIER_AUTHORITY IdentifierAuthority; 
+           [size_is(SubAuthorityCount)] ULONG SubAuthority[*]; 
+        } SID, *PSID; 
+    
+    
+  
+Brezak                 Category - Informational                      5 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+   Other authorities are defined in the Microsoft Developer Network 
+   Development Kit 3. 
+   The SubAuthorityCount field contains the number of elements in the 
+   actual SubAuthority conformant array. The maximum number of 
+   subauthorities allowed is 15. 
+    
+   The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and 
+   their corresponding attributes: 
+    
+        typedef struct _KERB_SID_AND_ATTRIBUTES { 
+            PSID Sid; 
+            ULONG Attributes; 
+        } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES; 
+         
+   The attributes are the same as the group attributes defined above. 
+   
+5. Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM) 
+ 
+   The PAC contains two digital signatures: one using the key of the 
+   server, and one using the key of the KDC. The signatures are present 
+   for two reasons. First, the signature with the serverÆs key is 
+   present to prevent a client from generating their own PAC and 
+   sending it to the KDC as encrypted authorization data to be included 
+   in tickets. Second, the signature with the KDCÆs key is present to 
+   prevent an untrusted service from forging a ticket to itself with an 
+   invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type 
+   PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively. 
+    
+    
+   The signatures are contained in the following structure: 
+    
+        typedef struct _PAC_SIGNATURE_DATA { 
+            ULONG SignatureType; 
+            UCHAR Signature[1];      
+        } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA; 
+    
+   The fields are defined as follows: 
+    
+   SignatureType - This field contains the type of checksum used to 
+           create a signature. The checksum must be a keyed checksum. 
+    
+   Signature - This field consists of an array of bytes containing the 
+           checksum data. The length of bytes may be determined by the 
+           wrapping PAC_INFO_BUFFER structure. 
+    
+   For the serverÆs checksum, the key used to generate the signature 
+   should be the same key used to encrypt the ticket. Thus, if the 
+   enc_tkt_in_skey option is used, the session key from the serverÆs 
+   TGT should be used. The Key used to encrypt ticket granting tickets 
+   is used to generate the KDCÆs checksum. 
+    
+   The checksums are computed as follows: 
+    
+  
+Brezak                 Category - Informational                      6 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+     1. The complete PAC is built, including space for both checksums 
+     2. The data portion of both checksums is zeroed. 
+     3. The entire PAC structure is checksummed with the serverÆs key, 
+        and the result is stored in the serverÆs checksum structure. 
+     4. The serverÆs checksum is then checksummed with the KDC's key. 
+     5. The checksum with the KDC key is stored in the KDC's checksum 
+        structure. 
+ 
+6. PAC Request Pre-Auth Data 
+    
+   Normally, the PAC is included in every pre-authenticated ticket 
+   received from an AS request. However, a client may also explicitly 
+   request either to include or to not include the PAC. This is done by 
+   sending the PAC-REQUEST preauth data. 
+    
+   This is an ASN.1 encoded structure. 
+    
+        KERB-PA-PAC-REQUEST     ::= SEQUENCE { 
+                include-pac[0] BOOLEAN -- if TRUE, and no pac present, 
+                                       -- include PAC. 
+                                       ---If FALSE, and pac 
+                                       -- PAC present, remove PAC 
+        }  
+    
+   The fields are defined as follows: 
+    
+   include-pac - This field indicates whether a PAC should be included 
+           or not. If the value is TRUE, a PAC will be included 
+           independent of other preauth data. If the value is FALSE, 
+           then no PAC will be included, even if other preauth data is 
+           present. 
+    
+   The preauth ID is: 
+        #define KRB5_PADATA_PAC_REQUEST         128 
+    
+7. Security Considerations 
+ 
+   Before the PAC data is used for access control, the 
+   PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that 
+   the provider of the PAC data knows the server's secret key.  
+   Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to 
+   verify that the PAC was issued from the KDC and not placed in the 
+   ticket by someone other than the KDC with access to the service key. 
+    
+   Caution must be used with accepting the SIDs present in the logon-
+   info part of the PAC. Only SIDs from a domain that is authoritative 
+   for a particular domain's SIDs should be used in the construction of 
+   access tokens. If a SID is found to be from outside of a domain's 
+   authoritative SID namespace, it MUST be ignored for purposes of 
+   access control. 
+    
+8. References 
+    
+  
+Brezak                 Category - Informational                      7 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+ 
+   1 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 
+      (V5)", RFC 1510, September 1993 
+    
+   2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+     Levels", BCP 14, RFC 2119, March 1997 
+    
+   3 Microsoft Developer's Network - http://msdn.microsoft.com 
+    
+ 
+9. Author's Addresses 
+    
+   John Brezak 
+   Microsoft Corporation 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      8 
+               Windows 2000 Kerberos Authorization Data   October 2002 
+ 
+ 
+    
+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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Brezak                 Category - Informational                      9 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-00.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-00.txt
new file mode 100644
index 00000000000..a29c1ca760b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-00.txt
@@ -0,0 +1,412 @@
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-00.txt              Microsoft 
+Category: Informational                                 September, 1999 
+ 
+ 
+           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 desired 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       July 1999 
+ 
+ 
+   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 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). 
+    
+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(Key, Data) returning the checksum using the specified key on the 
+   data. 
+    
+   The basic RC4 encryption operation is used in this encryption type 
+   and defined 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. 
+    
+   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. 
+  
+Swift                  Category - Informational                      2 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
+ 
+ 
+    
+   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, "signature key")  //includes zero octet at end 
+        tmp = MD5(Ksign, concat(T, data)) 
+        CHKSUM = HMAC(K, 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. 
+    
+   ENCRYPT(K, T, data) 
+        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
+                L = "fiftysixbits" //includes zero octet at end 
+        Else 
+                L = ""  // one octet of zero 
+        Ksign = HMAC(K, concat(L, T)) 
+        Confounder = nonce(8) // get an 8 octet nonce for a confounder 
+        Checksum = HMAC(Ksign, concat(Confounder, data)) 
+        Ke = Ksign 
+        if (L == "fiftysixbits") memset(&Ke[7], 0x0ab, 9) 
+        Ke2 = HMAC(Ke, Checksum) 
+        data = RC4(Ke2, data) 
+    
+   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; 
+    
+
+  
+Swift                  Category - Informational                      3 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
+ 
+ 
+   The character constant "fiftysixbits" evolved from the time when a 
+   56-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. 
+    
+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. 
+    
+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). 
+    
+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. 
+    
+
+
+  
+Swift                  Category - Informational                      4 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
+ 
+ 
+   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 based messages is as follow: 
+    
+   GSS-ENCRYPT(K, T, data) 
+        IV = SND_SEQ 
+        K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) 
+        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
+                L = "fortybits" //includes zero octet at end 
+        else 
+                L = "" // one octet of zero 
+        Ksign = HMAC(K, concat(L, T)) 
+        Ke = Ksign 
+        if (L == "fortybits") memset(&Ke[7], 0x0ab, 9) 
+        Ke2 = HMAC(Ke, IV) 
+        Data = RC4(Ke2, data) 
+        SND_SEQ = RC4(Ke, seq#) 
+         
+   The sequence number (SND_SEQ) and IV are used as defined in [5] 
+   Section 1.2.2. 
+    
+   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. 
+    
+8. 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. 
+    
+9. 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 
+ 
+   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
+      June 1996 
+ 
+ 
+  
+Swift                  Category - Informational                      5 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
+ 
+ 
+ 
+   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  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 
+ 
+   9  Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+ 
+    
+10. Author's Addresses 
+    
+   Mike Swift 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: mikesw@microsoft.com  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      6 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
+ 
+ 
+    
+11. 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." 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      7 
+
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt
new file mode 100644
index 00000000000..a97ef9d191e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt
@@ -0,0 +1,412 @@
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-01.txt              Microsoft 
+Category: Informational                                    October 1999 
+ 
+ 
+           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    October 1999 
+ 
+ 
+   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). 
+    
+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. 
+    
+   The basic RC4 encryption operation is used in this encryption type 
+   and defined 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. 
+    
+   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. 
+  
+Swift                  Category - Informational                      2 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+   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, "signature key")  //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. 
+    
+   ENCRYPT(K, T, data) 
+        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
+                L = concat("fortybits", T) //includes zero octet at 
+                                           //end of string constant 
+        Else 
+                L = T 
+        Ksign = HMAC(K,L) 
+        Confounder = nonce(8) // get an 8 octet nonce for a confounder 
+        Checksum = HMAC(Ksign, concat(Confounder, data)) 
+        Ke = Ksign 
+        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
+                memset(&Ke[7], 0x0ab, 9) 
+        Ke2 = HMAC(Ke, Checksum) 
+        data = RC4(Ke2, data) 
+    
+   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; 
+  
+Swift                  Category - Informational                      3 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+   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. 
+    
+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). 
+    
+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. 
+    
+
+  
+Swift                  Category - Informational                      4 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+   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 based messages is as follow: 
+    
+   T = the message type, encoded as a little-endian four byte integer. 
+    
+   GSS-ENCRYPT(K, T, data) 
+        IV = SND_SEQ 
+        K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) 
+        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
+                L = concat("fortybits", T) //includes zero octet at end 
+        else 
+                L = T 
+        Ksign = HMAC(K, L) 
+        Ke = Ksign 
+        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
+                memset(&Ke[7], 0x0ab, 9) 
+        Ke2 = HMAC(Ke, IV) 
+        Data = RC4(Ke2, data) 
+        SND_SEQ = RC4(Ke, seq#) 
+         
+   The sequence number (SND_SEQ) and IV are used as defined in [5] 
+   Section 1.2.2. 
+    
+   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. 
+    
+8. 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. 
+    
+9. 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                      5 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+ 
+   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  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 
+ 
+   9  Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+ 
+    
+10. Author's Addresses 
+    
+   Mike Swift 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: mikesw@microsoft.com  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      6 
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+    
+11. 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." 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      7 
+
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
new file mode 100644
index 00000000000..1fc9927dea4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
@@ -0,0 +1,589 @@
+
+
+CAT working group                                              M. Swift 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-02.txt              Microsoft 
+Category: Informational                                   November 2000 
+
+
+           The Windows 2000 RC4-HMAC Kerberos encryption type 
+
+
+tatus of this Memo 
+
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 
+   working documents of the Internet Engineering Task Force (IETF), its 
+   areas, and its working groups. Note that other groups may also 
+   distribute working documents as Internet-Drafts. Internet-Drafts are 
+   draft documents valid for a maximum of six months and may be 
+   updated, replaced, or obsoleted by other documents at any time. It 
+   is inappropriate to use Internet- Drafts as reference material or to 
+   cite them other than as "work in progress." 
+     
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt  
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html. 
+    
+. Abstract 
+    
+   The Windows 2000 implementation of Kerberos introduces a new 
+   encryption type based on the RC4 encryption algorithm and using an 
+   MD5 HMAC for checksum. This is offered as an alternative to using 
+   the existing DES based encryption types. 
+    
+   The RC4-HMAC encryption types are used to ease upgrade of existing 
+   Windows NT environments, provide strong crypto (128-bit key 
+   lengths), and provide exportable (meet United States government 
+   export restriction requirements) encryption. 
+    
+   The Windows 2000 implementation of Kerberos contains new encryption 
+   and checksum types for two reasons: for export reasons early in the 
+   development process, 56 bit DES encryption could not be exported, 
+   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
+   accounts will not have the appropriate DES keying material to do the 
+   standard DES encryption. Furthermore, 3DES is not available for 
+   export, and there was a desire to use a single flavor of encryption 
+   in the product for both US and international products. 
+    
+   As a result, there are two new encryption types and one new checksum 
+   type introduced in Windows 2000. 
+    
+    
+. Conventions used in this document 
+    
+
+ 
+wift                  Category - Informational                      1 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
+   this document are to be interpreted as described in RFC-2119 [2]. 
+    
+. Key Generation 
+    
+   On upgrade from existing Windows NT domains, the user accounts would 
+   not have a DES based key available to enable the use of DES base 
+   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
+   the same as the existing Windows NT key (NT Password Hash) for 
+   compatibility reasons. Once the account password is changed, the DES 
+   based keys are created and maintained. Once the DES keys are 
+   available DES based encryption types can be used with Kerberos.  
+    
+   The RC4-HMAC String to key function is defined as follow: 
+    
+   String2Key(password) 
+    
+        K = MD4(UNICODE(password)) 
+         
+   The RC4-HMAC keys are generated by using the Windows UNICODE version 
+   of the password. Each Windows UNICODE character is encoded in 
+   little-endian format of 2 octets each. Then performing an MD4 [6] 
+   hash operation on just the UNICODE characters of the password (not 
+   including the terminating zero octets). 
+    
+   For an account with a password of "foo", this String2Key("foo") will 
+   return: 
+    
+        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
+        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
+    
+. Basic Operations 
+    
+   The MD5 HMAC function is defined in [3]. It is used in this 
+   encryption type for checksum operations. Refer to [3] for details on 
+   its operation. In this document this function is referred to as 
+   HMAC(Key, Data) returning the checksum using the specified key on 
+   the data. 
+    
+   The basic MD5 hash operation is used in this encryption type and 
+   defined in [7]. In this document this function is referred to as 
+   MD5(Data) returning the checksum of the data. 
+    
+   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
+   compatible cipher is described in [8]. In this document the function 
+   is referred to as RC4(Key, Data) returning the encrypted data using 
+   the specified key on the data. 
+    
+   These encryption types use key derivation as defined in [9] (RFC-
+   1510BIS) in Section titled "Key Derivation". With each message, the 
+   message type (T) is used as a component of the keying material. This 
+   summarizes the different key derivation values used in the various 
+ 
+wift                  Category - Informational                      2 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+   operations. Note that these differ from the key derivations used in 
+   other Kerberos encryption types. 
+    
+        T = 1 for TS-ENC-TS in the AS-Request 
+        T = 8 for the AS-Reply  
+        T = 7 for the Authenticator in the TGS-Request 
+        T = 8 for the TGS-Reply  
+        T = 2 for the Server Ticket in the AP-Request 
+        T = 11 for the Authenticator in the AP-Request 
+        T = 12 for the Server returned AP-Reply 
+        T = 15 in the generation of checksum for the MIC token 
+        T = 0 in the generation of sequence number for the MIC token  
+        T = 13 in the generation of checksum for the WRAP token 
+        T = 0 in the generation of sequence number for the WRAP token  
+        T = 0 in the generation of encrypted data for the WRAPPED token 
+    
+   All strings in this document are ASCII unless otherwise specified. 
+   The lengths of ASCII encoded character strings include the trailing 
+   terminator character (0). 
+    
+   The concat(a,b,c,...) function will return the logical concatenation 
+   (left to right) of the values of the arguments. 
+    
+   The nonce(n) function returns a pseudo-random number of "n" octets. 
+    
+. Checksum Types 
+    
+   There is one checksum type used in this encryption type. The 
+   Kerberos constant for this type is: 
+        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
+    
+   The function is defined as follows: 
+    
+   K - is the Key 
+   T - the message type, encoded as a little-endian four byte integer 
+    
+   CHKSUM(K, T, data) 
+    
+        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
+        tmp = MD5(concat(T, data)) 
+        CHKSUM = HMAC(Ksign, tmp) 
+    
+    
+. Encryption Types 
+    
+   There are two encryption types used in these encryption types. The 
+   Kerberos constants for these types are: 
+        #define KERB_ETYPE_RC4_HMAC             23 
+        #define KERB_ETYPE_RC4_HMAC_EXP         24 
+    
+   The basic encryption function is defined as follow: 
+    
+   T = the message type, encoded as a little-endian four byte integer. 
+ 
+wift                  Category - Informational                      3 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+    
+        BYTE L40[14] = "fortybits"; 
+        BYTE SK = "signaturekey"; 
+         
+        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 10 + 4, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            add_8_random_bytes(data, data_len, conf_plus_data); 
+            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
+            HMAC (K1, checksum, 16, K3); 
+            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
+            memcpy (edata, checksum, 16); 
+            edata_len = 16 + 8 + data_len; 
+        }         
+         
+        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
+        { 
+            if (fRC4_EXP){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K1); 
+            }else{ 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
+            HMAC (K1, edata, 16, K3); // checksum is at edata 
+            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
+            data_len = edata_len - 16 - 8; 
+            memcpy (data, edata + 16 + 8, data_len); 
+             
+            // verify generated and received checksums 
+            HMAC (K2, edata + 16, edata_len - 16, checksum); 
+            if (memcmp(edata, checksum, 16) != 0)  
+                printf("CHECKSUM ERROR  !!!!!!\n"); 
+        } 
+    
+   The header field on the encrypted data in KDC messages is: 
+    
+        typedef struct _RC4_MDx_HEADER { 
+            UCHAR Checksum[16]; 
+            UCHAR Confounder[8]; 
+        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
+         
+   The KDC message is encrypted using the ENCRYPT function not 
+   including the Checksum in the RC4_MDx_HEADER. 
+    
+ 
+wift                  Category - Informational                      4 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+. Key Strength Negotiation 
+    
+   A Kerberos client and server can negotiate over key length if they 
+   are using mutual authentication. If the client is unable to perform 
+   full strength encryption, it may propose a key in the "subkey" field 
+   of the authenticator, using a weaker encryption type. The server 
+   must then either return the same key or suggest its own key in the 
+   subkey field of the AP reply message. The key used to encrypt data 
+   is derived from the key returned by the server. If the client is 
+   able to perform strong encryption but the server is not, it may 
+   propose a subkey in the AP reply without first being sent a subkey 
+   in the authenticator. 
+
+. GSSAPI Kerberos V5 Mechanism Type  
+
+.1 Mechanism Specific Changes 
+    
+   The GSSAPI per-message tokens also require new checksum and 
+   encryption types. The GSS-API per-message tokens must be changed to 
+   support these new encryption types (See [5] Section 1.2.2). The 
+   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
+   is: 
+        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
+    
+   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
+        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
+    
+   The only support quality of protection is: 
+        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
+    
+   In addition, when using an RC4 based encryption type, the sequence 
+   number is sent in big-endian rather than little-endian order. 
+    
+   The Windows 2000 implementation also defines new GSSAPI flags in the 
+   initial token passed when initializing a security context. These 
+   flags are passed in the checksum field of the authenticator (See [5] 
+   Section 1.1.1). 
+    
+   GSS_C_DCE_STYLE - This flag was added for use with MicrosoftÆs 
+   implementation of DCE RPC, which initially expected three legs of 
+   authentication. Setting this flag causes an extra AP reply to be 
+   sent from the client back to the server after receiving the serverÆs 
+   AP reply. In addition, the context negotiation tokens do not have 
+   GSSAPI framing - they are raw AP message and do not include object 
+   identifiers. 
+        #define GSS_C_DCE_STYLE                 0x1000 
+    
+
+ 
+wift                  Category - Informational                      5 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
+   server that it should only allow the server application to identify 
+   the client by name and ID, but not to impersonate the client. 
+        #define GSS_C_IDENTIFY_FLAG             0x2000 
+         
+   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
+   client wants to be informed of extended error information. In 
+   particular, Windows 2000 status codes may be returned in the data 
+   field of a Kerberos error message. This allows the client to 
+   understand a server failure more precisely. In addition, the server 
+   may return errors to the client that are normally handled at the 
+   application layer in the server, in order to let the client try to 
+   recover. After receiving an error message, the client may attempt to 
+   resubmit an AP request. 
+        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
+    
+   These flags are only used if a client is aware of these conventions 
+   when using the SSPI on the Windows platform, they are not generally 
+   used by default. 
+    
+   When NetBIOS addresses are used in the GSSAPI, they are identified 
+   by the GSS_C_AF_NETBIOS value. This value is defined as: 
+        #define GSS_C_AF_NETBIOS                0x14 
+   NetBios addresses are 16-octet addresses typically composed of 1 to                                                                  th   15 characters, trailing blank (ascii char 20) filled, with a 16  
+   octet of 0x0. 
+    
+.2 GSSAPI Checksum Type 
+    
+   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
+   the first 8 octets of the checksum are used. The resulting checksum 
+   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
+   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
+    
+        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
+             MIC_seq, MIC_checksum) 
+        { 
+            HMAC (K, SK, 13, K4); 
+            T = 15; 
+            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
+            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
+                                                // 0101 1100 FFFFFFFF 
+            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
+            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
+            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
+            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K5); 
+            }else{ 
+                HMAC (K, &T, 4, K5); 
+ 
+wift                  Category - Informational                      6 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+            } 
+            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
+            HMAC(K5, MIT_checksum, 8, K6); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K6, seq_plus_direction, 8, MIC_seq); 
+        } 
+    
+.3 GSSAPI Encryption Types 
+    
+   There are two encryption types for GSSAPI message tokens, one that 
+   is 128 bits in strength, and one that is 56 bits in strength as 
+   defined in Section 6. 
+    
+   All padding is rounded up to 1 byte. One byte is needed to say that 
+   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
+   padding. See [5] Section 1.2.2.3. 
+    
+   The encryption mechanism used for GSS wrap based messages is as 
+   follow: 
+    
+    
+        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
+              WRAP_seq, WRAP_checksum, edata, edata_len) 
+        { 
+            HMAC (K, SK, 13, K7); 
+            T = 13; 
+            PAD = 1; 
+            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
+            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
+        FFFFFFFF 
+            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
+            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
+            MD5 (T_hdr_conf_msg_pad, 
+                 4 + 8 + 8 + msg_len + 1, 
+                 MD5_of_T_hdr_conf_msg_pad); 
+            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
+            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
+        bytes 
+          
+            T = 0; 
+            if (fRC4_EXP){  
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K8); 
+            }else{ 
+                HMAC (K, &T, 4, K8); 
+            } 
+            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
+            HMAC(K8, WRAP_checksum, 8, K9); 
+            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
+        //0x12345678 
+ 
+wift                  Category - Informational                      7 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+            copy_direction_flag (direction_flag, seq_plus_direction + 
+        4); //0x12345678FFFFFFFF 
+            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
+          
+            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
+        of key with 0xF0 
+            T = 0; 
+            if (fRC4_EXP){ 
+                *(DWORD *)(L40+10) = T; 
+                HMAC(K10, L40, 14, K11); 
+                memset(K11+7, 0xAB, 9); 
+            }else{ 
+                HMAC(K10, &T, 4, K11);  
+            } 
+            HMAC(K11, seq_num, 4, K12); 
+            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
+        edata); /* skip T & hdr */ 
+            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
+         } 
+          
+    
+   The character constant "fortybits" evolved from the time when a 40-
+   bit key length was all that was exportable from the United States. 
+   It is now used to recognize that the key length is of "exportable" 
+   length. In this description, the key size is actually 56-bits. 
+    
+. Security Considerations 
+
+   Care must be taken in implementing this encryption type because it 
+   uses a stream cipher. If a different IV isnÆt used in each direction 
+   when using a session key, the encryption is weak. By using the 
+   sequence number as an IV, this is avoided. 
+    
+0. Acknowledgements 
+    
+   We would like to thank Salil Dangi for the valuable input in 
+   refining the descriptions of the functions and review input. 
+     
+1. References 
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
+      Message Authentication", RFC 2104, February 1997 
+    
+   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+
+
+ 
+wift                  Category - Informational                      8 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
+
+
+
+   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
+      June 1996 
+
+   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
+      1992 
+
+   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
+      1992 
+
+   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
+      Algorithm", Work in Progress. 
+
+   9  RC4 is a proprietary encryption algorithm available under license 
+      from RSA Data Security Inc.  For licensing information, contact: 
+       
+         RSA Data Security, Inc. 
+         100 Marine Parkway 
+         Redwood City, CA 94065-1031 
+
+   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
+      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
+      04.txt, June 25, 1999 
+
+    
+2. Author's Addresses 
+    
+   Mike Swift 
+   Dept. of Computer Science 
+   Sieg Hall 
+   University of Washington 
+   Seattle, WA 98105 
+   Email: mikesw@cs.washington.edu  
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+wift                  Category - Informational                      9 
+
+               Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+
+
+    
+3. Full Copyright Statement 
+
+   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
+    
+   This document and translations of it may be copied and          
+   furnished to others, and derivative works that comment on or          
+   otherwise explain it or assist in its implementation may be          
+   prepared, copied, published and distributed, in whole or in          
+   part, without restriction of any kind, provided that the above          
+   copyright notice and this paragraph are included on all such          
+   copies and derivative works.  However, this document itself may          
+   not be modified in any way, such as by removing the copyright          
+   notice or references to the Internet Society or other Internet          
+   organizations, except as needed for the purpose of developing          
+   Internet standards in which case the procedures for copyrights          
+   defined in the Internet Standards process must be followed, or          
+   as required to translate it into languages other than English. 
+    
+   The limited permissions granted above are perpetual and will          
+   not be revoked by the Internet Society or its successors or          
+   assigns. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+wift                  Category - Informational                     10 
+
diff --git a/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
new file mode 100644
index 00000000000..9ebe39e0aab
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
@@ -0,0 +1,589 @@
+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/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt
new file mode 100644
index 00000000000..9887873ef06
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt
@@ -0,0 +1,923 @@
+
+
+Kerberos working group                                         M. Swift 
+                                                           U.Washington 
+Internet Draft                                                J. Brezak 
+Document: draft-brezak-win2k-krb-rc4-hmac-04.txt              Microsoft 
+Category: Informational                                        May 2002 
+ 
+ 
+      The Microsoft 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 Microsoft 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 Microsoft 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 Microsoft Windows 2000. 
+    
+    
+2. Conventions used in this document 
+  
+Swift                  Category - Informational                      1 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+    
+   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. With each message, the 
+   message type (T) is used as a component of the keying material. This 
+   table summarizes the different key derivation values used in the 
+  
+Swift                  Category - Informational                      2 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+   various operations. Note that these differ from the key derivations 
+   used in other Kerberos encryption types. T = the message type, 
+   encoded as a little-endian four byte integer. 
+    
+    
+        1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with 
+        the client key (T=1) 
+        2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key 
+        or application session key), encrypted with the service key 
+        (T=2) 
+        3.  AS-REP encrypted part (includes TGS session key or 
+        application session key), encrypted with the client key (T=8) 
+        4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the 
+        TGS session key (T=4) 
+        5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the 
+        TGS authenticator subkey (T=5) 
+        6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 
+        with the TGS session key (T=6) 
+        7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes 
+        TGS authenticator subkey), encrypted with the TGS session key 
+        (T=7) 
+        8.  TGS-REP encrypted part (includes application session key), 
+        encrypted with the TGS session key (T=8) 
+        9.  TGS-REP encrypted part (includes application session key), 
+        encrypted with the TGS authenticator subkey (T=8) 
+        10.  AP-REQ Authenticator cksum, keyed with the application 
+        session key (T=10) 
+        11.  AP-REQ Authenticator (includes application authenticator 
+        subkey), encrypted with the application session key (T=11) 
+        12.  AP-REP encrypted part (includes application session 
+        subkey), encrypted with the application session key (T=12) 
+        13.  KRB-PRIV encrypted part, encrypted with a key chosen by 
+        the application. Also for data encrypted with GSS Wrap (T=13) 
+        14.  KRB-CRED encrypted part, encrypted with a key chosen by 
+        the application (T=14) 
+        15.  KRB-SAFE cksum, keyed with a key chosen by the 
+        application. Also for data signed in GSS MIC (T=15) 
+    
+        Relative to RFC-1964 key uses: 
+         
+        T = 0 in the generation of sequence number for the MIC 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. 
+    
+  
+Swift                  Category - Informational                      3 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+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. 
+    
+        OCTET L40[14] = "fortybits"; 
+        OCTET SK = "signaturekey"; 
+         
+   The header field on the encrypted data in KDC messages is: 
+    
+        typedef struct _RC4_MDx_HEADER { 
+            OCTET Checksum[16]; 
+            OCTET Confounder[8]; 
+        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
+         
+         
+        ENCRYPT (K, export, T, data) 
+        { 
+            struct EDATA { 
+                struct HEADER { 
+                        OCTET Checksum[16]; 
+                        OCTET Confounder[8]; 
+                } Header; 
+                OCTET Data[0]; 
+            } edata; 
+         
+            if (export){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 10 + 4, K1); 
+  
+Swift                  Category - Informational                      4 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+            } 
+            else 
+            { 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (export) memset (K1+7, 0xAB, 9); 
+         
+            nonce (edata.Confounder, 8); 
+            memcpy (edata.Data, data); 
+         
+            edata.Checksum = HMAC (K2, edata); 
+            K3 = HMAC (K1, edata.Checksum); 
+         
+            RC4 (K3, edata.Confounder); 
+            RC4 (K3, data.Data); 
+        }         
+         
+        DECRYPT (K, export, T, edata) 
+        { 
+            // edata looks like 
+            struct EDATA { 
+                struct HEADER { 
+                        OCTET Checksum[16]; 
+                        OCTET Confounder[8]; 
+                } Header; 
+                OCTET Data[0]; 
+            } edata; 
+         
+            if (export){ 
+                *((DWORD *)(L40+10)) = T; 
+                HMAC (K, L40, 14, K1); 
+            } 
+            else 
+            { 
+                HMAC (K, &T, 4, K1); 
+            } 
+            memcpy (K2, K1, 16); 
+            if (export) memset (K1+7, 0xAB, 9); 
+         
+            K3 = HMAC (K1, edata.Checksum); 
+         
+            RC4 (K3, edata.Confounder); 
+            RC4 (K3, edata.Data); 
+         
+                
+            // verify generated and received checksums 
+            checksum = HMAC (K2, concat(edata.Confounder, edata.Data)); 
+            if (checksum != edata.Checksum)  
+                printf("CHECKSUM ERROR  !!!!!!\n"); 
+        } 
+    
+
+  
+Swift                  Category - Informational                      5 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+   The KDC message is encrypted using the ENCRYPT function not 
+   including the Checksum in the RC4_MDx_HEADER. 
+    
+   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 are adapted to 
+   support these new encryption types (See [5] Section 1.2.2). 
+    
+   The only support quality of protection is: 
+        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
+    
+   When using this RC4 based encryption type, the sequence number is 
+   always 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 per message tokens - they are raw AP messages that do not 
+   include object identifiers. 
+        #define GSS_C_DCE_STYLE                 0x1000 
+    
+   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 
+  
+Swift                  Category - Informational                      6 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+         
+   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 
+   15 characters, trailing blank (ASCII char 20) filled, with a 16-th 
+   octet of 0x0. 
+    
+8.2 GSSAPI MIC Semantics 
+    
+   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). 
+    
+   The GSS_GetMIC token has the following format: 
+    
+      Byte no         Name       Description 
+       0..1           TOK_ID     Identification field. 
+                                 Tokens emitted by GSS_GetMIC() contain 
+                                 the hex value 01 01 in this field. 
+       2..3           SGN_ALG    Integrity algorithm indicator. 
+                                 11 00 - HMAC 
+       4..7           Filler     Contains ff ff ff ff 
+       8..15          SND_SEQ    Sequence number field. 
+       16..23         SGN_CKSUM  Checksum of "to-be-signed data", 
+                                 calculated according to algorithm 
+                                 specified in SGN_ALG field. 
+    
+   The MIC mechanism used for GSS MIC based messages is as follow: 
+    
+        GetMIC(Kss, direction, export, seq_num, data) 
+        { 
+                struct Token { 
+                       struct Header { 
+                              OCTET TOK_ID[2]; 
+                              OCTET SGN_ALG[2]; 
+                              OCTET Filler[4]; 
+  
+Swift                  Category - Informational                      7 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+                       }; 
+                       OCTET SND_SEQ[8]; 
+                       OCTET SGN_CKSUM[8]; 
+                } Token; 
+         
+         
+                Token.TOK_ID = 01 01; 
+                Token.SGN_SLG = 11 00; 
+                Token.Filler = ff ff ff ff; 
+         
+                // Create the sequence number 
+         
+                if (direction == sender_is_initiator) 
+                { 
+                        memset(Token.SEND_SEQ+4, 0xff, 4) 
+                } 
+                else if (direction == sender_is_acceptor) 
+                { 
+                        memset(Token.SEND_SEQ+4, 0, 4) 
+                } 
+                Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; 
+                Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; 
+                Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; 
+                Token.SEND_SEQ[3] = (seq_num & 0x000000ff); 
+         
+                // Derive signing key from session key 
+         
+                Ksign = HMAC(Kss, "signaturekey"); 
+                                  // length includes terminating null 
+         
+                // Generate checksum of message - SGN_CKSUM 
+                //   Key derivation salt = 15 
+         
+                Sgn_Cksum = MD5((int32)15, Token.Header, data); 
+         
+                // Save first 8 octets of HMAC Sgn_Cksum 
+         
+                Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 
+                memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 
+         
+                // Encrypt the sequence number 
+         
+                // Derive encryption key for the sequence number 
+                //   Key derivation salt = 0 
+         
+                if (exportable) 
+                { 
+                        Kseq = HMAC(Kss, "fortybits", (int32)0); 
+                                     // len includes terminating null 
+                        memset(Kseq+7, 0xab, 7) 
+                } 
+                else 
+                { 
+  
+Swift                  Category - Informational                      8 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+                        Kseq = HMAC(Kss, (int32)0); 
+                } 
+                Kseq = HMAC(Kseq, Token.SGN_CKSUM); 
+         
+                // Encrypt the sequence number 
+         
+                RC4(Kseq, Token.SND_SEQ); 
+        } 
+    
+8.3 GSSAPI WRAP Semantics 
+    
+   There are two encryption keys 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 RC4-HMAC GSS_Wrap() token has the following format: 
+    
+   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. 
+                                   11 00 - HMAC 
+       4..5           SEAL_ALG     ff ff - none 
+                                   00 00 - DES-CBC 
+                                   10 00 - RC4 
+       6..7           Filler       Contains ff ff 
+       8..15          SND_SEQ      Encrypted sequence number field. 
+       16..23         SGN_CKSUM    Checksum of plaintext padded data, 
+                                   calculated according to algorithm 
+                                   specified in SGN_ALG field. 
+       24..31         Confounder   Random confounder 
+       32..last       Data         encrypted or plaintext padded data 
+    
+   The encryption mechanism used for GSS wrap based messages is as 
+   follow: 
+    
+    
+        WRAP(Kss, encrypt, direction, export, seq_num, data) 
+        { 
+                struct Token {          // 32 octets 
+                       struct Header { 
+                              OCTET TOK_ID[2]; 
+                              OCTET SGN_ALG[2]; 
+                              OCTET SEAL_ALG[2]; 
+                              OCTET Filler[2]; 
+                       }; 
+                       OCTET SND_SEQ[8]; 
+                       OCTET SGN_CKSUM[8]; 
+  
+Swift                  Category - Informational                      9 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+                       OCTET Confounder[8]; 
+                } Token; 
+         
+         
+                Token.TOK_ID = 02 01; 
+                Token.SGN_SLG = 11 00; 
+                Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; 
+                Token.Filler = ff ff; 
+         
+                // Create the sequence number 
+         
+                if (direction == sender_is_initiator) 
+                { 
+                        memset(&Token.SEND_SEQ[4], 0xff, 4) 
+                } 
+                else if (direction == sender_is_acceptor) 
+                { 
+                        memset(&Token.SEND_SEQ[4], 0, 4) 
+                } 
+                Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; 
+                Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; 
+                Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; 
+                Token.SEND_SEQ[3] = (seq_num & 0x000000ff); 
+                         
+                // Generate random confounder 
+         
+                nonce(&Token.Confounder, 8); 
+         
+                // Derive signing key from session key 
+         
+                Ksign = HMAC(Kss, "signaturekey"); 
+         
+                // Generate checksum of message -  
+                //  SGN_CKSUM + Token.Confounder 
+                //   Key derivation salt = 15 
+         
+                Sgn_Cksum = MD5((int32)15, Token.Header, 
+                                Token.Confounder); 
+         
+                // Derive encryption key for data 
+                //   Key derivation salt = 0 
+         
+                for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;     
+        // XOR 
+                if (exportable) 
+                { 
+                        Kcrypt = HMAC(Klocal, "fortybits", (int32)0); 
+                                    // len includes terminating null 
+                        memset(Kcrypt+7, 0xab, 7); 
+                } 
+                else 
+                { 
+                        Kcrypt = HMAC(Klocal, (int32)0); 
+  
+Swift                  Category - Informational                     10 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+                } 
+         
+                // new encryption key salted with seq 
+         
+                Kcrypt = HMAC(Kcrypt, (int32)seq); 
+         
+                // Encrypt confounder (if encrypting) 
+         
+                if (encrypt) 
+                        RC4(Kcrypt, Token.Confounder); 
+         
+                // Sum the data buffer 
+         
+                Sgn_Cksum += MD5(data);         // Append to checksum 
+         
+                // Encrypt the data (if encrypting) 
+         
+                if (encrypt) 
+                        RC4(Kcrypt, data); 
+         
+                // Save first 8 octets of HMAC Sgn_Cksum 
+         
+                Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 
+                memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 
+         
+                // Derive encryption key for the sequence number 
+                //   Key derivation salt = 0 
+         
+                if (exportable) 
+                { 
+                        Kseq = HMAC(Kss, "fortybits", (int32)0); 
+                                      // len includes terminating null 
+                        memset(Kseq+7, 0xab, 7) 
+                } 
+                else 
+                { 
+                        Kseq = HMAC(Kss, (int32)0); 
+                } 
+                Kseq = HMAC(Kseq, Token.SGN_CKSUM); 
+         
+                // Encrypt the sequence number 
+         
+                RC4(Kseq, Token.SND_SEQ); 
+         
+                // Encrypted message = Token + Data 
+        } 
+    
+   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 
+  
+Swift                  Category - Informational                     11 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
+ 
+ 
+ 
+   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 and Sam Hartman for the valuable 
+   input in refining the descriptions of the functions and their 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 
+ 
+   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 
+  
+Swift                  Category - Informational                     12 
+
+
+
+
+
+
+
+
+                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
+ 
+ 
+   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                     13 
+
+
+
+
+
+
+
+
+                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                     14 
+
+
+
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-foo b/third_party/heimdal/doc/standardisation/draft-foo
new file mode 100644
index 00000000000..8174d4678f8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-foo
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                   Assar Westerlund
+<draft-ietf-cat-krb5-ipv6.txt>                                      SICS
+Internet-Draft                                             October, 1997
+Expire in six months
+
+                           Kerberos over IPv6
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
+   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+   ftp.isi.edu (US West Coast).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+   This document specifies the address types and transport types
+   necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
+
+Specification
+
+   IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
+   order.  The type of IPv6 addresses is twenty-four (24).
+
+   The following addresses (see [RFC1884]) MUST not appear in any
+   Kerberos packet:
+
+   the Unspecified Address
+   the Loopback Address
+   Link-Local addresses
+
+   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
+   2.
+
+
+
+
+Westerlund                                                      [Page 1]
+
+Internet Draft             Kerberos over IPv6              October, 1997
+
+
+   Communication with the KDC over IPv6 MUST be done as in section 8.2.1
+   of [RFC1510].
+
+Discussion
+
+   [RFC1510] suggests using the address family constants in
+   <sys/socket.h> from BSD.  This cannot be done for IPv6 as these
+   numbers have diverged and are different on different BSD-derived
+   systems.  [RFC2133] does not either specify a value for AF_INET6.
+   Thus a value has to be decided and the implementations have to
+   convert between the value used in Kerberos HostAddress and the local
+   AF_INET6.
+
+   There are a few different address types in IPv6, see [RFC1884].  Some
+   of these are used for quite special purposes and it makes no sense to
+   include them in Kerberos packets.
+
+   It is necessary to represent IPv4-mapped addresses as Internet
+   addresses (type 2) to be compatible with Kerberos implementations
+   that only support IPv4.
+
+Security considerations
+
+   This memo does not introduce any known security considerations in
+   addition to those mentioned in [RFC1510].
+
+References
+
+   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+   Authentication Service (V5)", RFC 1510, September 1993.
+
+   [RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
+   (IPv6) Specification", RFC 1883, December 1995.
+
+   [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
+   Architecture", RFC 1884, December 1995.
+
+   [RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
+   Socket Interface Extensions for IPv6", RFC2133, April 1997.
+
+Author's Address
+
+   Assar Westerlund
+   Swedish Institute of Computer Science
+   Box 1263
+   S-164 29  KISTA
+   Sweden
+
+
+
+
+Westerlund                                                      [Page 2]
+
+Internet Draft             Kerberos over IPv6              October, 1997
+
+
+   Phone: +46-8-7521526
+   Fax:   +46-8-7517230
+   EMail: assar@sics.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Westerlund                                                      [Page 3]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-foo.ms b/third_party/heimdal/doc/standardisation/draft-foo.ms
new file mode 100644
index 00000000000..62b109afa52
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-foo.ms
@@ -0,0 +1,136 @@
+.pl 10.0i
+.po 0
+.ll 7.2i
+.lt 7.2i
+.nr LL 7.2i
+.nr LT 7.2i
+.ds LF Westerlund
+.ds RF [Page %]
+.ds CF
+.ds LH Internet Draft
+.ds RH October, 1997
+.ds CH Kerberos over IPv6
+.hy 0
+.ad l
+.in 0
+.ta \n(.luR
+Network Working Group	Assar Westerlund
+<draft-ietf-cat-krb5-ipv6.txt>	SICS
+Internet-Draft	October, 1997
+Expire in six months
+
+.ce
+Kerberos over IPv6
+
+.ti 0
+Status of this Memo
+
+.in 3
+This document is an Internet-Draft.  Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+To view the entire list of current Internet-Drafts, please check
+the "1id-abstracts.txt" listing contained in the Internet-Drafts
+Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
+(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
+Coast), or ftp.isi.edu (US West Coast).
+
+Distribution of this memo is unlimited.  Please send comments to the
+<cat-ietf@mit.edu> mailing list.
+
+.ti 0
+Abstract
+
+.in 3
+This document specifies the address types and transport types
+necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
+
+.ti 0
+Specification
+
+.in 3
+IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
+order.  The type of IPv6 addresses is twenty-four (24).
+
+The following addresses (see [RFC1884]) MUST not appear in any
+Kerberos packet:
+
+the Unspecified Address
+.br
+the Loopback Address
+.br
+Link-Local addresses
+
+IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
+
+Communication with the KDC over IPv6 MUST be done as in section
+8.2.1 of [RFC1510].
+
+.ti 0
+Discussion
+
+.in 3
+[RFC1510] suggests using the address family constants in
+<sys/socket.h> from BSD.  This cannot be done for IPv6 as these
+numbers have diverged and are different on different BSD-derived
+systems.  [RFC2133] does not either specify a value for AF_INET6.
+Thus a value has to be decided and the implementations have to convert
+between the value used in Kerberos HostAddress and the local AF_INET6.
+
+There are a few different address types in IPv6, see [RFC1884].  Some
+of these are used for quite special purposes and it makes no sense to
+include them in Kerberos packets.
+
+It is necessary to represent IPv4-mapped addresses as Internet
+addresses (type 2) to be compatible with Kerberos implementations that
+only support IPv4.
+
+.ti 0
+Security considerations
+
+.in 3
+This memo does not introduce any known security considerations in
+addition to those mentioned in [RFC1510].
+
+.ti 0
+References
+
+.in 3
+[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+Authentication Service (V5)", RFC 1510, September 1993.
+
+[RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
+(IPv6) Specification", RFC 1883, December 1995.
+
+[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
+Architecture", RFC 1884, December 1995.
+
+[RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
+Socket Interface Extensions for IPv6", RFC2133, April 1997.
+
+.ti 0
+Author's Address
+
+Assar Westerlund
+.br
+Swedish Institute of Computer Science
+.br
+Box 1263
+.br
+S-164 29  KISTA
+.br
+Sweden
+
+Phone: +46-8-7521526
+.br
+Fax:   +46-8-7517230
+.br
+EMail: assar@sics.se
diff --git a/third_party/heimdal/doc/standardisation/draft-foo2 b/third_party/heimdal/doc/standardisation/draft-foo2
new file mode 100644
index 00000000000..0fa695f640f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-foo2
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                   Assar Westerlund
+<draft-ietf-cat-krb5-tcp.txt>                                       SICS
+Internet-Draft                                          Johan Danielsson
+November, 1997                                                  PDC, KTH
+Expire in six months
+
+                           Kerberos over TCP
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
+   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+   ftp.isi.edu (US West Coast).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+   This document specifies how the communication should be done between
+   a client and a KDC using Kerberos [RFC1510] with TCP as the transport
+   protocol.
+
+Specification
+
+   This draft specifies an extension to section 8.2.1 of RFC1510.
+
+   A Kerberos server MAY accept requests on TCP port 88 (decimal).
+
+   The data sent from the client to the KDC should consist of 4 bytes
+   containing the length, in network byte order, of the Kerberos
+   request, followed by the request (AS-REQ or TGS-REQ) itself.  The
+   reply from the KDC should consist of the length of the reply packet
+   (4 bytes, network byte order) followed by the packet itself (AS-REP,
+   TGS-REP, or KRB-ERROR).
+
+
+
+
+Westerlund, Danielsson                                          [Page 1]
+
+Internet Draft             Kerberos over TCP              November, 1997
+
+
+   C->S: Open connection to TCP port 88 at the server
+   C->S: length of request
+   C->S: AS-REQ or TGS-REQ
+   S->C: length of reply
+   S->C: AS-REP, TGS-REP, or KRB-ERROR
+
+Discussion
+
+   Even though the preferred way of sending kerberos packets is over UDP
+   there are several occasions when it's more practical to use TCP.
+
+   Mainly, it's usually much less cumbersome to get TCP through
+   firewalls than UDP.
+
+   In theory, there's no reason for having explicit length fields, that
+   information is already encoded in the ASN1 encoding of the Kerberos
+   packets.  But having explicit lengths makes it unnecessary to have to
+   decode the ASN.1 encoding just to know how much data has to be read.
+
+   Another way of signaling the end of the request of the reply would be
+   to do a half-close after the request and a full-close after the
+   reply.  This does not work well with all kinds of firewalls.
+
+Security considerations
+
+   This memo does not introduce any known security considerations in
+   addition to those mentioned in [RFC1510].
+
+References
+
+   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+   Authentication Service (V5)", RFC 1510, September 1993.
+
+Authors' Addresses
+
+   Assar Westerlund
+   Swedish Institute of Computer Science
+   Box 1263
+   S-164 29  KISTA
+   Sweden
+
+   Phone: +46-8-7521526
+   Fax:   +46-8-7517230
+   EMail: assar@sics.se
+
+   Johan Danielsson
+   PDC, KTH
+   S-100 44  STOCKHOLM
+
+
+
+Westerlund, Danielsson                                          [Page 2]
+
+Internet Draft             Kerberos over TCP              November, 1997
+
+
+   Sweden
+
+   Phone: +46-8-7907885
+   Fax:   +46-8-247784
+   EMail: joda@pdc.kth.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Westerlund, Danielsson                                          [Page 3]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-foo2.ms b/third_party/heimdal/doc/standardisation/draft-foo2.ms
new file mode 100644
index 00000000000..7e0fa0a6281
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-foo2.ms
@@ -0,0 +1,145 @@
+.pl 10.0i
+.po 0
+.ll 7.2i
+.lt 7.2i
+.nr LL 7.2i
+.nr LT 7.2i
+.ds LF Westerlund, Danielsson
+.ds RF [Page %]
+.ds CF
+.ds LH Internet Draft
+.ds RH November, 1997
+.ds CH Kerberos over TCP
+.hy 0
+.ad l
+.in 0
+.ta \n(.luR
+.nf
+Network Working Group	Assar Westerlund
+<draft-ietf-cat-krb5-tcp.txt>	SICS
+Internet-Draft	Johan Danielsson
+November, 1997	PDC, KTH
+Expire in six months
+.fi
+
+.ce
+Kerberos over TCP
+
+.ti 0
+Status of this Memo
+
+.in 3
+This document is an Internet-Draft.  Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+To view the entire list of current Internet-Drafts, please check
+the "1id-abstracts.txt" listing contained in the Internet-Drafts
+Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
+(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
+Coast), or ftp.isi.edu (US West Coast).
+
+Distribution of this memo is unlimited.  Please send comments to the
+<cat-ietf@mit.edu> mailing list.
+
+.ti 0
+Abstract
+
+.in 3
+This document specifies how the communication should be done between a
+client and a KDC using Kerberos [RFC1510] with TCP as the transport
+protocol.
+
+.ti 0
+Specification
+
+This draft specifies an extension to section 8.2.1 of RFC1510. 
+
+A Kerberos server MAY accept requests on TCP port 88 (decimal).
+
+The data sent from the client to the KDC should consist of 4 bytes
+containing the length, in network byte order, of the Kerberos request,
+followed by the request (AS-REQ or TGS-REQ) itself.  The reply from
+the KDC should consist of the length of the reply packet (4 bytes,
+network byte order) followed by the packet itself (AS-REP, TGS-REP, or
+KRB-ERROR).
+
+.nf
+C->S: Open connection to TCP port 88 at the server
+C->S: length of request
+C->S: AS-REQ or TGS-REQ
+S->C: length of reply
+S->C: AS-REP, TGS-REP, or KRB-ERROR
+.fi
+
+.ti 0
+Discussion
+
+Even though the preferred way of sending kerberos packets is over UDP
+there are several occasions when it's more practical to use TCP.
+
+Mainly, it's usually much less cumbersome to get TCP through firewalls
+than UDP.
+
+In theory, there's no reason for having explicit length fields, that
+information is already encoded in the ASN1 encoding of the Kerberos
+packets.  But having explicit lengths makes it unnecessary to have to
+decode the ASN.1 encoding just to know how much data has to be read.
+
+Another way of signaling the end of the request of the reply would be
+to do a half-close after the request and a full-close after the reply.
+This does not work well with all kinds of firewalls.
+
+.ti 0
+Security considerations
+
+.in 3
+This memo does not introduce any known security considerations in
+addition to those mentioned in [RFC1510].
+
+.ti 0
+References
+
+.in 3
+[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+Authentication Service (V5)", RFC 1510, September 1993.
+
+.ti 0
+Authors' Addresses
+
+Assar Westerlund
+.br
+Swedish Institute of Computer Science
+.br
+Box 1263
+.br
+S-164 29  KISTA
+.br
+Sweden
+
+Phone: +46-8-7521526
+.br
+Fax:   +46-8-7517230
+.br
+EMail: assar@sics.se
+
+Johan Danielsson
+.br
+PDC, KTH
+.br
+S-100 44  STOCKHOLM
+.br
+Sweden
+
+Phone: +46-8-7907885
+.br
+Fax:   +46-8-247784
+.br
+EMail: joda@pdc.kth.se
diff --git a/third_party/heimdal/doc/standardisation/draft-foo3 b/third_party/heimdal/doc/standardisation/draft-foo3
new file mode 100644
index 00000000000..2b8b7bb5775
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-foo3
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                   Assar Westerlund
+<draft-ietf-cat-krb5-firewalls.txt>                                 SICS
+Internet-Draft                                          Johan Danielsson
+November, 1997                                                  PDC, KTH
+Expire in six months
+
+                         Kerberos vs firewalls
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   To view the entire list of current Internet-Drafts, please check the
+   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
+   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+   ftp.isi.edu (US West Coast).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+Introduction
+
+   Kerberos[RFC1510] is a protocol for authenticating parties
+   communicating over insecure networks.
+
+   Firewalling is a technique for achieving an illusion of security by
+   putting restrictions on what kinds of packets and how these are sent
+   between the internal (so called "secure") network and the global (or
+   "insecure") Internet.
+
+Definitions
+
+   client: the user, process, and host acquiring tickets from the KDC
+   and authenticating itself to the kerberised server.
+
+   KDC: the Kerberos Key Distribution Center
+
+
+
+
+Westerlund, Danielsson                                          [Page 1]
+
+Internet Draft           Kerberos vs firewalls            November, 1997
+
+
+   Kerberised server: the server using Kerberos to authenticate the
+   client, for example telnetd.
+
+Firewalls
+
+   A firewall is usually placed between the "inside" and the "outside"
+   networks, and is supposed to protect the inside from the evils on the
+   outside.  There are different kinds of firewalls.  The main
+   differences are in the way they forward packets.
+
+   o+  The most straight forward type is the one that just imposes
+      restrictions on incoming packets. Such a firewall could be
+      described as a router that filters packets that match some
+      criteria.
+
+   o+  They may also "hide" some or all addresses on the inside of the
+      firewall, replacing the addresses in the outgoing packets with the
+      address of the firewall (aka network address translation, or NAT).
+      NAT can also be used without any packet filtering, for instance
+      when you have more than one host sharing a single address (for
+      example, with a dialed-in PPP connection).
+
+   There are also firewalls that does NAT both on the inside and the
+   outside (a server on the inside will see this as a connection from
+   the firewall).
+
+   o+  A third type is the proxy type firewall, that parses the contents
+      of the packets, basically acting as a server to the client, and as
+      a client to the server (man-in-the-middle). If Kerberos is to be
+      used with this kind of firewall, a protocol module that handles
+      KDC requests has to be written.
+
+   This type of firewall might also cause extra trouble when used with
+   kerberised versions of protocols that the proxy understands, in
+   addition to the ones mentioned below. This is the case with the FTP
+   Security Extensions [RFC2228], that adds a new set of commands to the
+   FTP protocol [RFC959], for integrity, confidentiality, and privacy
+   protecting commands. When transferring data, the FTP protocol uses a
+   separate data channel, and an FTP proxy will have to look out for
+   commands that start a data transfer. If all commands are encrypted,
+   this is impossible. A protocol that doesn't suffer from this is the
+   Telnet Authentication Option [RFC1416] that does all authentication
+   and encryption in-bound.
+
+Scenarios
+
+   Here the different scenarios we have considered are described, the
+   problems they introduce and the proposed ways of solving them.
+
+
+
+Westerlund, Danielsson                                          [Page 2]
+
+Internet Draft           Kerberos vs firewalls            November, 1997
+
+
+   Combinations of these can also occur.
+
+ Client behind firewall
+
+   This is the most typical and common scenario.  First of all the
+   client needs some way of communicating with the KDC.  This can be
+   done with whatever means and is usually much simpler when the KDC is
+   able to communicate over TCP.
+
+   Apart from that, the client needs to be sure that the ticket it will
+   acquire from the KDC can be used to authenticate to a server outside
+   its firewall.  For this, it needs to add the address(es) of potential
+   firewalls between itself and the KDC/server, to the list of its own
+   addresses when requesting the ticket.  We are not aware of any
+   protocol for determining this set of addresses, thus this will have
+   to be manually configured in the client.
+
+   The client could also request a ticket with no addresses, but some
+   KDCs and servers might not accept such a ticket.
+
+   With the ticket in possession, communication with the kerberised
+   server will not need to be any different from communicating between a
+   non-kerberised client and server.
+
+ Kerberised server behind firewall
+
+   The kerberised server does not talk to the KDC at all so nothing
+   beyond normal firewall-traversal techniques for reaching the server
+   itself needs to be applied.
+
+   The kerberised server needs to be able to retrieve the original
+   address (before its firewall) that the request was sent for.  If this
+   is done via some out-of-band mechanism or it's directly able to see
+   it doesn't matter.
+
+ KDC behind firewall
+
+   The same restrictions applies for a KDC as for any other server.
+
+Specification
+
+Security considerations
+
+   This memo does not introduce any known security considerations in
+   addition to those mentioned in [RFC1510].
+
+References
+
+
+
+
+Westerlund, Danielsson                                          [Page 3]
+
+Internet Draft           Kerberos vs firewalls            November, 1997
+
+
+   [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
+   RFC 969, October 1985
+
+   [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
+   February 1993.
+
+   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+   Authentication Service (V5)", RFC 1510, September 1993.
+
+   [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
+   RFC2228, October 1997.
+
+Authors' Addresses
+
+   Assar Westerlund
+   Swedish Institute of Computer Science
+   Box 1263
+   S-164 29  KISTA
+   Sweden
+
+   Phone: +46-8-7521526
+   Fax:   +46-8-7517230
+   EMail: assar@sics.se
+
+   Johan Danielsson
+   PDC, KTH
+   S-100 44  STOCKHOLM
+   Sweden
+
+   Phone: +46-8-7907885
+   Fax:   +46-8-247784
+   EMail: joda@pdc.kth.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Westerlund, Danielsson                                          [Page 4]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-foo3.ms b/third_party/heimdal/doc/standardisation/draft-foo3.ms
new file mode 100644
index 00000000000..c024ca355cd
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-foo3.ms
@@ -0,0 +1,260 @@
+.\" even if this file is called .ms, it's using the me macros.
+.\" to format try something like `nroff -me'
+.\" level 2 heading
+.de HH
+.$p "\\$2" "" "\\$1"
+.$0 "\\$2"
+..
+.\" make sure footnotes produce the right thing with nroff
+.ie t \
+\{\
+.ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
+.ds } \s0\v'0.4m'
+.\}
+.el \
+\{\
+.ds { [
+.ds } ]
+.\}
+.ds * \\*{\\n($f\\*}\k*
+.\" page footer
+.fo 'Westerlund, Danielsson''[Page %]'
+.\" date
+.ds RH \*(mo, 19\n(yr
+.\" left margin
+.nr lm 6
+.\" heading indent per level
+.nr si 3n
+.\" footnote indent
+.nr fi 0
+.\" paragraph indent
+.nr po 0
+.\" don't hyphenate
+.hy 0
+.\" left adjustment
+.ad l
+.\" indent 0
+.in 0
+.\" line length 16cm and page length 25cm (~10 inches)
+.ll 16c
+.pl 25c
+.ta \n(.luR
+.nf
+Network Working Group	Assar Westerlund
+<draft-ietf-cat-krb5-firewalls.txt>	SICS
+Internet-Draft	Johan Danielsson
+\*(RH	PDC, KTH
+Expire in six months	
+.fi
+
+.\" page header, has to be set here so it won't appear on page 1
+.he 'Internet Draft'Kerberos vs firewalls'\*(RH'
+.ce
+.b "Kerberos vs firewalls"
+
+.HH 1 "Status of this Memo"
+.lp
+This document is an Internet-Draft.  Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas,
+and its working groups.  Note that other groups may also distribute
+working documents as Internet-Drafts.
+.lp
+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 \*(lqwork in progress.\*(rq
+.lp
+To view the entire list of current Internet-Drafts, please check the
+\*(lq1id-abstracts.txt\*(rq listing contained in the Internet-Drafts
+Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
+munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ftp.isi.edu (US West Coast).
+.lp
+Distribution of this memo is unlimited.  Please send comments to the
+<cat-ietf@mit.edu> mailing list.
+.HH 1 "Abstract"
+.lp
+Kerberos and firewalls both deal with security, but doesn't get along
+very well. This memo discusses ways to use Kerberos in a firewalled
+environment.
+.HH 1 "Introduction"
+.lp
+Kerberos[RFC1510]
+.(d
+[RFC1510]
+Kohl, J. and Neuman, C., \*(lqThe Kerberos Network Authentication
+Service (V5)\*(rq, RFC 1510, September 1993.
+.)d
+is a protocol for authenticating parties communicating over insecure
+networks.  Firewalling is a technique for achieving an illusion of
+security by putting restrictions on what kinds of packets and how
+these are sent between the internal (so called \*(lqsecure\*(rq)
+network and the global (or \*(lqinsecure\*(rq) Internet.  The problems
+with firewalls are many, but to name a few:
+.np
+Firewalls usually doesn't allow people to use UDP. The reason for this
+is that UDP is (by firewall advocates) considered insecure. This
+belief is probably based on the fact that many \*(lqinsecure\*(rq
+protocols (like NFS) use UDP. UDP packets are also considered easy to
+fake.
+.np
+Firewalls usually doesn't allow people to connect to arbitrary ports,
+such as the ports used when talking to the KDC.
+.np
+In many non-computer organisations, the computer staff isn't what
+you'd call \*(lqwizards\*(rq; a typical case is an academic
+institution, where someone is taking care of the computers part time,
+and is doing research the rest of the time. Adding a complex device
+like a firewall to an environment like this, often leads to poorly run
+systems that is more a hindrance for the legitimate users than to
+possible crackers.
+.lp
+The easiest way to deal with firewalls is to ignore them, however in
+some cases this just isn't possible. You might have users that are
+stuck behind a firewall, but also has to access your system, or you
+might find yourself behind a firewall, for instance when out
+travelling.
+.lp
+To make it possible for people to use Kerberos from behind a firewall,
+there are several things to consider.
+.(q
+.i
+Add things to do when stuck behind a firewall, like talking about the
+problem with local staff, making them open some port in the firewall,
+using some other port, or proxy.
+.r
+.)q
+.HH 1 "Firewalls"
+.lp
+A firewall is usually placed between the \*(lqinside\*(rq and the
+\*(lqoutside\*(rq networks, and is supposed to protect the inside from the
+evils on the outside.  There are different kinds of firewalls.  The
+main differences are in the way they forward (or doesn't) packets.
+.ip \(bu
+The most straight forward type is the one that just imposes
+restrictions on incoming packets. Such a firewall could be described
+as a router that filters packets that match some criteria.
+.ip \(bu
+They may also \*(lqhide\*(rq some or all addresses on the inside of the
+firewall, replacing the addresses in the outgoing packets with the
+address of the firewall (aka network address translation, or NAT). NAT
+can also be used without any packet filtering, for instance when you
+have more than one host sharing a single address (e.g with a dialed-in
+PPP connection).
+.ip
+There are also firewalls that does NAT both on the inside and the
+outside (a server on the inside will see this as a connection from the
+firewall).
+.ip \(bu
+A third type is the proxy type firewall, that parses the contents of
+the packets, basically acting as a server to the client, and as a
+client to the server (man-in-the-middle). If Kerberos is to be used
+with this kind of firewall, a protocol module that handles KDC
+requests has to be written\**.
+.(f
+\**Instead of writing a new module for Kerberos, it can be possible to
+hitch a ride on some other protocol, that's already beeing handled by
+the proxy.
+.)f
+.lp
+The last type of firewall might also cause extra trouble when used
+with kerberised versions of protocols that the proxy understands, in
+addition to the ones mentioned below. This is the case with the FTP
+Security Extensions [RFC2228],
+.(d
+[RFC2228]
+Horowitz, M. and Lunt, S., \*(lqFTP Security Extensions\*(rq, RFC2228,
+October 1997.
+.)d
+that adds a new set of commands to the FTP protocol [RFC959],
+.(d
+[RFC959] Postel, J. and Reynolds, J., \*(lqFile Transfer Protocol
+(FTP)\*(rq, RFC 969, October 1985
+.)d
+for integrity, confidentiality, and privacy protecting commands, and
+data. When transferring data, the FTP protocol uses a separate data
+channel, and an FTP proxy will have to look out for commands that
+start a data transfer. If all commands are encrypted, this is
+impossible. A protocol that doesn't suffer from this is the Telnet
+Authentication Option [RFC1416]
+.(d
+[RFC1416]
+Borman, D., \*(lqTelnet Authentication Option\*(rq, RFC 1416, February
+1993.
+.)d
+that does all
+authentication and encryption in-bound.
+.HH 1 "Scenarios"
+.lp
+Here the different scenarios we have considered are described, the
+problems they introduce and the proposed ways of solving them.
+Combinations of these can also occur.
+.HH 2 "Client behind firewall"
+.lp
+This is the most typical and common scenario.  First of all the client
+needs some way of communicating with the KDC.  This can be done with
+whatever means and is usually much simpler when the KDC is able to
+communicate over TCP.
+.lp
+Apart from that, the client needs to be sure that the ticket it will
+acquire from the KDC can be used to authenticate to a server outside
+its firewall.  For this, it needs to add the address(es) of potential
+firewalls between itself and the KDC/server, to the list of its own
+addresses when requesting the ticket.  We are not aware of any
+protocol for determining this set of addresses, thus this will have to
+be manually configured in the client.
+.lp
+The client could also request a ticket with no addresses. This is not
+a recommended way to solve this problem. The address was put into the
+ticket to make it harder to use a stolen ticket.  A ticket without
+addresses will therefore be less \*(lqsecure.\*(rq RFC1510 also says that
+the KDC may refuse to issue, and the server may refuse to accept an
+address-less ticket.
+.lp
+With the ticket in possession, communication with the kerberised
+server will not need to be any different from communicating between a
+non-kerberised client and server.
+.HH 2 "Kerberised server behind firewall"
+.lp
+The kerberised server does not talk to the KDC at all, so nothing
+beyond normal firewall-traversal techniques for reaching the server
+itself needs to be applied.
+.lp
+If the firewall rewrites the clients address, the server will have to
+use some other (possibly firewall specific) protocol to retrieve the
+original address. If this is not possible, the address field will have
+to be ignored. This has the same effect as if there were no addresses
+in the ticket (see the discussion above).
+.HH 2 "KDC behind firewall"
+.lp
+The KDC is in this respect basically just like any other server.
+.\" .uh "Specification"
+.HH 1 "Security considerations"
+.lp
+Since the whole network behind a NAT-type firewall looks like one
+computer from the outside, any security added by the addresses in the
+ticket will be lost.
+.HH 1 "References"
+.lp
+.pd
+.HH 1 "Authors' Addresses"
+.lp
+.nf
+Assar Westerlund
+Swedish Institute of Computer Science
+Box 1263
+S-164 29 KISTA
+.sp
+Phone: +46-8-7521526
+Fax: +46-8-7517230
+EMail: assar@sics.se
+.sp 2
+Johan Danielsson
+Center for Parallel Computers
+KTH
+S-100 44 STOCKHOLM
+.sp
+Phone: +46-8-7906356
+Fax: +46-8-247784
+EMail: joda@pdc.kth.se
+.fi
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-hartman-gss-naming-00.txt b/third_party/heimdal/doc/standardisation/draft-hartman-gss-naming-00.txt
new file mode 100644
index 00000000000..9141e339dfb
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-hartman-gss-naming-00.txt
@@ -0,0 +1,561 @@
+
+
+Network Working Group                                         S. Hartman
+Internet-Draft                                                       MIT
+Expires: January 10, 2005                                  July 12, 2004
+
+
+           GSSAPI Mechanisms without a Single Canonical Name
+                    draft-hartman-gss-naming-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on January 10, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+   The Generic Security Services API (GSSAPI) uses name-based
+   authorization.  GSSAPI authenticates two named parties to each other.
+   Names can be stored on access control lists to make authorization
+   decisions.  Advances in security mechanisms require this model to be
+   extended.  Some mechanisms such as public-key mechanisms do not have
+   a single name to be used. Other mechanisms such as Kerberos allow
+   names to change as people move around organizations.  This document
+   proposes expanding the definition of GSSAPI names to deal with these
+   situations.
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 1]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+1.  Introduction
+
+   The Generic  Security Services API [1] provides a function called
+   gss_export_name that will flatten a GSSAPI name  into a binary blob
+   suitable for comparisons.   This binary blob can be stored on ACLs
+   and then authorization decisions can be made simply by comparing the
+   name exported from a newly accepted context to the name on the ACL.
+
+   As a side effect of this name-based authorization model, each
+   mechanism name needs to be able to be represented in a single
+   canonical form and anyone importing that name needs to be able to
+   retrieve the canonical form.
+
+   Several security mechanisms have been proposed for which this naming
+   architecture is too restrictive.  In some cases it is not always
+   possible to canonicalize any name that is imported.  In other cases
+   there is no single canonical name.  In addition, there is a desire to
+   have more complex authorization models  in GSSAPI than the current
+   name based authorization model.
+
+   This draft discusses two different cases where the current GSSAPI
+   naming seems inadequate.  Then, an extension to GSSAPI naming to meet
+   these concerns is sketched.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 2]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+2.  Kerberos Naming
+
+   The Kerberos Referals draft [2] proposes a new type of Kerberos name
+   called an enterprise name. The intent is that the enterprise name is
+   an alias that the user knows for themselves and can use to login.
+   The Kerberos KDC translates this name into a normal Kerberos
+   principal and gives the user tickets for this principal.  This normal
+   principal is used for authorization.  The intent is that the
+   enterprise name tracks the user as they move throughout the
+   organization, even if they move to parts of the organization that
+   have different naming policies.    The name they type at login
+   remains constant, but the Kerberos principal used to authenticate
+   them to services changes.
+
+   Performing a mapping from enterprise  name to principal name is not
+   generally possible for unauthenticated services.  So in order to
+   canonicalize an enterprise name to get a principal, a service must
+   have credentials.    However it may not be desirable to allow
+   services to map enterprise names to principal names in the general
+   case.   Also, Kerberos does not (and does not plan to) provide a
+   mechanism for mapping enterprise names to principals besides
+   authentication as the enterprise name.  So any such mapping would be
+   vendor-specific.  With this feature in Kerberos, it is not possible
+   to implement gss_canonicalize_name for enterprise name types.
+
+   Another issue arises with enterprise names.  IN some cases it would
+   be desirable to put   the enterprise name on the ACL instead of a
+   principal name.  Thus, it would be desirable to include the
+   enterprise name in the name exported by gss_export_name.  However
+   then the exported name would change whenever the mapping changed,
+   defeating the purpose  of including the enterprise name.  So in some
+   cases it would be desirable to have the exported name be based on the
+   enterprise name and in others based on the principal name, but this
+   is not currently possible.
+
+   Another development also complicates GSSAPI naming for Kerberos.
+   Several vendors have been looking at mechanisms to include group
+   membership information in Kerberos authorization data.   Then it is
+   desirable to put these group names on ACLs.  Again, GSSAPI currently
+   has no mechanism to use this information.
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 3]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+3.  X.509 Names
+
+   X.509 names are at least as complex as Kerberos names.  It seems like
+   you might want to use the subject name as the name to be exported in
+   a GSSAPI mechanism.  However RFC 3280 [3] does not even require the
+   subject name to be a non-empty sequence.  Instead there are cases
+   where the subjectAltName extension is the only thing to identify the
+   subject of the certificate.  As in the case of Kerberos group
+   memberships, there may be many subjectAltName extensions available in
+   a certificate.  Different applications will care about different
+   extensions.   Thus there is no single value that can be  defined as
+   the exported GSSAPI name that will be generally useful.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 4]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+4.  Composite Names
+
+   I propose extending the concept of a GSSAPI name  to include a
+   collection of attributes.  Each attribute would be an octet-string
+   labeled by an OID.  Examples of attributes would include Kerberos
+   enterprise names, group memberships in an authorization
+   infrastructure, Kerberos authorization data attributes and
+   subjectAltName attributes in a certificate.  Several new operations
+   would be needed:
+   1.  Add attribute to name
+   2.  Query attributes of name
+   3.  Query values of an attribute
+   4.  Delete an attribute from a name
+
+4.1  Usage of Name Attributes
+
+   Since attributes are part of GSSAPI names, the acceptor can retrieve
+   the attributes of the initiator's name from the context.   These
+   attributes can then be used for authorization.
+
+   Most name attributes will probably not come from explicit operations
+   to add attributes to a name.   Instead, name attributes will probably
+   come from mechanism specific credentials.    Mechanism specific
+   naming and group membership can be  mapped into name attributes by
+   the mechanism implementation.    The specific form of this mapping
+   will general require protocol specification for each mechanism.
+
+4.2  Open issues
+
+   This section describes parts of the proposal to add attributes to
+   names that will need to be explored before the proposal can become a
+   protocol specification.
+
+   Are mechanisms expected to be able to carry arbitrary name attributes
+   as part of a context establishment?   At first it seems like this
+   would be desirable.  However the point of GSSAPI is to establish an
+   authenticated context between two peers.   In particular, a context
+   authenticates two named entities to each other.  The names of these
+   entities and attributes associated with these names will be used for
+   authorization decisions.  If an initiator or acceptor is allowed to
+   assert name attributes and the authenticity of these assertions is
+   not validated by the mechanisms, then security problems may result.
+   On the other hand, requiring that name attributes be mechanism
+   specific and only be carried by mechanisms that understand the name
+   attributes and can validate them compromises GSSAPI's place as a
+   generic API. Application authors would be forced to understand
+   mechanism-specific attributes to make authorization decisions.   In
+   addition if mechanisms are not required to transport arbitrary
+
+
+
+Hartman                 Expires January 10, 2005                [Page 5]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+   attributes, then application authors will need to deal with different
+   implementations of the same mechanism that support different sets of
+   name attributes.
+
+   Another related question is how will name attributes be mapped into
+   their mechanism-specific forms.  For example it would be desirable to
+   map many  Kerberos authorization data elements into name attributes.
+   For example in the case of the Microsoft PAC, it would be desirable
+   for some applications to get the entire PAC.  However in many cases,
+   the specific lists of security IDs contained in the PAC would be more
+   directly useful to an application.  So there may not be a good
+   one-to-one mapping between the mechanism-specific elements and the
+   representation desirable at the GSSAPI layer.
+
+   Specific name matching rules need to be developed.  How do names with
+   attributes compare?  What is the effect of a name attribute on a
+   target name in gss_accept_sec_context?
+
+4.3  Name Attributes Instead of Credential Extensions
+
+   An alternative to this proposal is to extend GSSAPI credentials  with
+   extensions labeled by OIDs.  Interfaces would be needed to manipulate
+   these credential extensions and to retrieve the credential extensions
+   for credentials used to establish a context.  Even if name attributes
+   are used, credential extensions may be useful for other unrelated
+   purposes.
+
+   It is possible to solve problems discussed in this document using
+   some credential extension mechanism.  Doing so will have many of the
+   same open issues as discussed in this name attributes proposal.  The
+   main advantage of a credential extensions proposal is that  it avoids
+   specifying how name attributes interact with name comparison or
+   target names.
+
+   The primary advantage of the name attributes proposal over credential
+   extensions is that name attributes seem to fit better into the GSSAPI
+   authorization model.    Names are already available at all points
+   when authorization decisions are made.  In addition, for many
+   mechanisms the sort of information carried as name attributes will
+   also be carried as part of the name in the mechanism
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 6]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+5.  Handling gss_export_name
+
+   For many mechanisms, there will be  an obvious choice to use for the
+   name exported by gss_export_name.  For example in the case of
+   Kerberos, the principal name can continue to be used as the exported
+   name.  This will allow applications depending on existing GSSAPI
+   name-based authorization to continue to work. However it is probably
+   desirable to allow GSSAPI mechanisms for which gss_export_name cannot
+   meaningfully be defined.  The behavior of gss_export_name in such
+   cases should probably be to return some error.  Such mechanisms may
+   not work with existing applications and cannot conform to the current
+   version of the GSSAPI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 7]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+6.  Security Considerations
+
+   GSSAPI sets up a security context between two named parties. The
+   GSSAPI names are security assertions that are authenticated by the
+   context establishment process.  As such  the GSS naming architecture
+   is critical to the security of GSSAPI.
+
+   Currently GSSAPI uses a simplistic naming model for authorization.
+   Names can be compared  against a set of names on an access control
+   list.  This architecture is relatively simple and its security
+   properties are well understood.  However it does not provide the
+   flexibility and feature set for future deployments of GSSAPI.
+
+   This proposal will significantly increase the complexity of the GSS
+   naming architecture.  As this proposal is fleshed out, we need to
+   consider ways of managing security exposures created by this
+   increased complexity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 8]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+7.  Acknowledgements
+
+   John Brezak, Paul Leach and Nicolas Williams all participated in
+   discussions that defined the problem this proposal attempts to solve.
+   Nicolas Williams and I discussed details of proposals to solve this
+   problem.   However the details and open issues presented here have
+   only been reviewed by me and so I am responsible for their errors.
+
+8  Informative References
+
+   [1]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [2]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
+        KDC Referrals to locate Kerberos realms",
+        draft-ietf-krb-wg-kerberos-referals-03.txt (work in progress),
+        2004.
+
+   [3]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and Certificate Revocation
+        List (CRL) Profile", rfc 3280, April 2002.
+
+
+Author's Address
+
+   Sam Hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 10, 2005                [Page 9]
+
+Internet-Draft            GSS Name Attributes                  July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights. Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard. Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004). This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                 Expires January 10, 2005               [Page 10]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-hartman-gss-naming-01.txt b/third_party/heimdal/doc/standardisation/draft-hartman-gss-naming-01.txt
new file mode 100644
index 00000000000..544eba2845f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-hartman-gss-naming-01.txt
@@ -0,0 +1,674 @@
+
+
+
+Network Working Group                                         S. Hartman
+Internet-Draft                                                       MIT
+Expires: April 24, 2005                                 October 24, 2004
+
+
+           GSSAPI Mechanisms without a Single Canonical Name
+                    draft-hartman-gss-naming-01.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on April 24, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The Generic Security Services API (GSSAPI) provides a naming
+   architecture that supports  name-based authorization.  GSSAPI
+   authenticates two named parties to each other.  Names can be stored
+   on access control lists to make authorization decisions.  Advances in
+   security mechanisms and the way implementers wish to use GSSAPI
+   require this model to be extended.  Some mechanisms such as
+   public-key mechanisms do not have a single name to be used.  Other
+   mechanisms such as Kerberos allow names to change as people move
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 1]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+   around organizations.  This document proposes expanding the
+   definition of GSSAPI names to deal with these situations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 2]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+1.  Introduction
+
+   The Generic  Security Services API [1] provides a function called
+   gss_export_name that will flatten a GSSAPI name  into a binary blob
+   suitable for comparisons.  This binary blob can be stored on ACLs and
+   then authorization decisions can be made simply by comparing the name
+   exported from a newly accepted context to the name on the ACL.
+
+   As a side effect of this model, each mechanism name needs to be able
+   to be represented in a single canonical form and anyone importing
+   that name needs to be able to retrieve the canonical form.
+
+   Several security mechanisms have been proposed for which this naming
+   architecture is too restrictive.  In some cases it is not always
+   possible to canonicalize any name that is imported.  In other cases
+   there is no single canonical name.  In addition, there is a desire to
+   have more complex authorization models  in GSSAPI than the current
+   name based authorization model.
+
+   This draft discusses two different cases where the current GSSAPI
+   naming seems inadequate.  Two proposals that have been discussed
+   within the IETF Kitten community are discussed.  Finally, the
+   problems that need to be resolved to adopt either of these proposals
+   are discussed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 3]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+2.  Kerberos Naming
+
+   The Kerberos Referrals draft [2] proposes a new type of Kerberos name
+   called an enterprise name.  The intent is that the enterprise name is
+   an alias that the user knows for themselves and can use to login.
+   The Kerberos KDC translates this name into a normal Kerberos
+   principal and gives the user tickets for this principal.  This normal
+   principal is used for authorization.  The intent is that the
+   enterprise name tracks the user as they move throughout the
+   organization, even if they move to parts of the organization that
+   have different naming policies.  The name they type at login remains
+   constant, but the Kerberos principal used to authenticate them to
+   services changes.
+
+   Performing a mapping from enterprise  name to principal name is not
+   generally possible for unauthenticated services.  So in order to
+   canonicalize an enterprise name to get a principal, a service must
+   have credentials.  However it may not be desirable to allow services
+   to map enterprise names to principal names in the general case.
+   Also, Kerberos does not (and does not plan to) provide a mechanism
+   for mapping enterprise names to principals besides authentication as
+   the enterprise name.  So any such mapping would be vendor-specific.
+   With this feature in Kerberos, it is not possible to implement
+   gss_canonicalize_name for enterprise name types.
+
+   Another issue arises with enterprise names.  IN some cases it would
+   be desirable to put   the enterprise name on the ACL instead of a
+   principal name.  Thus, it would be desirable to include the
+   enterprise name in the name exported by gss_export_name.  However
+   then the exported name would change whenever the mapping changed,
+   defeating the purpose  of including the enterprise name.  So in some
+   cases it would be desirable to have the exported name be based on the
+   enterprise name and in others based on the principal name, but this
+   is not currently possible.
+
+   Another development also complicates GSSAPI naming for Kerberos.
+   Several vendors have been looking at mechanisms to include group
+   membership information in Kerberos authorization data.  It is
+   desirable to put these group names on ACLs.  Again, GSSAPI currently
+   has no mechanism to use this information.
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 4]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+3.  X.509 Names
+
+   X.509 names are at least as complex as Kerberos names.  It seems like
+   you might want to use the subject name as the name to be exported in
+   a GSSAPI mechanism.  However RFC 3280 [3] does not even require the
+   subject name to be a non-empty sequence.  Instead there are cases
+   where the subjectAltName extension is the only thing to identify the
+   subject of the certificate.  As in the case of Kerberos group
+   memberships, there may be many subjectAltName extensions available in
+   a certificate.  Different applications will care about different
+   extensions.  Thus there is no single value that can be  defined as
+   the exported GSSAPI name that will be generally useful.
+
+   A profile of a particular X.509  GSSAPI mechanism could require a
+   specific name be used.  However this would limit that mechanism to
+   require a particular type of certificate.  There is interest in being
+   able to use arbitrary X.509 certificates with GSSAPI for some
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 5]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+4.  Composite Names
+
+   One proposal to solve these problems is to extend the concept of a
+   GSSAPI name to include a set of name attributes.  Each attribute
+   would be an octet-string labeled by an OID.  Examples of attributes
+   would include Kerberos enterprise names, group memberships in an
+   authorization infrastructure, Kerberos authorization data attributes
+   and subjectAltName attributes in a certificate.  Several new
+   operations would be needed:
+   1.  Add attribute to name
+   2.  Query attributes of name
+   3.  Query values of an attribute
+   4.  Delete an attribute from a name
+
+4.1  Usage of Name Attributes
+
+   Since attributes are part of GSSAPI names, the acceptor can retrieve
+   the attributes of the initiator's name from the context.  These
+   attributes can then be used for authorization.
+
+   Most name attributes will probably not come from explicit operations
+   to add attributes to a name.  Instead, name attributes will probably
+   come from mechanism specific credentials.  Mechanism specific naming
+   and group membership can be  mapped into name attributes by the
+   mechanism implementation.  The specific form of this mapping will
+   general require protocol specification for each mechanism.
+
+4.2  Open issues
+
+   This section describes parts of the proposal to add attributes to
+   names that will need to be explored before the proposal can become a
+   protocol specification.
+
+   Are mechanisms expected to be able to carry arbitrary name attributes
+   as part of a context establishment?   At first it seems like this
+   would be desirable.  However the point of GSSAPI is to establish an
+   authenticated context between two peers.  In particular, a context
+   authenticates two named entities to each other.  The names of these
+   entities and attributes associated with these names will be used for
+   authorization decisions.  If an initiator or acceptor is allowed to
+   assert name attributes and the authenticity of these assertions is
+   not validated by the mechanisms, then security problems may result.
+   On the other hand, requiring that name attributes be mechanism
+   specific and only be carried by mechanisms that understand the name
+   attributes and can validate them compromises GSSAPI's place as a
+   generic API.  Application authors would be forced to understand
+   mechanism-specific attributes to make authorization decisions.  In
+   addition if mechanisms are not required to transport arbitrary
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 6]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+   attributes, then application authors will need to deal with different
+   implementations of the same mechanism that support different sets of
+   name attributes.  One possible solution is to carry a source along
+   with each name attribute; this source could indicate whether the
+   attribute comes from a mechanism data structure or from the other
+   party in the authentication.
+
+   Another related question is how will name attributes be mapped into
+   their mechanism-specific forms.  For example it would be desirable to
+   map many  Kerberos authorization data elements into name attributes.
+   In the case of the Microsoft PAC, it would be desirable for some
+   applications to get the entire PAC.  However in many cases, the
+   specific lists of security IDs contained in the PAC would be more
+   directly useful to an application.  So there may not be a good
+   one-to-one mapping between the mechanism-specific elements and the
+   representation desirable at the GSSAPI layer.
+
+   Specific name matching rules need to be developed.  How do names with
+   attributes compare?  What is the effect of a name attribute on a
+   target name in gss_accept_sec_context?
+
+4.3  Handling gss_export_name
+
+   For many mechanisms, there will be  an obvious choice to use for the
+   name exported by gss_export_name.  For example in the case of
+   Kerberos, the principal name can continue to be used as the exported
+   name.  This will allow applications depending on existing GSSAPI
+   name-based authorization to continue to work.  However it is probably
+   desirable to allow GSSAPI mechanisms for which gss_export_name cannot
+   meaningfully be defined.  The behavior of gss_export_name in such
+   cases should probably be to return some error.  Such mechanisms may
+   not work with existing applications and cannot conform to the current
+   version of the GSSAPI.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 7]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+5.  Credential Extensions
+
+   An alternative to the name attributes proposal  is to extend GSSAPI
+   credentials  with extensions labeled by OIDs.  Interfaces would be
+   needed to manipulate these credential extensions and to retrieve the
+   credential extensions for credentials used to establish a context.
+   Even if name attributes are used, credential extensions may be useful
+   for other unrelated purposes.
+
+   It is possible to solve problems discussed in this document using
+   some credential extension mechanism.  Doing so will have many of the
+   same open issues as discussed in the  name attributes proposal.  The
+   main advantage of a credential extensions proposal is that  it avoids
+   specifying how name attributes interact with name comparison or
+   target names.
+
+   The primary advantage of the name attributes proposal over credential
+   extensions is that name attributes seem to fit better into the GSSAPI
+   authorization model.  Names are already available at all points when
+   authorization decisions are made.  In addition, for many mechanisms
+   the sort of information carried as name attributes will also be
+   carried as part of the name in the mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 8]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+6.  Mechanisms for Export Name
+
+   Another proposal is to define some GSSAPI mechanisms whose only
+   purpose is to have an exportable name form that is useful.  For
+   example, you might be able to export a name as a local machine user
+   ID with such a mechanism.
+
+   This solution works well especially for name information that can be
+   looked up in a directory.  It was unclear from the discussion whether
+   this solution would allow mechanism-specific name information to be
+   extracted from a context.  If so, then this solution would meet many
+   of the goals of this document.
+
+   One advantage of this solution is that it requires few if any changes
+   to GSSAPI semantics.  It is not as flexible as other solutions.
+   Also, it is not clear how to handle mechanisms that do not have a
+   well defined name to export with this solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 9]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+7.  Security Considerations
+
+   GSSAPI sets up a security context between two named parties.  The
+   GSSAPI names are security assertions that are authenticated by the
+   context establishment process.  As such  the GSS naming architecture
+   is critical to the security of GSSAPI.
+
+   Currently GSSAPI uses a simplistic naming model for authorization.
+   Names can be compared  against a set of names on an access control
+   list.  This architecture is relatively simple and its security
+   properties are well understood.  However it does not provide the
+   flexibility and feature set for future deployments of GSSAPI.
+
+   This proposal will significantly increase the complexity of the GSS
+   naming architecture.  As this proposal is fleshed out, we need to
+   consider ways of managing security exposures created by this
+   increased complexity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 10]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+8.  Acknowledgements
+
+   John Brezak, Paul Leach and Nicolas Williams all participated in
+   discussions that defined the problem this proposal attempts to solve.
+   Nicolas Williams and I discussed details of proposals to solve this
+   problem.  However the details and open issues presented here have
+   only been reviewed by me and so I am responsible for their errors.
+
+9  Informative References
+
+   [1]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [2]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
+        KDC Referrals to locate Kerberos realms",
+        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
+        2004.
+
+   [3]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and Certificate Revocation
+        List (CRL) Profile", rfc 3280, April 2002.
+
+
+Author's Address
+
+   Sam Hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 11]
+
+Internet-Draft            GSS Name Attributes               October 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 12]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/third_party/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
new file mode 100644
index 00000000000..89e64524c47
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt b/third_party/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt
new file mode 100644
index 00000000000..4dcff486b93
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt
@@ -0,0 +1,244 @@
+Network Working Group                                        M. Horowitz
+<draft-horowitz-key-derivation-01.txt>                  Cygnus Solutions
+Internet-Draft                                               March, 1997
+
+
+       Key Derivation for Authentication, Integrity, and Privacy
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as ``work in progress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+   Directories on ds.internic.net (US East Coast), nic.nordu.net
+   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   author.
+
+Abstract
+
+   Recent advances in cryptography have made it desirable to use longer
+   cryptographic keys, and to make more careful use of these keys.  In
+   particular, it is considered unwise by some cryptographers to use the
+   same key for multiple purposes.  Since most cryptographic-based
+   systems perform a range of functions, such as authentication, key
+   exchange, integrity, and encryption, it is desirable to use different
+   cryptographic keys for these purposes.
+
+   This RFC does not define a particular protocol, but defines a set of
+   cryptographic transformations for use with arbitrary network
+   protocols and block cryptographic algorithm.
+
+
+Deriving Keys
+
+   In order to use multiple keys for different functions, there are two
+   possibilities:
+
+    - Each protocol ``key'' contains multiple cryptographic keys.  The
+      implementation would know how to break up the protocol ``key'' for
+      use by the underlying cryptographic routines.
+
+    - The protocol ``key'' is used to derive the cryptographic keys.
+      The implementation would perform this derivation before calling
+
+
+
+Horowitz                                                        [Page 1]
+
+Internet Draft               Key Derivation                  March, 1997
+
+
+      the underlying cryptographic routines.
+
+   In the first solution, the system has the opportunity to provide
+   separate keys for different functions.  This has the advantage that
+   if one of these keys is broken, the others remain secret.  However,
+   this comes at the cost of larger ``keys'' at the protocol layer.  In
+   addition, since these ``keys'' may be encrypted, compromising the
+   cryptographic key which is used to encrypt them compromises all the
+   component keys.  Also, the not all ``keys'' are used for all possible
+   functions.  Some ``keys'', especially those derived from passwords,
+   are generated from limited amounts of entropy.  Wasting some of this
+   entropy on cryptographic keys which are never used is unwise.
+
+   The second solution uses keys derived from a base key to perform
+   cryptographic operations.  By carefully specifying how this key is
+   used, all of the advantages of the first solution can be kept, while
+   eliminating some disadvantages.  In particular, the base key must be
+   used only for generating the derived keys, and this derivation must
+   be non-invertible and entropy-preserving.  Given these restrictions,
+   compromise of one derived keys does not compromise the other subkeys.
+   Attack of the base key is limited, since it is only used for
+   derivation, and is not exposed to any user data.
+
+   Since the derived key has as much entropy as the base keys (if the
+   cryptosystem is good), password-derived keys have the full benefit of
+   all the entropy in the password.
+
+   To generate a derived key from a base key:
+
+      Derived Key = DK(Base Key, Well-Known Constant)
+
+   where
+
+      DK(Key, Constant) = n-truncate(E(Key, Constant))
+
+   In this construction, E(Key, Plaintext) is a block cipher, Constant
+   is a well-known constant defined by the protocol, and n-truncate
+   truncates its argument by taking the first n bits; here, n is the key
+   size of E.
+
+   If the output of E is is shorter than n bits, then some entropy in
+   the key will be lost.  If the Constant is smaller than the block size
+   of E, then it must be padded so it may be encrypted.  If the Constant
+   is larger than the block size, then it must be folded down to the
+   block size to avoid chaining, which affects the distribution of
+   entropy.
+
+   In any of these situations, a variation of the above construction is
+   used, where the folded Constant is encrypted, and the resulting
+   output is fed back into the encryption as necessary (the | indicates
+   concatentation):
+
+      K1 = E(Key, n-fold(Constant))
+      K2 = E(Key, K1)
+
+
+
+Horowitz                                                        [Page 2]
+
+Internet Draft               Key Derivation                  March, 1997
+
+
+      K3 = E(Key, K2)
+      K4 = ...
+
+      DK(Key, Constant) = n-truncate(K1 | K2 | K3 | K4 ...)
+
+   n-fold is an algorithm which takes m input bits and ``stretches''
+   them to form n output bits with no loss of entropy, as described in
+   [Blumenthal96].  In this document, n-fold is always used to produce n
+   bits of output, where n is the key size of E.
+
+   If the size of the Constant is not equal to the block size of E, then
+   the Constant must be n-folded to the block size of E.  This number is
+   used as input to E.  If the block size of E is less than the key
+   size, then the output from E is taken as input to a second invocation
+   of E.  This process is repeated until the number of bits accumulated
+   is greater than or equal to the key size of E.  When enough bits have
+   been computed, the first n are taken as the derived key.
+
+   Since the derived key is the result of one or more encryptions in the
+   base key, deriving the base key from the derived key is equivalent to
+   determining the key from a very small number of plaintext/ciphertext
+   pairs.  Thus, this construction is as strong as the cryptosystem
+   itself.
+
+
+Deriving Keys from Passwords
+
+   When protecting information with a password or other user data, it is
+   necessary to convert an arbitrary bit string into an encryption key.
+   In addition, it is sometimes desirable that the transformation from
+   password to key be difficult to reverse.  A simple variation on the
+   construction in the prior section can be used:
+
+      Key = DK(n-fold(Password), Well-Known Constant)
+
+   The n-fold algorithm is reversible, so recovery of the n-fold output
+   is equivalent to recovery of Password.  However, recovering the n-
+   fold output is difficult for the same reason recovering the base key
+   from a derived key is difficult.
+
+
+
+   Traditionally, the transformation from plaintext to ciphertext, or
+   vice versa, is determined by the cryptographic algorithm and the key.
+   A simple way to think of derived keys is that the transformation is
+   determined by the cryptographic algorithm, the constant, and the key.
+
+   For interoperability, the constants used to derive keys for different
+   purposes must be specified in the protocol specification.  The
+   constants must not be specified on the wire, or else an attacker who
+   determined one derived key could provide the associated constant and
+   spoof data using that derived key, rather than the one the protocol
+   designer intended.
+
+
+
+
+Horowitz                                                        [Page 3]
+
+Internet Draft               Key Derivation                  March, 1997
+
+
+   Determining which parts of a protocol require their own constants is
+   an issue for the designer of protocol using derived keys.
+
+
+Security Considerations
+
+   This entire document deals with security considerations relating to
+   the use of cryptography in network protocols.
+
+
+Acknowledgements
+
+   I would like to thank Uri Blumenthal, Hugo Krawczyk, and Bill
+   Sommerfeld for their contributions to this document.
+
+
+References
+
+   [Blumenthal96] Blumenthal, U., "A Better Key Schedule for DES-Like
+      Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
+
+
+Author's Address
+
+   Marc Horowitz
+   Cygnus Solutions
+   955 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: +1 617 354 7688
+   Email: marc@cygnus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz                                                        [Page 4]
diff --git a/third_party/heimdal/doc/standardisation/draft-howard-gss-sanon-13.txt b/third_party/heimdal/doc/standardisation/draft-howard-gss-sanon-13.txt
new file mode 100644
index 00000000000..e533e3dc85d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-howard-gss-sanon-13.txt
@@ -0,0 +1,616 @@
+
+
+
+
+Network Working Group                                          L. Howard
+Internet-Draft                                                      PADL
+Intended status: Informational                            April 27, 2020
+Expires: October 29, 2020
+
+
+                  A Simple Anonymous GSS-API Mechanism
+                       draft-howard-gss-sanon-13
+
+Abstract
+
+   This document defines protocols, procedures and conventions for a
+   Generic Security Service Application Program Interface (GSS-API)
+   security mechanism that provides key agreement without authentication
+   of either party.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on October 29, 2020.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 1]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
+   3.  Discovery and Negotiation . . . . . . . . . . . . . . . . . .   3
+   4.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   4.1.  Mechanism Names . . . . . . . . . . . . . . . . . . . . . .   3
+   4.2.  Display Name Format . . . . . . . . . . . . . . . . . . . .   3
+   4.3.  Exported Name Format  . . . . . . . . . . . . . . . . . . .   3
+   5.  Definitions and Token Formats . . . . . . . . . . . . . . . .   4
+   5.1.  Context Establishment Tokens  . . . . . . . . . . . . . . .   4
+   5.1.1.  Initial context token . . . . . . . . . . . . . . . . . .   4
+   5.1.2.  Acceptor context token  . . . . . . . . . . . . . . . . .   5
+   5.1.3.  Initiator context completion  . . . . . . . . . . . . . .   5
+   5.2.  Per-Message Tokens  . . . . . . . . . . . . . . . . . . . .   6
+   5.3.  Context Deletion Tokens . . . . . . . . . . . . . . . . . .   6
+   6.  Key derivation  . . . . . . . . . . . . . . . . . . . . . . .   6
+   7.  Pseudo-Random Function  . . . . . . . . . . . . . . . . . . .   7
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   10.1.  Normative References . . . . . . . . . . . . . . . . . . .   7
+   10.2.  Informative References . . . . . . . . . . . . . . . . . .   8
+   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .   9
+   Appendix B.  Mechanism Attributes . . . . . . . . . . . . . . . .  10
+   Appendix C.  NegoEx . . . . . . . . . . . . . . . . . . . . . . .  10
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
+
+1.  Introduction
+
+   The Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743] provides a framework for authentication and message
+   protection services through a common programming interface.
+
+   The Simple Anonymous mechanism (hereafter SAnon) described in this
+   document is a simple protocol based on the X25519 elliptic curve
+   Diffie-Hellman (ECDH) key agreement scheme defined in [RFC7748].  No
+   authentication of initiator or acceptor is provided.  A potential use
+   of SAnon is to provide a degree of privacy when bootstrapping unkeyed
+   entities.
+
+2.  Requirements notation
+
+   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 [RFC2119].
+
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 2]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+3.  Discovery and Negotiation
+
+   The SAnon mechanism is identified by the following OID:
+
+       sanon-x25519 OBJECT IDENTIFIER ::=
+           {iso(1)identified-organization(3)dod(6)internet(1)
+            private(4)enterprise(1)padl(5322)gss-sanon(26)
+            mechanisms(1)sanon-x25519(110)}
+
+   The means of discovering GSS-API peers and their supported mechanisms
+   is out of this specification's scope.  To avoid multiple layers of
+   negotiation, SAnon is not crypto-agile; a future variant using a
+   different algorithm would be assigned a different OID.
+
+   If anonymity is not desired then SAnon MUST NOT be used.  Either
+   party can test for anon_state (GSS_C_ANON_FLAG) to check if anonymous
+   authentication was performed.
+
+4.  Naming
+
+4.1.  Mechanism Names
+
+   A SAnon mechanism name is abstractly a boolean indicating whether it
+   represents an anonymous identity.  Anonymous identities are names
+   imported with the GSS_C_NT_ANONYMOUS name type.  Implementations MAY
+   map other names to anonymous identities according to local policy.
+   Names representing non-anonymous identities MUST be importable so
+   that initiators with non-default credentials can engage SAnon by
+   setting anon_req_flag (GSS_C_ANON_FLAG).
+
+4.2.  Display Name Format
+
+   When GSS_Display_name() is called on a mechanism name representing an
+   anonymous identity, the display string is WELLKNOWN/
+   ANONYMOUS@WELLKNOWN:ANONYMOUS [RFC8062] and the name type is
+   GSS_C_NT_ANONYMOUS.  This is always the name observed by a SAnon
+   peer.  All context APIs that return peer names MUST return this name
+   for both parties if the context is established.
+
+4.3.  Exported Name Format
+
+   SAnon uses the mechanism-independent exported name object format
+   defined in [RFC2743] Section 3.2.  All lengths are encoded as big-
+   endian integers.  The export of non-anonymous mechanism names MUST
+   fail with GSS_S_BAD_NAME.
+
+
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 3]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+     +--------------+--------------+---------------------------------+
+     | Length       | Name         | Description                     |
+     +--------------+--------------+---------------------------------+
+     | 2            | TOK_ID       | 04 01                           |
+     |              |              |                                 |
+     | 2            | MECH_OID_LEN | Length of the mechanism OID     |
+     |              |              |                                 |
+     | MECH_OID_LEN | MECH_OID     | The SAnon mechanism OID, in DER |
+     |              |              |                                 |
+     | 4            | NAME_LEN     | 00 00 00 01                     |
+     |              |              |                                 |
+     | 1            | NAME         | 01                              |
+     +--------------+--------------+---------------------------------+
+
+5.  Definitions and Token Formats
+
+5.1.  Context Establishment Tokens
+
+5.1.1.  Initial context token
+
+   The initial context token is framed per Section 1 of [RFC2743]:
+
+   GSS-API DEFINITIONS ::=
+       BEGIN
+
+       MechType ::= OBJECT IDENTIFIER -- 1.3.6.1.4.1.5322.26.1.110
+       GSSAPI-Token ::=
+       [APPLICATION 0] IMPLICIT SEQUENCE {
+            thisMech MechType,
+            innerToken ANY DEFINED BY thisMech
+                -- 32 byte initiator public key
+                -- 8 byte protocol flags (optional)
+       }
+       END
+
+   On the first call to GSS_Init_sec_context(), the mechanism checks if
+   one or more of the following are true:
+
+      The caller set anon_req_flag (GSS_C_ANON_FLAG)
+
+      The claimant credential identity is anonymous (see Section 4.1)
+
+      The claimant credential is the default one and target identity is
+      anonymous
+
+   If none of these are the case, the call MUST fail with
+   GSS_S_UNAVAILABLE.
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 4]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+   If proceeding, the initiator generates a fresh secret and public key
+   pair per [RFC7748] Section 6.1 and returns GSS_S_CONTINUE_NEEDED,
+   indicating that a subsequent context token from the acceptor is
+   expected.  The innerToken field of the output_token contains the
+   initiator's 32 byte public key, optionally concatenated with a 64-bit
+   big-endian integer containing flags the acceptor would be otherwise
+   be unable to infer (such as those defined in [RFC4757] Section 7.1).
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible and request anonymity only through anon_req_flag
+   (see [RFC8062] Section 6).
+
+5.1.2.  Acceptor context token
+
+   Upon receiving a context token from the initiator, the acceptor
+   validates that the token is well formed and contains a public key of
+   the requisite length.  The acceptor generates a fresh secret and
+   public key pair.  The context session key is computed as specified in
+   Section 6.
+
+   The acceptor constructs an output_token by concatenating its public
+   key with the token emitted by calling GSS_GetMIC() with the default
+   QOP and zero-length octet string.  The output token is sent to the
+   initiator without additional framing.
+
+   The acceptor then returns GSS_S_COMPLETE, setting src_name to the
+   canonical anonymous name.  The reply_det_state (GSS_C_REPLAY_FLAG),
+   sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG),
+   integ_avail (GSS_C_INTEG_FLAG) and anon_state (GSS_C_ANON_FLAG)
+   security context flags are set, along with any additional flags
+   received from the initiator.  The context is ready to use.
+
+5.1.3.  Initiator context completion
+
+   Upon receiving the acceptor context token and verifying it is well
+   formed, the initiator extracts the acceptor's public key (being the
+   first 32 bytes of the input token) and computes the context session
+   key per Section 6.
+
+   The initiator calls GSS_VerifyMIC() with the MIC extracted from the
+   context token and the zero-length octet string.  If successful, the
+   initiator returns GSS_S_COMPLETE to the caller, to indicate the
+   initiator is authenticated and the context is ready for use.  No
+   output token is emitted.  Supported security context flags are as for
+   the acceptor context.  The flags returned to the caller are the
+   intersection of supported and requested flags, combined with
+   anon_state (GSS_C_ANON_FLAG) which is set unconditionally.
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 5]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+5.2.  Per-Message Tokens
+
+   The per-message tokens definitions are imported from [RFC4121]
+   Section 4.2.  The base key used to derive specific keys for signing
+   and sealing messages is defined in Section 6.  The [RFC3961]
+   encryption and checksum algorithms use the aes128-cts-hmac-sha256-128
+   encryption type defined in [RFC8009].  The AcceptorSubkey flag as
+   defined in [RFC4121] Section 4.2.2 MUST be set.
+
+5.3.  Context Deletion Tokens
+
+   Context deletion tokens are empty in this mechanism.  The behavior of
+   GSS_Delete_sec_context() [RFC2743] is as specified in [RFC4121]
+   Section 4.3.
+
+6.  Key derivation
+
+   The context session key is known as the base key, and is computed
+   using a key derivation function from [SP800-108] Section 5.1 (using
+   HMAC as the PRF):
+
+       base key = HMAC-SHA-256(K1, i | label | 0x00 | context | L)
+
+   where:
+
+   K1            the output of X25519(local secret key, peer public key)
+                 as specified in [RFC7748] Section 6.1
+
+   i             the constant 0x00000001, representing the iteration
+                 count expressed in big-endian binary representation of
+                 4 bytes
+
+   label         the string "sanon-x25519" (without quotation marks)
+
+   context       initiator public key | acceptor public key | flags |
+                 channel binding application data (if present)
+
+   L             the constant 0x00000080, being length in bits of the
+                 key to be outputted expressed in big-endian binary
+                 representation of 4 bytes
+
+   The flags input to the context contains any flags sent by the
+   initiator, defaulting to zero if none were sent, expressed in big-
+   endian binary representation of 8 bytes.
+
+   The inclusion of channel bindings in the key derivation function
+   means that the acceptor cannot ignore initiator channel bindings;
+   this differs from some other mechanisms.
+
+
+
+Howard                  Expires October 29, 2020                [Page 6]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+   The base key provides the acceptor-asserted subkey defined in
+   [RFC4121] Section 2 and is used to generate keys for per-message
+   tokens and the GSS-API PRF.  Its encryption type is aes128-cts-hmac-
+   sha256-128 per [RFC8009].  The [RFC3961] algorithm protocol
+   parameters are as given in [RFC8009] Section 5.
+
+7.  Pseudo-Random Function
+
+   The [RFC4401] GSS-API pseudo-random function for this mechanism
+   imports the definitions from [RFC8009], using the base key for both
+   GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL usages.
+
+8.  Security Considerations
+
+   This document defines a GSS-API security mechanism, and therefore
+   deals in security and has security considerations text embedded
+   throughout.  This section only addresses security considerations
+   associated with the SAnon mechanism described in this document.  It
+   does not address security considerations associated with the GSS-API
+   itself.
+
+   This mechanism provides only for key agreement.  It does not
+   authenticate the identity of either party.  It MUST NOT be selected
+   if either party requires identification of its peer.
+
+   SAnon mechanism names are not unary.  Implementations MUST ensure
+   that GSS_Compare_name() always sets name_equal to FALSE when
+   comparing mechanism names.
+
+9.  Acknowledgements
+
+   AuriStor, Inc funded the design of this protocol, along with an
+   implementation for the Heimdal GSS-API library.
+
+   Jeffrey Altman, Greg Hudson, Simon Josefsson, and Nicolas Williams
+   provided valuable feedback on this document.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 7]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743,
+              DOI 10.17487/RFC2743, January 2000,
+              <https://www.rfc-editor.org/info/rfc2743>.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
+              2005, <https://www.rfc-editor.org/info/rfc3961>.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              DOI 10.17487/RFC4121, July 2005,
+              <https://www.rfc-editor.org/info/rfc4121>.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401,
+              DOI 10.17487/RFC4401, February 2006,
+              <https://www.rfc-editor.org/info/rfc4401>.
+
+   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+              for Security", RFC 7748, DOI 10.17487/RFC7748, January
+              2016, <https://www.rfc-editor.org/info/rfc7748>.
+
+   [RFC8009]  Jenkins, M., Peck, M., and K. Burgin, "AES Encryption with
+              HMAC-SHA2 for Kerberos 5", RFC 8009, DOI 10.17487/RFC8009,
+              October 2016, <https://www.rfc-editor.org/info/rfc8009>.
+
+10.2.  Informative References
+
+   [I-D.zhu-negoex]
+              Short, M., Zhu, L., Damour, K., and D. McPherson, "SPNEGO
+              Extended Negotiation (NEGOEX) Security Mechanism", draft-
+              zhu-negoex-04 (work in progress), January 2011.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, DOI 10.17487/RFC4178, October 2005,
+              <https://www.rfc-editor.org/info/rfc4178>.
+
+   [RFC4757]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
+              Kerberos Encryption Types Used by Microsoft Windows",
+              RFC 4757, DOI 10.17487/RFC4757, December 2006,
+              <https://www.rfc-editor.org/info/rfc4757>.
+
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 8]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+   [RFC5587]  Williams, N., "Extended Generic Security Service Mechanism
+              Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009,
+              <https://www.rfc-editor.org/info/rfc5587>.
+
+   [RFC8062]  Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
+              "Anonymity Support for Kerberos", RFC 8062,
+              DOI 10.17487/RFC8062, February 2017,
+              <https://www.rfc-editor.org/info/rfc8062>.
+
+   [SP800-108]
+              Chen, L., "Recommendation for Key Derivation Using
+              Pseudorandom Functions (Revised)", October 2009.
+
+Appendix A.  Test Vectors
+
+   The example exchange below contains no extra flags or channel binding
+   information.
+
+   initiator secret key  83 33 f2 ea 2a 22 eb aa 05 39 c6 06 1d 6a 99 05
+                         84 24 49 9e 2c 16 c1 b1 34 d9 22 27 f3 f4 5e bd
+
+   initiator public key  5f 40 66 22 5a 3c fd 72 57 23 c1 8f ae 71 3e 8c
+                         ab 32 a7 2c 93 b9 76 66 04 4b 8f e4 a0 c9 69 19
+
+   initiator token       60 2c 06 0a 2b 06 01 04 01 a9 4a 1a 01 6e 5f 40
+                         66 22 5a 3c fd 72 57 23 c1 8f ae 71 3e 8c ab 32
+                         a7 2c 93 b9 76 66 04 4b 8f e4 a0 c9 69 1
+
+   acceptor secret key   b0 db 16 32 39 0a dd 93 1e f7 62 bc d3 c9 1d 03
+                         e8 d9 59 52 48 eb e2 f2 b5 f7 d8 06 ec dd 50 60
+
+   acceptor public key   2f 81 51 9f a8 9c 07 f8 eb b2 95 6c 0c c3 22 77
+                         ae a1 0e 62 0c 79 33 81 ef 9a c5 b2 f0 d9 1e 06
+
+   base key              80 76 2c 43 32 6a 95 f5 be 30 6d ea 10 ba f3 d0
+
+   acceptor token        2f 81 51 9f a8 9c 07 f8 eb b2 95 6c 0c c3 22 77
+                         ae a1 0e 62 0c 79 33 81 ef 9a c5 b2 f0 d9 1e 06
+                         04 04 05 ff ff ff ff ff 00 00 00 00 00 00 00 00
+                         4d 5e a9 e0 e1 9c 7a 61 c2 6a 9a c5 e8 17 5f 04
+
+   initiator negoex key  2a c8 f9 d0 31 87 40 42 cb d4 50 07 ce db c2 c2
+
+   acceptor negoex key   73 9f 4d a2 f1 2d f7 f7 d7 ea e4 9d a4 08 62 5b
+
+
+
+
+
+
+
+Howard                  Expires October 29, 2020                [Page 9]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+Appendix B.  Mechanism Attributes
+
+   The [RFC5587] mechanism attributes for this mechanism are:
+
+      GSS_C_MA_MECH_CONCRETE
+
+      GSS_C_MA_ITOK_FRAMED
+
+      GSS_C_MA_AUTH_INIT_ANON
+
+      GSS_C_MA_AUTH_TARG_ANON
+
+      GSS_C_MA_INTEG_PROT
+
+      GSS_C_MA_CONF_PROT
+
+      GSS_C_MA_MIC
+
+      GSS_C_MA_WRAP
+
+      GSS_C_MA_REPLAY_DET
+
+      GSS_C_MA_OOS_DET
+
+      GSS_C_MA_CBINDINGS
+
+      GSS_C_MA_PFS
+
+      GSS_C_MA_CTX_TRANS
+
+Appendix C.  NegoEx
+
+   When SAnon is negotiated by [I-D.zhu-negoex], the authentication
+   scheme identifier is DEE384FF-1086-4E86-BE78-B94170BFD376.
+
+   The initiator and acceptor keys for NegoEx checksum generation and
+   verification are derived using the GSS-API PRF (see Section 7), with
+   the input data "sanon-x25519-initiator-negoex-key" and "sanon-x25519-
+   acceptor-negoex-key" respectively (without quotation marks).  No
+   metadata is defined and any, if present, SHOULD be ignored.
+
+   It is RECOMMENDED that GSS-API implementations supporting both SPNEGO
+   [RFC4178] and NegoEx advertise SAnon under both to maximise
+   interoperability.
+
+
+
+
+
+
+
+Howard                  Expires October 29, 2020               [Page 10]
+
+Internet-Draft           SAnon GSS-API Mechanism              April 2020
+
+
+Author's Address
+
+   Luke Howard
+   PADL Software Pty Ltd
+   PO Box 59
+   Central Park, VIC  3145
+   Australia
+
+   Email: lukeh@padl.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard                  Expires October 29, 2020               [Page 11]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-iakerb-04.txt
new file mode 100644
index 00000000000..208d057f24c
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-iakerb-09.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-iakerb-09.txt
new file mode 100644
index 00000000000..ee2ca5f7e94
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-iakerb-09.txt
@@ -0,0 +1,809 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                        Jonathan Trostle
+draft-ietf-cat-iakerb-09.txt                          Cisco Systems
+Updates: RFC 1510, 1964                               Michael Swift
+October   2002                                        University of WA
+                                                      Bernard Aboba
+                                                      Microsoft
+                                                      Glen Zorn
+                                                      Cisco Systems
+
+
+Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
+(IAKERB)
+                     <draft-ietf-cat-iakerb-09.txt>
+
+
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [5].
+
+   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 in March 2003. Please send comments to the
+   authors.
+
+1. Abstract
+
+   This document defines extensions to the Kerberos protocol
+   specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism
+   (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for
+   services where the KDC is not accessible to the client, but is
+   accessible to the application server. Some common scenarios where
+   lack of accessibility would occur are when the client does not have
+   an IP address prior to authenticating to an access point, the client
+   is unable to locate a KDC, or a KDC is behind a firewall. The
+   document specifies two protocols to allow a client to exchange KDC
+   messages (which are GSS encapsulated) with an IAKERB proxy instead of
+   a KDC.
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 1]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+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 RFC2119 [6].
+
+3. 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. The following is a
+   list of some of the scenarios that this proposal addresses:
+
+   (1) The client must initially authenticate to an access point in
+   order to gain full access to the network. Here the client may be
+   unable to directly contact the KDC either because it does not have an
+   IP address, or the access point packet filter does not allow the
+   client to send packets to the Internet before it authenticates to the
+   access point [8].
+
+   (2) A KDC is behind a firewall so the client will send Kerberos
+   messages to the IAKERB proxy which will transmit the KDC request and
+   reply messages between the client and the KDC. (The IAKERB proxy is a
+   special type of Kerberos application server that also relays KDC
+   request and reply messages between a client and the KDC).
+
+4. Overview
+
+   This proposal specifies two protocols that address the above
+   scenarios: the IAKERB proxy option and the IAKERB minimal messages
+   option. In the IAKERB proxy option (see Figure 1) an application
+   server called the IAKERB proxy acts as a protocol gateway and proxies
+   Kerberos messages back and forth between the client and the KDC. The
+   IAKERB proxy is also responsible for locating the KDC and may
+   additionally perform other application proxy level functions such as
+   auditing. A compliant IAKERB proxy MUST implement the IAKERB proxy
+   protocol.
+
+
+            Client <---------> IAKERB proxy <----------> KDC
+
+
+                      Figure 1: IAKERB proxying
+
+   The second protocol is the minimal messages protocol which is based
+   on user-user authentication [4]; this protocol is targetted at
+   environments where the number of messages, prior to key
+   establishment, needs to be minimized. In the normal minimal messages
+   protocol, the client sends its ticket granting ticket (TGT) to the
+   IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB
+   proxy then sends a TGS_REQ to the KDC with the client's TGT in the
+   additional tickets field of the TGS_REQ message. The returned ticket
+   will list the client as the ticket's server principal, and will be
+   encrypted with the session key from the client's TGT. The IAKERB
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 2]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+   proxy then uses this ticket to generate an AP request that is sent to
+   the client (see Figure 2). Thus mutual authentication is accomplished
+   with three messages between the client and the IAKERB proxy versus
+   four or more (the difference is larger if crossrealm operations are
+   involved).
+
+   Subsequent to mutual authentication and key establishment, the IAKERB
+   proxy sends a ticket to the client (in a KRB_TKT_PUSH message).  This
+   ticket is created by the IAKERB proxy and contains the same fields as
+   the original service ticket that the proxy sent in the AP_REQ
+   message, except the client and server names are reversed and it is
+   encrypted in a long term key known to the IAKERB proxy. Its purpose
+   is to enable fast subsequent re-authentication by the client to the
+   application server (using the conventional AP request AP reply
+   exchange) for subsequent sessions. In addition to minimizing the
+   number of messages, a secondary goal is to minimize the number of
+   bytes transferred between the client and the IAKERB proxy prior to
+   mutual authentication and key establishment. Therefore, the final
+   service ticket (the reverse ticket) is sent after mutual
+   authentication and key establishment is complete, rather than as part
+   of the initial AP_REQ from the IAKERB proxy to the client. Thus
+   protected application data (e.g., GSS signed and wrapped messages)
+   can flow before this final message is sent.
+
+   The AS_REQ case for the minimal messages option is similar, where the
+   client sends up the AS_REQ message and the IAKERB proxy forwards it
+   to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP
+   message; the protocol now proceeds as in the TGS_REQ case described
+   above with the IAKERB proxy including the client's TGT in the
+   additional tickets field of the TGS_REQ message.
+
+   A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
+   and MAY implement the IAKERB minimal message protocol. In general,
+   the existing Kerberos paradigm where clients contact the KDC to
+   obtain service tickets should be preserved where possible.
+
+   For most IAKERB scenarios, such as when the client does not have an
+   IP address, or cannot directly contact a KDC, the IAKERB proxy
+   protocol should be adequate. If the client needs to obtain a
+   crossrealm TGT (and the conventional Kerberos protocol cannot be
+   used), then the IAKERB proxy protocol must be used.  In a scenario
+   where the client does not have a service ticket for the target
+   server, it is crucial that the number of messages between the client
+   and the target server be minimized (especially if the client and
+   target server are in different realms), and/or it is crucial that the
+   number of bytes transferred between the client and the target server
+   be minimized, then the client should consider using the minimal
+   messages protocol. The reader should see the security considerations
+   section regarding the minimal messages protocol.
+
+
+
+
+
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 3]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+                Client  --------> IAKERB proxy
+                        TKT_PUSH (w/ TGT)
+
+                Client            IAKERB proxy --------------------> KDC
+                                                TGS_REQ with client
+                                                TGT as additional TGT
+
+                Client            IAKERB proxy <-------------------- KDC
+                                                TGS_REP with service
+                                                ticket
+
+                Client <--------  IAKERB proxy                       KDC
+                         AP_REQ
+
+                Client -------->  IAKERB proxy                       KDC
+                         AP_REP
+
+           -------------------------------------------------------------
+            post-key establishment and application data flow phase:
+
+                Client <--------  IAKERB proxy                       KDC
+                        TKT_PUSH (w/ticket targetted at IAKERB proxy
+                               to enable fast subsequent authentication)
+
+
+                 Figure 2: IAKERB Minimal Messages Option: TGS case
+
+
+
+5.  GSSAPI Encapsulation
+
+   The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance
+   with the mechanism proposed by SPNEGO [7] for negotiating protocol
+   variations, is:  {iso(1) org(3) dod(6) internet(1) security(5)
+   mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}.  The proposed
+   mechanism ID for IAKERB minimum messages GSS-API Kerberos, in
+   accordance with the mechanism proposed by SPNEGO for negotiating
+   protocol variations, is: {iso(1) org(3) dod(6) internet(1)
+   security(5) mechanisms(5) iakerb(10)
+   iakerbMinimumMessagesProtocol(2)}.
+
+   NOTE: An IAKERB implementation does not require SPNEGO in order to
+   achieve interoperability with other IAKERB peers. Two IAKERB
+   implementations may interoperate in the same way that any two peers
+   can interoperate using a pre-established GSSAPI mechanism.  The above
+   OID's allow two SPNEGO peers to securely negotiate IAKERB from among
+   a set of GSS mechanisms.
+
+   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 [3]:
+
+
+
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 4]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
+           thisMech        MechType
+                   -- MechType is OBJECT IDENTIFIER
+                   -- representing iakerb proxy or iakerb min messages
+           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
+
+   We also define the token ID for the KRB_TKT_PUSH token (defined below
+   and used in the minimal messages variation):
+
+   Message          TOK_ID
+
+   KRB_TKT_PUSH     02 03
+
+   For completeness, we list the other RFC 1964 defined token ID's here:
+
+   Message          TOK_ID
+
+   AP_REQ           01 00
+
+   AP_REP           02 00
+
+   KRB_ERROR        03 00
+
+6.  The IAKERB proxy protocol
+
+   The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and
+   KRB_ERROR messages back and forth between the client and the KDC as
+   illustrated in Figure 1. Messages received from the client must first
+   have the Kerberos GSS header (RFC1964 [2]) stripped off. The
+   unencapsulated message will then be forwarded to a KDC. The IAKERB
+   proxy is responsible for locating an appropriate KDC using the realm
+   information in the KDC request message it received from the client.
+   In addition, the IAKERB proxy SHOULD implement a retry algorithm for
+   KDC requests over UDP (including selection of alternate KDC's if the
+   initial KDC does not respond to its requests). For messages sent by
+   the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 5]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+   header before sending them to the client.
+
+   We define two new Kerberos error codes that allow the proxy to
+   indicate the following error conditions to the client:
+
+   (a) when the proxy is unable to obtain an IP address for a KDC in the
+   client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR
+   (80) message to the client.
+
+   (b) when the proxy has an IP address for a KDC in the client realm,
+   but does not receive a response from any KDC in the realm (including
+   in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE
+   KRB_ERROR (81) message to the client.
+
+   To summarize, the sequence of steps for processing is as follows:
+
+   Servers:
+
+   1. For received KDC_REQ messages (with token ID 00 03)
+      - process GSS framing (check OID)
+        if the OID is not one of the two OID's specified in the GSSAPI
+        Encapsulation section above, then process according to mechanism
+        defined by that OID (if the OID is recognized). The processing
+        is outside the scope of this specification. Otherwise, strip
+        off GSS framing.
+      - find KDC for specified realm (if KDC IP address cannot be
+        obtained, send a KRB_ERROR message with error code
+        KRB_IAKERB_ERR_KDC_NOT_FOUND to the client).
+      - send to KDC (storing client IP address, port, and indication
+        whether IAKERB proxy option or minimal messages option is
+        being used)
+      - retry with same or another KDC if no response is received. If
+        the retries also fail, send an error message with error code
+        KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client.
+
+   2. For received KDC_REP messages
+      - encapsulate with GSS framing, using token ID 01 03 and the OID
+        that corresponds to the stored protocol option
+      - send to client (using the stored client IP address and port)
+
+   3. For KRB_ERROR messages received from the KDC
+      - encapsulate with GSS framing, using token ID 03 00 and the OID
+        that corresponds to the stored protocol option
+      - send to client (using the stored client IP address and port)
+        (one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error
+        which can lead to a retry of the KDC_REQ message over the TCP
+        transport by the server, instead of simply proxying the error
+        to the client).
+
+   4. For sending/receiving AP_REQ and AP_REP messages
+      - process per RFC 1510 and RFC 1964; the created AP_REP message
+        SHOULD include the subkey (with same etype as the session key)
+        to facilitate use with other key derivation algorithms outside
+        of [2]. The subkey SHOULD be created using locally generated
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 6]
+
+INTERNET DRAFT                 October 2002           Expires March 2003
+
+
+        entropy as one of the inputs (in addition to other inputs
+        such as the session key).
+
+   Clients:
+
+   1. For sending KDC_REQ messages
+      - create AS_REQ or TGS_REQ message
+      - encapsulate with GSS framing (token ID 00 03 and OID
+        corresponding to the protocol option).
+      - send to server
+
+   2. For received KDC_REP messages
+      - decapsulate by removing GSS framing (token ID 01 03)
+      - process inner Kerberos message according to RFC 1510
+
+   3. For received KRB_ERROR messages
+      - decapsulate by removing GSS framing (token ID 03 00)
+      - process inner Kerberos message according to RFC 1510
+        and possibly retry the request (time skew errors lead
+        to retries in most existing Kerberos implementations)
+
+   4. For sending/receiving AP_REQ and AP_REP messages
+      - process per RFC 1510 and RFC 1964; the created AP_REQ
+        message SHOULD include the subsession key in the
+        authenticator field.
+
+7. The IAKERB minimal messages protocol
+
+   The client MAY initiate the IAKERB minimal messages variation when
+   the number of messages must be minimized (the most significant
+   reduction in the number of messages can occur when the client and the
+   IAKERB proxy are in different realms). SPNEGO [7] MAY be used to
+   securely negotiate between the protocols (and amongst other GSS
+   mechanism protocols). A compliant IAKERB server MAY support the
+   IAKERB minimal messages protocol.
+
+   (a) AS_REQ case: (used when the client does not have a TGT)
+
+   We apply the Kerberos user-user authentication protocol [4] in this
+   scenario (other work in this area includes the IETF work in progress
+   effort to apply Kerberos user user authentication to DHCP
+   authentication).
+
+   The client indicates that the minimal message sub-protocol will be
+   used by using the appropriate OID as described above. The client
+   sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and
+   the IAKERB proxy processes the GSS framing (as described above for
+   the IAKERB proxy option) and forwards the AS_REQ message to the KDC.
+
+   The IAKERB proxy will either send a KRB_ERROR message back to the
+   client, or it will send an initial context token consisting of the
+   GSS header (minimal messages OID with a two byte token header 01 03),
+   followed by an AS_REP message. The AS_REP message will contain the
+   AP_REQ message in a padata field; the ticket in the AP_REQ is a
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 7]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+   user-user ticket encrypted in the session key from the client's
+   original TGT. We define the padata type PA-AP-REQ with type number
+   25.  The corresponding padata value is the AP_REQ message without any
+   GSS framing. For the IAKERB minimal messages AS option, the AP_REQ
+   message authenticator MUST include the RFC 1964 [2] checksum.  The
+   mutual-required and use-session-key flags are set in the ap-options
+   field of the AP_REQ message.
+
+   The protocol is complete in the KRB_ERROR case (from the server
+   perspective, but the client should retry depending on the error
+   type). If the IAKERB proxy receives an AS_REP message from the KDC,
+   the IAKERB proxy will then obtain the client's TGT from the AS_REP
+   message. The IAKERB proxy then sends a TGS_REQ message with the
+   client's TGT in the additional tickets field to the client's KDC
+   (ENC-TKT-IN-SKEY option).
+
+   The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the
+   TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error,
+   switching to TCP from UDP). Ultimately, the IAKERB proxy either
+   proxies a KRB_ERROR message to the client (after adding the GSS
+   framing), sends one of the new GSS framed KRB_ERROR messages defined
+   above, or it receives the TGS_REP message from the KDC and then
+   creates the AP_REQ message according to RFC 1964 [2]. The IAKERB
+   proxy then sends a GSS token containing the AS_REP message with the
+   AP_REQ message in the padata field as described above. (Note:
+   although the server sends the context token with the AP_REQ, the
+   client is the initiator.) The IAKERB proxy MUST set both the mutual-
+   required and use-session-key flags in the AP_REQ message in order to
+   cause the client to authenticate as well. The authenticator SHOULD
+   include the subsession key (containing locally added entropy).  The
+   client will reply with the GSSAPI enscapsulated AP_REP message, if
+   the IAKERB proxy's authentication succeeds (which SHOULD include the
+   subkey field to facilitate use with other key derivation algorithms
+   outside of [2]). If all goes well, then, in order to enable
+   subsequent efficient client authentications, the IAKERB proxy will
+   then send a final message of type KRB_TKT_PUSH containing a Kerberos
+   ticket (the reverse ticket) that has the IAKERB client principal
+   identifier in the client identifier field of the ticket and its own
+   principal identity in the server identifier field of the ticket (see
+   Figure 3):
+
+     KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE {
+       pvno[0]             INTEGER,  -- 5 (protocol version)
+       msg-type[1]         INTEGER,  -- 17 (message type)
+       ticket[2]           Ticket
+     }
+
+   NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER.  The
+   key used to encrypt the reverse ticket is a long term secret key
+   chosen by the IAKERB proxy. The fields are identical to the AP_REQ
+   ticket, except the client name will be switched with the server name,
+   and the server realm will be switched with the client realm. (The one
+   other exception is that addresses should not be copied from the
+   AP_REQ ticket to the reverse ticket). Sending the reverse ticket
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 8]
+
+INTERNET DRAFT                  October 2002           Expires March 2003
+
+
+   allows the client to efficiently initiate subsequent reauthentication
+   attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH
+   message is sent after mutual authentication and key establishment are
+   complete.
+
+
+                Client  --------> IAKERB proxy --------------------> KDC
+                        AS_REQ                  AS_REQ
+
+                Client            IAKERB proxy <-------------------- KDC
+                                                AS_REP w/ client TGT
+
+                Client            IAKERB proxy --------------------> KDC
+                                                TGS_REQ with client
+                                                TGT as additional TGT
+
+                Client            IAKERB proxy <-------------------- KDC
+                                                TGS_REP with service
+                                                ticket
+
+                Client <--------  IAKERB proxy                       KDC
+                         AS_REP w/ AP_REQ in padata field
+
+                Client -------->  IAKERB proxy                       KDC
+                         AP_REP
+
+           -------------------------------------------------------------
+            post-key establishment and application data flow phase:
+
+                Client <--------  IAKERB proxy                       KDC
+                        TKT_PUSH (w/ticket targetted at IAKERB proxy
+                               to enable fast subsequent authentication)
+
+
+                 Figure 3: IAKERB Minimal Messages Option: AS case
+
+
+
+   (b) TGS_REQ case: (used when the client has a TGT)
+
+   The client indicates that the minimal messages sub-protocol will be
+   used by using the appropriate OID as described above. The client
+   initially sends a KRB_TKT_PUSH message (with the GSS header) to the
+   IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain
+   the client's TGT from the KRB_TKT_PUSH message and then proceed to
+   send a TGS_REQ message to a KDC where the realm of the KDC is equal
+   to the realm from the server realm field in the TGT sent by the
+   client in the KRB_TKT_PUSH message. NOTE: this realm could be the
+   client's home realm, the proxy's realm, or an intermediate realm. The
+   protocol then continues as in the minimal messages AS_REQ case
+   described above (see Figure 2); the IAKERB proxy's TGS_REQ message
+   contains the client's TGT in the additional tickets field (ENC-TKT-
+   IN-SKEY option). The IAKERB proxy then receives the TGS_REP message
+   from the KDC and then sends a RFC 1964 AP_REQ message to the client
+
+
+
+Trostle, Swift, Aboba, Zorn                                     [Page 9]
+
+INTERNET DRAFT                 October 2002           Expires March 2003
+
+
+   (with the MUTUAL AUTH flag set - see AS_REQ case).
+
+   To summarize, here are the steps for the minimal messages TGS
+   protocol:
+
+   Client:
+          (has TGT already for, or targetted at, realm X.ORG)
+          sends TKT_PUSH message to server containing client's ticket
+          for X.ORG (which could be a crossrealm TGT)
+
+   Server:
+          (has TGT already targetted at realm X.ORG)
+          sends to KDC (where KDC has principal id = server name,
+            server realm from client ticket) a TGS_REQ:
+          TGT in TGS_REQ is server's TGT
+          Additional ticket in TGS_REQ is client's TGT from TKT_PUSH
+            message
+          Server name in TGS_REQ (optional by rfc1510) is not present
+          Server realm in TGS_REQ is realm in server's TGT - X.ORG
+
+   KDC:
+          Builds a ticket:
+             Server name = client's name
+             Client name = server's name, Client realm = server's realm
+             Server realm = client's realm
+             Encrypted with: session key from client's TGT (passed in
+                additional tickets field)
+          Build a TGS_REP
+             Encrypted with session key from server's TGT
+          Sends TGS_REP and ticket to server
+
+   Server:
+          Decrypts TGS_REP from KDC using session key from its TGT
+          Constructs AP_REQ
+              Ticket = ticket from KDC (which was encrypted with
+                       client's TGT session key)
+              authenticator clientname = server's name (matches
+                clientname in AP-REQ ticket)
+              authenticator clientrealm = server's realm
+              subsession key in authenticator is present (same
+              etype as the etype of the session key in the ticket)
+              checksum in authenticator is the RFC 1964 checksum
+              sequence number in authenticator is present (RFC 1964)
+              ap-options has both use-session-key and mutual-required
+              flags set
+          Sends AP_REQ (with GSS-API framing) to client
+
+   Client:
+          Receives AP_REQ
+          Decrypts ticket using session key from its TGT
+          Verifies AP_REQ
+          Builds AP_REP and sends to server (AP_REP SHOULD include
+          subkey field to facilitate use with other key derivation
+          algorithms outside of [2] e.g., [8] and its successors.
+
+
+
+Trostle, Swift, Aboba, Zorn                                    [Page 10]
+
+INTERNET DRAFT                 October 2002           Expires March 2003
+
+
+          Some apps may have their own message protection key
+          derivation algorithm and protected message format.
+          AP_REP includes the sequence number per RFC 1964.)
+
+   Server:
+          Verifies AP-REP. Builds reverse ticket as described above
+          and sends reverse ticket to client using the KRB_TKT_PUSH
+          message. The reverse ticket is the same as the AP_REQ
+          ticket except the client name, realm are switched with the
+          server name, realm fields and it is encrypted in a secret
+          key known to the IAKERB proxy.
+
+8. 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.
+
+9. Security Considerations
+
+   Similar to other network access protocols, IAKERB allows an
+   unauthenticated client (possibly outside the security perimeter of an
+   organization) to send messages that are proxied to interior servers.
+   When combined with DNS SRV RR's for KDC lookup, there is the
+   possibility that an attacker can send an arbitrary message to an
+   interior server. There are several aspects to note here:
+
+   (1) in many scenarios, compromise of the DNS lookup will require the
+   attacker to already have access to the internal network. Thus the
+   attacker would already be able to send arbitrary messages to interior
+   servers. No new vulnerabilities are added in these scenarios.
+
+   (2) in a scenario where DNS SRV RR's are being used to locate the
+   KDC, IAKERB is being used, and an external attacker can modify DNS
+   responses to the IAKERB proxy, there are several countermeasures to
+   prevent arbitrary messages from being sent to internal servers:
+
+   (a) KDC port numbers can be statically configured on the IAKERB
+   proxy. In this case, the messages will always be sent to KDC's. For
+   an organization that runs KDC's on a static port (usually port 88)
+   and does not run any other servers on the same port, this
+   countermeasure would be easy to administer and should be effective.
+
+   (b) the proxy can do application level sanity checking and filtering.
+   This countermeasure should eliminate many of the above attacks.
+
+   (c) DNS security can be deployed. This countermeasure is probably
+   overkill for this particular problem, but if an organization has
+
+
+
+Trostle, Swift, Aboba, Zorn                                    [Page 11]
+
+INTERNET DRAFT                 October 2002           Expires March 2003
+
+
+   already deployed DNS security for other reasons, then it might make
+   sense to leverage it here. Note that Kerberos could be used to
+   protect the DNS exchanges.  The initial DNS SRV KDC lookup by the
+   proxy will be unprotected, but an attack here is at most a denial of
+   service (the initial lookup will be for the proxy's KDC to facilitate
+   Kerberos protection of subsequent DNS exchanges between itself and
+   the DNS server).
+
+   In the minimal messages protocol option, the application server sends
+   an AP_REQ message to the client. The ticket in the AP_REQ message
+   SHOULD NOT contain authorization data since some operating systems
+   may allow the client to impersonate the server and increase its own
+   privileges. If the ticket from the server connotes any authorization,
+   then the minimal messages protocol should not be used. Also, the
+   minimal messages protocol may facilitate denial of service attacks in
+   some environments; to prevent these attacks, it may make sense for
+   the minimal messages protocol server to only accept a KRB_TGT_PUSH
+   message on a local network interface (to ensure that the message was
+   not sent from a remote malicious host).
+
+10. Acknowledgements
+
+   We thank the Kerberos Working Group chair, Doug Engert, for his
+   efforts in helping to progress this specification. We also thank Ken
+   Raeburn for his comments and the other working group participants for
+   their input.
+
+11.  References
+
+   [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication
+       Service (V5)", RFC 1510.
+
+   [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964.
+
+   [3] J. Linn, "Generic Security Service Application Program
+       Interface Version 2, Update 1", RFC 2743.
+
+   [4] D. Davis, R. Swick, "Workstation Services and Kerberos
+       Authentication at Project Athena", Technical Memorandum TM-424,
+       MIT Laboratory for Computer Science, February 1990.
+
+   [5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
+       9, RFC 2026, October 1996.
+
+   [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
+       Mechanism," RFC 2478, December 1998.
+
+   [8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical
+       Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition.
+
+
+
+
+
+Trostle, Swift, Aboba, Zorn                                    [Page 12]
+
+INTERNET DRAFT               October 2002             Expires March 2003
+
+
+12.  Author's Addresses
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134, U.S.A.
+   Email: jtrostle@cisco.com
+   Phone: (408) 527-6201
+
+   Michael Swift
+   University of Washington
+   Seattle, WA
+   Email: mikesw@cs.washington.edu
+
+   Bernard Aboba
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington, 98052, U.S.A.
+   Email: bernarda@microsoft.com
+   Phone: (425) 706-6605
+
+   Glen Zorn
+   Cisco Systems
+   Bellevue, WA U.S.A.
+   Email: gwz@cisco.com
+   Phone: (425) 468-0955
+
+   This draft expires on March 31st, 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trostle, Swift, Aboba, Zorn                                    [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt
new file mode 100644
index 00000000000..e235bec58c0
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt
@@ -0,0 +1,311 @@
+
+
+
+
+Network Working Group                                        M. Horowitz
+<draft-ietf-cat-kerb-chg-password-02.txt>                Stonecast, Inc.
+Internet-Draft                                              August, 1998
+
+                   Kerberos Change Password Protocol
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as ``work in progress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+   Directories on ftp.ietf.org (US East Coast), nic.nordu.net
+   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+   The Kerberos V5 protocol [RFC1510] does not describe any mechanism
+   for users to change their own passwords.  In order to promote
+   interoperability between workstations, personal computers, terminal
+   servers, routers, and KDC's from multiple vendors, a common password
+   changing protocol is required.
+
+
+
+Overview
+
+   When a user wishes to change his own password, or is required to by
+   local policy, a simple request of a password changing service is
+   necessary.  This service must be implemented on at least one host for
+   each Kerberos realm, probably on one of the kdc's for that realm.
+   The service must accept requests on UDP port 464 (kpasswd), and may
+   accept requests on TCP port 464 as well.
+
+   The protocol itself 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.
+
+
+
+
+
+
+
+
+Horowitz                                                        [Page 1]
+
+Internet Draft      Kerberos Change Password Protocol       August, 1998
+
+
+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                       /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   message length (16 bits)
+      Contains the length of the message, including this field, in bytes
+      (big-endian integer)
+   protocol version number (16 bits)
+      Contains the hex constant 0x0001 (big-endian integer)
+   AP-REQ length (16 bits)
+      length (big-endian integer) of AP-REQ data, in bytes.
+   AP-REQ data, as described in RFC1510 (variable length)
+      This AP-REQ must be for the service principal
+      kadmin/changepw@REALM, where REALM is the REALM of the user who
+      wishes to change his password.  The Ticket in the AP-REQ must be
+      derived from an AS request (thus having the INITIAL flag set), and
+      must include a subkey in the Authenticator.
+   KRB-PRIV message, as described in RFC1510 (variable length)
+      This KRB-PRIV message must be generated using the subkey in the
+      Authenticator in the AP-REQ data.  The user-data component of the
+      message must consist of the user's new password.
+
+   The server must verify the AP-REQ message, decrypt the new password,
+   perform any local policy checks (such as password quality, history,
+   authorization, etc.) required, then set the password to the new value
+   specified.
+
+   The principal whose password is to be changed is the principal which
+   authenticated to the password changing service.  This protocol does
+   not address administrators who want to change passwords of principal
+   besides their own.
+
+
+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 or KRB-ERROR message                  /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   message length (16 bits)
+
+
+
+Horowitz                                                        [Page 2]
+
+Internet Draft      Kerberos Change Password Protocol       August, 1998
+
+
+      Contains the length of the message, including this field, in bytes
+      (big-endian integer),
+   protocol version number (16 bits)
+      Contains the hex constant 0x0001 (big-endian integer)
+   AP-REP length (16 bits)
+      length of AP-REP data, in bytes.  If the the length is zero, then
+      the last field will contain a KRB-ERROR message instead of a KRB-
+      PRIV message.
+   AP-REP data, as described in RFC1510 (variable length)
+      The AP-REP corresponding to the AP-REQ in the request packet.
+   KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable
+      length)
+      If the AP-REP length is zero, then this field contains a KRB-ERROR
+      message.  Otherwise, it contains a KRB-PRIV message.  This KRB-
+      PRIV message must be generated using the subkey in the
+      Authenticator in the AP-REQ data.
+
+      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)
+         The result code must have one of the following values (big-
+         endian integer):
+         0x0000 if the request succeeds.  (This value is not permitted
+            in a KRB-ERROR message.)
+         0x0001 if the request fails due to being malformed
+         0x0002 if the request fails due to a "hard" error processing
+            the request (for example, there is a resource or other
+            problem causing the request to fail)
+         0x0003 if the request fails due to an error in authentication
+            processing
+         0x0004 if the request fails due to a "soft" error processing
+            the request (for example, some policy or other similar
+            consideration is causing the request to be rejected).
+         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 (variable length)
+         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.
+
+
+
+
+Horowitz                                                        [Page 3]
+
+Internet Draft      Kerberos Change Password Protocol       August, 1998
+
+
+Dropped and Modified Messages
+
+   An attacker (or simply a lossy network) could cause either the
+   request or reply to be dropped, or modified by substituting a KRB-
+   ERROR message in the reply.
+
+   If a request is dropped, no modification of the password/key database
+   will take place.  If a reply is dropped, the server will (assuming a
+   valid request) make the password change.  However, the client cannot
+   distinguish between these two cases.
+
+   In this situation, the client should construct a new authenticator,
+   re-encrypt the request, and retransmit.  If the original request was
+   lost, the server will treat this as a valid request, and the password
+   will be changed normally.  If the reply was lost, then the server
+   should take care to notice that the request was a duplicate of the
+   prior request, because the "new" password is the current password,
+   and the password change time is within some implementation-defined
+   replay time window.  The server should then return a success reply
+   (an AP-REP message with result code == 0x0000) without actually
+   changing the password or any other information (such as modification
+   timestamps).
+
+   If a success reply was replaced with an error reply, then the
+   application performing the request would return an error to the user.
+   In this state, the user's password has been changed, but the user
+   believes that it has not.  If the user attempts to change the
+   password again, this will probably fail, because the user cannot
+   successfully provide the old password to get an INITIAL ticket to
+   make the request.  This situation requires administrative
+   intervention as if a password was lost.  This situation is,
+   unfortunately, impossible to prevent.
+
+
+Security Considerations
+
+   This document deals with changing passwords for Kerberos.  Because
+   Kerberos is used for authentication and key distribution, it is
+   important that this protocol use the highest level of security
+   services available to a particular installation.  Mutual
+   authentication is performed, so that the server knows the request is
+   valid, and the client knows that the request has been received and
+   processed by the server.
+
+   There are also security issues relating to dropped or modified
+   messages which are addressed explicitly.
+
+
+References
+
+   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+      Authentication Service (V5)", RFC 1510, September 1993.
+
+
+
+
+
+Horowitz                                                        [Page 4]
+
+Internet Draft      Kerberos Change Password Protocol       August, 1998
+
+
+Author's Address
+
+   Marc Horowitz
+   Stonecast, Inc.
+   108 Stow Road
+   Harvard, MA 01451
+
+   Phone: +1 978 456 9103
+   Email: marc@stonecast.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz                                                        [Page 5]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
new file mode 100644
index 00000000000..2583a84da0a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
@@ -0,0 +1,127 @@
+
+
+
+
+
+
+Network Working Group                                        M. Horowitz
+<draft-ietf-cat-kerb-des3-hmac-sha1-00.txt>             Cygnus Solutions
+Internet-Draft                                            November, 1996
+
+
+           Triple DES with HMAC-SHA1 Kerberos Encryption Type
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as ``work in progress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+   Directories on ds.internic.net (US East Coast), nic.nordu.net
+   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+   This document defines a new encryption type and a new checksum type
+   for use with Kerberos V5 [RFC1510].  This encryption type is based on
+   the Triple DES cryptosystem and the HMAC-SHA1 [Krawczyk96] message
+   authentication algorithm.
+
+   The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
+   The hmac-sha1-des3 checksum type has been assigned the value 12.
+
+
+Encryption Type des3-cbc-hmac-sha1
+
+   EncryptedData using this type must be generated as described in
+   [Horowitz96].  The encryption algorithm is Triple DES in Outer-CBC
+   mode.  The keyed hash algorithm is HMAC-SHA1.  Unless otherwise
+   specified, a zero IV must be used.  If the length of the input data
+   is not a multiple of the block size, zero octets must be used to pad
+   the plaintext to the next eight-octet boundary.  The counfounder must
+   be eight random octets (one block).
+
+
+Checksum Type hmac-sha1-des3
+
+   Checksums using this type must be generated as described in
+   [Horowitz96].  The keyed hash algorithm is HMAC-SHA1.
+
+
+
+Horowitz                                                        [Page 1]
+
+Internet Draft     Kerberos Triple DES with HMAC-SHA1     November, 1996
+
+
+Common Requirements
+
+   Where the Triple DES key is represented as an EncryptionKey, it shall
+   be represented as three DES keys, with parity bits, concatenated
+   together.  The key shall be represented with the most significant bit
+   first.
+
+   When keys are generated by the derivation function, a key length of
+   168 bits shall be used.  The output bit string will be converted to a
+   valid Triple DES key by inserting DES parity bits after every seventh
+   bit.
+
+   Any implementation which implements either of the encryption or
+   checksum types in this document must support both.
+
+
+Security Considerations
+
+   This entire document defines encryption and checksum types for use
+   with Kerberos V5.
+
+
+References
+
+   [Horowitz96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
+      horowitz-kerb-key-derivation-00.txt, November 1996.
+   [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
+      Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
+      md5-01.txt, August, 1996.
+   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+      Authentication Service (V5)", RFC 1510, September 1993.
+
+
+Author's Address
+
+   Marc Horowitz
+   Cygnus Solutions
+   955 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: +1 617 354 7688
+   Email: marc@cygnus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz                                                        [Page 2]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
new file mode 100644
index 00000000000..46a41585270
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
@@ -0,0 +1,250 @@
+
+
+
+
+
+Network Working Group                                        M. Horowitz
+<draft-ietf-cat-kerb-key-derivation-00.txt>             Cygnus Solutions
+Internet-Draft                                            November, 1996
+
+
+                     Key Derivation for Kerberos V5
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as ``work in progress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+   Directories on ds.internic.net (US East Coast), nic.nordu.net
+   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+   In the Kerberos protocol [RFC1510], 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.
+
+
+Overview
+
+   Under RFC1510 as stated, key derivation could be specified as a set
+   of encryption types which share the same key type.  The constant for
+   each derivation would be a function of the encryption type.  However,
+   it is generally accepted that, for interoperability, key types and
+   encryption types must map one-to-one onto each other.  (RFC 1510 is
+   being revised to address this issue.)  Therefore, to use key
+   derivcation with Kerberos V5 requires a small change to the
+   specification.
+
+   For each place where a key is used in Kerberos, a ``key usage'' must
+   be specified for that purpose.  The key, key usage, and
+   encryption/checksum type together describe the transformation from
+   plaintext to ciphertext, or plaintext to checksum.  For backward
+
+
+
+Horowitz                                                        [Page 1]
+
+Internet Draft       Key Derivation for Kerberos V5       November, 1996
+
+
+   compatibility, old encryption types would be defined independently of
+   the key usage.
+
+
+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)
+
+      16. Data which is defined in some specification outside of
+          Kerberos to be encrypted using an RFC1510 encryption type.
+      17. Data which is defined in some specification outside of
+          Kerberos to be checksummed using an RFC1510 checksum type.
+
+   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
+
+
+
+Horowitz                                                        [Page 2]
+
+Internet Draft       Key Derivation for Kerberos V5       November, 1996
+
+
+   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 16 and 17 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 shall 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 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 | length | plaintext | padding) |
+                   H(Ki, confounder | length | 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, length | plaintext)
+
+   Note that each enctype is described by an encryption algorithm E and
+   a keyed hash algorithm H, and each checksum type is described by a
+   keyed hash algorithm H.  HMAC, with an appropriate hash, is
+   recommended for use as H.
+
+
+Security Considerations
+
+   This entire document addresses shortcomings in the use of
+   cryptographic keys in Kerberos V5.
+
+
+
+
+Horowitz                                                        [Page 3]
+
+Internet Draft       Key Derivation for Kerberos V5       November, 1996
+
+
+Acknowledgements
+
+   I would like to thank Uri Blumenthal, Sam Hartman, and Bill
+   Sommerfeld for their contributions to this document.
+
+
+References
+
+   [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
+      Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
+      November 1996.  [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
+      Network Authentication Service (V5)", RFC 1510, September 1993.
+
+
+Author's Address
+
+   Marc Horowitz
+   Cygnus Solutions
+   955 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: +1 617 354 7688
+   Email: marc@cygnus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz                                                        [Page 4]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
new file mode 100644
index 00000000000..c5e4d05e7e3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
@@ -0,0 +1,252 @@
+
+INTERNET-DRAFT                                           Ari Medvinsky
+draft-ietf-cat-kerberos-err-msg-00.txt                        Matt Hur
+Updates: RFC 1510                                  Dominique Brezinski
+expires September 30, 1997                       CyberSafe Corporation
+                                                           Gene Tsudik
+                                                            Brian Tung
+                                                                   ISI
+
+Integrity Protection for the Kerberos Error Message
+
+0.  Status Of this Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as "work in
+    progress."
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ds.internic.net (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997.
+    Please send comments to the authors.
+
+1.  Abstract
+
+    The Kerberos error message, as defined in RFC 1510, is transmitted 
+    to the client without any integrity assurance.  Therefore, the 
+    client has no means to distinguish between a valid error message 
+    sent from the KDC and one sent by an attacker.  This draft describes 
+    a method for assuring the integrity of Kerberos error messages, and 
+    proposes a consistent format for the e-data field in the KRB_ERROR 
+    message.  This e-data format enables the storage of cryptographic 
+    checksums by providing an extensible mechanism for specifying e-data 
+    types.
+
+
+2.  Motivation      
+
+    In the Kerberos protocol [1], if an error occurs for AS_REQ,
+    TGS_REQ, or AP_REQ, a clear text error message is returned to the
+    client.  An attacker may exploit this vulnerability by sending a
+    false error message as a reply to any of the above requests.  For
+    example, an attacker may send the KDC_ERR_KEY_EXPIRED error message
+    in order to force a user to change their password in hope that the
+    new key will not be as strong as the current key, and thus, easier
+    to break.
+
+    Since false error messages may be utilized by an attacker, a
+    Kerberos client should have a means for determining how much trust
+    to place in a given error message.  The rest of this draft
+    describes a method for assuring the integrity of Kerberos error
+    messages.
+
+
+3.  Approach
+
+    We propose taking a cryptographic checksum over the entire KRB-ERROR
+    message.  This checksum would be returned as part of the error
+    message and would enable the client to verify the integrity of the
+    error message.  For interoperability reasons, no new fields are
+    added to the KRB-ERROR message.  Instead, the e-data field (see
+    figure 1) is utilized to carry the cryptographic checksum.
+
+
+3.1 Cryptographic checksums in error messages for AS_REQ,
+    TGS_REQ & AP_REQ
+
+    If an error occurs for the AS request, the only key that is
+    available to the KDC is the shared secret (the key derived from the
+    clients password) registered in the KDCs database.  The KDC will
+    use this key to sign the error message, if and only if, the client
+    already proved knowledge of the shared secret in the AS request
+    (e.g. via PA-ENC-TIMESTAMP in preauth data).  This policy is needed
+    to prevent an attacker from getting the KDC to send a signed error
+    message and then launching an off-line attack in order to obtain a
+    key of a given principal. 
+
+    If an error occurs for a TGS or an AP request, the server will use
+    the session key sealed in the clients ticket granting ticket to
+    compute the checksum over the error message.  If the checksum could
+    not be computed (e.g. error while decrypting the ticket) the error
+    message is returned to the client without the checksum.  The client
+    then has the option to treat unprotected error messages differently.
+
+
+    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
+    }
+    Figure 1
+
+
+3.2 Format of the e-data field
+
+    We propose to place the cryptographic checksum in the e-data field.
+    First, we review the format of the e-data field, as specified in
+    RFC 1510.  The format of e-data is specified only in two cases [2].
+    "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
+    field will contain an encoding of a sequence of padata fields":
+
+    METHOD-DATA ::=  SEQUENCE of PA-DATA
+    PA-DATA ::= SEQUENCE {
+                padata-type    [1] INTEGER,
+                padata-value   [2] OCTET STRING
+    }
+
+    The second case deals with the KRB_AP_ERR_METHOD error code.  The
+    e-data field will contain an encoding of the following sequence:
+
+    METHOD-DATA ::=  SEQUENCE {
+                     method-type    [0] INTEGER,
+                     method-data    [1] OCTET STRING OPTIONAL
+    }
+
+    method-type indicates the required alternate authentication method.
+
+    It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed
+    checksum is not returned as part of the error message, since the
+    error code indicates that the Kerberos credentials provided in the
+    AP_REQ message are unacceptable.
+
+    We propose that the e-data field have the following format for all
+    error-codes (except KRB_AP_ERR_METHOD):
+
+    E-DATA ::=  SEQUENCE {
+                data-type    [1] INTEGER,
+                data-value   [2] OCTET STRING,
+    }
+
+    The data-type field specifies the type of information that is
+    carried in the data-value field.  Thus, to send a cryptographic
+    checksum back to the client, the data-type is set to CHECKSUM, the
+    data-value is set to the ASN.1 encoding of the following sequence:
+
+    Checksum  ::=  SEQUENCE {
+                   cksumtype  [0] INTEGER,
+                   checksum   [1] OCTET STRING
+    }
+
+
+3.3 Computing the checksum 
+
+    After the error message is filled out, the error structure is
+    converted into ASN.1 representation.  A cryptographic checksum is
+    then taken over the encoded error message; the result is placed in
+    the error message structure, as the last item in the e-data field.
+    To send the error message, ASN.1 encoding is again performed over
+    the error message, which now includes the cryptographic checksum.
+
+
+3.4 Verifying the integrity of the error message
+
+    In addition to verifying the cryptographic checksum for the error
+    message, the client must verify that the error message is bound to
+    its request.  This is done by comparing the ctime field in the
+    error message to its counterpart in the request message.
+
+
+4.  E-DATA types
+
+    Since the e-data types must not conflict with preauthentication data
+    types, we propose that the preauthentication data types in the range
+    of 2048 and above be reserved for use as e-data types.
+
+    We define the following e-data type in support of integrity checking
+    for the Kerberos error message:
+
+    CHECKSUM = 2048 -- the keyed checksum described above
+
+
+5.  Discussion
+
+
+5.1 e-data types
+
+    The extension for Kerberos error messages, as outlined above, is
+    extensible to allow for definition of other error data types. 
+    We propose that the following e-data types be reserved:
+
+    KDCTIME = 2049
+    The error data would consist of the KDCs time in KerberosTime.
+    This data would be used by the client to adjust for clock skew.
+
+    REDIRECT = 2050
+    The error data would consist of a hostname.  The hostname would
+    indicate the authoritative KDC from which to obtain a TGT.
+
+
+5.2 e-data types vs. error code specific data formats
+
+    Since RFC 1510 does not define an error data type, the data format
+    must be explicitly specified for each error code.  This draft has
+    proposed an extension to RFC 1510 that would introduce the concept
+    of error data types.  This would allow for a manageable set of data
+    types to be used for any error message.  The authors assume that
+    the introduction of this e-data structure will not break any
+    existing Kerberos implementations.
+
+
+6.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
+        Service (V5).  Request for Comments: 1510
+    [2] J. Kohl, C. Neuman.  The Kerberos Network Authentication
+        Service (V5).  Request for Comments: 1510 p.67
+
+
+7.  Authors
+
+    Ari Medvinsky       <ari.medvinsky@cybersafe.com>
+    Matthew Hur         <matt.hur@cybersafe.com>
+    Dominique Brezinski <dominique.brezinski@cybersafe.com>
+
+    CyberSafe Corporation 
+    1605 NW Sammamish Road
+    Suite 310
+    Issaquah, WA 98027-5378
+    Phone: (206) 391-6000
+    Fax:   (206) 391-0508
+    http:/www.cybersafe.com
+
+
+    Brian Tung  <brian@isi.edu>
+    Gene Tsudik <gts@isi.edu>
+
+    USC Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey CA 90292-6695
+    Phone: (310) 822-1511
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
new file mode 100644
index 00000000000..b3ec336b651
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
new file mode 100644
index 00000000000..d09a2ded5bc
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
new file mode 100644
index 00000000000..4b193c57390
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
@@ -0,0 +1,282 @@
+INTERNET-DRAFT                                              Brian Tung
+draft-ietf-cat-kerberos-pk-cross-01.txt                 Tatyana Ryutov
+Updates: RFC 1510                                      Clifford Neuman
+expires September 30, 1997                                 Gene Tsudik
+                                                                   ISI
+                                                       Bill Sommerfeld
+                                                       Hewlett-Packard
+                                                         Ari Medvinsky
+                                                           Matthew Hur
+                                                 CyberSafe Corporation
+
+
+    Public Key Cryptography for Cross-Realm Authentication in Kerberos
+
+
+0.  Status Of this Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as ``work in
+    progress.''
+
+    To learn the current status of any Internet-Draft, please check
+    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
+    Shadow Directories on ds.internic.net (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-cross-01.txt, and expires September 30,
+    1997.  Please send comments to the authors.
+
+
+1.  Abstract
+
+    This document defines extensions to the Kerberos protocol
+    specification (RFC 1510, "The Kerberos Network Authentication
+    Service (V5)", September 1993) to provide a method for using
+    public key cryptography during 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.  Motivation
+
+    The advantages provided by public key cryptography--ease of
+    recoverability in the event of a compromise, the possibility of
+    an autonomous authentication infrastructure, to name a few--have
+    produced a demand for use by Kerberos authentication protocol.  A
+    draft describing the use of public key cryptography in the initial
+    authentication exchange in Kerberos has already been submitted.
+    This draft describes its use in cross-realm authentication.
+
+    The principal advantage provided by public key cryptography in
+    cross-realm authentication lies in the ability to leverage the
+    existing public key infrastructure.  It frees the Kerberos realm
+    administrator from having to maintain separate keys for each other
+    realm with which it wishes to exchange authentication information,
+    or to utilize a hierarchical arrangement, which may pose problems
+    of trust.
+
+    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.
+
+    The methods described in this draft allow a realm to specify, at
+    the time of authentication, which certification paths it will
+    trust.  A shared key for cross-realm authentication can be
+    established, for a period of time.  Furthermore, these methods are
+    transparent to the client, so that only the KDC's need to be
+    modified to use them.
+
+    It is not necessary to implement the changes described in the
+    "Public Key Cryptography for Initial Authentication" draft to make
+    use of the changes in this draft.  We solicit comments about the
+    interaction between the two protocol changes, but as of this
+    writing, the authors do not perceive any obstacles to using both.
+
+
+3.  Protocol Amendments
+
+    We assume that the user has already obtained a TGT.  To perform
+    cross-realm authentication, the user sends a request to the local
+    KDC as per RFC 1510.  If the two realms share a secret key, then
+    cross-realm authentication proceeds as usual.  Otherwise, the
+    local KDC may attempt to establish a shared key with the remote
+    KDC using public key cryptography, and exchange this key through
+    the cross-realm ticket granting ticket.
+
+    We will consider the specific channel on which the message
+    exchanges take place in Section 5 below.
+
+
+3.1.  Changes to the Cross-Realm Ticket Granting Ticket
+
+    In order to avoid the need for changes to the "installed base" of
+    Kerberos application clients and servers, the only protocol change
+    is to the way in which cross-realm ticket granting tickets (TGTs)
+    are encrypted; as these tickets are opaque to clients and servers,
+    the only change visible to them will be the increased size of the
+    tickets.
+
+    Cross-realm TGTs are granted by a local KDC to authenticate a user
+    to a remote KDC's ticket granting service.  In standard Kerberos,
+    they are encrypted using a shared secret key manually configured
+    into each KDC.
+
+    In order to incorporate public key cryptography, we define a new
+    encryption type, "ENCTYPE_PK_CROSS".  Operationally, this encryption
+    type transforms an OCTET STRING of plaintext (normally an EncTktPart)
+    into the following SEQUENCE:
+
+        PKCrossOutput ::= SEQUENCE {
+            certificate [0]     OCTET STRING OPTIONAL,
+                                    -- public key certificate
+                                    -- of local KDC
+            encSharedKey [1]    EncryptedData,
+                                    -- of type EncryptionKey
+                                    -- containing random symmetric key
+                                    -- encrypted using public key
+                                    -- of remote KDC
+            sigSharedKey [2]    Signature,
+                                    -- of encSharedKey
+                                    -- using signature key
+                                    -- of local KDC
+            pkEncData [3]       EncryptedData,
+                                    -- (normally) of type EncTktPart
+                                    -- encrypted using encryption key
+                                    -- found in encSharedKey
+        }
+
+    PKCROSS operates as follows: when a client submits a request for
+    cross-realm authentication, the local KDC checks to see if it has
+    a long-term shared key established for that realm.  If so, it uses
+    this key as per RFC 1510.
+
+    If not, it sends a request for information to the remote KDC.  The
+    content of this message is immaterial, as it does not need to be
+    processed by the remote KDC; for the sake of consistency, we define
+    it as follows:
+
+        RemoteRequest ::= [APPLICATION 41] SEQUENCE {
+            nonce [0]                   INTEGER
+        }
+
+    The remote KDC replies with a list of all trusted certifiers and
+    all its (the remote KDC's) certificates.  We note that this response
+    is universal and does not depend on which KDC makes the request:
+
+        RemoteReply ::= [APPLICATION 42] SEQUENCE {
+            trustedCertifiers [0]       SEQUENCE OF PrincipalName,
+            certificates[1]             SEQUENCE OF Certificate,
+            encTypeToUse [1]            SEQUENCE OF INTEGER
+                                            -- encryption types usable
+                                            -- for encrypting pkEncData
+        }
+
+        Certificate ::= SEQUENCE {
+            CertType                [0] INTEGER,
+                                        -- type of certificate
+                                        -- 1 = X.509v3 (DER encoding)
+                                        -- 2 = PGP (per PGP draft)
+            CertData                [1] OCTET STRING
+                                        -- actual certificate
+                                        -- type determined by CertType
+        } -- from pk-init draft
+
+    Upon receiving this reply, the local KDC determines whether it has
+    a certificate the remote KDC trusts, and whether the remote KDC has
+    a certificate the local KDC trusts.  If so, it issues a ticket
+    encrypted using the ENCTYPE_PK_CROSS encryption type defined above.
+
+
+3.2.  Profile Caches
+
+    We observe that using PKCROSS as specified above requires two
+    private key operations: a signature generation by the local KDC and
+    a decryption by the remote KDC.  This cost can be reduced in the
+    long term by judicious caching of the encSharedKey and the
+    sigSharedKey.
+
+    Let us define a "profile" as the encSharedKey and sigSharedKey, in
+    conjunction with the associated remote realm name and decrypted
+    shared key (the key encrypted in the encSharedKey).
+
+    To optimize these interactions, each KDC maintains two caches, one
+    for outbound profiles and one for inbound profiles.  When generating
+    an outbound TGT for another realm, the local KDC first checks to see
+    if the corresponding entry exists in the outbound profile cache; if
+    so, it uses its contents to form the first three fields of the
+    PKCrossOutput; the shared key is used to encrypt the data for the
+    fourth field.  If not, the components are generated fresh and stored
+    in the outbound profile cache.
+
+    Upon receipt of the TGT, the remote realm checks its inbound profile
+    cache for the corresponding entry.  If it exists, then it uses the
+    contents of the entry to decrypt the data encrypted in the pkEncData.
+    If not, then it goes through the full process of verifying and
+    extracting the shared key; if this is successful, then a new entry
+    is created in the inbound profile cache.
+
+    The inbound profile cache should support multiple entries per realm,
+    in the event that the initiating realm is replicated.
+
+
+4.  Finding Realms Supporting PKCROSS
+
+    If either the local realm or the destination realm does not support
+    PKCROSS, or both do not, the mechanism specified in Section 3 can
+    still be used in obtaining the desired remote TGT.
+
+    In the reference Kerberos implementations, the default behavior is
+    to traverse a path up and down the realm name hierarchy, if the
+    two realms do not share a key.  There is, however, the possibility
+    of using cross links--i.e., keys shared between two realms that
+    are non-contiguous in the realm name hierarchy--to shorten the
+    path, both to minimize delay and the number of intermediate realms
+    that need to be trusted.
+
+    PKCROSS can be used as a way to provide cross-links even in the
+    absence of shared keys.  If the client is aware that one or two
+    intermediate realms support PKCROSS, then a combination of
+    PKCROSS and conventional cross-realm authentication can be used
+    to reach the final destination realm.
+
+    We solicit discussion on the best methods for clients and KDCs to
+    determine or advertise support for PKCROSS.
+
+
+5.  Message Ports
+
+    We have not specified the port on which KDCs supporting PKCROSS
+    should listen to receive the request for information messages noted
+    above.  We solicit discussion on which port should be used.  We
+    propose to use the standard Kerberos ports (well-known 88 or 750),
+    but another possibility is to use a completely different port.
+
+    We also solicit discussion on what other approaches can be taken to
+    obtain the information in the RemoteReply (e.g., secure DNS or some
+    other repository).
+
+
+6.  Expiration Date
+
+    This Internet-Draft will expire on September 30, 1997.
+
+
+7.  Authors' Addresses
+
+    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
+
+    Bill Sommerfeld
+    Hewlett Packard
+    300 Apollo Drive
+    Chelmsford MA 01824
+    Phone: +1 508 436 4352
+    E-Mail: sommerfeld@apollo.hp.com
+
+    Ari Medvinsky
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road Suite 310
+    Issaquah WA 98027-5378
+    Phone: +1 206 391 6000
+    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
new file mode 100644
index 00000000000..1ab2b03e079
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt
new file mode 100644
index 00000000000..41b8e8e5f45
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt
@@ -0,0 +1,542 @@
+INTERNET-DRAFT                                               Matthew Hur
+draft-ietf-cat-kerberos-pk-cross-08.txt                    Cisco Systems
+Updates: RFC 1510                                             Brian Tung
+November 8, 2001 (Expires May 8, 2001)                    Tatyana Ryutov
+                                                         Clifford Neuman
+                                                                     ISI
+                                                           Ari Medvinsky
+                                                                Liberate
+                                                             Gene Tsudik
+                                                               UC Irvine
+                                                         Bill Sommerfeld
+                                                        Sun Microsystems
+
+
+    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.''
+
+    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 list of current Internet-Drafts can be accessed at
+     http://www.ietf.org/1id-abstracts.html
+
+     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-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001.
+    Please send comments to the authors.
+
+
+1.  Abstract
+
+    This document defines extensions to the Kerberos protocol 
+    specification [KERB] 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
+
+    Symmetric and asymmetric key systems may co-exist within hybrid 
+    architectures in order to leverage the advantages and mitigiate 
+    issues within the respective systems.  An example of a hybrid 
+    solution that may employ both symmetric and asymmetric technologies 
+    is Kerberos ciphersuires in TLS [KERBTLS] which utilizes the 
+    Kerberos protocol [KERB] [KERB94] in conjunction with TLS [TLS] 
+    which has commonly been thought of as a public key protocol.
+
+    The Kerberos can leverage the advantages provided by public key 
+    cryptography.  PKINIT [PKINIT] describes the use of public key 
+    cryptography in the initial authentication exchange in Kerberos.  
+    PKTAPP [PKTAPP] describes how an application service can essentially 
+    issue a kerberos ticket to itself after utilizing public key 
+    cryptography for authentication.  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 increase network traffic and 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) [X509] 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 [NEUMAN].  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
+    [KERB-REV]:
+    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.  Note that the service
+            name in the request is for pkcross/realm@REALM instead of
+            krbtgt/realm@REALM.
+
+        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 (for pkcross/realm@REALM) 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.
+
+
+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.  This is the reason
+    that the name pkcross/realm@REALM is used instead of
+    krbtgt/realm@REALM.  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
+
+  [KERBTLS]  A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
+             Suites to Transport Layer Security (TLS)", RFC 2712,
+             October 1999.
+
+  [KERB]     J. Kohl and C. Neuman, "The Kerberos Network
+             Authentication Service (V5)", RFC 1510, September 1993.
+
+  [TLS]      T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
+             RFC 2246, January 1999.
+
+  [PKINIT]   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-14.txt
+
+  [PKTAPP]   A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
+             Public Key Utilizing Tickets for Application
+             Servers (PKTAPP).  draft-ietf-cat-kerberos-pk-tapp-03.txt
+
+  [X509]     ITU-T (formerly CCITT) Information technology - Open
+             Systems Interconnection - The Directory: Authentication
+             Framework Recommendation X.509 ISO/IEC 9594-8
+
+  [NEUMAN]   B.C. Neuman, "Proxy-Based Authorization and Accounting for
+             Distributed Systems".  Proceedings of the 13th
+             International Conference on Distributed Computing Systems,
+             May 1993
+
+  [KERB94]   B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication
+             Service for Computer Networks, IEEE Communications,
+             32(9):33-38.  September 1994.
+
+  [KERB-REV] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network
+             Authentication Service (V5).
+             draft-ietf-cat-kerberos-revisions-08.txt
+
+
+11. Authors' Addresses
+
+    Matthew Hur
+    Cisco Systems
+    2901 Third Avenue
+    Seattle, WA 98121
+    Phone: +1 206 256 3197
+    E-Mail: mhur@cisco.com
+ 
+    Brian Tung
+    Tatyana Ryutov
+    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, tryutov, bcn}@isi.edu
+
+    Ari Medvinsky
+    Liberate
+    2 Circle Star Way
+    San Carlos, CA 94070-6200
+    Phone: +1 650 701 4000
+    EMail: ari@liberate.com
+
+    Gene Tsudik
+    ICS Dept, 458 CS Building 
+    Irvine CA 92697-3425
+    Phone: +1 310 448 9329
+    E-Mail: gts@ics.uci.edu
+
+    Bill Sommerfeld
+    Sun Microsystems
+    E-Mail: sommerfeld@east.sun.com
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt
new file mode 100644
index 00000000000..704c7caf2bf
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt
@@ -0,0 +1,373 @@
+
+INTERNET-DRAFT                                         Clifford Neuman
+draft-ietf-cat-kerberos-pk-init-00.txt                      Brian Tung
+Updates: RFC 1510                                                  ISI
+expires September 3, 1995                                    John Wray
+                                         Digital Equipment Corporation
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0. Status Of this Memo
+
+   This document is an Internet-Draft.   Internet-Drafts  are  working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid  for  a  maximum  of  six
+   months  and  may  be updated, replaced, or obsoleted by other docu-
+   ments at any time.  It is inappropriate to use  Internet-Drafts  as
+   reference  material  or  to  cite them other than as ``work in pro-
+   gress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
+   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
+   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   The distribution of  this  memo  is  unlimited.   It  is  filed  as
+   draft-ietf-cat-kerberos-pk-init-00.txt, and expires August 6, 1995.
+   Please send comments to the authors.
+
+
+1. Abstract
+
+   This document defines extensions to the Kerberos protocol  specifi-
+   cation  (RFC  1510,  "The  Kerberos  Network Authentication Service
+   (V5)", September 1993) to provide a method for using public key
+   cryptography during initial authentication.  The method defined 
+   specifies the way in which preauthentication data fields and error
+   data fields in Kerberos messages are to be used to transport public
+   key data. 
+
+2. Motivation
+
+   Public key cryptography provides a means by which a principal may
+   demonstrate possession of a key, without ever having divulged this
+   key to anyone else.  In conventional cryptography, the encryption key
+   and decryption key are either identical or can easily be derived from
+   each other.  In public key cryptography, however, neither key can be
+   derived easily from the other; hence, the ability to encrypt a message
+   does not imply the ability to decrypt it in turn.  Additionally, each
+   key is a full inverse of the other, so that either key can be used
+   for encryption or decryption.
+
+   The advantages provided by public key cryptography have produced a
+   demand for its integration into the Kerberos authentication protocol.
+   There are two important areas where public key cryptography will have
+   immediate use: in the initial authentication of users registered with
+   the KDC or using public key certificates from outside authorities,
+   and to establish inter-realm keys for cross-realm authentication.
+   This memo describes a method by which the first of these can be done.
+   The second case will be the topic for a separate proposal.
+
+   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 are drawn from the DASS system, and
+   similar extensions have been discussed for use in DCE.  These changes
+   are by no means endorsed by these groups.  This is an attempt to
+   revive some of the goals of that group, and the proposal approaches
+   those goals primarily from the Kerberos perspective.
+
+   This proposal will allow users with keys already registered for use
+   with X.509, PEM, or PGP, to use those keys to obtain Kerberos
+   credentials which can then be used for authentication with application
+   servers supporting Kerberos.
+
+   Use of public-key will not be a requirement for Kerberos, but if one's
+   organization runs a KDC supporting public key, then users may choose
+   to be registered with public keys instead of the current secret key.
+   The application request and response, between Kerberos clients and
+   application servers, will continue to be based on conventional
+   cryptography, and the application servers will continue to be
+   registered with conventional keys.
+
+
+3. Initial authentication of users with public keys
+
+   This section proposes extensions to Version 5 of the Kerberos
+   protocol that will support the use of public key cryptography 
+   by users in the initial request for a ticket granting ticket.
+
+   The advantage of registering public keys with the KDC lies in the
+   ease of recovery in case the KDC is compromised.  With Kerberos as it
+   currently stands, compromise of the security KDC is disastrous.  All
+   keys become known by the attacker and all keys must be changed.  
+
+   If users register public keys, compromise of the KDC does not divulge
+   their private key.  Compromise of security on the KDC is still
+   disastrous, since the attacker can impersonate any user.  An
+   attacker with the private key of the KDC can use it to certify a
+   bogus nonce key, and impersonate a user.  Changing this key
+   invalidates all bogus certifications.  Legitimate users must
+   re-certify their keys with the new KDC key, but users' public
+   keys do not have to be changed.  (Users who store their private
+   keys in an encrypted form on the KDC do have to change their
+   keys, since the encryption key is a symmetric key derived from
+   a password (as described below) and hence vulnerable to dictionary
+   attacks.  The difference is that, assuming good password policy,
+   site policy may allow the use of the old password only for the
+   purpose of key change for a time after the compromise, which means
+   that users can change their own passwords, rather than forcing the
+   administrator to re-key everyone.)
+
+   In the event of compromise of the KDC, recovery is simple since only
+   the KDC's key, keys for application servers, and users' private keys
+   stored in the KDC (as described above) must be changed.
+   Since there are usually fewer servers than users, and since an
+   organization usually has better procedures for updating servers,
+   changing these keys is much easier than having to individually
+   contact every user.
+
+   This proposed extension will not require users to register with
+   public keys.  It is intended to allow them to do so, but we recognize
+   that there are many reasons, including licensing terms, that users or
+   an organization as a whole will choose not to use the public key
+   option.  Users registered will public keys will only be able to
+   perform initial authentication from a client that support public key,
+   and must be registered in a realm that supports public key.  But they
+   will be able to use services registered in realms that support only
+   conventional Kerberos.  Further, users registered with conventional
+   Kerberos keys will be able to use all clients.
+
+   This proposal specifically does not address the registration of
+   public keys for services.  The application request and response,
+   between Kerberos clients and application servers, will continue to be
+   based on conventional cryptography, and the application servers will
+   continue to be registered with conventional keys. There are
+   performance issues and other reasons that servers may be better off
+   using conventional cryptography.  There are also reasons that they
+   may want to use public key.  For this proposal, however, we feel that
+   80 percent of the benefits of integrating public key with Kerberos
+   can be attained for 20 percent of the effort, by addressing only
+   initial authentication. This proposal does not preclude separate
+   extensions.
+
+   This proposal address two ways in which users may use public key
+   cryptography for initial authentication with Kerberos.  In both
+   cases, the end result is that the user obtains a conventional ticket
+   granting ticket, or conventional server ticket, that may be used for
+   subsequent authentication, with such subsequent authentication using
+   only conventional cryptography.
+
+   Users may register keys directly with the KDC, or they may present
+   certificates by outside certification authorities (or certifications
+   by other users) attesting to the association of the public key with
+   the named user.  We first consider the case where the user's key is
+   registered with the KDC.
+
+
+3.1 Initial request for user registered with public key on KDC 
+
+   In this scenario it is assumed that the user is registered with a public
+   key on the KDC.  The user's private key may be known to the user, or
+   may be stored on the KDC, encrypted so that it can not be used by the KDC.
+
+   We consider first the case where the user knows the private key, then
+   add support for retrieving the private key from the KDC.
+
+   The initial request to the KDC for a ticket granting ticket proceeds
+   according to RFC 1510.  Typically, preauthentication using a secret
+   key would not be included, but if included it may be ignored by the
+   KDC.  (This may introduce a problem: even if the KDC should ignore
+   the preauthentication, an attacker may not, and use an
+   intercepted message to guess the password off-line.)
+   If the private key is known to the client in advance, the
+   response from the KDC would be identical to the response in RFC1510,
+   except that instead of being encrypted in the secret key shared by the
+   client and the KDC, it is encrypted in a random key freshly generated
+   by the KDC.  A preauthentication field (specified below)
+   accompanies the response, containing a certificate with the public
+   key for the KDC, and a package containing the secret key in which the
+   rest of the response is encrypted, itself encrypted in the private key
+   of the KDC, and the public key of the user.  This package also contains
+   the same nonce used in the rest of the response, in order to prevent
+   replays of this part of the message, accompanied by a reconstructed
+   response.
+
+   PA-PK-AS-REP ::= SEQUENCE {
+	   kdc-cert	SEQUENCE OF OCTET STRING,
+           encryptPack  EncryptedData -- EncPaPkAsRepPart
+   }
+
+   EncPaPkAsRepPart ::= SEQUENCE {
+           enc-sess-key INTEGER,
+           nonce        INTEGER
+   }
+
+   Upon receipt of the response from the KDC, the client will verify the
+   public key for the KDC from PA-PK-AS-REP preauthentication data field,
+   The certificate must certify the key as belonging to a principal whose
+   name can be derived from the realm name.  We solicit discussion on the
+   form of the kdc-cert.  If client systems are expected to know (by
+   being hard-coded, for example) at least one public key, and to verify
+   certificates from that key, then there should be at least some policy
+   about which key that is, or alternatively some way to inform the KDC
+   which key the client possesses.
+
+   If the certificate checks
+   out, the client then extracts the message key for the rest of the
+   response by decrypting the field in the PA-PK-AS-REP with the public
+   key of the KDC and the private key of the user.  The client then uses
+   the message key to decrypt the rest of the response, and continues as
+   per RFC1510[1].
+
+
+3.1.1. Private key held by KDC
+
+   When the user's private key is not carried with the user, the user may
+   encrypt the private key using conventional cryptography, and register
+   the encrypted private key with the KDC.
+
+   When the user's private key is registered with the KDC, the KDC record
+   will also indicate whether preauthentication is required before
+   returning the record (we recommend that it be required).  If such
+   preauthentication is required, when the initial request is received
+   the KDC will respond with a KRB_ERROR message of type
+   KDC_ERR_PREAUTH_REQUIRED and with an error data field set to:
+
+   PA-PK-AS-INFO ::= SEQUENCE {
+	   kdc-cert	OCTET STRING}
+   }
+
+   The kdc-cert field is identical to that in the PA-PK-AS-REP
+   preauthentication data field returned with the KDC response, and must
+   be validated as belonging to the KDC in the same manner.
+
+   Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the
+   client will prompt the user for the password that will be used to
+   decrypt the private key when returned, calculate a one way hash H1 of the
+   key, and send a request to the KDC, including a timestamp and a
+   client-generated nonce secret key that will be used to super-encrypt
+   the encrypted private key before it is returned to the client.  This
+   information is sent to the KDC in a subsequent AS_REQ message in a
+   preauthentication data field:
+
+   PA-PK-AS-REQ ::= SEQUENCE {
+	   enc-part	EncryptedData -- EncPaPkAsReqPart
+   }
+
+   EncPaPkAsReqPart ::= SEQUENCE {
+           tstamp       KerberosTime,
+           noncekey	INTEGER
+   }
+
+   encrypted first with the hash H1, then the public key of the KDC from
+   the certificate in the PA-PK-AS-INFO field of the error response.
+
+   Upon receipt of the authentication request with the PA-PK-AS-REQ the
+   KDC verifies the hash of the user's DES encryption key by comparing it
+   to the hash stored in the users database record.  If valid, it
+   generates the AS response as defined in RFC1510, but additionally
+   includes a preauthentication field of type PA-PK-USER KEY.  This
+   response will also be included in response to the initial request
+   without preauthentication if preauthentication is not required for the
+   user and the user's encrypted private key is stored on the KDC.  The
+   KDC generates a preauthentication data field of type PA-PK-USER-KEY
+   which will be returned with the KDC reply (together with the
+   PA-PK-AS-REP that is already returned).
+
+   PA-PK-USER-KEY ::= SEQUENCE {
+           enc-priv-key         OCTET STRING OPTIONAL
+   }
+
+   This message contains the encrypted private key that has been
+   registered with the KDC by the user, as encrypted by the user,
+   super-encrypted with the noncekey from the PA-PK-AS-REQ message if
+   preauthentication using that method was provided.  Note that since
+   H1 is a one-way hash, it is not possible for one to decrypt the
+   message if one possesses H1 but not the noncekey that H1 is derived
+   from.
+
+
+3.2. Clients with a public key certified by an outside authority
+
+   In the case where the client is not registered with the current KDC,
+   the client is responsible for obtaining the private key on its own.
+   The client will request initial tickets from the KDC using the TGS
+   exchange, but instead of performing pre-authentication using a
+   Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used
+   when the public key is known to the KDC, the client performs
+   preauthentication using the preauthentication data field of type
+   PA-PK-AS-EXT-CERT:
+
+   PA-PK-AS-EXT-CERT ::= SEQUENCE {
+           user-cert	SEQUENCE OF OCTET STRING,
+	   authent	EncryptedData -- PKAuthenticator
+   }
+
+   PKAuthenticator ::= SEQUENCE {
+	   cksum	Checksum OPTIONAL,
+	   cusec	INTEGER,
+	   ctime	KerberosTime,
+   }
+
+   The fields in the encrypted authenticator are the same as those
+   in the Kerberos authenticator.  The structure is itself signed using
+   the user's private key corresponding to the public key in the
+   certificate. 
+
+   The KDC will verify the preauthentication authenticator, and check the
+   certification path against its own policy of legitimate certifiers.
+   This may be based on a certification hierarchy, or simply a list of
+   recognized certifiers in a system like PGP.
+
+   If all checks out, the KDC will issue Kerberos credentials, as in 3.1,
+   but with the names of all the certifiers in the certification path
+   added to the transited field of the ticket, with a principal name
+   taken from the certificate (this might be a long path for X.509, or a
+   string like "John Q. Public <jqpublic@company.com>" if the certificate
+   was a PGP certificate.  The realm will identify the kind of
+   certificate and the final certifier (e.g. PGP:<endorser@company.com>)[2].
+
+
+4. Compatibility with One-Time Passcodes
+
+   We solicit discussion on how the use of public key crytpgraphy for
+   intial authentication will interact with the proposed use of one time
+   passwords discussed in Internet Draft
+   draft-ietf-cat-kerberos-passwords-00.txt 
+
+5. Expiration
+
+   This Internet-Draft expires on August 6, 1995.
+
+
+6. Authors' Addresses
+
+   B. Clifford Neuman
+   USC/Information Sciences Institute
+   4676 Admiralty Way #1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: bcn@isi.edu
+
+
+   Brian Tung
+   USC/Information Sciences Institute
+   4676 Admiralty Way #1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: brian@isi.edu
+
+
+   John Wray
+   Digital Equipment Corporation
+   550 King Street, LKG2-2/Z7
+   Littleton, MA 01460
+
+   Phone: 508-486-5210
+   EMail: wray@tuxedo.enet.dec.com
+
+[1] Note: We have not yet defined the public key encryption method for
+encrypting the enc-sess-key field in the PA-PK-AS-REP.
+
+[2] Note: We are soliciting input on the form of the name.  We believe the
+name part must be taken without modification from the certificate, but the
+realm part is open for discussion.
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt
new file mode 100644
index 00000000000..e6ae54d9777
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt
@@ -0,0 +1,614 @@
+INTERNET-DRAFT                                         Clifford Neuman
+draft-ietf-cat-kerberos-pk-init-01.txt                      Brian Tung
+Updates: RFC 1510                                                  ISI
+expires December 7, 1996                                     John Wray
+                                         Digital Equipment Corporation
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0. Status Of this Memo
+
+   This document is an Internet-Draft.   Internet-Drafts  are  working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid  for  a  maximum  of  six
+   months  and  may  be updated, replaced, or obsoleted by other docu-
+   ments at any time.  It is inappropriate to use  Internet-Drafts  as
+   reference  material  or  to  cite them other than as ``work in pro-
+   gress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
+   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
+   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   The distribution of  this  memo  is  unlimited.   It  is  filed  as
+   draft-ietf-cat-kerberos-pk-init-01.txt, and expires December 7, 1996.
+   Please send comments to the authors.
+
+
+1. Abstract
+
+   This document defines extensions to the Kerberos protocol  specifi-
+   cation  (RFC  1510,  "The  Kerberos  Network Authentication Service
+   (V5)", September 1993) to provide a method for using public key
+   cryptography during initial authentication.  The method defined 
+   specifies the way in which preauthentication data fields and error
+   data fields in Kerberos messages are to be used to transport public
+   key data. 
+
+2. Motivation
+
+   Public key cryptography presents a means by which a principal may
+   demonstrate possession of a key, without ever having divulged this
+   key to anyone else.  In conventional cryptography, the encryption key
+   and decryption key are either identical or can easily be derived from
+   one another.  In public key cryptography, however, neither the public
+   key nor the private key can be derived from the other (although the
+   private key RECORD may include the information required to generate
+   BOTH keys).  Hence, a message encrypted with a public key is private,
+   since only the person possessing the private key can decrypt it;
+   similarly, someone possessing the private key can also encrypt a
+   message, thus providing a digital signature.
+
+   Furthermore, conventional keys are often derived from passwords, so
+   messages encrypted with these keys are susceptible to dictionary
+   attacks, whereas public key pairs are generated from a pseudo-random
+   number sequence.  While it is true that messages encrypted using
+   public key cryptography are actually encrypted with a conventional
+   secret key, which is in turn encrypted using the public key pair,
+   the secret key is also randomly generated and is hence not vulnerable
+   to a dictionary attack.
+
+   The advantages provided by public key cryptography have produced a
+   demand for its integration into the Kerberos authentication protocol.
+   The primary advantage of registering public keys with the KDC lies in
+   the ease of recovery in case the KDC is compromised.  With Kerberos as
+   it currently stands, compromise of the KDC is disastrous.  All
+   keys become known by the attacker and all keys must be changed.  
+
+   If users register public keys, compromise of the KDC does not divulge
+   their private key.  Compromise of security on the KDC is still a
+   problem, since an attacker can impersonate any user by certifying a
+   bogus key with the KDC's private key.  However, all bogus
+   certificates can be invalidated by revoking and changing the
+   KDC's public key.  Legitimate users have to re-certify their public
+   keys with the new KDC key, but the users's keys themselves do not
+   need to be changed.  Keys for application servers are conventional
+   symmetric keys and must be changed.
+
+   Note: If a user stores his private key, in an encrypted form, on the
+   KDC, then he does have to change the key pair, since the private key
+   is encrypted using a symmetric key derived from a password (as
+   described below), and is therefore vulnerable to dictionary attack.
+   Assuming good password policy, however, legitimate users may be
+   allowed to use the old password for a limited time, solely for the
+   purpose of changing the key pair.  The realm administrator is then
+   not forced to re-key all users.
+
+   There are two important areas where public key cryptography will have
+   immediate use: in the initial authentication of users registered with
+   the KDC or using public key certificates from outside authorities,
+   and to establish inter-realm keys for cross-realm authentication.
+   This memo describes a method by which the first of these can be done.
+   The second case will be the topic for a separate proposal.
+
+   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 are drawn from the DASS system, and
+   similar extensions have been discussed for use in DCE.  These changes
+   are by no means endorsed by these groups.  This is an attempt to
+   revive some of the goals of that group, and the proposal approaches
+   those goals primarily from the Kerberos perspective.
+
+
+3. Initial authentication of users with public keys
+
+   This section describes the extensions to Version 5 of the Kerberos
+   protocol that will support the use of public key cryptography by
+   users in the initial request for a ticket granting ticket.  This
+   proposal is based on the implementation already made available;
+   nevertheless, we solicit any comments on modifications or additions
+   to the protocol description below.
+
+   Roughly speaking, the following changes to RFC 1510 are proposed:
+       a.  The KDC's response is encrypted using a random nonce key,
+           rather than the user's secret key.
+       b.  This random key accompanies the response in a
+           preauthentication field, encrypted and signed using the
+           public key pairs of the user and the KDC.
+   Certificate and message formats are also defined in this section.
+
+   This proposal will allow users either to use keys registered directly
+   with the KDC, or to use keys already registered for use with X.509,
+   PEM, or PGP, to obtain Kerberos credentials.  These credentials can
+   then be used, as before, with application servers supporting Kerberos.
+   Use of public key cryptography will not be a requirement for Kerberos,
+   but if one's organization runs a KDC supporting public key, then users
+   may choose to be registered with a public key pair, instead of the
+   current secret key.
+
+   The application request and response between Kerberos clients and
+   application servers will continue to be based on conventional
+   cryptography, or will be converted to use user-to-user
+   authentication.  There are performance issues and other reasons
+   that servers may be better off using conventional cryptography.
+   For this proposal, we feel that 80 percent of the benefits of
+   integrating public key with Kerberos can be attained for 20 percent
+   of the effort, by addressing only initial authentication. This
+   proposal does not preclude separate extensions.
+
+   With these changes, users will be able to register public keys, only
+   in realms that support public key, and they will then only be able
+   to perform initial authentication from a client that supports public key,
+   although they will be able to use services registered in any realm.
+   Furthermore, users registered with conventional keys will be able
+   to use any client.
+
+   This proposal addresses three ways in which users may use public key
+   cryptography for initial authentication with Kerberos, with minimal
+   change to the existing protocol.  Users may register keys directly
+   with the KDC, or they may present certificates by outside certification
+   authorities (or certifications by other users) attesting to the
+   association of the public key with the named user.  In both cases,
+   the end result is that the user obtains a conventional ticket
+   granting ticket or conventional server ticket that may be used for
+   subsequent authentication, with such subsequent authentication using
+   only conventional cryptography.
+
+   Additionally, users may also register a digital signature key with
+   the KDC.  We provide this option for the licensing benefits, as well
+   as a simpler variant of the initial authentication exchange.  However,
+   this option relies on the client to generate random keys.
+
+   We first consider the case where the user's key is registered with
+   the KDC.
+
+
+3.1 Definitions
+
+   Before we proceed, we will lay some groundwork definitions for
+   encryption and signatures.  We propose the following definitions
+   of signature and encryption modes (and their corresponding values
+   on the wire):
+
+       #define ENCTYPE_SIGN_MD5_RSA      0x0011
+
+       #define ENCTYPE_ENCRYPT_RSA_PRIV  0x0021
+       #define ENCTYPE_ENCRYPT_RSA_PUB   0x0022
+
+   allowing further modes to be defined accordingly.
+
+   In the exposition below, we will use the notation E (T, K) to denote
+   the encryption of data T, with key (or parameters) K.
+
+   If E is ENCTYPE_SIGN_MD5_RSA, then
+
+       E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}
+
+   If E is ENCTYPE_ENCRYPT_RSA_PRIV, then
+
+       E (T, K) = RSAEncryptPrivate (T, K)
+
+   Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then
+
+       E (T, K) = RSAEncryptPublic (T, K)
+
+
+3.2 Initial request for user registered with public key on KDC 
+
+   In this scenario it is assumed that the user is registered with a
+   public key on the KDC.  The user's private key may be held by the
+   user, or it may be stored on the KDC, encrypted so that it cannot be
+   used by the KDC.
+
+3.2.1 User's private key is stored locally
+
+   If the user stores his private key locally, the initial request to
+   the KDC for a ticket granting ticket proceeds according to RFC 1510,
+   except that a preauthentication field containing a nonce signed by
+   the user's private key is included.  The preauthentication field
+   may also include a list of the root certifiers trusted by the user.
+
+   PA-PK-AS-ROOT ::= SEQUENCE {
+           rootCert[0]         SEQUENCE OF OCTET STRING,
+           signedAuth[1]       SignedPKAuthenticator
+   }
+
+   SignedPKAuthenticator ::= SEQUENCE {
+           authent[0]          PKAuthenticator,
+           authentSig[1]       Signature
+   }
+
+   PKAuthenticator ::= SEQUENCE {
+           cksum[0]            Checksum OPTIONAL,
+           cusec[1]            INTEGER,
+           ctime[2]            KerberosTime,
+           nonce[3]            INTEGER,
+           kdcRealm[4]         Realm,
+           kdcName[5]          PrincipalName
+   }
+
+   Signature ::= SEQUENCE {
+           sigType[0]          INTEGER,
+           kvno[1]             INTEGER OPTIONAL,
+           sigHash[2]          OCTET STRING
+   }
+
+   Notationally, sigHash is then
+
+       sigType (authent, userPrivateKey)
+
+   where userPrivateKey is the user's private key (corresponding to the
+   public key held in the user's database record).  Valid sigTypes are
+   thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect
+   that other types may be listed (and given on-the-wire values between
+   0x0011 and 0x001f).
+
+   The format of each certificate depends on the particular
+   service used.  (Alternatively, the KDC could send, with its reply,
+   a sequence of certifications (see below), but since the KDC is likely
+   to have more certifications than users have trusted root certifiers,
+   we have chosen the first method.)  In the event that the client
+   believes it already possesses the current public key of the KDC,
+   a zero-length root-cert field is sent.
+
+   The fields in the signed authenticator are the same as those
+   in the Kerberos authenticator; in addition, we include a client-
+   generated nonce, and the name of the KDC.  The structure is itself
+   signed using the user's private key corresponding to the public key
+   registered with the KDC.
+
+   Typically, preauthentication using a secret key would not be included,
+   but if included it may be ignored by the KDC.  (We recommend that it
+   not be included: even if the KDC should ignore the preauthentication,
+   an attacker may not, and use an intercepted message to guess the
+   password off-line.)
+
+   The response from the KDC would be identical to the response in RFC 1510,
+   except that instead of being encrypted in the secret key shared by the
+   client and the KDC, it is encrypted in a random key freshly generated
+   by the KDC (of type ENCTYPE_ENC_CBC_CRC).  A preauthentication field
+   (specified below) accompanies the response, optionally containing a
+   certificate with the public key for the KDC (since we do not assume
+   that the client knows this public key), and a package containing the
+   secret key in which the rest of the response is encrypted, along with
+   the same nonce used in the rest of the response, in order to prevent
+   replays.  This package is itself encrypted with the private key of the
+   KDC, then encrypted with the public key of the user.
+
+   PA-PK-AS-REP ::= SEQUENCE {
+           kdcCert[0]          SEQUENCE OF Certificate,
+           encryptShell[1]     EncryptedData, -- EncPaPkAsRepPartShell
+                                              -- encrypted by encReplyTmpKey
+           encryptKey[2]       EncryptedData  -- EncPaPkAsRepTmpKey
+                                              -- encrypted by userPubliKey
+   }
+
+   EncPaPkAsRepPartShell ::= SEQUENCE {
+           encReplyPart[0]     EncPaPkAsRepPart,
+           encReplyPartSig[1]  Signature -- encReplyPart
+                                         -- signed by kdcPrivateKey
+   }
+
+   EncPaPkAsRepPart ::= SEQUENCE {
+           encReplyKey[0]      EncryptionKey,
+           nonce[1]            INTEGER
+   }
+
+   EncPaPkAsRepTmpKey ::= SEQUENCE {
+           encReplyTmpKey[0]   EncryptionKey
+   }
+
+   Notationally, assume that encryptPack is encrypted (or signed) with
+   algorithm Ak, and that encryptShell is encrypted with algorithm Au.
+   Then, encryptShell is
+
+       Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey)
+
+   where kdcPrivateKey is the KDC's private key, and userPublicKey is the
+   user's public key.
+
+   The kdc-cert specification is lifted, with slight modifications,
+   from v3 of the X.509 certificate specification:
+
+   Certificate ::= SEQUENCE {
+           version[0]          Version DEFAULT v1 (1),
+           serialNumber[1]     CertificateSerialNumber,
+           signature[2]        AlgorithmIdentifier,
+           issuer[3]           PrincipalName,
+           validity[4]         Validity,
+           subjectRealm[5]     Realm,
+           subject[6]          PrincipalName,
+           subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
+           issuerUniqueID[8]   IMPLICIT UniqueIdentifier OPTIONAL,
+           subjectUniqueID[9]  IMPLICIT UniqueIdentifier OPTIONAL,
+           authentSig[10]      Signature
+   }
+
+   The kdc-cert must have as its root certification one of the certifiers
+   sent to the KDC with the original request.  If the KDC has no such
+   certification, then it will instead reply with a KRB_ERROR of type
+   KDC_ERROR_PREAUTH_FAILED.  If a zero-length root-cert was sent by the
+   client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length
+   kdc-cert may be absent, in which case the client uses its copy of the
+   KDC's public key.
+
+   Upon receipt of the response from the KDC, the client will verify the
+   public key for the KDC from PA-PK-AS-REP preauthentication data field,
+   The certificate must certify the key as belonging to a principal whose
+   name can be derived from the realm name.  If the certificate checks
+   out, the client then decrypts the EncPaPkAsRepPart using the private
+   key of the user, and verifies the signature of the KDC.  It then uses
+   the random key contained therein to decrypt the rest of the response,
+   and continues as per RFC 1510.  Because there is direct trust between
+   the user and the KDC, the transited field of the ticket returned by
+   the KDC should remain empty. (Cf. Section 3.3.)
+
+
+3.2.2. Private key held by KDC
+
+   Implementation of the changes in this section is OPTIONAL.
+
+   When the user's private key is not carried with the user, the user may
+   encrypt the private key using conventional cryptography, and register
+   the encrypted private key with the KDC.  The MD5 hash of the DES key
+   used to encrypt the private key must also be registered with the KDC.
+
+   We provide this option with the warning that storing the private key
+   on the KDC carries the risk of exposure in case the KDC is compromised.
+   If a suffiently good password is chosen to encrypt the key, then this
+   password can be used for a limited time to change the private key.
+   If the user wishes to authenticate himself without storing the private
+   key on each local disk, then a safer, albeit possibly less practical,
+   alternative is to use a smart card to store the keys.
+
+   When the user's private key is stored on the KDC, the KDC record
+   will also indicate whether preauthentication is required before
+   returning the key (we recommend that it be required).  If such
+   preauthentication is required, when the initial request is received,
+   the KDC will respond with a KRB_ERROR message, with msg-type set
+   to KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
+
+   PA-PK-AS-INFO ::= SEQUENCE {
+           kdcCert[0]          SEQUENCE OF Certificate
+   }
+
+   The kdc-cert field is identical to that in the PA-PK-AS-REP
+   preauthentication data field returned with the KDC response, and must
+   be validated as belonging to the KDC in the same manner.
+
+   Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the
+   client will prompt the user for the password that was used to
+   encrypt the private key, derive the DES key from that password,
+   and calculate the MD5 hash H1 of the DES key.  The client then sends
+   a request to the KDC, which includes a timestamp and a
+   client-generated random secret key that will be used by the KDC
+   to super-encrypt the encrypted private key before it is returned
+   to the client.  This information is sent to the KDC in a subsequent
+   AS_REQ message in a preauthentication data field:
+
+   PA-PK-AS-REQ ::= SEQUENCE {
+           encHashShell[0]     EncryptedData -- EncPaPkAsReqShell
+   }
+
+   EncPaPkAsReqShell ::= SEQUENCE {
+           encHashPart[0]      EncryptedData -- EncPaPkAsReqPart
+   }
+
+   EncPaPkAsReqPart ::= SEQUENCE {
+           encHashKey[0]       EncryptionKey,
+           nonce[1]            INTEGER
+   }
+
+   The EncPaPkAsReqPart is first encrypted with a DES key K1, derived
+   by string_to_key from the hash H1 (with null salt), then encrypted
+   again with the KDC's public key from the certificate in the
+   PA-PK-AS-INFO field of the error response.
+
+   Notationally, if encryption algorithm A is used for DES encryption,
+   and Ak is used for the public key encryption, then enc-shell is
+
+       Ak (A ({encHashKey, nonce}, K1), kdcPublicKey)
+
+   Upon receipt of the authentication request with the PA-PK-AS-REQ, the
+   KDC verifies the hash of the user's DES encryption key by attempting
+   to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ.  If decryption
+   is successful, the KDC generates the AS response as defined in
+   RFC 1510, but additionally includes a preauthentication field of type
+   PA-PK-USER-KEY.  (This response will also be included in response to
+   the initial request without preauthentication if preauthentication is
+   not required for the user and the user's encrypted private key is
+   stored on the KDC.)
+
+   PA-PK-USER-KEY ::= SEQUENCE {
+           encUserKeyPart[0]   EncryptedData -- EncPaPkUserKeyPart
+   }
+
+   EncPaPkUserKeyPart ::= SEQUENCE {
+           encUserKey[0]       OCTET STRING,
+           nonce[1]            INTEGER
+   }
+
+   Notationally, if encryption algorithm A is used, then enc-key-part is
+
+       A ({encUserKey, nonce}, enc-hash-key)
+
+   (where A could be null encryption).
+
+   This message contains the encrypted private key that has been
+   registered with the KDC by the user, as encrypted by the user,
+   optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ
+   message if preauthentication using that method was provided (otherwise,
+   the EncryptedData should denote null encryption).  Note that since
+   H1 is a one-way hash, it is not possible for one to decrypt the
+   message if one possesses H1 but not the DES key that H1 is derived
+   from.  Because there is direct trust between the user and the
+   KDC, the transited field of the ticket returned by the KDC should
+   remain empty.  (Cf. Section 3.3.)
+
+
+3.3. Clients with a public key certified by an outside authority
+
+   Implementation of the changes in this section is OPTIONAL.
+
+   In the case where the client is not registered with the current KDC,
+   the client is responsible for obtaining the private key on its own.
+   The client will request initial tickets from the KDC using the TGS
+   exchange, but instead of performing pre-authentication using a
+   Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used
+   when the public key is known to the KDC, the client performs
+   preauthentication using the preauthentication data field of type
+   PA-PK-AS-EXT-CERT:
+
+   PA-PK-AS-EXT-CERT ::= SEQUENCE {
+           userCert[0]         SEQUENCE OF OCTET STRING,
+           signedAuth[1]       SignedPKAuthenticator
+   }
+
+   where the user-cert specification depends on the type of certificate
+   that the user possesses.  In cases where the service has separate
+   key pairs for digital signature and for encryption, we recommend
+   that the signature keys be used for the purposes of sending the
+   preauthentication (and deciphering the response).
+
+   The authenticator is the one used from the exchange in section 3.2.1,
+   except that it is signed using the private key corresponding to
+   the public key in the user-cert.
+
+   The KDC will verify the preauthentication authenticator, and check the
+   certification path against its own policy of legitimate certifiers.
+   This may be based on a certification hierarchy, or simply a list of
+   recognized certifiers in a system like PGP.
+
+   If all checks out, the KDC will issue Kerberos credentials, as in 3.2,
+   but with the names of all the certifiers in the certification path
+   added to the transited field of the ticket, with a principal name
+   taken from the certificate (this might be a long path for X.509, or a
+   string like "John Q. Public <jqpublic@company.com>" if the certificate
+   was a PGP certificate.  The realm will identify the kind of
+   certificate and the final certifier as follows:
+
+       cert_type/final_certifier
+
+   as in PGP/<endorser@company.com>.
+
+
+3.4. Digital Signature
+
+   Implementation of the changes in this section is OPTIONAL.
+
+   We offer this option with the warning that it requires the client
+   process to generate a random DES key; this generation may not
+   be able to guarantee the same level of randomness as the KDC.
+
+   If a user registered a digital signature key pair with the KDC,
+   a separate exchange may be used.  The client sends a KRB_AS_REQ as
+   described in section 3.2.2.  If the user's database record
+   indicates that a digital signature key is to be used, then the
+   KDC sends back a KRB_ERROR as in section 3.2.2.
+
+   It is assumed here that the signature key is stored on local disk.
+   The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,
+   signs it using the signature key (otherwise the signature is
+   performed as described in section 3.2.1), then encrypts the whole with
+   the public key of the KDC.  This is returned with a separate KRB_AS_REQ
+   in a preauthentication of type
+
+   PA-PK-AS-SIGNED ::= SEQUENCE {
+           signedKey[0]        EncryptedData -- PaPkAsSignedData
+   }
+
+   PaPkAsSignedData ::= SEQUENCE {
+           signedKeyPart[0]    SignedKeyPart,
+           signedKeyAuth[1]    PKAuthenticator
+   }
+
+   SignedKeyPart ::= SEQUENCE {
+           encSignedKey[0]     EncryptionKey,
+           nonce[1]            INTEGER
+   }
+
+   where the nonce is the one from the request.  Upon receipt of the
+   request, the KDC decrypts, then verifies the random key.  It then
+   replies as per RFC 1510, except that instead of being encrypted
+   with the password-derived DES key, the reply is encrypted using
+   the randomKey sent by the client.  Since the client already knows
+   this key, there is no need to accompany the reply with an extra
+   preauthentication field.  Because there is direct trust between
+   the user and the KDC, the transited field of the ticket returned
+   by the KDC should remain empty.  (Cf. Section 3.3.)
+
+
+4. Preauthentication Data Types
+
+   We propose that the following preauthentication types be allocated
+   for the preauthentication data packages described in this draft:
+
+       #define KRB5_PADATA_ROOT_CERT     17  /* PA-PK-AS-ROOT */
+       #define KRB5_PADATA_PUBLIC_REP    18  /* PA-PK-AS-REP */
+       #define KRB5_PADATA_PUBLIC_REQ    19  /* PA-PK-AS-REQ */
+       #define KRB5_PADATA_PRIVATE_REP   20  /* PA-PK-USER-KEY */
+       #define KRB5_PADATA_PUBLIC_EXT    21  /* PA-PK-AS-EXT-CERT */
+       #define KRB5_PADATA_PUBLIC_SIGN   22  /* PA-PK-AS-SIGNED */
+
+
+5. Encryption Information
+
+   For the public key cryptography used in direct registration, we used
+   (in our implementation) the RSAREF library supplied with the PGP 2.6.2
+   release.  Encryption and decryption functions were implemented directly
+   on top of the primitives made available therein, rather than the
+   fully sealing operations in the API.
+
+
+6. Compatibility with One-Time Passcodes
+
+   We solicit discussion on how the use of public key cryptography for initial
+   authentication will interact with the proposed use of one time passwords
+   discussed in Internet Draft <draft-ietf-cat-kerberos-passwords-00.txt>.
+
+
+7. Strength of Encryption and Signature Mechanisms
+
+   In light of recent findings on the strengths of MD5 and various DES
+   modes, we solicit discussion on which modes to incorporate into the
+   protocol changes.
+
+
+8. Expiration
+
+   This Internet-Draft expires on December 7, 1996.
+
+
+9. Authors' Addresses
+
+   B. Clifford Neuman
+   USC/Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: bcn@isi.edu
+
+   Brian Tung
+   USC/Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: brian@isi.edu
+
+   John Wray
+   Digital Equipment Corporation
+   550 King Street, LKG2-2/Z7
+   Littleton, MA 01460
+
+   Phone: 508-486-5210
+   EMail: wray@tuxedo.enet.dec.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt
new file mode 100644
index 00000000000..1a15ae33e8f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt
@@ -0,0 +1,1120 @@
+INTERNET-DRAFT                                         Clifford Neuman
+draft-ietf-cat-kerberos-pk-init-02.txt                      Brian Tung
+Updates: RFC 1510                                                  ISI
+expires April 19, 1997                                       John Wray
+                                         Digital Equipment Corporation
+						      Jonathan Trostle
+						 CyberSafe Corporation
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0. Status Of this Memo
+
+   This document is an Internet-Draft.   Internet-Drafts  are  working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid  for  a  maximum  of  six
+   months  and  may  be updated, replaced, or obsoleted by other docu-
+   ments at any time.  It is inappropriate to use  Internet-Drafts  as
+   reference  material  or  to  cite them other than as ``work in pro-
+   gress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
+   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
+   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   The distribution of  this  memo  is  unlimited.   It  is  filed  as
+   draft-ietf-cat-kerberos-pk-init-02.txt, and expires April 19, 1997.
+   Please send comments to the authors.
+
+
+1. Abstract
+
+   This document defines extensions to the Kerberos protocol
+   specification (RFC 1510, "The Kerberos Network Authentication
+   Service (V5)", September 1993) to provide a method for using public
+   key cryptography during initial authentication.  The method defined
+   specifies the way in which preauthentication data fields and error
+   data fields in Kerberos messages are to be used to transport public
+   key data. 
+
+2. Motivation
+
+   Public key cryptography presents a means by which a principal may
+   demonstrate possession of a key, without ever having divulged this
+   key to anyone else.  In conventional cryptography, the encryption
+   key and decryption key are either identical or can easily be
+   derived from one another. In public key cryptography, however,
+   neither the public key nor the private key can be derived from the
+   other (although the private key RECORD may include the information
+   required to generate BOTH keys). Hence, a message encrypted with a
+   public key is private, since only the person possessing the private
+   key can decrypt it; similarly, someone possessing the private key
+   can also encrypt a message, thus providing a digital signature.
+
+   Furthermore, conventional keys are often derived from passwords, so
+   messages encrypted with these keys are susceptible to dictionary
+   attacks, whereas public key pairs are generated from a
+   pseudo-random number sequence.  While it is true that messages
+   encrypted using public key cryptography are actually encrypted with
+   a conventional secret key, which is in turn encrypted using the
+   public key pair, the secret key is also randomly generated and is
+   hence not vulnerable to a dictionary attack.
+
+   The advantages provided by public key cryptography have produced a
+   demand for its integration into the Kerberos authentication
+   protocol. The public key integration into Kerberos described in
+   this document has three goals. 
+
+   First, by allowing users to register public keys with the KDC, the
+   KDC can be recovered much more easily in the event it is
+   compromised. With Kerberos as it currently stands, compromise of
+   the KDC is disastrous. All keys become known by the attacker and
+   all keys must be changed. Second, we allow users that have public
+   key certificates signed by outside authorities to obtain Kerberos
+   credentials for access to Kerberized services. Third, we obtain the
+   above benefits while maintaining the performance advantages of
+   Kerberos over protocols that use only public key authentication. 
+
+   If users register public keys, compromise of the KDC does not
+   divulge their private key.  Compromise of security on the KDC is
+   still a problem, since an attacker can impersonate any user by
+   creating a ticket granting ticket for the user. When the compromise
+   is detected, the KDC can be cleaned up and restored from backup
+   media and loaded with a backup private/public key pair. Keys for
+   application servers are conventional symmetric keys and must be
+   changed.
+
+   Note: If a user stores his private key, in an encrypted form, on
+   the KDC, then it may be desirable to change the key pair, since the
+   private key is encrypted using a symmetric key derived from a
+   password (as described below), and can therefore be vulnerable to
+   dictionary attack if a good password policy is not used. 
+   Alternatively, if the encrypting symmetric key has 56 bits, then it
+   may also be desirable to change the key pair after a short period
+   due to the short key length. The KDC does not have access to the
+   user's unencrypted private key.
+
+   There are two important areas where public key cryptography will
+   have immediate use: in the initial authentication of users
+   registered with the KDC or using public key certificates from
+   outside authorities, and to establish inter-realm keys for
+   cross-realm authentication. This memo describes a method by which
+   the first of these can be done. The second case will be the topic
+   for a separate proposal.
+
+   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 are drawn from the DASS system, and
+   similar extensions have been discussed for use in DCE.  These
+   changes are by no means endorsed by these groups.  This is an
+   attempt to revive some of the goals of that group, and the
+   proposal approaches those goals primarily from the Kerberos
+   perspective.
+
+3. Initial authentication of users with public keys
+
+   This section describes the extensions to Version 5 of the Kerberos
+   protocol that will support the use of public key cryptography by
+   users in the initial request for a ticket granting ticket.  
+
+   Roughly speaking, the following changes to RFC 1510 are proposed:
+   Users can initially authenticate using public key or conventional
+   (symmetric key) cryptography. After a KDC compromise, the KDC
+   replies with an error message that informs the client of the new
+   KDC public backup key. Users must authenticate using public key 
+   cryptography in response to the error message. If applicable, the 
+   client generates the new user secret key at this point as well. 
+
+   Public key initial authentication is performed using either the 
+   RSA encryption or Diffie Hellman public key algorithms. There is 
+   also an option to allow the user to store his/her private key 
+   encrypted in the user password in the KDC database; this option 
+   solves the problem of transporting the user private key to
+   different workstations. The combination of this option and the
+   provision for conventional symmetric key authentication allows
+   organizations to smoothly migrate to public key cryptography.
+
+   This proposal will allow users either to use keys registered
+   directly with the KDC, or to use keys already registered for use
+   with X.509, PEM, or PGP, to obtain Kerberos credentials.  These
+   credentials can then be used, as before, with application servers
+   supporting Kerberos. Use of public key cryptography will not be a
+   requirement for Kerberos, but if one's organization runs a KDC
+   supporting public key, then users may choose to be registered with
+   a public key pair, instead of or in addition to the current secret
+   key.
+
+   The application request and response between Kerberos clients and
+   application servers will continue to be based on conventional
+   cryptography, or will be converted to use user-to-user
+   authentication.  There are performance issues and other reasons
+   that servers may be better off using conventional cryptography.
+   For this proposal, we feel that 80 percent of the benefits of
+   integrating public key with Kerberos can be attained for 20 percent
+   of the effort, by addressing only initial authentication. This
+   proposal does not preclude separate extensions.
+
+   With these changes, users will be able to register public keys,
+   only in realms that support public key, but they will still be able
+   to perform initial authentication from a client that does not
+   support public key. They will be able to use services registered in
+   any realm. Furthermore, users registered with conventional keys
+   will be able to use any client.
+
+   This proposal addresses three ways in which users may use public
+   key cryptography for initial authentication with Kerberos, with
+   minimal change to the existing protocol.  Users may register keys
+   directly with the KDC, or they may present certificates by outside
+   certification authorities (or certifications by other users)
+   attesting to the association of the public key with the named user.
+   In both cases, the end result is that the user obtains a
+   conventional ticket granting ticket or conventional server ticket
+   that may be used for subsequent authentication, with such
+   subsequent authentication using only conventional cryptography.
+
+   Additionally, users may also register a digital signature
+   verification key with the KDC.  We provide this option for the
+   licensing benefits, as well as a simpler variant of the initial
+   authentication exchange. However, this option relies on the client
+   to generate random keys.
+
+   We first consider the case where the user's key is registered with
+   the KDC.
+
+3.1 Definitions
+
+   Before we proceed, we will lay some groundwork definitions for
+   encryption and signatures.  We propose the following definitions
+   of signature and encryption modes (and their corresponding values
+   on the wire):
+
+       #define ENCTYPE_SIGN_MD5_RSA      0x0011
+
+       #define ENCTYPE_ENCRYPT_RSA_PRIV  0x0021
+       #define ENCTYPE_ENCRYPT_RSA_PUB   0x0022
+
+   allowing further modes to be defined accordingly.
+
+   In the exposition below, we will use the notation E (T, K) to
+   denote the encryption of data T, with key (or parameters) K.
+
+   If E is ENCTYPE_SIGN_MD5_RSA, then
+
+       E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}
+
+   If E is ENCTYPE_ENCRYPT_RSA_PRIV, then
+
+       E (T, K) = RSAEncryptPrivate (T, K)
+
+   Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then
+
+       E (T, K) = RSAEncryptPublic (T, K)
+
+
+3.2 Initial request for user registered with public key on KDC 
+
+   In this scenario it is assumed that the user is registered with a
+   public key on the KDC.  The user's private key may be held by the
+   user, or it may be stored on the KDC, encrypted so that it cannot
+   be used by the KDC.
+
+3.2.1 User's private key is stored locally
+
+   Implementation of the changes in this section is REQUIRED.
+
+   In this section, we present the basic Kerberos V5 pk-init protocol
+   that all conforming implementations must support. The key features 
+   of the protocol are: (1) easy, automatic (for the clients) recovery 
+   after a KDC compromise, (2) the ability for a realm to support a
+   mix of old and new Kerberos V5 clients with the new clients being a
+   mix of both public key and symmetric key configured clients, and
+   (3) support for Diffie-Hellman (DH) key exchange as well as RSA
+   public key encryption. The benefit of having new clients being able
+   to use either symmetric key or public key initial authentication is
+   that it allows an organization to roll out the new clients as
+   rapidly as possible without having to be concerned about the need
+   to purchase additional hardware to support the CPU intensive public
+   key cryptographic operations. 
+
+   In order to give a brief overview of the four protocols in this
+   section, we now give diagrams of the protocols. We denote
+   encryption of message M with key K by {M}K and the signature of
+   message M with key K by [M]K. All messages from the KDC to the
+   client are AS_REP messages unless denoted otherwise; similarly, all
+   messages from the client to the KDC are AS_REQ messages unless
+   denoted otherwise. Since only the padata fields are affected by
+   this specification in the AS_REQ and AS_REP messages, we do not
+   show the other fields. We first show the RSA encryption option in
+   normal mode:
+       
+      certifier list, [cksum, time, nonce, kdcRealm, 
+      kdcName]User PrivateKey
+   C ------------------------------------------------------> KDC
+
+      list of cert's, {[encReplyKey, nonce]KDC privkey}
+      EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
+   C <------------------------------------------------------ KDC
+
+
+   We now show RSA encryption in recovery mode:
+
+      certifier list, [cksum, time, nonce, kdcRealm, 
+      kdcName]User PrivateKey
+   C ------------------------------------------------------> KDC
+
+
+      KRB_ERROR (error code KDC_RECOVERY_NEEDED) 
+                 error data: [nonce, algID (RSA), 
+                 KDC PublicKey Kvno and PublicKey, KDC Salt]
+                 Signed with KDC PrivateKey
+   C <------------------------------------------------------ KDC
+
+
+      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
+      {newUserSymmKey, nonce}KDC public key]User PrivateKey
+   C ------------------------------------------------------> KDC
+
+
+      list of cert's, {[encReplyKey, nonce]KDC privkey}
+      EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
+   C <------------------------------------------------------ KDC
+
+   Next, we show Diffie Hellman in normal mode:
+
+      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
+      User DH public parameter]User PrivateKey
+   C ------------------------------------------------------> KDC
+
+
+      list of cert's, {encReplyKey, nonce}DH shared symmetric 
+      key, [KDC DH public parameter]KDC Private Key
+   C <------------------------------------------------------ KDC
+
+
+   Finally, we show Diffie Hellman in recovery mode:
+
+      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
+      User DH public parameter]User PrivateKey
+   C ------------------------------------------------------> KDC
+
+
+      KRB_ERROR (error code KDC_RECOVERY_NEEDED)
+                error data: [nonce, algID (DH), KDC DH public 
+                             parameter, KDC DH ID, KDC PublicKey 
+                             Kvno and PublicKey, KDC Salt]
+                             Signed with KDC PrivateKey
+   C <------------------------------------------------------ KDC
+
+
+      certifier list, [cksum, time, nonce, kdcRealm, 
+      kdcName, User DH public parameter, {newUserSymmKey, 
+      nonce}DH shared key, KDC DH ID]User PrivateKey
+   C ------------------------------------------------------> KDC
+
+
+      list of cert's, {encReplyKey, nonce}DH shared 
+      symmetric key
+   C <------------------------------------------------------ KDC
+
+
+
+   If the user stores his private key locally, the initial request 
+   to the KDC for a ticket granting ticket proceeds according to 
+   RFC 1510, except that a preauthentication field containing a 
+   nonce signed by the user's private key is included.  The 
+   preauthentication field may also include a list of the root 
+   certifiers trusted by the user.
+
+   PA-PK-AS-ROOT ::= SEQUENCE {
+           rootCert[0]         SEQUENCE OF OCTET STRING,
+           signedAuth[1]       SignedPKAuthenticator
+   }
+
+   SignedPKAuthenticator ::= SEQUENCE {
+           authent[0]          PKAuthenticator,
+           authentSig[1]       Signature
+   }
+
+   PKAuthenticator ::= SEQUENCE {
+           cksum[0]            Checksum OPTIONAL,
+           cusec[1]            INTEGER,
+           ctime[2]            KerberosTime,
+           nonce[3]            INTEGER,
+           kdcRealm[4]         Realm,
+           kdcName[5]          PrincipalName,
+	   clientPubValue[6]   SubjectPublicKeyInfo OPTIONAL, 
+                                  -- DH algorithm
+	   recoveryData[7]     RecoveryData OPTIONAL          
+                                  -- Recovery Alg.
+   }
+
+   RecoveryData ::= SEQUENCE {
+           clientRecovData[0]  ClientRecovData, 
+	   kdcPubValueId[1]    INTEGER OPTIONAL 
+                                   -- DH algorithm, copied
+                                   -- from KDC response     
+   }
+
+   ClientRecovData ::= CHOICE {
+           newPrincKey[0]      EncryptedData, -- EncPaPkAsRoot
+					      -- encrypted with 
+                                              -- either KDC 
+					      -- public key or 
+                                              -- DH shared key   
+           recovDoneFlag[1]    INTEGER        -- let KDC know that
+                                              -- recovery is done
+                                              -- when user uses a
+                                              -- mix of clients or
+                                              -- does not want to
+                                              -- keep a symmetric
+                                              -- key in the database
+   }
+
+   EncPaPkAsRoot ::= SEQUENCE {
+           newSymmKey[0]       EncryptionKey  -- the principal's new 
+                                              -- symmetric key
+           nonce[1]            INTEGER        -- the same nonce as
+                                              -- the one in the 
+                                              -- PKAuthenticator  
+   }
+
+   Signature ::= SEQUENCE {
+           sigType[0]          INTEGER,
+           kvno[1]             INTEGER OPTIONAL,
+           sigHash[2]          OCTET STRING
+   }
+
+   Notationally, sigHash is then
+
+       sigType (authent, userPrivateKey)
+
+   where userPrivateKey is the user's private key (corresponding to the
+   public key held in the user's database record). Valid sigTypes are
+   thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect
+   that other types may be listed (and given on-the-wire values between
+   0x0011 and 0x001f).
+
+   The format of each certificate depends on the particular service
+   used.  (Alternatively, the KDC could send, with its reply, a
+   sequence of certifications (see below), but since the KDC is likely
+   to have more certifications than users have trusted root certifiers,
+   we have chosen the first method.)  In the event that the client
+   believes it already possesses the current public key of the KDC, a
+   zero-length root-cert field is sent.
+
+   The fields in the signed authenticator are the same as those in the
+   Kerberos authenticator; in addition, we include a client-generated
+   nonce, and the name of the KDC.  The structure is itself signed
+   using the user's private key corresponding to the public key 
+   registered with the KDC. We include the newSymmKey field so clients
+   can generate a new symmetric key (for users, this key is based on
+   a password and a salt value generated by the KDC) and
+   confidentially send this key to the KDC during the recovery phase. 
+
+   We now describe the recovery phase of the protocol. There is a bit
+   associated with each principal in the database indicating whether
+   recovery for that principal is necessary. After a KDC compromise,
+   the KDC software is reloaded from backup media and a new backup
+   KDC public/private pair is generated. The public half of this pair
+   is then either made available to the KDC, or given to the
+   appropriate certification authorities for certification. The private
+   half is not made available to the KDC until after the next
+   compromise clean-up. If clients are maintaining a copy of the KDC
+   public key, they also have a copy of the backup public key.
+
+   After the reload of KDC software, the bits associated with
+   recovery of each principal are all set. The KDC clears the bit
+   for each principal that undergoes the recovery phase. In addition,
+   there is a bit associated with each principal to indicate whether
+   there is a valid symmetric key in the database for the principal.
+   These bits are all cleared after the reload of the KDC software
+   (the old symmetric keys are no longer valid). Finally, there is a
+   bit associated with each principal indicating whether that
+   principal still uses non-public key capable clients. If a user
+   principal falls into this category, a public key capable client
+   cannot transparently re-establish a symmetric key for that user,
+   since the older clients would not be able to compute the new
+   symmetric key that includes hashing the password with a KDC
+   supplied salt value. The re-establishment of the symmetric key 
+   in this case is outside the scope of this protocol. 
+
+   One method of re-establishing a symmetric key for public key
+   capable clients is to generate a hash of the user password and a
+   KDC supplied salt value. The KDC salt is changed after every
+   compromise of the KDC. In the recovery protocol, if the principal
+   does not still use old clients, the KDC supplied salt is sent to
+   the client principal in a KRB_ERROR message with error code
+   KDC_RECOVERY_NEEDED. The error data field of the message contains
+   the following structure which is encoded into an octet string.
+
+   PA-PK-KDC-ERR ::= CHOICE {
+           recoveryDhErr      SignedDHError,   -- Used during recovery   
+                                               -- when algorithm is DH 
+                                               -- based
+           recoveryPKEncErr   SignedPKEncError -- Used during recovery
+                                               -- for PK encryption 
+                                               -- (RSA,...)
+   }
+
+   SignedDHError ::= SEQUENCE {
+           dhErr              DHError,
+           dhErrSig           Signature
+   }
+
+   SignedPKEncError ::= SEQUENCE {
+           pkEncErr           PKEncryptError,
+           pkEncErrSig        Signature
+   }
+
+   DHError ::= SEQUENCE {
+           nonce	      INTEGER,		     -- From AS_REQ
+           algorithmId        INTEGER,               -- DH algorithm
+           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
+           kdcPubValueId      INTEGER,               -- DH algorithm
+           kdcPublicKeyKvno   INTEGER OPTIONAL,      -- New KDC public
+                                                     -- key kvno
+           kdcPublicKey       OCTET STRING OPTIONAL, -- New KDC pubkey
+	   kdcSalt            OCTET STRING OPTIONAL  -- If user uses 
+                                                     -- only new
+                                                     -- clients
+   }
+
+   PKEncryptError ::= SEQUENCE {
+           nonce              INTEGER,               -- From AS_REQ
+           algorithmId        INTEGER,               -- Public Key
+                                                     -- encryption alg
+           kdcPublicKeyKvno   INTEGER OPTIONAL,      -- New KDC public 
+                                                     -- key kvno
+           kdcPublicKey       OCTET STRING OPTIONAL, -- New KDC public
+                                                     -- key
+	   kdcSalt            OCTET STRING OPTIONAL  -- If user uses 
+                                                     -- only new
+                                                     -- clients
+   }
+
+   The KDC_RECOVERY_NEEDED error message is sent in response to a 
+   client AS_REQ message if the client principal needs to be 
+   recovered, unless the client AS_REQ contains the PKAuthenticator
+   with a nonempty RecoveryData field (in this case the client has
+   already received the KDC_RECOVERY_NEEDED error message. We will
+   also see in section 3.2.2 that a different error response is
+   sent by the KDC if the encrypted user private key is stored in
+   the KDC database.) If the client principal uses only new clients, 
+   then the kdcSalt field is returned; otherwise, the kdcSalt field
+   is absent. 
+
+   If the client uses the Diffie Hellman algorithm during the recovery
+   phase then the DHError field contains the public Diffie Hellman 
+   parameter (kdcPubValue) for the KDC along with an identifier 
+   (kdcPubValueID). The client will then send this identifier to 
+   the KDC in an AS_REQ message; the identifier allows the KDC to 
+   look up the Diffie Hellman private value corresponding to the
+   identifier. Depending on how often the KDC updates its private
+   Diffie Hellman parameters, it will have to store anywhere between a
+   handful and several dozen of these identifiers and their parameters.
+   The KDC must send its Diffie Hellman public value to the client
+   first so the client can encrypt its new symmetric key.
+
+   In the case where the user principal does not need to be recovered
+   and the user still uses old clients as well as new clients, the 
+   KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ 
+   messages when there is no valid symmetric key in the KDC database. 
+   This situation can occur if the user principal has been recovered 
+   but no new symmetric key has been established in the database.
+ 
+   In addition, the two error messages with error codes 
+   KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified 
+   so the error data contains the kdcSalt encoded as an OCTET STRING. 
+   The reason for the modification is to allow principals that use 
+   new clients only to have their symmetric key transparently updated
+   by the client software during the recovery phase. The kdcSalt is
+   used to create the new symmetric key. As a performance optimization,
+   the kdcSalt is stored in the /krb5/salt file along with the realm.
+   Thus the /krb5/salt file consists of realm-salt pairs. If the file
+   is missing, or the salt is not correct, the above error messages
+   allow the client to find out the correct salt. New clients which 
+   are configured for symmetric key authentication attempt to 
+   preauthenticate with the salt from the /krb5/salt file as an 
+   input into their key, and if the file is not present, the new client
+   does not use preauthentication. The error messages above return
+   either the correct salt to use, or no salt at all which indicates
+   that the principal is still using old clients (the client software
+   should use the existing mapping from the user password to the
+   symmetric key).
+
+   In order to assure interoperability between clients from different
+   vendors and organizations, a standard algorithm is needed for
+   creating the symmetric key from the principal password and kdcSalt.
+   The algorithm for creating the symmetric key is as follows: take the
+   SHA-1 hash of the kdcSalt concatenated with the principal password
+   and use the 20 byte output as the input into the existing key
+   generation process (string to key function). After a compromise, the
+   KDC changes the kdcSalt; thus, the recovery algorithm allows users
+   to obtain a new symmetric key without actually changing their
+   password.
+
+   The response from the KDC would be identical to the response in RFC
+   1510, except that instead of being encrypted in the secret key
+   shared by the client and the KDC, it is encrypted in a random key
+   freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A 
+   preauthentication field (specified below) accompanies the response, 
+   optionally containing a certificate with the public key for the KDC 
+   (since we do not assume that the client knows this public key), and
+   a package containing the secret key in which the rest of the 
+   response is encrypted, along with the same nonce used in the rest
+   of the response, in order to prevent replays. This package is itself
+   signed with the private key of the KDC, then encrypted with the
+   symmetric key that is returned encrypted in the public key of the
+   user (or for Diffie Hellman, encrypted in the shared secret Diffie
+   Hellman symmetric key). 
+
+   Pictorially, in the public key encryption case we have:
+
+   kdcCert, {[encReplyKey, nonce] Sig w/KDC 
+   privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
+
+   Pictorially, in the Diffie Hellman case we have:
+
+   kdcCert, {encReplyKey, nonce}DH shared symmetric key,
+   [DH public value]Sig w/KDC privkey
+
+   PA-PK-AS-REP ::= SEQUENCE {
+           kdcCert[0]          SEQUENCE OF Certificate,
+           encryptShell[1]     EncryptedData, 
+                                           -- EncPaPkAsRepPartShell
+                                           -- encrypted by 
+                                           -- encReplyTmpKey or DH 
+                                           -- shared symmetric key
+           pubKeyExchange[2]   PubKeyExchange OPTIONAL, 
+                                           -- a choice between 
+                                           -- a KDC signed DH 
+                                           -- value and a public 
+                                           -- key encrypted 
+                                           -- symmetric key.
+                                           -- Not needed after
+                                           -- recovery when
+                                           -- DH is used.
+   }                                         
+
+   PubKeyExchange ::= CHOICE {
+           signedDHPubVal      SignedDHPublicValue, 
+           encryptKey          EncryptedData  
+                                           -- EncPaPkAsRepTmpKey
+                                           -- encrypted by 
+                                           -- userPublicKey
+   }
+
+   SignedDHPublicValue ::= SEQUENCE {
+           dhPublic[0]         SubjectPublicKeyInfo,
+           dhPublicSig[1]      Signature
+   }
+
+   EncPaPkAsRepPartShell ::= SEQUENCE {
+           encReplyPart[0]     EncPaPkAsRepPart,
+           encReplyPartSig[1]  Signature OPTIONAL 
+                                    -- encReplyPart
+                                    -- signed by kdcPrivateKey
+                                    -- except not present in 
+                                    -- DH case
+   }
+
+   EncPaPkAsRepPart ::= SEQUENCE {
+           encReplyKey[0]      EncryptionKey,
+           nonce[1]            INTEGER,
+   }
+
+   EncPaPkAsRepTmpKey ::= SEQUENCE {
+           encReplyTmpKey[0]   EncryptionKey
+   }
+
+   The kdc-cert specification is lifted, with slight modifications,
+   from v3 of the X.509 certificate specification:
+
+   Certificate ::= SEQUENCE {
+           version[0]          Version DEFAULT v1 (1),
+           serialNumber[1]     CertificateSerialNumber,
+           signature[2]        AlgorithmIdentifier,
+           issuer[3]           PrincipalName,
+           validity[4]         Validity,
+           subjectRealm[5]     Realm,
+           subject[6]          PrincipalName,
+           subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
+           issuerUniqueID[8]   IMPLICIT UniqueIdentifier OPTIONAL,
+           subjectUniqueID[9]  IMPLICIT UniqueIdentifier OPTIONAL,
+           authentSig[10]      Signature
+   }
+
+   The kdc-cert must have as its root certification one of the
+   certifiers sent to the KDC with the original request.  If the KDC
+   has no such certification, then it will instead reply with a
+   KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED.  If a zero-length
+   root-cert was sent by the client as part of the PA-PK-AS-ROOT, then
+   a correspondingly zero-length kdc-cert may be absent, in which case
+   the client uses its copy of the KDC's public key. In the case of
+   recovery, the client uses its copy of the backup KDC public key. 
+
+   Upon receipt of the response from the KDC, the client will verify 
+   the public key for the KDC from PA-PK-AS-REP preauthentication data 
+   field. The certificate must certify the key as belonging to a
+   principal whose name can be derived from the realm name.  If the
+   certificate checks out, the client then decrypts the EncPaPkAsRepPart
+   and verifies the signature of the KDC.  It then uses the random key
+   contained therein to decrypt the rest of the response, and continues
+   as per RFC 1510. Because there is direct trust between the user and
+   the KDC, the transited field of the ticket returned by the KDC should
+   remain empty. (Cf. Section 3.3.)
+
+   Examples
+
+   We now give several examples illustrating the protocols in this 
+   section. Encryption of message M with key K is denoted {M}K and
+   the signature of message M with key K is denoted [M]K.
+
+   Example 1: The requesting user principal needs to be recovered and
+   uses only new clients. The recovery algorithm is Diffie Hellman (DH).
+   Then the exchange sequence between the user principal and the KDC is:
+
+   
+   Client  --------> AS_REQ (with or without preauth) --------> KDC
+
+   Client  <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC
+                error data: [nonce, algID (DH), KDC DH public parameter,
+                            KDC DH ID, KDC PublicKey Kvno and PublicKey,
+                            KDC Salt]Signed with KDC PrivateKey
+
+   At this point, the client validates the KDC signature, checks to 
+   see if the nonce is the same as the one in the AS_REQ, and stores
+   the new KDC public key and public key version number. The client 
+   then generates a Diffie Hellman private parameter and computes
+   the corresponding Diffie Hellman public parameter; the client
+   also computes the shared Diffie Hellman symmetric key using the
+   KDC Diffie Hellman public parameter and its own Diffie Hellman 
+   private parameter. Next, the client prompts the user for his/her
+   password (if it does not already have the password). The password
+   is concatenated with the KDC Salt and then SHA1 hashed; the 
+   result is fed into the string to key function to obtain the new
+   user DES key.
+
+   The new user DES key will be encrypted (along with the AS_REQ
+   nonce) using the Diffie Hellman symmetric key and sent to the 
+   KDC in the new AS_REQ message:
+
+   Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with
+             user DH public parameter, {newUser DES key, nonce}DH 
+             symmetric key, KDC DH ID]Signed with User PrivateKey 
+                                                        -> KDC
+
+   The KDC DH ID is copied by the client from the KDC_ERROR message
+   received above. Upon receipt and validation of this message, the
+   KDC first uses the KDC DH ID as an index to locate its
+   private Diffie Hellman parameter; it uses this parameter in 
+   combination with the user public Diffie Hellman parameter
+   to compute the symmetric Diffie Hellman key. The KDC checks
+   if the encrypted nonce is the same as the one in the 
+   PKAuthenticator and the AS_REQ part. The KDC then enters
+   the new user DES key into the database, resets the recovery 
+   needed bit, and sets the valid symmetric key in database
+   bit. The KDC then creates the AS_REP message:
+
+   Client <-- AS_REP with preauth: kdcCert, {encReplyKey,
+              nonce}DH symmetric key <-------------------- KDC
+
+   
+   The AS_REP encrypted part is encrypted with the encReplyKey
+   that is generated on the KDC. The nonces are copied from the
+   client AS_REQ. The kdcCert is a sequence of certificates
+   that have been certified by certifiers listed in the client
+   rootCert field, unless a zero length rootCert field was sent.
+   In the last case, the kdcCert will also have zero length.   
+
+3.2.2. Private key held by KDC
+
+   Implementation of the changes in this section is RECOMMENDED.
+
+   When the user's private key is not carried with the user, the 
+   user may encrypt the private key using conventional cryptography, 
+   and register the encrypted private key with the KDC.  As
+   described in the previous section, the SHA1 hash of the password
+   concatenated with the kdcSalt is also stored in the KDC database
+   if the user only uses new clients. We restrict users of this
+   protocol to using new clients only. The reason for this restriction
+   is that it is not secure to store both the user private key 
+   encrypted in the user's password and the user password on the KDC 
+   simultaneously.
+
+   There are several options for storing private keys. If the 
+   user stores their private key on a removable disk, it is 
+   less convenient since they need to always carry the disk 
+   around with them; in addition, the procedures for extracting 
+   the key may vary between different operating systems. 
+   Alternatively, the user can store a private key on the hard
+   disks of systems that he/she uses; besides limiting the 
+   systems that the user can login from there is also a 
+   greater security risk to the private key. If smart card 
+   readers or slots are deployed in an organization, then the 
+   user can store his/her private key on a smart card. Finally, 
+   the user can store his/her private key encrypted in a password 
+   on the KDC. This last option is probably the most practical
+   option currently; it is important that a good password policy 
+   be used.
+
+   When the user's private key is stored on the KDC, 
+   preauthentication is required. There are two cases depending on 
+   whether the requesting user principal needs to be recovered. 
+
+   In order to obtain its private key, a user principal includes the
+   padata type PA-PK-AS-REQ in the preauthentication data
+   field of the AS_REQ message. The accompanying pa-data field is:
+
+   PA-PK-AS-REQ ::= SEQUENCE {
+           algorithmId[0]       INTEGER,      -- Public Key Alg.
+           encClientPubVal[1]   EncryptedData -- EncPaPkAsReqDH
+                                              -- (encrypted with key
+                                              -- K1)
+   }
+
+   EncPaPkAsReqDH ::= SEQUENCE {
+           clientPubValue[0]    SubjectPublicKeyInfo 
+   }
+
+   Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1.
+
+   The user principal sends its Diffie-Hellman public value encrypted
+   in the key K1. The key K1 is derived by performing string to key on
+   the SHA1 hash of the user password concatenated with the kdcSalt 
+   which is stored in the /krb5/salt file. If the file is absent, 
+   the concatenation step is skipped in the above algorithm. The 
+   Diffie Hellman parameters g and p are implied by the algorithmID
+   field. By choosing g and p correctly, dictionary attacks against
+   the key K1 can be made more difficult [Jaspan].
+
+   If the requesting user principal needs recovery, the encrypted 
+   user private key is stored in the KDC database, and the AS_REQ 
+   RecoveryData field is not present in the PKAuthenticator, then 
+   the KDC replies with a KRB_ERROR message, with msg-type set to 
+   KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
+
+   PA-PK-AS-INFO ::= SEQUENCE {
+           signedDHErr         SignedDHError,         -- signed by KDC
+           encUserKey          OCTET STRING OPTIONAL  -- encrypted by
+                                                      -- user password 
+                                                      -- key; (recovery
+                                                      -- response)
+
+   }
+
+   The user principal should then continue with the section 3.2.1.1
+   protocol using the Diffie Hellman algorithm. 
+
+   We now assume that the requesting user principal does not need
+   recovery. 
+
+   Upon receipt of the authentication request with the PA-PK-AS-REQ, 
+   the KDC generates the AS response as defined in RFC 1510, but 
+   additionally includes a preauthentication field of type 
+   PA-PK-USER-KEY. 
+
+   PA-PK-USER-KEY ::= SEQUENCE {
+           kdcCert            SEQUENCE OF Certificate,
+           encUserKeyPart     EncryptedData, -- EncPaPkUserKeyPart           
+           kdcPrivKey         KDCPrivKey,
+           kdcPrivKeySig      Signature
+   }
+
+   The kdc-cert field is identical to that in the PA-PK-AS-REP
+   preauthentication data field returned with the KDC response, and 
+   must be validated as belonging to the KDC in the same manner.
+
+   KDCPrivKey ::= SEQUENCE {
+           nonce	      INTEGER,		     -- From AS_REQ
+           algorithmId        INTEGER,               -- DH algorithm
+           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
+	   kdcSalt            OCTET STRING           -- Since user
+                                                     -- uses only new
+                                                     -- clients
+   }
+
+   The KDCPrivKey field is signed using the KDC private key.
+   The encrypted part of the AS_REP message is encrypted using the 
+   Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart.
+
+   EncPaPkUserKeyPart ::= SEQUENCE {
+           encUserKey         OCTET STRING,
+           nonce              INTEGER                -- From AS_REQ
+   }
+
+   Notationally, if encryption algorithm A is used, then enc-key-part
+   is
+
+       A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key).
+
+   If the client has used an incorrect kdcSalt to compute the
+   key K1, then the client needs to resubmit the above AS_REQ
+   message using the correct kdcSalt field from the KDCPrivKey
+   field. 
+
+   This message contains the encrypted private key that has been
+   registered with the KDC by the user, as encrypted by the user,
+   super-encrypted with the Diffie Hellman derived symmetric key.
+   Because there is direct trust between the user and the KDC, the 
+   transited field of the ticket returned by the KDC should remain 
+   empty.  (Cf. Section 3.3.)
+
+   Examples
+
+   We now give several examples illustrating the protocols in this 
+   section.
+
+   Example 1: The requesting user principal needs to be recovered
+   and stores his/her encrypted private key on the KDC. Then the 
+   exchange sequence between the user principal and the KDC is:
+
+   Client  --------> AS_REQ (with or without preauth) -----> KDC
+
+   Client  <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED)
+                error data: [nonce, algID (DH), KDC DH public 
+                            parameter, KDC DH ID, KDC PublicKey 
+                            Kvno and PublicKey, KDC Salt]Signed 
+                            with KDC PrivateKey, {user private 
+                            key}user password <------------- KDC
+
+   The protocol now continues with the second AS_REQ as in Example
+   1 of section 3.2.1.1.
+   
+   Example 2: The requesting user principal does not need to be 
+   recovered and stores his/her encrypted private key on the KDC. 
+   Then the exchange sequence between the user principal and the KDC 
+   when the user principal wants to obtain his/her private key is:
+
+   Client  -> AS_REQ with preauth: algID, 
+              {DH public parameter}K1 -> KDC
+
+   The key K1 is generated by using the string to key function 
+   on the SHA1 hash of the password concatenated with the kdcSalt
+   from the /krb5/salt file. If the file is absent, then 
+   the concatenation step is skipped, and the client will learn 
+   the correct kdcSalt in the following AS_REP message from the
+   KDC. The algID should indicate some type of Diffie Hellman
+   algorithm.
+
+   The KDC replies with the AS_REP message with a preauthentication
+   data field:
+
+   Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC
+              nonce}DH symmetric key, [nonce, algID, DH
+              public parameter, kdcSalt]KDC privateKey
+
+   The client validates the KDC's signature and checks that
+   the nonce matches the nonce in its AS_REQ message.
+   If the kdcSalt does not match what the client used, it
+   starts the protocol over. The client then uses the KDC
+   Diffie Hellman public parameter along with its own Diffie
+   Hellman private parameter to compute the Diffie Hellman 
+   symmetric key. This key is used to decrypt the encUserKey
+   field; the client checks if the nonce matches its AS_REQ
+   nonce. At this point, the initial authentication protocol
+   is complete.  
+
+   Example 3: The requesting user principal does not need to be 
+   recovered and stores his/her encrypted private key on the KDC.
+   In this example, the user principal uses the conventional
+   symmetric key Kerberos V5 initial authentication protocol
+   exchange. 
+
+   We note that the conventional protocol exposes the user 
+   password to dictionary attacks; therefore, the user password 
+   must be changed more often. An example of when this protocol 
+   would be used is when new clients have been installed but an 
+   organization has not phased in public key authentication for 
+   all clients due to performance concerns.
+
+   Client ----> AS_REQ with preauthentication: {time}K1 --> KDC
+
+   Client <--------------------  AS_REP <------------------ KDC
+
+   The key K1 is derived as in the preceding two examples. 
+
+
+3.3. Clients with a public key certified by an outside authority
+
+   Implementation of the changes in this section is OPTIONAL.
+
+   In the case where the client is not registered with the current
+   KDC, the client is responsible for obtaining the private key on
+   its own. The client will request initial tickets from the KDC
+   using the TGS exchange, but instead of performing
+   preauthentication using a Kerberos ticket granting ticket, or
+   with the PA-PK-AS-REQ that is used when the public key is known
+   to the KDC, the client performs preauthentication using the
+   preauthentication data field of type PA-PK-AS-EXT-CERT:
+
+   PA-PK-AS-EXT-CERT ::= SEQUENCE {
+           userCert[0]         SEQUENCE OF OCTET STRING,
+           signedAuth[1]       SignedPKAuthenticator
+   }
+
+   where the user-cert specification depends on the type of
+   certificate that the user possesses.  In cases where the service
+   has separate key pairs for digital signature and for encryption,
+   we recommend that the signature keys be used for the purposes of
+   sending the preauthentication (and deciphering the response).
+
+   The authenticator is the one used from the exchange in section
+   3.2.1, except that it is signed using the private key corresponding
+   to the public key in the user-cert.
+
+   The KDC will verify the preauthentication authenticator, and check the
+   certification path against its own policy of legitimate certifiers.
+   This may be based on a certification hierarchy, or simply a list of
+   recognized certifiers in a system like PGP.
+
+   If all checks out, the KDC will issue Kerberos credentials, as in 3.2,
+   but with the names of all the certifiers in the certification path
+   added to the transited field of the ticket, with a principal name
+   taken from the certificate (this might be a long path for X.509, or a
+   string like "John Q. Public <jqpublic@company.com>" if the certificate
+   was a PGP certificate.  The realm will identify the kind of
+   certificate and the final certifier as follows:
+
+       cert_type/final_certifier
+
+   as in PGP/<endorser@company.com>.
+
+
+3.4. Digital Signature
+
+   Implementation of the changes in this section is OPTIONAL.
+
+   We offer this option with the warning that it requires the client
+   process to generate a random DES key; this generation may not
+   be able to guarantee the same level of randomness as the KDC.
+
+   If a user registered a digital signature key pair with the KDC,
+   a separate exchange may be used.  The client sends a KRB_AS_REQ 
+   as described in section 3.2.2.  If the user's database record
+   indicates that a digital signature key is to be used, then the
+   KDC sends back a KRB_ERROR as in section 3.2.2.
+
+   It is assumed here that the signature key is stored on local disk.
+   The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,
+   signs it using the signature key (otherwise the signature is
+   performed as described in section 3.2.1), then encrypts the whole
+   with the public key of the KDC.  This is returned with a separate
+   KRB_AS_REQ in a preauthentication of type
+
+   PA-PK-AS-SIGNED ::= SEQUENCE {
+           signedKey[0]        EncryptedData -- PaPkAsSignedData
+   }
+
+   PaPkAsSignedData ::= SEQUENCE {
+           signedKeyPart[0]    SignedKeyPart,
+           signedKeyAuth[1]    PKAuthenticator,
+           sig[2]              Signature
+   }
+
+   SignedKeyPart ::= SEQUENCE {
+           encSignedKey[0]     EncryptionKey,
+           nonce[1]            INTEGER
+   }
+
+   where the nonce is the one from the request.  Upon receipt of the
+   request, the KDC decrypts, then verifies the random key.  It then
+   replies as per RFC 1510, except that instead of being encrypted
+   with the password-derived DES key, the reply is encrypted using
+   the randomKey sent by the client.  Since the client already knows
+   this key, there is no need to accompany the reply with an extra
+   preauthentication field.  Because there is direct trust between
+   the user and the KDC, the transited field of the ticket returned
+   by the KDC should remain empty.  (Cf. Section 3.3.)
+
+   In the event that the KDC database indicates that the user 
+   principal must be recovered, and the PKAuthenticator does not 
+   contain the RecoveryData field, the KDC will reply with the
+   KDC_RECOVERY_NEEDED error. The user principal then sends
+   another AS_REQ message that includes the RecoveryData field
+   in the PKAuthenticator. The AS_REP message is the same as
+   in the basic Kerberos V5 protocol. 
+
+
+4. Preauthentication Data Types
+
+   We propose that the following preauthentication types be allocated
+   for the preauthentication data packages described in this draft:
+
+       #define KRB5_PADATA_ROOT_CERT     17  /* PA-PK-AS-ROOT */
+       #define KRB5_PADATA_PUBLIC_REP    18  /* PA-PK-AS-REP */
+       #define KRB5_PADATA_PUBLIC_REQ    19  /* PA-PK-AS-REQ */
+       #define KRB5_PADATA_PRIVATE_REP   20  /* PA-PK-USER-KEY */
+       #define KRB5_PADATA_PUBLIC_EXT    21  /* PA-PK-AS-EXT-CERT */
+       #define KRB5_PADATA_PUBLIC_SIGN   22  /* PA-PK-AS-SIGNED */
+
+
+5. Encryption Information
+
+   For the public key cryptography used in direct registration, we
+   used (in our implementation) the RSAREF library supplied with the
+   PGP 2.6.2 release.  Encryption and decryption functions were
+   implemented directly on top of the primitives made available
+   therein, rather than the fully sealing operations in the API.
+
+
+6. Compatibility with One-Time Passcodes
+
+   We solicit discussion on how the use of public key cryptography
+   for initial authentication will interact with the proposed use of
+   one time passwords discussed in Internet Draft
+   <draft-ietf-cat-kerberos-passwords-00.txt>.
+
+7. Strength of Encryption and Signature Mechanisms
+
+   In light of recent findings on the strengths of MD5 and various DES
+   modes, we solicit discussion on which modes to incorporate into the
+   protocol changes.
+
+
+8. Expiration
+
+   This Internet-Draft expires on April 19, 1997.
+
+
+9. Authors' Addresses
+
+   B. Clifford Neuman
+   USC/Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: bcn@isi.edu
+
+   Brian Tung
+   USC/Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: brian@isi.edu
+
+   John Wray
+   Digital Equipment Corporation
+   550 King Street, LKG2-2/Z7
+   Littleton, MA 01460
+
+   Phone: 508-486-5210
+   EMail: wray@tuxedo.enet.dec.com
+
+   Jonathan Trostle
+   CyberSafe Corporation
+   1605 NW Sammamish Rd., Suite 310
+   Issaquah, WA 98027-5378
+
+   Phone: 206-391-6000
+   EMail: jonathan.trostle@cybersafe.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
new file mode 100644
index 00000000000..c59aa3c0e6f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
@@ -0,0 +1,588 @@
+INTERNET-DRAFT                                         Clifford Neuman
+draft-ietf-cat-kerberos-pk-init-03.txt                      Brian Tung
+Updates: RFC 1510                                                  ISI
+expires September 30, 1997                                   John Wray
+                                         Digital Equipment Corporation
+                                                         Ari Medvinsky
+                                                           Matthew Hur
+                                                 CyberSafe Corporation
+                                                      Jonathan Trostle
+                                                                Novell
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of this Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as "work in
+    progress."
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ds.internic.net (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30,
+    1997.  Please send comments to the authors.
+
+
+1.  Abstract
+
+    This document defines extensions (PKINIT) to the Kerberos protocol
+    specification (RFC 1510 [1]) to provide a method for using public
+    key cryptography during initial authentication.  The methods
+    defined specify the ways in which preauthentication data fields and
+    error data fields in Kerberos messages are to be used to transport
+    public key data.
+
+
+2.  Introduction
+
+    The popularity of public key cryptography has produced a desire for
+    its support in Kerberos [2].  The advantages provided by public key
+    cryptography include simplified key management (from the Kerberos
+    perspective) and the ability to leverage existing and developing
+    public key certification infrastructures.
+
+    Public key cryptography can be integrated into Kerberos in a number
+    of ways.  One is to to associate a key pair with each realm, which
+    can then be used to facilitate cross-realm authentication; this is
+    the topic of another draft proposal.  Another way is to allow users
+    with public key certificates to use them in initial authentication.
+    This is the concern of the current document.
+
+    One of the guiding principles in the design of PKINIT is that
+    changes should be as minimal as possible.  As a result, the basic
+    mechanism of PKINIT is as follows:  The user sends a request to the
+    KDC as before, except that if that user is to use public key
+    cryptography in the initial authentication step, his certificate
+    accompanies the initial request, in the preauthentication fields.
+
+    Upon receipt of this request, the KDC verifies the certificate and
+    issues a ticket granting ticket (TGT) as before, except that instead
+    of being encrypted in the user's long-term key (which is derived
+    from a password), it is encrypted in a randomly-generated key.  This
+    random key is in turn encrypted using the public key certificate
+    that came with the request and signed using the KDC's signature key,
+    and accompanies the reply, in the preauthentication fields.
+
+    PKINIT also allows for users with only digital signature keys to
+    authenticate using those keys, and for users to store and retrieve
+    private keys on the KDC.
+
+    The PKINIT specification may also be used for direct peer to peer
+    authentication without contacting a central KDC. This application
+    of PKINIT is described in PKTAPP [4] and is based on concepts
+    introduced in [5, 6]. For direct client-to-server authentication,
+    the client uses PKINIT to authenticate to the end server (instead
+    of a central KDC), which then issues a ticket for itself.  This
+    approach has an advantage over SSL [7] in that the server does not
+    need to save state (cache session keys).  Furthermore, an
+    additional benefit is that Kerberos tickets can facilitate
+    delegation (see [8]).
+
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510 for supporting the
+    use of public key cryptography in the initial request for a ticket
+    granting ticket (TGT).
+
+    In summary, the following changes to RFC 1510 are proposed:
+
+        --> Users may authenticate using either a public key pair or a
+            conventional (symmetric) key.  If public key cryptography is
+            used, public key data is transported in preauthentication
+            data fields to help establish identity.
+        --> Users may store private keys on the KDC for retrieval during
+            Kerberos initial authentication.
+
+    This proposal addresses two ways that users may use public key
+    cryptography for initial authentication.  Users may present public
+    key certificates, or they may generate their own session key,
+    signed by their digital signature key.  In either case, the end
+    result is that the user obtains an ordinary TGT that may be used for
+    subsequent authentication, with such authentication using only
+    conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 and 3.3 describe the extensions for the two initial
+    authentication methods.  Section 3.3 describes a way for the user to
+    store and retrieve his private key on the KDC.
+
+
+3.1.  Definitions
+
+    Hash and encryption types will be specified using ENCTYPE tags; we
+    propose the addition of the following types:
+
+        #define ENCTYPE_SIGN_DSA_GENERATE   0x0011
+        #define ENCTYPE_SIGN_DSA_VERIFY     0x0012
+        #define ENCTYPE_ENCRYPT_RSA_PRIV    0x0021
+        #define ENCTYPE_ENCRYPT_RSA_PUB     0x0022
+
+    allowing further signature types to be defined in the range 0x0011
+    through 0x001f, and further encryption types to be defined in the
+    range 0x0021 through 0x002f.
+
+    The extensions involve new preauthentication fields.  The
+    preauthentication data types are in the range 17 through 21.
+    These values are also specified along with their corresponding
+    ASN.1 definition.
+
+        #define PA-PK-AS-REQ                17
+        #define PA-PK-AS-REP                18
+        #define PA-PK-AS-SIGN               19
+        #define PA-PK-KEY-REQ               20
+        #define PA-PK-KEY-REP               21
+
+    The extensions also involve new error types.  The new error types
+    are in the range 227 through 229.  They are:
+
+        #define KDC_ERROR_CLIENT_NOT_TRUSTED    227
+        #define KDC_ERROR_KDC_NOT_TRUSTED       228
+        #define KDC_ERROR_INVALID_SIG           229
+
+    In the exposition below, we use the following terms: encryption key,
+    decryption key, signature key, verification key.  It should be
+    understood that encryption and verification keys are essentially
+    public keys, and decryption and signature keys are essentially
+    private keys.  The fact that they are logically distinct does
+    not preclude the assignment of bitwise identical keys.
+
+
+3.2.  Standard Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with pk-init.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's signature key accompanies the request:
+
+    PA-PK-AS-REQ ::- SEQUENCE {
+                                -- PA TYPE 17
+        signedPKAuth            [0] SignedPKAuthenticator,
+        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the user's certificate
+                                    -- optionally followed by that
+                                    -- certificate's certifier chain
+        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
+                                    -- CAs that the client trusts
+    }
+
+    SignedPKAuthenticator ::= SEQUENCE {
+        pkAuth                  [0] PKAuthenticator,
+        pkAuthSig               [1] Signature,
+                                    -- of pkAuth
+                                    -- using user's signature key
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+                                    -- for replay prevention
+        ctime                   [1] KerberosTime,
+                                    -- for replay prevention
+        nonce                   [2] INTEGER,
+                                    -- binds response to this request
+        kdcName                 [3] PrincipalName,
+        clientPubValue          [4] SubjectPublicKeyInfo OPTIONAL,
+                                    -- for Diffie-Hellman algorithm
+    }
+
+    Signature ::= SEQUENCE {
+        signedHash              [0] EncryptedData
+                                    -- of type Checksum
+                                    -- encrypted under signature key
+    }
+
+    Checksum ::=   SEQUENCE {
+        cksumtype               [0] INTEGER,
+        checksum                [1] OCTET STRING
+    }   -- as specified by RFC 1510
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm               [0] algorithmIdentifier,
+        subjectPublicKey        [1] BIT STRING
+    }   -- as specified by the X.509 recommendation [9]
+
+    Certificate ::= SEQUENCE {
+        CertType                [0] INTEGER,
+                                    -- type of certificate
+                                    -- 1 = X.509v3 (DER encoding)
+                                    -- 2 = PGP (per PGP draft)
+        CertData                [1] OCTET STRING
+                                    -- actual certificate
+                                    -- type determined by CertType
+    }
+
+    Note: If the signature uses RSA keys, then it is to be performed
+    as per PKCS #1.
+
+    The PKAuthenticator carries information to foil replay attacks,
+    to bind the request and response, and to optionally pass the
+    client's Diffie-Hellman public value (i.e. for using DSA in
+    combination with Diffie-Hellman).  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    In the PKAuthenticator, the client may specify the KDC name in one
+    of two ways: 1) a Kerberos principal name, or 2) the name in the
+    KDC's certificate (e.g., an X.500 name, or a PGP name).  Note that
+    case #1 requires that the certificate name and the Kerberos principal
+    name be bound together (e.g., via an X.509v3 extension).
+
+    The userCert field is a sequence of certificates, the first of which
+    must be the user's public key certificate. Any subsequent
+    certificates will be certificates of the certifiers of the user's
+    certificate.  These cerificates may be used by the KDC to verify the
+    user's public key.  This field is empty if the KDC already has the
+    user's certifcate.
+
+    The trustedCertifiers field contains a list of certification
+    authorities trusted by the client, in the case that the client does
+    not possess the KDC's public key certificate.
+
+    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
+    type, the KDC attempts to verify the user's certificate chain
+    (userCert), if one is provided in the request.  This is done by
+    verifying the certification path against the KDC's policy of
+    legitimate certifiers.  This may be based on a certification
+    hierarchy, or it may be simply a list of recognized certifiers in a
+    system like PGP.  If the certification path does not match one of
+    the KDC's trusted certifiers, the KDC sends back an error message of
+    type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
+    field a list of its own trusted certifiers, upon which the client
+    resends the request.
+
+    If  trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
+    verifies that it has a certificate issued by one of the certifiers
+    trusted by the client.  If it does not have a suitable certificate,
+    the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
+    to the client. 
+
+    If a trust relationship exists, the KDC then verifies the client's
+    signature on PKAuthenticator.  If that fails, the KDC returns an
+    error message of type KDC_ERROR_INVALID_SIG.  Otherwise, the KDC
+    uses the timestamp in the PKAuthenticator to assure that the request
+    is not a replay.   The KDC also verifies that its name is specified
+    in PKAuthenticator.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except that it
+    encrypts the reply not with the user's key, but with a random key
+    generated only for this particular response.  This random key
+    is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= SEQUENCE {
+                               -- PA TYPE 18
+        kdcCert                 [0] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the KDC's certificate
+                                    -- optionally followed by that
+                                    -- certificate's certifier chain
+        encPaReply              [1] EncryptedData,
+                                    -- of type PaReply
+                                    -- using either the client public
+                                    -- key or the Diffie-Hellman key
+                                    -- specified by SignedDHPublicValue
+        signedDHPublicValue     [2] SignedDHPublicValue OPTIONAL
+    }
+
+
+    PaReply ::= SEQUENCE {
+        replyEncKeyPack         [0] ReplyEncKeyPack,
+        replyEncKeyPackSig      [1] Signature,
+                                    -- of replyEncKeyPack
+                                    -- using KDC's signature key
+    }
+
+    ReplyEncKeyPack ::= SEQUENCE {
+        replyEncKey             [0] EncryptionKey,
+                                    -- used to encrypt main reply
+        nonce                   [1] INTEGER
+                                    -- binds response to the request
+                                    -- passed in the PKAuthenticator
+    }
+
+    SignedDHPublicValue ::= SEQUENCE {
+        dhPublicValue           [0] SubjectPublicKeyInfo,
+        dhPublicValueSig        [1] Signature
+                                    -- of dhPublicValue
+                                    -- using KDC's signature key
+    }
+
+    The kdcCert field is a sequence of certificates, the first of which
+    must have as its root certifier one of the certifiers sent to the
+    KDC in the PA-PK-AS-REQ. Any subsequent certificates will be 
+    certificates of the certifiers of the KDC's certificate.  These
+    cerificates may be used by the client to verify the KDC's public
+    key.  This field is empty if the client did not send to the KDC a
+    list of trusted certifiers (the trustedCertifiers field was empty).
+    
+    Since each certifier in the certification path of a user's
+    certificate is essentially a separate realm, the name of each
+    certifier shall be added to the transited field of the ticket.  The
+    format of these realm names shall follow the naming constraints set
+    forth in RFC 1510 (sections 7.1 and 3.3.3.1).  Note that this will
+    require new nametypes to be defined for PGP certifiers and other
+    types of realms as they arise.
+
+    The KDC's certificate must bind the public key to a name derivable
+    from the name of the realm for that KDC.  The client then extracts
+    the random key used to encrypt the main reply.  This random key (in
+    encPaReply) is encrypted with either the client's public key or
+    with a key derived from the DH values exchanged between the client
+    and the KDC.
+
+
+3.3.  Digital Signature
+
+    Implementation of the changes in this section are OPTIONAL for
+    compliance with pk-init.
+
+    We offer this option with the warning that it requires the client to
+    generate a random key; the client may not be able to guarantee the
+    same level of randomness as the KDC.
+
+    If the user registered a digital signature key with the KDC instead
+    of an encryption key, then a separate exchange must be used.  The
+    client sends a request for a TGT as usual, except that it (rather
+    than the KDC) generates the random key that will be used to encrypt
+    the KDC response.  This key is sent to the KDC along with the
+    request in a preauthentication field:
+
+    PA-PK-AS-SIGN ::= SEQUENCE {
+                                -- PA TYPE 19
+        encSignedKeyPack        [0] EncryptedData
+                                    -- of SignedKeyPack
+                                    -- using the KDC's public key
+    }
+
+    SignedKeyPack ::= SEQUENCE {
+        signedKey               [0] KeyPack,
+        signedKeyAuth           [1] PKAuthenticator,
+        signedKeySig            [2] Signature
+                                    -- of signedKey.signedKeyAuth
+                                    -- using user's signature key
+    }
+
+    KeyPack ::= SEQUENCE {
+        randomKey               [0] EncryptionKey,
+                                    -- will be used to encrypt reply
+        nonce                   [1] INTEGER
+    }
+
+    where the nonce is copied from the request.
+
+    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
+    the randomKey.  It then replies as per RFC 1510, except that the
+    reply is encrypted not with a password-derived user key, but with
+    the randomKey sent in the request.  Since the client already knows
+    this key, there is no need to accompany the reply with an extra
+    preauthentication field.  The transited field of the ticket should
+    specify the certification path as described in Section 3.2.
+
+
+3.4.  Retrieving the Private Key From the KDC
+
+    Implementation of the changes in this section is RECOMMENDED for
+    compliance with pk-init.
+
+    When the user's private key is not stored local to the user, he may
+    choose to store the private key (normally encrypted using a
+    password-derived key) on the KDC.  We provide this option to present
+    the user with an alternative to storing the private key on local
+    disk at each machine where he expects to authenticate himself using
+    pk-init.  It should be noted that it replaces the added risk of
+    long-term storage of the private key on possibly many workstations
+    with the added risk of storing the private key on the KDC in a
+    form vulnerable to brute-force attack.
+
+    In order to obtain a private key, the client includes a
+    preauthentication field with the AS-REQ message:
+
+    PA-PK-KEY-REQ ::= SEQUENCE {
+                                -- PA TYPE 20
+        patimestamp             [0] KerberosTime OPTIONAL, 
+                                    -- used to address replay attacks.
+        pausec                  [1] INTEGER OPTIONAL,
+                                    -- used to address replay attacks.
+        nonce                   [2] INTEGER,
+                                    -- binds the reply to this request
+        privkeyID               [3] SEQUENCE OF KeyID OPTIONAL
+                                    -- constructed as a hash of
+                                    -- public key corresponding to
+                                    -- desired private key
+    }
+
+    KeyID ::= SEQUENCE {
+        KeyIdentifier           [0] OCTET STRING
+    }
+
+    The client may request a specific private key by sending the
+    corresponding ID.  If this field is left empty, then all
+    private keys are returned.
+
+    If all checks out, the KDC responds as described in the above
+    sections, except that an additional preauthentication field,
+    containing the user's private key, accompanies the reply:
+
+    PA-PK-KEY-REP ::= SEQUENCE {
+                                -- PA TYPE 21
+        nonce                   [0] INTEGER,
+                                    -- binds the reply to the request
+        KeyData                 [1] SEQUENCE OF KeyPair
+    }
+
+    KeyPair ::= SEQUENCE {
+        privKeyID               [0] OCTET STRING,
+                                    -- corresponding to encPrivKey
+        encPrivKey              [1] OCTET STRING
+    }
+
+
+3.4.1.  Additional Protection of Retrieved Private Keys
+
+    We solicit discussion on the following proposal: that the client may
+    optionally include in its request additional data to encrypt the
+    private key, which is currently only protected by the user's
+    password.  One possibility is that the client might generate a
+    random string of bits, encrypt it with the public key of the KDC (as
+    in the SignedKeyPack, but with an ordinary OCTET STRING in place of
+    an EncryptionKey), and include this with the request.  The KDC then
+    XORs each returned key with this random bit string.  (If the bit
+    string is too short, the KDC could either return an error, or XOR
+    the returned key with a repetition of the bit string.)
+
+    In order to make this work, additional means of preauthentication
+    need to be devised in order to prevent attackers from simply
+    inserting their own bit string.  One way to do this is to store
+    a hash of the password-derived key (the one used to encrypt the
+    private key).  This hash is then used in turn to derive a second
+    key (called the hash-key); the hash-key is used to encrypt an ASN.1
+    structure containing the generated bit string and a nonce value
+    that binds it to the request.
+
+    Since the KDC possesses the hash, it can generate the hash-key and
+    verify this (weaker) preauthentication, and yet cannot reproduce
+    the private key itself, since the hash is a one-way function.
+
+
+4.  Logistics and Policy Issues
+
+    We solicit discussion on how clients and KDCs should be configured
+    in order to determine which of the options described above (if any)
+    should be used.  One possibility is to set the user's database
+    record to indicate that authentication is to use public key
+    cryptography; this will not work, however, in the event that the
+    client needs to know before making the initial request.
+
+5.  Compatibility with One-Time Passcodes
+
+    We solicit discussion on how the protocol changes proposed in this
+    draft will interact with the proposed use of one-time passcodes
+    discussed in draft-ietf-cat-kerberos-passwords-00.txt.
+
+
+6.  Strength of Cryptographic Schemes
+
+    In light of recent findings on the strength of MD5 and DES,
+    we solicit discussion on which encryption types to incorporate
+    into the protocol changes.
+
+
+7.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
+    Service (V5).  Request for Comments: 1510
+
+    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+    for Computer Networks, IEEE Communications, 32(9):33-38.
+    September 1994.
+
+    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
+    Transport Layer Security (TLS).
+    draft-ietf-tls-kerb-cipher-suites-00.txt
+
+    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.txt
+
+    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
+    Public Key Cryptography.  Symposium On Network and Distributed System 
+    Security, 1997.
+
+    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic Commerce,
+    July 1995.
+
+    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
+    The SSL Protocol, Version 3.0 - IETF Draft. 
+
+    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
+    Distributed Systems.  In Proceedings of the 13th International 
+    Conference on Distributed Computing Systems, May 1993
+
+    [9] ITU-T (formerly CCITT)
+    Information technology - Open Systems Interconnection -
+    The Directory: Authentication Framework Recommendation X.509
+    ISO/IEC 9594-8
+
+
+8.  Acknowledgements
+
+    Some of the ideas on which this proposal is based arose during
+    discussions over several years between members of the SAAG, the IETF
+    CAT working group, and the PSRG, regarding integration of Kerberos
+    and SPX.  Some ideas have also been drawn from the DASS system.
+    These changes are by no means endorsed by these groups.  This is an
+    attempt to revive some of the goals of those groups, and this
+    proposal approaches those goals primarily from the Kerberos
+    perspective.  Lastly, comments from groups working on similar ideas
+    in DCE have been invaluable.
+
+
+9.  Expiration Date
+
+    This draft expires September 30, 1997.
+
+
+10.  Authors
+
+    Clifford Neuman
+    Brian Tung
+    USC Information Sciences Institute
+    4676 Admiralty Way Suite 1001
+    Marina del Rey CA 90292-6695
+    Phone: +1 310 822 1511
+    E-mail: {bcn, brian}@isi.edu
+
+    John Wray
+    Digital Equipment Corporation
+    550 King Street, LKG2-2/Z7
+    Littleton, MA 01460
+    Phone: +1 508 486 5210
+    E-mail: wray@tuxedo.enet.dec.com
+
+    Ari Medvinsky
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road Suite 310
+    Issaquah WA 98027-5378
+    Phone: +1 206 391 6000
+    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
+
+    Jonathan Trostle
+    Novell
+    E-mail: jonathan.trostle@novell.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt
new file mode 100644
index 00000000000..f26cc722d99
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt
@@ -0,0 +1,868 @@
+INTERNET-DRAFT                                              Brian Tung
+draft-ietf-cat-kerberos-pk-init-04.txt                 Clifford Neuman
+Updates: RFC 1510                                                  ISI
+expires January 31, 1998                                     John Wray
+                                         Digital Equipment Corporation
+                                                         Ari Medvinsky
+                                                           Matthew Hur
+                                                 CyberSafe Corporation
+                                                      Jonathan Trostle
+                                                                Novell
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as "work in
+    progress."
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ds.internic.net (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-04.txt, and expires January 31,
+    1998.  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.
+
+    One of the guiding principles in the design of PKINIT is that
+    changes should be as minimal as possible.  As a result, the basic
+    mechanism of PKINIT is as follows:  The user sends a request to the
+    KDC as before, except that if that user is to use public key
+    cryptography in the initial authentication step, his certificate
+    accompanies the initial request, in the preauthentication fields.
+
+    Upon receipt of this request, the KDC verifies the certificate and
+    issues a ticket granting ticket (TGT) as before, except that instead
+    of being encrypted in the user's long-term key (which is derived
+    from a password), it is encrypted in a randomly-generated key.  This
+    random key is in turn encrypted using the public key from the
+    certificate that came with the request and signed using the KDC's
+    private key, and accompanies the reply, in the preauthentication
+    fields.
+
+    PKINIT also allows for users with only digital signature keys to
+    authenticate using those keys, and for users to store and retrieve
+    private keys on the KDC.
+
+    The PKINIT specification may also be used for direct peer to peer
+    authentication without contacting a central KDC. This application
+    of PKINIT is described in PKTAPP [4] and is based on concepts
+    introduced in [5, 6]. For direct client-to-server authentication,
+    the client uses PKINIT to authenticate to the end server (instead
+    of a central KDC), which then issues a ticket for itself.  This
+    approach has an advantage over SSL [7] in that the server does not
+    need to save state (cache session keys).  Furthermore, an
+    additional benefit is that Kerberos tickets can facilitate
+    delegation (see [8]).
+
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510 for supporting the
+    use of public key cryptography in the initial request for a ticket
+    granting ticket (TGT).
+
+    In summary, the following changes to RFC 1510 are proposed:
+
+        --> Users may authenticate using either a public key pair or a
+            conventional (symmetric) key.  If public key cryptography is
+            used, public key data is transported in preauthentication
+            data fields to help establish identity.
+        --> Users may store private keys on the KDC for retrieval during
+            Kerberos initial authentication.
+
+    This proposal addresses two ways that users may use public key
+    cryptography for initial authentication.  Users may present public
+    key certificates, or they may generate their own session key,
+    signed by their digital signature key.  In either case, the end
+    result is that the user obtains an ordinary TGT that may be used for
+    subsequent authentication, with such authentication using only
+    conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 and 3.3 describe the extensions for the two initial
+    authentication methods.  Section 3.4 describes a way for the user to
+    store and retrieve his private key on the KDC, as an adjunct to the
+    initial authentication.
+
+
+3.1.  Definitions
+
+    The extensions involve new encryption methods; we propose the
+    addition of the following types:
+
+        dsa-sign                                8
+        rsa-priv                                9
+        rsa-pub                                 10
+        rsa-pub-md5                             11
+        rsa-pub-sha1                            12
+
+    The proposal of these encryption types notwithstanding, we do not
+    mandate the use of any particular public key encryption method.
+
+    The extensions involve new preauthentication fields; we propose the
+    addition of the following types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+        PA-PK-AS-SIGN                           16
+        PA-PK-KEY-REQ                           17
+        PA-PK-KEY-REP                           18
+
+    The extensions also involve new error types; we propose the addition
+    of 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
+
+    In many cases, PKINIT requires the encoding of an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-ASN1-BASE64.  The full realm name will appear as follows:
+
+        X500-ASN1-BASE64:Base64Encode(DistinguishedName)
+
+    where Base64 is an ASCII encoding of binary data as per RFC 1521,
+    and DistinguishedName is the ASN.1 encoding of the X.500
+    Distinguished Name from the X.509 certificate.
+
+    Similarly, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to NT-X500-PRINCIPAL, and the name-string shall be set
+    as follows:
+
+        Base64Encode(DistinguishedName)
+
+    as described above.
+
+    [Similar description needed on how realm names and principal names
+    are to be derived from PGP names.]
+
+
+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.
+
+    All additional symmetric keys specified in this draft shall use the
+    same encryption type as the session key in the response from the
+    KDC.  These include the temporary keys used to encrypt the signed
+    random key encrypting the response, as well as the key derived from
+    Diffie-Hellman agreement.  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.
+
+    RFC 1510, Section 6.1, defines EncryptedData as follows:
+
+        EncryptedData ::= SEQUENCE {
+            etype               [0] INTEGER,
+            kvno                [1] INTEGER OPTIONAL,
+            cipher              [2] OCTET STRING
+                                    -- is CipherText
+        }
+
+    RFC 1510 suggests that ciphertext is coded as follows:
+
+        CipherText ::= ENCRYPTED SEQUENCE {
+            confounder          [0] UNTAGGED OCTET STRING(conf_length)
+                                    OPTIONAL,
+            check               [1] UNTAGGED OCTET STRING(checksum_length)
+                                    OPTIONAL,
+            msg-seq             [2] MsgSequence,
+            pad                 [3] UNTAGGED OCTET STRING(pad_length)
+                                    OPTIONAL
+        }
+
+    The PKINIT protocol introduces several new types of encryption.
+    Data that is encrypted with a public key will allow only the check
+    optional field, as it is defined above. This type of the checksum
+    will be specified in the etype field, together with the encryption
+    type.
+
+    In order to identify the checksum type, etype will have the
+    following values:
+
+                rsa-pub-MD5
+                rsa-pub-SHA1
+
+    In the case that etype is set to rsa-pub, the optional 'check'
+    field will not be provided.
+
+    Data that is encrypted with a private key will not use any optional
+    fields. PKINIT uses private key encryption only for signatures,
+    which are encrypted checksums. Therefore, the optional check field
+    is not needed.
+
+
+3.2.  Standard Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedAuthPack
+        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the user's certificate chain
+        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
+                                    -- CAs that the client trusts
+    }
+
+    SignedAuthPack ::= SEQUENCE {
+        authPack                [0] AuthPack,
+        authPackSig             [1] Signature,
+                                    -- of authPack
+                                    -- using user's private key
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        nonce                   [4] INTEGER
+    }
+
+    Signature ::= SEQUENCE {
+        signedHash              [0] EncryptedData
+                                    -- of type Checksum
+    }
+
+    Checksum ::= SEQUENCE {
+        cksumtype               [0] INTEGER,
+        checksum                [1] OCTET STRING
+    }   -- as specified by RFC 1510
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm               [0] AlgorithmIdentifier,
+        subjectPublicKey        [1] BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [9]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm               [0] ALGORITHM.&id,
+                                    -- for DH, equals
+                                    -- dhKeyAgreement
+                                    -- ({iso(1) member-body(2) US(840)
+                                    -- rsadsi(113549) pkcs(1) pkcs-3(3)
+                                    -- 1})
+        parameters              [1] ALGORITHM.&type
+                                    -- for DH, is DHParameter 
+    }   -- as specified by the X.509 recommendation [9]
+
+    DHParameter ::= SEQUENCE {
+        prime                   [0] INTEGER,
+                                    -- p
+        base                    [1] INTEGER,
+                                    -- g
+        privateValueLength      [2] INTEGER OPTIONAL
+    }
+
+    Certificate ::= SEQUENCE {
+        certType                [0] INTEGER,
+                                    -- type of certificate
+                                    -- 1 = X.509v3 (DER encoding)
+                                    -- 2 = PGP (per PGP specification)
+        certData                [1] OCTET STRING
+                                    -- actual certificate
+                                    -- type determined by certType
+    }
+
+    The PKAuthenticator carries information to foil replay attacks,
+    to bind the request and response, and to optionally pass the
+    client's Diffie-Hellman public value (i.e. for using DSA in
+    combination with Diffie-Hellman).  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    In the PKAuthenticator, the client may specify the KDC name in one
+    of two ways:
+
+        * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
+          where <realm_name> is replaced by the applicable realm name.
+        * The name in the KDC's certificate (e.g., an X.500 name, or a
+          PGP name).
+
+    Note that the first case requires that the certificate name and the
+    Kerberos principal name be bound together (e.g., via an X.509v3
+    extension).
+
+    The userCert field is a sequence of certificates, the first of which
+    must be the user's public key certificate. Any subsequent
+    certificates will be certificates of the certifiers of the user's
+    certificate.  These cerificates may be used by the KDC to verify the
+    user's public key.  This field may be left empty if the KDC already
+    has the user's certificate.
+
+    The trustedCertifiers field contains a list of certification
+    authorities trusted by the client, in the case that the client does
+    not possess the KDC's public key certificate.
+
+    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
+    type, the KDC attempts to verify the user's certificate chain
+    (userCert), if one is provided in the request.  This is done by
+    verifying the certification path against the KDC's policy of
+    legitimate certifiers.  This may be based on a certification
+    hierarchy, or it may be simply a list of recognized certifiers in a
+    system like PGP.
+
+    If verification of the user's certificate fails, the KDC sends back
+    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
+    field contains additional information pertaining to this error, and
+    is formatted as follows:
+
+        METHOD-DATA ::= SEQUENCE {
+            method-type         [0] INTEGER,
+                                    -- 1 = cannot verify public key
+                                    -- 2 = invalid certificate
+                                    -- 3 = revoked certificate
+                                    -- 4 = invalid KDC name
+            method-data         [1] OCTET STRING OPTIONAL
+        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
+
+    The values for the method-type and method-data fields are described
+    in Section 3.2.1.
+
+    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
+    verifies that it has a certificate issued by one of the certifiers
+    trusted by the client.  If it does not have a suitable certificate,
+    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
+    the client. 
+
+    If a trust relationship exists, the KDC then verifies the client's
+    signature on PKAuthenticator.  If that fails, the KDC returns an
+    error message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses
+    the timestamp in the PKAuthenticator to assure that the request is
+    not a replay.   The KDC also verifies that its name is specified in
+    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.  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.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows:  The user's name in the ticket is as represented in the
+    certificate, unless a Kerberos principal name is bound to the name
+    in the certificate (e.g., via an X.509v3 extension).  The user's
+    realm in the ticket shall be the name of the Certification
+    Authority that issued the user's public key certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= SEQUENCE {
+                                -- PA TYPE 15
+        encSignedReplyKeyPack   [0] EncryptedData,
+                                    -- of type SignedReplyKeyPack
+                                    -- using the temporary key
+                                    -- in encTmpKey
+        encTmpKeyPack           [1] EncryptedData,
+                                    -- of type TmpKeyPack
+                                    -- using either the client public
+                                    -- key or the Diffie-Hellman key
+                                    -- specified by SignedDHPublicValue
+        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
+                                    -- if one was passed in the request
+        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the KDC's certificate chain
+    }
+
+    SignedReplyKeyPack ::= SEQUENCE {
+        replyKeyPack            [0] ReplyKeyPack,
+        replyKeyPackSig         [1] Signature,
+                                    -- of replyEncKeyPack
+                                    -- using KDC's private key
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- used to encrypt main reply
+        nonce                   [1] INTEGER
+                                    -- binds response to the request
+                                    -- must be same as the nonce
+                                    -- passed in the PKAuthenticator
+    }
+
+    TmpKeyPack ::= SEQUENCE {
+        tmpKey                  [0] EncryptionKey,
+                                    -- used to encrypt the
+                                    -- SignedReplyKeyPack
+    }
+        
+    SignedKDCPublicValue ::= SEQUENCE {
+        kdcPublicValue          [0] SubjectPublicKeyInfo,
+                                    -- as described above
+        kdcPublicValueSig       [1] Signature
+                                    -- of kdcPublicValue
+                                    -- using KDC's private key
+    }
+
+    The kdcCert field is a sequence of certificates, the first of which
+    must be the KDC's public key certificate.  Any subsequent
+    certificates will be certificates of the certifiers of the KDC's
+    certificate.  The last of these must have as its certifier one of
+    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
+    cerificates may be used by the client to verify the KDC's public
+    key.  This field is empty if the client did not send to the KDC a
+    list of trusted certifiers (the trustedCertifiers field was empty).
+    
+    Since each certifier in the certification path of a user's
+    certificate is essentially a separate realm, the name of each
+    certifier shall be added to the transited field of the ticket.  The
+    format of these realm names 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  For an X.509 certificate,
+    this is done as follows.  The certificate will contain a
+    distinguished X.500 name contains, in addition to other attributes,
+    an extended attribute, called principalName, with the KDC's
+    principal name as its value (as the text string
+    krbtgt/<realm_name>@<realm_name>, where <realm_name> is the realm
+    name of the KDC):
+
+        principalName ATTRIBUTE ::= {
+            WITH SYNTAX PrintableString(SIZE(1..ub-prinicipalName))
+            EQUALITY MATCHING RULE  caseExactMatch
+            ORDERING MATCHING RULE  caseExactOrderingMatch
+            SINGLE VALUE            TRUE
+            ID                      id-at-principalName
+        }
+
+        ub-principalName INTEGER ::= 1024
+
+        id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
+
+        id-at-principalName OBJECT IDENTIFIER ::= {id-at 60}
+
+    where ATTRIBUTE is as defined in X.501, and the matching rules are
+    as defined in X.520.
+
+    [Still need to register principalName.]
+
+    [Still need to discuss what is done for a PGP 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.
+
+
+3.2.1.  Additional Information for Errors
+
+    This section describes the interpretation of the method-type and
+    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
+
+    If method-type=1, the client's public key certificate chain does not
+    contain a certificate that is signed by a certification authority
+    trusted by the KDC.  The format of the method-data field will be an
+    ASN.1 encoding of a list of trusted certifiers, as defined above:
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+
+    If method-type=2, the signature on one of the certificates in the
+    chain cannot be verified.  The format of the method-data field will
+    be an ASN.1 encoding of the integer index of the certificate in
+    question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=3, one of the certificates in the chain has been
+    revoked.  The format of the method-data field will be an ASN.1
+    encoding of the integer index of the certificate in question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=4, the KDC name or realm in the PKAuthenticator does
+    not match the principal name of the KDC.  There is no method-data
+    field in this case.
+
+
+3.3.  Digital Signature
+
+    Implementation of the changes in this section are OPTIONAL for
+    compliance with PKINIT.
+
+    We offer this option with the warning that it requires the client to
+    generate a random key; the client may not be able to guarantee the
+    same level of randomness as the KDC.
+
+    If the user registered, or presents a certificate for, a digital
+    signature key with the KDC instead of an encryption key, then a
+    separate exchange must be used.  The client sends a request for a
+    TGT as usual, except that it (rather than the KDC) generates the
+    random key that will be used to encrypt the KDC response.  This key
+    is sent to the KDC along with the request in a preauthentication
+    field, encrypted with the KDC's public key:
+
+    PA-PK-AS-SIGN ::= SEQUENCE {
+                                -- PA TYPE 16
+        encSignedRandomKeyPack  [0] EncryptedData,
+                                    -- of type SignedRandomKeyPack
+                                    -- using the key in encTmpKeyPack
+        encTmpKeyPack           [1] EncryptedData,
+                                    -- of type TmpKeyPack
+                                    -- using the KDC's public key
+        userCert                [2] SEQUENCE OF Certificate OPTIONAL
+                                    -- the user's certificate chain
+    }
+
+    SignedRandomKeyPack ::= SEQUENCE {
+        randomkeyPack           [0] RandomKeyPack,
+        randomkeyPackSig        [1] Signature
+                                    -- of keyPack
+                                    -- using user's private key
+    }
+
+    RandomKeyPack ::= SEQUENCE {
+        randomKey               [0] EncryptionKey,
+                                    -- will be used to encrypt reply
+        randomKeyAuth           [1] PKAuthenticator
+                                    -- nonce copied from AS-REQ
+    }
+
+    If the KDC does not accept client-generated random keys as a matter
+    of policy, then it sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
+    follows.
+
+    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
+    the randomKey.  It then replies as per RFC 1510, except that the
+    reply is encrypted not with a password-derived user key, but with
+    the randomKey sent in the request.  Since the client already knows
+    this key, there is no need to accompany the reply with an extra
+    preauthentication field.  The transited field of the ticket should
+    specify the certification path as described in Section 3.2.
+
+
+3.4.  Retrieving the User's Private Key from the KDC
+
+    Implementation of the changes described in this section are OPTIONAL
+    for compliance with PKINIT.
+
+    When the user's private key is not stored local to the user, he may
+    choose to store the private key (normally encrypted using a
+    password-derived key) on the KDC.  In this case, the client makes a
+    request as described above, except that instead of preauthenticating
+    with his private key, he uses a symmetric key shared with the KDC.
+
+    For simplicity's sake, this shared key is derived from the password-
+    derived key used to encrypt the private key, in such a way that the
+    KDC can authenticate the user with the shared key without being able
+    to extract the private key.
+
+    We provide this option to present the user with an alternative to
+    storing the private key on local disk at each machine where he
+    expects to authenticate himself using PKINIT.  It should be noted
+    that it replaces the added risk of long-term storage of the private
+    key on possibly many workstations with the added risk of storing the
+    private key on the KDC in a form vulnerable to brute-force attack.
+
+    Denote by K1 the symmetric key used to encrypt the private key.
+    Then construct symmetric key K2 as follows:
+
+        * Perform a hash on K1.
+        * Truncate the digest to Length(K1) bytes.
+        * Rectify parity in each byte (if necessary) to obtain K2.
+
+    The KDC stores K2, the public key, and the encrypted private key.
+    This key pair is designated as the "primary" key pair for that user.
+    This primary key pair is the one used to perform initial
+    authentication using the PA-PK-AS-REP preauthentication field.  If
+    he desires, he may also store additional key pairs on the KDC; these
+    may be requested in addition to the primary.  When the client
+    requests initial authentication using public key cryptography, it
+    must then include in its request, instead of a PA-PK-AS-REQ, the
+    following preauthentication sequence:
+
+    PA-PK-KEY-REQ ::= SEQUENCE {
+                                -- PA TYPE 17
+        signedPKAuth            [0] SignedPKAuth,
+        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
+                                    -- payload is hash of public key
+                                    -- corresponding to desired
+                                    -- private key
+                                    -- if absent, KDC will return all
+                                    -- stored private keys
+    }
+
+    SignedPKAuth ::= SEQUENCE {
+        pkAuth                  [0] PKAuthenticator,
+        pkAuthSig               [1] Signature
+                                    -- of pkAuth
+                                    -- using the symmetric key K2
+    }
+
+    If a keyIDList is present, the first identifier should indicate
+    the primary private key.  No public key certificate is required,
+    since the KDC stores the public key along with the private key.
+    If there is no keyIDList, all the user's private keys are returned.
+
+    Upon receipt, the KDC verifies the signature using K2.  If the
+    verification fails, the KDC sends back an error of type
+    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
+    keys are not found on the KDC, then the KDC sends back an error of
+    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
+    described in Section 3.2, except that in addition, the KDC appends
+    the following preauthentication sequence:
+
+    PA-PK-KEY-REP ::= SEQUENCE {
+                                -- PA TYPE 18
+        encKeyRep               [0] EncryptedData
+                                    -- of type EncKeyReply
+                                    -- using the symmetric key K2
+    }
+
+    EncKeyReply ::= SEQUENCE {
+        keyPackList             [0] SEQUENCE OF KeyPack,
+                                    -- the first KeyPair is
+                                    -- the primary key pair
+        nonce                   [1] INTEGER
+                                    -- binds reply to request
+                                    -- must be identical to the nonce
+                                    -- sent in the SignedAuthPack
+    }
+
+    KeyPack ::= SEQUENCE {
+        keyID                   [0] Checksum,
+        encPrivKey              [1] OCTET STRING
+    }
+
+    Upon receipt of the reply, the client extracts the encrypted private
+    keys (and may store them, at the client's option).  The primary
+    private key, which must be the first private key in the keyPack
+    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
+    this key in turn is used to decrypt the main reply as described in
+    Section 3.2.
+
+
+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
+    that use either the Standard Public Key Authentication or Public Key
+    Authentication with a Digital Signature.  However, if these users
+    are registered with the KDC, it is recommended that the database
+    record for these users be modified to include three additional flags
+    in the attributes field.
+
+    The first flag, use_standard_pk_init, indicates that the user should
+    authenticate using standard PKINIT as described in Section 3.2.  The
+    second flag, use_digital_signature, indicates that the user should
+    authenticate using digital signature PKINIT as described in Section
+    3.3.  The third flag, store_private_key, indicates that the user
+    has stored his private key on the KDC and should retrieve it using
+    the exchange described in Section 3.4.
+
+    If one of the preauthentication fields defined above is included in
+    the request, then the KDC shall respond as described in Sections 3.2
+    through 3.4, ignoring the aforementioned database flags.  If more
+    than one of the preauthentication fields is present, the KDC shall
+    respond with an error of type KDC_ERR_PREAUTH_FAILED.
+
+    In the event that none of the preauthentication fields defined above
+    are included in the request, the KDC checks to see if any of the
+    above flags are set.  If the first flag is set, then it sends back
+    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
+    preauthentication field of type PA-PK-AS-REQ must be included in the
+    request.
+
+    Otherwise, if the first flag is clear, but the second flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-AS-SIGN must
+    be included in the request.
+
+    Lastly, if the first two flags are clear, but the third flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-KEY-REQ must
+    be included in the request.
+
+
+5.  Dependence on Transport Mechanisms
+
+    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
+    allow TCP as a transport mechanism, we solicit discussion on whether
+    using PKINIT should encourage the use of TCP.
+
+
+6.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+    (V5).  Request for Comments 1510.
+
+    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+    for Computer Networks, IEEE Communications, 32(9):33-38.  September
+    1994.
+
+    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
+    Transport Layer Security (TLS).
+    draft-ietf-tls-kerb-cipher-suites-00.txt
+
+    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.txt
+
+    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
+    Protocol, Version 3.0 - IETF Draft. 
+
+    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
+    Distributed Systems.  In Proceedings of the 13th International 
+    Conference on Distributed Computing Systems, May 1993.
+
+    [9] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+
+7.  Acknowledgements
+
+    Sasha Medvinsky contributed several ideas to the protocol changes
+    and specifications in this document.  His additions have been most
+    appreciated.
+
+    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.
+
+
+8.  Expiration Date
+
+    This draft expires January 31, 1997.
+
+
+9.  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
+
+    John Wray
+    Digital Equipment Corporation
+    550 King Street, LKG2-2/Z7
+    Littleton, MA 01460
+    Phone: +1 508 486 5210
+    E-mail: wray@tuxedo.enet.dec.com
+
+    Ari Medvinsky
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road Suite 310
+    Issaquah WA 98027-5378
+    Phone: +1 206 391 6000
+    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
+
+    Jonathan Trostle
+    Novell Corporation
+    Provo UT
+    E-mail: jtrostle@novell.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt
new file mode 100644
index 00000000000..068edc2c0f4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt
@@ -0,0 +1,916 @@
+INTERNET-DRAFT                                              Brian Tung
+draft-ietf-cat-kerberos-pk-init-05.txt                 Clifford Neuman
+Updates: RFC 1510                                                  ISI
+expires May 26, 1998                                         John Wray
+                                         Digital Equipment Corporation
+                                                         Ari Medvinsky
+                                                           Matthew Hur
+                                                 CyberSafe Corporation
+                                                      Jonathan Trostle
+                                                                Novell
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as "work in
+    progress."
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ds.internic.net (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998.
+    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.
+
+    One of the guiding principles in the design of PKINIT is that
+    changes should be as minimal as possible.  As a result, the basic
+    mechanism of PKINIT is as follows:  The user sends a request to the
+    KDC as before, except that if that user is to use public key
+    cryptography in the initial authentication step, his certificate
+    accompanies the initial request, in the preauthentication fields.
+
+    Upon receipt of this request, the KDC verifies the certificate and
+    issues a ticket granting ticket (TGT) as before, except that
+    the encPart from the AS-REP message carrying the TGT is now
+    encrypted in a randomly-generated key, instead of the user's
+    long-term key (which is derived from a password).  This
+    random key is in turn encrypted using the public key from the
+    certificate that came with the request and signed using the KDC's
+    private key, and accompanies the reply, in the preauthentication
+    fields.
+
+    PKINIT also allows for users with only digital signature keys to
+    authenticate using those keys, and for users to store and retrieve
+    private keys on the KDC.
+
+    The PKINIT specification may also be used for direct peer to peer
+    authentication without contacting a central KDC. This application
+    of PKINIT is described in PKTAPP [4] and is based on concepts
+    introduced in [5, 6]. For direct client-to-server authentication,
+    the client uses PKINIT to authenticate to the end server (instead
+    of a central KDC), which then issues a ticket for itself.  This
+    approach has an advantage over SSL [7] in that the server does not
+    need to save state (cache session keys).  Furthermore, an
+    additional benefit is that Kerberos tickets can facilitate
+    delegation (see [8]).
+
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510 for supporting the
+    use of public key cryptography in the initial request for a ticket
+    granting ticket (TGT).
+
+    In summary, the following changes to RFC 1510 are proposed:
+
+        * Users may authenticate using either a public key pair or a
+          conventional (symmetric) key.  If public key cryptography is
+          used, public key data is transported in preauthentication
+          data fields to help establish identity.
+        * Users may store private keys on the KDC for retrieval during
+          Kerberos initial authentication.
+
+    This proposal addresses two ways that users may use public key
+    cryptography for initial authentication.  Users may present public
+    key certificates, or they may generate their own session key,
+    signed by their digital signature key.  In either case, the end
+    result is that the user obtains an ordinary TGT that may be used for
+    subsequent authentication, with such authentication using only
+    conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 and 3.3 describe the extensions for the two initial
+    authentication methods.  Section 3.4 describes a way for the user to
+    store and retrieve his private key on the KDC, as an adjunct to the
+    initial authentication.
+
+
+3.1.  Definitions
+
+    The extensions involve new encryption methods; we propose the
+    addition of the following types:
+
+        dsa-sign                                8
+        rsa-priv                                9
+        rsa-pub                                 10
+        rsa-pub-md5                             11
+        rsa-pub-sha1                            12
+
+    The proposal of these encryption types notwithstanding, we do not
+    mandate the use of any particular public key encryption method.
+
+    The extensions involve new preauthentication fields; we propose the
+    addition of the following types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+        PA-PK-AS-SIGN                           16
+        PA-PK-KEY-REQ                           17
+        PA-PK-KEY-REP                           18
+
+    The extensions also involve new error types; we propose the addition
+    of 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
+
+    In many cases, PKINIT requires the encoding of an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC1779.  The full realm name will appear as follows:
+
+        X500-RFC1779:RFC1779Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC1779Encode is a
+    readable ASCII encoding of an X.500 name, as defined by RFC 1779.
+    To ensure that this encoding is unique, we add the following rules
+    to those specified by RFC 1779:
+
+        * The optional spaces specified in RFC 1779 are not allowed.
+        * The character that separates relative distinguished names
+          must be ',' (i.e., it must never be ';').
+        * Attribute values must not be enclosed in double quotes.
+        * Attribute values must not be specified as hexadecimal
+          numbers.
+        * When an attribute name is specified in the form of an OID,
+          it must start with the 'OID.' prefix, and not the 'oid.'
+          prefix.
+        * The order in which the attributes appear in the RFC 1779
+          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, because RFC 1779 requires that the least
+          significant relative distinguished name appear first.  The
+          order of the relative distinguished names, as well as the
+          order of the attributes within each relative distinguished
+          name, will be reversed.
+
+    Similarly, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to NT-X500-PRINCIPAL.  This new name type is defined
+    as:
+        #define CSFC5c_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC1779Encode(DistinguishedName)
+
+    as described above.
+
+
+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.
+
+    All additional symmetric keys specified in this draft shall use the
+    same encryption type as the session key in the response from the
+    KDC.  These include the temporary keys used to encrypt the signed
+    random key encrypting the response, as well as the key derived from
+    Diffie-Hellman agreement.  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.
+
+    RFC 1510, Section 6.1, defines EncryptedData as follows:
+
+        EncryptedData ::= SEQUENCE {
+            etype               [0] INTEGER,
+            kvno                [1] INTEGER OPTIONAL,
+            cipher              [2] OCTET STRING
+                                    -- is CipherText
+        }
+
+    RFC 1510 also defines how CipherText is to be composed.  It is not
+    an ASN.1 data structure, but rather an octet string which is the
+    encryption of a plaintext string.  This plaintext string is in turn
+    a concatenation of the following octet strings: a confounder, a
+    checksum, the message, and padding.  Details of how these components
+    are arranged can be found in RFC 1510.
+
+    The PKINIT protocol introduces several new types of encryption.
+    Data that is encrypted with a public key will allow only the check
+    optional field, as it is defined above. This type of the checksum
+    will be specified in the etype field, together with the encryption
+    type.
+
+    In order to identify the checksum type, etype will have the
+    following values:
+
+                rsa-pub-MD5
+                rsa-pub-SHA1
+
+    In the case that etype is set to rsa-pub, the optional 'check'
+    field will not be provided.
+
+    Data that is encrypted with a private key will not use any optional
+    fields. PKINIT uses private key encryption only for signatures,
+    which are encrypted checksums. Therefore, the optional check field
+    is not needed.
+
+
+3.2.  Standard Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedAuthPack
+        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the user's certificate chain
+        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        serialNumber            [3] CertificateSerialNumber OPTIONAL
+                                    -- specifying a particular
+                                    -- certificate if the client
+                                    -- already has it;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+    }
+
+    CertificateSerialNumber ::= INTEGER
+                                -- as specified by PKCS 6
+
+    SignedAuthPack ::= SEQUENCE {
+        authPack                [0] AuthPack,
+        authPackSig             [1] Signature,
+                                    -- of authPack
+                                    -- using user's private key
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        nonce                   [4] INTEGER
+    }
+
+    Signature ::= SEQUENCE {
+        signedHash              [0] EncryptedData
+                                    -- of type Checksum
+    }
+
+    Checksum ::= SEQUENCE {
+        cksumtype               [0] INTEGER,
+        checksum                [1] OCTET STRING
+    }   -- as specified by RFC 1510
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm               [0] AlgorithmIdentifier,
+        subjectPublicKey        [1] BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [9]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm               [0] ALGORITHM.&id,
+                                    -- for DH, equals
+                                    -- dhKeyAgreement
+                                    -- ({iso(1) member-body(2) US(840)
+                                    -- rsadsi(113549) pkcs(1) pkcs-3(3)
+                                    -- 1})
+        parameters              [1] ALGORITHM.&type
+                                    -- for DH, is DHParameter 
+    }   -- as specified by the X.509 recommendation [9]
+
+    DHParameter ::= SEQUENCE {
+        prime                   [0] INTEGER,
+                                    -- p
+        base                    [1] INTEGER,
+                                    -- g
+        privateValueLength      [2] INTEGER OPTIONAL
+    }
+
+    Certificate ::= SEQUENCE {
+        certType                [0] INTEGER,
+                                    -- type of certificate
+                                    -- 1 = X.509v3 (DER encoding)
+                                    -- 2 = PGP (per PGP specification)
+        certData                [1] OCTET STRING
+                                    -- actual certificate
+                                    -- type determined by certType
+    }
+
+    If the client passes a certificate 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 PKAuthenticator carries information to foil replay attacks,
+    to bind the request and response, and to optionally pass the
+    client's Diffie-Hellman public value (i.e. for using DSA in
+    combination with Diffie-Hellman).  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    In the PKAuthenticator, the client may specify the KDC name in one
+    of two ways:
+
+        * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
+          where <realm_name> is replaced by the applicable realm name.
+        * The name in the KDC's certificate (e.g., an X.500 name, or a
+          PGP name).
+
+    Note that the first case requires that the certificate name and the
+    Kerberos principal name be bound together (e.g., via an X.509v3
+    extension).
+
+    The userCert field is a sequence of certificates, the first of which
+    must be the user's public key certificate. Any subsequent
+    certificates will be certificates of the certifiers of the user's
+    certificate.  These cerificates may be used by the KDC to verify the
+    user's public key.  This field may be left empty if the KDC already
+    has the user's certificate.
+
+    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_CERTIFICATE_MISMATCH.
+
+    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 verification of the user's certificate fails, the KDC sends back
+    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
+    field contains additional information pertaining to this error, and
+    is formatted as follows:
+
+        METHOD-DATA ::= SEQUENCE {
+            method-type         [0] INTEGER,
+                                    -- 1 = cannot verify public key
+                                    -- 2 = invalid certificate
+                                    -- 3 = revoked certificate
+                                    -- 4 = invalid KDC name
+                                    -- 5 = client name mismatch
+            method-data         [1] OCTET STRING OPTIONAL
+        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
+
+    The values for the method-type and method-data fields are described
+    in Section 3.2.1.
+
+    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
+    verifies that it has a certificate issued by one of the certifiers
+    trusted by the client.  If it does not have a suitable certificate,
+    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
+    the client. 
+
+    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 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.  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.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows:  The user's name in the ticket is as represented in the
+    certificate, unless a Kerberos principal name is bound to the name
+    in the certificate (e.g., via an X.509v3 extension).  The user's
+    realm in the ticket shall be the name of the Certification
+    Authority that issued the user's public key certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= SEQUENCE {
+                                -- PA TYPE 15
+        encSignedReplyKeyPack   [0] EncryptedData,
+                                    -- of type SignedReplyKeyPack
+                                    -- using the temporary key
+                                    -- in encTmpKey
+        encTmpKeyPack           [1] EncryptedData,
+                                    -- of type TmpKeyPack
+                                    -- using either the client public
+                                    -- key or the Diffie-Hellman key
+                                    -- specified by SignedDHPublicValue
+        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
+                                    -- if one was passed in the request
+        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the KDC's certificate chain
+    }
+
+    SignedReplyKeyPack ::= SEQUENCE {
+        replyKeyPack            [0] ReplyKeyPack,
+        replyKeyPackSig         [1] Signature,
+                                    -- of replyEncKeyPack
+                                    -- using KDC's private key
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- used to encrypt main reply
+                                    -- of same ENCTYPE as session key
+        nonce                   [1] INTEGER
+                                    -- binds response to the request
+                                    -- must be same as the nonce
+                                    -- passed in the PKAuthenticator
+    }
+
+    TmpKeyPack ::= SEQUENCE {
+        tmpKey                  [0] EncryptionKey,
+                                    -- used to encrypt the
+                                    -- SignedReplyKeyPack
+                                    -- of same ENCTYPE as session key
+    }
+        
+    SignedKDCPublicValue ::= SEQUENCE {
+        kdcPublicValue          [0] SubjectPublicKeyInfo,
+                                    -- as described above
+        kdcPublicValueSig       [1] Signature
+                                    -- of kdcPublicValue
+                                    -- using KDC's private key
+    }
+
+    The kdcCert field is a sequence of certificates, the first of which
+    must be the KDC's public key certificate.  Any subsequent
+    certificates will be certificates of the certifiers of the KDC's
+    certificate.  The last of these must have as its certifier one of
+    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
+    cerificates may be used by the client to verify the KDC's public
+    key.  This field is empty if the client did not send to the KDC a
+    list of trusted certifiers (the trustedCertifiers field was empty).
+    
+    Since each certifier in the certification path of a user's
+    certificate is essentially a separate realm, the name of each
+    certifier shall be added to the transited field of the ticket.  The
+    format of these realm names 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  For an X.509 certificate,
+    this is done as follows.  The name of the KDC will be represented
+    as an OtherName, encoded as a GeneralString:
+
+        GeneralName ::= CHOICE {
+            otherName       [0] KDCPrincipalName,
+            ...
+        }
+
+        KDCPrincipalNameTypes OTHER-NAME ::= {
+            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
+        }
+
+        KDCPrincipalName ::= SEQUENCE {
+            nameType        OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
+            name            OTHER-NAME.&type ( { KDCPrincipalNameTypes }
+                               { @nameType } )
+        }
+
+        PrincipalNameSrvInst ::= GeneralString
+
+    where (from the Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        principalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
+
+    The client then extracts the random key used to encrypt the main
+    reply.  This random key (in encPaReply) is encrypted with either the
+    client's public key or with a key derived from the DH values
+    exchanged between the client and the KDC.
+
+
+3.2.1.  Additional Information for Errors
+
+    This section describes the interpretation of the method-type and
+    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
+
+    If method-type=1, the client's public key certificate chain does not
+    contain a certificate that is signed by a certification authority
+    trusted by the KDC.  The format of the method-data field will be an
+    ASN.1 encoding of a list of trusted certifiers, as defined above:
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+
+    If method-type=2, the signature on one of the certificates in the
+    chain cannot be verified.  The format of the method-data field will
+    be an ASN.1 encoding of the integer index of the certificate in
+    question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=3, one of the certificates in the chain has been
+    revoked.  The format of the method-data field will be an ASN.1
+    encoding of the integer index of the certificate in question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=4, the KDC name or realm in the PKAuthenticator does
+    not match the principal name of the KDC.  There is no method-data
+    field in this case.
+
+    If method-type=5, the client name or realm in the certificate does
+    not match the principal name of the client.  There is no
+    method-data field in this case.
+
+
+3.3.  Digital Signature
+
+    Implementation of the changes in this section are OPTIONAL for
+    compliance with PKINIT.
+
+    We offer this option with the warning that it requires the client to
+    generate a random key; the client may not be able to guarantee the
+    same level of randomness as the KDC.
+
+    If the user registered, or presents a certificate for, a digital
+    signature key with the KDC instead of an encryption key, then a
+    separate exchange must be used.  The client sends a request for a
+    TGT as usual, except that it (rather than the KDC) generates the
+    random key that will be used to encrypt the KDC response.  This key
+    is sent to the KDC along with the request in a preauthentication
+    field, encrypted with the KDC's public key:
+
+    PA-PK-AS-SIGN ::= SEQUENCE {
+                                -- PA TYPE 16
+        encSignedRandomKeyPack  [0] EncryptedData,
+                                    -- of type SignedRandomKeyPack
+                                    -- using the key in encTmpKeyPack
+        encTmpKeyPack           [1] EncryptedData,
+                                    -- of type TmpKeyPack
+                                    -- using the KDC's public key
+        userCert                [2] SEQUENCE OF Certificate OPTIONAL
+                                    -- the user's certificate chain
+    }
+
+    SignedRandomKeyPack ::= SEQUENCE {
+        randomkeyPack           [0] RandomKeyPack,
+        randomkeyPackSig        [1] Signature
+                                    -- of keyPack
+                                    -- using user's private key
+    }
+
+    RandomKeyPack ::= SEQUENCE {
+        randomKey               [0] EncryptionKey,
+                                    -- will be used to encrypt reply
+        randomKeyAuth           [1] PKAuthenticator
+                                    -- nonce copied from AS-REQ
+    }
+
+    If the KDC does not accept client-generated random keys as a matter
+    of policy, then it sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
+    follows.
+
+    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
+    the randomKey.  It then replies as per RFC 1510, except that the
+    reply is encrypted not with a password-derived user key, but with
+    the randomKey sent in the request.  Since the client already knows
+    this key, there is no need to accompany the reply with an extra
+    preauthentication field.  The transited field of the ticket should
+    specify the certification path as described in Section 3.2.
+
+
+3.4.  Retrieving the User's Private Key from the KDC
+
+    Implementation of the changes described in this section are OPTIONAL
+    for compliance with PKINIT.
+
+    When the user's private key is not stored local to the user, he may
+    choose to store the private key (normally encrypted using a
+    password-derived key) on the KDC.  In this case, the client makes a
+    request as described above, except that instead of preauthenticating
+    with his private key, he uses a symmetric key shared with the KDC.
+
+    For simplicity's sake, this shared key is derived from the password-
+    derived key used to encrypt the private key, in such a way that the
+    KDC can authenticate the user with the shared key without being able
+    to extract the private key.
+
+    We provide this option to present the user with an alternative to
+    storing the private key on local disk at each machine where he
+    expects to authenticate himself using PKINIT.  It should be noted
+    that it replaces the added risk of long-term storage of the private
+    key on possibly many workstations with the added risk of storing the
+    private key on the KDC in a form vulnerable to brute-force attack.
+
+    Denote by K1 the symmetric key used to encrypt the private key.
+    Then construct symmetric key K2 as follows:
+
+        * Perform a hash on K1.
+        * Truncate the digest to Length(K1) bytes.
+        * Rectify parity in each byte (if necessary) to obtain K2.
+
+    The KDC stores K2, the public key, and the encrypted private key.
+    This key pair is designated as the "primary" key pair for that user.
+    This primary key pair is the one used to perform initial
+    authentication using the PA-PK-AS-REP preauthentication field.  If
+    he desires, he may also store additional key pairs on the KDC; these
+    may be requested in addition to the primary.  When the client
+    requests initial authentication using public key cryptography, it
+    must then include in its request, instead of a PA-PK-AS-REQ, the
+    following preauthentication sequence:
+
+    PA-PK-KEY-REQ ::= SEQUENCE {
+                                -- PA TYPE 17
+        signedPKAuth            [0] SignedPKAuth,
+        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
+                                    -- payload is hash of public key
+                                    -- corresponding to desired
+                                    -- private key
+                                    -- if absent, KDC will return all
+                                    -- stored private keys
+    }
+
+    SignedPKAuth ::= SEQUENCE {
+        pkAuth                  [0] PKAuthenticator,
+        pkAuthSig               [1] Signature
+                                    -- of pkAuth
+                                    -- using the symmetric key K2
+    }
+
+    If a keyIDList is present, the first identifier should indicate
+    the primary private key.  No public key certificate is required,
+    since the KDC stores the public key along with the private key.
+    If there is no keyIDList, all the user's private keys are returned.
+
+    Upon receipt, the KDC verifies the signature using K2.  If the
+    verification fails, the KDC sends back an error of type
+    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
+    keys are not found on the KDC, then the KDC sends back an error of
+    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
+    described in Section 3.2, except that in addition, the KDC appends
+    the following preauthentication sequence:
+
+    PA-PK-KEY-REP ::= SEQUENCE {
+                                -- PA TYPE 18
+        encKeyRep               [0] EncryptedData
+                                    -- of type EncKeyReply
+                                    -- using the symmetric key K2
+    }
+
+    EncKeyReply ::= SEQUENCE {
+        keyPackList             [0] SEQUENCE OF KeyPack,
+                                    -- the first KeyPair is
+                                    -- the primary key pair
+        nonce                   [1] INTEGER
+                                    -- binds reply to request
+                                    -- must be identical to the nonce
+                                    -- sent in the SignedAuthPack
+    }
+
+    KeyPack ::= SEQUENCE {
+        keyID                   [0] Checksum,
+        encPrivKey              [1] OCTET STRING
+    }
+
+    Upon receipt of the reply, the client extracts the encrypted private
+    keys (and may store them, at the client's option).  The primary
+    private key, which must be the first private key in the keyPack
+    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
+    this key in turn is used to decrypt the main reply as described in
+    Section 3.2.
+
+
+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
+    that use either the Standard Public Key Authentication or Public Key
+    Authentication with a Digital Signature.  However, if these users
+    are registered with the KDC, it is recommended that the database
+    record for these users be modified to include three additional flags
+    in the attributes field.
+
+    The first flag, use_standard_pk_init, indicates that the user should
+    authenticate using standard PKINIT as described in Section 3.2.  The
+    second flag, use_digital_signature, indicates that the user should
+    authenticate using digital signature PKINIT as described in Section
+    3.3.  The third flag, store_private_key, indicates that the user
+    has stored his private key on the KDC and should retrieve it using
+    the exchange described in Section 3.4.
+
+    If one of the preauthentication fields defined above is included in
+    the request, then the KDC shall respond as described in Sections 3.2
+    through 3.4, ignoring the aforementioned database flags.  If more
+    than one of the preauthentication fields is present, the KDC shall
+    respond with an error of type KDC_ERR_PREAUTH_FAILED.
+
+    In the event that none of the preauthentication fields defined above
+    are included in the request, the KDC checks to see if any of the
+    above flags are set.  If the first flag is set, then it sends back
+    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
+    preauthentication field of type PA-PK-AS-REQ must be included in the
+    request.
+
+    Otherwise, if the first flag is clear, but the second flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-AS-SIGN must
+    be included in the request.
+
+    Lastly, if the first two flags are clear, but the third flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-KEY-REQ must
+    be included in the request.
+
+
+5.  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.
+
+
+6.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+    (V5).  Request for Comments 1510.
+
+    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+    for Computer Networks, IEEE Communications, 32(9):33-38.  September
+    1994.
+
+    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
+    Transport Layer Security (TLS).
+    draft-ietf-tls-kerb-cipher-suites-00.txt
+
+    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.txt
+
+    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
+    Protocol, Version 3.0 - IETF Draft. 
+
+    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
+    Distributed Systems.  In Proceedings of the 13th International 
+    Conference on Distributed Computing Systems, May 1993.
+
+    [9] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+
+7.  Acknowledgements
+
+    Sasha Medvinsky contributed several ideas to the protocol changes
+    and specifications in this document.  His additions have been most
+    appreciated.
+
+    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.
+
+
+8.  Expiration Date
+
+    This draft expires May 26, 1998.
+
+
+9.  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
+
+    John Wray
+    Digital Equipment Corporation
+    550 King Street, LKG2-2/Z7
+    Littleton, MA 01460
+    Phone: +1 508 486 5210
+    E-mail: wray@tuxedo.enet.dec.com
+
+    Ari Medvinsky
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road Suite 310
+    Issaquah WA 98027-5378
+    Phone: +1 206 391 6000
+    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
+
+    Jonathan Trostle
+    Novell Corporation
+    Provo UT
+    E-mail: jtrostle@novell.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt
new file mode 100644
index 00000000000..cb18eb5ca3d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt
@@ -0,0 +1,959 @@
+INTERNET-DRAFT                                              Brian Tung
+draft-ietf-cat-kerberos-pk-init-06.txt                 Clifford Neuman
+Updates: RFC 1510                                                  ISI
+expires September 15, 1998                                   John Wray
+                                         Digital Equipment Corporation
+                                                         Ari Medvinsky
+                                                           Matthew Hur
+                                                 CyberSafe Corporation
+                                                      Jonathan Trostle
+                                                                Novell
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as "work in
+    progress."
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on ds.internic.net (US East Coast),
+    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+    munnari.oz.au (Pacific Rim).
+
+    The distribution of this memo is unlimited.  It is filed as
+    draft-ietf-cat-kerberos-pk-init-05.txt, and expires September 15,
+    1998.  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.
+
+    One of the guiding principles in the design of PKINIT is that
+    changes should be as minimal as possible.  As a result, the basic
+    mechanism of PKINIT is as follows:  The user sends a request to the
+    KDC as before, except that if that user is to use public key
+    cryptography in the initial authentication step, his certificate
+    accompanies the initial request, in the preauthentication fields.
+
+    Upon receipt of this request, the KDC verifies the certificate and
+    issues a ticket granting ticket (TGT) as before, except that
+    the encPart from the AS-REP message carrying the TGT is now
+    encrypted in a randomly-generated key, instead of the user's
+    long-term key (which is derived from a password).  This
+    random key is in turn encrypted using the public key from the
+    certificate that came with the request and signed using the KDC's
+    private key, and accompanies the reply, in the preauthentication
+    fields.
+
+    PKINIT also allows for users with only digital signature keys to
+    authenticate using those keys, and for users to store and retrieve
+    private keys on the KDC.
+
+    The PKINIT specification may also be used for direct peer to peer
+    authentication without contacting a central KDC. This application
+    of PKINIT is described in PKTAPP [4] and is based on concepts
+    introduced in [5, 6]. For direct client-to-server authentication,
+    the client uses PKINIT to authenticate to the end server (instead
+    of a central KDC), which then issues a ticket for itself.  This
+    approach has an advantage over SSL [7] in that the server does not
+    need to save state (cache session keys).  Furthermore, an
+    additional benefit is that Kerberos tickets can facilitate
+    delegation (see [8]).
+
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510 for supporting the
+    use of public key cryptography in the initial request for a ticket
+    granting ticket (TGT).
+
+    In summary, the following changes to RFC 1510 are proposed:
+
+        * Users may authenticate using either a public key pair or a
+          conventional (symmetric) key.  If public key cryptography is
+          used, public key data is transported in preauthentication
+          data fields to help establish identity.
+        * Users may store private keys on the KDC for retrieval during
+          Kerberos initial authentication.
+
+    This proposal addresses two ways that users may use public key
+    cryptography for initial authentication.  Users may present public
+    key certificates, or they may generate their own session key,
+    signed by their digital signature key.  In either case, the end
+    result is that the user obtains an ordinary TGT that may be used for
+    subsequent authentication, with such authentication using only
+    conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 and 3.3 describe the extensions for the two initial
+    authentication methods.  Section 3.4 describes a way for the user to
+    store and retrieve his private key on the KDC, as an adjunct to the
+    initial authentication.
+
+
+3.1.  Definitions
+
+    The extensions involve new encryption methods; we propose the
+    addition of the following types:
+
+        dsa-sign                                8
+        rsa-priv                                9
+        rsa-pub                                 10
+        rsa-pub-md5                             11
+        rsa-pub-sha1                            12
+
+    The proposal of these encryption types notwithstanding, we do not
+    mandate the use of any particular public key encryption method.
+
+    The extensions involve new preauthentication fields; we propose the
+    addition of the following types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+        PA-PK-AS-SIGN                           16
+        PA-PK-KEY-REQ                           17
+        PA-PK-KEY-REP                           18
+
+    The extensions also involve new error types; we propose the addition
+    of 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
+
+    In addition, PKINIT does not define, but does permit, the following
+    algorithm identifiers for use with the Signature data structure:
+
+        md4WithRSAEncryption (as defined in PKCS 1)
+        md5WithRSAEncryption (as defined in PKCS 1)
+        sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840)
+                                     rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
+        dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2)
+                          dsaWithSHA1(27) }
+
+    where
+
+        OIW ::= iso(1) identifiedOrganization(3) oIW(14)
+
+    In many cases, PKINIT requires the encoding of an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC1779.  The full realm name will appear as follows:
+
+        X500-RFC1779:RFC1779Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC1779Encode is a
+    readable ASCII encoding of an X.500 name, as defined by RFC 1779.
+    To ensure that this encoding is unique, we add the following rules
+    to those specified by RFC 1779:
+
+        * The optional spaces specified in RFC 1779 are not allowed.
+        * The character that separates relative distinguished names
+          must be ',' (i.e., it must never be ';').
+        * Attribute values must not be enclosed in double quotes.
+        * Attribute values must not be specified as hexadecimal
+          numbers.
+        * When an attribute name is specified in the form of an OID,
+          it must start with the 'OID.' prefix, and not the 'oid.'
+          prefix.
+        * The order in which the attributes appear in the RFC 1779
+          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, because RFC 1779 requires that the least
+          significant relative distinguished name appear first.  The
+          order of the relative distinguished names, as well as the
+          order of the attributes within each relative distinguished
+          name, will be reversed.
+
+    Similarly, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to NT-X500-PRINCIPAL.  This new name type is defined
+    as:
+
+        #define CSFC5c_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC1779Encode(DistinguishedName)
+
+    as described above.
+
+
+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.
+
+    All additional symmetric keys specified in this draft shall use the
+    same encryption type as the session key in the response from the
+    KDC.  These include the temporary keys used to encrypt the signed
+    random key encrypting the response, as well as the key derived from
+    Diffie-Hellman agreement.  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.
+
+    RFC 1510, Section 6.1, defines EncryptedData as follows:
+
+        EncryptedData ::= SEQUENCE {
+            etype               [0] INTEGER,
+            kvno                [1] INTEGER OPTIONAL,
+            cipher              [2] OCTET STRING
+                                    -- is CipherText
+        }
+
+    RFC 1510 also defines how CipherText is to be composed.  It is not
+    an ASN.1 data structure, but rather an octet string which is the
+    encryption of a plaintext string.  This plaintext string is in turn
+    a concatenation of the following octet strings: a confounder, a
+    checksum, the message, and padding.  Details of how these components
+    are arranged can be found in RFC 1510.
+
+    The PKINIT protocol introduces several new types of encryption.
+    Data that is encrypted with a public key will allow only the check
+    optional field, as it is defined above. This type of the checksum
+    will be specified in the etype field, together with the encryption
+    type.
+
+    In order to identify the checksum type, etype will have the
+    following values:
+
+                rsa-pub-MD5
+                rsa-pub-SHA1
+
+    In the case that etype is set to rsa-pub, the optional 'check'
+    field will not be provided.
+
+    Data that is encrypted with a private key will not use any optional
+    fields. PKINIT uses private key encryption only for signatures,
+    which are encrypted checksums. Therefore, the optional check field
+    is not needed.
+
+
+3.2.  Standard Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedAuthPack
+        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the user's certificate chain
+        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        serialNumber            [3] CertificateSerialNumber OPTIONAL
+                                    -- specifying a particular
+                                    -- certificate if the client
+                                    -- already has it;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+    }
+
+    CertificateSerialNumber ::= INTEGER
+                                -- as specified by PKCS 6
+
+    SignedAuthPack ::= SEQUENCE {
+        authPack                [0] AuthPack,
+        authPackSig             [1] Signature,
+                                    -- of authPack
+                                    -- using user's private key
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        nonce                   [4] INTEGER
+    }
+
+    Signature ::= SEQUENCE {
+        signatureAlgorithm      [0] SignatureAlgorithmIdentifier,
+        pkcsSignature           [1] BIT STRING
+                                    -- octet-aligned big-endian bit
+                                    -- string (encrypted with signer's
+                                    -- private key)
+    }
+
+    SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   ALGORITHM.&id,
+                                    -- for DH, equals
+                                    -- dhKeyAgreement
+                                    -- ({iso(1) member-body(2) US(840)
+                                    -- rsadsi(113549) pkcs(1) pkcs-3(3)
+                                    -- 1})
+        parameters                  ALGORITHM.&type
+                                    -- for DH, is DHParameter 
+    }   -- as specified by the X.509 recommendation [9]
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm                   AlgorithmIdentifier,
+        subjectPublicKey            BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [9]
+
+    DHParameter ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+    }   -- as specified by the X.509 recommendation [9]
+
+    Certificate ::= SEQUENCE {
+        certType                [0] INTEGER,
+                                    -- type of certificate
+                                    -- 1 = X.509v3 (DER encoding)
+                                    -- 2 = PGP (per PGP specification)
+        certData                [1] OCTET STRING
+                                    -- actual certificate
+                                    -- type determined by certType
+    }
+
+    If the client passes a certificate 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 PKAuthenticator carries information to foil replay attacks,
+    to bind the request and response, and to optionally pass the
+    client's Diffie-Hellman public value (i.e. for using DSA in
+    combination with Diffie-Hellman).  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    In the PKAuthenticator, the client may specify the KDC name in one
+    of two ways:
+
+        * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
+          where <realm_name> is replaced by the applicable realm name.
+        * The name in the KDC's certificate (e.g., an X.500 name, or a
+          PGP name).
+
+    Note that the first case requires that the certificate name and the
+    Kerberos principal name be bound together (e.g., via an X.509v3
+    extension).
+
+    The userCert field is a sequence of certificates, the first of which
+    must be the user's public key certificate. Any subsequent
+    certificates will be certificates of the certifiers of the user's
+    certificate.  These cerificates may be used by the KDC to verify the
+    user's public key.  This field may be left empty if the KDC already
+    has the user's certificate.
+
+    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_CERTIFICATE_MISMATCH.
+
+    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 verification of the user's certificate fails, the KDC sends back
+    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
+    field contains additional information pertaining to this error, and
+    is formatted as follows:
+
+        METHOD-DATA ::= SEQUENCE {
+            method-type         [0] INTEGER,
+                                    -- 1 = cannot verify public key
+                                    -- 2 = invalid certificate
+                                    -- 3 = revoked certificate
+                                    -- 4 = invalid KDC name
+                                    -- 5 = client name mismatch
+            method-data         [1] OCTET STRING OPTIONAL
+        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
+
+    The values for the method-type and method-data fields are described
+    in Section 3.2.1.
+
+    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
+    verifies that it has a certificate issued by one of the certifiers
+    trusted by the client.  If it does not have a suitable certificate,
+    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
+    the client. 
+
+    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 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.  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.
+
+    Assuming no errors, the KDC replies as per RFC 1510, except as
+    follows:  The user's name in the ticket is as represented in the
+    certificate, unless a Kerberos principal name is bound to the name
+    in the certificate (e.g., via an X.509v3 extension).  The user's
+    realm in the ticket shall be the name of the Certification
+    Authority that issued the user's public key certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= SEQUENCE {
+                                -- PA TYPE 15
+        encSignedReplyKeyPack   [0] EncryptedData,
+                                    -- of type SignedReplyKeyPack
+                                    -- using the temporary key
+                                    -- in encTmpKey
+        encTmpKeyPack           [1] EncryptedData,
+                                    -- of type TmpKeyPack
+                                    -- using either the client public
+                                    -- key or the Diffie-Hellman key
+                                    -- specified by SignedDHPublicValue
+        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
+                                    -- if one was passed in the request
+        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the KDC's certificate chain
+    }
+
+    SignedReplyKeyPack ::= SEQUENCE {
+        replyKeyPack            [0] ReplyKeyPack,
+        replyKeyPackSig         [1] Signature,
+                                    -- of replyEncKeyPack
+                                    -- using KDC's private key
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- used to encrypt main reply
+                                    -- of same ENCTYPE as session key
+        nonce                   [1] INTEGER
+                                    -- binds response to the request
+                                    -- must be same as the nonce
+                                    -- passed in the PKAuthenticator
+    }
+
+    TmpKeyPack ::= SEQUENCE {
+        tmpKey                  [0] EncryptionKey,
+                                    -- used to encrypt the
+                                    -- SignedReplyKeyPack
+                                    -- of same ENCTYPE as session key
+    }
+        
+    SignedKDCPublicValue ::= SEQUENCE {
+        kdcPublicValue          [0] SubjectPublicKeyInfo,
+                                    -- as described above
+        kdcPublicValueSig       [1] Signature
+                                    -- of kdcPublicValue
+                                    -- using KDC's private key
+    }
+
+    The kdcCert field is a sequence of certificates, the first of which
+    must be the KDC's public key certificate.  Any subsequent
+    certificates will be certificates of the certifiers of the KDC's
+    certificate.  The last of these must have as its certifier one of
+    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
+    cerificates may be used by the client to verify the KDC's public
+    key.  This field is empty if the client did not send to the KDC a
+    list of trusted certifiers (the trustedCertifiers field was empty).
+    
+    Since each certifier in the certification path of a user's
+    certificate is essentially a separate realm, the name of each
+    certifier shall be added to the transited field of the ticket.  The
+    format of these realm names 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  For an X.509 certificate,
+    this is done as follows.  The name of the KDC will be represented
+    as an OtherName, encoded as a GeneralString:
+
+        GeneralName ::= CHOICE {
+            otherName       [0] KDCPrincipalName,
+            ...
+        }
+
+        KDCPrincipalNameTypes OTHER-NAME ::= {
+            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
+        }
+
+        KDCPrincipalName ::= SEQUENCE {
+            nameType        [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
+            name            [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes }
+                               { @nameType } )
+        }
+
+        PrincipalNameSrvInst ::= GeneralString
+
+    where (from the Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        principalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
+
+    The client then extracts the random key used to encrypt the main
+    reply.  This random key (in encPaReply) is encrypted with either the
+    client's public key or with a key derived from the DH values
+    exchanged between the client and the KDC.
+
+
+3.2.1.  Additional Information for Errors
+
+    This section describes the interpretation of the method-type and
+    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
+
+    If method-type=1, the client's public key certificate chain does not
+    contain a certificate that is signed by a certification authority
+    trusted by the KDC.  The format of the method-data field will be an
+    ASN.1 encoding of a list of trusted certifiers, as defined above:
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+
+    If method-type=2, the signature on one of the certificates in the
+    chain cannot be verified.  The format of the method-data field will
+    be an ASN.1 encoding of the integer index of the certificate in
+    question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=3, one of the certificates in the chain has been
+    revoked.  The format of the method-data field will be an ASN.1
+    encoding of the integer index of the certificate in question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=4, the KDC name or realm in the PKAuthenticator does
+    not match the principal name of the KDC.  There is no method-data
+    field in this case.
+
+    If method-type=5, the client name or realm in the certificate does
+    not match the principal name of the client.  There is no
+    method-data field in this case.
+
+
+3.3.  Digital Signature
+
+    Implementation of the changes in this section are OPTIONAL for
+    compliance with PKINIT.
+
+    We offer this option with the warning that it requires the client to
+    generate a random key; the client may not be able to guarantee the
+    same level of randomness as the KDC.
+
+    If the user registered, or presents a certificate for, a digital
+    signature key with the KDC instead of an encryption key, then a
+    separate exchange must be used.  The client sends a request for a
+    TGT as usual, except that it (rather than the KDC) generates the
+    random key that will be used to encrypt the KDC response.  This key
+    is sent to the KDC along with the request in a preauthentication
+    field, encrypted with the KDC's public key:
+
+    PA-PK-AS-SIGN ::= SEQUENCE {
+                                -- PA TYPE 16
+        encSignedRandomKeyPack  [0] EncryptedData,
+                                    -- of type SignedRandomKeyPack
+                                    -- using the key in encTmpKeyPack
+        encTmpKeyPack           [1] EncryptedData,
+                                    -- of type TmpKeyPack
+                                    -- using the KDC's public key
+        userCert                [2] SEQUENCE OF Certificate OPTIONAL
+                                    -- the user's certificate chain
+    }
+
+    SignedRandomKeyPack ::= SEQUENCE {
+        randomkeyPack           [0] RandomKeyPack,
+        randomkeyPackSig        [1] Signature
+                                    -- of keyPack
+                                    -- using user's private key
+    }
+
+    RandomKeyPack ::= SEQUENCE {
+        randomKey               [0] EncryptionKey,
+                                    -- will be used to encrypt reply
+        randomKeyAuth           [1] PKAuthenticator
+                                    -- nonce copied from AS-REQ
+    }
+
+    If the KDC does not accept client-generated random keys as a matter
+    of policy, then it sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
+    follows.
+
+    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
+    the randomKey.  It then replies as per RFC 1510, except that the
+    reply is encrypted not with a password-derived user key, but with
+    the randomKey sent in the request.  Since the client already knows
+    this key, there is no need to accompany the reply with an extra
+    preauthentication field.  The transited field of the ticket should
+    specify the certification path as described in Section 3.2.
+
+
+3.4.  Retrieving the User's Private Key from the KDC
+
+    Implementation of the changes described in this section are OPTIONAL
+    for compliance with PKINIT.
+
+    When the user's private key is not stored local to the user, he may
+    choose to store the private key (normally encrypted using a
+    password-derived key) on the KDC.  In this case, the client makes a
+    request as described above, except that instead of preauthenticating
+    with his private key, he uses a symmetric key shared with the KDC.
+
+    For simplicity's sake, this shared key is derived from the password-
+    derived key used to encrypt the private key, in such a way that the
+    KDC can authenticate the user with the shared key without being able
+    to extract the private key.
+
+    We provide this option to present the user with an alternative to
+    storing the private key on local disk at each machine where he
+    expects to authenticate himself using PKINIT.  It should be noted
+    that it replaces the added risk of long-term storage of the private
+    key on possibly many workstations with the added risk of storing the
+    private key on the KDC in a form vulnerable to brute-force attack.
+
+    Denote by K1 the symmetric key used to encrypt the private key.
+    Then construct symmetric key K2 as follows:
+
+        * Perform a hash on K1.
+        * Truncate the digest to Length(K1) bytes.
+        * Rectify parity in each byte (if necessary) to obtain K2.
+
+    The KDC stores K2, the public key, and the encrypted private key.
+    This key pair is designated as the "primary" key pair for that user.
+    This primary key pair is the one used to perform initial
+    authentication using the PA-PK-AS-REP preauthentication field.  If
+    he desires, he may also store additional key pairs on the KDC; these
+    may be requested in addition to the primary.  When the client
+    requests initial authentication using public key cryptography, it
+    must then include in its request, instead of a PA-PK-AS-REQ, the
+    following preauthentication sequence:
+
+    PA-PK-KEY-REQ ::= SEQUENCE {
+                                -- PA TYPE 17
+        signedPKAuth            [0] SignedPKAuth,
+        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
+                                    -- payload is hash of public key
+                                    -- corresponding to desired
+                                    -- private key
+                                    -- if absent, KDC will return all
+                                    -- stored private keys
+    }
+
+    Checksum ::= SEQUENCE {
+        cksumtype               [0] INTEGER,
+        checksum                [1] OCTET STRING
+    }   -- as specified by RFC 1510
+
+    SignedPKAuth ::= SEQUENCE {
+        pkAuth                  [0] PKAuthenticator,
+        pkAuthSig               [1] Signature
+                                    -- of pkAuth
+                                    -- using the symmetric key K2
+    }
+
+    If a keyIDList is present, the first identifier should indicate
+    the primary private key.  No public key certificate is required,
+    since the KDC stores the public key along with the private key.
+    If there is no keyIDList, all the user's private keys are returned.
+
+    Upon receipt, the KDC verifies the signature using K2.  If the
+    verification fails, the KDC sends back an error of type
+    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
+    keys are not found on the KDC, then the KDC sends back an error of
+    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
+    described in Section 3.2, except that in addition, the KDC appends
+    the following preauthentication sequence:
+
+    PA-PK-KEY-REP ::= SEQUENCE {
+                                -- PA TYPE 18
+        encKeyRep               [0] EncryptedData
+                                    -- of type EncKeyReply
+                                    -- using the symmetric key K2
+    }
+
+    EncKeyReply ::= SEQUENCE {
+        keyPackList             [0] SEQUENCE OF KeyPack,
+                                    -- the first KeyPair is
+                                    -- the primary key pair
+        nonce                   [1] INTEGER
+                                    -- binds reply to request
+                                    -- must be identical to the nonce
+                                    -- sent in the SignedAuthPack
+    }
+
+    KeyPack ::= SEQUENCE {
+        keyID                   [0] Checksum,
+        encPrivKey              [1] OCTET STRING
+    }
+
+    Upon receipt of the reply, the client extracts the encrypted private
+    keys (and may store them, at the client's option).  The primary
+    private key, which must be the first private key in the keyPack
+    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
+    this key in turn is used to decrypt the main reply as described in
+    Section 3.2.
+
+
+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
+    that use either the Standard Public Key Authentication or Public Key
+    Authentication with a Digital Signature.  However, if these users
+    are registered with the KDC, it is recommended that the database
+    record for these users be modified to include three additional flags
+    in the attributes field.
+
+    The first flag, use_standard_pk_init, indicates that the user should
+    authenticate using standard PKINIT as described in Section 3.2.  The
+    second flag, use_digital_signature, indicates that the user should
+    authenticate using digital signature PKINIT as described in Section
+    3.3.  The third flag, store_private_key, indicates that the user
+    has stored his private key on the KDC and should retrieve it using
+    the exchange described in Section 3.4.
+
+    If one of the preauthentication fields defined above is included in
+    the request, then the KDC shall respond as described in Sections 3.2
+    through 3.4, ignoring the aforementioned database flags.  If more
+    than one of the preauthentication fields is present, the KDC shall
+    respond with an error of type KDC_ERR_PREAUTH_FAILED.
+
+    In the event that none of the preauthentication fields defined above
+    are included in the request, the KDC checks to see if any of the
+    above flags are set.  If the first flag is set, then it sends back
+    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
+    preauthentication field of type PA-PK-AS-REQ must be included in the
+    request.
+
+    Otherwise, if the first flag is clear, but the second flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-AS-SIGN must
+    be included in the request.
+
+    Lastly, if the first two flags are clear, but the third flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-KEY-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 order
+    to simplify key management, 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.
+
+
+5.  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.
+
+
+6.  Bibliography
+
+    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
+    (V5).  Request for Comments 1510.
+
+    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+    for Computer Networks, IEEE Communications, 32(9):33-38.  September
+    1994.
+
+    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
+    Transport Layer Security (TLS).
+    draft-ietf-tls-kerb-cipher-suites-00.txt
+
+    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.txt
+
+    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
+    Protocol, Version 3.0 - IETF Draft. 
+
+    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
+    Distributed Systems.  In Proceedings of the 13th International 
+    Conference on Distributed Computing Systems, May 1993.
+
+    [9] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+
+7.  Acknowledgements
+
+    Sasha Medvinsky contributed several ideas to the protocol changes
+    and specifications in this document.  His additions have been most
+    appreciated.
+
+    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.
+
+
+8.  Expiration Date
+
+    This draft expires September 15, 1998.
+
+
+9.  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
+
+    John Wray
+    Digital Equipment Corporation
+    550 King Street, LKG2-2/Z7
+    Littleton, MA 01460
+    Phone: +1 508 486 5210
+    E-mail: wray@tuxedo.enet.dec.com
+
+    Ari Medvinsky
+    Matthew Hur
+    CyberSafe Corporation
+    1605 NW Sammamish Road Suite 310
+    Issaquah WA 98027-5378
+    Phone: +1 206 391 6000
+    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
+
+    Jonathan Trostle
+    Novell Corporation
+    Provo UT
+    E-mail: jtrostle@novell.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt
new file mode 100644
index 00000000000..9609440b9bb
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt
@@ -0,0 +1,1181 @@
+INTERNET-DRAFT                                              Brian Tung
+draft-ietf-cat-kerberos-pk-init-07.txt                 Clifford Neuman
+Updates: RFC 1510                                                  ISI
+expires May 15, 1999                                         John Wray
+                                         Digital Equipment Corporation
+                                                         Ari Medvinsky
+                                                           Matthew Hur
+                                                       Sasha Medvinsky
+                                                 CyberSafe Corporation
+                                                      Jonathan Trostle
+                                                                 Cisco
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of This Memo
+
+    This document is an Internet-Draft.  Internet-Drafts are working
+    documents of the Internet Engineering Task Force (IETF), its
+    areas, and its working groups.  Note that other groups may also
+    distribute working documents as Internet-Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six
+    months and may be updated, replaced, or obsoleted by other
+    documents at any time.  It is inappropriate to use Internet-Drafts
+    as reference material or to cite them other than as "work in
+    progress."
+
+    To learn the current status of any Internet-Draft, please check
+    the "1id-abstracts.txt" listing contained in the Internet-Drafts
+    Shadow Directories on 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-07.txt, and expires May 15, 1999.
+    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.
+
+    One of the guiding principles in the design of PKINIT is that
+    changes should be as minimal as possible.  As a result, the basic
+    mechanism of PKINIT is as follows:  The user sends a request to the
+    KDC as before, except that if that user is to use public key
+    cryptography in the initial authentication step, his certificate
+    accompanies the initial request, in the preauthentication fields.
+
+    Upon receipt of this request, the KDC verifies the certificate and
+    issues a ticket granting ticket (TGT) as before, except that
+    the encPart from the AS-REP message carrying the TGT is now
+    encrypted in a randomly-generated key, instead of the user's
+    long-term key (which is derived from a password).  This
+    random key is in turn encrypted using the public key from the
+    certificate that came with the request and signed using the KDC's
+    private key, and accompanies the reply, in the preauthentication
+    fields.
+
+    PKINIT also allows for users with only digital signature keys to
+    authenticate using those keys, and for users to store and retrieve
+    private keys on the KDC.
+
+    The PKINIT specification may also be used 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 SSL [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 changes to RFC 1510 are proposed:
+
+        * Users may authenticate using either a public key pair or a
+          conventional (symmetric) key.  If public key cryptography is
+          used, public key data is transported in preauthentication
+          data fields to help establish identity.
+        * Users may store private keys on the KDC for retrieval during
+          Kerberos initial authentication.
+
+    This proposal addresses two ways that users may use public key
+    cryptography for initial authentication.  Users may present public
+    key certificates, or they may generate their own session key,
+    signed by their digital signature key.  In either case, the end
+    result is that the user obtains an ordinary TGT that may be used for
+    subsequent authentication, with such authentication using only
+    conventional cryptography.
+
+    Section 3.1 provides definitions to help specify message formats.
+    Section 3.2 and 3.3 describe the extensions for the two initial
+    authentication methods.  Section 3.4 describes a way for the user to
+    store and retrieve his private key on the KDC, as an adjunct to the
+    initial authentication.
+
+
+3.1.  Definitions
+
+    The extensions involve new preauthentication fields; we propose the
+    addition of the following types:
+
+        PA-PK-AS-REQ                            14
+        PA-PK-AS-REP                            15
+        PA-PK-AS-SIGN                           16
+        PA-PK-KEY-REQ                           17
+        PA-PK-KEY-REP                           18
+
+    The extensions also involve new error types; we propose the addition
+    of 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
+
+    In many cases, PKINIT requires the encoding of an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        X500-RFC2253:RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    readable ASCII encoding of an X.500 name, as defined by
+    RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which
+    is not supported by this version of PKINIT.)
+
+    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, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to NT-X500-PRINCIPAL.  This new name type is defined
+    as:
+
+        #define CSFC5c_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.
+
+
+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.
+
+    All additional symmetric keys specified in this draft shall use the
+    same encryption type as the session key in the response from the
+    KDC.  These include the temporary keys used to encrypt the signed
+    random key encrypting the response, as well as the key derived from
+    Diffie-Hellman agreement.  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
+
+    These are the algorithm identifiers for use in the Signature data
+    structure:
+  
+    sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-1(1) 5 }
+    
+    dsaWithSHA1 ALGORITHM PARAMETER NULL
+         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
+               oIWSecAlgorithm(2) dsaWithSHA1(27) }
+    
+    md4WithRsaEncryption ALGORITHM PARAMETER NULL
+         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
+               oIWSecAlgorithm(2) md4WithRSAEncryption(4) }
+    
+    md5WithRSAEncryption ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-1(1) md5WithRSAEncryption(4) }
+
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+    This algorithm identifier is used inside the SubjectPublicKeyInfo
+    data structure:
+
+    dhKeyAgreement ALGORITHM PARAMETER DHParameters
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-3(3) dhKeyAgreement(1) }
+
+    DHParameters ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+    }   -- as specified by the X.509 recommendation [9]
+
+
+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 ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-1(1) rsaEncryption(1)
+
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure, for encrypting the temporary key with a Diffie-Hellman-
+    derived key, or for encrypting the reply key:
+
+    desCBC ALGORITHM PARAMETER IV8
+         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
+               oIWSecAlgorithm(2) desCBC(7) }
+
+    DES-EDE3-CBC ALGORITHM PARAMETER IV8
+         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
+               encryptionAlgorithm(3) desEDE3(7) }
+
+    IV8 ::= OCTET STRING (SIZE(8))        -- initialization vector
+
+    rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
+         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
+               encryptionAlgorithm(3) rc2CBC(2) }
+
+    The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
+    in the following section.
+
+    rc4 ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
+               encryptionAlgorithm(3) rc4(4) }
+
+    The rc4 algorithm cannot be used with the Diffie-Hellman-derived
+    keys, because its parameters do not specify the size of the key.
+
+
+3.1.2.5. rc2CBC Algorithm Parameters
+
+    This definition of the RC2 parameters is taken from a paper by
+    Ron Rivest [13]. Refer to [13] for the complete description of the
+    RC2 algorithm.
+
+    RC2-CBCParameter ::= CHOICE {
+        iv IV,
+        params SEQUENCE {
+            version RC2Version,
+            iv IV
+        }
+    }
+
+    where
+
+    IV ::= OCTET STRING -- 8 octets
+    RC2Version ::= INTEGER -- 1-1024
+
+    RC2 in CBC mode has two parameters: an 8-byte initialization 
+    vector (IV) and a version number in the range 1-1024 which 
+    specifies in a roundabout manner the number of effective key bits 
+    to be used for the RC2 encryption/decryption.
+
+    The correspondence between effective key bits and version number 
+    is as follows:
+
+    1. If the number EKB of effective key bits is in the range 1-255, 
+       then the version number is given by Table[EKB], where the 
+       256-byte translation table is specified below. It specifies a
+       permutation on the numbers 0-255.
+
+    2. If the number EKB of effective key bits is in the range 
+       256-1024, then the version number is simply EKB.
+
+       The default number of effective key bits for RC2 is 32.  
+       If RC2-CBC is being performed with 32 effective key bits, the 
+       parameters should be supplied as a simple IV, rather than as a
+       SEQUENCE containing a version and an IV.
+
+         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
+
+    00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0
+    10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a
+    20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36
+    30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
+    40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
+    50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
+    60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
+    70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
+    80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
+    90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
+    a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
+    b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
+    c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
+    d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
+    e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
+    f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
+
+    
+3.2.  Standard Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's private key accompanies the request:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                -- PA TYPE 14
+        signedAuthPack          [0] SignedAuthPack
+        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
+                                    -- the user's certificate chain;
+				    -- if present, the KDC must use
+				    -- the public key from this
+				    -- particular certificate chain to
+				    -- verify the signature in the
+				    -- request
+        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        serialNumber            [3] CertificateSerialNumber OPTIONAL
+                                    -- specifying a particular KDC
+                                    -- certificate if the client
+                                    -- already has it;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+    }
+
+    CertificateSerialNumber ::= INTEGER
+                                -- as specified by PKCS #6 [15]
+
+    SignedAuthPack ::= SEQUENCE {
+        authPack                [0] AuthPack,
+        authPackSig             [1] Signature,
+                                    -- of authPack
+                                    -- using user's private key
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        nonce                   [4] INTEGER
+    }
+
+    Signature ::= SEQUENCE {
+        signatureAlgorithm      [0] SignatureAlgorithmIdentifier,
+        pkcsSignature           [1] BIT STRING
+                                    -- octet-aligned big-endian bit
+                                    -- string (encrypted with signer's
+                                    -- private key)
+    }
+
+    SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   ALGORITHM.&id,
+        parameters                  ALGORITHM.&type 
+    }   -- as specified by the X.509 recommendation [10]
+
+    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 [9]
+
+    Certificate ::= SEQUENCE {
+        certType                [0] INTEGER,
+                                    -- type of certificate
+                                    -- 1 = X.509v3 (DER encoding)
+                                    -- 2 = PGP (per PGP specification)
+                                    -- 3 = PKIX (per PKCS #6 [15])
+        certData                [1] OCTET STRING
+                                    -- actual certificate
+                                    -- type determined by certType
+    }
+
+    If the client passes a certificate 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 PKAuthenticator carries information to foil replay attacks,
+    to bind the request and response, and to optionally pass the
+    client's Diffie-Hellman public value (i.e. for using DSA in
+    combination with Diffie-Hellman).  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    The userCert field is a sequence of certificates, the first of which
+    must be the user's public key certificate. Any subsequent
+    certificates will be certificates of the certifiers of the user's
+    certificate.  These cerificates may be used by the KDC to verify the
+    user's public key.  This field may be left empty if the KDC already
+    has the user's certificate.
+
+    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_CERTIFICATE_MISMATCH.
+
+    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 verification of the user's certificate fails, the KDC sends back
+    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
+    field contains additional information pertaining to this error, and
+    is formatted as follows:
+
+        METHOD-DATA ::= SEQUENCE {
+            method-type         [0] INTEGER,
+                                    -- 1 = cannot verify public key
+                                    -- 2 = invalid certificate
+                                    -- 3 = revoked certificate
+                                    -- 4 = invalid KDC name
+                                    -- 5 = client name mismatch
+            method-data         [1] OCTET STRING OPTIONAL
+        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
+
+    The values for the method-type and method-data fields are described
+    in Section 3.2.1.
+
+    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
+    verifies that it has a certificate issued by one of the certifiers
+    trusted by the client.  If it does not have a suitable certificate,
+    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
+    the client. 
+
+    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 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.  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.
+
+    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 a Kerberos name in an extension
+            field, and local KDC policy allows, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, 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
+            certification authority that issued the user's certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= SEQUENCE {
+                                -- PA TYPE 15
+        encKeyPack		[1] EnvelopedKeyPack,
+                                    -- temporary key is encrypted
+                                    -- using either the client public
+                                    -- key or the Diffie-Hellman key
+                                    -- specified by SignedKDCPublicValue.
+				    -- SignedReplyKeyPack, encrypted
+				    -- with the temporary key, is also
+				    -- included.
+        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL,
+                                    -- if one was passed in the request
+        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL
+                                    -- the KDC's certificate chain
+    }
+  
+        
+    The EnvelopedKeyPack data type below contains an encrypted
+    temporary key (either with the PKINIT client's public key or with a
+    symmetric key, resulting from the Diffie-Hellman exchange). It also
+    contains a signed and encrypted reply key. This data structure is
+    similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12].
+    
+    EnvelopedKeyPack ::= SEQUENCE {
+        version                     Version,
+                                    -- Always set to 0.
+        recipientInfos              RecipientInfos,
+                                    -- This is a SET, which must contain
+                                    -- exactly one member. Contains a
+                                    -- temporary key, encrypted with the
+                                    -- client's public key. This
+				    -- temporary key is used to encrypt
+				    -- the reply key.
+        encryptedContentInfo        EncryptedContentInfo
+                                    -- contains the signed and encrypted
+				    -- reply key
+    }
+
+    Version ::= INTEGER
+
+    RecipientInfos ::= SET OF RecipientInfo
+
+    RecipientInfo ::= SEQUENCE {
+        version                     Version,
+                                    -- shall be 0
+        rid                         RecipientIdentifier,
+                                    -- Since this is an optional field, 
+				    -- it supports both CMS and PKCS #7
+        keyEncryptionAlgorithm      KeyEncryptionAlgorithmIdentifier,
+        EncryptedKey                OCTET STRING
+                                    -- the temporary key, encrypted with
+                                    -- the PKINIT client's public key        
+    }
+
+    KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
+
+    RecipientIdentifier ::= IssuerAndSerialNumber
+                            -- Corresponds to the X.509 V3 extension
+                            -- SubjectKeyIdentifier.
+
+    IssuerAndSerialNumber ::= SEQUENCE {
+	issuer			Name,
+				    -- a distinguished name, as defined
+				    -- by X.509
+	serialNumber		CertificateSerialNumber
+    }
+
+    CertificateSerialNumber ::= INTEGER
+	
+    EncryptedContentInfo ::= SEQUENCE {
+	contentType		ContentType,
+				    -- shall be:
+				    -- 	iso(1) member-body(2) us(840)
+				    --  rsadsi(113549) pkcs(1) pkcs7(7)
+				    --  EnvelopedData(3)
+	contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier
+				    -- Algorithm used to encrypt the
+				    -- SignedReplyKeyPack.
+        encryptedContent           OCTET STRING
+				    -- The encrypted data is of the type
+				    -- SignedReplyKeyPack.
+    }
+
+    ContentType ::= OBJECT IDENTIFIER
+
+    ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
+
+    SignedReplyKeyPack ::= SEQUENCE {
+        replyKeyPack            [0] ReplyKeyPack,
+        replyKeyPackSig         [1] Signature,
+                                    -- of replyKeyPack
+                                    -- using KDC's private key
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- used to encrypt main reply
+                                    -- of same ENCTYPE as session key
+        nonce                   [1] INTEGER
+                                    -- binds response to the request
+                                    -- must be same as the nonce
+                                    -- passed in the PKAuthenticator
+    }
+       
+    SignedKDCPublicValue ::= SEQUENCE {
+        kdcPublicValue          [0] SubjectPublicKeyInfo,
+                                    -- as described above
+        kdcPublicValueSig       [1] Signature
+                                    -- of kdcPublicValue
+                                    -- using KDC's private key
+    }
+
+
+    The kdcCert field is a sequence of certificates, the first of which
+    must be the KDC's public key certificate.  Any subsequent
+    certificates will be certificates of the certifiers of the KDC's
+    certificate.  The last of these must have as its certifier one of
+    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
+    cerificates may be used by the client to verify the KDC's public
+    key.  This field is empty if the client did not send to the KDC a
+    list of trusted certifiers (the trustedCertifiers field was empty).
+    
+    Since each certifier in the certification path of a user's
+    certificate is essentially a separate realm, the name of each
+    certifier shall be added to the transited field of the ticket.  The
+    format of these realm names 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  X.509 certificates shall
+    contain the principal name of the KDC 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] INSTANCE OF OTHER-NAME,
+	    ...
+	}
+
+	OTHER-NAME ::= TYPE-IDENTIFIER
+
+    In this definition, otherName is a name of any form defined as an
+    instance of the OTHER-NAME information object class. For the purpose
+    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
+    be replaced by the type KerberosPrincipalName:
+
+	KerberosPrincipalName ::= SEQUENCE {
+            nameType        [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
+            name            [1] OTHER-NAME.&type ( { PrincipalNameTypes }
+                               { @nameType } )
+        }
+
+        PrincipalNameTypes OTHER-NAME ::= {
+            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
+        }  
+
+        PrincipalNameSrvInst ::= GeneralString
+
+    where (from the Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        principalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
+
+    (This specification can also be used to specify a Kerberos name
+    within the user'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.
+
+
+3.2.1.  Additional Information for Errors
+
+    This section describes the interpretation of the method-type and
+    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
+
+    If method-type=1, the client's public key certificate chain does not
+    contain a certificate that is signed by a certification authority
+    trusted by the KDC.  The format of the method-data field will be an
+    ASN.1 encoding of a list of trusted certifiers, as defined above:
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+
+    If method-type=2, the signature on one of the certificates in the
+    chain cannot be verified.  The format of the method-data field will
+    be an ASN.1 encoding of the integer index of the certificate in
+    question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=3, one of the certificates in the chain has been
+    revoked.  The format of the method-data field will be an ASN.1
+    encoding of the integer index of the certificate in question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=4, the KDC name or realm in the PKAuthenticator does
+    not match the principal name of the KDC.  There is no method-data
+    field in this case.
+
+    If method-type=5, the client name or realm in the certificate does
+    not match the principal name of the client.  There is no
+    method-data field in this case.
+
+
+3.2.2. Required Algorithms and Data Formats
+
+    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 and data formats:
+
+	- Diffie-Hellman public/private key pairs
+	- SHA1 digest and DSA for signatures
+	- X.509 version 3 certificates
+	- 3-key triple DES keys derived from the Diffie-Hellman Exchange
+	- 3-key triple DES Temporary and Reply keys
+
+	
+3.3.  Digital Signature
+
+    Implementation of the changes in this section are OPTIONAL for
+    compliance with PKINIT.
+
+    We offer this option with the warning that it requires the client to
+    generate a random key; the client may not be able to guarantee the
+    same level of randomness as the KDC.
+
+    If the user registered, or presents a certificate for, a digital
+    signature key with the KDC instead of an encryption key, then a
+    separate exchange must be used.  The client sends a request for a
+    TGT as usual, except that it (rather than the KDC) generates the
+    random key that will be used to encrypt the KDC response.  This key
+    is sent to the KDC along with the request in a preauthentication
+    field, encrypted with the KDC's public key:
+
+    PA-PK-AS-SIGN ::= SEQUENCE {
+                                -- PA TYPE 16
+        encKeyPack		[1] EnvelopedKeyPack,
+                                    -- temporary key is encrypted
+                                    -- using the KDC public
+                                    -- key.
+				    -- SignedRandomKeyPack, encrypted
+				    -- with the temporary key, is also
+				    -- included.
+        userCert                [2] SEQUENCE OF Certificate OPTIONAL
+                                    -- the user's certificate chain;
+				    -- if present, the KDC must use
+				    -- the public key from this
+				    -- particular certificate chain to
+				    -- verify the signature in the
+				    -- request
+    }
+
+    In the above message, the content of the encKeyPack is similar to
+    the content of the encKeyPack field in the PA-PK-AS-REP message,
+    except that it is the KDC's public key and not the client's public
+    key that is used to encrypt the temporary key. And, the
+    encryptedContentInfo field inside the EnvelopedKeyPack contains
+    encrypted data of the type SignedRandomKeyPack instead of the
+    SignedReplyKeyPack.
+
+    SignedRandomKeyPack ::= SEQUENCE {
+        randomkeyPack           [0] RandomKeyPack,
+        randomkeyPackSig        [1] Signature
+                                    -- of keyPack
+                                    -- using user's private key
+    }
+
+    RandomKeyPack ::= SEQUENCE {
+        randomKey               [0] EncryptionKey,
+                                    -- will be used to encrypt reply
+        randomKeyAuth           [1] PKAuthenticator
+    }
+
+    If the KDC does not accept client-generated random keys as a matter
+    of policy, then it sends back an error message of type
+    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
+    follows.
+
+    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
+    the randomKey.  It then replies as per RFC 1510, except that the
+    reply is encrypted not with a password-derived user key, but with
+    the randomKey sent in the request.  Since the client already knows
+    this key, there is no need to accompany the reply with an extra
+    preauthentication field.  The transited field of the ticket should
+    specify the certification path as described in Section 3.2.
+
+
+3.4.  Retrieving the User's Private Key from the KDC
+
+    Implementation of the changes described in this section are OPTIONAL
+    for compliance with PKINIT.  (This section may or may not fall under
+    the purview of a patent for private key storage; please see Section
+    8 for more information.)
+
+    When the user's private key is not stored local to the user, he may
+    choose to store the private key (normally encrypted using a
+    password-derived key) on the KDC.  In this case, the client makes a
+    request as described above, except that instead of preauthenticating
+    with his private key, he uses a symmetric key shared with the KDC.
+
+    For simplicity's sake, this shared key is derived from the password-
+    derived key used to encrypt the private key, in such a way that the
+    KDC can authenticate the user with the shared key without being able
+    to extract the private key.
+
+    We provide this option to present the user with an alternative to
+    storing the private key on local disk at each machine where he
+    expects to authenticate himself using PKINIT.  It should be noted
+    that it replaces the added risk of long-term storage of the private
+    key on possibly many workstations with the added risk of storing the
+    private key on the KDC in a form vulnerable to brute-force attack.
+
+    Denote by K1 the symmetric key used to encrypt the private key.
+    Then construct symmetric key K2 as follows:
+
+        * Perform a hash on K1.
+        * Truncate the digest to Length(K1) bytes.
+        * Rectify parity in each byte (if necessary) to obtain K2.
+
+    The KDC stores K2, the public key, and the encrypted private key.
+    This key pair is designated as the "primary" key pair for that user.
+    This primary key pair is the one used to perform initial
+    authentication using the PA-PK-AS-REP preauthentication field.  If
+    he desires, he may also store additional key pairs on the KDC; these
+    may be requested in addition to the primary.  When the client
+    requests initial authentication using public key cryptography, it
+    must then include in its request, instead of a PA-PK-AS-REQ, the
+    following preauthentication sequence:
+
+    PA-PK-KEY-REQ ::= SEQUENCE {
+                                -- PA TYPE 17
+        signedPKAuth            [0] SignedPKAuth,
+        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
+                                    -- payload is hash of public key
+                                    -- corresponding to desired
+                                    -- private key
+                                    -- if absent, KDC will return all
+                                    -- stored private keys
+    }
+
+    Checksum ::= SEQUENCE {
+        cksumtype               [0] INTEGER,
+        checksum                [1] OCTET STRING
+    }   -- as specified by RFC 1510
+
+    SignedPKAuth ::= SEQUENCE {
+        pkAuth                  [0] PKAuthenticator,
+        pkAuthSig               [1] Signature
+                                    -- of pkAuth
+                                    -- using the symmetric key K2
+    }
+
+    If a keyIDList is present, the first identifier should indicate
+    the primary private key.  No public key certificate is required,
+    since the KDC stores the public key along with the private key.
+    If there is no keyIDList, all the user's private keys are returned.
+
+    Upon receipt, the KDC verifies the signature using K2.  If the
+    verification fails, the KDC sends back an error of type
+    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
+    keys are not found on the KDC, then the KDC sends back an error of
+    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
+    described in Section 3.2, except that in addition, the KDC appends
+    the following preauthentication sequence:
+
+    PA-PK-KEY-REP ::= SEQUENCE {
+                                -- PA TYPE 18
+        encKeyRep               [0] EncryptedData
+                                    -- of type EncKeyReply
+                                    -- using the symmetric key K2
+    }
+
+    EncKeyReply ::= SEQUENCE {
+        keyPackList             [0] SEQUENCE OF KeyPack,
+                                    -- the first KeyPair is
+                                    -- the primary key pair
+        nonce                   [1] INTEGER
+                                    -- binds reply to request
+                                    -- must be identical to the nonce
+                                    -- sent in the SignedAuthPack
+    }
+
+    KeyPack ::= SEQUENCE {
+        keyID                   [0] Checksum,
+        encPrivKey              [1] OCTET STRING
+    }
+
+    Upon receipt of the reply, the client extracts the encrypted private
+    keys (and may store them, at the client's option).  The primary
+    private key, which must be the first private key in the keyPack
+    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
+    this key in turn is used to decrypt the main reply as described in
+    Section 3.2.
+
+
+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
+    that use either the Standard Public Key Authentication or Public Key
+    Authentication with a Digital Signature.  However, if these users
+    are registered with the KDC, it is recommended that the database
+    record for these users be modified to include three additional flags
+    in the attributes field.
+
+    The first flag, use_standard_pk_init, indicates that the user should
+    authenticate using standard PKINIT as described in Section 3.2.  The
+    second flag, use_digital_signature, indicates that the user should
+    authenticate using digital signature PKINIT as described in Section
+    3.3.  The third flag, store_private_key, indicates that the user
+    has stored his private key on the KDC and should retrieve it using
+    the exchange described in Section 3.4.
+
+    If one of the preauthentication fields defined above is included in
+    the request, then the KDC shall respond as described in Sections 3.2
+    through 3.4, ignoring the aforementioned database flags.  If more
+    than one of the preauthentication fields is present, the KDC shall
+    respond with an error of type KDC_ERR_PREAUTH_FAILED.
+
+    In the event that none of the preauthentication fields defined above
+    are included in the request, the KDC checks to see if any of the
+    above flags are set.  If the first flag is set, then it sends back
+    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
+    preauthentication field of type PA-PK-AS-REQ must be included in the
+    request.
+
+    Otherwise, if the first flag is clear, but the second flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-AS-SIGN must
+    be included in the request.
+
+    Lastly, if the first two flags are clear, but the third flag is set,
+    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
+    indicating that a preauthentication field of type PA-PK-KEY-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 order
+    to simplify key management, 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.
+
+
+5.  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.
+
+
+6.  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] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.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] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
+    Protocol, Version 3.0 - IETF Draft. 
+
+    [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. Hously. Cryptographic Message Syntax. 
+    draft-ietf-smime-cms-04.txt, March 1998.
+
+    [12] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [13] Ron Rivest, MIT Laboratory for Computer Science and
+    RSA Data Security, Inc. A Description of the RC2(r) Encryption
+    Algorithm, November 1997.
+
+    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [15] PKCS #6: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+
+7.  Patent Issues
+
+    The private key storage and retrieval process described in Section
+    3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie
+    Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of
+    Digital Corporation).  At this time, inquiries into this patent are
+    inconclusive.  We solicit discussion from any party who can illuminate
+    the coverage of this particular patent.
+
+
+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 May 15, 1999.
+
+
+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
+
+    John Wray
+    Digital Equipment Corporation
+    550 King Street, LKG2-2/Z7
+    Littleton, MA 01460
+    Phone: +1 508 486 5210
+    E-mail: wray@tuxedo.enet.dec.com
+
+    Ari Medvinsky
+    Matthew Hur
+    Sasha Medvinsky
+    CyberSafe Corporation
+    1605 NW Sammamish Road Suite 310
+    Issaquah WA 98027-5378
+    Phone: +1 206 391 6000
+    E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com
+
+    Jonathan Trostle
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt
new file mode 100644
index 00000000000..51e252acf4b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt
@@ -0,0 +1,944 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-08.txt                   Clifford Neuman
+Updates: RFC 1510                                                    ISI
+expires November 12, 1999                                    Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                                  Excite
+                                                         Sasha Medvinsky
+                                                      General Instrument
+                                                               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-09.txt, and expires November 12,
+    1999.  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 Diffie-Hellman keys in combination with digital
+    signature keys as the primary, required mechanism.  It also allows
+    for the use of RSA keys.  Note 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 a request to the KDC as before, except that if that user
+    is to use public key cryptography in the initial authentication
+    step, his certificate 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.
+
+    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
+        PA-PK-KEY-REQ                           18
+        PA-PK-KEY-REP                           19
+
+    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
+
+    We utilize the following typed data for errors:
+
+        ETD-PKINIT-CMS-CERTIFICATES            101
+        ETD-KRB-PRINCIPAL                      102
+        ETD-KRB-REALM                          103
+
+    We utilize the following encryption types (which map directly to
+    OIDs):
+        sha1WithRSAEncryption-CmsOID             8
+        dsaWithSHA1-CmsOID                       9
+        md4WithRsaEncryption-CmsOID             10
+        md5WithRSAEncryption-CmsOID             11
+        rc2CBC-EnvOID                           12
+        rc4-EnvOID                              13
+
+    In many cases, PKINIT requires the encoding of an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        X500-RFC2253:RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    readable ASCII encoding of an X.500 name, as defined by
+    RFC 2253 [14] (part of LDAPv3).
+
+    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, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
+    defined as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.
+
+    Note that name mapping may be required or optional based on policy.
+
+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.
+
+    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
+
+    These are the algorithm identifiers for use in the Signature data
+    structure as specified in CMS [11]:
+
+    sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-1(1) 5 }
+
+    dsaWithSHA1 ALGORITHM PARAMETER NULL
+         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
+               oIWSecAlgorithm(2) dsaWithSHA1(27) }
+
+    md4WithRsaEncryption ALGORITHM PARAMETER NULL
+         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
+               oIWSecAlgorithm(2) md4WithRSAEncryption(4) }
+
+    md5WithRSAEncryption ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-1(1) md5WithRSAEncryption(4) }
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+    This algorithm identifier is used inside the SubjectPublicKeyInfo
+    data structure:
+
+    dhKeyAgreement ALGORITHM PARAMETER DHParameters
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-3(3) dhKeyAgreement(1) }
+
+    DHParameters ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+    }   -- as specified by the X.509 recommendation [9]
+
+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:
+
+    id-RSAES-OAEP OBJECT IDENTIFIER
+         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+               pkcs-1(1) 7 }
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+    These algorithm identifiers are used inside the EnvelopedData data
+    structure, for encrypting the temporary key with a Diffie-Hellman-
+    derived key, or for encrypting the reply key:
+
+    desCBC ALGORITHM PARAMETER IV8
+         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
+               oIWSecAlgorithm(2) desCBC(7) }
+
+    DES-EDE3-CBC ALGORITHM PARAMETER IV8
+         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
+               encryptionAlgorithm(3) desEDE3(7) }
+
+    IV8 ::= OCTET STRING (SIZE(8))        -- initialization vector
+
+    rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
+         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
+               encryptionAlgorithm(3) rc2CBC(2) }
+
+    The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
+    in the following section.
+
+    rc4 ALGORITHM PARAMETER NULL
+         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
+               encryptionAlgorithm(3) rc4(4) }
+
+    The rc4 algorithm cannot be used with the Diffie-Hellman-derived
+    keys, because its parameters do not specify the size of the key.
+
+3.1.2.5. rc2CBC Algorithm Parameters
+
+    This definition of the RC2 parameters is taken from a paper by
+    Ron Rivest [13]. Refer to [13] for the complete description of the
+    RC2 algorithm.
+
+    RC2-CBCParameter ::= CHOICE {
+        iv IV,
+        params SEQUENCE {
+            version RC2Version,
+            iv IV
+        }
+    }
+
+    where
+
+    IV ::= OCTET STRING -- 8 octets
+    RC2Version ::= INTEGER -- 1-1024
+
+    RC2 in CBC mode has two parameters: an 8-byte initialization
+    vector (IV) and a version number in the range 1-1024 which
+    specifies in a roundabout manner the number of effective key bits
+    to be used for the RC2 encryption/decryption.
+
+    The correspondence between effective key bits and version number
+    is as follows:
+
+    1. If the number EKB of effective key bits is in the range 1-255,
+       then the version number is given by Table[EKB], where the
+       256-byte translation table is specified below. It specifies a
+       permutation on the numbers 0-255.
+
+    2. If the number EKB of effective key bits is in the range
+       256-1024, then the version number is simply EKB.
+
+       The default number of effective key bits for RC2 is 32.
+       If RC2-CBC is being performed with 32 effective key bits, the
+       parameters should be supplied as a simple IV, rather than as a
+       SEQUENCE containing a version and an IV.
+
+         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
+
+    00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0
+    10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a
+    20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36
+    30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
+    40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
+    50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
+    60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
+    70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
+    80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
+    90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
+    a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
+    b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
+    c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
+    d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
+    e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
+    f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
+
+
+3.2.  Public Key Authentication
+
+    Implementation of the changes in this section is REQUIRED for
+    compliance with PKINIT.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's 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 PrincipalName OPTIONAL,
+                                    -- CAs that the client trusts
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- as defined in CMS [11]
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+    }
+
+    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 encapContentInfo field must contain the PKAuthenticator
+      and, optionally, the client's Diffie Hellman public value.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+      - The eContent field is data of the type AuthPack (below).
+    - The signerInfos field is a SET of SignerInfo that is required by
+      CMS; however, the set may contain zero elements.  When non-empty,
+      this field 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 certificates 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.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        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 [9]
+
+    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-typed-data
+    type as follows:
+
+    ETypedData ::=  SEQUENCE {
+                    e-data-type    [1] INTEGER,
+                    e-data-value   [2] OCTET STRING,
+    } -- per Kerberos RFC 1510 revisions
+
+    where:
+    e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101
+    e-data-value = CertificateSet // as specified by CMS [11]
+
+    The PKAuthenticator carries information to foil replay attacks,
+    to bind the request and response.  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    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.
+
+    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 verification of the user's certificate fails, the KDC sends back
+    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
+    field contains additional information pertaining to this error, and
+    is formatted as follows:
+
+        METHOD-DATA ::= SEQUENCE {
+            method-type         [0] INTEGER,
+                                    -- 0 = not specified
+                                    -- 1 = cannot verify public key
+                                    -- 2 = invalid certificate
+                                    -- 3 = revoked certificate
+                                    -- 4 = invalid KDC name
+                                    -- 5 = client name mismatch
+            method-data         [1] OCTET STRING OPTIONAL
+        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
+
+    The values for the method-type and method-data fields are described
+    in Section 3.2.1.
+
+    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.  If the
+    principal name or realm do not match the KDC, then the KDC returns
+    an error message of type KDC_ERR_NAME_MISMATCH for which the
+    e-typed-data may contain the correct name to use
+    (EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where
+    e-data-value = PrincipalName or Realm as defined by RFC 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 a Kerberos name in an extension
+            field, and local KDC policy allows, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, 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
+            certification authority that issued the user's certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Helman key exchange
+        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:
+    If 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:
+    - 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.
+    - 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.
+    - If the reply key is DES, N=64 bits, where some of the bits are
+      replaced with parity bits, according to FIPS PUB 74.
+    - 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.
+    - The encapContentInfo field must contain the KdcDHKeyInfo as
+      defined below.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+    - 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).
+    - The signerInfos field is a SET that must contain at least one
+      member, since it contains the actual signature.
+
+    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 an temporary key encrypted with the PKINIT
+    client's public key.  It also contains a signed and encrypted
+    reply key.
+    - The originatorInfo field is not required, since that information
+      may be presented in the signedData structure that is encrypted
+      within the encryptedContentInfo field.
+    - The optional unprotectedAttrs field is not required for PKINIT.
+    - The recipientInfos field is a SET which must contain exactly one
+      member of the KeyTransRecipientInfo type for encryption
+      with an RSA public key.
+         - The encryptedKey field (in KeyTransRecipientInfo) contains
+           the temporary key which is encrypted with the PKINIT client's
+           public key.
+    - The encryptedContentInfo field contains the signed and encrypted
+      reply key.
+      - 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)
+      - The encryptedContent field is encrypted data of the CMS type
+        signedData as specified below.
+        - The encapContentInfo field must contains the ReplyKeyPack.
+          - The eContentType field shall contain the OID value for
+            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+            pkcs(1) pkcs7(7) data(1)
+          - The eContent field is data of the type ReplyKeyPack (below).
+        - 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).
+        - 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
+    }
+
+    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 essentially a separate realm, the name of each
+    certifier 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  X.509 certificates shall
+    contain the principal name of the KDC 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] INSTANCE OF OTHER-NAME,
+            ...
+        }
+
+        OTHER-NAME ::= TYPE-IDENTIFIER
+
+    In this definition, otherName is a name of any form defined as an
+    instance of the OTHER-NAME information object class. For the purpose
+    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
+    be replaced by the type KerberosPrincipalName:
+
+        KerberosPrincipalName ::= SEQUENCE {
+            nameType      [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
+            name          [1] OTHER-NAME.&type ( { PrincipalNameTypes }
+                              { @nameType } )
+        }
+
+        PrincipalNameTypes OTHER-NAME ::= {
+            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
+        }
+
+        PrincipalNameSrvInst ::= GeneralString
+
+    where (from the Kerberos specification) we have
+
+        krb5 OBJECT IDENTIFIER ::= { iso (1)
+                                     org (3)
+                                     dod (6)
+                                     internet (1)
+                                     security (5)
+                                     kerberosv5 (2) }
+
+        principalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
+
+    (This specification can also be used to specify a Kerberos name
+    within the user'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.
+
+3.2.1.  Additional Information for Errors
+
+    This section describes the interpretation of the method-type and
+    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
+
+    If method-type=1, the client's public key certificate chain does not
+    contain a certificate that is signed by a certification authority
+    trusted by the KDC.  The format of the method-data field will be an
+    ASN.1 encoding of a list of trusted certifiers, as defined above:
+
+        TrustedCertifiers ::= SEQUENCE OF PrincipalName
+
+    If method-type=2, the signature on one of the certificates in the
+    chain cannot be verified.  The format of the method-data field will
+    be an ASN.1 encoding of the integer index of the certificate in
+    question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=3, one of the certificates in the chain has been
+    revoked.  The format of the method-data field will be an ASN.1
+    encoding of the integer index of the certificate in question:
+
+        CertificateIndex ::= INTEGER
+                             -- 0 = 1st certificate,
+                             -- 1 = 2nd certificate, etc
+
+    If method-type=4, the KDC name or realm in the PKAuthenticator does
+    not match the principal name of the KDC.  There is no method-data
+    field in this case.
+
+    If method-type=5, the client name or realm in the certificate does
+    not match the principal name of the client.  There is no
+    method-data field in this case.
+
+3.2.2. 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
+    - 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
+    that use either the Standard 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 order
+    to simplify key management, 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] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.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-10.txt, December 1998.
+
+    [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.
+
+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 November 12, 1999.
+
+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
+    Excite
+    555 Broadway
+    Redwood City, CA 94063
+    Phone +1 650 569 2119
+    E-mail: amedvins@excitecorp.com
+
+    Sasha Medvinsky
+    General Instrument
+    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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt
new file mode 100644
index 00000000000..748f08954b8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt
@@ -0,0 +1,908 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-09.txt                   Clifford Neuman
+Updates: RFC 1510                                                    ISI
+expires December 1, 1999                                     Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                                  Excite
+                                                         Sasha Medvinsky
+                                                      General Instrument
+                                                               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-09.txt, and expires December 1,
+    1999.  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 Diffie-Hellman keys in combination with digital
+    signature keys as the primary, required mechanism.  It also allows
+    for the use of RSA keys.  Note 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 a request to the KDC as before, except that if that user
+    is to use public key cryptography in the initial authentication
+    step, his certificate 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.
+
+    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 an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        X500-RFC2253:RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    readable UTF encoding of an X.500 name, as defined by
+    RFC 2253 [14] (part of LDAPv3).
+
+    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, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
+    defined as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.
+
+    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 within this structure,
+    the name-string shall be encoded as a single GeneralString.
+
+    Note that name mapping may be required or optional based on
+    policy.
+
+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.
+
+    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.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's 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,
+                                    -- CAs that the client trusts
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- as defined in CMS [11]
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+        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 OPTIONAL
+                                  -- 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 encapContentInfo field must contain the PKAuthenticator
+      and, optionally, the client's Diffie Hellman public value.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+      - The eContent field is data of the type AuthPack (below).
+    - The signerInfos field contains the signature of AuthPack.
+    - 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 certificates 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
+      enable static-ephemeral Diffie-Hellman mode for the reply.  As
+      another example, the client may place an RSA encryption
+      certificate in this field.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        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,
+    to bind the request and response.  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    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.
+
+    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 the signature on one of the certificates in the client's chain
+    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
+
+        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, the KDC returns an
+    error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
+    status is unavailable, the KDC returns an error of type
+    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.
+
+    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.
+
+    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 a Kerberos name in an extension
+            field, and local KDC policy allows, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, 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
+            certification authority that issued the user's certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Helman key exchange
+                            -- 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:
+    If 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:
+    - 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.
+    - 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.
+    - If the reply key is DES, N=64 bits, where some of the bits are
+      replaced with parity bits, according to FIPS PUB 74.
+    - 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.
+    - The encapContentInfo field must contain the KdcDHKeyInfo as
+      defined below.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+    - 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).
+    - The signerInfos field is a SET that must contain at least one
+      member, since it contains the actual signature.
+
+    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 an temporary key encrypted with the PKINIT
+    client's public key.  It also contains a signed and encrypted
+    reply key.
+    - The originatorInfo field is not required, since that information
+      may be presented in the signedData structure that is encrypted
+      within the encryptedContentInfo field.
+    - The optional unprotectedAttrs field is not required for PKINIT.
+    - The recipientInfos field is a SET which must contain exactly one
+      member of the KeyTransRecipientInfo type for encryption
+      with an RSA public key.
+         - The encryptedKey field (in KeyTransRecipientInfo) contains
+           the temporary key which is encrypted with the PKINIT client's
+           public key.
+    - The encryptedContentInfo field contains the signed and encrypted
+      reply key.
+      - 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)
+      - The encryptedContent field is encrypted data of the CMS type
+        signedData as specified below.
+        - The encapContentInfo field must contains the ReplyKeyPack.
+          - The eContentType field shall contain the OID value for
+            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+            pkcs(1) pkcs7(7) data(1)
+          - The eContent field is data of the type ReplyKeyPack (below).
+        - 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).
+        - 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
+    }
+
+    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 essentially a separate realm, the name of each
+    certifier 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  X.509 certificates shall
+    contain the principal name of the KDC 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] INSTANCE OF OTHER-NAME,
+            ...
+        }
+
+        OTHER-NAME ::= TYPE-IDENTIFIER
+
+    In this definition, otherName is a name of any form defined as an
+    instance of the OTHER-NAME information object class. For the purpose
+    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
+    be chosen and replaced by the type KerberosName:
+
+        KerberosName ::= SEQUENCE {
+          realm           [0] Realm,
+                              -- as define in RFC 1510
+          principalName   [1] PrincipalName,
+                              -- as define in RFC 1510
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the OID id-ce-subjectAltName 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.
+
+    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 as 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 client then extracts the random key used to encrypt the main
+    reply.  This random key (in encPaReply) is encrypted with either the
+    client's public key or with a key derived from the DH values
+    exchanged between the client and the KDC.
+
+3.2.2. 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 order
+    to simplify key management, 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] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.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.
+
+    [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
+
+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 December 1, 1999.
+
+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
+    Excite
+    555 Broadway
+    Redwood City, CA 94063
+    Phone +1 650 569 2119
+    E-mail: amedvins@excitecorp.com
+
+    Sasha Medvinsky
+    General Instrument
+    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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt
new file mode 100644
index 00000000000..7dcb06a6036
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt
@@ -0,0 +1,957 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-10.txt                   Clifford Neuman
+Updates: RFC 1510                                                    ISI
+expires April 30, 2000                                       Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                                  Excite
+                                                         Sasha Medvinsky
+                                                      General Instrument
+                                                               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-10.txt, and expires April 30,
+    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 ream 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 within this structure,
+    the name-string shall be encoded as a single GeneralString.
+
+    Note that name mapping may be required or optional based on
+    policy.  All names must conform to validity requirements as given
+    in RFC 1510.
+
+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,
+                                    -- CAs that the client trusts
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- as defined in CMS [11]
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it;
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
+                                    -- For example, this may be the
+                                    -- client's Diffie-Hellman
+                                    -- certificate, or it may be the
+                                    -- client's RSA encryption
+                                    -- certificate.
+    }
+
+    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 encapContentInfo field must contain the PKAuthenticator
+      and, optionally, the client's Diffie Hellman public value.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+      - The eContent field is data of the type AuthPack (below).
+    - The signerInfos field contains the signature of AuthPack.
+    - 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 certificates 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.
+
+    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 as 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:
+    If 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:
+    - 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.
+    - 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.
+    - If the reply key is DES, N=64 bits, where some of the bits are
+      replaced with parity bits, according to FIPS PUB 74.
+    - 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.
+    - The encapContentInfo field must contain the KdcDHKeyInfo as
+      defined below.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+    - 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).
+    - 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 an temporary key encrypted with the PKINIT
+    client's public key.  It also contains a signed and encrypted
+    reply key.
+    - The originatorInfo field is not required, since that information
+      may be presented in the signedData structure that is encrypted
+      within the encryptedContentInfo field.
+    - The optional unprotectedAttrs field is not required for PKINIT.
+    - The recipientInfos field is a SET which must contain exactly one
+      member of the KeyTransRecipientInfo type for encryption
+      with an RSA public key.
+         - The encryptedKey field (in KeyTransRecipientInfo) contains
+           the temporary key which is encrypted with the PKINIT client's
+           public key.
+    - The encryptedContentInfo field contains the signed and encrypted
+      reply key.
+      - 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)
+      - The encryptedContent field is encrypted data of the CMS type
+        signedData as specified below.
+        - The encapContentInfo field must contains the ReplyKeyPack.
+          - The eContentType field shall contain the OID value for
+            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+            pkcs(1) pkcs7(7) data(1)
+          - The eContent field is data of the type ReplyKeyPack (below).
+        - 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).
+        - 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] INSTANCE OF OTHER-NAME,
+            ...
+        }
+
+        OTHER-NAME ::= TYPE-IDENTIFIER
+
+    In this definition, otherName is a name of any form defined as an
+    instance of the OTHER-NAME information object class. For the purpose
+    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
+    be chosen and replaced by the type KerberosName:
+
+        KerberosName ::= SEQUENCE {
+          realm           [0] Realm,
+                              -- as defined in RFC 1510
+          principalName   [1] PrincipalName,
+                              -- as defined in RFC 1510
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the OID id-ce-subjectAltName 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 order
+    to simplify key management, 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] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.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.
+
+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 April 30, 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
+    Excite
+    555 Broadway
+    Redwood City, CA 94063
+    Phone +1 650 569 2119
+    E-mail: amedvins@excitecorp.com
+
+    Sasha Medvinsky
+    General Instrument
+    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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
new file mode 100644
index 00000000000..9b0e76adad9
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
new file mode 100644
index 00000000000..b1e596836eb
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt
new file mode 100644
index 00000000000..1bcc2ad451e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt
@@ -0,0 +1,1062 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-13.txt                   Clifford Neuman
+Updates: RFC 1510                                                USC/ISI
+expires August 31, 2001                                      Matthew Hur
+                                                                   Cisco
+                                                           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 August 31,
+    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 DSA keys as the primary, required mechanism.  Note
+    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
+    symmetric key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKINIT may be utilized to establish
+    inter-realm keys for the purposes of issuing cross-realm service
+    tickets.  It may also be used to issue anonymous Kerberos tickets
+    using the Diffie-Hellman option.  Efforts are under way to draft
+    specifications for these two application protocols.
+
+    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 MUST be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510 as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    For this type, the name-string MUST be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm MUST 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
+        }
+
+    The following rules relate to the the matching of PrincipalNames
+    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 client principal name 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 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.
+
+            c.  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 is 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] are 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 MUST 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.
+
+    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
+            as necessary (e.g., as per RFC 2253 for X.500 names).  In
+            this case the realm in the ticket MUST be the name of the
+            certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subjectAltName
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subjectAltName 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 mapped
+    according to local policy.  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 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.
+
+            a.  For example, if the reply key is DES, N=64 bits, where
+                some of the bits are replaced with parity bits, according
+                to FIPS PUB 74.
+
+            b.  As another example, 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.
+
+        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field MUST 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).
+
+        4.  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).
+
+        5.  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 a 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 MUST 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 MUST 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,
+                                 -- from RFC 1510bis
+                                 -- 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
+    }
+
+
+3.2.2.1. Use of transited Field
+
+    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.
+
+
+3.2.2.2. Kerberos Names in Certificates
+
+    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 MUST 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 MUST be a KerberosName as defined in RFC 1510:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] PrincipalName
+        }
+
+    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.
+
+    Note that the KDC's principal name has the instance equal to the
+    realm, and those fields should be appropriately set in the realm
+    and principalName fields of the KerberosName.  This is the case
+    even when obtaining a cross-realm ticket using PKINIT.
+
+
+3.2.3. Client Extraction of Reply
+
+    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.4. 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 August 31, 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
+    Cisco Systems
+    500 108th Ave. NE, Suite 500
+    Bellevue, WA 98004
+    Phone: (408) 525-0034
+    EMail: mhur@cisco.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
+    Cisco Systems
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt
new file mode 100644
index 00000000000..49ea9de8eb9
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt
@@ -0,0 +1,1104 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-14.txt                   Clifford Neuman
+Updates: RFC 1510bis                                             USC/ISI
+expires January 15, 2002                                     Matthew Hur
+                                                                   Cisco
+                                                           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-14.txt, and expires January 15,
+    2002.  Please send comments to the authors.
+
+1.  Abstract
+
+    This document defines extensions (PKINIT) to the Kerberos protocol
+    specification (RFC 1510bis [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 DSA keys as the primary, required mechanism.  Note
+    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
+    symmetric key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKINIT may be utilized to establish
+    inter-realm keys for the purposes of issuing cross-realm service
+    tickets.  It may also be used to issue anonymous Kerberos tickets
+    using the Diffie-Hellman option.  Efforts are under way to draft
+    specifications for these two application protocols.
+
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT 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 [5] 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 [6]).
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510bis 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 1510bis 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 RFC 1510bis.
+    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 [11] (part of LDAPv3 [15]).
+
+    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 MUST be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510bis as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    For this type, the name-string MUST be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm MUST be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section.
+
+    RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    The following rules relate to the the matching of PrincipalNames
+    with regard to the PKI name constraints for CAs as laid out in RFC
+    2459 [12].  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 client principal name plus realm name (as specified in
+            RFC 1510bis), 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 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.
+
+            c.  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 is 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.  Appropriate
+    key constraints for each valid cryptosystem are given in RFC
+    1510bis.
+
+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 [8] and
+    in [12] are 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 [12].
+
+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 [13].
+    Currently, only PKCS#1 v1.5 is specified by CMS [8], 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 [8].
+
+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 1510bis, 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 [8];
+                                    -- 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 [8];
+                                    -- 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 MUST 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.
+
+        4.  When a DH key is being used, the public exponent is provided
+            in the subjectPublicKey field of the SubjectPublicKeyInfo and
+            the DH parameters are supplied as a DHParameter in the
+            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
+            chosen from the First and Second defined Oakley Groups [The
+            Internet Key Exchange (IKE) RFC-2409], if a server will not
+            accept either of these groups, it will respond with a krb-error
+            of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a
+            DHParameter with appropriate parameters for the client to use.
+
+        5.  The KDC may wish to use cached Diffie-Hellman parameters
+            (see Section 3.2.2, KDC Response).  To indicate acceptance
+            of cached parameters, the client sends zero in the nonce
+            field of the PKAuthenticator.  Zero is not a valid value
+            for this field under any other circumstances.  If cached
+            parameters are used, the client and the KDC MUST perform
+            key derivation (for the appropriate cryptosystem) on the
+            resulting encryption key, as specified in RFC 1510bis.  (With
+            a zero nonce, message binding is performed using the nonce
+            in the main request, which must be encrypted using the
+            encapsulated reply key.)
+
+    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 RFC 1510bis
+        ctime                   [1] KerberosTime,
+                                    -- for replay prevention as in RFC 1510bis
+        nonce                   [2] INTEGER,
+                                    -- zero only if client will accept
+                                    -- cached DH parameters from KDC;
+                                    -- must be non-zero otherwise
+        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 [7]
+
+    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 [17]
+        parameters                  ANY DEFINED by algorithm OPTIONAL
+                                    -- for dhKeyAgreement, this is
+                                    -- DHParameter
+    }   -- as specified by the X.509 recommendation [7]
+
+    DHParameter ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+                                    -- l
+    }   -- as defined in PKCS #3 [17]
+
+    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 1510bis revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510bis
+
+    where:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [8]
+
+    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.
+
+    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.
+
+    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, with an e-data containing a structure of
+    type DHParameter with appropriate DH parameters for the client to
+    retry the request.  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
+    RFC 1510bis.
+
+    Assuming no errors, the KDC replies as per RFC 1510bis, 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
+            as necessary (e.g., as per RFC 2253 for X.500 names).  In
+            this case the realm in the ticket MUST be the name of the
+            certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subjectAltName
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subjectAltName 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 [14], 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 mapped
+    according to local policy.  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 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.
+
+            a.  For example, if the reply key is DES, N=64 bits, where
+                some of the bits are replaced with parity bits, according
+                to FIPS PUB 74.
+
+            b.  As another example, 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.
+
+        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field MUST 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).
+
+        4.  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).
+
+        5.  The signerInfos field is a SET that MUST contain at least
+            one member, since it contains the actual signature.
+
+        6.  If the client indicated acceptance of cached Diffie-Hellman
+            parameters from the KDC, and the KDC supports such an option
+            (for performance reasons), the KDC should return a zero in
+            the nonce field and include the expiration time of the
+            parameters in the dhKeyExpiration field.  If this time is
+            exceeded, the client SHOULD NOT use the reply.  If the time
+            is absent, the client SHOULD NOT use the reply and MAY
+            resubmit a request with a non-zero nonce (thus indicating
+            non-acceptance of cached Diffie-Hellman parameters).  As
+            indicated above in Section 3.2.1, Client Request, when the
+            KDC uses cached parameters, the client and the KDC MUST
+            perform key derivation (for the appropriate cryptosystem)
+            on the resulting encryption key, as specified in RFC 1510bis.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      subjectPublicKey      [0] BIT STRING,
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+      nonce                 [1] INTEGER,
+                                -- Binds response to the request
+                                -- Exception: Set to zero when KDC
+                                -- is using a cached DH value
+      dhKeyExpiration       [2] KerberosTime OPTIONAL
+                                -- Expiration time for KDC's cached
+                                -- DH value
+    }
+
+    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 a 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 MUST 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 MUST 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,
+                                 -- from RFC 1510bis
+                                 -- 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
+    }
+
+
+3.2.2.1. Use of transited Field
+
+    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.
+
+
+3.2.2.2. Kerberos Names in Certificates
+
+    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 MUST contain the principal name of the KDC (defined in
+    RFC 1510bis) 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 MUST be a KerberosName as defined in RFC 1510bis:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] PrincipalName
+        }
+
+    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.
+
+    Note that the KDC's principal name has the instance equal to the
+    realm, and those fields should be appropriately set in the realm
+    and principalName fields of the KerberosName.  This is the case
+    even when obtaining a cross-realm ticket using PKINIT.
+
+
+3.2.3. Client Extraction of Reply
+
+    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 1510bis.
+
+3.2.4. 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.
+
+    Also, PKINIT 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.
+
+    Care should be taken in how certificates are choosen for the purposes
+    of authentication using PKINIT. Some local policies require that key
+    escrow be applied for certain certificate types. People deploying
+    PKINIT should be aware of the implications of using certificates that
+    have escrowed keys for the purposes of authentication.
+
+    As described in Section 3.2, PKINIT allows for the caching of the
+    Diffie-Hellman parameters on the KDC side, for performance reasons.
+    For similar reasons, the signed data in this case does not vary from
+    message to message, until the cached parameters expire.  Because of
+    the persistence of these parameters, the client and the KDC are to
+    use the appropriate key derivation measures (as described in RFC
+    1510bis) when using cached DH parameters.
+
+    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] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [7] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [8] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [9] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [10] 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.
+
+    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [15] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [16] 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
+
+    [17] 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, 2002.
+
+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
+    Cisco Systems
+    500 108th Ave. NE, Suite 500
+    Bellevue, WA 98004
+    Phone: (408) 525-0034
+    E-Mail: mhur@cisco.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
+    Cisco Systems
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt
new file mode 100644
index 00000000000..7d5a223ebed
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt
@@ -0,0 +1,1116 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-15.txt                   Clifford Neuman
+Updates: RFC 1510bis                                             USC/ISI
+expires May 25, 2002                                         Matthew Hur
+                                                                   Cisco
+                                                           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-15.txt, and expires May 25, 2002.
+    Please send comments to the authors.
+
+1.  Abstract
+
+    This document defines extensions (PKINIT) to the Kerberos protocol
+    specification (RFC 1510bis [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 DSA keys as the primary, required mechanism.  Note
+    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
+    symmetric key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKINIT may be utilized to establish
+    inter-realm keys for the purposes of issuing cross-realm service
+    tickets.  It may also be used to issue anonymous Kerberos tickets
+    using the Diffie-Hellman option.  Efforts are under way to draft
+    specifications for these two application protocols.
+
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT 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 [5] 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 [6]).
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510bis 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 1510bis 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).  The
+    above encryption types are utilized only within CMS structures
+    within the PKINIT preauthentication fields. Their use within
+    the Kerberos EncryptedData structure is unspecified.
+
+    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 RFC 1510bis.
+    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 [11] (part of LDAPv3 [15]).
+
+    Each component of a DistinguishedName is called a
+    RelativeDistinguishedName, where a RelativeDistinguishedName is a
+    SET OF AttributeTypeAndValue.  RFC 2253 does not specify the order
+    in which to encode the elements of the RelativeDistinguishedName and
+    so to ensure that this encoding is unique, we add the following rule
+    to those specified by RFC 2253:
+     
+	When converting a multi-valued RelativeDistinguishedName
+        to a string, the output consists of the string encodings
+        of each AttributeTypeAndValue, in the same order as
+	specified by the DER encoding.    
+
+    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 MUST be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510bis as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    For this type, the name-string MUST be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm MUST be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section.
+
+    Note that the same string may be represented using several different
+    ASN.1 data types.  As the result, the reverse conversion from an
+    RFC2253-encoded principal name back to an X.500 name may not be
+    unique and may result in an X.500 name that is not the same as the
+    original X.500 name found in the client certificate.
+
+    RFC 1510bis describes an alternate encoding of an X.500 name into a
+    realm name.  However, as described in RFC 1510bis, the alternate
+    encoding does not guarantee a unique mapping from a
+    DistinguishedName inside a certificate into a realm name and
+    similarly cannot be used to produce a unique principal name.  PKINIT
+    therefore uses an RFC 2253-based name mapping approach, as specified
+    above.
+
+    RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    The following rules relate to the the matching of PrincipalNames
+    with regard to the PKI name constraints for CAs as laid out in RFC
+    2459 [12].  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 client principal name plus realm name (as specified in
+            RFC 1510bis), 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 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.
+
+            c.  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 is produced from the agreed
+    bit string as follows:
+
+        * Truncate the bit string to the required length.
+        * Apply the specific cryptosystem's random-to-key function.
+
+    Appropriate key constraints for each valid cryptosystem are given
+    in RFC 1510bis.
+
+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 [8] and
+    in [12] are 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 [12].
+
+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 [13].
+    Currently, only PKCS#1 v1.5 is specified by CMS [8], 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 [8].
+
+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 1510bis, 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] ContentInfo,
+                                    -- Defined in CMS [8];
+                                    -- SignedData OID is {pkcs7 2}
+                                    -- 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 [8];
+                                    -- 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
+    }
+
+    The type of the ContentInfo in the signedAuthPack is SignedData.
+    Its usage is as follows:
+
+        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 MUST 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.
+
+        4.  When a DH key is being used, the public exponent is provided
+            in the subjectPublicKey field of the SubjectPublicKeyInfo and
+            the DH parameters are supplied as a DHParameter in the
+            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
+            chosen from the First and Second defined Oakley Groups [The
+            Internet Key Exchange (IKE) RFC-2409], if a server will not
+            accept either of these groups, it will respond with a krb-error
+            of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a
+            DHParameter with appropriate parameters for the client to use.
+
+        5.  The KDC may wish to use cached Diffie-Hellman parameters
+            (see Section 3.2.2, KDC Response).  To indicate acceptance
+            of cached parameters, the client sends zero in the nonce
+            field of the PKAuthenticator.  Zero is not a valid value
+            for this field under any other circumstances.  If cached
+            parameters are used, the client and the KDC MUST perform
+            key derivation (for the appropriate cryptosystem) on the
+            resulting encryption key, as specified in RFC 1510bis.  (With
+            a zero nonce, message binding is performed using the nonce
+            in the main request, which must be encrypted using the
+            encapsulated reply key.)
+
+    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 RFC 1510bis
+        ctime                   [1] KerberosTime,
+                                    -- for replay prevention as in RFC 1510bis
+        nonce                   [2] INTEGER,
+                                    -- zero only if client will accept
+                                    -- cached DH parameters from KDC;
+                                    -- must be non-zero otherwise
+        pachecksum              [3] Checksum
+                                    -- Checksum over KDC-REQ-BODY
+                                    -- Defined by Kerberos spec;
+				    -- must be unkeyed, e.g. sha1 or rsa-md5
+    }
+
+    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 [7]
+
+    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 [17]
+        parameters                  ANY DEFINED by algorithm OPTIONAL
+                                    -- for dhKeyAgreement, this is
+                                    -- DHParameter
+    }   -- as specified by the X.509 recommendation [7]
+
+    DHParameter ::= SEQUENCE {
+        prime                       INTEGER,
+                                    -- p
+        base                        INTEGER,
+                                    -- g
+        privateValueLength          INTEGER OPTIONAL
+                                    -- l
+    }   -- as defined in PKCS #3 [17]
+
+    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 1510bis revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510bis
+
+    where:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [8]
+
+    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.
+
+    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.
+
+    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, with an e-data containing a structure of
+    type DHParameter with appropriate DH parameters for the client to
+    retry the request.  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
+    RFC 1510bis.
+
+    Assuming no errors, the KDC replies as per RFC 1510bis, 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
+            as necessary (e.g., as per RFC 2253 for X.500 names).  In
+            this case the realm in the ticket MUST be the name of the
+            certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subjectAltName
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subjectAltName 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 [14], 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 mapped
+    according to local policy.  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 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] ContentInfo,
+                            -- Defined in CMS [8] and used only with
+                            -- Diffie-Hellman key exchange (if the
+                            -- client public value was present in the
+                            -- request).
+                            -- SignedData OID is {pkcs7 2}
+                            -- This choice MUST be supported
+                            -- by compliant implementations.
+        encKeyPack         [1] ContentInfo
+                            -- Defined in CMS [8].
+                            -- The temporary key is encrypted
+                            -- using the client public key
+                            -- key.
+                            -- EnvelopedData OID is {pkcs7 3}
+                            -- SignedReplyKeyPack, encrypted
+                            -- with the temporary key, is also
+                            -- included.
+    }
+
+    The type of the ContentInfo in the dhSignedData is SignedData.
+    Its usage is as follows:
+
+        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.
+
+            a.  For example, if the reply key is DES, N=64 bits, where
+                some of the bits are replaced with parity bits, according
+                to FIPS PUB 74.
+
+            b.  As another example, 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.
+
+        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field MUST 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).
+
+        4.  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).
+
+        5.  The signerInfos field is a SET that MUST contain at least
+            one member, since it contains the actual signature.
+
+        6.  If the client indicated acceptance of cached Diffie-Hellman
+            parameters from the KDC, and the KDC supports such an option
+            (for performance reasons), the KDC should return a zero in
+            the nonce field and include the expiration time of the
+            parameters in the dhKeyExpiration field.  If this time is
+            exceeded, the client SHOULD NOT use the reply.  If the time
+            is absent, the client SHOULD NOT use the reply and MAY
+            resubmit a request with a non-zero nonce (thus indicating
+            non-acceptance of cached Diffie-Hellman parameters).  As
+            indicated above in Section 3.2.1, Client Request, when the
+            KDC uses cached parameters, the client and the KDC MUST
+            perform key derivation (for the appropriate cryptosystem)
+            on the resulting encryption key, as specified in RFC 1510bis.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      subjectPublicKey      [0] BIT STRING,
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+      nonce                 [1] INTEGER,
+                                -- Binds response to the request
+                                -- Exception: Set to zero when KDC
+                                -- is using a cached DH value
+      dhKeyExpiration       [2] KerberosTime OPTIONAL
+                                -- Expiration time for KDC's cached
+                                -- DH value
+    }
+
+    The type of the ContentInfo in the encKeyPack is EnvelopedData.  Its
+    usage is as follows:
+
+        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 a 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 MUST 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 MUST 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,
+                                 -- from RFC 1510bis
+                                 -- 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
+    }
+
+
+3.2.2.1. Use of transited Field
+
+    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.
+
+
+3.2.2.2. Kerberos Names in Certificates
+
+    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 MUST contain the principal name of the KDC (defined in
+    RFC 1510bis) 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 MUST be a KerberosName, defined as follows:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] PrincipalName
+        }
+
+    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.
+
+    Note that the KDC's principal name has the instance equal to the
+    realm, and those fields should be appropriately set in the realm
+    and principalName fields of the KerberosName.  This is the case
+    even when obtaining a cross-realm ticket using PKINIT.
+
+
+3.2.3. Client Extraction of Reply
+
+    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 1510bis.
+
+3.2.4. 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 for the Checksum in the PKAuthenticator
+        * using Kerberos checksum type 'sha1'
+    * 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 extends the cross-realm model to the public
+    key infrastructure.  Anyone using PKINIT must be aware of how the
+    certification infrastructure they are linking to works.
+
+    Also, as in standard Kerberos, PKINIT presents the possibility of
+    interactions between different cryptosystems of varying strengths,
+    and this now includes public-key cryptosystems.  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, may be inappropriate.
+
+    Care should be taken in how certificates are choosen for the purposes
+    of authentication using PKINIT. Some local policies require that key
+    escrow be applied for certain certificate types. People deploying
+    PKINIT should be aware of the implications of using certificates that
+    have escrowed keys for the purposes of authentication.
+
+    As described in Section 3.2, PKINIT allows for the caching of the
+    Diffie-Hellman parameters on the KDC side, for performance reasons.
+    For similar reasons, the signed data in this case does not vary from
+    message to message, until the cached parameters expire.  Because of
+    the persistence of these parameters, the client and the KDC are to
+    use the appropriate key derivation measures (as described in RFC
+    1510bis) when using cached DH parameters.
+
+    Lastly, PKINIT calls for randomly generated keys for conventional
+    cryptosystems.  Many such systems contain systematically "weak"
+    keys.  For recommendations regarding these weak keys, see RFC
+    1510bis.
+
+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] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [7] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [8] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [9] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [10] 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.
+
+    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [15] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [16] 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
+
+    [17] 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 May 25, 2002.
+
+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
+    Cisco Systems
+    2901 Third Avenue
+    Seattle WA 98121
+    Phone: (206) 256-3197
+    E-Mail: mhur@cisco.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
+    Cisco Systems
+    170 W. Tasman Dr.
+    San Jose, CA 95134
+    E-mail: jtrostle@cisco.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-16.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-16.txt
new file mode 100644
index 00000000000..10dd60299ac
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-16.txt
@@ -0,0 +1,1132 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-16.txt                   Clifford Neuman
+Updates: RFC 1510bis                                             USC/ISI
+expires March 12, 2002                                       Matthew Hur
+                                                   Microsoft Corporation
+                                                           Ari Medvinsky
+                                                   Liberate Technologies
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+
+    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-16.txt, and expires March 12,
+    2002.  Please send comments to the authors.
+
+1.  Abstract
+
+    This document defines extensions (PKINIT) to the Kerberos protocol
+    specification (RFC 1510bis [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 RSA keys as the primary, required mechanism.  Note
+    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
+    symmetric key, a public key, or both.
+
+    The PKINIT specification may also be used as a building block for
+    other specifications.  PKINIT may be utilized to establish
+    inter-realm keys for the purposes of issuing cross-realm service
+    tickets.  It may also be used to issue anonymous Kerberos tickets
+    using the Diffie-Hellman option.  Efforts are under way to draft
+    specifications for these two application protocols.
+
+    Additionally, the PKINIT specification may be used for direct peer
+    to peer authentication without contacting a central KDC. This
+    application of PKINIT 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 [5] 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 [6]).
+
+3.  Proposed Extensions
+
+    This section describes extensions to RFC 1510bis 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 1510bis 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-DH-PARAMETERS                       102
+        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).  The
+    above encryption types are utilized only within CMS structures
+    within the PKINIT preauthentication fields. Their use within
+    the Kerberos EncryptedData structure is unspecified.
+
+    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 RFC 1510bis.
+    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 [11] (part of LDAPv3 [15]).
+
+    Each component of a DistinguishedName is called a
+    RelativeDistinguishedName, where a RelativeDistinguishedName is a
+    SET OF AttributeTypeAndValue.  RFC 2253 does not specify the order
+    in which to encode the elements of the RelativeDistinguishedName and
+    so to ensure that this encoding is unique, we add the following rule
+    to those specified by RFC 2253:
+     
+	When converting a multi-valued RelativeDistinguishedName
+        to a string, the output consists of the string encodings
+        of each AttributeTypeAndValue, in the same order as
+	specified by the DER encoding.    
+
+    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 MUST be set to KRB_NT-X500-PRINCIPAL.  This new
+    name type is defined in RFC 1510bis as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    For this type, the name-string MUST be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.  When this name type is used, the principal's
+    realm MUST be set to the certificate authority's distinguished
+    name using the X500-RFC2253 realm name format described earlier in
+    this section.
+
+    Note that the same string may be represented using several different
+    ASN.1 data types.  As the result, the reverse conversion from an
+    RFC2253-encoded principal name back to an X.500 name may not be
+    unique and may result in an X.500 name that is not the same as the
+    original X.500 name found in the client certificate.
+
+    RFC 1510bis describes an alternate encoding of an X.500 name into a
+    realm name.  However, as described in RFC 1510bis, the alternate
+    encoding does not guarantee a unique mapping from a
+    DistinguishedName inside a certificate into a realm name and
+    similarly cannot be used to produce a unique principal name.  PKINIT
+    therefore uses an RFC 2253-based name mapping approach, as specified
+    above.
+
+    RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
+
+        PrincipalName ::=   SEQUENCE {
+                        name-type[0]     INTEGER,
+                        name-string[1]   SEQUENCE OF GeneralString
+        }
+
+    The following rules relate to the the matching of PrincipalNames
+    with regard to the PKI name constraints for CAs as laid out in RFC
+    2459 [12].  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 client principal name plus realm name (as specified in
+            RFC 1510bis), 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 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.
+
+            c.  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 is produced from the agreed
+    bit string as follows:
+
+        * Truncate the bit string to the required length.
+        * Apply the specific cryptosystem's random-to-key function.
+
+    Appropriate key constraints for each valid cryptosystem are given
+    in RFC 1510bis.
+
+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 [8] and
+    in [12] are used with PKINIT:
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA 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 [12].
+
+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 [13].
+    Currently, only PKCS#1 v1.5 is specified by CMS [8], 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 [8].
+
+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 1510bis, 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] ContentInfo,
+                                    -- Defined in CMS [8];
+                                    -- SignedData OID is {pkcs7 2}
+                                    -- 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 [8];
+                                    -- 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
+    }
+
+    The type of the ContentInfo in the signedAuthPack is SignedData.
+    Its usage is as follows:
+
+        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 MUST 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.
+
+        4.  When a DH key is being used, the public exponent is provided
+            in the subjectPublicKey field of the SubjectPublicKeyInfo and
+            the DH parameters are supplied as a DomainParameters in the
+            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
+            chosen from the First and Second defined Oakley Groups [The
+            Internet Key Exchange (IKE) RFC-2409], if a server will not
+            accept either of these groups, it will respond with a krb-
+            error of KDC_ERR_KEY_TOO_WEAK.  The accompanying e-data is
+            a SEQUENCE of TypedData that includes type 
+            TD-DH-PARAMETERS (102) whose data-value is DomainParameters
+            with appropriate Diffie-Hellman parameters for the client to
+            use.
+
+        5.  The KDC may wish to use cached Diffie-Hellman parameters
+            (see Section 3.2.2, KDC Response).  To indicate acceptance
+            of cached parameters, the client sends zero in the nonce
+            field of the PKAuthenticator.  Zero is not a valid value
+            for this field under any other circumstances.  If cached
+            parameters are used, the client and the KDC MUST perform
+            key derivation (for the appropriate cryptosystem) on the
+            resulting encryption key, as specified in RFC 1510bis.  (With
+            a zero nonce, message binding is performed using the nonce
+            in the main request, which must be encrypted using the
+            encapsulated reply key.)
+
+    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 RFC 1510bis
+        ctime                   [1] KerberosTime,
+                                    -- for replay prevention as in RFC 1510bis
+        nonce                   [2] INTEGER,
+                                    -- zero only if client will accept
+                                    -- cached DH parameters from KDC;
+                                    -- must be non-zero otherwise
+        pachecksum              [3] Checksum
+                                    -- Checksum over KDC-REQ-BODY
+                                    -- Defined by Kerberos spec;
+				    -- must be unkeyed, e.g. sha1 or rsa-md5
+    }
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+        algorithm                   AlgorithmIdentifier,
+                                    -- dhPublicNumber
+        subjectPublicKey            BIT STRING
+                                    -- for DH, equals
+                                    -- public exponent (INTEGER encoded
+                                    -- as payload of BIT STRING)
+    }   -- as specified by the X.509 recommendation [7]
+
+    AlgorithmIdentifier ::= SEQUENCE {
+        algorithm                   OBJECT IDENTIFIER,
+                                    -- for dhPublicNumber, this is
+                                    -- { iso (1) member-body (2) US (840)
+                                    -- ansi-x942(10046) number-type(2) 1 }
+                                    -- from RFC 2459 [12]
+        parameters                  ANY DEFINED by algorithm OPTIONAL
+                                    -- for dhPublicNumber, this is
+                                    -- DomainParameters
+    }   -- as specified by the X.509 recommendation [7]
+
+    DomainParameters ::= SEQUENCE {
+        p                           INTEGER, -- odd prime, p=jq +1
+        g                           INTEGER, -- generator, g
+        q                           INTEGER, -- factor of p-1
+        j                           INTEGER OPTIONAL, -- subgroup factor
+        validationParms             ValidationParms OPTIONAL
+    }   -- as defined in RFC 2459 [12]
+
+    ValidationParms ::= SEQUENCE {
+        seed                        BIT STRING,
+                                    -- seed for the system parameter
+                                    -- generation process
+        pgenCounter                 INTEGER
+                                    -- integer value output as part
+                                    -- of the of the system parameter
+                                    -- prime generation process
+    }   -- as defined in RFC 2459 [12]
+
+    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 1510bis revisions as a SEQUENCE of TypedData:
+
+    TypedData ::=  SEQUENCE {
+                    data-type      [0] INTEGER,
+                    data-value     [1] OCTET STRING,
+    } -- per Kerberos RFC 1510bis
+
+    where one of the TypedData elements is:
+    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+    data-value = CertificateSet // as specified by CMS [8]
+
+    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 client's certificate chain, if
+    one is provided in the request.  This is done by verifying the
+    certification path against the KDC's policy of legitimate
+    certifiers.
+
+    If the KDC cannot find a trusted client certificate chain within
+    the PA-PK-AS-REQ, then the KDC sends back an error message of type
+    KDC_ERR_CANT_VERIFY_CERTIFICATE.  Certificate chain validation is
+    defined in RFC 2459 [12].  The accompanying e-data for this error
+    code is a SEQUENCE of TypedData that includes 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 TypedData that includes 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.
+
+    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.  The accompanying e-data is a SEQUENCE of
+    TypedData that includes type TD-DH-PARAMETERS (102) whose data-value
+    is DomainParameters with appropriate Diffie-Hellman parameters for
+    the client to retry the request.  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
+    RFC 1510bis.
+
+    Assuming no errors, the KDC replies as per RFC 1510bis, 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
+            as necessary (e.g., as per RFC 2253 for X.500 names).  In
+            this case the realm in the ticket MUST be the name of the
+            certifier that issued the user's certificate.
+
+    Note that a principal name may be carried in the subjectAltName
+    field of a certificate. This name may be mapped to a principal
+    record in a security database based on local policy, for example
+    the subjectAltName 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 [14], 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 mapped
+    according to local policy.  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 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] ContentInfo,
+                            -- Defined in CMS [8] and used only with
+                            -- Diffie-Hellman key exchange (if the
+                            -- client public value was present in the
+                            -- request).
+                            -- SignedData OID is {pkcs7 2}
+                            -- This choice MUST be supported
+                            -- by compliant implementations.
+        encKeyPack         [1] ContentInfo
+                            -- Defined in CMS [8].
+                            -- The temporary key is encrypted
+                            -- using the client public key
+                            -- key.
+                            -- EnvelopedData OID is {pkcs7 3}
+                            -- SignedReplyKeyPack, encrypted
+                            -- with the temporary key, is also
+                            -- included.
+    }
+
+    The type of the ContentInfo in the dhSignedData is SignedData.
+    Its usage is as follows:
+
+        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.
+
+            a.  For example, if the reply key is DES, N=64 bits, where
+                some of the bits are replaced with parity bits, according
+                to FIPS PUB 74.
+
+            b.  As another example, 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.
+
+        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
+            defined below.
+
+            a.  The eContentType field MUST 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).
+
+        4.  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).
+
+        5.  The signerInfos field is a SET that MUST contain at least
+            one member, since it contains the actual signature.
+
+        6.  If the client indicated acceptance of cached Diffie-Hellman
+            parameters from the KDC, and the KDC supports such an option
+            (for performance reasons), the KDC should return a zero in
+            the nonce field and include the expiration time of the
+            parameters in the dhKeyExpiration field.  If this time is
+            exceeded, the client SHOULD NOT use the reply.  If the time
+            is absent, the client SHOULD NOT use the reply and MAY
+            resubmit a request with a non-zero nonce (thus indicating
+            non-acceptance of cached Diffie-Hellman parameters).  As
+            indicated above in Section 3.2.1, Client Request, when the
+            KDC uses cached parameters, the client and the KDC MUST
+            perform key derivation (for the appropriate cryptosystem)
+            on the resulting encryption key, as specified in RFC 1510bis.
+
+    KdcDHKeyInfo ::= SEQUENCE {
+                              -- used only when utilizing Diffie-Hellman
+      subjectPublicKey      [0] BIT STRING,
+                                -- Equals public exponent (g^a mod p)
+                                -- INTEGER encoded as payload of
+                                -- BIT STRING
+      nonce                 [1] INTEGER,
+                                -- Binds response to the request
+                                -- Exception: Set to zero when KDC
+                                -- is using a cached DH value
+      dhKeyExpiration       [2] KerberosTime OPTIONAL
+                                -- Expiration time for KDC's cached
+                                -- DH value
+    }
+
+    The type of the ContentInfo in the encKeyPack is EnvelopedData.  Its
+    usage is as follows:
+
+        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 a 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 MUST 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 MUST 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,
+                                 -- from RFC 1510bis
+                                 -- 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
+    }
+
+
+3.2.2.1. Use of transited Field
+
+    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.
+
+
+3.2.2.2. Kerberos Names in Certificates
+
+    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 MUST contain the principal name of the KDC (defined in
+    RFC 1510bis) 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 MUST be a KerberosName, defined as follows:
+
+        KerberosName ::= SEQUENCE {
+            realm           [0] Realm,
+            principalName   [1] PrincipalName
+        }
+
+    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.
+
+    Note that the KDC's principal name has the instance equal to the
+    realm, and those fields should be appropriately set in the realm
+    and principalName fields of the KerberosName.  This is the case
+    even when obtaining a cross-realm ticket using PKINIT.
+
+
+3.2.3. Client Extraction of Reply
+
+    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 1510bis.
+
+3.2.4. 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 RSA for signatures
+    * SHA1 digest for the Checksum in the PKAuthenticator
+        * using Kerberos checksum type 'sha1'
+    * 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 extends the cross-realm model to the public
+    key infrastructure.  Anyone using PKINIT must be aware of how the
+    certification infrastructure they are linking to works.
+
+    Also, as in standard Kerberos, PKINIT presents the possibility of
+    interactions between different cryptosystems of varying strengths,
+    and this now includes public-key cryptosystems.  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, may be inappropriate.
+
+    Care should be taken in how certificates are choosen for the purposes
+    of authentication using PKINIT. Some local policies require that key
+    escrow be applied for certain certificate types. People deploying
+    PKINIT should be aware of the implications of using certificates that
+    have escrowed keys for the purposes of authentication.
+
+    As described in Section 3.2, PKINIT allows for the caching of the
+    Diffie-Hellman parameters on the KDC side, for performance reasons.
+    For similar reasons, the signed data in this case does not vary from
+    message to message, until the cached parameters expire.  Because of
+    the persistence of these parameters, the client and the KDC are to
+    use the appropriate key derivation measures (as described in RFC
+    1510bis) when using cached DH parameters.
+
+    PKINIT does not provide for a "return routability test" to prevent
+    attackers from mounting a denial of service attack on the KDC by
+    causing it to perform needless expensive cryptographic operations.
+    Strictly speaking, this is also true of base Kerberos, although the
+    potential cost is not as great in base Kerberos, because it does
+    not make use of public key cryptography.
+
+    Lastly, PKINIT calls for randomly generated keys for conventional
+    cryptosystems.  Many such systems contain systematically "weak"
+    keys.  For recommendations regarding these weak keys, see RFC
+    1510bis.
+
+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] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+    Using Public Key Cryptography.  Symposium On Network and Distributed
+    System Security, 1997.
+
+    [4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+    Protocol.  In Proceedings of the USENIX Workshop on Electronic
+    Commerce, July 1995.
+
+    [5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
+    Request for Comments 2246, January 1999.
+
+    [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
+    Distributed Systems.  In Proceedings of the 13th International
+    Conference on Distributed Computing Systems, May 1993.
+
+    [7] ITU-T (formerly CCITT) Information technology - Open Systems
+    Interconnection - The Directory: Authentication Framework
+    Recommendation X.509 ISO/IEC 9594-8
+
+    [8] R. Housley. Cryptographic Message Syntax.
+    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
+    as RFC.
+
+    [9] PKCS #7: Cryptographic Message Syntax Standard,
+    An RSA Laboratories Technical Note Version 1.5
+    Revised November 1, 1993
+
+    [10] 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.
+
+    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+    Protocol (v3): UTF-8 String Representation of Distinguished Names.
+    Request for Comments 2253.
+
+    [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+    Key Infrastructure, Certificate and CRL Profile, January 1999.
+    Request for Comments 2459.
+
+    [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+    Specifications, October 1998.  Request for Comments 2437.
+
+    [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
+    Version 2 Certificate Handling, March 1998.  Request for
+    Comments 2312.
+
+    [15] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
+    Protocol (v3), December 1997.  Request for Comments 2251.
+
+    [16] 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
+
+    [17] 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 March 12, 2002.
+
+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
+    Microsoft Corporation
+    One Microsoft Way
+    Redmond WA 98052
+    Phone: +1 425 707 3336
+    E-mail: matthur@microsoft.com
+
+    Ari Medvinsky
+    Liberate Technologies
+    2 Circle Star Way
+    San Carlos CA 94070
+    E-mail: ari@liberate.com
+
+    Sasha Medvinsky
+    Motorola, Inc.
+    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
+    E-mail: jtrostle@world.std.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt
new file mode 100644
index 00000000000..174d0502f80
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt
@@ -0,0 +1,805 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-17.txt                   Clifford Neuman
+Updates: RFC 1510bis                                             USC/ISI
+expires May 31, 2004                                         Matthew Hur
+                                                           Ari Medvinsky
+                                                   Microsoft Corporation
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+
+    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 provision 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
+
+The distribution of this memo is unlimited.  It is filed as
+draft-ietf-cat-kerberos-pk-init-17.txt and expires May 31, 2004.
+Please send comments to the authors.
+
+
+1.  Abstract
+
+This draft describes protocol extensions (hereafter called PKINIT)
+to the Kerberos protocol specification (RFC 1510bis [1]).  These
+extensions provide a method for integrating public key cryptography
+into the initial authentication exchange, by passing cryptographic
+certificates and associated authenticators in preauthentication data
+fields.
+
+
+2.  Introduction
+
+A client typically authenticates itself to a service in Kerberos
+using three distinct though related exchanges.  First, the client
+requests a ticket-granting ticket (TGT) from the Kerberos
+authentication server (AS).  Then, it uses the TGT to request a
+service ticket from the Kerberos ticket-granting server (TGS).
+Usually, the AS and TGS are integrated in a single device known as
+a Kerberos Key Distribution Center, or KDC.  (In this draft, we will
+refer to both the AS and the TGS as the KDC.) Finally, the client
+uses the service ticket to authenticate itself to the service.
+
+The advantage afforded by the TGT is that the user need only
+explicitly request a ticket and expose his credentials once.  The
+TGT and its associated session key can then be used for any
+subsequent requests.  One implication of this is that all further
+authentication is independent of the method by which the initial
+authentication was performed.  Consequently, initial authentication
+provides a convenient place to integrate public-key cryptography
+into Kerberos authentication.
+
+As defined, Kerberos authentication exchanges use symmetric-key
+cryptography, in part for performance.  (Symmetric-key cryptography
+is typically 10-100 times faster than public-key cryptography,
+depending on the public-key operations. [c])  One cost of using
+symmetric-key cryptography is that the keys must be shared, so that
+before a user can authentication himself, he must already be
+registered with the KDC.
+
+Conversely, public-key cryptography--in conjunction with an
+established certification infrastructure--permits authentication
+without prior registration.  Adding it to Kerberos allows the
+widespread use of Kerberized applications by users without requiring
+them to register first--a requirement that has no inherent security
+benefit.
+
+As noted above, a convenient and efficient place to introduce
+public-key cryptography into Kerberos is in the initial
+authentication exchange.  This document describes the methods and
+data formats for integrating public-key cryptography into Kerberos
+initial authentication.  Another document (PKCROSS) describes a
+similar protocol for Kerberos cross-realm authentication.
+
+
+3.  Extensions
+
+This section describes extensions to RFC 1510bis for supporting the
+use of public-key cryptography in the initial request for a ticket
+granting ticket (TGT).
+
+Briefly, the following changes to RFC 1510bis are proposed:
+
+    1.  If public-key authentication is indicated, the client sends
+        the user's public-key data and an authenticator in a
+        preauthentication field accompanying the usual request.
+        This authenticator is signed by the user's private
+        signature key.
+
+    2.  The KDC verifies the client's request against its own
+        policy and certification authorities.
+
+    3.  If the request passes the verification tests, the KDC
+        replies as usual, but the reply is encrypted using either:
+
+        a.  a randomly generated key, signed using the KDC's
+            signature key and encrypted using the user's encryption
+            key; or
+
+        b.  a key generated through a Diffie-Hellman exchange with
+            the client, signed using the KDC's signature key.
+
+        Any key data required by the client to obtain the encryption
+        key is returned in a preauthentication field accompanying
+        the usual reply.
+
+    4.  The client obtains the encryption key, decrypts the reply,
+        and then proceeds as usual.
+
+Section 3.1 of this document defines the necessary message formats.
+Section 3.2 describes their syntax and use in greater detail.
+Implementation of all specified formats and uses in these sections
+is REQUIRED for compliance with PKINIT.
+
+
+3.1.  Definitions
+
+
+3.1.1.  Required Algorithms
+
+[What is the current list of required algorithm? --brian]
+
+
+3.1.2.  Defined Message and Encryption Types
+
+PKINIT makes use of the following new preauthentication types:
+
+    PA-PK-AS-REQ                             TBD
+    PA-PK-AS-REP                             TBD
+
+PKINIT introduces the following new error 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_CLIENT_NAME_MISMATCH              75
+
+PKINIT uses the following typed data types for errors:
+
+    TD-DH-PARAMETERS                         102
+    TD-TRUSTED-CERTIFIERS                    104
+    TD-CERTIFICATE-INDEX                     105
+
+PKINIT defines the following encryption types, for use in the AS-REQ
+message (to indicate acceptance of the corresponding encryption OIDs
+in PKINIT):
+
+    dsaWithSHA1-CmsOID                         9
+    md5WithRSAEncryption-CmsOID               10
+    sha1WithRSAEncryption-CmsOID              11
+    rc2CBC-EnvOID                             12
+    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+    rsaES-OAEP-ENV-OID     (PKCS1 v2.0)       14
+    des-ede3-cbc-Env-OID                      15
+
+The above encryption types are used (in PKINIT) only within CMS [8]
+structures within the PKINIT preauthentication fields.  Their use
+within Kerberos EncryptedData structures is unspecified.
+
+
+3.1.3.  Algorithm Identifiers
+
+PKINIT does not define, but does make use of, the following
+algorithm identifiers.
+
+PKINIT uses the following algorithm identifier for Diffie-Hellman
+key agreement [11]:
+
+    dhpublicnumber
+
+PKINIT uses the following signature algorithm identifiers [8, 12]:
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA with SHA1)
+
+PKINIT uses the following encryption algorithm identifiers [12] for
+encrypting the temporary key with a public key:
+
+    rsaEncryption          (PKCS1 v1.5)
+    id-RSAES-OAEP          (PKCS1 v2.0)
+
+These OIDs are not to be confused with the encryption types listed
+above.
+
+PKINIT uses the following algorithm identifiers [8] for encrypting
+the reply key with the temporary key:
+
+    des-ede3-cbc           (three-key 3DES, CBC mode)
+    rc2-cbc                (RC2, CBC mode)
+
+Again, these OIDs are not to be confused with the encryption types
+listed above.
+
+
+3.2.  PKINIT Preauthentication Syntax and Use
+
+In this section, we describe the syntax and use of the various
+preauthentication fields employed to implement PKINIT.
+
+
+3.2.1.  Client Request
+
+The initial authentication request (AS-REQ) is sent as per RFC
+1510bis, except that a preauthentication field containing data
+signed by the user's private signature key accompanies the request,
+as follows:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                    -- PAType TBD
+        signedAuthPack          [0] ContentInfo,
+                                    -- Defined in CMS.
+                                    -- Type is SignedData.
+                                    -- Content is AuthPack
+                                    -- (defined below).
+        trustedCertifiers       [1] SEQUENCE OF TrustedCAs OPTIONAL,
+                                    -- A list of CAs, trusted by
+                                    -- the client, used to certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
+                                    -- Defined in CMS.
+                                    -- Identifies a particular KDC
+                                    -- certificate, if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
+                                    -- May identify the user's
+                                    -- Diffie-Hellman certificate,
+                                    -- or an RSA encryption key
+                                    -- certificate.
+        ...
+    }
+
+    TrustedCAs ::= CHOICE {
+        caName                  [0] Name,
+                                    -- Fully qualified X.500 name
+                                    -- as defined in X.509 [11].
+        issuerAndSerial         [1] IssuerAndSerialNumber,
+                                    -- Identifies a specific CA
+                                    -- certificate, if the client
+                                    -- only trusts one.
+        ...
+    }
+
+[Should we even allow principalName as a choice? --brian]
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- Defined in X.509,
+                                    -- reproduced below.
+                                    -- Present only if the client
+                                    -- is using ephemeral-ephemeral
+                                    -- Diffie-Hellman.
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+        ctime                   [1] KerberosTime,
+                                    -- cusec and ctime are used as
+                                    -- in RFC 1510bis, for replay
+                                    -- prevention.
+        nonce                   [2] INTEGER,
+                                    -- Binds reply to request,
+                                    -- except is zero when client
+                                    -- will accept cached
+                                    -- Diffie-Hellman parameters
+                                    -- from KDC and MUST NOT be
+                                    -- zero otherwise.
+        paChecksum              [3] Checksum,
+                                    -- Defined in RFC 1510bis.
+                                    -- Performed over KDC-REQ-BODY,
+                                    -- must be unkeyed.
+        ...
+    }
+
+    SubjectPublicKeyInfo ::= SEQUENCE {
+                                    -- As defined in X.509.
+        algorithm                   AlgorithmIdentifier,
+                                    -- Equals dhpublicnumber (see
+                                    -- AlgorithmIdentifier, below)
+                                    -- for PKINIT.
+        subjectPublicKey            BIT STRING
+                                    -- Equals public exponent
+                                    -- (INTEGER encoded as payload
+                                    -- of BIT STRING) for PKINIT.
+    }
+
+    AlgorithmIdentifier ::= SEQUENCE {
+                                    -- As defined in X.509.
+        algorithm                   OBJECT IDENTIFIER,
+                                    -- dhpublicnumber is
+                                    -- { iso (1) member-body (2)
+                                    -- US (840) ansi-x942 (10046)
+                                    -- number-type (2) 1 }
+                                    -- From RFC 2459 [11].
+        parameters                  ANY DEFINED BY algorithm OPTIONAL
+                                    -- Content is DomainParameters
+                                    -- (see below) for PKINIT.
+    }
+
+    DomainParameters ::= SEQUENCE {
+                                    -- As defined in RFC 2459.
+        p                           INTEGER,
+                                    -- p is the odd prime, equals
+                                    -- jq+1.
+        g                           INTEGER,
+                                    -- Generator.
+        q                           INTEGER,
+                                    -- Divides p-1.
+        j                           INTEGER OPTIONAL,
+                                    -- Subgroup factor.
+        validationParms             ValidationParms OPTIONAL
+    }
+
+    ValidationParms ::= SEQUENCE {
+                                    -- As defined in RFC 2459.
+        seed                        BIT STRING,
+                                    -- Seed for the system parameter
+                                    -- generation process.
+        pgenCounter                 INTEGER
+                                    -- Integer value output as part
+                                    -- of the system parameter
+                                    -- generation process.
+    }
+
+The ContentInfo in the signedAuthPack is filled out as follows:
+
+    1.  The eContent field contains data of type AuthPack.  It MUST
+        contain the pkAuthenticator, and MAY also contain the
+        user's Diffie-Hellman public value (clientPublicValue).
+
+    2.  The eContentType field MUST contain the OID value for
+        pkauthdata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
+
+    3.  The signerInfos field MUST contain the signature of the
+        AuthPack.
+
+    4.  The certificates field MUST contain at least a signature
+        verification certificate chain that the KDC can use to
+        verify the signature on the AuthPack.  Additionally, the
+        client may also insert an encryption certificate chain, if
+        (for example) the client is not using ephemeral-ephemeral
+        Diffie-Hellman.
+
+    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
+        be chosen from the First or Second defined Oakley Groups.
+        (See RFC 2409 [c].)
+
+    6.  The KDC may wish to use cached Diffie-Hellman parameters.
+        To indicate acceptance of caching, the client sends zero in
+        the nonce field of the pkAuthenticator.  Zero is not a valid
+        value for this field under any other circumstances.  Since
+        zero is used to indicate acceptance of cached parameters,
+        message binding in this case is performed instead using the
+        nonce in the main request.
+
+
+3.2.2.  Validation of Client Request
+
+Upon receiving the client's request, the KDC validates it.  This
+section describes the steps that the KDC MUST (unless otherwise
+noted) take in validating the request.
+
+The KDC must look for a user certificate in the signedAuthPack.
+If it cannot find one signed by a CA it trusts, it sends back an
+error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
+e-data for this error is a SEQUENCE OF TypedData:
+
+    TypedData ::= SEQUENCE {
+                                    -- As defined in RFC 1510bis.
+        data-type               [0] INTEGER,
+        data-value              [1] OCTET STRING
+    }
+
+For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
+data-value is an OCTET STRING containing the DER encoding of
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+If, while verifying the certificate chain, the KDC determines that
+the signature on one of the certificates in the signedAuthPack is
+invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+The accompanying e-data for this error is a SEQUENCE OF TypedData,
+whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
+OCTET STRING containing the DER encoding of the index into the
+CertificateSet field, ordered as sent by the client:
+
+    CertificateIndex ::= INTEGER
+                                    -- 0 = first certificate (in
+                                    --     order of encoding),
+                                    -- 1 = second certificate, etc.
+
+If more than one signature is invalid, the KDC sends one TypedData
+per invalid signature.
+
+The KDC MAY also check whether any of the certificates in the user's
+chain have been revoked.  If any of them have been revoked, the KDC
+returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
+attempts to determine the revocation status but is unable to do so,
+it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.  In
+either case, the certificate or certificates affected are identified
+exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see
+above).
+
+If the certificate chain is successfully validated, but the name in
+the user's certificate does not match the name given in the request,
+the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.  There
+is no accompanying e-data for this error.
+
+Even if the chain is validated, and the names in the certificate and
+the request match, the KDC may decide not to trust the client.  For
+example, the certificate may include (or not include) an Enhanced
+Key Usage (EKU) OID in the extensions field.  As a matter of local
+policy, the KDC may decide to reject requests on the basis of the
+absence or presence of specific EKU OIDs.  In this case, the KDC
+returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED.  For the
+benefit of implementors, we define a PKINIT EKU OID as follows:
+{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
+pkinit (3) pkekuoid (2) }.
+
+If the certificate chain and usage check out, but the client's
+signature on the signedAuthPack fails to verify, the KDC returns an
+error of type KDC_ERR_INVALID_SIG.  There is no accompanying e-data
+for this error.
+
+[What about the case when all this checks out but one or more
+certificates is rejected for other reasons?  For example, perhaps
+the key is too short for local policy. --DRE]
+
+The KDC must check the timestamp to ensure that the request is not
+a replay, and that the time skew falls within acceptable limits.  If
+the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT
+or KRB_AP_ERR_SKEW, respectively.
+
+Finally, if the clientPublicValue is filled in, indicating that the
+client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
+checks to see if the parameters satisfy its policy.  If they do not,
+it returns an error of type KDC_ERR_KEY_TOO_WEAK.  The accompanying
+e-data is a SEQUENCE OF TypedData, whose data-type is
+TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
+the DER encoding of a DomainParameters (see above), including
+appropriate Diffie-Hellman parameters with which to retry the
+request.
+
+[This makes no sense.  For example, maybe the key is too strong for
+local policy. --DRE]
+
+In order to establish authenticity of the reply, the KDC will sign
+some key data (either the random key used to encrypt the reply in
+the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
+generate the reply-encrypting key in the case of a ReplyKeyPack).
+The signature certificate to be used is to be selected as follows:
+
+    1.  If the client included a kdcCert field in the PA-PK-AS-REQ,
+        use the referred-to certificate, if the KDC has it.  If it
+        does not, the KDC returns an error of type
+        KDC_ERR_CERTIFICATE_MISMATCH.
+       
+    2.  Otherwise, if the client did not include a kdcCert field,
+        but did include a trustedCertifiers field, and the KDC
+        possesses a certificate issued by one of the listed
+        certifiers, use that certificate.  if it does not possess
+        one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+    3.  Otherwise, if the client included neither a kdcCert field
+        nor a trustedCertifiers field, and the KDC has only one
+        signature certificate, use that certificate.  If it has
+        more than one certificate, it returns an error of type
+        KDC_ERR_CERTIFICATE_MISMATCH.
+
+
+3.2.3.  KDC Reply
+
+Assuming that the client's request has been properly validated, the
+KDC proceeds as per RFC 1510bis, except as follows.
+
+The user's name as represented in the AS-REP must be derived from
+the certificate provided in the client's request.  If the KDC has
+its own mapping from the name in the certificate to a Kerberos name,
+it uses that Kerberos name.
+
+Otherwise, if the certificate contains a subjectAltName extension
+with PrincipalName, it uses that name.  In this case, the realm in
+the ticket is that of the local realm (or some other realm name
+chosen by that realm).  (OID and syntax for this extension to be
+specified here.)  Otherwise, the KDC returns an error of type
+KDC_ERR_CLIENT_NAME_MISMATCH.
+
+In addition, the certifiers in the certification path of the user's
+certificate MUST be added to an authdata (to be specified at a later
+time).
+
+The AS-REP is otherwise unchanged from RFC 1510bis.  The KDC then
+encrypts the reply as usual, but not with the user's long-term key.
+Instead, it encrypts it with either a random encryption key, or a
+key derived through a Diffie-Hellman exchange.  Which is the case is
+indicated by the contents of the PA-PK-AS-REP (note tags):
+
+    PA-PK-AS-REP ::= CHOICE {
+                                    -- PAType YY (TBD)
+        dhSignedData            [0] ContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is KDCDHKeyInfo
+                                    -- (defined below).
+        encKeyPack              [1] ContentInfo,
+                                    -- Type is EnvelopedData.
+                                    -- Content is ReplyKeyPack
+                                    -- (defined below).
+        ...
+    }
+
+Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
+encKeyPack, but not both.  The former contains data of type
+KDCDHKeyInfo, and is used only when the reply is encrypted using a
+Diffie-Hellman derived key:
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+                                    -- Equals public exponent
+                                    -- (g^a mod p).
+                                    -- INTEGER encoded as payload
+                                    -- of BIT STRING.
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+                                    -- Exception: A value of zero
+                                    -- indicates that the KDC is
+                                    -- using cached values.
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                                    -- Expiration time for KDC's
+                                    -- cached values.
+        ...
+    }
+
+The fields of the ContentInfo for dhSignedData are to be filled in
+as follows:
+
+    1.  The eContent field contains data of type KDCDHKeyInfo.
+
+    2.  The eContentType field contains the OID value for
+        pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the KDCDHKeyInfo.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client may use to verify the
+        KDC's signature over the KDCDHKeyInfo.)  It may only be left
+        empty if the client did not include a trustedCertifiers
+        field in the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.
+
+    5.  If the client and KDC agree to use cached parameters, the
+        KDC SHOULD return a zero in the nonce field and include the
+        expiration time of the cached values in the dhKeyExpiration
+        field.  If this time is exceeded, the client SHOULD NOT use
+        the reply.  If the time is absent, the client SHOULD NOT use
+        the reply and MAY resubmit a request with a non-zero nonce,
+        thus indicating non-acceptance of the cached parameters.
+
+The key is derived as follows: Both the KDC and the client calculate
+the value g^(ab) mod p, where a and b are the client and KDC's
+private exponents, respectively.  They both take the first N bits of
+this secret value and convert it into a reply key, where N depends
+on the key type.
+
+    1.  For example, if the key type is DES, N = 64 bits, where some
+        of the bits are replaced with parity bits, according to FIPS
+        PUB 74 [c].
+
+    2.  If the key type is (three-key) 3DES, N = 192 bits, where
+        some of the bits are replaced with parity bits, again
+        according to FIPS PUB 74.
+
+If the KDC and client are not using Diffie-Hellman, the KDC encrypts
+the reply with an encryption key, packed in the encKeyPack, which
+contains data of type ReplyKeyPack:
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- Defined in RFC 1510bis.
+                                    -- Used to encrypt main reply.
+                                    -- MUST be at least as strong as
+                                    -- enctype of session key.
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+        ...
+    }
+
+[What exactly does "at least as strong" mean? --DRE]
+
+The fields of the ContentInfo for encKeyPack MUST be filled in as
+follows:
+
+    1.  The innermost data is of type SignedData.  The eContent for
+        this data is of type ReplyKeyPack.
+
+    2.  The eContentType for this data contains the OID value for
+        pkrkeydata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the ReplyKeyPack.
+
+    4.  The certificates field contains a signature verification
+        certificate chain, which the client may use to verify the
+        KDC's signature over the ReplyKeyPack.)  It may only be left
+        empty if the client did not include a trustedCertifiers
+        field in the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.
+
+    5.  The outer data is of type EnvelopedData.  The
+        encryptedContent for this data is the SignedData described
+        in items 1 through 4, above.
+
+    6.  The encryptedContentType for this data contains the OID
+        value for id-signedData: { iso (1) member-body (2) us (840)
+        rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
+
+    7.  The recipientInfos field is a SET which MUST contain exactly
+        one member of type KeyTransRecipientInfo.  The encryptedKey
+        for this member contains the temporary key which is
+        encrypted using the client's public key.
+
+    8.  Neither the unprotectedAttrs field nor the originatorInfo
+        field is required for PKINIT.
+
+
+3.2.4.  Validation of KDC Reply
+
+Upon receipt of the KDC's reply, the client proceeds as follows.  If
+the PA-PK-AS-REP contains a dhSignedData, the client obtains and
+verifies the Diffie-Hellman parameters, and obtains the shared key
+as described above.  Otherwise, the message contains an encKeyPack,
+and the client decrypts and verifies the temporary encryption key.
+In either case, the client then decrypts the main reply with the
+resulting key, and then proceeds as described in RFC 1510bis.
+
+
+4.  Security Considerations
+
+PKINIT raises certain security considerations beyond those that can
+be regulated strictly in protocol definitions.  We will address them
+in this section.
+
+PKINIT extends the cross-realm model to the public-key
+infrastructure.  Anyone using PKINIT must be aware of how the
+certification infrastructure they are linking to works.
+
+Also, as in standard Kerberos, PKINIT presents the possibility of
+interactions between cryptosystems of varying strengths, and this
+now includes public-key cryptosystems.  Many systems, for example,
+allow the use of 512-bit public keys.  Using such keys to wrap data
+encrypted under strong conventional cryptosystems, such as 3DES, may
+be inappropriate.
+
+PKINIT calls for randomly generated keys for conventional
+cryptosystems.  Many such systems contain systematically "weak"
+keys.  For recommendations regarding these weak keys, see RFC
+1510bis.
+
+Care should be taken in how certificates are chosen for the purposes
+of authentication using PKINIT.  Some local policies may require
+that key escrow be applied for certain certificate types.  People
+deploying PKINIT should be aware of the implications of using
+certificates that have escrowed keys for the purposes of
+authentication.
+
+PKINIT does not provide for a "return routability" test to prevent
+attackers from mounting a denial-of-service attack on the KDC by
+causing it to perform unnecessary and expensive public-key
+operations.  Strictly speaking, this is also true of standard
+Kerberos, although the potential cost is not as great, because
+standard Kerberos does not make use of public-key cryptography.
+
+
+5.  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.
+
+
+6.  Expiration Date
+
+This draft expires May 31, 2004.
+
+
+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] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+Using Public Key Cryptography.  Symposium On Network and Distributed
+System Security, 1997.
+
+[4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+Protocol.  In Proceedings of the USENIX Workshop on Electronic
+Commerce, July 1995.
+
+[5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0.  Request
+for Comments 2246, January 1999.
+
+[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
+Distributed Systems.  In Proceedings of the 13th International
+Conference on Distributed Computing Systems, May 1993.
+
+[7] ITU-T (formerly CCITT) Information technology - Open Systems
+Interconnection - The Directory: Authentication Framework
+Recommendation X.509 ISO/IEC 9594-8
+
+[8] R. Housley. Cryptographic Message Syntax.
+draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
+RFC.
+
+[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
+Laboratories Technical Note Version 1.5. Revised November 1, 1993
+
+[10] 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.
+
+[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+Key Infrastructure, Certificate and CRL Profile, January 1999.
+Request for Comments 2459.
+
+[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+Specifications, October 1998.  Request for Comments 2437.
+
+[13] 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
+
+[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
+Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
+
+
+8.  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
+Ari Medvinsky
+Microsoft Corporation
+One Microsoft Way
+Redmond WA 98052
+Phone: +1 425 707 3336
+E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
+
+Sasha Medvinsky
+Motorola, Inc.
+6450 Sequence Drive
+San Diego, CA 92121
++1 858 404 2367
+E-mail: smedvinsky@motorola.com
+
+John Wray
+Iris Associates, Inc.
+5 Technology Park Dr.
+Westford, MA 01886
+E-mail: John_Wray@iris.com
+
+Jonathan Trostle
+E-mail: jtrostle@world.std.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt
new file mode 100644
index 00000000000..f3c795f282b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt
@@ -0,0 +1,893 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-18.txt                   Clifford Neuman
+Updates: RFC 1510bis                                             USC/ISI
+expires August 20, 2004                                      Matthew Hur
+                                                           Ari Medvinsky
+                                                   Microsoft Corporation
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+
+    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 provision 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
+
+The distribution of this memo is unlimited.  It is filed as
+draft-ietf-cat-kerberos-pk-init-18.txt and expires August 20, 2004.
+Please send comments to the authors.
+
+
+1.  Abstract
+
+This draft describes protocol extensions (hereafter called PKINIT)
+to the Kerberos protocol specification (RFC 1510bis [1]).  These
+extensions provide a method for integrating public key cryptography
+into the initial authentication exchange, by passing cryptographic
+certificates and associated authenticators in preauthentication data
+fields.
+
+
+2.  Introduction
+
+A client typically authenticates itself to a service in Kerberos
+using three distinct though related exchanges.  First, the client
+requests a ticket-granting ticket (TGT) from the Kerberos
+authentication server (AS).  Then, it uses the TGT to request a
+service ticket from the Kerberos ticket-granting server (TGS).
+Usually, the AS and TGS are integrated in a single device known as
+a Kerberos Key Distribution Center, or KDC.  (In this draft, we will
+refer to both the AS and the TGS as the KDC.) Finally, the client
+uses the service ticket to authenticate itself to the service.
+
+The advantage afforded by the TGT is that the user need only
+explicitly request a ticket and expose his credentials once.  The
+TGT and its associated session key can then be used for any
+subsequent requests.  One implication of this is that all further
+authentication is independent of the method by which the initial
+authentication was performed.  Consequently, initial authentication
+provides a convenient place to integrate public-key cryptography
+into Kerberos authentication.
+
+As defined, Kerberos authentication exchanges use symmetric-key
+cryptography, in part for performance.  (Symmetric-key cryptography
+is typically 10-100 times faster than public-key cryptography,
+depending on the public-key operations. [cite])  One cost of using
+symmetric-key cryptography is that the keys must be shared, so that
+before a user can authentication himself, he must already be
+registered with the KDC.
+
+Conversely, public-key cryptography--in conjunction with an
+established certification infrastructure--permits authentication
+without prior registration.  Adding it to Kerberos allows the
+widespread use of Kerberized applications by users without requiring
+them to register first--a requirement that has no inherent security
+benefit.
+
+As noted above, a convenient and efficient place to introduce
+public-key cryptography into Kerberos is in the initial
+authentication exchange.  This document describes the methods and
+data formats for integrating public-key cryptography into Kerberos
+initial authentication.  Another document (PKCROSS) describes a
+similar protocol for Kerberos cross-realm authentication.
+
+
+3.  Extensions
+
+This section describes extensions to RFC 1510bis for supporting the
+use of public-key cryptography in the initial request for a ticket
+granting ticket (TGT).
+
+Briefly, the following changes to RFC 1510bis are proposed:
+
+    1.  If public-key authentication is indicated, the client sends
+        the user's public-key data and an authenticator in a
+        preauthentication field accompanying the usual request.
+        This authenticator is signed by the user's private
+        signature key.
+
+    2.  The KDC verifies the client's request against its own
+        policy and certification authorities.
+
+    3.  If the request passes the verification tests, the KDC
+        replies as usual, but the reply is encrypted using either:
+
+        a.  a randomly generated key, signed using the KDC's
+            signature key and encrypted using the user's encryption
+            key; or
+
+        b.  a key generated through a Diffie-Hellman exchange with
+            the client, signed using the KDC's signature key.
+
+        Any key data required by the client to obtain the encryption
+        key is returned in a preauthentication field accompanying
+        the usual reply.
+
+    4.  The client obtains the encryption key, decrypts the reply,
+        and then proceeds as usual.
+
+Section 3.1 of this document defines the necessary message formats.
+Section 3.2 describes their syntax and use in greater detail.
+Implementation of all specified formats and uses in these sections
+is REQUIRED for compliance with PKINIT.
+
+
+3.1.  Definitions
+
+
+3.1.1.  Required Algorithms
+
+At minimum, PKINIT must be able to use the following algorithms:
+
+    Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype
+      (as required by clarifications).
+    Signature algorithm: SHA-1 digest and RSA.
+    Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
+      with a non-zero nonce.
+    Unkeyed checksum type for the paChecksum member of
+      PKAuthenticator: SHA1 (unkeyed).
+
+
+3.1.2.  Defined Message and Encryption Types
+
+PKINIT makes use of the following new preauthentication types:
+
+    PA-PK-AS-REQ                             TBD
+    PA-PK-AS-REP                             TBD
+    PA-PK-OCSP-REQ                           TBD
+    PA-PK-OCSP-REP                           TBD
+
+PKINIT also makes use of the following new authorization data type:
+
+    AD-INITIAL-VERIFIED-CAS                  TBD
+
+PKINIT introduces the following new error 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_CLIENT_NAME_MISMATCH              75
+
+PKINIT uses the following typed data types for errors:
+
+    TD-DH-PARAMETERS                         102
+    TD-TRUSTED-CERTIFIERS                    104
+    TD-CERTIFICATE-INDEX                     105
+
+PKINIT defines the following encryption types, for use in the AS-REQ
+message (to indicate acceptance of the corresponding encryption OIDs
+in PKINIT):
+
+    dsaWithSHA1-CmsOID                         9
+    md5WithRSAEncryption-CmsOID               10
+    sha1WithRSAEncryption-CmsOID              11
+    rc2CBC-EnvOID                             12
+    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+    rsaES-OAEP-ENV-OID     (PKCS1 v2.0)       14
+    des-ede3-cbc-Env-OID                      15
+
+The above encryption types are used (in PKINIT) only within CMS [8]
+structures within the PKINIT preauthentication fields.  Their use
+within Kerberos EncryptedData structures is unspecified.
+
+
+3.1.3.  Algorithm Identifiers
+
+PKINIT does not define, but does make use of, the following
+algorithm identifiers.
+
+PKINIT uses the following algorithm identifier for Diffie-Hellman
+key agreement [11]:
+
+    dhpublicnumber
+
+PKINIT uses the following signature algorithm identifiers [8, 12]:
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA with SHA1)
+
+PKINIT uses the following encryption algorithm identifiers [12] for
+encrypting the temporary key with a public key:
+
+    rsaEncryption          (PKCS1 v1.5)
+    id-RSAES-OAEP          (PKCS1 v2.0)
+
+These OIDs are not to be confused with the encryption types listed
+above.
+
+PKINIT uses the following algorithm identifiers [8] for encrypting
+the reply key with the temporary key:
+
+    des-ede3-cbc           (three-key 3DES, CBC mode)
+    rc2-cbc                (RC2, CBC mode)
+
+Again, these OIDs are not to be confused with the encryption types
+listed above.
+
+
+3.2.  PKINIT Preauthentication Syntax and Use
+
+In this section, we describe the syntax and use of the various
+preauthentication fields employed to implement PKINIT.
+
+
+3.2.1.  Client Request
+
+The initial authentication request (AS-REQ) is sent as per RFC
+1510bis, except that a preauthentication field containing data
+signed by the user's private signature key accompanies the request,
+as follows:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+                                    -- PAType TBD
+        signedAuthPack          [0] ContentInfo,
+                                    -- Defined in CMS.
+                                    -- Type is SignedData.
+                                    -- Content is AuthPack
+                                    -- (defined below).
+        trustedCertifiers       [1] SEQUENCE OF TrustedCAs OPTIONAL,
+                                    -- A list of CAs, trusted by
+                                    -- the client, used to certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
+                                    -- Defined in CMS.
+                                    -- Identifies a particular KDC
+                                    -- certificate, if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
+                                    -- May identify the user's
+                                    -- Diffie-Hellman certificate,
+                                    -- or an RSA encryption key
+                                    -- certificate.
+        ...
+    }
+
+    TrustedCAs ::= CHOICE {
+        caName                  [0] Name,
+                                    -- Fully qualified X.500 name
+                                    -- as defined in X.509 [11].
+        issuerAndSerial         [1] IssuerAndSerialNumber,
+                                    -- Identifies a specific CA
+                                    -- certificate, if the client
+                                    -- only trusts one.
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- Defined in X.509,
+                                    -- reproduced below.
+                                    -- Present only if the client
+                                    -- is using ephemeral-ephemeral
+                                    -- Diffie-Hellman.
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+        ctime                   [1] KerberosTime,
+                                    -- cusec and ctime are used as
+                                    -- in RFC 1510bis, for replay
+                                    -- prevention.
+        nonce                   [2] INTEGER,
+                                    -- Binds reply to request,
+                                    -- except is zero when client
+                                    -- will accept cached
+                                    -- Diffie-Hellman parameters
+                                    -- from KDC and MUST NOT be
+                                    -- zero otherwise.
+                                    -- MUST be < 2^32.
+        paChecksum              [3] Checksum,
+                                    -- Defined in [15].
+                                    -- Performed over KDC-REQ-BODY,
+                                    -- must be unkeyed.
+        ...
+    }
+
+    IMPORTS
+        -- from X.509
+        SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters,
+          ValidationParms
+            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+              dod (6) internet (1) security (5) mechanisms (5)
+              pkix (7) id-mod (0) id-pkix1-explicit-88 (1) }
+
+The ContentInfo in the signedAuthPack is filled out as follows:
+
+    1.  The eContent field contains data of type AuthPack.  It MUST
+        contain the pkAuthenticator, and MAY also contain the
+        user's Diffie-Hellman public value (clientPublicValue).
+
+    2.  The eContentType field MUST contain the OID value for
+        pkauthdata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
+
+    3.  The signerInfos field MUST contain the signature of the
+        AuthPack.
+
+    4.  The certificates field MUST contain at least a signature
+        verification certificate chain that the KDC can use to
+        verify the signature on the AuthPack.  Additionally, the
+        client may also insert an encryption certificate chain, if
+        (for example) the client is not using ephemeral-ephemeral
+        Diffie-Hellman.
+
+    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
+        be chosen from the First or Second defined Oakley Groups.
+        (See RFC 2409 [c].)
+
+    6.  The KDC may wish to use cached Diffie-Hellman parameters.
+        To indicate acceptance of caching, the client sends zero in
+        the nonce field of the pkAuthenticator.  Zero is not a valid
+        value for this field under any other circumstances.  Since
+        zero is used to indicate acceptance of cached parameters,
+        message binding in this case is performed instead using the
+        nonce in the main request.
+
+
+3.2.2.  Validation of Client Request
+
+Upon receiving the client's request, the KDC validates it.  This
+section describes the steps that the KDC MUST (unless otherwise
+noted) take in validating the request.
+
+The KDC must look for a user certificate in the signedAuthPack.
+If it cannot find one signed by a CA it trusts, it sends back an
+error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
+e-data for this error is a SEQUENCE OF TypedData:
+
+    TypedData ::= SEQUENCE {
+                                    -- As defined in RFC 1510bis.
+        data-type               [0] INTEGER,
+        data-value              [1] OCTET STRING
+    }
+
+For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
+data-value is an OCTET STRING containing the DER encoding of
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+If, while verifying the certificate chain, the KDC determines that
+the signature on one of the certificates in the signedAuthPack is
+invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+The accompanying e-data for this error is a SEQUENCE OF TypedData,
+whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
+OCTET STRING containing the DER encoding of the index into the
+CertificateSet field, ordered as sent by the client:
+
+    CertificateIndex ::= INTEGER
+                                    -- 0 = first certificate (in
+                                    --     order of encoding),
+                                    -- 1 = second certificate, etc.
+
+If more than one signature is invalid, the KDC sends one TypedData
+per invalid signature.
+
+The KDC MAY also check whether any of the certificates in the user's
+chain have been revoked.  If any of them have been revoked, the KDC
+returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
+attempts to determine the revocation status but is unable to do so,
+it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
+The certificate or certificates affected are identified exactly as
+for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
+
+If the certificate chain is successfully validated, but the user's
+certificate is not authorized to the client's principal name in the
+AS-REQ (when present), the KDC MUST return an error of type
+KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+this error.
+
+Even if the chain is validated, and the names in the certificate and
+the request match, the KDC may decide not to trust the client.  For
+example, the certificate may include (or not include) an Enhanced
+Key Usage (EKU) OID in the extensions field.  As a matter of local
+policy, the KDC may decide to reject requests on the basis of the
+absence or presence of specific EKU OIDs.  In this case, the KDC
+returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED.  For the
+benefit of implementors, we define a PKINIT EKU OID as follows:
+{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
+pkinit (3) pkekuoid (4) }.
+
+If the certificate chain and usage check out, but the client's
+signature on the signedAuthPack fails to verify, the KDC returns an
+error of type KDC_ERR_INVALID_SIG.  There is no accompanying e-data
+for this error.
+
+The KDC must check the timestamp to ensure that the request is not
+a replay, and that the time skew falls within acceptable limits.
+The recommendations for ordinary (that is, non-PKINIT) skew times
+apply here.  If the check fails, the KDC returns an error of type
+KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.
+
+Finally, if the clientPublicValue is filled in, indicating that the
+client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
+checks to see if the parameters satisfy its policy.  If they do not,
+it returns an error of type KDC_ERR_KEY_TOO_WEAK.  The accompanying
+e-data is a SEQUENCE OF TypedData, whose data-type is
+TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
+the DER encoding of a DomainParameters (see above), including
+appropriate Diffie-Hellman parameters with which to retry the
+request.
+
+In order to establish authenticity of the reply, the KDC will sign
+some key data (either the random key used to encrypt the reply in
+the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
+generate the reply-encrypting key in the case of a ReplyKeyPack).
+The signature certificate to be used is to be selected as follows:
+
+    1.  If the client included a kdcCert field in the PA-PK-AS-REQ,
+        use the referred-to certificate, if the KDC has it.  If it
+        does not, the KDC returns an error of type
+        KDC_ERR_CERTIFICATE_MISMATCH.
+       
+    2.  Otherwise, if the client did not include a kdcCert field,
+        but did include a trustedCertifiers field, and the KDC
+        possesses a certificate issued by one of the listed
+        certifiers, use that certificate.  if it does not possess
+        one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+    3.  Otherwise, if the client included neither a kdcCert field
+        nor a trustedCertifiers field, and the KDC has only one
+        signature certificate, use that certificate.  If it has
+        more than one certificate, it returns an error of type
+        KDC_ERR_CERTIFICATE_MISMATCH.
+
+
+3.2.3.  KDC Reply
+
+Assuming that the client's request has been properly validated, the
+KDC proceeds as per RFC 1510bis, except as follows.
+
+The user's name as represented in the AS-REP must be derived from
+the certificate provided in the client's request.  If the KDC has
+its own mapping from the name in the certificate to a Kerberos name,
+it uses that Kerberos name.
+
+Otherwise, if the certificate contains a SubjectAltName extension
+with a KerberosName in the otherName field, it uses that name.
+
+    AnotherName ::= SEQUENCE {
+                                    -- Defined in [11].
+        type-id                     OBJECT IDENTIFIER,
+        value                   [0] EXPLICIT ANY DEFINED BY type-id
+    }
+
+    KerberosName ::= SEQUENCE {
+        realm                   [0] Realm,
+        principalName           [1] PrincipalName
+    }
+
+with OID
+
+    krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1)
+                                 security (5) kerberosv5 (2) }
+
+    krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+In this case, the realm in the ticket is that of the local realm (or
+some other realm name chosen by that realm).  Otherwise, the KDC
+returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.
+
+In addition, the KDC MUST set the initial flag in the issued TGT
+*and* add an authorization data of type AD-INITIAL-VERIFIED-CAS to
+the TGT.  The value is an OCTET STRING containing the DER encoding
+of InitialVerifiedCAs:
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        ocspValidated           [1] BOOLEAN,
+        ...
+    }
+
+The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+containers if the list of CAs satisfies the KDC's realm's policy.
+(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
+Furthermore, any TGS must copy such authorization data from tickets
+used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
+including the AD-IF-RELEVANT container, if present.
+
+AP servers that understand this authorization data type SHOULD apply
+local policy to determine whether a given ticket bearing such a type
+(not contained within an AD-IF-RELEVANT container) is acceptable.
+(This corresponds to the AP server checking the transited field when
+the TRANSITED-POLICY-CHECKED flag has not been set.)  If such a data
+type *is* contained within an AD-IF-RELEVANT container, AP servers
+still MAY apply local policy to determine whether the authorization
+data is acceptable.
+
+The AS-REP is otherwise unchanged from RFC 1510bis.  The KDC then
+encrypts the reply as usual, but not with the user's long-term key.
+Instead, it encrypts it with either a random encryption key, or a
+key derived from a Diffie-Hellman exchange.  Which is the case is
+indicated by the contents of the PA-PK-AS-REP (note tags):
+
+    PA-PK-AS-REP ::= CHOICE {
+                                    -- PAType YY (TBD)
+        dhSignedData            [0] ContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is KDCDHKeyInfo
+                                    -- (defined below).
+        encKeyPack              [1] ContentInfo,
+                                    -- Type is EnvelopedData.
+                                    -- Content is ReplyKeyPack
+                                    -- (defined below).
+        ...
+    }
+
+Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
+encKeyPack, but not both.  The former contains data of type
+KDCDHKeyInfo, and is used only when the reply is encrypted using a
+Diffie-Hellman derived key:
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+                                    -- Equals public exponent
+                                    -- (g^a mod p).
+                                    -- INTEGER encoded as payload
+                                    -- of BIT STRING.
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+                                    -- Exception: A value of zero
+                                    -- indicates that the KDC is
+                                    -- using cached values.
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                                    -- Expiration time for KDC's
+                                    -- cached values.
+        ...
+    }
+
+The fields of the ContentInfo for dhSignedData are to be filled in
+as follows:
+
+    1.  The eContent field contains data of type KDCDHKeyInfo.
+
+    2.  The eContentType field contains the OID value for
+        pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the KDCDHKeyInfo.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client may use to verify the
+        KDC's signature over the KDCDHKeyInfo.)  It may only be left
+        empty if the client did not include a trustedCertifiers
+        field in the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.
+
+    5.  If the client and KDC agree to use cached parameters, the
+        KDC SHOULD return a zero in the nonce field and include the
+        expiration time of the cached values in the dhKeyExpiration
+        field.  If this time is exceeded, the client SHOULD NOT use
+        the reply.  If the time is absent, the client SHOULD NOT use
+        the reply and MAY resubmit a request with a non-zero nonce,
+        thus indicating non-acceptance of the cached parameters.
+
+The key is derived as follows: Both the KDC and the client calculate
+the value g^(ab) mod p, where a and b are the client's and KDC's
+private exponents, respectively.  They both take the first k bits of
+this secret value as a key generation seed, where the parameter k
+(the size of the seed) is dependent on the selected key type, as
+specified in the Kerberos crypto draft [15].  The seed is then
+converted into a protocol key by applying to it a random-to-key
+function, which is also dependent on key type.
+
+The protocol key is used to derive the integrity key Ki and the
+encryption key Ke according to [15].  Ke and Ki are used to generate
+the encrypted part of the AS-REP.
+
+    1.  For example, if the encryption type is DES with MD4, k = 64
+        bits and the random-to-key function consists of replacing
+        some of the bits with parity bits, according to FIPS PUB 74
+        [cite].  In this case, the key derivation function for Ke is
+        the identity function, and Ki is not needed because the
+        checksum in the EncryptedData is not keyed.
+
+    2.  If the encryption type is three-key 3DES with HMAC-SHA1,
+        k = 168 bits and the random-to-key function is
+        DES3random-to-key as defined in [15].  This function inserts
+        parity bits to create a 192-bit 3DES protocol key that is
+        compliant with FIPS PUB 74 [cite].  Ke and Ki are derived
+        from this protocol key according to [15] with the key usage
+        number set to 3 (AS-REP encrypted part).
+
+If the KDC and client are not using Diffie-Hellman, the KDC encrypts
+the reply with an encryption key, packed in the encKeyPack, which
+contains data of type ReplyKeyPack:
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- Defined in RFC 1510bis.
+                                    -- Used to encrypt main reply.
+                                    -- MUST be at least as large
+                                    -- as session key.
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+                                    -- MUST be < 2^32.
+        ...
+    }
+
+The fields of the ContentInfo for encKeyPack MUST be filled in as
+follows:
+
+    1.  The innermost data is of type SignedData.  The eContent for
+        this data is of type ReplyKeyPack.
+
+    2.  The eContentType for this data contains the OID value for
+        pkrkeydata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the ReplyKeyPack.
+
+    4.  The certificates field contains a signature verification
+        certificate chain, which the client may use to verify the
+        KDC's signature over the ReplyKeyPack.)  It may only be left
+        empty if the client did not include a trustedCertifiers
+        field in the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.
+
+    5.  The outer data is of type EnvelopedData.  The
+        encryptedContent for this data is the SignedData described
+        in items 1 through 4, above.
+
+    6.  The encryptedContentType for this data contains the OID
+        value for id-signedData: { iso (1) member-body (2) us (840)
+        rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
+
+    7.  The recipientInfos field is a SET which MUST contain exactly
+        one member of type KeyTransRecipientInfo.  The encryptedKey
+        for this member contains the temporary key which is
+        encrypted using the client's public key.
+
+    8.  Neither the unprotectedAttrs field nor the originatorInfo
+        field is required for PKINIT.
+
+
+3.2.4.  Validation of KDC Reply
+
+Upon receipt of the KDC's reply, the client proceeds as follows.  If
+the PA-PK-AS-REP contains a dhSignedData, the client obtains and
+verifies the Diffie-Hellman parameters, and obtains the shared key
+as described above.  Otherwise, the message contains an encKeyPack,
+and the client decrypts and verifies the temporary encryption key.
+In either case, the client then decrypts the main reply with the
+resulting key, and then proceeds as described in RFC 1510bis.
+
+
+3.2.5.  Support for OCSP
+
+OCSP (Online Certificate Status Protocol) [cite] allows the use of
+on-line requests for a client or server to determine the validity of
+each other's certificates.  It is particularly useful for clients
+authenticating each other across a constrained network.  These
+clients will not have to download the entire CRL to check for the
+validity of the KDC's certificate.
+
+In these cases, the KDC generally has better connectivity to the
+OCSP server, and it therefore processes the OCSP request and
+response and sends the results to the client.  The changes proposed
+in this section allow a client to request an OCSP response from the
+KDC when using PKINIT.  This is similar to the way that OCSP is
+handled in [cite].
+
+OCSP support is provided in PKINIT through the use of additional
+preauthentication data.  The following new preauthentication types
+are defined:
+
+    PA-PK-OCSP-REQ ::= SEQUENCE {
+                                    -- PAType TBD
+        responderIDList         [0] SEQUENCE of ResponderID OPTIONAL,
+                                    -- ResponderID is a DER-encoded
+                                    -- ASN.1 type defined in [cite]
+        requestExtensions       [1] Extensions OPTIONAL
+                                    -- Extensions is a DER-encoded
+                                    -- ASN.1 type defined in [cite]
+    }
+
+    PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
+                                    -- OCSPResponse is a DER-encoded
+                                    -- ASN.1 type defined in [cite]
+
+A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
+KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
+PA-PK-OCSP-REQ from the client.  The KDC may either send a cached
+OCSP response or send an on-line request to the OCSP server.
+
+When using OCSP, the response is signed by the OCSP server, which is
+trusted by the client.  Depending on local policy, further
+verification of the validity of the OCSP server may need to be done.
+
+
+4.  Security Considerations
+
+PKINIT raises certain security considerations beyond those that can
+be regulated strictly in protocol definitions.  We will address them
+in this section.
+
+PKINIT extends the cross-realm model to the public-key
+infrastructure.  Anyone using PKINIT must be aware of how the
+certification infrastructure they are linking to works.
+
+Also, as in standard Kerberos, PKINIT presents the possibility of
+interactions between cryptosystems of varying strengths, and this
+now includes public-key cryptosystems.  Many systems, for example,
+allow the use of 512-bit public keys.  Using such keys to wrap data
+encrypted under strong conventional cryptosystems, such as 3DES, may
+be inappropriate.
+
+PKINIT calls for randomly generated keys for conventional
+cryptosystems.  Many such systems contain systematically "weak"
+keys.  For recommendations regarding these weak keys, see RFC
+1510bis.
+
+PKINIT allows the use of a zero nonce in the PKAuthenticator when
+cached Diffie-Hellman parameters are used.  In this case, message
+binding is performed using the nonce in the main request in the same
+way as it is done for ordinary (that is, non-PKINIT) AS-REQs.  The
+nonce field in the KDC request body is signed through the checksum
+in the PKAuthenticator, and it therefore cryptographically binds the
+AS-REQ with the AS-REP.  If cached parameters are also used on the
+client side, the generated session key will be the same, and a
+compromised session key could lead to the compromise of future
+cached exchanges.  It is desirable to limit the use of cached
+parameters to just the KDC, in order to eliminate this exposure.
+
+Care should be taken in how certificates are chosen for the purposes
+of authentication using PKINIT.  Some local policies may require
+that key escrow be applied for certain certificate types.  People
+deploying PKINIT should be aware of the implications of using
+certificates that have escrowed keys for the purposes of
+authentication.
+
+PKINIT does not provide for a "return routability" test to prevent
+attackers from mounting a denial-of-service attack on the KDC by
+causing it to perform unnecessary and expensive public-key
+operations.  Strictly speaking, this is also true of standard
+Kerberos, although the potential cost is not as great, because
+standard Kerberos does not make use of public-key cryptography.
+It might be possible to address this using a preauthentication field
+as part of the proposed Kerberos preauthenticatino framework.
+
+
+5.  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.
+
+
+6.  Expiration Date
+
+This draft expires August 20, 2004.
+
+
+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] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
+Using Public Key Cryptography.  Symposium On Network and Distributed
+System Security, 1997.
+
+[4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
+Protocol.  In Proceedings of the USENIX Workshop on Electronic
+Commerce, July 1995.
+
+[5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0.  Request
+for Comments 2246, January 1999.
+
+[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
+Distributed Systems.  In Proceedings of the 13th International
+Conference on Distributed Computing Systems, May 1993.
+
+[7] ITU-T (formerly CCITT) Information technology - Open Systems
+Interconnection - The Directory: Authentication Framework
+Recommendation X.509 ISO/IEC 9594-8
+
+[8] R. Housley. Cryptographic Message Syntax.
+draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
+RFC.
+
+[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
+Laboratories Technical Note Version 1.5. Revised November 1, 1993
+
+[10] 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.
+
+[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+Key Infrastructure, Certificate and CRL Profile, April 2002.
+Request for Comments 3280.
+
+[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+Specifications, October 1998.  Request for Comments 2437.
+
+[13] 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.
+
+[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
+Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
+
+[15] K. Raeburn.  Encryption and Checksum Specifications for
+Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt.
+
+[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
+T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
+Request for Comments 3546.
+
+[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
+Internet X.509 Public Key Infrastructure: Online Certificate Status
+Protocol - OCSP, June 1999.  Request for Comments 2560.
+
+
+8.  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
+Ari Medvinsky
+Microsoft Corporation
+One Microsoft Way
+Redmond WA 98052
+Phone: +1 425 707 3336
+E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
+
+Sasha Medvinsky
+Motorola, Inc.
+6450 Sequence Drive
+San Diego, CA 92121
++1 858 404 2367
+E-mail: smedvinsky@motorola.com
+
+John Wray
+Iris Associates, Inc.
+5 Technology Park Dr.
+Westford, MA 01886
+E-mail: John_Wray@iris.com
+
+Jonathan Trostle
+E-mail: jtrostle@world.std.com
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-19.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-19.txt
new file mode 100644
index 00000000000..f86b9f622f5
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-19.txt
@@ -0,0 +1,1055 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-19.txt                   Clifford Neuman
+Updates: RFC 1510bis                                             USC/ISI
+expires September 30, 2004                                   Matthew Hur
+                                                           Ari Medvinsky
+                                                   Microsoft Corporation
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+
+
+    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 provision 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
+
+
+The distribution of this memo is unlimited.  It is filed as
+draft-ietf-cat-kerberos-pk-init-19.txt and expires September 30,
+2004.  Please send comments to the authors.
+
+
+
+1.  Abstract
+
+
+This document describes protocol extensions (hereafter called PKINIT)
+to the Kerberos protocol specification (RFC 1510bis [1]).  These
+extensions provide a method for integrating public key cryptography
+into the initial authentication exchange, by passing digital
+certificates and associated authenticators in preauthentication data
+fields.
+
+
+
+2.  Introduction
+
+
+A client typically authenticates itself to a service in Kerberos
+using three distinct though related exchanges.  First, the client
+requests a ticket-granting ticket (TGT) from the Kerberos
+authentication server (AS).  Then, it uses the TGT to request a
+service ticket from the Kerberos ticket-granting server (TGS).
+Usually, the AS and TGS are integrated in a single device known as
+a Kerberos Key Distribution Center, or KDC.  (In this document, we will
+refer to both the AS and the TGS as the KDC.) Finally, the client
+uses the service ticket to authenticate itself to the service.
+
+
+The advantage afforded by the TGT is that the client need
+explicitly request a ticket and expose his credentials only once.  The
+TGT and its associated session key can then be used for any
+subsequent requests.  One result of this is that all further
+authentication is independent of the method by which the initial
+authentication was performed.  Consequently, initial authentication
+provides a convenient place to integrate public-key cryptography
+into Kerberos authentication.
+
+
+As defined, Kerberos authentication exchanges use symmetric-key
+cryptography, in part for performance.  One cost of using
+symmetric-key cryptography is that the keys must be shared, so that
+before a client can authenticate itself, he must already be
+registered with the KDC.
+
+
+Conversely, public-key cryptography (in conjunction with an
+established Public Key Infrastructure) permits authentication
+without prior registration with a KDC.  Adding it to Kerberos allows the
+widespread use of Kerberized applications by clients without requiring
+them to register first with a KDC: a requirement that has no inherent 
+security benefit.
+
+
+As noted above, a convenient and efficient place to introduce
+public-key cryptography into Kerberos is in the initial
+authentication exchange.  This document describes the methods and
+data formats for integrating public-key cryptography into Kerberos
+initial authentication.
+
+
+
+3.  Extensions
+
+
+This section describes extensions to RFC 1510bis for supporting the
+use of public-key cryptography in the initial request for a ticket.
+
+
+Briefly, this document defines the following extensions to RFC 1510bis:
+
+
+    1.  The client indicates the use of public-key authentication by
+        including a special preauthenticator in the initial request. 
+        This preauthenticator contains the client's public-key data 
+        and a signature.
+
+
+2.     2.  The KDC tests the client's request against its policy and
+        trusted Certification Authorities (CAs).
+
+
+    3.  If the request passes the verification tests, the KDC
+        replies as usual, but the reply is encrypted using either:
+
+
+        a.  a symmetric encryption key, signed using the KDC?s
+            signature key and encrypted using the client?s encryption
+            key; or
+
+
+        b.  a key generated through a Diffie-Hellman exchange with
+            the client, signed using the KDC's signature key.
+
+
+        Any keying material required by the client to obtain the 
+        Encryption key is returned in a preauthentication field in 
+        the usual reply.
+
+
+    4.  The client obtains the encryption key, decrypts the reply,
+        and then proceeds as usual.
+
+
+Section 3.1 of this document defines the necessary message formats.
+Section 3.2 describes their syntax and use in greater detail.
+
+
+
+3.1.  Definitions
+
+
+
+3.1.1.  Required Algorithms
+
+
+All PKINIT implementations MUST support the following algorithms:
+
+
+    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype;
+    
+    - Signature algorithm: SHA-1 digest and RSA;
+
+
+    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
+      with a non-zero nonce;
+
+
+    - Unkeyed checksum type for the paChecksum member of
+      PKAuthenticator: SHA1 (unkeyed).
+
+
+
+3.1.2.  Defined Message and Encryption Types
+
+
+PKINIT makes use of the following new preauthentication types:
+
+
+    PA-PK-AS-REQ                             TBD
+    PA-PK-AS-REP                             TBD
+    PA-PK-OCSP-REQ                           TBD
+    PA-PK-OCSP-REP                           TBD
+
+
+PKINIT also makes use of the following new authorization data type:
+
+
+    AD-INITIAL-VERIFIED-CAS                  TBD
+
+
+PKINIT introduces the following new error codes:
+
+
+    KDC_ERR_CLIENT_NOT_TRUSTED                62
+    KDC_ERR_KDC_NOT_TRUSTED                   63
+    KDC_ERR_INVALID_SIG                       64
+    KDC_ERR_KEY_SIZE                          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_CLIENT_NAME_MISMATCH              75
+
+
+PKINIT uses the following typed data types for errors:
+
+
+    TD-DH-PARAMETERS                         TBD
+    TD-TRUSTED-CERTIFIERS                    104
+    TD-CERTIFICATE-INDEX                     105
+
+
+PKINIT defines the following encryption types, for use in the AS-REQ
+message (to indicate acceptance of the corresponding encryption OIDs
+in PKINIT):
+
+
+    dsaWithSHA1-CmsOID                         9
+    md5WithRSAEncryption-CmsOID               10
+    sha1WithRSAEncryption-CmsOID              11
+    rc2CBC-EnvOID                             12
+    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
+    des-ede3-cbc-EnvOID                       15
+
+
+The above encryption types are used by the client only within the 
+KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.  Their 
+use within Kerberos EncryptedData structures is not specified by this 
+document.
+
+
+
+3.1.3.  Algorithm Identifiers
+
+
+PKINIT does not define, but does make use of, the following
+algorithm identifiers.
+
+
+PKINIT uses the following algorithm identifier for Diffie-Hellman
+key agreement [9]:
+
+
+    dhpublicnumber
+
+
+PKINIT uses the following signature algorithm identifiers [8, 12]:
+
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA with SHA1)
+
+
+PKINIT uses the following encryption algorithm identifiers [5] for
+encrypting the temporary key with a public key:
+
+
+    rsaEncryption          (PKCS1 v1.5)
+    id-RSAES-OAEP          (PKCS1 v2.0)
+
+
+PKINIT uses the following algorithm identifiers [2] for encrypting
+the reply key with the temporary key:
+
+
+    des-ede3-cbc           (three-key 3DES, CBC mode)
+    rc2-cbc                (RC2, CBC mode)
+
+
+Kerberos data structures require the use of integer etypes, while CMS 
+objects use OIDs. Therefore, each cryptographic algorithm supported 
+by PKINIT is identified both by a CMS OID and by an equivalent 
+Kerberos etype (defined in section 3.1.2).
+
+
+3.2.  PKINIT Preauthentication Syntax and Use
+
+
+This section defines the syntax and use of the various
+preauthentication fields employed by PKINIT.
+
+
+
+3.2.1.  Client Request
+
+
+The initial authentication request (AS-REQ) is sent as per RFC
+1510bis; the preauthentication field contains data signed by the
+client's private signature key as follows:
+
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] ContentInfo,
+                                    -- Defined in CMS [2].
+                                    -- Type is SignedData.
+                                    -- Content is AuthPack
+                                    -- (defined below).
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                                    -- A list of CAs, trusted by
+                                    -- the client, used to certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
+                                    -- Defined in CMS [2].
+                                    -- Identifies a particular KDC
+                                    -- certificate, if the client
+                                    -- already has it.
+        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
+                                    -- May identify the client's
+                                    -- Diffie-Hellman certificate,
+                                    -- or an RSA encryption key
+                                    -- certificate.
+        ...
+    }
+
+
+    TrustedCA ::= CHOICE {
+        caName                  [0] Name,
+                                    -- Fully qualified X.500 name
+                                    -- as defined in RFC 3280 [4].
+        issuerAndSerial         [1] IssuerAndSerialNumber,
+                                    -- Identifies a specific CA
+                                    -- certificate.
+        ...
+    }
+
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                                    -- Defined in RFC 3280 [4].
+                                    -- Present only if the client
+                                    -- is using ephemeral-ephemeral
+                                    -- Diffie-Hellman.
+        ...
+    }
+
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+        ctime                   [1] KerberosTime,
+                                    -- cusec and ctime are used as
+                                    -- in RFC 1510bis, for replay
+                                    -- prevention.
+        nonce                   [2] INTEGER,
+                                    -- Binds reply to request,
+                                    -- MUST be zero when client
+                                    -- will accept cached
+                                    -- Diffie-Hellman parameters
+                                    -- from KDC. MUST NOT be
+                                    -- zero otherwise.
+                                    -- MUST be 0 <= nonce < 2^32.
+        paChecksum              [3] Checksum,
+                                    -- Defined in RFC 1510bis [1].
+                                    -- Performed over KDC-REQ-BODY,
+                                    -- MUST be unkeyed.
+        ...
+    }
+
+
+    IMPORTS
+        -- from RFC 3280 [4]
+        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
+            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+              dod (6) internet (1) security (5) mechanisms (5)
+              pkix (7) id-mod (0) id-pkix1-explicit (18) }
+
+
+    IMPORTS
+        -- from RFC 2630 [2]
+        ContentInfo, IssuerAndSerialNumber
+            FROM CryptographicMessageSyntax { iso(1) member-body(2)
+              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
+              modules(0) cms(1) }
+
+
+    IMPORTS
+        -- from RFC 1510bis [1]
+        KerberosTime, Checksum
+            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+              krb5spec2(2) }
+
+
+The ContentInfo in the signedAuthPack is filled out as follows:
+
+
+    1.  The eContent field contains data of type AuthPack.  It MUST
+        contain the pkAuthenticator, and MAY also contain the
+        client's Diffie-Hellman public value (clientPublicValue).
+
+
+    2.  The eContentType field MUST contain the OID value for
+        pkauthdata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
+
+
+    3.  The signerInfos field MUST contain the signature over the
+        AuthPack.
+
+
+    4.  The certificates field MUST contain at least a signature
+        verification certificate chain that the KDC can use to
+        verify the signature over the AuthPack.  Additionally, the
+        client MAY insert an encryption certificate chain, if
+        (for example) the client is not using ephemeral-ephemeral
+        Diffie-Hellman.
+
+
+    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
+        be chosen from the First or Second defined Oakley Groups.
+        (See RFC 2409 [10].)
+
+
+    6.  The KDC may wish to use cached Diffie-Hellman parameters.
+        To indicate acceptance of caching, the client sends zero in
+        the nonce field of the pkAuthenticator.  Zero is not a valid
+        value for this field under any other circumstances.  Since
+        zero is used to indicate acceptance of cached parameters,
+        message binding in this case is performed using only the
+        nonce in the main request.
+
+
+
+3.2.2.  Validation of Client Request
+
+
+Upon receiving the client's request, the KDC validates it.  This
+section describes the steps that the KDC MUST (unless otherwise
+noted) take in validating the request.
+
+
+The KDC must look for a client certificate in the signedAuthPack.
+If it cannot find one signed by a CA it trusts, it sends back an
+error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
+e-data for this error is a SEQUENCE OF TYPED-DATA:
+
+
+    TYPED-DATA ::= SEQUENCE {
+                                    -- As defined in RFC 1510bis.
+        data-type               [0] INTEGER,
+        data-value              [1] OCTET STRING
+    }
+
+
+    IMPORTS
+        -- from RFC 1510bis [1]
+        TYPED-DATA, Checksum
+            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+              krb5spec2(2) }
+
+
+For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
+data-value is an OCTET STRING containing the DER encoding of
+
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+
+If, while verifying the certificate chain, the KDC determines that
+the signature on one of the certificates in the signedAuthPack is
+invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA,
+whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
+OCTET STRING containing the DER encoding of the index into the
+CertificateSet field, ordered as sent by the client:
+
+
+    CertificateIndex ::= IssuerAndSerialNumber
+                                    -- IssuerAndSerialNumber of
+                                    -- certificate with invalid signature
+
+
+If more than one certificate signature is invalid, the KDC MAY send one
+TYPED-DATA per invalid signature.
+
+
+The KDC MAY also check whether any of the certificates in the client's
+chain have been revoked.  If any of them have been revoked, the KDC
+MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
+attempts to determine the revocation status but is unable to do so,
+it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
+The certificate or certificates affected are identified exactly as
+for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
+
+
+In addition to validating the certificate chain, the KDC MUST also
+check that the certificate properly maps to the client's principal name
+as specified in the AS-REQ as follows:
+
+
+    1.  If the KDC has its own mapping from the name in the
+        certificate to a Kerberos name, it uses that Kerberos
+        name.
+
+
+    2.  Otherwise, if the certificate contains a SubjectAltName
+        extension with a Kerberos name in the otherName field,
+        it uses that name. The otherName field (of type AnotherName) in
+        the SubjectAltName extension MUST contain the following:
+
+
+        The type-id is:
+
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
+        internet (1) security (5) kerberosv5 (2) 2 }
+
+
+        The value is:
+
+
+        KRB5PrincipalName ::= SEQUENCE {
+            realm                   [0] Realm,
+            principalName           [1] PrincipalName
+        }
+
+
+        IMPORTS
+            -- from RFC 3280 [4]
+            GeneralName
+                FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+                  dod (6) internet (1) security (5) mechanisms (5)
+                  pkix (7) id-mod (0) id-pkix1-explicit (18) }
+
+
+        IMPORTS
+            -- from RFC 1510bis [1]
+            PrincipalName, Realm
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+                  krb5spec2(2) }
+
+
+If the KDC does not have its own mapping and there is no Kerberos
+name present in the certificate, or if the name in the request does
+not match the name in the certificate (including the realm name), or
+if there is no name in the request, the KDC MUST return error code
+KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+for this error.  If the name in the request is [special "blank"
+name], the KDC MAY insert a different name in the reply.
+
+
+Even if the chain is validated, and the names in the certificate and
+the request match, the KDC may decide not to trust the client.  For
+example, the certificate may include an Enxtended Key Usage (EKU) OID 
+in the extensions field.  As a matter of local policy, the KDC may 
+decide to reject requests on the basis of the absence or presence of 
+specific EKU OIDs.  In this case, the KDC MUST return error code 
+KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
+
+
+      { iso (1) org (3) dod (6) internet (1) security (5)
+        kerberosv5 (2) pkinit (3) pkekuoid (4) }
+
+
+If the client's signature on the signedAuthPack fails to verify, the KDC
+MUST return error KDC_ERR_INVALID_SIG.  There is no accompanying
+e-data for this error.
+
+
+The KDC MUST check the timestamp to ensure that the request is not
+a replay, and that the time skew falls within acceptable limits.
+The recommendations clock skew times in RFC 1510bis [1] apply here.
+If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT 
+or KRB_AP_ERR_SKEW, respectively.
+
+
+If the clientPublicValue is filled in, indicating that the
+client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
+checks to see if the parameters satisfy its policy.  If they do not,
+it MUST return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is 
+a SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose 
+data-value is an OCTET STRING containing the DER encoding of a 
+DomainParameters (see [3]), including appropriate Diffie-Hellman 
+parameters with which to retry the request.
+
+
+The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 
+client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not 
+have the corresponding certificate.
+
+
+The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did 
+not include a kdcCert field, but did include a trustedCertifiers field, 
+and the KDC does not possesses a certificate issued by one of the listed 
+certifiers.
+
+
+
+3.2.3.  KDC Reply
+
+
+Assuming that the client's request has been properly validated, the
+KDC proceeds as per RFC 1510bis, except as follows.
+
+
+The KDC MUST set the initial flag and include an authorization data of 
+type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is an 
+OCTET STRING containing the DER encoding of InitialVerifiedCAs:
+
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        Validated               [1] BOOLEAN,
+        ...
+    }
+
+
+The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 
+containers if the list of CAs satisfies the KDC's realm's policy. 
+(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 
+Furthermore, any TGS must copy such authorization data from tickets 
+used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 
+including the AD-IF-RELEVANT container, if present. 
+
+
+AP servers that understand this authorization data type SHOULD apply 
+local policy to determine whether a given ticket bearing such a type 
+(not contained within an AD-IF-RELEVANT container) is acceptable. 
+(This corresponds to the AP server checking the transited field when 
+the TRANSITED-POLICY-CHECKED flag has not been set.)  If such a data 
+type is contained within an AD-IF-RELEVANT container, AP servers 
+MAY apply local policy to determine whether the authorization 
+data is acceptable.
+
+
+The AS-REP is otherwise unchanged from RFC 1510bis.  The KDC encrypts 
+the reply as usual, but not with the client's long-term key.
+Instead, it encrypts it with either a generated encryption key, or a 
+key derived from a Diffie-Hellman exchange. The contents of the 
+PA-PK-AS-REP indicate the type of encryption key that was used:
+
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] ContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is KDCDHKeyInfo
+                                    -- (defined below).
+        encKeyPack              [1] ContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is ReplyKeyPack
+                                    -- (defined below).
+        ...
+    }
+
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+                                    -- Equals public exponent
+                                    -- (g^a mod p).
+                                    -- INTEGER encoded as payload
+                                    -- of BIT STRING.
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+                                    -- Exception: A value of zero
+                                    -- indicates that the KDC is
+                                    -- using cached values.
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                                    -- Expiration time for KDC's
+                                    -- cached values.
+        ...
+    }
+
+
+The fields of the ContentInfo for dhSignedData are to be filled in
+as follows:
+
+
+    1.  The eContent field contains data of type KDCDHKeyInfo.
+
+
+    2.  The eContentType field contains the OID value for
+        pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
+
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the KDCDHKeyInfo.
+
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the KDCDHKeyInfo.  This field may only 
+        be left empty if the client did include a kdcCert field in 
+        the PA-PK-AS-REQ, indicating that it has the KDC's certificate.
+
+
+    5.  If the client and KDC agree to use cached parameters, the
+        KDC MUST return a zero in the nonce field and include the
+        expiration time of the cached values in the dhKeyExpiration
+        field.  If this time is exceeded, the client MUST NOT use
+        the reply.  If the time is absent, the client MUST NOT use
+        the reply and MAY resubmit a request with a non-zero nonce,
+        thus indicating non-acceptance of the cached parameters.
+
+
+The key is derived as follows: Both the KDC and the client calculate
+the value g^(ab) mod p, where a and b are the client's and KDC's
+private exponents, respectively.  They both take the first k bits of
+this secret value as a key generation seed, where the parameter k
+(the size of the seed) is dependent on the selected key type, as
+specified in [6].  The seed is then converted into a protocol key by 
+applying to it a random-to-key function, which is also dependent on 
+key type.
+
+
+    1.  For example, if the encryption type is DES with MD4, k = 64
+        bits and the random-to-key function consists of replacing
+        some of the bits with parity bits, according to FIPS PUB 74
+        [9].
+
+
+    2.  If the encryption type is three-key 3DES with HMAC-SHA1,
+        k = 168 bits and the random-to-key function is
+        DES3random-to-key as defined in [6].  This function inserts
+        parity bits to create a 192-bit 3DES protocol key that is
+        compliant with FIPS PUB 74 [9].  This key is used to
+        generate additional keys Ke and Ki, for encryption and
+        integrity protection, respectively, using the key usage
+        value of 3, as per [6] for the handling of the encrypted
+        part of the AS-REP.
+
+
+If the KDC and client are not using Diffie-Hellman, the KDC encrypts
+the reply with an encryption key, packed in the encKeyPack, which
+contains data of type ReplyKeyPack:
+
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- Defined in RFC 1510bis.
+                                    -- Used to encrypt main reply.
+                                    -- MUST be at least as strong
+                                    -- as session key.  (Using the
+                                    -- same enctype and a strong
+                                    -- prng should suffice, if no
+                                    -- stronger encryption system
+                                    -- is available.)
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+                                    -- MUST be 0 < nonce < 2^32.
+        ...
+    }
+
+
+    IMPORTS
+        -- from RFC 1510bis [1]
+        EncryptionKey
+            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+              krb5spec2(2) }
+
+
+The fields of the ContentInfo for encKeyPack MUST be filled in as
+follows:
+
+
+    1.  The content is of type SignedData.  The eContent for
+        the SignedData is of type ReplyKeyPack.
+
+
+    2.  The eContentType for the SignedData contains the OID value for
+        pkrkeydata: { iso (1) org (3) dod (6) internet (1)
+        security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
+
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the ReplyKeyPack.
+
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the ReplyKeyPack.  This field may only 
+        be left empty if the client did include a kdcCert field in 
+        the PA-PK-AS-REQ, indicating that it has the KDC's certificate.
+
+
+    5.  The encryptedContentType for the EnvelopedData contains the OID
+        value for id-signedData: { iso (1) member-body (2) us (840)
+        rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
+
+
+    6.  The recipientInfos field is a SET which MUST contain exactly
+        one member of type KeyTransRecipientInfo.  The encryptedKey
+        for this member contains the temporary key which is
+        encrypted using the client's public key.
+
+
+    7.  The unprotectedAttrs or originatorInfo fields MAY be present.
+
+
+
+3.2.4.  Validation of KDC Reply
+
+
+Upon receipt of the KDC's reply, the client proceeds as follows.  If
+the PA-PK-AS-REP contains a dhSignedData, the client obtains and
+verifies the Diffie-Hellman parameters, and obtains the shared key
+as described above.  Otherwise, the message contains an encKeyPack,
+and the client decrypts and verifies the temporary encryption key.
+In either case, the client then decrypts the main reply with the
+resulting key, and then proceeds as described in RFC 1510bis.
+
+
+
+3.2.5.  Support for OCSP
+
+
+OCSP (Online Certificate Status Protocol) [8] allows the use of
+on-line requests for a client or server to determine the validity of
+each other's certificates.  It is particularly useful for clients
+authenticating each other across a constrained network.  These
+clients will not have to download the entire CRL to check for the
+validity of the KDC's certificate.
+
+
+In these cases, the KDC generally has better connectivity to the
+OCSP server, and it therefore processes the OCSP request and
+response and sends the results to the client.  The mechanism defined
+in this section allow a client to request an OCSP response from the
+KDC when using PKINIT.  This is similar to the way that OCSP is
+handled in [7].
+
+
+OCSP support is provided in PKINIT through the use of additional
+preauthentication data.  The following new preauthentication types
+are defined:
+
+
+    PA-PK-OCSP-REQ ::= SEQUENCE {
+                                    -- PAType TBD
+        responderIDList         [0] SEQUENCE of ResponderID OPTIONAL,
+                                    -- ResponderID is a DER-encoded
+                                    -- ASN.1 type defined in [8]
+        requestExtensions       [1] Extensions OPTIONAL
+                                    -- Extensions is a DER-encoded
+                                    -- ASN.1 type defined in [8]
+    }
+
+
+    PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
+                                    -- OCSPResponse is a DER-encoded
+                                    -- ASN.1 type defined in [8]
+
+
+A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
+KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
+PA-PK-OCSP-REQ from the client.  The KDC MAY either send a cached
+OCSP response or send an on-line request to the OCSP server.
+
+
+In the case that a responderIDList is not sent or is empty, the OCSP
+response must be signed by the authority that issued the
+certificate, unless specified otherwise by a mutually agreed policy
+between the client and the KDC.
+
+
+When using OCSP, the response is signed by the OCSP server, which is
+trusted by the client.  Depending on local policy, further
+verification of the validity of the OCSP server may need to be done.
+
+
+
+4.  Security Considerations
+
+
+PKINIT raises certain security considerations beyond those that can
+be regulated strictly in protocol definitions.  We will address them
+in this section.
+
+
+PKINIT extends the cross-realm model to the public-key
+infrastructure.  Users of PKINIT must understand security policies 
+and procedures appropriate to the use of Public Key Infrastructures.
+
+
+Standard Kerberos allows the possibility of interactions between 
+cryptosystems of varying strengths; this document adds interactions 
+with public-key cryptosystems to Kerberos.  Some administrative 
+policies may allow the use of relatively weak public keys.  Using 
+such keys to wrap data encrypted under stronger conventional 
+cryptosystems may be inappropriate.
+
+
+PKINIT requires keys for symmetric cryptosystems to be generated. 
+Some such systems contain "weak" keys.  For recommendations regarding 
+these weak keys, see RFC 1510bis.
+
+
+PKINIT allows the use of a zero nonce in the PKAuthenticator when 
+cached Diffie-Hellman keys are used.  In this case, message binding 
+is performed using the nonce in the main request in the same way as 
+it is done for ordinary AS-REQs (without the PKINIT 
+pre-authenticator).  The nonce field in the KDC request body is 
+signed through the checksum in the PKAuthenticator, which 
+cryptographically binds the PKINIT pre-authenticator to the main body 
+of the AS Request and also provides message integrity for the full 
+AS Request.
+
+
+However, when a PKINIT pre-authenticator in the AS-REP has a 
+zero-nonce, and an attacker has somehow recorded this 
+pre-authenticator and discovered the corresponding Diffie-Hellman 
+private key (e.g., with a brute-force attack), the attacker will be 
+able to fabricate his own AS-REP messages that impersonate the KDC 
+with this same pre-authenticator.  This compromised pre-authenticator 
+will remain valid as long as its expiration time has not been reached 
+and it is therefore important for clients to check this expiration 
+time and for the expiration time to be reasonably short, which 
+depends on the size of the Diffie-Hellman group.
+
+
+If a client also caches its Diffie-Hellman keys, then the session key 
+ could remain the same during multiple AS-REQ/AS-REP exchanges and an 
+ attacker which compromised the session key could fabricate his own 
+AS-REP messages with a pre-recorded pre-authenticator until the 
+client starts using a new Diffie-Hellman key pair and while the KDC 
+pre-authenticator has not yet expired.  It is therefore not 
+recommended for KDC clients to also cache their Diffie-Hellman keys.
+
+
+Care should be taken in how certificates are chosen for the purposes
+of authentication using PKINIT.  Some local policies may require
+that key escrow be used for certain certificate types.  Deployers of 
+PKINIT should be aware of the implications of using certificates that 
+have escrowed keys for the purposes of authentication.
+
+
+PKINIT does not provide for a "return routability" test to prevent
+attackers from mounting a denial-of-service attack on the KDC by
+causing it to perform unnecessary and expensive public-key
+operations.  Strictly speaking, this is also true of standard
+Kerberos, although the potential cost is not as great, because
+standard Kerberos does not make use of public-key cryptography.
+
+
+
+
+5.  Acknowledgements
+
+
+Some of the ideas on which this document 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
+document approaches those goals primarily from the Kerberos
+perspective.  Lastly, comments from groups working on similar ideas
+in DCE have been invaluable.
+
+
+
+6.  Expiration Date
+
+
+This draft expires September 30, 2004.
+
+
+
+7.  Bibliography
+
+
+[1]  RFC-Editor: To be replaced by RFC number for 
+draft-ietf-krb-wg-kerberos-clarifications.
+
+
+[2] R. Housley. Cryptographic Message Syntax., April 1999. 
+Request For Comments 2630.
+
+
+[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers 
+for the Internet X.509 Public Key Infrastructure Certificate and 
+Certificate Revocation List (CRL) Profile, April 2002. Request For 
+Comments 3279.
+
+
+[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
+Key Infrastructure Certificate and Certificate Revocation List 
+(CRL) Profile, April 2002. Request for Comments 3280.
+
+
+[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+Specifications, October 1998.  Request for Comments 2437.
+
+
+[6] RFC-Editor: To be replaced by RFC number for 
+draft-ietf-krb-wg-crypto.
+
+
+[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
+T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
+Request for Comments 3546.
+
+
+[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
+Internet X.509 Public Key Infrastructure: Online Certificate Status
+Protocol - OCSP, June 1999.  Request for Comments 2560.
+
+
+[9] NIST, Guidelines for Implementing and Using the NBS Encryption
+Standard, April 1981.  FIPS PUB 74.
+
+
+[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
+November 1998.  Request for Comments 2409.
+
+
+
+8.  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
+Ari Medvinsky
+Microsoft Corporation
+One Microsoft Way
+Redmond WA 98052
+Phone: +1 425 707 3336
+E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
+
+
+Sasha Medvinsky
+Motorola, Inc.
+6450 Sequence Drive
+San Diego, CA 92121
++1 858 404 2367
+E-mail: smedvinsky@motorola.com
+
+
+John Wray
+Iris Associates, Inc.
+5 Technology Park Dr.
+Westford, MA 01886
+E-mail: John_Wray@iris.com
+
+
+Jonathan Trostle
+E-mail: jtrostle@world.std.com
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt
new file mode 100644
index 00000000000..0504450b83c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt
@@ -0,0 +1,908 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-20.txt                   Clifford Neuman
+Updates: CLARIFICATIONS                                          USC/ISI
+expires January 25, 2005                                     Matthew Hur
+                                                           Ari Medvinsky
+                                                   Microsoft Corporation
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+                                                               John Wray
+                                                   Iris Associates, Inc.
+                                                        Jonathan Trostle
+
+
+    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 provision 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
+
+The distribution of this memo is unlimited.  It is filed as
+draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005.
+Please send comments to the authors.
+
+
+1.  Abstract
+
+This document describes protocol extensions (hereafter called
+PKINIT) to the Kerberos protocol specification ([1], hereafter
+called CLARIFICATIONS).  These extensions provide a method for
+integrating public key cryptography into the initial authentication
+exchange, by passing digital certificates and associated
+authenticators in preauthentication data fields.
+
+
+2.  Introduction
+
+A client typically authenticates itself to a service in Kerberos
+using three distinct though related exchanges.  First, the client
+requests a ticket-granting ticket (TGT) from the Kerberos
+authentication server (AS).  Then, it uses the TGT to request a
+service ticket from the Kerberos ticket-granting server (TGS).
+Usually, the AS and TGS are integrated in a single device known as
+a Kerberos Key Distribution Center, or KDC.  (In this document, we
+will refer to both the AS and the TGS as the KDC.)  Finally, the
+client uses the service ticket to authenticate itself to the
+service.
+
+The advantage afforded by the TGT is that the client need explicitly
+request a ticket and expose his credentials only once.  The TGT and
+its associated session key can then be used for any subsequent
+requests.  One result of this is that all further authentication is
+independent of the method by which the initial authentication was
+performed.  Consequently, initial authentication provides a
+convenient place to integrate public-key cryptography into Kerberos
+authentication.
+
+As defined, Kerberos authentication exchanges use symmetric-key
+cryptography, in part for performance.  One cost of using
+symmetric-key cryptography is that the keys must be shared, so that
+before a client can authenticate itself, he must already be
+registered with the KDC.
+
+Conversely, public-key cryptography (in conjunction with an
+established Public Key Infrastructure) permits authentication
+without prior registration with a KDC.  Adding it to Kerberos allows
+the widespread use of Kerberized applications by clients without
+requiring them to register first with a KDC--a requirement that has
+no inherent security benefit.
+
+As noted above, a convenient and efficient place to introduce
+public-key cryptography into Kerberos is in the initial
+authentication exchange.  This document describes the methods and
+data formats for integrating public-key cryptography into Kerberos
+initial authentication.
+
+
+3.  Extensions
+
+This section describes extensions to CLARIFICATIONS for supporting
+the use of public-key cryptography in the initial request for a
+ticket.
+
+Briefly, this document defines the following extensions to
+CLARIFICATIONS:
+
+    1.  The client indicates the use of public-key authentication by
+        including a special preauthenticator in the initial request.
+        This preauthenticator contains the client's public-key data
+        and a signature.
+
+    2.  The KDC tests the client's request against its policy and
+        trusted Certification Authorities (CAs).
+
+    3.  If the request passes the verification tests, the KDC
+        replies as usual, but the reply is encrypted using either:
+
+        a.  a symmetric encryption key, signed using the KDC's
+            signature key and encrypted using the client's encryption
+            key; or
+
+        b.  a key generated through a Diffie-Hellman exchange with
+            the client, signed using the KDC's signature key.
+
+        Any keying material required by the client to obtain the
+        Encryption key is returned in a preauthentication field
+        accompanying the usual reply.
+
+    4.  The client obtains the encryption key, decrypts the reply,
+        and then proceeds as usual.
+
+Section 3.1 of this document defines the necessary message formats.
+Section 3.2 describes their syntax and use in greater detail.
+
+
+3.1.  Definitions
+
+
+3.1.1.  Required Algorithms
+
+All PKINIT implementations MUST support the following algorithms:
+
+    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
+
+    - Signature algorithm: SHA-1 digest and RSA.
+
+    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
+      with a non-zero nonce.
+
+    - Unkeyed checksum type for the paChecksum member of
+      PKAuthenticator: SHA1 (unkeyed).
+
+
+3.1.2.  Defined Message and Encryption Types
+
+PKINIT makes use of the following new preauthentication types:
+
+    PA-PK-AS-REQ                             TBD
+    PA-PK-AS-REP                             TBD
+
+PKINIT also makes use of the following new authorization data type:
+
+    AD-INITIAL-VERIFIED-CAS                  TBD
+
+PKINIT introduces the following new error codes:
+
+    KDC_ERR_CLIENT_NOT_TRUSTED                62
+    KDC_ERR_KDC_NOT_TRUSTED                   63
+    KDC_ERR_INVALID_SIG                       64
+    KDC_ERR_KEY_SIZE                          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_CLIENT_NAME_MISMATCH              75
+
+PKINIT uses the following typed data types for errors:
+
+    TD-DH-PARAMETERS                         TBD
+    TD-TRUSTED-CERTIFIERS                    104
+    TD-CERTIFICATE-INDEX                     105
+
+PKINIT defines the following encryption types, for use in the AS-REQ
+message (to indicate acceptance of the corresponding encryption OIDs
+in PKINIT):
+
+    dsaWithSHA1-CmsOID                         9
+    md5WithRSAEncryption-CmsOID               10
+    sha1WithRSAEncryption-CmsOID              11
+    rc2CBC-EnvOID                             12
+    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
+    des-ede3-cbc-EnvOID                       15
+
+The above encryption types are used by the client only within the
+KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.  Their
+use within Kerberos EncryptedData structures is not specified by this
+document.
+
+The ASN.1 module for all structures defined in this document (plus
+IMPORT statements for all imported structures) are given in Appendix
+A.  All structures MUST be encoded using Distinguished Encoding
+Rules (DER).
+
+
+3.1.3.  Algorithm Identifiers
+
+PKINIT does not define, but does make use of, the following
+algorithm identifiers.
+
+PKINIT uses the following algorithm identifier for Diffie-Hellman
+key agreement [9]:
+
+    dhpublicnumber
+
+PKINIT uses the following signature algorithm identifiers [8, 12]:
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA with SHA1)
+
+PKINIT uses the following encryption algorithm identifiers [5] for
+encrypting the temporary key with a public key:
+
+    rsaEncryption          (PKCS1 v1.5)
+    id-RSAES-OAEP          (PKCS1 v2.0)
+
+PKINIT uses the following algorithm identifiers [2] for encrypting
+the reply key with the temporary key:
+
+    des-ede3-cbc           (three-key 3DES, CBC mode)
+    rc2-cbc                (RC2, CBC mode)
+
+Kerberos data structures require the use of integer etypes, while CMS
+objects use OIDs. Therefore, each cryptographic algorithm supported
+by PKINIT is identified both by a CMS OID and by an equivalent
+Kerberos etype (defined in section 3.1.2).
+
+
+3.2.  PKINIT Preauthentication Syntax and Use
+
+This section defines the syntax and use of the various
+preauthentication fields employed by PKINIT.
+
+
+3.2.1.  Client Request
+
+The initial authentication request (AS-REQ) is sent as per RFC
+1510bis; in addition, a preauthentication field contains data signed
+by the client's private signature key, as follows:
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] ContentInfo,
+                                    -- Defined in CMS [2].
+                                    -- Type is SignedData.
+                                    -- Content is AuthPack
+                                    -- (defined below).
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                                    -- A list of CAs, trusted by
+                                    -- the client, used to certify
+                                    -- KDCs.
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
+                                    -- Defined in CMS [2].
+                                    -- Identifies a particular KDC
+                                    -- certificate, if the client
+                                    -- already has it.
+        ...
+    }
+
+    TrustedCA ::= CHOICE {
+        caName                  [0] Name,
+                                    -- Fully qualified X.500 name
+                                    -- as defined in RFC 3280 [4].
+        issuerAndSerial         [2] IssuerAndSerialNumber,
+                                    -- Identifies a specific CA
+                                    -- certificate.
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                                    -- Defined in RFC 3280 [4].
+                                    -- Present only if the client
+                                    -- is using ephemeral-ephemeral
+                                    -- Diffie-Hellman.
+        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                    OPTIONAL,
+                                    -- List of CMS encryption types
+                                    -- supported by client in order
+                                    -- of (decreasing) preference.
+        ...
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+        ctime                   [1] KerberosTime,
+                                    -- cusec and ctime are used as
+                                    -- in CLARIFICATIONS, for replay
+                                    -- prevention.
+        nonce                   [2] INTEGER (0..4294967295),
+                                    -- Binds reply to request,
+                                    -- MUST be zero when client
+                                    -- will accept cached
+                                    -- Diffie-Hellman parameters
+                                    -- from KDC. MUST NOT be
+                                    -- zero otherwise.
+        paChecksum              [3] Checksum,
+                                    -- Defined in CLARIFICATIONS.
+                                    -- Performed over KDC-REQ-BODY,
+                                    -- MUST be unkeyed.
+        ...
+    }
+
+The ContentInfo in the signedAuthPack is filled out as follows:
+
+    1.  The eContent field contains data of type AuthPack.  It MUST
+        contain the pkAuthenticator, and MAY also contain the
+        client's Diffie-Hellman public value (clientPublicValue).
+
+    2.  The eContentType field MUST contain the OID value for
+        id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
+
+    3.  The signerInfos field MUST contain the signature over the
+        AuthPack.
+
+    4.  The certificates field MUST contain at least a signature
+        verification certificate chain that the KDC can use to
+        verify the signature over the AuthPack.  Additionally, the
+        client MAY insert an encryption certificate chain, if
+        (for example) the client is not using ephemeral-ephemeral
+        Diffie-Hellman.
+
+    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
+        be chosen from the First or Second defined Oakley Groups.
+        (See RFC 2409 [10].)
+
+    6.  The KDC may wish to use cached Diffie-Hellman parameters.
+        To indicate acceptance of caching, the client sends zero in
+        the nonce field of the pkAuthenticator.  Zero is not a valid
+        value for this field under any other circumstances.  Since
+        zero is used to indicate acceptance of cached parameters,
+        message binding in this case is performed using only the
+        nonce in the main request.
+
+
+3.2.2.  Validation of Client Request
+
+Upon receiving the client's request, the KDC validates it.  This
+section describes the steps that the KDC MUST (unless otherwise
+noted) take in validating the request.
+
+The KDC must look for a client certificate in the signedAuthPack.
+If it cannot find one signed by a CA it trusts, it sends back an
+error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
+e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC
+1510bis).  For this error, the data-type is TD-TRUSTED-CERTIFIERS,
+and the data-value is an OCTET STRING containing the DER encoding of
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+If, while verifying the certificate chain, the KDC determines that
+the signature on one of the certificates in the signedAuthPack is
+invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA,
+whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
+OCTET STRING containing the DER encoding of the index into the
+CertificateSet field, ordered as sent by the client:
+
+    CertificateIndex ::= IssuerAndSerialNumber
+                                    -- IssuerAndSerialNumber of
+                                    -- certificate with invalid signature
+
+If more than one certificate signature is invalid, the KDC MAY send
+one TYPED-DATA per invalid signature.
+
+The KDC MAY also check whether any certificates in the client's
+chain have been revoked.  If any of them have been revoked, the KDC
+MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
+attempts to determine the revocation status but is unable to do so,
+it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
+The certificate or certificates affected are identified exactly as
+for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
+
+In addition to validating the certificate chain, the KDC MUST also
+check that the certificate properly maps to the client's principal name
+as specified in the AS-REQ as follows:
+
+    1.  If the KDC has its own mapping from the name in the
+        certificate to a Kerberos name, it uses that Kerberos
+        name.
+
+    2.  Otherwise, if the certificate contains a SubjectAltName
+        extension with a Kerberos name in the otherName field,
+        it uses that name. The otherName field (of type AnotherName)
+        in the SubjectAltName extension MUST contain the following:
+
+        The type-id is:
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
+        internet (1) security (5) kerberosv5 (2) 2 }
+
+        The value is:
+
+        KRB5PrincipalName ::= SEQUENCE {
+            realm                   [0] Realm,
+            principalName           [1] PrincipalName
+        }
+
+If the KDC does not have its own mapping and there is no Kerberos
+name present in the certificate, or if the name in the request does
+not match the name in the certificate (including the realm name), or
+if there is no name in the request, the KDC MUST return error code
+KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+for this error.
+
+Even if the chain is validated, and the names in the certificate and
+the request match, the KDC may decide not to trust the client.  For
+example, the certificate may include an Enxtended Key Usage (EKU) OID
+in the extensions field.  As a matter of local policy, the KDC may
+decide to reject requests on the basis of the absence or presence of
+specific EKU OIDs.  In this case, the KDC MUST return error code
+KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
+
+    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+      pkinit(3) pkekuoid(4) }
+
+If the client's signature on the signedAuthPack fails to verify, the KDC
+MUST return error KDC_ERR_INVALID_SIG.  There is no accompanying
+e-data for this error.
+
+The KDC MUST check the timestamp to ensure that the request is not
+a replay, and that the time skew falls within acceptable limits.
+The recommendations clock skew times in CLARIFICATIONS apply here.
+If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT
+or KRB_AP_ERR_SKEW, respectively.
+
+If the clientPublicValue is filled in, indicating that the client
+wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
+see if the parameters satisfy its policy.  If they do not, it MUST
+return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is a
+SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
+whose data-value is an OCTET STRING containing the DER encoding of a
+DomainParameters (see [3]), including appropriate Diffie-Hellman
+parameters with which to retry the request.
+
+The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
+client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
+not have the corresponding certificate.
+
+The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
+did not include a kdcCert field, but did include a trustedCertifiers
+field, and the KDC does not possesses a certificate issued by one of
+the listed certifiers.
+
+If there is a supportedCMSTypes field in the AuthPack, the KDC must
+check to see if it supports any of the listed types.  If it supports
+more than one of the types, the KDC SHOULD use the one listed first.
+If it does not support any of them, it MUST return an error of type
+KRB5KDC_ERR_ETYPE_NOSUPP.
+
+
+3.2.3.  KDC Reply
+
+Assuming that the client's request has been properly validated, the
+KDC proceeds as per CLARIFICATIONS, except as follows.
+
+The KDC MUST set the initial flag and include an authorization data
+of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
+an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        Validated               [1] BOOLEAN,
+        ...
+    }
+
+The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+containers if the list of CAs satisfies the KDC's realm's policy.
+(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
+Furthermore, any TGS must copy such authorization data from tickets
+used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
+including the AD-IF-RELEVANT container, if present.
+
+Application servers that understand this authorization data type
+SHOULD apply local policy to determine whether a given ticket
+bearing such a type *not* contained within an AD-IF-RELEVANT
+container is acceptable.  (This corresponds to the AP server
+checking the transited field when the TRANSITED-POLICY-CHECKED flag
+has not been set.)  If such a data type is contained within an
+AD-IF-RELEVANT container, AP servers MAY apply local policy to
+determine whether the authorization data is acceptable.
+
+The AS-REP is otherwise unchanged from CLARIFICATIONS.  The KDC
+encrypts the reply as usual, but not with the client's long-term
+key.  Instead, it encrypts it with either a generated encryption
+key, or a key derived from a Diffie-Hellman exchange. The contents
+of the PA-PK-AS-REP indicate the type of encryption key that was
+used:
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] ContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is KDCDHKeyInfo
+                                    -- (defined below).
+        encKeyPack              [1] ContentInfo,
+                                    -- Type is EnvelopedData.
+                                    -- Content is SignedData over
+                                    -- ReplyKeyPack (defined below).
+        ...
+    }
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+                                    -- Equals public exponent
+                                    -- (g^a mod p).
+                                    -- INTEGER encoded as payload
+                                    -- of BIT STRING.
+        nonce                   [1] INTEGER,
+                                    -- Binds reply to request.
+                                    -- Exception: A value of zero
+                                    -- indicates that the KDC is
+                                    -- using cached values.
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                                    -- Expiration time for KDC's
+                                    -- cached values.
+        ...
+    }
+
+The fields of the ContentInfo for dhSignedData are to be filled in
+as follows:
+
+    1.  The eContent field contains data of type KDCDHKeyInfo.
+
+    2.  The eContentType field contains the OID value for
+        id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the KDCDHKeyInfo.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the KDCDHKeyInfo.  This field may only
+        be left empty if the client did include a kdcCert field in
+        the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.
+
+    5.  If the client and KDC agree to use cached parameters, the
+        KDC MUST return a zero in the nonce field and include the
+        expiration time of the cached values in the dhKeyExpiration
+        field.  If this time is exceeded, the client MUST NOT use
+        the reply.  If the time is absent, the client MUST NOT use
+        the reply and MAY resubmit a request with a non-zero nonce,
+        thus indicating non-acceptance of the cached parameters.
+
+The key is derived as follows: Both the KDC and the client calculate
+the value g^(ab) mod p, where a and b are the client's and KDC's
+private exponents, respectively.  They both take the first k bits of
+this secret value as a key generation seed, where the parameter k
+(the size of the seed) is dependent on the selected key type, as
+specified in [6].  The seed is then converted into a protocol key by
+applying to it a random-to-key function, which is also dependent on
+key type.
+
+If the KDC and client are not using Diffie-Hellman, the KDC encrypts
+the reply with an encryption key, packed in the encKeyPack, which
+contains data of type ReplyKeyPack:
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- Defined in CLARIFICATIONS.
+                                    -- Used to encrypt main reply.
+                                    -- MUST be at least as strong
+                                    -- as session key.  (Using the
+                                    -- same enctype and a strong
+                                    -- prng should suffice, if no
+                                    -- stronger encryption system
+                                    -- is available.)
+        nonce                   [1] INTEGER (0..4294967295),
+                                    -- Binds reply to request.
+        ...
+    }
+
+The fields of the ContentInfo for encKeyPack MUST be filled in as
+follows:
+
+    1.  The content is of type SignedData.  The eContent for
+        the SignedData is of type ReplyKeyPack.
+
+    2.  The eContentType for the SignedData contains the OID value
+        for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the ReplyKeyPack.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the ReplyKeyPack.  This field may only
+        be left empty if the client included a kdcCert field in the
+        PA-PK-AS-REQ, indicating that it has the KDC's certificate.
+
+    5.  The contentType for the EnvelopedData contains the OID value
+        for id-signedData: { iso (1) member-body (2) us (840) rsadsi
+        (113549) pkcs (1) pkcs7 (7) signedData (2) }
+
+    6.  The recipientInfos field is a SET which MUST contain exactly
+        one member of type KeyTransRecipientInfo.  The encryptedKey
+        for this member contains the temporary key which is
+        encrypted using the client's public key.
+
+    7.  The unprotectedAttrs or originatorInfo fields MAY be
+        present.
+
+
+3.2.4.  Validation of KDC Reply
+
+Upon receipt of the KDC's reply, the client proceeds as follows.  If
+the PA-PK-AS-REP contains a dhSignedData, the client obtains and
+verifies the Diffie-Hellman parameters, and obtains the shared key
+as described above.  Otherwise, the message contains an encKeyPack,
+and the client decrypts and verifies the temporary encryption key.
+
+In either case, the client MUST check to see if the included
+certificate contains a subjectAltName extension of type dNSName or
+iPAddress (if the KDC is specified by IP address instead of name).
+If it does, it MUST check to see if that extension matches the KDC
+it believes it is communicating with, with matching rules specified
+in RFC 2459.  Exception: If the client has some external information
+as to the identity of the KDC, this check MAY be omitted.
+
+The client also MUST check that the KDC's certificate contains an
+extendedKeyUsage OID of id-pkkdcekuoid:
+
+    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+      pkinit(3) pkkdcekuoid(5) }
+
+If all applicable checks are satisfied, the client then decrypts the
+main reply with the resulting key, and then proceeds as described in
+CLARIFICATIONS.
+
+
+4.  Security Considerations
+
+PKINIT raises certain security considerations beyond those that can
+be regulated strictly in protocol definitions.  We will address them
+in this section.
+
+PKINIT extends the cross-realm model to the public-key
+infrastructure.  Users of PKINIT must understand security policies
+and procedures appropriate to the use of Public Key Infrastructures.
+
+Standard Kerberos allows the possibility of interactions between
+cryptosystems of varying strengths; this document adds interactions
+with public-key cryptosystems to Kerberos.  Some administrative
+policies may allow the use of relatively weak public keys.  Using
+such keys to wrap data encrypted under stronger conventional
+cryptosystems may be inappropriate.
+
+PKINIT requires keys for symmetric cryptosystems to be generated.
+Some such systems contain "weak" keys.  For recommendations regarding
+these weak keys, see CLARIFICATIONS.
+
+PKINIT allows the use of a zero nonce in the PKAuthenticator when
+cached Diffie-Hellman keys are used.  In this case, message binding
+is performed using the nonce in the main request in the same way as
+it is done for ordinary AS-REQs (without the PKINIT
+pre-authenticator).  The nonce field in the KDC request body is
+signed through the checksum in the PKAuthenticator, which
+cryptographically binds the PKINIT pre-authenticator to the main
+body of the AS Request and also provides message integrity for the
+full AS Request.
+
+However, when a PKINIT pre-authenticator in the AS-REP has a
+zero-nonce, and an attacker has somehow recorded this
+pre-authenticator and discovered the corresponding Diffie-Hellman
+private key (e.g., with a brute-force attack), the attacker will be
+able to fabricate his own AS-REP messages that impersonate the KDC
+with this same pre-authenticator.  This compromised pre-authenticator
+will remain valid as long as its expiration time has not been reached
+and it is therefore important for clients to check this expiration
+time and for the expiration time to be reasonably short, which
+depends on the size of the Diffie-Hellman group.
+
+If a client also caches its Diffie-Hellman keys, then the session key
+could remain the same during multiple AS-REQ/AS-REP exchanges and an
+attacker which compromised the session key could fabricate his own
+AS-REP messages with a pre-recorded pre-authenticator until the
+client starts using a new Diffie-Hellman key pair and while the KDC
+pre-authenticator has not yet expired.  It is therefore not
+recommended for KDC clients to also cache their Diffie-Hellman keys.
+
+Care should be taken in how certificates are chosen for the purposes
+of authentication using PKINIT.  Some local policies may require
+that key escrow be used for certain certificate types.  Deployers of
+PKINIT should be aware of the implications of using certificates that
+have escrowed keys for the purposes of authentication.
+
+PKINIT does not provide for a "return routability" test to prevent
+attackers from mounting a denial-of-service attack on the KDC by
+causing it to perform unnecessary and expensive public-key
+operations.  Strictly speaking, this is also true of standard
+Kerberos, although the potential cost is not as great, because
+standard Kerberos does not make use of public-key cryptography.
+
+The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+be used if the KDC itself vouches for the user's certificate.  [This
+seems to reflect the consensus of the Kerberos working group.]
+
+
+5.  Acknowledgements
+
+Some of the ideas on which this document 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
+document approaches those goals primarily from the Kerberos
+perspective.  Lastly, comments from groups working on similar ideas
+in DCE have been invaluable.
+
+
+6.  Expiration Date
+
+This draft expires January 25, 2004.
+
+
+7.  Bibliography
+
+[1]  RFC-Editor: To be replaced by RFC number for
+draft-ietf-krb-wg-kerberos-clarifications.
+
+[2] R. Housley. Cryptographic Message Syntax., April 1999.
+Request For Comments 2630.
+
+[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
+for the Internet X.509 Public Key Infrastructure Certificate and
+Certificate Revocation List (CRL) Profile, April 2002. Request For
+Comments 3279.
+
+[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
+Key Infrastructure Certificate and Certificate Revocation List
+(CRL) Profile, April 2002. Request for Comments 3280.
+
+[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+Specifications, October 1998.  Request for Comments 2437.
+
+[6] RFC-Editor: To be replaced by RFC number for
+draft-ietf-krb-wg-crypto.
+
+[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
+T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
+Request for Comments 3546.
+
+[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
+Internet X.509 Public Key Infrastructure: Online Certificate Status
+Protocol - OCSP, June 1999.  Request for Comments 2560.
+
+[9] NIST, Guidelines for Implementing and Using the NBS Encryption
+Standard, April 1981.  FIPS PUB 74.
+
+[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
+November 1998.  Request for Comments 2409.
+
+
+8.  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
+Ari Medvinsky
+Microsoft Corporation
+One Microsoft Way
+Redmond WA 98052
+Phone: +1 425 707 3336
+E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
+
+Sasha Medvinsky
+Motorola, Inc.
+6450 Sequence Drive
+San Diego, CA 92121
++1 858 404 2367
+E-mail: smedvinsky@motorola.com
+
+John Wray
+Iris Associates, Inc.
+5 Technology Park Dr.
+Westford, MA 01886
+E-mail: John_Wray@iris.com
+
+Jonathan Trostle
+E-mail: jtrostle@world.std.com
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+KerberosV5-PK-INIT-SPEC {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) pkinit(TBD)
+} DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+    IMPORTS
+        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
+            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+              dod (6) internet (1) security (5) mechanisms (5)
+              pkix (7) id-mod (0) id-pkix1-explicit (18) }
+
+        ContentInfo, IssuerAndSerialNumber
+            FROM CryptographicMessageSyntax { iso(1) member-body(2)
+              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
+              modules(0) cms(1) }
+
+        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+              krb5spec2(2) } ;
+
+    id-pkinit  OBJECT IDENTIFIER ::=
+      { iso (1) org (3) dod (6) internet (1) security (5)
+        kerberosv5 (2) pkinit (3) }
+
+    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+    id-pkkdcekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+    pa-pk-as-req INTEGER ::=                 TBD
+    pa-pk-as-rep INTEGER ::=                 TBD
+    pa-pk-ocsp-req INTEGER ::=               TBD
+    pa-pk-ocsp-rep INTEGER ::=               TBD
+
+    ad-initial-verified-cas INTEGER ::=      TBD
+
+    td-dh-parameters INTEGER ::=             TBD
+    td-trusted-certifiers INTEGER ::=        104
+    td-certificate-index INTEGER ::=         105
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] ContentInfo,
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
+        ...
+    }
+
+    TrustedCA ::= CHOICE {
+        caName                  [0] Name,
+        issuerAndSerial         [2] IssuerAndSerialNumber,
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                    OPTIONAL,
+        ...
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER,
+        ctime                   [1] KerberosTime,
+        nonce                   [2] INTEGER (0..4294967295),
+        paChecksum              [3] Checksum,
+        ...
+    }
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+    CertificateIndex ::= IssuerAndSerialNumber
+
+    KRB5PrincipalName ::= SEQUENCE {
+        realm                   [0] Realm,
+        principalName           [1] PrincipalName
+    }
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        validated               [1] BOOLEAN,
+        ...
+    }
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] ContentInfo,
+        encKeyPack              [1] ContentInfo,
+        ...
+    }
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+        nonce                   [1] INTEGER,
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+        ...
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+        nonce                   [1] INTEGER (0..4294967295),
+        ...
+    }
+
+END
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
new file mode 100644
index 00000000000..d2510b5262d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
@@ -0,0 +1,1036 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-21.txt                   Clifford Neuman
+expires April 25, 2005                                           USC/ISI
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of This Memo
+
+By submitting this Internet-Draft, I certify that any applicable
+patent or other IPR claims of which I am aware have been disclosed,
+or will be disclosed, and any of which I become aware will be
+disclosed, in accordance with RFC 3668.
+
+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-ietf-cat-kerberos-pk-init-21.txt and expires April 25, 2005.
+Please send comments to the authors.
+
+
+1.  Abstract
+
+This document describes protocol extensions (hereafter called
+PKINIT) to the Kerberos protocol specification [1].  These
+extensions provide a method for integrating public key cryptography
+into the initial authentication exchange, by passing digital
+certificates and associated authenticators in preauthentication data
+fields.
+
+
+2.  Introduction
+
+A client typically authenticates itself to a service in Kerberos
+using three distinct though related exchanges.  First, the client
+requests a ticket-granting ticket (TGT) from the Kerberos
+authentication server (AS).  Then, it uses the TGT to request a
+service ticket from the Kerberos ticket-granting server (TGS).
+Usually, the AS and TGS are integrated in a single device known as
+a Kerberos Key Distribution Center, or KDC.  (In this document, we
+will refer to both the AS and the TGS as the KDC.)  Finally, the
+client uses the service ticket to authenticate itself to the
+service.
+
+The advantage afforded by the TGT is that the client need explicitly
+request a ticket and expose his credentials only once.  The TGT and
+its associated session key can then be used for any subsequent
+requests.  One result of this is that all further authentication is
+independent of the method by which the initial authentication was
+performed.  Consequently, initial authentication provides a
+convenient place to integrate public-key cryptography into Kerberos
+authentication.
+
+As defined, Kerberos authentication exchanges use symmetric-key
+cryptography, in part for performance.  One cost of using
+symmetric-key cryptography is that the keys must be shared, so that
+before a client can authenticate itself, he must already be
+registered with the KDC.
+
+Conversely, public-key cryptography (in conjunction with an
+established Public Key Infrastructure) permits authentication
+without prior registration with a KDC.  Adding it to Kerberos allows
+the widespread use of Kerberized applications by clients without
+requiring them to register first with a KDC--a requirement that has
+no inherent security benefit.
+
+As noted above, a convenient and efficient place to introduce
+public-key cryptography into Kerberos is in the initial
+authentication exchange.  This document describes the methods and
+data formats for integrating public-key cryptography into Kerberos
+initial authentication.
+
+
+3.  Extensions
+
+This section describes extensions to [1] for supporting the use of
+public-key cryptography in the initial request for a ticket.
+
+Briefly, this document defines the following extensions to [1]:
+
+    1.  The client indicates the use of public-key authentication by
+        including a special preauthenticator in the initial request.
+        This preauthenticator contains the client's public-key data
+        and a signature.
+
+    2.  The KDC tests the client's request against its policy and
+        trusted Certification Authorities (CAs).
+
+    3.  If the request passes the verification tests, the KDC
+        replies as usual, but the reply is encrypted using either:
+
+        a.  a symmetric encryption key, signed using the KDC's
+            signature key and encrypted using the client's encryption
+            key; or
+
+        b.  a key generated through a Diffie-Hellman exchange with
+            the client, signed using the KDC's signature key.
+
+        Any keying material required by the client to obtain the
+        Encryption key is returned in a preauthentication field
+        accompanying the usual reply.
+
+    4.  The client obtains the encryption key, decrypts the reply,
+        and then proceeds as usual.
+
+Section 3.1 of this document defines the necessary message formats.
+Section 3.2 describes their syntax and use in greater detail.
+
+
+3.1.  Definitions, Requirements, and Constants
+
+
+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 [12].
+
+
+3.1.1.  Required Algorithms
+
+All PKINIT implementations MUST support the following algorithms:
+
+    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
+
+    - Signature algorithm: SHA-1 digest and RSA.
+
+    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
+      with a non-zero nonce.
+
+    - Unkeyed checksum type for the paChecksum member of
+      PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
+      [11].
+
+
+3.1.2.  Defined Message and Encryption Types
+
+PKINIT makes use of the following new preauthentication types:
+
+    PA-PK-AS-REQ                             TBD
+    PA-PK-AS-REP                             TBD
+
+PKINIT also makes use of the following new authorization data type:
+
+    AD-INITIAL-VERIFIED-CAS                  TBD
+
+PKINIT introduces the following new error codes:
+
+    KDC_ERR_CLIENT_NOT_TRUSTED                62
+    KDC_ERR_KDC_NOT_TRUSTED                   63
+    KDC_ERR_INVALID_SIG                       64
+    KDC_ERR_KEY_SIZE                          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_CLIENT_NAME_MISMATCH              75
+
+PKINIT uses the following typed data types for errors:
+
+    TD-DH-PARAMETERS                         TBD
+    TD-TRUSTED-CERTIFIERS                    104
+    TD-CERTIFICATE-INDEX                     105
+    TD-UNKEYED-CHECKSUM-INFO                 109
+
+PKINIT defines the following encryption types, for use in the AS-REQ
+message (to indicate acceptance of the corresponding encryption OIDs
+in PKINIT):
+
+    dsaWithSHA1-CmsOID                         9
+    md5WithRSAEncryption-CmsOID               10
+    sha1WithRSAEncryption-CmsOID              11
+    rc2CBC-EnvOID                             12
+    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
+    des-ede3-cbc-EnvOID                       15
+
+The above encryption types are used by the client only within the
+KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.  Their
+use within Kerberos EncryptedData structures is not specified by this
+document.
+
+The ASN.1 module for all structures defined in this document (plus
+IMPORT statements for all imported structures) are given in Appendix
+A.  In the event of a discrepancy between Appendix A and the portions
+of ASN.1 in the main text, the appendix is normative.
+
+All structures defined in this document MUST be encoded using
+Distinguished Encoding Rules (DER).  All imported data structures
+must be encoded according to the rules specified in Kerberos [1] or
+CMS [2] as appropriate.
+
+Interoperability note: Some implementations may not be able to
+decode CMS objects encoded with BER but not DER; specifically, they
+may not be able to decode infinite length encodings.  To maximize
+interoperability, implementers SHOULD encode CMS objects used in
+PKINIT with DER.
+
+
+3.1.3.  Algorithm Identifiers
+
+PKINIT does not define, but does make use of, the following
+algorithm identifiers.
+
+PKINIT uses the following algorithm identifier for Diffie-Hellman
+key agreement [9]:
+
+    dhpublicnumber
+
+PKINIT uses the following signature algorithm identifiers [8, 12]:
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA with SHA1)
+
+PKINIT uses the following encryption algorithm identifiers [5] for
+encrypting the temporary key with a public key:
+
+    rsaEncryption          (PKCS1 v1.5)
+    id-RSAES-OAEP          (PKCS1 v2.0)
+
+PKINIT uses the following algorithm identifiers [2] for encrypting
+the reply key with the temporary key:
+
+    des-ede3-cbc           (three-key 3DES, CBC mode)
+    rc2-cbc                (RC2, CBC mode)
+    aes256_CBC             (AES-256, CBC mode)
+
+
+3.2.  PKINIT Preauthentication Syntax and Use
+
+This section defines the syntax and use of the various
+preauthentication fields employed by PKINIT.
+
+
+3.2.1.  Client Request
+
+The initial authentication request (AS-REQ) is sent as per [1]; in
+addition, a preauthentication field contains data signed by the
+client's private signature key, as follows:
+
+    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- ContentInfo
+    })
+
+    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- IssuerAndSerialNumber
+    })
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] IMPLICIT WrapContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is AuthPack
+                                    -- (defined below).
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                                    -- A list of CAs, trusted by
+                                    -- the client, used to certify
+                                    -- KDCs.
+        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
+                                    OPTIONAL,
+                                    -- Identifies a particular KDC
+                                    -- certificate, if the client
+                                    -- already has it.
+        ...
+    }
+
+    TrustedCA ::= CHOICE {
+        caName                  [1] Name,
+                                    -- Fully qualified X.500 name
+                                    -- as defined in RFC 3280 [4].
+        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
+                                    -- Identifies a specific CA
+                                    -- certificate.
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                                    -- Defined in RFC 3280 [4].
+                                    -- Present only if the client
+                                    -- is using ephemeral-ephemeral
+                                    -- Diffie-Hellman.
+        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                    OPTIONAL,
+                                    -- List of CMS encryption types
+                                    -- supported by client in order
+                                    -- of (decreasing) preference.
+        ...
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER (0..999999),
+        ctime                   [1] KerberosTime,
+                                    -- cusec and ctime are used as
+                                    -- in [1], for replay
+                                    -- prevention.
+        nonce                   [2] INTEGER (0..4294967295),
+                                    -- Binds reply to request,
+                                    -- MUST be zero when client
+                                    -- will accept cached
+                                    -- Diffie-Hellman parameters
+                                    -- from KDC. MUST NOT be
+                                    -- zero otherwise.
+        paChecksum              [3] Checksum,
+                                    -- Defined in [1].
+                                    -- Performed over KDC-REQ-BODY,
+                                    -- MUST be unkeyed.
+        ...
+    }
+
+The ContentInfo in the signedAuthPack is filled out as follows:
+
+    1.  The eContent field contains data of type AuthPack.  It MUST
+        contain the pkAuthenticator, and MAY also contain the
+        client's Diffie-Hellman public value (clientPublicValue).
+
+    2.  The eContentType field MUST contain the OID value for
+        id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
+
+    3.  The signerInfos field MUST contain the signature over the
+        AuthPack.
+
+    4.  The certificates field MUST contain at least a signature
+        verification certificate chain that the KDC can use to
+        verify the signature over the AuthPack.  The certificate
+        chain(s) MUST NOT contain the root CA certificate.
+
+    5.  If a Diffie-Hellman key is being used, the parameters MUST
+        be chosen from Oakley Group 2 or 14.  Implementations MUST
+        support Group 2; they are RECOMMENDED to support Group 14.
+        (See RFC 2409 [10].)
+
+    6.  The KDC may wish to use cached Diffie-Hellman parameters.
+        To indicate acceptance of caching, the client sends zero in
+        the nonce field of the pkAuthenticator.  Zero is not a valid
+        value for this field under any other circumstances.  Since
+        zero is used to indicate acceptance of cached parameters,
+        message binding in this case is performed using only the
+        nonce in the main request.
+
+
+3.2.2.  Validation of Client Request
+
+Upon receiving the client's request, the KDC validates it.  This
+section describes the steps that the KDC MUST (unless otherwise
+noted) take in validating the request.
+
+The KDC must look for a client certificate in the signedAuthPack.
+If it cannot find one signed by a CA it trusts, it sends back an
+error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
+e-data for this error is a TYPED-DATA (as defined in [1]).  For this
+error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is
+the DER encoding of
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+If, while verifying the certificate chain, the KDC determines that
+the signature on one of the certificates in the signedAuthPack is
+invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+The accompanying e-data for this error is a TYPED-DATA, whose
+data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
+encoding of the index into the CertificateSet field, ordered as sent
+by the client:
+
+    CertificateIndex ::= IssuerAndSerialNumber
+                                    -- IssuerAndSerialNumber of
+                                    -- certificate with invalid signature
+
+If more than one certificate signature is invalid, the KDC MAY send
+one TYPED-DATA per invalid signature.
+
+The KDC MAY also check whether any certificates in the client's
+chain have been revoked.  If any of them have been revoked, the KDC
+MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
+attempts to determine the revocation status but is unable to do so,
+it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
+The certificate or certificates affected are identified exactly as
+for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
+
+In addition to validating the certificate chain, the KDC MUST also
+check that the certificate properly maps to the client's principal name
+as specified in the AS-REQ as follows:
+
+    1.  If the KDC has its own mapping from the name in the
+        certificate to a Kerberos name, it uses that Kerberos
+        name.
+
+    2.  Otherwise, if the certificate contains a SubjectAltName
+        extension with a Kerberos name in the otherName field,
+        it uses that name. The otherName field (of type AnotherName)
+        in the SubjectAltName extension MUST contain the following:
+
+        The type-id is:
+
+        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
+        internet (1) security (5) kerberosv5 (2) 2 }
+
+        The value is:
+
+        KRB5PrincipalName ::= SEQUENCE {
+            realm                   [0] Realm,
+            principalName           [1] PrincipalName
+        }
+
+If the KDC does not have its own mapping and there is no Kerberos
+name present in the certificate, or if the name in the request does
+not match the name in the certificate (including the realm name), or
+if there is no name in the request, the KDC MUST return error code
+KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+for this error.
+
+Even if the chain is validated, and the names in the certificate and
+the request match, the KDC may decide not to trust the client.  For
+example, the certificate may include an Extended Key Usage (EKU) OID
+in the extensions field.  As a matter of local policy, the KDC may
+decide to reject requests on the basis of the absence or presence of
+specific EKU OIDs.  In this case, the KDC MUST return error code
+KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
+
+    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+      pkinit(3) pkekuoid(4) }
+
+If the client's signature on the signedAuthPack fails to verify, the KDC
+MUST return error KDC_ERR_INVALID_SIG.  There is no accompanying
+e-data for this error.
+
+The KDC MUST check the timestamp to ensure that the request is not
+a replay, and that the time skew falls within acceptable limits.
+The recommendations clock skew times in [1] apply here.  If the
+check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or
+KRB_AP_ERR_SKEW, respectively.
+
+If the clientPublicValue is filled in, indicating that the client
+wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
+see if the parameters satisfy its policy.  If they do not, it MUST
+return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is a
+TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
+data-value is the DER encoding of a DomainParameters (see [3]),
+including appropriate Diffie-Hellman parameters with which to retry
+the request.
+
+The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
+client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
+not have the corresponding certificate.
+
+The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
+did not include a kdcCert field, but did include a trustedCertifiers
+field, and the KDC does not possesses a certificate issued by one of
+the listed certifiers.
+
+If there is a supportedCMSTypes field in the AuthPack, the KDC must
+check to see if it supports any of the listed types.  If it supports
+more than one of the types, the KDC SHOULD use the one listed first.
+If it does not support any of them, it MUST return an error of type
+KRB5KDC_ERR_ETYPE_NOSUPP.
+
+
+3.2.3.  KDC Reply
+
+Assuming that the client's request has been properly validated, the
+KDC proceeds as per [1], except as follows.
+
+The KDC MUST set the initial flag and include an authorization data
+of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
+an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        Validated               [1] BOOLEAN,
+        ...
+    }
+
+The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+containers if the list of CAs satisfies the KDC's realm's policy.
+(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
+Furthermore, any TGS must copy such authorization data from tickets
+used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
+including the AD-IF-RELEVANT container, if present.
+
+Application servers that understand this authorization data type
+SHOULD apply local policy to determine whether a given ticket
+bearing such a type *not* contained within an AD-IF-RELEVANT
+container is acceptable.  (This corresponds to the AP server
+checking the transited field when the TRANSITED-POLICY-CHECKED flag
+has not been set.)  If such a data type is contained within an
+AD-IF-RELEVANT container, AP servers MAY apply local policy to
+determine whether the authorization data is acceptable.
+
+The AS-REP is otherwise unchanged from [1].  The KDC encrypts the
+reply as usual, but not with the client's long-term key.  Instead,
+it encrypts it with either a generated encryption key, or a key
+derived from a Diffie-Hellman exchange. The contents of the
+PA-PK-AS-REP indicate the type of encryption key that was used:
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] IMPLICIT WrapContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is KDCDHKeyInfo
+                                    -- (defined below).
+        encKeyPack              [1] IMPLICIT WrapContentInfo,
+                                    -- Type is EnvelopedData.
+                                    -- Content is SignedData over
+                                    -- ReplyKeyPack (defined below).
+        ...
+    }
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+                                    -- Equals public exponent
+                                    -- (g^a mod p).
+                                    -- INTEGER encoded as payload
+                                    -- of BIT STRING.
+        nonce                   [1] INTEGER (0..4294967295),
+                                    -- Binds reply to request.
+                                    -- Exception: A value of zero
+                                    -- indicates that the KDC is
+                                    -- using cached values.
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                                    -- Expiration time for KDC's
+                                    -- cached values.
+        ...
+    }
+
+The fields of the ContentInfo for dhSignedData are to be filled in
+as follows:
+
+    1.  The eContent field contains data of type KDCDHKeyInfo.
+
+    2.  The eContentType field contains the OID value for
+        id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the KDCDHKeyInfo.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the KDCDHKeyInfo.  This field may only
+        be left empty if the client did include a kdcCert field in
+        the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.  The certificate chain MUST NOT contain the
+        root CA certificate.
+
+    5.  If the client and KDC agree to use cached parameters, the
+        KDC MUST return a zero in the nonce field and include the
+        expiration time of the cached values in the dhKeyExpiration
+        field.  If this time is exceeded, the client MUST NOT use
+        the reply.  If the time is absent, the client MUST NOT use
+        the reply and MAY resubmit a request with a non-zero nonce,
+        thus indicating non-acceptance of the cached parameters.
+
+The KDC reply key is derived as follows:
+
+    1.  Both the KDC and the client calculate the shared secret
+        value
+
+            DHKey = g^(ab) mod p
+
+        where a and b are the client's and KDC's private exponents,
+        respectively.  DHKey, padded first with leading zeros as
+        needed to make it as long as the modulus p, is represented
+        as a string of octets in big-endian order (such that the
+        size of DHKey in octets is the size of the modulus p).
+
+    2.  Let K be the key-generation seed length [6] of the reply key
+        whose enctype is selected according to [1].
+
+    3.  Define the function octetstring2key() as follows:
+
+            octetstring2key(h, x) == random-to-key(K-truncate(
+                                         h(0x00 | x) |
+                                         h(0x01 | x) |
+                                         h(0x02 | x) |
+                                         ...
+                                     ))
+
+        where x is an octet string; h:octet string -> octet string
+        is a cryptographically strong hash function; | is the
+        concatenation operator; 0x00, 0x01, 0x02, etc. are each
+        represented as a single octet; random-to-key() is an
+        operation that generates a protocolkey from a bitstring of
+        length K; and K-truncate truncates its input to K bits.
+        Both K and random-to-key() are defined in the kcrypto
+        profile [6] for the enctype of the reply key.
+
+        A good example of h() is SHA1.
+
+    4.  Define H to be a hash function based on operations of a
+        given checksum type [6], as follows:
+
+            H(x) = get_mic(dummy-key, x)
+
+        where x is an octet string.
+
+        H() MUST be a cryptographically strong hash, in order to be
+        suitable for use in the octetstring2key() operation above.
+
+    5.  The client specifies a checksum type to use in the
+        paChecksum of the PKAuthenticator.  If the H() operation
+        based on this checksum is not suitable for use in
+        octetstring2key(), or this checksum type is too weak or not
+        supported by the KDC, the KDC MUST return an error of type
+        KDC_ERR_PA_CKSUMTYPE_NOT_SUPPORTED.  The accompanying e-data
+        for this error is a TYPED-DATA: the data-type is
+        TD-UNKEYED-CHECKSUM-INFO, and the data-value is the DER
+        encoding of
+
+            UNKEYED-CHECKSUM-INFO ::= SEQUENCE OF SEQUENCE {
+                cksumtype       [0] Int32,
+                ...
+            }
+
+        This list is in the preference order (best choice first) of
+        the KDC, and the client SHOULD retry with the first
+        available checksum type.
+
+    6.  When cached DH parameters are used, let n_c be the
+        clientDHNonce, and n_k be the serverDHNonce; otherwise, let
+        both n_c and n_k be empty octet strings.  The reply key k is
+
+            k = octetstring2key(H, DHKey | n_c | n_k)
+
+        where H() is the hash function based on the checksum type
+        used in the paChecksum of the PKAuthenticator (as defined in
+        step 4).
+
+Both the KDC and the client calculate
+the value g^(ab) mod p, where a and b are the client's and KDC's
+private exponents, respectively.  They both take the first k bits of
+this secret value as a key generation seed, where the parameter k
+(the size of the seed) is dependent on the selected key type, as
+specified in [6].  The seed is then converted into a protocol key by
+applying to it a random-to-key function, which is also dependent on
+key type.
+
+If the KDC and client are not using Diffie-Hellman, the KDC encrypts
+the reply with an encryption key, packed in the encKeyPack, which
+contains data of type ReplyKeyPack:
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- Defined in [1].
+                                    -- Used to encrypt main reply.
+                                    -- MUST be at least as strong
+                                    -- as session key.  (Using the
+                                    -- same enctype and a strong
+                                    -- prng should suffice, if no
+                                    -- stronger encryption system
+                                    -- is available.)
+        nonce                   [1] INTEGER (0..4294967295),
+                                    -- Binds reply to request.
+        ...
+    }
+
+The fields of the ContentInfo for encKeyPack MUST be filled in as
+follows:
+
+    1.  The content is of type SignedData.  The eContent for
+        the SignedData is of type ReplyKeyPack.
+
+    2.  The eContentType for the SignedData contains the OID value
+        for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the ReplyKeyPack.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the ReplyKeyPack.  This field may only
+        be left empty if the client included a kdcCert field in the
+        PA-PK-AS-REQ, indicating that it has the KDC's certificate.
+        The certificate chain MUST NOT contain the root CA
+        certificate.
+
+    5.  The contentType for the EnvelopedData contains the OID value
+        for id-signedData: { iso (1) member-body (2) us (840) rsadsi
+        (113549) pkcs (1) pkcs7 (7) signedData (2) }
+
+    6.  The recipientInfos field is a SET which MUST contain exactly
+        one member of type KeyTransRecipientInfo.  The encryptedKey
+        for this member contains the temporary key which is
+        encrypted using the client's public key.
+
+    7.  The unprotectedAttrs or originatorInfo fields MAY be
+        present.
+
+
+3.2.4.  Validation of KDC Reply
+
+Upon receipt of the KDC's reply, the client proceeds as follows.  If
+the PA-PK-AS-REP contains a dhSignedData, the client obtains and
+verifies the Diffie-Hellman parameters, and obtains the shared key
+as described above.  Otherwise, the message contains an encKeyPack,
+and the client decrypts and verifies the temporary encryption key.
+
+In either case, the client MUST check to see if the included
+certificate contains a subjectAltName extension of type dNSName or
+iPAddress (if the KDC is specified by IP address instead of name).
+If it does, it MUST check to see if that extension matches the KDC
+it believes it is communicating with, with matching rules specified
+in RFC 2459.  Exception: If the client has some external information
+as to the identity of the KDC, this check MAY be omitted.
+
+The client also MUST check that the KDC's certificate contains an
+extendedKeyUsage OID of id-pkkdcekuoid:
+
+    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+      pkinit(3) pkkdcekuoid(5) }
+
+If all applicable checks are satisfied, the client then decrypts the
+main reply with the resulting key, and then proceeds as described in
+[1].
+
+
+4.  Security Considerations
+
+PKINIT raises certain security considerations beyond those that can
+be regulated strictly in protocol definitions.  We will address them
+in this section.
+
+PKINIT extends the cross-realm model to the public-key
+infrastructure.  Users of PKINIT must understand security policies
+and procedures appropriate to the use of Public Key Infrastructures.
+
+Standard Kerberos allows the possibility of interactions between
+cryptosystems of varying strengths; this document adds interactions
+with public-key cryptosystems to Kerberos.  Some administrative
+policies may allow the use of relatively weak public keys.  Using
+such keys to wrap data encrypted under stronger conventional
+cryptosystems may be inappropriate.
+
+PKINIT requires keys for symmetric cryptosystems to be generated.
+Some such systems contain "weak" keys.  For recommendations regarding
+these weak keys, see [1].
+
+PKINIT allows the use of a zero nonce in the PKAuthenticator when
+cached Diffie-Hellman keys are used.  In this case, message binding
+is performed using the nonce in the main request in the same way as
+it is done for ordinary AS-REQs (without the PKINIT
+pre-authenticator).  The nonce field in the KDC request body is
+signed through the checksum in the PKAuthenticator, which
+cryptographically binds the PKINIT pre-authenticator to the main
+body of the AS Request and also provides message integrity for the
+full AS Request.
+
+However, when a PKINIT pre-authenticator in the AS-REP has a
+zero-nonce, and an attacker has somehow recorded this
+pre-authenticator and discovered the corresponding Diffie-Hellman
+private key (e.g., with a brute-force attack), the attacker will be
+able to fabricate his own AS-REP messages that impersonate the KDC
+with this same pre-authenticator.  This compromised pre-authenticator
+will remain valid as long as its expiration time has not been reached
+and it is therefore important for clients to check this expiration
+time and for the expiration time to be reasonably short, which
+depends on the size of the Diffie-Hellman group.
+
+If a client also caches its Diffie-Hellman keys, then the session key
+could remain the same during multiple AS-REQ/AS-REP exchanges and an
+attacker which compromised the session key could fabricate his own
+AS-REP messages with a pre-recorded pre-authenticator until the
+client starts using a new Diffie-Hellman key pair and while the KDC
+pre-authenticator has not yet expired.  It is therefore not
+recommended for KDC clients to also cache their Diffie-Hellman keys.
+
+Care should be taken in how certificates are chosen for the purposes
+of authentication using PKINIT.  Some local policies may require
+that key escrow be used for certain certificate types.  Deployers of
+PKINIT should be aware of the implications of using certificates that
+have escrowed keys for the purposes of authentication.
+
+PKINIT does not provide for a "return routability" test to prevent
+attackers from mounting a denial-of-service attack on the KDC by
+causing it to perform unnecessary and expensive public-key
+operations.  Strictly speaking, this is also true of standard
+Kerberos, although the potential cost is not as great, because
+standard Kerberos does not make use of public-key cryptography.
+
+The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+be used if the KDC itself vouches for the user's certificate.  [This
+seems to reflect the consensus of the Kerberos working group.]
+
+
+5.  Acknowledgements
+
+The following people have made significant contributions to this
+draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas
+Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman.
+
+Some of the ideas on which this document 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
+document approaches those goals primarily from the Kerberos
+perspective.  Lastly, comments from groups working on similar ideas
+in DCE have been invaluable.
+
+
+6.  Expiration Date
+
+This draft expires January 25, 2004.
+
+
+7.  Bibliography
+
+[1] RFC-Editor: To be replaced by RFC number for
+draft-ietf-krb-wg-kerberos-clarifications.
+
+[2] R. Housley. Cryptographic Message Syntax. April 1999.  Request
+For Comments 2630.
+
+[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
+for the Internet X.509 Public Key Infrastructure Certificate and
+Certificate Revocation List (CRL) Profile, April 2002. Request For
+Comments 3279.
+
+[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
+Key Infrastructure Certificate and Certificate Revocation List
+(CRL) Profile, April 2002. Request for Comments 3280.
+
+[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+Specifications, October 1998.  Request for Comments 2437.
+
+[6] RFC-Editor: To be replaced by RFC number for
+draft-ietf-krb-wg-crypto.
+
+[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
+T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
+Request for Comments 3546.
+
+[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
+Internet X.509 Public Key Infrastructure: Online Certificate Status
+Protocol - OCSP, June 1999.  Request for Comments 2560.
+
+[9] NIST, Guidelines for Implementing and Using the NBS Encryption
+Standard, April 1981.  FIPS PUB 74.
+
+[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
+November 1998.  Request for Comments 2409.
+
+[11] K. Raeburn.  Unkeyed SHA-1 Checksum Specification for Kerberos
+5.  Internet-Draft, draft-ietf-krb-wg-sha1-00.txt.
+
+[12] S. Bradner.  Key Words for Use in RFCs to Indicate Requirement
+Levels.  March 1997.  Request for Comments 2119 (BCP 14).
+
+
+8.  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
+Ari Medvinsky
+Microsoft Corporation
+One Microsoft Way
+Redmond WA 98052
+Phone: +1 425 707 3336
+E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
+
+Sasha Medvinsky
+Motorola, Inc.
+6450 Sequence Drive
+San Diego, CA 92121
++1 858 404 2367
+E-mail: smedvinsky@motorola.com
+
+John Wray
+Iris Associates, Inc.
+5 Technology Park Dr.
+Westford, MA 01886
+E-mail: John_Wray@iris.com
+
+Jonathan Trostle
+E-mail: jtrostle@world.std.com
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+KerberosV5-PK-INIT-SPEC {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) pkinit(TBD)
+} DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+    IMPORTS
+        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
+            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+              dod (6) internet (1) security (5) mechanisms (5)
+              pkix (7) id-mod (0) id-pkix1-explicit (18) }
+
+        ContentInfo, IssuerAndSerialNumber
+            FROM CryptographicMessageSyntax { iso(1) member-body(2)
+              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
+              modules(0) cms(1) }
+
+        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+              krb5spec2(2) } ;
+
+    id-pkinit  OBJECT IDENTIFIER ::=
+      { iso (1) org (3) dod (6) internet (1) security (5)
+        kerberosv5 (2) pkinit (3) }
+
+    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+    id-pkkdcekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+    pa-pk-as-req INTEGER ::=                 TBD
+    pa-pk-as-rep INTEGER ::=                 TBD
+    pa-pk-ocsp-req INTEGER ::=               TBD
+    pa-pk-ocsp-rep INTEGER ::=               TBD
+
+    ad-initial-verified-cas INTEGER ::=      TBD
+
+    td-dh-parameters INTEGER ::=             TBD
+    td-trusted-certifiers INTEGER ::=        104
+    td-certificate-index INTEGER ::=         105
+
+    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- ContentInfo
+    })
+
+    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- IssuerAndSerialNumber
+    })
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] IMPLICIT WrapContentInfo,
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
+                                    OPTIONAL,
+        ...
+    }
+
+    TrustedCA ::= CHOICE {
+        caName                  [1] Name,
+        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                    OPTIONAL,
+        ...
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER (0..999999),
+        ctime                   [1] KerberosTime,
+        nonce                   [2] INTEGER (0..4294967295),
+        paChecksum              [3] Checksum,
+        ...
+    }
+
+    TrustedCertifiers ::= SEQUENCE OF Name
+
+    CertificateIndex ::= IssuerAndSerialNumber
+
+    KRB5PrincipalName ::= SEQUENCE {
+        realm                   [0] Realm,
+        principalName           [1] PrincipalName
+    }
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        validated               [1] BOOLEAN,
+        ...
+    }
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] IMPLICIT WrapContentInfo,
+        encKeyPack              [1] IMPLICIT WrapContentInfo,
+        ...
+    }
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+        nonce                   [1] INTEGER (0..4294967295),
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+        ...
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+        nonce                   [1] INTEGER (0..4294967295),
+        ...
+    }
+
+END
+
+Copyright (C) The Internet Society 2004.  This document is subject
+to the rights, licenses and restrictions contained in BCP 78, and
+except as set forth therein, the authors retain all their rights.
+
+This document and the information contained herein are provided on
+an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+INTERNET ENGINEERING TASK FORCE DISCLAIM 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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt
new file mode 100644
index 00000000000..7f9fe5df65e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt
@@ -0,0 +1,1016 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-22.txt                   Clifford Neuman
+expires May 15, 2005                                             USC/ISI
+                                                         Sasha Medvinsky
+                                                          Motorola, Inc.
+                                                               Larry Zhu
+                                                               Microsoft
+
+
+    Public Key Cryptography for Initial Authentication in Kerberos
+
+
+0.  Status Of This Memo
+
+By submitting this Internet-Draft, I certify that any applicable
+patent or other IPR claims of which I am aware have been disclosed,
+or will be disclosed, and any of which I become aware will be
+disclosed, in accordance with RFC 3668.
+
+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-ietf-cat-kerberos-pk-init-22.txt and expires May 15, 2005.
+Please send comments to the authors.
+
+
+1.  Abstract
+
+This document describes protocol extensions (hereafter called
+PKINIT) to the Kerberos protocol specification [1].  These
+extensions provide a method for integrating public key cryptography
+into the initial authentication exchange, by passing digital
+certificates and associated authenticators in preauthentication data
+fields.
+
+
+2.  Introduction
+
+A client typically authenticates itself to a service in Kerberos
+using three distinct though related exchanges.  First, the client
+requests a ticket-granting ticket (TGT) from the Kerberos
+authentication server (AS).  Then, it uses the TGT to request a
+service ticket from the Kerberos ticket-granting server (TGS).
+Usually, the AS and TGS are integrated in a single device known as
+a Kerberos Key Distribution Center, or KDC.  (In this document, we
+will refer to both the AS and the TGS as the KDC.)  Finally, the
+client uses the service ticket to authenticate itself to the
+service.
+
+The advantage afforded by the TGT is that the client need explicitly
+request a ticket and expose his credentials only once.  The TGT and
+its associated session key can then be used for any subsequent
+requests.  One result of this is that all further authentication is
+independent of the method by which the initial authentication was
+performed.  Consequently, initial authentication provides a
+convenient place to integrate public-key cryptography into Kerberos
+authentication.
+
+As defined, Kerberos authentication exchanges use symmetric-key
+cryptography, in part for performance.  One cost of using
+symmetric-key cryptography is that the keys must be shared, so that
+before a client can authenticate itself, he must already be
+registered with the KDC.
+
+Conversely, public-key cryptography (in conjunction with an
+established Public Key Infrastructure) permits authentication
+without prior registration with a KDC.  Adding it to Kerberos allows
+the widespread use of Kerberized applications by clients without
+requiring them to register first with a KDC--a requirement that has
+no inherent security benefit.
+
+As noted above, a convenient and efficient place to introduce
+public-key cryptography into Kerberos is in the initial
+authentication exchange.  This document describes the methods and
+data formats for integrating public-key cryptography into Kerberos
+initial authentication.
+
+
+3.  Extensions
+
+This section describes extensions to [1] for supporting the use of
+public-key cryptography in the initial request for a ticket.
+
+Briefly, this document defines the following extensions to [1]:
+
+    1.  The client indicates the use of public-key authentication by
+        including a special preauthenticator in the initial request.
+        This preauthenticator contains the client's public-key data
+        and a signature.
+
+    2.  The KDC tests the client's request against its policy and
+        trusted Certification Authorities (CAs).
+
+    3.  If the request passes the verification tests, the KDC
+        replies as usual, but the reply is encrypted using either:
+
+        a.  a symmetric encryption key, signed using the KDC's
+            signature key and encrypted using the client's encryption
+            key; or
+
+        b.  a key generated through a Diffie-Hellman exchange with
+            the client, signed using the KDC's signature key.
+
+        Any keying material required by the client to obtain the
+        Encryption key is returned in a preauthentication field
+        accompanying the usual reply.
+
+    4.  The client obtains the encryption key, decrypts the reply,
+        and then proceeds as usual.
+
+Section 3.1 of this document defines the necessary message formats.
+Section 3.2 describes their syntax and use in greater detail.
+
+
+3.1.  Definitions, Requirements, and Constants
+
+
+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 [12].
+
+
+3.1.1.  Required Algorithms
+
+All PKINIT implementations MUST support the following algorithms:
+
+    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
+
+    - Signature algorithm: SHA-1 digest and RSA.
+
+    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
+      with a non-zero nonce.
+
+    - Unkeyed checksum type for the paChecksum member of
+      PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
+      [11].
+
+
+3.1.2.  Defined Message and Encryption Types
+
+PKINIT makes use of the following new preauthentication types:
+
+    PA-PK-AS-REQ                             TBD
+    PA-PK-AS-REP                             TBD
+    PA-PK-AS-ERR                             TBD
+
+PKINIT also makes use of the following new authorization data type:
+
+    AD-INITIAL-VERIFIED-CAS                  TBD
+
+PKINIT introduces the following new error codes:
+
+    KDC_ERR_CLIENT_NOT_TRUSTED                62
+    KDC_ERR_KDC_NOT_TRUSTED                   63
+    KDC_ERR_INVALID_SIG                       64
+    KDC_ERR_KEY_SIZE                          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_CLIENT_NAME_MISMATCH              75
+
+PKINIT uses the following typed data types for errors:
+
+    TD-DH-PARAMETERS                         TBD
+    TD-TRUSTED-CERTIFIERS                    104
+    TD-CERTIFICATE-INDEX                     105
+    TD-UNKEYED-CHECKSUM-INFO                 109
+
+PKINIT defines the following encryption types, for use in the AS-REQ
+message (to indicate acceptance of the corresponding encryption OIDs
+in PKINIT):
+
+    dsaWithSHA1-CmsOID                         9
+    md5WithRSAEncryption-CmsOID               10
+    sha1WithRSAEncryption-CmsOID              11
+    rc2CBC-EnvOID                             12
+    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
+    des-ede3-cbc-EnvOID                       15
+
+The above encryption types are used by the client only within the
+KDC-REQ-BODY to indicate which CMS [14] algorithms it supports.  Their
+use within Kerberos EncryptedData structures is not specified by this
+document.
+
+The ASN.1 module for all structures defined in this document (plus
+IMPORT statements for all imported structures) are given in Appendix
+A.  In the event of a discrepancy between Appendix A and the portions
+of ASN.1 in the main text, the appendix is normative.
+
+All structures defined in this document MUST be encoded using
+Distinguished Encoding Rules (DER).  All imported data structures
+must be encoded according to the rules specified in Kerberos [1] or
+CMS [2] as appropriate.
+
+Interoperability note: Some implementations may not be able to
+decode CMS objects encoded with BER but not DER; specifically, they
+may not be able to decode infinite length encodings.  To maximize
+interoperability, implementers SHOULD encode CMS objects used in
+PKINIT with DER.
+
+
+3.1.3.  Algorithm Identifiers
+
+PKINIT does not define, but does make use of, the following
+algorithm identifiers.
+
+PKINIT uses the following algorithm identifier for Diffie-Hellman
+key agreement [9]:
+
+    dhpublicnumber
+
+PKINIT uses the following signature algorithm identifiers [8, 12]:
+
+    sha-1WithRSAEncryption (RSA with SHA1)
+    md5WithRSAEncryption   (RSA with MD5)
+    id-dsa-with-sha1       (DSA with SHA1)
+
+PKINIT uses the following encryption algorithm identifiers [5] for
+encrypting the temporary key with a public key:
+
+    rsaEncryption          (PKCS1 v1.5)
+    id-RSAES-OAEP          (PKCS1 v2.0)
+
+PKINIT uses the following algorithm identifiers [14, 8] for
+encrypting the reply key with the temporary key:
+
+    des-ede3-cbc           (three-key 3DES, CBC mode)
+    rc2-cbc                (RC2, CBC mode)
+    id-aes256-CBC          (AES-256, CBC mode)
+
+
+3.2.  PKINIT Preauthentication Syntax and Use
+
+This section defines the syntax and use of the various
+preauthentication fields employed by PKINIT.
+
+
+3.2.1.  Client Request
+
+The initial authentication request (AS-REQ) is sent as per [1]; in
+addition, a preauthentication field contains data signed by the
+client's private signature key, as follows:
+
+    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- ContentInfo
+    })
+
+    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- IssuerAndSerialNumber
+    })
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] IMPLICIT WrapContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is AuthPack
+                                    -- (defined below).
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                                    -- A list of CAs, trusted by
+                                    -- the client, used to certify
+                                    -- KDCs.
+        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
+                                    OPTIONAL,
+                                    -- Identifies a particular KDC
+                                    -- certificate, if the client
+                                    -- already has it.
+        ...
+    }
+
+    TrustedCA ::= CHOICE {
+        caName                  [1] Name,
+                                    -- Fully qualified X.500 name
+                                    -- as defined in RFC 3280 [4].
+        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
+                                    -- Identifies a specific CA
+                                    -- certificate.
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                                    -- Defined in RFC 3280 [4].
+                                    -- Present only if the client
+                                    -- is using ephemeral-ephemeral
+                                    -- Diffie-Hellman.
+        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                    OPTIONAL,
+                                    -- List of CMS encryption types
+                                    -- supported by client in order
+                                    -- of (decreasing) preference.
+        ...
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER (0..999999),
+        ctime                   [1] KerberosTime,
+                                    -- cusec and ctime are used as
+                                    -- in [1], for replay
+                                    -- prevention.
+        nonce                   [2] INTEGER (0..4294967295),
+                                    -- Binds reply to request,
+                                    -- MUST be zero when client
+                                    -- will accept cached
+                                    -- Diffie-Hellman parameters
+                                    -- from KDC. MUST NOT be
+                                    -- zero otherwise.
+        paChecksum              [3] OCTET STRING OPTIONAL,
+                                    -- Defined in [1].
+                                    -- Performed over KDC-REQ-BODY,
+                                    -- MUST be unkeyed.
+        ...
+    }
+
+The ContentInfo in the signedAuthPack is filled out as follows:
+
+    1.  The eContent field MUST contain data of type AuthPack.
+        The supportedCMSTypes field is filled with the algorithm
+        identifiers that the client supports, in order of
+        preference, with most preferred first.
+
+    2.  The eContentType field MUST contain the OID value for
+        id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
+
+    3.  The signerInfos field MUST contain the signature over the
+        AuthPack.
+
+    4.  The certificates field MUST contain at least a signature
+        verification certificate chain that the KDC can use to
+        verify the signature over the AuthPack.  The certificate
+        chain(s) MUST NOT contain the root CA certificate.
+
+    5.  If a Diffie-Hellman key is being used, the parameters MUST
+        be chosen from Oakley Group 2 or 14.  Implementations MUST
+        support Group 2; they are RECOMMENDED to support Group 14.
+        (See RFC 2409 [10] and RFC 3526 [13].)
+
+    6.  The KDC may wish to use cached Diffie-Hellman parameters.
+        To indicate acceptance of caching, the client sends zero in
+        the nonce field of the pkAuthenticator.  Zero is not a valid
+        value for this field under any other circumstances.  Since
+        zero is used to indicate acceptance of cached parameters,
+        message binding in this case is performed using only the
+        nonce in the main request.
+
+
+3.2.2.  Validation of Client Request
+
+Upon receiving the client's request, the KDC validates it.  This
+section describes the steps that the KDC MUST (unless otherwise
+noted) take in validating the request.
+
+The KDC must look for a client certificate in the signedAuthPack.
+If it cannot find one signed by a CA it trusts, it sends back an
+error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
+e-data for this error is a TYPED-DATA (as defined in [1]).  For this
+error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is
+the DER encoding of
+
+    KDCTrustedCertifiers ::= SEQUENCE OF Name
+
+If, while verifying the certificate chain, the KDC determines that
+the signature on one of the certificates in the signedAuthPack is
+invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+The accompanying e-data for this error is a TYPED-DATA, whose
+data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
+encoding of the index into the CertificateSet field, ordered as sent
+by the client:
+
+    CertificateIndex ::= IssuerAndSerialNumber
+                                    -- IssuerAndSerialNumber of
+                                    -- certificate with invalid signature
+
+If more than one certificate signature is invalid, the KDC MAY send
+one TYPED-DATA per invalid signature.
+
+The KDC MAY also check whether any certificates in the client's
+chain have been revoked.  If any of them have been revoked, the KDC
+MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
+attempts to determine the revocation status but is unable to do so,
+it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
+The certificate or certificates affected are identified exactly as
+for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
+
+In addition to validating the certificate chain, the KDC MUST also
+check that the certificate properly maps to the client's principal name
+as specified in the AS-REQ as follows:
+
+    1.  If the KDC has its own mapping from the name in the
+        certificate to a Kerberos name, it uses that Kerberos
+        name.
+
+    2.  Otherwise, if the certificate contains a SubjectAltName
+        extension with a Kerberos name in the otherName field,
+        it uses that name. The otherName field (of type AnotherName)
+        in the SubjectAltName extension MUST contain the following:
+
+        The type-id is:
+
+            krb5PrincipalName OBJECT IDENTIFIER ::= {
+                iso (1) org (3) dod (6) internet (1) security (5)
+                kerberosv5 (2) 2
+            }
+
+        The value is:
+
+            KRB5PrincipalName ::= SEQUENCE {
+                realm                   [0] Realm,
+                principalName           [1] PrincipalName
+            }
+
+If the KDC does not have its own mapping and there is no Kerberos
+name present in the certificate, or if the name in the request does
+not match the name in the certificate (including the realm name), or
+if there is no name in the request, the KDC MUST return error code
+KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
+for this error.
+
+Even if the chain is validated, and the names in the certificate and
+the request match, the KDC may decide not to trust the client.  For
+example, the certificate may include an Extended Key Usage (EKU) OID
+in the extensions field.  As a matter of local policy, the KDC may
+decide to reject requests on the basis of the absence or presence of
+specific EKU OIDs.  In this case, the KDC MUST return error code
+KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
+
+    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+      pkinit(3) pkekuoid(4) }
+
+If the client's signature on the signedAuthPack fails to verify, or
+if there is no paChecksum field, the KDC MUST return error
+KDC_ERR_INVALID_SIG.  There is no accompanying e-data for this
+error.
+
+The KDC MUST check the timestamp to ensure that the request is not
+a replay, and that the time skew falls within acceptable limits.
+The recommendations clock skew times in [1] apply here.  If the
+check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or
+KRB_AP_ERR_SKEW, respectively.
+
+If the clientPublicValue is filled in, indicating that the client
+wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
+see if the parameters satisfy its policy.  If they do not, it MUST
+return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is a
+TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
+data-value is the DER encoding of a DomainParameters (see [3]),
+including appropriate Diffie-Hellman parameters with which to retry
+the request.
+
+The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
+client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
+not have the corresponding certificate.
+
+The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
+did not include a kdcCert field, but did include a trustedCertifiers
+field, and the KDC does not possesses a certificate issued by one of
+the listed certifiers.
+
+If there is a supportedCMSTypes field in the AuthPack, the KDC must
+check to see if it supports any of the listed types.  If it supports
+more than one of the types, the KDC SHOULD use the one listed first.
+If it does not support any of them, it MUST return an error of type
+KRB5KDC_ERR_ETYPE_NOSUPP.
+
+
+3.2.3.  KDC Reply
+
+Assuming that the client's request has been properly validated, the
+KDC proceeds as per [1], except as follows.
+
+The KDC MUST set the initial flag and include an authorization data
+of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
+an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        Validated               [1] BOOLEAN,
+        ...
+    }
+
+The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+containers if the list of CAs satisfies the KDC's realm's policy.
+(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
+Furthermore, any TGS must copy such authorization data from tickets
+used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
+including the AD-IF-RELEVANT container, if present.
+
+Application servers that understand this authorization data type
+SHOULD apply local policy to determine whether a given ticket
+bearing such a type *not* contained within an AD-IF-RELEVANT
+container is acceptable.  (This corresponds to the AP server
+checking the transited field when the TRANSITED-POLICY-CHECKED flag
+has not been set.)  If such a data type is contained within an
+AD-IF-RELEVANT container, AP servers MAY apply local policy to
+determine whether the authorization data is acceptable.
+
+The AS-REP is otherwise unchanged from [1].  The KDC encrypts the
+reply as usual, but not with the client's long-term key.  Instead,
+it encrypts it with either a generated encryption key, or a key
+derived from a Diffie-Hellman exchange. The contents of the
+PA-PK-AS-REP indicate the type of encryption key that was used:
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] IMPLICIT WrapContentInfo,
+                                    -- Type is SignedData.
+                                    -- Content is KDCDHKeyInfo
+                                    -- (defined below).
+        encKeyPack              [1] IMPLICIT WrapContentInfo,
+                                    -- Type is EnvelopedData.
+                                    -- Encrypted using client's
+                                    -- public key certificate.
+                                    -- Content is SignedData over
+                                    -- ReplyKeyPack (defined below).
+        ...
+    }
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+                                    -- Equals public exponent
+                                    -- (g^a mod p).
+                                    -- INTEGER encoded as payload
+                                    -- of BIT STRING.
+        nonce                   [1] INTEGER (0..4294967295),
+                                    -- Binds reply to request.
+                                    -- Exception: A value of zero
+                                    -- indicates that the KDC is
+                                    -- using cached values.
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                                    -- Expiration time for KDC's
+                                    -- cached values.
+        ...
+    }
+
+The fields of the ContentInfo for dhSignedData are to be filled in
+as follows:
+
+    1.  The eContent field contains data of type KDCDHKeyInfo.
+
+    2.  The eContentType field contains the OID value for
+        id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the KDCDHKeyInfo.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the KDCDHKeyInfo.  This field may only
+        be left empty if the client did include a kdcCert field in
+        the PA-PK-AS-REQ, indicating that it has the KDC's
+        certificate.  The certificate chain MUST NOT contain the
+        root CA certificate.
+
+    5.  If the client and KDC agree to use cached parameters, the
+        KDC MUST return a zero in the nonce field and include the
+        expiration time of the cached values in the dhKeyExpiration
+        field.  If this time is exceeded, the client MUST NOT use
+        the reply.  If the time is absent, the client MUST NOT use
+        the reply and MAY resubmit a request with a non-zero nonce,
+        thus indicating non-acceptance of the cached parameters.
+
+The KDC reply key is derived as follows:
+
+    1.  Both the KDC and the client calculate the shared secret
+        value
+
+            DHKey = g^(ab) mod p
+
+        where a and b are the client's and KDC's private exponents,
+        respectively.  DHKey, padded first with leading zeros as
+        needed to make it as long as the modulus p, is represented
+        as a string of octets in big-endian order (such that the
+        size of DHKey in octets is the size of the modulus p).
+
+    2.  Let K be the key-generation seed length [6] of the reply key
+        whose enctype is selected according to [1].
+
+    3.  Define the function octetstring2key() as follows:
+
+            octetstring2key(x) == random-to-key(K-truncate(
+                                         sha1(0x00 | x) |
+                                         sha1(0x01 | x) |
+                                         sha1(0x02 | x) |
+                                         ...
+                                     ))
+
+        where x is an octet string; | is the concatenation operator;
+        0x00, 0x01, 0x02, etc. are each represented as a single
+        octet; random-to-key() is an operation that generates a
+        protocolkey from a bitstring of length K; and K-truncate
+        truncates its input to K bits.  Both K and random-to-key()
+        are defined in the kcrypto profile [6] for the enctype of
+        the reply key.
+
+    4.  When cached DH parameters are used, let n_c be the
+        clientDHNonce, and n_k be the serverDHNonce; otherwise, let
+        both n_c and n_k be empty octet strings.  The reply key k is
+
+            k = octetstring2key(DHKey | n_c | n_k)
+
+If the KDC and client are not using Diffie-Hellman, the KDC encrypts
+the reply with an encryption key, packed in the encKeyPack, which
+contains data of type ReplyKeyPack:
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+                                    -- Defined in [1].
+                                    -- Used to encrypt main reply.
+                                    -- MUST be at least as strong
+                                    -- as session key.  (Using the
+                                    -- same enctype and a strong
+                                    -- prng should suffice, if no
+                                    -- stronger encryption system
+                                    -- is available.)
+        nonce                   [1] INTEGER (0..4294967295),
+                                    -- Binds reply to request.
+        ...
+    }
+
+The fields of the ContentInfo for encKeyPack MUST be filled in as
+follows:
+
+    1.  The content is of type SignedData.  The eContent for
+        the SignedData is of type ReplyKeyPack.
+
+    2.  The eContentType for the SignedData contains the OID value
+        for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
+        security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
+
+    3.  The signerInfos field contains a single signerInfo, which is
+        the signature of the ReplyKeyPack.
+
+    4.  The certificates field contains a signature verification
+        certificate chain that the client will use to verify the
+        KDC's signature over the ReplyKeyPack.  This field may only
+        be left empty if the client included a kdcCert field in the
+        PA-PK-AS-REQ, indicating that it has the KDC's certificate.
+        The certificate chain MUST NOT contain the root CA
+        certificate.
+
+    5.  The contentType for the EnvelopedData contains the OID value
+        for id-signedData: { iso (1) member-body (2) us (840) rsadsi
+        (113549) pkcs (1) pkcs7 (7) signedData (2) }
+
+    6.  The enveloped data MUST contain one KeyTransRecipientInfo,
+        which is targeted to the client's certificate (obtained in
+        the initial request).
+
+    7.  The unprotectedAttrs or originatorInfo fields MAY be
+        present.
+
+
+3.2.4.  Validation of KDC Reply
+
+Upon receipt of the KDC's reply, the client proceeds as follows.  If
+the PA-PK-AS-REP contains a dhSignedData, the client obtains and
+verifies the Diffie-Hellman parameters, and obtains the shared key
+as described above.  Otherwise, the message contains an encKeyPack,
+and the client decrypts and verifies the temporary encryption key.
+
+In either case, the client MUST check to see if the included
+certificate contains a subjectAltName extension of type dNSName or
+iPAddress (if the KDC is specified by IP address instead of name).
+If it does, it MUST check to see if that extension matches the KDC
+it believes it is communicating with, with matching rules specified
+in RFC 2459.  Exception: If the client has some external information
+as to the identity of the KDC, this check MAY be omitted.
+
+The client also MUST check that the KDC's certificate contains an
+extendedKeyUsage OID of id-pkkdcekuoid:
+
+    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+      pkinit(3) pkkdcekuoid(5) }
+
+If all applicable checks are satisfied, the client then decrypts the
+main reply with the resulting key, and then proceeds as described in
+[1].
+
+
+3.2.5.  Indicating PKINIT Support
+
+A KDC that supports PKINIT SHOULD indicate support for PKINIT to
+clients that did not include any or acceptable pre-authentication in
+their AS requests.  As per [1], KDCs respond to such requests with a
+KRB-ERROR with KDC_ERR_PREAUTH_REQUIRED as the error code and with a
+list of pre-authentication data in the KRB-ERROR's e-data field.
+
+To indicate support for PKINIT, then, a KDC MUST include, in
+KDC_ERR_PREAUTH_REQUIRED KRB-ERROR messages, a padata element of
+type PA-PK-AS-ERR.  The padata-value field of this padata element
+MUST be set to the zero-length string; clients MUST ignore this and
+any other value.
+
+A client that receives a KRB-ERROR message, bearing a PA-PK-AS-ERR
+padata element, from a KDC in response to its AS-REQ should take the
+message as an indication of support by the KDC for PKINIT.  The
+client MAY respond by attempting a new AS exchange using its
+preferred pre-authentication mechanism for which the KDC has
+indicated support in its error message and for which the client has
+credentials, possibly including PKINIT.
+
+Future extensions to PKINIT may provide for the use of the value of
+PA-PK-AS-ERR padata elements to indicate such details as KDCs' PKI
+trust anchors, negotiation preferences, etc.
+
+
+4.  Security Considerations
+
+PKINIT raises certain security considerations beyond those that can
+be regulated strictly in protocol definitions.  We will address them
+in this section.
+
+PKINIT extends the cross-realm model to the public-key
+infrastructure.  Users of PKINIT must understand security policies
+and procedures appropriate to the use of Public Key Infrastructures.
+
+Standard Kerberos allows the possibility of interactions between
+cryptosystems of varying strengths; this document adds interactions
+with public-key cryptosystems to Kerberos.  Some administrative
+policies may allow the use of relatively weak public keys.  Using
+such keys to wrap data encrypted under stronger conventional
+cryptosystems may be inappropriate.
+
+PKINIT requires keys for symmetric cryptosystems to be generated.
+Some such systems contain "weak" keys.  For recommendations regarding
+these weak keys, see [1].
+
+PKINIT allows the use of a zero nonce in the PKAuthenticator when
+cached Diffie-Hellman keys are used.  In this case, message binding
+is performed using the nonce in the main request in the same way as
+it is done for ordinary AS-REQs (without the PKINIT
+pre-authenticator).  The nonce field in the KDC request body is
+signed through the checksum in the PKAuthenticator, which
+cryptographically binds the PKINIT pre-authenticator to the main
+body of the AS Request and also provides message integrity for the
+full AS Request.
+
+However, when a PKINIT pre-authenticator in the AS-REP has a
+zero-nonce, and an attacker has somehow recorded this
+pre-authenticator and discovered the corresponding Diffie-Hellman
+private key (e.g., with a brute-force attack), the attacker will be
+able to fabricate his own AS-REP messages that impersonate the KDC
+with this same pre-authenticator.  This compromised pre-authenticator
+will remain valid as long as its expiration time has not been reached
+and it is therefore important for clients to check this expiration
+time and for the expiration time to be reasonably short, which
+depends on the size of the Diffie-Hellman group.
+
+If a client also caches its Diffie-Hellman keys, then the session key
+could remain the same during multiple AS-REQ/AS-REP exchanges and an
+attacker which compromised the session key could fabricate his own
+AS-REP messages with a pre-recorded pre-authenticator until the
+client starts using a new Diffie-Hellman key pair and while the KDC
+pre-authenticator has not yet expired.  It is therefore not
+recommended for KDC clients to also cache their Diffie-Hellman keys.
+
+Care should be taken in how certificates are chosen for the purposes
+of authentication using PKINIT.  Some local policies may require
+that key escrow be used for certain certificate types.  Deployers of
+PKINIT should be aware of the implications of using certificates that
+have escrowed keys for the purposes of authentication.
+
+PKINIT does not provide for a "return routability" test to prevent
+attackers from mounting a denial-of-service attack on the KDC by
+causing it to perform unnecessary and expensive public-key
+operations.  Strictly speaking, this is also true of standard
+Kerberos, although the potential cost is not as great, because
+standard Kerberos does not make use of public-key cryptography.
+
+The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+be used if the KDC itself vouches for the user's certificate.  [This
+seems to reflect the consensus of the Kerberos working group.]
+
+
+5.  Acknowledgements
+
+The following people have made significant contributions to this
+draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas
+Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman.
+
+Some of the ideas on which this document 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
+document approaches those goals primarily from the Kerberos
+perspective.  Lastly, comments from groups working on similar ideas
+in DCE have been invaluable.
+
+
+6.  Expiration Date
+
+This draft expires May 15, 2005.
+
+
+7.  Bibliography
+
+[1] RFC-Editor: To be replaced by RFC number for
+draft-ietf-krb-wg-kerberos-clarifications.
+
+[2] R. Housley. Cryptographic Message Syntax. August 2002.  Request
+For Comments 3369.
+
+[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
+for the Internet X.509 Public Key Infrastructure Certificate and
+Certificate Revocation List (CRL) Profile, April 2002. Request For
+Comments 3279.
+
+[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
+Key Infrastructure Certificate and Certificate Revocation List
+(CRL) Profile, April 2002. Request for Comments 3280.
+
+[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+Specifications, October 1998.  Request for Comments 2437.
+
+[6] RFC-Editor: To be replaced by RFC number for
+draft-ietf-krb-wg-crypto.
+
+[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
+T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
+Request for Comments 3546.
+
+[8] J. Schaad.  Use of the Advanced Encryption Standard (AES)
+Encryption Algorithm in Cryptographic Message Syntax (CMS).  July
+2003.  Request for Comments 3565.
+
+[9] NIST, Guidelines for Implementing and Using the NBS Encryption
+Standard, April 1981.  FIPS PUB 74.
+
+[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
+November 1998.  Request for Comments 2409.
+
+[11] K. Raeburn.  Unkeyed SHA-1 Checksum Specification for Kerberos
+5.  Internet-Draft, draft-ietf-krb-wg-sha1-00.txt.
+
+[12] S. Bradner.  Key Words for Use in RFCs to Indicate Requirement
+Levels.  March 1997.  Request for Comments 2119 (BCP 14).
+
+[13] T. Kivinen, M. Kojo.  More Modular Exponential (MODP) Diffie-
+Hellman Groups for Internet Key Exchange (IKE).  May 2003.  Request
+for Comments 3526.
+
+[14] R. Housley. Cryptographic Message Syntax (CMS) Algorithms.
+August 2002.  Request For Comments 3370.
+
+
+8.  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
+
+Sasha Medvinsky
+Motorola, Inc.
+6450 Sequence Drive
+San Diego, CA 92121
++1 858 404 2367
+E-mail: smedvinsky@motorola.com
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+KerberosV5-PK-INIT-SPEC {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) pkinit(TBD)
+} DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+    IMPORTS
+        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
+            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
+              dod (6) internet (1) security (5) mechanisms (5)
+              pkix (7) id-mod (0) id-pkix1-explicit (18) }
+
+        ContentInfo, IssuerAndSerialNumber
+            FROM CryptographicMessageSyntax { iso(1) member-body(2)
+              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
+              modules(0) cms(1) }
+
+        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
+              krb5spec2(2) } ;
+
+    id-pkinit  OBJECT IDENTIFIER ::=
+      { iso (1) org (3) dod (6) internet (1) security (5)
+        kerberosv5 (2) pkinit (3) }
+
+    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+    id-pkkdcekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+    pa-pk-as-req INTEGER ::=                 TBD
+    pa-pk-as-rep INTEGER ::=                 TBD
+    pa-pk-ocsp-req INTEGER ::=               TBD
+    pa-pk-ocsp-rep INTEGER ::=               TBD
+
+    ad-initial-verified-cas INTEGER ::=      TBD
+
+    td-dh-parameters INTEGER ::=             TBD
+    td-trusted-certifiers INTEGER ::=        104
+    td-certificate-index INTEGER ::=         105
+
+    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- ContentInfo
+    })
+
+    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
+                                    -- Contains a BER encoding of
+                                    -- IssuerAndSerialNumber
+    })
+
+    PA-PK-AS-REQ ::= SEQUENCE {
+        signedAuthPack          [0] IMPLICIT WrapContentInfo,
+        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
+                                    OPTIONAL,
+        ...
+    }
+
+    TrustedCA ::= CHOICE {
+        caName                  [1] Name,
+        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
+        ...
+    }
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                    OPTIONAL,
+        ...
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        cusec                   [0] INTEGER (0..999999),
+        ctime                   [1] KerberosTime,
+        nonce                   [2] INTEGER (0..4294967295),
+        paChecksum              [3] OCTET STRING OPTIONAL,
+        ...
+    }
+
+    KDCTrustedCertifiers ::= SEQUENCE OF Name
+
+    CertificateIndex ::= IssuerAndSerialNumber
+
+    KRB5PrincipalName ::= SEQUENCE {
+        realm                   [0] Realm,
+        principalName           [1] PrincipalName
+    }
+
+    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+        ca                      [0] Name,
+        validated               [1] BOOLEAN,
+        ...
+    }
+
+    PA-PK-AS-REP ::= CHOICE {
+        dhSignedData            [0] IMPLICIT WrapContentInfo,
+        encKeyPack              [1] IMPLICIT WrapContentInfo,
+        ...
+    }
+
+    KDCDHKeyInfo ::= SEQUENCE {
+        subjectPublicKey        [0] BIT STRING,
+        nonce                   [1] INTEGER (0..4294967295),
+        dhKeyExpiration         [2] KerberosTime OPTIONAL,
+        ...
+    }
+
+    ReplyKeyPack ::= SEQUENCE {
+        replyKey                [0] EncryptionKey,
+        nonce                   [1] INTEGER (0..4294967295),
+        ...
+    }
+
+END
+
+Copyright (C) The Internet Society 2004.  This document is subject
+to the rights, licenses and restrictions contained in BCP 78, and
+except as set forth therein, the authors retain all their rights.
+
+This document and the information contained herein are provided on
+an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+INTERNET ENGINEERING TASK FORCE DISCLAIM 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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt
new file mode 100644
index 00000000000..f0cd9cac4c3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt
@@ -0,0 +1,1511 @@
+
+
+
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: August 4, 2005                                           L. Zhu
+                                                   Microsoft Corporation
+                                                        January 31, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                    draft-ietf-cat-kerberos-pk-init
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 4, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by passing digital certificates and
+   associated authenticators in pre-authentication data fields.
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 1]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  6
+       3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . .  9
+       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 12
+       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17
+     3.3   KDC Indication of PKINIT Support . . . . . . . . . . . . . 18
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+     7.1   Normative References . . . . . . . . . . . . . . . . . . . 20
+     7.2   Informative References . . . . . . . . . . . . . . . . . . 21
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
+   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 21
+       Intellectual Property and Copyright Statements . . . . . . . . 27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 2]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  (In this document, we will
+   refer to both the AS and the TGS as the KDC.)  Finally, the client
+   uses the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [CLAR], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce
+   public-key cryptography into Kerberos is in the initial
+   authentication exchange.  This document describes the methods and
+   data formats for integrating public-key cryptography into Kerberos
+   initial authentication.
+
+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 [RFC2119].
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 3]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+3.  Extensions
+
+   This section describes extensions to [CLAR] for supporting the use of
+   public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [CLAR]:
+
+   1.  The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2.  The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3.  If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a.  a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] with the client, signed using the KDC's signature
+         key; or
+
+      b.  a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a
+      pre-authentication field accompanying the usual reply.
+
+   4.  The client obtains the encryption key, decrypts the reply, and
+      then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1  Definitions, Requirements, and Constants
+
+3.1.1  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  KDC AS reply key delivery method: ephemeral-ephemeral
+      Diffie-Hellman exchange (Diffie-Hellman keys are not cached).
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 4]
+
+
+
+3.1.2  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA-PK-AS-REQ                             16
+       PA-PK-AS-REP                             17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD-INITIAL-VERIFIED-CAS                   9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                62
+       KDC_ERR_KDC_NOT_TRUSTED                   63
+       KDC_ERR_INVALID_SIG                       64
+       KDC_ERR_KEY_SIZE                          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_CLIENT_NAME_MISMATCH              75
+
+   PKINIT uses the following typed data types for errors:
+
+       TD-TRUSTED-CERTIFIERS                    104
+       TD-CERTIFICATE-INDEX                     105
+       TD-DH-PARAMETERS                         109
+
+   PKINIT defines the following encryption types, for use in the AS-REQ
+   message (to indicate acceptance of the corresponding encryption
+   Object Identifiers (OIDs) in PKINIT):
+
+       dsaWithSHA1-CmsOID                         9
+       md5WithRSAEncryption-CmsOID               10
+       sha1WithRSAEncryption-CmsOID              11
+       rc2CBC-EnvOID                             12
+       rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+       rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
+       des-ede3-cbc-EnvOID                       15
+
+   The above encryption types are used by the client only within the
+   KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS)
+   [RFC3852] algorithms it supports.  Their use within Kerberos
+   EncryptedData structures is not specified by this document.
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) are given in
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 5]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X690].  All data
+   structures wrapped in OCTET STRINGs must be encoded according to the
+   rules specified in corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   CMS objects encoded with BER but not DER; specifically, they may not
+   be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifier for Diffie-Hellman key
+   agreement [RFC3279]:
+
+        dhpublicnumber
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v1.5)
+       id-RSAES-OAEP          (PKCS1 v2.0)
+
+   PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
+   for encrypting the reply key with the temporary key:
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+
+3.2  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various
+   pre-authentication fields employed by PKINIT.
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 6]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+3.2.1  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
+   addition, a pre-authentication field contains data signed by the
+   client's private signature key, as follows:
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to validate KDC certificates.
+          kdcCert                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a particular KDC certificate, if the
+                   -- client already has it.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= CHOICE {
+          caName                  [1] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+          issuerAndSerial         [2] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a specific CA certificate.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Defined in [RFC3280].
+                   -- Present only if the client wishes to use the
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 7]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+                   -- Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- List of CMS encryption types supported by
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to cache DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkauthdata:
+       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+       pkinit(3) pkauthdata(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains the
+       client's certificate and additional certificates intended to
+       facilitate certification path construction, so that the KDC can
+       validate the client's certificate and verify the signature over
+       the type AuthPack.  The certificates field MUST NOT contain
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 8]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+       "root" CA certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the
+       Diffie-Hellman key agreement method.  For the Diffie-Hellman key
+       agreement method, implementations MUST support Oakley 1024-bit
+       MODP well-known group 2 [RFC2412] and SHOULD support Oakley
+       2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
+       well-known group 16 [RFC3526].  They MAY support Oakley 185-bit
+       EC2N group 4 [RFC2412].  The Diffie-Hellman group size should be
+       chosen so as to provide sufficient cryptographic security.  The
+       exponents should have at least twice as many bits as the
+       symmetric keys that will be derived from them [ODL99].
+
+   7.  The client may wish to cache DH keys or to allow the KDC to do
+       so.  If so, then the client includes the clientDHNonce field.
+       This nonce string needs to be as long as the longest key length
+       of the symmetric key types that the client supports.  This nonce
+       MUST be chosen randomly.
+
+
+3.2.2  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC looks for the client's certificate in the signedAuthPack
+   (based on the signerInfo) and validate this certificate.
+
+   If the KDC cannot find a certification path to validate the client's
+   certificate, it sends back an error of type
+   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
+   error is a TYPED-DATA (as defined in [CLAR]).  For this error, the
+   data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER
+   encoding of
+
+       TrustedCertifiers ::= SEQUENCE OF OCTET STRING
+                   -- The OCTET STRING contains a PKIX type Name encoded
+                   -- according to [RFC3280].
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack is
+   invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
+   The accompanying e-data for this error is a TYPED-DATA, whose
+   data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
+   encoding of the index into the CertificateSet field, ordered as sent
+   by the client:
+
+
+
+Tung & Zhu               Expires August 4, 2005                 [Page 9]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+       CertificateIndex ::= OCTET STRING
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- IssuerAndSerialNumber of certificate with an
+                   -- invalid signature.
+
+   If more than one certificate signature is invalid, the KDC MAY send
+   one TYPED-DATA per invalid signature.
+
+   The KDC SHOULD also check whether any certificates in the client's
+   certification path have been revoked.  If any of them have been
+   revoked, the KDC MUST return an error of type
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The certificate or
+   certificates affected are identified exactly as for an error of type
+   KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   In addition to validating the client's certificate, the KDC MUST also
+   check that this certificate properly maps to the client's principal
+   name as specified in the AS-REQ as follows:
+
+   1.  If the KDC has its own mapping from the name in the client's
+      certificate to a Kerberos name, it uses that Kerberos name.
+
+   2.  Otherwise, if the client's certificate contains a SubjectAltName
+      extension with a Kerberos name in the otherName field, it uses
+      that name.
+
+      The otherName field (of type AnotherName) in the SubjectAltName
+      extension MUST contain KRB5PrincipalName as defined below.
+
+      The type-id field of the type AnotherName is id-pksan:
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+      The value field of the type AnotherName is the DER encoding of the
+      following ASN.1 type:
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own mapping and there is no Kerberos
+   name present in the client's certificate, or if the name in the
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 10]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+   request does not match the name in the certificate (including the
+   realm name), the KDC MUST return error code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error.
+
+   Even if the client's certificate is validated and it is mapped to the
+   client's principal name, the KDC may decide not to accept the
+   client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
+   client's certificate:
+
+       id-pkekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkekuoid(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that may be consistent: digitalSignature
+              -- nonRepudiation, and (keyEncipherment or keyAgreement).
+
+   As a matter of local policy, the KDC may decide to reject requests on
+   the basis of the absence or presence of specific EKU OIDs.  KDCs
+   implementing this requirement SHOULD also accept the EKU KeyPurposeId
+   id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
+   as there are a large number of client certificates deployed for use
+   with PKINIT which have this EKU.
+
+   The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
+   client's certificate is not accepted.
+
+   Once the client's certificate is accepted, the KDC can then verify
+   the client's signature over the type AuthPack according to [RFC3852].
+   If the signature fails to verify, the KDC MUST return error
+   KDC_ERR_INVALID_SIG.  There is no accompanying e-data for this error.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations clock skew times in [CLAR] apply here.  If the check
+   fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return error code KDC_ERR_KEY_SIZE.  The accompanying
+   e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
+   whose data-value is the DER encoding of the following:
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 11]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
+                   -- Type DomainParameters is defined in [RFC3279].
+                   -- Contains a list of Diffie-Hellman group
+                   -- parameters in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters
+   that the KDC supports in decreasing preference order, from which the
+   client should pick one to retry the request.
+
+   The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
+   client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
+   not have the corresponding certificate.
+
+   The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
+   did not include a kdcCert field, but did include a trustedCertifiers
+   field, and the KDC does not possesses a certificate issued by one of
+   the listed certifiers.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error of type
+   KRB5KDC_ERR_ETYPE_NOSUPP.
+
+3.2.3  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [CLAR], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
+   an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
+
+       InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+          ca                      [0] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+          validated               [1] BOOLEAN,
+          ...
+       }
+
+   The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the KDC's realm's policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [CLAR]).  Furthermore, any TGS must copy such authorization data from
+   tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
+   including the AD-IF-RELEVANT container, if present.
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 12]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [CLAR].)  If such a data type is contained within an
+   AD-IF-RELEVANT container, AP servers MAY apply local policy to
+   determine whether the authorization data is acceptable.
+
+   The AS-REP is otherwise unchanged from [CLAR].  The KDC encrypts the
+   reply as usual, but not with the client's long-term key.  Instead, it
+   encrypts it with either a shared key derived from a Diffie-Hellman
+   exchange, or a generated encryption key.  The contents of the
+   PA-PK-AS-REP indicate which key delivery method is used:
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 13]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's public key, y = g^x mod p.
+                   -- MUST be ASN.1 encoded as an INTEGER;
+                   -- This encoding is then used as the contents
+                   -- (i.e., the value) of this BIT STRING field.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if cached DH keys are NOT used,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's cached values, present
+                   -- if and only if cached DH keys are used.  If this
+                   -- field is omitted then the serverDHNonce field
+                   -- MUST also be omitted.
+          ...
+       }
+
+
+3.2.3.1  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains the KDC's
+       certificate and additional certificates intended to facilitate
+       certification path construction, so that the client can validate
+       the KDC's certificate and verify the KDC's signature over the
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 14]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+       type KDCDHKeyInfo.  This field may only be left empty if the
+       client did include a kdcCert field in the PA-PK-AS-REQ,
+       indicating that the client already has the KDC's certificate.
+       The certificates field MUST NOT contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys.  If the server reuses DH keys then
+       it MUST include an expiration time in the dhKeyExperiation field.
+       Past the point of the expiration time, the signature over the
+       type DHRepInfo is considered expired/invalid.  When the server
+       reuses DH keys then it MUST include a serverDHNonce at least as
+       long as the length of keys for the symmetric encryption system
+       used to encrypt the AS reply.  Note that including the
+       serverDHNonce changes how the client and server calculate the key
+       to use to encrypt the reply; see below for details.  The KDC
+       SHOULD NOT reuse DH keys unless the clientDHNonce field is
+       present in the request.
+
+   The reply key for use to decrypt the KDC reply [CLAR] is derived as
+   follows:
+
+   1.  Both the KDC and the client calculate the shared secret value
+      DHKey:
+
+           DHKey = g^(xb * xa) mod p
+
+      where xb and xa are the KDC's and client's private exponents,
+      respectively.  DHKey, padded first with leading zeros as needed to
+      make it as long as the modulus p, is represented as a string of
+      octets in big-endian order (such that the size of DHKey in octets
+      is the size of the modulus p).
+
+   2.  Let K be the key-generation seed length [KCRYPTO] of the reply
+      key whose enctype is selected according to [CLAR].
+
+   3.  Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet;
+      random-to-key() is an operation that generates a protocol key from
+      a bitstring of length K; and K-truncate truncates its input to the
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 15]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+      first K bits.  Both K and random-to-key() are defined in the
+      kcrypto profile [KCRYPTO] for the enctype of the reply key.
+
+   4.  When cached DH keys are used, let n_c be the clientDHNonce, and
+      n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty
+      octet strings.
+
+   5.  The reply key k is:
+
+           k = octetstring2key(DHKey | n_c | n_k)
+
+
+3.2.3.2  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The reply key for use to decrypt the KDC
+   reply [CLAR] is encrypted in the encKeyPack field, which contains
+   data of type ReplyKeyPack:
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is
+       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 16]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains the
+       KDC's certificate and additional certificates intended to
+       facilitate certification path construction, so that the client
+       can validate the KDC's certificate and verify the KDC's signature
+       over the type ReplyKeyPack.  This field may only be left empty if
+       the client included a kdcCert field in the PA-PK-AS-REQ,
+       indicating that the client already has the KDC's certificate.
+       The certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+3.2.4  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the shared key using the same procedure used by the KDC as defined in
+   Section 3.2.3.1.  Otherwise, the message contains an encKeyPack, and
+   the client decrypts and verifies the temporary encryption key.
+
+   In either case, the client MUST validate the KDC's certificate and
+   verify the signature in the SignedData according to [RFC3852].
+   Unless the client can otherwise prove that the KDC's certificate is
+   for the target KDC (i.e., the subject distinguished name in the KDC
+   certificate is bound to the hostname or IP address of the KDC
+   authenticating the client), it MUST do the following to verify the
+   responder's identity:
+
+   1.  The client checks to see if the included certificate contains a
+      Subject Alternative Name extension [RFC3280] carrying a dNSName or
+      an iPAddress (if the KDC is specified by an IP address instead of
+      a name).  If it does, it MUST check to see if that name value
+      matches that of the KDC it believes it is communicating with, with
+      matching rules specified in [RFC3280].
+
+   2.  The client verifies that the KDC's certificate MUST contain the
+      EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
+
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 17]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+
+
+       id-pkkdcekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkkdcekuoid(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that may be consistent:
+              -- digitalSignature.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part of the KDC-REP in the AS_REP with the resulting key, and
+   then proceeds as described in [CLAR].
+
+3.3  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [CLAR] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including a PA-PK-AS-REQ element in
+   that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the
+   KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+4.  Security Considerations
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 18]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [CLAR].
+
+   PKINIT uses the same RSA key pair for encryption and signing when
+   doing RSA encryption based key delivery.  This is not recommended
+   usage of RSA keys [RFC3447], by using DH based key delivery this is
+   avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love
+   Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan
+   Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and
+   Karthik Jaganathan.
+
+   Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who
+   wrote earlier versions of this document.
+
+   The authors are indebt to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 19]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+   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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+7.  References
+
+7.1  Normative References
+       
+   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+
+   [KCRYPTO]  RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-crypto.  Work in Progress. 
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 20]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+             
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER), ITU-T Recommendation
+              X.690 (1997) | ISO/IEC International Standard
+              8825-1:1998.
+
+7.2  Informative References
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001, Marina del Rey CA
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 21]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           DomainParameters
+               FROM PKIX1Algorithms88 { iso(1)
+                 identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-mod-pkix1-algorithms(17) }
+                 -- As defined in RFC 3279.
+
+           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       pa-pk-as-req INTEGER ::=                 16
+       pa-pk-as-rep INTEGER ::=                 17
+
+       ad-initial-verified-cas INTEGER ::=       9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-certificate-index INTEGER ::=         105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 22]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to validate KDC certificates.
+          kdcCert                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a particular KDC certificate, if the
+                   -- client already has it.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= CHOICE {
+          caName                  [1] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+          issuerAndSerial         [2] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a specific CA certificate.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Defined in [RFC3280].
+                   -- Present only if the client wishes to use the
+                   -- Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- List of CMS encryption types supported by
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to cache DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 23]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TrustedCertifiers ::= SEQUENCE OF OCTET STRING
+                   -- The OCTET STRING contains a PKIX type Name encoded
+                   -- according to [RFC3280].
+
+       CertificateIndex ::= OCTET STRING
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
+          ca                      [0] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+          validated               [1] BOOLEAN,
+          ...
+       }
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 24]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's public key, y = g^x mod p.
+                   -- MUST be ASN.1 encoded as an INTEGER;
+                   -- This encoding is then used as the contents
+                   -- (i.e., the value) of this BIT STRING field.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if cached DH keys are NOT used,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's cached values, present
+                   -- if and only if cached DH keys are used.  If this
+                   -- field is omitted then the serverDHNonce field
+                   -- MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 25]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
+                   -- Contains a list of Diffie-Hellman group
+                   -- parameters in decreasing preference order.
+       END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 26]
+
+Internet-Draft                   PKINIT                     January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu               Expires August 4, 2005                [Page 27]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt
new file mode 100644
index 00000000000..2aed744ce1c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt
@@ -0,0 +1,1621 @@
+
+
+
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: August 11, 2005                                          L. Zhu
+                                                   Microsoft Corporation
+                                                        February 7, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                    draft-ietf-cat-kerberos-pk-init
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 11, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 1]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  6
+       3.2.1   Generation of Client Request . . . . . . . . . . . . .  6
+       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
+       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 13
+       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 18
+     3.3   KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     7.1   Normative References . . . . . . . . . . . . . . . . . . . 22
+     7.2   Informative References . . . . . . . . . . . . . . . . . . 23
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
+   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 24
+       Intellectual Property and Copyright Statements . . . . . . . . 29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 2]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  (In this document, we will
+   refer to both the AS and the TGS as the KDC.)  Finally, the client
+   uses the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [CLAR], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce
+   public-key cryptography into Kerberos is in the initial
+   authentication exchange.  This document describes the methods and
+   data formats for integrating public-key cryptography into Kerberos
+   initial authentication.
+
+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 [RFC2119].
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 3]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+3.  Extensions
+
+   This section describes extensions to [CLAR] for supporting the use of
+   public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [CLAR]:
+
+   1.  The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2.  The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3.  If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a.  a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631][IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b.  a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a
+      pre-authentication field accompanying the usual reply.
+
+   4.  The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1  Definitions, Requirements, and Constants
+
+3.1.1  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  KDC AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 4]
+
+
+
+3.1.2  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                             16
+       PA_PK_AS_REP                             17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                   9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                    104
+       TD_INVLID_CERTIFICATES                   105
+       TD_DH_PARAMETERS                         109
+
+   PKINIT defines the following encryption types, for use in the AS-REQ
+   message to indicate acceptance of the corresponding algorithms that
+   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
+   the reply:
+
+       dsaWithSHA1-CmsOID                         9
+       md5WithRSAEncryption-CmsOID               10
+       sha1WithRSAEncryption-CmsOID              11
+       rc2CBC-EnvOID                             12
+       rsaEncryption-EnvOID   (PKCS1 v1.5)       13
+       rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
+       des-ede3-cbc-EnvOID                       15
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X690] (unless
+   otherwise noted).  All data structures carried in OCTET STRINGs must
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 5]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   be encoded according to the rules specified in corresponding
+   specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifiers for Diffie-Hellman
+   key agreement [RFC3279]:
+
+        dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
+        id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v1.5)
+       id-RSAES-OAEP          (PKCS1 v2.0)
+
+   PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
+   for encrypting the reply key with the temporary key:
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+
+3.2  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various
+   pre-authentication fields employed by PKINIT.
+
+3.2.1  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 6]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used as the trust anchor to validate the KDC's
+                   -- signature.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= CHOICE {
+          caName                  [1] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies a CA.
+                   -- Prefer the sid field below if that is available.
+          sid                     [2] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies the trusted CA's certificate (and
+                   -- thereby the public key).
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 7]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Defined in [RFC3280].
+                   -- The pubic key value (the subjectPublicKey field
+                   -- of the type SubjectPublicKeyInfo) MUST be encoded
+                   -- according to [RFC3279].
+                   -- Present only if the client wishes to use the
+                   -- Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- List of CMS encryption types supported by
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkauthdata:
+       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+       pkinit(3) pkauthdata(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 8]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [CAPATH].  If the client sends all the X.509 certificates on a
+       certification path to a trust anchor acceptable by the KDC and
+       the KDC can not verify the client's public key otherwise, the KDC
+       MUST process path validation for the client's X.509 certificate
+       based on the certificates in the request.  The certificates field
+       MUST NOT contain "root" CA certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the
+       Diffie-Hellman key agreement method.  For the Diffie-Hellman key
+       agreement method, implementations MUST support Oakley 1024-bit
+       MODP well-known group 2 [RFC2412] and SHOULD support Oakley
+       2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
+       well-known group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security.  The following table, based on
+       [LENSTRA], gives approximate comparable key sizes for symmetric-
+       and asymmetric-key cryptosystems based on the best-known
+       algorithms for attacking them.
+
+                  Symmetric    |  ECC    |  DH/DSA/RSA
+                  -------------+---------+------------
+                     80        |  163    |  1024
+                    112        |  233    |  2048
+                    128        |  283    |  3072
+                    192        |  409    |  7680
+                    256        |  571    |  15360
+
+                 Table 1: Comparable key sizes (in bits)
+
+       When Diffie-Hellma modulo a prime p is used, the exponents should
+       have at least twice as many bits as the symmetric keys that will
+       be derived from them [ODL99].
+
+   7.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string needs to be as long as
+       the longest key length of the symmetric key types that the client
+
+
+
+Tung & Zhu               Expires August 11, 2005                [Page 9]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       supports.  This nonce MUST be chosen randomly.
+
+
+3.2.2  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [CLAR] message with the code
+   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
+   error message is a TYPED-DATA (as defined in [CLAR]) that contains an
+   element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
+   data-value contains the DER encoding of the type
+   TD-TRUSTED-CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors selected by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [CLAR] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
+                   -- Each OCTET STRING contains a CMS type
+                   -- IssuerAndSerialNumber encoded according to
+                   -- [RFC3852].
+                   -- Each IssuerAndSerialNumber indentifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 10]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   send one TYPED-DATA element per invalid signature.
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1.  If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2.  Otherwise, if the client's X.509 certificate contains a
+      SubjectAltName extension with a KRB5PrincipalName (defined below)
+      in the otherName field, it binds the client's X.509 certificate to
+      that name.
+
+      The otherName field (of type AnotherName) in the SubjectAltName
+      extension MUST contain KRB5PrincipalName as defined below.
+
+      The type-id field of the type AnotherName is id-pksan:
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+      The value field of the type AnotherName is the DER encoding of the
+      following ASN.1 type:
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 11]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, and
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
+   client's X.509 certificate:
+
+       id-pkekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkekuoid(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature;
+              -- Key usage bits that MAY be consistent:
+              -- nonRepudiation, and (keyEncipherment or keyAgreement).
+
+   If this EKU is required but is missing, the KDC MUST return an error
+   message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There is no
+   accompanying e-data for this error message.  KDCs implementing this
+   requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
+   (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
+   large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   If for any other reasons, the client's public key is not accepted,
+   the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NOT_TRUSTED.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [CLAR] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 12]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
+                   -- Contains a list of Diffie-Hellman domain
+                   -- parameters in decreasing preference order.
+
+       DHDomainParameters ::= CHOICE {
+           modp                   [0] DomainParameters,
+                   -- Type DomainParameters is defined in [RFC3279].
+           ec                     [1] EcpkParameters,
+                   -- Type EcpkParameters is defined in [RFC3279].
+           ...
+       }
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not have the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the client included a trustedCertifiers field, and the KDC does
+   not possesses the private key for any one of the listed certifiers,
+   the KDC MUST ignore the trustedCertifiers field as if the client did
+   not include one.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
+
+3.2.3  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [CLAR], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [CLAR] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+   The KDC MUST wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 13]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   containers.  Furthermore, any TGS MUST copy such authorization data
+   from tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the
+   resulting ticket.  Upon receipt of a service ticket carrying the
+   AD-INITIAL-VERIFIED-CAS data, application servers MAY apply local
+   policy to determine whether the authorization data is acceptable.
+
+   The content of the AS-REP is otherwise unchanged from [CLAR].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used:
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 14]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH pubic key value is mapped to a BIT STRING
+                   -- according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted. See Section 3.2.3.1.
+          ...
+       }
+
+
+3.2.3.1  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 15]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       PA-PK-AS-REQ was used for signing.  Otherwise, for path
+       validation, these certificates SHOULD be sufficient to construct
+       at least one certification path from the KDC certificate to one
+       trust anchor acceptable by the client [CAPATH].  If the KDC sends
+       all the X.509 certificates on a certification path to a trust
+       anchor acceptable by the client and the client can not verify the
+       KDC's public key otherwise, the client MUST process path
+       validation for the KDC's X.509 certificate based on the
+       certificates in the reply.  The certificates field MUST NOT
+       contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExperiation field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered
+       expired/invalid.  When the server reuses DH keys then it MUST
+       include a serverDHNonce at least as long as the length of keys
+       for the symmetric encryption system used to encrypt the AS reply.
+       Note that including the serverDHNonce changes how the client and
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+   The reply key for use to decrypt the KDC reply [CLAR] is derived as
+   follows:
+
+   1.  Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
+         DHSharedSecret be the shared secret value.
+
+      b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
+         contributing one key pair) [IEEE1363] is used, let
+         DHSharedSecret be the x-coordinate of the shared secret value
+         (an elliptic curve point).
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 16]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   2.  Let K be the key-generation seed length [KCRYPTO] of the reply
+      key whose enctype is selected according to [CLAR].
+
+   3.  Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet;
+      random-to-key() is an operation that generates a protocol key from
+      a bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [KCRYPTO] for the enctype of the reply key.
+
+   4.  When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5.  The reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+
+3.2.3.2  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The reply key for use to decrypt the KDC
+   reply [CLAR] is encrypted in the encKeyPack field, which contains
+   data of type ReplyKeyPack:
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 17]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is
+       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type ReplyKeyPack.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the
+       PA-PK-AS-REQ was used for signing.  Otherwise, for path
+       validation, these certificates SHOULD be sufficient to construct
+       at least one certification path from the KDC certificate to one
+       trust anchor acceptable by the client [CAPATH].  If the KDC sends
+       all the X.509 certificates on a certification path to a trust
+       anchor acceptable by the client and the client can not verify the
+       KDC's public key otherwise, the client MUST process path
+       validation for the KDC's X.509 certificate based on the
+       certificates in the reply.  The certificates field MUST NOT
+       contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+3.2.4  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 18]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   the reply key using the same procedure used by the KDC as defined in
+   Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the reply key.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  Unless the client can otherwise
+   prove that the public key used to verify the KDC's signature is bound
+   to the target KDC, it MUST verify the responder's identity as
+   follows:
+
+   1.  The KDC's X.509 certificate MUST contain the EKU KeyPurposeId
+      [RFC3280] id-pkkdcekuoid:
+
+       id-pkkdcekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkkdcekuoid(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   2.  The KDC's X.509 certificate MUST contain a Subject Alternative
+      Name (SAN) extension [RFC3280] carrying an AnotherName whose
+      type-id is id-pksan (as defined in Section 3.2.2) and whose value
+      contains a KRB5PrincipalName name, and the realm name of that
+      KRB5PrincipalName matches the realm name of the target KDC.  If no
+      such SAN extension is present in the KDC's certificate, the client
+      SHOULD accept the KDC's certificate as meeting this requirement if
+      the KDC's X.509 certificate contains an SAN extension carrying a
+      dNSName and that name value matches the domain style realm name
+      [CLAR] of the target KDC.  The KDC's certificate SHOULD also be
+      accepted if it contains an SAN extension carrying a dNSName or an
+      iPAddress (if the KDC is specified by an IP address instead of a
+      name) and that name value matches the hostname or the IP address
+      of the KDC with which the client believes it is communicating.  If
+      the KDC's hostname or IP address is used to match the dNSName
+      value, it MUST have been obtained securely.  Matching rules used
+      for the dNSName value are specified in [RFC3280].
+
+      Implementation note: CAs issuing KDC certificates SHOULD place all
+      "short" and "fully-qualified" realm names of the KDC (one per SAN
+      id-pksan extension) into the KDC certificate to allow maximum
+      flexibility.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part of the KDC-REP in the AS-REP with the reply key, and then
+   proceeds as described in [CLAR].
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 19]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+3.3  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [CLAR] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value of PA_PK_AS_REQ entry in the
+   KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+4.  Security Considerations
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   Users of PKINIT must understand security policies and procedures
+   appropriate to the use of Public Key Infrastructures [RFC3280].
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [CLAR].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 20]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
+   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and Karthik
+   Jaganathan.
+
+   Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
+   who wrote earlier versions of this document.
+
+   The authors are indebt to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 21]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+7.  References
+
+7.1  Normative References
+
+   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+
+   [IEEE1363] 
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [KCRYPTO]  RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-crypto.  Work in Progress. 
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 22]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER), ITU-T Recommendation
+              X.690 (1997) | ISO/IEC International Standard
+              8825-1:1998.
+
+7.2  Informative References
+
+   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-certpathbuild.  Work in Progress. 
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+              
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001, Marina del Rey CA
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+Appendix A.  PKINIT ASN.1 Module
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 23]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           DomainParameters, EcpkParameters
+               FROM PKIX1Algorithms88 { iso(1)
+                 identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-mod-pkix1-algorithms(17) }
+                 -- As defined in RFC 3279.
+
+           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       pa-pk-as-req INTEGER ::=                 16
+       pa-pk-as-rep INTEGER ::=                 17
+
+       ad-initial-verified-cas INTEGER ::=       9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 24]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used as the trust anchor to validate the KDC's
+                   -- signature.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= CHOICE {
+          caName                  [1] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies a CA.
+                   -- Prefer the sid field below if that is available.
+          sid                     [2] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies the trusted CA's certificate (and
+                   -- thereby the public key).
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Defined in [RFC3280].
+                   -- The pubic key value (the subjectPublicKey field
+                   -- of the type SubjectPublicKeyInfo) MUST be encoded
+                   -- according to [RFC3279].
+                   -- Present only if the client wishes to use the
+                   -- Diffie-Hellman key agreement method.
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 25]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- List of CMS encryption types supported by
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
+                   -- Each OCTET STRING contains a CMS type
+                   -- IssuerAndSerialNumber encoded according to
+                   -- [RFC3852].
+                   -- Each IssuerAndSerialNumber indentifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 26]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH pubic key value is mapped to a BIT STRING
+                   -- according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 27]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
+                   -- Contains a list of Diffie-Hellman domain
+                   -- parameters in decreasing preference order.
+
+       DHDomainParameters ::= CHOICE {
+           modp                   [0] DomainParameters,
+                   -- Type DomainParameters is defined in [RFC3279].
+           ec                     [1] EcpkParameters,
+                   -- Type EcpkParameters is defined in [RFC3279].
+           ...
+       }
+       END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 28]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu               Expires August 11, 2005               [Page 29]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt
new file mode 100644
index 00000000000..cb13ed0bb12
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt
@@ -0,0 +1,1674 @@
+
+
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: August 22, 2005                                          L. Zhu
+                                                   Microsoft Corporation
+                                                       February 18, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                    draft-ietf-cat-kerberos-pk-init-25
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 22, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 1]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  6
+       3.2.1   Generation of Client Request . . . . . . . . . . . . .  6
+       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
+       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 13
+       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
+     3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
+     3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+     7.1   Normative References . . . . . . . . . . . . . . . . . . . 23
+     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
+   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
+       Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 2]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  (In this document, both
+   the AS and the TGS are referred to as the KDC.)  Finally, the client
+   uses the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [CLAR], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce
+   public-key cryptography into Kerberos is in the initial
+   authentication exchange.  This document describes the methods and
+   data formats for integrating public-key cryptography into Kerberos
+   initial authentication.
+
+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 [RFC2119].
+
+   In this document, the encryption key used to encrypt the enc-part
+   field of the KDC-REP in the AS-REP [CLAR] is referred to as the KDC
+   AS reply key.
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 3]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+3.  Extensions
+
+   This section describes extensions to [CLAR] for supporting the use of
+   public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [CLAR]:
+
+   1.  The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2.  The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3.  If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a.  a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631][IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b.  a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a
+      pre-authentication field accompanying the usual reply.
+
+   4.  The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1  Definitions, Requirements, and Constants
+
+3.1.1  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3961].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  KDC AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 4]
+
+
+
+3.1.2  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVLID_CERTIFICATES                      105
+       TD_DH_PARAMETERS                            109
+
+   PKINIT defines the following encryption types, for use in the AS-REQ
+   message to indicate acceptance of the corresponding algorithms that
+   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
+   the reply:
+
+       dsaWithSHA1-CmsOID                            9
+       md5WithRSAEncryption-CmsOID                  10
+       sha1WithRSAEncryption-CmsOID                 11
+       rc2CBC-EnvOID                                12
+       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
+       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
+       des-ede3-cbc-EnvOID                          15
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X690] (unless
+   otherwise noted).  All data structures carried in OCTET STRINGs must
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 5]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   be encoded according to the rules specified in corresponding
+   specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifiers for Diffie-Hellman
+   key agreement [RFC3279]:
+
+       dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
+       id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v1.5)
+       id-RSAES-OAEP          (PKCS1 v2.0)
+
+   PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
+   for encrypting the KDC AS reply key with the temporary key:
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+
+3.2  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various
+   pre-authentication fields employed by PKINIT.
+
+3.2.1  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 6]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used as the trust anchor to validate the KDC's
+                   -- signature.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= SEQUENCE {
+          caName                  [0] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies a CA by the CA's distinguished subject
+                   -- name.
+          certificateSerialNumber [1] INTEGER OPTIONAL,
+                   -- Specifies the CA certificate's serial number.
+                   -- The defintion of the certificate serial number
+                   -- is taken from X.509 [X.509-97].
+          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
+                   -- Identifies the CA's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 7]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The public key value (the subjectPublicKey field
+                   -- of the type SubjectPublicKeyInfo) MUST be encoded
+                   -- according to [RFC3279].
+                   -- Present only if the client wishes to use the
+                   -- Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 8]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkauthdata:
+       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+       pkinit(3) pkauthdata(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [CAPATH].  The certificates field MUST NOT contain "root" CA
+       certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the
+       Diffie-Hellman key agreement method.  The Diffie-Hellman domain
+       parameters for the client's public key are specified in the
+       algorithm field of the type SubjectPublicKeyInfo
+       [IEEE1363][RFC3279] and the client's Diffie-Hellman public key
+       value is mapped to a subjectPublicKey (a BIT STRING) according to
+       [RFC3279].  When using the Diffie-Hellman key agreement method,
+       implementations MUST support Oakley 1024-bit MODP well-known
+       group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
+       well-known group 14 and Oakley 4096-bit MODP well-known group 16
+       [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security.  The following table, based on
+       [LENSTRA], gives approximate comparable key sizes for symmetric-
+       and asymmetric-key cryptosystems based on the best-known
+       algorithms for attacking them.
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 22, 2005                [Page 9]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                  Symmetric    |  ECC    |  DH/DSA/RSA
+                  -------------+---------+------------
+                     80        |  163    |  1024
+                    112        |  233    |  2048
+                    128        |  283    |  3072
+                    192        |  409    |  7680
+                    256        |  571    |  15360
+
+                 Table 1: Comparable key sizes (in bits)
+
+       When Diffie-Hellma modulo a prime p is used, the exponents should
+       have at least twice as many bits as the symmetric keys that will
+       be derived from them [ODL99].
+
+   7.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string needs to be as long as
+       the longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+
+3.2.2  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [CLAR] message with the code
+   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
+   error message is a TYPED-DATA (as defined in [CLAR]) that contains an
+   element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
+   data-value contains the DER encoding of the type
+   TD-TRUSTED-CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors selected by the KDC to its own certificate.
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 10]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [CLAR] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
+                   -- Each OCTET STRING contains a CMS type
+                   -- IssuerAndSerialNumber encoded according to
+                   -- [RFC3852].
+                   -- Each IssuerAndSerialNumber indentifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   send one TYPED-DATA element per invalid signature.
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1.  If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2.  Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension [RFC3280] with a
+      KRB5PrincipalName (defined below) in the otherName field, it binds
+      the client's X.509 certificate to that name.
+
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 11]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+      The otherName field (of type AnotherName) in the SAN extension
+      MUST contain KRB5PrincipalName as defined below.
+
+      The type-id field of the type AnotherName is id-pksan:
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+      The value field of the type AnotherName is the DER encoding of the
+      following ASN.1 type:
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, and
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
+   client's X.509 certificate:
+
+       id-pkekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkekuoid(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature;
+              -- Key usage bits that MAY be consistent:
+              -- nonRepudiation, and (keyEncipherment or keyAgreement).
+
+   If this EKU is required but is missing, the KDC MUST return an error
+   message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There is no
+   accompanying e-data for this error message.  KDCs implementing this
+   requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
+   (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
+   large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   If for any other reasons, the client's public key is not accepted,
+   the KDC MUST return an error message with the code
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 12]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   KDC_ERR_CLIENT_NOT_TRUSTED.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [CLAR] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the client included a trustedCertifiers field, and the KDC does
+   not possesses the private key for any one of the listed certifiers,
+   the KDC MUST ignore the trustedCertifiers field as if the client did
+   not include any.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
+
+3.2.3  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [CLAR], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 13]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   ticket.  The ad-data [CLAR] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [CLAR]).  Furthermore, any TGS MUST copy such authorization data from
+   tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting
+   ticket, and it can wrap or unwrap the data into or out-of the
+   AD-IF-RELEVANT container, depends on if the list of CAs satisfies the
+   TGS' realm's local policy.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [CLAR].)  If such a data type is contained within an
+   AD-IF-RELEVANT container, AP servers MAY apply local policy to
+   determine whether the authorization data is acceptable.
+
+   The content of the AS-REP is otherwise unchanged from [CLAR].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used:
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 14]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH pubic key value is mapped to a BIT STRING
+                   -- according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted. See Section 3.2.3.1.
+          ...
+       }
+
+
+3.2.3.1  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 15]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the
+       PA-PK-AS-REQ was used for signing.  Otherwise, for path
+       validation, these certificates SHOULD be sufficient to construct
+       at least one certification path from the KDC certificate to one
+       trust anchor acceptable by the client [CAPATH].  The certificates
+       field MUST NOT contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExperiation field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered
+       expired/invalid.  When the server reuses DH keys then it MUST
+       include a serverDHNonce at least as long as the length of keys
+       for the symmetric encryption system used to encrypt the AS reply.
+       Note that including the serverDHNonce changes how the client and
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+   The KDC AS reply key is derived as follows:
+
+   1.  Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
+         DHSharedSecret be the shared secret value.
+
+
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 16]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+      b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
+         contributing one key pair) [IEEE1363] is used, let
+         DHSharedSecret be the x-coordinate of the shared secret value
+         (an elliptic curve point).
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2.  Let K be the key-generation seed length [RFC3961] of the KDC AS
+      reply key whose enctype is selected according to [CLAR].
+
+   3.  Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet;
+      random-to-key() is an operation that generates a protocol key from
+      a bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the KDC AS reply key.
+
+   4.  When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5.  The KDC AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+
+3.2.3.2  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The KDC AS reply key is encrypted in the
+   encKeyPack field, which contains data of type ReplyKeyPack:
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 17]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is
+       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type ReplyKeyPack.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the
+       PA-PK-AS-REQ was used for signing.  Otherwise, for path
+       validation, these certificates SHOULD be sufficient to construct
+       at least one certification path from the KDC certificate to one
+       trust anchor acceptable by the client [CAPATH].  The certificates
+       field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 18]
+
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+3.2.4  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the KDC AS reply key using the same procedure used by the KDC as
+   defined in Section 3.2.3.1.  Otherwise, the message contains the
+   encKeyPack field, and the client decrypts and extracts the temporary
+   key in the encryptedKey field of the member KeyTransRecipientInfo,
+   and then uses that as the KDC AS reply key.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  Unless the client can otherwise
+   prove that the public key used to verify the KDC's signature is bound
+   to the target KDC,  the KDC's X.509 certificate MUST satisfy at least
+   one of the following two requirements:
+
+   1.  The certificate contains a Subject Alternative Name (SAN)
+       extension [RFC3280] carrying a dNSName and that name value
+       matches the following name format:
+
+           _Service._Proto.Realm
+
+        Where the Service name is the string literal "kerberos", the
+       Proto can be "udp" or "tcp", and the Realm is the domain style
+       Kerberos realm name [CLAR] of the target KDC.  This name format
+       is identical to the owner label format used in the DNS SRV
+       records for specifying the KDC location as described in [CLAR].
+       For example, the X.509 certificate for the KDC of the Kerberos
+       realm "EXAMPLE.COM" would contain a dNSName value of
+       "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".
+
+   2.  The certificate contains the EKU KeyPurposeId [RFC3280]
+       id-pkkdcekuoid (defined below) and an SAN extension [RFC3280]
+       carrying an AnotherName whose type-id is id-pksan (as defined in
+       Section 3.2.2) and whose value contains a KRB5PrincipalName name,
+       and the realm name of that KRB5PrincipalName matches the realm
+       name of the target KDC.
+
+       id-pkkdcekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkkdcekuoid(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+        If no SAN id-pksan extension is present (but the id-pkkdcekuoid
+       EKU is) in the KDC's X.509 certificate, and the client has a
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 19]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       priori knowledge of the KDC's hostname (or IP address), the
+       client SHOULD accept the KDC's X.509 certificate if that
+       certificate contains an SAN extension carrying a dNSName and the
+       dNSName value matches the hostname (or the IP address) of the KDC
+       with which the client believes it is communicating.
+
+   Matching rules used for the dNSName value are specified in [RFC3280].
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the KDC AS reply
+   key, and then proceeds as described in [CLAR].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per SAN extension) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [CLAR] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 20]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+4.  Security Considerations
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [CLAR].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 21]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
+   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan
+   and Chaskiel M Grundman.
+
+   Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
+   who wrote earlier versions of this document.
+
+   The authors are indebt to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 22]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+7.  References
+
+7.1  Normative References
+
+   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+
+   [IEEE1363] 
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 23]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
+              Framework.  1997.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER), ITU-T Recommendation
+              X.690 (1997) | ISO/IEC International Standard
+              8825-1:1998.
+
+7.2  Informative References
+
+   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-certpathbuild.  Work in Progress. 
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+              
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001, Marina del Rey CA
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+Appendix A.  PKINIT ASN.1 Module
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 24]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           DomainParameters, EcpkParameters
+               FROM PKIX1Algorithms88 { iso(1)
+                 identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-mod-pkix1-algorithms(17) }
+                 -- As defined in RFC 3279.
+
+           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 25]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used as the trust anchor to validate the KDC's
+                   -- signature.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= SEQUENCE {
+          caName                  [0] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies a CA by the CA's distinguished subject
+                   -- name.
+          certificateSerialNumber [1] INTEGER OPTIONAL,
+                   -- Specifies the CA certificate's serial number.
+                   -- The defintion of the certificate serial number
+                   -- is taken from X.509 [X.509-97].
+          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
+                   -- Identifies the CA's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+          ...
+       }
+
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 26]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The public key value (the subjectPublicKey field
+                   -- of the type SubjectPublicKeyInfo) MUST be encoded
+                   -- according to [RFC3279].
+                   -- Present only if the client wishes to use the
+                   -- Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
+                   -- Each OCTET STRING contains a CMS type
+                   -- IssuerAndSerialNumber encoded according to
+                   -- [RFC3852].
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 27]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- Each IssuerAndSerialNumber indentifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 28]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH pubic key value is mapped to a BIT STRING
+                   -- according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 29]
+
+Internet-Draft                   PKINIT                    February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu               Expires August 22, 2005               [Page 30]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt
new file mode 100644
index 00000000000..0493302602e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt
@@ -0,0 +1,1674 @@
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: November 24, 2005                                        L. Zhu
+                                                   Microsoft Corporation
+                                                            May 23, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                    draft-ietf-cat-kerberos-pk-init
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  
+   
+   By submitting this Internet-Draft, each author represents that any 
+   applicable patent or other IPR claims of which he or she is aware 
+   have been or will be disclosed, and any of which he or she becomes 
+   aware will be disclosed, in accordance with Section 6 of BCP 79. 
+     
+   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 Internet-Draft will expire on November 24, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 1]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
+       3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
+       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 13
+       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
+     3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
+     3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     7.1   Normative References . . . . . . . . . . . . . . . . . . . 22
+     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
+   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
+       Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 2]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
+   the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [CLAR], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce public-
+   key cryptography into Kerberos is in the initial authentication
+   exchange.  This document describes the methods and data formats for
+   integrating public-key cryptography into Kerberos initial
+   authentication.
+
+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 [RFC2119].
+
+   Both the AS and the TGS are referred to as the KDC.
+
+   In this document, the encryption key used to encrypt the enc-part
+   field of the KDC-REP in the AS-REP [CLAR] is referred to as the AS
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 3]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   reply key.
+
+3.  Extensions
+
+   This section describes extensions to [CLAR] for supporting the use of
+   public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [CLAR]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1  Definitions, Requirements, and Constants
+
+3.1.1  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3962].
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 4]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+
+3.1.2  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   PKINIT defines the following encryption types, for use in the AS-REQ
+   message to indicate acceptance of the corresponding algorithms that
+   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
+   the reply:
+
+       dsaWithSHA1-CmsOID                            9
+       md5WithRSAEncryption-CmsOID                  10
+       sha1WithRSAEncryption-CmsOID                 11
+       rc2CBC-EnvOID                                12
+       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
+       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
+       des-ede3-cbc-EnvOID                          15
+
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 5]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X690] (unless
+   otherwise noted).  All data structures carried in OCTET STRINGs must
+   be encoded according to the rules specified in corresponding
+   specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifiers for Diffie-Hellman
+   key agreement [RFC3279]:
+
+       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
+       id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v1.5)
+       id-RSAES-OAEP          (PKCS1 v2.0)
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 6]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+3.2  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
+   addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= SEQUENCE {
+          caName                  [0] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 7]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+                   -- Identifies a CA by the CA's distinguished subject
+                   -- name.
+          certificateSerialNumber [1] INTEGER OPTIONAL,
+                   -- Specifies the CA certificate's serial number.
+                   -- The defintion of the certificate serial number
+                   -- is taken from X.509 [X.509-97].
+          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
+                   -- Identifies the CA's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 8]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkauthdata:
+       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+       pkinit(3) pkauthdata(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [CAPATH].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
+       well-known group 14 and Oakley 4096-bit MODP well-known group 16
+
+
+
+Tung & Zhu              Expires November 24, 2005               [Page 9]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+       [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   7.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string needs to be as long as
+       the longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+
+3.2.2  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [CLAR] message with the code
+   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
+   error message is a TYPED-DATA (as defined in [CLAR]) that contains an
+   element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-
+   value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [CLAR] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 10]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
+                   -- Each OCTET STRING contains a CMS type
+                   -- IssuerAndSerialNumber encoded according to
+                   -- [RFC3852].
+                   -- Each IssuerAndSerialNumber identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 11]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pksan:
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
+   client's X.509 certificate:
+
+       id-pkekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkekuoid(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 12]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   If for any other reasons, the client's public key is not accepted,
+   the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NOT_TRUSTED.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [CLAR] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
+
+3.2.3  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [CLAR], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [CLAR] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 13]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [CLAR]).  Furthermore, any TGS MUST copy such authorization data from
+   tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting
+   ticket.  If the list of CAs satisfies the local KDC's realm's policy,
+   the TGS MAY wrap the data into the AD-IF-RELEVANT container,
+   otherwise it MAY unwrap the authorization data out of the AD-IF-
+   RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [CLAR].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   The content of the AS-REP is otherwise unchanged from [CLAR].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used:
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 14]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted. See Section 3.2.3.1.
+          ...
+       }
+
+
+3.2.3.1  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 15]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only. be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExpiration field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered expired/
+       invalid.  When the server reuses DH keys then it MUST include a
+       serverDHNonce at least as long as the length of keys for the
+       symmetric encryption system used to encrypt the AS reply.  Note
+       that including the serverDHNonce changes how the client and
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+   The AS reply key is derived as follows:
+
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 16]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
+         contributing one key pair) is used, let DHSharedSecret be the
+         x-coordinate of the shared secret value (an elliptic curve
+         point).  DHSharedSecret is the output of operation ECSVDP-DH as
+         described in Section 7.2.1 of [IEEE1363].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [CLAR].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 17]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+
+3.2.3.2  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
+   encKeyPack field, which contains data of type ReplyKeyPack:
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type ReplyKeyPack.  The information contained in the
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 18]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+3.2.4  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [CLAR]).
+
+   Based on local policy, the client MAY require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
+
+       id-pkkdcekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkkdcekuoid(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 19]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+              -- digitalSignature.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [CLAR].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [CLAR] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 20]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+4.  Security Considerations
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [CLAR].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 21]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
+   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
+   Jaganathan, Chaskiel M Grundman and Stefan Santesson.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+7.  References
+
+7.1  Normative References
+
+   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 22]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   [IEEE1363] 
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 23]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
+              Framework.  1997.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER), ITU-T Recommendation
+              X.690 (1997) | ISO/IEC International Standard
+              8825-1:1998.
+
+7.2  Informative References
+
+   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-certpathbuild.  Work in Progress. 
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001, Marina del Rey CA
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+Appendix A.  PKINIT ASN.1 Module
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 24]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           DomainParameters, EcpkParameters
+               FROM PKIX1Algorithms88 { iso(1)
+                 identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-mod-pkix1-algorithms(17) }
+                 -- As defined in RFC 3279.
+
+           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 25]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       TrustedCA ::= SEQUENCE {
+          caName                  [0] IMPLICIT OCTET STRING,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies a CA by the CA's distinguished subject
+                   -- name.
+          certificateSerialNumber [1] INTEGER OPTIONAL,
+                   -- Specifies the CA certificate's serial number.
+                   -- The defintion of the certificate serial number
+                   -- is taken from X.509 [X.509-97].
+          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
+                   -- Identifies the CA's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 26]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+          ...
+       }
+
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [CLAR], for replay
+                   -- prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 27]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
+                   -- Each OCTET STRING contains a CMS type
+                   -- IssuerAndSerialNumber encoded according to
+                   -- [RFC3852].
+                   -- Each IssuerAndSerialNumber identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each TrustedCA identifies a CA or a CA
+                   -- certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 28]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+
+
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 29]
+
+Internet-Draft                   PKINIT                         May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu              Expires November 24, 2005              [Page 30]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt
new file mode 100644
index 00000000000..ab4aeb58c4c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt
@@ -0,0 +1,1730 @@
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: January 20, 2006                                         L. Zhu
+                                                   Microsoft Corporation
+                                                           July 19, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-27
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 20, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 1]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
+       3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
+       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 14
+       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
+     3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
+     3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+     7.1   Normative References . . . . . . . . . . . . . . . . . . . 23
+     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
+       Intellectual Property and Copyright Statements . . . . . . . . 31
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 2]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
+   the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [RFC4120], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce public-
+   key cryptography into Kerberos is in the initial authentication
+   exchange.  This document describes the methods and data formats for
+   integrating public-key cryptography into Kerberos initial
+   authentication.
+
+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 [RFC2119].
+
+   Both the AS and the TGS are referred to as the KDC.
+
+   In this document, the encryption key used to encrypt the enc-part
+   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 3]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   reply key.
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1  Definitions, Requirements, and Constants
+
+3.1.1  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 4]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+
+3.1.2  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   PKINIT defines the following encryption types, for use in the AS-REQ
+   message to indicate acceptance of the corresponding algorithms that
+   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
+   the reply:
+
+       dsaWithSHA1-CmsOID                            9
+       md5WithRSAEncryption-CmsOID                  10
+       sha1WithRSAEncryption-CmsOID                 11
+       rc2CBC-EnvOID                                12
+       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
+       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
+       des-ede3-cbc-EnvOID                          15
+
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 5]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X690] (unless
+   otherwise noted).  All data structures carried in OCTET STRINGs must
+   be encoded according to the rules specified in corresponding
+   specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
+   key agreement [RFC3279]:
+
+       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v1.5)
+       id-RSAES-OAEP          (PKCS1 v2.0)
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 6]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+3.2  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 7]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 8]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkauthdata:
+       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+       pkinit(3) pkauthdata(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [CAPATH].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+
+
+
+Tung & Zhu              Expires January 20, 2006                [Page 9]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   7.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string needs to be as long as
+       the longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+
+3.2.2  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 10]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 11]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pksan:
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
+   client's X.509 certificate:
+
+       id-pkekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkekuoid(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 12]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the client's public key is not accepted, the KDC returns an error
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 13]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+3.2.3  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used:
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 14]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted. See Section 3.2.3.1.
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 15]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+          ...
+       }
+
+
+3.2.3.1  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only. be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExpiration field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered expired/
+       invalid.  When the server reuses DH keys then it MUST include a
+       serverDHNonce at least as long as the length of keys for the
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 16]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+       symmetric encryption system used to encrypt the AS reply.  Note
+       that including the serverDHNonce changes how the client and
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+
+
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 17]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+
+3.2.3.2  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
+   encKeyPack field, which contains data of type ReplyKeyPack:
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 18]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support for RSA keys at least 2048 bits in size.
+
+3.2.4  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 19]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Based on local policy, the client MAY require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
+
+       id-pkkdcekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkkdcekuoid(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 20]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+3.4  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+4.  Security Considerations
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 21]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
+   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
+   Jaganathan, Chaskiel M Grundman and Stefan Santesson.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 22]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+7.  References
+
+7.1  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 23]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
+              Framework.  1997.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER), ITU-T Recommendation
+              X.690 (1997) | ISO/IEC International Standard
+              8825-1:1998.
+
+7.2  Informative References
+
+   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-certpathbuild.  Work in Progress. 
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 24]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001, Marina del Rey CA
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           DomainParameters
+               FROM PKIX1Algorithms88 { iso(1)
+                 identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-mod-pkix1-algorithms(17) }
+                 -- As defined in RFC 3279.
+
+           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 25]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 26]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 27]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 28]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING, as specified in Section 2.3.3 of
+                   -- [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 29]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 30]
+
+Internet-Draft                   PKINIT                        July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu              Expires January 20, 2006               [Page 31]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt
new file mode 100644
index 00000000000..ae76eb8d2d3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt
@@ -0,0 +1,1897 @@
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: March 16, 2006                                           L. Zhu
+                                                   Microsoft Corporation
+                                                      September 12, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-28
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on March 16, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 1]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 10
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 14
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 20
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 25
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 31
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
+   Intellectual Property and Copyright Statements . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 2]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
+   the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [RFC4120], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce public-
+   key cryptography into Kerberos is in the initial authentication
+   exchange.  This document describes the methods and data formats for
+   integrating public-key cryptography into Kerberos initial
+   authentication.
+
+
+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 [RFC2119].
+
+   Both the AS and the TGS are referred to as the KDC.
+
+   In this document, the encryption key used to encrypt the enc-part
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 3]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
+   reply key.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 4]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pksan
+   (as defined in Section 3.2.2) otherName of the Subject Alternative
+   Name (SAN) extension in X.509 certificates [RFC3280], if present.
+
+3.1.2.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   PKINIT defines the following encryption types, for use in the AS-REQ
+   message to indicate acceptance of the corresponding algorithms that
+   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
+   the reply:
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 5]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       dsaWithSHA1-CmsOID                            9
+       md5WithRSAEncryption-CmsOID                  10
+       sha1WithRSAEncryption-CmsOID                 11
+       rc2CBC-EnvOID                                12
+       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
+       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
+       des-ede3-cbc-EnvOID                          15
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X690] (unless
+   otherwise noted).  All data structures carried in OCTET STRINGs must
+   be encoded according to the rules specified in corresponding
+   specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3.  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
+   key agreement [RFC3279]:
+
+       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v1.5)
+       id-RSAES-OAEP          (PKCS1 v2.0)
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 6]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 7]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 8]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkauthdata:
+       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+       pkinit(3) pkauthdata(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [CAPATH].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+
+
+
+Tung & Zhu               Expires March 16, 2006                 [Page 9]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   7.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string needs to be as long as
+       the longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 10]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 11]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pksan:
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
+   client's X.509 certificate:
+
+       id-pkekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkekuoid(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 12]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the client's public key is not accepted, the KDC returns an error
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 13]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+3.2.3.  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used:
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 14]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted. See Section 3.2.3.1.
+          ...
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 15]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       }
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only. be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExpiration field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered expired/
+       invalid.  When the server reuses DH keys then it MUST include a
+       serverDHNonce at least as long as the length of keys for the
+       symmetric encryption system used to encrypt the AS reply.  Note
+       that including the serverDHNonce changes how the client and
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 16]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 17]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
+   encKeyPack field, which contains data of type ReplyKeyPack:
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 18]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support for RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   If the public key encrytion method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 19]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
+
+       id-pkkdcekuoid OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) pkkdcekuoid(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pksan SAN, this certificate is certified by the issuing CA as a
+   KDC certificate, therefore the id-pkkdcekuoid EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 20]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+4.  Security Considerations
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 21]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pksan SAN and/or restricting the
+   certificate usage by using the id-pkkdcekuoid EKU, as described in
+   Section 3.2.4), the client MUST verify that the KDC certificate's
+   issuing CA is authorized to issue KDC certificates for that target
+   realm.  Otherwise, the binding between the KDC certificate and the
+   KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkkdcekuoid EKU or that the realm be
+   specified with the id-pksan SAN.
+
+   It is the responsibility of the PKI administrators for an
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 22]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
+   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
+   Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and
+   Aaron D. Jaggard.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 23]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 24]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
+              Framework.  1997.
+              
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER), ITU-T Recommendation
+              X.690 (1997) | ISO/IEC International Standard
+              8825-1:1998.
+
+7.2.  Informative References
+
+   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-certpathbuild.  Work in Progress. 
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 25]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pksan OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509-sanan (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 26]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 27]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 28]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is id-pkrkeydata
+                   -- (1.2.840.113549.1.7.3) and the eContent field
+                   -- contains the DER encoding of the type
+                   -- ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 29]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+           nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 30]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 31]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 32]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001, Marina del Rey CA
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 33]
+
+Internet-Draft                   PKINIT                   September 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu               Expires March 16, 2006                [Page 34]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt
new file mode 100644
index 00000000000..1c70b180451
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt
@@ -0,0 +1,2013 @@
+NETWORK WORKING GROUP                                            B. Tung
+Internet-Draft                        USC Information Sciences Institute
+Expires: April 22, 2006                                           L. Zhu
+                                                   Microsoft Corporation
+                                                        October 19, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-29
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 22, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 1]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  4
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  4
+       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 10
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 14
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 20
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 21
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 26
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 26
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 32
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations  . . . . . . . . . . . . . . . 33
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
+   Intellectual Property and Copyright Statements . . . . . . . . . . 36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 2]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
+   the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [RFC4120], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce public-
+   key cryptography into Kerberos is in the initial authentication
+   exchange.  This document describes the methods and data formats for
+   integrating public-key cryptography into Kerberos initial
+   authentication.
+
+
+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 [RFC2119].
+
+   Both the AS and the TGS are referred to as the KDC.
+
+   In this document, the encryption key used to encrypt the enc-part
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 3]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
+   reply key.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 4]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
+   present.
+
+3.1.2.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   PKINIT defines the following encryption types, for use in the etype
+   field of the AS-REQ [RFC4120] message to indicate acceptance of the
+   corresponding algorithms that can used by Cryptographic Message
+   Syntax (CMS) [RFC3852] messages in the reply:
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 5]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       dsaWithSHA1-CmsOID                            9
+          -- Indicates that the client supports dsaWithSHA1
+       md5WithRSAEncryption-CmsOID                  10
+          -- Indicates that the client supports md5WithRSAEncryption
+       sha1WithRSAEncryption-CmsOID                 11
+          -- Indicates that the client supports sha1WithRSAEncryption
+       rc2CBC-EnvOID                                12
+          -- Indicates that the client supports rc2CBC
+       rsaEncryption-EnvOID                         13
+          -- Indicates that the client supports
+          --  rsaEncryption (PKCS1 v2.1)
+       id-RSAES-OAEP-EnvOID                         14
+          -- Indicates that the client supports
+          -- id-RSAES-OAEP (PKCS1 v2.1)
+       des-ede3-cbc-EnvOID                          15
+          -- Indicates that the client supports des-ede3-cbc
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs must be encoded according to the rules specified in
+   corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode infinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3.  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
+   key agreement [RFC3279]:
+
+       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
+
+   PKINIT uses the following signature algorithm identifiers [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 6]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   PKINIT uses the following encryption algorithm identifiers [RFC3447]
+   for encrypting the temporary key with a public key:
+
+       rsaEncryption          (PKCS1 v2.1)
+       id-RSAES-OAEP          (PKCS1 v2.1)
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+       des-ede3-cbc           (three-key 3DES, CBC mode)
+       rc2-cbc                (RC2, CBC mode)
+       id-aes256-CBC          (AES-256, CBC mode)
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 7]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 8]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the signedAuthPack field is
+   filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+
+
+
+Tung & Zhu               Expires April 22, 2006                 [Page 9]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [CAPATH].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   6.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   7.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string needs to be as long as
+       the longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 10]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 11]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 12]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the client's public key is not accepted, the KDC returns an error
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 13]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+3.2.3.  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 14]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 15]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted. See Section 3.2.3.1.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   5.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 16]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only. be left empty if
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   6.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExpiration field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered expired/
+       invalid.  When the server reuses DH keys then it MUST include a
+       serverDHNonce at least as long as the length of keys for the
+       symmetric encryption system used to encrypt the AS reply.  Note
+       that including the serverDHNonce changes how the client and
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 17]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains a ContentInfo structure
+   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
+   encKeyPack field, which contains data of type ReplyKeyPack:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 18]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack.
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature over the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may only be left empty if
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 19]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       the KDC public key specified by the kdcPkId field in the PA-PK-
+       AS-REQ was used for signing.  Otherwise, for path validation,
+       these certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [CAPATH].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support for RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 20]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 21]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+4.  Security Considerations
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 22]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 23]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
+   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
+   Jaganathan, and Chaskiel M Grundman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26, the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 24]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 25]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [X.509-97] ITU-T Recommendation X.509: The Directory - Authentication 
+              Framework, 1997.
+                    
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
+              Information technology - Abstract Syntax Notation One 
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
+              Information technology - ASN.1 encoding Rules: Specification 
+              of Basic Encoding Rules (BER), Canonical Encoding Rules 
+              (CER) and Distinguished Encoding Rules (DER).
+
+7.2.  Informative References
+
+   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-certpathbuild.  Work in Progress. 
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)". 
+              
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 26]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 27]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- A list of CAs, trusted by the client, that can
+                   -- be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 28]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 29]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 30]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+           nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the PKAuthenticator of the
+                   -- request if DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if DH keys are reused. If
+                   -- this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 31]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 32]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to better interoperate with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 33]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
+   serverAuth EKU and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC and the intended
+   purpose of these KDC certificates be restricted by the presence of
+   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+   contains a UTF8 encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are domain
+   style realm names and strictly in upper case.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 34]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+Authors' Addresses
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 35]
+
+Internet-Draft                   PKINIT                     October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Tung & Zhu               Expires April 22, 2006                [Page 36]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt
new file mode 100644
index 00000000000..ca5205a65a2
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt
@@ -0,0 +1,2183 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Expires: June 2, 2006                                            B. Tung
+                                      USC Information Sciences Institute
+                                                       November 29, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-30
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on June 2, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 1]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  5
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  5
+       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 12
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 16
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 24
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 24
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 29
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 35
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations  . . . . . . . . . . . . . . . 36
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
+   Intellectual Property and Copyright Statements . . . . . . . . . . 39
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 2]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
+   the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [RFC4120], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, public-key cryptography (in conjunction with an
+   established Public Key Infrastructure) permits authentication without
+   prior registration with a KDC.  Adding it to Kerberos allows the
+   widespread use of Kerberized applications by clients without
+   requiring them to register first with a KDC--a requirement that has
+   no inherent security benefit.
+
+   As noted above, a convenient and efficient place to introduce public-
+   key cryptography into Kerberos is in the initial authentication
+   exchange.  This document describes the methods and data formats for
+   integrating public-key cryptography into Kerberos initial
+   authentication.
+
+
+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 [RFC2119].
+
+   Both the AS and the TGS are referred to as the KDC.
+
+   In this document, the encryption key used to encrypt the enc-part
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 3]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
+   reply key.
+
+   In this document, an empty sequence in an optional field can be
+   either included or omitted: both encodings are permitted and
+   considered equivalent.
+
+   In this document, the term "Modular Exponential Diffie-Hellman" is
+   used to refer to the Diffie-Hellman key exchange as described in
+   [RFC2631], in order to differentiate it from other equivalent
+   representations of the same key agreement algorithm.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 4]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
+   present.
+
+3.1.2.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          77
+       KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED             78
+       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   79
+
+   PKINIT uses the following typed data types for errors:
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 5]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs must be encoded according to the rules specified in
+   corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER but not DER; specifically, they
+   may not be able to decode indefinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3.  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifier(s) for Modular
+   Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
+
+       dhpublicnumber (as described in [RFC3279])
+
+   PKINIT uses the following signature algorithm identifiers as defined
+   in [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers as defined
+   in [RFC3447] for encrypting the temporary key with a public key:
+
+       rsaEncryption
+       id-RSAES-OAEP
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
+       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 6]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
+
+   PKINIT defines the following encryption types, for use in the etype
+   field of the AS-REQ [RFC4120] message to indicate acceptance of the
+   corresponding algorithms that can used by Cryptographic Message
+   Syntax (CMS) [RFC3852] messages in the reply:
+
+       id-dsa-with-sha1-CmsOID                       9
+          -- Indicates that the client supports id-dsa-with-sha1.
+       md5WithRSAEncryption-CmsOID                  10
+          -- Indicates that the client supports md5WithRSAEncryption.
+       sha-1WithRSAEncryption-CmsOID                11
+          -- Indicates that the client supports sha-1WithRSAEncryption.
+       rc2-cbc-EnvOID                               12
+          -- Indicates that the client supports rc2-cbc.
+       rsaEncryption-EnvOID                         13
+          -- Indicates that the client supports rsaEncryption.
+       id-RSAES-OAEP-EnvOID                         14
+          -- Indicates that the client supports id-RSAES-OAEP.
+       des-ede3-cbc-EnvOID                          15
+          -- Indicates that the client supports des-ede3-cbc.
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 7]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 8]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure contained in the signedAuthPack
+   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+   is filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
+
+
+
+Zhu & Tung                Expires June 2, 2006                  [Page 9]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-authData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The AuthPack structure contains a PKAuthenticator, the client
+       public key information, the CMS encryption types supported by the
+       client and a DHNonce.  The pkAuthenticator field certifies to the
+       KDC that the client has recent knowledge of the signing key that
+       authenticates the client.  The clientPublicValue field specifies
+       Diffie-Hellman domain parameters and the client's public key
+       value.  The DH public key value is encoded as a BIT STRING
+       according to [RFC3279].  The clientPublicValue field is present
+       only if the client wishes to use the Diffie-Hellman key agreement
+       method.  The supportedCMSTypes field specifies the list of CMS
+       encryption types supported by the client in order of (decreasing)
+       preference.  The clientDHNonce field is described later in this
+       section.
+
+   6.  The ctime field in the PKAuthenticator structure contains the
+       current time on the client's host, and the cusec field contains
+       the microsecond part of the client's timestamp.  The ctime and
+       cusec fields are used together to specify a reasonably accurate
+       timestamp [RFC4120].  The nonce field is chosen randomly.  The
+       paChecksum field contains a SHA1 checksum that is performed over
+       the KDC-REQ-BODY [RFC4120].
+
+   7.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [RFC4158].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   8.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 10]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   9.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string MUST be as long as the
+       longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+   The ExternalPrincipalIdentifier structure is used in this document to
+   identify the subject's public key thereby the subject principal.
+   This structure is filled out as follows:
+
+   1.  The subjectName field contains a PKIX type Name encoded according
+       to [RFC3280].  This field identifies the certificate subject by
+       the distinguished subject name.  This field is REQUIRED when
+       there is a distinguished subject name present in the certificate
+       being used.
+
+   2.  The issuerAndSerialNumber field contains a CMS type
+       IssuerAndSerialNumber encoded according to [RFC3852].  This field
+       identifies a certificate of the subject.  This field is REQUIRED
+       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+       structures are defined in Section 3.2.2).
+
+   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
+       public key by a key identifier.  When an X.509 certificate is
+       referenced, this key identifier matches the X.509
+       subjectKeyIdentifier extension value.  When other certificate
+       formats are referenced, the documents that specify the
+       certificate format and their use with the CMS must include
+       details on matching the key identifier to the appropriate
+       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
+       CERTIFIERS (as defined in Section 3.2.2).
+
+   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+   of CAs, trusted by the client, that can be used to certify the KDC.
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 11]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+   SignerIdentifier encoded according to [RFC3852].  This field
+   identifies, if present, a particular KDC public key that the client
+   already has.
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+   (thereby its public key) trusted by the KDC.
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 12]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+   sent by the client) with an invalid signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 13]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit MUST be asserted when the intended
+   purpose of the client certificate is restricted with the id-pkinit-
+   KPClientAuth EKU.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 14]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the digest algorithm used in generating the CA signature for the
+   public key in any certificate of the request is not acceptable by the
+   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+   If the client's public key is not accepted with reasons other than
+   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
+   accompanying e-data currently defined for this error message.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   The AlgorithmIdentifier structure is defined in [RFC3280] and is
+   filled in according to [RFC3279].  More specifically Section 2.3.3 of
+   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
+   in the case where MODP Diffie-Hellman key exchange is used.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 15]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the digest algorithm used by the id-pkinit-authData is not
+   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+   The accompanying e-data MUST be encoded in TYPED-DATA although none
+   is defined at this point.
+
+3.2.3.  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+   path based on which the client certificate was validated.  Each
+   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 16]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 17]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-DHKeyData
+       according to [RFC3852].
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 18]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
+       and optionally the expiration time of the KDC's DH key being
+       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
+       field identifies KDC's DH public key.  This DH public key value
+       is encoded as a BIT STRING according to [RFC3279].  The nonce
+       field contains the nonce in the pkAuthenticator field in the
+       request if the DH keys are NOT reused.  The value of this nonce
+       field is 0 if the DH keys are reused.  The dhKeyExpiration field
+       is present if and only if the DH keys are reused.  If the
+       dhKeyExpiration field is present, the KDC's public key in this
+       KDCDHKeyInfo structure MUST NOT be used past the point of this
+       expiration time.  If this field is omitted then the serverDHNonce
+       field MUST also be omitted.
+
+   5.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   6.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
+       reuses DH keys then it MUST include an expiration time in the
+       dhKeyExpiration field.  Past the point of the expiration time,
+       the signature over the type DHRepInfo is considered expired/
+       invalid.  When the server reuses DH keys then it MUST include a
+       serverDHNonce at least as long as the length of keys for the
+       symmetric encryption system used to encrypt the AS reply.  Note
+       that including the serverDHNonce changes how the client and
+       server calculate the key to use to encrypt the reply; see below
+       for details.  The KDC SHOULD NOT reuse DH keys unless the
+       clientDHNonce field is present in the request.
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 19]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+   If the hash algorithm used in the key derivation function (currently
+   only octetstring2key() is defined) is not acceptable by the KDC, the
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 20]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains an encKeyPack structure where
+   the AS reply key is encrypted.
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+       Notes to CMS implementers: the signed attribute content-type MUST
+       be present in this SignedData instance and its value is id-
+       pkinit-rkeyData according to [RFC3852].
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack (as described below).
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature for the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       for the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 21]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+   Furthermore the KDC computes the checksum of the AS-REQ in the client
+   request.  This checksum is performed over the type AS-REQ and the
+   protocol key [RFC3961] of the checksum operation is the replyKey and
+   the key usage number is 6.  If the replyKey's enctype is "newer"
+   [RFC4120] [RFC4121], the checksum operation is the required checksum
+   operation [RFC3961] of that enctype.
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 22]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit MUST be asserted when the intended
+   purpose of KDC certificate is restricted with the id-pkinit-KPKdc
+   EKU.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 23]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 24]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+4.  Security Considerations
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 25]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+   When the Diffie-Hellman key exchange method is used, additional pre-
+   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
+   defined in this specification) is not bound to the AS_REQ by the
+   mechanisms discussed in this specification (meaning it may be dropped
+   or added by attackers without being detected by either the client or
+   the KDC).  Designers of additional pre-authentication data should
+   take that into consideration if such additional pre-authentication
+   data can be used in conjunction with the PA_PK_AS_REQ.  The future
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 26]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   work of the Kerberos working group is expected to update the hash
+   algorithms specified in this document and provide a generic mechanism
+   to bind additional pre-authentication data with the accompanying
+   AS_REQ.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+   Grundman and Jeffrey Altman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26, the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+7.  References
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 27]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 28]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
+              Information technology - Abstract Syntax Notation One 
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
+              Information technology - ASN.1 encoding Rules: Specification 
+              of Basic Encoding Rules (BER), Canonical Encoding Rules 
+              (CER) and Distinguished Encoding Rules (DER).
+
+7.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)".
+
+
+Zhu & Tung                Expires June 1, 2006                 [Page 27]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+              Nicholas, "Internet X.509 Public Key Infrastructure:
+              Certification Path Building", RFC 4158, September 2005.
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 29]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 30]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 31]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 32]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL
+                   -- Present if and only if dhKeyExpiration is
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 33]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+                   -- present.
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 34]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 35]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to better interoperate with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 36]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
+   serverAuth EKU and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC and the intended
+   purpose of these KDC certificates be restricted by the presence of
+   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+   contains a UTF8 encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are domain
+   style realm names and strictly in upper case.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 37]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 38]
+
+Internet-Draft                   PKINIT                    November 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Tung                Expires June 2, 2006                 [Page 39]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt
new file mode 100644
index 00000000000..5a0799144a0
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt
@@ -0,0 +1,2237 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Expires: June 15, 2006                                           B. Tung
+                                      USC Information Sciences Institute
+                                                       December 12, 2005
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-31
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on June 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 1]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  5
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  5
+       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
+       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 12
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 16
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 23
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 24
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 25
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 30
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 30
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 35
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations  . . . . . . . . . . . . . . . 37
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
+   Intellectual Property and Copyright Statements . . . . . . . . . . 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 2]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+1.  Introduction
+
+   A client typically authenticates itself to a service in Kerberos
+   using three distinct though related exchanges.  First, the client
+   requests a ticket-granting ticket (TGT) from the Kerberos
+   authentication server (AS).  Then, it uses the TGT to request a
+   service ticket from the Kerberos ticket-granting server (TGS).
+   Usually, the AS and TGS are integrated in a single device known as a
+   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
+   the service ticket to authenticate itself to the service.
+
+   The advantage afforded by the TGT is that the client exposes his
+   long-term secrets only once.  The TGT and its associated session key
+   can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.
+
+   As defined in [RFC4120], Kerberos authentication exchanges use
+   symmetric-key cryptography, in part for performance.  One
+   disadvantage of using symmetric-key cryptography is that the keys
+   must be shared, so that before a client can authenticate itself, he
+   must already be registered with the KDC.
+
+   Conversely, an established Public Key Infrastructure (PKI) already
+   provides key management and key distribution mechanisms that are
+   sufficient to establish authentication and secure communication.
+   Adding public-key cryptography to Kerberos allows Kerberized
+   applications to leverage these existing services.  In addition, human
+   users can avoid the inconvenience of managing strong passwords, by
+   using randomly generated strong public and private key pairs.
+
+   As noted above, a convenient and efficient place to introduce public-
+   key cryptography into Kerberos is in the initial authentication
+   exchange.  This document describes the methods and data formats for
+   integrating public-key cryptography into Kerberos initial
+   authentication.
+
+
+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 [RFC2119].
+
+   Both the AS and the TGS are referred to as the KDC.
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 3]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   In this protocol, both the client and the KDC have a public-private
+   key pair in order to prove their identities to each other over the
+   open network.  The client's key pair is used to authenticate the
+   client to the KDC, and the KDC's key pair is used to authenticate the
+   KDC to the client.  The term "signature key" is used to refer to the
+   private key of the key pair being used.
+
+   In this document, the encryption key used to encrypt the enc-part
+   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
+   reply key.
+
+   In this document, an empty sequence in an optional field can be
+   either included or omitted: both encodings are permitted and
+   considered equivalent.
+
+   In this document, the term "Modular Exponential Diffie-Hellman" is
+   used to refer to the Diffie-Hellman key exchange as described in
+   [RFC2631], in order to differentiate it from other equivalent
+   representations of the same key agreement algorithm.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 4]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
+   present.
+
+3.1.2.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 5]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
+       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          77
+       KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED             78
+       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   79
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs must be encoded according to the rules specified in
+   corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER; specifically, they may not be
+   able to decode indefinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3.  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+   PKINIT uses the following algorithm identifier(s) for Modular
+   Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
+
+       dhpublicnumber (as described in [RFC3279])
+
+   PKINIT uses the following signature algorithm identifiers as defined
+   in [RFC3279]:
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 6]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers as defined
+   in [RFC3447] for encrypting the temporary key with a public key:
+
+       rsaEncryption
+       id-RSAES-OAEP
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
+       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
+       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
+
+   PKINIT defines the following encryption types, for use in the etype
+   field of the AS-REQ [RFC4120] message to indicate acceptance of the
+   corresponding algorithms that can used by Cryptographic Message
+   Syntax (CMS) [RFC3852] messages in the reply:
+
+       id-dsa-with-sha1-CmsOID                       9
+          -- Indicates that the client supports id-dsa-with-sha1.
+       md5WithRSAEncryption-CmsOID                  10
+          -- Indicates that the client supports md5WithRSAEncryption.
+       sha-1WithRSAEncryption-CmsOID                11
+          -- Indicates that the client supports sha-1WithRSAEncryption.
+       rc2-cbc-EnvOID                               12
+          -- Indicates that the client supports rc2-cbc.
+       rsaEncryption-EnvOID                         13
+          -- Indicates that the client supports rsaEncryption.
+       id-RSAES-OAEP-EnvOID                         14
+          -- Indicates that the client supports id-RSAES-OAEP.
+       des-ede3-cbc-EnvOID                          15
+          -- Indicates that the client supports des-ede3-cbc.
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 7]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 8]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+
+
+
+Zhu & Tung                Expires June 15, 2006                 [Page 9]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure contained in the signedAuthPack
+   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+   is filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-authData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The AuthPack structure contains a PKAuthenticator, the client
+       public key information, the CMS encryption types supported by the
+       client and a DHNonce.  The pkAuthenticator field certifies to the
+       KDC that the client has recent knowledge of the signing key that
+       authenticates the client.  The clientPublicValue field specifies
+       Diffie-Hellman domain parameters and the client's public key
+       value.  The DH public key value is encoded as a BIT STRING
+       according to [RFC3279].  The clientPublicValue field is present
+       only if the client wishes to use the Diffie-Hellman key agreement
+       method.  The supportedCMSTypes field specifies the list of CMS
+       encryption types supported by the client in order of (decreasing)
+       preference.  The clientDHNonce field is described later in this
+       section.
+
+   6.  The ctime field in the PKAuthenticator structure contains the
+       current time on the client's host, and the cusec field contains
+       the microsecond part of the client's timestamp.  The ctime and
+       cusec fields are used together to specify a reasonably accurate
+       timestamp [RFC4120].  The nonce field is chosen randomly.  The
+       paChecksum field contains a SHA1 checksum that is performed over
+       the KDC-REQ-BODY [RFC4120].
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 10]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   7.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [RFC4158].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   8.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   9.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string MUST be as long as the
+       longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+   The ExternalPrincipalIdentifier structure is used in this document to
+   identify the subject's public key thereby the subject principal.
+   This structure is filled out as follows:
+
+   1.  The subjectName field contains a PKIX type Name encoded according
+       to [RFC3280].  This field identifies the certificate subject by
+       the distinguished subject name.  This field is REQUIRED when
+       there is a distinguished subject name present in the certificate
+       being used.
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 11]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   2.  The issuerAndSerialNumber field contains a CMS type
+       IssuerAndSerialNumber encoded according to [RFC3852].  This field
+       identifies a certificate of the subject.  This field is REQUIRED
+       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+       structures are defined in Section 3.2.2).
+
+   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
+       public key by a key identifier.  When an X.509 certificate is
+       referenced, this key identifier matches the X.509
+       subjectKeyIdentifier extension value.  When other certificate
+       formats are referenced, the documents that specify the
+       certificate format and their use with the CMS must include
+       details on matching the key identifier to the appropriate
+       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
+       CERTIFIERS (as defined in Section 3.2.2).
+
+   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+   of CAs, trusted by the client, that can be used to certify the KDC.
+   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+   SignerIdentifier encoded according to [RFC3852].  This field
+   identifies, if present, a particular KDC public key that the client
+   already has.
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 12]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+                   -- or a CA certificate (thereby its public key).
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+   (thereby its public key) trusted by the KDC.
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+   sent by the client) with an invalid signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 13]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 14]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the client's X.509 certificate is restricted
+   with the id-pkinit-KPClientAuth EKU.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the digest algorithm used in generating the CA signature for the
+   public key in any certificate of the request is not acceptable by the
+   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+   If the client's public key is not accepted with reasons other than
+   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
+   accompanying e-data currently defined for this error message.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 15]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   The AlgorithmIdentifier structure is defined in [RFC3280] and is
+   filled in according to [RFC3279].  More specifically Section 2.3.3 of
+   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
+   in the case where MODP Diffie-Hellman key exchange is used.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the digest algorithm used by the id-pkinit-authData is not
+   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+   The accompanying e-data MUST be encoded in TYPED-DATA although none
+   is defined at this point.
+
+3.2.3.  Generation of KDC Reply
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+   path based on which the client certificate was validated.  Each
+   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 16]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 17]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 18]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-DHKeyData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
+       and optionally the expiration time of the KDC's DH key being
+       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
+       field identifies KDC's DH public key.  This DH public key value
+       is encoded as a BIT STRING according to [RFC3279].  The nonce
+       field contains the nonce in the pkAuthenticator field in the
+       request if the DH keys are NOT reused.  The value of this nonce
+       field is 0 if the DH keys are reused.  The dhKeyExpiration field
+       is present if and only if the DH keys are reused.  If the
+       dhKeyExpiration field is present, the KDC's public key in this
+       KDCDHKeyInfo structure MUST NOT be used past the point of this
+       expiration time.  If this field is omitted then the serverDHNonce
+       field MUST also be omitted.
+
+   5.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   6.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 19]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys.  If the server reuses DH keys then
+       it MUST include an expiration time in the dhKeyExpiration field.
+       Past the point of the expiration time, the signature over the
+       type DHRepInfo is considered expired/invalid.  When the server
+       reuses DH keys then it MUST include a serverDHNonce at least as
+       long as the length of keys for the symmetric encryption system
+       used to encrypt the AS reply.  Note that including the
+       serverDHNonce changes how the client and server calculate the key
+       to use to encrypt the reply; see below for details.  The KDC
+       SHOULD NOT reuse DH keys unless the clientDHNonce field is
+       present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 20]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+   If the hash algorithm used in the key derivation function (currently
+   only octetstring2key() is defined) is not acceptable by the KDC, the
+   KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains the encKeyPack field where
+   the AS reply key is encrypted.
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 21]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       Notes to CMS implementers: the signed attribute content-type MUST
+       be present in this SignedData instance and its value is id-
+       pkinit-rkeyData according to [RFC3852].
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack (as described below).
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature for the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       for the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+   Furthermore the KDC computes the checksum of the AS-REQ in the client
+   request.  This checksum is performed over the type AS-REQ and the
+   protocol key [RFC3961] of the checksum operation is the replyKey and
+   the key usage number is 6.  If the replyKey's enctype is "newer"
+   [RFC4120] [RFC4121], the checksum operation is the required checksum
+   operation [RFC3961] of that enctype.
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 22]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 23]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the KDC's X.509 certificate is restricted
+   with the id-pkinit-KPKdc EKU.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 24]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+4.  Security Considerations
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 25]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 26]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+   When the Diffie-Hellman key exchange method is used, additional pre-
+   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
+   defined in this specification) is not bound to the AS_REQ by the
+   mechanisms discussed in this specification (meaning it may be dropped
+   or added by attackers without being detected by either the client or
+   the KDC).  Designers of additional pre-authentication data should
+   take that into consideration if such additional pre-authentication
+   data can be used in conjunction with the PA_PK_AS_REQ.  The future
+   work of the Kerberos working group is expected to update the hash
+   algorithms specified in this document and provide a generic mechanism
+   to bind additional pre-authentication data with the accompanying
+   AS_REQ.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+   Grundman and Jeffrey Altman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26, the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 27]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+7.  References
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 28]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
+              Information technology - Abstract Syntax Notation One 
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
+              Information technology - ASN.1 encoding Rules: Specification 
+              of Basic Encoding Rules (BER), Canonical Encoding Rules 
+              (CER) and Distinguished Encoding Rules (DER).
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 29]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+7.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)".
+
+   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+              Nicholas, "Internet X.509 Public Key Infrastructure:
+              Certification Path Building", RFC 4158, September 2005.
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 30]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 31]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 32]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING,
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 33]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 34]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 35]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 36]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to better interoperate with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
+   serverAuth EKU and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC and the intended
+   purpose of these KDC certificates be restricted by the presence of
+   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 37]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+   contains a UTF8 encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are domain
+   style realm names and strictly in upper case.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 38]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 39]
+
+Internet-Draft                   PKINIT                    December 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Tung                Expires June 15, 2006                [Page 40]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt
new file mode 100644
index 00000000000..b575aaaedc8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt
@@ -0,0 +1,2288 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Expires: July 15, 2006                                           B. Tung
+                                      USC Information Sciences Institute
+                                                        January 11, 2006
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-32
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on July 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 1]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  6
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  6
+       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  6
+       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  7
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  9
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  9
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 13
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 17
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 24
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 25
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 26
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 31
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 31
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 36
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations  . . . . . . . . . . . . . . . 38
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
+   Intellectual Property and Copyright Statements . . . . . . . . . . 41
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 2]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+1.  Introduction
+
+   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
+   party known as the Key Distribution Center (KDC) to negotiate shared
+   session keys between clients and services and provide mutual
+   authentication between them.
+
+   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
+   A Ticket encapsulates a symmetric key (the ticket session key) in an
+   envelope (a public message) intended for a specific service.  The
+   contents of the Ticket are encrypted with a symmetric key shared
+   between the service principal and the issuing KDC.  The encrypted
+   part of the Ticket contains the client principal name, amongst other
+   items.  An Authenticator is a record that can be shown to have been
+   recently generated using the ticket session key in the associated
+   Ticket.  The ticket session key is known by the client who requested
+   the ticket.  The contents of the Authenticator are encrypted with the
+   associated ticket session key.  The encrypted part of an
+   Authenticator contains a timestamp and the client principal name,
+   amongst other items.
+
+   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
+   following message exchanges between the client and the KDC, and the
+   client and the application service:
+
+    - The Authentication Service (AS) Exchange
+
+      The client obtains an "initial" ticket from the Kerberos
+      authentication server (AS), typically a Ticket Granting Ticket
+      (TGT).  The AS-REQ message and the AS-REP message are the request
+      and the reply message respectively between the client and the AS.
+
+    - The Ticket Granting Service (TGS) Exchange
+
+      The client subsequently uses the TGT to authenticate and request a
+      service ticket for a particular service, from the Kerberos ticket-
+      granting server (TGS).  The TGS-REQ message and the TGS-REP
+      message are the request and the reply message respectively between
+      the client and the TGS.
+
+    - The Client/Server Authentication Protocol (AP) Exchange
+
+      The client then makes a request with an AP-REQ message, consisting
+      of a service ticket and an authenticator that certifies the
+      client's possession of the ticket session key.  The server may
+      optionally reply with an AP-REP message.  AP exchanges typically
+      negotiate session specific symmetric keys.
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 3]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   Usually, the AS and TGS are integrated in a single device also known
+   as the KDC.
+
+      Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
+
+                          +--------------+
+               +--------->|  KDC         |
+       AS-REQ /   +-------|              |
+             /   /        +--------------+
+            /   /          ^           |
+           /    |AS-REP   /            |
+          |     |        / TGS-REQ     + TGS-REP
+          |     |       /             /
+          |     |      /             /
+          |     |     /   +---------+
+          |     |    /   /
+          |     |   /   /
+          |     |  /   /
+          |     v /   v
+         ++-------+------+             +-----------------+
+         |  Client       +------------>|  Application    |
+         |               |    AP-REQ   |  Server         |
+         |               |<------------|                 |
+         +---------------+    AP-REP   +-----------------+
+
+   In the AS exchange, the KDC reply contains the ticket session key,
+   amongst other items, that is encrypted using a key (the AS reply key)
+   shared between the client and the KDC.  The AS reply key is typically
+   derived from the client's password for human users.  Therefore for
+   human users the attack resistance strength of the Kerberos protocol
+   is no stronger than the strength of their passwords.
+
+   The use of asymmetric cryptography in the form of X.509 certificates
+   [RFC3280] is popular for facilitating non-repudiation and perfect
+   secrecy.  An established Public Key Infrastructure (PKI) provides key
+   management and key distribution mechanisms that can be used to
+   establish authentication and secure communication.  Adding public-key
+   cryptography to Kerberos provides a nice congruence to public-key
+   protocols, obviates the human users' burden to manage strong
+   passwords, and allows Kerberized applications to take advantage of
+   existing key services and identity management.
+
+   The advantage afforded by the Kerberos TGT is that the client exposes
+   his long-term secrets only once.  The TGT and its associated session
+   key can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 4]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   integrate public-key cryptography into Kerberos authentication.  In
+   addition, the use of symmetric cryptography after the initial
+   exchange is preferred for performance.
+
+   This document describes the methods and data formats using which the
+   client and the KDC can use public and private key pairs to mutually
+   authenticate in the AS exchange and negotiate the AS reply key, known
+   only by the client and the KDC, to encrypt the AS-REP sent by the
+   KDC.
+
+
+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 [RFC2119].
+
+   In this protocol, both the client and the KDC have a public-private
+   key pair in order to prove their identities to each other over the
+   open network.  The term "signature key" is used to refer to the
+   private key of the key pair being used.
+
+   The encryption key used to encrypt the enc-part field of the KDC-REP
+   in the AS-REP [RFC4120] is referred to as the AS reply key.
+
+   An empty sequence in an optional field can be either included or
+   omitted: both encodings are permitted and considered equivalent.
+
+   The term "Modular Exponential Diffie-Hellman" is used to refer to the
+   Diffie-Hellman key exchange as described in [RFC2631], in order to
+   differentiate it from other equivalent representations of the same
+   key agreement algorithm.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 5]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
+   present.
+
+3.1.2.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 6]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
+       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
+       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs must be encoded according to the rules specified in
+   corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped CMS objects encoded with BER; specifically, they may not be
+   able to decode indefinite length encodings.  To maximize
+   interoperability, implementers SHOULD encode CMS objects used in
+   PKINIT with DER.
+
+3.1.3.  Algorithm Identifiers
+
+   PKINIT does not define, but does make use of, the following algorithm
+   identifiers.
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 7]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   PKINIT uses the following algorithm identifier(s) for Modular
+   Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
+
+       dhpublicnumber (as described in [RFC3279])
+
+   PKINIT uses the following signature algorithm identifiers as defined
+   in [RFC3279]:
+
+       sha-1WithRSAEncryption (RSA with SHA1)
+       md5WithRSAEncryption   (RSA with MD5)
+       id-dsa-with-sha1       (DSA with SHA1)
+
+   PKINIT uses the following encryption algorithm identifiers as defined
+   in [RFC3447] for encrypting the temporary key with a public key:
+
+       rsaEncryption
+       id-RSAES-OAEP
+
+   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
+   for encrypting the AS reply key with the temporary key:
+
+       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
+       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
+       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
+
+   PKINIT defines the following encryption types, for use in the etype
+   field of the AS-REQ [RFC4120] message to indicate acceptance of the
+   corresponding algorithms that can used by Cryptographic Message
+   Syntax (CMS) [RFC3852] messages in the reply:
+
+       id-dsa-with-sha1-CmsOID                       9
+          -- Indicates that the client supports id-dsa-with-sha1.
+       md5WithRSAEncryption-CmsOID                  10
+          -- Indicates that the client supports md5WithRSAEncryption.
+       sha-1WithRSAEncryption-CmsOID                11
+          -- Indicates that the client supports sha-1WithRSAEncryption.
+       rc2-cbc-EnvOID                               12
+          -- Indicates that the client supports rc2-cbc.
+       rsaEncryption-EnvOID                         13
+          -- Indicates that the client supports rsaEncryption.
+       id-RSAES-OAEP-EnvOID                         14
+          -- Indicates that the client supports id-RSAES-OAEP.
+       des-ede3-cbc-EnvOID                          15
+          -- Indicates that the client supports des-ede3-cbc.
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 8]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+
+
+
+Zhu & Tung                Expires July 15, 2006                 [Page 9]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 10]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure contained in the signedAuthPack
+   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+   is filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-authData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The AuthPack structure contains a PKAuthenticator, the client
+       public key information, the CMS encryption types supported by the
+       client and a DHNonce.  The pkAuthenticator field certifies to the
+       KDC that the client has recent knowledge of the signing key that
+       authenticates the client.  The clientPublicValue field specifies
+       Diffie-Hellman domain parameters and the client's public key
+       value.  The DH public key value is encoded as a BIT STRING
+       according to [RFC3279].  The clientPublicValue field is present
+       only if the client wishes to use the Diffie-Hellman key agreement
+       method.  The supportedCMSTypes field specifies the list of CMS
+       encryption types supported by the client in order of (decreasing)
+       preference.  The clientDHNonce field is described later in this
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 11]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       section.
+
+   6.  The ctime field in the PKAuthenticator structure contains the
+       current time on the client's host, and the cusec field contains
+       the microsecond part of the client's timestamp.  The ctime and
+       cusec fields are used together to specify a reasonably accurate
+       timestamp [RFC4120].  The nonce field is chosen randomly.  The
+       paChecksum field MUST be present and it contains a SHA1 checksum
+       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
+       ease future migration from the use of SHA1, the paChecksum field
+       is made optional syntactically: when the request is extended to
+       negotiate hash algorithms, the new client wishing not to use SHA1
+       will send the request in the extended message syntax without the
+       paChecksum field.  The KDC conforming to this specification MUST
+       return a KRB-ERROR [RFC4120] message with the code
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
+       will allow a new client to retry with SHA1 if allowed by the
+       local policy.
+
+   7.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [RFC4158].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   8.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 12]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   9.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string MUST be as long as the
+       longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+   The ExternalPrincipalIdentifier structure is used in this document to
+   identify the subject's public key thereby the subject principal.
+   This structure is filled out as follows:
+
+   1.  The subjectName field contains a PKIX type Name encoded according
+       to [RFC3280].  This field identifies the certificate subject by
+       the distinguished subject name.  This field is REQUIRED when
+       there is a distinguished subject name present in the certificate
+       being used.
+
+   2.  The issuerAndSerialNumber field contains a CMS type
+       IssuerAndSerialNumber encoded according to [RFC3852].  This field
+       identifies a certificate of the subject.  This field is REQUIRED
+       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+       structures are defined in Section 3.2.2).
+
+   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
+       public key by a key identifier.  When an X.509 certificate is
+       referenced, this key identifier matches the X.509
+       subjectKeyIdentifier extension value.  When other certificate
+       formats are referenced, the documents that specify the
+       certificate format and their use with the CMS must include
+       details on matching the key identifier to the appropriate
+       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
+       CERTIFIERS (as defined in Section 3.2.2).
+
+   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+   of CAs, trusted by the client, that can be used to certify the KDC.
+   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+   SignerIdentifier encoded according to [RFC3852].  This field
+   identifies, if present, a particular KDC public key that the client
+   already has.
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 13]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+   (thereby its public key) trusted by the KDC.
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+   sent by the client) with an invalid signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 14]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 15]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   If the KDC does not have its own binding and there is no
+   KRB5PrincipalName name present in the client's X.509 certificate, or
+   if the Kerberos name in the request does not match the
+   KRB5PrincipalName in the client's X.509 certificate (including the
+   realm name), the KDC MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the client's X.509 certificate is restricted
+   with the id-pkinit-KPClientAuth EKU.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the digest algorithm used in generating the CA signature for the
+   public key in any certificate of the request is not acceptable by the
+   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+   If the client's public key is not accepted with reasons other than
+   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 16]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
+   accompanying e-data currently defined for this error message.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   The AlgorithmIdentifier structure is defined in [RFC3280] and is
+   filled in according to [RFC3279].  More specifically Section 2.3.3 of
+   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
+   in the case where MODP Diffie-Hellman key exchange is used.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the digest algorithm used by the id-pkinit-authData is not
+   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+   The accompanying e-data MUST be encoded in TYPED-DATA although none
+   is defined at this point.
+
+3.2.3.  Generation of KDC Reply
+
+   If the paChecksum filed in the request is not present, the KDC
+   conforming to this specification MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
+   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 17]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   defined by this specification).
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+   path based on which the client certificate was validated.  Each
+   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 18]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 19]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-DHKeyData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
+       and optionally the expiration time of the KDC's DH key being
+       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
+       field identifies KDC's DH public key.  This DH public key value
+       is encoded as a BIT STRING according to [RFC3279].  The nonce
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 20]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       field contains the nonce in the pkAuthenticator field in the
+       request if the DH keys are NOT reused.  The value of this nonce
+       field is 0 if the DH keys are reused.  The dhKeyExpiration field
+       is present if and only if the DH keys are reused.  If the
+       dhKeyExpiration field is present, the KDC's public key in this
+       KDCDHKeyInfo structure MUST NOT be used past the point of this
+       expiration time.  If this field is omitted then the serverDHNonce
+       field MUST also be omitted.
+
+   5.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   6.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys.  If the server reuses DH keys then
+       it MUST include an expiration time in the dhKeyExpiration field.
+       Past the point of the expiration time, the signature over the
+       type DHRepInfo is considered expired/invalid.  When the server
+       reuses DH keys then it MUST include a serverDHNonce at least as
+       long as the length of keys for the symmetric encryption system
+       used to encrypt the AS reply.  Note that including the
+       serverDHNonce changes how the client and server calculate the key
+       to use to encrypt the reply; see below for details.  The KDC
+       SHOULD NOT reuse DH keys unless the clientDHNonce field is
+       present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 21]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains the encKeyPack field where
+   the AS reply key is encrypted.
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 22]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+       Notes to CMS implementers: the signed attribute content-type MUST
+       be present in this SignedData instance and its value is id-
+       pkinit-rkeyData according to [RFC3852].
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack (as described below).
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature for the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       for the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 23]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+   Furthermore the KDC computes the checksum of the AS-REQ in the client
+   request.  This checksum is performed over the type AS-REQ and the
+   protocol key [RFC3961] of the checksum operation is the replyKey and
+   the key usage number is 6.  If the replyKey's enctype is "newer"
+   [RFC4120] [RFC4121], the checksum operation is the required checksum
+   operation [RFC3961] of that enctype.
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 24]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the KDC's X.509 certificate is restricted
+   with the id-pkinit-KPKdc EKU.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+   Implementation note: CAs issuing KDC certificates SHOULD place all
+   "short" and "fully-qualified" Kerberos realm names of the KDC (one
+   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
+   flexibility.
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 25]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+4.  Security Considerations
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 26]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  Using
+   such keys to wrap data encrypted under stronger conventional
+   cryptosystems may be inappropriate.
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 27]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
+   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
+   be used if the KDC itself vouches for the user's certificate.
+
+   When the Diffie-Hellman key exchange method is used, additional pre-
+   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
+   defined in this specification) is not bound to the AS_REQ by the
+   mechanisms discussed in this specification (meaning it may be dropped
+   or added by attackers without being detected by either the client or
+   the KDC).  Designers of additional pre-authentication data should
+   take that into consideration if such additional pre-authentication
+   data can be used in conjunction with the PA_PK_AS_REQ.  The future
+   work of the Kerberos working group is expected to update the hash
+   algorithms specified in this document and provide a generic mechanism
+   to bind additional pre-authentication data with the accompanying
+   AS_REQ.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 28]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+   Grundman and Jeffrey Altman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26, the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+7.  References
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 29]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 30]
+
+Internet-Draft                   PKINIT                     January 2006
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
+              Information technology - Abstract Syntax Notation One 
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
+              Information technology - ASN.1 encoding Rules: Specification 
+              of Basic Encoding Rules (BER), Canonical Encoding Rules 
+              (CER) and Distinguished Encoding Rules (DER).
+
+7.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)".
+
+   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+              Nicholas, "Internet X.509 Public Key Infrastructure:
+              Certification Path Building", RFC 4158, September 2005.
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 31]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 32]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS encryption types supported by the
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 33]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- client in order of (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 34]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 35]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 36]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 37]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to better interoperate with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
+   serverAuth EKU and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC and the intended
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 38]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   purpose of these KDC certificates be restricted by the presence of
+   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+   contains a UTF8 encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are domain
+   style realm names and strictly in upper case.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 39]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 40]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Tung                Expires July 15, 2006                [Page 41]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt
new file mode 100644
index 00000000000..6f84c1a71ef
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt
@@ -0,0 +1,2335 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Expires: July 28, 2006                                           B. Tung
+                                      USC Information Sciences Institute
+                                                        January 24, 2006
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-33
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on July 28, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 1]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  6
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  6
+       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  7
+       3.1.3.  Kerberos Encryption Types Defined for CMS
+               Algorithm Identifiers  . . . . . . . . . . . . . . . .  8
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  9
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  9
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 14
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 18
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 26
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 26
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 32
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 37
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations  . . . . . . . . . . . . . . . 39
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
+   Intellectual Property and Copyright Statements . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 2]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+1.  Introduction
+
+   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
+   party known as the Key Distribution Center (KDC) to negotiate shared
+   session keys between clients and services and provide mutual
+   authentication between them.
+
+   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
+   A Ticket encapsulates a symmetric key (the ticket session key) in an
+   envelope (a public message) intended for a specific service.  The
+   contents of the Ticket are encrypted with a symmetric key shared
+   between the service principal and the issuing KDC.  The encrypted
+   part of the Ticket contains the client principal name, amongst other
+   items.  An Authenticator is a record that can be shown to have been
+   recently generated using the ticket session key in the associated
+   Ticket.  The ticket session key is known by the client who requested
+   the ticket.  The contents of the Authenticator are encrypted with the
+   associated ticket session key.  The encrypted part of an
+   Authenticator contains a timestamp and the client principal name,
+   amongst other items.
+
+   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
+   following message exchanges between the client and the KDC, and the
+   client and the application service:
+
+    - The Authentication Service (AS) Exchange
+
+      The client obtains an "initial" ticket from the Kerberos
+      authentication server (AS), typically a Ticket Granting Ticket
+      (TGT).  The AS-REQ message and the AS-REP message are the request
+      and the reply message respectively between the client and the AS.
+
+    - The Ticket Granting Service (TGS) Exchange
+
+      The client subsequently uses the TGT to authenticate and request a
+      service ticket for a particular service, from the Kerberos ticket-
+      granting server (TGS).  The TGS-REQ message and the TGS-REP
+      message are the request and the reply message respectively between
+      the client and the TGS.
+
+    - The Client/Server Authentication Protocol (AP) Exchange
+
+      The client then makes a request with an AP-REQ message, consisting
+      of a service ticket and an authenticator that certifies the
+      client's possession of the ticket session key.  The server may
+      optionally reply with an AP-REP message.  AP exchanges typically
+      negotiate session specific symmetric keys.
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 3]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   Usually, the AS and TGS are integrated in a single device also known
+   as the KDC.
+
+      Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
+
+                          +--------------+
+               +--------->|  KDC         |
+       AS-REQ /   +-------|              |
+             /   /        +--------------+
+            /   /          ^           |
+           /    |AS-REP   /            |
+          |     |        / TGS-REQ     + TGS-REP
+          |     |       /             /
+          |     |      /             /
+          |     |     /   +---------+
+          |     |    /   /
+          |     |   /   /
+          |     |  /   /
+          |     v /   v
+         ++-------+------+             +-----------------+
+         |  Client       +------------>|  Application    |
+         |               |    AP-REQ   |  Server         |
+         |               |<------------|                 |
+         +---------------+    AP-REP   +-----------------+
+
+   In the AS exchange, the KDC reply contains the ticket session key,
+   amongst other items, that is encrypted using a key (the AS reply key)
+   shared between the client and the KDC.  The AS reply key is typically
+   derived from the client's password for human users.  Therefore for
+   human users the attack resistance strength of the Kerberos protocol
+   is no stronger than the strength of their passwords.
+
+   The use of asymmetric cryptography in the form of X.509 certificates
+   [RFC3280] is popular for facilitating data origin authentication and
+   perfect secrecy.  An established Public Key Infrastructure (PKI)
+   provides key management and key distribution mechanisms that can be
+   used to establish authentication and secure communication.  Adding
+   public-key cryptography to Kerberos provides a nice congruence to
+   public-key protocols, obviates the human users' burden to manage
+   strong passwords, and allows Kerberized applications to take
+   advantage of existing key services and identity management.
+
+   The advantage afforded by the Kerberos TGT is that the client exposes
+   his long-term secrets only once.  The TGT and its associated session
+   key can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 4]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   integrate public-key cryptography into Kerberos authentication.  In
+   addition, the use of symmetric cryptography after the initial
+   exchange is preferred for performance.
+
+   This document describes the methods and data formats using which the
+   client and the KDC can use public and private key pairs to mutually
+   authenticate in the AS exchange and negotiate the AS reply key, known
+   only by the client and the KDC, to encrypt the AS-REP sent by the
+   KDC.
+
+
+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 [RFC2119].
+
+   In this protocol, both the client and the KDC have a public-private
+   key pair in order to prove their identities to each other over the
+   open network.  The term "signature key" is used to refer to the
+   private key of the key pair being used.
+
+   The encryption key used to encrypt the enc-part field of the KDC-REP
+   in the AS-REP [RFC4120] is referred to as the AS reply key.
+
+   An empty sequence in an optional field can be either included or
+   omitted: both encodings are permitted and considered equivalent.
+
+   The term "Modular Exponential Diffie-Hellman" is used to refer to the
+   Diffie-Hellman key exchange as described in [RFC2631], in order to
+   differentiate it from other equivalent representations of the same
+   key agreement algorithm.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 5]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
+      sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
+
+   o  AS reply key delivery method: Diffie-Hellman key exchange
+      [RFC2631].
+
+   o  Algorithms identified in the contentEncryptionAlgorithm field of
+      the type EncryptedContentInfo [RFC3852] for encrypting the
+      temporary key in the encryptedKey field of the type
+      KeyTransRecipientInfo [RFC3852] with a public key, as described in
+      Section 3.2.3.2: rsaEncryption [RFC3447] [RFC3279].
+
+   o  Algorithms identified in the contentEncryptionAlgorithm field of
+      the type EncryptedContentInfo [RFC3852] for encrypting the AS
+      reply key with the temporary key contained in the encryptedKey
+      field of the type KeyTransRecipientInfo [RFC3852], as described in
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 6]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+      Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode)
+      [RFC3370].
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280].
+
+3.1.2.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
+       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
+       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs must be encoded according to the rules specified in
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 7]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
+   with BER; specifically, they may not be able to decode indefinite
+   length encodings.  To maximize interoperability, implementers SHOULD
+   encode CMS objects used in PKINIT with DER.
+
+3.1.3.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers
+
+   PKINIT defines the following Kerberos encryption type numbers
+   [RFC3961], which can be used in the etype field of the AS-REQ
+   [RFC4120] message to indicate to the KDC the client's acceptance of
+   the corresponding algorithms (including public encryption algorithms,
+   bulk encryption algorithms, and signature algorithms) for use with
+   Cryptographic Message Syntax (CMS) [RFC3852].
+
+   Per [RFC4120], the encryption types in the etype field are in the
+   decreasing preference order of the client.  Note that there is no
+   significance in the relative order between any two of different types
+   of algorithms: public key encryption algorithms, bulk encryption
+   algorithms and signature algorithms.
+
+   The presence of each of these encryption types in the etype field is
+   equivalent to the presence of the corresponding algorithm Object
+   Identifier (OID) in the supportedCMSTypes field as described in
+   Section 3.2.1.  And the preference order expressed in the
+   supportedCMSTypes field would override the preference order listed in
+   the etype field.
+
+
+    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
+    ============================== === ===============================
+    id-dsa-with-sha1-CmsOID        9   id-dsa-with-sha1 [RFC3279]
+    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3279]
+    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3279]
+    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
+    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3279]
+    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3279]
+    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]
+
+   The above encryption type numbers are used only to indicate support
+   for the use of the corresponding algorithms in PKINIT; they do not
+   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
+   be used in the etype field of the Kerberos EncryptedData type
+   [RFC4120].  The practice of assigning Kerberos encryption type
+   numbers to indicate support for CMS algorithms is considered
+   deprecated, and new numbers should not be assigned for this purpose.
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 8]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   Instead, the supportedCMSTypes field should be used to identify the
+   algorithms supported by the client and the preference order of the
+   client.
+
+   For maximum interoperability, however, PKINIT clients wishing to
+   indicate to the KDC the support for one or more of the algorithms
+   listed above SHOULD include the corresponding encryption type numbers
+   in the etype field of the AS-REQ.
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+
+
+
+Zhu & Tung                Expires July 28, 2006                 [Page 9]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 10]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- [RFC3280].
+                   -- List of CMS public key encryption algorithm
+                   -- identifiers, bulk encryption algorithm
+                   -- identifiers, or signature algorithm identifiers
+                   -- supported by the client in order of (decreasing)
+                   -- preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure contained in the signedAuthPack
+   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+   is filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-authData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 11]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The AuthPack structure contains a PKAuthenticator, the client
+       public key information, the CMS encryption types supported by the
+       client and a DHNonce.  The pkAuthenticator field certifies to the
+       KDC that the client has recent knowledge of the signing key that
+       authenticates the client.  The clientPublicValue field specifies
+       Diffie-Hellman domain parameters and the client's public key
+       value.  The DH public key value is encoded as a BIT STRING
+       according to [RFC3279].  The clientPublicValue field is present
+       only if the client wishes to use the Diffie-Hellman key agreement
+       method.  The supportedCMSTypes field specifies the list of CMS
+       algorithm identifiers that are supported by the client in order
+       of (decreasing) preference, and can be used to identify a
+       signature algorithm or a public key encryption algorithm in the
+       keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or
+       a bulk encryption algorithm in the contentEncryptionAlgorithm
+       field of the type EncryptedContentInfo [RFC3852] when encrypting
+       the AS reply key as described in Section 3.2.3.2.  However, there
+       is no significance in the relative order between any two of
+       different types of algorithms: public key encryption algorithms,
+       bulk encryption algorithms and signature algorithms.  The
+       clientDHNonce field is described later in this section.
+
+   6.  The ctime field in the PKAuthenticator structure contains the
+       current time on the client's host, and the cusec field contains
+       the microsecond part of the client's timestamp.  The ctime and
+       cusec fields are used together to specify a reasonably accurate
+       timestamp [RFC4120].  The nonce field is chosen randomly.  The
+       paChecksum field MUST be present and it contains a SHA1 checksum
+       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
+       ease future migration from the use of SHA1, the paChecksum field
+       is made optional syntactically: when the request is extended to
+       negotiate hash algorithms, the new client wishing not to use SHA1
+       will send the request in the extended message syntax without the
+       paChecksum field.  The KDC conforming to this specification MUST
+       return a KRB-ERROR [RFC4120] message with the code
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
+       will allow a new client to retry with SHA1 if allowed by the
+       local policy.
+
+   7.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 12]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       [RFC4158].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   8.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   9.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string MUST be as long as the
+       longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+   The ExternalPrincipalIdentifier structure is used in this document to
+   identify the subject's public key thereby the subject principal.
+   This structure is filled out as follows:
+
+   1.  The subjectName field contains a PKIX type Name encoded according
+       to [RFC3280].  This field identifies the certificate subject by
+       the distinguished subject name.  This field is REQUIRED when
+       there is a distinguished subject name present in the certificate
+       being used.
+
+   2.  The issuerAndSerialNumber field contains a CMS type
+       IssuerAndSerialNumber encoded according to [RFC3852].  This field
+       identifies a certificate of the subject.  This field is REQUIRED
+       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+       structures are defined in Section 3.2.2).
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 13]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
+       public key by a key identifier.  When an X.509 certificate is
+       referenced, this key identifier matches the X.509
+       subjectKeyIdentifier extension value.  When other certificate
+       formats are referenced, the documents that specify the
+       certificate format and their use with the CMS must include
+       details on matching the key identifier to the appropriate
+       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
+       CERTIFIERS (as defined in Section 3.2.2).
+
+   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+   of CAs, trusted by the client, that can be used to certify the KDC.
+   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+   SignerIdentifier encoded according to [RFC3852].  This field
+   identifies, if present, a particular KDC public key that the client
+   already has.
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+   (thereby its public key) trusted by the KDC.
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 14]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+   sent by the client) with an invalid signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 15]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the Kerberos client name in the AS-REQ does not match a name bound
+   by the KDC (the binding can be in the certificate, for example as
+   described above), or if there is no binding found by the KDC, the KDC
+   MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 16]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the client's X.509 certificate is restricted
+   with the id-pkinit-KPClientAuth EKU.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the digest algorithm used in generating the CA signature for the
+   public key in any certificate of the request is not acceptable by the
+   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+   If the client's public key is not accepted with reasons other than
+   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
+   accompanying e-data currently defined for this error message.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 17]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   The AlgorithmIdentifier structure is defined in [RFC3280] and is
+   filled in according to [RFC3279].  More specifically Section 2.3.3 of
+   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
+   in the case where MODP Diffie-Hellman key exchange is used.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the digest algorithm used by the id-pkinit-authData is not
+   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+   The accompanying e-data MUST be encoded in TYPED-DATA although none
+   is defined at this point.
+
+3.2.3.  Generation of KDC Reply
+
+   If the paChecksum filed in the request is not present, the KDC
+   conforming to this specification MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
+   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
+   defined by this specification).
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+   path based on which the client certificate was validated.  Each
+   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 18]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   (thereby its public key).
+
+   Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
+   data does permit empty SEQUENCEs to be encoded.  Such empty sequences
+   may only be used if the KDC itself vouches for the user's
+   certificate.
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 19]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 20]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-DHKeyData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
+       and optionally the expiration time of the KDC's DH key being
+       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
+       field identifies KDC's DH public key.  This DH public key value
+       is encoded as a BIT STRING according to [RFC3279].  The nonce
+       field contains the nonce in the pkAuthenticator field in the
+       request if the DH keys are NOT reused.  The value of this nonce
+       field is 0 if the DH keys are reused.  The dhKeyExpiration field
+       is present if and only if the DH keys are reused.  If the
+       dhKeyExpiration field is present, the KDC's public key in this
+       KDCDHKeyInfo structure MUST NOT be used past the point of this
+       expiration time.  If this field is omitted then the serverDHNonce
+       field MUST also be omitted.
+
+   5.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   6.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 21]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys.  If the server reuses DH keys then
+       it MUST include an expiration time in the dhKeyExpiration field.
+       Past the point of the expiration time, the signature over the
+       type DHRepInfo is considered expired/invalid.  When the server
+       reuses DH keys then it MUST include a serverDHNonce at least as
+       long as the length of keys for the symmetric encryption system
+       used to encrypt the AS reply.  Note that including the
+       serverDHNonce changes how the client and server calculate the key
+       to use to encrypt the reply; see below for details.  The KDC
+       SHOULD NOT reuse DH keys unless the clientDHNonce field is
+       present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 22]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains the encKeyPack field where
+   the AS reply key is encrypted.
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+       Notes to CMS implementers: the signed attribute content-type MUST
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 23]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       be present in this SignedData instance and its value is id-
+       pkinit-rkeyData according to [RFC3852].
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack (as described below).
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature for the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       for the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+   Furthermore the KDC computes the checksum of the AS-REQ in the client
+   request.  This checksum is performed over the type AS-REQ and the
+   protocol key [RFC3961] of the checksum operation is the replyKey and
+   the key usage number is 6.  If the replyKey's enctype is "newer"
+   [RFC4120] [RFC4121], the checksum operation is the required checksum
+   operation [RFC3961] of that enctype.
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 24]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 25]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the KDC's X.509 certificate is restricted
+   with the id-pkinit-KPKdc EKU.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 26]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+4.  Security Considerations
+
+   The security of cryptographic algorithms is dependent on generating
+   secret quantities [RFC4086].  The number of truly random bits is
+   extremely important to determining the attack resistance strength of
+   the cryptosystem, for example, the secret Diffie-Hellman exponents
+   must be chosen based on n truly random bits (where n is the system
+   security requirement).  The security of the overall system is
+   significantly weakened by using insufficient random inputs: a
+   sophisticated attacker may find it easier to reproduce the
+   environment that produced the secret quantities and to search the
+   resulting small set of possibilities than to locate the quantities in
+   the whole of the potential number space.
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 27]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  When
+   using such weak asymmetric keys to protect/exchange stronger
+   symmetric Keys, the attack resistant strength of the overall system
+   is no better than that of these weak keys [RFC3766].
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 28]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   When the Diffie-Hellman key exchange method is used, additional pre-
+   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
+   defined in this specification) is not bound to the AS_REQ by the
+   mechanisms discussed in this specification (meaning it may be dropped
+   or added by attackers without being detected by either the client or
+   the KDC).  Designers of additional pre-authentication data should
+   take that into consideration if such additional pre-authentication
+   data can be used in conjunction with the PA_PK_AS_REQ.  The future
+   work of the Kerberos working group is expected to update the hash
+   algorithms specified in this document and provide a generic mechanism
+   to bind additional pre-authentication data with the accompanying
+   AS_REQ.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+   Grundman and Jeffrey Altman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26, the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 29]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+7.  References
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 30]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
+              Information technology - Abstract Syntax Notation One 
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
+              Information technology - ASN.1 encoding Rules: Specification 
+              of Basic Encoding Rules (BER), Canonical Encoding Rules 
+              (CER) and Distinguished Encoding Rules (DER).
+
+7.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)".
+              April 1999.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+              Nicholas, "Internet X.509 Public Key Infrastructure:
+              Certification Path Building", RFC 4158, September 2005.
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 32]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 33]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS public key encryption algorithm
+                   -- identifiers, bulk encryption algorithm
+                   -- identifiers, or signature algorithm identifiers
+                   -- supported by the client in order of (decreasing)
+                   -- preference.
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 34]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 35]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 36]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 37]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 38]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to better interoperate with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
+   serverAuth EKU and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC and the intended
+   purpose of these KDC certificates be restricted by the presence of
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 39]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+   contains a UTF8 encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are domain
+   style realm names and strictly in upper case.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 40]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 41]
+
+Internet-Draft                   PKINIT                     January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Tung                Expires July 28, 2006                [Page 42]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt
new file mode 100644
index 00000000000..af84a08ff6b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt
@@ -0,0 +1,2346 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Expires: August 11, 2006                                         B. Tung
+                                      USC Information Sciences Institute
+                                                        February 7, 2006
+
+
+     Public Key Cryptography for Initial Authentication in Kerberos
+                   draft-ietf-cat-kerberos-pk-init-34
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on August 11, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 1]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  6
+       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  6
+       3.1.2.  Recommended Algorithms . . . . . . . . . . . . . . . .  6
+       3.1.3.  Defined Message and Encryption Types . . . . . . . . .  7
+       3.1.4.  Kerberos Encryption Types Defined for CMS
+               Algorithm Identifiers  . . . . . . . . . . . . . . . .  8
+     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  9
+       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  9
+       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 14
+       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 18
+       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25
+     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 26
+     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 27
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 32
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32
+   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 38
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations  . . . . . . . . . . . . . . . 40
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
+   Intellectual Property and Copyright Statements . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 2]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+1.  Introduction
+
+   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
+   party known as the Key Distribution Center (KDC) to negotiate shared
+   session keys between clients and services and provide mutual
+   authentication between them.
+
+   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
+   A Ticket encapsulates a symmetric key (the ticket session key) in an
+   envelope (a public message) intended for a specific service.  The
+   contents of the Ticket are encrypted with a symmetric key shared
+   between the service principal and the issuing KDC.  The encrypted
+   part of the Ticket contains the client principal name, amongst other
+   items.  An Authenticator is a record that can be shown to have been
+   recently generated using the ticket session key in the associated
+   Ticket.  The ticket session key is known by the client who requested
+   the ticket.  The contents of the Authenticator are encrypted with the
+   associated ticket session key.  The encrypted part of an
+   Authenticator contains a timestamp and the client principal name,
+   amongst other items.
+
+   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
+   following message exchanges between the client and the KDC, and the
+   client and the application service:
+
+    - The Authentication Service (AS) Exchange
+
+      The client obtains an "initial" ticket from the Kerberos
+      authentication server (AS), typically a Ticket Granting Ticket
+      (TGT).  The AS-REQ message and the AS-REP message are the request
+      and the reply message respectively between the client and the AS.
+
+    - The Ticket Granting Service (TGS) Exchange
+
+      The client subsequently uses the TGT to authenticate and request a
+      service ticket for a particular service, from the Kerberos ticket-
+      granting server (TGS).  The TGS-REQ message and the TGS-REP
+      message are the request and the reply message respectively between
+      the client and the TGS.
+
+    - The Client/Server Authentication Protocol (AP) Exchange
+
+      The client then makes a request with an AP-REQ message, consisting
+      of a service ticket and an authenticator that certifies the
+      client's possession of the ticket session key.  The server may
+      optionally reply with an AP-REP message.  AP exchanges typically
+      negotiate session specific symmetric keys.
+
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 3]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   Usually, the AS and TGS are integrated in a single device also known
+   as the KDC.
+
+      Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
+
+                          +--------------+
+               +--------->|  KDC         |
+       AS-REQ /   +-------|              |
+             /   /        +--------------+
+            /   /          ^           |
+           /    |AS-REP   /            |
+          |     |        / TGS-REQ     + TGS-REP
+          |     |       /             /
+          |     |      /             /
+          |     |     /   +---------+
+          |     |    /   /
+          |     |   /   /
+          |     |  /   /
+          |     v /   v
+         ++-------+------+             +-----------------+
+         |  Client       +------------>|  Application    |
+         |               |    AP-REQ   |  Server         |
+         |               |<------------|                 |
+         +---------------+    AP-REP   +-----------------+
+
+   In the AS exchange, the KDC reply contains the ticket session key,
+   amongst other items, that is encrypted using a key (the AS reply key)
+   shared between the client and the KDC.  The AS reply key is typically
+   derived from the client's password for human users.  Therefore for
+   human users the attack resistance strength of the Kerberos protocol
+   is no stronger than the strength of their passwords.
+
+   The use of asymmetric cryptography in the form of X.509 certificates
+   [RFC3280] is popular for facilitating data origin authentication and
+   perfect secrecy.  An established Public Key Infrastructure (PKI)
+   provides key management and key distribution mechanisms that can be
+   used to establish authentication and secure communication.  Adding
+   public-key cryptography to Kerberos provides a nice congruence to
+   public-key protocols, obviates the human users' burden to manage
+   strong passwords, and allows Kerberized applications to take
+   advantage of existing key services and identity management.
+
+   The advantage afforded by the Kerberos TGT is that the client exposes
+   his long-term secrets only once.  The TGT and its associated session
+   key can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 4]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   integrate public-key cryptography into Kerberos authentication.  In
+   addition, the use of symmetric cryptography after the initial
+   exchange is preferred for performance.
+
+   This document describes the methods and data formats using which the
+   client and the KDC can use public and private key pairs to mutually
+   authenticate in the AS exchange and negotiate the AS reply key, known
+   only by the client and the KDC, to encrypt the AS-REP sent by the
+   KDC.
+
+
+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 [RFC2119].
+
+   In this protocol, both the client and the KDC have a public-private
+   key pair in order to prove their identities to each other over the
+   open network.  The term "signature key" is used to refer to the
+   private key of the key pair being used.
+
+   The encryption key used to encrypt the enc-part field of the KDC-REP
+   in the AS-REP [RFC4120] is referred to as the AS reply key.
+
+   An empty sequence in an optional field can be either included or
+   omitted: both encodings are permitted and considered equivalent.
+
+   The term "Modular Exponential Diffie-Hellman" is used to refer to the
+   Diffie-Hellman key exchange as described in [RFC2631], in order to
+   differentiate it from other equivalent representations of the same
+   key agreement algorithm.
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 5]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctype(s): aes128-cts-hmac-sha1-96 and aes256-cts-
+      hmac-sha1-96 [RFC3962].
+
+   o  Signature algorithm(s): sha-1WithRSAEncryption [RFC3370].
+
+   o  AS reply key delivery method(s): the Diffie-Hellman key delivery
+      method as described in Section 3.2.3.1.
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280].
+
+3.1.2.  Recommended Algorithms
+
+   All PKINIT implementations SHOULD support the following algorithms:
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 6]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   o  AS reply key delivery method(s): the public key encryption key
+      delivery method as described in Section 3.2.3.2.
+
+   For implementations that support the public key encryption key
+   delivery method, the following algorithms MUST be supported:
+
+   a) Key transport algorithm(s) identified in the
+      keyEncryptionAlgorithm field of the type KeyTransRecipientInfo
+      [RFC3852] for encrypting the temporary key in the encryptedKey
+      field [RFC3852] with a public key, as described in
+      Section 3.2.3.2: rsaEncryption (this is the RSAES-PKCS1-v1_5
+      encryption scheme) [RFC3370] [RFC3447].
+
+   b) Content encryption algorithm(s) identified in the
+      contentEncryptionAlgorithm field of the type EncryptedContentInfo
+      [RFC3852] for encrypting the AS reply key with the temporary key
+      contained in the encryptedKey field of the type
+      KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
+      des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
+
+3.1.3.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
+       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
+       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
+       KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED  81
+
+   PKINIT uses the following typed data types for errors:
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 7]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in
+   Appendix A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs must be encoded according to the rules specified in
+   corresponding specifications.
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
+   with BER; specifically, they may not be able to decode indefinite
+   length encodings.  To maximize interoperability, implementers SHOULD
+   encode CMS objects used in PKINIT with DER.
+
+3.1.4.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers
+
+   PKINIT defines the following Kerberos encryption type numbers
+   [RFC3961], which can be used in the etype field of the AS-REQ
+   [RFC4120] message to indicate to the KDC the client's acceptance of
+   the corresponding algorithms (including key transport algorithms
+   [RFC3370], content encryption algorithms [RFC3370], and signature
+   algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
+   [RFC3370].
+
+   Per [RFC4120], the encryption types in the etype field are in the
+   decreasing preference order of the client.  Note that there is no
+   significance in the relative order between any two of different types
+   of algorithms: key transport algorithms, content encryption
+   algorithms and signature algorithms.
+
+   The presence of each of these encryption types in the etype field is
+   equivalent to the presence of the corresponding algorithm Object
+   Identifier (OID) in the supportedCMSTypes field as described in
+   Section 3.2.1.  And the preference order expressed in the
+   supportedCMSTypes field would override the preference order listed in
+   the etype field.
+
+
+
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 8]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
+    ============================== === ===============================
+    id-dsa-with-sha1-CmsOID         9  id-dsa-with-sha1 [RFC3370]
+    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3370]
+    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3370]
+    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
+    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3370]
+    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3560]
+    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]
+
+   The above encryption type numbers are used only to indicate support
+   for the use of the corresponding algorithms in PKINIT; they do not
+   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
+   be used in the etype field of the Kerberos EncryptedData type
+   [RFC4120].  The practice of assigning Kerberos encryption type
+   numbers to indicate support for CMS algorithms is considered
+   deprecated, and new numbers should not be assigned for this purpose.
+   Instead, the supportedCMSTypes field should be used to identify the
+   algorithms supported by the client and the preference order of the
+   client.
+
+   For maximum interoperability, however, PKINIT clients wishing to
+   indicate to the KDC the support for one or more of the algorithms
+   listed above SHOULD include the corresponding encryption type
+   number(s) in the etype field of the AS-REQ.
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+
+
+
+Zhu & Tung               Expires August 11, 2006                [Page 9]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 10]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS algorithm [RFC3370] identifiers
+                   -- that identify key transport algorithms, or
+                   -- content encryption algorithms, or signature
+                   -- algorithms supported by the client in order of
+                   -- (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure contained in the signedAuthPack
+   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+   is filled out as follows:
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 11]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-authData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The AuthPack structure contains a PKAuthenticator, the client
+       public key information, the CMS encryption types supported by the
+       client and a DHNonce.  The pkAuthenticator field certifies to the
+       KDC that the client has recent knowledge of the signing key that
+       authenticates the client.  The clientPublicValue field specifies
+       Diffie-Hellman domain parameters and the client's public key
+       value.  The DH public key value is encoded as a BIT STRING
+       according to [RFC3279].  The clientPublicValue field is present
+       only if the client wishes to use the Diffie-Hellman key agreement
+       method.  The supportedCMSTypes field specifies the list of CMS
+       algorithm identifiers that are supported by the client in order
+       of (decreasing) preference, and can be used to identify a
+       signature algorithm or a key transport algorithm [RFC3370] in the
+       keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or
+       a content encryption algorithm [RFC3370] in the
+       contentEncryptionAlgorithm field of the type EncryptedContentInfo
+       [RFC3852] when encrypting the AS reply key as described in
+       Section 3.2.3.2.  However, there is no significance in the
+       relative order between any two of different types of algorithms:
+       key transport algorithms, content encryption algorithms, and
+       signature algorithms.  The clientDHNonce field is described later
+       in this section.
+
+   6.  The ctime field in the PKAuthenticator structure contains the
+       current time on the client's host, and the cusec field contains
+       the microsecond part of the client's timestamp.  The ctime and
+       cusec fields are used together to specify a reasonably accurate
+       timestamp [RFC4120].  The nonce field is chosen randomly.  The
+       paChecksum field MUST be present and it contains a SHA1 checksum
+       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
+       ease future migration from the use of SHA1, the paChecksum field
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 12]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       is made optional syntactically: when the request is extended to
+       negotiate hash algorithms, the new client wishing not to use SHA1
+       will send the request in the extended message syntax without the
+       paChecksum field.  The KDC conforming to this specification MUST
+       return a KRB-ERROR [RFC4120] message with the code
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
+       will allow a new client to retry with SHA1 if allowed by the
+       local policy.
+
+   7.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [RFC4158].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   8.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
+       and the client's Diffie-Hellman public key value is mapped to a
+       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
+       using the Diffie-Hellman key agreement method, implementations
+       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
+       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
+       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
+       group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   9.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string MUST be as long as the
+       longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+   The ExternalPrincipalIdentifier structure is used in this document to
+   identify the subject's public key thereby the subject principal.
+   This structure is filled out as follows:
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 13]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   1.  The subjectName field contains a PKIX type Name encoded according
+       to [RFC3280].  This field identifies the certificate subject by
+       the distinguished subject name.  This field is REQUIRED when
+       there is a distinguished subject name present in the certificate
+       being used.
+
+   2.  The issuerAndSerialNumber field contains a CMS type
+       IssuerAndSerialNumber encoded according to [RFC3852].  This field
+       identifies a certificate of the subject.  This field is REQUIRED
+       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+       structures are defined in Section 3.2.2).
+
+   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
+       public key by a key identifier.  When an X.509 certificate is
+       referenced, this key identifier matches the X.509
+       subjectKeyIdentifier extension value.  When other certificate
+       formats are referenced, the documents that specify the
+       certificate format and their use with the CMS must include
+       details on matching the key identifier to the appropriate
+       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
+       CERTIFIERS (as defined in Section 3.2.2).
+
+   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+   of CAs, trusted by the client, that can be used to certify the KDC.
+   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+   SignerIdentifier encoded according to [RFC3852].  This field
+   identifies, if present, a particular KDC public key that the client
+   already has.
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 14]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   CERTIFIERS:
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+   (thereby its public key) trusted by the KDC.
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+   sent by the client) with an invalid signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Based on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 15]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client's principal name as specified in the
+   AS-REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the Kerberos client name in the AS-REQ does not match a name bound
+   by the KDC (the binding can be in the certificate, for example as
+   described above), or if there is no binding found by the KDC, the KDC
+   MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 16]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the client's X.509 certificate is restricted
+   with the id-pkinit-KPClientAuth EKU.
+
+   If this EKU KeyPurposeId is required but it is not present or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
+   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
+   are a large number of X.509 client certificates deployed for use with
+   PKINIT which have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OID's.
+
+   If the digest algorithm used in generating the CA signature for the
+   public key in any certificate of the request is not acceptable by the
+   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA although none is defined at this point.
+
+   If the client's public key is not accepted with reasons other than
+   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
+   accompanying e-data currently defined for this error message.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 17]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   The AlgorithmIdentifier structure is defined in [RFC3280] and is
+   filled in according to [RFC3279].  More specifically Section 2.3.3 of
+   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
+   in the case where MODP Diffie-Hellman key exchange is used.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the digest algorithm used by the id-pkinit-authData is not
+   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+   The accompanying e-data MUST be encoded in TYPED-DATA although none
+   is defined at this point.
+
+3.2.3.  Generation of KDC Reply
+
+   If the paChecksum filed in the request is not present, the KDC
+   conforming to this specification MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
+   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
+   defined by this specification).
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 18]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+   path based on which the client certificate was validated.  Each
+   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+   (thereby its public key).
+
+   Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
+   data does permit empty SEQUENCEs to be encoded.  Such empty sequences
+   may only be used if the KDC itself vouches for the user's
+   certificate.
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container, otherwise it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 19]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 20]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+                   -- field MUST also be omitted.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange, or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   If the client does not wish to use the Diffie-Hellman key delivery
+   method (the clientPublicValue field is not present in the request)
+   and the KDC does not support the public key encryption key delivery
+   method, the KDC MUST return an error message with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED.  There is no
+   accompanying e-data for this error message.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance and its value is id-pkinit-DHKeyData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
+       and optionally the expiration time of the KDC's DH key being
+       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 21]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       field identifies KDC's DH public key.  This DH public key value
+       is encoded as a BIT STRING according to [RFC3279].  The nonce
+       field contains the nonce in the pkAuthenticator field in the
+       request if the DH keys are NOT reused.  The value of this nonce
+       field is 0 if the DH keys are reused.  The dhKeyExpiration field
+       is present if and only if the DH keys are reused.  If the
+       dhKeyExpiration field is present, the KDC's public key in this
+       KDCDHKeyInfo structure MUST NOT be used past the point of this
+       expiration time.  If this field is omitted then the serverDHNonce
+       field MUST also be omitted.
+
+   5.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   6.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys.  If the server reuses DH keys then
+       it MUST include an expiration time in the dhKeyExpiration field.
+       Past the point of the expiration time, the signature over the
+       type DHRepInfo is considered expired/invalid.  When the server
+       reuses DH keys then it MUST include a serverDHNonce at least as
+       long as the length of keys for the symmetric encryption system
+       used to encrypt the AS reply.  Note that including the
+       serverDHNonce changes how the client and server calculate the key
+       to use to encrypt the reply; see below for details.  The KDC
+       SHOULD NOT reuse DH keys unless the clientDHNonce field is
+       present in the request.
+
+   The AS reply key is derived as follows:
+
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 22]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+         shared secret value.  DHSharedSecret is the value ZZ as
+         described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc., are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+
+           k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains the encKeyPack field where
+   the AS reply key is encrypted.
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 23]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+       Notes to CMS implementers: the signed attribute content-type MUST
+       be present in this SignedData instance and its value is id-
+       pkinit-rkeyData according to [RFC3852].
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack (as described below).
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature for the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       for the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET which
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key which
+       is encrypted using the client's public key.
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 24]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+   Furthermore the KDC computes the checksum of the AS-REQ in the client
+   request.  This checksum is performed over the type AS-REQ and the
+   protocol key [RFC3961] of the checksum operation is the replyKey and
+   the key usage number is 6.  If the replyKey's enctype is "newer"
+   [RFC4120] [RFC4121], the checksum operation is the required checksum
+   operation [RFC3961] of that enctype.
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo, and then uses
+   that as the AS reply key.
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 25]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the KDC's X.509 certificate is restricted
+   with the id-pkinit-KPKdc EKU.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and the KDC can not
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 26]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   certificates in the request.
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required, but was not present in the
+   request, per [RFC4120] an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
+   stored in the e-data field of the KRB-ERROR message to specify which
+   pre-authentication mechanisms are acceptable.  The KDC can then
+   indicate the support of PKINIT by including an empty element whose
+   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+
+4.  Security Considerations
+
+   The security of cryptographic algorithms is dependent on generating
+   secret quantities [RFC4086].  The number of truly random bits is
+   extremely important to determining the attack resistance strength of
+   the cryptosystem, for example, the secret Diffie-Hellman exponents
+   must be chosen based on n truly random bits (where n is the system
+   security requirement).  The security of the overall system is
+   significantly weakened by using insufficient random inputs: a
+   sophisticated attacker may find it easier to reproduce the
+   environment that produced the secret quantities and to search the
+   resulting small set of possibilities than to locate the quantities in
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 27]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   the whole of the potential number space.
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280]; and for each CA or trust
+   anchor the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA is trusted to issue KDC certificates can also
+   issue other kinds of certificates, then local policy must be able to
+   distinguish between them: for example, it could require that KDC
+   certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 28]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  When
+   using such weak asymmetric keys to protect/exchange stronger
+   symmetric Keys, the attack resistant strength of the overall system
+   is no better than that of these weak keys [RFC3766].
+
+   PKINIT requires keys for symmetric cryptosystems to be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447], by using DH based key
+   delivery this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing only certificates are normally not escrowed, by using DH
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   When the Diffie-Hellman key exchange method is used, additional pre-
+   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
+   defined in this specification) is not bound to the AS_REQ by the
+   mechanisms discussed in this specification (meaning it may be dropped
+   or added by attackers without being detected by either the client or
+   the KDC).  Designers of additional pre-authentication data should
+   take that into consideration if such additional pre-authentication
+   data can be used in conjunction with the PA_PK_AS_REQ.  The future
+   work of the Kerberos working group is expected to update the hash
+   algorithms specified in this document and provide a generic mechanism
+   to bind additional pre-authentication data with the accompanying
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 29]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   AS_REQ.
+
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+   Grundman and Jeffrey Altman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26, the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
+   Jonathan Trostle who wrote earlier versions of this document.
+
+   The authors are indebted to the Kerberos working group chair Jeffrey
+   Hutzelman who kept track of various issues and was enormously helpful
+   during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+
+6.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+7.  References
+
+7.1.  Normative References
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key 
+              Cryptography", IEEE 1363, 2000.
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 30]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
+              RFC 2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
+              Algorithm in Cryptographic Message Syntax (CMS)",
+              RFC 3560, July 2003.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 31]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
+              Information technology - Abstract Syntax Notation One 
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
+              Information technology - ASN.1 encoding Rules: Specification 
+              of Basic Encoding Rules (BER), Canonical Encoding Rules 
+              (CER) and Distinguished Encoding Rules (DER).
+
+7.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+   
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)".
+              April 1999.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+              Nicholas, "Internet X.509 Public Key Infrastructure:
+              Certification Path Building", RFC 4158, September 2005.
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 32]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) } ;
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso (1) org (3) dod (6) internet (1) security (5)
+           kerberosv5 (2) pkinit (3) }
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 33]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 34]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS algorithm [RFC3370] identifiers
+                   -- that identify key transport algorithms, or
+                   -- content encryption algorithms, or signature
+                   -- algorithms supported by the client in order of
+                   -- (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  This nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 35]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 36]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e. the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 37]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+
+   Set 1
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 38]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 39]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to better interoperate with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
+   serverAuth EKU and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC and the intended
+   purpose of these KDC certificates be restricted by the presence of
+   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+   contains a UTF8 encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are domain
+   style realm names and strictly in upper case.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 40]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Brian Tung
+   USC Information Sciences Institute
+   4676 Admiralty Way Suite 1001
+   Marina del Rey, CA  90292
+   US
+
+   Email: brian@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 41]
+
+Internet-Draft                   PKINIT                    February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Tung               Expires August 11, 2006               [Page 42]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-9.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-9.txt
new file mode 100644
index 00000000000..748f08954b8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-9.txt
@@ -0,0 +1,908 @@
+INTERNET-DRAFT                                                Brian Tung
+draft-ietf-cat-kerberos-pk-init-09.txt                   Clifford Neuman
+Updates: RFC 1510                                                    ISI
+expires December 1, 1999                                     Matthew Hur
+                                                   CyberSafe Corporation
+                                                           Ari Medvinsky
+                                                                  Excite
+                                                         Sasha Medvinsky
+                                                      General Instrument
+                                                               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-09.txt, and expires December 1,
+    1999.  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 Diffie-Hellman keys in combination with digital
+    signature keys as the primary, required mechanism.  It also allows
+    for the use of RSA keys.  Note 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 a request to the KDC as before, except that if that user
+    is to use public key cryptography in the initial authentication
+    step, his certificate 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.
+
+    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 an X.500 name as a
+    Realm.  In these cases, the realm will be represented using a
+    different style, specified in RFC 1510 with the following example:
+
+        NAMETYPE:rest/of.name=without-restrictions
+
+    For a realm derived from an X.500 name, NAMETYPE will have the value
+    X500-RFC2253.  The full realm name will appear as follows:
+
+        X500-RFC2253:RFC2253Encode(DistinguishedName)
+
+    where DistinguishedName is an X.500 name, and RFC2253Encode is a
+    readable UTF encoding of an X.500 name, as defined by
+    RFC 2253 [14] (part of LDAPv3).
+
+    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, PKINIT may require the encoding of an X.500 name as a
+    PrincipalName.  In these cases, the name-type of the principal name
+    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
+    defined as:
+
+        KRB_NT_X500_PRINCIPAL    6
+
+    The name-string shall be set as follows:
+
+        RFC2253Encode(DistinguishedName)
+
+    as described above.
+
+    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 within this structure,
+    the name-string shall be encoded as a single GeneralString.
+
+    Note that name mapping may be required or optional based on
+    policy.
+
+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.
+
+    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.
+
+    It is assumed that all public keys are signed by some certification
+    authority (CA).  The initial authentication request is sent as per
+    RFC 1510, except that a preauthentication field containing data
+    signed by the user's 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,
+                                    -- CAs that the client trusts
+        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
+                                    -- as defined in CMS [11]
+                                    -- specifies a particular KDC
+                                    -- certificate if the client
+                                    -- already has it;
+                                    -- must be accompanied by
+                                    -- a single trustedCertifier
+        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 OPTIONAL
+                                  -- 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 encapContentInfo field must contain the PKAuthenticator
+      and, optionally, the client's Diffie Hellman public value.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+      - The eContent field is data of the type AuthPack (below).
+    - The signerInfos field contains the signature of AuthPack.
+    - 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 certificates 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
+      enable static-ephemeral Diffie-Hellman mode for the reply.  As
+      another example, the client may place an RSA encryption
+      certificate in this field.
+
+    AuthPack ::= SEQUENCE {
+        pkAuthenticator         [0] PKAuthenticator,
+        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
+                                    -- if client is using Diffie-Hellman
+    }
+
+    PKAuthenticator ::= SEQUENCE {
+        kdcName                 [0] PrincipalName,
+        kdcRealm                [1] Realm,
+        cusec                   [2] INTEGER,
+                                    -- for replay prevention
+        ctime                   [3] KerberosTime,
+                                    -- for replay prevention
+        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,
+    to bind the request and response.  The PKAuthenticator is signed
+    with the private key corresponding to the public key in the
+    certificate found in userCert (or cached by the KDC).
+
+    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.
+
+    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 the signature on one of the certificates in the client's chain
+    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
+
+        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, the KDC returns an
+    error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
+    status is unavailable, the KDC returns an error of type
+    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.
+
+    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.
+
+    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 a Kerberos name in an extension
+            field, and local KDC policy allows, then use that name.
+            Else
+        3.  Use the name as represented in the certificate, 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
+            certification authority that issued the user's certificate.
+
+    The KDC encrypts the reply not with the user's long-term key, but
+    with a random key generated only for this particular response.  This
+    random key is sealed in the preauthentication field:
+
+    PA-PK-AS-REP ::= CHOICE {
+                            -- PA TYPE 15
+        dhSignedData       [0] SignedData,
+                            -- Defined in CMS and used only with
+                            -- Diffie-Helman key exchange
+                            -- 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:
+    If 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:
+    - 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.
+    - 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.
+    - If the reply key is DES, N=64 bits, where some of the bits are
+      replaced with parity bits, according to FIPS PUB 74.
+    - 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.
+    - The encapContentInfo field must contain the KdcDHKeyInfo as
+      defined below.
+      - The eContentType field shall contain the OID value for
+        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+        pkcs(1) pkcs7(7) data(1)
+    - 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).
+    - The signerInfos field is a SET that must contain at least one
+      member, since it contains the actual signature.
+
+    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 an temporary key encrypted with the PKINIT
+    client's public key.  It also contains a signed and encrypted
+    reply key.
+    - The originatorInfo field is not required, since that information
+      may be presented in the signedData structure that is encrypted
+      within the encryptedContentInfo field.
+    - The optional unprotectedAttrs field is not required for PKINIT.
+    - The recipientInfos field is a SET which must contain exactly one
+      member of the KeyTransRecipientInfo type for encryption
+      with an RSA public key.
+         - The encryptedKey field (in KeyTransRecipientInfo) contains
+           the temporary key which is encrypted with the PKINIT client's
+           public key.
+    - The encryptedContentInfo field contains the signed and encrypted
+      reply key.
+      - 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)
+      - The encryptedContent field is encrypted data of the CMS type
+        signedData as specified below.
+        - The encapContentInfo field must contains the ReplyKeyPack.
+          - The eContentType field shall contain the OID value for
+            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+            pkcs(1) pkcs7(7) data(1)
+          - The eContent field is data of the type ReplyKeyPack (below).
+        - 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).
+        - 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
+    }
+
+    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 essentially a separate realm, the name of each
+    certifier 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 must bind the public key to a name derivable
+    from the name of the realm for that KDC.  X.509 certificates shall
+    contain the principal name of the KDC 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] INSTANCE OF OTHER-NAME,
+            ...
+        }
+
+        OTHER-NAME ::= TYPE-IDENTIFIER
+
+    In this definition, otherName is a name of any form defined as an
+    instance of the OTHER-NAME information object class. For the purpose
+    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
+    be chosen and replaced by the type KerberosName:
+
+        KerberosName ::= SEQUENCE {
+          realm           [0] Realm,
+                              -- as define in RFC 1510
+          principalName   [1] PrincipalName,
+                              -- as define in RFC 1510
+        }
+
+    This specific syntax is identified within subjectAltName by setting
+    the OID id-ce-subjectAltName 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.
+
+    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 as 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 client then extracts the random key used to encrypt the main
+    reply.  This random key (in encPaReply) is encrypted with either the
+    client's public key or with a key derived from the DH values
+    exchanged between the client and the KDC.
+
+3.2.2. 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 order
+    to simplify key management, 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] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
+    Tickets for Application Servers (PKTAPP).
+    draft-ietf-cat-pktapp-00.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.
+
+    [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
+
+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 December 1, 1999.
+
+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
+    Excite
+    555 Broadway
+    Redwood City, CA 94063
+    Phone +1 650 569 2119
+    E-mail: amedvins@excitecorp.com
+
+    Sasha Medvinsky
+    General Instrument
+    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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
new file mode 100644
index 00000000000..6581dd5810a
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
new file mode 100644
index 00000000000..2284c3c6b57
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
@@ -0,0 +1,8277 @@
+
+INTERNET-DRAFT                               Clifford Neuman
+                                                   John Kohl
+                                               Theodore Ts'o
+                                                11 July 1997
+
+
+
+     The Kerberos  Network Authentication Service (V5)
+
+
+STATUS OF THIS MEMO
+
+     This document is  an  Internet-Draft.   Internet-Drafts
+are working documents of the Internet Engineering Task Force
+(IETF), its areas, and its working groups.  Note that  other
+groups  may  also  distribute working documents as Internet-
+Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum
+of  six months and may be updated, replaced, or obsoleted by
+other documents at any time.  It  is  inappropriate  to  use
+Internet-Drafts  as reference material or to cite them other
+than as "work in progress."
+
+     To learn the  current  status  of  any  Internet-Draft,
+please  check  the  "1id-abstracts.txt" listing contained in
+the Internet-Drafts Shadow  Directories  on  ds.internic.net
+(US  East  Coast),  nic.nordu.net  (Europe), ftp.isi.edu (US
+West Coast), or munnari.oz.au (Pacific Rim).
+
+     The distribution of this  memo  is  unlimited.   It  is
+filed  as  draft-ietf-cat-kerberos-revisions-00.txt,  and expires 
+11 January 1998.  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 pro-
+vided in RFC1510.  This document is intended  to  provide  a
+detailed description of the protocol, suitable for implemen-
+tation, together with descriptions of the appropriate use of
+protocol messages and fields within those messages.
+
+     This document is not intended to describe  Kerberos  to
+__________________________
+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.
+
+
+
+Overview                   - 1 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+the  end  user,   system   administrator,   or   application
+developer.   Higher level papers describing Version 5 of the
+Kerberos system [1] and documenting  version  4   [23],  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  proto-
+col.
+
+     The  motivations,  goals,  assumptions,  and  rationale
+behind most design decisions are treated cursorily; they are
+more fully described in a paper available in IEEE communica-
+tions  [1] and earlier in the Kerberos portion of the Athena
+Technical Plan [2].  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 [4]
+and on modifications suggested by  Denning  and  Sacco  [5].
+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  Ker-
+beros.
+
+     Version 5 of the Kerberos protocol (described  in  this
+document)  has  evolved from Version 4 based on new require-
+ments 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  com-
+munity.  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.  Reference implementa-
+tions of both version 4 and version 5 of Kerberos  are  pub-
+licly  available  and  commercial  implementations have been
+
+Overview                   - 2 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+developed and are widely used.
+
+     Details on the differences between Kerberos Versions  4
+and 5 can be found in [6].
+
+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  per-
+forms  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  certifi-
+cation  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 con-
+tains  the  client's identity and a copy of the session key,
+all encrypted in the server's key) to the server.  The  ses-
+sion  key  (now  shared by the client and server) is used to
+authenticate the client,  and  may  optionally  be  used  to
+__________________________
+[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.
+
+
+
+Section 1.                 - 3 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 transac-
+tions, 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  authenti-
+cation.
+
+     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  pro-
+tocol specification describes the AS and the TGS as separate
+servers, they are implemented in practice as different  pro-
+tocol 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  tran-
+saction,  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,  addi-
+tional  information  is  sent to prove that the message ori-
+ginated 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 ses-
+sion key.  Since no one except the requesting principal  and
+
+
+Section 1.                 - 4 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 princi-
+pals can also be guaranteed using the session key (passed in
+the ticket and contained in the credentials).  This approach
+provides detection of both replay attacks and message stream
+modification attacks.  It is accomplished by generating  and
+transmitting  a collision-proof checksum (elsewhere called a
+hash or digest function) of the client's message, keyed with
+the  session  key.   Privacy  and  integrity of the messages
+exchanged between principals can be  secured  by  encrypting
+the data to be passed using the session key contained in the
+ticket or the subsession key found in the authenticator.
+
+     The authentication exchanges  mentioned  above  require
+read-only  access to the Kerberos database.  Sometimes, how-
+ever, 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
+__________________________
+[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.
+
+
+Section 1.1.               - 5 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  tran-
+sited 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 authen-
+tication 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,  intermedi-
+ate  realms may be bypassed to achieve cross-realm authenti-
+cation 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.
+
+1.2.  Authorization
+
+As an authentication service, Kerberos provides a  means  of
+verifying  the identity of principals on a network.  Authen-
+tication 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 con-
+sidered 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 [7] , or on other authorization services.
+
+     Applications should  not  be  modified  to  accept  the
+issuance of a service ticket by the Kerberos server (even by
+
+Section 1.2.               - 6 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+an modified Kerberos server) as granting  authority  to  use
+the  service,  since such applications may become vulnerable
+to the bypass of this authorization check in an  environment
+where  they  interoperate  with  other  KDCs  or where other
+options for application authentication (e.g. the PKTAPP pro-
+posal) 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  Ker-
+     beros.   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  not-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 suc-
+     cessive 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 detec-
+     tion.  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  net-
+     work, 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.
+
+
+
+Section 1.3.               - 7 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+1.4.  Glossary of terms
+
+Below is a list of terms used throughout this document.
+
+
+Authentication      Verifying  the  claimed  identity  of  a
+                    principal.
+
+
+Authentication headerA 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  tran-
+                    sited 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  permis-
+                    sion 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).
+
+
+
+Section 1.4.               - 8 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+Credentials         A ticket plus  the  secret  session  key
+                    necessary   to   successfully  use  that
+                    ticket in an authentication exchange.
+
+
+KDC                 Key Distribution Center, a network  ser-
+                    vice 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  ser-
+                    vice).
+
+
+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  authentica-
+                    tion service.
+
+
+Plaintext           The input to an encryption  function  or
+                    the  output  of  a  decryption function.
+                    Decryption  transforms  ciphertext  into
+                    plaintext.
+
+
+Principal           A  uniquely  named  client   or   server
+                    instance  that participates in a network
+                    communication.
+
+
+Principal identifierThe 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  life-
+                    time.   In  the  case  of a human user's
+                    principal, the  secret  key  is  derived
+
+
+Section 1.4.               - 9 -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                    from a password.
+
+
+Server              A particular Principal which provides  a
+                    resource to network clients.  The server
+                    is sometimes refered to as the  Applica-
+                    tion 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  "ses-
+                    sion".
+
+
+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 dura-
+                    tion of a single association.
+
+
+Ticket              A record that helps a  client  authenti-
+                    cate 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
+
+
+Section 2.1.               - 10 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 tick-
+ets 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  inter-
+preted  by  the  ticket-granting service (discussed below in
+section 3.3).  It can  usually  be  ignored  by  application
+servers.   However,  some  particularly  careful application
+
+
+Section 2.3.               - 11 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  ser-
+viced.   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; post-
+dated  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
+
+
+Section 2.5.               - 12 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  sec-
+tion to forward a ticket granting ticket.
+
+     The PROXIABLE flag in a ticket is normally only  inter-
+preted  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 grant-
+ing 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 ser-
+vice 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 authen-
+tication  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
+__________________________
+[4] Though it is permissible to request or issue  tick-
+ets with no network addresses specified.
+
+
+Section 2.6.               - 13 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 pro-
+cess FORWARDED tickets differently than non-FORWARDED  tick-
+ets.
+
+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 indi-
+cates 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 pro-
+vided with the request.   See  section  3.3.3  for  specific
+details.
+
+__________________________
+[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  sys-
+tem,  the  credentials  obtained in the AS exchange may
+first be used in a TGS exchange to  obtain  credentials
+
+
+Section 3.1.               - 14 -    Expires 11 January 1998
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+
+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  creden-
+tials for a given server but currently holds no credentials.
+In its basic form, the client's secret key is used  for  en-
+cryption 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  ser-
+vices 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 sec-
+tions 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 ses-
+sion 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
+__________________________
+for  a  local  server.   Those credentials must then be
+verified by a local server through  successful  comple-
+tion of the Client/Server exchange.
+
+
+
+Section 3.1.               - 15 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+message is not encrypted.  The  KRB_ERROR  message  contains
+information  which can be used to associate it with the mes-
+sage 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 know-
+ing 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  ini-
+tial  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  pre-
+authentication as described in section <<sec preauth>>.
+
+3.1.1.  Generation of KRB_AS_REQ message
+
+     The client may specify a number of options in the  ini-
+tial   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 sec-
+tion 4).  See section A.1 for pseudocode.
+
+     The client prepares the KRB_AS_REQ message and sends it
+to the KDC.
+
+3.1.2.  Receipt of KRB_AS_REQ message
+
+     If all goes well,  processing  the  KRB_AS_REQ  message
+will  result  in  the creation of a ticket for the client to
+present to  the  server.   The  format  for  the  ticket  is
+described  in section 5.3.1.  The contents of the ticket are
+determined as follows.
+
+3.1.3.  Generation of KRB_AS_REP message
+
+     The authentication  server  looks  up  the  client  and
+server  principals  named in the KRB_AS_REQ in its database,
+extracting their respective keys.  If required,  the  server
+pre-authenticates the request, and if the pre-authentication
+check   fails,   an   error   message    with    the    code
+KDC_ERR_PREAUTH_FAILED  is  returned.   If the server cannot
+accommodate the requested encryption type, an error  message
+with  code  KDC_ERR_ETYPE_NOSUPP  is returned.  Otherwise it
+generates a "random" session key[7].
+__________________________
+
+
+Section 3.1.3.             - 16 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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.
+
+     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 infor-
+mation  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 speci-
+fied,  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 cer-
+tain types or ranges of postdated tickets), and  if  accept-
+able,  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.
+
+
+
+
+
+
+
+
+
+__________________________
+[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  desir-
+able  to  use  a truly random number generator, such as
+one based on measurements of random physical phenomena.
+
+
+
+Section 3.1.3.             - 17 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+The expiration time of the ticket will be set to the minimum
+of the following:
+
++The expiration time (endtime) requested in  the  KRB_AS_REQ
+ message.
+
++The ticket's start time plus the maximum allowable lifetime
+ associated  with  the  client principal (the authentication
+ server's database includes a maximum ticket lifetime  field
+ in each principal's record; see section 4).
+
++The ticket's start time plus the maximum allowable lifetime
+ associated with the server principal.
+
++The ticket's start time plus the maximum  lifetime  set  by
+ the policy of the local realm.
+
+     If the requested expiration time minus the  start  time
+(as determined above) is less than a site-determined minimum
+lifetime, an error message with code KDC_ERR_NEVER_VALID  is
+returned.   If  the requested expiration time for the ticket
+exceeds  what  was  determined  as   above,   and   if   the
+"RENEWABLE-OK"  option  was  requested, then the "RENEWABLE"
+flag is set in the new ticket, and the renew-till  value  is
+set  as  if the "RENEWABLE" option were requested (the field
+and option names are described fully in section 5.4.1).
+
+If the  RENEWABLE  option  has  been  requested  or  if  the
+RENEWABLE-OK  option  has been set and a renewable ticket is
+to be issued, then  the  renew-till  field  is  set  to  the
+minimum of:
+
++Its requested value.
+
++The start time of the ticket plus the minimum  of  the  two
+ maximum renewable lifetimes associated with the principals'
+ database entries.
+
++The start time of the ticket  plus  the  maximum  renewable
+ lifetime set by the policy of the local realm.
+
+     The flags field of the new ticket will have the follow-
+ing  options set if they have been requested and if the pol-
+icy 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
+
+
+Section 3.1.3.             - 18 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 suf-
+ficient  to verify the identity of the user; the user and an
+attacker could cooperate to  generate  a  KRB_AS_REP  format
+message  which  decrypts properly but is not from the proper
+KDC.  If the host wishes to verify the identity of the user,
+it  must require the user to present application credentials
+which can be verified using a securely-stored secret key for
+the  host.   If  those credentials can be verified, then the
+identity of the user can be assured.
+
+3.1.6.  Receipt of KRB_ERROR message
+
+     If the reply message type is KRB_ERROR, then the client
+interprets   it   as   an   error   and   performs  whatever
+application-specific tasks are necessary to recover.
+
+3.2.  The Client/Server Authentication Exchange
+
+                             Summary
+Message direction                         Message type    Section
+Client to Application server              KRB_AP_REQ      5.5.1
+[optional] Application server to client   KRB_AP_REP or   5.5.2
+                                          KRB_ERROR       5.9.1
+
+
+
+Section 3.2.               - 19 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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 authenti-
+cated 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 insuf-
+ficient  to  authenticate a client, since tickets are passed
+across the network in cleartext[8], 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 mes-
+sage  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 con-
+structs  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[9].  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  col-
+lide with other sequence numbers in use.
+
+     The  client  may  indicate  a  requirement  of   mutual
+__________________________
+[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 un-
+reliable 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.
+
+
+
+Section 3.2.2.             - 20 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  addi-
+tional  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 authentica-
+tor, 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 accept-
+able 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 indi-
+cates to the server that the ticket is encrypted in the ses-
+sion  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  encryp-
+tion  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
+__________________________
+[10] This is used for  user-to-user  authentication  as
+described in  [8].
+
+
+Section 3.2.3.             - 21 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 authen-
+ticators 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 authentica-
+tor  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.   Oth-
+erwise,  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
+__________________________
+[11] Note that the rejection here is restricted to  au-
+thenticators  from  the  same  principal  to  the  same
+server.  Other client principals communicating with the
+same  server principal should not be have their authen-
+ticators rejected if the time  and  microsecond  fields
+happen to match some other client's authenticator.
+
+
+Section 3.2.3.             - 22 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 ser-
+vice.
+
+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 ran-
+domly 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
+__________________________
+[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  mes-
+sages are formatted in such a way that it is not possi-
+ble to create the reply by  judicious  message  surgery
+(even  in  encrypted form) without knowledge of the ap-
+propriate 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.
+
+
+Section 3.2.5.             - 23 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+timestamp and microsecond fields match those in the  Authen-
+ticator  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  check-
+sum type) to the application programmer; the Kerberos proto-
+col 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 protec-
+tion 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
+__________________________
+[14] Implementations of the protocol may wish  to  pro-
+vide  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.
+
+
+Section 3.2.6.             - 24 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 authenti-
+cates to the system, such as when a user logs in).  The mes-
+sage format for the TGS exchange is almost identical to that
+for the AS exchange.  The primary difference is that encryp-
+tion 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  authentica-
+tion  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 col-
+lection 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 creden-
+tials, 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  authentica-
+tion  header).  The KRB_ERROR message contains an error code
+
+
+Section 3.3.               - 25 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+and text explaining what went wrong.  The KRB_ERROR  message
+is not encrypted.  The KRB_TGS_REP message contains informa-
+tion which can be used to detect replays, and  to  associate
+it with the message to which it replies.  The KRB_ERROR mes-
+sage also contains information which can be used to  associ-
+ate 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  ser-
+vice,  the client must determine in which realm the applica-
+tion 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 mes-
+sage recursively).  The Kerberos server may return a TGT for
+the  desired  realm in which case one can proceed.  Alterna-
+tively, 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.
+__________________________
+[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 appli-
+cation server to the client.
+
+
+
+Section 3.3.1.             - 26 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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 appli-
+cation 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  authentica-
+tion  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  simi-
+lar 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 ser-
+vice, 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  grant-
+ing  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
+__________________________
+[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  ran-
+dom  number  and  XOR  it with the session key from the
+ticket-granting ticket.
+
+
+Section 3.3.2.             - 27 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  sup-
+ported,  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
+
+
+Section 3.3.3.             - 28 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 speci-
+fied,  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  dif-
+ferent,  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
+__________________________
+[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.
+
+
+Section 3.3.3.             - 29 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 Authen-
+ticator, 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).
+
+
+
+Section 3.3.3.2.           - 30 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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  mali-
+cious 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  arrange-
+ment  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".
+__________________________
+[18] For the purpose of appending, the realm  preceding
+the  first  listed  realm  is considered to be the null
+realm ("").
+
+
+Section 3.3.3.2.           - 31 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 hierar-
+chy) 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 hierar-
+chy  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  pro-
+cessed  in  the  same  manner  as  the KRB_AS_REP processing
+described above.  The primary difference is that the cipher-
+text  part  of the response must be decrypted using the ses-
+sion 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 informa-
+tion.  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
+__________________________
+[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  con-
+sidered to follow them.
+
+
+Section 3.4.1.             - 32 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 prob-
+lem.
+
+     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 pro-
+tocol  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.   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
+__________________________
+[20] This means that a client and server running on the
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 check-
+sum  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 mes-
+sages 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 pro-
+tocol  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  gen-
+erated.   The recipient verifies that the operating system's
+report of the sender's address matches the sender's  address
+__________________________
+same  host and communicating with one another using the
+KRB_SAFE messages should  not  share  a  common  replay
+cache to detect KRB_SAFE replays.
+
+
+
+Section 3.5.2.             - 34 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 mes-
+sage  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
+
+
+Section 3.6.2.             - 35 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  gen-
+erated.
+
+     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  contain-
+ing  the principal identifiers and secret keys of principals
+to be authenticated[21].
+
+4.1.  Database contents
+
+A database entry  should  contain  at  least  the  following
+fields:
+
+Field                Value
+
+name                 Principal's                    identif-
+ier
+key                  Principal's secret key
+p_kvno               Principal's key version
+max_life             Maximum lifetime for Tickets
+__________________________
+[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.
+
+
+Section 4.1.               - 36 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 mas-
+ter 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 (end-
+time  - 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 prin-
+cipal,  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
+
+
+Section 4.2.               - 37 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 tick-
+ets as or for the principal.  (A database may want to  main-
+tain  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  con-
+trolled  by the system-wide database service, Moira [9]), 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  authentica-
+tion,  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  modifica-
+tion  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
+__________________________
+[22] See the discussion of the padata field in  section
+5.4.2 for details on why this can be useful.
+
+
+Section 4.3.               - 38 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+section 5.2).
+
+     Other frequently changing information that can be main-
+tained  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 confi-
+gurable  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 tick-
+   ets 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  encryp-
+tion  and  checksum  techniques,  and  the fields related to
+them, appear in section 6.
+
+5.1.  ASN.1 Distinguished Encoding Representation
+
+     All uses of  ASN.1  in  Kerberos  shall  use  the  Dis-
+tinguished  Encoding  Representation of the data elements as
+described in the X.509 specification, section 8.7  [10].
+
+
+
+
+
+Section 5.1.               - 39 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 char-
+acter (_) 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  com-
+ponents consisting of the following sub-fields:
+
+name-type This field specifies the type of  name  that  fol-
+          lows.   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-stringThis field encodes a sequence of components  that
+          form  a name, each component encoded as a General-
+          String.  Taken together,  a  PrincipalName  and  a
+          Realm  form  a principal identifier.  Most Princi-
+          palNames will have only a  few  components  (typi-
+          cally one or two).
+
+
+
+        KerberosTime ::=   GeneralizedTime
+                           -- Specifying UTC time zone (Z)
+
+
+     The timestamps used in Kerberos are encoded as General-
+izedTimes.   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
+
+
+Section 5.2.               - 40 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+ }
+
+ HostAddresses ::=   SEQUENCE OF SEQUENCE {
+                     addr-type[0]             INTEGER,
+                     address[1]               OCTET STRING
+ }
+
+
+     The host adddress encodings consists of two fields:
+
+addr-type This field  specifies the  type  of  address  that
+          follows.   Pre-defined  values  for this field are
+          specified in section 8.1.
+
+
+address   This field encodes a single address of type  addr-
+          type.
+
+The two forms differ slightly. HostAddress contains  exactly
+one  address;  HostAddresses contains a sequence of possibly
+many addresses.
+
+AuthorizationData ::=   SEQUENCE OF SEQUENCE {
+                        ad-type[0]               INTEGER,
+                        ad-data[1]               OCTET STRING
+}
+
+
+ad-data   This  field  contains  authorization  data  to  be
+          interpreted   according   to   the  value  of  the
+          corresponding ad-type field.
+
+ad-type   This field specifies the format  for  the  ad-data
+          subfield.   All  negative  values are reserved for
+          local use.  Non-negative values are  reserved  for
+          registered use.
+
+                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),
+
+
+Section 5.2.               - 41 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                            pre-authent(10),
+                            hw-authent(11),
+                            transited-policy-checked(12),
+                            ok-as-delegate(13)
+          }
+
+
+           KDCOptions ::=   BIT STRING {
+                            reserved(0),
+                            forwardable(1),
+                            forwarded(2),
+                            proxiable(3),
+                            proxy(4),
+                            allow-postdate(5),
+                            postdated(6),
+                            unused7(7),
+                            renewable(8),
+                            unused9(9),
+                            unused10(10),
+                            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 multiple
+          of 32 bits needed to include the highest order bit
+          that is set (1), but in no case less than 32 bits.
+          Implementations  should  accept  values   of   bit
+          strings of any length and treat the value of flags
+          cooresponding to bits beyond the end  of  the  bit
+          string as if the bit were reset (0).  Comparisonof
+          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].
+
+__________________________
+[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.
+
+
+
+Section 5.2.               - 42 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+         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 indi-
+          cate 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 informa-
+          tion 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).
+
+
+lr-value  This field contains the time of the last  request.
+          The time must be interpreted according to the con-
+          tents of the accompanying lr-type subfield.
+
+     See section 6 for the definitions of  Checksum,  Check-
+sumType,  EncryptedData,  EncryptionKey, EncryptionType, and
+KeyType.
+
+
+5.3.  Tickets and Authenticators
+
+     This section describes the format and encryption param-
+eters  for  tickets  and  authenticators.   When a ticket or
+authenticator is  included  in  a  protocol  message  it  is
+treated as an opaque object.
+
+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
+}
+
+
+Section 5.3.1.             - 43 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+-- 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  identi-
+          cal.
+
+
+sname     This field specifies the name part of the server's
+          identity.
+
+
+enc-part  This field holds the  encrypted  encoding  of  the
+          EncTicketPart sequence.
+
+
+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:
+
+
+Section 5.3.1.             - 44 -    Expires 11 January 1998
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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.
+
+     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.
+
+
+
+
+
+
+
+
+Section 5.3.1.             - 45 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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.
+
+
+
+
+Section 5.3.1.             - 46 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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.
+
+Section 5.3.1.             - 47 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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.
+
+
+
+
+Section 5.3.1.             - 48 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     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.
+
+
+authtime  This field indicates the time of initial authenti-
+          cation 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 implementa-
+          tion of a `hot list' service at the KDC.   An  end
+          service that is particularly paranoid could refuse
+          to accept tickets for which the initial  authenti-
+          cation 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
+
+
+Section 5.3.1.             - 49 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          (KRB_AS_REP), this is the current time on the Ker-
+          beros server[24].
+
+
+starttime This field in the ticket specifies the time  after
+          which the ticket is valid.  Together with endtime,
+          this field specifies the life of the  ticket.   If
+          it  is absent from the ticket, its value should be
+          treated as that of the authtime field.
+
+
+endtime   This field  contains  the  time  after  which  the
+          ticket  will not be honored (its expiration time).
+          Note that individual services may place their  own
+          limits  on  the  life  of  a ticket and may reject
+          tickets which have not yet expired.  As such, this
+          is  really  an  upper bound on the expiration time
+          for the ticket.
+
+
+renew-tillThis 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 abso-
+          lute 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  sug-
+          gested  and  default policy, however, is that such
+          tickets will only be issued or accepted when addi-
+          tional  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
+__________________________
+[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  actu-
+ally came from the proper KDC in a timely manner.
+
+
+Section 5.3.1.             - 50 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          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 worksta-
+          tion  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 ser-
+          vice.   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 bases 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 addi-
+          tional  entries when a new ticket is obtained dur-
+          ing the TGS exchange, or they may be added  during
+          chained  delegation  using  the authorization data
+          field of the authenticator.
+
+          Because entries may be added to this field by  the
+          holder of credentials, it is not allowable for the
+          presence of an entry  in  the  authorization  data
+          field  of  a  ticket to amplify the priveleges one
+          would obtain from using a ticket.
+
+          The data in this field may be specific to the  end
+          service;  the field will contain the names of ser-
+          vice specific objects, and  the  rights  to  those
+          objects.   The  format for this field is described
+          in section 5.2.  Although  Kerberos  is  not  con-
+          cerned with the format of the contents of the sub-
+          fields, it does carry type information (ad-type).
+
+
+
+Section 5.3.1.             - 51 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          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 providing  authoriza-
+          tion  or  certifying group membership may be built
+          using the authorization-data field.  In this case,
+          the entity granting authorization (not the author-
+          ized entity), obtains a ticket  in  its  own  name
+          (e.g.  the  ticket  is  issued  in  the  name of a
+          privelege server), and this entity  adds  restric-
+          tions  on its own authority and delegates the res-
+          tricted authority through a proxy to  the  client.
+          The  client  would then present this authorization
+          credential to the  application  server  separately
+          from the authentication exchange.
+
+          Similarly, if one specifies the authorization-data
+          field  of  a  proxy  and leaves the host addresses
+          blank, the resulting ticket and session key can be
+          treated  as  a  capability.  See [7] for some sug-
+          gested 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
+}
+
+
+
+Section 5.3.2.             - 52 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+authenticator-vno
+          This field specifies the version  number  for  the
+          format of the authenticator.  This document speci-
+          fies 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  applica-
+          tion  specifies  otherwise,  if this field is left
+          out the session key from the ticket will be used.
+
+seq-numberThis optional field includes the initial  sequence
+          number to be used by the KRB_PRIV or KRB_SAFE mes-
+          sages when sequence numbers  are  used  to  detect
+          replays  (It  may  also  be  used  by  application
+          specific messages).  When included in the  authen-
+          ticator  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.
+
+          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.
+
+
+
+Section 5.3.2.             - 53 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 car-
+          ried 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
+
+
+Section 5.4.1.             - 54 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                    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 speci-
+          fies  the  protocol version number.  This document
+          specifies protocol version 5.
+
+
+msg-type  This field indicates the type of a  protocol  mes-
+          sage.   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  con-
+          tains  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  authenti-
+          cation  (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
+
+
+Section 5.4.1.             - 55 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          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.
+
+          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  [11]  for
+          additional uses of this field.
+
+padata-type
+          The padata-type element of the padata field  indi-
+          cates  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:
+
+
+
+
+Section 5.4.1.             - 56 -    Expires 11 January 1998
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+   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.
+
+
+
+
+
+
+
+Section 5.4.1.             - 57 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+    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
+                                 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.
+
+
+
+Section 5.4.1.             - 58 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+    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.
+
+cname and sname
+          These fields are the same as those  described  for
+          the  ticket  in  section 5.3.1.  sname may only be
+
+
+Section 5.4.1.             - 59 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          absent when the ENC-TKT-IN-SKEY option  is  speci-
+          fied.   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 encod-
+          ing 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.
+
+
+
+till      This field contains the expiration date  requested
+          by  the  client in a ticket request.  It is option
+          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 gen-
+          erated randomly, but if the correct time is known,
+          it may suffice[25].
+__________________________
+[25] Note, however, that if the time  is  used  as  the
+
+Section 5.4.1.             - 60 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+etype     This field specifies the desired encryption  algo-
+          rithm 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 per-
+form 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 subse-
+quent  (TGS)  request.   There  is  no  message   type   for
+__________________________
+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.
+
+
+
+Section 5.4.2.             - 61 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 cipher-
+text is encrypted in the sub-session key from the  Authenti-
+cator,  or  if  absent,  the  session  key  from the ticket-
+granting ticket used in the request.  In that case, no  ver-
+sion 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.
+__________________________
+[27] An application code in the  encrypted  part  of  a
+message  provides  an additional check that the message
+was decrypted properly.
+
+
+Section 5.4.2.             - 62 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 use-
+          ful  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 appear-
+          ance 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
+
+
+Section 5.4.2.             - 63 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          client's secret key is due to expire.  The expira-
+          tion  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 expira-
+          tion 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 sec-
+          tion 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)
+
+
+Section 5.5.1.             - 64 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+}
+
+
+pvno and msg-type
+          These fields are described above in section 5.4.1.
+          msg-type is KRB_AP_REQ.
+
+
+ap-optionsThis field  appears  in  the  application  request
+          (KRB_AP_REQ)  and  affects  the way the request is
+          processed.  It is a bit-field, where the  selected
+          options  are  indicated  by the bit being set (1),
+          and the unselected  options  and  reserved  fields
+          being  reset  (0).   The  encoding  of the bits is
+          specified in section 5.2.   The  meanings  of  the
+          options are:
+
+          Bit(s)   Name              Description
+
+          0        RESERVED
+                                     Reserved for future  expansion  of  this
+                                     field.
+
+          1        USE-SESSION-KEY
+                                     The  USE-SESSION-KEY  option   indicates
+                                     that the ticket the client is presenting
+                                     to a server is encrypted in the  session
+                                     key  from  the  server's ticket-granting
+                                     ticket.  When this option is not  speci-
+                                     fied,  the  ticket  is  encrypted in the
+                                     server's secret key.
+
+          2        MUTUAL-REQUIRED
+                                     The  MUTUAL-REQUIRED  option  tells  the
+                                     server  that  the client requires mutual
+                                     authentication, and that it must respond
+                                     with a KRB_AP_REP message.
+
+          3-31     RESERVED
+                                     Reserved for future use.
+
+
+
+ticket    This field is a ticket authenticating  the  client
+          to the server.
+
+
+authenticator
+          This contains the  authenticator,  which  includes
+          the  client's choice of a subkey.  Its encoding is
+          described in section 5.3.2.
+
+5.5.2.  KRB_AP_REP definition
+
+     The KRB_AP_REP message contains the  Kerberos  protocol
+version  number,  the  message  type, and an encrypted time-
+stamp.  The message is sent in in response to an application
+request  (KRB_AP_REQ) where the mutual authentication option
+
+
+Section 5.5.2.             - 65 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 associa-
+tion 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 ses-
+          sion.  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 authentica-
+          tor, or if also left out, the session key from the
+          ticket will be used.
+
+
+
+__________________________
+[29] An application code in the  encrypted  part  of  a
+message  provides  an additional check that the message
+was decrypted properly.
+
+
+
+Section 5.5.2.             - 66 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 exam-
+ple, 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.  It is to be encoded separately
+          and then have the checksum computed over  it,  for
+          use in the cksum field.
+
+
+
+Section 5.6.1.             - 67 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+cksum     This field contains the checksum of  the  applica-
+          tion data.  Checksum details are described in sec-
+          tion 6.4.   The  checksum  is  computed  over  the
+          encoding of the KRB-SAFE-BODY sequence.
+
+
+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  reci-
+          pient.
+
+
+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.
+
+
+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:
+
+__________________________
+[31] An application code in the  encrypted  part  of  a
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+
+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
+__________________________
+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 mes-
+sage, 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  algo-
+rithm will be used.
+
+
+Section 5.8.               - 69 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+another.  It is presented here to encourage a common mechan-
+ism  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 KRB_CRED.
+
+
+
+
+Section 5.8.1.             - 70 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+tickets
+          These  are  the  tickets  obtained  from  the  KDC
+          specifically  for  use  by the intended recipient.
+          Successive tickets are paired with the correspond-
+          ing  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 mes-
+          sage 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 pro-
+          vide 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  mes-
+          sage.
+
+
+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
+
+
+Section 5.8.1.             - 71 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          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 not  protected
+by  any  encryption, it is quite possible for an intruder to
+synthesize or modify such a message.   In  particular,  this
+means that the client should not use any fields in this mes-
+sage for security-critical purposes, such as setting a  sys-
+tem  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
+}
+
+
+
+
+
+Section 5.9.1.             - 72 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 rea-
+          sonably accurate timestamp.
+
+
+error-codeThis 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  sup-
+          port 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  the  error-
+          code  is KDC_ERR_PREAUTH_REQUIRED, then the e-data
+          field will contain an encoding of  a  sequence  of
+          padata fields, each corresponding to an acceptable
+          pre-authentication method and optionally  contain-
+          ing data for the method:
+
+
+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
+
+
+Section 5.9.1.             - 73 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          message with the checksum absent.  The checksum is
+          then added to the KRB-ERROR structure and the mes-
+          sage is re-encoded.  The Checksum should be calcu-
+          lated using the session key from the ticket grant-
+          ing 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 preau-
+          thentication to prove knowledge of the secret  key
+          by the client[33].  If a checksum can not be  com-
+          puted because the key to be used is not available,
+          no checksum will be included.
+
+               METHOD-DATA ::=   SEQUENCE of PA-DATA
+
+
+          If the error-code is KRB_AP_ERR_METHOD,  then  the
+          e-data  field will contain an encoding of the fol-
+          lowing sequence:
+
+       METHOD-DATA ::=   SEQUENCE {
+                         method-type[0]   INTEGER,
+                         method-data[1]   OCTET STRING OPTIONAL
+       }
+
+          method-type will indicate the  required  alternate
+          method;  method-data  will  contain  any  required
+          additional information.
+
+
+
+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, [12] in conjunction
+with block chaining and checksum methods  [13].   Encryption
+is used to prove the identities of the network entities par-
+ticipating  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  confi-
+dence.   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
+__________________________
+[33] This prevents an attacker  who  generates  an  in-
+correct  AS request from obtaining verifiable plaintext
+for use in an off-line password guessing attack.
+
+
+Section 6.                 - 74 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+exchange) or a shared session key (in the TGS  exchange)  to
+encrypt  responses to ticket requests; the ability to obtain
+the secret key or session key implies the knowledge  of  the
+appropriate  keys  and the identity of the KDC.  The ability
+of a principal to decrypt the KDC  response  and  present  a
+Ticket  and  a properly formed Authenticator (generated with
+the session key from the KDC response) to a service verifies
+the  identity  of the principal; likewise the ability of the
+service to extract the session key from the Ticket and prove
+its knowledge thereof in a response verifies the identity of
+the service.
+
+     The  Kerberos  protocols  generally  assume  that   the
+encryption  used  is  secure from cryptanalysis; however, in
+some cases, the order of fields in the encrypted portions of
+messages  are  arranged  to  minimize  the effects of poorly
+chosen keys.  It is still important to choose good keys.  If
+keys  are derived from user-typed passwords, those passwords
+need to be well chosen to make brute force attacks more dif-
+ficult.   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 con-
+founder 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 map-
+ping 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.
+
+
+
+Section 6.                 - 75 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+     For an discussion of the integrity  characteristics  of
+the candidate encryption and checksum methods considered for
+Kerberos, the the reader is referred to [14].
+
+6.1.  Encryption Specifications
+
+     The following ASN.1 definition describes all  encrypted
+messages.   The  enc-part  field  which appears in the unen-
+crypted part of messages in section 5 is a sequence consist-
+ing  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 specif-
+          ications  for  selected  encryption  types  appear
+          later in this section.
+
+
+kvno      This field contains the version number of the  key
+          under which data is encrypted.  It is only present
+          in messages encrypted  under  long  lasting  keys,
+          such as principals' secret keys.
+
+
+cipher    This field contains the enciphered  text,  encoded
+          as an OCTET STRING.
+
+
+     The cipher field is generated by applying the specified
+encryption  algorithm  to  data  composed of the message and
+algorithm-specific inputs.   Encryption  mechanisms  defined
+for  use  with  Kerberos  must  take  sufficient measures to
+guarantee the integrity of the plaintext, and  we  recommend
+they  also take measures to protect against precomputed dic-
+tionary 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 suffi-
+cient to hold the appropriate item.  The type and length  is
+implicit  and  specified  by  the particular encryption type
+
+
+Section 6.1.               - 76 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+being used (etype).  The format for the data to be encrypted
+is described in the following diagram:
+
+      +-----------+----------+-------------+-----+
+      |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; calcu-
+lates 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  encryp-
+tion  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
+__________________________
+[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 be-
+cause they are specified by the encryption type.
+[36] The  ordering  of  the fields in the CipherText is
+important.  Additionally, messages encoded in this for-
+mat 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  mes-
+sage which could be truncated, while leaving the check-
+sum 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.
+
+
+
+Section 6.1.               - 77 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  encryp-
+tion  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  addi-
+tional 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  key
+          that  follows  in  the  keyvalue  field.   It will
+          almost always correspond to the  encryption  algo-
+          rithm  used  to generate the EncryptedData, though
+          more than one algorithm may use the same  type  of
+          key (the mapping is many to one).  This might hap-
+          pen, for example, if the encryption algorithm uses
+          an  alternate  checksum algorithm for an integrity
+          check, or a different chaining mechanism.
+
+
+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 encryp-
+tion 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).
+
+
+
+Section 6.3.1.             - 78 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  [12] using the cipher
+block chaining mode [13].  A CRC-32 checksum  (described  in
+ISO  3309  [15])  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  con-
+founder is used  [14].  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 Specifi-
+cation 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  [12] using the cipher
+block chaining mode [13].  An  MD4  checksum  (described  in
+[16])  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 concate-
+nation 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  [12] using the cipher
+block chaining mode [13].  An MD5  checksum   (described  in
+[17].)  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 concate-
+nation of confounder, checksum, and message) must be  padded
+to an 8 byte boundary before encryption.
+
+     Plaintext and DES ciphtertext are  encoded  as  8-octet
+blocks  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
+
+
+Section 6.3.4.             - 79 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+bits,  ..., and the eighth octet supplies the 8 least signi-
+ficant bits.
+
+     Encryption  under  DES  using  cipher  block   chaining
+requires  an  additional input in the form of an initializa-
+tion 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 mes-
+sages 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 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.]
+
+     To generate a DES key from a  text  string  (password),
+the  text  string normally must have the realm and each com-
+ponent of the principal's  name  appended[37],  then  padded
+with ASCII nulls to an 8 byte boundary.  This string is then
+fan-folded and eXclusive-ORed with itself to form an 8  byte
+DES key.  The parity is corrected on the key, and it is used
+to generate a DES CBC checksum on the initial  string  (with
+the  realm and name appended).  Next, parity is corrected on
+the CBC checksum.  If the result matches a "weak" or  "semi-
+weak"  key  as  described  in  the  DES specification, it is
+eXclusive-ORed with the constant 00000000000000F0.  Finally,
+the result is returned as the key.  Pseudocode follows:
+
+     string_to_key(string,realm,name) {
+          odd = 1;
+          s = string + realm;
+          for(each component in name) {
+               s = s + component;
+          }
+          tempkey = NULL;
+          pad(s); /* with nulls to 8 byte boundary */
+          for(8byteblock in s) {
+__________________________
+[37] In some cases, it may be necessary to use  a  dif-
+ferent  "mix-in"  string for compatibility reasons; see
+the discussion of padata in section 5.4.2.
+
+
+Section 6.3.4.             - 80 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+               if(odd == 0)  {
+                   odd = 1;
+                   reverse(8byteblock)
+               }
+               else odd = 0;
+               tempkey = tempkey XOR 8byteblock;
+          }
+          fixparity(tempkey);
+          key = DES-CBC-check(s,tempkey);
+          fixparity(key);
+          if(is_weak_key_key(key))
+               key = key XOR 0xF0;
+          return(key);
+     }
+
+6.3.5.  Triple DES EDE in outer CBC mode with an SHA1 check-
+sum (des3-cbc-sha1)
+
+     The des3-cbc-sha1 encryption encodes information  using
+three  Data  Encryption  Standard transformations with three
+DES keys.  The first key  is  used  to  perform  a  DES  ECB
+encryption  on an eight-octet data block using the first DES
+key, followed by a DES ECB decryption of  the  result  using
+the  second  DES key, and a DES ECB encryption of the result
+using the third DES key.  Because DES blocks  are  8  bytes,
+the  data  to be encrypted (the concatenation of confounder,
+checksum, and message) must first be padded  to  an  8  byte
+boundary  before encryption.  To support the outer CBC mode,
+the input is padded an eight-octet boundary.   The  first  8
+octets  of  the  data  to  be  encrypted (the confounder) is
+exclusive-ored with an initialization  vector  of  zero  and
+then  ECB  encrypted  using  triple  DES as described above.
+Subsequent blocks of 8 octets are  exclusive-ored  with  the
+ciphertext  produced by the encryption on the previous block
+before ECB encryption.
+
+     An HMAC-SHA1 checksum  (described in  [18].) is applied
+to  the confounder and message sequence (msg-seq) and placed
+in the cksum field.
+
+     Plaintext  are encoded as 8-octet blocks which are con-
+catenated  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 Triple DES using cipher block chaining
+requires  an  additional input in the form of an initializa-
+tion 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-
+
+
+Section 6.3.5.             - 81 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+weak" keys; those keys shall not be used for encrypting mes-
+sages 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 constant F0F0F0F0F0F0F0F0.
+
+     A Triple DES key is 24 octets  of  data,  with  keytype
+seven  (7).  This consists of 168 bits of key, and 24 parity
+bits (one per octet).  The key is encoded as a series of  24
+octets  written  in MSB-first order, with the first 8 octets
+treated as the first DES key, the second  8  octets  as  the
+second  key,  and the third 8 octets the third DES key.  The
+bits within each 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.]
+
+     To generate a DES key from a  text  string  (password),
+the  text  string normally must have the realm and each com-
+ponent of the principal's name appended[38],
+
+     The input string (with any salt data appended to it) is
+n-folded  into  a  24  octet  (192 bit) string.  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 X is rotated to the right  by  13  bit
+positions.   The  successive n-bit chunks are added together
+using  1's-complement  addition  (addition  with  end-around
+carry)  to  yield  a  n-bit result. (This transformation was
+proposed by Richard Basch)
+
+     Each successive set of 8 octets is taken as a DES  key,
+and  its parity is adjusted in the same manner as previously
+described.  If any of the three sets of  8  octets  match  a
+"weak" or "semi-weak" key as described in the DES specifica-
+tion,  that  chunk  is  eXclusive-ORed  with  the   constant
+00000000000000F0.   The  resulting DES keys are then used in
+sequence to perform a Triple-DES CBC encryption  of  the  n-
+folded  input  string (appended with any salt data), using a
+zero initial vector.  Parity, weak, and semi-weak  keys  are
+once  again  corrected  and the result is returned as the 24
+octet key.
+
+     Pseudocode follows:
+
+     string_to_key(string,realm,name) {
+__________________________
+[38] In some cases, it may be necessary to use  a  dif-
+ferent  "mix-in"  string for compatibility reasons; see
+the discussion of padata in section 5.4.2.
+
+
+Section 6.3.5.             - 82 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+          s = string + realm;
+          for(each component in name) {
+               s = s + component;
+          }
+          tkey[24] = fold(s);
+          fixparity(tkey);
+          if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
+          if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
+          if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
+          key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
+          fixparity(key);
+          if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
+          if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
+          if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
+          return(key);
+     }
+
+6.4.  Checksums
+
+     The following is the ASN.1 definition used for a check-
+sum:
+
+         Checksum ::=   SEQUENCE {
+                        cksumtype[0]   INTEGER,
+                        checksum[1]    OCTET STRING
+         }
+
+
+cksumtype This field indicates the algorithm  used  to  gen-
+          erate 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 subse-
+quently 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 mes-
+sage.  In such cases, the composition of  the  checksum  and
+
+
+Section 6.4.               - 83 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 [15].  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  proba-
+bilistic  chosen-plaintext attack as described in [14] 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  [16].   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
+__________________________
+[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  per-
+formed   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 pur-
+pose  in  the  Message  Integrity  Check in the Privacy
+Enhanced Mail standard.
+
+
+Section 6.4.3.             - 84 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+"semi-weak keys"; those keys shall not be used for  generat-
+ing 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.  [17].  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 constant F0F0F0F0F0F0F0F0.  The initialization vec-
+tor  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 encrypt-
+ing RSA-MD5 checksums for use in Kerberos.
+
+     The format for the checksum is described in the follow-
+ing 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
+
+
+Section 6.4.5.             - 85 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 constant F0F0F0F0F0F0F0F0.  The initializa-
+tion 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 follow-
+ing 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
+
+
+Section 6.4.7.             - 86 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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  vec-
+tor  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 generat-
+ing DES-MAC checksums for use in Kerberos.
+
+7.  Naming Constraints
+
+
+7.1.  Realm Names
+
+     Although realm names are encoded as GeneralStrings  and
+although a realm can technically select any name it chooses,
+interoperability across realm boundaries requires  agreement
+on  how realm names are to be assigned, and what information
+they imply.
+
+     To enforce these conventions, each realm  must  conform
+to  the  conventions  itself,  and  it must require that any
+realms with which inter-realm keys are shared  also  conform
+to the conventions and require the same from its neighbors.
+
+     Kerberos realm names are case sensitive.   Realm  names
+that  differ  only  in  the  case  of the characters are not
+equivalent.  There are presently four styles of realm names:
+domain,  X500,  other, and reserved.  Examples of each style
+follow:
+
+     domain:   ATHENA.MIT.EDU (example)
+       X500:   C=US/O=OSF (example)
+      other:   NAMETYPE:rest/of.name=without-restrictions (example)
+   reserved:   reserved, but will not conflict with above
+
+
+Domain names must look like domain names:  they  consist  of
+components separated by periods (.) and they contain neither
+colons (:) nor slashes (/).  Domain names must be  converted
+to upper case when used as realm names.
+
+     X.500 names contain an equal (=) and cannot  contain  a
+
+
+Section 7.1.               - 87 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 organiza-
+tion  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 adminis-
+trator 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  dif-
+ferent).   This  constraint may be eliminated in the future.
+The following name types are defined:
+
+                    name-type      value   meaning
+
+
+Section 7.2.               - 88 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+   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
+
+
+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 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  UNK-
+NOWN.
+
+     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
+
+
+Section 7.2.1.             - 89 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 interpreta-
+tions.
+
+     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  <sys/socket.h>  with symbolic names AF_xxx (where xxx is
+an abbreviation of the address family name).
+
+
+Internet addresses
+
+     Internet addresses  are  32-bit  (4-octet)  quantities,
+encoded in MSB order.  The type of internet addresses is two
+(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).
+
+
+Section 8.1.               - 90 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 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 net-
+work  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).
+
+8.2.  KDC messages
+
+8.2.1.  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).  Servers may also accept
+TCP requests on port 88  (decimal).   When  the  KRB_KDC_REQ
+message  is sent to the KDC by TCP, a new connection will be
+established  for  each  authentication  exchange   and   the
+KRB_KDC_REP  or  KRB_ERROR  message  will be returned to the
+client on the  TCP  stream  that  was  established  for  the
+request.   The connection will be broken after the reply has
+been received (or upon time-out).  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.
+
+8.2.2.  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 mechan-
+ism 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
+
+
+Section 8.2.2.             - 91 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+(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.
+
+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
+<reserved>        6
+des3-cbc-sha1     7            8                 0                 8
+sign-dsa-generate 8                                   (pkinit)
+encrypt-rsa-priv  9                                   (pkinit)
+encrypt-rsa-pub  10                                   (pkinit)
+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
+rsa-md5                    7                   16
+rsa-md5-des                8                   24
+rsa-md5-des3               9                   24
+hmac-sha1-des3             10                  20  (I had this as 10, is it 12)
+
+
+Section 8.3.               - 92 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+padata type                     padata-type value
+
+PA-TGS-REQ                      1
+PA-ENC-TIMESTAMP                2
+PA-PW-SALT                      3
+<reserved>                      4
+PA-ENC-UNIX-TIME                5
+PA-SANDIA-SECUREID              6
+PA-SESAME                       7
+PA-OSF-DCE                      8
+PA-CYBERSAFE-SECUREID           9
+PA-AFS3-SALT                    10
+PA-ETYPE-INFO                   11
+SAM-CHALLENGE                   12                  (sam/otp)
+SAM-RESPONSE                    13                  (sam/otp)
+PA-PK-AS-REQ                    14                  (pkinit)
+PA-PK-AS-REP                    15                  (pkinit)
+PA-PK-AS-SIGN                   16                  (pkinit)
+PA-PK-KEY-REQ                   17                  (pkinit)
+PA-PK-KEY-REP                   18                  (pkinit)
+
+authorization data type         ad-type value
+reserved values                 0-63
+OSF-DCE                         64
+SESAME                          65
+
+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
+
+
+Section 8.3.               - 93 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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
+
+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-
+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
+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
+
+
+
+Section 8.3.               - 94 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
+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)
+
+
+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  authentica-
+tion, user to user authentication, support for proxies, for-
+warding, 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  configura-
+tion  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 1
+
+     This section defines the first specification  of  these
+options.   Implementations  which are configured in this way
+can be said to support Kerberos Version  5  Specification  1
+(5.1).
+
+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
+Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
+
+
+__________________________
+- 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.
+
+
+
+Section 9.1.               - 95 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+Realm Names
+
+All implementations must understand hierarchical  realms  in
+both the Internet Domain and the X.500 style.  When a ticket
+granting ticket for an unknown realm is requested,  the  KDC
+must  be  able  to  determine  the names of the intermediate
+realms between the KDCs realm and the requested realm.
+
+Transited field encoding
+
+DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must  be
+supported.  Alternative encodings may be supported, but they
+may be used only when that  encoding  is  supported  by  ALL
+intermediate realms.
+
+Pre-authentication methods
+
+The TGS-REQ method must be supported.  The TGS-REQ method is
+not  used  on  the  initial  request.   The PA-ENC-TIMESTAMP
+method must be  supported  by  clients  but  whether  it  is
+enabled  by  default  may  be determined on a realm by realm
+basis.  If not used in the initial  request  and  the  error
+KDC_ERR_PREAUTH_REQUIRED   is  returned  specifying  PA-ENC-
+TIMESTAMP as an acceptable method, the client  should  retry
+the   initial   request   using  the  PA-ENC-TIMESTAMP  pre-
+authentication 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 deriva-
+tive 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.  Indi-
+vidual realms and application servers can set their own pol-
+icy on when such tickets will be accepted.
+
+     All implementations must recognize renewable and  post-
+dated  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  imple-
+mentations  shall  make  the  presence of the postdated flag
+
+
+Section 9.1.               - 96 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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 defin-
+ition   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  authori-
+zation  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.
+
+9.2.  Recommended KDC values
+
+Following is a list of recommended values for a  KDC  imple-
+mentation, based on the list of suggested configuration con-
+stants (see section 4.4).
+
+minimum lifetime    5 minutes
+
+maximum renewable lifetime1 week
+
+maximum ticket lifetime1 day
+
+empty addresses     only when suitable  restrictions  appear
+                    in authorization data
+
+proxiable, etc.     Allowed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Section 9.2.               - 97 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+10.  REFERENCES
+
+
+
+1.   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).
+
+2.   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).
+
+3.   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).
+
+4.   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).
+
+5.   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).
+
+6.   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).
+
+7.   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).
+
+8.   Don Davis and Ralph Swick,  "Workstation  Services  and
+     Kerberos  Authentication  at Project Athena," Technical
+     Memorandum TM-424,  MIT Laboratory for Computer Science
+     (February 1990).
+
+9.   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).
+
+10.  CCITT, Recommendation X.509: The Directory  Authentica-
+     tion Framework, December 1988.
+
+11.  J. Pato, Using  Pre-Authentication  to  Avoid  Password
+     Guessing  Attacks, Open Software Foundation DCE Request
+     for Comments 26 (December 1992).
+
+
+
+Section 10.                - 98 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+12.  National Bureau of Standards, U.S. Department  of  Com-
+     merce,  "Data Encryption Standard," Federal Information
+     Processing Standards Publication  46,   Washington,  DC
+     (1977).
+
+13.  National Bureau of Standards, U.S. Department  of  Com-
+     merce,  "DES  Modes  of Operation," Federal Information
+     Processing Standards Publication 81,   Springfield,  VA
+     (December 1980).
+
+14.  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).
+
+15.  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.
+
+16.  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
+     1320,   MIT  Laboratory  for  Computer  Science  (April
+     1992).
+
+17.  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
+     1321,   MIT  Laboratory  for  Computer  Science  (April
+     1992).
+
+18.  H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
+     Hashing  for  Message  Authentication,"  Working  Draft
+     draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Section 10.                - 99 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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;
+
+        client := lookup(req.cname,req.realm);
+        server := lookup(req.sname,req.realm);
+
+
+Section A.2.              - 100 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+
+        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
+
+
+Section A.2.              - 101 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        if (req.kdc-options.ALLOW-POSTDATE is set) then
+                set new_tkt.flags.MAY-POSTDATE;
+        endif
+        if ((req.kdc-options.RENEW is set) or
+            (req.kdc-options.VALIDATE is set) or
+            (req.kdc-options.PROXY is set) or
+            (req.kdc-options.FORWARDED is set) or
+            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
+                error_out(KDC_ERR_BADOPTION);
+        endif
+
+        new_tkt.session := random_session_key();
+        new_tkt.cname := req.cname;
+        new_tkt.crealm := req.crealm;
+        new_tkt.transited := empty_transited_field();
+
+        new_tkt.authtime := kdc_time;
+
+        if (req.kdc-options.POSTDATED is set) then
+           if (against_postdate_policy(req.from)) then
+                error_out(KDC_ERR_POLICY);
+           endif
+           set new_tkt.flags.POSTDATED;
+           set new_tkt.flags.INVALID;
+           new_tkt.starttime := req.from;
+        else
+           omit new_tkt.starttime; /* treated as authtime when omitted */
+        endif
+        if (req.till = 0) then
+                till := infinity;
+        else
+                till := req.till;
+        endif
+
+        new_tkt.endtime := min(till,
+                              new_tkt.starttime+client.max_life,
+                              new_tkt.starttime+server.max_life,
+                              new_tkt.starttime+max_life_for_realm);
+
+        if ((req.kdc-options.RENEWABLE-OK is set) and
+            (new_tkt.endtime < req.till)) then
+                /* we set the RENEWABLE option for later processing */
+                set req.kdc-options.RENEWABLE;
+                req.rtime := req.till;
+        endif
+
+        if (req.rtime = 0) then
+                rtime := infinity;
+        else
+                rtime := req.rtime;
+        endif
+
+        if (req.kdc-options.RENEWABLE is set) then
+                set new_tkt.flags.RENEWABLE;
+
+
+Section A.2.              - 102 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                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;
+        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);
+
+
+
+Section A.2.              - 103 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+A.3.  KRB_AS_REP verification
+        decode response into resp;
+
+        if (resp.msg-type = KRB_ERROR) then
+                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
+                        set pa_enc_timestamp_required;
+                        goto KRB_AS_REQ;
+                endif
+                process_error(resp);
+                return;
+        endif
+
+        /* On error, discard the response, and zero the session key */
+        /* from the response immediately */
+
+        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
+                                 resp.padata);
+        unencrypted part of resp := decode of decrypt of resp.enc-part
+                                using resp.enc-part.etype and key;
+        zero(key);
+
+        if (common_as_rep_tgs_rep_checks fail) then
+                destroy resp.key;
+                return error;
+        endif
+
+        if near(resp.princ_exp) then
+                print(warning message);
+        endif
+        save_for_later(ticket,session,client,server,times,flags);
+
+A.4.  KRB_AS_REP and KRB_TGS_REP common checks
+        if (decryption_error() or
+            (req.cname != resp.cname) or
+            (req.realm != resp.crealm) or
+            (req.sname != resp.sname) or
+            (req.realm != resp.realm) or
+            (req.nonce != resp.nonce) or
+            (req.addresses != resp.caddr)) then
+                destroy resp.key;
+                return KRB_AP_ERR_MODIFIED;
+        endif
+
+        /* make sure no flags are set that shouldn't be, and that all that */
+        /* should be are set                                               */
+        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
+                destroy resp.key;
+                return KRB_AP_ERR_MODIFIED;
+        endif
+
+        if ((req.from = 0) and
+            (resp.starttime is not within allowable skew)) then
+                destroy resp.key;
+                return KRB_AP_ERR_SKEW;
+
+
+Section A.4.              - 104 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        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;
+
+
+Section A.5.              - 105 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        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);
+
+        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
+
+
+Section A.6.              - 106 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        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(server)) then
+                        server := best_intermediate_tgs(server);
+                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;
+
+
+Section A.6.              - 107 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                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);
+                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
+
+
+Section A.6.              - 108 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        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);
+
+                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,
+
+
+Section A.6.              - 109 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                                          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)
+        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;
+
+
+
+Section A.6.              - 110 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        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
+                destroy resp.key;
+                return error;
+        endif
+
+        check authorization_data as necessary;
+        save_for_later(ticket,session,client,server,times,flags);
+
+
+
+Section A.7.              - 111 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+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};
+
+
+Section A.10.             - 112 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        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 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
+        /* 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 */
+
+
+Section A.11.             - 113 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        body.ctime := packet.ctime;
+        body.cusec := packet.cusec;
+        if (selecting sub-session key) then
+                select sub-session key;
+                body.subkey := sub-session key;
+        endif
+        if (using sequence numbers) then
+                select initial sequence number;
+                body.seq-number := initial sequence;
+        endif
+
+        encode body into OCTET STRING;
+
+        select encryption type;
+        encrypt OCTET STRING into packet.enc-part;
+
+A.12.  KRB_AP_REP verification
+        receive packet;
+        if (packet.pvno != 5) then
+                either process using other protocol spec
+                or error_out(KRB_AP_ERR_BADVERSION);
+        endif
+        if (packet.msg-type != KRB_AP_REP) then
+                error_out(KRB_AP_ERR_MSG_TYPE);
+        endif
+        cleartext := decrypt(packet.enc-part) using ticket's session key;
+        if (decryption_error()) then
+                error_out(KRB_AP_ERR_BAD_INTEGRITY);
+        endif
+        if (cleartext.ctime != authenticator.ctime) then
+                error_out(KRB_AP_ERR_MUT_FAIL);
+        endif
+        if (cleartext.cusec != authenticator.cusec) then
+                error_out(KRB_AP_ERR_MUT_FAIL);
+        endif
+        if (cleartext.subkey is present) then
+                save cleartext.subkey for future use;
+        endif
+        if (cleartext.seq-number is present) then
+                save cleartext.seq-number for future verifications;
+        endif
+        return(AUTHENTICATION_SUCCEEDED);
+
+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;
+
+
+Section A.13.             - 114 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        endif
+        if (using sequence numbers) then
+                body.seq-number := sequence number;
+        endif
+        body.s-address := sender host addresses;
+        if (only one recipient) then
+                body.r-address := recipient host address;
+        endif
+        checksum.cksumtype := checksum type;
+        compute checksum over body;
+        checksum.checksum := checksum value; /* checksum.checksum */
+        packet.cksum := checksum;
+        packet.safe-body := body;
+
+A.14.  KRB_SAFE verification
+        receive packet;
+        if (packet.pvno != 5) then
+                either process using other protocol spec
+                or error_out(KRB_AP_ERR_BADVERSION);
+        endif
+        if (packet.msg-type != KRB_SAFE) then
+                error_out(KRB_AP_ERR_MSG_TYPE);
+        endif
+        if (packet.checksum.cksumtype is not both collision-proof and keyed) then
+                error_out(KRB_AP_ERR_INAPP_CKSUM);
+        endif
+        if (safe_priv_common_checks_ok(packet)) then
+                set computed_checksum := checksum(packet.body);
+                if (computed_checksum != packet.checksum) then
+                        error_out(KRB_AP_ERR_MODIFIED);
+                endif
+                return (packet, PACKET_IS_GENUINE);
+        else
+                return common_checks_error;
+        endif
+
+A.15.  KRB_SAFE and KRB_PRIV common checks
+        if (packet.s-address != O/S_sender(packet)) then
+                /* O/S report of sender not who claims to have sent it */
+                error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if ((packet.r-address is present) and
+            (packet.r-address != local_host_address)) then
+                /* 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
+
+
+Section A.15.             - 115 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+        if (((packet.seq-number is present) and
+             ((not in_sequence(packet.seq-number)))) or
+            (packet.seq-number is not present and sequence expected)) then
+                error_out(KRB_AP_ERR_BADORDER);
+        endif
+        if (packet.timestamp not present and packet.seq-number not present) then
+                error_out(KRB_AP_ERR_MODIFIED);
+        endif
+
+        save_identifier(packet.{timestamp,usec,s-address},
+                        sender_principal(packet));
+
+        return PACKET_IS_OK;
+
+A.16.  KRB_PRIV generation
+        collect user data in buffer;
+
+        /* assemble packet: */
+        packet.pvno := protocol version; /* 5 */
+        packet.msg-type := message type; /* KRB_PRIV */
+
+        packet.enc-part.etype := encryption type;
+
+        body.user-data := buffer;
+        if (using timestamp) then
+                get system_time;
+                body.timestamp, body.usec := system_time;
+        endif
+        if (using sequence numbers) then
+                body.seq-number := sequence number;
+        endif
+        body.s-address := sender host addresses;
+        if (only one recipient) then
+                body.r-address := recipient host address;
+        endif
+
+        encode body into OCTET STRING;
+
+        select encryption type;
+        encrypt OCTET STRING into packet.enc-part.cipher;
+
+
+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
+
+
+Section A.17.             - 116 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                error_out(KRB_AP_ERR_BAD_INTEGRITY);
+        endif
+
+        if (safe_priv_common_checks_ok(cleartext)) then
+                return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
+        else
+                return common_checks_error;
+        endif
+
+A.18.  KRB_CRED generation
+        invoke KRB_TGS; /* obtain tickets to be provided to peer */
+
+        /* assemble packet: */
+        packet.pvno := protocol version; /* 5 */
+        packet.msg-type := message type; /* KRB_CRED */
+
+        for (tickets[n] in tickets to be forwarded) do
+                packet.tickets[n] = tickets[n].ticket;
+        done
+
+        packet.enc-part.etype := encryption type;
+
+        for (ticket[n] in tickets to be forwarded) do
+                body.ticket-info[n].key = tickets[n].session;
+                body.ticket-info[n].prealm = tickets[n].crealm;
+                body.ticket-info[n].pname = tickets[n].cname;
+                body.ticket-info[n].flags = tickets[n].flags;
+                body.ticket-info[n].authtime = tickets[n].authtime;
+                body.ticket-info[n].starttime = tickets[n].starttime;
+                body.ticket-info[n].endtime = tickets[n].endtime;
+                body.ticket-info[n].renew-till = tickets[n].renew-till;
+                body.ticket-info[n].srealm = tickets[n].srealm;
+                body.ticket-info[n].sname = tickets[n].sname;
+                body.ticket-info[n].caddr = tickets[n].caddr;
+        done
+
+        get system_time;
+        body.timestamp, body.usec := system_time;
+
+        if (using nonce) then
+                body.nonce := nonce;
+        endif
+
+        if (using s-address) then
+                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
+
+
+Section A.18.             - 117 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+               using negotiated encryption key;
+
+
+A.19.  KRB_CRED verification
+        receive packet;
+        if (packet.pvno != 5) then
+                either process using other protocol spec
+                or error_out(KRB_AP_ERR_BADVERSION);
+        endif
+        if (packet.msg-type != KRB_CRED) then
+                error_out(KRB_AP_ERR_MSG_TYPE);
+        endif
+
+        cleartext := decrypt(packet.enc-part) using negotiated key;
+        if (decryption_error()) then
+                error_out(KRB_AP_ERR_BAD_INTEGRITY);
+        endif
+        if ((packet.r-address is present or required) and
+           (packet.s-address != O/S_sender(packet)) then
+                /* O/S report of sender not who claims to have sent it */
+                error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if ((packet.r-address is present) and
+            (packet.r-address != local_host_address)) then
+                /* was not sent to proper place */
+                error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if (not in_clock_skew(packet.timestamp,packet.usec)) then
+                error_out(KRB_AP_ERR_SKEW);
+        endif
+        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
+                error_out(KRB_AP_ERR_REPEAT);
+        endif
+        if (packet.nonce is required or present) and
+           (packet.nonce != expected-nonce) then
+                error_out(KRB_AP_ERR_MODIFIED);
+        endif
+
+        for (ticket[n] in tickets that were forwarded) do
+                save_for_later(ticket[n],key[n],principal[n],
+                               server[n],times[n],flags[n]);
+        return
+
+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
+
+
+Section A.20.             - 118 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+                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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                          - 119 -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                          - cxx -    Expires 11 January 1998
+
+
+
+
+
+
+
+
+
+
+                     Table of Contents
+
+
+
+
+Overview ..............................................    2
+
+Background ............................................    2
+
+1. Introduction .......................................    3
+
+1.1. Cross-Realm Operation ............................    5
+
+1.2. Authorization ....................................    6
+
+1.3. Environmental assumptions ........................    7
+
+1.4. Glossary of terms ................................    8
+
+2. Ticket flag uses and requests ......................   10
+
+2.1. Initial and pre-authenticated tickets ............   10
+
+2.2. Invalid tickets ..................................   11
+
+2.3. Renewable tickets ................................   11
+
+2.4. Postdated tickets ................................   12
+
+2.5. Proxiable and proxy tickets ......................   12
+
+2.6. Forwardable tickets ..............................   13
+
+2.7. Other KDC options ................................   14
+
+3. Message Exchanges ..................................   14
+
+3.1. The Authentication Service Exchange ..............   14
+
+3.1.1. Generation of KRB_AS_REQ message ...............   16
+
+3.1.2. Receipt of KRB_AS_REQ message ..................   16
+
+3.1.3. Generation of KRB_AS_REP message ...............   16
+
+3.1.4. Generation of KRB_ERROR message ................   19
+
+3.1.5. Receipt of KRB_AS_REP message ..................   19
+
+3.1.6. Receipt of KRB_ERROR message ...................   19
+
+3.2. The Client/Server Authentication Exchange ........   19
+
+3.2.1. The KRB_AP_REQ message .........................   20
+
+
+                           - i -     Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+3.2.2. Generation of a KRB_AP_REQ message .............   20
+
+3.2.3. Receipt of KRB_AP_REQ message ..................   21
+
+3.2.4. Generation of a KRB_AP_REP message .............   23
+
+3.2.5. Receipt of KRB_AP_REP message ..................   23
+
+3.2.6. Using the encryption key .......................   24
+
+3.3. The Ticket-Granting Service (TGS) Exchange .......   25
+
+3.3.1. Generation of KRB_TGS_REQ message ..............   26
+
+3.3.2. Receipt of KRB_TGS_REQ message .................   27
+
+3.3.3. Generation of KRB_TGS_REP message ..............   28
+
+3.3.3.1. Checking for revoked tickets .................   30
+
+3.3.3.2. Encoding the transited field .................   30
+
+3.3.4. Receipt of KRB_TGS_REP message .................   32
+
+3.4. The KRB_SAFE Exchange ............................   32
+
+3.4.1. Generation of a KRB_SAFE message ...............   32
+
+3.4.2. Receipt of KRB_SAFE message ....................   33
+
+3.5. The KRB_PRIV Exchange ............................   34
+
+3.5.1. Generation of a KRB_PRIV message ...............   34
+
+3.5.2. Receipt of KRB_PRIV message ....................   34
+
+3.6. The KRB_CRED Exchange ............................   35
+
+3.6.1. Generation of a KRB_CRED message ...............   35
+
+3.6.2. Receipt of KRB_CRED message ....................   35
+
+4. The Kerberos Database ..............................   36
+
+4.1. Database contents ................................   36
+
+4.2. Additional fields ................................   37
+
+4.3. Frequently Changing Fields .......................   38
+
+4.4. Site Constants ...................................   39
+
+5. Message Specifications .............................   39
+
+
+
+                           - ii -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+5.1. ASN.1 Distinguished Encoding Representation ......   39
+
+5.2. ASN.1 Base Definitions ...........................   40
+
+5.3. Tickets and Authenticators .......................   43
+
+5.3.1. Tickets ........................................   43
+
+5.3.2. Authenticators .................................   52
+
+5.4. Specifications for the AS and TGS exchanges ......   54
+
+5.4.1. KRB_KDC_REQ definition .........................   54
+
+5.4.2. KRB_KDC_REP definition .........................   61
+
+5.5. Client/Server (CS) message specifications ........   64
+
+5.5.1. KRB_AP_REQ definition ..........................   64
+
+5.5.2. KRB_AP_REP definition ..........................   65
+
+5.5.3. Error message reply ............................   67
+
+5.6. KRB_SAFE message specification ...................   67
+
+5.6.1. KRB_SAFE definition ............................   67
+
+5.7. KRB_PRIV message specification ...................   68
+
+5.7.1. KRB_PRIV definition ............................   68
+
+5.8. KRB_CRED message specification ...................   69
+
+5.8.1. KRB_CRED definition ............................   70
+
+5.9. Error message specification ......................   72
+
+5.9.1. KRB_ERROR definition ...........................   72
+
+6. Encryption and Checksum Specifications .............   74
+
+6.1. Encryption Specifications ........................   76
+
+6.2. Encryption Keys ..................................   78
+
+6.3. Encryption Systems ...............................   78
+
+6.3.1. The NULL Encryption System (null) ..............   78
+
+6.3.2. DES in CBC mode with a CRC-32 checksum (des-
+cbc-crc) ..............................................   79
+
+6.3.3. DES in CBC mode with an MD4 checksum (des-
+
+
+                          - iii -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+cbc-md4) ..............................................   79
+
+6.3.4. DES in CBC mode with an MD5 checksum (des-
+cbc-md5) ..............................................   79
+
+6.3.5. Triple DES EDE in outer CBC mode with an SHA1
+checksum (des3-cbc-sha1) ..............................   81
+
+6.4. Checksums ........................................   83
+
+6.4.1. The CRC-32 Checksum (crc32) ....................   84
+
+6.4.2. The RSA MD4 Checksum (rsa-md4) .................   84
+
+6.4.3. RSA MD4 Cryptographic Checksum Using DES
+(rsa-md4-des) .........................................   84
+
+6.4.4. The RSA MD5 Checksum (rsa-md5) .................   85
+
+6.4.5. RSA MD5 Cryptographic Checksum Using DES
+(rsa-md5-des) .........................................   85
+
+6.4.6. DES cipher-block chained checksum (des-mac)
+
+6.4.7. RSA MD4 Cryptographic Checksum Using DES
+alternative (rsa-md4-des-k) ...........................   86
+
+6.4.8. DES cipher-block chained checksum alternative
+(des-mac-k) ...........................................   87
+
+7. Naming Constraints .................................   87
+
+7.1. Realm Names ......................................   87
+
+7.2. Principal Names ..................................   88
+
+7.2.1. Name of server principals ......................   89
+
+8. Constants and other defined values .................   90
+
+8.1. Host address types ...............................   90
+
+8.2. KDC messages .....................................   91
+
+8.2.1. IP transport ...................................   91
+
+8.2.2. OSI transport ..................................   91
+
+8.2.3. Name of the TGS ................................   92
+
+8.3. Protocol constants and associated values .........   92
+
+9. Interoperability requirements ......................   95
+
+
+
+                           - iv -    Expires 11 January 1998
+
+
+
+
+
+
+
+            Version 5 - Specification Revision 6
+
+
+9.1. Specification 1 ..................................   95
+
+9.2. Recommended KDC values ...........................   97
+
+10. REFERENCES ........................................   98
+
+A. Pseudo-code for protocol processing ................  100
+
+A.1. KRB_AS_REQ generation ............................  100
+
+A.2. KRB_AS_REQ verification and KRB_AS_REP genera-
+tion ..................................................  100
+
+A.3. KRB_AS_REP verification ..........................  104
+
+A.4. KRB_AS_REP and KRB_TGS_REP common checks .........  104
+
+A.5. KRB_TGS_REQ generation ...........................  105
+
+A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen-
+eration ...............................................  106
+
+A.7. KRB_TGS_REP verification .........................  111
+
+A.8. Authenticator generation .........................  112
+
+A.9. KRB_AP_REQ generation ............................  112
+
+A.10. KRB_AP_REQ verification .........................  112
+
+A.11. KRB_AP_REP generation ...........................  113
+
+A.12. KRB_AP_REP verification .........................  114
+
+A.13. KRB_SAFE generation .............................  114
+
+A.14. KRB_SAFE verification ...........................  115
+
+A.15. KRB_SAFE and KRB_PRIV common checks .............  115
+
+A.16. KRB_PRIV generation .............................  116
+
+A.17. KRB_PRIV verification ...........................  116
+
+A.18. KRB_CRED generation .............................  117
+
+A.19. KRB_CRED verification ...........................  118
+
+A.20. KRB_ERROR generation ............................  118
+
+
+
+
+
+
+
+                           - v -     Expires 11 January 1998
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
new file mode 100644
index 00000000000..78db9d78f3c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
@@ -0,0 +1,6214 @@
+
+INTERNET-DRAFT                                          Clifford Neuman
+                                                              John Kohl
+                                                          Theodore Ts'o
+                                                       21 November 1997
+
+The Kerberos Network Authentication Service (V5)
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft. Internet-Drafts are working documents of
+the Internet Engineering Task Force (IETF), its areas, and its working
+groups. Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time. It is
+inappropriate to use Internet-Drafts as reference material or to cite them
+other than as 'work in progress.'
+
+To learn the current status of any Internet-Draft, please check the
+'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
+Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
+ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
+
+The distribution of this memo is unlimited. It is filed as
+draft-ietf-cat-kerberos-r-01.txt, and expires 21 May 1998. 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
+available in IEEE communications [NT94] and earlier in the Kerberos portion
+of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+The integrity of the messages exchanged between principals can also be
+guaranteed using the session key (passed in the ticket and contained in the
+credentials). This approach provides detection of both replay attacks and
+message stream modification attacks. It is accomplished by generating and
+transmitting a collision-proof checksum (elsewhere called a hash or digest
+function) of the client's message, keyed with the session key. Privacy and
+integrity of the messages exchanged between principals can be secured by
+encrypting the data to be passed using the session key contained in the
+ticket or the subsession key found in the authenticator.
+
+The authentication exchanges mentioned above require read-only access to the
+Kerberos database. Sometimes, however, the entries in the database must be
+modified, such as when adding new principals or changing a principal's key.
+This is done using a protocol between a client and a third Kerberos server,
+the Kerberos Administration Server (KADM). There is also a protocol for
+maintaining multiple copies of the Kerberos database. Neither of these
+protocols are described in this document.
+
+1.1. Cross-Realm Operation
+
+The Kerberos protocol is designed to operate across organizational
+boundaries. A client in one organization can be authenticated to a server in
+another. Each organization wishing to run a Kerberos server establishes its
+own 'realm'. The name of the realm in which a client is registered is part
+of the client's name, and can be used by the end-service to decide whether
+to honor a request.
+
+By establishing 'inter-realm' keys, the administrators of two realms can
+allow a client authenticated in the local realm to prove its identity to
+servers in other realms[3]. The exchange of inter-realm keys (a separate key
+may be used for each direction) registers the ticket-granting service of
+each realm as a principal in the other realm. A client is then able to
+obtain a ticket-granting ticket for the remote realm's ticket-granting
+service from its local realm. When that ticket-granting ticket is used, the
+remote ticket-granting service uses the inter-realm key (which usually
+differs from its own normal TGS key) to decrypt the ticket-granting ticket,
+and is thus certain that it was issued by the client's own TGS. Tickets
+issued by the remote ticket-granting service will indicate to the
+end-service that the client was authenticated from another realm.
+
+A realm is said to communicate with another realm if the two realms share an
+inter-realm key, or if the local realm shares an inter-realm key with an
+intermediate realm that communicates with the remote realm. An
+authentication path is the sequence of intermediate realms that are
+transited in communicating from one realm to another.
+
+Realms are typically organized hierarchically. Each realm shares a key with
+its parent and a different key with each child. If an inter-realm key is not
+directly shared by two realms, the hierarchical organization allows an
+authentication path to be easily constructed. If a hierarchical organization
+is not used, it may be necessary to consult a database in order to construct
+an authentication path between realms.
+
+Although realms are typically hierarchical, intermediate realms may be
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+1.2. Authorization
+
+As an authentication service, Kerberos provides a means of verifying the
+identity of principals on a network. Authentication is usually useful
+primarily as a first step in the process of authorization, determining
+whether a client may use a service, which objects the client is allowed to
+access, and the type of access allowed for each. Kerberos does not, by
+itself, provide authorization. Possession of a client ticket for a service
+provides only for authentication of the client to that service, and in the
+absence of a separate authorization procedure, it should not be considered
+by an application as authorizing the use of that service.
+
+Such separate authorization methods may be implemented as application
+specific access control functions and may be based on files such as the
+application server, or on separately issued authorization credentials such
+as those based on proxies [Neu93] , or on other authorization services.
+
+Applications should not be modified to accept the issuance of a service
+ticket by the Kerberos server (even by an modified Kerberos server) as
+granting authority to use the service, since such applications may become
+vulnerable to the bypass of this authorization check in an environment if
+they interoperate with other KDCs or where other options for application
+authentication (e.g. the PKTAPP proposal) are provided.
+
+1.3. Environmental assumptions
+
+Kerberos imposes a few assumptions on the environment in which it can
+properly function:
+
+   * 'Denial of service' attacks are not solved with Kerberos. There are
+     places in these protocols where an intruder can prevent an application
+     from participating in the proper authentication steps. Detection and
+     solution of such attacks (some of which can appear to be nnot-uncommon
+     'normal' failure modes for the system) is usually best left to the
+     human administrators and users.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+   * 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
+     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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     (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.
+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
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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).
+
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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
+
+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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+possible. If an error occurs, the server is expected to reply to the client
+with a KRB_ERROR message. This message may be encapsulated in the
+application protocol if its 'raw' form is not acceptable to the protocol.
+The format of error messages is described in section 5.9.1.
+
+The algorithm for verifying authentication information is as follows. If the
+message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
+error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
+one the server can use (e.g., it indicates an old key, and the server no
+longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
+returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
+indicates to the server that the ticket is encrypted in the session key from
+the server's ticket-granting ticket rather than its secret key[10]. Since it
+is possible for the server to be registered in multiple realms, with
+different keys in each, the srealm field in the unencrypted portion of the
+ticket in the KRB_AP_REQ is used to specify which secret key the server
+should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
+returned if the server doesn't have the proper key to decipher the ticket.
+
+The ticket is decrypted using the version of the server's key specified by
+the ticket. If the decryption routines detect a modification of the ticket
+(each encryption system must provide safeguards to detect modified
+ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
+(chances are good that different keys were used to encrypt and decrypt).
+
+The authenticator is decrypted using the session key extracted from the
+decrypted ticket. If decryption shows it to have been modified, the
+KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
+from the ticket are compared against the same fields in the authenticator.
+If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
+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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+The server computes the age of the ticket: local (server) time minus the
+start time inside the Ticket. If the start time is later than the current
+time by more than the allowable clock skew or if the INVALID flag is set in
+the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
+current time is later than end time by more than the allowable clock skew,
+the KRB_AP_ERR_TKT_EXPIRED error is returned.
+
+If all these checks succeed without an error, the server is assured that the
+client possesses the credentials of the principal named in the ticket and
+thus, the client has been authenticated to the server. See section A.10 for
+pseudocode.
+
+Passing these checks provides only authentication of the named principal; it
+does not imply authorization to use the named service. Applications must
+make a separate authorization decisions based upon the authenticated name of
+the user, the requested operation, local acces control information such as
+that contained in a .k5login or .k5users file, and possibly a separate
+distributed authorization service.
+
+3.2.4. Generation of a KRB_AP_REP message
+
+Typically, a client's request will include both the authentication
+information and its initial request in the same message, and the server need
+not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
+(not only authenticating the client to the server, but also the server to
+the client) is being performed, the KRB_AP_REQ message will have
+MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
+required in response. As with the error message, this message may be
+encapsulated in the application protocol if its "raw" form is not acceptable
+to the application's protocol. The timestamp and microsecond field used in
+the reply must be the client's timestamp and microsecond field (as provided
+in the authenticator)[12]. If a sequence number is to be included, it should
+be randomly chosen as described above for the authenticator. A subkey may be
+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,
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+ticket expires, the client must use a separate exchange to obtain valid
+tickets.
+
+The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
+client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
+KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
+client plus a request for credentials. The authentication information
+consists of the authentication header (KRB_AP_REQ) which includes the
+client's previously obtained ticket-granting, renewable, or invalid ticket.
+In the ticket-granting ticket and proxy cases, the request may include one
+or more of: a list of network addresses, a collection of typed authorization
+data to be sealed in the ticket for authorization use by the application
+server, or additional tickets (the use of which are described later). The
+TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
+session key from the ticket-granting ticket or renewable ticket, or if
+present, in the sub-session key from the Authenticator (part of the
+authentication header). The KRB_ERROR message contains an error code and
+text explaining what went wrong. The KRB_ERROR message is not encrypted. The
+KRB_TGS_REP message contains information which can be used to detect
+replays, and to associate it with the message to which it replies. The
+KRB_ERROR message also contains information which can be used to associate
+it with the message to which it replies, but the lack of encryption in the
+KRB_ERROR message precludes the ability to detect replays or fabrications of
+such messages.
+
+3.3.1. Generation of KRB_TGS_REQ message
+
+Before sending a request to the ticket-granting service, the client must
+determine in which realm the application server is registered[15]. If the
+client does not already possess a ticket-granting ticket for the appropriate
+realm, then one must be obtained. This is first attempted by requesting a
+ticket-granting ticket for the destination realm from a Kerberos server for
+which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
+message recursively). The Kerberos server may return a TGT for the desired
+realm in which case one can proceed. Alternatively, the Kerberos server may
+return a TGT for a realm which is 'closer' to the desired realm (further
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+"closest" to the requested realm with which it does share a key, and use
+that realm instead. This is the only case where the response from the KDC
+will be for a different server than that requested by the client.
+
+By default, the address field, the client's name and realm, the list of
+transited realms, the time of initial authentication, the expiration time,
+and the authorization data of the newly-issued ticket will be copied from
+the ticket-granting ticket (TGT) or renewable ticket. If the transited field
+needs to be updated, but the transited type is not supported, the
+KDC_ERR_TRTYPE_NOSUPP error is returned.
+
+If the request specifies an endtime, then the endtime of the new ticket is
+set to the minimum of (a) that request, (b) the endtime from the TGT, and
+(c) the starttime of the TGT plus the minimum of the maximum life for the
+application server and the maximum life for the local realm (the maximum
+life for the requesting principal was already applied when the TGT was
+issued). If the new ticket is to be a renewal, then the endtime above is
+replaced by the minimum of (a) the value of the renew_till field of the
+ticket and (b) the starttime for the new ticket plus the life
+(endtime-starttime) of the old ticket.
+
+If the FORWARDED option has been requested, then the resulting ticket will
+contain the addresses specified by the client. This option will only be
+honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
+similar; the resulting ticket will contain the addresses specified by the
+client. It will be honored only if the PROXIABLE flag in the TGT is set. The
+PROXY option will not be honored on requests for additional ticket-granting
+tickets.
+
+If the requested start time is absent, indicates a time in the past, or is
+within the window of acceptable clock skew for the KDC and the POSTDATE
+option has not been specified, then the start time of the ticket is set to
+the authentication server's current time. If it indicates a time in the
+future beyond the acceptable clock skew, but the POSTDATED option has not
+been specified or the MAY-POSTDATE flag is not set in the TGT, then the
+error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
+ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
+postdated and the requested starttime is checked against the policy of the
+local realm. If acceptable, the ticket's start time is set as requested, and
+the INVALID flag is set. The postdated ticket must be validated before use
+by presenting it to the KDC after the starttime has been reached. However,
+in no case may the starttime, endtime, or renew-till time of a newly-issued
+postdated ticket extend beyond the renew-till time of the ticket-granting
+ticket.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+realm. Instead, its responsibility is to add the name of the previous realm.
+This prevents a malicious Kerberos server from intentionally leaving out its
+own name (it could, however, omit other realms' names).
+
+The names of neither the local realm nor the principal's realm are to be
+included in the transited field. They appear elsewhere in the ticket and
+both are known to have taken part in authenticating the principal. Since the
+endpoints are not included, both local and single-hop inter-realm
+authentication result in a transited field that is empty.
+
+Because the name of each realm transited is added to this field, it might
+potentially be very long. To decrease the length of this field, its contents
+are encoded. The initially supported encoding is optimized for the normal
+case of inter-realm communication: a hierarchical arrangement of realms
+using either domain or X.500 style realm names. This encoding (called
+DOMAIN-X500-COMPRESS) is now described.
+
+Realm names in the transited field are separated by a ",". The ",", "\",
+trailing "."s, and leading spaces (" ") are special characters, and if they
+are part of a realm name, they must be quoted in the transited field by
+preced- ing them with a "\".
+
+A realm name ending with a "." is interpreted as being prepended to the
+previous realm. For example, we can encode traversal of EDU, MIT.EDU,
+ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
+
+     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
+
+Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
+would not be included in this field, and we would have:
+
+     "EDU,MIT.,WASHINGTON.EDU"
+
+A realm name beginning with a "/" is interpreted as being appended to the
+previous realm[18]. If it is to stand by itself, then it should be preceded
+by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
+/COM/HP, /COM, and /COM/DEC as:
+
+     "/COM,/HP,/APOLLO, /COM/DEC".
+
+Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
+they would not be included in this field, and we would have:
+
+     "/COM,/HP"
+
+A null subfield preceding or following a "," indicates that all realms
+between the previous realm and the next realm have been traversed[19]. Thus,
+"," means that all realms along the path between the client and the server
+have been traversed. ",EDU, /COM," means that that all realms from the
+client's realm up to EDU (in a domain style hierarchy) have been traversed,
+and that everything from /COM down to the server's realm in an X.500 style
+has also been traversed. This could occur if the EDU realm in one hierarchy
+shares an inter-realm key directly with the /COM realm in another hierarchy.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+3.3.4. Receipt of KRB_TGS_REP message
+
+When the KRB_TGS_REP is received by the client, it is processed in the same
+manner as the KRB_AS_REP processing described above. The primary difference
+is that the ciphertext part of the response must be decrypted using the
+session key from the ticket-granting ticket rather than the client's secret
+key. See section A.7 for pseudocode.
+
+3.4. The KRB_SAFE Exchange
+
+The KRB_SAFE message may be used by clients requiring the ability to detect
+modifications of messages they exchange. It achieves this by including a
+keyed collision-proof checksum of the user data and some control
+information. The checksum is keyed with an encryption key (usually the last
+key negotiated via subkeys, or the session key if no negotiation has
+occured).
+
+3.4.1. Generation of a KRB_SAFE message
+
+When an application wishes to send a KRB_SAFE message, it collects its data
+and the appropriate control information and computes a checksum over them.
+The checksum algorithm should be a keyed one-way hash function (such as the
+RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
+generated using the sub-session key if present, or the session key.
+Different algorithms may be selected by changing the checksum type in the
+message. Unkeyed or non-collision-proof checksums are not suitable for this
+use.
+
+The control information for the KRB_SAFE message includes both a timestamp
+and a sequence number. The designer of an application using the KRB_SAFE
+message must choose at least one of the two mechanisms. This choice should
+be based on the needs of the application protocol.
+
+Sequence numbers are useful when all messages sent will be received by one's
+peer. Connection state is presently required to maintain the session key, so
+maintaining the next sequence number should not present an additional
+problem.
+
+If the application protocol is expected to tolerate lost messages without
+them being resent, the use of the timestamp is the appropriate replay
+detection mechanism. Using timestamps is also the appropriate mechanism for
+multi-cast protocols where all of one's peers share a common sub-session
+key, but some messages will be sent to a subset of one's peers.
+
+After computing the checksum, the client then transmits the information and
+checksum to the recipient in the message format specified in section 5.6.1.
+
+3.4.2. Receipt of KRB_SAFE message
+
+When an application receives a KRB_SAFE message, it verifies it as follows.
+If any error occurs, an error code is reported for use by the application.
+
+The message is first checked by verifying that the protocol version and type
+fields match the current version and KRB_SAFE, respectively. A mismatch
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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. 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.
+
+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. The recipient verifies that the
+operating system's report of the sender's address matches the sender's
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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
+generated.
+
+If present or required, the recipient verifies that the operating system's
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 contain- ing the
+principal identifiers and secret keys of principals to be authenticated[21].
+
+4.1. Database contents
+
+A database entry should contain at least the following fields:
+
+Field                Value
+
+name                 Principal's identifier
+key                  Principal's secret key
+p_kvno               Principal's key version
+max_life             Maximum lifetime for Tickets
+max_renewable_life   Maximum total lifetime for renewable Tickets
+
+The name field is an encoding of the principal's identifier. The key field
+contains an encryption key. This key is the principal's secret key. (The key
+can be encrypted before storage under a Kerberos "master key" to protect it
+in case the database is compromised but the master key is not. In that case,
+an extra field must be added to indicate the master key version used, see
+below.) The p_kvno field is the key version number of the principal's secret
+key. The max_life field contains the maximum allowable lifetime (endtime -
+starttime) for any Ticket issued for this principal. The max_renewable_life
+field contains the maximum allowable total lifetime for any renewable Ticket
+issued for this principal. (See section 3.1 for a description of how these
+lifetimes are used in determining the lifetime of a given Ticket.)
+
+A server may provide KDC service to several realms, as long as the database
+representation provides a mechanism to distinguish between principal records
+with identifiers which differ only in the realm name.
+
+When an application server's key changes, if the change is routine (i.e. not
+the result of disclosure of the old key), the old key should be retained by
+the server until all tickets that had been issued using that key have
+expired. Because of this, it is possible for several keys to be active for a
+single principal. Ciphertext encrypted in a principal's key is always tagged
+with the version of the key that was used for encryption, to help the
+recipient find the proper key for decryption.
+
+When more than one key is active for a particular principal, the principal
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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.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
+}
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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)
+}
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+KDCOptions ::=   BIT STRING {
+                  reserved(0),
+                  forwardable(1),
+                  forwarded(2),
+                  proxiable(3),
+                  proxy(4),
+                  allow-postdate(5),
+                  postdated(6),
+                  unused7(7),
+                  renewable(8),
+                  unused9(9),
+                  unused10(10),
+                  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 multiple of 32 bits needed to
+include the highest order bit that is set (1), but in no case less than 32
+bits. Implementations should accept values of bit strings of any length and
+treat the value of flags cooresponding to bits beyond the end of the bit
+string as if the bit were reset (0). Comparisonof 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).
+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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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.
+
+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,
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     the two will always be identical.
+sname
+     This field specifies the name part of the server's identity.
+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.
+
+     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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                                   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.
+
+          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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+          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.
+                                   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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                                   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.
+authtime
+     This field indicates the time of initial authentication for the named
+     principal. It is the time of issue for the original ticket on which
+     this ticket is based. It is included in the ticket to provide
+     additional information to the end service, and to provide the necessary
+     information for implementation of a `hot list' service at the KDC. An
+     end service that is particularly paranoid could refuse to accept
+     tickets for which the initial authentication occurred "too far" in the
+     past. This field is also returned as part of the response from the KDC.
+     When returned as part of the response to initial authentication
+     (KRB_AS_REP), this is the current time on the Ker- beros server[24].
+starttime
+     This field in the ticket specifies the time after which the ticket is
+     valid. Together with endtime, this field specifies the life of the
+     ticket. If it is absent from the ticket, its value should be treated as
+     that of the authtime field.
+endtime
+     This field contains the time after which the ticket will not be honored
+     (its expiration time). Note that individual services may place their
+     own limits on the life of a ticket and may reject tickets which have
+     not yet expired. As such, this is really an upper bound on the
+     expiration time for the ticket.
+renew-till
+     This field is only present in tickets that have the RENEWABLE flag set
+     in the flags field. It indicates the maximum endtime that may be
+     included in a renewal. It can be thought of as the absolute expiration
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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 worksta- tion could
+     use the credentials from there. Including the network addresses only
+     makes it more difficult, not impossible, for an attacker to walk off
+     with stolen credentials and then use them from a "safe" location.
+authorization-data
+     The authorization-data field is used to pass authorization data from
+     the principal on whose behalf a ticket was issued to the application
+     service. If no authorization data is included, this field will be left
+     out. Experience has shown that the name of this field is confusing, and
+     that a better name for this field would be restrictions. Unfortunately,
+     it is not possible to change the name of this field at this time.
+
+     This field contains restrictions on any authority obtained on the basis
+     of authentication using the ticket. It is possible for any principal in
+     posession of credentials to add entries to the authorization data field
+     since these entries further restrict what can be done with the ticket.
+     Such additions can be made by specifying the additional entries when a
+     new ticket is obtained during the TGS exchange, or they may be added
+     during chained delegation using the authorization data field of the
+     authenticator.
+
+     Because entries may be added to this field by the holder of
+     credentials, it is not allowable for the presence of an entry in the
+     authorization data field of a ticket to amplify the priveleges one
+     would obtain from using a ticket.
+
+     The data in this field may be specific to the end service; the field
+     will contain the names of service specific objects, and the rights to
+     those objects. The format for this field is described in section 5.2.
+     Although Kerberos is not concerned with the format of the contents of
+     the sub-fields, it does carry type information (ad-type).
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+     By using the authorization_data field, a principal is able to issue a
+     proxy that is valid for a specific purpose. For example, a client
+     wishing to print a file can obtain a file server proxy to be passed to
+     the print server. By specifying the name of the file in the
+     authorization_data field, the file server knows that the print server
+     can only use the client's rights when accessing the particular file to
+     be printed.
+
+     A separate service providing authorization or certifying group
+     membership may be built using the authorization-data field. In this
+     case, the entity granting authorization (not the authorized entity),
+     obtains a ticket in its own name (e.g. the ticket is issued in the name
+     of a privelege server), and this entity adds restrictions on its own
+     authority and delegates the restricted authority through a proxy to the
+     client. The client would then present this authorization credential to
+     the application server separately from the authentication exchange.
+
+     Similarly, if one specifies the authorization-data field of a proxy and
+     leaves the host addresses blank, the resulting ticket and session key
+     can be treated as a capability. See [Neu93] for some suggested uses of
+     this field.
+
+     The authorization-data field is optional and does not have to be
+     included in a ticket.
+
+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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+     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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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:
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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
+     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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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.
+
+         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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                                      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
+                                      session key, and  not  to  identify  the
+                                      user.   The ANONYMOUS flag on the ticket
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                                      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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                                      for  a  renewal.  The ticket provided is
+                                      encrypted in  the  secret  key  for  the
+                                      server  on  which  it  is  valid.   This
+                                      option  will  only  be  honored  if  the
+                                      ticket  to  be renewed has its RENEWABLE
+                                      flag set and if the time in  its  renew-
+                                      till  field  has not passed.  The ticket
+                                      to be renewed is passed  in  the  padata
+                                      field  as  part  of  the  authentication
+                                      header.
+
+         31       VALIDATE
+                                      This option is used only by the  ticket-
+                                      granting  service.   The VALIDATE option
+                                      indicates that the request is  to  vali-
+                                      date  a  postdated ticket.  It will only
+                                      be honored if the  ticket  presented  is
+                                      postdated,  presently  has  its  INVALID
+                                      flag set, and would be otherwise  usable
+                                      at  this time.  A ticket cannot be vali-
+                                      dated before its starttime.  The  ticket
+                                      presented for validation is encrypted in
+                                      the key of the server for  which  it  is
+                                      valid  and is passed in the padata field
+                                      as part of the authentication header.
+
+cname and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
+     specified. If absent, the name of the server is taken from the name of
+     the client in the ticket passed as additional-tickets.
+enc-authorization-data
+     The enc-authorization-data, if present (and it can only be present in
+     the TGS_REQ form), is an encoding of the desired authorization-data
+     encrypted under the sub-session key if present in the Authenticator, or
+     alternatively from the session key in the ticket-granting ticket, both
+     from the padata field in the KRB_AP_REQ.
+realm
+     This field specifies the realm part of the server's principal
+     identifier. In the AS exchange, this is also the realm part of the
+     client's principal identifier.
+from
+     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
+     requests when the requested ticket is to be postdated. It specifies the
+     desired start time for the requested ticket. If this field is omitted
+     then the KDC should use the current time instead.
+till
+     This field contains the expiration date requested by the client in a
+     ticket request. It is optional and if omitted the requested ticket is
+     to have the maximum endtime permitted according to KDC policy for the
+     parties to the authentication exchange as limited by expiration date of
+     the ticket granting ticket or other preauthentication credentials.
+rtime
+     This field is the requested renew-till time sent from a client to the
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     KDC in a ticket request. It is optional.
+nonce
+     This field is part of the KDC request and response. It it intended to
+     hold a random number generated by the client. If the same number is
+     included in the encrypted response from the KDC, it provides evidence
+     that the response is fresh and has not been replayed by an attacker.
+     Nonces must never be re-used. Ideally, it should be generated randomly,
+     but if the correct time is known, it may suffice[25].
+etype
+     This field specifies the desired encryption algorithm to be used in the
+     response.
+addresses
+     This field is included in the initial request for tickets, and
+     optionally included in requests for additional tickets from the
+     ticket-granting server. It specifies the addresses from which the
+     requested ticket is to be valid. Normally it includes the addresses for
+     the client's host. If a proxy is requested, this field will contain
+     other addresses. The contents of this field are usually copied by the
+     KDC into the caddr field of the resulting ticket.
+additional-tickets
+     Additional tickets may be optionally included in a request to the
+     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
+     specified, then the session key from the additional ticket will be used
+     in place of the server's key to encrypt the new ticket. If more than
+     one option which requires additional tickets has been specified, then
+     the additional tickets are used in the order specified by the ordering
+     of the options bits (see kdc-options, above).
+
+The application code will be either ten (10) or twelve (12) depending on
+whether the request is for an initial ticket (AS-REQ) or for an additional
+ticket (TGS-REQ).
+
+The optional fields (addresses, authorization-data and additional-tickets)
+are only included if necessary to perform the operation specified in the
+kdc-options field.
+
+It should be noted that in KRB_TGS_REQ, the protocol version number appears
+twice and two different message types appear: the KRB_TGS_REQ message
+contains these fields as does the authentication header (KRB_AP_REQ) that is
+passed in the padata field.
+
+5.4.2. KRB_KDC_REP definition
+
+The KRB_KDC_REP message format is used for the reply from the KDC for either
+an initial (AS) request or a subsequent (TGS) request. There is no message
+type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
+KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
+depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
+the client's secret key, and the client's key version number is included in
+the key version number for the encrypted data. For KRB_TGS_REP, the
+ciphertext is encrypted in the sub-session key from the Authenticator, or if
+absent, the session key from the ticket-granting ticket used in the request.
+In that case, no version number will be present in the EncryptedData
+sequence.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+The KRB_KDC_REP message contains the following fields:
+
+AS-REP ::=    [APPLICATION 11] KDC-REP
+TGS-REP ::=   [APPLICATION 13] KDC-REP
+
+KDC-REP ::=   SEQUENCE {
+              pvno[0]                    INTEGER,
+              msg-type[1]                INTEGER,
+              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
+              crealm[3]                  Realm,
+              cname[4]                   PrincipalName,
+              ticket[5]                  Ticket,
+              enc-part[6]                EncryptedData
+}
+
+EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
+EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
+
+EncKDCRepPart ::=   SEQUENCE {
+                    key[0]               EncryptionKey,
+                    last-req[1]          LastReq,
+                    nonce[2]             INTEGER,
+                    key-expiration[3]    KerberosTime OPTIONAL,
+                    flags[4]             TicketFlags,
+                    authtime[5]          KerberosTime,
+                    starttime[6]         KerberosTime OPTIONAL,
+                    endtime[7]           KerberosTime,
+                    renew-till[8]        KerberosTime OPTIONAL,
+                    srealm[9]            Realm,
+                    sname[10]            PrincipalName,
+                    caddr[11]            HostAddresses OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is either
+     KRB_AS_REP or KRB_TGS_REP.
+padata
+     This field is described in detail in section 5.4.1. One possible use
+     for this field is to encode an alternate "mix-in" string to be used
+     with a string-to-key algorithm (such as is described in section 6.3.2).
+     This ability is useful to ease transitions if a realm name needs to
+     change (e.g. when a company is acquired); in such a case all existing
+     password-derived entries in the KDC database would be flagged as
+     needing a special mix-in string until the next password change.
+crealm, cname, srealm and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+ticket
+     The newly-issued ticket, from section 5.3.1.
+enc-part
+     This field is a place holder for the ciphertext and related information
+     that forms the encrypted part of a message. The description of the
+     encrypted part of the message follows each appearance of this field.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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.
+
+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
+}
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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.
+
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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).
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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. It is
+     to be encoded separately and then have the checksum computed over it,
+     for use in the cksum field.
+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-BODY sequence.
+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.
+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
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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:
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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
+     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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     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 not protected by any encryption, it
+is quite possible for an intruder to synthesize or modify such a message. In
+particular, this means that 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,
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                e-data[12]                    OCTET STRING OPTIONAL,
+                e-cksum[13]                   Checksum OPTIONAL,
+                e-typed-data[14]              SEQUENCE of ETypedData OPTIONAL
+}
+
+ETypedData ::=  SEQUENCE {
+                e-data-type    [1] INTEGER,
+                e-data-value   [2] OCTET STRING,
+}
+
+
+
+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 the
+     errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
+     contain an encoding of a sequence of padata fields, each corresponding
+     to an acceptable pre-authentication method and optionally containing
+     data for the method:
+
+     METHOD-DATA ::=   SEQUENCE of PA-DATA
+
+     If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
+     contain an encoding of the following sequence:
+
+     METHOD-DATA ::=   SEQUENCE {
+                         method-type[0]   INTEGER,
+                         method-data[1]   OCTET STRING OPTIONAL
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+     }
+
+     method-type will indicate the required alternate method; method-data
+     will contain any required additional information.
+e-cksum
+     This field contains an optional checksum for the KRB-ERROR message. The
+     checksum is calculated over the Kerberos ASN.1 encoding of the
+     KRB-ERROR message with the checksum absent. The checksum is then added
+     to the KRB-ERROR structure and the message is re-encoded. The Checksum
+     should be calculated using the session key from the ticket granting
+     ticket or service ticket, where available. If the error is in response
+     to a TGS or AP request, the checksum should be calculated uing the the
+     session key from the client's ticket. If the error is in response to an
+     AS request, then the checksum should be calulated using the client's
+     secret key ONLY if there has been suitable preauthentication to prove
+     knowledge of the secret key by the client[33]. If a checksum can not be
+     computed because the key to be used is not available, no checksum will
+     be included.
+e-typed-data
+     [This field for discussion, may be deleted from final spec] This field
+     contains optional data that may be used to help the client recover from
+     the indicated error. [This could contain the METHOD-DATA specified
+     since I don't think anyone actually uses it yet. It could also contain
+     the PA-DATA sequence for the preauth required error if we had a clear
+     way to transition to the use of this field from the use of the untype
+     e-data field.] For example, this field may specify the key version of
+     the key used to verify preauthentication:
+
+     e-data-type  := 20 -- Key version number
+     e-data-value := Integer -- Key version number used to verify
+                                preauthentication 
+
+6. Encryption and Checksum Specifications
+
+The Kerberos protocols described in this document are designed to use stream
+encryption ciphers, which can be simulated using commonly available block
+encryption ciphers, such as the Data Encryption Standard, [DES77] in
+conjunction with block chaining and checksum methods [DESM80]. Encryption is
+used to prove the identities of the network entities participating in
+message exchanges. The Key Distribution Center for each realm is trusted by
+all principals registered in that realm to store a secret key in confidence.
+Proof of knowledge of this secret key is used to verify the authenticity of
+a principal.
+
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 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
+}
+
+
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+etype
+     This field identifies which encryption algorithm was used to encipher
+     the cipher. Detailed specifications for selected encryption types
+     appear later in this section.
+kvno
+     This field contains the version number of the key under which data is
+     encrypted. It is only present in messages encrypted under long lasting
+     keys, such as principals' secret keys.
+cipher
+     This field contains the enciphered text, encoded as an OCTET STRING.
+
+The cipher field is generated by applying the specified encryption algorithm
+to data composed of the message and algorithm-specific inputs. Encryption
+mechanisms defined for use with Kerberos must take sufficient measures to
+guarantee the integrity of the plaintext, and we recommend they also take
+measures to protect against precomputed dictionary attacks. If the
+encryption algorithm is not itself capable of doing so, the protections can
+often be enhanced by adding a checksum and a confounder.
+
+The suggested format for the data to be encrypted includes a confounder, a
+checksum, the encoded plaintext, and any necessary padding. The msg-seq
+field contains the part of the protocol message described in section 5 which
+is to be encrypted. The confounder, checksum, and padding are all untagged
+and untyped, and their length is exactly sufficient to hold the appropriate
+item. The type and length is implicit and specified by the particular
+encryption type being used (etype). The format for the data to be encrypted
+is described in the following diagram:
+
+      +-----------+----------+-------------+-----+
+      |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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+encryption type to communicate with all others using that type, the
+specification of an encryption type defines any checksum that is needed as
+part of the encryption process. If an alternative checksum is to be used, a
+new encryption type must be defined.
+
+Some cryptosystems require additional information beyond the key and the
+data to be encrypted. For example, DES, when used in cipher-block-chaining
+mode, requires an initialization vector. If required, the description for
+each encryption type must specify the source of such additional information.
+6.2. Encryption Keys
+
+The sequence below shows the encoding of an encryption key:
+
+       EncryptionKey ::=   SEQUENCE {
+                           keytype[0]    INTEGER,
+                           keyvalue[1]   OCTET STRING
+       }
+
+keytype
+     This field specifies the type of encryption key that follows in the
+     keyvalue field. It will almost always correspond to the encryption
+     algorithm used to generate the EncryptedData, though more than one
+     algorithm may use the same type of key (the mapping is many to one).
+     This might happen, for example, if the encryption algorithm uses an
+     alternate checksum algorithm for an integrity check, or a different
+     chaining mechanism.
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+Note that, since the CRC-32 checksum is not collision-proof, an attacker
+could use a probabilistic chosen-plaintext attack to generate a valid
+message even if a confounder is used [SG92]. The use of collision-proof
+checksums is recommended for environments where such attacks represent a
+significant threat. The use of the CRC-32 as the checksum for ticket or
+authenticator is no longer mandated as an interoperability requirement for
+Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
+
+6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
+
+The des-cbc-md4 encryption mode encrypts information under the Data
+Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
+An MD4 checksum (described in [MD492]) is applied to the confounder and
+message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
+bytes. As a result, the data to be encrypted (the concatenation of
+confounder, checksum, and message) must be padded to an 8 byte boundary
+before encryption. The details of the encryption of this data are identical
+to those for the des-cbc-md5 encryption mode.
+
+6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
+
+The des-cbc-md5 encryption mode encrypts information under the Data
+Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
+An MD5 checksum (described in [MD5-92].) is applied to the confounder and
+message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
+bytes. As a result, the data to be encrypted (the concatenation of
+confounder, checksum, and message) must be padded to an 8 byte boundary
+before encryption.
+
+Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
+concatenated to make the 64-bit inputs for the DES algorithms. The first
+octet supplies the 8 most significant bits (with the octet's MSbit used as
+the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
+and the eighth octet supplies the 8 least significant bits.
+
+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.]
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+String to key transformation
+
+To generate a DES key from a text string (password), the text string
+normally must have the realm and each component of the principal's name
+appended[37], then padded with ASCII nulls to an 8 byte boundary. This
+string is then fan-folded and eXclusive-ORed with itself to form an 8 byte
+DES key. The parity is corrected on the key, and it is used to generate a
+DES CBC checksum on the initial string (with the realm and name appended).
+Next, parity is corrected on the CBC checksum. If the result matches a
+'weak' or 'semi-weak' key as described in the DES specification, it is
+eXclusive-ORed with the constant 00000000000000F0. Finally, the result is
+returned as the key. Pseudocode follows:
+
+     string_to_key(string,realm,name) {
+          odd = 1;
+          s = string + realm;
+          for(each component in name) {
+               s = s + component;
+          }
+          tempkey = NULL;
+          pad(s); /* with nulls to 8 byte boundary */
+          for(8byteblock in s) {
+               if(odd == 0)  {
+                   odd = 1;
+                   reverse(8byteblock)
+               }
+               else odd = 0;
+               tempkey = tempkey XOR 8byteblock;
+          }
+          fixparity(tempkey);
+          key = DES-CBC-check(s,tempkey);
+          fixparity(key);
+          if(is_weak_key_key(key))
+               key = key XOR 0xF0;
+          return(key);
+     }
+
+6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-sum
+(des3-cbc-sha1)
+
+The des3-cbc-sha1 encryption encodes information using three Data Encryption
+Standard transformations with three DES keys. The first key is used to
+perform a DES ECB encryption on an eight-octet data block using the first
+DES key, followed by a DES ECB decryption of the result using the second DES
+key, and a DES ECB encryption of the result using the third DES key. Because
+DES blocks are 8 bytes, the data to be encrypted (the concatenation of
+confounder, checksum, and message) must first be padded to an 8 byte
+boundary before encryption. To support the outer CBC mode, the input is
+padded to an eight-octet boundary. The first 8 octets of the data to be
+encrypted (the confounder) is exclusive-ored with an initialization vector
+of zero and then ECB encrypted using triple DES as described above.
+Subsequent blocks of 8 octets are exclusive-ored with the ciphertext
+produced by the encryption on the previous block before ECB encryption.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+An HMAC-SHA1 checksum (described in [KBC96].) is applied to the confounder
+and message sequence (msg-seq) and placed in the cksum field.
+
+Plaintext 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 Triple 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 Triple DES key is 24 octets of data, with keytype seven (7). This consists
+of 168 bits of key, and 24 parity bits (one per octet). The key is encoded
+as a series of 24 octets written in MSB-first order, with the first 8 octets
+treated as the first DES key, the second 8 octets as the second key, and the
+third 8 octets the third DES key. The bits within each 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.]
+
+Key derivation for specified operations (Horowitz)
+
+[Discussion is needed for this section, especially since it does not simply
+derive key generation, but also specifies encryption using triple DES in a
+manner that is different than the basic template that was specified for
+single DES and similar systems]
+
+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 in each of these places. Key derivation [Horowitz96] can
+be used to construct different keys for each operation from the keys
+transported on the network or derived from the password specified by the
+user.
+
+For each place where a key is used in Kerberos, a ``key usage'' is specified
+for that purpose. The key, key usage, and encryption/checksum type together
+describe the transformation from plaintext to ciphertext. For backwards
+compatibility, this key derivation is only specified here for encryption
+methods based on triple DES. Encryption methods specified for use by
+Kerberos in the future should specify the key derivation function to be
+used.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 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 | length | plaintext | padding) |
+                   H(Ki, confounder | length | 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, length | plaintext)
+
+
+Note that each enctype is described by an encryption algorithm E and a keyed
+hash algorithm H, and each checksum type is described by a keyed hash
+algorithm H. HMAC, with an appropriate hash, is recommended for use as H.
+
+The key usage value will be taken from the following list of places where
+keys are used in the Kerberos protocol, with key usage values and Kerberos
+specification 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)
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+      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-SAFE cksum, keyed with a key chosen by the application
+          (section 5.8.1)
+
+      16. Data which is defined in some specification outside of
+          Kerberos to be encrypted using Kerberos encryption type.
+      17. Data which is defined in some specification outside of
+          Kerberos to be checksummed using Kerberos checksum type.
+
+      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)
+
+String to key transformation
+
+To generate a DES key from a text string (password), the text string
+normally must have the realm and each component of the principal's name
+appended[38].
+
+The input string (with any salt data appended to it) is n-folded into a 24
+octet (192 bit) string. 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 X is rotated to the right by 13 bit positions.
+The successive n-bit chunks are added together using 1's-complement addition
+(addition with end-around carry) to yield a n-bit result. (This
+transformation was proposed by Richard Basch)
+
+Each successive set of 8 octets is taken as a DES key, and its parity is
+adjusted in the same manner as previously described. If any of the three
+sets of 8 octets match a 'weak' or 'semi-weak key as described in the DES
+specification, that chunk is eXclusive-ORed with the hexadecimal constant
+00000000000000F0. The resulting DES keys are then used in sequence to
+perform a Triple-DES CBC encryption of the n-folded input string (appended
+with any salt data), using a zero initial vector. Parity, weak, and
+semi-weak keys are once again corrected and the result is returned as the 24
+octet key.
+
+Pseudocode follows:
+
+     string_to_key(string,realm,name) {
+          s = string + realm;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+          for(each component in name) {
+               s = s + component;
+          }
+          tkey[24] = fold(s);
+          fixparity(tkey);
+          if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
+          if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
+          if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
+          key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
+          fixparity(key);
+          if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
+          if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
+          if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
+          return(key);
+     }
+
+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.
+
+6.4.1. The CRC-32 Checksum (crc32)
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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)
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 1779.
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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
+
+IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
+type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The
+following addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
+
+   * the Unspecified Address
+   * the Loopback Address
+   * Link-Local addresses
+
+IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
+
+CHAOSnet addresses
+
+CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
+The type of CHAOSnet addresses is five (5).
+
+ISO addresses
+
+ISO addresses are variable-length. The type of ISO addresses is seven (7).
+
+Xerox Network Services (XNS) addresses
+
+XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
+type of XNS addresses is six (6).
+
+AppleTalk Datagram Delivery Protocol (DDP) addresses
+
+AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network
+number. The first octet of the address is the node number; the remaining two
+octets encode the network number in MSB order. The type of AppleTalk DDP
+addresses is sixteen (16).
+
+DECnet Phase IV addresses
+
+DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
+type of DECnet Phase IV addresses is twelve (12).
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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
+
+Kerberos servers (KDC's) must accept 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
+connection will be broken after the reply has been received (or upon
+time-out). 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 will be
+required. The response to a request made through TCP/IP transport must also
+use TCP/IP transport.
+
+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.
+
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+Encryption type  etype value  block size    minimum pad size  confounder size
+NULL              0            1                 0                 0
+des-cbc-crc       1            8                 4                 8
+des-cbc-md4       2            8                 0                 8
+des-cbc-md5       3            8                 0                 8
+        4
+des3-cbc-md5      5            8                 0                 8
+        6
+des3-cbc-sha1     7            8                 0                 8
+sign-dsa-generate 8                                   (pkinit)
+encrypt-rsa-priv  9                                   (pkinit)
+encrypt-rsa-pub  10                                   (pkinit)
+rsa-pub-md5      11                                   (pkinit)
+rsa-pub-sha1     12                                   (pkinit)
+ENCTYPE_PK_CROSS 48                                   (reserved for pkcross)
+       0x8003
+
+Checksum type              sumtype value       checksum size
+CRC32                      1                   4
+rsa-md4                    2                   16
+rsa-md4-des                3                   24
+des-mac                    4                   16
+des-mac-k                  5                   8
+rsa-md4-des-k              6                   16
+rsa-md5                    7                   16
+rsa-md5-des                8                   24
+rsa-md5-des3               9                   24
+hmac-sha1-des3             10                  20  (I had this as 10, is it 12)
+
+padata type                     padata-type value
+
+PA-TGS-REQ                      1
+PA-ENC-TIMESTAMP                2
+PA-PW-SALT                      3
+                      4
+PA-ENC-UNIX-TIME                5
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+PA-SANDIA-SECUREID              6
+PA-SESAME                       7
+PA-OSF-DCE                      8
+PA-CYBERSAFE-SECUREID           9
+PA-AFS3-SALT                    10
+PA-ETYPE-INFO                   11
+SAM-CHALLENGE                   12                  (sam/otp)
+SAM-RESPONSE                    13                  (sam/otp)
+PA-PK-AS-REQ                    14                  (pkinit)
+PA-PK-AS-REP                    15                  (pkinit)
+PA-PK-AS-SIGN                   16                  (pkinit)
+PA-PK-KEY-REQ                   17                  (pkinit)
+PA-PK-KEY-REP                   18                  (pkinit)
+PA-USE-SPECIFIED-KVNO           20
+
+authorization data type         ad-type value
+AD-KDC-ISSUED                      1
+AD-INTENDED-FOR-SERVER             2
+AD-INTENDED-FOR-APPLICATION-CLASS  3
+AD-IF-RELEVANT                     4
+AD-OR                              5
+AD-MANDATORY-TICKET-EXTENSIONS     6
+AD-IN-TICKET-EXTENSIONS            7
+reserved values                    8-63
+OSF-DCE                            64
+SESAME                             65
+
+Ticket Extension Types
+
+TE-TYPE-NULL                  0      Null ticket extension
+TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
+                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
+TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
+TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
+                    5      TE-TYPE-DEST-HOST (I have reservations)
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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 1779]
+
+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
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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_GENERIC                60   Generic error (description in e-text)
+KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
+KDC_ERROR_CLIENT_NOT_TRUSTED   62   (pkinit)
+KDC_ERROR_KDC_NOT_TRUSTED      63   (pkinit)
+KDC_ERROR_INVALID_SIG          64   (pkinit)
+KDC_ERR_KEY_TOO_WEAK           65   (pkinit)
+KDC_ERR_CERTIFICATE_MISMATCH   66   (pkinit)
+
+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 may support
+TCP/IP transport.
+
+Encryption and checksum methods
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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
+Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
+
+Realm Names
+
+All implementations must understand hierarchical realms in both the Internet
+Domain and the X.500 style. When a ticket granting ticket for an unknown
+realm is requested, the KDC must be able to determine the names of the
+intermediate realms between the KDCs realm and the requested realm.
+
+Transited field encoding
+
+DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
+Alternative encodings may be supported, but they may be used only when that
+encoding is supported by ALL intermediate realms.
+
+Pre-authentication methods
+
+The TGS-REQ method must be supported. The TGS-REQ method is not used on the
+initial request. The PA-ENC-TIMESTAMP method must be supported by clients
+but whether it is enabled by default may be determined on a realm by realm
+basis. If not used in the initial request and the error
+KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
+acceptable method, the client should retry the initial request using the
+PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
+PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
+presence of PA-ENC-TIMESTAMP pre-authentication in a request.
+
+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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.
+
+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-
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+          stamps  in  Key Distribution Protocols," Communications
+          of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
+
+[KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
+          "The Evolution of the Kerberos Authentication Service,"
+          in an IEEE Computer Society Text soon to  be  published
+          (June 1992).
+
+[Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
+          Accounting  for Distributed Systems," in Proceedings of
+          the 13th International Conference on  Distributed  Com-
+          puting Systems, Pittsburgh, PA (May, 1993).
+
+[DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
+          Kerberos  Authentication  at Project Athena," Technical
+          Memorandum TM-424,  MIT Laboratory for Computer Science
+          (February 1990).
+
+[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
+          merfeld,  and  K. Raeburn, Section E.1: Service Manage-
+          ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
+          sachusetts (1987).
+
+[X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
+          tion Framework, December 1988.
+
+[Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
+          Guessing  Attacks, Open Software Foundation DCE Request
+          for Comments 26 (December 1992).
+
+[DES77]   National Bureau of Standards, U.S. Department  of  Com-
+          merce,  "Data Encryption Standard," Federal Information
+          Processing Standards Publication  46,   Washington,  DC
+          (1977).
+
+[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).
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+[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).
+
+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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                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
+                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  */
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        /* 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;
+        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;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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;
+        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;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+        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
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        /* 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
+        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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                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);
+
+        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. */
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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 */
+                        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         */
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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);
+                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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                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);
+
+                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);
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+        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,
+                        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;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+        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 */
+
+        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;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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 decr_ticket.caddr) then
+                        error_out(KRB_AP_ERR_BADADDR);
+                endif
+        elseif (application requires addresses) then
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+                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
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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;
+        checksum.checksum := checksum value; /* checksum.checksum */
+        packet.cksum := checksum;
+        packet.safe-body := body;
+
+A.14. KRB_SAFE verification
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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 */
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+        /* assemble packet: */
+        packet.pvno := protocol version; /* 5 */
+        packet.msg-type := message type; /* KRB_CRED */
+
+        for (tickets[n] in tickets to be forwarded) do
+                packet.tickets[n] = tickets[n].ticket;
+        done
+
+        packet.enc-part.etype := encryption type;
+
+        for (ticket[n] in tickets to be forwarded) do
+                body.ticket-info[n].key = tickets[n].session;
+                body.ticket-info[n].prealm = tickets[n].crealm;
+                body.ticket-info[n].pname = tickets[n].cname;
+                body.ticket-info[n].flags = tickets[n].flags;
+                body.ticket-info[n].authtime = tickets[n].authtime;
+                body.ticket-info[n].starttime = tickets[n].starttime;
+                body.ticket-info[n].endtime = tickets[n].endtime;
+                body.ticket-info[n].renew-till = tickets[n].renew-till;
+                body.ticket-info[n].srealm = tickets[n].srealm;
+                body.ticket-info[n].sname = tickets[n].sname;
+                body.ticket-info[n].caddr = tickets[n].caddr;
+        done
+
+        get system_time;
+        body.timestamp, body.usec := system_time;
+
+        if (using nonce) then
+                body.nonce := nonce;
+        endif
+
+        if (using s-address) then
+                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);
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        endif
+
+        cleartext := decrypt(packet.enc-part) using negotiated key;
+        if (decryption_error()) then
+                error_out(KRB_AP_ERR_BAD_INTEGRITY);
+        endif
+        if ((packet.r-address is present or required) and
+           (packet.s-address != O/S_sender(packet)) then
+                /* O/S report of sender not who claims to have sent it */
+                error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if ((packet.r-address is present) and
+            (packet.r-address != local_host_address)) then
+                /* was not sent to proper place */
+                error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if (not in_clock_skew(packet.timestamp,packet.usec)) then
+                error_out(KRB_AP_ERR_SKEW);
+        endif
+        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
+                error_out(KRB_AP_ERR_REPEAT);
+        endif
+        if (packet.nonce is required or present) and
+           (packet.nonce != expected-nonce) then
+                error_out(KRB_AP_ERR_MODIFIED);
+        endif
+
+        for (ticket[n] in tickets that were forwarded) do
+                save_for_later(ticket[n],key[n],principal[n],
+                               server[n],times[n],flags[n]);
+        return
+
+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;
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+        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 ebcause 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. KDC Issued
+
+AD-KDCIssued   SEQUENCE {
+               ad-checksum[0]    Checksum,
+                i-realm[1]       Realm OPTIONAL,
+                i-sname[2]       PrincipalName OPTIONAL,
+               elements[3]       AuthorizationData.
+}
+
+ad-checksum
+     A checksum over the elements field using a cryptographic checksum
+     method that is identical to the checksum used to protect the ticket
+     itself (i.e. using the same hash function and the same encryption
+     algorithm used to encrypt the ticket) and using a key derived from the
+     same key used to protect the ticket.
+i-realm, i-sname
+     The name of the issuing principal if different from the KDC itself.
+     This field would be used when the KDC can verify the authenticity of
+     elements signed by the issuing principal and it allows this KDC to
+     notify the application server of the validity of those elements.
+elements
+     A sequence of authorization data elements issued by the KDC.
+
+The KDC-issued ad-data field is intended to provide a means for Kerberos
+principal credentials to embed within themselves privilege attributes and
+other mechanisms for positive authorization, amplifying the priveleges of
+the principal beyond what can be done using a credentials without such an
+a-data element.
+
+This can not be provided without this element because the definition of the
+authorization-data field allows elements to be added at will by the bearer
+of a TGT at the time that they request service tickets and elements may also
+be added to a delegated ticket by inclusion in the authenticator.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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.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. If relevant
+
+AD-IF-RELEVANT   AuthorizationData
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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.5. And-Or
+
+AD-AND-OR           SEQUENCE {
+                        condition-count[0]    INTEGER,
+                        elements[1]           AuthorizationData
+}
+
+When restrictive AD elements encapsulated within the and-or element are
+encountered, only the number specified in condition-count of the
+encapsulated conditions must be met in order to satisfy this element. This
+element may be used to implement an "or" operation by setting the
+condition-count field to 1, and it may specify an "and" operation by setting
+the condition count to the number of embedded elements. Application servers
+that do not implement this element must reject tickets that contain
+authorization data elements of this type.
+
+B.6. Mandatory ticket extensions
+
+AD-Mandatory-Ticket-Extensions   Checksum
+
+An authorization data element of type mandatory-ticket-extensions specifies
+a collision-proof checksum using the same has angorithm used to protect the
+integrity of the ticket itself. This checksum will be calculated over the
+entire extensions field. If there are more than one extension, all will be
+covered by the checksum. This restriction indicates that the ticket should
+not be accepted if the checksum does not match that calculated over the
+ticket extensions. 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 has angorithm 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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+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.
+----------------------------------------------------------------------------
+[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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+[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.
+
+[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.
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+
+[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.
+
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+[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
+
+
+draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
+
+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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt
new file mode 100644
index 00000000000..06d997d48cc
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt
@@ -0,0 +1,6766 @@
+
+
+
+INTERNET-DRAFT                                          Clifford Neuman
+                                                              John Kohl
+                                                          Theodore Ts'o
+                                                    November 18th, 1998
+
+The Kerberos Network Authentication Service (V5)
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft. Internet-Drafts are working documents
+of the Internet Engineering Task Force (IETF), its areas, and its working
+groups. Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time. It
+is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as 'work in progress.'
+
+To learn the current status of any Internet-Draft, please check the
+'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
+Directories on 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-03.txt, and expires May 18th, 1999. 
+Please send comments to: krb-protocol@MIT.EDU
+
+ABSTRACT
+
+This document provides an overview and specification of Version 5 of the
+Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
+and its intended use that require more detailed or clearer explanation than
+was provided in RFC1510. This document is intended to provide a detailed
+description of the protocol, suitable for implementation, together with
+descriptions of the appropriate use of protocol messages and fields within
+those messages.
+
+This document is not intended to describe Kerberos to the end user, system
+administrator, or application developer. Higher level papers describing
+Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
+are available elsewhere.
+
+OVERVIEW
+
+This INTERNET-DRAFT describes the concepts and model upon which the
+Kerberos network authentication system is based. It also specifies Version
+5 of the Kerberos protocol.
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+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.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+ticket-granting-tickets for other realms, but they are encouraged not to do
+so. A client may request that the KDC's not check the transited field by
+setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
+required to honor this flag.
+
+1.2. Authorization
+
+As an authentication service, Kerberos provides a means of verifying the
+identity of principals on a network. Authentication is usually useful
+primarily as a first step in the process of authorization, determining
+whether a client may use a service, which objects the client is allowed to
+access, and the type of access allowed for each. Kerberos does not, by
+itself, provide authorization. Possession of a client ticket for a service
+provides only for authentication of the client to that service, and in the
+absence of a separate authorization procedure, it should not be considered
+by an application as authorizing the use of that service.
+
+Such separate authorization methods may be implemented as application
+specific access control functions and may be based on files such as the
+application server, or on separately issued authorization credentials such
+as those based on proxies [Neu93] , or on other authorization services.
+
+Applications should not be modified to accept the issuance of a service
+ticket by the Kerberos server (even by an modified Kerberos server) as
+granting authority to use the service, since such applications may become
+vulnerable to the bypass of this authorization check in an environment if
+they interoperate with other KDCs or where other options for application
+authentication (e.g. the PKTAPP proposal) are provided.
+
+1.3. Environmental assumptions
+
+Kerberos imposes a few assumptions on the environment in which it can
+properly function:
+
+   * 'Denial of service' attacks are not solved with Kerberos. There are
+     places in these protocols where an intruder can prevent an application
+     from participating in the proper authentication steps. Detection and
+     solution of such attacks (some of which can appear to be nnot-uncommon
+     'normal' failure modes for the system) is usually best left to the
+     human administrators and users.
+   * Principals must keep their secret keys secret. If an intruder somehow
+     steals a principal's key, it will be able to masquerade as that
+     principal or impersonate any server to the legitimate principal.
+   * 'Password guessing' attacks are not solved by Kerberos. If a user
+     chooses a poor password, it is possible for an attacker to
+     successfully mount an offline dictionary attack by repeatedly
+     attempting to decrypt, with successive entries from a dictionary,
+     messages obtained which are encrypted under a key derived from the
+     user's password.
+   * 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     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.
+Principal
+     A uniquely named client or server instance that participates in a
+     network communication.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+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.
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+
+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:
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+   * 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
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+                             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
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+
+If all these checks succeed without an error, the server is assured that
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+used for subsequent communication. To make this example more concrete, if
+the encryption method in use required a 56 bit key, and for whatever
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 text explaining what went wrong. The KRB_ERROR message is not
+encrypted. The KRB_TGS_REP message contains information which can be used
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 tickets.
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     "/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: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+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: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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. 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 contain- ing the
+principal identifiers and secret keys of principals to be
+authenticated[21].
+
+4.1. Database contents
+
+A database entry should contain at least the following fields:
+
+Field                Value
+
+name                 Principal's identifier
+key                  Principal's secret key
+p_kvno               Principal's key version
+max_life             Maximum lifetime for Tickets
+max_renewable_life   Maximum total lifetime for renewable Tickets
+
+The name field is an encoding of the principal's identifier. The key field
+contains an encryption key. This key is the principal's secret key. (The
+key can be encrypted before storage under a Kerberos "master key" to
+protect it in case the database is compromised but the master key is not.
+In that case, an extra field must be added to indicate the master key
+version used, see below.) The p_kvno field is the key version number of the
+principal's secret key. The max_life field contains the maximum allowable
+lifetime (endtime - starttime) for any Ticket issued for this principal.
+The max_renewable_life field contains the maximum allowable total lifetime
+for any renewable Ticket issued for this principal. (See section 3.1 for a
+description of how these lifetimes are used in determining the lifetime of
+a given Ticket.)
+
+A server may provide KDC service to several realms, as long as the database
+representation provides a mechanism to distinguish between principal
+records with identifiers which differ only in the realm name.
+
+When an application server's key changes, if the change is routine (i.e.
+not the result of disclosure of the old key), the old key should be
+retained by the server until all tickets that had been issued using that
+key have expired. Because of this, it is possible for several keys to be
+active for a single principal. Ciphertext encrypted in a principal's key is
+always tagged with the version of the key that was used for encryption, to
+help the recipient find the proper key for decryption.
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+
+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).
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+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. Implementation should 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+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
+                  -- reserved(0),
+                  -- forwardable(1),
+                  -- forwarded(2),
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                  -- proxiable(3),
+                  -- proxy(4),
+                  -- allow-postdate(5),
+                  -- postdated(6),
+                  -- 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
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+
+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 the name part of the server's identity.
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     application server. See Appendix C for definitions of some common
+     extensions.
+
+     Note that some older versions of Kerberos did not support this field.
+     Because this is an optional field it will not break older clients, but
+     older clients might strip this field from the ticket before sending it
+     to the application server. This limits the usefulness of this ticket
+     field to environments where the ticket will not be parsed and
+     reconstructed by these older Kerberos clients.
+
+     If it is known that the client will strip this field from the ticket,
+     as an interim measure the KDC may append this field to the end of the
+     enc-part of the ticket and append a traler indicating the lenght of
+     the appended extensions field. (this paragraph is open for discussion,
+     including the form of the traler).
+flags
+     This field indicates which of various options were used or requested
+     when the ticket was issued. It is a bit-field, where the selected
+     options are indicated by the bit being set (1), and the unselected
+     options and reserved fields being reset (0). Bit 0 is the most
+     significant bit. The encoding of the bits is specified in section 5.2.
+     The flags are described in more detail above in section 2. The
+     meanings of the flags are:
+
+          Bit(s)      Name         Description
+
+          0           RESERVED
+                                   Reserved for future  expansion  of  this
+                                   field.
+
+          1           FORWARDABLE
+                                   The FORWARDABLE flag  is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.  When set,  this
+                                   flag  tells  the  ticket-granting server
+                                   that it is OK to  issue  a  new  ticket-
+                                   granting ticket with a different network
+                                   address based on the presented ticket.
+
+          2           FORWARDED
+                                   When set, this flag indicates  that  the
+                                   ticket  has either been forwarded or was
+                                   issued based on authentication involving
+                                   a forwarded ticket-granting ticket.
+
+          3           PROXIABLE
+                                   The  PROXIABLE  flag  is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.   The  PROXIABLE
+                                   flag  has an interpretation identical to
+                                   that of  the  FORWARDABLE  flag,  except
+                                   that   the   PROXIABLE  flag  tells  the
+                                   ticket-granting server  that  only  non-
+                                   ticket-granting  tickets  may  be issued
+                                   with different network addresses.
+
+          4           PROXY
+                                   When set, this  flag  indicates  that  a
+                                   ticket is a proxy.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+          5           MAY-POSTDATE
+                                   The MAY-POSTDATE flag is  normally  only
+                                   interpreted  by  the  TGS,  and  can  be
+                                   ignored by end servers.  This flag tells
+                                   the  ticket-granting server that a post-
+                                   dated ticket may be issued based on this
+                                   ticket-granting ticket.
+
+          6           POSTDATED
+                                   This flag indicates that this ticket has
+                                   been  postdated.   The  end-service  can
+                                   check the authtime field to see when the
+                                   original authentication occurred.
+
+          7           INVALID
+                                   This flag indicates  that  a  ticket  is
+                                   invalid, and it must be validated by the
+                                   KDC  before  use.   Application  servers
+                                   must reject tickets which have this flag
+                                   set.
+
+          8           RENEWABLE
+                                   The  RENEWABLE  flag  is  normally  only
+                                   interpreted  by the TGS, and can usually
+                                   be ignored by end servers (some particu-
+                                   larly careful servers may wish to disal-
+                                   low  renewable  tickets).   A  renewable
+                                   ticket  can be used to obtain a replace-
+                                   ment ticket  that  expires  at  a  later
+                                   date.
+
+          9           INITIAL
+                                   This flag indicates that this ticket was
+                                   issued  using  the  AS protocol, and not
+                                   issued  based   on   a   ticket-granting
+                                   ticket.
+
+          10          PRE-AUTHENT
+                                   This flag indicates that during  initial
+                                   authentication, the client was authenti-
+                                   cated by the KDC  before  a  ticket  was
+                                   issued.    The   strength  of  the  pre-
+                                   authentication method is not  indicated,
+                                   but is acceptable to the KDC.
+
+          11          HW-AUTHENT
+                                   This flag indicates  that  the  protocol
+                                   employed   for   initial  authentication
+                                   required the use of hardware expected to
+                                   be possessed solely by the named client.
+                                   The hardware  authentication  method  is
+                                   selected  by the KDC and the strength of
+                                   the method is not indicated.
+
+          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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                                   reset (0), then the application server
+                                   must check the transited field itself,
+                                   and if unable to do so it must reject
+                                   the authentication.  If the flag is set
+                                   (1) then the application server may skip
+                                   its own validation of the transited
+                                   field, relying on the validation
+                                   performed by the KDC.  At its option the
+                                   application server may still apply its
+                                   own validation based on a separate
+                                   policy for acceptance.
+
+          13      OK-AS-DELEGATE   This flag indicates that the server (not
+                                   the client) specified in the ticket has
+                                   been determined by policy of the realm
+                                   to be a suitable recipient of
+                                   delegation.  A client can use the
+                                   presence of this flag to help it make a
+                                   decision whether to delegate credentials
+                                   (either grant a proxy or a forwarded
+                                   ticket granting ticket) to this server.
+                                   The client is free to ignore the value
+                                   of this flag.  When setting this flag,
+                                   an administrator should consider the
+                                   Security and placement of the server on
+                                   which the service will run, as well as
+                                   whether the service requires the use of
+                                   delegated credentials.
+
+          14          ANONYMOUS
+                                   This flag indicates that  the  principal
+                                   named in the ticket is a generic princi-
+                                   pal for the realm and does not  identify
+                                   the  individual  using  the ticket.  The
+                                   purpose  of  the  ticket  is   only   to
+                                   securely  distribute  a session key, and
+                                   not to identify  the  user.   Subsequent
+                                   requests  using the same ticket and ses-
+                                   sion may be  considered  as  originating
+                                   from  the  same  user, but requests with
+                                   the same username but a different ticket
+                                   are  likely  to originate from different
+                                   users.
+
+          15-31       RESERVED
+                                   Reserved for future use.
+
+key
+     This field exists in the ticket and the KDC response and is used to
+     pass the session key from Kerberos to the application server and the
+     client. The field's encoding is described in section 6.2.
+crealm
+     This field contains the name of the realm in which the client is
+     registered and in which initial authentication took place.
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     authenticating the user to whom this ticket was issued. It does not
+     specify the order in which the realms were transited. See section
+     3.3.3.2 for details on how this field encodes the traversed realms.
+     When the names of CA's are to be embedded inthe transited field (as
+     specified for some extentions to the protocol), the X.500 names of the
+     CA's should be mapped into items in the transited field using the
+     mapping defined by RFC2253.
+authtime
+     This field indicates the time of initial authentication for the named
+     principal. It is the time of issue for the original ticket on which
+     this ticket is based. It is included in the ticket to provide
+     additional information to the end service, and to provide the
+     necessary information for implementation of a `hot list' service at
+     the KDC. An end service that is particularly paranoid could refuse to
+     accept tickets for which the initial authentication occurred "too far"
+     in the past. This field is also returned as part of the response from
+     the KDC. When returned as part of the response to initial
+     authentication (KRB_AS_REP), this is the current time on the Ker-
+     beros server[24].
+starttime
+     This field in the ticket specifies the time after which the ticket is
+     valid. Together with endtime, this field specifies the life of the
+     ticket. If it is absent from the ticket, its value should be treated
+     as that of the authtime field.
+endtime
+     This field contains the time after which the ticket will not be
+     honored (its expiration time). Note that individual services may place
+     their own limits on the life of a ticket and may reject tickets which
+     have not yet expired. As such, this is really an upper bound on the
+     expiration time for the ticket.
+renew-till
+     This field is only present in tickets that have the RENEWABLE flag set
+     in the flags field. It indicates the maximum endtime that may be
+     included in a renewal. It can be thought of as the absolute expiration
+     time for the ticket, including all renewals.
+caddr
+     This field in a ticket contains zero (if omitted) or more (if present)
+     host addresses. These are the addresses from which the ticket can be
+     used. If there are no addresses, the ticket can be used from any
+     location. The decision by the KDC to issue or by the end server to
+     accept zero-address tickets is a policy decision and is left to the
+     Kerberos and end-service administrators; they may refuse to issue or
+     accept such tickets. The suggested and default policy, however, is
+     that such tickets will only be issued or accepted when additional
+     information that can be used to restrict the use of the ticket is
+     included in the authorization_data field. Such a ticket is a
+     capability.
+
+     Network addresses are included in the ticket to make it harder for an
+     attacker to use stolen credentials. Because the session key is not
+     sent over the network in cleartext, credentials can't be stolen simply
+     by listening to the network; an attacker has to gain access to the
+     session key (perhaps through operating system security breaches or a
+     careless user's unattended session) to make use of stolen tickets.
+
+     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 worksta- tion could
+     use the credentials from there. Including the network addresses only
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     makes it more difficult, not impossible, for an attacker to walk off
+     with stolen credentials and then use them from a "safe" location.
+authorization-data
+     The authorization-data field is used to pass authorization data from
+     the principal on whose behalf a ticket was issued to the application
+     service. If no authorization data is included, this field will be left
+     out. Experience has shown that the name of this field is confusing,
+     and that a better name for this field would be restrictions.
+     Unfortunately, it is not possible to change the name of this field at
+     this time.
+
+     This field contains restrictions on any authority obtained on the
+     basis of authentication using the ticket. It is possible for any
+     principal in posession of credentials to add entries to the
+     authorization data field since these entries further restrict what can
+     be done with the ticket. Such additions can be made by specifying the
+     additional entries when a new ticket is obtained during the TGS
+     exchange, or they may be added during chained delegation using the
+     authorization data field of the authenticator.
+
+     Because entries may be added to this field by the holder of
+     credentials, it is not allowable for the presence of an entry in the
+     authorization data field of a ticket to amplify the priveleges one
+     would obtain from using a ticket.
+
+     The data in this field may be specific to the end service; the field
+     will contain the names of service specific objects, and the rights to
+     those objects. The format for this field is described in section 5.2.
+     Although Kerberos is not concerned with the format of the contents of
+     the sub-fields, it does carry type information (ad-type).
+
+     By using the authorization_data field, a principal is able to issue a
+     proxy that is valid for a specific purpose. For example, a client
+     wishing to print a file can obtain a file server proxy to be passed to
+     the print server. By specifying the name of the file in the
+     authorization_data field, the file server knows that the print server
+     can only use the client's rights when accessing the particular file to
+     be printed.
+
+     A separate service providing authorization or certifying group
+     membership may be built using the authorization-data field. In this
+     case, the entity granting authorization (not the authorized entity),
+     obtains a ticket in its own name (e.g. the ticket is issued in the
+     name of a privelege server), and this entity adds restrictions on its
+     own authority and delegates the restricted authority through a proxy
+     to the client. The client would then present this authorization
+     credential to the application server separately from the
+     authentication exchange.
+
+     Similarly, if one specifies the authorization-data field of a proxy
+     and leaves the host addresses blank, the resulting ticket and session
+     key can be treated as a capability. See [Neu93] for some suggested
+     uses of this field.
+
+     The authorization-data field is optional and does not have to be
+     included in a ticket.
+
+5.3.2. Authenticators
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+An authenticator is a record sent with a ticket to a server to certify the
+client's knowledge of the encryption key in the ticket, to help the server
+detect replays, and to help choose a "true session key" to use with the
+particular session. The encoding is encrypted in the ticket's session key
+shared by the client and the server:
+
+-- Unencrypted authenticator
+Authenticator ::= [APPLICATION 2] SEQUENCE  {
+                  authenticator-vno[0]          INTEGER,
+                  crealm[1]                     Realm,
+                  cname[2]                      PrincipalName,
+                  cksum[3]                      Checksum OPTIONAL,
+                  cusec[4]                      INTEGER,
+                  ctime[5]                      KerberosTime,
+                  subkey[6]                     EncryptionKey OPTIONAL,
+                  seq-number[7]                 INTEGER OPTIONAL,
+                  authorization-data[8]         AuthorizationData OPTIONAL
+}
+
+
+authenticator-vno
+     This field specifies the version number for the format of the
+     authenticator. This document specifies version 5.
+crealm and cname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+cksum
+     This field contains a checksum of the the applica- tion data that
+     accompanies the KRB_AP_REQ.
+cusec
+     This field contains the microsecond part of the client's timestamp.
+     Its value (before encryption) ranges from 0 to 999999. It often
+     appears along with ctime. The two fields are used together to specify
+     a reasonably accurate timestamp.
+ctime
+     This field contains the current time on the client's host.
+subkey
+     This field contains the client's choice for an encryption key which is
+     to be used to protect this specific application session. Unless an
+     application specifies otherwise, if this field is left out the session
+     key from the ticket will be used.
+seq-number
+     This optional field includes the initial sequence number to be used by
+     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
+     detect replays (It may also be used by application specific messages).
+     When included in the authenticator this field specifies the initial
+     sequence number for messages from the client to the server. When
+     included in the AP-REP message, the initial sequence number is that
+     for messages from the server to the client. When used in KRB_PRIV or
+     KRB_SAFE messages, it is incremented by one after each message is
+     sent. Sequence numbers fall in the range of 0 through 2^32 - 1 and
+     wrap to zero following the value 2^32 - 1.
+
+     For sequence numbers to adequately support the detection of replays
+     they should be non-repeating, even across connection boundaries. The
+     initial sequence number should be random and uniformly distributed
+     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.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+authorization-data
+     This field is the same as described for the ticket in section 5.3.1.
+     It is optional and will only appear when additional restrictions are
+     to be placed on the use of a ticket, beyond those carried in the
+     ticket itself.
+
+5.4. Specifications for the AS and TGS exchanges
+
+This section specifies the format of the messages used in the exchange
+between the client and the Kerberos server. The format of possible error
+messages appears in section 5.9.1.
+
+5.4.1. KRB_KDC_REQ definition
+
+The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
+KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an
+initial ticket or an additional ticket. In either case, the message is sent
+from the client to the Authentication Server to request credentials for a
+service.
+
+The message fields are:
+
+AS-REQ ::=         [APPLICATION 10] KDC-REQ
+TGS-REQ ::=        [APPLICATION 12] KDC-REQ
+
+KDC-REQ ::=        SEQUENCE {
+                   pvno[1]            INTEGER,
+                   msg-type[2]        INTEGER,
+                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
+                   req-body[4]        KDC-REQ-BODY
+}
+
+PA-DATA ::=        SEQUENCE {
+                   padata-type[1]     INTEGER,
+                   padata-value[2]    OCTET STRING,
+                                      -- might be encoded AP-REQ
+}
+
+KDC-REQ-BODY ::=   SEQUENCE {
+                    kdc-options[0]         KDCOptions,
+                    cname[1]               PrincipalName OPTIONAL,
+                                           -- Used only in AS-REQ
+                    realm[2]               Realm, -- Server's realm
+                                           -- Also client's in AS-REQ
+                    sname[3]               PrincipalName OPTIONAL,
+                    from[4]                KerberosTime OPTIONAL,
+                    till[5]                KerberosTime OPTIONAL,
+                    rtime[6]               KerberosTime OPTIONAL,
+                    nonce[7]               INTEGER,
+                    etype[8]               SEQUENCE OF INTEGER,
+                                           -- EncryptionType,
+                                           -- in preference order
+                    addresses[9]           HostAddresses OPTIONAL,
+                enc-authorization-data[10] EncryptedData OPTIONAL,
+                                           -- Encrypted AuthorizationData
+                                           -- encoding
+                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
+}
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+The fields in this message are:
+
+pvno
+     This field is included in each message, and specifies the protocol
+     version number. This document specifies protocol version 5.
+msg-type
+     This field indicates the type of a protocol message. It will almost
+     always be the same as the application identifier associated with a
+     message. It is included to make the identifier more readily accessible
+     to the application. For the KDC-REQ message, this type will be
+     KRB_AS_REQ or KRB_TGS_REQ.
+padata
+     The padata (pre-authentication data) field contains a sequence of
+     authentication information which may be needed before credentials can
+     be issued or decrypted. In the case of requests for additional tickets
+     (KRB_TGS_REQ), this field will include an element with padata-type of
+     PA-TGS-REQ and data of an authentication header (ticket-granting
+     ticket and authenticator). The checksum in the authenticator (which
+     must be collision-proof) is to be computed over the KDC-REQ-BODY
+     encoding. In most requests for initial authentication (KRB_AS_REQ) and
+     most replies (KDC-REP), the padata field will be left out.
+
+     This field may also contain information needed by certain extensions
+     to the Kerberos protocol. For example, it might be used to initially
+     verify the identity of a client before any response is returned. This
+     is accomplished with a padata field with padata-type equal to
+     PA-ENC-TIMESTAMP and padata-value defined as follows:
+
+     padata-type     ::= PA-ENC-TIMESTAMP
+     padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
+
+     PA-ENC-TS-ENC   ::= SEQUENCE {
+                     patimestamp[0]     KerberosTime, -- client's time
+                     pausec[1]          INTEGER OPTIONAL
+     }
+
+     with patimestamp containing the client's time and pausec containing
+     the microseconds which may be omitted if a client will not generate
+     more than one request per second. The ciphertext (padata-value)
+     consists of the PA-ENC-TS-ENC sequence, encrypted using the client's
+     secret key.
+
+     [use-specified-kvno item is here for discussion and may be removed] It
+     may also be used by the client to specify the version of a key that is
+     being used for accompanying preauthentication, and/or which should be
+     used to encrypt the reply from the KDC.
+
+     PA-USE-SPECIFIED-KVNO  ::=  Integer
+
+     The KDC should only accept and abide by the value of the
+     use-specified-kvno preauthentication data field when the specified key
+     is still valid and until use of a new key is confirmed. This situation
+     is likely to occur primarily during the period during which an updated
+     key is propagating to other KDC's in a realm.
+
+     The padata field can also contain information needed to help the KDC
+     or the client select the key needed for generating or decrypting the
+     response. This form of the padata is useful for supporting the use of
+     certain token cards with Kerberos. The details of such extensions are
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     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:
+
+        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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                                      the  initial request, or in a
+subsequent
+                                      request if the ticket-granting ticket
+on
+                                      which it is based is also proxiable.
+
+         4        PROXY
+                                      The PROXY option indicates that this
+is
+                                      a request for a proxy.  This option
+will
+                                      only be honored if  the
+ticket-granting
+                                      ticket  in the request has its
+PROXIABLE
+                                      bit set.  The address(es)  of  the
+host
+                                      from which the resulting ticket is to
+be
+                                       valid  are  included  in  the
+addresses
+                                      field of the request.
+
+         5        ALLOW-POSTDATE
+                                      The ALLOW-POSTDATE option indicates
+that
+                                      the  ticket  to be issued is to have
+its
+                                      MAY-POSTDATE flag set.  It may  only
+be
+                                      set on the initial request, or in a
+sub-
+                                      sequent request if  the
+ticket-granting
+                                      ticket on which it is based also has
+its
+                                      MAY-POSTDATE flag set.
+
+         6        POSTDATED
+                                      The POSTDATED option indicates that
+this
+                                      is  a  request  for  a postdated
+ticket.
+                                      This option will only be honored if
+the
+                                      ticket-granting  ticket  on  which
+                                      it is based has  its  MAY-POSTDATE
+                                      flag set.
+                                      The  resulting ticket will also have
+its
+                                      INVALID flag set, and that flag  may
+be
+                                      reset by a subsequent request to the
+KDC
+                                      after the starttime in  the  ticket
+has
+                                      been reached.
+
+         7        UNUSED
+                                      This option is presently unused.
+
+         8        RENEWABLE
+                                      The RENEWABLE option indicates that
+the
+                                      ticket  to  be  issued  is  to  have
+its
+                                      RENEWABLE flag set.  It may only be
+set
+                                      on  the  initial  request,  or  when
+the
+                                      ticket-granting  ticket  on  which
+the
+                                      request  is based is also renewable.
+If
+                                      this option is requested, then the
+rtime
+                                      field   in   the  request  contains
+the
+                                      desired absolute expiration time for
+the
+                                      ticket.
+
+         9-13     UNUSED
+                                      These options are presently unused.
+
+         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-
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                                      ier is to be generic,  as  specified
+by
+                                      the  policy  of  the realm (e.g.
+usually
+                                      anonymous@realm).  The  purpose  of
+the
+                                      ticket  is only to securely distribute
+a
+                                      session key, and  not  to  identify
+the
+                                      user.   The ANONYMOUS flag on the
+ticket
+                                      to be returned should be  set.   If
+the
+                                      local  realms  policy  does  not
+permit
+                                      anonymous credentials, the request is
+to
+                                      be rejected.
+
+         15-25    RESERVED
+                                      Reserved for future use.
+
+         26       DISABLE-TRANSITED-CHECK
+                                      By default the KDC will check the
+                                      transited field of a ticket-granting-
+                                      ticket against the policy of the local
+                                      realm before it will issue derivative
+                                      tickets based on the ticket granting
+                                      ticket.  If this flag is set in the
+                                      request, checking of the transited
+field
+                                      is disabled.  Tickets issued without
+the
+                                      performance of this check will be
+noted
+                                      by the reset (0) value of the
+                                      TRANSITED-POLICY-CHECKED flag,
+                                      indicating to the application server
+                                      that the tranisted field must be
+checked
+                                      locally.  KDC's are encouraged but not
+                                      required to honor the
+                                      DISABLE-TRANSITED-CHECK option.
+
+         27       RENEWABLE-OK
+                                      The RENEWABLE-OK option indicates that
+a
+                                      renewable ticket will be acceptable if
+a
+                                      ticket with the  requested  life
+cannot
+                                      otherwise be provided.  If a ticket
+with
+                                      the requested life cannot  be
+provided,
+                                      then  a  renewable  ticket may be
+issued
+                                      with  a  renew-till  equal  to  the
+the
+                                      requested  endtime.   The  value  of
+the
+                                      renew-till field may still be limited
+by
+                                      local  limits, or limits selected by
+the
+                                      individual principal or server.
+
+         28       ENC-TKT-IN-SKEY
+                                      This option is used only by the
+ticket-
+                                      granting  service.   The
+ENC-TKT-IN-SKEY
+                                      option indicates that the ticket for
+the
+                                      end  server  is  to  be encrypted in
+the
+                                      session key from the additional
+ticket-
+                                      granting ticket provided.
+
+         29       RESERVED
+                                      Reserved for future use.
+
+         30       RENEW
+                                      This option is used only by the
+ticket-
+                                      granting   service.   The  RENEW
+option
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                                      indicates that the  present  request
+is
+                                      for  a  renewal.  The ticket provided
+is
+                                      encrypted in  the  secret  key  for
+the
+                                      server  on  which  it  is  valid.
+This
+                                      option  will  only  be  honored  if
+the
+                                      ticket  to  be renewed has its
+RENEWABLE
+                                      flag set and if the time in  its
+renew-
+                                      till  field  has not passed.  The
+ticket
+                                      to be renewed is passed  in  the
+padata
+                                      field  as  part  of  the
+authentication
+                                      header.
+
+         31       VALIDATE
+                                      This option is used only by the
+ticket-
+                                      granting  service.   The VALIDATE
+option
+                                      indicates that the request is  to
+vali-
+                                      date  a  postdated ticket.  It will
+only
+                                      be honored if the  ticket  presented
+is
+                                      postdated,  presently  has  its
+INVALID
+                                      flag set, and would be otherwise
+usable
+                                      at  this time.  A ticket cannot be
+vali-
+                                      dated before its starttime.  The
+ticket
+                                      presented for validation is encrypted
+in
+                                      the key of the server for  which  it
+is
+                                      valid  and is passed in the padata
+field
+                                      as part of the authentication header.
+
+cname and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
+     specified. If absent, the name of the server is taken from the name of
+     the client in the ticket passed as additional-tickets.
+enc-authorization-data
+     The enc-authorization-data, if present (and it can only be present in
+     the TGS_REQ form), is an encoding of the desired authorization-data
+     encrypted under the sub-session key if present in the Authenticator,
+     or alternatively from the session key in the ticket-granting ticket,
+     both from the padata field in the KRB_AP_REQ.
+realm
+     This field specifies the realm part of the server's principal
+     identifier. In the AS exchange, this is also the realm part of the
+     client's principal identifier.
+from
+     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
+     requests when the requested ticket is to be postdated. It specifies
+     the desired start time for the requested ticket. If this field is
+     omitted then the KDC should use the current time instead.
+till
+     This field contains the expiration date requested by the client in a
+     ticket request. It is optional and if omitted the requested ticket is
+     to have the maximum endtime permitted according to KDC policy for the
+     parties to the authentication exchange as limited by expiration date
+     of the ticket granting ticket or other preauthentication credentials.
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     included in the encrypted response from the KDC, it provides evidence
+     that the response is fresh and has not been replayed by an attacker.
+     Nonces must never be re-used. Ideally, it should be generated
+     randomly, but if the correct time is known, it may suffice[25].
+etype
+     This field specifies the desired encryption algorithm to be used in
+     the response.
+addresses
+     This field is included in the initial request for tickets, and
+     optionally included in requests for additional tickets from the
+     ticket-granting server. It specifies the addresses from which the
+     requested ticket is to be valid. Normally it includes the addresses
+     for the client's host. If a proxy is requested, this field will
+     contain other addresses. The contents of this field are usually copied
+     by the KDC into the caddr field of the resulting ticket.
+additional-tickets
+     Additional tickets may be optionally included in a request to the
+     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
+     specified, then the session key from the additional ticket will be
+     used in place of the server's key to encrypt the new ticket. If more
+     than one option which requires additional tickets has been specified,
+     then the additional tickets are used in the order specified by the
+     ordering of the options bits (see kdc-options, above).
+
+The application code will be either ten (10) or twelve (12) depending on
+whether the request is for an initial ticket (AS-REQ) or for an additional
+ticket (TGS-REQ).
+
+The optional fields (addresses, authorization-data and additional-tickets)
+are only included if necessary to perform the operation specified in the
+kdc-options field.
+
+It should be noted that in KRB_TGS_REQ, the protocol version number appears
+twice and two different message types appear: the KRB_TGS_REQ message
+contains these fields as does the authentication header (KRB_AP_REQ) that
+is passed in the padata field.
+
+5.4.2. KRB_KDC_REP definition
+
+The KRB_KDC_REP message format is used for the reply from the KDC for
+either an initial (AS) request or a subsequent (TGS) request. There is no
+message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP
+or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
+depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
+the client's secret key, and the client's key version number is included in
+the key version number for the encrypted data. For KRB_TGS_REP, the
+ciphertext is encrypted in the sub-session key from the Authenticator, or
+if absent, the session key from the ticket-granting ticket used in the
+request. In that case, no version number will be present in the
+EncryptedData sequence.
+
+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,
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
+              crealm[3]                  Realm,
+              cname[4]                   PrincipalName,
+              ticket[5]                  Ticket,
+              enc-part[6]                EncryptedData
+}
+
+EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
+EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
+
+EncKDCRepPart ::=   SEQUENCE {
+                    key[0]               EncryptionKey,
+                    last-req[1]          LastReq,
+                    nonce[2]             INTEGER,
+                    key-expiration[3]    KerberosTime OPTIONAL,
+                    flags[4]             TicketFlags,
+                    authtime[5]          KerberosTime,
+                    starttime[6]         KerberosTime OPTIONAL,
+                    endtime[7]           KerberosTime,
+                    renew-till[8]        KerberosTime OPTIONAL,
+                    srealm[9]            Realm,
+                    sname[10]            PrincipalName,
+                    caddr[11]            HostAddresses OPTIONAL
+}
+
+pvno and msg-type
+     These fields are described above in section 5.4.1. msg-type is either
+     KRB_AS_REP or KRB_TGS_REP.
+padata
+     This field is described in detail in section 5.4.1. One possible use
+     for this field is to encode an alternate "mix-in" string to be used
+     with a string-to-key algorithm (such as is described in section
+     6.3.2). This ability is useful to ease transitions if a realm name
+     needs to change (e.g. when a company is acquired); in such a case all
+     existing password-derived entries in the KDC database would be flagged
+     as needing a special mix-in string until the next password change.
+crealm, cname, srealm and sname
+     These fields are the same as those described for the ticket in section
+     5.3.1.
+ticket
+     The newly-issued ticket, from section 5.3.1.
+enc-part
+     This field is a place holder for the ciphertext and related
+     information that forms the encrypted part of a message. The
+     description of the encrypted part of the message follows each
+     appearance of this field. The encrypted part is encoded as described
+     in section 6.1.
+key
+     This field is the same as described for the ticket in section 5.3.1.
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     systems.
+nonce
+     This field is described above in section 5.4.1.
+key-expiration
+     The key-expiration field is part of the response from the KDC and
+     specifies the time that the client's secret key is due to expire. The
+     expiration might be the result of password aging or an account
+     expiration. This field will usually be left out of the TGS reply since
+     the response to the TGS request is encrypted in a session key and no
+     client information need be retrieved from the KDC database. It is up
+     to the application client (usually the login program) to take
+     appropriate action (such as notifying the user) if the expiration time
+     is imminent.
+flags, authtime, starttime, endtime, renew-till and caddr
+     These fields are duplicates of those found in the encrypted portion of
+     the attached ticket (see section 5.3.1), provided so the client may
+     verify they match the intended request and to assist in proper ticket
+     caching. If the message is of type KRB_TGS_REP, the caddr field will
+     only be filled in if the request was for a proxy or forwarded ticket,
+     or if the user is substituting a subset of the addresses from the
+     ticket granting ticket. If the client-requested addresses are not
+     present or not used, then the addresses contained in the ticket will
+     be the same as those included in the ticket-granting ticket.
+
+5.5. Client/Server (CS) message specifications
+
+This section specifies the format of the messages used for the
+authentication of the client to the application server.
+
+5.5.1. KRB_AP_REQ definition
+
+The KRB_AP_REQ message contains the Kerberos protocol version number, the
+message type KRB_AP_REQ, an options field to indicate any options in use,
+and the ticket and authenticator themselves. The KRB_AP_REQ message is
+often referred to as the 'authentication header'.
+
+AP-REQ ::=      [APPLICATION 14] SEQUENCE {
+                pvno[0]                       INTEGER,
+                msg-type[1]                   INTEGER,
+                ap-options[2]                 APOptions,
+                ticket[3]                     Ticket,
+                authenticator[4]              EncryptedData
+}
+
+APOptions ::=   BIT STRING {
+                reserved(0),
+                use-session-key(1),
+                mutual-required(2)
+}
+
+
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     unselected options and reserved fields being reset (0). The encoding
+     of the bits is specified in section 5.2. The meanings of the options
+     are:
+
+          Bit(s)   Name              Description
+
+          0        RESERVED
+                                     Reserved for future  expansion  of
+this
+                                     field.
+
+          1        USE-SESSION-KEY
+                                     The  USE-SESSION-KEY  option
+indicates
+                                     that the ticket the client is
+presenting
+                                     to a server is encrypted in the
+session
+                                     key  from  the  server's
+ticket-granting
+                                     ticket.  When this option is not
+speci-
+                                     fied,  the  ticket  is  encrypted in
+the
+                                     server's secret key.
+
+          2        MUTUAL-REQUIRED
+                                     The  MUTUAL-REQUIRED  option  tells
+the
+                                     server  that  the client requires
+mutual
+                                     authentication, and that it must
+respond
+                                     with a KRB_AP_REP message.
+
+          3-31     RESERVED
+                                     Reserved for future use.
+
+ticket
+     This field is a ticket authenticating the client to the server.
+authenticator
+     This contains the authenticator, which includes the client's choice of
+     a subkey. Its encoding is described in section 5.3.2.
+
+5.5.2. KRB_AP_REP definition
+
+The KRB_AP_REP message contains the Kerberos protocol version number, the
+message type, and an encrypted time- stamp. The message is sent in in
+response to an application request (KRB_AP_REQ) where the mutual
+authentication option has been selected in the ap-options field.
+
+AP-REP ::=         [APPLICATION 15] SEQUENCE {
+                   pvno[0]                           INTEGER,
+                   msg-type[1]                       INTEGER,
+                   enc-part[2]                       EncryptedData
+}
+
+EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
+                   ctime[0]                          KerberosTime,
+                   cusec[1]                          INTEGER,
+                   subkey[2]                         EncryptionKey OPTIONAL,
+                   seq-number[3]                     INTEGER OPTIONAL
+}
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_AP_REP.
+enc-part
+     This field is described above in section 5.4.2.
+ctime
+     This field contains the current time on the client's host.
+cusec
+     This field contains the microsecond part of the client's timestamp.
+subkey
+     This field contains an encryption key which is to be used to protect
+     this specific application session. See section 3.2.6 for specifics on
+     how this field is used to negotiate a key. Unless an application
+     specifies otherwise, if this field is left out, the sub-session key
+     from the authenticator, or if also left out, the session key from the
+     ticket will be used.
+
+5.5.3. Error message reply
+
+If an error occurs while processing the application request, the KRB_ERROR
+message will be sent in response. See section 5.9.1 for the format of the
+error message. The cname and crealm fields may be left out if the server
+cannot determine their appropriate values from the corresponding KRB_AP_REQ
+message. If the authenticator was decipherable, the ctime and cusec fields
+will contain the values from it.
+
+5.6. KRB_SAFE message specification
+
+This section specifies the format of a message that can be used by either
+side (client or server) of an application to send a tamper-proof message to
+its peer. It presumes that a session key has previously been exchanged (for
+example, by using the KRB_AP_REQ/KRB_AP_REP messages).
+
+5.6.1. KRB_SAFE definition
+
+The KRB_SAFE message contains user data along with a collision-proof
+checksum keyed with the last encryption key negotiated via subkeys, or the
+session key if no negotiation has occured. The message fields are:
+
+KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
+                    pvno[0]                       INTEGER,
+                    msg-type[1]                   INTEGER,
+                    safe-body[2]                  KRB-SAFE-BODY,
+                    cksum[3]                      Checksum
+}
+
+KRB-SAFE-BODY ::=   SEQUENCE {
+                    user-data[0]                  OCTET STRING,
+                    timestamp[1]                  KerberosTime OPTIONAL,
+                    usec[2]                       INTEGER OPTIONAL,
+                    seq-number[3]                 INTEGER OPTIONAL,
+                    s-address[4]                  HostAddress OPTIONAL,
+                    r-address[5]                  HostAddress OPTIONAL
+}
+
+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.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     These fields are described above in section 5.4.1. msg-type is
+     KRB_PRIV.
+enc-part
+     This field holds an encoding of the EncKrbPrivPart sequence encrypted
+     under the session key[32]. This encrypted encoding is used for the
+     enc-part field of the KRB-PRIV message. See section 6 for the format
+     of the ciphertext.
+user-data, timestamp, usec, s-address and r-address
+     These fields are described above in section 5.6.1.
+seq-number
+     This field is described above in section 5.3.2.
+
+5.8. KRB_CRED message specification
+
+This section specifies the format of a message that can be used to send
+Kerberos credentials from one principal to another. It is presented here to
+encourage a common mechanism to be used by applications when forwarding
+tickets or providing proxies to subordinate servers. It presumes that a
+session key has already been exchanged perhaps by using the
+KRB_AP_REQ/KRB_AP_REP messages.
+
+5.8.1. KRB_CRED definition
+
+The KRB_CRED message contains a sequence of tickets to be sent and
+information needed to use the tickets, including the session key from each.
+The information needed to use the tickets is encrypted under an encryption
+key previously exchanged or transferred alongside the KRB_CRED message. The
+message fields are:
+
+KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
+                 pvno[0]                INTEGER,
+                 msg-type[1]            INTEGER, -- KRB_CRED
+                 tickets[2]             SEQUENCE OF Ticket,
+                 enc-part[3]            EncryptedData
+}
+
+EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
+                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
+                 nonce[1]               INTEGER OPTIONAL,
+                 timestamp[2]           KerberosTime OPTIONAL,
+                 usec[3]                INTEGER OPTIONAL,
+                 s-address[4]           HostAddress OPTIONAL,
+                 r-address[5]           HostAddress OPTIONAL
+}
+
+KrbCredInfo      ::=                    SEQUENCE {
+                 key[0]                 EncryptionKey,
+                 prealm[1]              Realm OPTIONAL,
+                 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
+}
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+
+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 not protected by any encryption,
+it is quite possible for an intruder to synthesize or modify such a
+message. In particular, this means that 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: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+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,
+                e-typed-data[14]              SEQUENCE of ETypedData
+OPTIONAL
+}
+
+ETypedData ::=  SEQUENCE {
+                e-data-type    [1] INTEGER,
+                e-data-value   [2] OCTET STRING,
+}
+
+
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     application to help it recover from or handle the error. If the
+     errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
+     contain an encoding of a sequence of padata fields, each corresponding
+     to an acceptable pre-authentication method and optionally containing
+     data for the method:
+
+     METHOD-DATA ::=   SEQUENCE of PA-DATA
+
+     If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
+     contain an encoding of the following sequence:
+
+     METHOD-DATA ::=   SEQUENCE {
+                         method-type[0]   INTEGER,
+                         method-data[1]   OCTET STRING OPTIONAL
+     }
+
+     method-type will indicate the required alternate method; method-data
+     will contain any required additional information.
+e-cksum
+     This field contains an optional checksum for the KRB-ERROR message.
+     The checksum is calculated over the Kerberos ASN.1 encoding of the
+     KRB-ERROR message with the checksum absent. The checksum is then added
+     to the KRB-ERROR structure and the message is re-encoded. The Checksum
+     should be calculated using the session key from the ticket granting
+     ticket or service ticket, where available. If the error is in response
+     to a TGS or AP request, the checksum should be calculated uing the the
+     session key from the client's ticket. If the error is in response to
+     an AS request, then the checksum should be calulated using the
+     client's secret key ONLY if there has been suitable preauthentication
+     to prove knowledge of the secret key by the client[33]. If a checksum
+     can not be computed because the key to be used is not available, no
+     checksum will be included.
+e-typed-data
+     [This field for discussion, may be deleted from final spec] This field
+     contains optional data that may be used to help the client recover
+     from the indicated error. [This could contain the METHOD-DATA
+     specified since I don't think anyone actually uses it yet. It could
+     also contain the PA-DATA sequence for the preauth required error if we
+     had a clear way to transition to the use of this field from the use of
+     the untype e-data field.] For example, this field may specify the key
+     version of the key used to verify preauthentication:
+
+     e-data-type  := 20 -- Key version number
+     e-data-value := Integer -- Key version number used to verify
+preauthentication
+
+6. Encryption and Checksum Specifications
+
+The Kerberos protocols described in this document are designed to use
+stream encryption ciphers, which can be simulated using commonly available
+block encryption ciphers, such as the Data Encryption Standard, [DES77] in
+conjunction with block chaining and checksum methods [DESM80]. Encryption
+is used to prove the identities of the network entities participating in
+message exchanges. The Key Distribution Center for each realm is trusted by
+all principals registered in that realm to store a secret key in
+confidence. Proof of knowledge of this secret key is used to verify the
+authenticity of a principal.
+
+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;
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+the ability to obtain the secret key or session key implies the knowledge
+of the appropriate keys and the identity of the KDC. The ability of a
+principal to decrypt the KDC response and present a Ticket and a properly
+formed Authenticator (generated with the session key from the KDC response)
+to a service verifies the identity of the principal; likewise the ability
+of the service to extract the session key from the Ticket and prove its
+knowledge thereof in a response verifies the identity of the service.
+
+The Kerberos protocols generally assume that the encryption used is secure
+from cryptanalysis; however, in some cases, the order of fields in the
+encrypted portions of messages are arranged to minimize the effects of
+poorly chosen keys. It is still important to choose good keys. If keys are
+derived from user-typed passwords, those passwords need to be well chosen
+to make brute force attacks more difficult. Poorly chosen keys still make
+easy targets for intruders.
+
+The following sections specify the encryption and checksum mechanisms
+currently defined for Kerberos. The encodings, chaining, and padding
+requirements for each are described. For encryption methods, it is often
+desirable to place random information (often referred to as a confounder)
+at the start of the message. The requirements for a confounder are
+specified with each encryption mechanism.
+
+Some encryption systems use a block-chaining method to improve the the
+security characteristics of the ciphertext. However, these chaining methods
+often don't provide an integrity check upon decryption. Such systems (such
+as DES in CBC mode) must be augmented with a checksum of the plain-text
+which can be verified at decryption and used to detect any tampering or
+damage. Such checksums should be good at detecting burst errors in the
+input. If any damage is detected, the decryption routine is expected to
+return an error indicating the failure of an integrity check. Each
+encryption type is expected to provide and verify an appropriate checksum.
+The specification of each encryption method sets out its checksum
+requirements.
+
+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 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+}
+
+
+
+etype
+     This field identifies which encryption algorithm was used to encipher
+     the cipher. Detailed specifications for selected encryption types
+     appear later in this section.
+kvno
+     This field contains the version number of the key under which data is
+     encrypted. It is only present in messages encrypted under long lasting
+     keys, such as principals' secret keys.
+cipher
+     This field contains the enciphered text, encoded as an OCTET STRING.
+
+The cipher field is generated by applying the specified encryption
+algorithm to data composed of the message and algorithm-specific inputs.
+Encryption mechanisms defined for use with Kerberos must take sufficient
+measures to guarantee the integrity of the plaintext, and we recommend they
+also take measures to protect against precomputed dictionary attacks. If
+the encryption algorithm is not itself capable of doing so, the protections
+can often be enhanced by adding a checksum and a confounder.
+
+The suggested format for the data to be encrypted includes a confounder, a
+checksum, the encoded plaintext, and any necessary padding. The msg-seq
+field contains the part of the protocol message described in section 5
+which is to be encrypted. The confounder, checksum, and padding are all
+untagged and untyped, and their length is exactly sufficient to hold the
+appropriate item. The type and length is implicit and specified by the
+particular encryption type being used (etype). The format for the data to
+be encrypted is described in the following diagram:
+
+      +-----------+----------+-------------+-----+
+      |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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+specification of an encryption type defines any checksum that is needed as
+part of the encryption process. If an alternative checksum is to be used, a
+new encryption type must be defined.
+
+Some cryptosystems require additional information beyond the key and the
+data to be encrypted. For example, DES, when used in cipher-block-chaining
+mode, requires an initialization vector. If required, the description for
+each encryption type must specify the source of such additional
+information. 6.2. Encryption Keys
+
+The sequence below shows the encoding of an encryption key:
+
+       EncryptionKey ::=   SEQUENCE {
+                           keytype[0]    INTEGER,
+                           keyvalue[1]   OCTET STRING
+       }
+
+keytype
+     This field specifies the type of encryption key that follows in the
+     keyvalue field. It will almost always correspond to the encryption
+     algorithm used to generate the EncryptedData, though more than one
+     algorithm may use the same type of key (the mapping is many to one).
+     This might happen, for example, if the encryption algorithm uses an
+     alternate checksum algorithm for an integrity check, or a different
+     chaining mechanism.
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
+
+6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
+
+The des-cbc-md4 encryption mode encrypts information under the Data
+Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
+An MD4 checksum (described in [MD492]) is applied to the confounder and
+message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
+bytes. As a result, the data to be encrypted (the concatenation of
+confounder, checksum, and message) must be padded to an 8 byte boundary
+before encryption. The details of the encryption of this data are identical
+to those for the des-cbc-md5 encryption mode.
+
+6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
+
+The des-cbc-md5 encryption mode encrypts information under the Data
+Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
+An MD5 checksum (described in [MD5-92].) is applied to the confounder and
+message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
+bytes. As a result, the data to be encrypted (the concatenation of
+confounder, checksum, and message) must be padded to an 8 byte boundary
+before encryption.
+
+Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
+concatenated to make the 64-bit inputs for the DES algorithms. The first
+octet supplies the 8 most significant bits (with the octet's MSbit used as
+the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
+and the eighth octet supplies the 8 least significant bits.
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+eXclusive-ORing a block, every byte is shifted one bit to the left to leave
+the lowest bit zero. The key is the "corrected" by correcting the parity on
+the key, and if the key matches a 'weak' or 'semi-weak' key as described in
+the DES specification, it is eXclusive-ORed with the constant
+00000000000000F0. This key is then used to generate a DES CBC checksum on
+the initial string (with the salt appended). The result of the CBC checksum
+is the "corrected" as described above to form the result which is return as
+the key. Pseudocode follows:
+
+     name_to_default_salt(realm, name) {
+          s = realm
+          for(each component in name) {
+               s = s + component;
+          }
+          return s;
+     }
+
+     key_correction(key) {
+          fixparity(key);
+          if (is_weak_key_key(key))
+               key = key XOR 0xF0;
+          return(key);
+     }
+
+     string_to_key(string,salt) {
+
+          odd = 1;
+          s = string + salt;
+          tempkey = NULL;
+          pad(s); /* with nulls to 8 byte boundary */
+          for(8byteblock in s) {
+               if(odd == 0)  {
+                   odd = 1;
+                   reverse(8byteblock)
+               }
+               else odd = 0;
+               left shift every byte in 8byteblock one bit;
+               tempkey = tempkey XOR 8byteblock;
+          }
+          tempkey = key_correction(tempkey);
+          key = key_correction(DES-CBC-check(s,tempkey));
+          return(key);
+     }
+
+6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key
+Derivation [Horowitz]
+
+NOTE: This description currently refers to documents, the contents of which
+might be bettered included by value in this spec. The description below was
+provided by Marc Horowitz, and the form in which it will finally appear is
+yet to be determined. This description is included in this version of the
+draft because it does describe the implemenation ready for use with the MIT
+implementation. Note also that the encryption identifier has been left
+unspecified here because the value from Marc Horowitz's spec conflicted
+with some other impmenentations implemented based on perevious versions of
+the specification.
+
+This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1
+[Krawczyk96] message authentication algorithm, and key derivation for
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+Kerberos V5 [HorowitzB96].
+
+The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The
+hmac-sha1-des3 checksum type has been assigned the value 12.
+
+Encryption Type des3-cbc-hmac-sha1
+
+EncryptedData using this type must be generated as described in
+[Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The
+keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV
+must be used. If the length of the input data is not a multiple of the
+block size, zero octets must be used to pad the plaintext to the next
+eight-octet boundary. The counfounder must be eight random octets (one
+block).
+
+Checksum Type hmac-sha1-des3
+
+Checksums using this type must be generated as described in [Horowitz96].
+The keyed hash algorithm is HMAC-SHA1.
+
+Common Requirements
+
+The EncryptionKey value is 24 octets long. The 7 most significant bits of
+each octet contain key bits, and the least significant bit is the inverse
+of the xor of the key bits.
+
+For the purposes of key derivation, the block size is 64 bits, and the key
+size is 168 bits. The 168 bits output by key derivation are converted to an
+EncryptionKey value as follows. First, the 168 bits are divided into three
+groups of 56 bits, which are expanded individually into 64 bits as follows:
+
+ 1  2  3  4  5  6  7  p
+ 9 10 11 12 13 14 15  p
+17 18 19 20 21 22 23  p
+25 26 27 28 29 30 31  p
+33 34 35 36 37 38 39  p
+41 42 43 44 45 46 47  p
+49 50 51 52 53 54 55  p
+56 48 40 32 24 16  8  p
+
+The "p" bits are parity bits computed over the data bits. The output of the
+three expansions are concatenated to form the EncryptionKey value.
+
+When the HMAC-SHA1 of a string is computed, the key is used in the
+EncryptedKey form.
+
+Key Derivation
+
+In the Kerberos protocol, cryptographic keys are used in a number of
+places. In order to minimize the effect of compromising a key, it is
+desirable to use a different key for each of these places. Key derivation
+[Horowitz96] can be used to construct different keys for each operation
+from the keys transported on the network. For this to be possible, a small
+change to the specification is necessary.
+
+This section specifies a profile for the use of key derivation [Horowitz96]
+with Kerberos. For each place where a key is used, a ``key usage'' must is
+specified for that purpose. The key, key usage, and encryption/checksum
+type together describe the transformation from plaintext to ciphertext, or
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+plaintext to checksum.
+
+Key Usage Values
+
+This is a complete list of places keys are used in the kerberos protocol,
+with key usage values and RFC 1510 section numbers:
+
+ 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
+    client key (section 5.4.1)
+ 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
+    application session key), encrypted with the service key
+    (section 5.4.2)
+ 3. AS-REP encrypted part (includes tgs session key or application
+    session key), encrypted with the client key (section 5.4.2)
+ 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+    session key (section 5.4.1)
+ 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+    authenticator subkey (section 5.4.1)
+ 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
+    with the tgs session key (sections 5.3.2, 5.4.1)
+ 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
+    authenticator subkey), encrypted with the tgs session key
+    (section 5.3.2)
+ 8. TGS-REP encrypted part (includes application session key),
+    encrypted with the tgs session key (section 5.4.2)
+ 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 recommended for use as H.
+
+Key Derivation from Passwords
+
+The well-known constant for password key derivation must be the byte string
+{0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the
+ASCII encoding for the string "kerberos".
+
+6.4. Checksums
+
+The following is the ASN.1 definition used for a checksum:
+
+         Checksum ::=   SEQUENCE {
+                        cksumtype[0]   INTEGER,
+                        checksum[1]    OCTET STRING
+         }
+
+cksumtype
+     This field indicates the algorithm used to generate the accompanying
+     checksum.
+checksum
+     This field contains the checksum itself, encoded as an octet string.
+
+Detailed specification of selected checksum types appear later in this
+section. Negative values for the checksum type are reserved for local use.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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:
+
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+|  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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 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:
+
++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+|   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 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)
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+      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 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]
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+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 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+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:
+
+   * the Unspecified Address
+   * the Loopback Address
+   * Link-Local addresses
+
+IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
+
+CHAOSnet addresses
+
+CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
+The type of CHAOSnet addresses is five (5).
+
+ISO addresses
+
+ISO addresses are variable-length. The type of ISO addresses is seven (7).
+
+Xerox Network Services (XNS) addresses
+
+XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
+type of XNS addresses is six (6).
+
+AppleTalk Datagram Delivery Protocol (DDP) addresses
+
+AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
+network number. The first octet of the address is the node number; the
+remaining two octets encode the network number in MSB order. The type of
+AppleTalk DDP addresses is sixteen (16).
+
+DECnet Phase IV addresses
+
+DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
+type of DECnet Phase IV addresses is twelve (12).
+
+Netbios addresses
+
+Netbios addresses are 16-octet addresses typically composed of 1 to 15
+characters, trailing blank (ascii char 20) filled, with a 16th octet of
+0x0. The type of Netbios addresses is 20 (0x14).
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+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 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 1
+bit).
+
+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:
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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
+        4
+des3-cbc-md5      5            8                 0                 8
+        6
+des3-cbc-sha1     7            8                 0                 8
+sign-dsa-generate 8                                   (pkinit)
+encrypt-rsa-priv  9                                   (pkinit)
+encrypt-rsa-pub  10                                   (pkinit)
+rsa-pub-md5      11                                   (pkinit)
+rsa-pub-sha1     12                                   (pkinit)
+des3kd-cbc-sha1  ??            8                 0                 8
+ENCTYPE_PK_CROSS 48                                   (reserved for pkcross)
+       0x8003
+
+Checksum type              sumtype value       checksum size
+CRC32                      1                   4
+rsa-md4                    2                   16
+rsa-md4-des                3                   24
+des-mac                    4                   16
+des-mac-k                  5                   8
+rsa-md4-des-k              6                   16
+rsa-md5                    7                   16
+rsa-md5-des                8                   24
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+rsa-md5-des3               9                   24
+hmac-sha1-des3             12                  20  (I had this as 10, is it
+12)
+
+padata type                     padata-type value
+
+PA-TGS-REQ                      1
+PA-ENC-TIMESTAMP                2
+PA-PW-SALT                      3
+                      4
+PA-ENC-UNIX-TIME                5
+PA-SANDIA-SECUREID              6
+PA-SESAME                       7
+PA-OSF-DCE                      8
+PA-CYBERSAFE-SECUREID           9
+PA-AFS3-SALT                    10
+PA-ETYPE-INFO                   11
+SAM-CHALLENGE                   12                  (sam/otp)
+SAM-RESPONSE                    13                  (sam/otp)
+PA-PK-AS-REQ                    14                  (pkinit)
+PA-PK-AS-REP                    15                  (pkinit)
+PA-PK-AS-SIGN                   16                  (pkinit)
+PA-PK-KEY-REQ                   17                  (pkinit)
+PA-PK-KEY-REP                   18                  (pkinit)
+PA-USE-SPECIFIED-KVNO           20
+
+authorization data type         ad-type value
+AD-KDC-ISSUED                      1
+AD-INTENDED-FOR-SERVER             2
+AD-INTENDED-FOR-APPLICATION-CLASS  3
+AD-IF-RELEVANT                     4
+AD-OR                              5
+AD-MANDATORY-TICKET-EXTENSIONS     6
+AD-IN-TICKET-EXTENSIONS            7
+reserved values                    8-63
+OSF-DCE                            64
+SESAME                             65
+
+Ticket Extension Types
+
+TE-TYPE-NULL                  0      Null ticket extension
+TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
+                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
+TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
+TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
+                    5      TE-TYPE-DEST-HOST (I have reservations)
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+KRB_AS_REQ             10   Request for initial authentication
+KRB_AS_REP             11   Response to KRB_AS_REQ request
+KRB_TGS_REQ            12   Request for authentication based on TGT
+KRB_TGS_REP            13   Response to KRB_TGS_REQ request
+KRB_AP_REQ             14   application request to server
+KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
+KRB_SAFE               20   Safe (checksummed) application message
+KRB_PRIV               21   Private (encrypted) application message
+KRB_CRED               22   Private (encrypted) message to forward
+credentials
+KRB_ERROR              30   Error response
+
+name types
+
+KRB_NT_UNKNOWN        0  Name type not known
+KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for
+users
+KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
+KRB_NT_SRV_HST        3  Service with host name as instance (telnet,
+rcommands)
+KRB_NT_SRV_XHST       4  Service with host as remaining components
+KRB_NT_UID            5  Unique ID
+KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
+
+error codes
+
+KDC_ERR_NONE                    0   No error
+KDC_ERR_NAME_EXP                1   Client's entry in database has expired
+KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
+KDC_ERR_BAD_PVNO                3   Requested protocol version 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
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+KRB_AP_ERR_SKEW                37   Clock skew too great
+KRB_AP_ERR_BADADDR             38   Incorrect net address
+KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
+KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
+KRB_AP_ERR_MODIFIED            41   Message stream modified
+KRB_AP_ERR_BADORDER            42   Message out of order
+KRB_AP_ERR_BADKEYVER           44   Specified version of key is not
+available
+KRB_AP_ERR_NOKEY               45   Service key not available
+KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
+KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
+KRB_AP_ERR_METHOD              48   Alternative authentication method
+required
+KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
+KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in
+message
+KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
+KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
+KRB_ERR_GENERIC                60   Generic error (description in e-text)
+KRB_ERR_FIELD_TOOLONG          61   Field is too long for this
+implementation
+KDC_ERROR_CLIENT_NOT_TRUSTED   62   (pkinit)
+KDC_ERROR_KDC_NOT_TRUSTED      63   (pkinit)
+KDC_ERROR_INVALID_SIG          64   (pkinit)
+KDC_ERR_KEY_TOO_WEAK           65   (pkinit)
+KDC_ERR_CERTIFICATE_MISMATCH   66   (pkinit)
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+also support them: This list is to be determined.
+
+Encryption: DES-CBC-MD5
+Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
+
+Realm Names
+
+All implementations must understand hierarchical realms in both the
+Internet Domain and the X.500 style. When a ticket granting ticket for an
+unknown realm is requested, the KDC must be able to determine the names of
+the intermediate realms between the KDCs realm and the requested realm.
+
+Transited field encoding
+
+DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
+Alternative encodings may be supported, but they may be used only when that
+encoding is supported by ALL intermediate realms.
+
+Pre-authentication methods
+
+The TGS-REQ method must be supported. The TGS-REQ method is not used on the
+initial request. The PA-ENC-TIMESTAMP method must be supported by clients
+but whether it is enabled by default may be determined on a realm by realm
+basis. If not used in the initial request and the error
+KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
+acceptable method, the client should retry the initial request using the
+PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
+PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
+presence of PA-ENC-TIMESTAMP pre-authentication in a request.
+
+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.
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+Authorization data
+
+Implementations must pass all authorization data subfields from
+ticket-granting tickets to any derivative tickets unless directed to
+suppress a subfield as part of the definition of that registered subfield
+type (it is never incorrect to pass on a subfield, and no registered
+subfield types presently specify suppression at the KDC).
+
+Implementations must make the contents of any authorization data subfields
+available to the server when a ticket is used. Implementations are not
+required to allow clients to specify the contents of the authorization data
+fields.
+
+Constant ranges
+
+All protocol constants are constrained to 32 bit (signed) values unless
+further constrained by the protocol definition. This limit is provided to
+allow implementations to make assumptions about the maximum values that
+will be received for these constants. Implementation receiving values
+outside this range may reject the request, but they must recover cleanly.
+
+9.2. Recommended KDC values
+
+Following is a list of recommended values for a KDC implementation, based
+on the list of suggested configuration constants (see section 4.4).
+
+minimum lifetime              5 minutes
+maximum renewable lifetime    1 week
+maximum ticket lifetime       1 day
+empty addresses               only when suitable  restrictions  appear
+                              in authorization data
+proxiable, etc.               Allowed.
+
+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,
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+          "The Evolution of the Kerberos Authentication Service,"
+          in an IEEE Computer Society Text soon to  be  published
+          (June 1992).
+
+[Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
+          Accounting  for Distributed Systems," in Proceedings of
+          the 13th International Conference on  Distributed  Com-
+          puting Systems, Pittsburgh, PA (May, 1993).
+
+[DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
+          Kerberos  Authentication  at Project Athena," Technical
+          Memorandum TM-424,  MIT Laboratory for Computer Science
+          (February 1990).
+
+[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
+          merfeld,  and  K. Raeburn, Section E.1: Service Manage-
+          ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
+          sachusetts (1987).
+
+[X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
+          tion Framework, December 1988.
+
+[Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
+          Guessing  Attacks, Open Software Foundation DCE Request
+          for Comments 26 (December 1992).
+
+[DES77]   National Bureau of Standards, U.S. Department  of  Com-
+          merce,  "Data Encryption Standard," Federal Information
+          Processing Standards Publication  46,   Washington,  DC
+          (1977).
+
+[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,
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+          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.
+
+A.1. KRB_AS_REQ generation
+
+        request.pvno := protocol version; /* pvno = 5 */
+        request.msg-type := message type; /* type = KRB_AS_REQ */
+
+        if(pa_enc_timestamp_required) then
+                request.padata.padata-type = PA-ENC-TIMESTAMP;
+                get system_time;
+                padata-body.patimestamp,pausec = system_time;
+                encrypt padata-body into request.padata.padata-value
+                        using client.key; /* derived from password */
+        endif
+
+        body.kdc-options := users's preferences;
+        body.cname := user's name;
+        body.realm := user's realm;
+        body.sname := service's name; /* usually "krbtgt",  "localrealm" */
+        if (body.kdc-options.POSTDATED is set) then
+                body.from := requested starting time;
+        else
+                omit body.from;
+        endif
+        body.till := requested end time;
+        if (body.kdc-options.RENEWABLE is set) then
+                body.rtime := requested final renewal time;
+        endif
+        body.nonce := random_nonce();
+        body.etype := requested etypes;
+        if (user supplied addresses) then
+                body.addresses := user's addresses;
+        else
+                omit body.addresses;
+        endif
+        omit body.enc-authorization-data;
+        request.req-body := body;
+
+        kerberos := lookup(name of local kerberos server (or servers));
+        send(packet,kerberos);
+
+        wait(for response);
+        if (timed_out) then
+                retry or use alternate server;
+        endif
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+A.2. KRB_AS_REQ verification and KRB_AS_REP generation
+
+        decode message into req;
+
+        client := lookup(req.cname,req.realm);
+        server := lookup(req.sname,req.realm);
+
+        get system_time;
+        kdc_time := system_time.seconds;
+
+        if (!client) then
+                /* no client in Database */
+                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
+        endif
+        if (!server) then
+                /* no server in Database */
+                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
+        endif
+
+        if(client.pa_enc_timestamp_required and
+           pa_enc_timestamp not present) then
+                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
+        endif
+
+        if(pa_enc_timestamp present) then
+                decrypt req.padata-value into decrypted_enc_timestamp
+                        using client.key;
+                        using auth_hdr.authenticator.subkey;
+                if (decrypt_error()) then
+                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
+                if(decrypted_enc_timestamp is not within allowable skew)
+then
+                        error_out(KDC_ERR_PREAUTH_FAILED);
+                endif
+                if(decrypted_enc_timestamp and usec is replay)
+                        error_out(KDC_ERR_PREAUTH_FAILED);
+                endif
+                add decrypted_enc_timestamp and usec to replay cache;
+        endif
+
+        use_etype := first supported etype in req.etypes;
+
+        if (no support for req.etypes) then
+                error_out(KDC_ERR_ETYPE_NOSUPP);
+        endif
+
+        new_tkt.vno := ticket version; /* = 5 */
+        new_tkt.sname := req.sname;
+        new_tkt.srealm := req.srealm;
+        reset all flags in new_tkt.flags;
+
+        /* It should be noted that local policy may affect the  */
+        /* processing of any of these flags.  For example, some */
+        /* realms may refuse to issue renewable tickets         */
+
+        if (req.kdc-options.FORWARDABLE is set) then
+                set new_tkt.flags.FORWARDABLE;
+        endif
+        if (req.kdc-options.PROXIABLE is set) then
+                set new_tkt.flags.PROXIABLE;
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+        endif
+
+        if (req.kdc-options.ALLOW-POSTDATE is set) then
+                set new_tkt.flags.MAY-POSTDATE;
+        endif
+        if ((req.kdc-options.RENEW is set) or
+            (req.kdc-options.VALIDATE is set) or
+            (req.kdc-options.PROXY is set) or
+            (req.kdc-options.FORWARDED is set) or
+            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
+                error_out(KDC_ERR_BADOPTION);
+        endif
+
+        new_tkt.session := random_session_key();
+        new_tkt.cname := req.cname;
+        new_tkt.crealm := req.crealm;
+        new_tkt.transited := empty_transited_field();
+
+        new_tkt.authtime := kdc_time;
+
+        if (req.kdc-options.POSTDATED is set) then
+           if (against_postdate_policy(req.from)) then
+                error_out(KDC_ERR_POLICY);
+           endif
+           set new_tkt.flags.POSTDATED;
+           set new_tkt.flags.INVALID;
+           new_tkt.starttime := req.from;
+        else
+           omit new_tkt.starttime; /* treated as authtime when omitted */
+        endif
+        if (req.till = 0) then
+                till := infinity;
+        else
+                till := req.till;
+        endif
+
+        new_tkt.endtime := min(till,
+                              new_tkt.starttime+client.max_life,
+                              new_tkt.starttime+server.max_life,
+                              new_tkt.starttime+max_life_for_realm);
+
+        if ((req.kdc-options.RENEWABLE-OK is set) and
+            (new_tkt.endtime < req.till)) then
+                /* we set the RENEWABLE option for later processing */
+                set req.kdc-options.RENEWABLE;
+                req.rtime := req.till;
+        endif
+
+        if (req.rtime = 0) then
+                rtime := infinity;
+        else
+                rtime := req.rtime;
+        endif
+
+        if (req.kdc-options.RENEWABLE is set) then
+                set new_tkt.flags.RENEWABLE;
+                new_tkt.renew-till := min(rtime,
+
+new_tkt.starttime+client.max_rlife,
+
+new_tkt.starttime+server.max_rlife,
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+new_tkt.starttime+max_rlife_for_realm);
+        else
+                omit new_tkt.renew-till; /* only present if RENEWABLE */
+        endif
+
+        if (req.addresses) then
+                new_tkt.caddr := req.addresses;
+        else
+                omit new_tkt.caddr;
+        endif
+
+        new_tkt.authorization_data := empty_authorization_data();
+
+        encode to-be-encrypted part of ticket into OCTET STRING;
+        new_tkt.enc-part := encrypt OCTET STRING
+                using etype_for_key(server.key), server.key, server.p_kvno;
+
+        /* Start processing the response */
+
+        resp.pvno := 5;
+        resp.msg-type := KRB_AS_REP;
+        resp.cname := req.cname;
+        resp.crealm := req.realm;
+        resp.ticket := new_tkt;
+
+        resp.key := new_tkt.session;
+        resp.last-req := fetch_last_request_info(client);
+        resp.nonce := req.nonce;
+        resp.key-expiration := client.expiration;
+        resp.flags := new_tkt.flags;
+
+        resp.authtime := new_tkt.authtime;
+        resp.starttime := new_tkt.starttime;
+        resp.endtime := new_tkt.endtime;
+
+        if (new_tkt.flags.RENEWABLE) then
+                resp.renew-till := new_tkt.renew-till;
+        endif
+
+        resp.realm := new_tkt.realm;
+        resp.sname := new_tkt.sname;
+
+        resp.caddr := new_tkt.caddr;
+
+        encode body of reply into OCTET STRING;
+
+        resp.enc-part := encrypt OCTET STRING
+                         using use_etype, client.key, client.p_kvno;
+        send(resp);
+
+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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                process_error(resp);
+                return;
+        endif
+
+        /* On error, discard the response, and zero the session key */
+        /* from the response immediately */
+
+        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
+                                 resp.padata);
+        unencrypted part of resp := decode of decrypt of resp.enc-part
+                                using resp.enc-part.etype and key;
+        zero(key);
+
+        if (common_as_rep_tgs_rep_checks fail) then
+                destroy resp.key;
+                return error;
+        endif
+
+        if near(resp.princ_exp) then
+                print(warning message);
+        endif
+        save_for_later(ticket,session,client,server,times,flags);
+
+A.4. KRB_AS_REP and KRB_TGS_REP common checks
+
+        if (decryption_error() or
+            (req.cname != resp.cname) or
+            (req.realm != resp.crealm) or
+            (req.sname != resp.sname) or
+            (req.realm != resp.realm) or
+            (req.nonce != resp.nonce) or
+            (req.addresses != resp.caddr)) then
+                destroy resp.key;
+                return KRB_AP_ERR_MODIFIED;
+        endif
+
+        /* make sure no flags are set that shouldn't be, and that all that
+*/
+        /* should be are set
+*/
+        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
+                destroy resp.key;
+                return KRB_AP_ERR_MODIFIED;
+        endif
+
+        if ((req.from = 0) and
+            (resp.starttime is not within allowable skew)) then
+                destroy resp.key;
+                return KRB_AP_ERR_SKEW;
+        endif
+        if ((req.from != 0) and (req.from != resp.starttime)) then
+                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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                destroy resp.key;
+                return KRB_AP_ERR_MODIFIED;
+        endif
+        if ((req.kdc-options.RENEWABLE-OK is set) and
+            (resp.flags.RENEWABLE) and
+            (req.till != 0) and
+            (resp.renew-till > req.till)) then
+                destroy resp.key;
+                return KRB_AP_ERR_MODIFIED;
+        endif
+
+A.5. KRB_TGS_REQ generation
+
+        /* Note that make_application_request might have to recursivly
+*/
+        /* call this routine to get the appropriate ticket-granting ticket
+*/
+
+        request.pvno := protocol version; /* pvno = 5 */
+        request.msg-type := message type; /* type = KRB_TGS_REQ */
+
+        body.kdc-options := users's preferences;
+        /* If the TGT is not for the realm of the end-server  */
+        /* then the sname will be for a TGT for the end-realm */
+        /* and the realm of the requested ticket (body.realm) */
+        /* will be that of the TGS to which the TGT we are    */
+        /* sending applies                                    */
+        body.sname := service's name;
+        body.realm := service's realm;
+
+        if (body.kdc-options.POSTDATED is set) then
+                body.from := requested starting time;
+        else
+                omit body.from;
+        endif
+        body.till := requested end time;
+        if (body.kdc-options.RENEWABLE is set) then
+                body.rtime := requested final renewal time;
+        endif
+        body.nonce := random_nonce();
+        body.etype := requested etypes;
+        if (user supplied addresses) then
+                body.addresses := user's addresses;
+        else
+                omit body.addresses;
+        endif
+
+        body.enc-authorization-data := user-supplied data;
+        if (body.kdc-options.ENC-TKT-IN-SKEY) then
+                body.additional-tickets_ticket := second TGT;
+        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));
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+        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
+
+        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);
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                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);
+                endif
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                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: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                                       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,
+                 * or requested not to check */
+                if (is_not_foreign_tgt_name(new_tkt.server)
+                   && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                        /* 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,
+                        req.padata.authenticator.subkey;
+        else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
+
+        send(resp);
+
+A.7. KRB_TGS_REP verification
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+        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 */
+
+        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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+        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 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+                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;
+        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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+        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
+                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);
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+        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 */
+
+        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;
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+        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;
+                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;
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+        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
+           (packet.nonce != expected-nonce) then
+                error_out(KRB_AP_ERR_MODIFIED);
+        endif
+
+        for (ticket[n] in tickets that were forwarded) do
+                save_for_later(ticket[n],key[n],principal[n],
+                               server[n],times[n],flags[n]);
+        return
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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. 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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+     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.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]
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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. If relevant
+
+AD-IF-RELEVANT   AuthorizationData
+
+AD elements encapsulated within the if-relevant element are intended for
+interpretation only by application servers that understand the particular
+ad-type of the embedded element. Application servers that do not understand
+the type of an element embedded within the if-relevant element may ignore
+the uninterpretable element. This element promotes interoperability across
+implementations which may have local extensions for authorization.
+
+B.5. And-Or
+
+AD-AND-OR           SEQUENCE {
+                        condition-count[0]    INTEGER,
+                        elements[1]           AuthorizationData
+}
+
+When restrictive AD elements encapsulated within the and-or element are
+encountered, only the number specified in condition-count of the
+encapsulated conditions must be met in order to satisfy this element. This
+element may be used to implement an "or" operation by setting the
+condition-count field to 1, and it may specify an "and" operation by
+setting the condition count to the number of embedded elements. Application
+servers that do not implement this element must reject tickets that contain
+authorization data elements of this type.
+
+B.6. Mandatory ticket extensions
+
+AD-Mandatory-Ticket-Extensions   Checksum
+
+An authorization data element of type mandatory-ticket-extensions specifies
+a collision-proof checksum using the same hash algorithm used to protect
+the integrity of the ticket itself. This checksum will be calculated over
+an individual extension field. If there are more than one extension,
+multiple Mandatory-Ticket-Extensions authorization data elements may be
+present, each with a checksum for a different extension field. This
+restriction indicates that the ticket should not be accepted if a ticket
+extension is not present in the ticket for which the checksum does not
+match that checksum specified in the authorization data element.
+Application servers that do not implement this element must reject tickets
+that contain authorization data elements of this type.
+
+B.7. Authorization Data in ticket extensions
+
+AD-IN-Ticket-Extensions   Checksum
+
+An authorization data element of type in-ticket-extensions specifies a
+collision-proof checksum using the same hash algorithm used to protect the
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+  ------------------------------------------------------------------------
+[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.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+[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.
+
+[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
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+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.
+
+[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.
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
+
+INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
+
+
+
+[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.
+
+
+Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
new file mode 100644
index 00000000000..15921248c11
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
new file mode 100644
index 00000000000..ae79e8a7c4f
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
new file mode 100644
index 00000000000..6f7dae0dea7
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
new file mode 100644
index 00000000000..0319f8bf347
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt
new file mode 100644
index 00000000000..b15c8284d9d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt
@@ -0,0 +1,809 @@
+
+
+
+
+
+
+Network Working Group                                   Jonathan Trostle
+INTERNET-DRAFT                                             Cisco Systems
+Category: Standards Track                                     Mike Swift
+                                                        University of WA
+                                                             John Brezak
+                                                               Microsoft
+                                                            Bill Gossman
+                                                           Cisco Systems
+
+
+                Kerberos Set/Change Password: Version 2
+              <draft-ietf-cat-kerberos-set-passwd-06.txt>
+
+
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026 [6].
+
+   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 December 31st, 2001. Please send comments to
+   the authors.
+
+1. Abstract
+
+   This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
+   protocol and a Kerberos change/set key protocol. The protocol
+   consists of a single request and reply message. The request message
+   includes both AP-REQ and KRB-PRIV submessages; the new password is
+   contained in the KRB-PRIV submessage which is encrypted in the
+   subsession key from the AP-REQ. The original Kerberos change password
+   protocol did not allow for an administrator to set a password for a
+   new user. This functionality is useful in some environments, and this
+   proposal allows password setting as well as password changing. The
+   protocol includes fields in the request message to indicate the
+   principal which is having its password set. We also extend the
+   set/change protocol to allow a client to send a sequence of keys to
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 1]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+   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 RFC2119 [7].
+
+3. Definitions from RFC 1510
+
+   We include some of the relevant ASN.1 definitions from RFC 1510 in
+   this section.
+
+      Realm ::=           GeneralString
+
+      PrincipalName ::=   SEQUENCE {
+                          name-type[0]     INTEGER,
+                          name-string[1]   SEQUENCE OF GeneralString
+      }
+
+      KerberosTime ::=    GeneralizedTime
+                          -- Specifying UTC time zone (Z)
+
+      HostAddress ::=     SEQUENCE  {
+                          addr-type[0]             INTEGER,
+                          address[1]               OCTET STRING
+      }
+
+      EncryptedData ::=   SEQUENCE {
+                        etype[0]     INTEGER, -- EncryptionType
+                        kvno[1]      INTEGER OPTIONAL,
+                        cipher[2]    OCTET STRING -- ciphertext
+      }
+
+      EncryptionKey ::=   SEQUENCE {
+                          keytype[0]    INTEGER,
+                          keyvalue[1]   OCTET STRING
+      }
+
+      Checksum ::=        SEQUENCE {
+                          cksumtype[0]   INTEGER,
+                          checksum[1]    OCTET STRING
+      }
+
+
+      AP-REQ ::= [APPLICATION 14] SEQUENCE {
+              pvno [0]         INTEGER,        -- indicates Version 5
+              msg-type [1]     INTEGER,        -- indicates KRB_AP_REQ
+              ap-options[2]    APOptions,
+              ticket[3]        Ticket,
+              authenticator[4] EncryptedData
+      }
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 2]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+      APOptions ::= BIT STRING {
+
+              reserved (0),
+              use-session-key (1),
+              mutual-required (2)
+      }
+
+      Ticket ::= [APPLICATION 1] SEQUENCE {
+              tkt-vno [0]     INTEGER,        -- indicates Version 5
+              realm [1]       Realm,
+              sname [2]       PrincipalName,
+              enc-part [3]    EncryptedData
+      }
+
+
+      -- 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
+      }
+
+      -- 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
+      }
+
+      AP-REP ::= [APPLICATION 15] SEQUENCE {
+              pvno [0]        INTEGER,        -- represents Kerberos V5
+              msg-type [1]    INTEGER,        -- represents KRB_AP_REP
+              enc-part [2]    EncryptedData
+      }
+
+      EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
+              ctime [0]       KerberosTime,
+              cusec [1]       INTEGER,
+              subkey [2]      EncryptionKey OPTIONAL,
+              seq-number [3]  INTEGER OPTIONAL
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 3]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+      }
+
+   Here is the syntax of the KRB-ERROR message:
+
+      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
+      }
+
+   The KRB-PRIV message is used to send the request and reply data:
+
+      KRB-PRIV ::=     [APPLICATION 21] SEQUENCE {
+                   pvno[0]                   INTEGER,
+                   msg-type[1]               INTEGER,
+                   enc-part[3]               EncryptedData
+      }
+
+      EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
+                   user-data[0]              OCTET STRING,
+                   timestamp[1]              KerberosTime OPTIONAL,
+                   usec[2]                   INTEGER OPTIONAL,
+                   seq-number[3]             INTEGER OPTIONAL,
+                   s-address[4]              HostAddress,
+                                                        -- sender's addr
+                   r-address[5]              HostAddress OPTIONAL
+                                                        -- recip's addr
+      }
+
+
+4. The Protocol
+
+   The service SHOULD accept requests on UDP port 464 and TCP port 464
+   as well. Use of other ports can significantly increase the complexity
+   and size of IPSEC policy rulesets in organizations that have IPSEC
+   capable nodes.
+
+   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
+   that precedes the message and specifies the length of the message.
+   This requirement is consistent with the TCP transport header in
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 4]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+   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 authenticator in the
+   AP-REQ MUST contain a subsession key (which will be used to encrypt
+   the KRB-PRIV user data field - see below). The KDC may have stronger
+   pseudorandom generating capability then the clients; thus, the client
+   SHOULD use the session key as an input (along with additional locally
+   pseudorandom generated bits) into the generation of the subsession
+   key. 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
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 5]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+   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 encrypted
+   using the subsession key from the authenticator in the AP-REQ. The
+   authenticator MUST contain a subsession key. The timestamp and usec
+   fields of the KRB-PRIV message MUST be present, and the data values
+   MUST be copies of the same data values from the authenticator. The
+   recipient should ignore the sender address field in the KRB-PRIV
+   message.
+
+   The user-data component of the message contains the DER encoding of
+   the ChangePasswdData ASN.1 type described below:
+
+    ChangePasswdData ::=  SEQUENCE {
+                        passwds [0]          PasswordSequence OPTIONAL,
+                        keys [1]             KeySequences OPTIONAL,
+                          -- exactly one of the above two will be
+                          -- present, else KRB5_KPASSWD_MALFORMED
+                          -- error will be returned by the server.
+                        targname[2]          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[3]         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.
+                        flags[4]             RequestFlags OPTIONAL
+                          -- 32 bit string
+                        }
+
+    KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence
+
+    KeySequence ::= SEQUENCE {
+                     key[0]        EncryptionKey,
+                     salt[1]       OCTET STRING OPTIONAL,
+                           -- depends on enc type, not currently used
+                     salt-type[2]  INTEGER OPTIONAL
+                           -- depends on enc type, not currently used
+    }
+
+    PasswordSequence ::= SEQUENCE {
+                        newpasswd[0]  OCTET STRING,
+                        oldpasswd[1]  OCTET STRING OPTIONAL
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 6]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+                          -- oldpasswd always present for change
+                          -- password but not present for set
+                          -- password, set key, or change key
+                          -- NOTE: the passwords are UTF8 strings.
+    }
+
+    RequestFlags ::= BIT STRING (SIZE (32..MAX))
+                      -- reserved(0)
+                      -- request-srv-gen-keys(1)
+                           -- only in change/set keys
+                           -- if the client desires
+                           -- server to contribute to
+                           -- keys;
+                           -- server will return keys
+
+
+   The server must verify the AP-REQ message, check whether the client
+   principal in the ticket is authorized to set/change the password/keys
+   (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.
+
+   If the passwds field is present, it contains the new cleartext
+   password (with the old cleartext password for a change password
+   operation). Otherwise the keys field is present, and it contains a
+   sequence of encryption keys.
+
+   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.
+
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 7]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+   For change/set key, the request message may include the request flags
+   bit string with the request-srv-gen-keys bit set. In this case, the
+   client is requesting that the server add entropy to its keys in the
+   KeySequences field. When using this option, the client SHOULD attempt
+   to generate pseudorandom keys with as much entropy as possible in its
+   request. The server will return the final key sequence in a
+   KeySequences structure in the edata of the reply message. The server
+   does not store any of the new keys at this point. The client MUST
+   make a subsequent change/set key request without the request-srv-
+   gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
+   second request, then the new keys have been written into the
+   database. A conformant server MUST support this option.
+
+
+
+
+
+
+
+   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 the
+   original Kerberos change password protocol).
+
+   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. An implementation should check this field to
+   determine whether a KRB-ERROR message or KRB-PRIV message has been
+   returned.
+
+   AP-REP data: the AP-REP is the response to the AP-REQ in the request
+   packet. The subkey MUST be present in the AP-REP message.
+
+   KRB-PRIV message: This KRB-PRIV message must be encrypted using the
+   subkey from the AP-REP message. The client should ignore the sender
+   address (the server's address) in the KRB-PRIV message. Reflection
+   attacks are prevented since the subkey is used to encrypt the user-
+   data field of the KRB-PRIV message. The timestamp and usec fields of
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 8]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+   the KRB-PRIV message MUST be present, and the data values MUST be
+   copies of the same data values from the AP-REP message.
+
+   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.
+
+   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          | key version (only on success) |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     result string length      |         result string         /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                             edata                             /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       result code (16 bits) (result codes 0-4 are the same as in the
+       original Kerberos change password protocol):
+
+       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_INITIALFLAG_NEEDED 7 initial flag required
+
+
+
+
+Trostle, Swift, Brezak, Gossman                                 [Page 9]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+       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_WRONG_SRV          9 policy failure: the client
+                                         sent change/set key and
+                                         should have sent change/set
+                                         passwd, or vice-versa.
+
+       KRB5_KPASSWD_BAD_PRINCIPAL     10 target principal does not
+                                         exist (only in response to
+                                         a set password or set key
+                                         request).
+
+       KRB5_KPASSWD_ETYPE_NOSUPP 11 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
+                                    DER 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, client
+                                                    -- may ignore if
+                                                    -- 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.
+
+       KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph.
+
+
+       The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when
+       the request has the request-srv-gen-keys flag set and the
+       server is returning the KeySequences structure defined above in
+       the edata field of the reply. The server returns one key sequence
+       structure of the same keytype for each key sequence structure in
+       the client request, unless it does not support one of the
+       keytypes (or etypes). In that case, it returns error
+       KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST
+       add keylength number of bits of entropy to each key, where
+
+
+
+Trostle, Swift, Brezak, Gossman                                [Page 10]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+       keylength is the number of actual key bits in the key (minus
+       any parity or non-entropy contributing bits). The assumption
+       here is that the client may have added insufficient entropy
+       to the request keys. The server SHOULD use the client key from
+       each KeySequence structure as input into the final keyvalue for
+       the returned key. The client MUST make another request after
+       receiving a reply with this status, since no keys have been
+       written into the database.
+
+       0xFFFF is returned if the request fails for some other reason.
+       The client must interpret any non-zero result code as a failure.
+
+       key version (16 bits - optional):
+       Present if and only if the result
+       code is KRB5_KPASSWD_SUCCESS. This contains the key version of
+       the new key(s).
+
+       result string length (16 bits):
+       Gives the length of the following result string field, in bytes.
+       If the result string is not present, the length is zero.
+
+       result string (optional):
+       This field is a UTF-8 encoded string which can be displayed
+       to the user. Specific reasons for a password set/change policy
+       failure is one possible use for this string.
+
+       edata (optional):
+       Used to convey additional information as defined by the
+       result code.
+
+5.  Acknowledgements
+
+   The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
+   Andrea, Nicolas Williams, and other participants from the IETF
+   Kerberos Working Group for their input to the document.
+
+6.  Security Considerations
+
+   Password policies should be enforced to make sure that users do not
+   pick passwords (for change password/key) that are vulnerable to brute
+   force password guessing attacks.
+
+7.  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.
+
+
+
+
+
+Trostle, Swift, Brezak, Gossman                                [Page 11]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+8. Expiration Date
+
+      This draft expires on December 31st, 2001.
+
+9. Authors' Addresses
+
+      Jonathan Trostle
+      Cisco Systems
+      170 W. Tasman Dr.
+      San Jose, CA 95134
+      Email: jtrostle@cisco.com
+
+      Mike Swift
+      University of Washington
+      Seattle, WA
+      Email: mikesw@cs.washington.edu
+
+      John Brezak
+      Microsoft
+      1 Microsoft Way
+      Redmond, WA 98052
+      Email: jbrezak@microsoft.com
+
+      Bill Gossman
+      Cisco Systems
+      500 108th Ave. NE, Suite 500
+      Bellevue, WA 98004
+      Email: bgossman@cisco.com
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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
+
+
+
+Trostle, Swift, Brezak, Gossman                                [Page 12]
+
+INTERNET DRAFT                 June 2001           Expires December 2001
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trostle, Swift, Brezak, Gossman                                [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt
new file mode 100644
index 00000000000..e76a0e402ad
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt
@@ -0,0 +1,250 @@
+INTERNET-DRAFT                                             Ken Hornstein
+<draft-ietf-cat-krb-dns-locate-00.txt>                               NRL
+June 21, 1999                                             Jeffrey Altman
+Expires: December 21, 1999                           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-00.txt>, and expires on December 21, 1999.  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                                                  June 21, 1999
+
+   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.
+
+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.
+   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 - KAdmin location information
+
+   Kadmin 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 Kadmin is always "_kadmin".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_tcp" record MUST be included.  If the Kadmin implementation
+   supports UDP transport, a "_udp" record SHOULD be included.
+
+Hornstein, Altman                                               [Page 2]
+
+RFC DRAFT                                                  June 21, 1999
+
+   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 - Kadmin location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has one Kad-
+   min server, kdc1.asdf.com.
+
+   _kadmin._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"
+
+Hornstein, Altman                                               [Page 3]
+
+RFC DRAFT                                                  June 21, 1999
+
+   _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:
+
+   _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.  However, the use of DNS to
+   store this configuration information does not introduce any new secu-
+   rity risks to the Kerberos protocol.
+
+   Current practice 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 vulnerabilities that already exist in the
+   common practice of using hostnames for KDC locations.
+
+   The same holds true for the TXT records used to indicate the domain
+   name to realm mapping.  Current practice is to configure these map-
+   pings locally.  But this again is vulnerable to spoofing via CNAME
+   records that point to hosts in other domains.  This has the same
+   effect as a spoofed TXT record.
+
+   While the described protocol does not introduce any new security
+   risks to the best of our knowledge, 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
+
+Hornstein, Altman                                               [Page 4]
+
+RFC DRAFT                                                  June 21, 1999
+
+   information on a client should be interpretted as permission to use
+   DNS.
+
+Expiration
+
+   This Internet-Draft expires on December 21, 1999.
+
+References
+
+   [RFC1510]
+        The Kerberos Network Authentication System; Kohl, Newman; Sep-
+        tember 1993.
+
+   [RFC1035]
+        Domain Names - Implementation and Specification; Mockapetris;
+        November 1987
+
+   [RFC2052]
+        A DNS RR for specifying the location of services (DNS SRV); Gul-
+        brandsen, Vixie; October 1996
+
+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 5]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
new file mode 100644
index 00000000000..bd31750a15a
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
new file mode 100644
index 00000000000..11e5dc9f954
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-ietf-ftpext-mlst-08.txt b/third_party/heimdal/doc/standardisation/draft-ietf-ftpext-mlst-08.txt
new file mode 100644
index 00000000000..885cf496767
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-ftpext-mlst-08.txt
@@ -0,0 +1,3415 @@
+FTPEXT Working Group                                              R. Elz
+Internet Draft                                   University of Melbourne
+Expiration Date: April 2000
+                                                              P. Hethmon
+                                                        Hethmon Brothers
+
+                                                            October 1999
+
+
+                           Extensions to FTP
+
+
+                     draft-ietf-ftpext-mlst-08.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is NOT offered in accordance
+   with Section 10 of RFC2026, and the author does not provide the IETF
+   with any rights other than to publish as an Internet-Draft.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   To view the list Internet-Draft Shadow Directories, see
+   http://www.ietf.org/shadow.html.
+
+   This entire section has been prepended to this document automatically
+   during formatting without any direct involvement by the author(s) of
+   this draft.
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 1]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+Abstract
+
+   In order to overcome the problems caused by the undefined format of
+   the current FTP LIST command output, a new command is needed to
+   transfer standardized listing information from Server-FTP to User-
+   FTP.  Commands to enable this are defined in this document.
+
+   In order to allow consenting clients and servers to interact more
+   freely, a quite basic, and optional, virtual file store structure is
+   defined.
+
+   This proposal also extends the FTP protocol to allow character sets
+   other than US-ASCII[1] by allowing the transmission of 8-bit
+   characters and the recommended use of UTF-8[2] encoding.
+
+   Much implemented, but long undocumented, mechanisms to permit
+   restarts of interrupted data transfers in STREAM mode, are also
+   included here.
+
+   Lastly, the HOST command has been added to allow a style of "virtual
+   site" to be constructed.
+
+   Changed in this version of this document: Minor corrections as
+   discussed on the mailing list, including fixing many typographical
+   errors; Additional examples.  This paragraph will be deleted from the
+   final version of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 2]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+
+
+Table of Contents
+
+          Abstract  ................................................   2
+    1     Introduction  ............................................   4
+    2     Document Conventions  ....................................   4
+    2.1   Basic Tokens  ............................................   5
+    2.2   Pathnames  ...............................................   5
+    2.3   Times  ...................................................   7
+    2.4   Server Replies  ..........................................   8
+    3     File Modification Time (MDTM)  ...........................   8
+    3.1   Syntax  ..................................................   9
+    3.2   Error responses  .........................................   9
+    3.3   FEAT response for MDTM  ..................................   9
+    3.4   MDTM Examples  ...........................................  10
+    4     File SIZE  ...............................................  11
+    4.1   Syntax  ..................................................  11
+    4.2   Error responses  .........................................  11
+    4.3   FEAT response for SIZE  ..................................  12
+    4.4   Size Examples  ...........................................  12
+    5     Restart of Interrupted Transfer (REST)  ..................  13
+    5.1   Restarting in STREAM Mode  ...............................  13
+    5.2   Error Recovery and Restart  ..............................  14
+    5.3   Syntax  ..................................................  14
+    5.4   FEAT response for REST  ..................................  16
+    5.5   REST Example  ............................................  16
+    6     Virtual FTP servers  .....................................  16
+    6.1   The HOST command  ........................................  18
+    6.2   Syntax of the HOST command  ..............................  18
+    6.3   HOST command semantics  ..................................  19
+    6.4   HOST command errors  .....................................  21
+    6.5   FEAT response for HOST command  ..........................  22
+    7     A Trivial Virtual File Store (TVFS)  .....................  23
+    7.1   TVFS File Names  .........................................  23
+    7.2   TVFS Path Names  .........................................  24
+    7.3   FEAT Response for TVFS  ..................................  25
+    7.4   OPTS for TVFS  ...........................................  26
+    7.5   TVFS Examples  ...........................................  26
+    8     Listings for Machine Processing (MLST and MLSD)  .........  28
+    8.1   Format of MLSx Requests  .................................  29
+    8.2   Format of MLSx Response  .................................  29
+    8.3   Filename encoding  .......................................  32
+    8.4   Format of Facts  .........................................  33
+    8.5   Standard Facts  ..........................................  33
+    8.6   System Dependent and Local Facts  ........................  41
+    8.7   MLSx Examples  ...........................................  42
+    8.8   FEAT response for MLSx  ..................................  50
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 3]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+    8.9   OPTS parameters for MLST  ................................  51
+    9     Impact On Other FTP Commands  ............................  55
+   10     Character sets and Internationalization  .................  56
+   11     IANA Considerations  .....................................  56
+   11.1   The OS specific fact registry  ...........................  56
+   11.2   The OS specific filetype registry  .......................  57
+   12     Security Considerations  .................................  57
+   13     References  ..............................................  58
+          Acknowledgments  .........................................  59
+          Copyright  ...............................................  60
+          Editors' Addresses  ......................................  60
+
+
+
+
+1. Introduction
+
+   This document amends the File Transfer Protocol (FTP) [3].  Five new
+   commands are added: "SIZE", "HOST", "MDTM", "MLST", and "MLSD".  The
+   existing command "REST" is modified.  Of those, the "SIZE" and "MDTM"
+   commands, and the modifications to "REST" have been in wide use for
+   many years.  The others are new.
+
+   These commands allow a client to restart an interrupted transfer in
+   transfer modes not previously supported in any documented way, to
+   support the notion of virtual hosts, and to obtain a directory
+   listing in a machine friendly, predictable, format.
+
+   An optional structure for the server's file store (NVFS) is also
+   defined, allowing servers that support such a structure to convey
+   that information to clients in a standard way, thus allowing clients
+   more certainty in constructing and interpreting path names.
+
+2. Document Conventions
+
+   This document makes use of the document conventions defined in BCP14
+   [4].  That provides the interpretation of capitalized imperative
+   words like MUST, SHOULD, etc.
+
+   This document also uses notation defined in STD 9 [3].  In
+   particular, the terms "reply", "user", "NVFS", "file", "pathname",
+   "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP",
+   "server-FTP process", "server-PI", "server-DTP", "mode", "type",
+   "NVT", "control connection", "data connection", and "ASCII", are all
+   used here as defined there.
+
+   Syntax required is defined using the Augmented BNF defined in [5].
+   Some general ABNF definitions are required throughout the document,
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 4]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   those will be defined later in this section.  At first reading, it
+   may be wise to simply recall that these definitions exist here, and
+   skip to the next section.
+
+2.1. Basic Tokens
+
+   This document imports the core definitions given in Appendix A of
+   [5].  There definitions will be found for basic ABNF elements like
+   ALPHA, DIGIT, SP, etc.  To that, the following terms are added for
+   use in this document.
+
+        TCHAR          = VCHAR / SP / HTAB    ; visible plus white space
+        RCHAR          = ALPHA / DIGIT / "," / "." / ":" / "!" /
+                         "@" / "#" / "$" / "%" / "^" /
+                         "&" / "(" / ")" / "-" / "_" /
+                         "+" / "?" / "/" / "\" / "'" /
+                         DQUOTE   ; <"> -- double quote character (%x22)
+
+   The VCHAR (from [5]), TCHAR, and RCHAR types give basic character
+   types from varying sub-sets of the ASCII character set for use in
+   various commands and responses.
+
+        token          = 1*RCHAR
+
+   A "token" is a string whose precise meaning depends upon the context
+   in which it is used.  In some cases it will be a value from a set of
+   possible values maintained elsewhere.  In others it might be a string
+   invented by one party to an FTP conversation from whatever sources it
+   finds relevant.
+
+   Note that in ABNF, string literals are case insensitive.  That
+   convention is preserved in this document, and implies that FTP
+   commands added by this specification have names that can be
+   represented in any case.  That is, "MDTM" is the same as "mdtm",
+   "Mdtm" and "MdTm" etc.  However note that ALPHA, in particular, is
+   case sensitive.  That implies that a "token" is a case sensitive
+   value.  That implication is correct.
+
+2.2. Pathnames
+
+   Various FTP commands take pathnames as arguments, or return pathnames
+   in responses.  When the MLST command is supported, as indicated in
+   the response to the FEAT command [6], pathnames are to be transferred
+   in one of the following two formats.
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 5]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        pathname       = utf-8-name / raw
+        utf-8-name     = <a UTF-8 encoded Unicode string>
+        raw            = <any string not being a valid UTF-8 encoding>
+
+   Which format is used is at the option of the user-PI or server-PI
+   sending the pathname.  UTF-8 encodings [2] contain enough internal
+   structure that it is always, in practice, possible to determine
+   whether a UTF-8 or raw encoding has been used, in those cases where
+   it matters.  While it is useful for the user-PI to be able to
+   correctly display a pathname received from the server-PI to the user,
+   it is far more important for the user-PI to be able to retain and
+   retransmit the identical pathname when required.  Implementations are
+   advised against converting a UTF-8 pathname to a local encoding, and
+   then attempting to invert the encoding later.  Note that ASCII is a
+   subset of UTF-8.
+
+   Unless otherwise specified, the pathname is terminated by the CRLF
+   that terminates the FTP command, or by the CRLF that ends a reply.
+   Any trailing spaces preceding that CRLF form part of the name.
+   Exactly one space will precede the pathname and serve as a separator
+   from the preceding syntax element.  Any additional spaces form part
+   of the pathname.  See [7] for a fuller explanation of the character
+   encoding issues.  All implementations supporting MLST MUST support
+   [7].
+
+   Implementations should also beware that the control connection uses
+   Telnet NVT conventions [8], and that the Telnet IAC character, if
+   part of a pathname sent over the control connection, MUST be
+   correctly escaped as defined by the Telnet protocol.
+
+   Implementors should also be aware that although Telnet NVT
+   conventions are used over the control connections, Telnet option
+   negotiation MUST NOT be attempted.  See section 4.1.2.12 of [9].
+
+2.2.1. Pathname Syntax
+
+   Except where TVFS is supported (see section 7) this specification
+   imposes no syntax upon pathnames.  Nor does it restrict the character
+   set from which pathnames are created.  This does not imply that the
+   NVFS is required to make sense of all possible pathnames.  Server-PIs
+   may restrict the syntax of valid pathnames in their NVFS in any
+   manner appropriate to their implementation or underlying file system.
+   Similarly, a server-PI may parse the pathname, and assign meaning to
+   the components detected.
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 6]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+2.2.2. Wildcarding
+
+   For the commands defined in this specification, all pathnames are to
+   be treated literally.  That is, for a pathname given as a parameter
+   to a command, the file whose name is identical to the pathname given
+   is implied.  No characters from the pathname may be treated as
+   special or "magic", thus no pattern matching (other than for exact
+   equality) between the pathname given and the files present in the
+   NVFS of the Server-FTP is permitted.
+
+   Clients that desire some form of pattern matching functionality must
+   obtain a listing of the relevant directory, or directories, and
+   implement their own filename selection procedures.
+
+2.3. Times
+
+   The syntax of a time value is:
+
+        time-val       = 14DIGIT [ "." 1*DIGIT ]
+
+   The leading, mandatory, fourteen digits are to be interpreted as, in
+   order from the leftmost, four digits giving the year, with a range of
+   1000-9999, two digits giving the month of the year, with a range of
+   01-12, two digits giving the day of the month, with a range of 01-31,
+   two digits giving the hour of the day, with a range of 00-23, two
+   digits giving minutes past the hour, with a range of 00-59, and
+   finally, two digits giving seconds past the minute, with a range of
+   00-60 (with 60 being used only at a leap second).  Years in the tenth
+   century, and earlier, cannot be expressed.  This is not considered a
+   serious defect of the protocol.
+
+   The optional digits, which are preceded by a period, give decimal
+   fractions of a second.  These may be given to whatever precision is
+   appropriate to the circumstance, however implementations MUST NOT add
+   precision to time-vals where that precision does not exist in the
+   underlying value being transmitted.
+
+   Symbolically, a time-val may be viewed as
+
+        YYYYMMDDHHMMSS.sss
+
+   The "." and subsequent digits ("sss") are optional.  However the "."
+   MUST NOT appear unless at least one following digit also appears.
+
+   Time values are always represented in UTC (GMT), and in the Gregorian
+   calendar regardless of what calendar may have been in use at the date
+   and time indicated at the location of the server-PI.
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 7]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   The technical differences between GMT, TAI, UTC, UT1, UT2, etc, are
+   not considered here.  A server-FTP process should always use the same
+   time reference, so the times it returns will be consistent.  Clients
+   are not expected to be time synchronized with the server, so the
+   possible difference in times that might be reported by the different
+   time standards is not considered important.
+
+2.4. Server Replies
+
+   Section 4.2 of [3] defines the format and meaning of replies by the
+   server-PI to FTP commands from the user-PI.  Those reply conventions
+   are used here without change.
+
+        error-response = error-code SP *TCHAR CRLF
+        error-code     = ("4" / "5") 2DIGIT
+
+   Implementors should note that the ABNF syntax (which was not used in
+   [3]) used in this document, and other FTP related documents,
+   sometimes shows replies using the one line format.  Unless otherwise
+   explicitly stated, that is not intended to imply that multi-line
+   responses are not permitted.  Implementors should assume that, unless
+   stated to the contrary, any reply to any FTP command (including QUIT)
+   may be of the multi-line format described in [3].
+
+   Throughout this document, replies will be identified by the three
+   digit code that is their first element.  Thus the term "500 reply"
+   means a reply from the server-PI using the three digit code "500".
+
+3. File Modification Time (MDTM)
+
+   The FTP command, MODIFICATION TIME (MDTM), can be used to determine
+   when a file in the server NVFS was last modified.  This command has
+   existed in many FTP servers for many years, as an adjunct to the REST
+   command for STREAM mode, thus is widely available.  However, where
+   supported, the "modify" fact which can be provided in the result from
+   the new MLST command is recommended as a superior alternative.
+
+   When attempting to restart a RETRieve, if the User-FTP makes use of
+   the MDTM command, or "modify" fact, it can check and see if the
+   modification time of the source file is more recent than the
+   modification time of the partially transferred file.  If it is, then
+   most likely the source file has changed and it would be unsafe to
+   restart the previously incomplete file transfer.
+
+   When attempting to restart a STORe, the User FTP can use the MDTM
+   command to discover the modification time of the partially
+   transferred file.  If it is older than the modification time of the
+   file that is about to be STORed, then most likely the source file has
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 8]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   changed and it would be unsafe to restart the file transfer.
+
+   Note that using MLST (described below) where available, can provide
+   this information, and much more, thus giving an even better
+   indication that a file has changed, and that restarting a transfer
+   would not give valid results.
+
+   Note that this is applicable to any RESTart attempt, regardless of
+   the mode of the file transfer.
+
+3.1. Syntax
+
+   The syntax for the MDTM command is:
+
+        mdtm          = "MdTm" SP pathname CRLF
+
+   As with all FTP commands, the "MDTM" command label is interpreted in
+   a case insensitive manner.
+
+   The "pathname" specifies an object in the NVFS which may be the
+   object of a RETR command.  Attempts to query the modification time of
+   files that are unable to be retrieved generate undefined responses.
+
+   The server-PI will respond to the MDTM command with a 213 reply
+   giving the last modification time of the file whose pathname was
+   supplied, or a 550 reply if the file does not exist, the modification
+   time is unavailable, or some other error has occurred.
+
+        mdtm-response = "213" SP time-val CRLF /
+                        error-response
+
+3.2. Error responses
+
+   Where the command is correctly parsed, but the modification time is
+   not available, either because the pathname identifies no existing
+   entity, or because the information is not available for the entity
+   named, then a 550 reply should be sent.  Where the command cannot be
+   correctly parsed, a 500 or 501 reply should be sent, as specified in
+   [3].
+
+3.3. FEAT response for MDTM
+
+   When replying to the FEAT command [6], an FTP server process that
+   supports the MDTM command MUST include a line containing the single
+   word "MDTM".  This MAY be sent in upper or lower case, or a mixture
+   of both (it is case insensitive) but SHOULD be transmitted in upper
+   case only.  That is, the response SHOULD be
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                  [Page 9]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        C> Feat
+        S> 211- <any descriptive text>
+        S>  ...
+        S>  MDTM
+        S>  ...
+        S> 211 End
+
+   The ellipses indicate place holders where other features may be
+   included, and are not required.  The one space indentation of the
+   feature lines is mandatory [6].
+
+3.4. MDTM Examples
+
+   If we assume the existence of three files, A B and C, and a directory
+   D, and no other files at all, then the MTDM command may behave as
+   indicated.  The "C>" lines are commands from user-PI to server-PI,
+   the "S>" lines are server-PI replies.
+
+        C> MDTM A
+        S> 213 19980615100045.014
+        C> MDTM B
+        S> 213 19980615100045.014
+        C> MDTM C
+        S> 213 19980705132316
+        C> MDTM D
+        S> 550 D is not retrievable
+        C> MDTM E
+        S> 550 No file named "E"
+        C> mdtm file6
+        S> 213 19990929003355
+        C> MdTm 19990929043300 File6
+        S> 213 19991005213102
+        C> MdTm 19990929043300 file6
+        S> 550 19990929043300 file6: No such file or directory.
+
+   From that we can conclude that both A and B were last modified at the
+   same time (to the nearest millisecond), and that C was modified 21
+   days and several hours later.
+
+   The times are in GMT, so file A was modified on the 15th of June,
+   1998, at approximately 11am in London (summer time was then in
+   effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New
+   York.  All of those represent the same absolute time of course.  The
+   location where the file was modified, and consequently the local wall
+   clock time at that location, is not available.
+
+   There is no file named "E" in the current directory, but there are
+   files named both "file6" and "19990929043300 File6".  The
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 10]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   modification times of those files were obtained.  There is no file
+   named "19990929043300 file6".
+
+4. File SIZE
+
+   The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer
+   size of a file from the server-FTP process.  That is, the exact
+   number of octets (8 bit bytes) which would be transmitted over the
+   data connection should that file be transmitted.  This value will
+   change depending on the current STRUcture, MODE and TYPE of the data
+   connection, or a data connection which would be created were one
+   created now.  Thus, the result of the SIZE command is dependent on
+   the currently established STRU, MODE and TYPE parameters.
+
+   The SIZE command returns how many octets would be transferred if the
+   file were to be transferred using the current transfer structure,
+   mode and type.  This command is normally used in conjunction with the
+   RESTART (REST) command.  The server-PI might need to read the
+   partially transferred file, do any appropriate conversion, and count
+   the number of octets that would be generated when sending the file in
+   order to correctly respond to this command.  Estimates of the file
+   transfer size MUST NOT be returned, only precise information is
+   acceptable.
+
+4.1. Syntax
+
+   The syntax of the SIZE command is:
+
+        size          = "Size" SP pathname CRLF
+
+   The server-PI will respond to the SIZE command with a 213 reply
+   giving the transfer size of the file whose pathname was supplied, or
+   an error response if the file does not exist, the size is
+   unavailable, or some other error has occurred.  The value returned is
+   in a format suitable for use with the RESTART (REST) command for mode
+   STREAM, provided the transfer mode and type are not altered.
+
+        size-response = "213" SP 1*DIGIT CRLF /
+                        error-response
+
+4.2. Error responses
+
+   Where the command is correctly parsed, but the size is not available,
+   either because the pathname identifies no existing entity, or because
+   the entity named cannot be transferred in the current MODE and TYPE
+   (or at all), then a 550 reply should be sent.  Where the command
+   cannot be correctly parsed, a 500 or 501 reply should be sent, as
+   specified in [3].
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 11]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+4.3. FEAT response for SIZE
+
+   When replying to the FEAT command [6], an FTP server process that
+   supports the SIZE command MUST include a line containing the single
+   word "SIZE".  This word is case insensitive, and MAY be sent in any
+   mixture of upper or lower case, however it SHOULD be sent in upper
+   case.  That is, the response SHOULD be
+
+        C> FEAT
+        S> 211- <any descriptive text>
+        S>  ...
+        S>  SIZE
+        S>  ...
+        S> 211 END
+
+   The ellipses indicate place holders where other features may be
+   included, and are not required.  The one space indentation of the
+   feature lines is mandatory [6].
+
+4.4. Size Examples
+
+   Consider a text file "Example" stored on a Unix(TM) server where each
+   end of line is represented by a single octet.  Assume the file
+   contains 112 lines, and 1830 octets total.  Then the SIZE command
+   would produce:
+
+        C> TYPE I
+        S> 200 Type set to I.
+        C> size Example
+        S> 213 1830
+        C> TYPE A
+        S> 200 Type set to A.
+        C> Size Example
+        S> 213 1942
+
+   Notice that with TYPE=A the SIZE command reports an extra 112 octets.
+   Those are the extra octets that need to be inserted, one at the end
+   of each line, to provide correct end of line semantics for a transfer
+   using TYPE=A.  Other systems might need to make other changes to the
+   transfer format of files when converting between TYPEs and MODEs.
+   The SIZE command takes all of that into account.
+
+   Since calculating the size of a file with this degree of precision
+   may take considerable effort on the part of the server-PI, user-PIs
+   should not used this command unless this precision is essential (such
+   as when about to restart an interrupted transfer).  For other uses,
+   the "Size" fact of the MLST command (see section 8.5.7) ought be
+   requested.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 12]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+5. Restart of Interrupted Transfer (REST)
+
+   To avoid having to resend the entire file if the file is only
+   partially transferred, both sides need some way to be able to agree
+   on where in the data stream to restart the data transfer.
+
+   The FTP specification [3] includes three modes of data transfer,
+   Stream, Block and Compressed.  In Block and Compressed modes, the
+   data stream that is transferred over the data connection is
+   formatted, allowing the embedding of restart markers into the stream.
+   The sending DTP can include a restart marker with whatever
+   information it needs to be able to restart a file transfer at that
+   point.  The receiving DTP can keep a list of these restart markers,
+   and correlate them with how the file is being saved.  To restart the
+   file transfer, the receiver just sends back that last restart marker,
+   and both sides know how to resume the data transfer.  Note that there
+   are some flaws in the description of the restart mechanism in RFC 959
+   [3].  See section 4.1.3.4 of RFC 1123 [9] for the corrections.
+
+5.1. Restarting in STREAM Mode
+
+   In Stream mode, the data connection contains just a stream of
+   unformatted octets of data.  Explicit restart markers thus cannot be
+   inserted into the data stream, they would be indistinguishable from
+   data.  For this reason, the FTP specification [3] did not provide the
+   ability to do restarts in stream mode.  However, there is not really
+   a need to have explicit restart markers in this case, as restart
+   markers can be implied by the octet offset into the data stream.
+
+   Because the data stream defines the file in STREAM mode, a different
+   data stream would represent a different file.  Thus, an offset will
+   always represent the same position within a file.  On the other hand,
+   in other modes than STREAM, the same file can be transferred using
+   quite different octet sequences, and yet be reconstructed into the
+   one identical file.  Thus an offset into the data stream in transfer
+   modes other than STREAM would not give an unambiguous restart point.
+
+   If the data representation TYPE is IMAGE, and the STRUcture is File,
+   for many systems the file will be stored exactly in the same format
+   as it is sent across the data connection.  It is then usually very
+   easy for the receiver to determine how much data was previously
+   received, and notify the sender of the offset where the transfer
+   should be restarted.  In other representation types and structures
+   more effort will be required, but it remains always possible to
+   determine the offset with finite, but perhaps non-negligible, effort.
+   In the worst case an FTP process may need to open a data connection
+   to itself, set the appropriate transfer type and structure, and
+   actually transmit the file, counting the transmitted octets.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 13]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   If the user-FTP process is intending to restart a retrieve, it will
+   directly calculate the restart marker, and send that information in
+   the RESTart command.  However, if the user-FTP process is intending
+   to restart sending the file, it needs to be able to determine how
+   much data was previously sent, and correctly received and saved.  A
+   new FTP command is needed to get this information.  This is the
+   purpose of the SIZE command, as documented in section 4.
+
+5.2. Error Recovery and Restart
+
+   STREAM MODE transfers with FILE STRUcture may be restarted even
+   though no restart marker has been transferred in addition to the data
+   itself.  This is done by using the SIZE command, if needed, in
+   combination with the RESTART (REST) command, and one of the standard
+   file transfer commands.
+
+   When using TYPE ASCII or IMAGE, the SIZE command will return the
+   number of octets that would actually be transferred if the file were
+   to be sent between the two systems.  I.e. with type IMAGE, the SIZE
+   normally would be the number of octets in the file.  With type ASCII,
+   the SIZE would be the number of octets in the file including any
+   modifications required to satisfy the TYPE ASCII CR-LF end of line
+   convention.
+
+5.3. Syntax
+
+   The syntax for the REST command when the current transfer mode is
+   STREAM is:
+
+        rest          = "Rest" SP 1*DIGIT CRLF
+
+   The numeric value gives the number of octets of the immediately
+   following transfer to not actually send, effectively causing the
+   transmission to be restarted at a later point.  A value of zero
+   effectively disables restart, causing the entire file to be
+   transmitted.  The server-PI will respond to the REST command with a
+   350 reply, indicating that the REST parameter has been saved, and
+   that another command, which should be either RETR or STOR, should
+   then follow to complete the restart.
+
+        rest-response = "350" SP *TCHAR CRLF /
+                        error-response
+
+   Server-FTP processes may permit transfer commands other than RETR and
+   STOR, such as APPE and STOU, to complete a restart, however, this is
+   not recommended.  STOU (store unique) is undefined in this usage, as
+   storing the remainder of a file into a unique filename is rarely
+   going to be useful.  If APPE (append) is permitted, it MUST act
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 14]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   identically to STOR when a restart marker has been set.  That is, in
+   both cases, octets from the data connection are placed into the file
+   at the location indicated by the restart marker value.
+
+   The REST command is intended to complete a failed transfer.  Use with
+   RETR is comparatively well defined in all cases, as the client bears
+   the responsibility of merging the retrieved data with the partially
+   retrieved file.  If it chooses to use the data obtained other than to
+   complete an earlier transfer, or if it chooses to re-retrieve data
+   that had been retrieved before, that is its choice.  With STOR,
+   however, the server must insert the data into the file named.  The
+   results are undefined if a client uses REST to do other than restart
+   to complete a transfer of a file which had previously failed to
+   completely transfer.  In particular, if the restart marker set with a
+   REST command is not at the end of the data currently stored at the
+   server, as reported by the server, or if insufficient data are
+   provided in a STOR that follows a REST to extend the destination file
+   to at least its previous size, then the effects are undefined.
+
+   The REST command must be the last command issued before the data
+   transfer command which is to cause a restarted rather than complete
+   file transfer.  The effect of issuing a REST command at any other
+   time is undefined.  The server-PI may react to a badly positioned
+   REST command by issuing an error response to the following command,
+   not being a restartable data transfer command, or it may save the
+   restart value and apply it to the next data transfer command, or it
+   may silently ignore the inappropriate restart attempt.  Because of
+   this, a user-PI that has issued a REST command, but which has not
+   successfully transmitted the following data transfer command for any
+   reason, should send another REST command before the next data
+   transfer command.  If that transfer is not to be restarted, then
+   "REST 0" should be issued.
+
+   An error-response will follow a REST command only when the server
+   does not implement the command, or the restart marker value is
+   syntactically invalid for the current transfer mode.  That is, in
+   STREAM mode, if something other than one or more digits appears in
+   the parameter to the REST command.  Any other errors, including such
+   problems as restart marker out of range, should be reported when the
+   following transfer command is issued.  Such errors will cause that
+   transfer request to be rejected with an error indicating the invalid
+   restart attempt.
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 15]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+5.4. FEAT response for REST
+
+   Where a server-FTP process supports RESTart in STREAM mode, as
+   specified here, it MUST include in the response to the FEAT command
+   [6], a line containing exactly the string "REST STREAM".  This string
+   is not case sensitive, but SHOULD be transmitted in upper case.
+   Where REST is not supported at all, or supported only in block or
+   compressed modes, the REST line MUST NOT be included in the FEAT
+   response.  Where required, the response SHOULD be
+
+        C> feat
+        S> 211- <any descriptive text>
+        S>  ...
+        S>  REST STREAM
+        S>  ...
+        S> 211 end
+
+   The ellipses indicate place holders where other features may be
+   included, and are not required.  The one space indentation of the
+   feature lines is mandatory [6].
+
+5.5. REST Example
+
+   Assume that the transfer of a largish file has previously been
+   interrupted after 802816 octets had been received, that the previous
+   transfer was with TYPE=I, and that it has been verified that the file
+   on the server has not since changed.
+
+        C> TYPE I
+        S> 200 Type set to I.
+        C> PORT 127,0,0,1,15,107
+        S> 200 PORT command successful.
+        C> REST 802816
+        S> 350 Restarting at 802816. Send STORE or RETRIEVE
+        C> RETR cap60.pl198.tar
+        S> 150 Opening BINARY mode data connection
+        [...]
+        S> 226 Transfer complete.
+
+6. Virtual FTP servers
+
+   It has become common in the Internet for many domain names to be
+   allocated to a single IP address.  This has introduced the concept of
+   a "virtual host", where a host appears to exist as an independent
+   entity, but in reality shares all of its resources with one, or more,
+   other such hosts.
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 16]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   Such an arrangement presents some problems for FTP Servers, as all
+   the FTP Server can detect is an incoming FTP connection to a
+   particular IP address.  That is, all domain names which share the IP
+   address also share the FTP server, and more importantly, its NVFS.
+   This means that the various virtual hosts cannot offer different
+   virtual file systems to clients, nor can they offer different
+   authentication systems.
+
+   No scheme can overcome this without modifications of some kind to the
+   user-PI and the user-FTP process.  That process is the only entity
+   that knows which virtual host is required.  It has performed the
+   domain name to IP address translation, and thus has the original
+   domain name available.
+
+   One method which could be used to allow a style of virtual host would
+   be for the client to simply send a "CWD" command after connecting,
+   using the virtual host name as the argument to the CWD command.  This
+   would allow the server-FTP process to implement the file stores of
+   the virtual hosts as sub-directories in its NVFS.  This is simple,
+   and supported by essentially all server-FTP implementations without
+   requiring any code changes.
+
+   While that method is simple to describe, and to implement, it suffers
+   from several drawbacks.  First, the "CWD" command is available only
+   after the user-PI has authenticated itself to the server-FTP process.
+   Thus, all virtual hosts would be required to share a common
+   authentication scheme.  Second, either the server-FTP process needs
+   to be modified to understand the special nature of this first CWD
+   command, negating most of the advantage of this scheme, or all users
+   must see the same identical NVFS view upon connecting (they must
+   connect in the same initial directory) or the NVFS must implement the
+   full set of virtual host directories at each possible initial
+   directory for any possible user, or the virtual host will not be
+   truly transparent.  Third, and again unless the server is specially
+   modified, a user connecting this way to a virtual host would be able
+   to trivially move to any other virtual host supported at the same
+   server-FTP process, exposing the nature of the virtual host.
+
+   Other schemes overloading other existing FTP commands have also been
+   proposed.  None of those have sufficient merit to be worth
+   discussion.
+
+   The conclusion from the examination of the possibilities seems to be
+   that to obtain an adequate emulation of "real" FTP servers, server
+   modifications to support virtual hosts are required.  A new command
+   seems most likely to provide the support required.
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 17]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+6.1. The HOST command
+
+   A new command "HOST" is added to the FTP command set to allow
+   server-FTP process to determine to which of possibly many virtual
+   hosts the client wishes to connect.  This command is intended to be
+   issued before the user is authenticated, allowing the authentication
+   scheme, and set of legal users, to be dependent upon the virtual host
+   chosen.  Server-FTP processes may, if they desire, permit the HOST
+   command to be issued after the user has been authenticated, or may
+   treat that as an erroneous sequence of commands.  The behavior of the
+   server-FTP process which does allow late HOST commands is undefined.
+   One reasonable interpretation would be for the user-PI to be returned
+   to the state that existed after the TCP connection was first
+   established, before user authentication.
+
+   Servers should note that the response to the HOST command is a
+   sensible time to send their "welcome" message.  This allows the
+   message to be personalized for any virtual hosts that are supported,
+   and also allows the client to have determined supported languages, or
+   representations, for the message, and other messages, via the FEAT
+   response, and selected an appropriate one via the LANG command.  See
+   [7] for more information.
+
+6.2. Syntax of the HOST command
+
+   The HOST command is defined as follows.
+
+        host-command     = "Host" SP hostname CRLF
+        hostname         = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ]
+        DNCHAR           = ALPHA / DIGIT / "-" / "_" / "$" /
+                           "!" / "%" / "[" / "]" / ":"
+        host-response    = host-ok / error-response
+        host-ok          = "220" [ SP *TCHAR ] CRLF
+
+   As with all FTP commands, the "host" command word is case
+   independent, and may be specified in any character case desired.
+
+   The "hostname" given as a parameter specifies the virtual host to
+   which access is desired.  It should normally be the same name that
+   was used to obtain the IP address to which the FTP control connection
+   was made, after any client conversions to convert an abbreviated or
+   local alias to a complete (fully qualified) domain name, but before
+   resolving a DNS alias (owner of a CNAME resource record) to its
+   canonical name.
+
+   If the client was given a network literal address, and consequently
+   was not required to derive it from a hostname, it should send the
+   HOST command with the network address, as specified to it, enclosed
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 18]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   in brackets (after eliminating any syntax, which might also be
+   brackets, but is not required to be, from which the server deduced
+   that a literal address had been specified.) That is, for example
+
+                         HOST [10.1.2.3]
+
+   should be sent if the client had been instructed to connect to
+   "10.1.2.3", or "[10.1.2.3]", or perhaps even IPv4:10.1.2.3.  The
+   method of indicating to a client that a literal address is to be used
+   is beyond the scope of this specification.
+
+   The parameter is otherwise to be treated as a "complete domain name",
+   as that term is defined in section 3.1 of RFC 1034 [10].  That
+   implies that the name is to be treated as a case independent string,
+   in that upper case ASCII characters are to be treated as equivalent
+   to the corresponding lower case ASCII characters, but otherwise
+   preserved as given.  It also implies some limits on the length of the
+   parameter and of the components that create its internal structure.
+   Those limits are not altered in any way here.
+
+   RFC 1034 imposes no other restrictions upon what kinds of names can
+   be stored in the DNS.  Nor does RFC 1035.  This specification,
+   however, allows only a restricted set of names for the purposes of
+   the HOST command.  Those restrictions can be inferred from the ABNF
+   grammar given for the "hostname".
+
+6.3. HOST command semantics
+
+   Upon receiving the HOST command, before authenticating the user-PI, a
+   server-FTP process should validate that the hostname given represents
+   a valid virtual host for that server, and if so, establish the
+   appropriate environment for that virtual host.  The meaning of that
+   is not specified here, and may range from doing nothing at all, or
+   performing a simple change of working directory, to much more
+   elaborate state changes, as required.
+
+   If the hostname specified is unknown at the server, or if the server
+   is otherwise unwilling to treat the particular connection as a
+   connection to the hostname specified, the server will respond with a
+   504 reply.
+
+   Note: servers may require that the name specified is in some sense
+   equivalent to the particular network address that was used to reach
+   the server.
+
+   If the hostname specified would normally be acceptable, but for any
+   reason is temporarily unavailable, the server SHOULD reply to the
+   HOST command with a 434 reply.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 19]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   The "220" reply code for the HOST command is the same as the code
+   used on the initial connection established "welcome" message.  This
+   is done deliberately so as to allow the implementation to implement
+   the front end FTP server as a wrapper which simply waits for the HOST
+   command, and then invokes an older, RFC959 compliant, server in the
+   appropriate environment for the particular hostname received.
+
+6.3.1. The REIN command
+
+   As specified in [3], the REIN command returns the state of the
+   connection to that it was immediately after the transport connection
+   was opened.  That is not changed here.  The effect of a HOST command
+   will be lost if a REIN command is performed, a new HOST command must
+   be issued.
+
+   Implementors of user-FTP should be aware that server-FTP
+   implementations which implement the HOST command as a wrapper around
+   older implementations will be unable to correctly implement the REIN
+   command.  In such an implementation, REIN will typically return the
+   server-FTP to the state that existed immediately after the HOST
+   command was issued, instead of to the state immediately after the
+   connection was opened.
+
+6.3.2. User-PI usage of HOST
+
+   A user-PI that conforms to this specification, MUST send the HOST
+   command after opening the transport connection, or after any REIN
+   command, before attempting to authenticate the user with the USER
+   command.
+
+   The following state diagram shows a typical sequence of flow of
+   control, where the "B" (begin) state is assumed to occur after the
+   transport connection has opened, or a REIN command has succeeded.
+   Other commands (such as FEAT [6]) which require no authentication may
+   have intervened.  This diagram is modeled upon (and largely borrowed
+   from) the similar diagram in section 6 of [3].
+
+   In this diagram, a three digit reply indicates that precise server
+   reply code, a single digit on a reply path indicates any server reply
+   beginning with that digit, other than any three digit replies that
+   might take another path.
+
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 20]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+
+              +---+   HOST    +---+ 1,3,5
+              | B |---------->| W |-----------------
+              +---+           +---+                 |
+                               | |                  |
+                     2,500,502 | | 4,501,503,504    |
+                 --------------   -------------     |
+                |                              |    |
+                V                   1          |    V
+              +---+   USER    +---+-------------->+---+
+              |   |---------->| W | 2       ----->| E |
+              +---+           +---+------  |  --->+---+
+                               | |       | | | |
+                             3 | | 4,5   | | | |
+                 --------------   -----  | | | |
+                |                      | | | | |
+                |                      | | | | |
+                |                 ---------  | |
+                |               1|     | |   | |
+                V                |     | |   | |
+              +---+   PASS    +---+ 2  |  ------->+---+
+              |   |---------->| W |-------------->| S |
+              +---+           +---+   ----------->+---+
+                               | |   | |     | |
+                             3 | |4,5| |     | |
+                 --------------   --------   | |
+                |                    | |  |  |  ----
+                |                    | |  |  |      |
+                |                 -----------       |
+                |             1,3|   | |  |         |
+                V                |  2| |  |         V
+              +---+   ACCT    +---+--  |   ------>+---+
+              |   |---------->| W | 4,5 --------->| F |
+              +---+           +---+-------------->+---+
+
+6.4. HOST command errors
+
+   The server-PI shall reply with a 500 or 502 reply if the HOST command
+   is unrecognized or unimplemented.  A 503 reply may be sent if the
+   HOST command is given after a previous HOST command, or after a user
+   has been authenticated.  Alternately, the server may accept the
+   command at such a time, with server defined behavior.  A 501 reply
+   should be sent if the hostname given is syntactically invalid, and a
+   504 reply if a syntactically valid hostname is not a valid virtual
+   host name for the server.
+
+   In all such cases the server-FTP process should act as if no HOST
+   command had been given.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 21]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   A user-PI receiving a 500 or 502 reply should assume that the
+   server-PI does not implement the HOST command style virtual server.
+   It may then proceed to login as if the HOST command had succeeded,
+   and perhaps, attempt a CWD command to the hostname after
+   authenticating the user.
+
+   A user-PI receiving some other error reply should assume that the
+   virtual HOST is unavailable, and terminate communications.
+
+   A server-PI that receives a USER command, beginning the
+   authentication sequence, without having received a HOST command
+   SHOULD NOT reject the USER command.  Clients conforming to earlier
+   FTP specifications do not send HOST commands.  In this case the
+   server may act as if some default virtual host had been explicitly
+   selected, or may enter an environment different from that of all
+   supported virtual hosts, perhaps one in which a union of all
+   available accounts exists, and which presents a NVFS which appears to
+   contain sub-directories containing the NVFS for all virtual hosts
+   supported.
+
+6.5. FEAT response for HOST command
+
+   A server-FTP process that supports the host command, and virtual FTP
+   servers, MUST include in the response to the FEAT command [6], a
+   feature line indicating that the HOST command is supported.  This
+   line should contain the single word "HOST".  This MAY be sent in
+   upper or lower case, or a mixture of both (it is case insensitive)
+   but SHOULD be transmitted in upper case only.  That is, the response
+   SHOULD be
+
+        C> Feat
+        S> 211- <any descriptive text>
+        S>  ...
+        S>  HOST
+        S>  ...
+        S> 211 End
+
+   The ellipses indicate place holders where other features may be
+   included, and are not required.  The one space indentation of the
+   feature lines is mandatory [6].
+
+
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 22]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+7. A Trivial Virtual File Store (TVFS)
+
+   Traditionally, FTP has placed almost no constraints upon the file
+   store (NVFS) provided by a server.  This specification does not alter
+   that.  However, it has become common for servers to attempt to
+   provide at least file system naming conventions modeled loosely upon
+   those of the UNIX(TM) file system.  That is, a tree structured file
+   system, built of directories, each of which can contain other
+   directories, or other kinds of files, or both.  Each file and
+   directory has a file name relative to the directory that contains it,
+   except for the directory at the root of the tree, which is contained
+   in no other directory, and hence has no name of its own.
+
+   That which has so far been described is perfectly consistent with the
+   standard FTP NVFS and access mechanisms.  The "CWD" command is used
+   to move from one directory to an embedded directory.  "CDUP" may be
+   provided to return to the parent directory, and the various file
+   manipulation commands ("RETR", "STOR", the rename commands, etc) are
+   used to manipulate files within the current directory.
+
+   However, it is often useful to be able to reference files other than
+   by changing directories, especially as FTP provides no guaranteed
+   mechanism to return to a previous directory.  The Trivial Virtual
+   File Store (TVFS), if implemented, provides that mechanism.
+
+7.1. TVFS File Names
+
+   Where a server implements the TVFS, no elementary filename shall
+   contain the character "/".  Where the underlying natural file store
+   permits files, or directories, to contain the "/" character in their
+   names, a server-PI implementing TVFS must encode that character in
+   some manner whenever file or directory names are being returned to
+   the user-PI, and reverse that encoding whenever such names are being
+   accepted from the user-PI.
+
+   The encoding method to be used is not specified here.  Where some
+   other character is illegal in file and directory names in the
+   underlying file store, a simple transliteration may be sufficient.
+   Where there is no suitable substitute character a more complex
+   encoding scheme, possibly using an escape character, is likely to be
+   required.
+
+   With the one exception of the unnamed root directory, a TVFS file
+   name may not be empty.  That is, all other file names contain at
+   least one character.
+
+   With the sole exception of the "/" character, any valid IS10646
+   character [11] may be used in a TVFS filename.  When transmitted,
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 23]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   file name characters are encoded using the UTF-8 encoding [2].
+
+7.2. TVFS Path Names
+
+   A TVFS "Path Name" combines the file or directory name of a target
+   file or directory, with the directory names of zero or more enclosing
+   directories, so as to allow the target file or directory to be
+   referenced other than when the server's "current working directory"
+   is the directory directly containing the target file or directory.
+
+   By definition, every TVFS file or directory name is also a TVFS path
+   name.  Such a path name is valid to reference the file from the
+   directory containing the name, that is, when that directory is the
+   server-FTP's current working directory.
+
+   Other TVFS path names are constructed by prefixing a path name by a
+   name of a directory from which the path is valid, and separating the
+   two with the "/" character.  Such a path name is valid to reference
+   the file or directory from the directory containing the newly added
+   directory name.
+
+   Where a path name has been extended to the point where the directory
+   added is the unnamed root directory, the path name will begin with
+   the "/" character.  Such a path is known as a fully qualified path
+   name.  Fully qualified paths may, obviously, not be further extended,
+   as, by definition, no directory contains the root directory.  Being
+   unnamed, it cannot be represented in any other directory.  A fully
+   qualified path name is valid to reference the named file or directory
+   from any location (that is, regardless of what the current working
+   directory may be) in the virtual file store.
+
+   Any path name which is not a fully qualified path name may be
+   referred to as a "relative path name" and will only correctly
+   reference the intended file when the current working directory of the
+   server-FTP is a directory from which the relative path name is valid.
+
+   As a special case, the path name "/" is defined to be a fully
+   qualified path name referring to the root directory.  That is, the
+   root directory does not have a directory (or file) name, but does
+   have a path name.  This special path name may be used only as is as a
+   reference to the root directory.  It may not be combined with other
+   path names using the rules above, as doing so would lead to a path
+   name containing two consecutive "/" characters, which is an undefined
+   sequence.
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 24]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+7.2.1. Notes
+
+     + It is not required, or expected, that there be only one fully
+       qualified path name that will reference any particular file or
+       directory.
+     + As a caveat, though the TVFS file store is basically tree
+       structured, there is no requirement that any file or directory
+       have only one parent directory.
+     + As defined, no TVFS path name will ever contain two consecutive
+       "/" characters.  Such a name is not illegal however, and may be
+       defined by the server for any purpose that suits it.  Clients
+       implementing this specification should not assume any semantics
+       at all for such names.
+     + Similarly, other than the special case path that refers to the
+       root directory, no TVFS path name constructed as defined here
+       will ever end with the "/" character.  Such names are also not
+       illegal, but are undefined.
+     + While any legal IS10646 character is permitted to occur in a TVFS
+       file or directory name, other than "/", server FTP
+       implementations are not required to support all possible IS10646
+       characters.  The subset supported is entirely at the discretion
+       of the server.  The case (where it exists) of the characters that
+       make up file, directory, and path names may be significant.
+       Unless determined otherwise by means unspecified here, clients
+       should assume that all such names are comprised of characters
+       whose case is significant.  Servers are free to treat case (or
+       any other attribute) of a name as irrelevant, and hence map two
+       names which appear to be distinct onto the same underlying file.
+     + There are no defined "magic" names, like ".", ".." or "C:".
+       Servers may implement such names, with any semantics they choose,
+       but are not required to do so.
+     + TVFS imposes no particular semantics or properties upon files,
+       guarantees no access control schemes, or any of the other common
+       properties of a file store.  Only the naming scheme is defined.
+
+7.3. FEAT Response for TVFS
+
+   In response to the FEAT command [6] a server that wishes to indicate
+   support for the TVFS as defined here will include a line that begins
+   with the four characters "TVFS" (in any case, or mixture of cases,
+   upper case is not required).  Servers SHOULD send upper case.
+
+   Such a response to the FEAT command MUST NOT be returned unless the
+   server implements TVFS as defined here.
+
+   Later specifications may add to the TVFS definition.  Such additions
+   should be notified by means of additional text appended to the TVFS
+   feature line.  Such specifications, if any, will define the extra
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 25]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   text.
+
+   Until such a specification is defined, servers should not include
+   anything after "TVFS" in the TVFS feature line.  Clients, however,
+   should be prepared to deal with arbitrary text following the four
+   defined characters, and simply ignore it if unrecognized.
+
+   A typical response to the FEAT command issued by a server
+   implementing only this specification would be:
+
+        C> feat
+        S> 211- <any descriptive text>
+        S>  ...
+        S>  TVFS
+        S>  ...
+        S> 211 end
+
+   The ellipses indicate place holders where other features may be
+   included, and are not required.  The one space indentation of the
+   feature lines is mandatory [6], and is not counted as one of the
+   first four characters for the purposes of this feature listing.
+
+   The TVFS feature adds no new commands to the FTP command repertoire.
+
+7.4. OPTS for TVFS
+
+   There are no options in this TVFS specification, and hence there is
+   no OPTS command defined.
+
+7.5. TVFS Examples
+
+   Assume a TVFS file store is comprised of a root directory, which
+   contains two directories (A and B) and two non-directory files (X and
+   Y).  The A directory contains two directories (C and D) and one other
+   file (Z).  The B directory contains just two non-directory files (P
+   and Q) and the C directory also two non-directory files (also named P
+   and Q, by chance).  The D directory is empty, that is, contains no
+   files or directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 26]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   This structure may depicted graphically as...
+
+                      (unnamed root)
+                        /  |  \   \
+                       /   |   \   \
+                      A    X    B   Y
+                     /|\       / \
+                    / | \     /   \
+                   C  D  Z   P     Q
+                  / \
+                 /   \
+                P     Q
+
+   Given this structure, the following fully qualified path names exist.
+
+        /
+        /A
+        /B
+        /X
+        /Y
+        /A/C
+        /A/D
+        /A/Z
+        /A/C/P
+        /A/C/Q
+        /B/P
+        /B/Q
+
+   It is clear that none of the paths / /A /B or /A/D refer to the same
+   directory, as the contents of each is different.  Nor do any of / /A
+   /A/C or /A/D.  However /A/C and /B might be the same directory, there
+   is insufficient information given to tell.  Any of the other path
+   names (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the same
+   underlying files, in almost any combination.
+
+   If the current working directory of the server-FTP is /A then the
+   following path names, in addition to all the fully qualified path
+   names, are valid
+
+        C
+        D
+        Z
+        C/P
+        C/Q
+
+   These all refer to the same files or directories as the corresponding
+   fully qualified path with "/A/" prepended.
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 27]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   That those path names all exist does not imply that the TVFS sever
+   will necessarily grant any kind of access rights to the named paths,
+   or that access to the same file via different path names will
+   necessarily be granted equal rights.
+
+   None of the following relative paths are valid when the current
+   directory is /A
+
+        A
+        B
+        X
+        Y
+        B/P
+        B/Q
+        P
+        Q
+
+   Any of those could be made valid by changing the server-FTP's current
+   working directory to the appropriate directory.  Note that the paths
+   "P" and "Q" might refer to different files depending upon which
+   directory is selected to cause those to become valid TVFS relative
+   paths.
+
+8. Listings for Machine Processing (MLST and MLSD)
+
+   The MLST and MLSD commands are intended to standardize the file and
+   directory information returned by the Server-FTP process.  These
+   commands differ from the LIST command in that the format of the
+   replies is strictly defined although extensible.
+
+   Two commands are defined, MLST which provides data about exactly the
+   object named on its command line, and no others.  MLSD on the other
+   hand will list the contents of a directory if a directory is named,
+   otherwise a 501 reply will be returned.  In either case, if no object
+   is named, the current directory is assumed.  That will cause MLST to
+   send a one line response, describing the current directory itself,
+   and MLSD to list the contents of the current directory.
+
+   In the following, the term MLSx will be used wherever either MLST or
+   MLSD may be inserted.
+
+   The MLST and MLSD commands also extend the FTP protocol as presented
+   in RFC 959 [3] and RFC 1123 [9] to allow that transmission of 8-bit
+   data over the control connection.  Note this is not specifying
+   character sets which are 8-bit, but specifying that FTP
+   implementations are to specifically allow the transmission and
+   reception of 8-bit bytes, with all bits significant, over the control
+   connection.  That is, all 256 possible octet values are permitted.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 28]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   The MLSx command allows both UTF-8/Unicode and "raw" forms as
+   arguments, and in responses both to the MLST and MLSD commands, and
+   all other FTP commands which take pathnames as arguments.
+
+8.1. Format of MLSx Requests
+
+   The MLST and MLSD commands each allow a single optional argument.
+   This argument may be either a directory name or, for MLST only, a
+   filename.  For these purposes, a "filename" is the name of any entity
+   in the server NVFS which is not a directory.  Where TVFS is
+   supported, any TVFS relative path name valid in the current working
+   directory, or any TVFS fully qualified path name, may be given.  If a
+   directory name is given then MLSD must return a listing of the
+   contents of the named directory, otherwise it issues a 501 reply, and
+   does not open a data connection.  In all cases for MLST, a single set
+   of fact lines (usually a single fact line) containing the information
+   about the named file or directory shall be returned over the control
+   connection, without opening a data connection.
+
+   If no argument is given then MLSD must return a listing of the
+   contents of the current working directory, and MLST must return a
+   listing giving information about the current working directory
+   itself.  For these purposes, the contents of a directory are whatever
+   filenames (not pathnames) the server-PI will allow to be referenced
+   when the current working directory is the directory named, and which
+   the server-PI desires to reveal to the user-PI.
+
+   No title, header, or summary, lines, or any other formatting, other
+   than as is specified below, is ever returned in the output of an MLST
+   or MLSD command.
+
+   If the Client-FTP sends an invalid argument, the Server-FTP MUST
+   reply with an error code of 501.
+
+   The syntax for the MLSx command is:
+
+        mlst             = "MLst" [ SP pathname ] CRLF
+        mlsd             = "MLsD" [ SP pathname ] CRLF
+
+8.2. Format of MLSx Response
+
+   The format of a response to an MLSx command is as follows:
+
+        mlst-response    = control-response / error-response
+        mlsd-response    = ( initial-response final-response ) /
+                           error-response
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 29]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        control-response = "250-" [ response-message ] CRLF
+                           1*( SP entry CRLF )
+                           "250" [ SP response-message ] CRLF
+
+        initial-response = "150" [ SP response-message ] CRLF
+        final-response   = "226" SP response-message CRLF
+
+        response-message = *TCHAR
+
+        data-response    = *( entry CRLF )
+
+        entry            = [ facts ] SP pathname
+        facts            = 1*( fact ";" )
+        fact             = factname "=" value
+        factname         = "Size" / "Modify" / "Create" /
+                           "Type" / "Unique" / "Perm" /
+                           "Lang" / "Media-Type" / "CharSet" /
+                           os-depend-fact / local-fact
+        os-depend-fact   = <IANA assigned OS name> "." token
+        local-fact       = "X." token
+        value            = *RCHAR
+
+   Upon receipt of a MLSx command, the server will verify the parameter,
+   and if invalid return an error-response.  For this purpose, the
+   parameter should be considered to be invalid if the client issuing
+   the command does not have permission to perform the request
+   operation.
+
+   If valid, then for an MLST command, the server-PI will send the first
+   (leading) line of the control response, the entry for the pathname
+   given, or the current directory if no pathname was provided, and the
+   terminating line.  Normally exactly one entry would be returned, more
+   entries are permitted only when required to represent a file that is
+   to have multiple "Type" facts returned.
+
+   Note that for MLST the fact set is preceded by a space.  That is
+   provided to guarantee that the fact set cannot be accidentally
+   interpreted as the terminating line of the control response, but is
+   required even when that would not be possible.  Exactly one space
+   exists between the set of facts and the pathname.  Where no facts are
+   present, there will be exactly two leading spaces before the
+   pathname.  No spaces are permitted in the facts, any other spaces in
+   the response are to be treated as being a part of the pathname.
+
+   If the command was an MLSD command, the server will open a data
+   connection as indicated in section 3.2 of RFC959 [3].  If that fails,
+   the server will return an error-response.  If all is OK, the server
+   will return the initial-response, send the appropriate data-response
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 30]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   over the new data connection, close that connection, and then send
+   the final-response over the control connection.  The grammar above
+   defines the format for the data-response, which defines the format of
+   the data returned over the data connection established.
+
+   The data connection opened for a MLSD response shall be a connection
+   as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given,
+   whatever FTP transfer type, mode and structure had actually been set,
+   and without causing those settings to be altered for future commands.
+   That is, this transfer type shall be set for the duration of the data
+   connection established for this command only.  While the content of
+   the data sent can be viewed as a series of lines, implementations
+   should note that there is no maximum line length defined.
+   Implementations should be prepared to deal with arbitrarily long
+   lines.
+
+   The facts part of the specification would contain a series of "file
+   facts" about the file or directory named on the same line.  Typical
+   information to be presented would include file size, last
+   modification time, creation time, a unique identifier, and a
+   file/directory flag.
+
+   The complete format for a successful reply to the MLSD command would
+   be:
+
+        facts SP pathname CRLF
+        facts SP pathname CRLF
+        facts SP pathname CRLF
+        ...
+
+   Note that the format is intended for machine processing, not human
+   viewing, and as such the format is very rigid.  Implementations MUST
+   NOT vary the format by, for example, inserting extra spaces for
+   readability, replacing spaces by tabs, including header or title
+   lines, or inserting blank lines, or in any other way alter this
+   format.  Exactly one space is always required after the set of facts
+   (which may be empty).  More spaces may be present on a line if, and
+   only if, the file name presented contains significant spaces.  The
+   set of facts must not contain any spaces anywhere inside it.  Facts
+   should be provided in each output line only if they both provide
+   relevant information about the file named on the same line, and they
+   are in the set requested by the user-PI.  There is no requirement
+   that the same set of facts be provided for each file, or that the
+   facts presented occur in the same order for each file.
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 31]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+8.3. Filename encoding
+
+   An FTP implementation supporting the MLSx commands must be 8-bit
+   clean.  This is necessary in order to transmit UTF-8 encoded
+   filenames.  This specification recommends the use of UTF-8 encoded
+   filenames.  FTP implementations SHOULD use UTF-8 whenever possible to
+   encourage the maximum interoperability.
+
+   Filenames are not restricted to UTF-8, however treatment of arbitrary
+   character encodings is not specified by this standard.  Applications
+   are encouraged to treat non-UTF-8 encodings of filenames as octet
+   sequences.
+
+   Note that this encoding is unrelated to that of the contents of the
+   file, even if the file contains character data.
+
+   Further information about filename encoding for FTP may be found in
+   "Internationalization of the File Transfer Protocol" [7].
+
+8.3.1. Notes about the Filename
+
+   The filename returned in the MLST response should be the same name as
+   was specified in the MLST command, or, where TVFS is supported, a
+   fully qualified TVFS path naming the same file.  Where no argument
+   was given to the MLST command, the server-PI may either include an
+   empty filename in the response, or it may supply a name that refers
+   to the current directory, if such a name is available.  Where TVFS is
+   supported, a fully qualified path name of the current directory
+   SHOULD be returned.
+
+   Filenames returned in the output from an MLSD command SHOULD be
+   unqualified names within the directory named, or the current
+   directory if no argument was given.  That is, the directory named in
+   the MLSD command SHOULD NOT appear as a component of the filenames
+   returned.
+
+   If the server-FTP process is able, and the "type" fact is being
+   returned, it MAY return in the MLSD response, an entry whose type is
+   "cdir", which names the directory from which the contents of the
+   listing were obtained.  Where TVFS is supported, the name MAY be the
+   fully qualified path name of the directory, or MAY be any other path
+   name which is valid to refer to that directory from the current
+   working directory of the server-FTP.  Where more than one name
+   exists, multiple of these entries may be returned.  In a sense, the
+   "cdir" entry can be viewed as a heading for the MLSD output.
+   However, it is not required to be the first entry returned, and may
+   occur anywhere within the listing.
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 32]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   When TVFS is supported, a user-PI can refer to any file or directory
+   in the listing by combining a type "cdir" name, with the appropriate
+   name from the directory listing using the procedure defined in
+   section 7.2.
+
+   Alternatively, whether TVFS is supported or not, the user-PI can
+   issue a CWD command ([3]) giving a name of type "cdir" from the
+   listing returned, and from that point reference the files returned in
+   the MLSD response from which the cdir was obtained by using the
+   filename components of the listing.
+
+8.4. Format of Facts
+
+   The "facts" for a file in a reply to a MLSx command consist of
+   information about that file.  The facts are a series of keyword=value
+   pairs each followed by semi-colon (";") characters.  An individual
+   fact may not contain a semi-colon in its name or value.  The complete
+   series of facts may not contain the space character.  See the
+   definition or "RCHAR" in section 2.1 for a list of the characters
+   that can occur in a fact value.  Not all are applicable to all facts.
+
+   A sample of a typical series of facts would be: (spread over two
+   lines for presentation here only)
+
+        size=4161;lang=en-US;modify=19970214165800;create=19961001124534;
+        type=file;x.myfact=foo,bar;
+
+8.5. Standard Facts
+
+   This document defines a standard set of facts as follows:
+
+        size       -- Size in octets
+        modify     -- Last modification time
+        create     -- Creation time
+        type       -- Entry type
+        unique     -- Unique id of file/directory
+        perm       -- File permissions, whether read, write, execute is
+                      allowed for the login id.
+        lang       -- Language of the filename per IANA[12] registry.
+        media-type -- MIME media-type of file contents per IANA registry.
+        charset    -- Character set per IANA registry (if not UTF-8)
+
+   Fact names are case-insensitive.  Size, size, SIZE, and SiZe are the
+   same fact.
+
+   Further operating system specific keywords could be specified by
+   using the IANA operating system name as a prefix (examples only):
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 33]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        OS/2.ea   -- OS/2 extended attributes
+        MACOS.rf  -- MacIntosh resource forks
+        UNIX.mode -- Unix file modes (permissions)
+
+   Implementations may define keywords for experimental, or private use.
+   All such keywords MUST begin with the two character sequence "x.".
+   As type names are case independent, "x." and "X." are equivalent.
+   For example:
+
+        x.ver  -- Version information
+        x.desc -- File description
+        x.type -- File type
+
+8.5.1. The type Fact
+
+   The type fact needs a special description.  Part of the problem with
+   current practices is deciding when a file is a directory.  If it is a
+   directory, is it the current directory, a regular directory, or a
+   parent directory?  The MLST specification makes this unambiguous
+   using the type fact.  The type fact given specifies information about
+   the object listed on the same line of the MLST response.
+
+   Five values are possible for the type fact:
+
+        file         -- a file entry
+        cdir         -- the listed directory
+        pdir         -- a parent directory
+        dir          -- a directory or sub-directory
+        OS.name=type -- an OS or file system dependent file type
+
+   The syntax is defined to be:
+
+        type-fact       = type-label "=" type-val
+        type-label      = "Type"
+        type-val        = "File" / "cdir" / "pdir" / "dir" /
+                          os-type
+
+8.5.1.1. type=file
+
+   The presence of the type=file fact indicates the listed entry is a
+   file containing non-system data.  That is, it may be transferred from
+   one system to another of quite different characteristics, and perhaps
+   still be meaningful.
+
+8.5.1.2. type=cdir
+
+   The type=cdir fact indicates the listed entry contains a pathname of
+   the directory whose contents are listed.  An entry of this type will
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 34]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   only be returned as a part of the result of an MLSD command when the
+   type fact is included, and provides a name for the listed directory,
+   and facts about that directory.  In a sense, it can be viewed as
+   representing the title of the listing, in a machine friendly format.
+   It may appear at any point of the listing, it is not restricted to
+   appearing at the start, though frequently may do so, and may occur
+   multiple times.  It MUST NOT be included if the type fact is not
+   included, or there would be no way for the user-PI to distinguish the
+   name of the directory from an entry in the directory.
+
+   Where TVFS is supported by the server-FTP, this name may be used to
+   construct path names with which to refer to the files and directories
+   returned in the same MLSD output (see section 7.2).  These path names
+   are only expected to work when the server-PI's position in the NVFS
+   file tree is the same as its position when the MLSD command was
+   issued, unless a fully qualified path name results.
+
+   Where TVFS is not supported, the only defined semantics associated
+   with a "type=cdir" entry are that, provided the current working
+   directory of the server-PI has not been changed, a pathname of type
+   "cdir" may be used as an argument to a CWD command, which will cause
+   the current directory of the server-PI to change so that the
+   directory which was listed in its current working directory.
+
+8.5.1.3. type=dir
+
+   If present, the type=dir entry gives the name of a directory.  Such
+   an entry typically cannot be transferred from one system to another
+   using RETR, etc, but should (permissions permitting) be able to be
+   the object of an MLSD command.
+
+8.5.1.4. type=pdir
+
+   If present, which will occur only in the response to a MLSD command
+   when the type fact is included, the type=pdir entry represents a
+   pathname of the parent directory of the listed directory.  As well as
+   having the properties of a type=dir, a CWD command that uses the
+   pathname from this entry should change the user to a parent directory
+   of the listed directory.  If the listed directory is the current
+   directory, a CDUP command may also have the effect of changing to the
+   named directory.  User-FTP processes should note not all responses
+   will include this information, and that some systems may provide
+   multiple type=pdir responses.
+
+   Where TVFS is supported, a "type=pdir" name may be a relative path
+   name, or a fully qualified path name.  A relative path name will be
+   relative to the directory being listed, not to the current directory
+   of the server-PI at the time.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 35]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   For the purposes of this type value, a "parent directory" is any
+   directory in which there is an entry of type=dir which refers to the
+   directory in which the type=pdir entity was found.  Thus it is not
+   required that all entities with type=pdir refer to the same
+   directory.  The "unique" fact (if supported) can be used to determine
+   whether there is a relationship between the type=pdir entries or not.
+
+8.5.1.5. System defined types
+
+   Files types that are specific to a specific operating system, or file
+   system, can be encoded using the "OS." type names.  The format is:
+
+        os-type   = "OS." os-name "=" os-type
+        os-name   = <an IANA registered operating system name>
+        os-type   = token
+
+   The "os-name" indicates the specific system type which supports the
+   particular localtype.  OS specific types are registered by the IANA
+   using the procedures specified in section 11.  The "os-type" provides
+   the system dependent information as to the type of the file listed.
+   The os-name and os-type strings in an os-type are case independent.
+   "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or
+   would, if such a type were registered.)
+
+   Note: Where the underlying system supports a file type which is
+   essentially an indirect pointer to another file, the NVFS
+   representation of that type should normally be to represent the file
+   which the reference indicates.  That is, the underlying basic file
+   will appear more than once in the NVFS, each time with the "unique"
+   fact (see immediately following section) containing the same value,
+   indicating that the same file is represented by all such names.
+   User-PIs transferring the file need then transfer it only once, and
+   then insert their own form of indirect reference to construct
+   alternate names where desired, or perhaps even copy the local file if
+   that is the only way to provide two names with the same content.  A
+   file which would be a reference to another file, if only the other
+   file actually existed, may be represented in any OS dependent manner
+   appropriate, or not represented at all.
+
+8.5.1.6. Multiple types
+
+   Where a file is such that it may validly, and sensibly, treated by
+   the server-PI as being of more than one of the above types, then
+   multiple entries should be returned, each with its own "Type" fact of
+   the appropriate type, and each containing the same pathname.  This
+   may occur, for example, with a structured file, which may contain
+   sub-files, and where the server-PI permits the structured file to be
+   treated as a unit, or treated as a directory allowing the sub-files
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 36]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   within it to be referenced.
+
+8.5.2. The unique Fact
+
+   The unique fact is used to present a unique identifier for a file or
+   directory in the NVFS accessed via a server-FTP process.  The value
+   of this fact should be the same for any number of pathnames that
+   refer to the same underlying file.  The fact should have different
+   values for names which reference distinct files.  The mapping between
+   files, and unique fact tokens should be maintained, and remain
+   consistent, for at least the lifetime of the control connection from
+   user-PI to server-PI.
+
+        unique-fact  = "Unique" "=" token
+
+   This fact would be expected to be used by Server-FTPs whose host
+   system allows things such as symbolic links so that the same file may
+   be represented in more than one directory on the server.  The only
+   conclusion that should be drawn is that if two different names each
+   have the same value for the unique fact, they refer to the same
+   underlying object.  The value of the unique fact (the token) should
+   be considered an opaque string for comparison purposes, and is a case
+   dependent value.  The tokens "A" and "a" do not represent the same
+   underlying object.
+
+8.5.3. The modify Fact
+
+   The modify fact is used to determine the last time the content of the
+   file (or directory) indicated was modified.  Any change of substance
+   to the file should cause this value to alter.  That is, if a change
+   is made to a file such that the results of a RETR command would
+   differ, then the value of the modify fact should alter.  User-PIs
+   should not assume that a different modify fact value indicates that
+   the file contents are necessarily different than when last retrieved.
+   Some systems may alter the value of the modify fact for other
+   reasons, though this is discouraged wherever possible.  Also a file
+   may alter, and then be returned to its previous content, which would
+   often be indicated as two incremental alterations to the value of the
+   modify fact.
+
+   For directories, this value should alter whenever a change occurs to
+   the directory such that different filenames would (or might) be
+   included in MLSD output of that directory.
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 37]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        modify-fact  = "Modify" "=" time-val
+
+8.5.4. The create Fact
+
+   The create fact indicates when a file, or directory, was first
+   created.  Exactly what "creation" is for this purpose is not
+   specified here, and may vary from server to server.  About all that
+   can be said about the value returned is that it can never indicate a
+   later time than the modify fact.
+
+        create-fact  = "Create" "=" time-val
+
+   Implementation Note: Implementors of this fact on UNIX(TM) systems
+        should note that the unix "stat" "st_ctime" field does not give
+        creation time, and that unix file systems do not record creation
+        time at all.  Unix (and POSIX) implementations will normally not
+        include this fact.
+
+8.5.5. The perm Fact
+
+   The perm fact is used to indicate access rights the current FTP user
+   has over the object listed.  Its value is always an unordered
+   sequence of alphabetic characters.
+
+        perm-fact    = "Perm" "=" *pvals
+        pvals        = "a" / "c" / "d" / "e" / "f" /
+                       "l" / "m" / "p" / "r" / "w"
+
+   There are ten permission indicators currently defined.  Many are
+   meaningful only when used with a particular type of object.  The
+   indicators are case independent, "d" and "D" are the same indicator.
+
+   The "a" permission applies to objects of type=file, and indicates
+   that the APPE (append) command may be applied to the file named.
+
+   The "c" permission applies to objects of type=dir (and type=pdir,
+   type=cdir).  It indicates that files may be created in the directory
+   named.  That is, that a STOU command is likely to succeed, and that
+   STOR and APPE commands might succeed if the file named did not
+   previously exist, but is to be created in the directory object that
+   has the "c" permission.  It also indicates that the RNTO command is
+   likely to succeed for names in the directory.
+
+   The "d" permission applies to all types.  It indicates that the
+   object named may be deleted, that is, that the RMD command may be
+   applied to it if it is a directory, and otherwise that the DELE
+   command may be applied to it.
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 38]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   The "e" permission applies to the directory types.  When set on an
+   object of type=dir, type=cdir, or type=pdir it indicates that a CWD
+   command naming the object should succeed, and the user should be able
+   to enter the directory named.  For type=pdir it also indicates that
+   the CDUP command may succeed (if this particular pathname is the one
+   to which a CDUP would apply.)
+
+   The "f" permission for objects indicates that the object named may be
+   renamed - that is, may be the object of an RNFR command.
+
+   The "l" permission applies to the directory file types, and indicates
+   that the listing commands, LIST, NLST, and MLSD may be applied to the
+   directory in question.
+
+   The "m" permission applies to directory types, and indicates that the
+   MKD command may be used to create a new directory within the
+   directory under consideration.
+
+   The "p" permission applies to directory types, and indicates that
+   objects in the directory may be deleted, or (stretching naming a
+   little) that the directory may be purged.  Note: it does not indicate
+   that the RMD command may be used to remove the directory named
+   itself, the "d" permission indicator indicates that.
+
+   The "r" permission applies to type=file objects, and for some
+   systems, perhaps to other types of objects, and indicates that the
+   RETR command may be applied to that object.
+
+   The "w" permission applies to type=file objects, and for some
+   systems, perhaps to other types of objects, and indicates that the
+   STOR command may be applied to the object named.
+
+   Note: That a permission indicator is set can never imply that the
+        appropriate command is guaranteed to work - just that it might.
+        Other system specific limitations, such as limitations on
+        available space for storing files, may cause an operation to
+        fail, where the permission flags may have indicated that it was
+        likely to succeed.  The permissions are a guide only.
+
+   Implementation note: The permissions are described here as they apply
+        to FTP commands.  They may not map easily into particular
+        permissions available on the server's operating system.  Servers
+        are expected to synthesize these permission bits from the
+        permission information available from operating system.  For
+        example, to correctly determine whether the "D" permission bit
+        should be set on a directory for a server running on the
+        UNIX(TM) operating system, the server should check that the
+        directory named is empty, and that the user has write permission
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 39]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        on both the directory under consideration, and its parent
+        directory.
+
+        Some systems may have more specific permissions than those
+        listed here, such systems should map those to the flags defined
+        as best they are able.  Other systems may have only more broad
+        access controls.  They will generally have just a few possible
+        permutations of permission flags, however they should attempt to
+        correctly represent what is permitted.
+
+8.5.6. The lang Fact
+
+   The lang fact describes the natural language of the filename for use
+   in display purposes.  Values used here should be taken from the
+   language registry of the IANA.  See [13] for the syntax, and
+   procedures, related to language tags.
+
+        lang-fact  = "Lang" "=" token
+
+   Server-FTP implementations MUST NOT guess language values.  Language
+   values must be determined in an unambiguous way such as file system
+   tagging of language or by user configuration.  Note that the lang
+   fact provides no information at all about the content of a file, only
+   about the encoding of its name.
+
+8.5.7. The size Fact
+
+   The size fact applies to non-directory file types and should always
+   reflect the approximate size of the file.  This should be as accurate
+   as the server can make it, without going to extraordinary lengths,
+   such as reading the entire file.  The size is expressed in units of
+   octets of data in the file.
+
+   Given limitations in some systems, Client-FTP implementations must
+   understand this size may not be precise and may change between the
+   time of a MLST and RETR operation.
+
+   Clients that need highly accurate size information for some
+   particular reason should use the SIZE command as defined in section
+   4.  The most common need for this accuracy is likely to be in
+   conjunction with the REST command described in section 5.  The size
+   fact, on the other hand, should be used for purposes such as
+   indicating to a human user the approximate size of the file to be
+   transferred, and perhaps to give an idea of expected transfer
+   completion time.
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 40]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        size-fact  = "Size" "=" 1*DIGIT
+
+8.5.8. The media-type Fact
+
+   The media-type fact represents the IANA media type of the file named,
+   and applies only to non-directory types.  The list of values used
+   must follow the guidelines set by the IANA registry.
+
+        media-type  = "Media-Type" "=" <per IANA guidelines>
+
+   Server-FTP implementations MUST NOT guess media type values.  Media
+   type values must be determined in an unambiguous way such as file
+   system tagging of media-type or by user configuration.  This fact
+   gives information about the content of the file named.  Both the
+   primary media type, and any appropriate subtype should be given,
+   separated by a slash "/" as is traditional.
+
+8.5.9. The charset Fact
+
+   The charset fact provides the IANA character set name, or alias, for
+   the encoded pathnames in a MLSx response.  The default character set
+   is UTF-8 unless specified otherwise.  FTP implementations SHOULD use
+   UTF-8 if possible to encourage maximum interoperability.  The value
+   of this fact applies to the pathname only, and provides no
+   information about the contents of the file.
+
+        charset-type  = "Charset" "=" token
+
+8.5.10. Required facts
+
+   Servers are not required to support any particular set of the
+   available facts.  However, servers SHOULD, if conceivably possible,
+   support at least the type, perm, size, unique, and modify facts.
+
+8.6. System Dependent and Local Facts
+
+   By using an system dependent fact, or a local fact, a server-PI may
+   communicate to the user-PI information about the file named which is
+   peculiar to the underlying file system.
+
+8.6.1. System Dependent Facts
+
+   System dependent fact names are labeled by prefixing a label
+   identifying the specific information returned by the name of the
+   appropriate operating system from the IANA maintained list of
+   operating system names.
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 41]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   The value of an OS dependent fact may be whatever is appropriate to
+   convey the information available.  It must be encoded as a "token" as
+   defined in section 2.1 however.
+
+   In order to allow reliable interoperation between users of system
+   dependent facts, the IANA will maintain a registry of system
+   dependent fact names, their syntax, and the interpretation to be
+   given to their values.  Registrations of system dependent facts are
+   to be accomplished according to the procedures of section 11.
+
+8.6.2. Local Facts
+
+   Implementations may also make available other facts of their own
+   choosing.  As the method of interpretation of such information will
+   generally not be widely understood, server-PIs should be aware that
+   clients will typically ignore any local facts provided.  As there is
+   no registration of locally defined facts, it is entirely possible
+   that different servers will use the same local fact name to provide
+   vastly different information.  Hence user-PIs should be hesitant
+   about making any use of any information in a locally defined fact
+   without some other specific assurance that the particular fact is one
+   that they do comprehend.
+
+   Local fact names all begin with the sequence "X.".  The rest of the
+   name is a "token" (see section 2.1).  The value of a local fact can
+   be anything at all, provided it can be encoded as a "token".
+
+8.7. MLSx Examples
+
+   The following examples are all taken from dialogues between existing
+   FTP clients and servers.  Because of this, not all possible
+   variations of possible response formats are shown in the examples.
+   This should not be taken as limiting the options of other server
+   implementors.  Where the examples show OS dependent information, that
+   is to be treated as being purely for the purposes of demonstration of
+   some possible OS specific information that could be defined.  As at
+   the time of the writing of this document, no OS specific facts or
+   file types have been defined, the examples shown here should not be
+   treated as in any way to be preferred over other possible similar
+   definitions.  Consult the IANA registries to determine what types and
+   facts have been defined.
+
+   In the examples shown, only relevant commands and responses have been
+   included.  This is not to imply that other commands (including
+   authentication, directory modification, PORT or PASV commands, or
+   similar) would not be present in an actual connection, or were not,
+   in fact, actually used in the examples before editing.  Note also
+   that the formats shown are those that are transmitted between client
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 42]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   and server, not formats which would normally ever be reported to the
+   user of the client.
+
+   In the examples, lines that begin "C> " were sent over the control
+   connection from the client to the server, lines that begin "S> " were
+   sent over the control connection from the server to the client, and
+   lines that begin "D> " were sent from the server to the client over a
+   data connection created just to send those lines and closed
+   immediately after.  No examples here show data transferred over a
+   data connection from the client to the server.  In all cases, the
+   prefixes shown above, including the one space, have been added for
+   the purposes of this document, and are not a part of the data
+   exchanged between client and server.
+
+8.7.1. Simple MLST
+
+ C> PWD
+ S> 257 "/tmp" is current directory.
+ C> MLst cap60.pl198.tar.gz
+ S> 250- Listing cap60.pl198.tar.gz
+ S>  Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz
+ S> 250 End
+
+   The client first asked to be told the current directory of the
+   server.  This was purely for the purposes of clarity of this example.
+   The client then requested facts about a specific file.  The server
+   returned the "250-" first control-response line, followed by a single
+   line of facts about the file, followed by the terminating "250 "
+   line.  The text on the control-response line and the terminating line
+   can be anything the server decides to send.  Notice that the fact
+   line is indented by a single space.  Notice also that there are no
+   spaces in the set of facts returned, until the single space before
+   the filename.  The filename returned on the fact line is a fully
+   qualified pathname of the file listed.  The facts returned show that
+   the line refers to a file, that file contains approximately 1024990
+   bytes, though more or less than that may be transferred if the file
+   is retrieved, and a different number may be required to store the
+   file at the client's file store, and the connected user has
+   permission to retrieve the file but not to do anything else
+   particularly interesting.
+
+8.7.2. MLST of a directory
+
+ C> PWD
+ S> 257 "/" is current directory.
+ C> MLst tmp
+ S> 250- Listing tmp
+ S>  Type=dir;Modify=19981107085215;Perm=el; /tmp
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 43]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+ S> 250 End
+
+   Again the PWD is just for the purposes of demonstration for the
+   example.  The MLST fact line this time shows that the file listed is
+   a directory, that it was last modified at 08:52:15 on the 7th of
+   November, 1998 UTC, and that the user has permission to enter the
+   directory, and to list its contents, but not to modify it in any way.
+   Again, the fully qualified path name of the directory listed is
+   given.
+
+8.7.3. MLSD of a directory
+
+ C> MLSD tmp
+ S> 150 BINARY connection open for MLSD tmp
+ D> Type=cdir;Modify=19981107085215;Perm=el; tmp
+ D> Type=cdir;Modify=19981107085215;Perm=el; /tmp
+ D> Type=pdir;Modify=19990112030508;Perm=el; ..
+ D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z
+ D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c
+ D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt
+ D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch
+ D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx
+ D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif
+ D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx
+ D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx
+ D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx
+ D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz
+ S> 226 MLSD completed
+
+   In this example notice that there is no leading space on the fact
+   lines returned over the data connection.  Also notice that two lines
+   of "type=cdir" have been given.  These show two alternate names for
+   the directory listed, one a fully qualified pathname, and the other a
+   local name relative to the servers current directory when the MLSD
+   was performed.  Note that all other filenames in the output are
+   relative to the directory listed, though the server could, if it
+   chose, give a fully qualified path name for the "type=pdir" line.
+   This server has chosen not to.  The other files listed present a
+   fairly boring set of files that are present in the listed directory.
+   Note that there is no particular order in which they are listed.
+   They are not sorted by filename, by size, or by modify time.  Note
+   also that the "perm" fact has an empty value for the file
+   "capmux.tar.z" indicating that the connected user has no permissions
+   at all for that file.  This server has chosen to present the "cdir"
+   and "pdir" lines before the lines showing the content of the
+   directory, it is not required to do so.  The "size" fact does not
+   provide any meaningful information for a directory, so is not
+   included in the fact lines for the directory types shown.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 44]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+8.7.4. A more complex example
+
+ C> MLst test
+ S> 250- Listing test
+ S>  Type=dir;Perm=el;Unique=keVO1+ZF4 test
+ S> 250 End
+ C> MLSD test
+ S> 150 BINARY connection open for MLSD test
+ D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
+ D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
+ D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
+ D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device
+ D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block
+ D> Type=file;Perm=awr;Unique=keVO1+8G4; writable
+ D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous
+ D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec
+ D> Type=file;Perm=r;Unique=keVO1+EG4; two words
+ D> Type=file;Perm=r;Unique=keVO1+IH4;  leading space
+ D> Type=file;Perm=r;Unique=keVO1+1G4; file1
+ D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming
+ D> Type=file;Perm=r;Unique=keVO1+1G4; file2
+ D> Type=file;Perm=r;Unique=keVO1+1G4; file3
+ D> Type=file;Perm=r;Unique=keVO1+1G4; file4
+ S> 226 MLSD completed
+ C> MLSD test/incoming
+ S> 150 BINARY connection open for MLSD test/incoming
+ D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming
+ D> Type=pdir;Perm=el;Unique=keVO1+ZF4; ..
+ D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar
+ D> Type=file;Perm=awdrf;Unique=keVO1+LH4;
+ D> Type=file;Perm=rf;Unique=keVO1+1G4; file5
+ D> Type=file;Perm=rf;Unique=keVO1+1G4; file6
+ D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty
+ S> 226 MLSD completed
+
+   For the purposes of this example the fact set requested has been
+   modified to delete the "size" and "modify" facts, and add the
+   "unique" fact.  First, facts about a filename have been obtained via
+   MLST.  Note that no fully qualified path name was given this time.
+   That was because the server was unable to determine that information.
+   Then having determined that the filename represents a directory, that
+   directory has been listed.  That listing also shows no fully
+   qualified path name, for the same reason, thus has but a single
+   "type=cdir" line.  This directory (which was created especially for
+   the purpose) contains several interesting files.  There are some with
+   OS dependent file types, several sub-directories, and several
+   ordinary files.
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 45]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   Not much can be said here about the OS dependent file types, as none
+   of the information shown there should be treated as any more than
+   possibilities.  It can be seen that the OS type of the server is
+   "unix" though, which is one of the OS types in the IANA registry of
+   Operating System names.
+
+   Of the three directories listed, "no-exec" has no permission granted
+   to this user to access at all.  From the "Unique" fact values, it can
+   be determined that "promiscuous" and "incoming" in fact represent the
+   same directory.  Its permissions show that the connected user has
+   permission to do essentially anything other than to delete the
+   directory.  That directory was later listed.  It happens that the
+   directory can not be deleted because it is not empty.
+
+   Of the normal files listed, two contain spaces in their names.  The
+   file called " leading space" actually contains two spaces in its
+   name, one before the "l" and one between the "g" and the "s".  The
+   two spaces that separate the facts from the visible part of the path
+   name make that clear.  The file "writable" has the "a" and "w"
+   permission bits set, and consequently the connected user should be
+   able to STOR or APPE to that file.
+
+   The other four file names, "file1", "file2", "file3", and "file4" all
+   represent the same underlying file, as can be seen from the values of
+   the "unique" facts of each.  It happens that "file1" and "file2" are
+   Unix "hard" links, and that "file3" and "file4" are "soft" or
+   "symbolic" links to the first two.  None of that information is
+   available via standard MLST facts, it is sufficient for the purposes
+   of FTP to note that all represent the same file, and that the same
+   data would be fetched no matter which of them was retrieved, and that
+   all would be simultaneously modified were data stored in any.
+
+   Finally, the sub-directory "incoming" is listed.  Since "promiscuous"
+   is the same directory there would be no point listing it as well.  In
+   that directory, the files "file5" and "file6" represent still more
+   names for the "file1" file we have seen before.  Notice the entry
+   between that for "bar" and "file5".  Though it is not possible to
+   easily represent it in this document, that shows a file with a name
+   comprising exactly three spaces ("   ").  A client will have no
+   difficulty determining that name from the output presented to it
+   however.  The directory "empty" is, as its name implies, empty,
+   though that is not shown here.  It can, however, be deleted, as can
+   file "bar" and the file whose name is three spaces.  All the files
+   that reside in this directory can be renamed.  This is a consequence
+   of the UNIX semantics of the directory that contains them being
+   modifiable.
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 46]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+8.7.5. More accurate time information
+
+ C> MLst file1
+ S> 250- Listing file1
+ S>  Type=file;Modify=19990929003355.237; file1
+ S> 250 End
+
+   In this example, the server-FTP is indicating that "file1" was last
+   modified 237 milliseconds after 00:33:55 UTC on the 29th of
+   September, 1999.
+
+8.7.6. A different server
+
+ C> MLST
+ S> 250-Begin
+ S>  type=dir;unique=AQkAAAAAAAABCAAA; /
+ S> 250 End.
+ C> MLSD .
+ S> 150 Opening ASCII mode data connection for MLS.
+ D> type=cdir;unique=AQkAAAAAAAABCAAA; /
+ D> type=dir;unique=AQkAAAAAAAABEAAA; bin
+ D> type=dir;unique=AQkAAAAAAAABGAAA; etc
+ D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife
+ D> type=dir;unique=AQkAAAAAAAABoAAA; incoming
+ D> type=dir;unique=AQkAAAAAAAABIAAA; lib
+ D> type=dir;unique=AQkAAAAAAAABWAEA; linux
+ D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd
+ D> type=dir;unique=AQkAAAAAAAABGAEA; outbox
+ D> type=dir;unique=AQkAAAAAAAABuAAA; quake2
+ D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff
+ S> 226 Listing completed.
+ C> MLSD linux
+ S> 150 Opening ASCII mode data connection for MLS.
+ D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux
+ D> type=pdir;unique=AQkAAAAAAAABCAAA; /
+ D> type=dir;unique=AQkAAAAAAAABeAEA; firewall
+ D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world
+ D> type=dir;unique=AQkAAAAAAAABYAEA; kernel
+ D> type=dir;unique=AQkAAAAAAAABmAEA; scripts
+ D> type=dir;unique=AQkAAAAAAAABkAEA; security
+ S> 226 Listing completed.
+ C> MLSD linux/kernel
+ S> 150 Opening ASCII mode data connection for MLS.
+ D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel
+ D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux
+ D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config
+ D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz
+ D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 47]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+ S> 226 Listing completed.
+
+   Note that this server returns its "unique" fact value in quite a
+   different format.  It also returns fully qualified path names for the
+   "pdir" entry.
+
+8.7.7. Some IANA files
+
+ C> MLSD .
+ S> 150 BINARY connection open for MLSD .
+ D> Type=cdir;Modify=19990219183438; /iana/assignments
+ D> Type=pdir;Modify=19990112030453; ..
+ D> Type=dir;Modify=19990219073522; media-types
+ D> Type=dir;Modify=19990112033515; character-set-info
+ D> Type=dir;Modify=19990112033529; languages
+ D> Type=file;Size=44242;Modify=19990217230400; character-sets
+ D> Type=file;Size=1947;Modify=19990209215600; operating-system-names
+ S> 226 MLSD completed
+ C> MLSD media-types
+ S> 150 BINARY connection open for MLSD media-types
+ D> Type=cdir;Modify=19990219073522; media-types
+ D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types
+ D> Type=pdir;Modify=19990219183438; ..
+ D> Type=dir;Modify=19990112033045; text
+ D> Type=dir;Modify=19990219183442; image
+ D> Type=dir;Modify=19990112033216; multipart
+ D> Type=dir;Modify=19990112033254; video
+ D> Type=file;Size=30249;Modify=19990218032700; media-types
+ S> 226 MLSD completed
+ C> MLSD character-set-info
+ S> 150 BINARY connection open for MLSD character-set-info
+ D> Type=cdir;Modify=19990112033515; character-set-info
+ D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info
+ D> Type=pdir;Modify=19990219183438; ..
+ D> Type=file;Size=1234;Modify=19980903020400; windows-1251
+ D> Type=file;Size=4557;Modify=19980922001400; tis-620
+ D> Type=file;Size=801;Modify=19970324130000; ibm775
+ D> Type=file;Size=552;Modify=19970320130000; ibm866
+ D> Type=file;Size=922;Modify=19960505140000; windows-1258
+ S> 226 MLSD completed
+ C> MLSD languages
+ S> 150 BINARY connection open for MLSD languages
+ D> Type=cdir;Modify=19990112033529; languages
+ D> Type=cdir;Modify=19990112033529; /iana/assignments/languages
+ D> Type=pdir;Modify=19990219183438; ..
+ D> Type=file;Size=2391;Modify=19980309130000; default
+ D> Type=file;Size=943;Modify=19980309130000; tags
+ D> Type=file;Size=870;Modify=19971026130000; navajo
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 48]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+ D> Type=file;Size=699;Modify=19950911140000; no-bok
+ S> 226 MLSD completed
+ C> PWD
+ S> 257 "/iana/assignments" is current directory.
+
+   This example shows some of the IANA maintained files that are
+   relevant for this specification in MLSD format.  Note that these
+   listings have been edited by deleting many entries, the actual
+   listings are much longer.
+
+8.7.8. A stress test of case (in)dependence
+
+   The following example is intended to make clear some cases where case
+   dependent strings are permitted in the MLSx commands, and where case
+   independent strings are required.
+
+ C> MlsD .
+ S> 150 BINARY connection open for MLSD .
+ D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; ..
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
+ D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
+ S> 226 MLSD completed
+
+   Note first that the "MLSD" command, shown here as "MlsD" is case
+   independent.  Clients may issue this command in any case, or
+   combination of cases, they desire.  This is the case for all FTP
+   commands.
+
+   Next, notice the labels of the facts.  These are also case
+   independent strings, Server-FTP is permitted to return them in any
+   case they desire.  User-FTP must be prepared to deal with any case,
+   though it may do this by mapping the labels to a common case if
+   desired.
+
+   Then, notice that there are nine objects of "type" file returned.  In
+   a case independent NVFS these would represent three different file
+   names, "file1", "file2", and "file3".  With a case dependent NVFS all
+   nine represent different file names.  Either is possible, server-FTPs
+   may implement a case dependent or a case independent NVFS.  User-FTPs
+   must allow for case dependent selection of files to manipulate on the
+   server.
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 49]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   Lastly, notice that the value of the "unique" fact is case dependent.
+   In the example shown, "file1", "File1", and "file2" all have the same
+   "unique" fact value "keVO1+bD8", and thus all represent the same
+   underlying file.  On the other hand, "FILE1" has a different "unique"
+   fact value ("keVO1+bd8") and hence represents a different file.
+   Similarly, "FILE2" and "File2" are two names for the same underlying
+   file, whereas "file3", "File3" and "FILE3" all represent different
+   underlying files.
+
+   That the approximate sizes ("size" fact) and last modification times
+   ("modify" fact) are the same in all cases might be no more than a
+   coincidence.
+
+   It is not suggested that the operators of server-FTPs create NVFS
+   which stress the protocols to this extent, however both user and
+   server implementations must be prepared to deal with such extreme
+   examples.
+
+8.8. FEAT response for MLSx
+
+   When responding to the FEAT command, a server-FTP process that
+   supports MLST, and MLSD, plus internationalization of pathnames, MUST
+   indicate that this support exists.  It does this by including a MLST
+   feature line.  As well as indicating the basic support, the MLST
+   feature line indicates which MLST facts are available from the
+   server, and which of those will be returned if no subsequent "OPTS
+   MLST" command is sent.
+
+        mlst-feat     = SP "MLST" [SP factlist] CRLF
+        factlist      = 1*( factname ["*"] ";" )
+
+   The initial space shown in the mlst-feat response is that required by
+   the FEAT command, two spaces are not permitted.  If no factlist is
+   given, then the server-FTP process is indicating that it supports
+   MLST, but implements no facts.  Only pathnames can be returned.  This
+   would be a minimal MLST implementation, and useless for most
+   practical purposes.  Where the factlist is present, the factnames
+   included indicate the facts supported by the server.  Where the
+   optional asterisk appears after a factname, that fact will be
+   included in MLST format responses, until an "OPTS MLST" is given to
+   alter the list of facts returned.  After that, subsequent FEAT
+   commands will return the asterisk to show the facts selected by the
+   most recent "OPTS MLST".
+
+   Note that there is no distinct FEAT output for MLSD.  The presence of
+   the MLST feature indicates that both MLST and MLSD are supported.
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 50]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+8.8.1. Examples
+
+ C> Feat
+ S> 211- Features supported
+ S>  REST STREAM
+ S>  MDTM
+ S>  SIZE
+ S>  TVFS
+ S>  UTF8
+ S>  MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+
+   Aside from some features irrelevant here, this server indicates that
+   it supports MLST including several, but not all, standard facts, all
+   of which it will send by default.  It also supports two OS dependent
+   facts, and one locally defined fact.  The latter three must be
+   requested expressly by the client for this server to supply them.
+
+ C> Feat
+ S> 211-Extensions supported:
+ S>  CLNT
+ S>  MDTM
+ S>  MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.group;unique;
+ S>  PASV
+ S>  REST STREAM
+ S>  SIZE
+ S>  TVFS
+ S>  Compliance Level: 19981201 (IETF mlst-05)
+ S> 211 End.
+
+   Again, in addition to some irrelevant features here, this server
+   indicates that it supports MLST, four of the standard facts, one of
+   which ("unique") is not enabled by default, and several OS dependent
+   facts, one of which is provided by the server by default.  This
+   server actually supported more OS dependent facts.  Others were
+   deleted for the purposes of this document to comply with document
+   formatting restrictions.
+
+8.9. OPTS parameters for MLST
+
+   For the MLSx commands, the Client-FTP may specify a list of facts it
+   wishes to be returned in all subsequent MLSx commands until another
+   OPTS MLST command is sent.  The format is specified by:
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 51]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+        mlst-opts     = "OPTS" SP "MLST"
+                        [ SP 1*( factname ";" ) ]
+
+   By sending the "OPTS MLST" command, the client requests the server to
+   include only the facts listed as arguments to the command in
+   subsequent output from MLSx commands.  Facts not included in the
+   "OPTS MLST" command MUST NOT be returned by the server.  Facts that
+   are included should be returned for each entry returned from the MLSx
+   command where they meaningfully apply.  Facts requested that are not
+   supported, or which are inappropriate to the file or directory being
+   listed should simply be omitted from the MLSx output.  This is not an
+   error.  Note that where no factname arguments are present, the client
+   is requesting that only the file names be returned.  In this case,
+   and in any other case where no facts are included in the result, the
+   space that separates the fact names and their values from the file
+   name is still required.  That is, the first character of the output
+   line will be a space, (or two characters will be spaces when the line
+   is returned over the control connection,) and the file name will
+   start immediately thereafter.
+
+   Clients should note that generating values for some facts can be
+   possible, but very expensive, for some servers.  It is generally
+   acceptable to retrieve any of the facts that the server offers as its
+   default set before any "OPTS MLST" command has been given, however
+   clients should use particular caution before requesting any facts not
+   in that set.  That is, while other facts may be available from the
+   server, clients should refrain from requesting such facts unless
+   there is a particular operational requirement for that particular
+   information, which ought be more significant than perhaps simply
+   improving the information displayed to an end user.
+
+   Note, there is no "OPTS MLSD" command, the fact names set with the
+   "OPTS MLST" command apply to both MLST and MLSD commands.
+
+   Servers are not required to accept "OPTS MLST" commands before
+   authentication of the user-PI, but may choose to permit them.
+
+8.9.1. OPTS MLST Response
+
+   The "response-message" from [6] to a successful OPTS MLST command has
+   the following syntax.
+
+        mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ]
+
+   This defines the "response-message" as used in the "opts-good"
+   message in RFC2389 [6].
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 52]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   The facts named in the response are those which the server will now
+   include in MLST (and MLSD) response, after the processing of the
+   "OPTS MLST" command.  Any facts from the request not supported by the
+   server will be omitted from this response message.  If no facts will
+   be included, the list of facts will be empty.  Note that the list of
+   facts returned will be the same as those marked by a trailing
+   asterisk ("*") in a subsequent FEAT command response.  There is no
+   requirement that the order of the facts returned be the same as that
+   in which they were requested, or that in which they will be listed in
+   a FEAT command response, or that in which facts are returned in MLST
+   responses.  The fixed string "MLST OPTS" in the response may be
+   returned in any case, or mixture of cases.
+
+8.9.2. Examples
+
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+ C> OptS Mlst Type;UNIX.mode;Perm;
+ S> 201 MLST OPTS Type;Perm;UNIX.mode;
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type*;Size;Modify;Perm*;Unique;UNIX.mode*;UNIX.chgd;X.hidden;
+ S> 211 End
+ C> opts MLst lang;type;charset;create;
+ S> 201 MLST OPTS Type;
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+ C> OPTS mlst size;frogs;
+ S> 201 MLST OPTS Size;
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+ C> opts MLst unique type;
+ S> 501 Invalid MLST options
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+
+   For the purposes of this example, features other than MLST have been
+   deleted from the output to avoid clutter.  The example shows the
+   initial default feature output for MLST.  The facts requested are
+   then changed by the client.  The first change shows facts that are
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 53]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   available from the server being selected.  Subsequent FEAT output
+   shows the altered features as being returned.  The client then
+   attempts to select some standard features which the server does not
+   support.  This is not an error, however the server simply ignores the
+   requests for unsupported features, as the FEAT output that follows
+   shows.  Then, the client attempts to request a non-standard, and
+   unsupported, feature.  The server ignores that, and selects only the
+   supported features requested.  Lastly, the client sends a request
+   containing a syntax error (spaces cannot appear in the factlist.) The
+   server-FTP sends an error response and completely ignores the
+   request, leaving the fact set selected as it had been previously.
+
+   Note that in all cases, except the error response, the response lists
+   the facts that have been selected.
+
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+ C> Opts MLST
+ S> 201 MLST OPTS
+ C> Feat
+ S> 211- Features supported
+ S>  MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
+ S> 211 End
+ C> MLst tmp
+ S> 250- Listing tmp
+ S>   /tmp
+ S> 250 End
+ C> OPTS mlst unique;size;
+ S> 201 MLST OPTS Size;Unique;
+ C>  MLst tmp
+ S> 250- Listing tmp
+ S>  Unique=keVO1+YZ5; /tmp
+ S> 250 End
+ C> OPTS mlst unique;type;modify;
+ S> 201 MLST OPTS Type;Modify;Unique;
+ C> MLst tmp
+ S> 250- Listing tmp
+ S>  Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp
+ S> 250 End
+ C> OPTS mlst fish;cakes;
+ S> 201 MLST OPTS
+ C> MLst tmp
+ S> 250- Listing tmp
+ S>   /tmp
+ S> 250 End
+ C> OptS Mlst Modify;Unique;
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 54]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+ S> 201 MLST OPTS Modify;Unique;
+ C> MLst tmp
+ S> 250- Listing tmp
+ S>  Modify=19990930152225;Unique=keVO1+YZ5; /tmp
+ S> 250 End
+ C> opts MLst fish cakes;
+ S> 501 Invalid MLST options
+ C>  MLst tmp
+ S> 250- Listing tmp
+ S>  Modify=19990930152225;Unique=keVO1+YZ5; /tmp
+ S> 250 End
+
+   This example shows the effect of changing the facts requested upon
+   subsequent MLST commands.  Notice that a syntax error leaves the set
+   of selected facts unchanged.  Also notice exactly two spaces
+   preceding the pathname when no facts were selected, either
+   deliberately, or because none of the facts requested were available.
+
+9. Impact On Other FTP Commands
+
+   Along with the introduction of MLST, traditional FTP commands must be
+   extended to allow for the use of more than US-ASCII or EBCDIC
+   character sets.  In general, the support of MLST requires support for
+   arbitrary character sets wherever filenames and directory names are
+   allowed.  This applies equally to both arguments given to the
+   following commands and to the replies from them, as appropriate.
+
+        CWD
+        RETR
+        STOR
+        STOU
+        APPE
+        RNFR
+        RNTO
+        DELE
+        RMD
+        MKD
+        PWD
+        STAT
+
+   The arguments to all of these commands should be processed the same
+   way that MLST commands and responses are processed with respect to
+   handling embedded spaces, CRs and NULs.  See section 2.2.
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 55]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+10. Character sets and Internationalization
+
+   FTP commands are protocol elements, and are always expressed in
+   ASCII.  FTP responses are composed of the numeric code, which is a
+   protocol element, and a message, which is often expected to convey
+   information to the user.  It is not expected that users normally
+   interact directly with the protocol elements, rather the user FTP-
+   process constructs the commands, and interprets the results, in the
+   manner best suited for the particular user.  Explanatory text in
+   responses generally has no particular meaning to the protocol.  The
+   numeric codes provide all necessary information.  Server-PIs are free
+   to provide the text in any language that can be adequately
+   represented in ASCII, or where an alternative language and
+   representation has been negotiated (see [7]) in that language and
+   representation.
+
+   Pathnames are expected to be encoded in UTF-8 allowing essentially
+   any character to be represented in a pathname.  Meaningful pathnames
+   are defined by the server NVFS.
+
+   No restrictions at all are placed upon the contents of files
+   transferred using the FTP protocols.  Unless the "media-type" fact is
+   provided in a MLSx response nor is any advice given here which would
+   allow determining the content type.  That information is assumed to
+   be obtained via other means.
+
+11. IANA Considerations
+
+   This specification makes use of some lists of values currently
+   maintained by the IANA, and creates two new lists for the IANA to
+   maintain.  It does not add any values to any existing registries.
+
+   The existing IANA registries used by this specification are modified
+   using mechanisms specified elsewhere.
+
+11.1. The OS specific fact registry
+
+   A registry of OS specific fact names shall be maintained by the IANA.
+   The OS names for the OS portion of the fact name must be taken from
+   the IANA's list of registered OS names.  To add a fact name to this
+   OS specific registry of OS specific facts, an applicant must send to
+   the IANA a request, in which is specified the OS name, the OS
+   specific fact name, a definition of the syntax of the fact value,
+   which must conform to the syntax of a token as given in this
+   document, and a specification of the semantics to be associated with
+   the particular fact and its values.  Upon receipt of such an
+   application, and if the combination of OS name and OS specific fact
+   name has not been previously defined, the IANA will add the
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 56]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   specification to the registry.
+
+   Any examples of OS specific facts found in this document are to be
+   treated as examples of possible OS specific facts, and do not form a
+   part of the IANA's registry merely because of being included in this
+   document.
+
+11.2. The OS specific filetype registry
+
+   A registry of OS specific file types shall be maintained by the IANA.
+   The OS names for the OS portion of the fact name must be taken from
+   the IANA's list of registered OS names.  To add a file type to this
+   OS specific registry of OS specific file types, an applicant must
+   send to the IANA a request, in which is specified the OS name, the OS
+   specific file type, a definition of the syntax of the fact value,
+   which must conform to the syntax of a token as given in this
+   document, and a specification of the semantics to be associated with
+   the particular fact and its values.  Upon receipt of such an
+   application, and if the combination of OS name and OS specific file
+   type has not been previously defined, the IANA will add the
+   specification to the registry.
+
+   Any examples of OS specific file types found in this document are to
+   be treated as potential OS specific file types only, and do not form
+   a part of the IANA's registry merely because of being included in
+   this document.
+
+12. Security Considerations
+
+   This memo does not directly concern security.  It is not believed
+   that any of the mechanisms documented here impact in any particular
+   way upon the security of FTP.
+
+   Implementing the SIZE command, and perhaps some of the facts of the
+   MDLx commands, may impose a considerable load on the server, which
+   could lead to denial of service attacks.  Servers have, however,
+   implemented this for many years, without significant reported
+   difficulties.
+
+   With the introduction of virtual hosts to FTP, and the possible
+   accompanying multiple authentication environments, server
+   implementors will need to take some care to ensure that integrity is
+   maintained.
+
+   The FEAT and OPTS commands may be issued before the FTP
+   authentication has occurred [6].  This allows unauthenticated clients
+   to determine which of the features defined here are supported, and to
+   negotiate the fact list for MLSx output.  No actual MLSx commands may
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 57]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   be issued however, and no problems with permitting the selection of
+   the format prior to authentication are foreseen.
+
+   A general discussion of issues related to the security of FTP can be
+   found in [14].
+
+13. References
+
+   [1]  Coded Character Set--7-bit American Standard Code for Information
+        Interchange, ANSI X3.4-1986.
+
+   [2]  Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+        10646", RFC 2044, October 1996.
+
+   [3]  Postel, J., Reynolds, J., "File Transfer Protocol (FTP)",
+        STD 9, RFC 959, October 1985
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate
+        Requirement Levels", BCP 14, RFC 2119, March 1997
+
+   [5]  Crocker, D., Overell, P., "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997
+
+   [6]  Hethmon, P., Elz, R., "Feature negotiation mechanism for the
+        File Transfer Protocol", RFC 2389, August 1998
+
+   [7]  Curtin, W., "Internationalization of the File Transfer Protocol",
+        RFC 2640, July 1999
+
+   [8]  Postel, J., Reynolds, J., "Telnet protocol Specification"
+        STD 8, RFC 854, May 1983
+
+   [9]  Braden, R,. "Requirements for Internet Hosts -- Application
+        and Support", STD 3, RFC 1123, October 1989
+
+   [10] Mockapetris, P., "Domain Names - Concepts and Facilities"
+        STD 13, RFC 1034, November 1987
+
+   [11] ISO/IEC 10646-1:1993  "Universal multiple-octet coded character set
+        (UCS) -- Part 1: Architecture and basic multilingual plane",
+        International Standard -- Information Technology, 1993
+
+   [12] Internet Assigned Numbers Authority.  http://www.iana.org
+        Email: iana@iana.org.
+
+   [13] Alvestrand, H., "Tags for the Identification of Languages"
+        RFC 1766, March 1995
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 58]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+   [14] Allman, M., Ostermann, S., "FTP Security Considerations"
+        RFC 2577, May 1999
+
+Acknowledgments
+
+   This document is a product of the FTPEXT working group of the IETF.
+
+   The following people are among those who have contributed to this
+   document:
+
+        Alex Belits
+        D. J. Bernstein
+        Dave Cridland
+        Martin J. Duerst
+        Mike Gleason
+        Mark Harris
+        Alun Jones
+        James Matthews
+        Luke Mewburn
+        Jan Mikkelsen
+        Keith Moore
+        Buz Owen
+        Mark Symons
+        Stephen Tihor
+        and the entire FTPEXT working group of the IETF.
+
+   Apologies are offered to any inadvertently omitted.
+
+   Bernhard Rosenkraenzer suggested the HOST command, and initially
+   described it.
+
+   The description of the modifications to the REST command and the MDTM
+   and SIZE commands comes from a set of modifications suggested for
+   RFC959 by Rick Adams in 1989.  A draft containing just those
+   commands, edited by David Borman, has been merged with this document.
+
+   Mike Gleason provided access to the FTP server used in some of the
+   examples.
+
+   All of the examples in this document are taken from actual
+   client/server exchanges, though some have been edited for brevity, or
+   to meet document formatting requirements.
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 59]
+
+
+Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
+
+
+Copyright
+
+   This document is in the public domain.  Any and all copyright
+   protection that might apply in any jurisdiction is expressly
+   disclaimed.
+
+Editors' Addresses
+
+   Robert Elz
+   University of Melbourne
+   Department of Computer Science
+   Parkville, Vic   3052
+   Australia
+
+   Email: kre@munnari.OZ.AU
+
+
+   Paul Hethmon
+   Hethmon Brothers
+   2305 Chukar Road
+   Knoxville, TN 37923 USA
+
+   Phone: +1 423 690 8990
+   Email: phethmon@hethmon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Hethmon             [Expires April 2000]                 [Page 60]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-00.txt
new file mode 100644
index 00000000000..91071f37881
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-00.txt
@@ -0,0 +1,1230 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Obsoletes: 2478 (if approved)                              K. Jaganathan
+Expires: May 22, 2005                              Microsoft Corporation
+                                                               S. Harman
+                                                                     MIT
+                                                            W. Ingersoll
+                                                        Sun Microsystems
+                                                       November 21, 2004
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+                        draft-ietf-kitten-2478bis-00
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on May 22, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies a negotiation mechanism for the Generic
+   Security Service Application Program Interface (GSS-API) which is
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 1]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   described in RFC 2743.
+
+   GSS-API peers can use this negotiation mechanism to choose from a
+   common set of security mechanisms.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
+     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
+     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
+   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . .  9
+     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . .  9
+     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . .  9
+       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
+       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
+   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 13
+   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 15
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
+   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 19
+     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 19
+     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 19
+   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 21
+       Intellectual Property and Copyright Statements . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 2]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+1.  Introduction
+
+   The GSS-API [RFC2743] provides a generic interface which can be
+   layered atop different security mechanisms such that if communicating
+   peers acquire GSS-API credentials for the same security mechanism,
+   then a security context may be established between them (subject to
+   policy).  However, GSS-API doesn't prescribe the method by which
+   GSS-API peers can establish whether they have a common security
+   mechanism.
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo security mechanism, represented by the
+   Object Identifier iso.org.dod.internet.security.mechanism.snego
+   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
+   whether their credentials share common GSS-API security mechanism(s),
+   and if so, to invoke normal security context establishment for a
+   selected common security mechanism.  This is most useful for
+   applications that are based on GSS-API implementations and multiple
+   mechanisms are shared between the peers.
+
+   The SPNEGO mechanism negotiation is based on the following
+   negotiation model: the initiator proposes a list of security
+   mechanism(s), in its preference order (favorite choice first), the
+   acceptor (also known as the target) either accepts the initiator's
+   preferred security mechanism (the first in the list), or chooses one
+   that is available from the offered list, or rejects the proposed
+   value(s).  The target then informs the initiator of its choice.
+
+   Once a common security mechanism is chosen, it MAY also negotiate
+   mechanism-specific options during its context establishment, but that
+   will be inside the mechanism tokens and invisible to this protocol.
+
+   If per-message integrity services are available on the established
+   mechanism security context, the peers can then exchange MIC tokens to
+   ensure that the mechanism list was not tampered with.  This MIC token
+   exchange is OPTIONAL if no interference could have material impact on
+   the negotiation, i.e., when the selected mechanism is the first
+   choice for both peers.
+
+   In order to avoid an extra round trip, the first security token of
+   the preferred mechanism SHOULD be embedded in the initial negotiation
+   message (as defined in Section 4.2).  This mechanism token is
+   referred to as the optimistic token in this document.  If the
+   selected mechanism matches the initiator's preferred mechanism, no
+   additional round trips need to be incurred by using this protocol.
+   In addition, by using the optimistic token, the initiator can recover
+   from a non-fatal error in producing the first token before a
+   mechanism can be selected.  Implementations, however, MAY omit the
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 3]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   optimistic token, to avoid the cost of generating it in cases where
+   the initiator's preferred mechanism is not selected by the acceptor.
+
+   SPNEGO uses the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+   the existence of the negotiation tokens but only of the new
+   pseudo-security mechanism.  A failure in the negotiation phase causes
+   a major status code to be returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 4]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 5]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+3.  Negotiation Protocol
+
+   When the established mechanism context provides for integrity
+   protection, the mechanism negotiation can be protected.  When
+   acquiring negotiated security mechanism tokens, per-message integrity
+   services are always requested by the SPNEGO mechanism.
+
+   When the established mechanism context supports per-message integrity
+   services, SPNEGO guarantees that the selected mechanism is mutually
+   preferred.
+
+   This section describes the negotiation process of this protocol.
+
+3.1  Negotiation Description
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms (in preference order, favorite choice first), and
+   optionally the initial security token for the preferred mechanism of
+   the initiator (i.e., the first in the list).  The list of security
+   mechanisms available for negotiation is based on the credentials
+   being used.
+
+   The target then processes the token from the initiator.  This will
+   result in one of four possible states (as defined in Section 4.2.2):
+   accept_completed, accept_incomplete, reject, or request_mic.  A
+   reject state will terminate the negotiation;  an accept_completed
+   state indicates that not only was the initiator-selected mechanism
+   acceptable to the target, but that the initial token was sufficient
+   to complete the authentication;  an accept_incomplete state indicates
+   that further message exchange is needed but the MIC token exchange as
+   described in Section 5 is OPITONAL;  a request_mic state (this state
+   can only be present in the first reply message from the target)
+   indicates the MIC token exchange is REQUIRED if per-message integrity
+   services are available.
+
+   Unless the preference order is specified by the application (see
+   Appendix A), the policy by which the target chooses a mechanism is an
+   implementation-specific local matter.  In the absence of application
+   specified preference order or other policy, the target SHALL choose
+   the first mechanism in the initiator proposed list for which it has
+   valid credentials.
+
+   In case of a successful negotiation, the security mechanism in the
+   first reply message represents the value suitable for the target, and
+   picked up from the list offered by the initiator.  A context level
+   token for a reject state is OPTIONAL.
+
+   Once a mechanism has been selected, the tokens specific to the
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 6]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   selected mechanism are carried within the negotiation tokens.
+
+   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
+   mechanism list as seen by the target.
+
+   To avoid conflicts with the use of MIC tokens by SPNEGO,
+   partially-established contexts are not used for per-message calls:
+   the prot_ready_state [RFC2743] will be false even if the underlying
+   mechanism would return true natively.
+
+3.2  Negotiation Procedure
+
+   The basic form of the procedure assumes that per-message integrity
+   services are available on the established mechanism context, and it
+   is summarized as follows:
+
+   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests (either explicitly, with the negotiation mechanism,
+      or through accepting a default, when the default is this
+      negotiation mechanism) that SPNEGO is used.
+
+   (b) The initiator GSS-API implementation emits a negotiation token
+      containing a list of supported security mechanisms (possible just
+      one mechanism) for the credentials used for this context
+      establishment, and optionally an initial security token for the
+      first mechanism from that list.
+
+   (c) The GSS-API initiator application sends the token to the target
+      application.  The GSS-API target application deposits the token
+      through invoking GSS_Accept_sec_context().  The acceptor will do
+      one of the following:
+
+      (I) No proposed mechanism is acceptable, the negotiation SHALL be
+         terminated.  GSS_Accept_sec_context indicates GSS_S_BAD_MECH.
+         The acceptor MAY output a negotiation token containing a reject
+         state.
+
+      (II) If either the initiator's preferred mechanism is not accepted
+         by the target, or this mechanism is accepted but it is not the
+         most preferred mechanism available for the acceptor (see
+         Section 3.1 and Section 5), GSS_Accept_sec_context() indicates
+         GSS_S_CONTINUE_NEEDED.  The acceptor MUST output a negotiation
+         token containing a request_mic state.
+
+      (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
+         or GSS_S_CONTINUE_NEEDED, depending on if at least one
+         additional negotiation token from the initiator is needed to
+         establish this context.  The acceptor outputs a negotiation
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 7]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+         token containing an accept_complete or accept_incomplete state,
+         respectively.
+
+      If the initiator's preferred mechanism is accepted, and an
+      optimistic mechanism token was included, this mechanism token MUST
+      be deposited to the selected mechanism through invoking
+      GSS_Accept_sec_context() and if a response mechanism token is
+      emitted, it MUST be included in the response negotiation token.
+      Otherwise, the target will not emit a response mechanism token in
+      the first reply.
+
+   (d) The GSS-API target application returns the negotiation token to
+      the initiator application.  The GSS-API initiator application
+      deposits the token through invoking GSS_Init_sec_context().  The
+      security context initialization is then continued according to the
+      standard GSS-API conventions for the selected mechanism, where the
+      tokens of the selected mechanism are encapsulated until the
+      GSS_S_COMPLETE is returned for both the initiator and the target
+      by the selected security mechanism.
+
+   (e) MIC tokens are then either skipped or exchanged according to
+      Section 5.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested but was not supported.
+
+   When GSS_Acquire_cred is invoked with this SPNEGO mechanism as
+   desired_mechs, an implementation-specific default credential is used
+   to carry on the negotiation.  A set of mechanisms as specified
+   locally by the system administrator is then available for
+   negotiation.  If there is a desire for the caller to make its own
+   choice, then an additional API has to be used (see Appendix A).
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 8]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+4.  Token Definitions
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+      SPNEGOASNOneSpec {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanism(5) snego (2) modules(4) spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- rest of definitions here
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   The encoding of SPNEGO protocol messages shall obey the Distinguished
+   Encoding Rules (DER) of ASN.1 as described in [X690].
+
+4.1  Mechanism Types
+
+   In this negotiation model, each OID represents one GSS-API mechanism
+   or one variant of it according to [RFC2743].
+
+
+       MechType ::= OBJECT IDENTIFIER
+           -- OID represents each security mechanism as suggested by
+           -- [RFC2743]
+
+       MechTypeList ::= SEQUENCE OF MechType
+
+
+4.2  Negotiation Tokens
+
+   The syntax of the initial negotiation tokens follows the
+   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
+   SPNEGO pseudo mechanism is identified by the Object Identifier
+   specified in Section 1.  Subsequent tokens are not encapsulated in
+   this GSS-API generic token framing.
+
+   This section specifies the syntax of the inner token for the initial
+   message, and the syntax of subsequent context establishment tokens.
+
+       NegotiationToken ::= CHOICE {
+           negTokenInit    [0] NegTokenInit,
+
+
+
+Zhu, et al.               Expires May 22, 2005                  [Page 9]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+           negTokenResp    [1] negTokenResp
+       }
+
+
+
+4.2.1  negTokenInit
+
+       NegTokenInit ::= SEQUENCE {
+           mechTypes       [0] MechTypeList,
+           reqFlags        [1] ContextFlags  OPTIONAL,
+           mechToken       [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+       ContextFlags ::= BIT STRING {
+           delegFlag       (0),
+           mutualFlag      (1),
+           replayFlag      (2),
+           sequenceFlag    (3),
+           anonFlag        (4),
+           confFlag        (5),
+           integFlag       (6)
+       }
+
+   This is the syntax for the inner token of the initial negotiation
+   message.
+
+   mechTypes
+
+         This field contains one or more security mechanisms available
+         for the initiator in preference order (favorite choice first).
+
+   reqFlags
+
+         This field, if present, contains the service options that are
+         requested to establish the context.  The context flags SHOULD
+         be filled in from the req_flags parameter of
+         GSS_Init_sec_context().  This field SHALL NOT have impact on
+         the negotiation.
+
+   mechToken
+
+         This field, is present, contains the optimistic security
+         mechanism token.
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 10]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   mechlistMIC
+
+         This field, is present, contains a MIC token, which is computed
+         according to Section 5, for the mechanism list in the initial
+         negotiation message.
+
+
+4.2.2  negTokenResp
+
+       NegTokenResp ::= SEQUENCE {
+           negResult       [0] ENUMERATED {
+               accept_completed    (0),
+               accept_incomplete   (1),
+               reject              (2),
+               request_mic         (3)
+           },
+           supportedMech   [1] MechType      OPTIONAL,
+           responseToken   [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+
+   This is the syntax for all subsequent negotiation messages.
+
+   negResult
+
+         This field contains the state of the negotiation.  This can be:
+
+         accept_completed
+            No further negotiation message from the peer is expected,
+            and the security context is established for the sender.
+
+         accept_incomplete
+            At least one more negotiation message from the peer is
+            needed to establish the security context.
+
+         reject
+            The sender terminates the negotiation.
+
+         request_mic
+            The sender indicates that the exchange of MIC tokens, as
+            described in Section 5, will be REQUIRED if per-message
+            integrity services are available on the mechanism context to
+            be established.  This value SHALL only be present in the
+            first reply from the target.
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 11]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   supportedMech
+
+         This field SHALL only be present in the first reply from the
+         target.  It is a choice from the mechanism(s) offered by the
+         initiator.
+
+   ResponseToken
+
+         The field, if present, contains tokens specific to the
+         mechanism selected.
+
+   mechlistMIC
+
+         This field, is present, contains a MIC token, which is computed
+         according to Section 5, for the mechanism list in the initial
+         negotiation message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 12]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+5.  Processing of mechListMIC
+
+   If the mechanism selected by the negotiation does not support
+   integrity protection, then no mechlistMIC token is used.  Otherwise
+   if the initiator's preferred mechanism is accepted and it is also the
+   most preferred mechanism available for the acceptor (there is no
+   mechanism which, had it been present in the mechanism list, the
+   acceptor would have preferred over the accepted mechanism), then the
+   MIC token exchange, as described later in this section, is OPTIONAL.
+   In all other cases, MIC tokens MUST be exchanged after the mechanism
+   context is fully established.
+
+   It is assumed that per-message integrity services are available on
+   the established mechanism context in the following procedure for
+   processing MIC tokens of the initiator's mechanism list.
+
+   a) The mechlistMIC token (or simply the MIC token) is computed
+      through invoking GSS_GetMIC(): the input context_handle is the
+      established mechanism context, the input qop_req is 0, and the
+      input message is the mechTypes field in the initial negotiation
+      message (only the "value" portion, omitting the tag and length, of
+      the ASN.1 encoding for that field is included).
+
+   b) If the selected mechanism uses an even number of mechanism tokens
+      (namely the acceptor sends the last mechanism token), the acceptor
+      does the following when emitting the negotiation message
+      containing the last mechanism token: if the MIC token exchange is
+      not required, GSS_Accept_sec_context() either indicates
+      GSS_S_COMPLETE and does not include a mechlistMIC token, or
+      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
+      and an accept_incomplete state; if the MIC token exchange is
+      required, GSS_Accept_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
+      Acceptors who wish to be compatible with legacy Windows SPNEGO
+      implementations as described in Appendix B shall not generate a
+      mechlistMIC token when the MIC token exchange is not required.
+      The initiator then processes the last mechanism token, and does
+      one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
+         output negotiation message contains a mechlistMIC token, and an
+         accept_complete state.  The acceptor MUST then verify this
+         mechlistMIC token.
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 13]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included, and the MIC token
+         exchange is not required, GSS_Init_sec_context() indicates
+         GSS_S_COMPLETE with no output token.
+
+      (IV) If no mechlistMIC token was included, but the MIC token
+         exchange is required, the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+   c) In the case that the chosen mechanism uses an odd number of
+      mechanism tokens (namely the initiator sends the last mechanism
+      token), the initiator does the following when emitting the
+      negotiation message containing the last mechanism token: if the
+      negResult state was request_mic in the first reply from the
+      target, a mechlistMIC token MUST be included, otherwise the
+      mechlistMIC token is OPTIONAL.  GSS_Init_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED.  Initiators who wish to be compatible with
+      legacy Windows SPNEGO implementations as described in Appendix B
+      shall not generate a mechlistMIC token when the MIC token exchange
+      is not required.  The acceptor then processes the last mechanism
+      token, and does one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
+         The output negotiation message contains a mechlistMIC token,
+         and an accept_complete state.  The initiator MUST then verify
+         this mechlistMIC token.
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included and the mechlistMIC
+         token exchange is not required, GSS_Accept_sec_context()
+         indicates GSS_S_COMPLETE.  The output negotiation message
+         contains an accept_complete state.
+
+      (IV) If no mechlistMIC token was included and the acceptor sent a
+         request_mic state in the first reply message (the exchange of
+         MIC tokens is required), the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 14]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+6.  Extensibility
+
+   Two mechanisms are provided by extensibility.  First, the ASN.1
+   structures in this specification MAY be expanded by IETF standards
+   action.  Implementations receiving unknown fields MUST ignore these
+   fields.
+
+   Secondly, OIDs corresponding to a desired mechanism attribute may be
+   included in the set of preferred mechanisms by an initiator.  The
+   acceptor can choose to honor this request by preferring mechanisms
+   that have that attribute.  Future work within the Kitten working
+   group is expected to standardize common attributes that SPNEGO
+   mechanisms may wish to support.  At this time it is sufficient to say
+   that initiators MAY include OIDs that do not correspond to mechanisms
+   but instead correspond to desired mechanism attributes in their
+   requests.  Such OIDs MAY influence the acceptor's choice of
+   mechanism.  As discussed in Section 5, if there are mechanisms that
+   if present in the initiator's list of mechanisms might be preferred
+   by the acceptor to the initiator's preferred mechanism, the acceptor
+   MUST demand the MIC token exchange.  As a consequence, acceptors MUST
+   demand the MIC token exchange if they support negotiation of
+   attributes not available in the initiator's preferred mechanism
+   regardless of whether the initiator actually requested these
+   attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 15]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+7.  Security Considerations
+
+   In order to produce the MIC token for the mechanism list, the
+   mechanism must provide integrity protection.  When the selected
+   mechanism does not support integrity protection, then the negotiation
+   is vulnerable: an active attacker can force it to use a security
+   mechanism that is not mutually preferred but is acceptable anyway to
+   the target.
+
+   When per-message integrity services are available on the established
+   mechanism context, and there was an alteration of the mechanism list
+   by an adversary such that a common mechanism that is not mutually
+   preferred could be selected, this protocol provides the following
+   guarantees: if the last mechanism token is sent by the initiator,
+   both peers shall fail; if the last mechanism token is sent by the
+   acceptor, the acceptor shall not complete and the initiator at worst
+   shall complete with its preferred mechanism being selected.  The
+   negotiation may not be terminated if an alteration was made but it
+   had no material impact.
+
+   The protection of the negotiation depends on the strength of the
+   integrity protection.  In particular, the strength of SPNEGO is no
+   stronger than the integrity protection of the weakest mechanism
+   acceptable to GSS-API peers.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 16]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+8.  Acknowledgments
+
+   The authors wish to thank Nicolas Williams, Ken Raeburn, Jeff Altman,
+   Cristian Ilac and Martin Rex for their comments and suggestions on
+   earlier versions of this document.
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478], of which some of the text has been retained in this
+   document.
+
+9  References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
+              (BER), Canonical Encoding Rules (CER) and Distinguished 
+              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
+              ISO/IEC International Standard 8825-1:1998.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 17]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Sam Hartman
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   EMail: hartmans@mit.edu
+
+
+   Wyllys Ingersoll
+   Sun Microsystems
+   1775 Wiehle Avenue, 2nd Floor
+   Reston, VA  20190
+   US
+
+   EMail: wyllys.ingersoll@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 18]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+Appendix A.  GSS-API Negotiation Support API
+
+   In order to provide to a GSS-API caller (either the initiator or the
+   target or both) the ability to choose among the set of supported
+   mechanisms a reduced set of mechanisms for negotiation, two
+   additional APIs are defined:
+
+   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
+      available on the local system to the caller for negotiation, based
+      on the credentials being used.
+   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+      used on the local system by the caller for negotiation, for the
+      given credentials.
+
+A.1  GSS_Set_neg_mechs call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
+      -- credentials
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been set to mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to specify the set of security mechanisms that may be
+   negotiated with the credential identified by cred_handle.  This call
+   is intended for support of specialized callers who need to restrict
+   the set of negotiable security mechanisms from the set of all
+   security mechanisms available to the caller (based on available
+   credentials).  Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative preference.
+
+A.2  GSS_Get_neg_mechs call
+
+   Input:
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 19]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
+      -- credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been returned in mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of security mechanisms available
+   for negotiation with the credential identified by cred_handle.  This
+   call is intended for support of specialized callers who need to
+   reduce the set of negotiable security mechanisms from the set of
+   supported security mechanisms available to the caller (based on
+   available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system.  Since this call has
+   no input parameter, the returned set is not necessarily available for
+   all credentials.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 20]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+Appendix B.  Changes since RFC2478
+
+      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
+      2003 have the following behavior: no mechlistMIC is produced, and
+      mechlistMIC is not processed if one is provided; if the initiator
+      sends the last mechanism token, the acceptor will send back a
+      negotiation token with an accept_complete state and no mechlistMIC
+      token.  In addition, the OID (1.2.840.48018.1.2.2) can be used to
+      identify the GSS-API Kerberos Version 5 mechanism.
+
+      The following changes have been made to be compatible with these
+      legacy implementations.
+
+      *  NegTokenTarg is changed to negTokenResp and it is the message
+         format for all subsequent negotiation tokens.
+      *  NegTokenInit is the message for the initial token and that
+         token only.
+      *  mechTypes in negTokenInit is not optional.
+      *  negResult is not optional in the negTokenResp token.
+      *  Two MIC tokens are exchanged, one in each direction.
+      *  If the selected mechanism is also the most preferred mechanism
+         for both peers, it is safe to omit the MIC tokens.
+
+      If at least one of the two peers implements the pseudo mechanism
+      in this document, the negotiation is protected.
+
+      The following changes are to address the problems in RFC 2478.
+
+      *  reqFlags is not protected therefore it should not impact the
+         negotiation.
+      *  DER encoding is required.
+      *  GSS_GetMIC() input is clarified.
+      *  Per-message integrity services are requested for the negotiated
+         mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 21]
+
+Internet-Draft       GSS-API Negotiation Mechanism         November 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires May 22, 2005                 [Page 22]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-02.txt
new file mode 100644
index 00000000000..d63f4f6b895
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-02.txt
@@ -0,0 +1,1405 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Obsoletes: 2478 (if approved)                              K. Jaganathan
+Expires: June 1, 2005                              Microsoft Corporation
+                                                            W. Ingersoll
+                                                        Sun Microsystems
+                                                        December 1, 2004
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+                       draft-ietf-kitten-2478bis
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on June 1, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies a negotiation mechanism for the Generic
+   Security Service Application Program Interface (GSS-API) which is
+   described in RFC 2743.
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 1]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   GSS-API peers can use this negotiation mechanism to choose from a
+   common set of security mechanisms.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
+     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
+     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
+   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . .  9
+     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . .  9
+     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . .  9
+       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
+       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
+   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 13
+   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 16
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
+   10.   Normative References . . . . . . . . . . . . . . . . . . . . 19
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
+   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 21
+     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21
+     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21
+   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 23
+       Intellectual Property and Copyright Statements . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 2]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+1.  Introduction
+
+   The GSS-API [RFC2743] provides a generic interface which can be
+   layered atop different security mechanisms such that if communicating
+   peers acquire GSS-API credentials for the same security mechanism,
+   then a security context may be established between them (subject to
+   policy).  However, GSS-API does not prescribe the method by which
+   GSS-API peers can establish whether they have a common security
+   mechanism.
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo security mechanism, represented by the
+   Object Identifier iso.org.dod.internet.security.mechanism.snego
+   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
+   whether their credentials share common GSS-API security mechanism(s),
+   and if so, to invoke normal security context establishment for a
+   selected common security mechanism.  This is most useful for
+   applications which are based on GSS-API implementations and share
+   multiple mechanisms between the peers.
+
+   The SPNEGO mechanism negotiation is based on the following
+   negotiation model: the initiator proposes a list of security
+   mechanism(s), in decreasing preference order (favorite choice first),
+   the acceptor (also known as the target) either accepts the
+   initiator's preferred security mechanism (the first in the list), or
+   chooses one that is available from the offered list, or rejects the
+   proposed value(s).  The target then informs the initiator of its
+   choice.
+
+   Once a common security mechanism is chosen, mechanism-specific
+   options MAY be negotiated as part of the selected mechanism's context
+   establishment.  These negotiations (if any) are internal to the
+   mechanism and opaque to the SPNEGO protocol.  As such they are
+   outside the scope of this document.
+
+   If per-message integrity services are available on the established
+   mechanism security context, then the peers can exchange MIC tokens to
+   ensure that the mechanism list was not tampered with.  This MIC token
+   exchange is OPTIONAL if the selected mechanism is the most preferred
+   choice of both peers (see Section 5).
+
+   In order to avoid an extra round trip, the first security token of
+   the initiator's preferred mechanism SHOULD be embedded in the initial
+   negotiation message (as defined in Section 4.2).  This mechanism
+   token is referred to as the optimistic mechanism token in this
+   document.  If the selected mechanism matches the initiator's
+   preferred mechanism, no additional round trips need be incurred by
+   using this protocol.  In addition, using the optimistic mechanism
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 3]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   token allows the initiator to recover from non-fatal errors while
+   producing the first mechanism token before a mechanism can be
+   selected.  Implementations MAY omit the optimistic mechanism token to
+   avoid the cost of generating it in cases where the initiator's
+   preferred mechanism is not selected by the acceptor.
+
+   SPNEGO relies the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+   the existence of the negotiation tokens but only of the new
+   pseudo-security mechanism.  A failure in the negotiation phase causes
+   a major status code to be returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 4]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 5]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+3.  Negotiation Protocol
+
+   When the established mechanism context provides integrity protection,
+   the mechanism negotiation can be protected.  When acquiring
+   negotiated security mechanism tokens, per-message integrity services
+   are always requested by the SPNEGO mechanism.
+
+   When the established mechanism context supports per-message integrity
+   services, SPNEGO guarantees that the selected mechanism is mutually
+   preferred.
+
+   This section describes the negotiation process of this protocol.
+
+3.1  Negotiation Description
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms (in decreasing preference order, favorite
+   mechanism first), and optionally the initial mechanism token for the
+   preferred mechanism of the initiator (i.e., the first in the list).
+   The list of security mechanisms available for negotiation is based on
+   the credentials being used.
+
+   The target then processes the token from the initiator.  This will
+   result in one of four possible states (as defined in Section 4.2.2):
+   accept_completed, accept_incomplete, reject, or request_mic.  A
+   reject state will terminate the negotiation;  an accept_completed
+   state indicates that not only was the initiator-selected mechanism
+   acceptable to the target, but also that the initial mechanism token
+   was sufficient to complete the authentication;  an accept_incomplete
+   state indicates that further message exchange is needed but the MIC
+   token exchange as described in Section 5 is OPTIONAL;  a request_mic
+   state (this state can only be present in the first reply message from
+   the target) indicates the MIC token exchange is REQUIRED if
+   per-message integrity services are available.
+
+   Unless the preference order is specified by the application (see
+   Appendix A), the policy by which the target chooses a mechanism is an
+   implementation-specific local matter.  In the absence of an
+   application specified preference order or other policy, the target
+   SHALL choose the first mechanism in the initiator proposed list for
+   which it has valid credentials.
+
+   In case of a successful negotiation, the security mechanism in the
+   first reply message represents the value suitable for the target,
+   picked up from the list offered by the initiator.  A context level
+   token for a reject state is OPTIONAL.
+
+   Once a mechanism has been selected, the tokens specific to the
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 6]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   selected mechanism are carried within the negotiation tokens.
+
+   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
+   mechanism list received by the target.
+
+   To avoid conflicts with the use of MIC tokens by SPNEGO,
+   partially-established contexts are not used for per-message calls:
+   the prot_ready_state [RFC2743] will be false even if the underlying
+   mechanism would return true natively.
+
+3.2  Negotiation Procedure
+
+   The basic form of the procedure assumes that per-message integrity
+   services are available on the established mechanism context, and it
+   is summarized as follows:
+
+   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests that SPNEGO be used.  SPNEGO can either be explicity
+      requested or accepted as the default mechanism.
+
+   (b) The initiator GSS-API implementation emits a negotiation token
+      containing a list of one or more security mechanisms that are
+      available based on the credentials used for this context
+      establishment, and optionally the initial mechanism token for the
+      first mechanism in the list.
+
+   (c) The GSS-API initiator application sends the token to the target
+      application.  The GSS-API target application deposits the token by
+      invoking GSS_Accept_sec_context().  The acceptor will do one of
+      the following:
+
+      (I) If none of the proposed mechanisms are acceptable, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context
+         indicates GSS_S_BAD_MECH.  The acceptor MAY output a
+         negotiation token containing a reject state.
+
+      (II) If either the initiator's preferred mechanism is not accepted
+         by the target or this mechanism is accepted but it is not the
+         acceptor's most preferred mechanism (see Section 3.1 and
+         Section 5), GSS_Accept_sec_context() indicates
+         GSS_S_CONTINUE_NEEDED.  The acceptor MUST output a negotiation
+         token containing a request_mic state.
+
+      (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
+         or GSS_S_CONTINUE_NEEDED depending on if at least one
+         additional negotiation token from the initiator is needed to
+         establish this context.  The acceptor outputs a negotiation
+         token containing an accept_complete or accept_incomplete state,
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 7]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+         respectively.
+
+      If the initiator's preferred mechanism is accepted, and an
+      optimistic mechanism token was included, this mechanism token MUST
+      be deposited to the selected mechanism by invoking
+      GSS_Accept_sec_context() and if a response mechanism token is
+      emitted, it MUST be included in the response negotiation token.
+      Otherwise, the target will not emit a response mechanism token in
+      the first reply.
+
+   (d) The GSS-API target application returns the negotiation token to
+      the initiator application.  The GSS-API initiator application
+      deposits the token by invoking GSS_Init_sec_context().  The
+      security context initialization is then continued according to the
+      standard GSS-API conventions for the selected mechanism, where the
+      tokens of the selected mechanism are encapsulated until the
+      GSS_S_COMPLETE is returned for both the initiator and the target
+      by the selected security mechanism.
+
+   (e) MIC tokens are then either skipped or exchanged according to
+      Section 5.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested and was not supported.
+
+   When GSS_Acquire_cred is invoked with this negotiation mechanism in
+   the desired_mechs, an implementation-specific default credential is
+   used to carry on the negotiation.  A set of mechanisms as specified
+   locally by the system administrator is then available for
+   negotiation.  If there is a desire for the caller to make its own
+   choice, then an additional API has to be used (see Appendix A).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 8]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+4.  Token Definitions
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+      SPNEGOASNOneSpec {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanism(5) snego (2) modules(4) spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- rest of definitions here
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   The encoding of SPNEGO protocol messages shall obey the Distinguished
+   Encoding Rules (DER) of ASN.1 as described in [X690].
+
+4.1  Mechanism Types
+
+   In this negotiation model, each OID represents one GSS-API mechanism
+   or one variant (see Section 6) of it according to [RFC2743].
+
+
+       MechType ::= OBJECT IDENTIFIER
+           -- OID represents each security mechanism as suggested by
+           -- [RFC2743]
+
+       MechTypeList ::= SEQUENCE OF MechType
+
+
+4.2  Negotiation Tokens
+
+   The syntax of the initial negotiation tokens follows the
+   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
+   SPNEGO pseudo mechanism is identified by the Object Identifier
+   specified in Section 1.  Subsequent tokens are not encapsulated in
+   this GSS-API generic token framing.
+
+   This section specifies the syntax of the inner token for the initial
+   message and the syntax of subsequent context establishment tokens.
+
+       NegotiationToken ::= CHOICE {
+           negTokenInit    [0] NegTokenInit,
+
+
+
+Zhu, et al.               Expires June 1, 2005                  [Page 9]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+           negTokenResp    [1] negTokenResp
+       }
+
+
+
+4.2.1  negTokenInit
+
+       NegTokenInit ::= SEQUENCE {
+           mechTypes       [0] MechTypeList,
+           reqFlags        [1] ContextFlags  OPTIONAL,
+           mechToken       [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+       ContextFlags ::= BIT STRING {
+           delegFlag       (0),
+           mutualFlag      (1),
+           replayFlag      (2),
+           sequenceFlag    (3),
+           anonFlag        (4),
+           confFlag        (5),
+           integFlag       (6)
+       }
+
+   This is the syntax for the inner token of the initial negotiation
+   message.
+
+   mechTypes
+
+         This field contains one or more security mechanisms available
+         for the initiator in decreasing preference order (favorite
+         choice first).
+
+   reqFlags
+
+         This field, if present, contains the service options that are
+         requested to establish the context.  The context flags SHOULD
+         be filled in from the req_flags parameter of
+         GSS_Init_sec_context().  This field SHALL NOT have impact on
+         the negotiation.
+
+   mechToken
+
+         This field, if present, contains the optimistic mechanism
+         token.
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 10]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   mechlistMIC
+
+         This field, if present, contains a MIC token for the mechanism
+         list in the initial negotiation message.  This MIC token is
+         computed according to Section 5.
+
+
+4.2.2  negTokenResp
+
+       NegTokenResp ::= SEQUENCE {
+           negResult       [0] ENUMERATED {
+               accept_completed    (0),
+               accept_incomplete   (1),
+               reject              (2),
+               request_mic         (3)
+           }                                 OPTIONAL,
+             -- REQUIRED in the first reply from the target
+           supportedMech   [1] MechType      OPTIONAL,
+             -- present only in the first reply from the target
+           responseToken   [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+
+   This is the syntax for all subsequent negotiation messages.
+
+   negResult
+
+         This field, if present, contains the state of the negotiation.
+         This can be:
+
+         accept_completed
+
+            No further negotiation message from the peer is expected,
+            and the security context is established for the sender.
+
+         accept_incomplete
+
+            At least one more negotiation message from the peer is
+            needed to establish the security context.
+
+         reject
+
+            The sender terminates the negotiation.
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 11]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+         request_mic
+
+            The sender indicates that the exchange of MIC tokens, as
+            described in Section 5, will be REQUIRED if per-message
+            integrity services are available on the mechanism context to
+            be established.  This value SHALL only be present in the
+            first reply from the target.
+
+         This field is REQUIRED in the first reply from the target, and
+         it is OPTIONAL thereafter.
+
+   supportedMech
+
+         This field SHALL only be present in the first reply from the
+         target.  It MUST be one of the mechanism(s) offered by the
+         initiator.
+
+   ResponseToken
+
+         This field, if present, contains tokens specific to the
+         mechanism selected.
+
+   mechlistMIC
+
+         This field, if present, contains a MIC token for the mechanism
+         list in the initial negotiation message.  This MIC token is
+         computed according to Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 12]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+5.  Processing of mechListMIC
+
+   If the mechanism selected by the negotiation does not support
+   integrity protection, then no mechlistMIC token is used.
+
+   Otherwise if the accepted mechanism is the most preferred mechanism
+   of both the initiator and the acceptor, then the MIC token exchange,
+   as described later in this section, is OPTIONAL.  A mechanism is the
+   acceptor's most preferred mechanism if there is no other mechanism
+   which would have been preferred over the accepted mechanism if it had
+   been present in the received mechanism list.
+
+   In all other cases, MIC tokens MUST be exchanged after the mechanism
+   context is fully established.
+
+   It is assumed that per-message integrity services are available on
+   the established mechanism context in the following procedure for
+   processing MIC tokens of the initiator's mechanism list.
+
+   a) The mechlistMIC token (or simply the MIC token) is computed by
+      invoking GSS_GetMIC(): the input context_handle is the established
+      mechanism context, the input qop_req is 0, and the input message
+      is the mechTypes field in the initial negotiation message (only
+      the DER encoding of the type MechTypeList is included).
+
+   b) If the selected mechanism uses an even number of mechanism tokens
+      (namely the acceptor sends the last mechanism token), the acceptor
+      does the following when emitting the negotiation message
+      containing the last mechanism token: if the MIC token exchange is
+      not required, GSS_Accept_sec_context() either indicates
+      GSS_S_COMPLETE and does not include a mechlistMIC token, or
+      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
+      and an accept_incomplete state; if the MIC token exchange is
+      required, GSS_Accept_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
+      Acceptors that wish to be compatible with legacy Windows SPNEGO
+      implementations as described in Appendix B shall not generate a
+      mechlistMIC token when the MIC token exchange is not required.
+      The initiator then processes the last mechanism token, and does
+      one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
+         output negotiation message contains a mechlistMIC token, and an
+         accept_complete state.  The acceptor MUST then verify this
+         mechlistMIC token.
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 13]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included, and the MIC token
+         exchange is not required, GSS_Init_sec_context() indicates
+         GSS_S_COMPLETE with no output token.
+
+      (IV) If no mechlistMIC token was included, but the MIC token
+         exchange is required, the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+   c) In the case that the chosen mechanism uses an odd number of
+      mechanism tokens (namely the initiator sends the last mechanism
+      token), the initiator does the following when emitting the
+      negotiation message containing the last mechanism token: if the
+      negResult state was request_mic in the first reply from the
+      target, a mechlistMIC token MUST be included, otherwise the
+      mechlistMIC token is OPTIONAL.  In the case that the optimistic
+      mechanism token is the only mechanism token for the initiator's
+      preferred mechanism, the mechlistMIC token is OPTIONAL.
+      GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
+      Initiators that wish to be compatible with legacy Windows SPNEGO
+      implementations as described in Appendix B shall not generate a
+      mechlistMIC token when the MIC token exchange is not required.
+      The acceptor then processes the last mechanism token and does one
+      of the following:
+
+      (I) If a mechlistMIC token was included and is correctly verified,
+         GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
+         negotiation message contains a mechlistMIC token and an
+         accept_complete state.  The initiator MUST then verify this
+         mechlistMIC token.
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included but the mechlistMIC
+         token exchange is not required, GSS_Accept_sec_context()
+         indicates GSS_S_COMPLETE.  The output negotiation message
+         contains an accept_complete state.
+
+      (IV) In the case that the optimistic mechanism token is also the
+         last mechanism token (when the initiator's preferred mechanism
+         is accepted by the target) and the target sends a request_mic
+         state but the initiator did not send a mechlistMIC token, the
+         target then MUST include a mechlistMIC token in that first
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 14]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+         reply.  GSS_Accept_sec_context() indicates
+         GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
+         mechlistMIC token and generate a mechlistMIC token to send back
+         to the target.  The target SHALL in turn verify the returned
+         mechlistMIC token and complete the negotiation.
+
+      (V) If no mechlistMIC token was included and the acceptor sent a
+         request_mic state in the first reply message (the exchange of
+         MIC tokens is required), the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 15]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+6.  Extensibility
+
+   Two mechanisms are provided for extensibility.  First, the ASN.1
+   structures in this specification MAY be expanded by IETF standards
+   action.  Implementations receiving unknown fields MUST ignore these
+   fields.
+
+   Secondly, OIDs corresponding to a desired mechanism attribute may be
+   included in the set of preferred mechanisms by an initiator.  The
+   acceptor can choose to honor this request by preferring mechanisms
+   that have the included attributes.  Future work within the Kitten
+   working group is expected to standardize common attributes that
+   SPNEGO mechanisms may wish to support.  At this time it is sufficient
+   to say that initiators MAY include OIDs that do not correspond to
+   mechanisms but instead correspond to desired mechanism attributes in
+   their requests.  Such OIDs MAY influence the acceptor's choice of
+   mechanism.  As discussed in Section 5, if there are mechanisms that
+   if present in the initiator's list of mechanisms might be preferred
+   by the acceptor to the initiator's preferred mechanism, the acceptor
+   MUST demand the MIC token exchange.  As a consequence, acceptors MUST
+   demand the MIC token exchange if they support negotiation of
+   attributes not available in the initiator's preferred mechanism
+   regardless of whether the initiator actually requested these
+   attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 16]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+7.  Security Considerations
+
+   In order to produce the MIC token for the mechanism list, the
+   mechanism must provide integrity protection.  When the selected
+   mechanism does not support integrity protection, the negotiation is
+   vulnerable: an active attacker can force it to use a security
+   mechanism that is not mutually preferred but is acceptable to the
+   target.
+
+   This protocol provides the following guarantees when per-message
+   integrity services are available on the established mechanism context
+   and the mechanism list was altered by an adversary such that a
+   mechanism which is not mutually preferred could be selected:
+
+   o  if the last mechanism token is sent by the initiator, both peers
+      shall fail;
+   o  if the last mechanism token is sent by the acceptor, the acceptor
+      shall not complete and the initiator at worst shall complete with
+      its preferred mechanism being selected.
+
+   The negotiation may not be terminated if an alteration was made but
+   it had no material impact.
+
+   The protection of the negotiation depends on the strength of the
+   integrity protection.  In particular, the strength of SPNEGO is no
+   stronger than the integrity protection of the weakest mechanism
+   acceptable to GSS-API peers.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 17]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+8.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 18]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+9.  Acknowledgments
+
+   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
+   Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
+   and suggestions during development of this document.
+
+   Luke Howard provided a prototype of this protocol in Heimdal and
+   resolved several issues in the initial draft.
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478] of which some of the text has been retained in this
+   document.
+
+10  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
+              Rules (BER), Canonical Encoding Rules (CER) and 
+              Distinguished Encoding Rules (DER), ITU-T Recommendation 
+              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 19]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Wyllys Ingersoll
+   Sun Microsystems
+   1775 Wiehle Avenue, 2nd Floor
+   Reston, VA  20190
+   US
+
+   EMail: wyllys.ingersoll@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 20]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Appendix A.  GSS-API Negotiation Support API
+
+   In order to provide to a GSS-API caller (either the initiator or the
+   target or both) the ability to choose among the set of supported
+   mechanisms a reduced set of mechanisms for negotiation, two
+   additional APIs are defined:
+
+   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
+      available on the local system to the caller for negotiation, based
+      on the credentials being used.
+   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+      used on the local system by the caller for negotiation, for the
+      given credentials.
+
+A.1  GSS_Set_neg_mechs call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
+      -- credentials
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been set to mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to specify the set of security mechanisms that may be
+   negotiated with the credential identified by cred_handle.  This call
+   is intended for support of specialized callers who need to restrict
+   the set of negotiable security mechanisms from the set of all
+   security mechanisms available to the caller (based on available
+   credentials).  Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative preference.
+
+A.2  GSS_Get_neg_mechs call
+
+   Input:
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 21]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
+      -- credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been returned in mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of security mechanisms available
+   for negotiation with the credential identified by cred_handle.  This
+   call is intended for support of specialized callers who need to
+   reduce the set of negotiable security mechanisms from the set of
+   supported security mechanisms available to the caller (based on
+   available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system.  Since this call has
+   no input parameter, the returned set is not necessarily available for
+   all credentials.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 22]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Appendix B.  Changes since RFC2478
+
+      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
+      2003 have the following behavior: no mechlistMIC is produced and
+      mechlistMIC is not processed if one is provided; if the initiator
+      sends the last mechanism token, the acceptor will send back a
+      negotiation token with an accept_complete state and no mechlistMIC
+      token.  In addition, the OID (1.2.840.48018.1.2.2) can be used to
+      identify the GSS-API Kerberos Version 5 mechanism.
+
+      The following changes have been made to be compatible with these
+      legacy implementations.
+
+      *  NegTokenTarg is changed to negTokenResp and it is the message
+         format for all subsequent negotiation tokens.
+      *  NegTokenInit is the message for the initial negotiation message
+         and that message only.
+      *  mechTypes in negTokenInit is not optional.
+      *  Two MIC tokens are exchanged, one in each direction.
+      *  If the selected mechanism is also the most preferred mechanism
+         for both peers, it is safe to omit the MIC tokens.
+
+      If at least one of the two peers implements the pseudo mechanism
+      in this document, the negotiation is protected.
+
+      The following changes are to address the problems in RFC 2478.
+
+      *  reqFlags is not protected therefore it should not impact the
+         negotiation.
+      *  DER encoding is required.
+      *  GSS_GetMIC() input is clarified.
+      *  Per-message integrity services are requested for the negotiated
+         mechanism.
+
+   An implementation that conforms to this specification  will not
+   interoperate with a strict 2748 implementation.  Even if the new
+   implementation always sends a mechlistMIC token, it will still fail
+   to interoperate.  If it is a server, it will fail because it requests
+   a mechlistMIC token using an option that older implementations simply
+   do not support.  Clients will tend to fail as well.
+
+   As an alternative to the approach chosen in this specification, we
+   could have documented a correct behavior that is fully backward
+   compatible with RFC 2478 and included an appendix on how to
+   interoperate with existing incorrect implementations of RFC 2478.
+
+   As a practical matter, the SPNEGO implementers within the IETF have
+   valued interoperability with the Microsoft implementations.  We were
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 23]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   unable to choose to maintain reasonable security guarantees, maintain
+   interoperability with the Microsoft implementations and maintain
+   interoperability with correct implementations of RFC 2478.  The
+   working group was not aware of any RFC 2478 implementations.  Even if
+   there are RFC 2478 implementations, it is unlikely that they will
+   interoperate because of a critical flaw in the description of the
+   encoding of the mechanism list in RFC 2478.
+
+   With the approach taken in this specification, we get security
+   between new implementations all the time while maintaining
+   interoperability with the implementations we have within the IETF
+   community.  The working group believes that this justifies breaking
+   compatibility with a correct implementation of RFC 2478.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 24]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires June 1, 2005                 [Page 25]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-04.txt
new file mode 100644
index 00000000000..48c11d2169c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-04.txt
@@ -0,0 +1,1570 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Obsoletes: 2478 (if approved)                              K. Jaganathan
+Expires: June 15, 2005                             Microsoft Corporation
+                                                            W. Ingersoll
+                                                        Sun Microsystems
+                                                       December 15, 2004
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+                      draft-ietf-kitten-2478bis-04
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on June 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies a negotiation mechanism for the Generic
+   Security Service Application Program Interface (GSS-API) which is
+   described in RFC 2743.
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 1]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   GSS-API peers can use this negotiation mechanism to choose from a
+   common set of security mechanisms.
+
+   If per-message integrity services are available on the established
+   mechanism context, then the negotiation is protected against an
+   attacker forcing the selection of a mechanism not desired by the
+   peers.
+
+   This mechanism replaces RFC 2478 in order to fix defects in that
+   specification and to describe how to interoperate with
+   implementations of that specification commonly deployed on the
+   Internet.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
+     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
+     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
+   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . . 10
+     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . . 10
+     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
+       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
+       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
+   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 14
+   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 17
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
+   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 21
+   10.2  Informative References . . . . . . . . . . . . . . . . . . . 21
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
+   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 23
+     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23
+     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23
+   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 25
+   C.  mechListMIC Computation Example  . . . . . . . . . . . . . . . 27
+       Intellectual Property and Copyright Statements . . . . . . . . 28
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 2]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+1.  Introduction
+
+   The GSS-API [RFC2743] provides a generic interface which can be
+   layered atop different security mechanisms such that if communicating
+   peers acquire GSS-API credentials for the same security mechanism,
+   then a security context may be established between them (subject to
+   policy).  However, GSS-API does not prescribe the method by which
+   GSS-API peers can establish whether they have a common security
+   mechanism.
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo security mechanism, represented by the
+   Object Identifier iso.org.dod.internet.security.mechanism.snego
+   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
+   whether their credentials support a common set of one or more GSS-API
+   security mechanisms, and if so, to invoke the normal security context
+   establishment for a selected common security mechanism.  This is most
+   useful for applications which depend on GSS-API implementations and
+   share multiple mechanisms between the peers.
+
+   The SPNEGO mechanism negotiation is based on the following model: the
+   initiator proposes a list of security mechanism(s), in decreasing
+   preference order (favorite choice first), the acceptor (also known as
+   the target) either accepts the initiator's preferred security
+   mechanism (the first in the list), or chooses one that is available
+   from the offered list, or rejects the proposed value(s).  The target
+   then informs the initiator of its choice.
+
+   Once a common security mechanism is chosen, mechanism-specific
+   options MAY be negotiated as part of the selected mechanism's context
+   establishment.  These negotiations (if any) are internal to the
+   mechanism and opaque to the SPNEGO protocol.  As such they are
+   outside the scope of this document.
+
+   If per-message integrity services are available on the established
+   mechanism security context, then the negotiation is protected to
+   ensure that the mechanism list has not been modified.  In cases where
+   an attacker could have materially influenced the negotiation, peers
+   exchange message integrity code (MIC) tokens to confirm the mechanism
+   list has not been modified.  If no action of an attacker could have
+   materially modified the outcome of the negotiation, the exchange of
+   MIC tokens is optional (see Section 5).  Allowing MIC tokens to be
+   optional in this case provides interoperability with existing
+   implementations while still protecting the negotiation.  This
+   interoperability comes at the cost of increased complexity.
+
+   In order to avoid an extra round trip, the first context
+   establishment token of the initiator's preferred mechanism SHOULD be
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 3]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   embedded in the initial negotiation message (as defined in Section
+   4.2).  (This mechanism token is referred to as the optimistic
+   mechanism token in this document.) In addition, using the optimistic
+   mechanism token allows the initiator to recover from non-fatal errors
+   encountered trying to produce the first mechanism token before a
+   mechanism can be selected.  Implementations MAY omit the optimistic
+   mechanism token in cases where the likelihood of the initiator's
+   preferred mechanism not being selected by the acceptor is significant
+   given the cost of generating it.
+
+   SPNEGO relies on the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+   the existence of the negotiation tokens but only of the new
+   pseudo-security mechanism.  A failure in the negotiation phase causes
+   a major status code to be returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 4]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 5]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+3.  Negotiation Protocol
+
+   When the established mechanism context provides integrity protection,
+   the mechanism negotiation can be protected.  When acquiring
+   negotiated security mechanism tokens, per-message integrity services
+   are always requested by the SPNEGO mechanism.
+
+   When the established mechanism context supports per-message integrity
+   services, SPNEGO guarantees that the selected mechanism is mutually
+   preferred.
+
+   This section describes the negotiation process of this protocol.
+
+3.1  Negotiation Description
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms in decreasing preference order (favorite mechanism
+   first), and optionally the initial mechanism token for the preferred
+   mechanism of the initiator (i.e., the first in the list).  (Note that
+   the list MUST NOT contain mechanisms for which the client does not
+   have appropriate credentials.)
+
+   The target then processes the token from the initiator.  This will
+   result in one of four possible states (as defined in Section 4.2.2)
+   being returned in the reply message: accept_completed,
+   accept_incomplete, reject, or request_mic.  A reject state will
+   terminate the negotiation;  an accept_completed state indicates that
+   not only was the initiator-selected mechanism acceptable to the
+   target, but also that the optimistic mechanism token was sufficient
+   to complete the authentication;  an accept_incomplete state indicates
+   that further message exchange is needed but the MIC token exchange as
+   described in Section 5 is OPTIONAL;  a request_mic state (this state
+   can only be present in the first reply message from the target)
+   indicates the MIC token exchange is REQUIRED if per-message integrity
+   services are available.
+
+   Unless the preference order is specified by the application, the
+   policy by which the target chooses a mechanism is an
+   implementation-specific local matter.  In the absence of an
+   application specified preference order or other policy, the target
+   SHALL choose the first mechanism in the initiator proposed list for
+   which it has valid credentials.
+
+   In case of a successful negotiation, the security mechanism in the
+   first reply message represents the value suitable for the target,
+   chosen from the list offered by the initiator.
+
+   In case of an unsuccessful negotiation, the reject state is returned
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 6]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   and it is OPTIONAL to emit a context level negotiation token.
+
+   Once a mechanism has been selected, context establishment tokens
+   specific to the selected mechanism are carried within the negotiation
+   tokens.
+
+   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
+   mechanism list received by the target.
+
+   To avoid conflicts with the use of MIC tokens by SPNEGO,
+   partially-established contexts MUST NOT be used for per-message
+   calls.  To guarantee this, the prot_ready_state [RFC2743] MUST be set
+   to false on return from GSS_Init_sec_context() and
+   GSS_Accept_sec_context() even if the underlying mechanism returned
+   true.
+
+3.2  Negotiation Procedure
+
+   The basic form of the procedure assumes that per-message integrity
+   services are available on the established mechanism context, and it
+   is summarized as follows:
+
+   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests that SPNEGO be used.  SPNEGO can either be explicity
+      requested or accepted as the default mechanism.
+
+   (b) The initiator GSS-API implementation emits a negotiation token
+      containing a list of one or more security mechanisms that are
+      available based on the credentials used for this context
+      establishment, and optionally the initial mechanism token for the
+      first mechanism in the list.
+
+   (c) The GSS-API initiator application sends the token to the target
+      application.  The GSS-API target application deposits the token by
+      invoking GSS_Accept_sec_context().  The acceptor will do one of
+      the following:
+
+
+         (I) If none of the proposed mechanisms are acceptable, the
+            negotiation SHALL be terminated.  GSS_Accept_sec_context
+            indicates GSS_S_BAD_MECH.  The acceptor MAY output a
+            negotiation token containing a reject state.
+
+         (II) If either the initiator's preferred mechanism is not
+            accepted by the target or this mechanism is accepted but it
+            is not the acceptor's most preferred mechanism (i.e., the
+            MIC token exchange as described in Section 5 is required),
+            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 7]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+            The acceptor MUST output a negotiation token containing a
+            request_mic state.
+
+         (III) Otherwise if at least one additional negotiation token
+            from the initiator is needed to establish this context,
+            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
+            outputs a negotiation token containing an accept_incomplete
+            state.
+
+         (IV) Otherwise no additional negotiation token from the
+            initiator is needed to establish this context,
+            GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
+            outputs a negotiation token containing an accept_complete
+            state.
+
+      If the initiator's preferred mechanism is accepted, and an
+      optimistic mechanism token was included, this mechanism token MUST
+      be deposited to the selected mechanism by invoking
+      GSS_Accept_sec_context() and if a response mechanism token is
+      emitted, it MUST be included in the response negotiation token.
+      Otherwise, the target will not emit a response mechanism token in
+      the first reply.
+
+   (d) The GSS-API target application returns the negotiation token to
+      the initiator application.  The GSS-API initiator application
+      deposits the token by invoking GSS_Init_sec_context().  The
+      security context initialization is then continued according to the
+      standard GSS-API conventions for the selected mechanism, where the
+      tokens of the selected mechanism are encapsulated in negotiation
+      messages (see Section 4) until the GSS_S_COMPLETE is returned for
+      both the initiator and the target by the selected security
+      mechanism.
+
+   (e) MIC tokens are then either skipped or exchanged according to
+      Section 5.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested and was not supported.
+
+   When a GSS-API credential is acquired for the SPNEGO mechanism the
+   implementation SHOULD produce a credential element for the SPNEGO
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 8]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   mechanism which internally contains GSS-API credential elements for
+   all mechanisms for which the principal has credentials available,
+   except for any mechanisms which are not to be negotiated, either as
+   per implementation-, site- or application-specific policy.  See
+   Appendix A for interfaces for expressing application policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                  [Page 9]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+4.  Token Definitions
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+      SPNEGOASNOneSpec {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanism(5) snego (2) modules(4) spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- rest of definitions here
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   The encoding of SPNEGO protocol messages shall obey the Distinguished
+   Encoding Rules (DER) of ASN.1 as described in [X690].
+
+4.1  Mechanism Types
+
+   In this negotiation model, each OID represents one GSS-API mechanism
+   or one variant (see Section 6) of it according to [RFC2743].
+
+
+       MechType ::= OBJECT IDENTIFIER
+           -- OID represents each security mechanism as suggested by
+           -- [RFC2743]
+
+       MechTypeList ::= SEQUENCE OF MechType
+
+
+4.2  Negotiation Tokens
+
+   The syntax of the initial negotiation tokens follows the
+   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
+   SPNEGO pseudo mechanism is identified by the Object Identifier
+   specified in Section 1.  Subsequent tokens MUST NOT be encapsulated
+   in this GSS-API generic token framing.
+
+   This section specifies the syntax of the inner token for the initial
+   message and the syntax of subsequent context establishment tokens.
+
+       NegotiationToken ::= CHOICE {
+           negTokenInit    [0] NegTokenInit,
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 10]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+           negTokenResp    [1] negTokenResp
+       }
+
+
+
+4.2.1  negTokenInit
+
+       NegTokenInit ::= SEQUENCE {
+           mechTypes       [0] MechTypeList,
+           reqFlags        [1] ContextFlags  OPTIONAL,
+             -- maintained from RFC 2478 for backward compatibility,
+             -- RECOMMENDED to be left out
+           mechToken       [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+       ContextFlags ::= BIT STRING {
+           delegFlag       (0),
+           mutualFlag      (1),
+           replayFlag      (2),
+           sequenceFlag    (3),
+           anonFlag        (4),
+           confFlag        (5),
+           integFlag       (6)
+       }
+
+   This is the syntax for the inner token of the initial negotiation
+   message.
+
+   mechTypes
+
+         This field contains one or more security mechanisms available
+         for the initiator in decreasing preference order (favorite
+         choice first).
+
+   reqFlags
+
+         This field, if present, contains the service options that are
+         requested to establish the context.  The context flags SHOULD
+         be filled in from the req_flags parameter of
+         GSS_Init_sec_context().  This field SHALL NOT have impact on
+         the negotiation.
+
+   mechToken
+
+         This field, if present, contains the optimistic mechanism
+         token.
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 11]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   mechlistMIC
+
+         This field, if present, contains a MIC token for the mechanism
+         list in the initial negotiation message.  This MIC token is
+         computed according to Section 5.
+
+
+4.2.2  negTokenResp
+
+       NegTokenResp ::= SEQUENCE {
+           negState       [0] ENUMERATED {
+               accept_completed    (0),
+               accept_incomplete   (1),
+               reject              (2),
+               request_mic         (3)
+           }                                 OPTIONAL,
+             -- REQUIRED in the first reply from the target
+           supportedMech   [1] MechType      OPTIONAL,
+             -- present only in the first reply from the target
+           responseToken   [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+
+   This is the syntax for all subsequent negotiation messages.
+
+   negState
+
+         This field, if present, contains the state of the negotiation.
+         This can be:
+
+         accept_completed
+
+            No further negotiation message from the peer is expected,
+            and the security context is established for the sender.
+
+         accept_incomplete
+
+            At least one more negotiation message from the peer is
+            needed to establish the security context.
+
+         reject
+
+            The sender terminates the negotiation.
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 12]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+         request_mic
+
+            The sender indicates that the exchange of MIC tokens, as
+            described in Section 5, will be REQUIRED if per-message
+            integrity services are available on the mechanism context to
+            be established.  This value SHALL only be present in the
+            first reply from the target.
+
+         This field is REQUIRED in the first reply from the target, and
+         it is OPTIONAL thereafter.  When negState is absent the actual
+         state should be inferred from the state of the negotiated
+         mechanism context.
+
+   supportedMech
+
+         This field SHALL only be present in the first reply from the
+         target.  It MUST be one of the mechanism(s) offered by the
+         initiator.
+
+   ResponseToken
+
+         This field, if present, contains tokens specific to the
+         mechanism selected.
+
+   mechlistMIC
+
+         This field, if present, contains a MIC token for the mechanism
+         list in the initial negotiation message.  This MIC token is
+         computed according to Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 13]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+5.  Processing of mechListMIC
+
+   If the mechanism selected by the negotiation does not support
+   integrity protection, then no mechlistMIC token is used.
+
+   Otherwise, if the accepted mechanism is the most preferred mechanism
+   of both the initiator and the acceptor, then the MIC token exchange,
+   as described later in this section, is OPTIONAL.  A mechanism is the
+   acceptor's most preferred mechanism if there is no other mechanism
+   which, had it been present in the mechanism list, the acceptor would
+   have preferred over the accepted mechanism.
+
+   In all other cases, MIC tokens MUST be exchanged after the mechanism
+   context is fully established.
+
+   a) The mechlistMIC token (or simply the MIC token) is computed over
+      the mechanism list in the initial negotiation message by invoking
+      GSS_GetMIC() as follows: the input context_handle is the
+      established mechanism context, the input qop_req is 0, and the
+      input message is the DER encoding of the value of type
+      MechTypeList which is contained in the "mechTypes" field of the
+      NegTokenInit.  The input message is NOT the DER encoding of the
+      type "[0] MechTypeList".
+
+   b) If the selected mechanism exchanges an even number of mechanism
+      tokens (i.e., the acceptor sends the last mechanism token), the
+      acceptor does the following when emitting the negotiation message
+      containing the last mechanism token: if the MIC token exchange is
+      optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE
+      and does not include a mechlistMIC token, or indicates
+      GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an
+      accept_incomplete state; if the MIC token exchange is required,
+      GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and
+      includes a mechlistMIC token.  Acceptors that wish to be
+      compatible with legacy Windows SPNEGO implementations as described
+      in Appendix B should not generate a mechlistMIC token when the MIC
+      token exchange is not required.  The initiator then processes the
+      last mechanism token, and does one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
+         output negotiation message contains a mechlistMIC token, and an
+         accept_complete state.  The acceptor MUST then verify this
+         mechlistMIC token.
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 14]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Init_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included, and the MIC token
+         exchange is not required, GSS_Init_sec_context() indicates
+         GSS_S_COMPLETE with no output token.
+
+      (IV) If no mechlistMIC token was included, but the MIC token
+         exchange is required, the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+   c) In the case that the chosen mechanism exchanges an odd number of
+      mechanism tokens (i.e., the initiator sends the last mechanism
+      token), the initiator does the following when emitting the
+      negotiation message containing the last mechanism token: if the
+      negState was request_mic in the first reply from the target, a
+      mechlistMIC token MUST be included, otherwise the mechlistMIC
+      token is OPTIONAL.  (Note that the MIC token exchange is required
+      if a mechanism other than the initiator's first choice is chosen.)
+      In the case that the optimistic mechanism token is the only
+      mechanism token for the initiator's preferred mechanism, the
+      mechlistMIC token is OPTIONAL.  Whether or not the mechlistMIC
+      token is included, GSS_Init_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED.  Initiators that wish to be compatible with
+      legacy Windows SPNEGO implementations as described in Appendix B
+      should not generate a mechlistMIC token when the MIC token
+      exchange is not required.  The acceptor then processes the last
+      mechanism token and does one of the following:
+
+      (I) If a mechlistMIC token was included and is correctly verified,
+         GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
+         negotiation message contains a mechlistMIC token and an
+         accept_complete state.  The initiator MUST then verify this
+         mechlistMIC token.
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included but the mechlistMIC
+         token exchange is not required, GSS_Accept_sec_context()
+         indicates GSS_S_COMPLETE.  The output negotiation message
+         contains an accept_complete state.
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 15]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+      (IV) In the case that the optimistic mechanism token is also the
+         last mechanism token (when the initiator's preferred mechanism
+         is accepted by the target) and the target sends a request_mic
+         state but the initiator did not send a mechlistMIC token, the
+         target then MUST include a mechlistMIC token in that first
+         reply.  GSS_Accept_sec_context() indicates
+         GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
+         mechlistMIC token and generate a mechlistMIC token to send back
+         to the target.  The target SHALL in turn verify the returned
+         mechlistMIC token and complete the negotiation.
+
+      (V) If no mechlistMIC token was included and the acceptor sent a
+         request_mic state in the first reply message (the exchange of
+         MIC tokens is required), the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 16]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+6.  Extensibility
+
+   Two mechanisms are provided for extensibility.  First, the ASN.1
+   structures in this specification MAY be expanded by IETF standards
+   action.  Implementations receiving unknown fields MUST ignore these
+   fields.
+
+   Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
+   mechanism variants) may be included in the set of preferred
+   mechanisms by an initiator.  The acceptor can choose to honor this
+   request by preferring mechanisms that have the included attributes.
+   Future work within the Kitten working group is expected to
+   standardize common attributes that SPNEGO mechanisms may wish to
+   support.  At this time it is sufficient to say that initiators MAY
+   include OIDs that do not correspond to mechanisms.  Such OIDs MAY
+   influence the acceptor's choice of mechanism.  As discussed in
+   Section 5, if there are mechanisms that if present in the initiator's
+   list of mechanisms might be preferred by the acceptor to the
+   initiator's preferred mechanism, the acceptor MUST demand the MIC
+   token exchange.  As a consequence, acceptors MUST demand the MIC
+   token exchange if they support negotiation of attributes not
+   available in the initiator's preferred mechanism regardless of
+   whether the initiator actually requested these attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 17]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+7.  Security Considerations
+
+   In order to produce the MIC token for the mechanism list, the
+   mechanism must provide integrity protection.  When the selected
+   mechanism does not support integrity protection, the negotiation is
+   vulnerable: an active attacker can force it to use a security
+   mechanism that is not mutually preferred but is acceptable to the
+   target.
+
+   This protocol provides the following guarantees when per-message
+   integrity services are available on the established mechanism context
+   and the mechanism list was altered by an adversary such that a
+   mechanism which is not mutually preferred could be selected:
+
+   a) If the last mechanism token is sent by the initiator, both peers
+      shall fail;
+   b) If the last mechanism token is sent by the acceptor, the acceptor
+      shall not complete and the initiator at worst shall complete with
+      its preferred mechanism being selected.
+
+   The negotiation may not be terminated if an alteration was made but
+   it had no material impact.
+
+   The protection of the negotiation depends on the strength of the
+   integrity protection.  In particular, the strength of SPNEGO is no
+   stronger than the integrity protection of the weakest mechanism
+   acceptable to GSS-API peers.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 18]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+8.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 19]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+9.  Acknowledgments
+
+   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
+   Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
+   and suggestions during development of this document.
+
+   Luke Howard provided a prototype of this protocol in Heimdal and
+   resolved several issues in the initial draft.
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478] of which some of the text has been retained in this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 20]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+10.  References
+
+10.1  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
+              Rules (BER), Canonical Encoding Rules (CER) and 
+              Distinguished Encoding Rules (DER), ITU-T Recommendation 
+              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
+
+10.2  Informative References
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 21]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   Wyllys Ingersoll
+   Sun Microsystems
+   1775 Wiehle Avenue, 2nd Floor
+   Reston, VA  20190
+   US
+
+   EMail: wyllys.ingersoll@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 22]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Appendix A.  GSS-API Negotiation Support API
+
+   In order to provide to a GSS-API caller (either the initiator or the
+   target or both) the ability to choose among the set of supported
+   mechanisms a reduced set of mechanisms for negotiation, two
+   additional APIs are defined:
+
+   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
+      available on the local system to the caller for negotiation, for
+      which appropriate credentials are available.
+   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+      used on the local system by the caller for negotiation, for the
+      given credentials.
+
+A.1  GSS_Set_neg_mechs call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
+      -- credentials
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been set to mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to specify the set of security mechanisms that may be
+   negotiated with the credential identified by cred_handle.  This call
+   is intended for support of specialized callers who need to restrict
+   the set of negotiable security mechanisms from the set of all
+   security mechanisms available to the caller (based on available
+   credentials).  Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative preference.
+
+A.2  GSS_Get_neg_mechs call
+
+   Input:
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 23]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
+      -- credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been returned in mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of security mechanisms available
+   for negotiation with the credential identified by cred_handle.  This
+   call is intended for support of specialized callers who need to
+   reduce the set of negotiable security mechanisms from the set of
+   supported security mechanisms available to the caller (based on
+   available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system.  Since this call has
+   no input parameter, the returned set is not necessarily available for
+   all credentials.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 24]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Appendix B.  Changes since RFC2478
+
+      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
+      2003 have the following behavior: no mechlistMIC is produced and
+      mechlistMIC is not processed if one is provided; if the initiator
+      sends the last mechanism token, the acceptor will send back a
+      negotiation token with an accept_complete state and no mechlistMIC
+      token.  In addition, an incorrect OID (1.2.840.48018.1.2.2) can be
+      used to identify the GSS-API Kerberos Version 5 mechanism.
+
+      The following changes have been made to be compatible with these
+      legacy implementations.
+
+      *  NegTokenTarg is changed to negTokenResp and it is the message
+         format for all subsequent negotiation tokens.
+      *  NegTokenInit is the message for the initial negotiation message
+         and that message only.
+      *  mechTypes in negTokenInit is not optional.
+      *  If the selected mechanism is also the most preferred mechanism
+         for both peers, it is safe to omit the MIC tokens.
+
+      If at least one of the two peers implements the updated pseudo
+      mechanism in this document, the negotiation is protected.
+
+      The following changes are to address the problems in RFC 2478.
+
+      *  reqFlags is not protected therefore it should not impact the
+         negotiation.
+      *  DER encoding is required.
+      *  GSS_GetMIC() input is clarified.
+      *  Per-message integrity services are requested for the negotiated
+         mechanism.
+      *  Two MIC tokens are exchanged, one in each direction.
+
+   An implementation that conforms to this specification will not
+   interoperate with a strict 2748 implementation.  Even if the new
+   implementation always sends a mechlistMIC token, it will still fail
+   to interoperate.  If it is a server, it will fail because it requests
+   a mechlistMIC token using an option that older implementations simply
+   do not support.  Clients will tend to fail as well.
+
+   As an alternative to the approach chosen in this specification, we
+   could have documented a correct behavior that is fully backward
+   compatible with RFC 2478 and included an appendix on how to
+   interoperate with existing incorrect implementations of RFC 2478.
+
+   As a practical matter, the SPNEGO implementers within the IETF have
+   valued interoperability with the Microsoft implementations.  We were
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 25]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+   unable to choose to maintain reasonable security guarantees, maintain
+   interoperability with the Microsoft implementations and maintain
+   interoperability with correct implementations of RFC 2478.  The
+   working group was not aware of any RFC 2478 implementations deployed
+   on the Internet.  Even if there are such implementations, it is
+   unlikely that they will interoperate because of a critical flaw in
+   the description of the encoding of the mechanism list in RFC 2478.
+
+   With the approach taken in this specification, security is ensured
+   between new implementations all the time while maintaining
+   interoperability with the implementations deployed within the IETF
+   community.  The working group believes that this justifies breaking
+   compatibility with a correct implementation of RFC 2478.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 26]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Appendix C.  mechListMIC Computation Example
+
+   The following is an example to illustrate how the mechListMIC field
+   would be computed.
+
+   The initial part of the DER encoding of NegTokenInit is constructed
+   as follows (the "nn" are length encodings, possibly longer than one
+   octet):
+
+      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
+      nn -- length
+
+         -- contents octets of the SEQUENCE begin with
+         -- DER encoding of "[0] MechTypeList":
+         A0 -- identifier octet for constructed [0]
+         nn -- length
+
+             -- contents of the constructed [0] are DER encoding
+             -- of MechTypeList (which is a SEQUENCE):
+             30 -- identifier octet for constructed SEQUENCE
+             nn -- length
+
+                -- contents octets of the SEQUENCE begin with
+                -- DER encoding of OBJECT IDENTIFIER:
+                06 -- identifier octet for primitive OBJECT IDENTIFIER
+                09 -- length
+                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
+                                           -- {1 2 840 113554 1 2 2}
+
+   If a mechlistMIC needs to be generated (according to the rules in
+   Section 5), it is computed by using the DER encoding of the type
+   MechTypeList data from the initiator's NegTokenInit token as input to
+   the GSS_GetMIC() function.  In this case, the MIC would be computed
+   over the following octets:
+
+      DER encoding of MechTypeList:
+      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
+
+   Note that the identifier octet and lengh octet(s) for constructed [0]
+   (A0 nn) are not included in the MIC computation.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 27]
+
+Internet-Draft       GSS-API Negotiation Mechanism         December 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.              Expires June 15, 2005                 [Page 28]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-05.txt
new file mode 100644
index 00000000000..84e0256770a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-2478bis-05.txt
@@ -0,0 +1,1680 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Obsoletes: 2478 (if approved)                              K. Jaganathan
+Expires: July 27, 2005                             Microsoft Corporation
+                                                            W. Ingersoll
+                                                        Sun Microsystems
+                                                        January 23, 2005
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+                      draft-ietf-kitten-2478bis-05
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on July 27, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies a negotiation mechanism for the Generic
+   Security Service Application Program Interface (GSS-API) which is
+   described in RFC 2743.
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 1]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   GSS-API peers can use this negotiation mechanism to choose from a
+   common set of security mechanisms.
+
+   If per-message integrity services are available on the established
+   mechanism context, then the negotiation is protected against an
+   attacker forcing the selection of a mechanism not desired by the
+   peers.
+
+   This mechanism replaces RFC 2478 in order to fix defects in that
+   specification and to describe how to inter-operate with
+   implementations of that specification commonly deployed on the
+   Internet.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
+     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
+     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
+   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . . 10
+     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . . 10
+     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
+       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
+       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
+   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 14
+   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 17
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
+   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     10.1  Normative References . . . . . . . . . . . . . . . . . . . 21
+     10.2  Informative References . . . . . . . . . . . . . . . . . . 21
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
+   A.  SPNEGO ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 23
+   B.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 25
+     B.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25
+     B.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25
+   C.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 27
+   D.  mechListMIC Computation Example  . . . . . . . . . . . . . . . 29
+       Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 2]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+1.  Introduction
+
+   The GSS-API [RFC2743] provides a generic interface which can be
+   layered atop different security mechanisms such that if communicating
+   peers acquire GSS-API credentials for the same security mechanism,
+   then a security context may be established between them (subject to
+   policy).  However, GSS-API does not prescribe the method by which
+   GSS-API peers can establish whether they have a common security
+   mechanism.
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo security mechanism, which enables GSS-API
+   peers to determine in-band whether their credentials support a common
+   set of one or more GSS-API security mechanisms, and if so, to invoke
+   the normal security context establishment for a selected common
+   security mechanism.  This is most useful for applications which
+   depend on GSS-API implementations and share multiple mechanisms
+   between the peers.
+
+   The SPNEGO mechanism negotiation is based on the following model: the
+   initiator proposes a list of security mechanism(s), in decreasing
+   preference order (favorite choice first), the acceptor (also known as
+   the target) either accepts the initiator's preferred security
+   mechanism (the first in the list), or chooses one that is available
+   from the offered list, or rejects the proposed value(s).  The target
+   then informs the initiator of its choice.
+
+   Once a common security mechanism is chosen, mechanism-specific
+   options MAY be negotiated as part of the selected mechanism's context
+   establishment.  These negotiations (if any) are internal to the
+   mechanism and opaque to the SPNEGO protocol.  As such they are
+   outside the scope of this document.
+
+   If per-message integrity services are available on the established
+   mechanism security context, then the negotiation is protected to
+   ensure that the mechanism list has not been modified.  In cases where
+   an attacker could have materially influenced the negotiation, peers
+   exchange message integrity code (MIC) tokens to confirm the mechanism
+   list has not been modified.  If no action of an attacker could have
+   materially modified the outcome of the negotiation, the exchange of
+   MIC tokens is optional (see Section 5).  Allowing MIC tokens to be
+   optional in this case provides interoperability with existing
+   implementations while still protecting the negotiation.  This
+   interoperability comes at the cost of increased complexity.
+
+   SPNEGO relies on the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 3]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   the existence of the negotiation tokens but only of the new
+   pseudo-security mechanism.  A failure in the negotiation phase causes
+   a major status code to be returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 4]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 5]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+3.  Negotiation Protocol
+
+   When the established mechanism context provides integrity protection,
+   the mechanism negotiation can be protected.  When acquiring
+   negotiated security mechanism tokens, per-message integrity services
+   are always requested by the SPNEGO mechanism.
+
+   When the established mechanism context supports per-message integrity
+   services, SPNEGO guarantees that the selected mechanism is mutually
+   preferred.
+
+   This section describes the negotiation process of this protocol.
+
+3.1  Negotiation Description
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms in decreasing preference order (favorite mechanism
+   first), and optionally the initial mechanism token for the preferred
+   mechanism of the initiator (i.e., the first in the list).  (Note that
+   the list MUST NOT contain either this SPNEGO mechanism itself or any
+   mechanism for which the client does not have appropriate
+   credentials.)
+
+   The target then processes the token from the initiator.  This will
+   result in one of four possible states (as defined in Section 4.2.2)
+   being returned in the reply message: accept-completed,
+   accept-incomplete, reject, or request-mic.  A reject state will
+   terminate the negotiation;  an accept-completed state indicates that
+   not only was the initiator-selected mechanism acceptable to the
+   target, but also that the security mechanism token embedded in the
+   first negotiation message was sufficient to complete the
+   authentication;  an accept-incomplete state indicates that further
+   message exchange is needed but the MIC token exchange as described in
+   Section 5 is OPTIONAL;  a request-mic state (this state can only be
+   present in the first reply message from the target) indicates the MIC
+   token exchange is REQUIRED if per-message integrity services are
+   available.
+
+   Unless the preference order is specified by the application, the
+   policy by which the target chooses a mechanism is an
+   implementation-specific local matter.  In the absence of an
+   application specified preference order or other policy, the target
+   SHALL choose the first mechanism in the initiator proposed list for
+   which it has valid credentials.
+
+   In case of a successful negotiation, the security mechanism in the
+   first reply message represents the value suitable for the target,
+   chosen from the list offered by the initiator.
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 6]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   In case of an unsuccessful negotiation, the reject state is returned
+   and generating a context level negotiation token is OPTIONAL.
+
+   Once a mechanism has been selected, context establishment tokens
+   specific to the selected mechanism are carried within the negotiation
+   tokens.
+
+   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
+   mechanism list received by the target.
+
+   To avoid conflicts with the use of MIC tokens by SPNEGO,
+   partially-established contexts MUST NOT be used for per-message
+   calls.  To guarantee this, the prot_ready_state [RFC2743] MUST be set
+   to false on return from GSS_Init_sec_context() and
+   GSS_Accept_sec_context() even if the underlying mechanism returned
+   true.
+
+   Note that in order to avoid an extra round trip, the first context
+   establishment token of the initiator's preferred mechanism SHOULD be
+   embedded in the initial negotiation message (as defined in
+   Section 4.2).  (This mechanism token is referred to as the optimistic
+   mechanism token in this document.) In addition, using the optimistic
+   mechanism token allows the initiator to recover from non-fatal errors
+   encountered trying to produce the first mechanism token before a
+   mechanism can be selected.  Implementations MAY omit the optimistic
+   mechanism token in cases where the likelihood of the initiator's
+   preferred mechanism not being selected by the acceptor is significant
+   given the cost of generating it.
+
+3.2  Negotiation Procedure
+
+   The basic form of the procedure assumes that per-message integrity
+   services are available on the established mechanism context, and it
+   is summarized as follows:
+
+   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests that SPNEGO be used.  SPNEGO can either be explicitly
+      requested or accepted as the default mechanism.
+
+   (b) The initiator GSS-API implementation generates a negotiation
+      token containing a list of one or more security mechanisms that
+      are available based on the credentials used for this context
+      establishment, and optionally the initial mechanism token for the
+      first mechanism in the list.
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 7]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   (c) The GSS-API initiator application sends the token to the target
+      application.  The GSS-API target application passes the token by
+      invoking GSS_Accept_sec_context().  The acceptor will do one of
+      the following:
+
+
+         (I) If none of the proposed mechanisms are acceptable, the
+            negotiation SHALL be terminated.  GSS_Accept_sec_context
+            indicates GSS_S_BAD_MECH.  The acceptor MAY output a
+            negotiation token containing a reject state.
+
+         (II) If either the initiator's preferred mechanism is not
+            accepted by the target or this mechanism is accepted but it
+            is not the acceptor's most preferred mechanism (i.e., the
+            MIC token exchange as described in Section 5 is required),
+            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
+            The acceptor MUST output a negotiation token containing a
+            request-mic state.
+
+         (III) Otherwise if at least one additional negotiation token
+            from the initiator is needed to establish this context,
+            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
+            outputs a negotiation token containing an accept-incomplete
+            state.
+
+         (IV) Otherwise no additional negotiation token from the
+            initiator is needed to establish this context,
+            GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
+            outputs a negotiation token containing an accept_complete
+            state.
+
+      If the initiator's preferred mechanism is accepted, and an
+      optimistic mechanism token was included, this mechanism token MUST
+      be passed to the selected mechanism by invoking
+      GSS_Accept_sec_context() and if a response mechanism token is
+      returned, it MUST be included in the response negotiation token.
+      Otherwise, the target will not generate a response mechanism token
+      in the first reply.
+
+   (d) The GSS-API target application returns the negotiation token to
+      the initiator application.  The GSS-API initiator application
+      passes the token by invoking GSS_Init_sec_context().  The security
+      context initialization is then continued according to the standard
+      GSS-API conventions for the selected mechanism, where the tokens
+      of the selected mechanism are encapsulated in negotiation messages
+      (see Section 4) until GSS_S_COMPLETE is returned for both the
+      initiator and the target by the selected security mechanism.
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 8]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   (e) MIC tokens are then either skipped or exchanged according to
+      Section 5.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested and was not supported.
+
+   When a GSS-API credential is acquired for the SPNEGO mechanism the
+   implementation SHOULD produce a credential element for the SPNEGO
+   mechanism which internally contains GSS-API credential elements for
+   all mechanisms for which the principal has credentials available,
+   except for any mechanisms which are not to be negotiated, either as
+   per implementation-, site- or application-specific policy.  See
+   Appendix B for interfaces for expressing application policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                 [Page 9]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+4.  Token Definitions
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+       SPNEGOASNOneSpec {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanism(5) snego (2) modules(4) spec2(2)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       -- rest of definitions here
+
+       END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   The encoding of SPNEGO protocol messages shall obey the Distinguished
+   Encoding Rules (DER) of ASN.1 as described in [X690].
+
+4.1  Mechanism Types
+
+   In this negotiation model, each OID represents one GSS-API mechanism
+   or one variant (see Section 6) of it according to [RFC2743].
+
+
+       MechType ::= OBJECT IDENTIFIER
+           -- OID represents each security mechanism as suggested by
+           -- [RFC2743]
+
+       MechTypeList ::= SEQUENCE OF MechType
+
+
+4.2  Negotiation Tokens
+
+   The syntax of the initial negotiation tokens follows the
+   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
+   SPNEGO pseudo mechanism is identified by the Object Identifier
+   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
+   Subsequent tokens MUST NOT be encapsulated in this GSS-API generic
+   token framing.
+
+   This section specifies the syntax of the inner token for the initial
+   message and the syntax of subsequent context establishment tokens.
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 10]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+       NegotiationToken ::= CHOICE {
+           negTokenInit    [0] NegTokenInit,
+           negTokenResp    [1] NegTokenResp
+       }
+
+
+
+4.2.1  negTokenInit
+
+       NegTokenInit ::= SEQUENCE {
+           mechTypes       [0] MechTypeList,
+           reqFlags        [1] ContextFlags  OPTIONAL,
+             -- inherited from RFC 2478 for backward compatibility,
+             -- RECOMMENDED to be left out
+           mechToken       [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+       ContextFlags ::= BIT STRING {
+           delegFlag       (0),
+           mutualFlag      (1),
+           replayFlag      (2),
+           sequenceFlag    (3),
+           anonFlag        (4),
+           confFlag        (5),
+           integFlag       (6)
+       } (SIZE (32))
+
+   This is the syntax for the inner token of the initial negotiation
+   message.
+
+   mechTypes
+
+         This field contains one or more security mechanisms available
+         for the initiator in decreasing preference order (favorite
+         choice first).
+
+   reqFlags
+
+         This field, if present, contains the service options that are
+         requested to establish the context (the req_flags parameter of
+         GSS_Init_sec_context()).  This field is inherited from RFC 2478
+         and it is not integrity protected.  For implementations of this
+         specification the initiator SHOULD omit this reqFlags field,
+         and the acceptor MUST ignore this reqFlags field.
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 11]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   mechToken
+
+         This field, if present, contains the optimistic mechanism
+         token.
+
+   mechlistMIC
+
+         This field, if present, contains a MIC token for the mechanism
+         list in the initial negotiation message.  This MIC token is
+         computed according to Section 5.
+
+
+4.2.2  negTokenResp
+
+       NegTokenResp ::= SEQUENCE {
+           negState       [0] ENUMERATED {
+               accept-completed    (0),
+               accept-incomplete   (1),
+               reject              (2),
+               request-mic         (3)
+           }                                 OPTIONAL,
+             -- REQUIRED in the first reply from the target
+           supportedMech   [1] MechType      OPTIONAL,
+             -- present only in the first reply from the target
+           responseToken   [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+
+   This is the syntax for all subsequent negotiation messages.
+
+   negState
+
+         This field, if present, contains the state of the negotiation.
+         This can be:
+
+         accept-completed
+
+            No further negotiation message from the peer is expected,
+            and the security context is established for the sender.
+
+         accept-incomplete
+
+            At least one more negotiation message from the peer is
+            needed to establish the security context.
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 12]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+         reject
+
+            The sender terminates the negotiation.
+
+         request-mic
+
+            The sender indicates that the exchange of MIC tokens, as
+            described in Section 5, will be REQUIRED if per-message
+            integrity services are available on the mechanism context to
+            be established.  This value SHALL only be present in the
+            first reply from the target.
+
+         This field is REQUIRED in the first reply from the target, and
+         it is OPTIONAL thereafter.  When negState is absent the actual
+         state should be inferred from the state of the negotiated
+         mechanism context.
+
+   supportedMech
+
+         This field SHALL only be present in the first reply from the
+         target.  It MUST be one of the mechanism(s) offered by the
+         initiator.
+
+   ResponseToken
+
+         This field, if present, contains tokens specific to the
+         mechanism selected.
+
+   mechlistMIC
+
+         This field, if present, contains a MIC token for the mechanism
+         list in the initial negotiation message.  This MIC token is
+         computed according to Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 13]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+5.  Processing of mechListMIC
+
+   If the mechanism selected by the negotiation does not support
+   integrity protection, then no mechlistMIC token is used.
+
+   Otherwise, if the accepted mechanism is the most preferred mechanism
+   of both the initiator and the acceptor, then the MIC token exchange,
+   as described later in this section, is OPTIONAL.  A mechanism is the
+   acceptor's most preferred mechanism if there is no other mechanism
+   which, had it been present in the mechanism list, the acceptor would
+   have preferred over the accepted mechanism.
+
+   In all other cases, MIC tokens MUST be exchanged after the mechanism
+   context is fully established.
+
+   a) The mechlistMIC token (or simply the MIC token) is computed over
+      the mechanism list in the initial negotiation message by invoking
+      GSS_GetMIC() as follows: the input context_handle is the
+      established mechanism context, the input qop_req is 0, and the
+      input message is the DER encoding of the value of type
+      MechTypeList which is contained in the "mechTypes" field of the
+      NegTokenInit.  The input message is NOT the DER encoding of the
+      type "[0] MechTypeList".
+
+   b) If the selected mechanism exchanges an even number of mechanism
+      tokens (i.e., the acceptor sends the last mechanism token), the
+      acceptor does the following when generating the negotiation
+      message containing the last mechanism token: if the MIC token
+      exchange is optional, GSS_Accept_sec_context() either indicates
+      GSS_S_COMPLETE and does not include a mechlistMIC token, or
+      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
+      and an accept-incomplete state; if the MIC token exchange is
+      required, GSS_Accept_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
+      Acceptors that wish to be compatible with legacy Windows SPNEGO
+      implementations as described in Appendix C should not generate a
+      mechlistMIC token when the MIC token exchange is not required.
+      The initiator then processes the last mechanism token, and does
+      one of the following:
+
+      (I) If a mechlistMIC token was included, and is correctly
+         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
+         output negotiation message contains a mechlistMIC token, and an
+         accept_complete state.  The acceptor MUST then verify this
+         mechlistMIC token.
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 14]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Init_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included, and the MIC token
+         exchange is not required, GSS_Init_sec_context() indicates
+         GSS_S_COMPLETE with no output token.
+
+      (IV) If no mechlistMIC token was included, but the MIC token
+         exchange is required, the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+   c) In the case that the chosen mechanism exchanges an odd number of
+      mechanism tokens (i.e., the initiator sends the last mechanism
+      token), the initiator does the following when generating the
+      negotiation message containing the last mechanism token: if the
+      negState was request-mic in the first reply from the target, a
+      mechlistMIC token MUST be included, otherwise the mechlistMIC
+      token is OPTIONAL.  (Note that the MIC token exchange is required
+      if a mechanism other than the initiator's first choice is chosen.)
+      In the case that the optimistic mechanism token is the only
+      mechanism token for the initiator's preferred mechanism, the
+      mechlistMIC token is OPTIONAL.  Whether or not the mechlistMIC
+      token is included, GSS_Init_sec_context() indicates
+      GSS_S_CONTINUE_NEEDED.  Initiators that wish to be compatible with
+      legacy Windows SPNEGO implementations as described in Appendix C
+      should not generate a mechlistMIC token when the MIC token
+      exchange is not required.  The acceptor then processes the last
+      mechanism token and does one of the following:
+
+      (I) If a mechlistMIC token was included and is correctly verified,
+         GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
+         negotiation message contains a mechlistMIC token and an
+         accept_complete state.  The initiator MUST then verify this
+         mechlistMIC token.
+
+      (II) If a mechlistMIC token was included but is incorrect, the
+         negotiation SHALL be terminated.  GSS_Accept_sec_context()
+         indicates GSS_S_DEFECTIVE_TOKEN.
+
+      (III) If no mechlistMIC token was included and the mechlistMIC
+         token exchange is not required, GSS_Accept_sec_context()
+         indicates GSS_S_COMPLETE.  The output negotiation message
+         contains an accept_complete state.
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 15]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+      (IV) In the case that the optimistic mechanism token is also the
+         last mechanism token (when the initiator's preferred mechanism
+         is accepted by the target) and the target sends a request-mic
+         state but the initiator did not send a mechlistMIC token, the
+         target then MUST include a mechlistMIC token in that first
+         reply.  GSS_Accept_sec_context() indicates
+         GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
+         mechlistMIC token and generate a mechlistMIC token to send back
+         to the target.  The target SHALL in turn verify the returned
+         mechlistMIC token and complete the negotiation.
+
+      (V) If no mechlistMIC token was included and the acceptor sent a
+         request-mic state in the first reply message (the exchange of
+         MIC tokens is required), the negotiation SHALL be terminated.
+         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 16]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+6.  Extensibility
+
+   Two mechanisms are provided for extensibility.  First, the ASN.1
+   structures in this specification MAY be expanded by IETF standards
+   action.  Implementations receiving unknown fields MUST ignore these
+   fields.
+
+   Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
+   mechanism variants) may be included in the set of preferred
+   mechanisms by an initiator.  The acceptor can choose to honor this
+   request by preferring mechanisms that have the included attributes.
+   Future work within the Kitten working group is expected to
+   standardize common attributes that SPNEGO mechanisms may wish to
+   support.  At this time it is sufficient to say that initiators MAY
+   include OIDs that do not correspond to mechanisms.  Such OIDs MAY
+   influence the acceptor's choice of mechanism.  As discussed in
+   Section 5, if there are mechanisms that if present in the initiator's
+   list of mechanisms might be preferred by the acceptor to the
+   initiator's preferred mechanism, the acceptor MUST demand the MIC
+   token exchange.  As the consequence, acceptors MUST demand the MIC
+   token exchange if they support negotiation of attributes not
+   available in the initiator's preferred mechanism regardless of
+   whether the initiator actually requested these attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 17]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+7.  Security Considerations
+
+   In order to produce the MIC token for the mechanism list, the
+   mechanism must provide integrity protection.  When the selected
+   mechanism does not support integrity protection, the negotiation is
+   vulnerable: an active attacker can force it to use a security
+   mechanism that is not mutually preferred but is acceptable to the
+   target.
+
+   This protocol provides the following guarantees when per-message
+   integrity services are available on the established mechanism context
+   and the mechanism list was altered by an adversary such that a
+   mechanism which is not mutually preferred could be selected:
+
+   a) If the last mechanism token is sent by the initiator, both peers
+      shall fail;
+   b) If the last mechanism token is sent by the acceptor, the acceptor
+      shall not complete and the initiator at worst shall complete with
+      its preferred mechanism being selected.
+
+   The negotiation may not be terminated if an alteration was made but
+   it had no material impact.
+
+   The protection of the negotiation depends on the strength of the
+   integrity protection.  In particular, the strength of SPNEGO is no
+   stronger than the integrity protection of the weakest mechanism
+   acceptable to GSS-API peers.
+
+   Note that where there exist multiple mechanisms with similar context
+   tokens, but different semantics, such that some or all of the
+   mechanisms' context tokens can be easily altered so that one
+   mechanism's context tokens may pass for another of the similar
+   mechanism's context tokens, then there may exist downgrade or similar
+   attacks.  For example, if a given family of mechanisms uses the same
+   context token syntax for two or more variants and depends on the OID
+   in the initial token's pseudo-ASN.1/DER wrapper, but does not provide
+   integrity protection for that OID, then there may exist an attack
+   against those mechanisms.  SPNEGO does not generally defeat such
+   attacks.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 18]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+8.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 19]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+9.  Acknowledgments
+
+   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
+   Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero and Bill
+   Sommerfeld for their comments and suggestions during development of
+   this document.
+
+   Luke Howard provided a prototype of this protocol in Heimdal and
+   resolved several issues in the initial draft.
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478] of which some of the text has been retained in this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 20]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+10.  References
+
+10.1  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
+              Rules (BER), Canonical Encoding Rules (CER) and 
+              Distinguished Encoding Rules (DER), ITU-T Recommendation 
+              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
+
+10.2  Informative References
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 21]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   Wyllys Ingersoll
+   Sun Microsystems
+   1775 Wiehle Avenue, 2nd Floor
+   Reston, VA  20190
+   US
+
+   Email: wyllys.ingersoll@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 22]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+Appendix A.  SPNEGO ASN.1 Module
+
+       SPNEGOASNOneSpec {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) mechanism(5) snego (2) modules(4) spec2(2)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       MechType ::= OBJECT IDENTIFIER
+           -- OID represents each security mechanism as suggested by
+           -- [RFC2743]
+
+       MechTypeList ::= SEQUENCE OF MechType
+
+       NegotiationToken ::= CHOICE {
+           negTokenInit    [0] NegTokenInit,
+           negTokenResp    [1] NegTokenResp
+       }
+
+       NegTokenInit ::= SEQUENCE {
+           mechTypes       [0] MechTypeList,
+           reqFlags        [1] ContextFlags  OPTIONAL,
+             -- inherited from RFC 2478 for backward compatibility,
+             -- RECOMMENDED to be left out
+           mechToken       [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+       NegTokenResp ::= SEQUENCE {
+           negState       [0] ENUMERATED {
+               accept-completed    (0),
+               accept-incomplete   (1),
+               reject              (2),
+               request-mic         (3)
+           }                                 OPTIONAL,
+             -- REQUIRED in the first reply from the target
+           supportedMech   [1] MechType      OPTIONAL,
+             -- present only in the first reply from the target
+           responseToken   [2] OCTET STRING  OPTIONAL,
+           mechListMIC     [3] OCTET STRING  OPTIONAL,
+           ...
+       }
+
+       ContextFlags ::= BIT STRING {
+           delegFlag       (0),
+           mutualFlag      (1),
+           replayFlag      (2),
+           sequenceFlag    (3),
+           anonFlag        (4),
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 23]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+           confFlag        (5),
+           integFlag       (6)
+       } (SIZE (32))
+
+       END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 24]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+Appendix B.  GSS-API Negotiation Support API
+
+   In order to provide to a GSS-API caller (either the initiator or the
+   target or both) the ability to choose among the set of supported
+   mechanisms a reduced set of mechanisms for negotiation, two
+   additional APIs are defined:
+
+   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
+      available on the local system to the caller for negotiation, for
+      which appropriate credentials are available.
+   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+      used on the local system by the caller for negotiation, for the
+      given credentials.
+
+B.1  GSS_Set_neg_mechs call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
+      -- credentials
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been set to mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to specify the set of security mechanisms that may be
+   negotiated with the credential identified by cred_handle.  This call
+   is intended for support of specialized callers who need to restrict
+   the set of negotiable security mechanisms from the set of all
+   security mechanisms available to the caller (based on available
+   credentials).  Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative preference.
+
+B.2  GSS_Get_neg_mechs call
+
+   Input:
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 25]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
+      -- credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been returned in mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of security mechanisms available
+   for negotiation with the credential identified by cred_handle.  This
+   call is intended for support of specialized callers who need to
+   reduce the set of negotiable security mechanisms from the set of
+   supported security mechanisms available to the caller (based on
+   available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system.  Since this call has
+   no input parameter, the returned set is not necessarily available for
+   all credentials.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 26]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+Appendix C.  Changes since RFC2478
+
+      SPNEGO implementations in Microsoft Windows 2000/Windows
+      XP/Windows Server 2003 have the following behavior: no mechlistMIC
+      is produced and mechlistMIC is not processed if one is provided;
+      if the initiator sends the last mechanism token, the acceptor will
+      send back a negotiation token with an accept_complete state and no
+      mechlistMIC token.  In addition, an incorrect OID
+      (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos
+      Version 5 mechanism.
+
+      The following changes have been made to be compatible with these
+      legacy implementations.
+
+      *  NegTokenTarg is changed to negTokenResp and it is the message
+         format for all subsequent negotiation tokens.
+      *  NegTokenInit is the message for the initial negotiation message
+         and that message only.
+      *  mechTypes in negTokenInit is not optional.
+      *  If the selected mechanism is also the most preferred mechanism
+         for both peers, it is safe to omit the MIC tokens.
+
+      If at least one of the two peers implements the updated pseudo
+      mechanism in this document, the negotiation is protected.
+
+      The following changes are to address problems in RFC 2478.
+
+      *  reqFlags is not protected therefore it should not impact the
+         negotiation.
+      *  DER encoding is required.
+      *  GSS_GetMIC() input is clarified.
+      *  Per-message integrity services are requested for the negotiated
+         mechanism.
+      *  Two MIC tokens are exchanged, one in each direction.
+
+   An implementation that conforms to this specification will not
+   inter-operate with a strict 2748 implementation.  Even if the new
+   implementation always sends a mechlistMIC token, it will still fail
+   to inter-operate.  If it is a server, it will fail because it
+   requests a mechlistMIC token using an option that older
+   implementations simply do not support.  Clients will tend to fail as
+   well.
+
+   As an alternative to the approach chosen in this specification, we
+   could have documented a correct behavior that is fully backward
+   compatible with RFC 2478 and included an appendix on how to
+   inter-operate with existing incorrect implementations of RFC 2478.
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 27]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+   As a practical matter, the SPNEGO implementers within the IETF have
+   valued interoperability with the Microsoft implementations.  We were
+   unable to choose to maintain reasonable security guarantees, maintain
+   interoperability with the Microsoft implementations and maintain
+   interoperability with correct implementations of RFC 2478.  The
+   working group was not aware of any RFC 2478 implementations deployed
+   on the Internet.  Even if there are such implementations, it is
+   unlikely that they will inter-operate because of a critical flaw in
+   the description of the encoding of the mechanism list in RFC 2478.
+
+   With the approach taken in this specification, security is ensured
+   between new implementations all the time while maintaining
+   interoperability with the implementations deployed within the IETF
+   community.  The working group believes that this justifies breaking
+   compatibility with a correct implementation of RFC 2478.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 28]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+Appendix D.  mechListMIC Computation Example
+
+   The following is an example to illustrate how the mechListMIC field
+   would be computed.
+
+   The initial part of the DER encoding of NegTokenInit is constructed
+   as follows (the "nn" are length encodings, possibly longer than one
+   octet):
+
+      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
+      nn -- length
+
+         -- contents octets of the SEQUENCE begin with
+         -- DER encoding of "[0] MechTypeList":
+         A0 -- identifier octet for constructed [0]
+         nn -- length
+
+             -- contents of the constructed [0] are DER encoding
+             -- of MechTypeList (which is a SEQUENCE):
+             30 -- identifier octet for constructed SEQUENCE
+             nn -- length
+
+                -- contents octets of the SEQUENCE begin with
+                -- DER encoding of OBJECT IDENTIFIER:
+                06 -- identifier octet for primitive OBJECT IDENTIFIER
+                09 -- length
+                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
+                                           -- {1 2 840 113554 1 2 2}
+
+   If a mechlistMIC needs to be generated (according to the rules in
+   Section 5), it is computed by using the DER encoding of the type
+   MechTypeList data from the initiator's NegTokenInit token as input to
+   the GSS_GetMIC() function.  In this case, the MIC would be computed
+   over the following octets:
+
+      DER encoding of MechTypeList:
+      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
+
+   Note that the identifier octet and length octet(s) for constructed
+   [0] (A0 nn) are not included in the MIC computation.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 29]
+
+Internet-Draft        GSS-API Negotiation Mechanism         January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires July 27, 2005                [Page 30]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt
new file mode 100644
index 00000000000..9aee4d125ff
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt
@@ -0,0 +1,785 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+        Extended Generic Security Service Mechanism Inquiry APIs
+             draft-ietf-kitten-extended-mech-inquiry-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document introduces new application programming interfaces
+   (APIs) to the Generic Security Services API (GSS-API) for extended
+   mechanism attribute inquiry.  These interfaces are primarily intended
+   for use in mechanism composition, but also to reduce instances of
+   hardcoding of mechanism identifiers in GSS applications.
+
+   These interfaces include: mechanism attributes and attribute sets, a
+   function for inquiring the attributes of a mechanism, a function for
+   indicating mechanisms that posses given attributes, and a function
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   for displaying mechanism attributes.
+
+
+Table of Contents
+
+   1.      Conventions used in this document  . . . . . . . . . . . .  3
+   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.      New GSS-API Interfaces . . . . . . . . . . . . . . . . . .  3
+   3.1.    Mechanism Attributes and Attribute Sets  . . . . . . . . .  3
+   3.2.    Determination of Attribute Sets of Composite Mechs . . . .  4
+   3.3.    List of Known Mechanism Attributes . . . . . . . . . . . .  4
+   3.4.    Mechanism Attribute Sets of Existing Mechs . . . . . . . .  6
+   3.5.    New GSS-API Function Interfaces  . . . . . . . . . . . . .  8
+   3.5.1.  GSS_Indicate_mechs_by_attr() . . . . . . . . . . . . . . .  8
+   3.5.2.  GSS_Inquire_attrs_for_mech() . . . . . . . . . . . . . . .  9
+   3.5.3.  GSS_Display_mech_attr()  . . . . . . . . . . . . . . . . . 10
+   3.5.4.  New Major Status Values  . . . . . . . . . . . . . . . . . 10
+   3.5.5.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
+   4.      Requirements for Mechanism Designers . . . . . . . . . . . 11
+   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 11
+   6.      Security considerations  . . . . . . . . . . . . . . . . . 11
+   7.      References . . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.1.    Normative  . . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.2.    Normative  . . . . . . . . . . . . . . . . . . . . . . . . 12
+           Author's Address . . . . . . . . . . . . . . . . . . . . . 13
+           Intellectual Property and Copyright Statements . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+1.  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 [RFC2119].
+
+
+2.  Introduction
+
+
+3.  New GSS-API Interfaces
+
+   GSS-API applications face, today, the problem of how to select from
+   multiple GSS-API mechanisms that may be available.  For example,
+   applications that support mechanism negotiation directly often have
+   to be careful not to use SPNEGO to avoid two-layer mechanism
+   negotiation, but since SPNEGO may be indicated by
+   GSS_Indicate_mechs() and since there's no way to know that a
+   mechanism negotiates mechanisms other than to hardcode the OIDs of
+   such mechanisms, such applications must hardcode the SPNEGO OID.
+   This problem is likely to be exacerbated by the introduction of
+   composite mechanisms.
+
+   To address this problem we introduce a new concept: that of mechanism
+   attributes.  By allowing applications to query the set of attributes
+   associated with individual mechanisms and to find out which
+   mechanisms support a given set of attributes we allow applications to
+   select mechanisms based on their attributes yet without having to
+   hardcode mechanism OIDs.
+
+   Section 3.1 describes the mechanism attributes concept.  Sections
+   3.5.1, 3.5.2 and 3.5.3 describe three new interfaces that deal in
+   mechanisms and attribute sets:
+
+   o  GSS_Indicate_mechs_by_attrs()
+   o  GSS_Inquire_attrs_for_mech()
+   o  GSS_Display_mech_attr()
+
+3.1.  Mechanism Attributes and Attribute Sets
+
+   An abstraction for the features provided by pseudo-mechanisms is
+   needed in order to facilitate the programmatic selection of
+   mechanisms as well as for the programmatic composition of mechanisms.
+
+   Two data types are needed: one for individual mechanism attributes
+   and one for mechanism attribute sets.  To simplify the mechanism
+   attributes interfaces we reuse the 'OID' and 'OID set' data types and
+   model individual mechanism attribute types as OIDs.
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   To this end we define an open namespace of mechanism attributes and
+   assign them arcs off of this OID:
+
+   <TBD> [1.3.6.1.5.5.12 appears to be available, registration w/ IANA
+   TBD]
+
+3.2.  Determination of Attribute Sets of Composite Mechs
+
+   Each mechanism, composite or otherwise, has a set of mechanism
+   attributes that it supports as specified.
+
+   The mechanism attribute set of a composite mechanism is to be
+   determined by the top-most stackable pseudo-mechanism of the
+   composite according to its own attribute set and that of the
+   remainder of the composite mechanism stack below it.
+
+   It may well be that some composite mechanisms' attribute sets consist
+   of the union of those of their every component, however this need not
+   be the case and MUST NOT be assumed.
+
+   Every stackable pseudo-mechanism's specification MUST specify the
+   rules for determining the mechanism attribute set of mechanisms
+   composed by it.
+
+3.3.  List of Known Mechanism Attributes
+
+   +-------------------------+--------+--------------------------------+
+   | Mech Attr Name          |    OID | Arc Name                       |
+   |                         |    Arc |                                |
+   +-------------------------+--------+--------------------------------+
+   | GSS_C_MA_MECH_CONCRETE  |    (1) | concrete-mech                  |
+   | GSS_C_MA_MECH_STACKABLE |    (2) | pseudo-mech                    |
+   | GSS_C_MA_MECH_COMPOSITE |    (3) | composite-mech                 |
+   | GSS_C_MA_MECH_NEGO      |    (4) | mech-negotiation-mech          |
+   | GSS_C_MA_MECH_GLUE      |    (5) | mech-glue                      |
+   | GSS_C_MA_NOT_MECH       |    (6) | not-mech                       |
+   | GSS_C_MA_DEPRECATED     |    (7) | mech-deprecated                |
+   | GSS_C_MA_NOT_DFLT_MECH  |    (8) | mech-not-default               |
+   | GSS_C_MA_ITOK_FRAMED    |    (9) | initial-is-framed              |
+   | GSS_C_MA_AUTH_INIT      |   (10) | auth-init-princ                |
+   | GSS_C_MA_AUTH_TARG      |   (11) | auth-targ-princ                |
+   | GSS_C_MA_AUTH_INIT_INIT |   (12) | auth-init-princ-initial        |
+   | GSS_C_MA_AUTH_TARG_INIT |   (13) | auth-targ-princ-initial        |
+   | GSS_C_MA_AUTH_INIT_ANON |   (14) | auth-init-princ-anon           |
+   | GSS_C_MA_AUTH_TARG_ANON |   (15) | auth-targ-princ-anon           |
+   | GSS_C_MA_DELEG_CRED     |   (16) | deleg-cred                     |
+   | GSS_C_MA_INTEG_PROT     |   (17) | integ-prot                     |
+   | GSS_C_MA_CONF_PROT      |   (18) | conf-prot                      |
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   | GSS_C_MA_MIC            |   (19) | mic                            |
+   | GSS_C_MA_WRAP           |   (20) | wap                            |
+   | GSS_C_MA_PROT_READY     |   (21) | prot-ready                     |
+   | GSS_C_MA_REPLAY_DET     |   (22) | replay-detection               |
+   | GSS_C_MA_OOS_DET        |   (23) | oos-detection                  |
+   | GSS_C_MA_CBINDINGS      |   (24) | channel-bindings               |
+   | GSS_C_MA_CBINDINGS_BIDI |   (25) | channel-bindings-bidirectional |
+   | GSS_C_MA_CBINDINGS_NEGO |   (26) | channel-bindings-negotiate     |
+   | GSS_C_MA_PFS            |   (27) | pfs                            |
+   | GSS_C_MA_COMPRESS       |   (28) | compress                       |
+   | GSS_C_MA_CTX_TRANS      |   (29) | context-transfer               |
+   | <reserved>              | (30..) |                                |
+   +-------------------------+--------+--------------------------------+
+
+                                  Table 1
+
+   +-------------------------+-----------------------------------------+
+   | Mech Attr Name          | Purpose                                 |
+   +-------------------------+-----------------------------------------+
+   | GSS_C_MA_MECH_CONCRETE  | Indicates that a mech is neither a      |
+   |                         | pseudo- mechanism nor a composite       |
+   |                         | mechanism.                              |
+   | GSS_C_MA_MECH_STACKABLE | Indicates that a mech is a              |
+   |                         | pseudo-mechanism.                       |
+   | GSS_C_MA_MECH_COMPOSITE | Indicates that a mech is a composite    |
+   |                         | mechanism.                              |
+   | GSS_C_MA_MECH_NEGO      | Indicates that a mech negotiates other  |
+   |                         | mechs (e.g., SPNEGO has this            |
+   |                         | attribute).                             |
+   | GSS_C_MA_MECH_GLUE      | Indicates that the OID is not for a     |
+   |                         | mechanism but for the GSS-API itself.   |
+   | GSS_C_MA_NOT_MECH       | Indicates that the OID is known, yet    |
+   |                         | also known not to be the OID of any     |
+   |                         | GSS-API mechanism (or the GSS-API       |
+   |                         | itself).                                |
+   | GSS_C_MA_DEPRECATED     | Indicates that a mech (or its OID) is   |
+   |                         | deprecated and MUST NOT be used as a    |
+   |                         | default mechanism.                      |
+   | GSS_C_MA_NOT_DFLT_MECH  | Indicates that a mech (or its OID) MUST |
+   |                         | NOT be used as a default mechanism.     |
+   | GSS_C_MA_ITOK_FRAMED    | Indicates that the given mechanism's    |
+   |                         | initial context tokens are properly     |
+   |                         | framed as per-section 3.1 of rfc2743.   |
+   | GSS_C_MA_AUTH_INIT      | Indicates support for authentication of |
+   |                         | initiator to acceptor.                  |
+   | GSS_C_MA_AUTH_TARG      | Indicates support for authentication of |
+   |                         | acceptor to initiator.                  |
+   | GSS_C_MA_AUTH_INIT_INIT | Indicates support for initial           |
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   |                         | authentication of initiator to          |
+   |                         | acceptor.                               |
+   | GSS_C_MA_AUTH_TARG_INIT | Indicates support for initial           |
+   |                         | authentication of acceptor to           |
+   |                         | initiator.                              |
+   | GSS_C_MA_AUTH_INIT_ANON | Indicates support for initiator         |
+   |                         | anonymity.                              |
+   | GSS_C_MA_AUTH_TARG_ANON | Indicates support for acceptor          |
+   |                         | anonymity.                              |
+   | GSS_C_MA_DELEG_CRED     | Indicates support for credential        |
+   |                         | delegation.                             |
+   | GSS_C_MA_INTEG_PROT     | Indicates support for per-message       |
+   |                         | integrity protection.                   |
+   | GSS_C_MA_CONF_PROT      | Indicates support for per-message       |
+   |                         | confidentiality protection.             |
+   | GSS_C_MA_MIC            | Indicates support for MIC tokens.       |
+   | GSS_C_MA_WRAP           | Indicates support for WRAP tokens.      |
+   | GSS_C_MA_PROT_READY     | Indicates support for per-message       |
+   |                         | protection prior to full context        |
+   |                         | establishment.                          |
+   | GSS_C_MA_REPLAY_DET     | Indicates support for replay detection. |
+   | GSS_C_MA_OOS_DET        | Indicates support for out-of-sequence   |
+   |                         | detection.                              |
+   | GSS_C_MA_CBINDINGS      | Indicates support for channel bindings. |
+   | GSS_C_MA_CBINDINGS_BIDI | Indicates that acceptors                |
+   |                         | unconditionally indicate to initiators  |
+   |                         | whether their channel bindings were     |
+   |                         | matched the acceptors', even when the   |
+   |                         | acceptor applications use               |
+   |                         | GSS_C_NO_CHANNEL_BINDINGS..             |
+   | GSS_C_MA_CBINDINGS_NEGO | Indicates that the mech acts as a       |
+   |                         | signal for application support for and  |
+   |                         | willingness to use channel bindings.    |
+   | GSS_C_MA_PFS            | Indicates support for Perfect Forward   |
+   |                         | Security.                               |
+   | GSS_C_MA_COMPRESS       | Indicates support for compression of    |
+   |                         | data inputs to GSS_Wrap().              |
+   | GSS_C_MA_CTX_TRANS      | Indicates support for security context  |
+   |                         | export/import.                          |
+   +-------------------------+-----------------------------------------+
+
+                                  Table 2
+
+3.4.  Mechanism Attribute Sets of Existing Mechs
+
+   The Kerberos V mechanism [RFC1964] [CFX] provides the following
+   mechanism attributes:
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   o  GSS_C_MA_MECH_CONCRETE
+   o  GSS_C_MA_ITOK_FRAMED
+   o  GSS_C_MA_AUTH_INIT
+   o  GSS_C_MA_AUTH_TARG
+   o  GSS_C_MA_DELEG_CRED
+   o  GSS_C_MA_INTEG_PROT
+   o  GSS_C_MA_CONF_PROT
+   o  GSS_C_MA_MIC
+   o  GSS_C_MA_WRAP
+   o  GSS_C_MA_PROT_READY
+   o  GSS_C_MA_REPLAY_DET
+   o  GSS_C_MA_OOS_DET
+   o  GSS_C_MA_CBINDINGS
+   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
+      specific exported context token formats)
+
+   The Kerberos V mechanism also has a deprecated OID which has the same
+   mechanism attributes as above, and GSS_C_MA_DEPRECATED.
+
+   [The mechanism attributes of the SPKM family of mechanisms will be
+   provided in a separate document as SPKM is current being reviewed for
+   possibly significant changes due to problems in its specifications.]
+
+   The LIPKEY mechanism offers the following attributes:
+
+   o  GSS_C_MA_MECH_CONCRETE (should be stackable, but does not compose)
+   o  GSS_C_MA_ITOK_FRAMED
+   o  GSS_C_MA_AUTH_INIT_INIT
+   o  GSS_C_MA_AUTH_TARG (from SPKM-3)
+   o  GSS_C_MA_AUTH_TARG_ANON (from SPKM-3)
+   o  GSS_C_MA_INTEG_PROT
+   o  GSS_C_MA_CONF_PROT
+   o  GSS_C_MA_REPLAY_DET
+   o  GSS_C_MA_OOS_DET
+   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
+      specific exported context token formats)
+
+      (LIPKEY should also provide GSS_C_MA_CBINDINGS, but SPKM-3
+      requires clarifications on this point.)
+
+   The SPNEGO mechanism [SPNEGO] provides the following attributes:
+   o  GSS_C_MA_MECH_NEGO
+   o  GSS_C_MA_ITOK_FRAMED
+
+   The attributes of mechanisms negotiated by SPNEGO are not modified by
+   the use of SPNEGO.
+
+   All other mechanisms' attributes will be described elsewhere.
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+3.5.  New GSS-API Function Interfaces
+
+   Several new interfaces are given by which, for example, GSS-API
+   applications may determine what features are provided by a given
+   mechanism, what mechanisms provide what features and what
+   compositions are legal.
+
+   These new interfaces are all OPTIONAL.
+
+   In order to preserve backwards compatibility with applications that
+   do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
+   support for any stackable pseduo-mechanisms.  GSS_Indicate_mechs()
+   MAY indicate support for some, all or none of the available composite
+   mechanisms; which composite mechanisms, if any, are indicated through
+   GSS_Indicate_mechs() SHOULD be configurable.  GSS_Acquire_cred() and
+   GSS_Add_cred() MUST NOT create credentials for composite mechanisms
+   not explicitly requested or, if no desired mechanism or mechanisms
+   are given, for composite mechanisms not indicated by
+   GSS_Indicate_mechs().
+
+   Applications SHOULD use GSS_Indicate_mechs_by_attr() instead of
+   GSS_Indicate_mechs() wherever possible.
+
+   Applications can use GSS_Indicate_mechs_by_attr() to determine what,
+   if any, mechanisms provide a given set of features.
+
+   GSS_Indicate_mechs_by_attr() can also be used to indicate (as in
+   GSS_Indicate_mechs()) the set of available mechanisms of each type
+   (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
+   mechanism and composite mechanisms).
+
+   Applications may use GSS_Inquire_attrs_for_mech() to test whether a
+   given composite mechanism is available and the set of features that
+   it offers.
+
+3.5.1.  GSS_Indicate_mechs_by_attr()
+
+   Inputs:
+   o  desired_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
+      OIDs that the mechanisms indicated in the mechs output parameter
+      MUST offer.
+   o  except_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
+      OIDs that the mechanisms indicated in the mechs output parameter
+      MUST NOT offer.
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+
+
+
+Williams                 Expires April 19, 2006                 [Page 8]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   o  mechs SET OF OBJECT IDENTIFIER -- set of mechanisms that support
+      -- the desired_mech_attrs but not the except_mech_attrs.
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
+      be the empty set (GSS_C_NO_OID_SET).
+   o  GSS_BAD_MECH_ATTR indicates that at least one mechanism attribute
+      OID in desired_mech_attrs or except_mech_attrs is unknown to the
+      implementation.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   GSS_Indicate_mechs_by_mech_attrs() returns the set of mechanism OIDs
+   that offer at least the desired_mech_attrs but none of the
+   except_mech_attrs.
+
+   When desired_mech_attrs and except_mech_attrs are the empty set this
+   function acts as a version of GSS_indicate_mechs() that outputs the
+   set of all supported mechanisms of all types.  By setting the
+   desired_mechs input parameter to a set of a single GSS_C_MA_MECH*
+   feature applications can obtain the list of all supported mechanisms
+   of a given type (concrete, stackable, etc...).
+
+3.5.2.  GSS_Inquire_attrs_for_mech()
+
+   Inputs:
+   o  mech OBJECT IDENTIFIER -- mechanism OID
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs OIDs
+      (GSS_C_MA_*)
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success; the output mech_attrs parameter
+      MAY be the empty set (GSS_C_NO_OID_SET).
+   o  GSS_S_BAD_MECH indicates that the mechanism named by the mech
+      parameter does not exist or that mech is GSS_C_NO_OID and no
+      default mechanism could be determined.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   GSS_Inquire_mech_attrs_for_mech() indicates the set of mechanism
+   attributes supported by a given mechanism.
+
+   Because the mechanism attribute sets of composite mechanisms need not
+   be the union of their components', when called to obtain the feature
+
+
+
+Williams                 Expires April 19, 2006                 [Page 9]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   set of a composite mechanism GSS_Inquire_mech_attrs_for_mech()
+   obtains it by querying the mechanism at the top of the stack.  See
+   Section 3.1.
+
+3.5.3.  GSS_Display_mech_attr()
+
+   Inputs:
+   o  mech_attr OBJECT IDENTIFIER -- mechanism attribute OID
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  name OCTET STRING, -- name of mechanism attribute (e.g.,
+      GSS_C_MA_*)
+   o  short_desc OCTET STRING, -- a short description of the mechanism
+      attribute
+   o  long_desc OCTET STRING -- a longer description of the mechanism
+      attribute
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success.
+   o  GSS_S_BAD_MECH_ATTR indicates that the mechanism attribute
+      referenced by the mech_attr parameter is unknown to the
+      implementation.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   This function can be used to obtain human-readable descriptions of
+   GSS-API mechanism attributes.
+
+3.5.4.  New Major Status Values
+
+   A single new major status code is added for GSS_Display_mech_attr():
+   o  GSS_S_BAD_MECH_ATTR
+   roughly corresponding to GSS_S_BAD_MECH, but applicable to mechanism
+   attribute OIDs, rather than to mechanism OIDs.
+
+   For the C-bindings GSS_S_BAD_MECH_ATTR shall have a routine error
+   number of 19 (this is shifted to the left by
+   GSS_C_ROUTINE_ERROR_OFFSET).
+
+3.5.5.  C-Bindings
+
+
+      #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
+
+      OM_uint32 gss_inquire_mechs_for_mech_attrs(
+         OM_uint32         *minor_status,
+
+
+
+Williams                 Expires April 19, 2006                [Page 10]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+         const gss_OID_set  desired_mech_attrs,
+         gss_OID_set       *mechs);
+
+      OM_uint32 gss_inquire_mech_attrs_for_mech(
+         OM_uint32         *minor_status,
+         const gss_OID      mech,
+         gss_OID_set       *mech_attrs);
+
+      OM_uint32 gss_display_mech_attr(
+         OM_uint32         *minor_status,
+         const gss_OID      mech_attr,
+         gss_buffer_t       name,
+         gss_buffer_t       short_desc,
+         gss_buffer_t       long_desc);
+
+
+   Figure 1
+
+
+4.  Requirements for Mechanism Designers
+
+   Stackable pseudo-mechanisms specifications MUST:
+   o  list the set of GSS-API mechanism attributes associated with them
+   o  list their initial mechanism composition rules
+   o  specify a mechanism for updating their mechanism composition rules
+
+   All other mechanism specifications MUST:
+   o  list the set of GSS-API mechanism attributes associated with them
+
+
+5.  IANA Considerations
+
+   The namsepace of programming language symbols with names beginning
+   with GSS_C_MA_* is reserved for allocation by the IANA.
+
+   Allocation of arcs in the namespace of OIDs relative to the base
+   mechanism attribute OID specified in Section 3.1 is reserved to the
+   IANA.
+
+
+6.  Security considerations
+
+   ...
+
+
+7.  References
+
+7.1.  Normative
+
+
+
+Williams                 Expires April 19, 2006                [Page 11]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+7.2.  Normative
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 12]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 13]
+
+Internet-Draft          Extended GSS Mech Inquiry           October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 14]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt
new file mode 100644
index 00000000000..66d7f021884
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt
@@ -0,0 +1,726 @@
+Network Working Group                                         S. Hartman
+Internet-Draft                                                       MIT
+Expires: May 31, 2005                                  November 30, 2004
+
+
+                 Desired Enhancements to GSSAPI Naming
+                  draft-ietf-kitten-gss-naming-00.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on May 31, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The Generic Security Services API (GSS-API) provides a naming
+   architecture that supports  name-based authorization.  GSS-API
+   authenticates two named parties to each other.  Names can be stored
+   on access control lists to make authorization decisions.  Advances in
+   security mechanisms and the way implementers wish to use GSS-API
+   require this model to be extended.  Some mechanisms such as
+   public-key mechanisms do not have a single name to be used across all
+   environments.  Other mechanisms such as Kerberos allow names to
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 1]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+   change as people move around organizations.  This document proposes
+   expanding the definition of GSS-API names to deal with these
+   situations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 2]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+1.  Introduction
+
+   The Generic Security Services API [1] authenticates two named parties
+   to each other.  GSS names can be imported in a variety of formats
+   through the gss_import_name call.  Several mechanism-independent name
+   formats such as GSS_C_NT_HOSTBASED_SERVICE for services running on an
+   Internet host and GSS_C_NT_USER_NAME for the names of users.  Other
+   mechanism-specific name types are also provided.  By the time a name
+   is used in acquiring a mechanism-specific credential or establishing
+   a security context, it has been transformed into one of these
+   mechanism-specific name types.  In addition, the GSS-API provides a
+   function called gss_export_name that will flatten a GSS-API name into
+   a binary blob suitable for comparisons.  This binary blob can be
+   stored on ACLs and then authorization decisions can be made simply by
+   comparing the name exported from a newly accepted context to the name
+   on the ACL.
+
+   Inherent in this model is the idea that  mechanism names need to be
+   able to be represented in a single canonical form.  Anyone importing
+   that name needs to be able to retrieve the canonical form of that
+   name.
+
+   Several security mechanisms have been proposed for which this naming
+   architecture is too restrictive.  In some cases it is not always
+   possible to canonicalize any name that is imported.  In other cases
+   there is no single canonical name.
+
+   Storing names on ACLs can be problematic because names tend to change
+   over time .  If the name contains organizational information such as
+   a domain part or an indication of what department someone works for,
+   this changes as the person moves around the organization.  Even if no
+   organizational information is included in the name, the name will
+   change as people change their names.  Updating ACLs to reflect name
+   changes is difficult.
+
+   Also, as GSS-API is used in more complex environments, there is a
+   desire to use attribute certificates [5], Kerberos authorization data
+   [2], or other non-name-based authorization models.  GSS-API needs to
+   be enhanced in order to support these uses in a mechanism-independent
+   manner.
+
+   This draft discusses two different cases where the current GSS-API
+   naming seems inadequate.  Two proposals that have been discussed
+   within the IETF Kitten community are discussed.  Finally, the
+   problems that need to be resolved to adopt either of these proposals
+   are discussed.
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 3]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+2.  Kerberos Naming
+
+   The Kerberos Referrals draft [3] proposes a new type of Kerberos name
+   called an enterprise name.  The intent is that the enterprise name is
+   an alias that the user knows for themselves and can use to login.
+   The Kerberos KDC translates this name into a normal Kerberos
+   principal and gives the user tickets for this principal.  This normal
+   principal is used for authorization.  The intent is that the
+   enterprise name tracks the user as they move throughout the
+   organization, even if they move to parts of the organization that
+   have different naming policies.  The name they type at login remains
+   constant, but the Kerberos principal used to authenticate them to
+   services changes.
+
+   Performing a mapping from enterprise  name to principal name is not
+   generally possible for unauthenticated services.  So in order to
+   canonicalize an enterprise name to get a principal, a service must
+   have credentials.  However it may not be desirable to allow services
+   to map enterprise names to principal names in the general case.
+   Also, Kerberos does not (and does not plan to) provide a mechanism
+   for mapping enterprise names to principals besides authentication as
+   the enterprise name.  Thus, any such mapping would be
+   vendor-specific.  With this feature in Kerberos, it is not possible
+   to implement gss_canonicalize_name for enterprise name types.
+
+   Another issue arises with enterprise names.  IN some cases it would
+   be desirable to put   the enterprise name on the ACL instead of a
+   principal name.  Thus, it would be desirable to include the
+   enterprise name in the name exported by gss_export_name.
+   Unfortunately, if this were done, the exported name would change
+   whenever the mapping changed, invalidating any ACL entries based off
+   the old exported name and defeating the purpose  of including the
+   enterprise name.  In some cases it would be desirable to have the
+   exported name be based on the enterprise name and in others based on
+   the principal name, but this is not permitted by the current GSS-API.
+
+   Another development also complicates GSS-API naming for Kerberos.
+   Several vendors have been looking at mechanisms to include group
+   membership information in Kerberos authorization data.  It is
+   desirable to put these group names on ACLs.  Again, GSS-API currently
+   has no mechanism to use this information.
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 4]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+3.  X.509 Names
+
+   X.509 names are at least as complex as Kerberos names.  It seems  the
+   subject name might be the appropriate name to use as the name to be
+   exported in a GSS-API mechanism.  However RFC 3280 [4] does not even
+   require the subject name to be a non-empty sequence.  Instead there
+   are cases where the subjectAltName extension is the only thing to
+   identify the subject of the certificate.  As in the case of Kerberos
+   group memberships, there may be many subjectAltName extensions
+   available in a certificate.  Different applications will care about
+   different extensions.  Thus there is no single value that can be
+   defined as the exported GSS-API name that will be useful in all
+   environments.
+
+   A profile of a particular X.509  GSS-API mechanism could require a
+   specific name be used.  However this would limit that mechanism to
+   require a particular type of certificate.  There is interest in being
+   able to use arbitrary X.509 certificates with GSS-API for some
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 5]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+4.  Composite Names
+
+   One proposal to solve these problems is to extend the concept of a
+   GSS-API name to include a set of name attributes.  Each attribute
+   would be an octet-string labeled by an OID.  Examples of attributes
+   would include Kerberos enterprise names, group memberships in an
+   authorization infrastructure, Kerberos authorization data attributes
+   and subjectAltName attributes in a certificate.  Several new
+   operations would be needed:
+   1.  Add attribute to name
+   2.  Query attributes of name
+   3.  Query values of an attribute
+   4.  Delete an attribute from a name
+
+4.1  Usage of Name Attributes
+
+   Since attributes are part of GSS-API names, the acceptor can retrieve
+   the attributes of the initiator's name from the context.  These
+   attributes can then be used for authorization.
+
+   Most name attributes will probably not come from explicit operations
+   to add attributes to a name.  Instead, name attributes will probably
+   come from mechanism specific credentials.  Mechanism specific naming
+   and group membership can be  mapped into name attributes by the
+   mechanism implementation.  The specific form of this mapping will
+   generally require protocol specification for each mechanism.
+
+   The value of many  name attributes may be suitable for use in binary
+   comparison.  This should enable applications to use these name
+   attributes on ACLs the same way exported names are now used on ACLs.
+   For example if a particular Subjectaltname extension contains the
+   appropriate  identity for an application, then  the name attribute
+   for this Subjectaltname can be placed on the ACL.  This is only true
+   if the name attribute is stored in some canonical form.
+
+4.2  Open issues
+
+   This section describes parts of the proposal to add attributes to
+   names that will need to be explored before the proposal can become a
+   protocol specification.
+
+   Are mechanisms expected to be able to carry arbitrary name attributes
+   as part of a context establishment?   At first it seems like this
+   would be desirable.  However the purpose of GSS-API is to establish
+   an authenticated context between two peers.  In particular, a context
+   authenticates two named entities to each other.  The names of these
+   entities and attributes associated with these names will be used for
+   authorization decisions.  If an initiator or acceptor is allowed to
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 6]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+   assert name attributes and the authenticity of these assertions is
+   not validated by the mechanisms, then security problems will result.
+   On the other hand, requiring that name attributes be mechanism
+   specific and only be carried by mechanisms that understand the name
+   attributes and can validate them compromises GSS-API's place as a
+   generic API.  Application authors would be forced to understand
+   mechanism-specific attributes to make authorization decisions.  In
+   addition if mechanisms are not required to transport arbitrary
+   attributes, then application authors will need to deal with different
+   implementations of the same mechanism that support different sets of
+   name attributes.  One possible solution is to carry a source along
+   with each name attribute; this source could indicate whether the
+   attribute comes from a mechanism data structure or from the other
+   party in the authentication.
+
+   Another related question is how will name attributes be mapped into
+   their mechanism-specific forms.  For example it would be desirable to
+   map many  Kerberos authorization data elements into name attributes.
+   In the case of the Microsoft PAC, it would be desirable for some
+   applications to get the entire PAC.  However in many cases, the
+   specific lists of security IDs contained in the PAC would be more
+   directly useful to an application.  So there may not be a good
+   one-to-one mapping between the mechanism-specific elements and the
+   representation desirable at the GSS-API layer.
+
+   Specific name matching rules need to be developed.  How do names with
+   attributes compare?  What is the effect of a name attribute on a
+   target name in gss_accept_sec_context?
+
+4.3  Handling gss_export_name
+
+   For many mechanisms, there will be  an obvious choice to use for the
+   name exported by gss_export_name.  For example in the case of
+   Kerberos, the principal name can continue to be used as the exported
+   name.  This will allow applications depending on existing GSS-API
+   name-based authorization to continue to work.  However it is probably
+   desirable to allow GSS-API mechanisms for which gss_export_name
+   cannot meaningfully be defined.  The behavior of gss_export_name in
+   such cases should probably be to return some error.  Such mechanisms
+   may not work with existing applications and cannot conform to the
+   current version of the GSS-API.
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 7]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+5.  Credential Extensions
+
+   An alternative to the name attributes proposal  is to extend GSS-API
+   credentials  with extensions labeled by OIDs.  Interfaces would be
+   needed to manipulate these credential extensions and to retrieve the
+   credential extensions for credentials used to establish a context.
+   Even if name attributes are used, credential extensions may be useful
+   for other unrelated purposes.
+
+   It is possible to solve problems discussed in this document using
+   some credential extension mechanism.  Doing so will have many of the
+   same open issues as discussed in the  composite names  proposal.  The
+   main advantage of a credential extensions proposal is that  it avoids
+   specifying how name attributes interact with name comparison or
+   target names.
+
+   The primary advantage of the name attributes proposal over credential
+   extensions is that name attributes seem to fit better into the
+   GSS-API authorization model.  Names are already available at all
+   points when authorization decisions are made.  In addition, for many
+   mechanisms the sort of information carried as name attributes will
+   also be carried as part of the name in the mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 8]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+6.  Mechanisms for Export Name
+
+   Another proposal is to define some GSS-API mechanisms whose only
+   purpose is to have an exportable name form that is useful.  For
+   example, you might be able to export a name as a local machine user
+   ID with such a mechanism.
+
+   This solution works well especially for name information that can be
+   looked up in a directory.  It was unclear from the p      discussion
+   whether this solution would allow mechanism-specific name information
+   to be extracted from a context.  If so, then this solution would meet
+   many of the goals of this document.
+
+   One advantage of this solution is that it requires few if any changes
+   to GSS-API semantics.  It is not as flexible as other solutions.
+   Also, it is not clear how to handle mechanisms that do not have a
+   well defined name to export with this solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                  [Page 9]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+7.  Deferring Credential Binding
+
+   Currently GSS-API credentials represent a single mechanism name.
+   While working on other issues discussion focused around choosing the
+   correct credential for a particular  target.  There are several
+   situations where an implementation can do a better job of choosing a
+   default source name to use given the name of the target to connect
+   to.  Currently, GSS-API does not provide a mechanism to do this.
+   Adding such a mechanism would be desirable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                 [Page 10]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+8.  Security Considerations
+
+   GSS-API sets up a security context between two named parties.  The
+   GSS-API names are security assertions that are authenticated by the
+   context establishment process.  As such  the GSS naming architecture
+   is critical to the security of GSS-API.
+
+   Currently GSS-API uses a simplistic naming model for authorization.
+   Names can be compared  against a set of names on an access control
+   list.  This architecture is relatively simple and its security
+   properties are well understood.  However it does not provide the
+   flexibility and feature set for future deployments of GSS-API.
+
+   This proposal will significantly increase the complexity of the GSS
+   naming architecture.  As this proposal is fleshed out, we need to
+   consider ways of managing security exposures created by this
+   increased complexity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                 [Page 11]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+9.  Acknowledgements
+
+   John Brezak, Paul Leach and Nicolas Williams all participated in
+   discussions that lead to a desire to enhance GSS naming.  Martin Rex
+   provided descriptions of the current naming architecture and pointed
+   out many ways in which proposed enhancements would create
+   interoperability problems or increase complexity.  Martin also
+   provided excellent information on what aspects of GSS naming have
+   tended to be implemented badly or have not met the needs of some
+   customers.
+
+   Nicolas Williams helped describe the possible approaches for
+   enhancing naming.
+
+10  Informative References
+
+   [1]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
+        progress), June 2004.
+
+   [3]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
+        KDC Referrals to locate Kerberos realms",
+        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
+        2004.
+
+   [4]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and Certificate Revocation
+        List (CRL) Profile", rfc 3280, April 2002.
+
+   [5]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
+        Profile for Authorization.", rfc 3281, April 2002.
+
+
+Author's Address
+
+   Sam Hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+Hartman                   Expires May 31, 2005                 [Page 12]
+
+Internet-Draft                 GSS Names                   November 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                   Expires May 31, 2005                 [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt
new file mode 100644
index 00000000000..51771e593b1
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt
@@ -0,0 +1,727 @@
+Network Working Group                                         S. Hartman
+Internet-Draft                                                       MIT
+Expires: August 21, 2005                               February 20, 2005
+
+
+                 Desired Enhancements to GSSAPI Naming
+                  draft-ietf-kitten-gss-naming-01.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 21, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Generic Security Services API (GSS-API) provides a naming
+   architecture that supports  name-based authorization.  GSS-API
+   authenticates two named parties to each other.  Names can be stored
+   on access control lists to make authorization decisions.  Advances in
+   security mechanisms and the way implementers wish to use GSS-API
+   require this model to be extended.  As people move within an
+   organization or change their names, the name authenticated by GSS-API
+   may change.  Using some sort of constant identifier would make ACLs
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 1]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+   more stable.  Some mechanisms such as public-key mechanisms do not
+   have a single name to be used across all environments.  Other
+   mechanisms such as Kerberos include may include group membership or
+   role information as part of authentication.  This document motivates
+   extensions to GSS-API naming and describes the extensions under
+   discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 2]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+1.  Introduction
+
+   The Generic Security Services API [2] authenticates two named parties
+   to each other.  GSS names can be imported in a variety of formats
+   through the gss_import_name call.  Several mechanism-independent name
+   formats are provided including GSS_C_NT_HOSTBASED_SERVICE for
+   services running on an Internet host and GSS_C_NT_USER_NAME for the
+   names of users.  Other mechanism-specific name types are also
+   provided.  By the time a name is used in acquiring a
+   mechanism-specific credential or establishing a security context, it
+   has been transformed into one of these mechanism-specific name types.
+   In addition, the GSS-API provides a function called gss_export_name
+   that will flatten a GSS-API name into a binary blob suitable for
+   comparisons.  This binary blob can be stored on ACLs and then
+   authorization decisions can be made simply by comparing the name
+   exported from a newly accepted context to the name on the ACL.
+
+   Storing names on ACLs can be problematic because names tend to change
+   over time .  If the name contains organizational information such as
+   a domain part or an indication of what department someone works for,
+   this changes as the person moves around the organization.  Even if no
+   organizational information is included in the name, the name will
+   change as people change their names.  Updating ACLs to reflect name
+   changes is difficult.
+
+   Inherent in the GSS naming  model is the idea that  mechanism names
+   need to be able to be represented in a single canonical form.  Anyone
+   importing that name needs to be able to retrieve the canonical form
+   of that name.
+
+   Several security mechanisms have been proposed for which this naming
+   architecture is too restrictive.  In some cases it is not always
+   possible to canonicalize any name that is imported.  In other cases
+   there is no single canonical name.
+
+   Also, as GSS-API is used in more complex environments, there is a
+   desire to use attribute certificates [6], Kerberos authorization data
+   [3], or other non-name-based authorization models.  GSS-API needs to
+   be enhanced in order to support these uses in a mechanism-independent
+   manner.
+
+   This document discusses the particular naming problems with two
+   important classes of GSS-API mechanisms.  It also discusses the set
+   of proposed solutions and open issues with these solutions.  This
+   draft limits discussion to these solutions and provides a description
+   of the problem against which the solutions can be judged.
+
+
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 3]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+2.  Kerberos Naming
+
+   The Kerberos mechanism demonstrates both the naming stability problem
+   and the authorization extension problem.
+
+   The Kerberos Referrals draft [4] proposes a new type of Kerberos name
+   called an enterprise name.  The intent is that the enterprise name is
+   an alias that the user knows for themselves and can use to login.
+   The Kerberos KDC translates this name into a normal Kerberos
+   principal and gives the user tickets for this principal.  This normal
+   principal is used for authorization.  The intent is that the
+   enterprise name tracks the user as they move throughout the
+   organization, even if they move to parts of the organization that
+   have different naming policies.  The name they type at login remains
+   constant, but the Kerberos principal used to authenticate them to
+   services changes.
+
+   Performing a mapping from enterprise  name to principal name is not
+   generally possible for unauthenticated services.  Even authenticated
+   services may not be authorized to perform this mapping except for
+   their own name.  Also, Kerberos does not (and does not plan to)
+   provide a mechanism for mapping enterprise names to principals
+   besides authentication as the enterprise name.  Thus, any such
+   mapping would be vendor-specific.  With this feature in Kerberos, it
+   is not possible to implement gss_canonicalize_name for enterprise
+   name types.
+
+   Another issue arises with enterprise names.  IN some cases it would
+   be desirable to put   the enterprise name on the ACL instead of a
+   principal name for greater ACL stability.  At first glance this could
+   be accomplished by including the enterprise name in the name exported
+   by gss_export_name.  Unfortunately, if this were done, the exported
+   name would change whenever the mapping changed, invalidating any ACL
+   entries based off the old exported name and defeating the purpose  of
+   including the enterprise name in the exported name.  In some cases it
+   would be desirable to have the exported name be based on the
+   enterprise name and in others based on the principal name, but this
+   is not permitted by the current GSS-API.
+
+   Another development also complicates GSS-API naming for Kerberos.
+   Several vendors have been looking at mechanisms to include group
+   membership information in Kerberos authorization data.  It is
+   desirable to put these group names on ACLs.  Again, GSS-API currently
+   has no mechanism to use this information.
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 4]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+3.  X.509 Names
+
+   X.509 names are more complicated than Kerberos names.  In the
+   Kerberos case there is a single principal carried in all Kerberos
+   messages.  X.509 certificates have multiple options.  It seems  the
+   subject name might be the appropriate name to use as the name to be
+   exported in a GSS-API mechanism.  However RFC 3280 [5] does not even
+   require the subject name to be a non-empty sequence.  Instead there
+   are cases where the subjectAltName extension is the only thing to
+   identify the subject of the certificate.  As in the case of Kerberos
+   group memberships, there may be many subjectAltName extensions
+   available in a certificate.  Different applications will care about
+   different extensions.  Thus there is no single value that can be
+   defined as the exported GSS-API name that will be useful in all
+   environments.
+
+   A profile of a particular X.509  GSS-API mechanism could require a
+   specific name be used.  However this would limit that mechanism to
+   require a particular type of certificate.  There is interest in being
+   able to use arbitrary X.509 certificates with GSS-API for some
+   applications.
+
+   Experience so far has not lead to sufficient interoperability with
+   GSS-API X.509 mechanisms.  Even if the subject name is used, there is
+   ambiguity in how to handle sorting of name components.  Martin Rex
+   said that he was aware of several SPKM [1] implementations but no two
+   were fully interoperable on names.
+
+   Also, as discussed in the introduction, it is desirable to support
+   X.509 attribute certificates.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 5]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+4.  Composite Names
+
+   One proposal to solve these problems is to extend the concept of a
+   GSS-API name to include a set of name attributes.  Each attribute
+   would be an octet-string labeled by an OID.  Examples of attributes
+   would include Kerberos enterprise names, group memberships in an
+   authorization infrastructure, Kerberos authorization data attributes
+   and subjectAltName attributes in a certificate.  Several new
+   operations would be needed:
+   1.  Add an  attribute to name.
+   2.  Query attributes of name.
+   3.  Query values of an attribute.
+   4.  Delete an attribute from a name.
+   5.  Export a complete composite name and all its attributes for
+       transport between processes.
+
+   Note that an exported composite name would not be suitable for binary
+   comparison.  Avoiding confusion between this operation and the
+   existing gss_export_name operation will require careful work.
+
+4.1  Usage of Name Attributes
+
+   Since attributes are part of GSS-API names, the acceptor can retrieve
+   the attributes of the initiator's and acceptor's name from the
+   context.  These attributes can then be used for authorization.
+
+   Most name attributes will probably not come from explicit operations
+   to add attributes to a name.  Instead, name attributes will probably
+   come from mechanism specific credentials.  Components of these
+   mechanism specific credentials may come from platform or
+   environment-specific names.  Mechanism specific naming and group
+   membership can be  mapped into name attributes by the mechanism
+   implementation.  The specific form of this mapping will generally
+   require protocol specification for each mechanism.
+
+   The value of many  name attributes may be suitable for use in binary
+   comparison.  This should enable applications to use these name
+   attributes on ACLs the same way exported names are now used on ACLs.
+   For example if a particular Subjectaltname extension contains the
+   appropriate  identity for an application, then  the name attribute
+   for this Subjectaltname can be placed on the ACL.  This is only true
+   if the name attribute is stored in some canonical form.
+
+4.2  Open issues
+
+   This section describes parts of the proposal to add attributes to
+   names that will need to be explored before the proposal can become a
+   protocol specification.
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 6]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+   Are mechanisms expected to be able to carry arbitrary name attributes
+   as part of a context establishment?   At first it seems like this
+   would be desirable.  However the purpose of GSS-API is to establish
+   an authenticated context between two peers.  In particular, a context
+   authenticates two named entities to each other.  The names of these
+   entities and attributes associated with these names will be used for
+   authorization decisions.  If an initiator or acceptor is allowed to
+   assert name attributes and the authenticity of these assertions is
+   not validated by the mechanisms, then security problems will result.
+   On the other hand, requiring that name attributes be mechanism
+   specific and only be carried by mechanisms that understand the name
+   attributes and can validate them compromises GSS-API's place as a
+   generic API.  Application authors would be forced to understand
+   mechanism-specific attributes to make authorization decisions.  In
+   addition if mechanisms are not required to transport arbitrary
+   attributes, then application authors will need to deal with different
+   implementations of the same mechanism that support different sets of
+   name attributes.  One possible solution is to carry a source along
+   with each name attribute; this source could indicate whether the
+   attribute comes from a mechanism data structure or from the other
+   party in the authentication.
+
+   Another related question is how will name attributes be mapped into
+   their mechanism-specific forms.  For example it would be desirable to
+   map many  Kerberos authorization data elements into name attributes.
+   In the case of the Microsoft PAC, it would be desirable for some
+   applications to get the entire PAC.  However in many cases, the
+   specific lists of security IDs contained in the PAC would be more
+   directly useful to an application.  So there may not be a good
+   one-to-one mapping between the mechanism-specific elements and the
+   representation desirable at the GSS-API layer.
+
+   Specific name matching rules need to be developed.  How do names with
+   attributes compare?  What is the effect of a name attribute on a
+   target name in gss_accept_sec_context?
+
+4.3  Handling gss_export_name
+
+   For many mechanisms, there will be  an obvious choice to use for the
+   name exported by gss_export_name.  For example in the case of
+   Kerberos, the principal name can continue to be used as the exported
+   name.  This will allow applications depending on existing GSS-API
+   name-based authorization to continue to work.  However it is probably
+   desirable to allow GSS-API mechanisms for which gss_export_name
+   cannot meaningfully be defined.  The behavior of gss_export_name in
+   such cases should probably be to return some error.  Such mechanisms
+   may not work with existing applications and cannot conform to the
+   current version of the GSS-API.
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 7]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+5.  Credential Extensions
+
+   An alternative to the name attributes proposal  is to extend GSS-API
+   credentials  with extensions labeled by OIDs.  Interfaces would be
+   needed to manipulate these credential extensions and to retrieve the
+   credential extensions for credentials used to establish a context.
+   Even if name attributes are used, credential extensions may be useful
+   for other unrelated purposes.
+
+   It is possible to solve problems discussed in this document using
+   some credential extension mechanism.  Doing so will have many of the
+   same open issues as discussed in the  composite names  proposal.  The
+   main advantage of a credential extensions proposal is that  it avoids
+   specifying how name attributes interact with name comparison or
+   target names.
+
+   The primary advantage of the name attributes proposal over credential
+   extensions is that name attributes seem to fit better into the
+   GSS-API authorization model.  Names are already available at all
+   points when authorization decisions are made.  In addition, for many
+   mechanisms the sort of information carried as name attributes will
+   also be carried as part of the name in the mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 8]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+6.  Mechanisms for Export Name
+
+   Another proposal is to define some GSS-API mechanisms whose only
+   purpose is to have an exportable name form that is useful.  For
+   example, you might be able to export a name as a local machine user
+   ID with such a mechanism.
+
+   This solution works well especially for name information that can be
+   looked up in a directory.  It was unclear from the p      discussion
+   whether this solution would allow mechanism-specific name information
+   to be extracted from a context.  If so, then this solution would meet
+   many of the goals of this document.
+
+   One advantage of this solution is that it requires few if any changes
+   to GSS-API semantics.  It is not as flexible as other solutions.
+   Also, it is not clear how to handle mechanisms that do not have a
+   well defined name to export with this solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                 [Page 9]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+7.  Deferring Credential Binding
+
+   Currently GSS-API credentials represent a single mechanism name.
+   While working on other issues discussion focused around choosing the
+   correct credential for a particular  target.  There are several
+   situations where an implementation can do a better job of choosing a
+   default source name to use given the name of the target to connect
+   to.  Currently, GSS-API does not provide a mechanism to do this.
+   Adding such a mechanism would be desirable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                [Page 10]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+8.  Security Considerations
+
+   GSS-API sets up a security context between two named parties.  The
+   GSS-API names are security assertions that are authenticated by the
+   context establishment process.  As such  the GSS naming architecture
+   is critical to the security of GSS-API.
+
+   Currently GSS-API uses a simplistic naming model for authorization.
+   Names can be compared  against a set of names on an access control
+   list.  This architecture is relatively simple and its security
+   properties are well understood.  However it does not provide the
+   flexibility and feature set for future deployments of GSS-API.
+
+   This proposal will significantly increase the complexity of the GSS
+   naming architecture.  As this proposal is fleshed out, we need to
+   consider ways of managing security exposures created by this
+   increased complexity.
+
+   One area where the complexity may lead to security problems is
+   composite names with attributes from different sources.  This may be
+   desirable so that name attributes that carry their own
+   authentication.  However the design of any solutions needs to make
+   sure that applications can assign appropriate trust to name
+   components.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires August 21, 2005                [Page 11]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+9.  Acknowledgements
+
+   John Brezak, Paul Leach and Nicolas Williams all participated in
+   discussions that lead to a desire to enhance GSS naming.  Martin Rex
+   provided descriptions of the current naming architecture and pointed
+   out many ways in which proposed enhancements would create
+   interoperability problems or increase complexity.  Martin also
+   provided excellent information on what aspects of GSS naming have
+   tended to be implemented badly or have not met the needs of some
+   customers.
+
+   Nicolas Williams helped describe the possible approaches for
+   enhancing naming.
+
+10  Informative References
+
+   [1]  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", rfc
+        2025, October 1996.
+
+   [2]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [3]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
+        progress), June 2004.
+
+   [4]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
+        KDC Referrals to locate Kerberos realms",
+        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
+        2004.
+
+   [5]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and Certificate Revocation
+        List (CRL) Profile", rfc 3280, April 2002.
+
+   [6]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
+        Profile for Authorization.", rfc 3281, April 2002.
+
+
+Author's Address
+
+   Sam Hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+Hartman                 Expires August 21, 2005                [Page 12]
+
+Internet-Draft                 GSS Names                   February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                 Expires August 21, 2005                [Page 13]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-02.txt
new file mode 100644
index 00000000000..b5d04478850
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-02.txt
@@ -0,0 +1,842 @@
+
+
+
+
+Network Working Group                                         S. Hartman
+Internet-Draft                                                       MIT
+Expires: December 4, 2005                                   June 2, 2005
+
+
+                 Desired Enhancements to GSSAPI Naming
+                  draft-ietf-kitten-gss-naming-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on December 4, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Generic Security Services API (GSS-API) provides a naming
+   architecture that supports  name-based authorization.  GSS-API
+   authenticates two named parties to each other.  Names can be stored
+   on access control lists to make authorization decisions.  Advances in
+   security mechanisms and the way implementers wish to use GSS-API
+   require this model to be extended.  As people move within an
+   organization or change their names, the name authenticated by GSS-API
+   may change.  Using some sort of constant identifier would make ACLs
+   more stable.  Some mechanisms such as public-key mechanisms do not
+
+
+
+Hartman                 Expires December 4, 2005                [Page 1]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+   have a single name to be used across all environments.  Other
+   mechanisms such as Kerberos include may include group membership or
+   role information as part of authentication.  This document motivates
+   extensions to GSS-API naming and describes the extensions under
+   discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005                [Page 2]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+1.  Introduction
+
+   The Generic Security Services API [2] authenticates two named parties
+   to each other.  GSS names can be imported in a variety of formats
+   through the gss_import_name call.  Several mechanism-independent name
+   formats are provided including GSS_C_NT_HOSTBASED_SERVICE for
+   services running on an Internet host and GSS_C_NT_USER_NAME for the
+   names of users.  Other mechanism-specific name types are also
+   provided.  By the time a name is used in acquiring a mechanism-
+   specific credential or establishing a security context, it has been
+   transformed into one of these mechanism-specific name types.  In
+   addition, the GSS-API provides a function called gss_export_name that
+   will flatten a GSS-API name into a binary blob suitable for
+   comparisons.  This binary blob can be stored on ACLs and then
+   authorization decisions can be made simply by comparing the name
+   exported from a newly accepted context to the name on the ACL.
+
+   Storing names on ACLs can be problematic because names tend to change
+   over time .  If the name contains organizational information such as
+   a domain part or an indication of what department someone works for,
+   this changes as the person moves around the organization.  Even if no
+   organizational information is included in the name, the name will
+   change as people change their names.  Updating ACLs to reflect name
+   changes is difficult.  Another significant problem is that names can
+   be reused to apply to another entity than the entity to which they
+   originally applied.  For example if a Unix user ID is placed on an
+   ACL, the account deleted and then a new user assigned the old ID,
+   then that new user may gain privileges intended for the old user.
+
+   Inherent in the GSS naming  model is the idea that  mechanism names
+   need to be able to be represented in a single canonical form.  Anyone
+   importing that name needs to be able to retrieve the canonical form
+   of that name.
+
+   Several security mechanisms have been proposed for which this naming
+   architecture is too restrictive.  In some cases it is not always
+   possible to canonicalize any name that is imported.  In other cases
+   there is no single canonical name.
+
+   Also, as GSS-API is used in more complex environments, there is a
+   desire to use attribute certificates [6], Kerberos authorization data
+   [3], or other non-name-based authorization models.  GSS-API needs to
+   be enhanced in order to support these uses in a mechanism-independent
+   manner.
+
+   This document discusses the particular naming problems with two
+   important classes of GSS-API mechanisms.  It also discusses the set
+   of proposed solutions and open issues with these solutions.  This
+
+
+
+Hartman                 Expires December 4, 2005                [Page 3]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+   draft limits discussion to these solutions and provides a description
+   of the problem against which the solutions can be judged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005                [Page 4]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+2.  Kerberos Naming
+
+   The Kerberos mechanism demonstrates both the naming stability problem
+   and the authorization extension problem.
+
+   The Kerberos Referrals draft [4] proposes a new type of Kerberos name
+   called an enterprise name.  The intent is that the enterprise name is
+   an alias that the user knows for themselves and can use to login.
+   The Kerberos KDC translates this name into a normal Kerberos
+   principal and gives the user tickets for this principal.  This normal
+   principal is used for authorization.  The intent is that the
+   enterprise name tracks the user as they move throughout the
+   organization, even if they move to parts of the organization that
+   have different naming policies.  The name they type at login remains
+   constant, but the Kerberos principal used to authenticate them to
+   services changes.
+
+   Performing a mapping from enterprise  name to principal name is not
+   generally possible for unauthenticated services.  Even authenticated
+   services may not be authorized to perform this mapping except for
+   their own name.  Also, Kerberos does not (and does not plan to)
+   provide a mechanism for mapping enterprise names to principals
+   besides authentication as the enterprise name.  Thus, any such
+   mapping would be vendor-specific.  With this feature in Kerberos, it
+   is not possible to implement gss_canonicalize_name for enterprise
+   name types.
+
+   Another issue arises with enterprise names.  IN some cases it would
+   be desirable to put   the enterprise name on the ACL instead of a
+   principal name for greater ACL stability.  At first glance this could
+   be accomplished by including the enterprise name in the name exported
+   by gss_export_name.  Unfortunately, if this were done, the exported
+   name would change whenever the mapping changed, invalidating any ACL
+   entries based off the old exported name and defeating the purpose  of
+   including the enterprise name in the exported name.  In some cases it
+   would be desirable to have the exported name be based on the
+   enterprise name and in others based on the principal name, but this
+   is not permitted by the current GSS-API.
+
+   Another development also complicates GSS-API naming for Kerberos.
+   Several vendors have been looking at mechanisms to include group
+   membership information in Kerberos authorization data.  It is
+   desirable to put these group names on ACLs.  Again, GSS-API currently
+   has no mechanism to use this information.
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005                [Page 5]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+3.  X.509 Names
+
+   X.509 names are more complicated than Kerberos names.  In the
+   Kerberos case there is a single principal carried in all Kerberos
+   messages.  X.509 certificates have multiple options.  It seems  the
+   subject name might be the appropriate name to use as the name to be
+   exported in a GSS-API mechanism.  However RFC 3280 [5] does not even
+   require the subject name to be a non-empty sequence.  Instead there
+   are cases where the subjectAltName extension is the only thing to
+   identify the subject of the certificate.  As in the case of Kerberos
+   group memberships, there may be many subjectAltName extensions
+   available in a certificate.  Different applications will care about
+   different extensions.  One possible candidate for an exported name
+   would be all the names and SubjectAltName extensions from a
+   certificate.  However as new names are added then existing ACL
+   entries would be invalidated; this is undesirable.  Thus there is no
+   single value that can be  defined as the exported GSS-API name that
+   will be useful in all environments.
+
+   A profile of a particular X.509  GSS-API mechanism could require a
+   specific name be used.  However this would limit that mechanism to
+   require a particular type of certificate.  There is interest in being
+   able to use arbitrary X.509 certificates with GSS-API for some
+   applications.
+
+   Experience so far has not lead to sufficient interoperability with
+   GSS-API X.509 mechanisms.  Even if the subject name is used, there is
+   ambiguity in how to handle sorting of name components.  Martin Rex
+   said that he was aware of several SPKM [1] implementations but no two
+   were fully interoperable on names.
+
+   Also, as discussed in the introduction, it is desirable to support
+   X.509 attribute certificates.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005                [Page 6]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+4.  Composite Names
+
+   One proposal to solve these problems is to extend the concept of a
+   GSS-API name to include a set of name attributes.  Each attribute
+   would be an octet-string labeled by an OID.  Examples of attributes
+   would include Kerberos enterprise names, group memberships in an
+   authorization infrastructure, Kerberos authorization data attributes
+   and subjectAltName attributes in a certificate.  Several new
+   operations would be needed:
+
+   1.  Add an  attribute to name.
+
+   2.  Query attributes of name.
+
+   3.  Query values of an attribute.
+
+   4.  Delete an attribute from a name.
+
+   5.  Export a complete composite name and all its attributes for
+       transport between processes.
+
+   Note that an exported composite name would not generally be suitable
+   for binary comparison.  Avoiding confusion between this operation and
+   the existing gss_export_name operation will require careful work.
+
+   Additional utility operations will probably be needed depending on
+   the implementation of name attributes.
+
+4.1  Usage of Name Attributes
+
+   Since attributes are part of GSS-API names, the acceptor can retrieve
+   the attributes of the initiator's and acceptor's name from the
+   context.  These attributes can then be used for authorization.
+
+   Most name attributes will probably not come from explicit operations
+   to add attributes to a name.  Instead, name attributes will probably
+   come from mechanism specific credentials.  Components of these
+   mechanism specific credentials may come from platform or environment-
+   specific names.  Mechanism specific naming and group membership can
+   be  mapped into name attributes by the mechanism implementation.  The
+   specific form of this mapping will generally require protocol
+   specification for each mechanism.
+
+   The value of many  name attributes may be suitable for use in binary
+   comparison.  This should enable applications to use these name
+   attributes on ACLs the same way exported names are now used on ACLs.
+   For example if a particular Subjectaltname extension contains the
+   appropriate  identity for an application, then  the name attribute
+
+
+
+Hartman                 Expires December 4, 2005                [Page 7]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+   for this Subjectaltname can be placed on the ACL.  This is only true
+   if the name attribute is stored in some canonical form.
+
+4.2  Open issues
+
+   This section describes parts of the proposal to add attributes to
+   names that will need to be explored before the proposal can become a
+   protocol specification.
+
+   Are mechanisms expected to be able to carry arbitrary name attributes
+   as part of a context establishment?  At first it seems like this
+   would be desirable.  However the purpose of GSS-API is to establish
+   an authenticated context between two peers.  In particular, a context
+   authenticates two named entities to each other.  The names of these
+   entities and attributes associated with these names will be used for
+   authorization decisions.  If an initiator or acceptor is allowed to
+   assert name attributes and the authenticity of these assertions is
+   not validated by the mechanisms, then security problems will result.
+   On the other hand, requiring that name attributes be mechanism
+   specific and only be carried by mechanisms that understand the name
+   attributes and can validate them compromises GSS-API's place as a
+   generic API.  Application authors would be forced to understand
+   mechanism-specific attributes to make authorization decisions.  In
+   addition if mechanisms are not required to transport arbitrary
+   attributes, then application authors will need to deal with different
+   implementations of the same mechanism that support different sets of
+   name attributes.  One possible solution is to carry a source along
+   with each name attribute; this source could indicate whether the
+   attribute comes from a mechanism data structure or from the other
+   party in the authentication.
+
+   Another related question is how will name attributes be mapped into
+   their mechanism-specific forms.  For example it would be desirable to
+   map many  Kerberos authorization data elements into name attributes.
+   In the case of the Microsoft PAC, it would be desirable for some
+   applications to get the entire PAC.  However in many cases, the
+   specific lists of security IDs contained in the PAC would be more
+   directly useful to an application.  So there may not be a good one-
+   to-one mapping between the mechanism-specific elements and the
+   representation desirable at the GSS-API layer.
+
+   Specific name matching rules need to be developed.  How do names with
+   attributes compare?  What is the effect of a name attribute on a
+   target name in gss_accept_sec_context?
+
+4.3  Handling gss_export_name
+
+   For many mechanisms, there will be  an obvious choice to use for the
+
+
+
+Hartman                 Expires December 4, 2005                [Page 8]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+   name exported by gss_export_name.  For example in the case of
+   Kerberos, the principal name can continue to be used as the exported
+   name.  This will allow applications depending on existing GSS-API
+   name-based authorization to continue to work.  However it is probably
+   desirable to allow GSS-API mechanisms for which gss_export_name
+   cannot meaningfully be defined.  The behavior of gss_export_name in
+   such cases should probably be to return some error.  Such mechanisms
+   may not work with existing applications and cannot conform to the
+   current version of the GSS-API.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005                [Page 9]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+5.  Credential Extensions
+
+   An alternative to the name attributes proposal  is to extend GSS-API
+   credentials  with extensions labeled by OIDs.  Interfaces would be
+   needed to manipulate these credential extensions and to retrieve the
+   credential extensions for credentials used to establish a context.
+   Even if name attributes are used, credential extensions may be useful
+   for other unrelated purposes.
+
+   It is possible to solve problems discussed in this document using
+   some credential extension mechanism.  Doing so will have many of the
+   same open issues as discussed in the  composite names  proposal.  The
+   main advantage of a credential extensions proposal is that  it avoids
+   specifying how name attributes interact with name comparison or
+   target names.
+
+   The primary advantage of the name attributes proposal over credential
+   extensions is that name attributes seem to fit better into the GSS-
+   API authorization model.  Names are already available at all points
+   when authorization decisions are made.  In addition, for many
+   mechanisms the sort of information carried as name attributes will
+   also be carried as part of the name in the mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005               [Page 10]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+6.  Mechanisms for Export Name
+
+   Another proposal is to define some GSS-API mechanisms whose only
+   purpose is to have an exportable name form that is useful.  For
+   example, you might be able to export a name as a local machine user
+   ID with such a mechanism.
+
+   This solution works well especially for name information that can be
+   looked up in a directory.  It was unclear from the p      discussion
+   whether this solution would allow mechanism-specific name information
+   to be extracted from a context.  If so, then this solution would meet
+   many of the goals of this document.
+
+   One advantage of this solution is that it requires few if any changes
+   to GSS-API semantics.  It is not as flexible as other solutions.
+   Also, it is not clear how to handle mechanisms that do not have a
+   well defined name to export with this solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005               [Page 11]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+7.  Deferring Credential Binding
+
+   Currently GSS-API credentials represent a single mechanism name.
+   While working on other issues discussion came up focused around
+   choosing the correct credential for a particular target.  There are
+   several situations where an implementation can do a better job of
+   choosing a default source name to use given the name of the target to
+   connect to.  Currently, GSS-API does not provide a mechanism to do
+   this.  Adding such a mechanism would be desirable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005               [Page 12]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+8.  Security Considerations
+
+   GSS-API sets up a security context between two named parties.  The
+   GSS-API names are security assertions that are authenticated by the
+   context establishment process.  As such  the GSS naming architecture
+   is critical to the security of GSS-API.
+
+   Currently GSS-API uses a simplistic naming model for authorization.
+   Names can be compared  against a set of names on an access control
+   list.  This architecture is relatively simple and its security
+   properties are well understood.  However it does not provide the
+   flexibility and feature set for future deployments of GSS-API.
+
+   This proposal will significantly increase the complexity of the GSS
+   naming architecture.  As this proposal is fleshed out, we need to
+   consider ways of managing security exposures created by this
+   increased complexity.
+
+   One area where the complexity may lead to security problems is
+   composite names with attributes from different sources.  This may be
+   desirable so that name attributes that carry their own
+   authentication.  However the design of any solutions needs to make
+   sure that applications can assign appropriate trust to name
+   components.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires December 4, 2005               [Page 13]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+9.  Acknowledgements
+
+   John Brezak, Paul Leach and Nicolas Williams all participated in
+   discussions that lead to a desire to enhance GSS naming.  Martin Rex
+   provided descriptions of the current naming architecture and pointed
+   out many ways in which proposed enhancements would create
+   interoperability problems or increase complexity.  Martin also
+   provided excellent information on what aspects of GSS naming have
+   tended to be implemented badly or have not met the needs of some
+   customers.
+
+   Nicolas Williams helped describe the possible approaches for
+   enhancing naming.
+
+10.  Informative References
+
+   [1]  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
+        rfc 2025, October 1996.
+
+   [2]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
+        progress), June 2004.
+
+   [4]  Jaganathan , K., Zhu, L., Swift, M., and J. Brezak, "Generating
+        KDC Referrals to locate Kerberos realms",
+        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
+        2004.
+
+   [5]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and Certificate Revocation
+        List (CRL) Profile", rfc 3280, April 2002.
+
+   [6]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
+        Profile for Authorization.", rfc 3281, April 2002.
+
+
+Author's Address
+
+   Sam Hartman
+   MIT
+
+   Email: hartmans@mit.edu
+
+
+
+
+
+Hartman                 Expires December 4, 2005               [Page 14]
+
+Internet-Draft                  GSS Names                      June 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                 Expires December 4, 2005               [Page 15]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
new file mode 100644
index 00000000000..b7bcc7c5eac
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
@@ -0,0 +1,784 @@
+
+KITTEN WG                                                    N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+  Clarifications and Extensions to the GSS-API for the Use of Channel
+                                Bindings
+            draft-ietf-kitten-gssapi-channel-bindings-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document clarifies and generalizes the GSS-API "channel
+   bindings" facility.  This document also specifies the format of the
+   various types of channel bindings.
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Generic Structure for GSS-API Channel Bindings . . . . . . . .  5
+     3.1   Proper Mechanism Use of Channel Bindings . . . . . . . . .  5
+   4.  Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . .  6
+     4.1   GSS_Make_sshv2_channel_bindings()  . . . . . . . . . . . .  6
+       4.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Channel Bindings for TLS . . . . . . . . . . . . . . . . . . .  7
+     5.1   GSS_Make_tls_channel_bindings()  . . . . . . . . . . . . .  7
+       5.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Channel Bindings for IPsec . . . . . . . . . . . . . . . . . .  8
+     6.1   GSS_Make_ipsec_channel_bindings()  . . . . . . . . . . . .  8
+       6.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.1   Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.2   Informative  . . . . . . . . . . . . . . . . . . . . . . . . 11
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
+       Intellectual Property and Copyright Statements . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+2.  Introduction
+
+   The concept of "channel bindings" and the abstract construction of
+   channel bindings for several types of channels are described in
+   [CHANNEL-BINDINGS]
+
+   To actually use channel bindings in GSS-API aplications additional
+   details are required that are given below.
+
+   First the structure given to channel bindings data in [RFC2744] is
+   generalized to all of the GSS-API, not just its C-Bindings.
+
+   Then the actual construction of channel bindings to SSHv2, TLS and
+   IPsec channels is given.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+3.  Generic Structure for GSS-API Channel Bindings
+
+   The base GSS-API v2, update 1 specification [RFC2743]describes
+   channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
+   update 1 C-Bindings specification to specify the structure of the
+   contents of the channel bindings OCTET STRINGs.  The C-Bindings
+   specification [RFC2744]then defines, in terms of C, what should be
+   generic structure for channel bindings.  The Kerberos V GSS mechanism
+   [RFC1964]then defines a method for encoding GSS channel bindings in a
+   way that is independent of the C-Bindings!
+
+   In other words, the structure of GSS channel bindings given in
+   [RFC2744] is actually generic, rather than specific to the C
+   programming language.
+
+   Here, then, is a generic re-statement of this structure, in
+   pseudo-ASN.1:
+
+   		GSS-CHANNEL-BINDINGS := SEQUENCE {
+   			initiator-address-type	INTEGER,
+   			initiator-address	OCTET STRING,
+   			acceptor-address-type   INTEGER,
+   			acceptor-address	OCTET STRING,
+   			application-data	OCTET STRING,
+   		}
+
+   The values for the address fields are described in [RFC2744].
+
+   Language-specific bindings of the GSS-API should specify a
+   language-specific formulation of this structure.
+
+3.1  Proper Mechanism Use of Channel Bindings
+
+   As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
+   integrity protected proofs of channel bindings, where the proof is
+   obtained by running a strong hash of the channel bindings data
+   (encoded as per some mechanism-specific, such as in [RFC1964]) and a
+   binary value to represent the initiator->acceptor, and opposite,
+   direction.
+
+   The encoding of channel bindings used in [RFC1964], with the addition
+   of a binary value as described above, and the substitution of SHA-1
+   for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
+   that any future GSS mechanisms can use.
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+4.  Channel Bindings for SSHv2
+
+   The SSHv2 channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS SSHv2 CB:"
+   2.  The SSHv2 session ID
+   3.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+4.1  GSS_Make_sshv2_channel_bindings()
+
+   Inputs:
+
+   o  session_id OCTET STRING,
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+4.1.1  C-Bindings
+
+   OM_uint32 gss_make_sshv2_channel_bindings(
+     OM_uint32			*minor_status,
+     const gss_buffer_t		session_id,
+     const gss_buffer_t		additional_app_data,
+     gss_buffer_t	     channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+5.  Channel Bindings for TLS
+
+   The TLS channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS TLSv1.0 CB:"
+   2.  The TLS finished message sent by the client
+   3.  The TLS finished message sent by the server
+   4.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+5.1  GSS_Make_tls_channel_bindings()
+
+   Inputs:
+
+   o  client_finished_msg OCTET STRING,
+   o  server_finished_msg OCTET STRING,
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+5.1.1  C-Bindings
+
+   OM_uint32 gss_make_tls_channel_bindings(
+     OM_uint32			*minor_status,
+     const gss_buffer_t		client_finished_msg,
+     const gss_buffer_t		server_finished_msg,
+     const gss_buffer_t		additional_app_data,
+     gss_buffer_t		channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+6.  Channel Bindings for IPsec
+
+   The IPsec channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS IPsec CB:"
+   2.  The transform ID for encryption, as a 16-bit big-endian word
+   3.  The transform ID for integrity protection, as 16-bit in
+       big-endian word
+   4.  The initiator ID payload as used in the key exchange protocol
+       used for setting up the channel's SAs
+   5.  The responder ID payload as used in the key exchange protocol
+       used for setting up the channel's SAs
+   6.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+   Note that traffic selectors are not included.  Inclusion of
+   confidentiality/integrity algorithms protects against MITMs that can
+   compromise weaker algorithms that policy might permit, for the same
+   peers, for other traffic.
+
+6.1  GSS_Make_ipsec_channel_bindings()
+
+   Inputs:
+
+   o  encr_alg INTEGER,
+   o  integ_alg INTEGER,
+   o  initiator_id OCTET_STRING,
+   o  acceptor_id OCTET_STRING,
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+6.1.1  C-Bindings
+
+   OM_uint32 gss_make_ipsec_channel_bindings(
+     OM_uint32			*minor_status,
+     OM_uint32			encr_alg,
+     OM_uint32			integ_alg,
+     const gss_buffer_t		initiator_id,
+     const gss_buffer_t		acceptor_id,
+     const gss_buffer_t		additional_app_data,
+     gss_buffer_t		channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+7.  Security Considerations
+
+   For general security considerations relating to channel bindings see
+   [CHANNEL-BINDINGS]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 10]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+8.  References
+
+8.1  Normative
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+8.2  Informative
+
+   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
+              Specification", STD 8, RFC 854, May 1983.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2203]  Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
+              Specification", RFC 2203, September 1997.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2623]  Eisler, M., "NFS Version 2 and Version 3 Security Issues
+              and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
+              RFC 2623, June 1999.
+
+   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
+              Beame, C., Eisler, M. and D. Noveck, "Network File System
+              (NFS) version 4 Protocol", RFC 3530, April 2003.
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 11]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 12]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Appendix A.  Acknowledgments
+
+   The author would like to thank Mike Eisler for his work on the
+   Channel Conjunction Mechanism I-D and for bringing the problem to a
+   head, Sam Hartman for pointing out that channel bindings provide a
+   general solution to the channel binding problem, Jeff Altman for his
+   suggestion of using the TLS finished messages as the TLS channel
+   bindings, Bill Sommerfeld, for his help in developing channel
+   bindings for IPsec, and Radia Perlman for her most helpful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 13]
+
+Internet-Draft          GSS-API Channel Bindings               July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004               [Page 14]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt
new file mode 100644
index 00000000000..f148c65023b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt
@@ -0,0 +1,897 @@
+
+
+
+KITTEN WG                                                    N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+  Clarifications and Extensions to the GSS-API for the Use of Channel
+                                Bindings
+            draft-ietf-kitten-gssapi-channel-bindings-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document clarifies and generalizes the GSS-API "channel
+   bindings" facility.  This document also specifies the format of the
+   various types of channel bindings.
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Generic Structure for GSS-API Channel Bindings . . . . . . . .  5
+     3.1.  Proper Mechanism Use of Channel Bindings . . . . . . . . .  5
+   4.  Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . .  6
+     4.1.  GSS_Make_sshv2_channel_bindings()  . . . . . . . . . . . .  6
+       4.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Channel Bindings for TLS . . . . . . . . . . . . . . . . . . .  8
+     5.1.  GSS_Make_tls_channel_bindings()  . . . . . . . . . . . . .  8
+       5.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 10
+     6.1.  GSS_Make_ipsec_channel_bindings()  . . . . . . . . . . . . 10
+       6.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 11
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 13
+     8.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
+   Intellectual Property and Copyright Statements . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+2.  Introduction
+
+   The concept of "channel bindings" and the abstract construction of
+   channel bindings for several types of channels are described in
+   [CHANNEL-BINDINGS]
+
+   To actually use channel bindings in GSS-API aplications additional
+   details are required that are given below.
+
+   First the structure given to channel bindings data in [RFC2744] is
+   generalized to all of the GSS-API, not just its C-Bindings.
+
+   Then the actual construction of channel bindings to SSHv2, TLS and
+   IPsec channels is given.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+3.  Generic Structure for GSS-API Channel Bindings
+
+   The base GSS-API v2, update 1 specification [RFC2743]describes
+   channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
+   update 1 C-Bindings specification to specify the structure of the
+   contents of the channel bindings OCTET STRINGs.  The C-Bindings
+   specification [RFC2744]then defines, in terms of C, what should be
+   generic structure for channel bindings.  The Kerberos V GSS mechanism
+   [RFC1964]then defines a method for encoding GSS channel bindings in a
+   way that is independent of the C-Bindings!
+
+   In other words, the structure of GSS channel bindings given in
+   [RFC2744] is actually generic, rather than specific to the C
+   programming language.
+
+   Here, then, is a generic re-statement of this structure, in pseudo-
+   ASN.1:
+
+                   GSS-CHANNEL-BINDINGS := SEQUENCE {
+                           initiator-address-type  INTEGER,
+                           initiator-address       OCTET STRING,
+                           acceptor-address-type   INTEGER,
+                           acceptor-address        OCTET STRING,
+                           application-data        OCTET STRING,
+                   }
+
+   The values for the address fields are described in [RFC2744].
+
+   Language-specific bindings of the GSS-API should specify a language-
+   specific formulation of this structure.
+
+3.1.  Proper Mechanism Use of Channel Bindings
+
+   As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
+   integrity protected proofs of channel bindings, where the proof is
+   obtained by running a strong hash of the channel bindings data
+   (encoded as per some mechanism-specific, such as in [RFC1964]) and a
+   binary value to represent the initiator->acceptor, and opposite,
+   direction.
+
+   The encoding of channel bindings used in [RFC1964], with the addition
+   of a binary value as described above, and the substitution of SHA-1
+   for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
+   that any future GSS mechanisms can use.
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+4.  Channel Bindings for SSHv2
+
+   The SSHv2 channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS SSHv2 CB:"
+
+   2.  The SSHv2 session ID
+
+   3.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+4.1.  GSS_Make_sshv2_channel_bindings()
+
+   Inputs:
+
+
+   o  session_id OCTET STRING,
+
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+4.1.1.  C-Bindings
+
+   OM_uint32 gss_make_sshv2_channel_bindings(
+     OM_uint32                     *minor_status,
+     const gss_buffer_t            session_id,
+     const gss_buffer_t            additional_app_data,
+     gss_buffer_t       channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+5.  Channel Bindings for TLS
+
+   The TLS channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+   1.  The ASCII string "GSS TLSv1.0 CB:"
+
+   2.  The TLS finished message sent by the client
+
+   3.  The TLS finished message sent by the server
+
+   4.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+5.1.  GSS_Make_tls_channel_bindings()
+
+   Inputs:
+
+
+   o  client_finished_msg OCTET STRING,
+
+   o  server_finished_msg OCTET STRING,
+
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 8]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+5.1.1.  C-Bindings
+
+   OM_uint32 gss_make_tls_channel_bindings(
+     OM_uint32                     *minor_status,
+     const gss_buffer_t            client_finished_msg,
+     const gss_buffer_t            server_finished_msg,
+     const gss_buffer_t            additional_app_data,
+     gss_buffer_t          channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 9]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+6.  Channel Bindings for IPsec
+
+   The IPsec channel bindings are constructed as an octet string for the
+   'application-data' field of the channel bindings by concatenating the
+   following values and in this order:
+
+
+   1.  The ASCII string "GSS IPsec CB:"
+
+   2.  The transform ID for encryption, as a 16-bit big-endian word
+
+   3.  The transform ID for integrity protection, as 16-bit in big-
+       endian word
+
+   4.  NOTE: The following needs to be updated to take into account
+       progress of BTNS.
+
+   5.  The initiator ID payload as used in the key exchange protocol
+       used for setting up the channel's SAs
+
+   6.  The responder ID payload as used in the key exchange protocol
+       used for setting up the channel's SAs
+
+   7.  Any additional application-provided data, encoded as the DER
+       encoding of an ASN.1 OCTET STRING
+
+   Note that traffic selectors are not included.  Inclusion of
+   confidentiality/integrity algorithms protects against MITMs that can
+   compromise weaker algorithms that policy might permit, for the same
+   peers, for other traffic.
+
+6.1.  GSS_Make_ipsec_channel_bindings()
+
+   Inputs:
+
+
+   o  encr_alg INTEGER,
+
+   o  integ_alg INTEGER,
+
+   o  initiator_id OCTET_STRING,
+
+   o  acceptor_id OCTET_STRING,
+
+   o  additional_app_data OCTET STRING
+
+   Outputs:
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 10]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  channel_bindings_app_data OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates failure to construct the channel bindings
+      as a result, perhaps, of a memory management, or similar failure.
+
+   This function constructs an OCTET STRING for use as the value of the
+   application-data field of the GSS-CHANNEL-BINDINGS structure
+   described above.
+
+6.1.1.  C-Bindings
+
+   OM_uint32 gss_make_ipsec_channel_bindings(
+     OM_uint32                     *minor_status,
+     OM_uint32                     encr_alg,
+     OM_uint32                     integ_alg,
+     const gss_buffer_t            initiator_id,
+     const gss_buffer_t            acceptor_id,
+     const gss_buffer_t            additional_app_data,
+     gss_buffer_t          channel_bindings_app_data
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 11]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+7.  Security Considerations
+
+   For general security considerations relating to channel bindings see
+   [CHANNEL-BINDINGS]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 12]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+8.  References
+
+8.1.  Normative
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+8.2.  Informative
+
+   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
+              Specification", STD 8, RFC 854, May 1983.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
+              Specification", RFC 2203, September 1997.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2623]  Eisler, M., "NFS Version 2 and Version 3 Security Issues
+              and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
+              RFC 2623, June 1999.
+
+   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
+              Beame, C., Eisler, M., and D. Noveck, "Network File System
+              (NFS) version 4 Protocol", RFC 3530, April 2003.
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 13]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+Appendix A.  Acknowledgments
+
+   The author would like to thank Mike Eisler for his work on the
+   Channel Conjunction Mechanism I-D and for bringing the problem to a
+   head, Sam Hartman for pointing out that channel bindings provide a
+   general solution to the channel binding problem, Jeff Altman for his
+   suggestion of using the TLS finished messages as the TLS channel
+   bindings, Bill Sommerfeld, for his help in developing channel
+   bindings for IPsec, and Radia Perlman for her most helpful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 14]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 15]
+
+Internet-Draft          GSS-API Channel Bindings            October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 16]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt
new file mode 100644
index 00000000000..50cd5b9d9ca
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt
@@ -0,0 +1,617 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+            GSS-API Domain-Based Service Names and Name Type
+           draft-ietf-kitten-gssapi-domain-based-names-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes domainname-based service principal names and
+   the corresponding name type for the Generic Security Service
+   Application Programming Interface (GSS-API).
+
+   Domain-based service names are similar to host-based service names,
+   but using a domain name (not necessarily and Internat domain name)
+   instead of or in addition to a hostname.  The primary purpose of
+   domain-based service names is to provide a way to name clustered
+   services after the domain which they service, thereby allowing their
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+   clients to authorize the service's servers based on authentication of
+   their names.
+
+
+Table of Contents
+
+   1.    Conventions used in this document  . . . . . . . . . . . . .  3
+   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.    Name Type OID and Symbolic Name  . . . . . . . . . . . . . .  5
+   4.    Query and Display Syntaxes . . . . . . . . . . . . . . . . .  6
+   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   6.    Security Considerations  . . . . . . . . . . . . . . . . . .  8
+   7.    References . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . .  9
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
+         Intellectual Property and Copyright Statements . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+2.  Introduction
+
+   The use of hostbased principal names for domain-wide services
+   presents the problem of how to distinguish between an instance of a
+   hostbased service that is authorized to respond for a domain and one
+   that isn't.
+
+   Consider LDAP.  LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V
+   mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased
+   principal with a service name of "ldap", a reasonable approach,
+   provided there is only one logical LDAP directory in a Kerberos
+   realm's domain, and that all ldap servers in that realm serve that
+   one LDAP directory.  If there were other LDAP directories, then
+   clients could not tell which service is authorized to serve which
+   directory, not without assuming a secure method for finding LDAP
+   servers (e.g., DNSSEC).  This is a significant, and oft-unstated
+   restriction on users of LDAP.
+
+   Domain based names can eliminate this problem by allowing LDAP
+   service names to indicate which LDAP directory they are authorized to
+   serve.
+
+   A domain-based name consists of three required elements:
+
+   o  a service name
+
+   o  a domain name
+
+   o  a hostname
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+3.  Name Type OID and Symbolic Name
+
+   The new name type has an OID of
+
+      [NOTE: OID assignment to be made with IANA.]
+
+      {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
+      domain-based(5)}
+
+   The recommended symbolic name for this GSS-API name type is
+   "GSS_C_NT_DOMAINBASED_SERVICE".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+4.  Query and Display Syntaxes
+
+   There is a single name syntax for domain-based names.
+
+   The syntax is:
+
+      domain-based-name :=
+
+         | <service> '@' <domain> '@' <hostname>
+
+   Note that for Internet domain names the trailing '.' is not and MUST
+   NOT be included in the domain name (or hostname) parts of the display
+   form GSS-API domain-based MNs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+5.  Examples
+
+   o  ldap@example.tld@ds1.example.tld
+
+   o  kadmin@example.tld@kdc1.example.tld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+6.  Security Considerations
+
+   Use of GSS-API domain-based names may not be negotiable by some GSS-
+   API mechanisms, and some acceptors may not support GSS-API domain-
+   based names.  In such cases initiators are left to fallback on the
+   use of hostbased names, in which case the initiators MUST also verify
+   that the acceptor's hostbased name is authorized to provide the given
+   service for the domain that the initiator had wanted.
+
+   The above security consideration also applies to all GSS-API
+   initiators who lack support for domain-based service names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 8]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+7.  References
+
+7.1.  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+7.2.  Informative
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
+              (SASL)", RFC 2222, October 1997.
+
+   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
+              Protocol (v3): Technical Specification", RFC 3377,
+              September 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 9]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 10]
+
+Internet-Draft           GSS Domain Based Names             October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
new file mode 100644
index 00000000000..772f3678688
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
@@ -0,0 +1,393 @@
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: July 2, 2005                                       January 2005
+
+
+     Namespace Considerations and Registries for GSS-API Extensions
+            draft-ietf-kitten-gssapi-extensions-iana-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on July 2, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes the ways in which the GSS-API may be extended
+   and directs the creation of IANA registries for various GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 1]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Extensions to the GSS-API  . . . . . . . . . . . . . . . . . .  3
+   4.  Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . .  3
+   5.  Language Binding-Specific GSS-API Namespaces . . . . . . . . .  4
+   6.  Extension-Specific GSS-API Namespaces  . . . . . . . . . . . .  4
+   7.  Registration Form(s) . . . . . . . . . . . . . . . . . . . . .  4
+   8.  Initial Namespace Registrations  . . . . . . . . . . . . . . .  6
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   10. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
+       Intellectual Property and Copyright Statements . . . . . . . .  7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 2]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+1.  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 [RFC2119].
+
+2.  Introduction
+
+   There is a need for generic and mechanism-specific extensions to the
+   Generic Security Services Application Programming Interface
+   (GSS-API).  As such extensions are designed and standardized, both at
+   the IETF and elsewhere, there is a non-trivial risk of namespace
+   pollution and conflicts.  To avoid this we set out guidelines for
+   extending the GSS-API and create IANA registries of GSS-API
+   namespaces.
+
+   The registration of name prefixes and constant value ranges is
+   allowed so as to save the IANA the trouble of registering every
+   GSS-API name and constant, and to allow for reservation of portions
+   of some GSS namespaces for private extensions or extensions which
+   lack IETF Standards-Track extensions.
+
+3.  Extensions to the GSS-API
+
+   Extensions to the GSS-API can be categorized as follows:
+   o  Generic
+   o  Implementation-specific
+   o  Mechanism-specific
+   o  Language binding-specific
+   o  Any combination of two or all three of the last three
+
+   Extensions to the GSS-API may be purely semantic, without effect on
+   the GSS-API's namespaces.  Or they may introduce new functions,
+   constants, types, etc...; these clearly affect the GSS-API
+   namespaces.
+
+   Extensions that affect the GSS-API namespaces should be registered
+   with the IANA.
+
+4.  Generic GSS-API Namespaces
+
+   All the function, constant and type names, as well as all the
+   constant values specified in the base GSS-API specification for the
+   basic generic GSS-API namespace.
+
+   The generic GSS-API namespaces are:
+   o  Type names
+   o  Function names
+
+
+
+Williams                  Expires July 2, 2005                  [Page 3]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+   o  Constant names for each type
+   o  Constant values for each type
+   o  Mechanism OIDs
+   o  Name Type OIDs
+   o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
+
+5.  Language Binding-Specific GSS-API Namespaces
+
+   <Add text; discuss header, module, library, class, method namespaces
+   and whatever else comes up that is language-specific and appropriate
+   for registration with the IANA.>
+
+6.  Extension-Specific GSS-API Namespaces
+
+   Extensions to the GSS-API may create additional namespaces.
+   Instructions to the IANA should included for the handling of such
+   namespaces.
+
+7.  Registration Form(s)
+
+   Registrations for GSS-API namespaces SHALL take the following form:
+
+   +----------------------+----------------------+---------------------+
+   | Registration Field   | Possible Values      | Description         |
+   +----------------------+----------------------+---------------------+
+   | Registration type    | 'Individual',        | Indicates whether   |
+   |                      | 'Prefix', 'Range'    | this entry reserves |
+   |                      |                      | a given symbol name |
+   |                      |                      | or constant value   |
+   |                      |                      | or whether it       |
+   |                      |                      | reserves an entire  |
+   |                      |                      | sub-namespace (the  |
+   |                      |                      | name is a "prefix") |
+   |                      |                      | or constant value   |
+   |                      |                      | range.              |
+   | Bindings             | 'Generic',           | Indicates the       |
+   |                      | 'C-bindings',        | language bindings   |
+   |                      | 'Java', 'C#', etc... | that this           |
+   |                      |                      | registration is     |
+   |                      |                      | for, or, if         |
+   |                      |                      | 'Generic', that     |
+   |                      |                      | this is an entry    |
+   |                      |                      | for the generic     |
+   |                      |                      | GSS-API, not        |
+   |                      |                      | specific to any     |
+   |                      |                      | programming         |
+   |                      |                      | language.           |
+   | Object Type          | 'Symbol',            | Indicates whether   |
+
+
+
+Williams                  Expires July 2, 2005                  [Page 4]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+   |                      | 'Constant-Value'     | this registration   |
+   |                      |                      | is for a symbol     |
+   |                      |                      | (e.g., function,    |
+   |                      |                      | constant name(s))   |
+   |                      |                      | or constant value.  |
+   | Object Programming   | 'Data-Type',         | Indicates the type  |
+   | Type                 | 'Function',          | of the object(s)    |
+   |                      | 'Method', 'Integer', | whose symbolic name |
+   |                      | 'String', 'OID'      | or constant value   |
+   |                      |                      | is this entry       |
+   |                      |                      | registers.          |
+   | Object Name          | <Symbol name or name | The name(s) of      |
+   |                      | prefix>              | symbols or values   |
+   |                      |                      | being registered.   |
+   | Object Value         | <Constant value> or  | [Only for           |
+   |                      | <constant value      | Constant-Value      |
+   |                      | range>               | registrations.] The |
+   |                      |                      | value(s)            |
+   |                      |                      | registered.         |
+   | Description          | <Text>               | Description of      |
+   |                      |                      | object(s) being     |
+   |                      |                      | registered.         |
+   | Reference            | <Reference>          | Reference to        |
+   |                      |                      | document that       |
+   |                      |                      | describes the       |
+   |                      |                      | object(s) being     |
+   |                      |                      | registered.         |
+   | Status               | 'Standards-Track',   |                     |
+   |                      | 'Informational',     |                     |
+   |                      | 'Experimental',      |                     |
+   |                      | 'Obsolete'           |                     |
+   +----------------------+----------------------+---------------------+
+
+   The IANA should create a single GSS-API namespace registry, or
+   multiple registries, one for symbolic names and one for constant
+   values, or it may create a registry per-programming language, at its
+   convenience.
+
+   Entries in these registries should consist of all the fields from
+   their corresponding registration entries.
+
+   Entries SHOULD be sorted by object type, proggamming language, symbol
+   name.
+
+   <Add text on guidelines for IANA consideration of registration
+   applications, particularly with respect to entries lacking normative
+   references, "magic" entries (e.g., special values of 'time' types
+   which indicate something other than absolute or relative time, such
+
+
+
+Williams                  Expires July 2, 2005                  [Page 5]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+   as GSS_C_INDEFINITE), expert review requirements (if any) for
+   registrations lacking normative references, etc....>
+
+8.  Initial Namespace Registrations
+
+   <Add registration entries for namespaces (name prefixes) for RFC2743/
+   RFC2744/RFC2853.>
+
+   <Add registration entries for private namespaces (name prefixes) for
+   implementation- and/or platform-specific extensions.>
+
+9.  Security Considerations
+
+   This document has no security considerations.
+
+10  Normative
+
+   [EXTENDED-INQUIRY]
+              Williams, N., "Extended Generic Security Service Mechanism
+              Inquiry APIs",
+              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
+              progress).
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 6]
+
+Internet-Draft           GSS IANA Instructions              January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                  Expires July 2, 2005                  [Page 7]
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt
new file mode 100644
index 00000000000..2d1e888c8d0
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt
@@ -0,0 +1,393 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+     Namespace Considerations and Registries for GSS-API Extensions
+            draft-ietf-kitten-gssapi-extensions-iana-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes the ways in which the GSS-API may be extended
+   and directs the creation of IANA registries for various GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft            GSS IANA Instructions             October 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document . . . . . . . . . . . . . . . 3
+   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3
+   4.  Generic GSS-API Namespaces  . . . . . . . . . . . . . . . . . . 3
+   5.  Language Binding-Specific GSS-API Namespaces  . . . . . . . . . 4
+   6.  Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4
+   7.  Registration Form(s)  . . . . . . . . . . . . . . . . . . . . . 4
+   8.  Initial Namespace Registrations . . . . . . . . . . . . . . . . 5
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+       Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 6
+       Intellectual Property and Copyright Statements  . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft            GSS IANA Instructions             October 2005
+
+
+1.  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 [RFC2119].
+
+
+2.  Introduction
+
+   There is a need for generic and mechanism-specific extensions to the
+   Generic Security Services Application Programming Interface (GSS-
+   API).  As such extensions are designed and standardized, both at the
+   IETF and elsewhere, there is a non-trivial risk of namespace
+   pollution and conflicts.  To avoid this we set out guidelines for
+   extending the GSS-API and create IANA registries of GSS-API
+   namespaces.
+
+   The registration of name prefixes and constant value ranges is
+   allowed so as to save the IANA the trouble of registering every GSS-
+   API name and constant, and to allow for reservation of portions of
+   some GSS namespaces for private extensions or extensions which lack
+   IETF Standards-Track extensions.
+
+
+3.  Extensions to the GSS-API
+
+   Extensions to the GSS-API can be categorized as follows:
+   o  Generic
+   o  Implementation-specific
+   o  Mechanism-specific
+   o  Language binding-specific
+   o  Any combination of two or all three of the last three
+
+   Extensions to the GSS-API may be purely semantic, without effect on
+   the GSS-API's namespaces.  Or they may introduce new functions,
+   constants, types, etc...; these clearly affect the GSS-API
+   namespaces.
+
+   Extensions that affect the GSS-API namespaces should be registered
+   with the IANA.
+
+
+4.  Generic GSS-API Namespaces
+
+   All the function, constant and type names, as well as all the
+   constant values specified in the base GSS-API specification for the
+   basic generic GSS-API namespace.
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft            GSS IANA Instructions             October 2005
+
+
+   The generic GSS-API namespaces are:
+   o  Type names
+   o  Function names
+   o  Constant names for each type
+   o  Constant values for each type
+   o  Mechanism OIDs
+   o  Name Type OIDs
+   o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
+
+
+5.  Language Binding-Specific GSS-API Namespaces
+
+   <Add text; discuss header, module, library, class, method namespaces
+   and whatever else comes up that is language-specific and appropriate
+   for registration with the IANA.>
+
+
+6.  Extension-Specific GSS-API Namespaces
+
+   Extensions to the GSS-API may create additional namespaces.
+   Instructions to the IANA should included for the handling of such
+   namespaces.
+
+
+7.  Registration Form(s)
+
+   Registrations for GSS-API namespaces SHALL take the following form:
+
+   <TBD>
+
+   The IANA should create a single GSS-API namespace registry, or
+   multiple registries, one for symbolic names and one for constant
+   values, or it may create a registry per-programming language, at its
+   convenience.
+
+   Entries in these registries should consist of all the fields from
+   their corresponding registration entries.
+
+   Entries SHOULD be sorted by object type, proggamming language, symbol
+   name.
+
+   <Add text on guidelines for IANA consideration of registration
+   applications, particularly with respect to entries lacking normative
+   references, "magic" entries (e.g., special values of 'time' types
+   which indicate something other than absolute or relative time, such
+   as GSS_C_INDEFINITE), expert review requirements (if any) for
+   registrations lacking normative references, etc....>
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft            GSS IANA Instructions             October 2005
+
+
+8.  Initial Namespace Registrations
+
+   <Add registration entries for namespaces (name prefixes) for RFC2743/
+   RFC2744/RFC2853.>
+
+   <Add registration entries for private namespaces (name prefixes) for
+   implementation- and/or platform-specific extensions.>
+
+
+9.  Security Considerations
+
+   This document has no security considerations.
+
+10.  Normative
+
+   [EXTENDED-INQUIRY]
+              Williams, N., "Extended Generic Security Service Mechanism
+              Inquiry APIs",
+              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
+              progress).
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft            GSS IANA Instructions             October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft            GSS IANA Instructions             October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-00.txt
new file mode 100644
index 00000000000..c6325ee78c0
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-00.txt
@@ -0,0 +1,1117 @@
+Internet-Draft                                                       Sun
+Expires: November 14, 2005                                  May 13, 2005
+
+
+                       GSS-API Naming Extensions
+              draft-ietf-kitten-gssapi-naming-exts-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on November 14, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Generic Security Services API (GSS-API) provides a simple naming
+   architecture that supports name-based authorization.  This document
+   introduces new APIs that extend the GSS-API naming and authorization
+   model.
+
+
+
+
+
+
+
+
+Williams                Expires November 14, 2005               [Page 1]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+Table of Contents
+
+   1.    Conventions used in this document  . . . . . . . . . . . . .  3
+   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.    Name Attribute Sources and Criticality . . . . . . . . . . .  3
+   4.    Name Attributes/Values as ACL Subjects . . . . . . . . . . .  4
+   5.    Mapping Mechanism Facilities to Name Attributes  . . . . . .  4
+   5.1   Kerberos V and SPKM Authorization-Data . . . . . . . . . . .  4
+   5.2   Kerberos V Cross-Realm Transit Paths . . . . . . . . . . . .  5
+   5.3   PKIX Certificate Extensions  . . . . . . . . . . . . . . . .  5
+   5.3.1 PKIX EKUs  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   5.3.2 PKIX Certificate Alternative Names . . . . . . . . . . . . .  6
+   5.3.3 Other PKIX Certificate Extensions and Attributes . . . . . .  6
+   5.4   PKIX Certificate CA Paths and Trust Anchors  . . . . . . . .  6
+   6.    GSS_Inquire_name_attribute() . . . . . . . . . . . . . . . .  6
+   6.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   6.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . .  7
+   7.    GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . .  7
+   7.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   7.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.    GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . .  8
+   8.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   8.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.    GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . . 10
+   9.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 11
+   10.   GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . . 12
+   10.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   10.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 12
+   11.   GSS_Delete_name_attribute()  . . . . . . . . . . . . . . . . 13
+   11.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   11.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 13
+   12.   GSS_Export_name_composite()  . . . . . . . . . . . . . . . . 14
+   12.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   12.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 14
+   13.   GSS_Map_name_to_any()  . . . . . . . . . . . . . . . . . . . 15
+   13.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 15
+   13.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 16
+   14.   GSS_Release_any_name_mapping() . . . . . . . . . . . . . . . 16
+   14.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 16
+   14.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 17
+   15.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 17
+   16.   Security Considerations  . . . . . . . . . . . . . . . . . . 17
+   17.   References . . . . . . . . . . . . . . . . . . . . . . . . . 18
+   17.1  Normative References . . . . . . . . . . . . . . . . . . . . 18
+   17.2  Informative References . . . . . . . . . . . . . . . . . . . 18
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
+         Intellectual Property and Copyright Statements . . . . . . . 20
+
+
+
+Williams                Expires November 14, 2005               [Page 2]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+1.  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 [RFC2119].
+
+2.  Introduction
+
+   As described in [I-D.GSS-NAMING] the GSS-API's naming architecture
+   suffers from certain limitations.  This document proposes concrete
+   GSS-API extensions as outlined in [I-D.GSS-NAMING].
+
+   A number of extensions to the GSS-API are described herein with the
+   goal of making authorization information, and other information that
+   can be modelled as "name attributes" available as such to
+   applications.  For example, Kerberos V authorization data elements,
+   both, in their raw forms as well as mapped to more useful value
+   types, can be made available to GSS-API applications through these
+   interfaces.
+
+   The model is that GSS names have attributes.  The attributes of a
+   name may be authenticated by the credential whence the name comes, or
+   may have been set locally on a GSS name for the purpose of
+   "asserting" the attribute during credential acquisition or security
+   context exchange.  Name attributes' values are network
+   representations thereof (e.g., the actual value octets of the
+   contents of an X.509 certificate extension, for example) and are
+   intended to be useful for constructing portable access control
+   facilities.  Applications may often require language- or platform-
+   specific data types, rather than network representations of name
+   attributes, so a function is provided to obtain objects of such types
+   associated with names and name attributes.
+
+3.  Name Attribute Sources and Criticality
+
+   A given GSS name object's name attributes may be authenticated or
+   asserted by an associated credential, or it may be mapped or derived
+   from another attribute of the same name.
+
+   That a given name's given attribute is 'mapped' means that it was
+   obtained through some mapping mechanism applied to another attribute
+   of the name that was not, itself, mapped.  For example, such
+   attributes as platform-specific internal identifiers may sometimes be
+   mapped from other name attributes.
+
+   Name attributes may be "critical," meaning that applications that do
+   not understand them MUST reject security contexts where the peer has
+   such unknown, critical attributes.
+
+
+
+Williams                Expires November 14, 2005               [Page 3]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+4.  Name Attributes/Values as ACL Subjects
+
+   Some name attributes (e.g., numeric user or group identifiers) may be
+   useful as subjects of access control list (ACL) entries, some may not
+   (e.g., time of day login restrictions).  The
+   GSS_Inquire_name_attribute() function indicates this.
+
+   To facilitate the development of portable applications that make use
+   of name attributes to construct and evaluate portable ACLs the GSS-
+   API makes name attribute values available in canonical network
+   encodings thereof.
+
+   To facilitate the development of platform- or language-specific
+   applications that need access to native types of representations of
+   name attributes an optional facility is provided,
+   GSS_Map_name_to_any().
+
+5.  Mapping Mechanism Facilities to Name Attributes
+
+   [NOTE:  This entire section should probably be split into one or more
+   separate Internet-Drafts.  It is here in the -00 of this I-D to help
+   readers understand how to mechanism-specific name attributes would be
+   accessed through these GSS-API extensions.]
+
+   Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple
+   Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the
+   concept and encoding of containers of "authorization-data" as
+   described in [I-D.ietf-krb-wg-kerberos-clarifications].
+
+   PKIX [RFC3280] supports a number of authorization-data-like features,
+   like Extended Key Usage values (EKUs) and certificate extensions.
+
+   The authorization data can be accessed through the GSS-API name
+   attributes facility defined herein.
+
+5.1  Kerberos V and SPKM Authorization-Data
+
+   Authorization-data non-container elements asserted in Kerberos V AP-
+   REQ Authenticators MUST be mapped into *asserted* GSS-API name
+   attributes; if not contained in AD-IF-RELEVANT then they MUST be
+   mapped into *critical* GSS-API name attributes.  AD-AND-OR
+   authorization-data elements MUST be mapped into a single *critical*
+   attribute, (TBD).
+
+   Authorization-data included in Kerberos V Tickets that is not
+   contained in AD-KDCIssued (with valid signature) MUST be mapped into
+   *asserted* GSS-API name attributes.  Conversely, authorization-data
+   elements in Kerberos V Tickets contained by AD-KDCIssued MUST be
+
+
+
+Williams                Expires November 14, 2005               [Page 4]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   mapped into *authenticated* GSS-API name attributes
+
+   As with authorization-data elements in Authenticators, authorization-
+   data elements in Tickets not contained in AD-IF-RELEVANT are to be
+   mapped to *critical* name attributes, and similarly with AD-AND-OR
+   (see above).
+
+   The OIDs for authorization-data elements are to be the authorization-
+   data element's 'ad-type' integer ID, relative to the base OID <TBD>
+   [NOTE: what about negative ad-type's?  OID arcs are positive
+   integers... ad-type is an Int32, so clearly something can be done.]
+
+5.2  Kerberos V Cross-Realm Transit Paths
+
+   [Add text on how to represent/encode/interpret krb5 realm transit
+   paths as name attribute values.  And text on PKINIT too...  Basically
+   Ticket's 'transited' field should be exposed as an authenticated name
+   attribute, with some uncompressed encoding, possibly encompassing
+   certificate validation paths of client certs used for PKINIT, with
+   criticality determined by the presence of the transit-policy-checked
+   flag.]
+
+5.3  PKIX Certificate Extensions
+
+   [NOTE:  In the Kerberos V authorization-data case we can tell when AD
+   elements are "authenticated" and when the are asserted, but what
+   about x.509 certificate extensions?  Clearly KU, EKUs and
+   subjectAltNames are authenticated in that no CA should sign a cert
+   with, say, arbitrary subjectAltNames not understood by the CA, but,
+   does that also apply to all other x.509 certificate extensions?  The
+   answer may depend on actual CA operator practices...  At worst a new
+   extension may be needed, like Kerberos V's AD-KDCIssued AD container
+   element; at best this text can just say "all cert extensions MUST be
+   mapped to authenticated..." below.]
+
+   PKI certificate extensions MAY/SHOULD/MUST (see comment above) be
+   mapped to *authenticated* GSS-API name attributes with the _same_
+   OIDs, and if they be marked critical in the certificate then they
+   MUST be mapped as *critical* GSS-API name attributes.
+   SubjectAltNames and EKUs, specifically, MUST be mapped to
+   *authenticated* GSS-API name attributes; see below.  Certificate
+   extensions MUST be mapped to GSS-API name attributes whose OIDs are
+   the same as the extensions'
+
+5.3.1  PKIX EKUs
+
+   Extended Key Usage extensions, specifically, MUST be mapped as
+   described above, except that GSS-API name attributes for EKUs MUST
+
+
+
+Williams                Expires November 14, 2005               [Page 5]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   have NULL values (i.e., zero-length OCTET STRINGs).
+
+   PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to
+   GSS-API name attributes.
+
+5.3.2  PKIX Certificate Alternative Names
+
+   PKI certificate subjectAltNames MUST be mapped as *authenticated*,
+   *non-critical* GSS-API name attributes.
+
+   PKI certificate extensions MUST be mapped to *authenticated* GSS-API
+   name attributes with the _same_ OIDs, and if they be marked critical
+   in the certificate then they MUST be mapped as *critical* GSS-API
+   name attributes.
+
+   Extended Key Usage extensions, specifically, MUST be mapped as
+   described above, except that GSS-API name attributes for EKUs MUST
+   have NULL values (i.e., zero-length OCTET STRINGs).
+
+5.3.3  Other PKIX Certificate Extensions and Attributes
+
+   [Add text...]
+
+5.4  PKIX Certificate CA Paths and Trust Anchors
+
+   [Add text on how to represent/encode/interpret PKI certificate
+   validation CA paths as name attribute values, much as with Kerberos V
+   transited paths.]
+
+6.  GSS_Inquire_name_attribute()
+
+   Inputs:
+
+
+   o  attr OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  attr_name OCTET STRING,
+
+   o  attr_description OCTET STRING,
+
+   o  attr_is_a_name BOOLEAN,
+
+
+
+Williams                Expires November 14, 2005               [Page 6]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   o  attr_is_trust_indicator BOOLEAN
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known (even if present as a name's attribute).
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs a name for the given name attribute,
+   description for display to users, indicates whether the given name
+   attribute's values are useful as the subject of an access control
+   list entry and/or whether the given name attribute's values are
+   useful as indicators of trust (for example, whether they name PKIX
+   trust anchors).
+
+6.1  C-Bindings
+
+   OM_uint32 gss_inquire_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_OID                       attr,
+     gss_buffer_t                  attr_name,
+     gss_buffer_t                  attr_description,
+     int                           *attr_is_a_name,
+     int                           *attr_is_trust_indicator
+   );
+
+
+6.2  Java Bindings
+
+   public String nameAttributeName(Oid attr)
+      throws GSSException
+   public String nameAttributeDescription(Oid attr)
+      throws GSSException
+   public boolean nameAttributeIsName(Oid attr)
+      throws GSSException
+   public boolean nameAttributeIsTrustIndicator(Oid attr)
+      throws GSSException
+
+
+7.  GSS_Display_name_ext()
+
+   Inputs:
+
+
+   o  name NAME,
+
+
+
+Williams                Expires November 14, 2005               [Page 7]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   o  display_as_name_type OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  display_name STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given name could not be
+      displayed using the syntax of the given name type.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function displays a given name using the given name syntax, if
+   possible.  This operation may require mapping MNs to generic name
+   syntaxes or generic name syntaxes to mechanism-specific name
+   syntaxes; such mappings may not always be feasible and MAY be inexact
+   or lossy.
+
+7.1  C-Bindings
+
+   OM_uint32 GSS_Display_name_ext(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       display_as_name_type,
+     gss_buffer_t                  display_name
+   );
+
+
+7.2  Java Bindings
+
+   public String displayExtended(Oid display_as_name_type)
+      throws GSSException
+
+
+8.  GSS_Inquire_name()
+
+   Inputs:
+
+
+   o  name NAME
+
+
+
+Williams                Expires November 14, 2005               [Page 8]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_is_MN BOOLEAN,
+
+   o  mn_mech OBJECT IDENTIFIER
+
+   o  asserted_attrs SET OF OBJECT IDENTIFIER
+
+   o  authenticated_attrs SET OF OBJECT IDENTIFIER
+
+   o  critical_attrs SET OF OBJECT IDENTIFIER
+
+   o  all_attrs SET OF OBJECT IDENTIFIER
+
+   o  [NOTE: Perhaps this function should also output an indicator as to
+      the provenance of the name, of which, in the GSS-API, there are
+      three: imported, inquired from a credential, and a peer's name
+      inquired from a security context.]
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs the sets of attributes of a name, that are
+   authenticated, asserted or critical.  It also indicates if a given
+   NAME is an MN or not and, if it is, what mechanism it's an MN of.
+
+8.1  C-Bindings
+
+   OM_uint32 gss_inquire_name(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     int                           name_is_MN,
+     gss_OID                       *MN_mech,
+     gss_OID_set                   *authenticated,
+     gss_OID_set                   *asserted,
+     gss_OID_set                   *critical,
+     gss_OID_set                   *all_attrs
+   );
+
+
+
+
+
+Williams                Expires November 14, 2005               [Page 9]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+8.2  Java Bindings
+
+   public boolean isMN(boolean authenticated, boolean critical)
+      throws GSSException
+   public Oid mnMech(boolean authenticated, boolean critical)
+      throws GSSException
+   public Oid[] allAttributes(boolean authenticated, boolean critical)
+      throws GSSException
+   public Oid[] authenticatedAttributes(boolean authenticated,
+      boolean critical) throws GSSException
+   public Oid[] assertedAttributes(boolean authenticated,
+      boolean critical) throws GSSException
+   public Oid[] criticalAttributes(boolean authenticated,
+      boolean critical) throws GSSException
+
+
+9.  GSS_Get_name_attribute()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  attr OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  authenticated BOOLEAN,
+
+   o  mapped BOOLEAN,
+
+   o  critical BOOLEAN,
+
+   o  values SET OF OCTET STRING,
+
+   o  display_values SET OF STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known or set.
+
+
+
+Williams                Expires November 14, 2005              [Page 10]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs the value(s) associated with a given GSS name
+   object for a given name attribute.
+
+9.1  C-Bindings
+
+   The C-bindings of GSS_Get_name_attribute() requires one function call
+   per-attribute value, for multi-valued name attributes.  This is done
+   by using a single gss_buffer_t for each value and an input/output
+   integer parameter to distinguish initial and subsequent calls and to
+   indicate when all values have been obtained.
+
+   The 'more' input/output parameter should point to an integer variable
+   whose value, on first call to gss_name_attribute_get() MUST be -1,
+   and whose value upon function call return will be non-zero to
+   indicate that additional values remain, or zero to indicate that no
+   values remain.  The caller should not modify this parameter after the
+   initial call.
+
+   OM_uint32 gss_get_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       attr,
+     int                           *authenticated,
+     int                           *mapped,
+     int                           *critical,
+     gss_buffer_t                  value,
+     gss_buffer_t                  display_value,
+     int                           *more
+   );
+
+
+9.2  Java Bindings
+
+   public byte[] getAttributeValue(Oid attr)
+      throws GSSException
+   public String getAttributeDisplayValue(Oid attr)
+      throws GSSException
+   public boolean isAttributeAuthenticated(Oid attr)
+      throws GSSException
+   public boolean isAttributeMapped(Oid attr)
+      throws GSSException
+   public boolean getAttributeCriticality(Oid attr)
+      throws GSSException
+
+
+10.  GSS_Set_name_attribute()
+
+
+
+Williams                Expires November 14, 2005              [Page 11]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  critical BOOLEAN,
+
+   o  attr OBJECT IDENTIFIER,
+
+   o  values SET OF OCTET STRING
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known or could not be set.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+
+10.1  C-Bindings
+
+   The C-bindings of GSS_Set_name_attribute() requires one function call
+   per-attribute value, for multi-valued name attributes -- each call
+   adds one value.  To replace an attribute's every value delete the
+   attribute's values first with GSS_Delete_name_attribute().
+
+   OM_uint32 gss_set_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     int                           critical,
+     gss_OID                       attr,
+     gss_buffer_t                  value
+   );
+
+
+10.2  Java Bindings
+
+   The Java-bindings of GSS_Set_name_attribute() requires one function
+   call per-attribute value, for multi-valued name attributes -- each
+
+
+
+Williams                Expires November 14, 2005              [Page 12]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   call adds one value.  To replace an attribute's every value delete
+   the attribute's values first with GSS_Delete_name_attribute().
+
+   public abstract setAttribute(Oid attr, boolean critical,
+                                byte[] value)
+      throws GSSException
+
+
+11.  GSS_Delete_name_attribute()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  attr OBJECT IDENTIFIER,
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+
+11.1  C-Bindings
+
+   OM_uint32 gss_delete_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       attr
+   );
+
+
+11.2  Java Bindings
+
+   public abstract deleteAttribute(Oid attr, boolean critical)
+      throws GSSException
+
+
+
+
+Williams                Expires November 14, 2005              [Page 13]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+12.  GSS_Export_name_composite()
+
+   Inputs:
+
+
+   o  name NAME
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  exp_composite_name OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs a token which can be imported with
+   GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type
+   and which preserves any name attribute information associated with
+   the input name (which GSS_Export_name() may well not).  The token
+   format is no specified here as this facility is intended for inter-
+   process communication only; however, all such tokens MUST start with
+   a two-octet token ID, hex 04 02, in network byte order.
+
+   The OID for GSS_C_NT_COMPOSITE_EXPORT is <TBD>.
+
+12.1  C-Bindings
+
+   OM_uint32 gss_export_name_composite(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_buffer_t                  exp_composite_name
+   );
+
+
+12.2  Java Bindings
+
+   public byte[] exportComposite()
+      throws GSSException
+
+
+13.  GSS_Map_name_to_any()
+
+
+
+Williams                Expires November 14, 2005              [Page 14]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  authenticated BOOLEAN, -- if TRUE no data will be output unless it
+      is authenticated
+
+   o  type_id OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output ANY DEFINED BY type_id
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
+      not be done.  The minor status code may provide additional
+      information.
+
+   o  GSS_S_FAILURE indicates a general error.  The minor status code
+      may provide additional information.
+
+   Whereas name attribute's values are encoded in some network
+   representation applications often require native, language- and/or
+   platform-specific data types.  This function provides access to such
+   types.
+
+13.1  C-Bindings
+
+   struct gss_any;
+   typedef struct gss_any *gss_any_t;
+   OM_uint32 gss_map_name_to_any(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     int                           authenticated,
+     gss_OID                       type_id,
+     gss_any_t                     output
+   );
+
+
+
+
+
+Williams                Expires November 14, 2005              [Page 15]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+13.2  Java Bindings
+
+   ...
+
+
+14.  GSS_Release_any_name_mapping()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  type_id OBJECT IDENTIFIER,
+
+   o  input ANY DEFINED BY type_id
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
+      not be done.  The minor status code may provide additional
+      information.
+
+   o  GSS_S_FAILURE indicates a general error.  The minor status code
+      may provide additional information.
+
+   This function releases, if possible, the objects of language- and/or
+   platform-specific types output by GSS_Map_name_to_any().  If such
+   types have native release functions applications MAY use either those
+   or this function to release the given object.
+
+14.1  C-Bindings
+
+   struct gss_any;
+   typedef struct gss_any *gss_any_t;
+   OM_uint32 gss_release_any_name_mapping(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       type_id,
+     gss_any_t                     *input
+
+
+
+Williams                Expires November 14, 2005              [Page 16]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   );
+
+
+14.2  Java Bindings
+
+   ...
+
+
+15.  IANA Considerations
+
+   This document creates a namespace of GSS-API name attributes.
+   Attributes are named by OID, so no single authority might be needed
+   for allocation, however, in the interest of providing the community
+   with an authority for name attribute OID allocation and a way to find
+   the existing set of name attributes, the IANA should establish both,
+   a single OID off of which name attributes could be allocated, and a
+   registry of known GSS name attributes.
+
+   GSS-API name attribute registry entries should contain all the
+   information that GSS_Inquire_name_attribute() may return about the
+   given name attributes and their OIDs:
+
+   o  a name attribute OID (this is a unique key)
+
+   o  a name attribute symbolic name, starting with "GSS_C_NA_" (this is
+      a unique key)
+
+   o  a brief description, in English
+
+   o  whether the attribute is useful as the subject of access control
+      list entries
+
+   o  whether the attribute is useful as an indicator of trust
+
+   o  an optional normative reference to documentation for the given
+      name attribute
+
+   The allocation and registration policy should be first come, first
+   served.  Registry entries' OIDs need not be based on the base OID
+   given above.
+
+16.  Security Considerations
+
+   <TBA>
+
+   [In particular, the status of a name attribute as "authenticated" vs.
+   "asserted" requires close review, particularly with respect to PKIX
+   certificate extensions.]
+
+
+
+Williams                Expires November 14, 2005              [Page 17]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+17.  References
+
+17.1  Normative References
+
+   [I-D.GSS-NAMING]
+              Hartman, S., "Desired Enhancements to GSSAPI Naming",
+              draft-ietf-kitten-gss-naming-01.txt (work in progress),
+              February 2005.
+
+   [I-D.ietf-krb-wg-kerberos-clarifications]
+              Neuman, C., "The Kerberos Network Authentication Service
+              (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work
+              in progress), September 2004.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+17.2  Informative References
+
+   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+
+
+Williams                Expires November 14, 2005              [Page 18]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires November 14, 2005              [Page 19]
+
+Internet-Draft          GSS-API Naming Extensions               May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires November 14, 2005              [Page 20]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-01.txt
new file mode 100644
index 00000000000..2058070007e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-01.txt
@@ -0,0 +1,1065 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 17, 2006                                 October 14, 2005
+
+
+                       GSS-API Naming Extensions
+              draft-ietf-kitten-gssapi-naming-exts-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 17, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Generic Security Services API (GSS-API) provides a simple naming
+   architecture that supports name-based authorization.  This document
+   introduces new APIs that extend the GSS-API naming and authorization
+   model.
+
+
+
+
+
+
+
+
+Williams                 Expires April 17, 2006                 [Page 1]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+Table of Contents
+
+   1.      Conventions used in this document  . . . . . . . . . . . .  3
+   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.      Name Attribute Sources and Criticality . . . . . . . . . .  3
+   4.      Name Attributes/Values as ACL Subjects . . . . . . . . . .  4
+   5.      Mapping Mechanism Facilities to Name Attributes  . . . . .  4
+   5.1.    Kerberos V and SPKM Authorization-Data . . . . . . . . . .  4
+   5.2.    Kerberos V Cross-Realm Transit Paths . . . . . . . . . . .  5
+   5.3.    PKIX Certificate Extensions  . . . . . . . . . . . . . . .  5
+   5.3.1.  PKIX EKUs  . . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.3.2.  PKIX Certificate Alternative Names . . . . . . . . . . . .  6
+   5.3.3.  Other PKIX Certificate Extensions and Attributes . . . . .  6
+   5.4.    PKIX Certificate CA Paths and Trust Anchors  . . . . . . .  6
+   6.      GSS_Inquire_name_attribute() . . . . . . . . . . . . . . .  6
+   6.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  7
+   7.      GSS_Display_name_ext() . . . . . . . . . . . . . . . . . .  8
+   7.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.      GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . .  9
+   8.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.      GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 10
+   9.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11
+   10.     GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 11
+   10.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
+   11.     GSS_Delete_name_attribute()  . . . . . . . . . . . . . . . 12
+   11.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13
+   12.     GSS_Export_name_composite()  . . . . . . . . . . . . . . . 13
+   12.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14
+   13.     GSS_Map_name_to_any()  . . . . . . . . . . . . . . . . . . 14
+   13.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15
+   14.     GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 15
+   14.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 16
+   15.     IANA Considerations  . . . . . . . . . . . . . . . . . . . 16
+   16.     Security Considerations  . . . . . . . . . . . . . . . . . 17
+   17.     Normative References . . . . . . . . . . . . . . . . . . . 17
+           Author's Address . . . . . . . . . . . . . . . . . . . . . 18
+           Intellectual Property and Copyright Statements . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 17, 2006                 [Page 2]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+1.  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 [RFC2119].
+
+
+2.  Introduction
+
+   As described in [I-D.GSS-NAMING] the GSS-API's naming architecture
+   suffers from certain limitations.  This document proposes concrete
+   GSS-API extensions as outlined in [I-D.GSS-NAMING].
+
+   A number of extensions to the GSS-API [RFC2743] and its C Bindings
+   [RFC2744] are described herein with the goal of making authorization
+   information, and other information that can be modelled as "name
+   attributes" available as such to applications.  For example, Kerberos
+   V authorization data elements, both, in their raw forms as well as
+   mapped to more useful value types, can be made available to GSS-API
+   applications through these interfaces.
+
+   The model is that GSS names have attributes.  The attributes of a
+   name may be authenticated by the credential whence the name comes, or
+   may have been set locally on a GSS name for the purpose of
+   "asserting" the attribute during credential acquisition or security
+   context exchange.  Name attributes' values are network
+   representations thereof (e.g., the actual value octets of the
+   contents of an X.509 certificate extension, for example) and are
+   intended to be useful for constructing portable access control
+   facilities.  Applications may often require language- or platform-
+   specific data types, rather than network representations of name
+   attributes, so a function is provided to obtain objects of such types
+   associated with names and name attributes.
+
+
+3.  Name Attribute Sources and Criticality
+
+   A given GSS name object's name attributes may be authenticated or
+   asserted by an associated credential, or it may be mapped or derived
+   from another attribute of the same name.
+
+   That a given name's given attribute is 'mapped' means that it was
+   obtained through some mapping mechanism applied to another attribute
+   of the name that was not, itself, mapped.  For example, such
+   attributes as platform-specific internal identifiers may sometimes be
+   mapped from other name attributes.
+
+   Name attributes may be "critical," meaning that applications that do
+
+
+
+Williams                 Expires April 17, 2006                 [Page 3]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   not understand them MUST reject security contexts where the peer has
+   such unknown, critical attributes.
+
+
+4.  Name Attributes/Values as ACL Subjects
+
+   Some name attributes (e.g., numeric user or group identifiers) may be
+   useful as subjects of access control list (ACL) entries, some may not
+   (e.g., time of day login restrictions).  The
+   GSS_Inquire_name_attribute() function indicates this.
+
+   To facilitate the development of portable applications that make use
+   of name attributes to construct and evaluate portable ACLs the GSS-
+   API makes name attribute values available in canonical network
+   encodings thereof.
+
+   To facilitate the development of platform- or language-specific
+   applications that need access to native types of representations of
+   name attributes an optional facility is provided,
+   GSS_Map_name_to_any().
+
+
+5.  Mapping Mechanism Facilities to Name Attributes
+
+   [NOTE: This entire section should probably be split into one or more
+   separate Internet-Drafts.  It is here in the -00 of this I-D to help
+   readers understand how to mechanism-specific name attributes would be
+   accessed through these GSS-API extensions.]
+
+   Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple
+   Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the
+   concept and encoding of containers of "authorization-data" as
+   described in [I-D.ietf-krb-wg-kerberos-clarifications].
+
+   PKIX [RFC3280] supports a number of authorization-data-like features,
+   like Extended Key Usage values (EKUs) and certificate extensions.
+
+   The authorization data can be accessed through the GSS-API name
+   attributes facility defined herein.
+
+5.1.  Kerberos V and SPKM Authorization-Data
+
+   Authorization-data non-container elements asserted in Kerberos V AP-
+   REQ Authenticators MUST be mapped into *asserted* GSS-API name
+   attributes; if not contained in AD-IF-RELEVANT then they MUST be
+   mapped into *critical* GSS-API name attributes.  AD-AND-OR
+   authorization-data elements MUST be mapped into a single *critical*
+   attribute, (TBD).
+
+
+
+Williams                 Expires April 17, 2006                 [Page 4]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   Authorization-data included in Kerberos V Tickets that is not
+   contained in AD-KDCIssued (with valid signature) MUST be mapped into
+   *asserted* GSS-API name attributes.  Conversely, authorization-data
+   elements in Kerberos V Tickets contained by AD-KDCIssued MUST be
+   mapped into *authenticated* GSS-API name attributes
+
+   As with authorization-data elements in Authenticators, authorization-
+   data elements in Tickets not contained in AD-IF-RELEVANT are to be
+   mapped to *critical* name attributes, and similarly with AD-AND-OR
+   (see above).
+
+   The OIDs for authorization-data elements are to be the authorization-
+   data element's 'ad-type' integer ID, relative to the base OID <TBD>
+   [NOTE: what about negative ad-type's?  OID arcs are positive
+   integers... ad-type is an Int32, so clearly something can be done.]
+
+5.2.  Kerberos V Cross-Realm Transit Paths
+
+   [Add text on how to represent/encode/interpret krb5 realm transit
+   paths as name attribute values.  And text on PKINIT too...  Basically
+   Ticket's 'transited' field should be exposed as an authenticated name
+   attribute, with some uncompressed encoding, possibly encompassing
+   certificate validation paths of client certs used for PKINIT, with
+   criticality determined by the presence of the transit-policy-checked
+   flag.]
+
+5.3.  PKIX Certificate Extensions
+
+   [NOTE: In the Kerberos V authorization-data case we can tell when AD
+   elements are "authenticated" and when the are asserted, but what
+   about x.509 certificate extensions?  Clearly KU, EKUs and
+   subjectAltNames are authenticated in that no CA should sign a cert
+   with, say, arbitrary subjectAltNames not understood by the CA, but,
+   does that also apply to all other x.509 certificate extensions?  The
+   answer may depend on actual CA operator practices...  At worst a new
+   extension may be needed, like Kerberos V's AD-KDCIssued AD container
+   element; at best this text can just say "all cert extensions MUST be
+   mapped to authenticated..." below.]
+
+   PKI certificate extensions MAY/SHOULD/MUST (see comment above) be
+   mapped to *authenticated* GSS-API name attributes with the _same_
+   OIDs, and if they be marked critical in the certificate then they
+   MUST be mapped as *critical* GSS-API name attributes.
+   SubjectAltNames and EKUs, specifically, MUST be mapped to
+   *authenticated* GSS-API name attributes; see below.  Certificate
+   extensions MUST be mapped to GSS-API name attributes whose OIDs are
+   the same as the extensions'
+
+
+
+
+Williams                 Expires April 17, 2006                 [Page 5]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+5.3.1.  PKIX EKUs
+
+   Extended Key Usage extensions, specifically, MUST be mapped as
+   described above, except that GSS-API name attributes for EKUs MUST
+   have NULL values (i.e., zero-length OCTET STRINGs).
+
+   PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to
+   GSS-API name attributes.
+
+5.3.2.  PKIX Certificate Alternative Names
+
+   PKI certificate subjectAltNames MUST be mapped as *authenticated*,
+   *non-critical* GSS-API name attributes.
+
+   PKI certificate extensions MUST be mapped to *authenticated* GSS-API
+   name attributes with the _same_ OIDs, and if they be marked critical
+   in the certificate then they MUST be mapped as *critical* GSS-API
+   name attributes.
+
+   Extended Key Usage extensions, specifically, MUST be mapped as
+   described above, except that GSS-API name attributes for EKUs MUST
+   have NULL values (i.e., zero-length OCTET STRINGs).
+
+5.3.3.  Other PKIX Certificate Extensions and Attributes
+
+   [Add text...]
+
+5.4.  PKIX Certificate CA Paths and Trust Anchors
+
+   [Add text on how to represent/encode/interpret PKI certificate
+   validation CA paths as name attribute values, much as with Kerberos V
+   transited paths.]
+
+
+6.  GSS_Inquire_name_attribute()
+
+   [NOTE: This function was somewhat controversial at IETF63; we should
+   decide whether to remove it at IETF64.  The controversy was, as I
+   recall over whether reflection functionality might not be dangerous,
+   leading to construction of inappropriate ACLs through dumb UIs.  For
+   now I am making some changes to it: adding a NAME object as an input
+   parameter and some output parameters.]
+
+   Inputs:
+
+
+   o  name NAME
+
+
+
+
+Williams                 Expires April 17, 2006                 [Page 6]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   o  attr OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  attr_name OCTET STRING, -- display name of the attribute
+
+   o  attr_description OCTET STRING, -- description of the attribute
+
+   o  attr_values_ordered BOOLEAN, -- whether the attribute's values are
+      an ordered set
+
+   o  attr_is_a_name BOOLEAN, -- whether the attribute's values can be
+      used as subjects of access control list entries
+
+   o  attr_is_trust_indicator BOOLEAN -- whether the attribute's values
+      represent nodes in trust paths
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known (even if present as a name's attribute).
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs a name for the given name attribute,
+   description for display to users, and indicates whether the
+   attribute's values are ordered sets, whether the given name
+   attribute's values are useful as the subject of an access control
+   list entry and/or whether the given name attribute's values are
+   useful as indicators of trust (for example, whether they name PKIX
+   trust anchors).
+
+6.1.  C-Bindings
+
+   OM_uint32 gss_inquire_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       attr,
+     gss_buffer_t                  attr_name,
+     gss_buffer_t                  attr_description,
+     int                           attr_values_ordered,
+
+
+
+Williams                 Expires April 17, 2006                 [Page 7]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+     int                           *attr_is_a_name,
+     int                           *attr_is_trust_indicator
+   );
+
+
+7.  GSS_Display_name_ext()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  display_as_name_type OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  display_name STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given name could not be
+      displayed using the syntax of the given name type.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function displays a given name using the given name syntax, if
+   possible.  This operation may require mapping MNs to generic name
+   syntaxes or generic name syntaxes to mechanism-specific name
+   syntaxes; such mappings may not always be feasible and MAY be inexact
+   or lossy.
+
+7.1.  C-Bindings
+
+   OM_uint32 GSS_Display_name_ext(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       display_as_name_type,
+     gss_buffer_t                  display_name
+   );
+
+
+
+
+
+Williams                 Expires April 17, 2006                 [Page 8]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+8.  GSS_Inquire_name()
+
+   Inputs:
+
+
+   o  name NAME
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_is_MN BOOLEAN,
+
+   o  mn_mech OBJECT IDENTIFIER,
+
+   o  asserted_attrs SET OF OBJECT IDENTIFIER,
+
+   o  authenticated_attrs SET OF OBJECT IDENTIFIER,
+
+   o  critical_attrs SET OF OBJECT IDENTIFIER,
+
+   o  all_attrs SET OF OBJECT IDENTIFIER,
+
+   o  [NOTE: Perhaps this function should also output an indicator as to
+      the provenance of the name, of which, in the GSS-API, there are
+      three: imported, inquired from a credential, and a peer's name
+      inquired from a security context.]
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs the sets of attributes of a name, that are
+   authenticated, asserted or critical.  It also indicates if a given
+   NAME is an MN or not and, if it is, what mechanism it's an MN of.
+
+8.1.  C-Bindings
+
+   OM_uint32 gss_inquire_name(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     int                           name_is_MN,
+     gss_OID                       *MN_mech,
+
+
+
+Williams                 Expires April 17, 2006                 [Page 9]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+     gss_OID_set                   *authenticated,
+     gss_OID_set                   *asserted,
+     gss_OID_set                   *critical,
+     gss_OID_set                   *all_attrs
+   );
+
+
+9.  GSS_Get_name_attribute()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  attr OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  authenticated BOOLEAN, -- FALSE if asserted but not authenticated
+      by a trusted entity
+
+   o  negative BOOLEAN,
+
+   o  mapped BOOLEAN,
+
+   o  critical BOOLEAN,
+
+   o  values SET OF OCTET STRING,
+
+   o  display_values SET OF STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known or set.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   This function outputs the value(s) associated with a given GSS name
+   object for a given name attribute.
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 10]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   NOTE: This function relies on the GSS-API notion of "SET OF" allowing
+   for order preservation; this has been discussed on the KITTEN WG
+   mailing list and the consensus seems to be that, indeed, that was
+   always the intention.
+
+9.1.  C-Bindings
+
+   The C-bindings of GSS_Get_name_attribute() requires one function call
+   per-attribute value, for multi-valued name attributes.  This is done
+   by using a single gss_buffer_t for each value and an input/output
+   integer parameter to distinguish initial and subsequent calls and to
+   indicate when all values have been obtained.
+
+   The 'more' input/output parameter should point to an integer variable
+   whose value, on first call to gss_name_attribute_get() MUST be -1,
+   and whose value upon function call return will be non-zero to
+   indicate that additional values remain, or zero to indicate that no
+   values remain.  The caller should not modify this parameter after the
+   initial call.
+
+   OM_uint32 gss_get_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       attr,
+     int                           *authenticated,
+     int                           *negative,
+     int                           *mapped,
+     int                           *critical,
+     gss_buffer_t                  value,
+     gss_buffer_t                  display_value,
+     int                           *more
+   );
+
+
+10.  GSS_Set_name_attribute()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  critical BOOLEAN,
+
+   o  negative BOOLEAN,
+
+   o  attr OBJECT IDENTIFIER,
+
+   o  values SET OF OCTET STRING
+
+
+
+Williams                 Expires April 17, 2006                [Page 11]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known or could not be set.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   NOTE: This function relies on the GSS-API notion of "SET OF" allowing
+   for order preservation; this has been discussed on the KITTEN WG
+   mailing list and the consensus seems to be that, indeed, that was
+   always the intention.
+
+10.1.  C-Bindings
+
+   The C-bindings of GSS_Set_name_attribute() requires one function call
+   per-attribute value, for multi-valued name attributes -- each call
+   adds one value.  To replace an attribute's every value delete the
+   attribute's values first with GSS_Delete_name_attribute().
+
+   OM_uint32 gss_set_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     int                           critical,
+     int                           negative,
+     gss_OID                       attr,
+     gss_buffer_t                  value
+   );
+
+
+11.  GSS_Delete_name_attribute()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  attr OBJECT IDENTIFIER,
+
+   Outputs:
+
+
+
+Williams                 Expires April 17, 2006                [Page 12]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
+      known.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+   Deletion of negative authenticated attributes from NAME objects MUST
+   NOT be allowed.  [Do we need a new major status code for "permission
+   denied"?]
+
+11.1.  C-Bindings
+
+   OM_uint32 gss_delete_name_attribute(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       attr
+   );
+
+
+12.  GSS_Export_name_composite()
+
+   Inputs:
+
+
+   o  name NAME
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  exp_composite_name OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_FAILURE indicates a general error.
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 13]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   This function outputs a token which can be imported with
+   GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type
+   and which preserves any name attribute information associated with
+   the input name (which GSS_Export_name() may well not).  The token
+   format is no specified here as this facility is intended for inter-
+   process communication only; however, all such tokens MUST start with
+   a two-octet token ID, hex 04 02, in network byte order.
+
+   The OID for GSS_C_NT_COMPOSITE_EXPORT is <TBD>.
+
+12.1.  C-Bindings
+
+   OM_uint32 gss_export_name_composite(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_buffer_t                  exp_composite_name
+   );
+
+
+13.  GSS_Map_name_to_any()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  authenticated BOOLEAN, -- if TRUE no data will be output unless it
+      is authenticated
+
+   o  type_id OBJECT IDENTIFIER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output ANY DEFINED BY type_id
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
+      not be done.  The minor status code may provide additional
+      information.
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 14]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   o  GSS_S_FAILURE indicates a general error.  The minor status code
+      may provide additional information.
+
+   Whereas name attribute's values are encoded in some network
+   representation applications often require native, language- and/or
+   platform-specific data types.  This function provides access to such
+   types.
+
+13.1.  C-Bindings
+
+   typedef struct gss_any *gss_any_t;
+   OM_uint32 gss_map_name_to_any(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     int                           authenticated,
+     gss_OID                       type_id,
+     gss_any_t                     output
+   );
+
+   Note the new C bindings type, gss_any_t.  We define it as a pointer
+   to an incompletely declared struct.
+
+
+14.  GSS_Release_any_name_mapping()
+
+   Inputs:
+
+
+   o  name NAME,
+
+   o  type_id OBJECT IDENTIFIER,
+
+   o  input ANY DEFINED BY type_id
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
+      not be done.  The minor status code may provide additional
+      information.
+
+
+
+Williams                 Expires April 17, 2006                [Page 15]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   o  GSS_S_FAILURE indicates a general error.  The minor status code
+      may provide additional information.
+
+   This function releases, if possible, the objects of language- and/or
+   platform-specific types output by GSS_Map_name_to_any().  If such
+   types have native release functions applications MAY use either those
+   or this function to release the given object.
+
+14.1.  C-Bindings
+
+   typedef struct gss_any *gss_any_t;
+   OM_uint32 gss_release_any_name_mapping(
+     OM_uint32                     *minor_status,
+     gss_name_t                    name,
+     gss_OID                       type_id,
+     gss_any_t                     *input
+   );
+
+
+15.  IANA Considerations
+
+   This document creates a namespace of GSS-API name attributes.
+   Attributes are named by OID, so no single authority might be needed
+   for allocation, however, in the interest of providing the community
+   with an authority for name attribute OID allocation and a way to find
+   the existing set of name attributes, the IANA should establish both,
+   a single OID off of which name attributes could be allocated, and a
+   registry of known GSS name attributes.
+
+   GSS-API name attribute registry entries should contain all the
+   information that GSS_Inquire_name_attribute() may return about the
+   given name attributes and their OIDs:
+
+   o  a name attribute OID (this is a unique key)
+
+   o  a name attribute symbolic name, starting with "GSS_C_NA_" (this is
+      a unique key)
+
+   o  a brief description, in English
+
+   o  whether the attribute is useful as the subject of access control
+      list entries
+
+   o  whether the attribute is useful as an indicator of trust
+
+   o  an optional normative reference to documentation for the given
+      name attribute
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 16]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+   The allocation and registration policy should be first come, first
+   served.  Registry entries' OIDs need not be based on the base OID
+   given above.
+
+
+16.  Security Considerations
+
+   <TBA>
+
+   [In particular, the status of a name attribute as "authenticated" vs.
+   "asserted" requires close review, particularly with respect to PKIX
+   certificate extensions.]
+
+   [Also, we need to work out the security considerations of (and
+   possibly remove) negative attributes.]
+
+17.  Normative References
+
+   [I-D.GSS-NAMING]
+              Hartman, S., "Desired Enhancements to GSSAPI Naming",
+              draft-ietf-kitten-gss-naming-01.txt (work in progress),
+              February 2005.
+
+   [I-D.ietf-krb-wg-kerberos-clarifications]
+              Neuman, C., "The Kerberos Network Authentication Service
+              (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work
+              in progress), September 2004.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+
+
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 17]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 18]
+
+Internet-Draft          GSS-API Naming Extensions           October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 17, 2006                [Page 19]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-01.txt
new file mode 100644
index 00000000000..99676165ded
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-01.txt
@@ -0,0 +1,505 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+                  A PRF API extension for the GSS-API
+                  draft-ietf-kitten-gssapi-prf-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   Generic Security Service Applicatoin Programming Interface (GSS-API)
+   for keying application protocols given an established GSS-API
+   security context.  The primary intended use of this function is to
+   key secure session layers that don't or cannot use GSS-API
+   per-message MIC (message integrity check) and wrap tokens for session
+   protection.
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
+   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  8
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
+       Intellectual Property and Copyright Statements . . . . . . . .  9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+2.  Introduction
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+   To address this need we define a pseudo-random function (PRF)
+   extension to the GSS-API.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+3.  GSS_Pseudo_random()
+
+   Inputs:
+
+   o  context CONTEXT handle,
+   o  prf_in OCTET STRING,
+   o  desired_output_len INTEGER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  prf_out OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
+      this function.
+   o  GSS_S_FAILURE indicates failure or lack of support; the minor
+      status code may provide additional information.
+
+   This function applies the established context's mechanism's keyed PRF
+   function to the input data (prf_in), keyed with key material
+   associated with the given security context and outputs the resulting
+   octet string (prf_out) of desired_output_len length.
+
+   The output string of this function MUST be a pseudo-random function
+   [GGM1][GGM2] of the input keyed with key material from the
+   established security context -- the chances of getting the same
+   output given different input parameters should be exponentially
+   small.
+
+   This function, applied to the same inputs by an initiator and
+   acceptor using the same established context, MUST produce the *same
+   results* for both, the initiator and acceptor, even if called
+   multiple times for the same context.
+
+   Mechanisms MAY limit the output of the PRF according, possibly in
+   ways related to the types of cryptographic keys available for the PRF
+   function, thus the prf_out output of GSS_Pseudo_random() MAY be
+   smaller than requested.
+
+3.1  C-Bindings
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32			*minor_status,
+     gss_ctx_id_t			context,
+     const gss_buffer_t		prf_in,
+     ssize_t		desired_output_len,
+     gss_buffer_t		prf_out
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+4.  Security Considerations
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+5.  References
+
+5.1  Normative References
+
+   [GGM1]     Goldreich, O., Goldwasser, S. and S. Micali, "How to
+              Construct Random Functions", October 1986.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+5.2  Informative References
+
+   [GGM2]     Goldreich, O., Goldwasser, S. and S. Micali, "On the
+              Cryptographic Applications of Random Functions", 1985.
+
+   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
new file mode 100644
index 00000000000..9afd512d260
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
@@ -0,0 +1,505 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+                  A PRF API extension for the GSS-API
+                  draft-ietf-kitten-gssapi-prf-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   Generic Security Service Applicatoin Programming Interface (GSS-API)
+   for keying application protocols given an established GSS-API
+   security context.  The primary intended use of this function is to
+   key secure session layers that don't or cannot use GSS-API
+   per-message MIC (message integrity check) and wrap tokens for session
+   protection.
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
+   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  8
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
+       Intellectual Property and Copyright Statements . . . . . . . .  9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+2.  Introduction
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+   To address this need we define a pseudo-random function (PRF)
+   extension to the GSS-API.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+3.  GSS_Pseudo_random()
+
+   Inputs:
+
+   o  context CONTEXT handle,
+   o  prf_in OCTET STRING,
+   o  desired_output_len INTEGER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  prf_out OCTET STRING
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
+      this function or, if the security context is not fully
+      established, that the context is not ready to compute the PRF.
+   o  GSS_S_FAILURE indicates failure or lack of support; the minor
+      status code may provide additional information.
+
+   This function applies the established context's mechanism's keyed PRF
+   function to the input data (prf_in), keyed with key material
+   associated with the given security context and outputs the resulting
+   octet string (prf_out) of desired_output_len length.
+
+   The output string of this function MUST be a pseudo-random function
+   [GGM1][GGM2] of the input keyed with key material from the
+   established security context -- the chances of getting the same
+   output given different input parameters should be exponentially
+   small.
+
+   This function, applied to the same inputs by an initiator and
+   acceptor using the same established context, MUST produce the *same
+   results* for both, the initiator and acceptor, even if called
+   multiple times for the same context.
+
+   Mechanisms MAY limit the output of the PRF according, possibly in
+   ways related to the types of cryptographic keys available for the PRF
+   function, thus the prf_out output of GSS_Pseudo_random() MAY be
+   smaller than requested.
+
+   Mechanisms may be able to compute PRFs with security contexts that
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+   are not fully established, therefore applications MAY call
+   GSS_Pseudo_random() with such security contexts.  Such mechanisms
+   MUST return GSS_S_UNAVAILABLE when called on to compute a PRF given a
+   security context that is not fully established and also not ready for
+   PRF computation.  Mechanisms that allow for PRF computation prior to
+   full security context establishment MUST use the same PRF and key
+   material, for any given security context, both, before and after full
+   context establishment, and the PRF and key material negotiation MUT
+   be authenticated when the security context is fully established.
+
+3.1  C-Bindings
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32			*minor_status,
+     gss_ctx_id_t			context,
+     const gss_buffer_t		prf_in,
+     ssize_t		desired_output_len,
+     gss_buffer_t		prf_out
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+4.  Security Considerations
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+   Some mechanisms may support the GSS PRF function with security
+   contexts that are not fully established, but applications MUST assume
+   that authentication, mutual or otherwise, has not completed until the
+   security context is fully established
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+5.  References
+
+5.1  Normative References
+
+   [GGM1]     Goldreich, O., Goldwasser, S. and S. Micali, "How to
+              Construct Random Functions", October 1986.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+5.2  Informative References
+
+   [GGM2]     Goldreich, O., Goldwasser, S. and S. Micali, "On the
+              Cryptographic Applications of Random Functions", 1985.
+
+   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-03.txt
new file mode 100644
index 00000000000..97687b332df
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-03.txt
@@ -0,0 +1,446 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: November 13, 2005                                  May 12, 2005
+
+
+                  A PRF API extension for the GSS-API
+                  draft-ietf-kitten-gssapi-prf-03.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on November 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   Generic Security Service Application Programming Interface (GSS-API)
+   for keying application protocols given an established GSS-API
+   security context.  The primary intended use of this function is to
+   key secure session layers that don't or cannot use GSS-API per-
+   message MIC (message integrity check) and wrap tokens for session
+   protection.
+
+
+
+
+
+Williams                Expires November 13, 2005               [Page 1]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  3
+   2.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.2 Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  7
+   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  7
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
+       Intellectual Property and Copyright Statements . . . . . . . .  8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires November 13, 2005               [Page 2]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+1.  Introduction
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+   To address this need we define a pseudo-random function (PRF)
+   extension to the GSS-API.
+
+1.1  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 [RFC2119].
+
+2.  GSS_Pseudo_random()
+
+   Inputs:
+
+
+   o  context CONTEXT handle,
+
+   o  prf_key INTEGER,
+
+   o  prf_in OCTET STRING,
+
+   o  desired_output_len INTEGER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  prf_out OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+
+
+
+
+Williams                Expires November 13, 2005               [Page 3]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+
+   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
+      this function or, if the security context is not fully
+      established, that the context is not ready to compute the PRF with
+      the given prf_key, or that the given prf_key is not available.
+
+   o  GSS_S_FAILURE indicates general failure, possibly due to the given
+      input data being too large or of zero length, or due to the
+      desired_output_len being zero; the minor status code may provide
+      additional information.
+
+   This function applies the established context's mechanism's keyed
+   pseudo-random function (PRF) to the input data ('prf_in'), keyed with
+   key material associated with the given security context and
+   identified by 'prf_key', and outputs the resulting octet string
+   ('prf_out') of desired_output_len length.
+
+   The minimum input data length is one octet.
+
+   Mechanisms MUST be able to consume all the provided prf_in input data
+   that is 2^14 or fewer octets.
+
+   If a mechanism cannot consume as much input data as provided by the
+   caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
+
+   The minimum desired_output_len is one.
+
+   Mechanisms MUST be able to output at least up to 2^14 octets.
+
+   If the implementation cannot produce the desired output due to lack
+   of resources then it MUST output what it can and still return
+   GSS_S_COMPLETE.
+
+   The prf_key can take on the following values: GSS_C_PRF_KEY_FULL,
+   GSS_C_PRF_KEY_PARTIAL or mechanism-specific values, if any.  This
+   parameter is intended to distinguish between the best cryptographic
+   keys that may be available only after full security context
+   establishment and keys that may be available prior to full security
+   context establishment.  For some mechanisms, or contexts, those two
+   prf_key values MAY refer to the same cryptographic keys; for
+   mechanisms like the Kerberos V GSS-API mechanism [RFC1964] where one
+   peer may assert a key that may be considered better than the others
+   they MAY be different keys.
+
+   GSS_C_PRF_KEY_PARTIAL corresponds to a key that would be have been
+   used while the security context was partially established, even if it
+
+
+
+Williams                Expires November 13, 2005               [Page 4]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+   is fully established when GSS_Pseudo_random() is actually called.
+   Mechanism-specific prf_key values are intended to refer to any other
+   keys that may be available.
+
+   The GSS_C_PRF_KEY_FULL value corresponds to the best key available
+   for fully-established security contexts.
+
+   GSS_Pseudo_random() has the following properties:
+
+   o  its output string MUST be a pseudo-random function [GGM1] [GGM2]
+      of the input keyed with key material from the given security
+      context -- the chances of getting the same output given different
+      input parameters should be exponentially small.
+
+   o  when successfully applied to the same inputs by an initiator and
+      acceptor using the same security context, it MUST produce the
+      _same results_ for both, the initiator and acceptor, even if
+      called multiple times (as long as the security context is not
+      expired).
+
+   o  upon full establishment of a security context all cryptographic
+      keys and/or negotiations used for computing the PRF with any
+      prf_key MUST be authenticated (mutually, if mutual authentication
+      is in effect for the given security context).
+
+   o  the outputs of the mechanism's GSS_Pseudo_random() (for different
+      inputs) and its per-message tokens for the given security context
+      MUST be "cryptographically separate;" in other words, it must not
+      be feasible to recover key material for one mechanism operation or
+      transform its tokens and PRF outputs from one to the other given
+      only said tokens and PRF outputs.  [This is a fancy way of saying
+      that key derivation and strong cryptographic operations and
+      constructions must be used.]
+
+   o  as implied by the above requirement, it MUST NOT be possible to
+      access any raw keys of a security context through
+      GSS_Pseudo_random(), no matter what inputs are given.
+
+   Mechanisms MAY limit the output of the PRF, possibly in ways related
+   to the types of cryptographic keys available for the PRF function,
+   thus the prf_out output of GSS_Pseudo_random() MAY be smaller than
+   requested.
+
+2.1  C-Bindings
+
+   #define GSS_C_PRF_KEY_FULL 0
+   #define GSS_C_PRF_KEY_PARTIAL 1
+
+
+
+
+Williams                Expires November 13, 2005               [Page 5]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32                     *minor_status,
+     gss_ctx_id_t                  context,
+     int                           prf_key,
+     const gss_buffer_t            prf_in,
+     ssize_t                       desired_output_len,
+     gss_buffer_t                  prf_out
+   );
+
+   Additional major status codes for the C-bindings:
+
+   o  GSS_S_CALL_INACCESSIBLE_READ
+
+   o  GSS_S_CALL_INACCESSIBLE_WRITE
+
+   See [RFC2744].
+
+2.2  Java Bindings
+
+   For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf':
+
+   public static final int GSS_C_PRF_KEY_FULL = 0
+   public static final int GSS_C_PRF_KEY_PARTIAL = 1
+
+   public byte[] prf(int prf_key, byte inBuf[], int outlen)
+      throws GSSException
+
+   See [RFC2853].
+
+3.  IANA Considerations
+
+   This document has no IANA considerations currently.  If and when a
+   relevant IANA registry of GSS-API symbols is created then the generic
+   and language-specific function names, constant names and constant
+   values described above should be added to such a registry.
+
+4.  Security Considerations
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   authenticated session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+   Some mechanisms may support the GSS PRF function with security
+   contexts that are not fully established, but applications MUST assume
+   that authentication, mutual or otherwise, has not completed until the
+
+
+
+Williams                Expires November 13, 2005               [Page 6]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+   security context is fully established.
+
+   Callers of GSS_Pseudo_random() should avoid accidentally calling it
+   with the same inputs.  One useful technique is to prepend to the
+   prf_in input string, by convention, a string indicating the intended
+   purpose of the PRF output in such a way that unique contexts in which
+   the function is called yield unique inputs to it.
+
+5.  References
+
+5.1  Normative References
+
+   [GGM1]     Goldreich, O., Goldwasser, S., and S. Micali, "How to
+              Construct Random Functions", October 1986.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC2853]  Kabat, J. and M. Upadhyay, "Generic Security Service API
+              Version 2 : Java Bindings", RFC 2853, June 2000.
+
+5.2  Informative References
+
+   [GGM2]     Goldreich, O., Goldwasser, S., and S. Micali, "On the
+              Cryptographic Applications of Random Functions", 1985.
+
+   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+Williams                Expires November 13, 2005               [Page 7]
+
+Internet-Draft       A PRF Extension for the GSS-API            May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires November 13, 2005               [Page 8]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-04.txt
new file mode 100644
index 00000000000..8a3bb4d344b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-prf-04.txt
@@ -0,0 +1,505 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 15, 2005                                 June 13, 2005
+
+
+                  A PRF API extension for the GSS-API
+                  draft-ietf-kitten-gssapi-prf-04.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on December 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   Generic Security Service Application Programming Interface (GSS-API)
+   for keying application protocols given an established GSS-API
+   security context.  The primary intended use of this function is to
+   key secure session layers that don't or cannot use GSS-API per-
+   message MIC (message integrity check) and wrap tokens for session
+   protection.
+
+
+
+
+
+Williams                Expires December 15, 2005               [Page 1]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  3
+   2.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.2 Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  7
+   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  7
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
+       Intellectual Property and Copyright Statements . . . . . . . .  9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires December 15, 2005               [Page 2]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+1.  Introduction
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+   To address this need we define a pseudo-random function (PRF)
+   extension to the GSS-API.
+
+1.1  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 [RFC2119].
+
+2.  GSS_Pseudo_random()
+
+   Inputs:
+
+
+   o  context CONTEXT handle,
+
+   o  prf_key INTEGER,
+
+   o  prf_in OCTET STRING,
+
+   o  desired_output_len INTEGER
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  prf_out OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+
+
+
+
+Williams                Expires December 15, 2005               [Page 3]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+
+   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
+      this function or, if the security context is not fully
+      established, that the context is not ready to compute the PRF with
+      the given prf_key, or that the given prf_key is not available.
+
+   o  GSS_S_FAILURE indicates general failure, possibly due to the given
+      input data being too large or of zero length, or due to the
+      desired_output_len being zero; the minor status code may provide
+      additional information.
+
+   This function applies the established context's mechanism's keyed
+   pseudo-random function (PRF) to the input data ('prf_in'), keyed with
+   key material associated with the given security context and
+   identified by 'prf_key', and outputs the resulting octet string
+   ('prf_out') of desired_output_len length.
+
+   The minimum input data length is one octet.
+
+   Mechanisms MUST be able to consume all the provided prf_in input data
+   that is 2^14 or fewer octets.
+
+   If a mechanism cannot consume as much input data as provided by the
+   caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
+
+   The minimum desired_output_len is one.
+
+   Mechanisms MUST be able to output at least up to 2^14 octets.
+
+   If the implementation cannot produce the desired output due to lack
+   of resources then it MUST output what it can and still return
+   GSS_S_COMPLETE.
+
+   The prf_key can take on the following values: GSS_C_PRF_KEY_FULL,
+   GSS_C_PRF_KEY_PARTIAL or mechanism-specific values, if any.  This
+   parameter is intended to distinguish between the best cryptographic
+   keys that may be available only after full security context
+   establishment and keys that may be available prior to full security
+   context establishment.  For some mechanisms, or contexts, those two
+   prf_key values MAY refer to the same cryptographic keys; for
+   mechanisms like the Kerberos V GSS-API mechanism [RFC1964] where one
+   peer may assert a key that may be considered better than the others
+   they MAY be different keys.
+
+   GSS_C_PRF_KEY_PARTIAL corresponds to a key that would be have been
+   used while the security context was partially established, even if it
+
+
+
+Williams                Expires December 15, 2005               [Page 4]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+   is fully established when GSS_Pseudo_random() is actually called.
+   Mechanism-specific prf_key values are intended to refer to any other
+   keys that may be available.
+
+   The GSS_C_PRF_KEY_FULL value corresponds to the best key available
+   for fully-established security contexts.
+
+   GSS_Pseudo_random() has the following properties:
+
+   o  its output string MUST be a pseudo-random function [GGM1] [GGM2]
+      of the input keyed with key material from the given security
+      context -- the chances of getting the same output given different
+      input parameters should be exponentially small.
+
+   o  when successfully applied to the same inputs by an initiator and
+      acceptor using the same security context, it MUST produce the
+      _same results_ for both, the initiator and acceptor, even if
+      called multiple times (as long as the security context is not
+      expired).
+
+   o  upon full establishment of a security context all cryptographic
+      keys and/or negotiations used for computing the PRF with any
+      prf_key MUST be authenticated (mutually, if mutual authentication
+      is in effect for the given security context).
+
+   o  the outputs of the mechanism's GSS_Pseudo_random() (for different
+      inputs) and its per-message tokens for the given security context
+      MUST be "cryptographically separate;" in other words, it must not
+      be feasible to recover key material for one mechanism operation or
+      transform its tokens and PRF outputs from one to the other given
+      only said tokens and PRF outputs.  [This is a fancy way of saying
+      that key derivation and strong cryptographic operations and
+      constructions must be used.]
+
+   o  as implied by the above requirement, it MUST NOT be possible to
+      access any raw keys of a security context through
+      GSS_Pseudo_random(), no matter what inputs are given.
+
+   Mechanisms MAY limit the output of the PRF, possibly in ways related
+   to the types of cryptographic keys available for the PRF function,
+   thus the prf_out output of GSS_Pseudo_random() MAY be smaller than
+   requested.
+
+2.1  C-Bindings
+
+   #define GSS_C_PRF_KEY_FULL 0
+   #define GSS_C_PRF_KEY_PARTIAL 1
+
+
+
+
+Williams                Expires December 15, 2005               [Page 5]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32                     *minor_status,
+     gss_ctx_id_t                  context,
+     int                           prf_key,
+     const gss_buffer_t            prf_in,
+     ssize_t                       desired_output_len,
+     gss_buffer_t                  prf_out
+   );
+
+   Additional major status codes for the C-bindings:
+
+   o  GSS_S_CALL_INACCESSIBLE_READ
+
+   o  GSS_S_CALL_INACCESSIBLE_WRITE
+
+   See [RFC2744].
+
+2.2  Java Bindings
+
+   For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf':
+
+   public static final int GSS_C_PRF_KEY_FULL = 0
+   public static final int GSS_C_PRF_KEY_PARTIAL = 1
+
+   public byte[] prf(int prf_key, byte inBuf[], int outlen)
+      throws GSSException
+
+   See [RFC2853].
+
+3.  IANA Considerations
+
+   This document has no IANA considerations currently.  If and when a
+   relevant IANA registry of GSS-API symbols is created then the generic
+   and language-specific function names, constant names and constant
+   values described above should be added to such a registry.
+
+4.  Security Considerations
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   authenticated session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+   Some mechanisms may support the GSS PRF function with security
+   contexts that are not fully established, but applications MUST assume
+   that authentication, mutual or otherwise, has not completed until the
+
+
+
+Williams                Expires December 15, 2005               [Page 6]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+   security context is fully established.
+
+   Callers of GSS_Pseudo_random() should avoid accidentally calling it
+   with the same inputs.  One useful technique is to prepend to the
+   prf_in input string, by convention, a string indicating the intended
+   purpose of the PRF output in such a way that unique contexts in which
+   the function is called yield unique inputs to it.
+
+   Pseudo-random functions are, by their nature, capable of producing
+   only limited amounts of cryptographically secure output.  The exact
+   amount of output that one can safely use, unfortunately, varies from
+   one PRF to another (which prevents us from recommending specific
+   numbers).  Because of this we recommend that unless you really know
+   what you are doing (i.e. you are a cryptographer and are qualified to
+   pass judgement on cryptographic functions in areas of period,
+   presence of short cycles, etc), you limit the amount of the PRF
+   output used to the necessary minimum.
+
+5.  References
+
+5.1  Normative References
+
+   [GGM1]     Goldreich, O., Goldwasser, S., and S. Micali, "How to
+              Construct Random Functions", October 1986.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC2853]  Kabat, J. and M. Upadhyay, "Generic Security Service API
+              Version 2 : Java Bindings", RFC 2853, June 2000.
+
+5.2  Informative References
+
+   [GGM2]     Goldreich, O., Goldwasser, S., and S. Micali, "On the
+              Cryptographic Applications of Random Functions", 1985.
+
+   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+
+
+
+Williams                Expires December 15, 2005               [Page 7]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires December 15, 2005               [Page 8]
+
+Internet-Draft       A PRF Extension for the GSS-API           June 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires December 15, 2005               [Page 9]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
new file mode 100644
index 00000000000..e5398a0a44e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
@@ -0,0 +1,560 @@
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: August 15, 2005                               February 14, 2005
+
+
+          GSS-API Extension for Storing Delegated Credentials
+               draft-ietf-kitten-gssapi-store-cred-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document defines a new function for the GSS-API which allows
+   applications to store delegated (and other) credentials in the
+   implicit GSS-API credential store.  This is needed for GSS-API
+   applications to use delegated credentials as they would use other
+   credentials.
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 1]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . .   3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .   5
+   4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   6. Security considerations  . . . . . . . . . . . . . . . . . . .   9
+   7. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .   9
+      Intellectual Property and Copyright Statements . . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 2]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 3]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+2.  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
+   [RFC2743] as well as in section 3.5 of [RFC2744].
+
+   Note to the RFC editor: please remove this note before publication.]
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change - which is precisely the raison d'etre of credential
+   delegation.  But the GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+   replace the process image obliterates the delegated credentials
+   handle.
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred() a primitive is needed which allows storing of
+   credentials in the implicit credential store.  This primitive we call
+   "GSS_Store_cred()."
+
+
+
+Williams                Expires August 15, 2005                 [Page 4]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+3.  GSS_Store_cred()
+
+   Inputs:
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+      NOT be GSS_C_NO_CREDENTIAL
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
+      store all the elements of the input_cred_handle, otherwise store
+      only the element of the corresponding mechanism
+   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
+      same principal in the credential store
+   o  default_cred BOOLEAN -- if TRUE make the stored credential
+      available as the default credential (for acquisition with
+      GSS_C_NO_NAME as the desired name or for use as
+      GSS_C_NO_CREDENTIAL)
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+      mechanism OIDs for which credential elements were successfully
+      stored
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+      kind of credential was stored (useful when the cred_usage input
+      parameter is set to INITIATE-AND-ACCEPT)
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+      stored.
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
+      expired or expired before they could be stored.
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+      available.
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+      credential could not be stored because a credential for the same
+      principal exists in the current credential store and the
+      overwrite_cred input argument was FALSE.
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+      for some other reason.  The minor status code may provide more
+      information if a non-GSS_C_NULL_OID desired_mech_element was
+      given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 5]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument, in which case the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor or both usages of the input credential may be
+   stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   Finally, if the current credential store has no default credential
+   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
+   if the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential will be
+   available for acquisition with GSS_C_NO_NAME as the desired name
+   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
+   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
+   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 6]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+4.  C-Bindings
+
+   The C-bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+
+      OM_uint32 gss_store_cred(
+         OM_uint32         *minor_status,
+         gss_cred_id_t     input_cred,
+         gss_cred_usage_t  cred_usage,
+         const gss_OID     desired_mech,
+         OM_uint32         overwrite_cred,
+         OM_uint32         default_cred,
+         gss_OID_set       *elements_stored,
+         gss_cred_usage_t  *cred_usage_stored)
+
+
+                                Figure 1
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 7]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+5.   Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+
+      /*
+       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
+       * an initiator name (hereafter, "src_name") and a delegated
+       * credential handle (hereafter "deleg_cred").>
+       *
+       * <"requested_username" is a username derived from the
+       * initiator name or explicitly requested by the initiator
+       * application.>
+       */
+      ...
+
+      if (authorize_gss_client(src_name, requested_username)) {
+         /*
+          * For Unix-type platforms this may mean calling setuid() and
+          * it may or may not also mean setting/unsetting such
+          * environment variables as KRB5CCNAME and what not.
+          */
+         if (change_user_context(requested_username))
+            (void) gss_store_creds(&minor_status, deleg_cred,
+   				GSS_C_INITIATE, actual_mech,
+   				0, 1, NULL, NULL);
+         }
+         else ...
+      }
+      else ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 8]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+6.  Security considerations
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API
+   C-Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+7  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires August 15, 2005                 [Page 9]
+
+Internet-Draft              GSS_Store_cred()               February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires August 15, 2005                [Page 10]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt
new file mode 100644
index 00000000000..0327d87099d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt
@@ -0,0 +1,617 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+          GSS-API Extension for Storing Delegated Credentials
+               draft-ietf-kitten-gssapi-store-cred-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a new function for the GSS-API which allows
+   applications to store delegated (and other) credentials in the
+   implicit GSS-API credential store.  This is needed for GSS-API
+   applications to use delegated credentials as they would use other
+   credentials.
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
+       Intellectual Property and Copyright Statements . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+2.  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
+   [RFC2743] as well as in section 3.5 of [RFC2744].
+
+   Note to the RFC editor: please remove this note before publication.]
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change - which is precisely the raison d'etre of credential
+   delegation.  But the GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+   replace the process image obliterates the delegated credentials
+   handle.
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred() a primitive is needed which allows storing of
+   credentials in the implicit credential store.  This primitive we call
+   "GSS_Store_cred()."
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+3.  GSS_Store_cred()
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+      NOT be GSS_C_NO_CREDENTIAL
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
+      store all the elements of the input_cred_handle, otherwise store
+      only the element of the corresponding mechanism
+
+   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
+      same principal in the credential store
+
+   o  default_cred BOOLEAN -- if TRUE make the stored credential
+      available as the default credential (for acquisition with
+      GSS_C_NO_NAME as the desired name or for use as
+      GSS_C_NO_CREDENTIAL)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+      mechanism OIDs for which credential elements were successfully
+      stored
+
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+      kind of credential was stored (useful when the cred_usage input
+      parameter is set to INITIATE-AND-ACCEPT)
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+      stored.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
+      expired or expired before they could be stored.
+
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+      available.
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+      credential could not be stored because a credential for the same
+      principal exists in the current credential store and the
+      overwrite_cred input argument was FALSE.
+
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+      for some other reason.  The minor status code may provide more
+      information if a non-GSS_C_NULL_OID desired_mech_element was
+      given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument, in which case the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor or both usages of the input credential may be
+   stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   Finally, if the current credential store has no default credential
+   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
+   if the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential will be
+   available for acquisition with GSS_C_NO_NAME as the desired name
+   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
+   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
+   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+4.  C-Bindings
+
+   The C-bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+
+      OM_uint32 gss_store_cred(
+         OM_uint32         *minor_status,
+         gss_cred_id_t     input_cred,
+         gss_cred_usage_t  cred_usage,
+         const gss_OID     desired_mech,
+         OM_uint32         overwrite_cred,
+         OM_uint32         default_cred,
+         gss_OID_set       *elements_stored,
+         gss_cred_usage_t  *cred_usage_stored)
+
+
+   Figure 1
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+5.   Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+
+      /*
+       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
+       * an initiator name (hereafter, "src_name") and a delegated
+       * credential handle (hereafter "deleg_cred").>
+       *
+       * <"requested_username" is a username derived from the
+       * initiator name or explicitly requested by the initiator
+       * application.>
+       */
+      ...
+
+      if (authorize_gss_client(src_name, requested_username)) {
+         /*
+          * For Unix-type platforms this may mean calling setuid() and
+          * it may or may not also mean setting/unsetting such
+          * environment variables as KRB5CCNAME and what not.
+          */
+         if (change_user_context(requested_username))
+            (void) gss_store_creds(&minor_status, deleg_cred,
+                                   GSS_C_INITIATE, actual_mech,
+                                   0, 1, NULL, NULL);
+         }
+         else ...
+      }
+      else ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 8]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+6.  Security considerations
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API
+   C-Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+7.  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 9]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 10]
+
+Internet-Draft              GSS_Store_cred()                October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt
new file mode 100644
index 00000000000..80125f96060
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt
@@ -0,0 +1,673 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Intended status: Informational                          October 19, 2006
+Expires: April 22, 2007
+
+
+          GSS-API Extension for Storing Delegated Credentials
+               draft-ietf-kitten-gssapi-store-cred-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 22, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 1]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+Abstract
+
+   This document defines a new function for the GSS-API which allows
+   applications to store delegated (and other) credentials in the
+   implicit GSS-API credential store.  This is needed for GSS-API
+   applications to use delegated credentials as they would use other
+   credentials.
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
+       Intellectual Property and Copyright Statements . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 2]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 3]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+2.  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
+   [RFC2743] as well as in section 3.5 of [RFC2744].
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change.  The GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+   replace the process image obliterates any delegated credentials
+   handle that may exist in that process.
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred() a primitive is needed which allows storing of
+   credentials in the implicit credential store.  This primitive we call
+   "GSS_Store_cred()."
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 4]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+3.  GSS_Store_cred()
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+      NOT be GSS_C_NO_CREDENTIAL
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
+      store all the elements of the input_cred_handle, otherwise store
+      only the element of the corresponding mechanism
+
+   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
+      same principal in the credential store
+
+   o  default_cred BOOLEAN -- if TRUE make the stored credential
+      available as the default credential (for acquisition with
+      GSS_C_NO_NAME as the desired name or for use as
+      GSS_C_NO_CREDENTIAL)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+      mechanism OIDs for which credential elements were successfully
+      stored
+
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+      kind of credential was stored (useful when the cred_usage input
+      parameter is set to INITIATE-AND-ACCEPT)
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+      stored.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
+      expired or expired before they could be stored.
+
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+      available.
+
+
+
+Williams                 Expires April 22, 2007                 [Page 5]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+      credential could not be stored because a credential for the same
+      principal exists in the current credential store and the
+      overwrite_cred input argument was FALSE.
+
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+      for some other reason.  The minor status code may provide more
+      information if a non-GSS_C_NULL_OID desired_mech_element was
+      given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument, in which case the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor or both usages of the input credential may be
+   stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   Finally, if the current credential store has no default credential
+   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
+   if the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential will be
+   available for acquisition with GSS_C_NO_NAME as the desired name
+   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
+   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
+   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 6]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+4.  C-Bindings
+
+   The C-bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+
+      OM_uint32 gss_store_cred(
+         OM_uint32         *minor_status,
+         gss_cred_id_t     input_cred_handle,
+         gss_cred_usage_t  cred_usage,
+         const gss_OID     desired_mech,
+         OM_uint32         overwrite_cred,
+         OM_uint32         default_cred,
+         gss_OID_set       *elements_stored,
+         gss_cred_usage_t  *cred_usage_stored)
+
+
+                                 Figure 1
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 7]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+5.  Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+
+      /*
+       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
+       * an initiator name (hereafter, "src_name") and a delegated
+       * credential handle (hereafter "deleg_cred").>
+       *
+       * <"requested_username" is a username derived from the
+       * initiator name or explicitly requested by the initiator
+       * application.>
+       */
+      ...
+
+      if (authorize_gss_client(src_name, requested_username)) {
+         /*
+          * For Unix-type platforms this may mean calling setuid() and
+          * it may or may not also mean setting/unsetting such
+          * environment variables as KRB5CCNAME and what not -- all
+          * OS-specific details.
+          */
+         if (change_user_context(requested_username))
+            (void) gss_store_creds(&minor_status, deleg_cred,
+                                   GSS_C_INITIATE, actual_mech,
+                                   0, 1, NULL, NULL);
+         }
+         else ...
+      }
+      else ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 8]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+6.  Security considerations
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API
+   C-Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                 [Page 9]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                [Page 10]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 22, 2007                [Page 11]
+
+Internet-Draft              GSS_Store_cred()                October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Williams                 Expires April 22, 2007                [Page 12]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
new file mode 100644
index 00000000000..98da42e8762
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
@@ -0,0 +1,1121 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: July 26, 2005                                  January 25, 2005
+
+
+                         Guide to the GSS-APIv3
+              draft-ietf-kitten-gssapi-v3-guide-to-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on July 26, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
+   documents describes the extensions being proposed, the resons,
+   possible future directions, and portability, IANA and security
+   considerations.  This document does not define any protocol or
+   interface and is purely informational.
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 1]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  5
+   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  6
+   5.  Security Context Extensibility Extensions  . . . . . . . . . .  7
+   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  8
+   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . .  9
+   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 11
+   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
+   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 13
+   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 14
+   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 15
+   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 16
+   15. Portability Considerations . . . . . . . . . . . . . . . . . . 17
+   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
+       Intellectual Property and Copyright Statements . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 2]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 3]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+2.  Introduction
+
+   [NOTE: the references section is current fairly empty; the various
+   KITTEN WG work items will be added to this I-D in a subsequent
+   revision.]
+
+   Since the advent of the GSS-APIv2 it has come to be used in a number
+   of Internet (and other) protocols and a number of implementations
+   exist.  In that time implementors and protocol designers have come to
+   understand both, the GSS-API's strengths, and its shortcommings; we
+   believe now that a number of extensions to the GSS-API are needed.
+   Here these proposed extensions, forming what we may call the GSS-API
+   version 3, are described at a high-level.;
+
+   Some of these extensions are intended to facilitate further
+   extensions, so that further major revisions to the GSS-API may not be
+   necessary.  Others are intended to fill voids in the the GSS-APIv2.
+
+   The extensions being proposed are:
+      A pseudo-mechanism OID for the GSS-API itself
+      Mechanism attribute inquiry facilities
+      Security context extensibility extensions
+      Credential extensibility extensions
+      Credential export/import
+      GSS_Store_cred(), for making delegated credentials available for
+      acquisition
+      Pseudo-mechanism stacking
+      Naming extensions, to facilitate authorization by identifiers
+      other than names
+      Additional name types, specifically domain-based naming
+      A pseudo-random function interface
+      Channel bindings specifications
+      Semantic extensions relating to thread- and/or fork-safety
+      [Have I missed anything?  I have a feeling I have.  Re-keying?]
+      ...
+
+   Additionally, because we foresee future minor extensions, including,
+   specifically, extensions which may impact the various namespaces
+   associated with APIs (symbol names, constant values, class names,
+   etc...) we also propose the establishment of IANA registries for
+   these namespaces.
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 4]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+3.  A Pseudo-Mechanism OID for the GSS-API Itself
+
+   A mechanism OID is assigned to identify and refer to the GSS-API
+   iself.  This is necessary to enable the use of extended inquiry
+   interfaces to inquire about features of a GSS-API implementation
+   specifically, apart from actual mechanisms.
+
+   But also, this OID is needed for better error handling, so that minor
+   status codes produced in generic contexts that lack a mechanism OID
+   can be distinguished from minor status codes for a "default"
+   mechanism and properly displayed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 5]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+4.  Mechanism Attribute Inquiry Facilities
+
+   In the course of designing a pseudo-mechanism stacking facility, as
+   well as while considering the impact of all of these extensions on
+   portability, a need for interfaces through which to discover or
+   inquire by features provided by GSS-API mechanisms was discovered.
+
+   The proposed mechanism attribute inquiry interfaces consist of:
+      GSS_Inquire_mech_attrs_for_mech()
+      GSS_Indicate_mechs_by_mech_attrs()
+      GSS_Display_mech_attr()
+
+   These extensions facilitate portability by allowing GSS-APIv3
+   applications to discover the features provided by a given
+   implementation of the GSS-API or any mechanisms.  These extensions
+   are also useful in facilitating stackable pseudo-mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 6]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+5.  Security Context Extensibility Extensions
+
+   In order to facilitate future security context options we introduce a
+   GSS_Create_sec_context() interface that creates a security context
+   object, for use with extensions and with GSS_Init_sec_context(),
+   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
+   security contexts are in a non-established state until they are
+   established through the use of GSS_Init_sec_context() or
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 7]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+6.  Credential Extensibility Extensions
+
+   In order to facilitate future extensions to GSS credentials we
+   introduce a GSS_Create_credential(), similar to
+   GSS_Create_sec_context(), interface that creates an "empty"
+   credential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 8]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+7.  Credential Export/Import
+
+   To allow for passing of credentials between different "session
+   contexts," between different hosts, or for storage of post-dated
+   credentials, we introduce a credential export/import facility, much
+   like the security context export/import facility of the GSS-APIv2.
+
+   Together with credential extensibility and other extensions this
+   facility may allow for:
+      Credential delegation at any time
+      Post-dated credentials, and storage of the such for subsequent
+      use.
+      ...?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                  [Page 9]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+8.  GSS_Store_cred()
+
+   This extension fills a void in the GSS-APIv2 where delegated
+   credentials could not be used except in the context of the same
+   process that received them.  With this extension acceptor
+   applications can now make delegated credentials available for use,
+   with GSS_Acquire_cred() et.  al., in other process contexts.
+
+   [Manipulation of "credential stores" is (may be?) out of scope for
+   this document.]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 10]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+9.  Pseudo-Mechanism Stacking
+
+   A number of pseudo-mechanisms are being proposed which are designed
+   to "stack" atop other mechanisms.  The possiblities are many,
+   including: a compression mechanism, a perfect forward security
+   mechanism, an many others.
+
+   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
+   (SPNEGO) available.  With this proposal the mechanism taxonomy is
+   quite expanded:
+      Concrete mechanisms (e.g., the Kerberos V mechanism)
+      Composite mechanisms (a concrete mechanism composed with one or
+      more stackable pseudo-mechanisms)
+      Stackable pseudo-mechanisms
+      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
+
+   Although composed mechanisms may be made available for use by
+   GSS-APIv2 applications without any further extensions, use of
+   stackable pseudo-mechanisms can complicate mechanism negotiation;
+   additionally, discovery of mechanisms appropriate for use in one or
+   another context would require hard-coding information about them in
+   GSS-APIv2 applications.  Extensions to the GSS-APIv2 could facilitate
+   use of composite.
+
+   The mechanism attribute inquiry facilities, together with the
+   forllowing additional interfaces, provide for a complete interface to
+   mechanism composition and for managing the complexity of mechanism
+   negotiation:
+      GSS_Compose_oid()
+      GSS_Decompose_oid()
+      GSS_Release_oid()
+      GSS_Indicate_negotiable_mechs()
+      GSS_Negotiate_mechs()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 11]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+10.  Naming Extensions
+
+   Some applications make use of exported names, as produced by
+   GSS_Export_name(), to create/manage/evaluate access control lists; we
+   call this name-based authorization.
+
+   Exported names typically encode names that are meant for display to
+   humans, not internal identifiers.
+
+   In practice this creates a number of problems.  E.g., the referential
+   integrity of such access control lists is hard to maintain as
+   principals are added, removed, renamed or old principal names reused.
+
+   Additionally, some mechanisms may lack a notion of a "canonical" name
+   for some or all of their principals.  Such mechanisms cannot be used
+   by applications that rely on name-based authorization.
+
+   <Describe the proposed extensions in this area.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 12]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+11.  Additional Name Types
+
+   <Decribe domain-based names and the need for them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 13]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+12.  GSS_Pseudo_random()
+
+   <Decribe GSS_Pseudo_random() and the need for it.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 14]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+13.  Channel Bindings Specifications
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 15]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+14.  Semantic and Miscallaneous Extensions
+
+   The GSS-APIv2 specifications say nothing about the thread-safety,
+   much less the fork-safety, of the GSS-API.  Thread-safety and
+   fork-safety are, after all, platform- and/or language-specific
+   matters.  But as support for multi-threading spreads the matter of
+   thread-safety cannot be avoided.  The matter of fork-safety is
+   specific to platforms that provide a "fork()" function, or similar.
+
+   <describe the GSS-APIv3's thread-safety requirements>
+
+   <reference the portability considerations section>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 16]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+15.  Portability Considerations
+
+   The potential for additional generic, mechanism-specific, language
+   binding-specific and, most importantly, semantic extensions to the
+   GSS-APIv3 may create application portability problems.  The mechanism
+   attribute inquiry facilities of the GSS-APIv3 and the
+   pseudo-mechanism OID for the GSS-API itself double as a run-time
+   facility for discovery of feature availability.  Run-time feature
+   discovery facilities, in turn, can be used at application build-time
+   as well by building small applications to display the available
+   features.
+
+   <...>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 17]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+16.  IANA Considerations
+
+   <Describe the namespace issues associated with future minor
+   extensions to the GSS-APIv3 and the IANA registries to be created to
+   cope with them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 18]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+17.  Security Considerations
+
+   <...>
+
+18  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 19]
+
+Internet-Draft           Guide to the GSS-APIv3             January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires July 26, 2005                 [Page 20]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt
new file mode 100644
index 00000000000..b3b94a1d973
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt
@@ -0,0 +1,1233 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+                         Guide to the GSS-APIv3
+              draft-ietf-kitten-gssapi-v3-guide-to-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
+   documents describes the extensions being proposed, the resons,
+   possible future directions, and portability, IANA and security
+   considerations.  This document does not define any protocol or
+   interface and is purely informational.
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+Table of Contents
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  6
+   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  7
+   5.  Security Context Extensibility Extensions  . . . . . . . . . .  8
+   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  9
+   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . . 10
+   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 12
+   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 13
+   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 14
+   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 15
+   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 16
+   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 17
+   15. Portability Considerations . . . . . . . . . . . . . . . . . . 18
+   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
+       Intellectual Property and Copyright Statements . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+2.  Introduction
+
+   [NOTE: the references section is current fairly empty; the various
+   KITTEN WG work items will be added to this I-D in a subsequent
+   revision.]
+
+   Since the advent of the GSS-APIv2 it has come to be used in a number
+   of Internet (and other) protocols and a number of implementations
+   exist.  In that time implementors and protocol designers have come to
+   understand both, the GSS-API's strengths, and its shortcommings; we
+   believe now that a number of extensions to the GSS-API are needed.
+   Here these proposed extensions, forming what we may call the GSS-API
+   version 3, are described at a high-level.;
+
+   Some of these extensions are intended to facilitate further
+   extensions, so that further major revisions to the GSS-API may not be
+   necessary.  Others are intended to fill voids in the the GSS-APIv2.
+
+   The extensions being proposed are:
+
+      A pseudo-mechanism OID for the GSS-API itself
+
+      Mechanism attribute inquiry facilities
+
+      Security context extensibility extensions
+
+      Credential extensibility extensions
+
+      Credential export/import
+
+      GSS_Store_cred(), for making delegated credentials available for
+      acquisition
+
+      Pseudo-mechanism stacking
+
+      Naming extensions, to facilitate authorization by identifiers
+      other than names
+
+      Additional name types, specifically domain-based naming
+
+      A pseudo-random function interface
+
+      Channel bindings specifications
+
+      Semantic extensions relating to thread- and/or fork-safety
+
+      [Have I missed anything?  I have a feeling I have.  Re-keying?]
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+      ...
+
+   Additionally, because we foresee future minor extensions, including,
+   specifically, extensions which may impact the various namespaces
+   associated with APIs (symbol names, constant values, class names,
+   etc...) we also propose the establishment of IANA registries for
+   these namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+3.  A Pseudo-Mechanism OID for the GSS-API Itself
+
+   A mechanism OID is assigned to identify and refer to the GSS-API
+   iself.  This is necessary to enable the use of extended inquiry
+   interfaces to inquire about features of a GSS-API implementation
+   specifically, apart from actual mechanisms.
+
+   But also, this OID is needed for better error handling, so that minor
+   status codes produced in generic contexts that lack a mechanism OID
+   can be distinguished from minor status codes for a "default"
+   mechanism and properly displayed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+4.  Mechanism Attribute Inquiry Facilities
+
+   In the course of designing a pseudo-mechanism stacking facility, as
+   well as while considering the impact of all of these extensions on
+   portability, a need for interfaces through which to discover or
+   inquire by features provided by GSS-API mechanisms was discovered.
+
+   The proposed mechanism attribute inquiry interfaces consist of:
+
+      GSS_Inquire_mech_attrs_for_mech()
+
+      GSS_Indicate_mechs_by_mech_attrs()
+
+      GSS_Display_mech_attr()
+
+   These extensions facilitate portability by allowing GSS-APIv3
+   applications to discover the features provided by a given
+   implementation of the GSS-API or any mechanisms.  These extensions
+   are also useful in facilitating stackable pseudo-mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+5.  Security Context Extensibility Extensions
+
+   In order to facilitate future security context options we introduce a
+   GSS_Create_sec_context() interface that creates a security context
+   object, for use with extensions and with GSS_Init_sec_context(),
+   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
+   security contexts are in a non-established state until they are
+   established through the use of GSS_Init_sec_context() or
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 8]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+6.  Credential Extensibility Extensions
+
+   In order to facilitate future extensions to GSS credentials we
+   introduce a GSS_Create_credential(), similar to
+   GSS_Create_sec_context(), interface that creates an "empty"
+   credential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 9]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+7.  Credential Export/Import
+
+   To allow for passing of credentials between different "session
+   contexts," between different hosts, or for storage of post-dated
+   credentials, we introduce a credential export/import facility, much
+   like the security context export/import facility of the GSS-APIv2.
+
+   Together with credential extensibility and other extensions this
+   facility may allow for:
+
+      Credential delegation at any time
+
+      Post-dated credentials, and storage of the such for subsequent
+      use.
+
+      ...?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 10]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+8.  GSS_Store_cred()
+
+   This extension fills a void in the GSS-APIv2 where delegated
+   credentials could not be used except in the context of the same
+   process that received them.  With this extension acceptor
+   applications can now make delegated credentials available for use,
+   with GSS_Acquire_cred() et. al., in other process contexts.
+
+   [Manipulation of "credential stores" is (may be?) out of scope for
+   this document.]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 11]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+9.  Pseudo-Mechanism Stacking
+
+   A number of pseudo-mechanisms are being proposed which are designed
+   to "stack" atop other mechanisms.  The possiblities are many,
+   including: a compression mechanism, a perfect forward security
+   mechanism, an many others.
+
+   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
+   (SPNEGO) available.  With this proposal the mechanism taxonomy is
+   quite expanded:
+
+      Concrete mechanisms (e.g., the Kerberos V mechanism)
+
+      Composite mechanisms (a concrete mechanism composed with one or
+      more stackable pseudo-mechanisms)
+
+      Stackable pseudo-mechanisms
+
+      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
+
+   Although composed mechanisms may be made available for use by GSS-
+   APIv2 applications without any further extensions, use of stackable
+   pseudo-mechanisms can complicate mechanism negotiation; additionally,
+   discovery of mechanisms appropriate for use in one or another context
+   would require hard-coding information about them in GSS-APIv2
+   applications.  Extensions to the GSS-APIv2 could facilitate use of
+   composite.
+
+   The mechanism attribute inquiry facilities, together with the
+   forllowing additional interfaces, provide for a complete interface to
+   mechanism composition and for managing the complexity of mechanism
+   negotiation:
+
+      GSS_Compose_oid()
+
+      GSS_Decompose_oid()
+
+      GSS_Release_oid()
+
+      GSS_Indicate_negotiable_mechs()
+
+      GSS_Negotiate_mechs()
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 12]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+10.  Naming Extensions
+
+   Some applications make use of exported names, as produced by
+   GSS_Export_name(), to create/manage/evaluate access control lists; we
+   call this name-based authorization.
+
+   Exported names typically encode names that are meant for display to
+   humans, not internal identifiers.
+
+   In practice this creates a number of problems.  E.g., the referential
+   integrity of such access control lists is hard to maintain as
+   principals are added, removed, renamed or old principal names reused.
+
+   Additionally, some mechanisms may lack a notion of a "canonical" name
+   for some or all of their principals.  Such mechanisms cannot be used
+   by applications that rely on name-based authorization.
+
+   <Describe the proposed extensions in this area.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 13]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+11.  Additional Name Types
+
+   <Decribe domain-based names and the need for them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 14]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+12.  GSS_Pseudo_random()
+
+   <Decribe GSS_Pseudo_random() and the need for it.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 15]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+13.  Channel Bindings Specifications
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 16]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+14.  Semantic and Miscallaneous Extensions
+
+   The GSS-APIv2 specifications say nothing about the thread-safety,
+   much less the fork-safety, of the GSS-API.  Thread-safety and fork-
+   safety are, after all, platform- and/or language-specific matters.
+   But as support for multi-threading spreads the matter of thread-
+   safety cannot be avoided.  The matter of fork-safety is specific to
+   platforms that provide a "fork()" function, or similar.
+
+   <describe the GSS-APIv3's thread-safety requirements>
+
+   <reference the portability considerations section>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 17]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+15.  Portability Considerations
+
+   The potential for additional generic, mechanism-specific, language
+   binding-specific and, most importantly, semantic extensions to the
+   GSS-APIv3 may create application portability problems.  The mechanism
+   attribute inquiry facilities of the GSS-APIv3 and the pseudo-
+   mechanism OID for the GSS-API itself double as a run-time facility
+   for discovery of feature availability.  Run-time feature discovery
+   facilities, in turn, can be used at application build-time as well by
+   building small applications to display the available features.
+
+   <...>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 18]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+16.  IANA Considerations
+
+   <Describe the namespace issues associated with future minor
+   extensions to the GSS-APIv3 and the IANA registries to be created to
+   cope with them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 19]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+17.  Security Considerations
+
+   <...>
+
+18.  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 20]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 21]
+
+Internet-Draft           Guide to the GSS-APIv3             October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 22]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-01.txt
new file mode 100644
index 00000000000..a1591472109
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-01.txt
@@ -0,0 +1,393 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                draft-ietf-kitten-krb5-gssapi-prf-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V mechanism for the Generic Security Service Application
+   Programming Interface (GSS-API), based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4
+   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
+   4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+      Intellectual Property and Copyright Statements . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+2.  Kerberos V GSS Mechanism PRF
+
+   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX]
+   shall be the output of a PRF+ function based on the enctype's PRF
+   function keyed with the negotiated session key of the security
+   context and key usage X (TBD).
+
+   The security context MUST be fully established, else the mechanism
+   MUST fail with GSS_S_FAILURE as the major status code and
+   GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code.
+
+   This PRF+ MUST be keyed with a key derived, with key usage (TBD),
+   from the session used by the initiator and acceptor, after the
+   security context is fully established, to derive keys for per-message
+   tokens.  For the current Kerberos V mechanism [CFX] this means that
+   the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did
+   assert such a key, or the initiator's sub-session key otherwise.
+
+   The PRF+ function is a simple counter-based extension of the Kerberos
+   V pseudo-random function [KRB5-CRYPTO] for the enctype of the
+   security context's keys:
+
+   	PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
+
+   	Tn = pseudo-random-function(K, n || S)
+
+   	where '||' is the concatenation operator, 'n' is encoded as a
+   	network byte order 32-bit unsigned binary number, and where
+   	truncate(L, S) truncates the input octet string S to length L.
+
+   The maximum output size of the Kerberos V mechanism's GSS-API PRF
+   then is, necessarily, 2^32 octets.
+
+   Implementations MUST support output size of up to 2^14 octets at
+   least.
+
+   If the implementation cannot produce the desired output then it MUST
+   output what it can.
+
+   The minimum input octet string length that implementations MUST
+   support is also 2^14 octets.  If the input octet string is longer
+   than the maximum that an implementation can process then the
+   implementation MUST fail with GSS_S_FAILURE as the major status code
+   and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+3.  Security Considerations
+
+   Kerberos V enctypes' PRF functions use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+   Legacy Kerberos V enctypes may be weak, particularly the single-DES
+   enctypes.
+
+   See also [GSS-PRF] for generic security considerations of
+   GSS_Pseudo_random().
+
+   The computational cost of computing this PRF+ may vary depending on
+   the Kerberos V enctypes being used, but generally the computation of
+   this PRF+ gets more expensive as the input and output octet string
+   lengths grow (note that the use of a counter in the PRF+ construction
+   allows for parallelization).  This means that if an application can
+   be tricked into providing very large input octet strings and
+   requesting very long output octet strings then that may constitue a
+   denial of service attack on the application; therefore applications
+   SHOULD place appropriate limits on the size of any input octet
+   strings received from their peers without integrity protection.
+
+4  Normative References
+
+   [CFX]      Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
+              Version 5 GSS-API Mechanism: Version 2".
+
+   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
+
+   [KRB5-CRYPTO]
+              Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5".
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt
new file mode 100644
index 00000000000..6521f987525
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt
@@ -0,0 +1,393 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                draft-ietf-kitten-krb5-gssapi-prf-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V mechanism for the Generic Security Service Application
+   Programming Interface (GSS-API), based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4
+   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
+   4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+      Intellectual Property and Copyright Statements . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+2.  Kerberos V GSS Mechanism PRF
+
+   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX]
+   shall be the output of a PRF+ function based on the enctype's PRF
+   function keyed with the negotiated session key of the security
+   context and key usage X (TBD).
+
+   The security context MUST be fully established, else the mechanism
+   MUST fail with GSS_S_UNAVAILABLE as the major status code and
+   GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code.
+
+   This PRF+ MUST be keyed with a key derived, with key usage (TBD),
+   from the session used by the initiator and acceptor, after the
+   security context is fully established, to derive keys for per-message
+   tokens.  For the current Kerberos V mechanism [CFX] this means that
+   the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did
+   assert such a key, or the initiator's sub-session key otherwise.
+
+   The PRF+ function is a simple counter-based extension of the Kerberos
+   V pseudo-random function [KRB5-CRYPTO] for the enctype of the
+   security context's keys:
+
+   	PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
+
+   	Tn = pseudo-random-function(K, n || S)
+
+   	where '||' is the concatenation operator, 'n' is encoded as a
+   	network byte order 32-bit unsigned binary number, and where
+   	truncate(L, S) truncates the input octet string S to length L.
+
+   The maximum output size of the Kerberos V mechanism's GSS-API PRF
+   then is, necessarily, 2^32 octets.
+
+   Implementations MUST support output size of up to 2^14 octets at
+   least.
+
+   If the implementation cannot produce the desired output then it MUST
+   output what it can.
+
+   The minimum input octet string length that implementations MUST
+   support is also 2^14 octets.  If the input octet string is longer
+   than the maximum that an implementation can process then the
+   implementation MUST fail with GSS_S_FAILURE as the major status code
+   and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+3.  Security Considerations
+
+   Kerberos V enctypes' PRF functions use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+   Legacy Kerberos V enctypes may be weak, particularly the single-DES
+   enctypes.
+
+   See also [GSS-PRF] for generic security considerations of
+   GSS_Pseudo_random().
+
+   The computational cost of computing this PRF+ may vary depending on
+   the Kerberos V enctypes being used, but generally the computation of
+   this PRF+ gets more expensive as the input and output octet string
+   lengths grow (note that the use of a counter in the PRF+ construction
+   allows for parallelization).  This means that if an application can
+   be tricked into providing very large input octet strings and
+   requesting very long output octet strings then that may constitue a
+   denial of service attack on the application; therefore applications
+   SHOULD place appropriate limits on the size of any input octet
+   strings received from their peers without integrity protection.
+
+4  Normative References
+
+   [CFX]      Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
+              Version 5 GSS-API Mechanism: Version 2".
+
+   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
+
+   [KRB5-CRYPTO]
+              Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5".
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-03.txt
new file mode 100644
index 00000000000..b943e16728b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-03.txt
@@ -0,0 +1,334 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: November 13, 2005                                  May 12, 2005
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                draft-ietf-kitten-krb5-gssapi-prf-03.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on November 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V mechanism for the Generic Security Service Application
+   Programming Interface (GSS-API), based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+Williams                Expires November 13, 2005               [Page 1]
+
+Internet-Draft        A PRF for the Kerberos V Mech             May 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . .  3
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  5
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
+       Intellectual Property and Copyright Statements . . . . . . . .  6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires November 13, 2005               [Page 2]
+
+Internet-Draft        A PRF for the Kerberos V Mech             May 2005
+
+
+1.  Introduction
+
+   This document specifies the Kerberos V GSS-API mechanism's pseudo-
+   random function corresponding to [GSS-PRF].  The function is a "PRF+"
+   style construction.
+
+1.1  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 [RFC2119].
+
+2.  Kerberos V GSS Mechanism PRF
+
+   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism
+   [RFC1964] shall be the output of a PRF+ function based on the
+   encryption type's PRF function keyed with the negotiated session key
+   of the security context corresponding to the 'prf_key' input
+   parameter of GSS_Pseudo_random().
+
+   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
+   parameter as follows:
+
+   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
+      acceptor, if any, or the sub-session asserted by the initiator, if
+      any, or the Ticket's session key
+
+   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
+      initiator, if any, or the Ticket's session key
+
+   The PRF+ function is a simple counter-based extension of the Kerberos
+   V pseudo-random function [RFC3961] for the encryption type of the
+   security context's keys:
+
+         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
+
+         Tn = pseudo-random(K, n || S)
+
+   where '||' is the concatenation operator, 'n' is encoded as a network
+   byte order 32-bit unsigned binary number, truncate(L, S) truncates
+   the input octet string S to length L, and pseudo-random() is the
+   Kerberos V pseudo-random function [RFC3961].
+
+   The maximum output size of the Kerberos V mechanism's GSS-API PRF
+   then is, necessarily, 2^32 times the output size of the pseudo-
+   random() function for the encryption type of the given key.
+
+   When the input size is longer than 2^14 octets as per [GSS-PRF] and
+
+
+
+Williams                Expires November 13, 2005               [Page 3]
+
+Internet-Draft        A PRF for the Kerberos V Mech             May 2005
+
+
+   exceeds an implementation's resources then the mechanism MUST return
+   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
+   code.
+
+3.  IANA Considerations
+
+   This document has no IANA considerations currently.  If and when a
+   relevant IANA registry of GSS-API symbols and constants is created
+   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
+   added to such a registry.
+
+4.  Security Considerations
+
+   Kerberos V encryption types' PRF functions use a key derived from
+   contexts' session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+   Legacy Kerberos V encryption types may be weak, particularly the
+   single-DES encryption types.
+
+   See also [GSS-PRF] for generic security considerations of
+   GSS_Pseudo_random().
+
+   See also [RFC3961] for generic security considerations of the
+   Kerberos V cryptographic framework.
+
+   Care should be taken not to exceed the useful lifetime of an
+   established security context's session key's useful lifetime as
+   implementations are not required to prevent overuse of the
+   GSS_Pseudo_random() function.  This can effectively be achieved by
+   limiting the number of GSS_Pseudo_random() calls to, say, a handful
+   of calls per-security context.
+
+   Use of Ticket session keys, rather than sub-session keys, when
+   initiators and acceptors fail to assert sub-session keys, is
+   dangerous as ticket reuse can lead to key reuse, therefore initiators
+   should assert sub-session keys always, and acceptors should assert
+   sub-session keys at least when initiators fail to do so..
+
+   The computational cost of computing this PRF+ may vary depending on
+   the Kerberos V encryption types being used, but generally the
+   computation of this PRF+ gets more expensive as the input and output
+   octet string lengths grow (note that the use of a counter in the PRF+
+   construction allows for parallelization).  This means that if an
+   application can be tricked into providing very large input octet
+   strings and requesting very long output octet strings then that may
+   constitute a denial of service attack on the application; therefore
+   applications SHOULD place appropriate limits on the size of any input
+
+
+
+Williams                Expires November 13, 2005               [Page 4]
+
+Internet-Draft        A PRF for the Kerberos V Mech             May 2005
+
+
+   octet strings received from their peers without integrity protection.
+
+5.  Normative References
+
+   [CFX]      Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 GSS-API Mechanism: Version 2".
+
+   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires November 13, 2005               [Page 5]
+
+Internet-Draft        A PRF for the Kerberos V Mech             May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires November 13, 2005               [Page 6]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-04.txt
new file mode 100644
index 00000000000..f9c23fbb7d4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-04.txt
@@ -0,0 +1,337 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 15, 2005                                 June 13, 2005
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                draft-ietf-kitten-krb5-gssapi-prf-04.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on December 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V mechanism for the Generic Security Service Application
+   Programming Interface (GSS-API), based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+Williams                Expires December 15, 2005               [Page 1]
+
+Internet-Draft        A PRF for the Kerberos V Mech            June 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . .  3
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
+       Intellectual Property and Copyright Statements . . . . . . . .  6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires December 15, 2005               [Page 2]
+
+Internet-Draft        A PRF for the Kerberos V Mech            June 2005
+
+
+1.  Introduction
+
+   This document specifies the Kerberos V GSS-API mechanism's pseudo-
+   random function corresponding to [GSS-PRF].  The function is a "PRF+"
+   style construction.
+
+1.1  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 [RFC2119].
+
+2.  Kerberos V GSS Mechanism PRF
+
+   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism
+   [RFC1964] shall be the output of a PRF+ function based on the
+   encryption type's PRF function keyed with the negotiated session key
+   of the security context corresponding to the 'prf_key' input
+   parameter of GSS_Pseudo_random().
+
+   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
+   parameter as follows:
+
+   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
+      acceptor, if any, or the sub-session asserted by the initiator, if
+      any, or the Ticket's session key
+
+   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
+      initiator, if any, or the Ticket's session key
+
+   The PRF+ function is a simple counter-based extension of the Kerberos
+   V pseudo-random function [RFC3961] for the encryption type of the
+   security context's keys:
+
+         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
+
+         Tn = pseudo-random(K, n || S)
+
+   where '||' is the concatenation operator, 'n' is encoded as a network
+   byte order 32-bit unsigned binary number, truncate(L, S) truncates
+   the input octet string S to length L, and pseudo-random() is the
+   Kerberos V pseudo-random function [RFC3961].
+
+   The maximum output size of the Kerberos V mechanism's GSS-API PRF
+   then is, necessarily, 2^32 times the output size of the pseudo-
+   random() function for the encryption type of the given key.
+
+   When the input size is longer than 2^14 octets as per [GSS-PRF] and
+
+
+
+Williams                Expires December 15, 2005               [Page 3]
+
+Internet-Draft        A PRF for the Kerberos V Mech            June 2005
+
+
+   exceeds an implementation's resources then the mechanism MUST return
+   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
+   code.
+
+3.  IANA Considerations
+
+   This document has no IANA considerations currently.  If and when a
+   relevant IANA registry of GSS-API symbols and constants is created
+   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
+   added to such a registry.
+
+4.  Security Considerations
+
+   Kerberos V encryption types' PRF functions use a key derived from
+   contexts' session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+   Legacy Kerberos V encryption types may be weak, particularly the
+   single-DES encryption types.
+
+   See also [GSS-PRF] for generic security considerations of
+   GSS_Pseudo_random().
+
+   See also [RFC3961] for generic security considerations of the
+   Kerberos V cryptographic framework.
+
+   Use of Ticket session keys, rather than sub-session keys, when
+   initiators and acceptors fail to assert sub-session keys, is
+   dangerous as ticket reuse can lead to key reuse, therefore initiators
+   should assert sub-session keys always, and acceptors should assert
+   sub-session keys at least when initiators fail to do so..
+
+   The computational cost of computing this PRF+ may vary depending on
+   the Kerberos V encryption types being used, but generally the
+   computation of this PRF+ gets more expensive as the input and output
+   octet string lengths grow (note that the use of a counter in the PRF+
+   construction allows for parallelization).  This means that if an
+   application can be tricked into providing very large input octet
+   strings and requesting very long output octet strings then that may
+   constitute a denial of service attack on the application; therefore
+   applications SHOULD place appropriate limits on the size of any input
+   octet strings received from their peers without integrity protection.
+
+5.  Normative References
+
+   [CFX]      Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 GSS-API Mechanism: Version 2".
+
+
+
+
+Williams                Expires December 15, 2005               [Page 4]
+
+Internet-Draft        A PRF for the Kerberos V Mech            June 2005
+
+
+   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires December 15, 2005               [Page 5]
+
+Internet-Draft        A PRF for the Kerberos V Mech            June 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires December 15, 2005               [Page 6]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt
new file mode 100644
index 00000000000..c3c49e6d69d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt
@@ -0,0 +1,953 @@
+
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: April 19, 2006                                 October 16, 2005
+
+
+          Stackable Generic Security Service Pseudo-Mechanisms
+            draft-ietf-kitten-stackable-pseudo-mechs-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines and formalizes the concept of stackable pseudo-
+   mechanisms, and associated concept of composite mechanisms, for the
+   Generic Security Service Application Programming Interface (GSS-API),
+   as well as several utility functions.
+
+   Stackable GSS-API pseudo-mechanisms allow for the composition of new
+   mechanisms that combine features from multiple mechanisms.  Stackable
+   mechanisms that add support for Perfect Forward Security (PFS), data
+   compression, additional authentication factors, etc... are
+
+
+
+Williams                 Expires April 19, 2006                 [Page 1]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   facilitated by this document.
+
+
+Table of Contents
+
+   1.      Conventions used in this document  . . . . . . . . . . . .  3
+   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.1.    Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.      Mechanism Composition Issues . . . . . . . . . . . . . . .  4
+   4.      Mechanism Composition  . . . . . . . . . . . . . . . . . .  5
+   4.1.    Construction of Composed Mechanism OIDs  . . . . . . . . .  5
+   4.2.    Mechanism Composition Rules  . . . . . . . . . . . . . . .  6
+   4.3.    Interfacing with Composite Mechanisms  . . . . . . . . . .  7
+   4.4.    Compatibility with the Basic GSS-APIv2u1 Interfaces  . . .  7
+   4.5.    Processing of Tokens for Composite Mechanisms  . . . . . .  8
+   5.      New GSS-API Interfaces . . . . . . . . . . . . . . . . . .  8
+   5.1.    New GSS-API Function Interfaces  . . . . . . . . . . . . .  9
+   5.1.1.  GSS_Compose_oid()  . . . . . . . . . . . . . . . . . . . .  9
+   5.1.2.  GSS_Decompose_oid()  . . . . . . . . . . . . . . . . . . . 10
+   5.1.3.  GSS_Release_oid()  . . . . . . . . . . . . . . . . . . . . 10
+   5.1.4.  GSS_Indicate_negotiable_mechs()  . . . . . . . . . . . . . 11
+   5.1.5.  GSS_Negotiate_mechs()  . . . . . . . . . . . . . . . . . . 12
+   5.1.6.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
+   6.      Negotiation of Composite Mechanisms  . . . . . . . . . . . 13
+   6.1.    Negotiation of Composite Mechanisms Through SPNEGO . . . . 14
+   7.      Requirements for Mechanism Designers . . . . . . . . . . . 14
+   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 14
+   9.      Security considerations  . . . . . . . . . . . . . . . . . 14
+   10.     Normative  . . . . . . . . . . . . . . . . . . . . . . . . 15
+           Author's Address . . . . . . . . . . . . . . . . . . . . . 16
+           Intellectual Property and Copyright Statements . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 2]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+1.  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 [RFC2119].
+
+
+2.  Introduction
+
+   Recent discussions within the IETF have shown the need for a
+   refactoring of the features that GSS-API mechanisms may provide and a
+   way to compose new mechanisms from smaller components.
+
+   One way to do this is to "stack" multiple mechanisms on top of each
+   other such that the features of all of them are summed into a new,
+   composite mechanism.
+
+   One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially
+   stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not
+   conform to the stackable pseduo-mechanism framework described
+   herein).
+
+   The first truly stackable pseudo-mechanism proposed, CCM [CCM], is
+   intended for signalling, during negotiation of mechanisms, the
+   willingness of an initiator and/or acceptor to utilize channel
+   bindings
+
+   Since then other similar mechanism compositing needs and ideas have
+   come up, along with problems such as "what combinations are possible,
+   useful, reasonable and secure?"  This document addresses those
+   problems.  It introduces the concepts of stackable pseudo-mechanisms,
+   composite mechanisms and mechanism features or attributes, as well as
+   new inquiry and related interfaces to help in the mechanism
+   compositing.
+
+   (Mechanism features are more formally referred to as "mechanism
+   attributes" below.  The terms "feature" and mechanism attribute" are
+   sometimes used interchangeably.)
+
+2.1.  Glossary
+
+   Concrete GSS-API mechanism
+      A mechanism which can be used standalone.  Examples include: the
+      Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY].
+
+   GSS-API Pseudo-mechanism
+      A mechanism which uses other mechanisms in the construction of its
+      context and/or per-message tokens and security contexts.  SPNEGO
+
+
+
+Williams                 Expires April 19, 2006                 [Page 3]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+      is an example of this.
+
+   Stackable GSS-API pseudo-mechanism
+      A mechanism which uses a single other mechanism in the
+      construction of its tokens such that the OID of the composite
+      result can be constructed by prepending the OID of the stackable
+      pseudo-mechanism to the OID of the mechanism to be used by it.
+
+   Mechanism-negotiation GSS-API pseudo-mechanism
+      A GSS-API mechanism that negotiates the use of GSS-API mechanisms.
+      SPNEGO [SPNEGO] is an example of this.
+
+
+3.  Mechanism Composition Issues
+
+   Interfacing with composite mechanisms through the existing GSS-API
+   interfaces and the handling of composite mechanism tokens is
+   straightforward enough and described in Section 4.
+
+   However, the concepts of stackable and composite mechanisms do give
+   rise to several minor problems:
+
+   o  How to determine allowable combinations of mechanisms;
+   o  How to encode composite mechanism OIDs;
+   o  How to decompose the OID of a composite mechanism and process its
+      tokens properly;
+   o  Application interfacing issues such as:
+
+      *  Whether and/or which composite mechanisms should be listed by
+         GSS_Indicate_mechs();
+      *  Whether and/or which composite mechanisms not listed by
+         GSS_Indicate_mechs() may nonetheless be available for use by
+         applications and how applications can detect their
+         availability;
+      *  What additional, if any, interfaces should be provided to help
+         applications select appropriate mechanisms;
+   o
+
+      Mechanism negotiation issues (related to the application interface
+      issues listed above), such as: vspace blankLines='1'/>
+      *  Should applications advertise composite mechanisms in SPNEGO or
+         other application-specific mechanism negotiation contexts?
+      *  Or should applications implicitly advertise composite
+         mechanisms by advertising concrete and stackable pseudo-
+         mechanisms in SPNEGO or other application-specific mechanism
+         negotiation contexts?
+
+   Section 4 addresses the OID composition, decomposition and encoding
+
+
+
+Williams                 Expires April 19, 2006                 [Page 4]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   issues, as well as basic interfacing and token handling issues.
+
+   Section 5 addresses interfacing issues more generally through the
+   specification of additional, optional APIs.
+
+   Section 6 addresses mechanism negotiation issues.
+
+
+4.  Mechanism Composition
+
+   Mechanism composition by stacking pseudo-mechanisms on a concrete
+   mechanism is conceptually simple: join the OIDs of the several
+   mechanisms in question and process GSS-API tokens and routine calls
+   through the top-most pseudo-mechanism in a stack, which can then, if
+   necessary, recursively call the GSS-API to process any tokens for the
+   remainder of the stack.
+
+   Some stackable pseudo-mechanisms may do nothing more than perform
+   transformations on application data (e.g., compression); such pseudo-
+   mechanisms will generally chain the processing of tokens and routine
+   calls to the mechanisms below them in the stack.
+
+   Other stackable pseudo-mechanisms may utilize the mechanisms below
+   them only during security context setup.  For example, a stackable
+   pseudo-mechanism could perform a Diffie-Hellman key exchange and
+   authenticate it by binding a security context established with the
+   mechanism stacked below it; such a mechanism would provide its own
+   per-message tokens.
+
+4.1.  Construction of Composed Mechanism OIDs
+
+   Composition of mechanism OIDs is simple: prepend the OID of one
+   pseudo-mechanism to the OID of another mechanism (composite or
+   otherwise), but there MUST always be at least one final mechanism OID
+   and it MUST be useful standalone (i.e., it MUST NOT be a pseudo-
+   mechanism).  A composite mechanism OID forms, essentially, a stack.
+
+   The encoding of composed mechanism OIDs is not quite the
+   concatenation of the component OIDs' encodings, however.  This is
+   because the first two arcs of ASN.1 OIDs are encoded differently from
+   subsequent arcs (the first two arcs have a limited namespace and are
+   encoded as a single octet), so were composite mechanism OIDs to be
+   encoded as the concatenation of the component OIDs the result would
+   not decode as the concatenation of the component OIDs.  To avoid this
+   problem the first two arcs of each component of a composite mechanism
+   OID, other than the leading component, will be encoded as other arcs
+   would.
+
+
+
+
+Williams                 Expires April 19, 2006                 [Page 5]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   Decomposition of composite mechanism OIDs is similar, with each
+   pseudo-mechanism in the stack being able to determine the OID suffix
+   from knowledge of its own OID(s).
+
+   New pseudo-mechanisms MAY be allocated OIDs from the prefix given
+   below as follows by assignment of a sub-string of OID arcs to be
+   appended to this prefix.  This prefix OID is:
+
+   <TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA
+   TBD]
+
+   All OID allocations below this OID MUST be for stackable pseudo-
+   mechanisms and MUST consist of a single arc.  This will make it
+   possible to decompose the OIDs of composite mechanisms without
+   necessarily knowing a priori the OIDs of the component stackable
+   pseudo-mechanisms.
+
+4.2.  Mechanism Composition Rules
+
+   All new stackable pseudo-mechanisms MUST specify the rules for
+   determining whether they can stack above a given mechanism, composite
+   or otherwise.  Such rules may be based on specific mechanism
+   attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs
+   (composite and otherwise).
+
+   All stackable pseudo-mechanisms MUST have the following mechanism
+   composition rule relating to unknown mechanism attributes:
+
+   o  composition with mechanisms supporting unknown mechanism
+      attributes MUST NOT be permitted.
+
+   This rule protects against compositions which cannot be considered
+   today but which might nonetheless arise due to the introduction of
+   new mechanisms and which might turn out to be insecure or otherwise
+   undesirable.
+
+   Mechanism composition rules for stackable pseudo-mechanisms MAY and
+   SHOULD be updated as new GSS-API mechanism attributes and mechanisms
+   sporting them are introduced.  The specifications of mechanisms that
+   introduce new mechanism attributes or which otherwise should not be
+   combined with others in ways which would be permitted under existing
+   rules SHOULD also update the mechanism composition rules of affected
+   pseudo-mechanisms.
+
+   A RECOMMENDED way to describe the stacking rules for stackable
+   mechanisms is as an ordered sequence of "MAY stack above X
+   mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above
+   Z mechanism," and/or "MUST NOT stack above a mechanism with Z
+
+
+
+Williams                 Expires April 19, 2006                 [Page 6]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   mechanism feature(s)."
+
+   For example a stackable mechanism that provides its own per-msg
+   tokens and does not use the underlying mechnism's per-msg token
+   facilities might require a rule such as "MUST NOT stack above a
+   mechanism with the GSS_C_MA_COMPRESS mechanism feature."
+
+4.3.  Interfacing with Composite Mechanisms
+
+   The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or
+   provide as output the OID of any stackable pseudo-mechanism.
+   Composite mechanisms MUST be treated as concrete mechanisms by the
+   basic GSS-API interfaces [RFC2743].
+
+   Thus the way in which a composite mechanism is used by applications
+   with the basic GSS-API (version 2, update 1) is straightforward:
+   exactly as if composite mechanisms were normal GSS-API mechanisms.
+
+   This is facilitated by the fact that in all cases where the GSS-API
+   implementation might need to know how to process or create a token it
+   has the necessary contextual information, that is, the mechanism OID,
+   available and can decompose composite mechanism OIDs as necessary.
+
+   For example, for initial GSS_Init_sec_context() calls the
+   implementation knows the desired mechanism OID, and if it should be
+   left unspecified, it can pick a default mechanism given the initiator
+   credentials provided by the application (and if none are provided
+   other default mechanism and credential selections can still be made).
+   For subsequent calls to GSS_Init_sec_context() the implementation
+   knows which mechanism to use from the given [partially established]
+   security context.  Similarly for GSS_Accept_sec_context, where on
+   initial calls the mechanism OID can be determined from the given
+   initial context token's framing.
+
+   The manner in which GSS-API implementations and the various
+   mechanisms and pseudo-mechanisms interface with one another is left
+   as an excercise to implementors.
+
+4.4.  Compatibility with the Basic GSS-APIv2u1 Interfaces
+
+   In order to preserve backwards compatibility with applications that
+   use only the basic GSS-API interfaces (version 2, update 1), several
+   restrictions are imposed on the use of composite and stackable
+   pseduo-mechanisms with the basic GSS-API interfaces:
+
+   o  GSS_Indicate_mechs() MUST NOT indicate support for any stackable
+      pseduo-mechanisms under any circumstance.
+   o  GSS_Indicate_mechs() MAY indicate support for some, all or none of
+
+
+
+Williams                 Expires April 19, 2006                 [Page 7]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+      the available composite mechanisms.
+   o  Which composite mechanisms, if any, are indicated through
+      GSS_Indicate_mechs() SHOULD be configurable.
+   o  Composite mechanisms which are not indicated by
+      GSS_Indicate_mechs() MUST NOT be considered as the default
+      mechanism (GSS_C_NULL_OID) or as part of the default mechanism set
+      (GSS_C_NULL_OID_SET).
+   o  The OIDs of *stackable* (not composite) pseudo-mechanisms MUST NOT
+      be accepted as inputs or produced in the output of any of the
+      basic GSS-APIv2, update 1 API functions, except for any OID set
+      construction/iteration functions.  And, if present in any OID SET
+      input parameters of GSS-APIv2, update 1 functions, they MUST be
+      ignored.
+   o  The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only
+      be used as inputs or produced as outputs of functions whose
+      specification explicitly allows for them or which are concerned
+      with the creation/iteration of OID containters, such as OID SETs.
+
+4.5.  Processing of Tokens for Composite Mechanisms
+
+   The initial context token for any standard mechanism, including
+   mechanisms composited from standard pseudo- and concrete mechanisms,
+   MUST be encapsulated as described in section 3.1 of rfc2743
+   [RFC2743], and the OID used in that framing MUST be that of the
+   mechanism, but in the case of composite mechanisms this OID MUST be
+   the OID of the leading component of the composite mechanism.
+
+   Note that this has implications for pluggable multi-mechanism
+   implementations of the GSS-API, namely that acceptors must route
+   initial context tokens to the appropriate mechanism and they must
+   allow that mechanism to determine the composite mechanism OID (such
+   as by allowing that mechanism's GSS_Accept_sec_context() to output
+   the actual mechanism to the application.
+
+   In all other cases the mechanism that produced or is to produce a
+   given token can be determined internally through the given security
+   context.
+
+
+5.  New GSS-API Interfaces
+
+   ...
+
+   Utility functions for mechanism OID composition and decomposition are
+   given in sections 5.1.1, 5.1.2 and 5.1.3.
+
+   Two utility functions, GSS_Indicate_negotiable_mechs() and
+   GSS_Negotiate_mechs(), to aid applications in mechanism negotiation
+
+
+
+Williams                 Expires April 19, 2006                 [Page 8]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   are described in sections 5.1.4 and 5.1.5.  These two interfaces may
+   be implemented entirely in terms of the other interfaces described
+   herein.
+
+5.1.  New GSS-API Function Interfaces
+
+   Several new interfaces are given by which, for example, GSS-API
+   applications may determine what features are provided by a given
+   mechanism, what mechanisms provide what features and what
+   compositions are legal.
+
+   These new interfaces are all OPTIONAL.
+
+   In order to preserve backwards compatibility with applications that
+   do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
+   support for any stackable pseduo-mechanisms.  GSS_Indicate_mechs()
+   MAY indicate support for some, all or none of the available composite
+   mechanisms; which composite mechanisms, if any, are indicated through
+   GSS_Indicate_mechs() SHOULD be configurable.  GSS_Acquire_cred() and
+   GSS_Add_cred() MUST NOT create credentials for composite mechanisms
+   not explicitly requested or, if no desired mechanism or mechanisms
+   are given, for composite mechanisms not indicated by
+   GSS_Indicate_mechs().
+
+   Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of
+   GSS_Indicate_mechs() wherever possible.
+
+   Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine
+   what, if any, mechanisms provide a given set of features.
+
+   GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as
+   in GSS_Indicate_mechs()) the set of available mechanisms of each type
+   (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
+   mechanism and composite mechanisms).
+
+   Applications may use GSS_Inquire_mech_attrs_for_mech() to test
+   whether a given composite mechanism is available and the set of
+   features that it offers.
+
+   GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms
+   such that composite mechanisms need not be advertised but instead be
+   implied by offering stackable pseudo-mechanisms.
+
+5.1.1.  GSS_Compose_oid()
+
+   Inputs:
+   o  mech1 OBJECT IDENTIFIER, -- mechanism OID
+   o  mech2 OBJECT IDENTIFIER -- mechanism OID
+
+
+
+Williams                 Expires April 19, 2006                 [Page 9]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2
+      ({mech1 mech2})
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success.
+   o  GSS_S_BAD_MECH indicates that mech1 is not supported.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.  The minor status will be specific to mech1 and may
+      provide further information.
+
+5.1.2.  GSS_Decompose_oid()
+
+   Inputs:
+   o  input_mech OBJECT IDENTIFIER, -- mechanism OID.
+   o  mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if
+      GSS_C_NULL_OID_SET defaults to the set of stackable pseudo-
+      mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()).
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo-
+      mechanism OID.
+   o  trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed
+      from the front.
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success.
+   o  GSS_S_BAD_MECH indicates that the input_mech could not be
+      decomposed as no stackable pseudo-mechanism is available whose OID
+      is a prefix of the input_mech.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+5.1.3.  GSS_Release_oid()
+
+   The following text is adapted from the obsoleted rfc2078 [RFC2078].
+
+   Inputs:
+   o  oid OBJECT IDENTIFIER
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 10]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates successful completion
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   Allows the caller to release the storage associated with an OBJECT
+   IDENTIFIER buffer allocated by another GSS-API call, specifically
+   GSS_Compose_oid() and GSS_Decompose_oid().  This call's specific
+   behavior depends on the language and programming environment within
+   which a GSS-API implementation operates, and is therefore detailed
+   within applicable bindings specifications; in particular, this call
+   may be superfluous within bindings where memory management is
+   automatic.
+
+5.1.4.  GSS_Indicate_negotiable_mechs()
+
+   Inputs:
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential handle to be
+      used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL.
+   o  peer_type_known BOOLEAN, -- indicates whether the peer is known to
+      support or not supprot the stackable pseudo-mechanism framework.
+   o  peer_has_mech_stacking BOOLEAN -- indicates whether the peer
+      supports the stackable pseudo-mechanism framework; ignore if
+      peer_type_known is FALSE.
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer.
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success.
+   o  GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
+      expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
+      credentials could be acquired for GSS_C_NO_NAME.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   This function produces a set of mechanism OIDs, optimized for space,
+   that its caller should advertise to peers during mechanism
+   negotiation.
+
+   The output offer_mechs parameter will include all of the mechanisms
+   for which the input_cred_handle has elements (as indicated by
+   GSS_Inquire_cred()), but composite mechanisms will be included either
+   implicitly or implicitly as per the following rules:
+   o  if peer_type_known is TRUE and peer_has_mech_stacking is FALSE
+      then no composite mechanisms not indicated by GSS_Indicate_mechs()
+      will be advertised, explictly or implicitly;
+
+
+
+Williams                 Expires April 19, 2006                [Page 11]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   o  if peer_type_known is FALSE then all composite mechanisms
+      indicated by GSS_Indicate_mechs() for which input_cred_handle has
+      elements will be indicated in offer_mechs explicitly and all
+      others may be indicated in offer_mechs implicitly, by including
+      their component stackable pseduo-mechanism OIDs (see below);
+   o  if peer_type_known is TRUE and peer_has_mech_stacking is TRUE
+      composite mechanisms will generally not be advertised explicitly,
+      but will be advertised implicitly, by including their component
+      stackable pseduo-mechanism OIDs (see below); no composite
+      mechanisms will be advertised explicitly
+   o  if the input_cred_handle does not have elements for all of the
+      possible composite mechanisms that could be constructed from the
+      its elements' decomposed mechanisms, then all composite mechanisms
+      for which the input_cred_handle does have elements will be
+      advertised explicitly in offer_mechs.
+
+5.1.5.  GSS_Negotiate_mechs()
+
+   Inputs:
+   o  input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered
+      by the caller.
+   o  peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the
+      caller's peer.
+
+   Outputs:
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the
+      caller's credentials and the caller's peer.
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
+      be the empty set (GSS_C_NO_OID_SET).
+   o  GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
+      expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
+      credentials could be acquired for GSS_C_NO_NAME.
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   This function matches the mechanisms for which the caller has
+   credentials with the mechanisms offered by the caller's peer and
+   returns the set of mechanisms in common to both, accounting for any
+   composite mechanisms offered by the peer implicitly.
+
+5.1.6.  C-Bindings
+
+
+      OM_uint32 gss_compose_oid(
+
+
+
+Williams                 Expires April 19, 2006                [Page 12]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+         OM_uint32         *minor_status,
+         const gss_OID      mech1,
+         const gss_OID      mech2,
+         gss_OID           *composite);
+
+      OM_uint32 gss_decompose_oid(
+         OM_uint32         *minor_status,
+         const gss_OID      input_mech,
+         const gss_OID_set  mechs,
+         gss_OID           *lead_mech,
+         gss_OID           *trail_mech);
+
+      OM_uint32 gss_release_oid(
+         OM_uint32         *minor_status,
+         gss_OID           *oid);
+
+      OM_uint32 gss_indicate_negotiable_mechs(
+         OM_uint32                 *minor_status,
+         const gss_cred_id_t        input_cred_handle,
+         OM_uint32                  peer_type_known,
+         OM_uint32                  peer_has_mech_stacking,
+         gss_OID_set               *offer_mechs);
+
+      OM_uint32 gss_negotiate_mechs(
+         OM_uint32                 *minor_status,
+         const gss_cred_id_t        input_cred_handle,
+         const gss_OID_set          peer_mechs,
+         const gss_OID_set         *mechs);
+
+
+   Figure 1
+
+
+6.  Negotiation of Composite Mechanisms
+
+   Where GSS-API implementations do not support the stackable mechanism
+   framework interfaces applications may only negotiate explicitly from
+   a set of concrete and composite mechanism OIDs as indicated by
+   GSS_Indicate_mechs() and for which suitable credentials are
+   available.  GSS_Indicate_mechs(), as described in Section 4.4, MUST
+   NOT indicate support for individual stackable pseudo-mechanisms, so
+   there will not be any composite mechanisms implied but not explicitly
+   offered in the mechanism negotiation.
+
+   Applications that support the stackable mechanism framework SHOULD
+   use GSS_Indicate_negotiable_mechs() to construct the set of mechanism
+   OIDs to offer to their peers.  GSS_Indicate_negotiable_mechs()
+   optimizes for bandwidth consumption by using decomposed OIDs instead
+
+
+
+Williams                 Expires April 19, 2006                [Page 13]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   of composed OIDs, where possible.  See Section 5.1.4.
+
+   Peers that support the stackable mechanism framework interfaces
+   SHOULD use GSS_Negotiate_mechs() to select a mechanism as that
+   routine accounts for composite mechanisms implicit in the mechanism
+   offers.
+
+6.1.  Negotiation of Composite Mechanisms Through SPNEGO
+
+   SPNEGO applications MUST advertise either the set of mechanism OIDs
+   for which they have suitable credentials or the set of mechanism OIDs
+   produced by calling GSS_Indicate_negotiable_mechs() with the
+   available credentials and the peer_type_known parameter as FALSE.
+
+
+7.  Requirements for Mechanism Designers
+
+   Stackable pseudo-mechanisms specifications MUST:
+   o  list the set of GSS-API mechanism attributes associated with them
+   o  list their initial mechanism composition rules
+   o  specify a mechanism for updating their mechanism composition rules
+
+   All other mechanism specifications MUST:
+   o  list the set of GSS-API mechanism attributes associated with them
+
+
+8.  IANA Considerations
+
+   Allocation of arcs in the namespace of OIDs relative to the base
+   stackable pseduo-mechanism OID specified in Section 4.1 is reserved
+   to the IANA.
+
+
+9.  Security considerations
+
+   Some composite mechanisms may well not be secure.  The mechanism
+   composition rules of pseudo-mechanisms (including the default
+   composition rule given in Section 4 for unknown mechanism attributes)
+   should be used to prevent the use of unsafe composite mechanisms.
+
+   Designers of pseudo-mechanisms should study the possible combinations
+   of their mechanisms with others and design mechanism composition
+   rules accordingly.
+
+   Similarly, pseudo-mechanism designers MUST specify, and implementors
+   MUST implement, composite mechanism attribute set determination rules
+   appropriate to the subject pseduo-mechanism, as described in section
+   4.2.  Failure to do so may lead to inappropriate composite mechanisms
+
+
+
+Williams                 Expires April 19, 2006                [Page 14]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+   being deemed permissible by programmatic application of flawed
+   mechanism composition rules or to by their application with incorrect
+   mechanism attribute sets.
+
+10.  Normative
+
+   [EXTENDED-INQUIRY]
+              Williams, N., "Extended Generic Security Service Mechanism
+              Inquiry APIs",
+              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
+              progress).
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 15]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 16]
+
+Internet-Draft             Stackable GSS Mechs              October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                 Expires April 19, 2006                [Page 17]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-00.txt
new file mode 100644
index 00000000000..7b8bf821d3a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-00.txt
@@ -0,0 +1,562 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Updates: 4120 (if approved)                                K. Jaganathan
+Expires: December 5, 2006                          Microsoft Corporation
+                                                            June 3, 2006
+
+
+                     Anonymity Support for Kerberos
+                       draft-ietf-krb-wg-anon-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on December 5, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines the use of anonymous Kerberos tickets for the
+   purpose of authenticating the servers and enabling secure
+   communication between a client and a server, without identifying the
+   client to the server.
+
+
+
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 1]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
+   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  6
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  7
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
+   Intellectual Property and Copyright Statements . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 2]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+1.  Introduction
+
+   In certain situations or environments, the Kerberos [RFC4120] client
+   may wish to authenticate a server and/or protect communications
+   without revealing its own identity.  For example, consider an
+   application which provides read access to a research database, and
+   which permits queries by arbitrary requestors.  A client of such a
+   service might wish to authenticate the service, to establish trust in
+   the information received from it, but might not wish to disclose its
+   identity to the service for privacy reasons.
+
+   To accomplish this, a Kerberos mechanism is specified in this
+   document by which a client requests an anonymous ticket and use that
+   to authenticate the server and secure subsequent client-server
+   communications.  This provides Kerberos with functional equivalence
+   to TLS [RFC2246] in environments where Kerberos is a more attractive
+   authentication mechanism.
+
+   Using this mechanism, the client has to reveal its identity in its
+   initial request to its own Key Distribution Center (KDC) [RFC4120],
+   and then it can remain anonymous thereafter to KDCs on the cross-
+   realm authentication path, if any, and to the server with which it
+   communicates.
+
+
+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 [RFC2119].
+
+
+3.  Definitions
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The client's principal name is the anonymous Kerberos principal
+      name.  The anonymous Kerberos principal name is defined as
+      follows: it is a reserved Kerberos principal name as defined in
+      [KRBNAM], the name-type is KRB_NT_RESRVED [KRBNAM], and the name-
+      string is a sequence of two KerberosString components: "RESERVED",
+      "ANONYMOUS".
+
+   o  The client's realm name is the anonymous kerberos realm name.  The
+      anonymous Kerberos realm name is defined as follows: it is a
+      reserved realm name as defined in [KRBNAM] and the realm name is
+      the literal "RESERVED:ANONYMOUS".
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 3]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+   o  The authtime field in the ticket is set to the time of the ticket
+      request, not the time of the initial authentication for the
+      principal who has made the request.
+
+   o  The transited field [RFC4120] can either contain the client's
+      authentication path or contain the anonymous authentication path
+      defined as follows: the tr-type field of the transited field is
+      NO-TRANSITED-INFO (as defined later in this section) and the
+      contents field is an empty OCTET STRING.  If a TGS request
+      contains an anonymous ticket with a "normal" authentication path
+      (i.e. the transited field does not contain the anonymous
+      authentication path as defined above), then the reply ticket, if
+      any, MUST NOT contain the anonymous authentication path.  For
+      application servers, no transited policy is defined for the
+      anonymous authentication path, but all of the transited checks
+      would still apply if an anonymous ticket contains a "normal"
+      authentication path.  Note that the "normal" authentication path
+      in an anonymous ticket can be a partial path, thus it may not be
+      sufficient to identify the originating client realm.
+
+   o  It contains no information that can reveal the client's identity
+      other than, at most, the client's realm or the realm(s) on the
+      authentication path.
+
+   o  The anonymous ticket flag (as defined later in this section) is
+      set.
+
+   The anonymous ticket flag is defined as bit 14 (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(14)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   The anonymous ticket flag MUST NOT be set by implementations of this
+   specification if the ticket is not an anonymous ticket as defined in
+   this section.
+
+   The request-anonymous KDC option is defined as bit 14 (with the first
+   bit being bit 0) in the KDCOptions:
+
+           KDCOptions      ::= KerberosFlags
+             -- request-anonymous(14)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+   The anonymous transited encoding type is defined as follows:
+
+           NO-TRANSITED-INFO    0
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 4]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+   This transited encoding type indicates that there is no information
+   available about the authentication path.
+
+   Note that the server principal name and the server realm in a cross-
+   realm referral TGT are not dependent on whether the client is the
+   anonymous principal or not.
+
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the request-
+   anonymous KDC option in an AS or TGS request [RFC4120].  Note that if
+   the service ticket in the PA-TGS-REQ [RFC4120] is anonymous, the
+   request-anonymous KDC option MUST be set in the request.
+
+   When policy allows, the KDC issues an anonymous ticket.  The KDC that
+   implements this specification MUST NOT carry information that can
+   reveal the client's identity, from the TGS request into the returned
+   anonymous ticket.
+
+   It should be noted that unless otherwise specified by this document
+   the client principal name and the client realm in the Kerberos
+   messages [RFC4120] should be the client name and client realm that
+   can uniquely identify the client principal to the KDC, not the
+   anonymous client principal name and the empty realm name.  For
+   example, the client name and realm in the request body and the
+   EncKDCRepPart of the reply [RFC4120] are identifiers of the client
+   principal.  In other words, the client name and client realm in the
+   EncKDCRepPart does not match with that of the returned anonymous
+   ticket.
+
+   If either local policy prohibits issuing of anonymous tickets or it
+   is inappropriate to remove information (such as restrictions) from
+   the TGS request in order to produce an anonymous ticket, the KDC MUST
+   return an error message with the code KDC_ERR_POLICY [RFC4120].
+
+   If a client requires anonymous communication then the client should
+   check to make sure that the resulting ticket is actually anonymous by
+   checking the presence of the anonymous ticket flag.  Because KDCs
+   ignore unknown KDC options, a KDC that does not understand the
+   request-anonymous KDC option will not return an error, but will
+   instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].  The client principal name in the
+   Authenticator of the KRB_AP_REQ MUST be the anonymous client
+   principal name and the client realm of the Authenticator MUST be an
+   empty KerberosString [RFC4120].
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 5]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+   A server accepting such an anonymous service ticket may assume that
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+   Interoperability and backward-compatibility notes: the KDC is given
+   the task of rejecting a request for an anonymous ticket when the
+   anonymous ticket is not acceptable by the server.
+
+
+5.  GSS-API Implementation Notes
+
+   At the GSS-API [RFC2743] level, the use of an anonymous principal by
+   the initiator/client requires a software change of the initiator/
+   client software (to assert the "anonymous" flag when calling
+   GSS_Init_Sec_Context().
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initator/client.  The printable name is relevant for
+   the acceptor/server when performing an authorization decision based
+   on the name that pops up from GSS_Accept_Sec_Context() upon
+   successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+   reasons -- and in that case the initiator must NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   GSS-API defines name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent
+   an anonymous identity.  In addition, according to Section 2.1.1 of
+   [RFC1964] the string representation of the anonymous client principal
+   name can be "RESERVED/ANONYMOUS" or "RESERVED/
+   ANONYMOUS@RESERVED:ANONYMOUS" with the name_type
+   GSS_KRB5_NT_PRINCIPAL_NAME.  Implementations conforming to this
+   specification MUST be able to accept the GSS_C_NT_ANONYMOUS name form
+   and the GSS_KRB5_NT_PRINCIPAL_NAME name forms, and consider them
+   equivalent.
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag to GSS_Init_Sec_Context().
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 6]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+6.  Security Considerations
+
+   Since KDCs ignore unknown options [RFC4120], a client requiring
+   anonymous communication needs to make sure that the ticket is
+   actually anonymous.  A KDC that that does not understand the
+   anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal its identity to the server but its identity may be
+   revealed to the KDC of the server principal (when the server
+   principal is in a different realm than that of the client), and any
+   KDC on the cross-realm authentication path.  The Kerberos client MUST
+   verify the ticket being used are indeed anonymous before
+   communicating with the cross-realm KDC or the server, otherwise the
+   client's identity may be revealed to the server unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server principal specific policy that insure any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+
+7.  Acknowledgements
+
+   The authors would like to thank the following individuals for their
+   insightful comments and fruitful discussions: Sam Hartman, Martin
+   Rex, Nicolas Williams, Jeffery Altman, Tom Yu, Chaskiel M Grundman,
+   Love Hoernquist Aestrand, Jeffery Hutzelman, and Clifford Neuman.
+
+
+8.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+9.  Normative References
+
+   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
+              draft-ietf-krb-wg-naming, work in progress.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 7]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 8]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires December 5, 2006                [Page 9]
+
+Internet-Draft         Kerberos Anonymity Support              June 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.             Expires December 5, 2006               [Page 10]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-01.txt
new file mode 100644
index 00000000000..e1a9e9b1c3d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-01.txt
@@ -0,0 +1,617 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Updates: 4120 (if approved)                                K. Jaganathan
+Expires: January 17, 2007                          Microsoft Corporation
+                                                           July 16, 2006
+
+
+                     Anonymity Support for Kerberos
+                       draft-ietf-krb-wg-anon-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 17, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines the use of anonymous Kerberos tickets for the
+   purpose of authenticating the servers and enabling secure
+   communication between a client and a server, without identifying the
+   client to the server.
+
+
+
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 1]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
+   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 2]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+1.  Introduction
+
+   In certain situations or environments, the Kerberos [RFC4120] client
+   may wish to authenticate a server and/or protect communications
+   without revealing its own identity.  For example, consider an
+   application which provides read access to a research database, and
+   which permits queries by arbitrary requestors.  A client of such a
+   service might wish to authenticate the service, to establish trust in
+   the information received from it, but might not wish to disclose its
+   identity to the service for privacy reasons.
+
+   To accomplish this, a Kerberos mechanism is specified in this
+   document by which a client requests an anonymous ticket and use that
+   to authenticate the server and secure subsequent client-server
+   communications.  This provides Kerberos with functional equivalence
+   to TLS [RFC2246] in environments where Kerberos is a more attractive
+   authentication mechanism.
+
+   Using this mechanism, the client has to reveal its identity in its
+   initial request to its own Key Distribution Center (KDC) [RFC4120],
+   and then it can remain anonymous thereafter to KDCs on the cross-
+   realm authentication path, if any, and to the server with which it
+   communicates.
+
+
+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 [RFC2119].
+
+
+3.  Definitions
+
+   The anonymous Kerberos realm name is a reserved realm name as defined
+   in [KRBNAM] and its value is the literal "RESERVED:ANONYMOUS".
+
+   The anonymous Kerberos principal name is a reserved Kerberos
+   principal name as defined in [KRBNAM], its name-type [RFC4120] is
+   KRB_NT_RESRVED [KRBNAM], and its name-string [RFC4120] is a sequence
+   of two KerberosString components: "RESERVED", "ANONYMOUS".
+
+   In this specification, only the client name or the client realm can
+   be anonymous; the server name or the server realm can not be
+   anonymous.
+
+   The transited field [RFC4120] of a ticket is an anonymous
+   authentication path if the tr-type field of the TransitedEncoding
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 3]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+   type [RFC4120] is NO-TRANSITED-INFO and the contents field is an
+   empty OCTET STRING.
+
+           NO-TRANSITED-INFO    TBA
+
+   This transited encoding type indicates that there is no information
+   available about the authentication path.
+
+   The anonymous ticket flag is defined as bit TBA (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(TBA)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The cname field [RFC4120] contains the anonymous Kerberos
+      principal name.
+
+   o  The crealm field [RFC4120] contains either the realm name of the
+      client who made the request or the anonymous kerberos realm name,
+      based on the local policy of the KDC.
+
+   o  The transited field [RFC4120] can contain either the client's
+      "normal" authentication path according to Section 3.3.3.2 of
+      [RFC4120] or the anonymous authentication path.
+
+   o  It contains no information that can reveal the client's identity.
+      However the ticket can contain the client realm and the realms on
+      the authentication path, and the authorization data may provide
+      additional information of the client.  For example, an anonymous
+      principal that is only identifiable within a particular group of
+      users can be implemented by using authorization data.
+
+   o  The anonymous ticket flag is set.
+
+   Notes: The anonymous ticket flag MUST NOT be set by implementations
+   of this specification if the ticket is not an anonymous ticket.  The
+   server principal name and the server realm in a cross-realm referral
+   TGT are not dependent on whether the client is the anonymous
+   principal or not.
+
+   The request-anonymous KDC option is defined as bit TBA (with the
+   first bit being bit 0) in the KDCOptions:
+
+
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 4]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+           KDCOptions      ::= KerberosFlags
+             -- request-anonymous(TBA)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the request-
+   anonymous KDC option in an Authentication Exchange (AS) or Ticket
+   Granting Service (TGS) request [RFC4120].  The client can request an
+   anonymous TGT based on a normal TGT.  Note that if the ticket in the
+   PA-TGS-REQ [RFC4120] is anonymous, the request-anonymous KDC option
+   MUST be set in the request.
+
+   When propagating authorization data, care MUST be taken by the TGS to
+   ensure that the client confidentiality is not violated: the TGS MUST
+   either fail the request or remove authorization data that may reveal
+   the client's identity.  An optional authorization element unknown by
+   the TGS MUST be removed if it can be ignored (such as ones enclosed
+   in the AD-IF-RELEVANT or the AD-KDCIssued containers [RFC4120]).  The
+   TGS can strip critical unknown authorization data if such data do not
+   convey any rights based on the requesting client's identity.  Here is
+   a table of the known authorization-data elements, flagged with
+   whether they interfere with client anonymity and recommendations for
+   how to process them.
+
+         ad-type          References  Can Breach Confidentiality?
+     ------------------------------------------------------------------
+     AD-IF-RELEVANT        RFC4120     Yes, remove if unknown
+     AD-KDCIssued          RFC4120     Yes, remove if unknown
+     AD-AND-OR             RFC4120     Yes, remove if unknown
+     AD-MANDATORY-FOR-KDC  RFC4120     Yes, fail the request if unknown
+
+   If it is inappropriate to remove an authorization element from the
+   TGS request in order to produce an anonymous ticket, the KDC MUST
+   return an error message with the code KDC_ERR_POLICY [RFC4120].
+
+   When policy allows, the KDC issues an anonymous ticket.  The client
+   realm in the anonymous ticket can be the anonymous realm name based
+   on local policy.  The client name and the client realm the
+   EncKDCRepPart of the reply [RFC4120] MUST match with the
+   corresponding client name and the client realm of the anonymous reply
+   ticket.  The client then MUST use the client name and the client
+   realm returned in the EncKDCRepPart in subsequent message exchanges
+   when using that anonymous ticket.
+
+   If there is a key known by both the client and the KDC for encrypting
+   the KDC reply, the cname field in the request [RFC4120] can be
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 5]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+   anonymous.  If the client is anonymous and the KDC does not have a
+   key to encrypt the reply, the KDC MUST return an error message with
+   the code KDC_ERR_NULL_KEY [RFC4120].  For AS exchange, if the reply
+   key is selected from the client keys (for example, as described in
+   Section 3.1.3 of [RFC4120]), then the client principal MUST NOT be
+   anonymous.  The client can use the client keys to request an
+   anonymous TGT in the AS request.  The anonymous client name, for
+   example, can be used in conjunction with PKINIT [RFC4556].  An
+   anonymous PKINIT client can authenticate the KDC based on the KDC
+   certificate.  For TGS exchange, the reply key is selected according
+   to Section 3.3.3 of [RFC4120] as normal.
+
+   The KDC fills out the transited field of the anonymous ticket in the
+   reply as follows: If the service ticket in a TGS request is an
+   anonymous ticket with a "normal" authentication path, then the
+   authentication path in the reply ticket MUST also contain a "normal"
+   authentication path: the TGS MUST add the name of the previous realm.
+   However, if the service ticket in a TGS request is an anonymous
+   ticket with an anonymous authentication path, then the reply ticket
+   can contain either an anonymous authentication path or a "normal"
+   authentication path, based on the local policy of the KDC.  Thus a
+   "normal" authentication path in an anonymous ticket can be a partial
+   path: it may not include all the intermediate realms on the
+   authentication path.
+
+   The KDC fills out the authtime field of the anonymous ticket in the
+   reply as follows: If the anonymous ticket is returned in an AS
+   exchange, the authtime field of the ticket contains the request time.
+   If the anonymous ticket is returned in a TGS exchange, the authtime
+   field contains the time of the initial authentication for the
+   principal who has made the request.  An anonymous ticket can be
+   renewed, and the authtime field of a renewed ticket is the authtime
+   in the anonymous ticket that the renewed ticket was based on.
+
+   If a client requires anonymous communication then the client MUST
+   check to make sure that the ticket in the reply is actually anonymous
+   by checking the presence of the anonymous ticket flag.  Because KDCs
+   ignore unknown KDC options, a KDC that does not understand the
+   request-anonymous KDC option will not return an error, but will
+   instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].  No transited policy checking is needed for
+   the anonymous authentication path.  However, transited policy checks
+   defined in Section 2.7 of [RFC4120] would apply to an anonymous
+   ticket that contains a "normal" authentication path.
+
+   A server accepting an anonymous service ticket may assume that
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 6]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+   Interoperability and backward-compatibility notes: the KDC is given
+   the task of rejecting a request for an anonymous ticket when the
+   anonymous ticket is not acceptable by the server.
+
+
+5.  GSS-API Implementation Notes
+
+   At the GSS-API [RFC2743] level, the use of an anonymous principal by
+   the initiator/client requires a software change of the initiator/
+   client software (to assert the "anonymous" flag when calling
+   GSS_Init_Sec_Context().
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initator/client.  The printable name is relevant for
+   the acceptor/server when performing an authorization decision based
+   on the name that pops up from GSS_Accept_Sec_Context() upon
+   successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+   reasons -- and in that case the initiator must NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
+   represent the anonymous identity.  In addition, Section 2.1.1 of
+   [RFC1964] defines the single string representation of a Kerberos
+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
+   the anonymous principals, the name component within the exportable
+   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
+   name according to Section 2.1.1 of [RFC1964].  In this specification
+   only the client/initiator can be the anonymous identity.
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
+
+
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 7]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+6.  Security Considerations
+
+   Since KDCs ignore unknown options [RFC4120], a client requiring
+   anonymous communication needs to make sure that the ticket is
+   actually anonymous.  A KDC that that does not understand the
+   anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal its identity to the server but its identity may be
+   revealed to the KDC of the server principal (when the server
+   principal is in a different realm than that of the client), and any
+   KDC on the cross-realm authentication path.  The Kerberos client MUST
+   verify the ticket being used is indeed anonymous before communicating
+   with the cross-realm KDC or the server, otherwise the client's
+   identity may be revealed to the server unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server principal specific policy that insure any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+   If the KDC that issued an anonymous ticket were to maintain records
+   of the association of identities to an anonymous ticket, then someone
+   obtaining such records could breach the anonymity.  Additionally, the
+   implementation of most (for now all) KDC's respond to requests at the
+   time that they are received.  Traffic analasys on the connection to
+   the KDC will allow an attacket to match client identities to
+   anonymous tickets issued.  Because there are plaintext parts of the
+   tickets that are exposed on the wire, such matching by a third party
+   observer is relatively straigtforward.
+
+
+7.  Acknowledgements
+
+   The authors would like to thank the following individuals for their
+   insightful comments and fruitful discussions: Sam Hartman, Clifford
+   Neuman, Martin Rex, Nicolas Williams, Jeffery Altman, Tom Yu,
+   Chaskiel M Grundman, Love Hoernquist Aestrand, and Jeffery Hutzelman.
+
+
+8.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+9.  Normative References
+
+   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
+              draft-ietf-krb-wg-naming, work in progress.
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 8]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 17, 2007                [Page 9]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 17, 2007               [Page 10]
+
+Internet-Draft         Kerberos Anonymity Support              July 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.             Expires January 17, 2007               [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-02.txt
new file mode 100644
index 00000000000..406382d6b20
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-02.txt
@@ -0,0 +1,617 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Updates: 4120 (if approved)                                K. Jaganathan
+Intended status: Standards Track                   Microsoft Corporation
+Expires: April 14, 2007                                 October 11, 2006
+
+
+                     Anonymity Support for Kerberos
+                       draft-ietf-krb-wg-anon-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 14, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol for the
+   Kerberos client to authenticate the Kerberos Key Distribution Center
+   and the Kerberos server, without revealing the client's identity.
+   These extensions can be used to secure communication between the
+   anonymous client and the server.
+
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 1]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
+   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 2]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+1.  Introduction
+
+   In certain situations, the Kerberos [RFC4120] client may wish to
+   authenticate a server and/or protect communications without revealing
+   its own identity.  For example, consider an application which
+   provides read access to a research database, and which permits
+   queries by arbitrary requestors.  A client of such a service might
+   wish to authenticate the service, to establish trust in the
+   information received from it, but might not wish to disclose its
+   identity to the service for privacy reasons.
+
+   Extensions to [RFC4120] are specified in this document by which a
+   client can authenticate the KDC and request an anonymous ticket.  The
+   client can use the anonymous ticket to authenticate the server and
+   protect subsequent client-server communications.  These extensions
+   provide Kerberos with functional equivalence to Transport Layer
+   Security (TLS) [RFC4346].
+
+   By using the extensions defined in this specification, the client MAY
+   reveal its identity in its initial request to its own KDC, but it can
+   remain anonymous thereafter to KDCs on the cross-realm authentication
+   path, and to the server with which it communicates.
+
+
+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 [RFC2119].
+
+
+3.  Definitions
+
+   The anonymous Kerberos realm name is a reserved realm name based on
+   [KRBNAM].  The value is the literal "RESERVED:ANONYMOUS".
+
+   The anonymous Kerberos principal name is a reserved Kerberos
+   principal name based on [KRBNAM].  The value of the name-type field
+   is KRB_NT_RESRVED [KRBNAM], and the value of the name-string field is
+   a sequence of two KerberosString components: "RESERVED", "ANONYMOUS".
+
+   Note that in this specification, the anonymous principal name and
+   realm are only applicable to the client in Kerberos messages, the
+   server MUST NOT be anonymous in any Kerberos message.
+
+   The transited field [RFC4120] of a ticket is an anonymous
+   authentication path if the tr-type field of the TransitedEncoding
+   type [RFC4120] is NO-TRANSITED-INFO and the contents field is an
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 3]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+   empty OCTET STRING.
+
+           NO-TRANSITED-INFO    TBA
+
+   This means that no information of the authentication path is
+   disclosed.
+
+   The anonymous ticket flag is defined as bit TBA (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(TBA)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The cname field [RFC4120] contains the anonymous Kerberos
+      principal name.
+
+   o  The crealm field [RFC4120] contains either the client's realm name
+      or the anonymous realm name.
+
+   o  The transited field [RFC4120] can contain either the client's
+      authentication path as described in Section 3.3.3.2 of [RFC4120]
+      or the anonymous authentication path.
+
+   o  The anonymous ticket contains no information that can reveal the
+      client's identity.  However the ticket MAY contain the client
+      realm and the realms on the authentication path, and authorization
+      data that MAY provide information related to the client's
+      identity.  For example, an anonymous principal that is only
+      identifiable within a particular group of users can be implemented
+      using authorization data and such authorization data, if included
+      in the anonymous ticket, shall disclose the client's membership of
+      that group.
+
+   o  The anonymous ticket flag is set.
+
+   The request-anonymous KDC option is defined as bit TBA (with the
+   first bit being bit 0) in the KDCOptions:
+
+           KDCOptions      ::= KerberosFlags
+             -- request-anonymous(TBA)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 4]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the request-
+   anonymous KDC option in an Authentication Exchange (AS) or Ticket
+   Granting Service (TGS) request [RFC4120].  The client can request an
+   anonymous TGT based on a normal TGT.  If the client wishes to
+   authenticate the KDC anonymously, it sets the client name as
+   anonymous in the AS exchange and provides a PA_PK_AS_REQ pre-
+   authentication data [RFC4556] where both the signerInfos field and
+   the certificates field of the SignedData [RFC3852] of PA_PK_AS_REQ
+   are empty.  Because the anonymous client does not have an associated
+   asymmetric key pair, the client MUST use the Diffie-Hellman key
+   agreement method by filling in the Diffie-Hellman domain parameters
+   in the clientPublicValue [RFC4556].
+
+   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
+   anonymous, or if the client in the AS request is anonymous, the
+   request-anonymous KDC option MUST be set in the request.
+
+   Upon receiving the AS request with a PA_PK_AS_REQ from the anonymous
+   client, the KDC skips the checks for the client's signature and the
+   client's public key (such as the verification of the binding between
+   the client's public key and the client name), but performs otherwise-
+   applicable checks, and proceeds as normal according to [RFC4556].
+   For example, the AS MUST check if the client's Diffie-Hellman domain
+   parameters are acceptable.  The Diffie-Hellman key agreement method
+   MUST be used and the reply key is derived according to Section
+   3.2.3.1 of [RFC4556].  If the clientPublicValue is not present in the
+   request, the KDC MUST return a KRB-ERROR [RFC4120] with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
+   accompanying e-data.  The client that made the anonymous request can
+   authenticate the KDC based on the KDC's signature in the reply.  If
+   the KDC does not have an asymmetric key pair, it MAY reply
+   anonymously.  In which case, both the signerInfos field and the
+   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
+   reply are empty.  The server name in an anonymous reply contains the
+   name of the TGS.  Upon receipt of an anonymous KDC reply, the client
+   MUST reject the returned ticket if it can not authenticate the KDC
+   otherwise.
+
+   The client can use its keys to mutually authenticate with the KDC,
+   and request an anonymous TGT in the AS request.  And in that case,
+   the reply key is selected as normal according to Section 3.1.3 of
+   [RFC4120].
+
+   For the TGS exchange, the reply key is selected as normal according
+   to Section 3.3.3 of [RFC4120].
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 5]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+   When policy allows, the KDC issues an anonymous ticket.  Based on
+   local policy, the client realm in the anonymous ticket can be the
+   anonymous realm name or the realm of the KDC.  However, in all cases,
+   the client name and the client realm in the EncKDCRepPart of the
+   reply [RFC4120] MUST match with the corresponding client name and the
+   client realm of the anonymous ticket in the reply.  The client MUST
+   use the client name and the client realm returned in the
+   EncKDCRepPart in subsequent message exchanges when using the obtained
+   anonymous ticket.
+
+   During the TGS request, when propagating authorization data, care
+   MUST be taken by the TGS to ensure that the client confidentiality is
+   not violated.  The TGS MUST either fail the request or remove
+   authorization data that may reveal the client's identity.  An
+   optional authorization element unknown by the TGS MUST be removed if
+   it can be ignored (such as ones enclosed in the AD-IF-RELEVANT
+   structure).  The TGS can only strip critical unknown authorization
+   data if the ticket does not convey any rights such as those conveyed
+   by a KDCIssued authorization data element.  If a ticket contains a
+   KDCIssued authorization data element, then no other authorization
+   data elements may be removed if they could serve to limit the rights
+   conveyed by the KDCIssued element.  Here is a table of the known
+   authorization-data elements, tagged with whether they interfere with
+   client anonymity and recommendations for how to process them:
+
+         ad-type          References  Can Breach Confidentiality?
+     ------------------------------------------------------------------
+     AD-IF-RELEVANT        RFC4120     Yes, remove if unknown
+     AD-KDCIssued          RFC4120     Yes, fail the request if unknown
+     AD-AND-OR             RFC4120     Yes, remove if unknown
+     AD-MANDATORY-FOR-KDC  RFC4120     Yes, fail the request if unknown
+
+   The KDC fills out the transited field of the anonymous ticket in the
+   reply as follows: If the service ticket in a TGS request is an
+   anonymous ticket with a "normal" authentication path, then the
+   authentication path in the reply ticket MUST also contain a "normal"
+   authentication path, the TGS MUST add the name of the previous realm.
+   However, if the service ticket in a TGS request is an anonymous
+   ticket with an anonymous authentication path, then the reply ticket
+   can contain either an anonymous authentication path or a "normal"
+   authentication path, based on local policy of the KDC.  Thus a
+   "normal" authentication path in an anonymous ticket can be a partial
+   path, it may not include all the intermediate realms on the
+   authentication path.
+
+   The KDC fills out the authtime field of the anonymous ticket in the
+   reply as follows: If the anonymous ticket is returned in an AS
+   exchange, the authtime field of the ticket contains the request time.
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 6]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+   If the anonymous ticket is returned in a TGS exchange, the authtime
+   field contains the authtime of the ticket in the PA-TGS-REQ
+   [RFC4120].  An anonymous ticket can be renewed, and the authtime
+   field of a renewed ticket is the authtime in the anonymous ticket on
+   which the renewed ticket was based.
+
+   If it is inappropriate to remove an authorization element from the
+   TGS request in order to produce an anonymous ticket, the KDC MUST
+   return an error message with the code KDC_ERR_POLICY [RFC4120].
+
+   If the client is anonymous and the KDC does not have a key to encrypt
+   the reply, the KDC MUST return an error message with the code
+   KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying e-data.
+
+   If a client requires anonymous communication then the client MUST
+   check to make sure that the ticket in the reply is actually anonymous
+   by checking the presence of the anonymous ticket flag.  This is
+   because KDCs ignore unknown KDC options.  A KDC that does not
+   understand the request-anonymous KDC option will not return an error,
+   but will instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].  No transited policy checking is needed for
+   the anonymous authentication path.  However, transited policy checks
+   defined in Section 2.7 of [RFC4120] would apply to an anonymous
+   ticket that contains a "normal" authentication path.
+
+   A server accepting an anonymous service ticket may assume that
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+   Interoperability and backward-compatibility notes: the KDC is given
+   the task of rejecting a request for an anonymous ticket when the
+   anonymous ticket is not acceptable by the server.
+
+
+5.  GSS-API Implementation Notes
+
+   At the GSS-API [RFC2743] level, the use of an anonymous principal by
+   the initiator/client requires the initiator/client to assert the
+   "anonymous" flag when calling GSS_Init_Sec_Context().
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initiator/client.  The printable name is relevant
+   for the acceptor/server when performing an authorization decision
+   based on the name that pops up from GSS_Accept_Sec_Context() upon
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 7]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+   successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+   reasons -- and in that case the initiator must NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
+   represent the anonymous identity.  In addition, Section 2.1.1 of
+   [RFC1964] defines the single string representation of a Kerberos
+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
+   the anonymous principals, the name component within the exportable
+   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
+   name according to Section 2.1.1 of [RFC1964].  Note that in this
+   specification only the client/initiator can be anonymous.
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
+
+
+6.  Security Considerations
+
+   Since KDCs ignore unknown options [RFC4120], a client requiring
+   anonymous communication needs to make sure that the ticket is
+   actually anonymous.  This is because a KDC that that does not
+   understand the anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal its identity to the server but its identity may be
+   revealed to the KDC of the server principal (when the server
+   principal is in a different realm than that of the client), and any
+   KDC on the cross-realm authentication path.  The Kerberos client MUST
+   verify the ticket being used is indeed anonymous before communicating
+   with the server, otherwise the client's identity may be revealed
+   unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server principal specific policy that insure any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 8]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+   If the KDC that issued an anonymous ticket were to maintain records
+   of the association of identities to an anonymous ticket, then someone
+   obtaining such records could breach the anonymity.  Additionally, the
+   implementations of most (for now all) KDC's respond to requests at
+   the time that they are received.  Traffic analysis on the connection
+   to the KDC will allow an attacker to match client identities to
+   anonymous tickets issued.  Because there are plaintext parts of the
+   tickets that are exposed on the wire, such matching by a third party
+   observer is relatively straightforward.
+
+
+7.  Acknowledgements
+
+   Clifford Neuman contributed the core notions of this document.
+
+   Martin Rex wrote the text for GSS-API considerations.
+
+   Nicolas Williams reviewed the GSS-API considerations section and
+   suggested ideas for improvements.
+
+   Sam Hartman and Nicolas Williams were great champions of this work.
+
+   In addition, the following individuals made significant
+   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
+   Hoernquist Aestrand, and Jeffery Hutzelman.
+
+
+8.  IANA Considerations
+
+   Section 3 defines the anonymous Kerberos name and the anonymous
+   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
+   need to be updated to add references to this document.
+
+
+9.  Normative References
+
+   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
+              draft-ietf-krb-wg-naming, work in progress.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+
+
+
+Zhu, et al.              Expires April 14, 2007                 [Page 9]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+              RFC 3852, July 2004.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                [Page 10]
+
+Internet-Draft         Kerberos Anonymity Support           October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu, et al.              Expires April 14, 2007                [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-03.txt
new file mode 100644
index 00000000000..3a53f63ab60
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-03.txt
@@ -0,0 +1,617 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Updates: 4120 (if approved)                                K. Jaganathan
+Intended status: Standards Track                   Microsoft Corporation
+Expires: September 3, 2007                                 March 2, 2007
+
+
+                     Anonymity Support for Kerberos
+                       draft-ietf-krb-wg-anon-03
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on September 3, 2007.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol for the
+   Kerberos client to authenticate the Kerberos Key Distribution Center
+   and the Kerberos server, without revealing the client's identity.
+   These extensions can be used to secure communication between the
+   anonymous client and the server.
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 1]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  4
+   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 2]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+1.  Introduction
+
+   In certain situations, the Kerberos [RFC4120] client may wish to
+   authenticate a server and/or protect communications without revealing
+   its own identity.  For example, consider an application which
+   provides read access to a research database, and which permits
+   queries by arbitrary requestors.  A client of such a service might
+   wish to authenticate the service, to establish trust in the
+   information received from it, but might not wish to disclose its
+   identity to the service for privacy reasons.
+
+   Extensions to [RFC4120] are specified in this document by which a
+   client can authenticate the Key Distribution Center (KDC) and request
+   an anonymous ticket.  The client can use the anonymous ticket to
+   authenticate the server and protect subsequent client-server
+   communications.  These extensions provide Kerberos with functional
+   equivalence to Transport Layer Security (TLS) [RFC4346].
+
+   By using the extensions defined in this specification, the client may
+   reveal its identity in its initial request to its own KDC, but it can
+   remain anonymous thereafter to KDCs on the cross-realm authentication
+   path, and to the server with which it communicates.
+
+
+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 [RFC2119].
+
+
+3.  Definitions
+
+   The anonymous Kerberos realm name is defined as a well-known realm
+   name based on [KRBNAM].  The value is the literal "WELLKNOWN:
+   ANONYMOUS".  An anonymous Kerberos realm name MUST NOT be present in
+   the transited field [RFC4120] of a ticket.
+
+   The anonymous Kerberos principal name is defined as a well-known
+   Kerberos principal name based on [KRBNAM].  The value of the name-
+   type field [RFC4120] is KRB_NT_RESRVED [KRBNAM], and the value of the
+   name-string field [RFC4120] is a sequence of two KerberosString
+   components: "WELLKNOWN", "ANONYMOUS".
+
+   Note that in this specification, the anonymous principal name and
+   realm are only applicable to the client in Kerberos messages, the
+   server MUST NOT be anonymous in any Kerberos message.
+
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 3]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   The anonymous ticket flag is defined as bit TBA (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(TBA)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The cname field [RFC4120] contains the anonymous Kerberos
+      principal name.
+
+   o  The crealm field [RFC4120] contains the client's realm name, or
+      the name of the realm that issued the initial ticket for the
+      client principal, or the anonymous realm name.
+
+   o  The anonymous ticket contains no information that can reveal the
+      client's identity.  However the ticket may contain the client
+      realm, intermediate realms on the client's authentication path,
+      and authorization data that may provide information related to the
+      client's identity.  For example, an anonymous principal that is
+      identifiable only within a particular group of users can be
+      implemented using authorization data and such authorization data,
+      if included in the anonymous ticket, shall disclose the client's
+      membership of that group.
+
+   o  The anonymous ticket flag is set.
+
+   The request-anonymous KDC option is defined as bit TBA (with the
+   first bit being bit 0) in the KDCOptions:
+
+           KDCOptions      ::= KerberosFlags
+             -- request-anonymous(TBA)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+   As described in Section 4, the request-anonymous KDC option is set to
+   request an anonymous ticket.
+
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the request-
+   anonymous KDC option in an Authentication Exchange (AS) or Ticket
+   Granting Service (TGS) request [RFC4120].  The client can request an
+   anonymous Ticket Granting Ticket (TGT) based on a normal TGT.  Unless
+   otherwise specified, the client can obtain an anonymous ticket with
+   the anonymous realm name only by requesting an anonymous ticket in an
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 4]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   AS exchange with the client realm set as anonymous in the request.
+
+   If the client wishes to authenticate the KDC anonymously, it sets the
+   client name as anonymous in the AS exchange and provides a
+   PA_PK_AS_REQ pre-authentication data [RFC4556] where both the
+   signerInfos field and the certificates field of the SignedData
+   [RFC3852] of the PA_PK_AS_REQ are empty.  Because the anonymous
+   client does not have an associated asymmetric key pair, the client
+   MUST choose the Diffie-Hellman key agreement method by filling in the
+   Diffie-Hellman domain parameters in the clientPublicValue [RFC4556].
+
+   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
+   anonymous, or if the client in the AS request is anonymous, the
+   request-anonymous KDC option MUST be set in the request.  Otherwise,
+   the KDC MUST return a KRB-ERROR message with the code
+   KDC_ERR_BADOPTION [RFC4120], and there is no accompanying e-data
+   defined in this document.
+
+   Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the
+   anonymous client, the KDC processes the request according to Section
+   3.1.2 of [RFC4120].  The KDC skips the checks for the client's
+   signature and the client's public key (such as the verification of
+   the binding between the client's public key and the client name), but
+   performs otherwise-applicable checks, and proceeds as normal
+   according to [RFC4556].  For example, the AS MUST check if the
+   client's Diffie-Hellman domain parameters are acceptable.  The
+   Diffie-Hellman key agreement method MUST be used and the reply key is
+   derived according to Section 3.2.3.1 of [RFC4556].  If the
+   clientPublicValue is not present in the request, the KDC MUST return
+   a KRB-ERROR [RFC4120] with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
+   accompanying e-data.  If all goes well, an anonymous ticket is
+   generated according to Section 3.1.3 of [RFC4120] and a PA_PK_AS_REP
+   [RFC4556] pre-authentication data is included in the KDC reply
+   according to [RFC4556].  If the KDC does not have an asymmetric key
+   pair, it MAY reply anonymously or reject the authentication attempt.
+   If the KDC replies anonymously, both the signerInfos field and the
+   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
+   reply are empty.  The server name in the anonymous KDC reply contains
+   the name of the TGS.
+
+   Upon receipt of the KDC reply that contains an anonymous ticket and a
+   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
+   authenticate the KDC based on the KDC's signature in the
+   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
+   (the reply is anonymous), the client MUST reject the returned ticket
+   if it cannot authenticate the KDC otherwise.
+
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 5]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   The client can use the client keys to mutually authenticate with the
+   KDC, request an anonymous TGT in the AS request.  And in that case,
+   the reply key is selected as normal according to Section 3.1.3 of
+   [RFC4120].
+
+   For the TGS exchange, the reply key is selected as normal according
+   to Section 3.3.3 of [RFC4120].
+
+   When policy allows, the KDC issues an anonymous ticket.  Based on
+   local policy, the client realm in the anonymous ticket can be the
+   anonymous realm name or the realm of the KDC.  However, in all cases,
+   the client name and the client realm in the EncKDCRepPart of the
+   reply [RFC4120] MUST match with the corresponding client name and the
+   client realm of the anonymous ticket in the reply.  The client MUST
+   use the client name and the client realm returned in the
+   EncKDCRepPart in subsequent message exchanges when using the obtained
+   anonymous ticket.
+
+   During the TGS request, when propagating authorization data, care
+   MUST be taken by the TGS to ensure that the client confidentiality is
+   not violated.  If a anonymous ticket is returned, any authorization
+   element that may reveal the client's identity MUST be removed.  The
+   authentication attempt MUST be rejected if there is an authorization
+   element that is intended to restrict the use of the ticket thus
+   cannot be removed or the local policy prevents the removal of an
+   authorization element, and this rule MUST be applied to all critical
+   and optional authorization data.  An optional authorization element
+   unknown by the TGS MUST be removed if it does not potentially convey
+   any rights or limit the rights otherwise conveyed in the ticket.  If
+   there is a critical unknown authorization element, unless this
+   element is encapsulated in a known authorization data element
+   amending the criticality of the elements it contains, authentication
+   MUST fail according to [RFC4120].  If it is inappropriate to remove
+   an authorization element from the TGS request in order to produce an
+   anonymous ticket, the KDC MUST return an error message with the code
+   KDC_ERR_POLICY [RFC4120], and there is no accompanying e-data defined
+   in this document.
+
+   The TGS MUST add the name of the previous realm according to Section
+   3.3.3.2 of [RFC4120].  If the client's realm is the anonymous realm,
+   the abbreviation forms [RFC4120] that build on the preceding name
+   cannot be used at the start of the transited encoding.  The null-
+   subfield form (e.g., encoding ending with ",") [RFC4120] could not be
+   used next to the anonymous realm that can potentially be at the
+   beginning where the client realm is filled in.
+
+   The KDC fills out the authtime field of the anonymous ticket in the
+   reply as follows: If the anonymous ticket is returned in an AS
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 6]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   exchange, the authtime field of the ticket contains the request time.
+   If the anonymous ticket is returned in a TGS exchange, the authtime
+   field contains the authtime of the ticket in the PA-TGS-REQ pre-
+   authentication data [RFC4120].  An anonymous ticket can be renewed,
+   and the authtime field of a renewed ticket is the authtime in the
+   anonymous ticket on which the renewed ticket was based.
+
+   If the client is anonymous and the KDC does not have a key to encrypt
+   the reply (this can happen when, for example, the KDC does not
+   support PKINIT [RFC4556]), the KDC MUST return an error message with
+   the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
+   e-data defined in this document.
+
+   If a client requires anonymous communication then the client MUST
+   check to make sure that the ticket in the reply is actually anonymous
+   by checking the presence of the anonymous ticket flag.  This is
+   because KDCs ignore unknown KDC options.  A KDC that does not
+   understand the request-anonymous KDC option will not return an error,
+   but will instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].
+
+   A server accepting an anonymous service ticket may assume that
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+
+5.  GSS-API Implementation Notes
+
+   At the GSS-API [RFC2743] level, the use of an anonymous principal by
+   the initiator/client requires the initiator/client to assert the
+   "anonymous" flag when calling GSS_Init_Sec_Context().
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initiator/client.  The printable name is relevant
+   for the acceptor/server when performing an authorization decision
+   based on the initiator name that is returned from the acceptor side
+   upon the successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 7]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   reasons -- and in that case the initiator must NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
+   represent the anonymous identity.  In addition, Section 2.1.1 of
+   [RFC1964] defines the single string representation of a Kerberos
+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
+   the anonymous principals, the name component within the exportable
+   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
+   name according to Section 2.1.1 of [RFC1964].  Note that in this
+   specification only the client/initiator can be anonymous.
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
+
+
+6.  Security Considerations
+
+   Since KDCs ignore unknown options [RFC4120], a client requiring
+   anonymous communication needs to make sure that the ticket is
+   actually anonymous.  This is because a KDC that that does not
+   understand the anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal its identity to the server but its identity may be
+   revealed to the KDC of the server principal (when the server
+   principal is in a different realm than that of the client), and any
+   KDC on the cross-realm authentication path.  The Kerberos client MUST
+   verify the ticket being used is indeed anonymous before communicating
+   with the server, otherwise the client's identity may be revealed
+   unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server principal specific policy that insure any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+   If the KDC that issued an anonymous ticket were to maintain records
+   of the association of identities to an anonymous ticket, then someone
+   obtaining such records could breach the anonymity.  Additionally, the
+   implementations of most (for now all) KDC's respond to requests at
+   the time that they are received.  Traffic analysis on the connection
+   to the KDC will allow an attacker to match client identities to
+   anonymous tickets issued.  Because there are plaintext parts of the
+   tickets that are exposed on the wire, such matching by a third party
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 8]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   observer is relatively straightforward.
+
+
+7.  Acknowledgements
+
+   Clifford Neuman contributed the core notions of this document.
+
+   Ken Raeburn reviewed the document and provided suggestions for
+   improvements.
+
+   Martin Rex wrote the text for GSS-API considerations.
+
+   Nicolas Williams reviewed the GSS-API considerations section and
+   suggested ideas for improvements.
+
+   Sam Hartman and Nicolas Williams were great champions of this work.
+
+   In addition, the following individuals made significant
+   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
+   Hoernquist Aestrand, and Jeffery Hutzelman.
+
+
+8.  IANA Considerations
+
+   Section 3 defines the anonymous Kerberos name and the anonymous
+   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
+   need to be updated to add references to this document.
+
+
+9.  Normative References
+
+   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
+              draft-ietf-krb-wg-naming, work in progress.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+
+
+Zhu, et al.             Expires September 3, 2007               [Page 9]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2007              [Page 10]
+
+Internet-Draft         Kerberos Anonymity Support             March 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2007              [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-04.txt
new file mode 100644
index 00000000000..8012859a623
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-04.txt
@@ -0,0 +1,617 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Updates: 4120 (if approved)                        Microsoft Corporation
+Intended status: Standards Track                            July 7, 2007
+Expires: January 8, 2008
+
+
+                     Anonymity Support for Kerberos
+                       draft-ietf-krb-wg-anon-04
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 8, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol for the
+   Kerberos client to authenticate the Kerberos Key Distribution Center
+   and the Kerberos server, without revealing the client's identity.
+   These extensions can be used to secure communication between the
+   anonymous client and the server.
+
+
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 1]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  4
+   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 2]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+1.  Introduction
+
+   In certain situations, the Kerberos [RFC4120] client may wish to
+   authenticate a server and/or protect communications without revealing
+   its own identity.  For example, consider an application which
+   provides read access to a research database, and which permits
+   queries by arbitrary requestors.  A client of such a service might
+   wish to authenticate the service, to establish trust in the
+   information received from it, but might not wish to disclose its
+   identity to the service for privacy reasons.
+
+   Extensions to [RFC4120] are specified in this document by which a
+   client can authenticate the Key Distribution Center (KDC) and request
+   an anonymous ticket.  The client can use the anonymous ticket to
+   authenticate the server and protect subsequent client-server
+   communications.  These extensions provide Kerberos with functional
+   equivalence to Transport Layer Security (TLS) [RFC4346].
+
+   By using the extensions defined in this specification, the client may
+   reveal its identity in its initial request to its own KDC, but it can
+   remain anonymous thereafter to KDCs on the cross-realm authentication
+   path, and to the server with which it communicates.
+
+
+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 [RFC2119].
+
+
+3.  Definitions
+
+   The anonymous Kerberos realm name is defined as a well-known realm
+   name based on [KRBNAM].  The value is the literal "WELLKNOWN:
+   ANONYMOUS".  An anonymous Kerberos realm name MUST NOT be present in
+   the transited field [RFC4120] of a ticket.
+
+   The anonymous Kerberos principal name is defined as a well-known
+   Kerberos principal name based on [KRBNAM].  The value of the name-
+   type field [RFC4120] is KRB_NT_WELLKNOWN [KRBNAM], and the value of
+   the name-string field [RFC4120] is a sequence of two KerberosString
+   components: "WELLKNOWN", "ANONYMOUS".
+
+   Note that in this specification, the anonymous principal name and
+   realm are only applicable to the client in Kerberos messages, the
+   server MUST NOT be anonymous in any Kerberos message.
+
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 3]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+   The anonymous ticket flag is defined as bit 14 (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(14)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The cname field [RFC4120] contains the anonymous Kerberos
+      principal name.
+
+   o  The crealm field [RFC4120] contains the client's realm name, or
+      the name of the realm that issued the initial ticket for the
+      client principal, or the anonymous realm name.
+
+   o  The anonymous ticket contains no information that can reveal the
+      client's identity.  However the ticket may contain the client
+      realm, intermediate realms on the client's authentication path,
+      and authorization data that may provide information related to the
+      client's identity.  For example, an anonymous principal that is
+      identifiable only within a particular group of users can be
+      implemented using authorization data and such authorization data,
+      if included in the anonymous ticket, shall disclose the client's
+      membership of that group.
+
+   o  The anonymous ticket flag is set.
+
+   The anonymous KDC option is defined as bit 14 (with the first bit
+   being bit 0) in the KDCOptions:
+
+           KDCOptions      ::= KerberosFlags
+             -- anonymous(14)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+   As described in Section 4, the anonymous KDC option is set to request
+   an anonymous ticket.
+
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the
+   anonymous KDC option in an Authentication Exchange (AS) or Ticket
+   Granting Service (TGS) request [RFC4120].  The client can request an
+   anonymous Ticket Granting Ticket (TGT) based on a normal TGT.  Unless
+   otherwise specified, the client can obtain an anonymous ticket with
+   the anonymous realm name only by requesting an anonymous ticket in an
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 4]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+   AS exchange with the client realm set as anonymous in the request.
+
+   If the client wishes to authenticate the KDC anonymously, it sets the
+   client name as anonymous in the AS exchange and provides a
+   PA_PK_AS_REQ pre-authentication data [RFC4556] where both the
+   signerInfos field and the certificates field of the SignedData
+   [RFC3852] of the PA_PK_AS_REQ are empty.  Because the anonymous
+   client does not have an associated asymmetric key pair, the client
+   MUST choose the Diffie-Hellman key agreement method by filling in the
+   Diffie-Hellman domain parameters in the clientPublicValue [RFC4556].
+
+   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
+   anonymous, or if the client in the AS request is anonymous, the
+   anonymous KDC option MUST be set in the request.  Otherwise, the KDC
+   MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION
+   [RFC4120], and there is no accompanying e-data defined in this
+   document.
+
+   Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the
+   anonymous client, the KDC processes the request according to Section
+   3.1.2 of [RFC4120].  The KDC skips the checks for the client's
+   signature and the client's public key (such as the verification of
+   the binding between the client's public key and the client name), but
+   performs otherwise-applicable checks, and proceeds as normal
+   according to [RFC4556].  For example, the AS MUST check if the
+   client's Diffie-Hellman domain parameters are acceptable.  The
+   Diffie-Hellman key agreement method MUST be used and the reply key is
+   derived according to Section 3.2.3.1 of [RFC4556].  If the
+   clientPublicValue is not present in the request, the KDC MUST return
+   a KRB-ERROR [RFC4120] with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
+   accompanying e-data.  If all goes well, an anonymous ticket is
+   generated according to Section 3.1.3 of [RFC4120] and a PA_PK_AS_REP
+   [RFC4556] pre-authentication data is included in the KDC reply
+   according to [RFC4556].  If the KDC does not have an asymmetric key
+   pair, it MAY reply anonymously or reject the authentication attempt.
+   If the KDC replies anonymously, both the signerInfos field and the
+   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
+   reply are empty.  The server name in the anonymous KDC reply contains
+   the name of the TGS.
+
+   Upon receipt of the KDC reply that contains an anonymous ticket and a
+   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
+   authenticate the KDC based on the KDC's signature in the
+   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
+   (the reply is anonymous), the client MUST reject the returned ticket
+   if it cannot authenticate the KDC otherwise.
+
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 5]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+   The client can use the client keys to mutually authenticate with the
+   KDC, request an anonymous TGT in the AS request.  And in that case,
+   the reply key is selected as normal according to Section 3.1.3 of
+   [RFC4120].
+
+   For the TGS exchange, the reply key is selected as normal according
+   to Section 3.3.3 of [RFC4120].
+
+   When policy allows, the KDC issues an anonymous ticket.  Based on
+   local policy, the client realm in the anonymous ticket can be the
+   anonymous realm name or the realm of the KDC.  However, in all cases,
+   the client name and the client realm in the EncKDCRepPart of the
+   reply [RFC4120] MUST match with the corresponding client name and the
+   client realm of the anonymous ticket in the reply.  The client MUST
+   use the client name and the client realm returned in the
+   EncKDCRepPart in subsequent message exchanges when using the obtained
+   anonymous ticket.
+
+   When propagating authorization data in the ticket or in the enc-
+   authorization-data field [RFC4120] of the request, the TGS MUST
+   ensure that the client confidentiality is not violated in the
+   returned anonymous ticket.  The TGS MUST process the authorization
+   data recursively according to Section 5.2.6 of [RFC4120] beyond the
+   container levels such that all embedded authorization elements are
+   interpreted.  Identity-based authorization data SHOULD NOT be present
+   in an anonymous ticket in that it typically reveals the client's
+   identity.  The specification of a new authorization data type MUST
+   specify the processing rules of the authorization data when an
+   anonymous ticket is returned.  If there is no processing rule defined
+   for an authorization data element or the authorization data element
+   is unknown, the TGS MUST process it when an anonymous ticket is
+   returned as follows:
+
+   o  If the authorization data element may reveal the client's
+      identity, it MUST be removed unless otherwise specified.
+
+   o  If the authorization data element is intended to restrict the use
+      of the ticket or limit the rights otherwise conveyed in the
+      ticket, it cannot be removed in order to hide the client's
+      identity.  In this case, the authentication attempt MUST be
+      rejected, and the KDC MUST return an error message with the code
+      KDC_ERR_POLICY [RFC4120].  There is no accompanying e-data defined
+      in this document.  Note this is applicable to both critical and
+      optional authorization data.
+
+   o  If the authorization data element is unknown, the TGS MAY remove
+      it, or transfer it into the returned anonymous ticket, or reject
+      the authentication attempt, based on local policy for that
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 6]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+      authorization data type unless otherwise specified.  If there is
+      no policy defined for a given unknown authorization data type, the
+      authentication MUST be rejected.  The error code is KDC_ERR_POLICY
+      when the authentication is rejected.
+
+   The AD-INITIAL-VERIFIED-CAS authorization data [RFC4556] MAY be
+   removed from an anonymous ticket based on local policy of the TGS.
+
+   The TGS MUST add the name of the previous realm according to Section
+   3.3.3.2 of [RFC4120].  If the client's realm is the anonymous realm,
+   the abbreviation forms [RFC4120] that build on the preceding name
+   cannot be used at the start of the transited encoding.  The null-
+   subfield form (e.g., encoding ending with ",") [RFC4120] could not be
+   used next to the anonymous realm that can potentially be at the
+   beginning where the client realm is filled in.
+
+   The KDC fills out the authtime field of the anonymous ticket in the
+   reply as follows: If the anonymous ticket is returned in an AS
+   exchange, the authtime field of the ticket contains the request time.
+   If the anonymous ticket is returned in a TGS exchange, the authtime
+   field contains the authtime of the ticket in the PA-TGS-REQ pre-
+   authentication data [RFC4120].  An anonymous ticket can be renewed,
+   and the authtime field of a renewed ticket is the authtime in the
+   anonymous ticket on which the renewed ticket was based.
+
+   If the client is anonymous and the KDC does not have a key to encrypt
+   the reply (this can happen when, for example, the KDC does not
+   support PKINIT [RFC4556]), the KDC MUST return an error message with
+   the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
+   e-data defined in this document.
+
+   If a client requires anonymous communication then the client MUST
+   check to make sure that the ticket in the reply is actually anonymous
+   by checking the presence of the anonymous ticket flag.  This is
+   because KDCs ignore unknown KDC options.  A KDC that does not
+   understand the anonymous KDC option will not return an error, but
+   will instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].
+
+   A server accepting an anonymous service ticket may assume that
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+
+
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 7]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+5.  GSS-API Implementation Notes
+
+   At the GSS-API [RFC2743] level, the use of an anonymous principal by
+   the initiator/client requires the initiator/client to assert the
+   "anonymous" flag when calling GSS_Init_Sec_Context().
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initiator/client.  The printable name is relevant
+   for the acceptor/server when performing an authorization decision
+   based on the initiator name that is returned from the acceptor side
+   upon the successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+   reasons -- and in that case the initiator must NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
+   represent the anonymous identity.  In addition, Section 2.1.1 of
+   [RFC1964] defines the single string representation of a Kerberos
+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
+   the anonymous principals, the name component within the exportable
+   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
+   name according to Section 2.1.1 of [RFC1964].  Note that in this
+   specification only the client/initiator can be anonymous.
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
+
+
+6.  Security Considerations
+
+   Since KDCs ignore unknown options [RFC4120], a client requiring
+   anonymous communication needs to make sure that the ticket is
+   actually anonymous.  This is because a KDC that that does not
+   understand the anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal its identity to the server but its identity may be
+   revealed to the KDC of the server principal (when the server
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 8]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+   principal is in a different realm than that of the client), and any
+   KDC on the cross-realm authentication path.  The Kerberos client MUST
+   verify the ticket being used is indeed anonymous before communicating
+   with the server, otherwise the client's identity may be revealed
+   unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server principal specific policy that insure any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+   If the KDC that issued an anonymous ticket were to maintain records
+   of the association of identities to an anonymous ticket, then someone
+   obtaining such records could breach the anonymity.  Additionally, the
+   implementations of most (for now all) KDC's respond to requests at
+   the time that they are received.  Traffic analysis on the connection
+   to the KDC will allow an attacker to match client identities to
+   anonymous tickets issued.  Because there are plaintext parts of the
+   tickets that are exposed on the wire, such matching by a third party
+   observer is relatively straightforward.
+
+
+7.  Acknowledgements
+
+   JK Jaganathan helped editing early revisions of this document.
+
+   Clifford Neuman contributed the core notions of this document.
+
+   Ken Raeburn reviewed the document and provided suggestions for
+   improvements.
+
+   Martin Rex wrote the text for GSS-API considerations.
+
+   Nicolas Williams reviewed the GSS-API considerations section and
+   suggested ideas for improvements.
+
+   Sam Hartman and Nicolas Williams were great champions of this work.
+
+   In addition, the following individuals made significant
+   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
+   Hoernquist Aestrand, and Jeffery Hutzelman.
+
+
+8.  IANA Considerations
+
+   Section 3 defines the anonymous Kerberos name and the anonymous
+   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
+   need to be updated to add references to this document.
+
+
+
+Zhu & Leach              Expires January 8, 2008                [Page 9]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+9.  Normative References
+
+   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
+              draft-ietf-krb-wg-naming, work in progress.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+
+
+
+
+Zhu & Leach              Expires January 8, 2008               [Page 10]
+
+Internet-Draft         Kerberos Anonymity Support              July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu & Leach              Expires January 8, 2008               [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-10.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-10.txt
new file mode 100644
index 00000000000..7ac14a692c1
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-anon-10.txt
@@ -0,0 +1,911 @@
+

+

+NETWORK WORKING GROUP                                             L. Zhu

+Internet-Draft                                                  P. Leach

+Updates: 4120, 4121 and 4556                       Microsoft Corporation

+(if approved)                                            October 8, 2008

+Intended status: Standards Track

+Expires: April 11, 2009

+

+

+                     Anonymity Support for Kerberos

+                       draft-ietf-krb-wg-anon-10

+

+Status of this Memo

+

+   By submitting this Internet-Draft, each author represents that any

+   applicable patent or other IPR claims of which he or she is aware

+   have been or will be disclosed, and any of which he or she becomes

+   aware will be disclosed, in accordance with Section 6 of BCP 79.

+

+   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 Internet-Draft will expire on April 11, 2009.

+

+Abstract

+

+   This document defines extensions to the Kerberos protocol to allow a

+   Kerberos client to securely communicate with a Kerberos application

+   service without revealing its identity, or without revealing more

+   than its Kerberos realm.  It also defines extensions which allow a

+   Kerberos client to obtain anonymous credentials without revealing its

+   identity to the Kerberos Key Distribution Center (KDC).  This

+   document updates RFC 4120, RFC 4121, and RFC 4556.

+

+

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 1]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+Table of Contents

+

+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3

+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3

+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5

+     4.1.  Anonymity Support in AS Exchange . . . . . . . . . . . . .  5

+       4.1.1.  Anonymous PKINIT . . . . . . . . . . . . . . . . . . .  6

+     4.2.  Anonymity Support in TGS Exchange  . . . . . . . . . . . .  7

+     4.3.  Subsequent Exchanges and Protocol Actions Common to AS

+           and TGS for Anonymity Support  . . . . . . . . . . . . . .  9

+   5.  Interoperability Requirements  . . . . . . . . . . . . . . . . 10

+   6.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10

+   7.  PKINIT Client Contribution to the Ticket Session Key . . . . . 11

+     7.1.  Combinging Two protocol Keys . . . . . . . . . . . . . . . 12

+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13

+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13

+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14

+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14

+     11.2. Informative References . . . . . . . . . . . . . . . . . . 15

+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

+   Intellectual Property and Copyright Statements . . . . . . . . . . 16

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 2]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+1.  Introduction

+

+   In certain situations, the Kerberos [RFC4120] client may wish to

+   authenticate a server and/or protect communications without revealing

+   the client's own identity.  For example, consider an application

+   which provides read access to a research database, and which permits

+   queries by arbitrary requestors.  A client of such a service might

+   wish to authenticate the service, to establish trust in the

+   information received from it, but might not wish to disclose the

+   client's identity to the service for privacy reasons.

+

+   Extensions to Kerberos are specified in this document by which a

+   client can authenticate the Key Distribution Center (KDC) and request

+   an anonymous ticket.  The client can use the anonymous ticket to

+   authenticate the server and protect subsequent client-server

+   communications.

+

+   By using the extensions defined in this specification, the client can

+   request an anonymous ticket where the client may reveal the client's

+   identity to the client's own KDC, or the client can hide the client's

+   identity completely by using anonymous Public Key Cryptography for

+   Initial Authentication in Kerberos (PKINIT) as defined in

+   Section 4.1.  Using the returned anonymous ticket, the client remains

+   anonymous in subsequent Kerberos exchanges thereafter to KDCs on the

+   cross-realm authentication path, and to the server with which it

+   communicates.

+

+   In this specification, the client realm in the anonymous ticket is

+   the anonymous realm name when anonymous PKINIT is used to obtain the

+   ticket.  The client realm is the client's real realm name if the

+   client is authenticated using the client's long term keys.  Note that

+   the membership of a realm can imply a member of the community

+   represented by the realm.

+

+   The interaction with Generic Security Service Application Program

+   Interface (GSS-API) is described after the protocol description.

+

+

+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 [RFC2119].

+

+

+3.  Definitions

+

+   The anonymous Kerberos realm name is defined as a well-known realm

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 3]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   name based on [KRBNAM], and the value of this well-known realm name

+   is the literal "WELLKNOWN:ANONYMOUS".

+

+   The anonymous Kerberos principal name is defined as a well-known

+   Kerberos principal name based on [KRBNAM].  The value of the name-

+   type field is KRB_NT_WELLKNOWN [KRBNAM], and the value of the name-

+   string field is a sequence of two KerberosString components:

+   "WELLKNOWN", "ANONYMOUS".

+

+   The anonymous ticket flag is defined as bit 14 (with the first bit

+   being bit 0) in the TicketFlags:

+

+           TicketFlags     ::= KerberosFlags

+             -- anonymous(14)

+             -- TicketFlags and KerberosFlags are defined in [RFC4120]

+

+   This is a new ticket flag that is used to indicate a ticket is an

+   anonymous one.

+

+   An anonymous ticket is a ticket that has all of the following

+   properties:

+

+   o  The cname field contains the anonymous Kerberos principal name.

+

+   o  The crealm field contains the client's realm name or the anonymous

+      realm name.

+

+   o  The anonymous ticket contains no information that can reveal the

+      client's identity.  However the ticket may contain the client

+      realm, intermediate realms on the client's authentication path,

+      and authorization data that may provide information related to the

+      client's identity.  For example, an anonymous principal that is

+      identifiable only within a particular group of users can be

+      implemented using authorization data and such authorization data,

+      if included in the anonymous ticket, would disclose the client's

+      membership of that group.

+

+   o  The anonymous ticket flag is set.

+

+   The anonymous KDC option is defined as bit 14 (with the first bit

+   being bit 0) in the KDCOptions:

+

+           KDCOptions      ::= KerberosFlags

+             -- anonymous(14)

+             -- KDCOptions and KerberosFlags are defined in [RFC4120]

+

+   As described in Section 4, the anonymous KDC option is set to request

+   an anonymous ticket in an Authentication Service (AS) request or an

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 4]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   Ticket Granting Service (TGS) request.

+

+

+4.  Protocol Description

+

+   In order to request an anonymous ticket, the client sets the

+   anonymous KDC option in an AS request or an TGS request.

+

+   The rest of this section is organized as follows: it first describes

+   protocol actions specific to AS exchanges, then it describes those of

+   TGS exchange.  These are then followed by the decription of protocol

+   actions common to both AS and TGS and those in subsequent exchanges.

+

+4.1.  Anonymity Support in AS Exchange

+

+   The client requests an anonymous ticket by setting the anonymous KDC

+   option in an AS exchange.

+

+   The Kerberos client can use the client's long term keys, or the

+   client's X.509 certificates [RFC4556], or any other preauthenication

+   data, to authenticate to the KDC and requests an anonymous ticket in

+   an AS exchange where the client's identity is known to the KDC.

+

+   If the client in the AS request is anonymous, the anonymous KDC

+   option MUST be set in the request.  Otherwise, the KDC MUST return a

+   KRB-ERROR message with the code KDC_ERR_BADOPTION.

+

+   If the client is anonymous and the KDC does not have a key to encrypt

+   the reply (this can happen when, for example, the KDC does not

+   support PKINIT [RFC4556]), the KDC MUST return an error message with

+   the code KDC_ERR_NULL_KEY [RFC4120].

+

+   When policy allows, the KDC issues an anonymous ticket.  If the

+   client name in the request is the anonymous principal, the client

+   realm (crealm) in the reply is the anonymous realm, otherwise the

+   client realm is the realm of the AS.  According to [RFC4120] the

+   client name and the client realm in the EncTicketPart of the reply

+   MUST match with the corresponding client name and the client realm of

+   the anonymous ticket in the reply; the client MUST use the client

+   name and the client realm returned in the KDC-REP in subsequent

+   message exchanges when using the obtained anonymous ticket.

+

+   Care MUST be taken by the KDC not to reveal the client's identity in

+   the authorization data of the returned ticket when populating the

+   authorization data in a returned anonymous ticket.

+

+   The AD-INITIAL-VERIFIED-CAS authorization data as defined in

+   [RFC4556] contains the issuer name of the client certificate.  This

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 5]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   authorization is not applicable and MUST NOT be present in the

+   returned anonymous ticket when anonymous PKINIT is used.  When the

+   client is authenticated (i.e. anonymous PKINIT is not used), if it is

+   undesirable to disclose such information about the client's identity,

+   the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be removed from

+   the returned anonymous ticket.

+

+   The client can use the client keys to mutually authenticate with the

+   KDC, request an anonymous TGT in the AS request.  And in that case,

+   the reply key is selected as normal according to Section 3.1.3 of

+   [RFC4120].

+

+4.1.1.  Anonymous PKINIT

+

+   This sub-section defines anonymity PKINIT.

+

+   As described earlier in this section, the client can request an

+   anonymous ticket by authenticating to the KDC using the client's

+   identity; alternatively without revealing the client's identity to

+   the KDC, the Kerberos client can request an anonymous ticket as

+   follows: the client sets the client name as the anonymous principal

+   in the AS exchange and provides a PA_PK_AS_REQ pre-authentication

+   data [RFC4556] where both the signerInfos field and the certificates

+   field of the SignedData [RFC3852] of the PA_PK_AS_REQ are empty.

+   Because the anonymous client does not have an associated asymmetric

+   key pair, the client MUST choose the Diffie-Hellman key agreement

+   method by filling in the Diffie-Hellman domain parameters in the

+   clientPublicValue [RFC4556].  This use of the anonymous client name

+   in conjunction with PKINIT is referred to as anonymous PKINIT.  If

+   anonymous PKINIT is used, the realm name in the returned anonymous

+   ticket MUST be the anonymous realm.

+

+   Upon receiving the anonymous PKINIT request from the client, the KDC

+   processes the request according to Section 3.1.2 of [RFC4120].  The

+   KDC skips the checks for the client's signature and the client's

+   public key (such as the verification of the binding between the

+   client's public key and the client name), but performs otherwise-

+   applicable checks, and proceeds as normal according to [RFC4556].

+   For example, the AS MUST check if the client's Diffie-Hellman domain

+   parameters are acceptable.  The Diffie-Hellman key agreement method

+   MUST be used and the reply key is derived according to Section

+   3.2.3.1 of [RFC4556].  If the clientPublicValue is not present in the

+   request, the KDC MUST return a KRB-ERROR with the code

+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556].  If all goes

+   well, an anonymous ticket is generated according to Section 3.1.3 of

+   [RFC4120] and a PA_PK_AS_REP [RFC4556] pre-authentication data is

+   included in the KDC reply according to [RFC4556].  If the KDC does

+   not have an asymmetric key pair, it MAY reply anonymously or reject

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 6]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   the authentication attempt.  If the KDC replies anonymously, both the

+   signerInfos field and the certificates field of the SignedData

+   [RFC3852] of PA_PK_AS_REP in the reply are empty.  The server name in

+   the anonymous KDC reply contains the name of the TGS.

+

+   Upon receipt of the KDC reply that contains an anonymous ticket and a

+   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then

+   authenticate the KDC based on the KDC's signature in the

+   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply

+   (the reply is anonymous), the client MUST reject the returned ticket

+   if it cannot authenticate the KDC otherwise.

+

+   A KDC that supports anonymous PKINIT MUST indicate the support of

+   PKINIT according to Section 3.4 of [RFC4556].

+

+   Note that in order to obtain an anonymous ticket with the anonymous

+   realm name, the client MUST set the client name as the anonymous

+   principal in the request when requesting an anonymous ticket in an AS

+   exchange.  Anonymity PKINIT is the only way via which an anonymous

+   ticket with the anonymous realm as the client realm can be generated

+   in this specification.

+

+4.2.  Anonymity Support in TGS Exchange

+

+   The client requests an anonymous ticket by setting the anonymous KDC

+   option in a TGS exchange, and in that request the client can use a

+   normal Ticket Granting Ticket (TGT) with the client's identity, or an

+   anonymous TGT, or an anonymous cross realm TGT.  If the client uses a

+   normal TGT, the client's identity is known to the TGS.

+

+   Note that the client can completely hide the client's identity in an

+   AS exchange using anonymous PKINIT as described in the previous

+   section.

+

+   If the ticket in the PA-TGS-REQ of the TGS request is an anonymous

+   one, the anonymous KDC option MUST be set in the request.  Otherwise,

+   the KDC MUST return a KRB-ERROR message with the code

+   KDC_ERR_BADOPTION.

+

+   When policy allows, the KDC issues an anonymous ticket.  If the

+   ticket in the TGS request is an anonymous one, the client name and

+   the client realm are copied from that ticket; otherwise the ticket in

+   the TGS request is a normal ticket, the returned anonymous ticket

+   contains the client name as the anonymous principal and the client

+   realm as the true realm of the client.  In all cases, according to

+   [RFC4120] the client name and the client realm in the EncTicketPart

+   of the reply MUST match with the corresponding client name and the

+   client realm of the anonymous ticket in the reply; the client MUST

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 7]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   use the client name and the client realm returned in the KDC-REP in

+   subsequent message exchanges when using the obtained anonymous

+   ticket.

+

+   Care MUST be taken by the TGS not to reveal the client's identity in

+   the authorization data of the returned ticket.  When propagating

+   authorization data in the ticket or in the enc-authorization-data

+   field of the request, the TGS MUST ensure that the client

+   confidentiality is not violated in the returned anonymous ticket.

+   The TGS MUST process the authorization data recursively according to

+   Section 5.2.6 of [RFC4120] beyond the container levels such that all

+   embedded authorization elements are interpreted.  The TGS SHOULD NOT

+   populate identity-based authorization data into an anonymous ticket

+   in that such authorization data typically reveals the client's

+   identity.  The specification of a new authorization data type MUST

+   specify the processing rules of the authorization data when an

+   anonymous ticket is returned.  If there is no processing rule defined

+   for an authorization data element or the authorization data element

+   is unknown, the TGS MUST process it when an anonymous ticket is

+   returned as follows:

+

+   o  If the authorization data element may reveal the client's

+      identity, it MUST be removed unless otherwise specified.

+

+   o  If the authorization data element, that could reveal's the

+      client's identity. is intended to restrict the use of the ticket

+      or limit the rights otherwise conveyed in the ticket, it cannot be

+      removed in order to hide the client's identity.  In this case, the

+      authentication attempt MUST be rejected, and the TGS MUST return

+      an error message with the code KDC_ERR_POLICY.  Note this is

+      applicable to both critical and optional authorization data.

+

+   o  If the authorization data element is unknown, the TGS MAY remove

+      it, or transfer it into the returned anonymous ticket, or reject

+      the authentication attempt, based on local policy for that

+      authorization data type unless otherwise specified.  If there is

+      no policy defined for a given unknown authorization data type, the

+      authentication MUST be rejected.  The error code is KDC_ERR_POLICY

+      when the authentication is rejected.

+

+   The AD-INITIAL-VERIFIED-CAS authorization data as defined in

+   [RFC4556] contains the issuer name of the client certificate.  If it

+   is undesirable to disclose such information about the client's

+   identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be

+   removed from an anonymous ticket.

+

+   The TGS encodes the name of the previous realm into the transited

+   field according to Section 3.3.3.2 of [RFC4120].  Based on local

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 8]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   policy, the TGS MAY omit the previous realm if the cross realm TGT is

+   an anonymous one in order to hide the authentication path of the

+   client.  The unordered set of realms in the transited field, if

+   present, can reveal which realm may potentially be the realm of the

+   client or the realm that issued the anonymous TGT.  The anonymous

+   Kerberos realm name MUST NOT be present in the transited field of a

+   ticket.  The true name of the realm that issued the anonymous ticket

+   MAY be present in the transited field of a ticket.

+

+4.3.  Subsequent Exchanges and Protocol Actions Common to AS and TGS for

+      Anonymity Support

+

+   In both AS and TGS exchanges, the realm field in the KDC request is

+   always the realm of the target KDC, not the anonymous realm when the

+   client requests an anonymous ticket.

+

+   Absent other information the KDC MUST NOT include any identifier in

+   the returned anonymous ticket that could reveal the client's identity

+   to the server.

+

+   Unless anonymous PKINIT is used, if a client requires anonymous

+   communication then the client MUST check to make sure that the ticket

+   in the reply is actually anonymous by checking the presence of the

+   anonymous ticket flag in the flags field of the EncKDCRepPart.  This

+   is because KDCs ignore unknown KDC options.  A KDC that does not

+   understand the anonymous KDC option will not return an error, but

+   will instead return a normal ticket.

+

+   The subsequent client and server communications then proceed as

+   described in [RFC4120].

+

+   Note that the anonymous principal name and realm are only applicable

+   to the client in Kerberos messages, the server cannot be anonymous in

+   any Kerberos message per this specification.

+

+   A server accepting an anonymous service ticket may assume that

+   subsequent requests using the same ticket originate from the same

+   client.  Requests with different tickets are likely to originate from

+   different clients.

+

+   Upon receipt of an anonymous ticket, the transited policy check is

+   preformed in the same way as that of a normal ticket if the client's

+   realm is not the anonymous realm; if the client realm is the

+   anonymous realm, absent other information any realm in the

+   authentication path is allowed by the cross-realm policy check.

+

+

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                 [Page 9]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+5.  Interoperability Requirements

+

+   Conforming implementations MUST support the anonymous principal with

+   a non-anonymous realm, and they MAY support the anonymous principal

+   with the anonymous realm using anonymous PKINIT.

+

+

+6.  GSS-API Implementation Notes

+

+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to

+   represent the anonymous identity.  In addition, Section 2.1.1 of

+   [RFC1964] defines the single string representation of a Kerberos

+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  The

+   anonymous principal with the anonymous realm corresponds to the GSS-

+   API anonymous principal.  A principal with the anonymous principal

+   name and a non-anonymous realm is an authenticated principal, hence

+   such a principal does not correspond to the anonymous principal in

+   GSS-API with the GSS_C_NT_ANONYMOUS name type.  The [RFC1964] name

+   syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the

+   anonymous principal name with a non-anonymous realm name and for

+   displaying and exporting these names.

+

+   At the GSS-API [RFC2743] level, an initiator/client requests the use

+   of an anonymous principal with the anonymous realm by asserting the

+   "anonymous" flag when calling GSS_Init_Sec_Context().  The GSS-API

+   implementation MAY provide implementation-specific means for

+   requesting the use of an anonymous principal with a non-anonymous

+   realm.

+

+   GSS-API does not know or define "anonymous credentials", so the

+   (printable) name of the anonymous principal will rarely be used by or

+   relevant for the initiator/client.  The printable name is relevant

+   for the acceptor/server when performing an authorization decision

+   based on the initiator name that is returned from the acceptor side

+   upon the successful security context establishment.

+

+   A GSS-API initiator MUST carefully check the resulting context

+   attributes from the initial call to GSS_Init_Sec_Context() when

+   requesting anonymity, because (as in the GSS-API tradition and for

+   backwards compatibility) anonymity is just another optional context

+   attribute.  It could be that the mechanism doesn't recognize the

+   attribute at all or that anonymity is not available for some other

+   reasons -- and in that case the initiator MUST NOT send the initial

+   security context token to the acceptor, because it will likely reveal

+   the initiators identity to the acceptor, something that can rarely be

+   "un-done".

+

+   Portable initiators are RECOMMENDED to use default credentials

+

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 10]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   whenever possible, and request anonymity only through the input

+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().

+

+

+7.  PKINIT Client Contribution to the Ticket Session Key

+

+   The definition in this section was motivated by protocol analysis of

+   anonymous PKINIT (defined in this document) in building tunneling

+   channels [FAST] and subsequent channel bindings.  In order to enable

+   applications of anonymous PKINIT to form channels, all

+   implementations of anonymous PKINIT need to meet the requirements of

+   this section.  There is otherwise no connection to the rest of this

+   document.

+

+   PKINIT is useful for constructing tunneling channels.  To ensure that

+   an attacker cannot create a channel with a given name, it is

+   desirable that neither the KDC nor the client can unilaterally

+   determine the ticket session key.  To achieve that end, a KDC

+   conforming to this definition MUST encrypt a randomly generated key,

+   called the KDC contribution key, in the PA_PKINIT_KX padata (defined

+   next in this section).  The KDC contribution key is then combined

+   with the reply key to form the ticket session key of the returned

+   ticket.  These two keys are then combined using the KRB-FX-CF2

+   operation defined in Section 7.1, where K1 is the KDC contribution

+   key, K2 is the reply key, the input pepper1 is American Standard Code

+   for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the

+   input pepper2 is ASCII string "KeyExchange".

+

+   PA_PKINIT_KX      135

+     -- padata for PKINIT that contains an encrypted

+     -- KDC contribution key.

+

+   PA-PKINIT-KX  ::= EncryptedData -- EncryptionKey

+     -- Contains an encrypted key randomly

+     -- generated by the KDC (known as the KDC contribution key).

+     -- Both EncryptedData and EncryptionKey are defined in [RFC4120]

+

+   The PA_PKINIT_KX padata MUST be included in the KDC reply when

+   anonymous PKINIT is used; it SHOULD be included if PKINIT is used

+   with the Diffie-Helleman key exchange but the client is not

+   anonymous; it MUST NOT be included otherwise (e.g. when PKINIT is

+   used with the public key encryption as the key exchange).

+

+   The padata-value field of the PA-PKINIT-KX type padata contains the

+   DER [X680] [X690] encoding of the Abstract Syntax Notation One

+   (ASN.1) type PA-PKINIT-KX.  The PA-PKINIT-KX structure is a

+   EncryptedData.  The clear text data being encrypted is the DER

+   encoded Kerberos session key randomly generated by the KDC.  The

+

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 11]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   encryption key is the reply key and the key usage number is

+   KEY_USAGE_PA_PKINIT_KX (44).

+

+   The client then decrypts the KDC contribution key and verifies the

+   ticket session key in the returned ticket is the combined key of the

+   KDC contribution key and the reply key as described above.  A

+   conforming client MUST reject anonymous PKINIT authentication if the

+   PA_PKINIT_KX padata is not present in the KDC reply or if the ticket

+   session key of the returned ticket is not the combined key of the KDC

+   contribution key and the reply key when PA-PKINIT-KX is present in

+   the KDC reply.

+

+7.1.  Combinging Two protocol Keys

+

+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()

+   function defined in [RFC3961].

+

+   Given two input keys, K1 and K2, where K1 and K2 can be of two

+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as

+   follows:

+

+    KRB-FX-CF2(protocol key, protocol key, octet string,

+              octet string)  ->  (protocol key)

+

+    PRF+(K1, pepper1) -> octet-string-1

+    PRF+(K2, pepper2) -> octet-string-2

+    KRB-FX-CF2(K1, K2, pepper1, pepper2) ->

+           random-to-key(octet-string-1 ^ octet-string-2)

+

+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as

+   follows:

+

+   PRF+(protocol key, octet string) -> (octet string)

+

+   PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||

+                pseudo-random( key, 2 || shared-info ) ||

+                pseudo-random( key, 3 || shared-info ) || ...

+

+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet

+   integer.  The pseudo-random() operation is specified by the enctype

+   of the protocol key.  PRF+() uses the counter to generate enough bits

+   as needed by the random-to-key() [RFC3961] function for the

+   encryption type specified for the resulting key; unneeded bits are

+   removed from the tail.

+

+

+

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 12]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+8.  Security Considerations

+

+   Since KDCs ignore unknown options, a client requiring anonymous

+   communication needs to make sure that the returned ticket is actually

+   anonymous.  This is because a KDC that that does not understand the

+   anonymous option would not return an anonymous ticket.

+

+   By using the mechanism defined in this specification, the client does

+   not reveal the client's identity to the server but the client

+   identity may be revealed to the KDC of the server principal (when the

+   server principal is in a different realm than that of the client),

+   and any KDC on the cross-realm authentication path.  The Kerberos

+   client MUST verify the ticket being used is indeed anonymous before

+   communicating with the server, otherwise the client's identity may be

+   revealed unintentionally.

+

+   In cases where specific server principals must not have access to the

+   client's identity (for example, an anonymous poll service), the KDC

+   can define server principal specific policy that insure any normal

+   service ticket can NEVER be issued to any of these server principals.

+

+   If the KDC that issued an anonymous ticket were to maintain records

+   of the association of identities to an anonymous ticket, then someone

+   obtaining such records could breach the anonymity.  Additionally, the

+   implementations of most (for now all) KDC's respond to requests at

+   the time that they are received.  Traffic analysis on the connection

+   to the KDC will allow an attacker to match client identities to

+   anonymous tickets issued.  Because there are plaintext parts of the

+   tickets that are exposed on the wire, such matching by a third party

+   observer is relatively straightforward.  A service that is

+   authenticated by the anonymous principals may be able to infer the

+   identity of the client by examining and linking quasi-static protocol

+   information such as the IP address from which a request is received,

+   or by linking multiple uses of the same anonymous ticket.

+

+   The client's real identity is not revealed when the client is

+   authenticated as the anonymous principal.  Application servers MAY

+   reject the authentication in order to, for example, prevent

+   information disclosure or as part of Denial of Service (DOS)

+   prevention.  Application servers MUST avoid accepting anonymous

+   credentials in situations where they must record the client's

+   identity; for example, when there must be an audit trail.

+

+

+9.  Acknowledgements

+

+   JK Jaganathan helped editing early revisions of this document.

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 13]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+   Clifford Neuman contributed the core notions of this document.

+

+   Ken Raeburn reviewed the document and provided suggestions for

+   improvements.

+

+   Martin Rex wrote the text for GSS-API considerations.

+

+   Nicolas Williams reviewed the GSS-API considerations section and

+   suggested ideas for improvements.

+

+   Sam Hartman and Nicolas Williams were great champions of this work.

+

+   Miguel Garcia and Phillip Hallam-Baker reviewed the document and

+   provided helpful suggestions.

+

+   In addition, the following individuals made significant

+   contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love

+   Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.

+

+

+10.  IANA Considerations

+

+   This document defines a new 'anonymous' Kerberos well-known name and

+   a new 'anonymous' Kerberos well-known realm based on [KRBNAM].  IANA

+   is requested to add these two values to the Kerberos naming

+   registries that are created in [KRBNAM].

+

+

+11.  References

+

+11.1.  Normative References

+

+   [ASAX34]   American Standard Code for Information Interchange, 

+              ASA X3.4-1963, American Standards Association, June 17, 

+              1963.

+

+   [KRBNAM]   Zhu, L., "Additional Kerberos Naming Constraints",

+              draft-ietf-krb-wg-naming (work in progress), 2008.

+

+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",

+              RFC 1964, June 1996.

+

+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

+              Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [RFC2743]  Linn, J., "Generic Security Service Application Program

+              Interface Version 2, Update 1", RFC 2743, January 2000.

+

+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",

+              RFC 3852, July 2004.

+

+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

+     

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 14]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+              Kerberos 5", RFC 3961, February 2005.

+

+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

+              Kerberos Network Authentication Service (V5)", RFC 4120,

+              July 2005.

+

+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

+

+

+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,

+              Information technology - Abstract Syntax Notation One

+              (ASN.1): Specification of basic notation.

+   

+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,

+              Information technology - ASN.1 encoding Rules:

+              Specification of Basic Encoding Rules (BER), Canonical

+              Encoding Rules (CER) and Distinguished Encoding Rules

+              (DER).        

+              

+11.2.  Informative References

+

+   [FAST]     Zhu, L. and S. Hartman, "A Generalized Framework for

+              Kerberos Pre-Authentication",

+              draft-ietf-krb-wg-preauth-framework (work in progress),

+              2008.

+

+

+Authors' Addresses

+

+   Larry Zhu

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: lzhu@microsoft.com

+

+

+   Paul Leach

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: paulle@microsoft.com

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 15]

+

+Internet-Draft         Kerberos Anonymity Support           October 2008

+

+

+Full Copyright Statement

+

+   Copyright (C) The IETF Trust (2008).

+

+   This document is subject to the rights, licenses and restrictions

+   contained in BCP 78, and except as set forth therein, the authors

+   retain all their rights.

+

+   This document and the information contained herein are provided on an

+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

+

+

+Intellectual Property

+

+   The IETF takes no position regarding the validity or scope of any

+   Intellectual Property Rights 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; nor does it represent that it has

+   made any independent effort to identify any such rights.  Information

+   on the procedures with respect to rights in RFC documents can be

+   found in BCP 78 and BCP 79.

+

+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at

+   http://www.ietf.org/ipr.

+

+   The IETF invites any interested party to bring to its attention any

+   copyrights, patents or patent applications, or other proprietary

+   rights that may cover technology that may be required to implement

+   this standard.  Please address the information to the IETF at

+   ietf-ipr@ietf.org.

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Leach              Expires April 11, 2009                [Page 16]

+

+

diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-cross-problem-statement-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-cross-problem-statement-04.txt
new file mode 100644
index 00000000000..d73e613d8a9
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-cross-problem-statement-04.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                 S. Sakane
+Intended Status: Informational                           Ken'ichi Kamada
+Expires: January 31, 2010                        Yokogawa Electric Corp.
+                                                               S. Zrelli
+                                                                   JAIST
+                                                             M. Ishiyama
+                                                           Toshiba Corp.
+                                                           July 30, 2009
+
+
+       Problem statement on the cross-realm operation of Kerberos
+            draft-ietf-krb-wg-cross-problem-statement-04.txt
+
+
+
+
+                          Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   This Internet-Draft expires in January 31, 2010.
+
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+
+
+
+S.Sakane, et al.                                                [Page 1]
+
+Internet-Draft                                                 July 2009
+
+
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+Abstract
+
+   As industrial automation is moving towards wider adoption of Internet
+   standards, the Kerberos authentication protocol represents one of the
+   best alternatives for ensuring the confidentiality and the integrity
+   of communications in control networks while meeting performance and
+   security requirements.
+
+   However, the use of Kerberos cross-realm operations in large scale
+   industrial systems may introduce issues that could cause performance
+   and reliability problems. This document describes some examples of
+   actual large scale industrial systems, and lists requirements and
+   restriction regarding authentication operations in such environments.
+   The document then describes standing issues in the Kerberos cross-
+   realm authentication model that should be fixed before Kerberos can
+   be adopted in large scale industrial systems.
+
+
+
+Conventions used in this document
+
+   It is assumed that the readers are familiar with the terms and
+   concepts described in the Kerberos Version 5 [RFC4120].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 2]
+
+Internet-Draft                                                 July 2009
+
+
+Table of Contents
+
+    1. Introduction .................................................  4
+    2. Kerberos system ..............................................  4
+       2.1. Kerberos basic operation ................................  4
+       2.2. Cross-realm operation ...................................  5
+    3. Applying Cross-Realm Kerberos in Complex Environments ........  6
+    4. Requirements .................................................  7
+    5. Issues .......................................................  8
+       5.1. Unreliability of authentication chain ...................  8
+       5.2. Possibility of MITM in case of the indirect trust model .  9
+       5.3. Scalability of the direct trust model ...................  9
+       5.4. Exposure to DoS Attacks .................................  9
+       5.5. Client's performance .................................... 10
+       5.6. Pre-authentication problem in roaming scenarios ......... 10
+    6. Implementation consideration ................................. 11
+    7. IANA Considerations .......................................... 11
+    8. Security Considerations ...................................... 11
+    9. Acknowledgments .............................................. 11
+   10. References ................................................... 11
+       10.1. Normative References ................................... 11
+       10.2. Informative References ................................. 12
+   Authors' Addresses ............................................... 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 3]
+
+Internet-Draft                                                 July 2009
+
+
+1.  Introduction
+
+   Kerberos Version 5 is a widely deployed mechanism that enables a
+   server to authenticate a client's access.  Each client belongs to a
+   managed domain called realm.  Kerberos supports authentication when a
+   client and a server belong to different realms.  This is called
+   cross-realm operation.
+
+   Meanwhile, there are lots of manners of operation in actual systems,
+   where Kerberos could be applied.  Large systems or distributed
+   systems are typically split into several managed domains.  For
+   example, systems could be split into multiple domains for
+   geographical reasons, or to implement different management policies.
+   Even in such systems, a common authentication mechanism for the
+   different managed domains is required.  When the cross-realm
+   operation of Kerberos is applied to such systems, some issues come
+   out.
+
+   This document briefly describes the Kerberos Version 5 system and its
+   cross-realm mode of operation.  Then, it describes two actual systems
+   that Kerberos could be applied to.  and describes seven requirements
+   of those systems in term both of management and operation.  Finally,
+   it lists six issues of the cross-realm operation when it is applied
+   to those system.
+
+   Note that this document might not describe all of the issues of
+   cross-realm operation.  New issues might be found in the future.  It
+   also does not propose any solution to solve the issues.  Furthermore,
+   publication of this document does not mean that each of the issues
+   have to be solved by the IETF members.  Hence, in further step, we
+   will analyze the issues, define problems and explore the solutions.
+   These works will be described in another document.
+
+   This document is assumed that the readers are familiar with the terms
+   and concepts described in the Kerberos Version 5 [RFC4120].
+
+
+2.  Kerberos system
+
+
+2.1.  Kerberos basic operation
+
+   Kerberos [RFC4120] is a widely deployed authentication system.  The
+   authentication process in Kerberos involves principals and a Key
+   Distribution Center (KDC).  The principals can be users or services.
+   Each KDC maintains a database of principals and shares a secret key
+   with each registered principal.
+
+
+
+
+S.Sakane, et al.                                                [Page 4]
+
+Internet-Draft                                                 July 2009
+
+
+   The authentication process allows a user to acquire the needed
+   credentials from the KDC.  These credentials allow services to
+   authenticate the users before granting them access to the resources.
+   An important part of the credentials are called Tickets.  There are
+   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
+   The TGT is obtained periodically from the KDC and has a limited limit
+   after which it expires and the user must renew it.  The TGT is used
+   to obtain the other kind of tickets, Service Tickets.  The user
+   obtains a TGT from the Authentication Service (AS), a logical
+   component of the KDC.  The process of obtaining a TGT is referred to
+   as 'AS exchange'.  When a TGT request is issued by an user, the AS
+   responds by sending a reply packet containing the credentials which
+   consists of the TGT along with a random key called 'TGS Session Key'.
+   The TGT contains a set of information encrypted using a secret key
+   associated with a special service referred to as TGS (Ticket Granting
+   Service).  The TGS session key is encrypted using the user's key so
+   that the user can obtain the TGS session key only if she knows the
+   secret key shared with the KDC.  The TGT then is used to obtain
+   Service Tickets from the Ticket Granting Service (TGS)- the second
+   component of the KDC.  The process of obtaining service tickets is
+   referred to as 'TGS exchange'.  The request for a service ticket
+   consists on a packet containing a TGT and an 'Authenticator'.  The
+   Authenticator is encrypted using the TGS session key and contains the
+   identity of the user as well as time stamps (for protection against
+   replay attacks).  After decrypting the TGT (which was encrypted by
+   the AS using the TGS's secret key), the TGS extracts the TGS session
+   key.  Using that session key, it decrypts the Authenticator and
+   authenticates the user.  Then, the TGS issues credentials requested
+   by the user.  These credentials consist on a service ticket and a
+   session key that will be used to authenticate the user with the
+   desired application service.
+
+
+2.2.  Cross-realm operation
+
+   The Kerberos protocol provides cross-realm authentication
+   capabilities.  This allows users to obtain service tickets to access
+   services in foreign realms.  In order to access such services, the
+   users first contact their home KDC asking for a TGT that will be used
+   with the TGS of the foreign realm.  If there is a direct trust
+   relationship between the home realm and the foreign realm, namely
+   both realms share keys (this is called inter-realm keys), the home
+   KDC delivers the requested TGT.
+
+   However, if the home realm does not share inter-realm keys with the
+   foreign realm the home KDC will provide a TGT that can be used with
+   an intermediary foreign realm that is likely to be sharing inter-
+   realm keys with the target realm.  The client can use this
+
+
+
+S.Sakane, et al.                                                [Page 5]
+
+Internet-Draft                                                 July 2009
+
+
+   'intermediary TGT' to communicate with the intermediary KDC which
+   will iterate the actions taken by the home KDC.  If the intermediary
+   KDC does not share inter-realm keys with the target foreign realm it
+   will point the user to another intermediary KDC (just as in the first
+   exchange between the user and its home KDC).  However, in the other
+   case (when it shares inter-realm keys with the target realm), the
+   intermediary KDC will issue a TGT that can be used with the KDC of
+   the target realm.  This is so-called indirect trust model.  After
+   obtaining a TGT for the desired foreign realm, the client uses it to
+   obtain service tickets from the TGS of the foreign realm.  Finally,
+   the user access the service using the service ticket.
+
+   When the realms belong to the same institution, a chain of trust can
+   be determined by the client or the KDC by following the DNS domain
+   hierarchy and supposing that the parent domains share keys with all
+   its child sub-domains.  However, because the inter-realm trust model
+   is not necessarily constructing the hierarchic approach anytime, the
+   trust path must be specified manually.  When intermediary realms are
+   involved, the success of the cross-realm operation completely depends
+   on the realms that are part of the authentication path.
+
+
+3.  Applying Cross-Realm Kerberos in Complex Environments
+
+   In order to help understanding both requirements and restriction,
+   this section describes scale and operation of two actual systems that
+   could be supported by cross-realm Kerberos.  The two systems would be
+   most naturally implemented using different models, which will imply
+   different requirements for cross-realm Kerberos.
+
+   We refer to actual petrochemical enterprise [SHELLCHEM], and show two
+   examples among its plants.  The enterprise produces bulk
+   petrochemicals and their delivery to large industrial customers.
+   There are 43 typical plants of the enterprise all over the world.
+   They are managed by the operation sites placed in 35 countries.  This
+   section shows two examples of them.
+
+   One is an example of a centralized system [CSPC].  CSPC is operated
+   by a joint enterprise of two companies.  This system is one of the
+   largest systems of this enterprise in the world.  This is placed in
+   the area of 3.4 square kilo meters in the north coast of Daya Bay,
+   Guangdong, which is at the southeast of China.  3,000 network
+   segments are established in the system.  16,000 control devices are
+   connected to the local area network.  These devices belong to
+   different 9 sub systems, A control device has some control points,
+   which are controlled and monitored by other devices remotely.  There
+   are 200,000 control points in all.  They are controlled by 3
+   different control center.
+
+
+
+S.Sakane, et al.                                                [Page 6]
+
+Internet-Draft                                                 July 2009
+
+
+   Another example is a distributed system [NAM].  The NAM (Nederlandse
+   Aardolie Maatschappij) is operated by a partnership company of two
+   enterprises that represent the oil company.  This system is
+   constituted by some plants that are geographically distributed within
+   the range of 863 square kilometers in the northern part of
+   Netherlands.  26 plants, each is named "cluster", are scattered in
+   the area.  They are connected each other by a private ATM WAN.  Each
+   cluster has approximately 500-1,000 control devices.  These devices
+   are managed by each local control center in each cluster.  In the
+   entire system of the NAM, there are one million control points.
+
+   In the both of the systems, the end devices are basically connected
+   to a local network by a twisted pair cable, which is a low band-width
+   of 32 kbps.  Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS-
+   M16C], are employed by many control devices.  Furthermore, to
+   suppress power consumption, these CPU may be lowered the number of
+   clocks.  Because there is a requirement of the explosion-proof.  The
+   requirement restricts the amount of total energy in the device.
+
+   A device on the network collects data from other devices which are
+   monitoring condition of the system.  The device uses the data to make
+   a decision how to control another devices.  And then the device gives
+   more than one instruction that controls other devices.  If it took
+   time for data to reach, they could not be associated.  The travel
+   time of data from the device to the other device is demanded within 1
+   second at least.
+
+   A part of the operation, like control of these system, maintenance,
+   and the environmental monitoring, is consigned to an external
+   organization.  Agents who are consigned walk around the plant to get
+   their information, or watch the plant from a remote site.
+
+
+4.  Requirements
+
+   This section lists the requirements derived from the previous
+   section.  R-1, R-2, R-3 and R-4 are related to the management of the
+   divided system.  R-5, R-6 and R-7 are related to the restriction to
+   such industrial network.
+
+
+   R-1  It is necessary to partition a management domain into some
+        domains.  Or it is necessary to delegate a management authority
+        to another independent management domain.
+
+   R-2  It is necessary to allow different independent management
+        domains to coexist on the same network because two or more
+        organizations need to enter into the system and to management
+
+
+
+S.Sakane, et al.                                                [Page 7]
+
+Internet-Draft                                                 July 2009
+
+
+        it.
+
+   R-3  It is necessary that a device controls other devices that belong
+        to a different domain.
+
+   R-4  It is necessary to consider that a device is not always
+        geographically or network topologically close to the other
+        devices even when the devices belong to a same management
+        domain.
+
+   R-5  It is demanded to reduce the management cost as much as
+        possible.
+
+   R-6  It is necessary to consider the processing performance of the
+        device.  And, it is necessary to suppress the power consumption
+        of the device.
+
+   R-7  It is necessary to consider bandwidth of the communication.
+
+
+5.  Issues
+
+   This section lists the issues in the cross-realm operation when we
+   apply the Kerberos version 5 into the system described in the section
+   3, and consider the system applied the Kerberos with the requirements
+   described in the section 4.
+
+
+5.1.  Unreliability of authentication chain
+
+   When the relationship of trust is constructed like a chain or
+   hierarchical, the authentication path is not dependable since it
+   strongly depends on intermediary realms that might not be under the
+   same authority.  If any of the realms in the authentication path is
+   not available, then the principals of the end-realms can not perform
+   the cross-realm operation.
+
+   The end-point realms do not have full control and responsibility of
+   the success of the operations even if their respective KDCs are fully
+   functional.  Dependability of a system decreases if the system relies
+   on uncontrolled components.  We can not be sure at 100% about the
+   result of the authentication since we do not know how is it going in
+   intermediary realms.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1 and R-2.
+
+
+
+
+
+S.Sakane, et al.                                                [Page 8]
+
+Internet-Draft                                                 July 2009
+
+
+5.2.  Possibility of MITM in case of the indirect trust model
+
+   Every KDC in the authentication path knows the shared secret between
+   the client and the remaining KDCs in the authentication path.  This
+   allows a malicious KDC to perform MITM attacks on communications
+   between the client and any KDC in the remaining authentication chain.
+   A malicious KDC also may learn the service session key that is used
+   to protect the communication between the client and the actual
+   application service, and performs a MITM attack between them.
+
+   In [SPECCROSS], the authors have analyzed the cross-realm operations
+   in Kerberos and provided formal proof of the issue discussed in this
+   section.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1 and R-2.
+
+
+5.3.  Scalability of the direct trust model
+
+   In the direct relationship of trust between each realm, the realms
+   involved in the cross-realm operation share keys and their respective
+   TGS principals are registered in each other's KDC.  When direct trust
+   relationships are used, the KDC of each realm must maintain keys with
+   all foreign realms.  This can become a cumbersome task when the
+   number of realms increase.  This also increases maintenance cost.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1, R-2 and R-5.
+
+
+5.4.  Exposure to DoS Attacks
+
+   One of the assumption made when allowing the cross-realm operation in
+   Kerberos is that users can communicate with KDCs located in remote
+   realms.  This practice introduces security threats because KDCs are
+   open to the public network.  Administrators may think of restricting
+   the access to the KDC to the trusted realms only.  However, this
+   approach is not scalable and does not really protect the KDC.
+   Indeed, when the remote realms have several IP prefixes (e.g. control
+   centers or outsourcing companies, located world wide), then the
+   administrator of the local KDC must collect the list of prefixes that
+   belong to these organization.  The filtering rules must then
+   explicitly allow the incoming traffic from any host that belongs to
+   one of these prefixes.  This makes the administrator's tasks more
+   complicated and prone to human errors.  And also, the maintenance
+   cost increases.  On the other hand, when ranges of external IP
+   addresses are allowed to communicate with the KDC, the risk of
+
+
+
+S.Sakane, et al.                                                [Page 9]
+
+Internet-Draft                                                 July 2009
+
+
+   becoming target to attacks from remote malicious users increases.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-3, R-4 and R-5.
+
+
+5.5.  Client's performance
+
+   In the cross-realm operation, Kerberos clients have to perform TGS
+   exchanges with all the KDCs in the trust path, including the home KDC
+   and the target KDC.  TGS exchange requires cryptographic operations.
+   This exchange demands important processing time especially when the
+   client has limited computational capabilities.  The overhead of these
+   cross-realm exchanges grows into unacceptable delays.
+
+   We ported the MIT Kerberos library (version 1.2.4), implemented a
+   Kerberos client on our original board with H8 (16-bit, 20MHz), and
+   measured the process time of each Kerberos message [KRBIMPL].  It
+   takes 195 milliseconds to perform a TGS exchange with the on-board
+   H/W crypto engine.  Indeed, this result seems reasonable to the
+   requirement of the response time for the control network.  However,
+   we did not modify the clock speed of the H8 during our measurement.
+   The processing time must be slower in a actual environment because H8
+   is used with lowered clock speed in such system.  Also, the delays
+   can grow to unacceptable delays when the number of intermediary
+   realms increases.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1, R-2, R-6 and R-7.
+
+
+5.6.  Pre-authentication problem in roaming scenarios
+
+   In roaming scenarios, the client needs to contact her home KDC to
+   obtain a cross-realm TGT for the local (or visited) realm.  However,
+   the policy of the network access providers or the gateway in the
+   local network usually does not allow clients to communicate with
+   hosts in the Internet unless they provide valid authentication
+   credentials.  In this manner, the client encounters a chicken-and-egg
+   problem where two resources are interdependent; the Internet
+   connection is needed to contact the home KDC and for obtaining
+   credentials, and on the other hand, the Internet connection is only
+   granted for clients who have valid credentials.  As a result, the
+   Kerberos protocol can not be used as it is for authenticating roaming
+   clients requesting network access.
+
+   This issue will happen as a result meeting the requirements R-3 and
+   R-4.
+
+
+
+S.Sakane, et al.                                               [Page 10]
+
+Internet-Draft                                                 July 2009
+
+
+6.  Implementation consideration
+
+   This document just describes issues of the cross-realm operation.
+   However, there are important matters to be considered, when we solve
+   these issues and implement solution.  Solution must not introduce new
+   problem.  It should use existing components or protocols as much as
+   possible, and it should not introduce any definition of new
+   component.  It should not require new changes to existing deployed
+   clients, and it should not influence the client code-base as much as
+   possible.  Because a KDC is a significant server of the Kerberos
+   system.  New burden should not be introduced into a KDC as much as
+   possible.  You must not forget that there would be a trade-off matter
+   anytime.  So an implementation may not solve all of the problems
+   stated in this document.
+
+
+7.  IANA Considerations
+
+   This document makes no request of IANA.
+
+
+8.  Security Considerations
+
+   This document clarifies the issues of the cross-realm operation of
+   the Kerberos V system, which include security issues to be
+   considered.  See Section 5.1, 5.2, 5.3 and 5.4 for further details.
+
+
+9.  Acknowledgments
+
+   The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and
+   Atsushi Inoue.  They gave us lots of comments and suggestions to this
+   document from the early stage.  Nicolas Williams, Chaskiel Grundman
+   and Love Hornquist Astrand gave valuable suggestions and corrections.
+   Finally, the authors thank to Jeffrey Hutzelman.  He gave us a lot of
+   suggestions for completion of this document.
+
+
+10.  References
+
+
+10.1.  Normative References
+
+   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                 Kerberos Network Authentication Service (V5)", RFC
+                 4120, July 2005.
+
+
+
+
+
+S.Sakane, et al.                                               [Page 11]
+
+Internet-Draft                                                 July 2009
+
+
+10.2.  Informative References
+
+   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
+                 531,00.html
+
+   [KRBIMPL]     "A Prototype of a Secure Autonomous Bootstrap Mechanism
+                 for Control Networks", Nobuo Okabe, Shoichi Sakane,
+                 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki,
+                 SAINT, pp. 56-62, IEEE Computer Society, 2006.
+
+   [NAM]         http://www.nam.nl/
+
+   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
+                 jsp&fp=/products/mpumcu/h8_family/
+
+   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
+                 ng.jsp&fp=/products/mpumcu/m16c_family/
+
+   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html
+
+   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
+                 Walstad, "Specifying Kerberos 5 Cross-Realm
+                 Authentication", Fifth Workshop on Issues in the Theory
+                 of Security, Jan 2005.
+
+Authors' Addresses
+
+   Shoichi Sakane
+   Ken'ichi Kamada
+   Yokogawa Electric Corporation
+   2-9-32 Nakacho, Musashino-shi,
+   Tokyo  180-8750 Japan
+   E-mail: Shouichi.Sakane@jp.yokogawa.com,
+           Ken-ichi.Kamada@jp.yokogawa.com
+
+
+   Saber Zrelli
+   Japan Advanced Institute of Science and Technology
+   1-1 Asahidai, Nomi,
+   Ishikawa  923-1292 Japan
+   E-mail: zrelli@jaist.ac.jp
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                               [Page 12]
+
+Internet-Draft                                                 July 2009
+
+
+   Masahiro Ishiyama
+   Toshiba Corporation
+   1, komukai-toshiba-cho, Saiwai-ku,
+   Kawasaki  212-8582 Japan
+   E-mail: masahiro@isl.rdc.toshiba.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                               [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt
new file mode 100644
index 00000000000..b1bee6fa491
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt
@@ -0,0 +1,2690 @@
+
+
+
+
+
+
+
+
+
+INTERNET DRAFT                                                K. Raeburn
+Kerberos Working Group                                               MIT
+Document: draft-ietf-krb-wg-crypto-03.txt              February 24, 2003
+                                                 expires August 24, 2003
+
+                 Encryption and Checksum Specifications
+                             for Kerberos 5
+
+Abstract
+
+   This document describes a framework for defining encryption and
+   checksum mechanisms for use with the Kerberos protocol [Kerb],
+   defining an abstraction layer between the Kerberos protocol and
+   related protocols, and the actual mechanisms themselves.  Several
+   mechanisms are also defined in this document.  Some are taken from
+   RFC 1510, modified in form to fit this new framework, and
+   occasionally modified in content when the old specification was
+   incorrect.  New mechanisms are presented here as well.  This document
+   does NOT indicate which mechanisms may be considered "required to
+   implement".
+
+   Comments should be sent to the editor, or to the IETF Kerberos
+   working group (ietf-krb-wg@anl.gov).
+
+Status
+
+   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.html.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                             February 2003
+
+
+                           Table of Contents
+
+
+Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
+Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
+Table of Contents  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+1. Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+2. Encryption algorithm profile  . . . . . . . . . . . . . . . . . .   4
+3. Checksum algorithm profile  . . . . . . . . . . . . . . . . . . .   9
+4. Simplified profile for CBC ciphers with key derivation  . . . . .  10
+4.1. A key derivation function . . . . . . . . . . . . . . . . . . .  10
+4.2. Simplified profile parameters . . . . . . . . . . . . . . . . .  12
+4.3. Cryptosystem profile based on simplified profile  . . . . . . .  14
+4.4. Checksum profiles based on simplified profile . . . . . . . . .  16
+5. Profiles for Kerberos encryption and checksum algorithms  . . . .  16
+5.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . .  16
+5.2. DES-based encryption and checksum types . . . . . . . . . . . .  18
+5.3. Triple-DES based encryption and checksum types  . . . . . . . .  28
+6. Use of Kerberos encryption outside this specification . . . . . .  30
+7. Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . . .  31
+8. Implementation Notes  . . . . . . . . . . . . . . . . . . . . . .  32
+9. Security Considerations . . . . . . . . . . . . . . . . . . . . .  33
+10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  34
+11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  35
+12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . .  35
+13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  36
+A. Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . . .  36
+A.1. n-fold  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  36
+A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . .  38
+A.3. DES3 DR and DK  . . . . . . . . . . . . . . . . . . . . . . . .  42
+A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . .  43
+A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . .  44
+B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . .  44
+Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  45
+Normative References . . . . . . . . . . . . . . . . . . . . . . . .  46
+Informative References . . . . . . . . . . . . . . . . . . . . . . .  48
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                             February 2003
+
+
+Introduction
+
+   The Kerberos protocols are designed to encrypt messages of arbitrary
+   sizes, using block encryption ciphers, or less commonly, stream
+   encryption ciphers.  Encryption is used to prove the identities of
+   the network entities participating in message exchanges.  However,
+   nothing in the Kerberos protocol requires any specific encryption
+   algorithm be used, as long as certain operations are available in the
+   algorithm that is used.
+
+   The following sections specify the encryption and checksum mechanisms
+   currently defined for Kerberos, as well as a framework for defining
+   future mechanisms.  The encoding, chaining, padding and other
+   requirements for each are described.  Test vectors for several
+   functions are given in appendix A.
+
+1. Concepts
+
+   Both encryption and checksum mechanisms are defined in terms of
+   profiles, detailed in later sections.  Each specifies a collection of
+   operations and attributes that must be defined for a mechanism.  A
+   Kerberos encryption or checksum mechanism specification is not
+   complete if it does not define all of these operations and
+   attributes.
+
+   An encryption mechanism must provide for confidentiality and
+   integrity of the original plaintext.  (Integrity checking may be
+   achieved by incorporating a checksum, if the encryption mode does not
+   provide an integrity check itself.)  It must also provide non-
+   malleability [Bellare98, Dolev91].  Use of a random confounder
+   prepended to the plaintext is recommended.  It should not be possible
+   to determine if two ciphertexts correspond to the same plaintext,
+   without knowledge of the key.
+
+   A checksum mechanism [1] must provide proof of the integrity of the
+   associated message, and must preserve the confidentiality of the
+   message in case it is not sent in the clear.  It should be infeasible
+   to find two plaintexts which have the same checksum.  It is NOT
+   required that an eavesdropper be unable to determine if two checksums
+   are for the same message; it is assumed that the messages themselves
+   will be visible to any such eavesdropper.
+
+   Due to advances in cryptography, it is considered unwise by some
+   cryptographers to use the same key for multiple purposes.  Since keys
+   are used in performing a number of different functions in Kerberos,
+   it is desirable to use different keys for each of these purposes,
+   even though we start with a single long-term or session key.
+
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                             February 2003
+
+
+   We do this by enumerating the different uses of keys within Kerberos,
+   and making the "usage number" an input to the encryption or checksum
+   mechanisms; this enumeration is outside the scope of this document.
+   Later sections of this document define simplified profile templates
+   for encryption and checksum mechanisms that use a key derivation
+   function applied to a CBC mode (or similar) cipher and a checksum or
+   hash algorithm.
+
+   We distinguish the "base key" specified by other documents from the
+   "specific key" to be used for a particular instance of encryption or
+   checksum operations.  It is expected but not required that the
+   specific key will be one or more separate keys derived from the
+   original protocol key and the key usage number.  The specific key
+   should not be explicitly referenced outside of this document.  The
+   typical language used in other documents should be something like,
+   "encrypt this octet string using this key and this usage number";
+   generation of the specific key and cipher state (described in the
+   next section) are implicit.  The creation of a new cipher-state
+   object, or the re-use of one from a previous encryption operation,
+   may also be explicit.
+
+   New protocols defined in terms of the Kerberos encryption and
+   checksum types should use their own key usage values.  Key usages are
+   unsigned 32 bit integers; zero is not permitted.
+
+   All data is assumed to be in the form of strings of octets or 8-bit
+   bytes.  Environments with other byte sizes will have to emulate this
+   behavior in order to get correct results.
+
+   Each algorithm is assigned an encryption type (or "etype") or
+   checksum type number, for algorithm identification within the
+   Kerberos protocol.  The full list of current type number assignments
+   is given in section 7.
+
+2. Encryption algorithm profile
+
+   An encryption mechanism profile must define the following attributes
+   and operations.  The operations must be defined as functions in the
+   mathematical sense: no additional or implicit inputs (such as
+   Kerberos principal names or message sequence numbers) are permitted.
+
+   protocol key format
+      This describes what octet string values represent valid keys.  For
+      encryption mechanisms that don't have perfectly dense key spaces,
+      this will describe the representation used for encoding keys.  It
+      need not describe specific values that are not valid or desirable
+      for use; such values should be avoid by all key generation
+      routines.
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                             February 2003
+
+
+   specific key structure
+      This is not a protocol format at all, but a description of the
+      keying material derived from the chosen key and used to encrypt or
+      decrypt data or compute or verify a checksum.  It may, for
+      example, be a single key, a set of keys, or a combination of the
+      original key with additional data.  The authors recommend using
+      one or more keys derived from the original key via one-way
+      functions.
+
+   required checksum mechanism
+      This indicates a checksum mechanism that must be available when
+      this encryption mechanism is used.  Since Kerberos has no built in
+      mechanism for negotiating checksum mechanisms, once an encryption
+      mechanism has been decided upon, the corresponding checksum
+      mechanism can simply be used.
+
+   key-generation seed length, K
+      This is the length of the random bitstring needed to generate a
+      key with the encryption scheme's random-to-key function (described
+      below).  This must be a fixed value so that various techniques for
+      producing a random bitstring of a given length may be used with
+      key generation functions.
+
+   key generation functions
+      Keys must be generated in a number of cases, from different types
+      of inputs.  All function specifications must indicate how to
+      generate keys in the proper wire format, and must avoid generation
+      of keys that significantly compromise the confidentiality of
+      encrypted data, if the cryptosystem has such.  Entropy from each
+      source should be preserved as much as possible.  Many of the
+      inputs, while unknown, may be at least partly predictable (e.g., a
+      password string is likely to be entirely in the ASCII subset and
+      of fairly short length in many environments; a semi-random string
+      may include timestamps); the benefit of such predictability to an
+      attacker must be minimized.
+
+      string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
+         This function generates a key from two UTF-8 strings and an
+         opaque octet string.  One of the strings is normally the
+         principal's pass phrase, but is in general merely a secret
+         string.  The other string is a "salt" string intended to
+         produce different keys from the same password for different
+         users or realms.  While the strings provided will use UTF-8
+         encoding, no specific version of Unicode should be assumed; all
+         valid UTF-8 strings should be allowed.
+
+         The third argument, the octet string, may be used to pass
+         mechanism-specific parameters in to this function.  Since doing
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                             February 2003
+
+
+         so implies knowledge of the specific encryption system, it is
+         intended that generating non-default parameter values be an
+         uncommon operation, and that normal Kerberos applications be
+         able to treat this parameter block as an opaque object supplied
+         by the KDC or defaulted to some mechanism-specific constant
+         value.
+
+         This should be a one-way function, so that compromising a
+         user's key in one realm does not compromise the user's key in
+         another realm, even if the same password (but a different salt)
+         is used.
+
+      random-to-key (bitstring[K])->(protocol-key)
+         This function generates a key from a random bit string of a
+         specific size.  It may be assumed that all the bits of the
+         input string are equally random, even though the entropy
+         present in the random source may be limited.
+
+      key-derivation (protocol-key, integer)->(specific-key)
+         In this function, the integer input is the key usage value as
+         described above; the usage values must be assumed to be known
+         to an attacker.  The specific-key output value was described in
+         section 1.
+
+   string-to-key parameter format
+      This describes the format of the block of data that can be passed
+      to the string-to-key function above to configure additional
+      parameters for that function.  Along with the mechanism of
+      encoding parameter values, bounds on the allowed parameters should
+      also be described to avoid allowing a spoofed KDC to compromise
+      the user's password.  It may be desirable to construct the
+      encoding such that values weakening the resulting key unacceptably
+      cannot be encoded, if practical.
+
+      Tighter bounds might be permitted by local security policy, or to
+      avoid excess resource consumption; if so, recommended defaults for
+      those bounds should be given in the specification.  The
+      description should also outline possible weaknesses that may be
+      caused by not applying bounds checks or other validation to a
+      parameter string received from the network.
+
+      As mentioned above, this should be considered opaque to most
+      normal applications.
+
+   default string-to-key parameters (octet string)
+      This default value for the "params" argument to the string-to-key
+      function is to be used when the application protocol (Kerberos or
+      otherwise) does not explicitly set the parameter value.  As
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                             February 2003
+
+
+      indicated above, this parameter block should be treated as an
+      opaque object in most cases.
+
+   cipher state
+      This describes any information that can be carried over from one
+      encryption or decryption operation to the next, for use in
+      conjunction with a given specific key.  For example, a block
+      cipher used in CBC mode may put an initial vector of one block in
+      the cipher state.  Other encryption modes may track nonces or
+      other data.
+
+      This state must be non-empty, and must influence encryption so as
+      to require that messages be decrypted in the same order they were
+      encrypted, if the cipher state is carried over from one encryption
+      to the next.  Distinguishing out-of-order or missing messages from
+      corrupted messages is not required; if desired, this can be done
+      at a higher level by including sequence numbers and not "chaining"
+      the cipher state between encryption operations.
+
+      The cipher state may not be reused in multiple encryption or
+      decryption operations; these operations all generate a new cipher
+      state that may be used for following operations using the same key
+      and operation.
+
+      The contents of the cipher state must be treated as opaque outside
+      of encryption system specifications.
+
+   initial cipher state (specific-key, direction)->(state)
+      This describes the generation of the initial value for the cipher
+      state if it is not being carried over from a previous encryption
+      or decryption operation.
+
+      This describes any initial state setup needed before encrypting
+      arbitrary amounts of data with a given specific key; the specific
+      key and the direction of operations to be performed (encrypt
+      versus decrypt) must be the only input needed for this
+      initialization.
+
+      This state should be treated as opaque in any uses outside of an
+      encryption algorithm definition.
+
+      IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
+      degree an application protocol could exercise control over the
+      initial vector used in DES CBC operations.  Some existing
+      implementations permit the setting of the initial vector.  This
+      new specification does not permit application control of the
+      cipher state (beyond "initialize" and "carry over from previous
+      encryption"), since the form and content of the initial cipher
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                             February 2003
+
+
+      state can vary between encryption systems, and may not always be a
+      single block of random data.
+
+      New Kerberos application protocols should not assume that they can
+      control the initial vector, or that one even exists.  However, a
+      general-purpose implementation may wish to provide the capability,
+      in case applications explicitly setting it are encountered.
+
+   encrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and a non-
+      empty plaintext string as input, and generates ciphertext and a
+      new cipher state as outputs.  If the basic encryption algorithm
+      itself does not provide for integrity protection (as DES in CBC
+      mode does not do), then some form of MAC or checksum must be
+      included that can be verified by the receiver.  Some random factor
+      such as a confounder should be included so that an observer cannot
+      know if two messages contain the same plaintext, even if the
+      cipher state and specific keys are the same.  The exact length of
+      the plaintext need not be encoded, but if it is not and if padding
+      is required, the padding must be added at the end of the string so
+      that the decrypted version may be parsed from the beginning.
+
+      The specification of the encryption function must not only
+      indicate the precise contents of the output octet string, but also
+      the output cipher state.  The application protocol may carry
+      forward the output cipher state from one encryption with a given
+      specific key to another; the effect of this "chaining" must be
+      defined.  [2]
+
+      Assuming correctly-produced values for the specific key and cipher
+      state, no input octet string may result in an error indication.
+
+   decrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and ciphertext
+      as inputs, and verifies the integrity of the supplied ciphertext.
+      If the ciphertext's integrity is intact, this function produces
+      the plaintext and a new cipher state as outputs; otherwise, an
+      error indication must be returned, and the data discarded.
+
+      The result of the decryption may be longer than the original
+      plaintext, for example if the encryption mode adds padding to
+      reach a multiple of a block size.  If this is the case, any extra
+      octets must be after the decoded plaintext.  An application
+      protocol which needs to know the exact length of the message must
+      encode a length or recognizable "end of message" marker within the
+      plaintext.  [3]
+
+      As with the encryption function, a correct specification for this
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                             February 2003
+
+
+      function must indicate not only the contents of the output octet
+      string, but also the resulting cipher state.
+
+   pseudo-random (protocol-key, octet-string)->(octet-string)
+      This pseudo-random function should generate an octet string of
+      some size that independent of the octet string input.  The PRF
+      output string should be suitable for use in key generation, even
+      if the octet string input is public.  It should not reveal the
+      input key, even if the output is made public.
+
+   These operations and attributes are all that should be required to
+   support Kerberos and various proposed preauthentication schemes.
+
+   A document defining a new encryption type should also describe known
+   weaknesses or attacks, so that its security may be fairly assessed,
+   and should include test vectors or other validation procedures for
+   the operations defined.  Specific references to information readily
+   available elsewhere are sufficient.
+
+3. Checksum algorithm profile
+
+   A checksum mechanism profile must define the following attributes and
+   operations:
+
+   associated encryption algorithm(s)
+      This indicates the types of encryption keys this checksum
+      mechanism can be used with.
+
+      A keyed checksum mechanism may have more than one associated
+      encryption algorithm if they share the same wire key format,
+      string-to-key function, and key derivation function. (This
+      combination means that, for example, a checksum type, key usage
+      value and password are adequate to get the specific key used to
+      compute a checksum.)
+
+      An unkeyed checksum mechanism can be used in conjunction with any
+      encryption type, since the key is ignored, but its use must be
+      limited to cases where the checksum itself is protected, to avoid
+      trivial attacks.
+
+   get_mic function
+      This function generates a MIC token for a given specific key (see
+      section 2), and message (represented as an octet string), that may
+      be used to verify the integrity of the associated message.  This
+      function is not required to return the same deterministic result
+      on every use; it need only generate a token that the verify_mic
+      routine can check.
+
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                             February 2003
+
+
+      The output of this function will also dictate the size of the
+      checksum.
+
+   verify_mic function
+      Given a specific key, message, and MIC token, this function
+      ascertains whether the message integrity has been compromised.
+      For a deterministic get_mic routine, the corresponding verify_mic
+      may simply generate another checksum and compare them.
+
+   The get_mic and verify_mic operations must be able to handle inputs
+   of arbitrary length; if any padding is needed, the padding scheme
+   must be specified as part of these functions.
+
+   These operations and attributes are all that should be required to
+   support Kerberos and various proposed preauthentication schemes.
+
+   As with encryption mechanism definition documents, documents defining
+   new checksum mechanisms should indicate validation processes and
+   known weaknesses.
+
+4. Simplified profile for CBC ciphers with key derivation
+
+   The profile outlines in sections 2 and 3 describes a large number of
+   operations that must be defined for encryption and checksum
+   algorithms to be used with Kerberos.  We describe here a simpler
+   profile from which both encryption and checksum mechanism definitions
+   can be generated, filling in uses of key derivation in appropriate
+   places, providing integrity protection, and defining multiple
+   operations for the cryptosystem profile based on a smaller set of
+   operations given in the simplified profile.  Not all of the existing
+   cryptosystems for Kerberos fit into this simplified profile, but we
+   recommend that future cryptosystems use it or something based on it.
+   [4]
+
+   Not all of the operations in the complete profiles are defined
+   through this mechanism; several must still be defined for each new
+   algorithm pair.
+
+4.1. A key derivation function
+
+   Rather than define some scheme by which a "protocol key" is composed
+   of a large number of encryption keys, we use keys derived from a base
+   key to perform cryptographic operations.  The base key must be used
+   only for generating the derived keys, and this derivation must be
+   non-invertible and entropy-preserving.  Given these restrictions,
+   compromise of one derived key does not compromise the other subkeys.
+   Attack of the base key is limited, since it is only used for
+   derivation, and is not exposed to any user data.
+
+
+
+Raeburn                                                        [Page 10]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Since the derived key has as much entropy as the base keys (if the
+   cryptosystem is good), password-derived keys have the full benefit of
+   all the entropy in the password.
+
+   To generate a derived key from a base key, we generate a pseudorandom
+   octet string, using an algorithm DR described below, and generate a
+   key from that octet string using a function dependent on the
+   encryption algorithm; the input length needed for that function,
+   which is also dependent on the encryption algorithm, dictates the
+   length of the string to be generated by the DR algorithm (the value
+   "k" below).  These procedures are based on the key derivation in
+   [Blumenthal96].
+
+      Derived Key = DK(Base Key, Well-Known Constant)
+
+      DK(Key, Constant) = random-to-key(DR(Key, Constant))
+
+      DR(Key, Constant) = k-truncate(E(Key, Constant,
+                                       initial-cipher-state))
+
+   Here DR is the random-octet generation function described below, and
+   DK is the key-derivation function produced from it.  In this
+   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
+   a well-known constant determined by the specific usage of this
+   function, and k-truncate truncates its argument by taking the first k
+   bits.  Here, k is the key generation seed length needed for the
+   encryption system.
+
+   The output of the DR function is a string of bits; the actual key is
+   produced by applying the cryptosystem's random-to-key operation on
+   this bitstring.
+
+   If the Constant is smaller than the cipher block size of E, then it
+   must be expanded with n-fold() so it can be encrypted.  If the output
+   of E is shorter than k bits it is fed back into the encryption as
+   many times as necessary.  The construct is as follows (where |
+   indicates concatentation):
+
+      K1 = E(Key, n-fold(Constant), initial-cipher-state)
+      K2 = E(Key, K1, initial-cipher-state)
+      K3 = E(Key, K2, initial-cipher-state)
+      K4 = ...
+
+      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
+
+   n-fold is an algorithm which takes m input bits and ``stretches''
+   them to form n output bits with equal contribution from each input
+   bit to the output, as described in [Blumenthal96]:
+
+
+
+Raeburn                                                        [Page 11]
+
+INTERNET DRAFT                                             February 2003
+
+
+      We first define a primitive called n-folding, which takes a
+      variable-length input block and produces a fixed-length output
+      sequence.  The intent is to give each input bit approximately
+      equal weight in determining the value of each output bit.  Note
+      that whenever we need to treat a string of octets as a number, the
+      assumed representation is Big-Endian -- Most Significant Byte
+      first.
+
+      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, with end-around carry) to yield
+      a n-bit result....
+
+
+   Test vectors for n-fold are supplied in Appendix A.  [5]
+
+   In this section, n-fold is always used to produce c bits of output,
+   where c is the cipher block size of E.
+
+   The size of the Constant must not be larger than c, because reducing
+   the length of the Constant by n-folding can cause collisions.
+
+   If the size of the Constant is smaller than c, then the Constant must
+   be n-folded to length c.  This string is used as input to E.  If the
+   block size of E is less than the random-to-key input size, then the
+   output from E is taken as input to a second invocation of E.  This
+   process is repeated until the number of bits accumulated is greater
+   than or equal to the random-to-key input size.  When enough bits have
+   been computed, the first k are taken as the random data used to
+   create the key with the algorithm-dependent random-to-key function.
+
+   Since the derived key is the result of one or more encryptions in the
+   base key, deriving the base key from the derived key is equivalent to
+   determining the key from a very small number of plaintext/ciphertext
+   pairs.  Thus, this construction is as strong as the cryptosystem
+   itself.
+
+4.2. Simplified profile parameters
+
+   These are the operations and attributes that must be defined:
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 12]
+
+INTERNET DRAFT                                             February 2003
+
+
+   protocol key format
+   string-to-key function
+   default string-to-key parameters
+   key-generation seed length, k
+   random-to-key function
+      As above for the normal encryption mechanism profile.
+
+   unkeyed hash algorithm, H
+      This should be a collision-resistant hash algorithm with fixed-
+      size output, suitable for use in an HMAC [HMAC].  It must support
+      inputs of arbitrary length.  Its output must be at least the
+      message block size (below).
+
+   HMAC output size, h
+      This indicates the size of the leading substring output by the
+      HMAC function that should be used in transmitted messages.  It
+      should be at least half the output size of the hash function H,
+      and at least 80 bits; it need not match the output size.
+
+   message block size, m
+      This is the size of the smallest units the cipher can handle in
+      the mode in which it is being used.  Messages will be padded to a
+      multiple of this size.  If a block cipher is used in a mode that
+      can handle messages that are not multiples of the cipher block
+      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
+      this value would be one octet.  For traditional CBC mode with
+      padding, it will be the underlying cipher's block size.
+
+      This value must be a multiple of 8 bits (one octet).
+
+   encryption/decryption functions, E and D
+      These are basic encryption and decryption functions for messages
+      of sizes that are multiples of the message block size.  No
+      integrity checking or confounder should be included here.  These
+      functions take as input the IV or similar data, a protocol-format
+      key, and a octet string, returning a new IV and octet string.
+
+      The encryption function is not required to use CBC mode, but is
+      assumed to be using something with similar properties.  In
+      particular, prepending a cipher-block-size confounder to the
+      plaintext should alter the entire ciphertext (comparable to
+      choosing and including a random initial vector for CBC mode).
+
+      The result of encrypting one cipher block (of size c, above) must
+      be deterministic, for the random octet generation function DR in
+      the previous section to work.  For best security, it should also
+      be no larger than c.
+
+
+
+
+Raeburn                                                        [Page 13]
+
+INTERNET DRAFT                                             February 2003
+
+
+   cipher block size, c
+      This is the block size of the block cipher underlying the
+      encryption and decryption functions indicated above, used for key
+      derivation and for the size of the message confounder and initial
+      vector.  (If a block cipher is not in use, some comparable
+      parameter should be determined.)  It must be at least 5 octets.
+
+      This is not actually an independent parameter; rather, it is a
+      property of the functions E and D.  It is listed here to clarify
+      the distinction between it and the message block size, m.
+
+   While there are still a number of properties to specify, they are
+   fewer and simpler than in the full profile.
+
+4.3. Cryptosystem profile based on simplified profile
+
+   The above key derivation function is used to produce three
+   intermediate keys.  One is used for computing checksums of
+   unencrypted data.  The other two are used for encrypting and
+   checksumming plaintext to be sent encrypted.
+
+   The ciphertext output is the concatenation of the output of the basic
+   encryption function E and a (possibly truncated) HMAC using the
+   specified hash function H, both applied to the plaintext with a
+   random confounder prefix and sufficient padding to bring it to a
+   multiple of the message block size.  When the HMAC is computed, the
+   key is used in the protocol key form.
+
+   Decryption is performed by removing the (partial) HMAC, decrypting
+   the remainder, and verifying the HMAC.  The cipher state is an
+   initial vector, initialized to zero.
+
+   The substring notation "[1..h]" in the following table should be read
+   as using 1-based indexing; leading substrings are used.
+
+
+                   cryptosystem from simplified profile
+----------------------------------------------------------------------------
+protocol key format       As given.
+
+specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
+
+key-generation seed       As given.
+length
+
+required checksum         As defined below in section 4.4.
+mechanism
+
+
+
+
+Raeburn                                                        [Page 14]
+
+INTERNET DRAFT                                             February 2003
+
+
+                   cryptosystem from simplified profile
+----------------------------------------------------------------------------
+
+cipher state              initial vector (usually of length c)
+
+initial cipher state      all bits zero
+
+encryption function       conf = random string of length c
+                          pad = shortest string to bring confounder
+                                and plaintext to a length that's a
+                                multiple of m
+                          C1 = E(Ke, conf | plaintext | pad,
+                                 oldstate.ivec)
+                          H1 = HMAC(Ki, conf | plaintext | pad)
+                          ciphertext =  C1 | H1[1..h]
+                          newstate.ivec = last c of C1
+
+decryption function       (C1,H1) = ciphertext
+                          P1 = D(Ke, C1, oldstate.ivec)
+                          if (H1 != HMAC(Ki, P1)[1..h])
+                             report error
+                          newstate.ivec = last c of C1
+
+default string-to-key     As given.
+params
+
+pseudo-random function    tmp1 = H(octet-string)
+                          tmp2 = truncate tmp1 to multiple of m
+                          PRF = E(protocol-key, tmp2, initial-cipher-state)
+
+key generation functions:
+
+string-to-key function    As given.
+
+random-to-key function    As given.
+
+key-derivation function   The "well-known constant" used for the DK
+                          function is the key usage number, expressed as
+                          four octets in big-endian order, followed by one
+                          octet indicated below.
+
+                          Kc = DK(base-key, usage | 0x99);
+                          Ke = DK(base-key, usage | 0xAA);
+                          Ki = DK(base-key, usage | 0x55);
+
+
+
+
+
+
+
+Raeburn                                                        [Page 15]
+
+INTERNET DRAFT                                             February 2003
+
+
+4.4. Checksum profiles based on simplified profile
+
+   When an encryption system is defined using the simplified profile
+   given in section 4.2, a checksum algorithm may be defined for it as
+   follows:
+
+
+                checksum mechanism from simplified profile
+             --------------------------------------------------
+             associated cryptosystem   as defined above
+
+             get_mic                   HMAC(Kc, message)[1..h]
+
+             verify_mic                get_mic and compare
+
+   The HMAC function and key Kc are as described in section 4.3.
+
+5. Profiles for Kerberos encryption and checksum algorithms
+
+   These profiles describe the encryption and checksum systems defined
+   for Kerberos.  The astute reader will notice that some of them do not
+   fulfull all of the requirements outlined in previous sections.  These
+   systems are defined for backward compatibility; newer implementations
+   should (whenever possible) attempt to make use of encryption systems
+   which satisfy all of the profile requirements.
+
+   The full list of current encryption and checksum type number
+   assignments, including values currently reserved but not defined in
+   this document, is given in section 7.
+
+5.1. Unkeyed checksums
+
+   These checksum types use no encryption keys, and thus can be used in
+   combination with any encryption type, but may only be used with
+   caution, in limited circumstances where the lack of a key does not
+   provide a window for an attack, preferably as part of an encrypted
+   message.  [6] Keyed checksum algorithms are recommended.
+
+5.1.1. The RSA MD5 Checksum
+
+   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)
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 16]
+
+INTERNET DRAFT                                             February 2003
+
+
+   checksum.  RSA-MD5 is believed to be collision-proof.
+
+                                  rsa-md5
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   rsa-md5(msg)
+
+               verify_mic                get_mic and compare
+
+   The rsa-md5 checksum algorithm is assigned a checksum type number of
+   seven (7).
+
+5.1.2. The RSA MD4 Checksum
+
+   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.
+
+
+                                  rsa-md4
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   md4(msg)
+
+               verify_mic                get_mic and compare
+
+
+   The rsa-md4 checksum algorithm is assigned a checksum type number of
+   two (2).
+
+5.1.3. CRC-32 Checksum
+
+   This CRC-32 checksum calculates a checksum based on a cyclic
+   redundancy check as described in ISO 3309 [CRC], modified as
+   described below.  The resulting checksum is four (4) octets in
+   length.  The CRC-32 is neither keyed nor collision-proof; thus, 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 CRC-32 checksum used in the des-cbc-crc encryption mode is
+   identical to the 32-bit FCS described in ISO 3309 with two
+   exceptions: the sum with the all-ones polynomial times x**k is
+   omitted, and the final remainder is not ones-complemented.  ISO 3309
+   describes the FCS in terms of bits, while this document describes the
+
+
+
+Raeburn                                                        [Page 17]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Kerberos protocol in terms of octets.  To disambiguate the ISO 3309
+   definition for the purpose of computing the CRC-32 in the des-cbc-crc
+   encryption mode, the ordering of bits in each octet shall be assumed
+   to be LSB-first.  Given this assumed ordering of bits within an
+   octet, the mapping of bits to polynomial coefficients shall be
+   identical to that specified in ISO 3309.
+
+   Test values for this modified CRC function are included in appendix
+   A.5.
+
+
+                                   crc32
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   crc32(msg)
+
+               verify_mic                get_mic and compare
+
+
+   The crc32 checksum algorithm is assigned a checksum type number of
+   one (1).
+
+5.2. DES-based encryption and checksum types
+
+   These encryption systems encrypt information under the Data
+   Encryption Standard [DES77] using the cipher block chaining mode
+   [DESM80].  A checksum is computed as described below 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 values
+   of the padding bytes are unspecified.
+
+   Plaintext and DES ciphertext 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 MSB used as the DES input block's MSB, 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; this vector
+   is specified for each encryption system, below.
+
+   The DES specifications [DESI81] identify four 'weak' and twelve
+   'semi-weak' keys; those keys shall not be used for encrypting
+   messages for use in Kerberos.
+
+
+
+
+Raeburn                                                        [Page 18]
+
+INTERNET DRAFT                                             February 2003
+
+
+   A DES key is 8 octets of data.  This consists of 56 bits of actual
+   key data, 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 most significant bit).  See the
+   [DESM80] introduction for reference.
+
+   Encryption data format
+
+   The format for the data to be encrypted includes a one-block
+   confounder, a checksum, the encoded plaintext, and any necessary
+   padding, as described in the following diagram.  The msg-seq field
+   contains the part of the protocol message which is to be encrypted.
+
+                  +-----------+----------+---------+-----+
+                  |confounder | checksum | msg-seq | pad |
+                  +-----------+----------+---------+-----+
+
+   One generates a random confounder of one block, placing it in
+   'confounder'; zeroes out the 'checksum' field (of length appropriate
+   to exactly hold the checksum to be computed); calculates the
+   appropriate checksum over the whole sequence, placing the result in
+   'checksum'; adds the necessary padding; then encrypts using the
+   specified encryption type and the appropriate key.
+
+   String or random-data to key transformation
+
+   To generate a DES key from two UTF-8 text strings (password and
+   salt), the two strings are concatenated, password first, and the
+   result is then padded with zero-valued octets to a multiple of 8
+   octets.
+
+   The top bit of each octet (always zero if the password is plain
+   ASCII, as was assumed when the original specification was written) is
+   discarded, and a bitstring is formed of the remaining seven bits of
+   each octet.  This bitstring is then fan-folded and eXclusive-ORed
+   with itself to produce a 56-bit string.  An eight-octet key is formed
+   from this string, each octet using seven bits from the bit string,
+   leaving the least significant bit unassigned.  The key is then
+   "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
+   0x00000000000000F0.  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 then "corrected" as described above to form the
+
+
+
+Raeburn                                                        [Page 19]
+
+INTERNET DRAFT                                             February 2003
+
+
+   result which is returned as the key.
+
+   For purposes of the string-to-key function, the DES CBC checksum is
+   calculated by CBC encrypting a string using the key as IV and using
+   the final 8 byte block as the checksum.
+
+   Pseudocode follows:
+
+        removeMSBits(8byteblock) {
+          /* Treats a 64 bit block as 8 octets and remove the MSB in
+             each octect (in big endian mode) and concatenates the
+             result.  E.g., input octet string:
+                01110000 01100001 11110011  01110011 11110111 01101111
+                11110010 01100100
+             results in output bit string:
+                1110000 1100001 1110011  1110011 1110111 1101111
+                1110010 1100100  */
+        }
+
+        reverse(56bitblock) {
+          /* Treats a 56-bit block as a binary string and reverse it.
+             E.g., input string:
+                1000001 1010100 1001000  1000101 1001110 1000001
+                0101110 1001101
+             results in output string:
+                1011001 0111010 1000001  0111001 1010001 0001001
+                0010101 1000001  */
+        }
+
+        add_parity_bits(56bitblock) {
+          /* Copies a 56-bit block into a 64-bit block, left shift
+             content in each octet and add DES parity bit.
+             E.g., input string:
+                1100000 0001111 0011100  0110100 1000101 1100100
+                0110110 0010111
+             results in output string:
+                11000001 00011111 00111000  01101000 10001010 11001000
+                01101101 00101111  */
+        }
+
+        key_correction(key) {
+             fixparity(key);
+             if (is_weak_key(key))
+                  key = key XOR 0xF0;
+             return(key);
+        }
+
+
+
+
+
+Raeburn                                                        [Page 20]
+
+INTERNET DRAFT                                             February 2003
+
+
+        mit_des_string_to_key(string,salt) {
+             odd = 1;
+             s = string | salt;
+             tempstring = 0; /* 56-bit string */
+             pad(s); /* with nulls to 8 byte boundary */
+             for (8byteblock in s) {
+                  56bitstring = removeMSBits(8byteblock);
+                  if (odd == 0) reverse(56bitstring);
+                  odd = ! odd;
+                  tempstring = tempstring XOR 56bitstring;
+             }
+             tempkey = key_correction(add_parity_bits(tempstring));
+             key = key_correction(DES-CBC-check(s,tempkey));
+             return(key);
+        }
+
+        des_string_to_key(string,salt,params) {
+             if (length(params) == 0)
+                  type = 0;
+             else if (length(params) == 1)
+                  type = params[0];
+             else
+                  error("invalid params");
+             if (type == 0)
+                  mit_des_string_to_key(string,salt);
+             else
+                  error("invalid params");
+        }
+
+   One common extension is to support the "AFS string-to-key" algorithm,
+   which is not defined here, if the type value above is one (1).
+
+   For generation of a key from a random bit-string, we start with a
+   56-bit string, and as with the string-to-key operation above, insert
+   parity bits, and if the result is a weak or semi-weak key, modify it
+   by exclusive-OR with the constart 0x00000000000000F0:
+
+        des_random_to_key(bitstring) {
+             return key_correction(add_parity_bits(bitstring));
+        }
+
+5.2.1. DES with MD5
+
+   The des-cbc-md5 encryption mode encrypts information under DES in CBC
+   mode with an all-zero initial vector, with an MD5 checksum (described
+   in [MD5-92]) computed and placed in the checksum field.
+
+
+
+
+
+Raeburn                                                        [Page 21]
+
+INTERNET DRAFT                                             February 2003
+
+
+   The encryption system parameters for des-cbc-md5 are:
+
+                                des-cbc-md5
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md5-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     all-zero
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = md5(confounder | 0000...
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            des_random_to_key
+
+    key-derivation           identity
+
+   The des-cbc-md5 encryption type is assigned the etype value three
+   (3).
+
+
+
+
+
+
+Raeburn                                                        [Page 22]
+
+INTERNET DRAFT                                             February 2003
+
+
+5.2.2. DES with MD4
+
+   The des-cbc-md4 encryption mode also encrypts information under DES
+   in CBC mode, with an all-zero initial vector.  An MD4 checksum
+   (described in [MD4-92]) is computed and placed in the checksum field.
+
+                                des-cbc-md4
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md4-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     all-zero
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = md4(confounder | 0000...
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            copy input, then fix parity bits
+
+    key-derivation           identity
+
+
+
+
+
+Raeburn                                                        [Page 23]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
+
+   The des-cbc-md4 encryption algorithm is assigned the etype value two
+   (2).
+
+5.2.3. DES with CRC
+
+   The des-cbc-crc encryption type uses DES in CBC mode with the key
+   used as the initialization vector, with a 4-octet CRC-based checksum
+   computed as described in section 5.1.3.  Note that this is not a
+   standard CRC-32 checksum, but a slightly modified one.
+
+
+                                des-cbc-crc
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md5-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     copy of original key
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = crc(confounder | 00000000
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+
+
+
+Raeburn                                                        [Page 24]
+
+INTERNET DRAFT                                             February 2003
+
+
+                                des-cbc-crc
+    --------------------------------------------------------------------
+
+    string-to-key            des_string_to_key
+
+    random-to-key            copy input, then fix parity bits
+
+    key-derivation           identity
+
+   The des-cbc-crc encryption algorithm is assigned the etype value one
+   (1).
+
+5.2.4. RSA MD5 Cryptographic Checksum Using 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 0xF0F0F0F0F0F0F0F0.  The
+   initialization vector should be zero.  The resulting checksum is 24
+   octets long.  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.
+
+
+                                rsa-md5-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md5(conf | msg))
+
+      verify_mic                decrypt and verify rsa-md5 checksum
+
+
+   The rsa-md5-des checksum algorithm is assigned a checksum type number
+   of eight (8).
+
+5.2.5. RSA MD4 Cryptographic Checksum Using 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 [MD4-92], and encrypting the confounder and
+   the checksum using DES in cipher-block-chaining (CBC) mode using a
+
+
+
+Raeburn                                                        [Page 25]
+
+INTERNET DRAFT                                             February 2003
+
+
+   variant of the key, where the variant is computed by eXclusive-ORing
+   the key with the constant 0xF0F0F0F0F0F0F0F0.  [7] The initialization
+   vector should be zero.  The resulting checksum is 24 octets long.
+   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.
+
+                                rsa-md4-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md4(conf | msg),
+                                        ivec=0)
+
+      verify_mic                decrypt and verify rsa-md4 checksum
+
+   The rsa-md4-des checksum algorithm is assigned a checksum type number
+   of three (3).
+
+5.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
+
+   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.
+
+
+                               rsa-md4-des-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key, md4(msg), ivec=key)
+
+      verify_mic                decrypt, compute checksum and compare
+
+
+   The rsa-md4-des-k checksum algorithm is assigned a checksum type
+   number of six (6).
+
+
+
+
+
+
+
+Raeburn                                                        [Page 26]
+
+INTERNET DRAFT                                             February 2003
+
+
+5.2.7. DES CBC checksum
+
+   The DES-MAC checksum is computed by prepending an 8 octet confounder
+   to the plaintext, padding with zero-valued octets if necessary to
+   bring the length to a multiple of 8 octets, 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 variant of the key, where the variant is computed
+   by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0.  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.
+
+
+                                  des-mac
+   ----------------------------------------------------------------------
+   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
+   cryptosystem
+
+   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                          conf | des-mac(key, conf | msg | pad, ivec=0),
+                          ivec=0)
+
+   verify_mic     decrypt, compute DES MAC using confounder, compare
+
+
+   The des-mac checksum algorithm is assigned a checksum type number of
+   four (4).
+
+5.2.8. DES CBC checksum alternative
+
+   The DES-MAC-K checksum is computed by performing a DES CBC-mode
+   encryption of the plaintext, with zero-valued padding bytes if
+   necessary to bring the length to a multiple of 8 octets, and using
+   the last block of the ciphertext as the checksum value.  It is keyed
+   with an encryption key which is also used as the 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 DESMAC checksum and
+   it is no longer recommended.
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 27]
+
+INTERNET DRAFT                                             February 2003
+
+
+                                 des-mac-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-mac(key, msg | pad, ivec=key)
+
+      verify_mic                compute MAC and compare
+
+
+   The des-mac-k checksum algorithm is assigned a checksum type number
+   of five (5).
+
+5.3. Triple-DES based encryption and checksum types
+
+   This encryption and checksum type pair is based on the Triple DES
+   cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
+   authentication algorithm.
+
+   A Triple DES key is the concatenation of three DES keys as described
+   above for des-cbc-md5.  A Triple DES key is generated from random
+   data by creating three DES keys from separate sequences of random
+   data.
+
+   Encrypted data using this type must be generated as described in
+   section 4.3.  If the length of the input data is not a multiple of
+   the block size, zero-valued octets must be used to pad the plaintext
+   to the next eight-octet boundary.  The confounder must be eight
+   random octets (one block).
+
+   The simplified profile for Triple DES, with key derivation as defined
+   in section 4, is as follows:
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              protocol key format     24 bytes, parity in low
+                                      bit of each
+
+              key-generation seed     21 bytes
+              length
+
+              hash function           SHA-1
+
+              HMAC output size        160 bits
+
+              message block size      8 bytes
+
+
+
+
+
+
+Raeburn                                                        [Page 28]
+
+INTERNET DRAFT                                             February 2003
+
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              default string-to-key   empty string
+              params
+
+              encryption and          triple-DES encrypt and
+              decryption functions    decrypt, in outer-CBC
+                                      mode (cipher block size
+                                      8 octets)
+
+              key generation functions:
+
+              random-to-key           DES3random-to-key (see
+                                      below)
+
+              string-to-key           DES3string-to-key (see
+                                      below)
+
+   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
+   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
+   checksum type number of twelve (12).
+
+5.3.1. Triple DES Key Production (random-to-key, string-to-key)
+
+   The 168 bits of random key data are converted to a protocol key value
+   as follows.  First, the 168 bits are divided into three groups of 56
+   bits, which are expanded individually into 64 bits as follows:
+
+   DES3random-to-key:
+         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 protocol key
+   value.
+
+   The string-to-key function is used to transform UTF-8 passwords into
+   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
+   algorithm and DK function, described in section 4.
+
+   The n-fold algorithm is applied to the password string concatenated
+   with a salt value.  For 3-key triple DES, the operation will involve
+
+
+
+Raeburn                                                        [Page 29]
+
+INTERNET DRAFT                                             February 2003
+
+
+   a 168-fold of the input password string, to generate an intermediate
+   key, from which the user's long-term key will be derived with the DK
+   function.  The DES3 string-to-key function is shown here in
+   pseudocode:
+
+         DES3string-to-key(passwordString, salt, params)
+             if (params != emptyString)
+              error("invalid params");
+             s = passwordString + salt
+             tmpKey = random-to-key(168-fold(s))
+             key = DK (tmpKey, KerberosConstant)
+
+   No weak-key checking is performed.  The KerberosConstant value is the
+   byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}.  These values
+   correspond to the ASCII encoding for the string "kerberos".
+
+6. Use of Kerberos encryption outside this specification
+
+   Several Kerberos-based application protocols and preauthentication
+   systems have been designed and deployed that perform encryption and
+   message integrity checks in various ways.  While in some cases there
+   may be good reason for specifying these protocols in terms of
+   specific encryption or checksum algorithms, we anticipate that in
+   many cases this will not be true, and more generic approaches
+   independent of particular algorithms will be desirable.  Rather than
+   having each protocol designer reinvent schemes for protecting data,
+   using multiple keys, etc, we have attempted to present in this
+   section a general framework that should be sufficient not only for
+   the Kerberos protocol itself but also for many preauthentication
+   systems and application protocols, while trying to avoid some of the
+   assumptions that can work their way into such protocol designs.
+
+   Some problematic assumptions we've seen (and sometimes made) include:
+   that a random bitstring is always valid as a key (not true for DES
+   keys with parity); that the basic block encryption chaining mode
+   provides no integrity checking, or can easily be separated from such
+   checking (not true for many modes in development that do both
+   simultaneously); that a checksum for a message always results in the
+   same value (not true if a confounder is incorporated); that an
+   initial vector is used (may not be true if a block cipher in CBC mode
+   is not in use).
+
+   Such assumptions, while they may hold for any given set of encryption
+   and checksum algorithms, may not be true of the next algorithms to be
+   defined, leaving the application protocol unable to make use of those
+   algorithms without updates to its specification.
+
+   The Kerberos protocol uses only the attributes and operations
+
+
+
+Raeburn                                                        [Page 30]
+
+INTERNET DRAFT                                             February 2003
+
+
+   described in sections 2 and 3.  Preauthentication systems and
+   application protocols making use of Kerberos are encouraged to use
+   them as well.  The specific key and string-to-key parameters should
+   generally be treated as opaque.  While the string-to-key parameters
+   are manipulated as an octet string, the representation for the
+   specific key structure is implementation-defined; it may not even be
+   a single object.
+
+   While we don't recommend it, some application protocols will
+   undoubtedly continue to use the key data directly, even if only in
+   some of the currently existing protocol specifications.  An
+   implementation intended to support general Kerberos applications may
+   therefore need to make the key data available, as well as the
+   attributes and operations described in sections 2 and 3.  [8]
+
+7. Assigned Numbers
+
+   The following encryption type numbers are already assigned or
+   reserved for use in Kerberos and related protocols.
+
+
+     encryption type                etype      section or comment
+     -----------------------------------------------------------------
+     des-cbc-crc                        1             5.2.3
+     des-cbc-md4                        2             5.2.2
+     des-cbc-md5                        3             5.2.1
+     [reserved]                         4
+     des3-cbc-md5                       5
+     [reserved]                         6
+     des3-cbc-sha1                      7
+     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              5.3
+     aes128-cts-hmac-sha1-96           17          [KRB5-AES]
+     aes256-cts-hmac-sha1-96           18          [KRB5-AES]
+     rc4-hmac                          23          (Microsoft)
+     rc4-hmac-exp                      24          (Microsoft)
+     subkey-keymaterial                65     (opaque; PacketCable)
+
+
+   (The "des3-cbc-sha1" assignment is a deprecated version using no key
+   derivation.  It should not be confused with des3-cbc-sha1-kd.)
+
+
+
+
+Raeburn                                                        [Page 31]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Several numbers have been reserved for use in encryption systems not
+   defined here.  Encryption type numbers have unfortunately been
+   overloaded on occasion in Kerberos-related protocols, so some of the
+   reserved numbers do not and will not correspond to encryption systems
+   fitting the profile presented here.
+
+   The following checksum type numbers are assigned or reserved.  As
+   with encryption type numbers, some overloading of checksum numbers
+   has occurred.
+
+
+   Checksum type              sumtype        checksum         section or
+                                value            size         reference
+   ----------------------------------------------------------------------
+   CRC32                            1               4           5.1.3
+   rsa-md4                          2              16           5.1.2
+   rsa-md4-des                      3              24           5.2.5
+   des-mac                          4              16           5.2.7
+   des-mac-k                        5               8           5.2.8
+   rsa-md4-des-k                    6              16           5.2.6
+   rsa-md5                          7              16           5.1.1
+   rsa-md5-des                      8              24           5.2.4
+   rsa-md5-des3                     9              24             ??
+   sha1 (unkeyed)                  10              20             ??
+   hmac-sha1-des3-kd               12              20            5.3
+   hmac-sha1-des3                  13              20             ??
+   sha1 (unkeyed)                  14              20             ??
+   hmac-sha1-96-aes128             15              20         [KRB5-AES]
+   hmac-sha1-96-aes256             16              20         [KRB5-AES]
+   [reserved]                  0x8003               ?         [GSS-KRB5]
+
+
+   Encryption and checksum type numbers are signed 32-bit values.  Zero
+   is invalid, and negative numbers are reserved for local use.  All
+   standardized values must be positive.
+
+8. Implementation Notes
+
+   The "interface" described here is the minimal information that must
+   be defined to make a cryptosystem useful within Kerberos in an
+   interoperable fashion.  Despite the functional notation used in some
+   places, it is not an attempt to define an API for cryptographic
+   functionality within Kerberos.  Actual implementations providing
+   clean APIs will probably find it useful to make additional
+   information available, which should be possible to derive from a
+   specification written to the framework given here.  For example, an
+   application designer may wish to determine the largest number of
+   bytes that can be encrypted without overflowing a certain size output
+
+
+
+Raeburn                                                        [Page 32]
+
+INTERNET DRAFT                                             February 2003
+
+
+   buffer, or conversely, the maximum number of bytes that might be
+   obtained by decrypting a ciphertext message of a given size.  (In
+   fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
+   will require some of these.)
+
+   The presence of a mechanism in this document should not be taken as
+   an indication that it must be implemented for compliance with any
+   specification; required mechanisms will be specified elsewhere.
+   Indeed, some of the mechanisms described here for backwards
+   compatibility are now considered rather weak for protecting critical
+   data.
+
+9. Security Considerations
+
+   Recent years have brought advancements in the ability to perform
+   large-scale attacks against DES, to such a degree that it is not
+   considered a strong encryption mechanism any longer; triple-DES is
+   generally preferred in its place, despite the poorer performance.
+   See [ESP-DES] for a summary of some of the potential attacks, and
+   [EFF-DES] for a detailed discussion of the implementation of
+   particular attack.  However, most Kerberos implementations still have
+   DES as their primary interoperable encryption type.
+
+   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
+   single-DES here avoids them. However, DES also has 48 'possibly-weak'
+   keys [Schneier96] (note that the tables in many editions of the
+   reference contains errors) which are not avoided.
+
+   DES weak keys are keys with the property that E1(E1(P)) = P (where E1
+   denotes encryption of a single block with key 1).  DES semi-weak keys
+   or "dual" keys are pairs of keys with the property that E1(P) =
+   D2(P), and thus E2(E1(P)) = P.  Because of the use of CBC mode and
+   leading random confounder, however, these properties are unlikely to
+   present a security problem.
+
+   The use of triple-DES in Kerberos makes no effort to avoid these
+   keys.  The nature of the weak keys is such that it is extremely
+   unlikely that they will weaken the triple-DES encryption -- only
+   slightly more likely than having the middle of the three sub-keys
+   match one of the other two, which effectively converts the encryption
+   to single-DES, which is another case we make no effort to avoid.
+
+   The true 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 of course recommended for environments where such
+   attacks represent a significant threat.  The "simplifications" (read:
+   bugs) introduced when CRC-32 was implemented for Kerberos cause
+
+
+
+Raeburn                                                        [Page 33]
+
+INTERNET DRAFT                                             February 2003
+
+
+   leading zeros to effectively be ignored, so messages differing only
+   in leading zero bits will have the same checksum.
+
+   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
+   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
+   the suggested truncation of the HMAC output.  As pointed out in
+   [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
+   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
+   vectors for HMAC-SHA-1.
+
+   The mit_des_string_to_key function was originally constructed with
+   the assumption that all input would be ASCII; it ignores the top bit
+   of each input byte.  Folding with XOR is also not an especially good
+   mixing mechanism in terms of preserving randomness.
+
+   The n-fold function used in the string-to-key operation for des3-cbc-
+   hmac-sha1-kd was designed to cause each bit of input to contribute
+   equally to the output; it was not designed to maximize or equally
+   distribute randomness in the input, and there are conceivable cases
+   of partially structured input where randomness may be lost.  This
+   should only be an issue for highly structured passwords, however.
+
+   [RFC1851] discusses the relative strength of triple-DES encryption.
+   The relative slow speed of triple-DES encryption may also be an issue
+   for some applications.
+
+   This document, like the Kerberos protocol, completely ignores the
+   notion of limiting the amount of data a key may be used with to a
+   quantity based on the robustness of the algorithm or size of the key.
+   It is assumed that any defined algorithms and key sizes will be
+   strong enough to support very large amounts of data, or they will be
+   deprecated once significant attacks are known.
+
+   This document also places no bounds on the amount of data that can be
+   handled in various operations.  In order to avoid denial of service
+   attacks, implementations will probably want to restrict message sizes
+   at some higher level.
+
+10. IANA Considerations
+
+   None at present.  The management of encryption and checksum type
+   number assignments may be transferred to IANA at some future time.
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 34]
+
+INTERNET DRAFT                                             February 2003
+
+
+11. Acknowledgments
+
+   This document is an extension of the encryption specification
+   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
+   of the text of the background, concepts, and DES specifications are
+   drawn directly from that document.
+
+   The abstract framework presented in this document was put together by
+   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
+   and Tom Yu, and the details were refined several times based on
+   comments from John Brezak and others.
+
+   Marc Horowitz wrote the original specification of triple-DES and key
+   derivation in a pair of Internet Drafts (under the names draft-
+   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
+   were later folded into a draft revision of [Kerb1510], from which
+   this document was later split off.
+
+   Tom Yu provided the text describing the modifications to the standard
+   CRC algorithm as Kerberos implementations actually use it.
+
+   Miroslav Jurisic provided information for one of the UTF-8 test cases
+   for the string-to-key functions.
+
+   Marcus Watts noticed some errors in earlier drafts, and pointed out
+   that the simplified profile could easily be modified to support
+   cipher text stealing modes.
+
+   Simon Josefsson contributed some clarifications to the DES "CBC
+   checksum", string-to-key and weak key descriptions, and some test
+   vectors.
+
+   Simon Josefsson, Louis LeVay and others also caught some errors in
+   earlier drafts.
+
+12. Editor's address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 35]
+
+INTERNET DRAFT                                             February 2003
+
+
+13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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."
+
+A. Test vectors
+
+   This section provides test vectors for various functions defined or
+   described in this document.  For convenience, most inputs are ASCII
+   strings, though some UTF-8 samples are be provided for string-to-key
+   functions.  Keys and other binary data are specified as hexadecimal
+   strings.
+
+A.1. n-fold
+
+   The n-fold function is defined in section 4.1.  As noted there, the
+   sample vector in the original paper defining the algorithm appears to
+   be incorrect.  Here are some test cases provided by Marc Horowitz and
+   Simon Josefsson:
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 36]
+
+INTERNET DRAFT                                             February 2003
+
+
+      64-fold("012345") =
+      64-fold(303132333435) = be072631276b1955
+
+      56-fold("password") =
+      56-fold(70617373776f7264) = 78a07b6caf85fa
+
+      64-fold("Rough Consensus, and Running Code") =
+      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
+              6e696e6720436f6465) = bb6ed30870b7f0e0
+
+      168-fold("password") =
+      168-fold(70617373776f7264) =
+               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
+
+      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
+      192-fold(4d41535341434856534554545320494e5354495456544520
+               4f4620544543484e4f4c4f4759) =
+               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
+
+      168-fold("Q") =
+      168-fold(51) =
+               518a54a2 15a8452a 518a54a2 15a8452a
+               518a54a2 15
+
+      168-fold("ba") =
+      168-fold(6261) =
+               fb25d531 ae897449 9f52fd92 ea9857c4
+               ba24cf29 7e
+
+   Here are some additional values corresponding to folded values of the
+   string "kerberos"; the 64-bit form is used in the des3 string-to-key
+   (section 5.3.1).
+
+      64-fold("kerberos") =
+               6b657262 65726f73
+      128-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+      168-fold("kerberos") =
+               8372c236 344e5f15 50cd0747 e15d62ca
+               7a5a3bce a4
+      256-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+               5c9bdcda d95c9899 c4cae4de e6d6cae4
+
+   Note that the initial octets exactly match the input string when the
+   output length is a multiple of the input length.
+
+
+
+
+
+Raeburn                                                        [Page 37]
+
+INTERNET DRAFT                                             February 2003
+
+
+A.2. mit_des_string_to_key
+
+   The function mit_des_string_to_key is defined in section 5.2.  We
+   present here several test values, with some of the intermediate
+   results.  The fourth test demonstrates the use of UTF-8 with three
+   characters.  The last two tests are specifically constructed so as to
+   trigger the weak-key fixups for the intermediate key produced by fan-
+   folding; we have no test cases that cause such fixups for the final
+   key.
+
+
+   UTF-8 encodings used in test vector:
+   eszett     C3 9F            s-caron     C5 A1      c-acute     C4 87
+   g-clef     F0 9D 84 9E
+
+
+   Test vector:
+
+
+   salt:        "ATHENA.MIT.EDUraeburn"
+                              415448454e412e4d49542e4544557261656275726e
+   password:    "password"    70617373776f7264
+   fan-fold result:           c01e38688ac86c2e
+   intermediate key:          c11f38688ac86d2f
+   DES key:                   cbc22fae235298e3
+
+
+
+   salt:       "WHITEHOUSE.GOVdanny"   5748495445484f5553452e474f5664616e6e79
+   password:   "potatoe"               706f7461746f65
+   fan-fold result:                    a028944ee63c0416
+   intermediate key:                   a129944fe63d0416
+   DES key:                            df3d32a74fd92a01
+
+
+
+   salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
+   password:  g-clef                f09d849e
+   fan-fold result:                 3c4a262c18fab090
+   intermediate key:                3d4a262c19fbb091
+   DES key:                         4ffb26bab0cd9413
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 38]
+
+INTERNET DRAFT                                             February 2003
+
+
+   salt:        "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
+                          415448454e412e4d49542e4544554a757269c5a169c487
+   password:    eszett    c39f
+   fan-fold result:       b8f6c40e305afc9e
+   intermediate key:      b9f7c40e315bfd9e
+   DES key:               62c81a5232b5e69d
+
+
+
+   salt:       "AAAAAAAA"   4141414141414141
+   password:   "11119999"   3131313139393939
+   fan-fold result:         e0e0e0e0f0f0f0f0
+   intermediate key:        e0e0e0e0f1f1f101
+   DES key:                 984054d0f1a73e31
+
+
+
+   salt:       "FFFFAAAA"   4646464641414141
+   password:   "NNNN6666"   4e4e4e4e36363636
+   fan-fold result:         1e1e1e1e0e0e0e0e
+   intermediate key:        1f1f1f1f0e0e0efe
+   DES key:                 c4bf6b25adf7a4f8
+
+
+   This trace provided by Simon Josefsson shows the intermediate
+   processing stages of one of the test inputs:
+
+     string_to_key (des-cbc-md5, string, salt)
+            ;; string:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; salt:
+            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+            ;; 65 62 75 72 6e
+     des_string_to_key (string, salt)
+            ;; String:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; Salt:
+            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+            ;; 65 62 75 72 6e
+     odd = 1;
+     s = string | salt;
+
+
+
+
+
+
+Raeburn                                                        [Page 39]
+
+INTERNET DRAFT                                             February 2003
+
+
+     tempstring = 0; /* 56-bit string */
+     pad(s); /* with nulls to 8 byte boundary */
+            ;; s = pad(string|salt):
+            ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
+            ;; (length 32 bytes)
+            ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
+            ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
+     for (8byteblock in s) {
+            ;; loop iteration 0
+            ;; 8byteblock:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; 01110000 01100001 01110011  01110011 01110111 01101111
+            ;; 01110010 01100100
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1110000 1100001 1110011  1110011 1110111 1101111
+            ;; 1110010 1100100
+     if (odd == 0) reverse(56bitstring);    ;; odd=1
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1110000 1100001 1110011  1110011 1110111 1101111
+            ;; 1110010 1100100
+
+     for (8byteblock in s) {
+            ;; loop iteration 1
+            ;; 8byteblock:
+            ;; `ATHENA.M' (length 8 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d
+            ;; 01000001 01010100 01001000  01000101 01001110 01000001
+            ;; 00101110 01001101
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1000001 1010100 1001000  1000101 1001110 1000001
+            ;; 0101110 1001101
+     if (odd == 0) reverse(56bitstring);    ;; odd=0
+     reverse(56bitstring)
+            ;; 56bitstring after reverse
+            ;; 1011001 0111010 1000001  0111001 1010001 0001001
+            ;; 0010101 1000001
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 0101001 1011011 0110010  1001010 0100110 1100110
+            ;; 1100111 0100101
+
+
+
+
+
+Raeburn                                                        [Page 40]
+
+INTERNET DRAFT                                             February 2003
+
+
+     for (8byteblock in s) {
+            ;; loop iteration 2
+            ;; 8byteblock:
+            ;; `IT.EDUra' (length 8 bytes)
+            ;; 49 54 2e 45 44 55 72 61
+            ;; 01001001 01010100 00101110  01000101 01000100 01010101
+            ;; 01110010 01100001
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1001001 1010100 0101110  1000101 1000100 1010101
+            ;; 1110010 1100001
+     if (odd == 0) reverse(56bitstring);    ;; odd=1
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1100000 0001111 0011100  0001111 1100010 0110011
+            ;; 0010101 1000100
+
+     for (8byteblock in s) {
+            ;; loop iteration 3
+            ;; 8byteblock:
+            ;; `eburn\x00\x00\x00' (length 8 bytes)
+            ;; 65 62 75 72 6e 00 00 00
+            ;; 01100101 01100010 01110101  01110010 01101110 00000000
+            ;; 00000000 00000000
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1100101 1100010 1110101  1110010 1101110 0000000
+            ;; 0000000 0000000
+     if (odd == 0) reverse(56bitstring);    ;; odd=0
+     reverse(56bitstring)
+            ;; 56bitstring after reverse
+            ;; 0000000 0000000 0000000  0111011 0100111 1010111
+            ;; 0100011 1010011
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1100000 0001111 0011100  0110100 1000101 1100100
+            ;; 0110110 0010111
+
+     for (8byteblock in s) {
+     }
+            ;; for loop terminated
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 41]
+
+INTERNET DRAFT                                             February 2003
+
+
+     tempkey = key_correction(add_parity_bits(tempstring));
+            ;; tempkey
+            ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
+            ;; c1 1f 38 68 8a c8 6d 2f
+            ;; 11000001 00011111 00111000  01101000 10001010 11001000
+            ;; 01101101 00101111
+
+     key = key_correction(DES-CBC-check(s,tempkey));
+            ;; key
+            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+            ;; cb c2 2f ae 23 52 98 e3
+            ;; 11001011 11000010 00101111  10101110 00100011 01010010
+            ;; 10011000 11100011
+
+            ;; string_to_key key:
+            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+            ;; cb c2 2f ae 23 52 98 e3
+
+
+A.3. DES3 DR and DK
+
+   These tests show the derived-random and derived-key values for the
+   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
+   defined in section 5.3.1.  The input keys were randomly generated;
+   the usage values are from this specification.
+
+
+   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
+   usage:               0000000155
+   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
+   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
+
+   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
+   usage:               00000001aa
+   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
+   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
+
+   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
+   usage:               0000000155
+   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
+   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
+
+   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
+   usage:               00000001aa
+   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
+   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
+
+
+
+
+
+Raeburn                                                        [Page 42]
+
+INTERNET DRAFT                                             February 2003
+
+
+   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
+   usage:               6b65726265726f73 ("kerberos")
+   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
+   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
+
+   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
+   usage:               0000000155
+   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
+   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
+
+   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
+   usage:               00000001aa
+   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
+   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
+
+   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
+   usage:               0000000155
+   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
+   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
+
+   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
+   usage:               00000001aa
+   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
+   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
+
+
+A.4. DES3string_to_key
+
+   These are the keys generated for some of the above input strings for
+   triple-DES with key derivation as defined in section 5.3.1.
+
+    salt:   "ATHENA.MIT.EDUraeburn"
+    passwd: "password"
+    key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
+
+    salt:   "WHITEHOUSE.GOVdanny"
+    passwd: "potatoe"
+    key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
+
+    salt:   "EXAMPLE.COMbuckaroo"
+    passwd: "penny"
+    key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
+
+    salt:   "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
+    passwd: eszett
+    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
+
+
+
+
+
+Raeburn                                                        [Page 43]
+
+INTERNET DRAFT                                             February 2003
+
+
+    salt:   "EXAMPLE.COMpianist"
+    passwd: g-clef
+    key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
+
+A.5. Modified CRC-32
+
+   Below are modified-CRC32 values for various ASCII and octet strings.
+   Only the printable ASCII characters are checksummed, no C-style
+   trailing zero-valued octet.  The 32-bit modified CRC and the sequence
+   of output bytes as used in Kerberos are shown.  (The octet values are
+   separated here to emphasize that they are octet values and not 32-bit
+   numbers, which will be the most convenient form for manipulation in
+   some implementations.  The bit and byte order used internally for
+   such a number is irrelevant; the octet sequence generated is what is
+   important.)
+
+
+    mod-crc-32("foo") =                                     33 bc 32 73
+    mod-crc-32("test0123456789") =                          d6 88 3e b8
+    mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
+    mod-crc-32(8000) =                                      4b 98 83 3b
+    mod-crc-32(0008) =                                      32 88 db 0e
+    mod-crc-32(0080) =                                      20 83 b8 ed
+    mod-crc-32(80) =                                        20 83 b8 ed
+    mod-crc-32(80000000) =                                  3b b6 59 ed
+    mod-crc-32(00000001) =                                  96 30 07 77
+
+
+B. Significant Changes from RFC 1510
+
+   The encryption and checksum mechanism profiles are new.  The old
+   specification defined a few operations for various mechanisms, but
+   didn't outline what should be required of new mechanisms in terms of
+   abstract properties, nor how to ensure that a mechanism specification
+   is complete enough for interoperability between implementations.  The
+   new profiles do differ from the old specification in a few ways:
+
+      Some message definitions in [Kerb1510] could be read as permitting
+      the initial vector to be specified by the application; the text
+      was too vague.  It is specifically not permitted in this
+      specification.  Some encryption algorithms may not use
+      initialization vectors, so relying on chosen, secret
+      initialization vectors for security is unwise.  Also, the
+      prepended confounder in the existing algorithms is roughly
+      equivalent to a per-message initialization vector that is revealed
+      in encrypted form.  However, carrying state across from one
+      encryption to another is explicitly permitted through the opaque
+      "cipher state" object.
+
+
+
+Raeburn                                                        [Page 44]
+
+INTERNET DRAFT                                             February 2003
+
+
+      The use of key derivation is new.
+
+      Several new methods are introduced, including generation of a key
+      in wire-protocol format from random input data.
+
+      The means for influencing the string-to-key algorithm are laid out
+      more clearly.
+
+   Triple-DES support is new.
+
+   The pseudo-random function is new.
+
+   The des-cbc-crc, DES string-to-key and CRC descriptions have been
+   updated to align them with existing implementations.
+
+   [Kerb1510] had no indication what character set or encoding might be
+   used for pass phrases and salts.
+
+   In [Kerb1510], key types, encryption algorithms and checksum
+   algorithms were only loosely associated, and the association was not
+   well described.  In this specification, key types and encryption
+   algorithms have a one-to-one correspondence, and associations between
+   encryption and checksum algorithms are described so that checksums
+   can be computed given negotiated keys, without requiring further
+   negotiation for checksum types.
+
+Notes
+
+   [1] While Message Authentication Code (MAC) or Message Integrity
+       Check (MIC) would be more appropriate terms for many of the
+       uses in this document, we continue to use the term "checksum"
+       for historical reasons.
+
+   [2] Extending CBC mode across messages would be one obvious
+       example of this chaining.  Another might be the use of
+       counter mode, with a counter randomly initialized and
+       attached to the ciphertext; a second message could continue
+       incrementing the counter when chaining the cipher state, thus
+       avoiding having to transmit another counter value.  However,
+       this chaining is only useful for uninterrupted, ordered
+       sequences of messages.
+
+   [3] In the case of Kerberos, the encrypted objects will generally
+       be ASN.1 DER encodings, which contain indications of their
+       length in the first few octets.
+
+   [4] As of the time of this writing, some new modes of operation
+       have been proposed, some of which may permit encryption and
+
+
+
+Raeburn                                                        [Page 45]
+
+INTERNET DRAFT                                             February 2003
+
+
+       integrity protection simultaneously.  After some of these
+       proposals have been subjected to adequate analysis, we may
+       wish to formulate a new simplified profile based on one of
+       them.
+
+   [5] It should be noted that the sample vector in Appendix B.2 of
+       the original paper appears to be incorrect.  Two independent
+       implementations from the specification (one in C by Marc
+       Horowitz, and another in Scheme by Bill Sommerfeld) agree on
+       a value different from that in [Blumenthal96].
+
+   [6] For example, in MIT's implementation of [Kerb1510], the rsa-
+       md5 unkeyed checksum of application data may be included in
+       an authenticator encrypted in a service's key; since rsa-md5
+       is believed to be collision-proof, even if the application
+       data is exposed to an attacker, it cannot be modified without
+       causing the checksum verification to fail.
+
+   [7] 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 0xF0F0F0F0F0F0F0F0 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.
+
+   [8] Perhaps one of the more common reasons for directly
+       performing encryption is direct control over the negotiation
+       and to select a "sufficiently strong" encryption algorithm
+       (whatever that means in the context of a given application).
+       While Kerberos directly provides no facility for negotiating
+       encryption types between the application client and server,
+       there are other means for accomplishing similar goals.  For
+       example, requesting only "strong" session key types from the
+       KDC, and assuming that the type actually returned by the KDC
+       will be understood and supported by the application server.
+
+Normative References
+
+   [Bellare98]
+      Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
+      "Relations Among Notions of Security for Public-Key Encryption
+      Schemes".  Extended abstract published in Advances in Cryptology-
+      Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
+      1462, H. Krawcyzk ed., Springer-Verlag, 1998.
+
+
+
+
+
+Raeburn                                                        [Page 46]
+
+INTERNET DRAFT                                             February 2003
+
+
+   [Blumenthal96]
+      Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
+      Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
+   [CRC]
+      International Organization for Standardization, "ISO Information
+      Processing Systems - Data Communication - High-Level Data Link
+      Control Procedure - Frame Structure," IS 3309, 3rd Edition,
+      October 1984.
+   [DES77]
+      National Bureau of Standards, U.S. Department of Commerce, "Data
+      Encryption Standard," Federal Information Processing Standards
+      Publication 46, Washington, DC, 1977.
+   [DESI81]
+      National Bureau of Standards, U.S. Department of Commerce,
+      "Guidelines for implementing and using NBS Data Encryption
+      Standard," Federal Information Processing Standards Publication
+      74, Washington, DC, 1981.
+   [DESM80]
+      National Bureau of Standards, U.S. Department of Commerce, "DES
+      Modes of Operation," Federal Information Processing Standards
+      Publication 81, Springfield, VA, December 1980.
+   [Dolev91]
+      Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
+      Proceedings of the 23rd Annual Symposium on Theory of Computing,
+      ACM, 1991.
+   [HMAC]
+      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+      for Message Authentication", RFC 2104, February 1997.
+   [KRB5-AES]
+      Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
+      2003.
+   [MD4-92]
+      Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
+      Laboratory for Computer Science, April 1992.
+   [MD5-92]
+      Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
+      Laboratory for Computer Science, April 1992.
+   [RFC2026]
+      Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
+      2026, October 1996.
+   [SG92]
+      Stubblebine, S., and V. D. Gligor, "On Message Integrity in
+      Cryptographic Protocols," in Proceedings of the IEEE Symposium on
+      Research in Security and Privacy, Oakland, California, May 1992.
+
+
+
+
+
+
+
+Raeburn                                                        [Page 47]
+
+INTERNET DRAFT                                             February 2003
+
+
+Informative References
+
+   [EFF-DES]
+      Electronic Frontier Foundation, "Cracking DES: Secrets of
+      Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
+      & Associates, Inc., May 1998.
+   [ESP-DES]
+      Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
+      With Explicit IV", RFC 2405, November 1998.
+   [GSS-KRB5]
+      Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
+      June 1996.
+   [HMAC-TEST]
+      Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
+      RFC 2202, September 1997.
+   [IPSEC-HMAC]
+      Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
+      AH", RFC 2404, November 1998.
+   [Kerb]
+      Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
+      Raeburn, "The Kerberos Network Authentication Service (V5)",
+      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
+      2002.  Work in progress.
+   [Kerb1510]
+      Kohl, J., and C. Neuman, "The Kerberos Network Authentication
+      Service (V5)", RFC 1510, September 1993.
+   [RC5]
+      Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+      RC5-CTS Algorithms", RFC 2040, October 1996.
+   [Schneier96]
+      Schneier, B., "Applied Cryptography Second Edition", John Wiley &
+      Sons, New York, NY, 1996.  ISBN 0-471-12845-7.
+
+Notes to RFC Editor
+
+   Before publication of this document as an RFC, the following changes
+   are needed:
+
+   Change the reference "[KRB5-AES]" in Normative References to indicate
+   the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
+   advancing to RFC at the same time.  The RFC number and publication
+   date are needed.
+
+   If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
+   same time as this document, change the information for [Kerb] in the
+   Informative References section as well.
+
+   Delete this section.
+
+
+
+Raeburn                                                        [Page 48]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-06.txt
new file mode 100644
index 00000000000..7fd04fe8b42
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-06.txt
@@ -0,0 +1,2802 @@
+
+
+
+
+
+
+
+
+
+INTERNET DRAFT                                                K. Raeburn
+Kerberos Working Group                                               MIT
+Document: draft-ietf-krb-wg-crypto-06.txt               October 27, 2003
+                                                  expires April 27, 2004
+
+                 Encryption and Checksum Specifications
+                             for Kerberos 5
+
+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.html.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   This document describes a framework for defining encryption and
+   checksum mechanisms for use with the Kerberos protocol, defining an
+   abstraction layer between the Kerberos protocol and related
+   protocols, and the actual mechanisms themselves.  Several mechanisms
+   are also defined in this document.  Some are taken from RFC 1510,
+   modified in form to fit this new framework, and occasionally modified
+   in content when the old specification was incorrect.  New mechanisms
+   are presented here as well.  This document does NOT indicate which
+   mechanisms may be considered "required to implement".
+
+   Comments should be sent to the editor, or to the IETF Kerberos
+   working group (ietf-krb-wg@anl.gov).
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                              October 2003
+
+
+                           Table of Contents
+
+
+Status of this Memo  . . . . . . . . . . . . . . . . . . . . . . . .   1
+Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
+Table of Contents  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+2. Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+3. Encryption algorithm profile  . . . . . . . . . . . . . . . . . .   4
+4. Checksum algorithm profile  . . . . . . . . . . . . . . . . . . .   9
+5. Simplified profile for CBC ciphers with key derivation  . . . . .  10
+5.1. A key derivation function . . . . . . . . . . . . . . . . . . .  11
+5.2. Simplified profile parameters . . . . . . . . . . . . . . . . .  13
+5.3. Cryptosystem profile based on simplified profile  . . . . . . .  14
+5.4. Checksum profiles based on simplified profile . . . . . . . . .  16
+6. Profiles for Kerberos encryption and checksum algorithms  . . . .  16
+6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . .  16
+6.2. DES-based encryption and checksum types . . . . . . . . . . . .  18
+6.3. Triple-DES based encryption and checksum types  . . . . . . . .  28
+7. Use of Kerberos encryption outside this specification . . . . . .  30
+8. Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . . .  31
+9. Implementation Notes  . . . . . . . . . . . . . . . . . . . . . .  33
+10. Security Considerations  . . . . . . . . . . . . . . . . . . . .  33
+11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  35
+12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  36
+A. Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . . .  37
+A.1. n-fold  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  37
+A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . .  39
+A.3. DES3 DR and DK  . . . . . . . . . . . . . . . . . . . . . . . .  43
+A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . .  44
+A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . .  45
+B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . .  45
+Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  46
+Normative References . . . . . . . . . . . . . . . . . . . . . . . .  47
+Informative References . . . . . . . . . . . . . . . . . . . . . . .  49
+Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . .  49
+Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .  50
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                              October 2003
+
+
+1. Introduction
+
+   The Kerberos protocols are designed to encrypt messages of arbitrary
+   sizes, using block encryption ciphers, or less commonly, stream
+   encryption ciphers.  Encryption is used to prove the identities of
+   the network entities participating in message exchanges.  However,
+   nothing in the Kerberos protocol requires any specific encryption
+   algorithm be used, as long as certain operations are available in the
+   algorithm that is used.
+
+   The following sections specify the encryption and checksum mechanisms
+   currently defined for Kerberos, as well as a framework for defining
+   future mechanisms.  The encoding, chaining, padding and other
+   requirements for each are described.  Test vectors for several
+   functions are given in appendix A.
+
+2. Concepts
+
+   Both encryption and checksum mechanisms are defined in terms of
+   profiles, detailed in later sections.  Each specifies a collection of
+   operations and attributes that must be defined for a mechanism.  A
+   Kerberos encryption or checksum mechanism specification is not
+   complete if it does not define all of these operations and
+   attributes.
+
+   An encryption mechanism must provide for confidentiality and
+   integrity of the original plaintext.  (Integrity checking may be
+   achieved by incorporating a checksum, if the encryption mode does not
+   provide an integrity check itself.)  It must also provide non-
+   malleability [Bellare98, Dolev91].  Use of a random confounder
+   prepended to the plaintext is recommended.  It should not be possible
+   to determine if two ciphertexts correspond to the same plaintext,
+   without knowledge of the key.
+
+   A checksum mechanism [1] must provide proof of the integrity of the
+   associated message, and must preserve the confidentiality of the
+   message in case it is not sent in the clear.  It should be infeasible
+   to find two plaintexts which have the same checksum.  It is NOT
+   required that an eavesdropper be unable to determine if two checksums
+   are for the same message; it is assumed that the messages themselves
+   will be visible to any such eavesdropper.
+
+   Due to advances in cryptography, it is considered unwise by some
+   cryptographers to use the same key for multiple purposes.  Since keys
+   are used in performing a number of different functions in Kerberos,
+   it is desirable to use different keys for each of these purposes,
+   even though we start with a single long-term or session key.
+
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                              October 2003
+
+
+   We do this by enumerating the different uses of keys within Kerberos,
+   and making the "usage number" an input to the encryption or checksum
+   mechanisms; this enumeration is outside the scope of this document.
+   Later sections of this document define simplified profile templates
+   for encryption and checksum mechanisms that use a key derivation
+   function applied to a CBC mode (or similar) cipher and a checksum or
+   hash algorithm.
+
+   We distinguish the "base key" specified by other documents from the
+   "specific key" to be used for a particular instance of encryption or
+   checksum operations.  It is expected but not required that the
+   specific key will be one or more separate keys derived from the
+   original protocol key and the key usage number.  The specific key
+   should not be explicitly referenced outside of this document.  The
+   typical language used in other documents should be something like,
+   "encrypt this octet string using this key and this usage number";
+   generation of the specific key and cipher state (described in the
+   next section) are implicit.  The creation of a new cipher-state
+   object, or the re-use of one from a previous encryption operation,
+   may also be explicit.
+
+   New protocols defined in terms of the Kerberos encryption and
+   checksum types should use their own key usage values.  Key usages are
+   unsigned 32 bit integers; zero is not permitted.
+
+   All data is assumed to be in the form of strings of octets or 8-bit
+   bytes.  Environments with other byte sizes will have to emulate this
+   behavior in order to get correct results.
+
+   Each algorithm is assigned an encryption type (or "etype") or
+   checksum type number, for algorithm identification within the
+   Kerberos protocol.  The full list of current type number assignments
+   is given in section 8.
+
+3. Encryption algorithm profile
+
+   An encryption mechanism profile must define the following attributes
+   and operations.  The operations must be defined as functions in the
+   mathematical sense: no additional or implicit inputs (such as
+   Kerberos principal names or message sequence numbers) are permitted.
+
+   protocol key format
+      This describes what octet string values represent valid keys.  For
+      encryption mechanisms that don't have perfectly dense key spaces,
+      this will describe the representation used for encoding keys.  It
+      need not describe specific values that are not valid or desirable
+      for use; such values should be avoid by all key generation
+      routines.
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                              October 2003
+
+
+   specific key structure
+      This is not a protocol format at all, but a description of the
+      keying material derived from the chosen key and used to encrypt or
+      decrypt data or compute or verify a checksum.  It may, for
+      example, be a single key, a set of keys, or a combination of the
+      original key with additional data.  The authors recommend using
+      one or more keys derived from the original key via one-way key
+      derivation functions.
+
+   required checksum mechanism
+      This indicates a checksum mechanism that must be available when
+      this encryption mechanism is used.  Since Kerberos has no built in
+      mechanism for negotiating checksum mechanisms, once an encryption
+      mechanism has been decided upon, the corresponding checksum
+      mechanism can simply be used.
+
+   key-generation seed length, K
+      This is the length of the random bitstring needed to generate a
+      key with the encryption scheme's random-to-key function (described
+      below).  This must be a fixed value so that various techniques for
+      producing a random bitstring of a given length may be used with
+      key generation functions.
+
+   key generation functions
+      Keys must be generated in a number of cases, from different types
+      of inputs.  All function specifications must indicate how to
+      generate keys in the proper wire format, and must avoid generation
+      of keys that significantly compromise the confidentiality of
+      encrypted data, if the cryptosystem has such.  Entropy from each
+      source should be preserved as much as possible.  Many of the
+      inputs, while unknown, may be at least partly predictable (e.g., a
+      password string is likely to be entirely in the ASCII subset and
+      of fairly short length in many environments; a semi-random string
+      may include timestamps); the benefit of such predictability to an
+      attacker must be minimized.
+
+      string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
+         This function generates a key from two UTF-8 strings and an
+         opaque octet string.  One of the strings is normally the
+         principal's pass phrase, but is in general merely a secret
+         string.  The other string is a "salt" string intended to
+         produce different keys from the same password for different
+         users or realms.  While the strings provided will use UTF-8
+         encoding, no specific version of Unicode should be assumed; all
+         valid UTF-8 strings should be allowed.
+
+         The third argument, the octet string, may be used to pass
+         mechanism-specific parameters in to this function.  Since doing
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                              October 2003
+
+
+         so implies knowledge of the specific encryption system, it is
+         intended that generating non-default parameter values be an
+         uncommon operation, and that normal Kerberos applications be
+         able to treat this parameter block as an opaque object supplied
+         by the Key Distribution Center or defaulted to some mechanism-
+         specific constant value.
+
+         The string-to-key function should be a one-way function, so
+         that compromising a user's key in one realm does not compromise
+         the user's key in another realm, even if the same password (but
+         a different salt) is used.
+
+      random-to-key (bitstring[K])->(protocol-key)
+         This function generates a key from a random bitstring of a
+         specific size.  It may be assumed that all the bits of the
+         input string are equally random, even though the entropy
+         present in the random source may be limited.
+
+      key-derivation (protocol-key, integer)->(specific-key)
+         In this function, the integer input is the key usage value as
+         described above; the usage values must be assumed to be known
+         to an attacker.  The specific-key output value was described in
+         section 2.
+
+   string-to-key parameter format
+      This describes the format of the block of data that can be passed
+      to the string-to-key function above to configure additional
+      parameters for that function.  Along with the mechanism of
+      encoding parameter values, bounds on the allowed parameters should
+      also be described to avoid allowing a spoofed KDC to compromise
+      the user's password.  It may be desirable to construct the
+      encoding such that values weakening the resulting key unacceptably
+      cannot be encoded, if practical.
+
+      Tighter bounds might be permitted by local security policy, or to
+      avoid excess resource consumption; if so, recommended defaults for
+      those bounds should be given in the specification.  The
+      description should also outline possible weaknesses that may be
+      caused by not applying bounds checks or other validation to a
+      parameter string received from the network.
+
+      As mentioned above, this should be considered opaque to most
+      normal applications.
+
+   default string-to-key parameters (octet string)
+      This default value for the "params" argument to the string-to-key
+      function is to be used when the application protocol (Kerberos or
+      otherwise) does not explicitly set the parameter value.  As
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                              October 2003
+
+
+      indicated above, this parameter block should be treated as an
+      opaque object in most cases.
+
+   cipher state
+      This describes any information that can be carried over from one
+      encryption or decryption operation to the next, for use in
+      conjunction with a given specific key.  For example, a block
+      cipher used in CBC mode may put an initial vector of one block in
+      the cipher state.  Other encryption modes may track nonces or
+      other data.
+
+      This state must be non-empty, and must influence encryption so as
+      to require that messages be decrypted in the same order they were
+      encrypted, if the cipher state is carried over from one encryption
+      to the next.  Distinguishing out-of-order or missing messages from
+      corrupted messages is not required; if desired, this can be done
+      at a higher level by including sequence numbers and not "chaining"
+      the cipher state between encryption operations.
+
+      The cipher state may not be reused in multiple encryption or
+      decryption operations; these operations all generate a new cipher
+      state that may be used for following operations using the same key
+      and operation.
+
+      The contents of the cipher state must be treated as opaque outside
+      of encryption system specifications.
+
+   initial cipher state (specific-key, direction)->(state)
+      This describes the generation of the initial value for the cipher
+      state if it is not being carried over from a previous encryption
+      or decryption operation.
+
+      This describes any initial state setup needed before encrypting
+      arbitrary amounts of data with a given specific key; the specific
+      key and the direction of operations to be performed (encrypt
+      versus decrypt) must be the only input needed for this
+      initialization.
+
+      This state should be treated as opaque in any uses outside of an
+      encryption algorithm definition.
+
+      IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
+      degree an application protocol could exercise control over the
+      initial vector used in DES CBC operations.  Some existing
+      implementations permit the setting of the initial vector.  This
+      new specification does not permit application control of the
+      cipher state (beyond "initialize" and "carry over from previous
+      encryption"), since the form and content of the initial cipher
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                              October 2003
+
+
+      state can vary between encryption systems, and may not always be a
+      single block of random data.
+
+      New Kerberos application protocols should not assume that they can
+      control the initial vector, or that one even exists.  However, a
+      general-purpose implementation may wish to provide the capability,
+      in case applications explicitly setting it are encountered.
+
+   encrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and a non-
+      empty plaintext string as input, and generates ciphertext and a
+      new cipher state as outputs.  If the basic encryption algorithm
+      itself does not provide for integrity protection (as DES in CBC
+      mode does not do), then some form of MAC or checksum must be
+      included that can be verified by the receiver.  Some random factor
+      such as a confounder should be included so that an observer cannot
+      know if two messages contain the same plaintext, even if the
+      cipher state and specific keys are the same.  The exact length of
+      the plaintext need not be encoded, but if it is not and if padding
+      is required, the padding must be added at the end of the string so
+      that the decrypted version may be parsed from the beginning.
+
+      The specification of the encryption function must not only
+      indicate the precise contents of the output octet string, but also
+      the output cipher state.  The application protocol may carry
+      forward the output cipher state from one encryption with a given
+      specific key to another; the effect of this "chaining" must be
+      defined.  [2]
+
+      Assuming correctly-produced values for the specific key and cipher
+      state, no input octet string may result in an error indication.
+
+   decrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and ciphertext
+      as inputs, and verifies the integrity of the supplied ciphertext.
+      If the ciphertext's integrity is intact, this function produces
+      the plaintext and a new cipher state as outputs; otherwise, an
+      error indication must be returned, and the data discarded.
+
+      The result of the decryption may be longer than the original
+      plaintext, for example if the encryption mode adds padding to
+      reach a multiple of a block size.  If this is the case, any extra
+      octets must be after the decoded plaintext.  An application
+      protocol which needs to know the exact length of the message must
+      encode a length or recognizable "end of message" marker within the
+      plaintext.  [3]
+
+      As with the encryption function, a correct specification for this
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                              October 2003
+
+
+      function must indicate not only the contents of the output octet
+      string, but also the resulting cipher state.
+
+   pseudo-random (protocol-key, octet-string)->(octet-string)
+      This pseudo-random function should generate an octet string of
+      some size that independent of the octet string input.  The PRF
+      output string should be suitable for use in key generation, even
+      if the octet string input is public.  It should not reveal the
+      input key, even if the output is made public.
+
+   These operations and attributes are all that is required to support
+   Kerberos and various proposed preauthentication schemes.
+
+   For convenience of certain application protocols that may wish to use
+   the encryption profile, we add the constraint that, for any given
+   plaintext input size, there must be a message size between that given
+   size and that size plus 65535 such that the length of such that the
+   decrypted version of the ciphertext for any message of that size will
+   never have extra octets added at the end.
+
+   Expressed mathematically, for every message length L1, there exists a
+   message size L2 such that:
+
+     L2 >= L1
+     L2 < L1 + 65536
+     for every message M with |M| = L2, decrypt(encrypt(M)) = M
+
+   A document defining a new encryption type should also describe known
+   weaknesses or attacks, so that its security may be fairly assessed,
+   and should include test vectors or other validation procedures for
+   the operations defined.  Specific references to information readily
+   available elsewhere are sufficient.
+
+4. Checksum algorithm profile
+
+   A checksum mechanism profile must define the following attributes and
+   operations:
+
+   associated encryption algorithm(s)
+      This indicates the types of encryption keys this checksum
+      mechanism can be used with.
+
+      A keyed checksum mechanism may have more than one associated
+      encryption algorithm if they share the same wire key format,
+      string-to-key function, and key derivation function. (This
+      combination means that, for example, a checksum type, key usage
+      value and password are adequate to get the specific key used to
+      compute a checksum.)
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                              October 2003
+
+
+      An unkeyed checksum mechanism can be used in conjunction with any
+      encryption type, since the key is ignored, but its use must be
+      limited to cases where the checksum itself is protected, to avoid
+      trivial attacks.
+
+   get_mic function
+      This function generates a MIC token for a given specific key (see
+      section 3), and message (represented as an octet string), that may
+      be used to verify the integrity of the associated message.  This
+      function is not required to return the same deterministic result
+      on every use; it need only generate a token that the verify_mic
+      routine can check.
+
+      The output of this function will also dictate the size of the
+      checksum.  It must be no larger than 65535 octets.
+
+   verify_mic function
+      Given a specific key, message, and MIC token, this function
+      ascertains whether the message integrity has been compromised.
+      For a deterministic get_mic routine, the corresponding verify_mic
+      may simply generate another checksum and compare them.
+
+   The get_mic and verify_mic operations must be able to handle inputs
+   of arbitrary length; if any padding is needed, the padding scheme
+   must be specified as part of these functions.
+
+   These operations and attributes are all that should be required to
+   support Kerberos and various proposed preauthentication schemes.
+
+   As with encryption mechanism definition documents, documents defining
+   new checksum mechanisms should indicate validation processes and
+   known weaknesses.
+
+5. Simplified profile for CBC ciphers with key derivation
+
+   The profile outlines in sections 3 and 4 describes a large number of
+   operations that must be defined for encryption and checksum
+   algorithms to be used with Kerberos.  We describe here a simpler
+   profile from which both encryption and checksum mechanism definitions
+   can be generated, filling in uses of key derivation in appropriate
+   places, providing integrity protection, and defining multiple
+   operations for the cryptosystem profile based on a smaller set of
+   operations given in the simplified profile.  Not all of the existing
+   cryptosystems for Kerberos fit into this simplified profile, but we
+   recommend that future cryptosystems use it or something based on it.
+   [4]
+
+   Not all of the operations in the complete profiles are defined
+
+
+
+Raeburn                                                        [Page 10]
+
+INTERNET DRAFT                                              October 2003
+
+
+   through this mechanism; several must still be defined for each new
+   algorithm pair.
+
+5.1. A key derivation function
+
+   Rather than define some scheme by which a "protocol key" is composed
+   of a large number of encryption keys, we use keys derived from a base
+   key to perform cryptographic operations.  The base key must be used
+   only for generating the derived keys, and this derivation must be
+   non-invertible and entropy-preserving.  Given these restrictions,
+   compromise of one derived key does not compromise the other subkeys.
+   Attack of the base key is limited, since it is only used for
+   derivation, and is not exposed to any user data.
+
+   Since the derived key has as much entropy as the base keys (if the
+   cryptosystem is good), password-derived keys have the full benefit of
+   all the entropy in the password.
+
+   To generate a derived key from a base key, we generate a pseudorandom
+   octet string, using an algorithm DR described below, and generate a
+   key from that octet string using a function dependent on the
+   encryption algorithm; the input length needed for that function,
+   which is also dependent on the encryption algorithm, dictates the
+   length of the string to be generated by the DR algorithm (the value
+   "k" below).  These procedures are based on the key derivation in
+   [Blumenthal96].
+
+      Derived Key = DK(Base Key, Well-Known Constant)
+
+      DK(Key, Constant) = random-to-key(DR(Key, Constant))
+
+      DR(Key, Constant) = k-truncate(E(Key, Constant,
+                                       initial-cipher-state))
+
+   Here DR is the random-octet generation function described below, and
+   DK is the key-derivation function produced from it.  In this
+   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
+   a well-known constant determined by the specific usage of this
+   function, and k-truncate truncates its argument by taking the first k
+   bits.  Here, k is the key generation seed length needed for the
+   encryption system.
+
+   The output of the DR function is a string of bits; the actual key is
+   produced by applying the cryptosystem's random-to-key operation on
+   this bitstring.
+
+   If the Constant is smaller than the cipher block size of E, then it
+   must be expanded with n-fold() so it can be encrypted.  If the output
+
+
+
+Raeburn                                                        [Page 11]
+
+INTERNET DRAFT                                              October 2003
+
+
+   of E is shorter than k bits it is fed back into the encryption as
+   many times as necessary.  The construct is as follows (where |
+   indicates concatentation):
+
+      K1 = E(Key, n-fold(Constant), initial-cipher-state)
+      K2 = E(Key, K1, initial-cipher-state)
+      K3 = E(Key, K2, initial-cipher-state)
+      K4 = ...
+
+      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
+
+   n-fold is an algorithm which takes m input bits and ``stretches''
+   them to form n output bits with equal contribution from each input
+   bit to the output, as described in [Blumenthal96]:
+
+      We first define a primitive called n-folding, which takes a
+      variable-length input block and produces a fixed-length output
+      sequence.  The intent is to give each input bit approximately
+      equal weight in determining the value of each output bit.  Note
+      that whenever we need to treat a string of octets as a number, the
+      assumed representation is Big-Endian -- Most Significant Byte
+      first.
+
+      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, with end-around carry) to yield
+      a n-bit result....
+
+
+   Test vectors for n-fold are supplied in Appendix A.  [5]
+
+   In this section, n-fold is always used to produce c bits of output,
+   where c is the cipher block size of E.
+
+   The size of the Constant must not be larger than c, because reducing
+   the length of the Constant by n-folding can cause collisions.
+
+   If the size of the Constant is smaller than c, then the Constant must
+   be n-folded to length c.  This string is used as input to E.  If the
+   block size of E is less than the random-to-key input size, then the
+   output from E is taken as input to a second invocation of E.  This
+   process is repeated until the number of bits accumulated is greater
+   than or equal to the random-to-key input size.  When enough bits have
+   been computed, the first k are taken as the random data used to
+   create the key with the algorithm-dependent random-to-key function.
+
+
+
+
+Raeburn                                                        [Page 12]
+
+INTERNET DRAFT                                              October 2003
+
+
+   Since the derived key is the result of one or more encryptions in the
+   base key, deriving the base key from the derived key is equivalent to
+   determining the key from a very small number of plaintext/ciphertext
+   pairs.  Thus, this construction is as strong as the cryptosystem
+   itself.
+
+5.2. Simplified profile parameters
+
+   These are the operations and attributes that must be defined:
+
+   protocol key format
+   string-to-key function
+   default string-to-key parameters
+   key-generation seed length, k
+   random-to-key function
+      As above for the normal encryption mechanism profile.
+
+   unkeyed hash algorithm, H
+      This should be a collision-resistant hash algorithm with fixed-
+      size output, suitable for use in an HMAC [HMAC].  It must support
+      inputs of arbitrary length.  Its output must be at least the
+      message block size (below).
+
+   HMAC output size, h
+      This indicates the size of the leading substring output by the
+      HMAC function that should be used in transmitted messages.  It
+      should be at least half the output size of the hash function H,
+      and at least 80 bits; it need not match the output size.
+
+   message block size, m
+      This is the size of the smallest units the cipher can handle in
+      the mode in which it is being used.  Messages will be padded to a
+      multiple of this size.  If a block cipher is used in a mode that
+      can handle messages that are not multiples of the cipher block
+      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
+      this value would be one octet.  For traditional CBC mode with
+      padding, it will be the underlying cipher's block size.
+
+      This value must be a multiple of 8 bits (one octet).
+
+   encryption/decryption functions, E and D
+      These are basic encryption and decryption functions for messages
+      of sizes that are multiples of the message block size.  No
+      integrity checking or confounder should be included here.  These
+      functions take as input the IV or similar data, a protocol-format
+      key, and a octet string, returning a new IV and octet string.
+
+      The encryption function is not required to use CBC mode, but is
+
+
+
+Raeburn                                                        [Page 13]
+
+INTERNET DRAFT                                              October 2003
+
+
+      assumed to be using something with similar properties.  In
+      particular, prepending a cipher-block-size confounder to the
+      plaintext should alter the entire ciphertext (comparable to
+      choosing and including a random initial vector for CBC mode).
+
+      The result of encrypting one cipher block (of size c, above) must
+      be deterministic, for the random octet generation function DR in
+      the previous section to work.  For best security, it should also
+      be no larger than c.
+
+   cipher block size, c
+      This is the block size of the block cipher underlying the
+      encryption and decryption functions indicated above, used for key
+      derivation and for the size of the message confounder and initial
+      vector.  (If a block cipher is not in use, some comparable
+      parameter should be determined.)  It must be at least 5 octets.
+
+      This is not actually an independent parameter; rather, it is a
+      property of the functions E and D.  It is listed here to clarify
+      the distinction between it and the message block size, m.
+
+   While there are still a number of properties to specify, they are
+   fewer and simpler than in the full profile.
+
+5.3. Cryptosystem profile based on simplified profile
+
+   The above key derivation function is used to produce three
+   intermediate keys.  One is used for computing checksums of
+   unencrypted data.  The other two are used for encrypting and
+   checksumming plaintext to be sent encrypted.
+
+   The ciphertext output is the concatenation of the output of the basic
+   encryption function E and a (possibly truncated) HMAC using the
+   specified hash function H, both applied to the plaintext with a
+   random confounder prefix and sufficient padding to bring it to a
+   multiple of the message block size.  When the HMAC is computed, the
+   key is used in the protocol key form.
+
+   Decryption is performed by removing the (partial) HMAC, decrypting
+   the remainder, and verifying the HMAC.  The cipher state is an
+   initial vector, initialized to zero.
+
+   The substring notation "[1..h]" in the following table should be read
+   as using 1-based indexing; leading substrings are used.
+
+
+
+
+
+
+
+Raeburn                                                        [Page 14]
+
+INTERNET DRAFT                                              October 2003
+
+
+                   cryptosystem from simplified profile
+----------------------------------------------------------------------------
+protocol key format       As given.
+
+specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
+
+key-generation seed       As given.
+length
+
+required checksum         As defined below in section 5.4.
+mechanism
+
+cipher state              initial vector (usually of length c)
+
+initial cipher state      all bits zero
+
+encryption function       conf = random string of length c
+                          pad = shortest string to bring confounder
+                                and plaintext to a length that's a
+                                multiple of m
+                          (C1, newIV) = E(Ke, conf | plaintext | pad,
+                                          oldstate.ivec)
+                          H1 = HMAC(Ki, conf | plaintext | pad)
+                          ciphertext =  C1 | H1[1..h]
+                          newstate.ivec = newIV
+
+decryption function       (C1,H1) = ciphertext
+                          (P1, newIV) = D(Ke, C1, oldstate.ivec)
+                          if (H1 != HMAC(Ki, P1)[1..h])
+                             report error
+                          newstate.ivec = newIV
+
+default string-to-key     As given.
+params
+
+pseudo-random function    tmp1 = H(octet-string)
+                          tmp2 = truncate tmp1 to multiple of m
+                          PRF = E(protocol-key, tmp2, initial-cipher-state)
+
+key generation functions:
+
+string-to-key function    As given.
+
+random-to-key function    As given.
+
+
+
+
+
+
+
+Raeburn                                                        [Page 15]
+
+INTERNET DRAFT                                              October 2003
+
+
+                   cryptosystem from simplified profile
+----------------------------------------------------------------------------
+key-derivation function   The "well-known constant" used for the DK
+                          function is the key usage number, expressed as
+                          four octets in big-endian order, followed by one
+                          octet indicated below.
+
+                          Kc = DK(base-key, usage | 0x99);
+                          Ke = DK(base-key, usage | 0xAA);
+                          Ki = DK(base-key, usage | 0x55);
+
+
+5.4. Checksum profiles based on simplified profile
+
+   When an encryption system is defined using the simplified profile
+   given in section 5.2, a checksum algorithm may be defined for it as
+   follows:
+
+
+                checksum mechanism from simplified profile
+             --------------------------------------------------
+             associated cryptosystem   as defined above
+
+             get_mic                   HMAC(Kc, message)[1..h]
+
+             verify_mic                get_mic and compare
+
+   The HMAC function and key Kc are as described in section 5.3.
+
+6. Profiles for Kerberos encryption and checksum algorithms
+
+   These profiles describe the encryption and checksum systems defined
+   for Kerberos.  The astute reader will notice that some of them do not
+   fulfull all of the requirements outlined in previous sections.  These
+   systems are defined for backward compatibility; newer implementations
+   should (whenever possible) attempt to make use of encryption systems
+   which satisfy all of the profile requirements.
+
+   The full list of current encryption and checksum type number
+   assignments, including values currently reserved but not defined in
+   this document, is given in section 8.
+
+6.1. Unkeyed checksums
+
+   These checksum types use no encryption keys, and thus can be used in
+   combination with any encryption type, but may only be used with
+   caution, in limited circumstances where the lack of a key does not
+   provide a window for an attack, preferably as part of an encrypted
+
+
+
+Raeburn                                                        [Page 16]
+
+INTERNET DRAFT                                              October 2003
+
+
+   message.  [6] Keyed checksum algorithms are recommended.
+
+6.1.1. The RSA MD5 Checksum
+
+   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.
+
+                                  rsa-md5
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   rsa-md5(msg)
+
+               verify_mic                get_mic and compare
+
+   The rsa-md5 checksum algorithm is assigned a checksum type number of
+   seven (7).
+
+6.1.2. The RSA MD4 Checksum
+
+   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.
+
+
+                                  rsa-md4
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   md4(msg)
+
+               verify_mic                get_mic and compare
+
+
+   The rsa-md4 checksum algorithm is assigned a checksum type number of
+   two (2).
+
+6.1.3. CRC-32 Checksum
+
+   This CRC-32 checksum calculates a checksum based on a cyclic
+   redundancy check as described in ISO 3309 [CRC], modified as
+   described below.  The resulting checksum is four (4) octets in
+   length.  The CRC-32 is neither keyed nor collision-proof; thus, the
+   use of this checksum is not recommended.  An attacker using a
+   probabilistic chosen-plaintext attack as described in [SG92] might be
+
+
+
+Raeburn                                                        [Page 17]
+
+INTERNET DRAFT                                              October 2003
+
+
+   able to generate an alternative message that satisfies the checksum.
+
+   The CRC-32 checksum used in the des-cbc-crc encryption mode is
+   identical to the 32-bit FCS described in ISO 3309 with two
+   exceptions: the sum with the all-ones polynomial times x**k is
+   omitted, and the final remainder is not ones-complemented.  ISO 3309
+   describes the FCS in terms of bits, while this document describes the
+   Kerberos protocol in terms of octets.  To disambiguate the ISO 3309
+   definition for the purpose of computing the CRC-32 in the des-cbc-crc
+   encryption mode, the ordering of bits in each octet shall be assumed
+   to be LSB-first.  Given this assumed ordering of bits within an
+   octet, the mapping of bits to polynomial coefficients shall be
+   identical to that specified in ISO 3309.
+
+   Test values for this modified CRC function are included in appendix
+   A.5.
+
+
+                                   crc32
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   crc32(msg)
+
+               verify_mic                get_mic and compare
+
+
+   The crc32 checksum algorithm is assigned a checksum type number of
+   one (1).
+
+6.2. DES-based encryption and checksum types
+
+   These encryption systems encrypt information under the Data
+   Encryption Standard [DES77] using the cipher block chaining mode
+   [DESM80].  A checksum is computed as described below 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 values
+   of the padding bytes are unspecified.
+
+   Plaintext and DES ciphertext 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 MSB used as the DES input block's MSB, 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
+
+
+
+Raeburn                                                        [Page 18]
+
+INTERNET DRAFT                                              October 2003
+
+
+   additional input in the form of an initialization vector; this vector
+   is specified for each encryption system, below.
+
+   The DES specifications [DESI81] identify four 'weak' and twelve
+   'semi-weak' keys; those keys shall not be used for encrypting
+   messages for use in Kerberos.  The "variant keys" generated for the
+   RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive-
+   or of a DES key with a hexadecimal constant are not checked for this
+   property.
+
+   A DES key is 8 octets of data.  This consists of 56 bits of actual
+   key data, 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 most significant bit).  See the
+   [DESM80] introduction for reference.
+
+   Encryption data format
+
+   The format for the data to be encrypted includes a one-block
+   confounder, a checksum, the encoded plaintext, and any necessary
+   padding, as described in the following diagram.  The msg-seq field
+   contains the part of the protocol message which is to be encrypted.
+
+                  +-----------+----------+---------+-----+
+                  |confounder | checksum | msg-seq | pad |
+                  +-----------+----------+---------+-----+
+
+   One generates a random confounder of one block, placing it in
+   'confounder'; zeroes out the 'checksum' field (of length appropriate
+   to exactly hold the checksum to be computed); calculates the
+   appropriate checksum over the whole sequence, placing the result in
+   'checksum'; adds the necessary padding; then encrypts using the
+   specified encryption type and the appropriate key.
+
+   String or random-data to key transformation
+
+   To generate a DES key from two UTF-8 text strings (password and
+   salt), the two strings are concatenated, password first, and the
+   result is then padded with zero-valued octets to a multiple of 8
+   octets.
+
+   The top bit of each octet (always zero if the password is plain
+   ASCII, as was assumed when the original specification was written) is
+   discarded, and a bitstring is formed of the remaining seven bits of
+
+
+
+Raeburn                                                        [Page 19]
+
+INTERNET DRAFT                                              October 2003
+
+
+   each octet.  This bitstring is then fan-folded and eXclusive-ORed
+   with itself to produce a 56-bit string.  An eight-octet key is formed
+   from this string, each octet using seven bits from the bitstring,
+   leaving the least significant bit unassigned.  The key is then
+   "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
+   0x00000000000000F0.  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 then "corrected" as described above to form the
+   result which is returned as the key.
+
+   For purposes of the string-to-key function, the DES CBC checksum is
+   calculated by CBC encrypting a string using the key as IV and using
+   the final 8 byte block as the checksum.
+
+   Pseudocode follows:
+
+        removeMSBits(8byteblock) {
+          /* Treats a 64 bit block as 8 octets and remove the MSB in
+             each octect (in big endian mode) and concatenates the
+             result.  E.g., input octet string:
+                01110000 01100001 11110011  01110011 11110111 01101111
+                11110010 01100100
+             results in output bitstring:
+                1110000 1100001 1110011  1110011 1110111 1101111
+                1110010 1100100  */
+        }
+
+        reverse(56bitblock) {
+          /* Treats a 56-bit block as a binary string and reverse it.
+             E.g., input string:
+                1000001 1010100 1001000  1000101 1001110 1000001
+                0101110 1001101
+             results in output string:
+                1011001 0111010 1000001  0111001 1010001 0001001
+                0010101 1000001  */
+        }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 20]
+
+INTERNET DRAFT                                              October 2003
+
+
+        add_parity_bits(56bitblock) {
+          /* Copies a 56-bit block into a 64-bit block, left shift
+             content in each octet and add DES parity bit.
+             E.g., input string:
+                1100000 0001111 0011100  0110100 1000101 1100100
+                0110110 0010111
+             results in output string:
+                11000001 00011111 00111000  01101000 10001010 11001000
+                01101101 00101111  */
+        }
+
+        key_correction(key) {
+             fixparity(key);
+             if (is_weak_key(key))
+                  key = key XOR 0xF0;
+             return(key);
+        }
+
+        mit_des_string_to_key(string,salt) {
+             odd = 1;
+             s = string | salt;
+             tempstring = 0; /* 56-bit string */
+             pad(s); /* with nulls to 8 byte boundary */
+             for (8byteblock in s) {
+                  56bitstring = removeMSBits(8byteblock);
+                  if (odd == 0) reverse(56bitstring);
+                  odd = ! odd;
+                  tempstring = tempstring XOR 56bitstring;
+             }
+             tempkey = key_correction(add_parity_bits(tempstring));
+             key = key_correction(DES-CBC-check(s,tempkey));
+             return(key);
+        }
+
+        des_string_to_key(string,salt,params) {
+             if (length(params) == 0)
+                  type = 0;
+             else if (length(params) == 1)
+                  type = params[0];
+             else
+                  error("invalid params");
+             if (type == 0)
+                  mit_des_string_to_key(string,salt);
+             else
+                  error("invalid params");
+        }
+
+   One common extension is to support the "AFS string-to-key" algorithm,
+
+
+
+Raeburn                                                        [Page 21]
+
+INTERNET DRAFT                                              October 2003
+
+
+   which is not defined here, if the type value above is one (1).
+
+   For generation of a key from a random bitstring, we start with a
+   56-bit string, and as with the string-to-key operation above, insert
+   parity bits, and if the result is a weak or semi-weak key, modify it
+   by exclusive-OR with the constart 0x00000000000000F0:
+
+        des_random_to_key(bitstring) {
+             return key_correction(add_parity_bits(bitstring));
+        }
+
+6.2.1. DES with MD5
+
+   The des-cbc-md5 encryption mode encrypts information under DES in CBC
+   mode with an all-zero initial vector, with an MD5 checksum (described
+   in [MD5-92]) computed and placed in the checksum field.
+
+   The encryption system parameters for des-cbc-md5 are:
+
+                                des-cbc-md5
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md5-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     all-zero
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = md5(confounder | 0000...
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+
+
+
+
+Raeburn                                                        [Page 22]
+
+INTERNET DRAFT                                              October 2003
+
+
+                                des-cbc-md5
+    --------------------------------------------------------------------
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            des_random_to_key
+
+    key-derivation           identity
+
+   The des-cbc-md5 encryption type is assigned the etype value three
+   (3).
+
+6.2.2. DES with MD4
+
+   The des-cbc-md4 encryption mode also encrypts information under DES
+   in CBC mode, with an all-zero initial vector.  An MD4 checksum
+   (described in [MD4-92]) is computed and placed in the checksum field.
+
+                                des-cbc-md4
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md4-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     all-zero
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = md4(confounder | 0000...
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+
+
+
+Raeburn                                                        [Page 23]
+
+INTERNET DRAFT                                              October 2003
+
+
+                                des-cbc-md4
+    --------------------------------------------------------------------
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            copy input, then fix parity bits
+
+    key-derivation           identity
+
+   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
+
+   The des-cbc-md4 encryption algorithm is assigned the etype value two
+   (2).
+
+6.2.3. DES with CRC
+
+   The des-cbc-crc encryption type uses DES in CBC mode with the key
+   used as the initialization vector, with a 4-octet CRC-based checksum
+   computed as described in section 6.1.3.  Note that this is not a
+   standard CRC-32 checksum, but a slightly modified one.
+
+
+                                des-cbc-crc
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md5-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+
+
+
+
+Raeburn                                                        [Page 24]
+
+INTERNET DRAFT                                              October 2003
+
+
+                                des-cbc-crc
+    --------------------------------------------------------------------
+    initial cipher state     copy of original key
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = crc(confounder | 00000000
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            copy input, then fix parity bits
+
+    key-derivation           identity
+
+   The des-cbc-crc encryption algorithm is assigned the etype value one
+   (1).
+
+6.2.4. RSA MD5 Cryptographic Checksum Using 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 0xF0F0F0F0F0F0F0F0.  The
+   initialization vector should be zero.  The resulting checksum is 24
+   octets long.  This checksum is tamper-proof and believed to be
+   collision-proof.
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 25]
+
+INTERNET DRAFT                                              October 2003
+
+
+                                rsa-md5-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md5(conf | msg))
+
+      verify_mic                decrypt and verify rsa-md5 checksum
+
+
+   The rsa-md5-des checksum algorithm is assigned a checksum type number
+   of eight (8).
+
+6.2.5. RSA MD4 Cryptographic Checksum Using 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 [MD4-92], 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 0xF0F0F0F0F0F0F0F0.  [7] The initialization
+   vector should be zero.  The resulting checksum is 24 octets long.
+   This checksum is tamper-proof and believed to be collision-proof.
+
+                                rsa-md4-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md4(conf | msg),
+                                        ivec=0)
+
+      verify_mic                decrypt and verify rsa-md4 checksum
+
+   The rsa-md4-des checksum algorithm is assigned a checksum type number
+   of three (3).
+
+6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
+
+   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.
+
+
+
+
+
+Raeburn                                                        [Page 26]
+
+INTERNET DRAFT                                              October 2003
+
+
+                               rsa-md4-des-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key, md4(msg), ivec=key)
+
+      verify_mic                decrypt, compute checksum and compare
+
+
+   The rsa-md4-des-k checksum algorithm is assigned a checksum type
+   number of six (6).
+
+6.2.7. DES CBC checksum
+
+   The DES-MAC checksum is computed by prepending an 8 octet confounder
+   to the plaintext, padding with zero-valued octets if necessary to
+   bring the length to a multiple of 8 octets, 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 variant of the key, where the variant is computed
+   by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0.  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.
+
+
+                                  des-mac
+   ----------------------------------------------------------------------
+   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
+   cryptosystem
+
+   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                          conf | des-mac(key, conf | msg | pad, ivec=0),
+                          ivec=0)
+
+   verify_mic     decrypt, compute DES MAC using confounder, compare
+
+
+   The des-mac checksum algorithm is assigned a checksum type number of
+   four (4).
+
+6.2.8. DES CBC checksum alternative
+
+   The DES-MAC-K checksum is computed by performing a DES CBC-mode
+   encryption of the plaintext, with zero-valued padding bytes if
+   necessary to bring the length to a multiple of 8 octets, and using
+   the last block of the ciphertext as the checksum value.  It is keyed
+
+
+
+Raeburn                                                        [Page 27]
+
+INTERNET DRAFT                                              October 2003
+
+
+   with an encryption key which is also used as the 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 DESMAC checksum and
+   it is no longer recommended.
+
+
+                                 des-mac-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-mac(key, msg | pad, ivec=key)
+
+      verify_mic                compute MAC and compare
+
+
+   The des-mac-k checksum algorithm is assigned a checksum type number
+   of five (5).
+
+6.3. Triple-DES based encryption and checksum types
+
+   This encryption and checksum type pair is based on the Triple DES
+   cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
+   authentication algorithm.
+
+   A Triple DES key is the concatenation of three DES keys as described
+   above for des-cbc-md5.  A Triple DES key is generated from random
+   data by creating three DES keys from separate sequences of random
+   data.
+
+   Encrypted data using this type must be generated as described in
+   section 5.3.  If the length of the input data is not a multiple of
+   the block size, zero-valued octets must be used to pad the plaintext
+   to the next eight-octet boundary.  The confounder must be eight
+   random octets (one block).
+
+   The simplified profile for Triple DES, with key derivation as defined
+   in section 5, is as follows:
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              protocol key format     24 bytes, parity in low
+                                      bit of each
+
+              key-generation seed     21 bytes
+              length
+
+
+
+
+
+Raeburn                                                        [Page 28]
+
+INTERNET DRAFT                                              October 2003
+
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              hash function           SHA-1
+
+              HMAC output size        160 bits
+
+              message block size      8 bytes
+
+              default string-to-key   empty string
+              params
+
+              encryption and          triple-DES encrypt and
+              decryption functions    decrypt, in outer-CBC
+                                      mode (cipher block size
+                                      8 octets)
+
+              key generation functions:
+
+              random-to-key           DES3random-to-key (see
+                                      below)
+
+              string-to-key           DES3string-to-key (see
+                                      below)
+
+   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
+   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
+   checksum type number of twelve (12).
+
+6.3.1. Triple DES Key Production (random-to-key, string-to-key)
+
+   The 168 bits of random key data are converted to a protocol key value
+   as follows.  First, the 168 bits are divided into three groups of 56
+   bits, which are expanded individually into 64 bits as follows:
+
+   DES3random-to-key:
+         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, each corrected to avoid "weak" and "semi-
+   weak" keys as in section 6.2, are concatenated to form the protocol
+   key value.
+
+
+
+Raeburn                                                        [Page 29]
+
+INTERNET DRAFT                                              October 2003
+
+
+   The string-to-key function is used to transform UTF-8 passwords into
+   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
+   algorithm and DK function, described in section 5.
+
+   The n-fold algorithm is applied to the password string concatenated
+   with a salt value.  For 3-key triple DES, the operation will involve
+   a 168-fold of the input password string, to generate an intermediate
+   key, from which the user's long-term key will be derived with the DK
+   function.  The DES3 string-to-key function is shown here in
+   pseudocode:
+
+         DES3string-to-key(passwordString, salt, params)
+             if (params != emptyString)
+              error("invalid params");
+             s = passwordString + salt
+             tmpKey = random-to-key(168-fold(s))
+             key = DK (tmpKey, KerberosConstant)
+
+   Weak key checking is performed in the random-to-key and DK
+   operations.  The KerberosConstant value is the byte string {0x6b 0x65
+   0x72 0x62 0x65 0x72 0x6f 0x73}.  These values correspond to the ASCII
+   encoding for the string "kerberos".
+
+7. Use of Kerberos encryption outside this specification
+
+   Several Kerberos-based application protocols and preauthentication
+   systems have been designed and deployed that perform encryption and
+   message integrity checks in various ways.  While in some cases there
+   may be good reason for specifying these protocols in terms of
+   specific encryption or checksum algorithms, we anticipate that in
+   many cases this will not be true, and more generic approaches
+   independent of particular algorithms will be desirable.  Rather than
+   having each protocol designer reinvent schemes for protecting data,
+   using multiple keys, etc, we have attempted to present in this
+   section a general framework that should be sufficient not only for
+   the Kerberos protocol itself but also for many preauthentication
+   systems and application protocols, while trying to avoid some of the
+   assumptions that can work their way into such protocol designs.
+
+   Some problematic assumptions we've seen (and sometimes made) include:
+   that a random bitstring is always valid as a key (not true for DES
+   keys with parity); that the basic block encryption chaining mode
+   provides no integrity checking, or can easily be separated from such
+   checking (not true for many modes in development that do both
+   simultaneously); that a checksum for a message always results in the
+   same value (not true if a confounder is incorporated); that an
+   initial vector is used (may not be true if a block cipher in CBC mode
+   is not in use).
+
+
+
+Raeburn                                                        [Page 30]
+
+INTERNET DRAFT                                              October 2003
+
+
+   Such assumptions, while they may hold for any given set of encryption
+   and checksum algorithms, may not be true of the next algorithms to be
+   defined, leaving the application protocol unable to make use of those
+   algorithms without updates to its specification.
+
+   The Kerberos protocol uses only the attributes and operations
+   described in sections 3 and 4.  Preauthentication systems and
+   application protocols making use of Kerberos are encouraged to use
+   them as well.  The specific key and string-to-key parameters should
+   generally be treated as opaque.  While the string-to-key parameters
+   are manipulated as an octet string, the representation for the
+   specific key structure is implementation-defined; it may not even be
+   a single object.
+
+   While we don't recommend it, some application protocols will
+   undoubtedly continue to use the key data directly, even if only in
+   some of the currently existing protocol specifications.  An
+   implementation intended to support general Kerberos applications may
+   therefore need to make the key data available, as well as the
+   attributes and operations described in sections 3 and 4.  [8]
+
+8. Assigned Numbers
+
+   The following encryption type numbers are already assigned or
+   reserved for use in Kerberos and related protocols.
+
+
+     encryption type                etype      section or comment
+     -----------------------------------------------------------------
+     des-cbc-crc                        1             6.2.3
+     des-cbc-md4                        2             6.2.2
+     des-cbc-md5                        3             6.2.1
+     [reserved]                         4
+     des3-cbc-md5                       5
+     [reserved]                         6
+     des3-cbc-sha1                      7
+     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              6.3
+     aes128-cts-hmac-sha1-96           17          [KRB5-AES]
+     aes256-cts-hmac-sha1-96           18          [KRB5-AES]
+     rc4-hmac                          23          (Microsoft)
+
+
+
+
+Raeburn                                                        [Page 31]
+
+INTERNET DRAFT                                              October 2003
+
+
+     rc4-hmac-exp                      24          (Microsoft)
+     subkey-keymaterial                65     (opaque; PacketCable)
+
+
+   (The "des3-cbc-sha1" assignment is a deprecated version using no key
+   derivation.  It should not be confused with des3-cbc-sha1-kd.)
+
+   Several numbers have been reserved for use in encryption systems not
+   defined here.  Encryption type numbers have unfortunately been
+   overloaded on occasion in Kerberos-related protocols, so some of the
+   reserved numbers do not and will not correspond to encryption systems
+   fitting the profile presented here.
+
+   The following checksum type numbers are assigned or reserved.  As
+   with encryption type numbers, some overloading of checksum numbers
+   has occurred.
+
+
+   Checksum type              sumtype        checksum         section or
+                                value            size         reference
+   ----------------------------------------------------------------------
+   CRC32                            1               4           6.1.3
+   rsa-md4                          2              16           6.1.2
+   rsa-md4-des                      3              24           6.2.5
+   des-mac                          4              16           6.2.7
+   des-mac-k                        5               8           6.2.8
+   rsa-md4-des-k                    6              16           6.2.6
+   rsa-md5                          7              16           6.1.1
+   rsa-md5-des                      8              24           6.2.4
+   rsa-md5-des3                     9              24             ??
+   sha1 (unkeyed)                  10              20             ??
+   hmac-sha1-des3-kd               12              20            6.3
+   hmac-sha1-des3                  13              20             ??
+   sha1 (unkeyed)                  14              20             ??
+   hmac-sha1-96-aes128             15              20         [KRB5-AES]
+   hmac-sha1-96-aes256             16              20         [KRB5-AES]
+   [reserved]                  0x8003               ?         [GSS-KRB5]
+
+
+   Encryption and checksum type numbers are signed 32-bit values.  Zero
+   is invalid, and negative numbers are reserved for local use.  All
+   standardized values must be positive.
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 32]
+
+INTERNET DRAFT                                              October 2003
+
+
+9. Implementation Notes
+
+   The "interface" described here is the minimal information that must
+   be defined to make a cryptosystem useful within Kerberos in an
+   interoperable fashion.  Despite the functional notation used in some
+   places, it is not an attempt to define an API for cryptographic
+   functionality within Kerberos.  Actual implementations providing
+   clean APIs will probably find it useful to make additional
+   information available, which should be possible to derive from a
+   specification written to the framework given here.  For example, an
+   application designer may wish to determine the largest number of
+   bytes that can be encrypted without overflowing a certain size output
+   buffer, or conversely, the maximum number of bytes that might be
+   obtained by decrypting a ciphertext message of a given size.  (In
+   fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
+   will require some of these.)
+
+   The presence of a mechanism in this document should not be taken as
+   an indication that it must be implemented for compliance with any
+   specification; required mechanisms will be specified elsewhere.
+   Indeed, some of the mechanisms described here for backwards
+   compatibility are now considered rather weak for protecting critical
+   data.
+
+10. Security Considerations
+
+   Recent years have brought advancements in the ability to perform
+   large-scale attacks against DES, to such a degree that it is not
+   considered a strong encryption mechanism any longer; triple-DES is
+   generally preferred in its place, despite the poorer performance.
+   See [ESP-DES] for a summary of some of the potential attacks, and
+   [EFF-DES] for a detailed discussion of the implementation of
+   particular attack.  However, most Kerberos implementations still have
+   DES as their primary interoperable encryption type.
+
+   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
+   single-DES here avoids them.  However, DES also has 48 'possibly-
+   weak' keys [Schneier96] (note that the tables in many editions of the
+   reference contains errors) which are not avoided.
+
+   DES weak keys are keys with the property that E1(E1(P)) = P (where E1
+   denotes encryption of a single block with key 1).  DES semi-weak keys
+   or "dual" keys are pairs of keys with the property that E1(P) =
+   D2(P), and thus E2(E1(P)) = P.  Because of the use of CBC mode and
+   leading random confounder, however, these properties are unlikely to
+   present a security problem.
+
+   Many of the choices concerning when weak-key corrections are
+
+
+
+Raeburn                                                        [Page 33]
+
+INTERNET DRAFT                                              October 2003
+
+
+   performed relate more to compatibility with existing implementations
+   than to any risk analysis.
+
+   While checks are also done for the component DES keys in a triple-DES
+   key, the nature of the weak keys is such that it is extremely
+   unlikely that they will weaken the triple-DES encryption -- only
+   slightly more likely than having the middle of the three sub-keys
+   match one of the other two, which effectively converts the encryption
+   to single-DES, which is a case we make no effort to avoid.
+
+   The true 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 of course recommended for environments where such
+   attacks represent a significant threat.  The "simplifications" (read:
+   bugs) introduced when CRC-32 was implemented for Kerberos cause
+   leading zeros to effectively be ignored, so messages differing only
+   in leading zero bits will have the same checksum.
+
+   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
+   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
+   the suggested truncation of the HMAC output.  As pointed out in
+   [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
+   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
+   vectors for HMAC-SHA-1.
+
+   The mit_des_string_to_key function was originally constructed with
+   the assumption that all input would be ASCII; it ignores the top bit
+   of each input byte.  Folding with XOR is also not an especially good
+   mixing mechanism in terms of preserving randomness.
+
+   The n-fold function used in the string-to-key operation for des3-cbc-
+   hmac-sha1-kd was designed to cause each bit of input to contribute
+   equally to the output; it was not designed to maximize or equally
+   distribute randomness in the input, and there are conceivable cases
+   of partially structured input where randomness may be lost.  This
+   should only be an issue for highly structured passwords, however.
+
+   [RFC1851] discusses the relative strength of triple-DES encryption.
+   The relative slow speed of triple-DES encryption may also be an issue
+   for some applications.
+
+   In [Bellovin91], there is a suggestion that analyses of encryption
+   schemes should include a model of an attacker capable of submitting
+   known plaintexts to be encrypted with an unknown key, as well as
+   being able to perform many types of operations on known protocol
+   messages.  Recent experiences with the chosen-plaintext attacks on
+   Kerberos version 4 bear out the value of this suggestion.
+
+
+
+Raeburn                                                        [Page 34]
+
+INTERNET DRAFT                                              October 2003
+
+
+   The use of unkeyed encrypted checksums, such as those used in the
+   single-DES cryptosystems specified in [Kerb1510], allows for cut-and-
+   paste attacks, especially if a confounder is not used.  In addition,
+   unkeyed encrypted checksums are vulnerable to chosen-plaintext
+   attacks: an attacker with access to an encryption oracle can easily
+   encrypt the required unkeyed checksum along with the chosen
+   plaintext. [Bellovin99]  These weaknesses, combined with a common
+   implementation design choice described below, allow for a cross-
+   protocol attack from version 4 to version 5.
+
+   The use of a random confounder is an important means of preventing an
+   attacker from making effective use of protocol exchanges as an
+   encryption oracle.  In Kerberos version 4, the encryption of constant
+   plaintext to constant ciphertext makes an effective encryption oracle
+   for an attacker.  The use of random confounders in [Kerb1510]
+   frustrates this sort of chosen-plaintext attack.
+
+   Using the same key for multiple purposes can enable or increase the
+   scope of chosen-plaintext attacks.  Some software which implements
+   both versions 4 and 5 of the Kerberos protocol uses the same keys for
+   both versions of the protocol.  This enables the encryption oracle of
+   version 4 to be used to attack version 5.  Vulnerabilities such as
+   this cross-protocol attack reinforce the wisdom of not using a key
+   for multiple purposes.
+
+   This document, like the Kerberos protocol, completely ignores the
+   notion of limiting the amount of data a key may be used with to a
+   quantity based on the robustness of the algorithm or size of the key.
+   It is assumed that any defined algorithms and key sizes will be
+   strong enough to support very large amounts of data, or they will be
+   deprecated once significant attacks are known.
+
+   This document also places no bounds on the amount of data that can be
+   handled in various operations.  In order to avoid denial of service
+   attacks, implementations will probably want to restrict message sizes
+   at some higher level.
+
+11. IANA Considerations
+
+   Two registries for numeric values should be created: Kerberos
+   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
+   are signed 32-bit values in twos-complement form.  Positive values up
+   to 2**31-1 inclusive should be assigned only for algorithms specified
+   in accordance with this specification for use with Kerberos or
+   related protocols.  Negative values through -2**31 are for private
+   use; local and experimental algorithms should use these values.  Zero
+   is reserved and may not be assigned.
+
+
+
+
+Raeburn                                                        [Page 35]
+
+INTERNET DRAFT                                              October 2003
+
+
+   Positive encryption and checksum type numbers may be assigned
+   following either of two policies described in [BCP26].
+
+   Standards-track specifications may be assigned values under the
+   Standards Action policy.
+
+   Specifications in Informational RFCs may be assigned values after
+   Expert Review.  A non-IETF specification may be assigned values by
+   publishing an Informational or standards-track RFC referencing the
+   external specification; that specification must be public and
+   published in some permanent record much like the IETF RFCs.  It is
+   highly desirable, though not required, that the full specification be
+   published as an IETF RFC.
+
+   Smaller encryption type values, which encode to smaller octet strings
+   under ASN.1, should be used for IETF standards-track mechanisms, and
+   much higher values (hex 0x1000000 and above) for other mechanisms.
+   No other guidance into allocation order is given.
+
+   Draft IETF specifications should not include values for encryption
+   and checksum type numbers.  Instead, they should indicate that values
+   would be assigned by IANA when the document is approved as an RFC.
+   For development and interoperability testing, values in the private-
+   use range (negative values) may be used, but should not be included
+   in the draft specification.
+
+   Each registered value should have an associated unique name to refer
+   to it by.  The lists given in section 8 should be used as an initial
+   registry; they include reservations for specifications in progress in
+   parallel with this document, and for certain other values believed to
+   be in use already.
+
+12. Acknowledgments
+
+   This document is an extension of the encryption specification
+   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
+   of the text of the background, concepts, and DES specifications are
+   drawn directly from that document.
+
+   The abstract framework presented in this document was put together by
+   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
+   and Tom Yu, and the details were refined several times based on
+   comments from John Brezak and others.
+
+   Marc Horowitz wrote the original specification of triple-DES and key
+   derivation in a pair of Internet Drafts (under the names draft-
+   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
+   were later folded into a draft revision of [Kerb1510], from which
+
+
+
+Raeburn                                                        [Page 36]
+
+INTERNET DRAFT                                              October 2003
+
+
+   this document was later split off.
+
+   Tom Yu provided the text describing the modifications to the standard
+   CRC algorithm as Kerberos implementations actually use it, and some
+   of the Security Considerations section.
+
+   Miroslav Jurisic provided information for one of the UTF-8 test cases
+   for the string-to-key functions.
+
+   Marcus Watts noticed some errors in earlier drafts, and pointed out
+   that the simplified profile could easily be modified to support
+   cipher text stealing modes.
+
+   Simon Josefsson contributed some clarifications to the DES "CBC
+   checksum", string-to-key and weak key descriptions, and some test
+   vectors.
+
+   Simon Josefsson, Louis LeVay and others also caught some errors in
+   earlier drafts.
+
+A. Test vectors
+
+   This section provides test vectors for various functions defined or
+   described in this document.  For convenience, most inputs are ASCII
+   strings, though some UTF-8 samples are be provided for string-to-key
+   functions.  Keys and other binary data are specified as hexadecimal
+   strings.
+
+A.1. n-fold
+
+   The n-fold function is defined in section 5.1.  As noted there, the
+   sample vector in the original paper defining the algorithm appears to
+   be incorrect.  Here are some test cases provided by Marc Horowitz and
+   Simon Josefsson:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 37]
+
+INTERNET DRAFT                                              October 2003
+
+
+      64-fold("012345") =
+      64-fold(303132333435) = be072631276b1955
+
+      56-fold("password") =
+      56-fold(70617373776f7264) = 78a07b6caf85fa
+
+      64-fold("Rough Consensus, and Running Code") =
+      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
+              6e696e6720436f6465) = bb6ed30870b7f0e0
+
+      168-fold("password") =
+      168-fold(70617373776f7264) =
+               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
+
+      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
+      192-fold(4d41535341434856534554545320494e5354495456544520
+               4f4620544543484e4f4c4f4759) =
+               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
+
+      168-fold("Q") =
+      168-fold(51) =
+               518a54a2 15a8452a 518a54a2 15a8452a
+               518a54a2 15
+
+      168-fold("ba") =
+      168-fold(6261) =
+               fb25d531 ae897449 9f52fd92 ea9857c4
+               ba24cf29 7e
+
+   Here are some additional values corresponding to folded values of the
+   string "kerberos"; the 64-bit form is used in the des3 string-to-key
+   (section 6.3.1).
+
+      64-fold("kerberos") =
+               6b657262 65726f73
+      128-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+      168-fold("kerberos") =
+               8372c236 344e5f15 50cd0747 e15d62ca
+               7a5a3bce a4
+      256-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+               5c9bdcda d95c9899 c4cae4de e6d6cae4
+
+   Note that the initial octets exactly match the input string when the
+   output length is a multiple of the input length.
+
+
+
+
+
+Raeburn                                                        [Page 38]
+
+INTERNET DRAFT                                              October 2003
+
+
+A.2. mit_des_string_to_key
+
+   The function mit_des_string_to_key is defined in section 6.2.  We
+   present here several test values, with some of the intermediate
+   results.  The fourth test demonstrates the use of UTF-8 with three
+   characters.  The last two tests are specifically constructed so as to
+   trigger the weak-key fixups for the intermediate key produced by fan-
+   folding; we have no test cases that cause such fixups for the final
+   key.
+
+
+   UTF-8 encodings used in test vector:
+   eszett     C3 9F            s-caron     C5 A1      c-acute     C4 87
+   g-clef     F0 9D 84 9E
+
+
+   Test vector:
+
+
+   salt:        "ATHENA.MIT.EDUraeburn"
+                              415448454e412e4d49542e4544557261656275726e
+   password:    "password"    70617373776f7264
+   fan-fold result:           c01e38688ac86c2e
+   intermediate key:          c11f38688ac86d2f
+   DES key:                   cbc22fae235298e3
+
+
+
+   salt:       "WHITEHOUSE.GOVdanny"   5748495445484f5553452e474f5664616e6e79
+   password:   "potatoe"               706f7461746f65
+   fan-fold result:                    a028944ee63c0416
+   intermediate key:                   a129944fe63d0416
+   DES key:                            df3d32a74fd92a01
+
+
+
+   salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
+   password:  g-clef                f09d849e
+   fan-fold result:                 3c4a262c18fab090
+   intermediate key:                3d4a262c19fbb091
+   DES key:                         4ffb26bab0cd9413
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 39]
+
+INTERNET DRAFT                                              October 2003
+
+
+   salt:        "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
+                          415448454e412e4d49542e4544554a757269c5a169c487
+   password:    eszett    c39f
+   fan-fold result:       b8f6c40e305afc9e
+   intermediate key:      b9f7c40e315bfd9e
+   DES key:               62c81a5232b5e69d
+
+
+
+   salt:       "AAAAAAAA"   4141414141414141
+   password:   "11119999"   3131313139393939
+   fan-fold result:         e0e0e0e0f0f0f0f0
+   intermediate key:        e0e0e0e0f1f1f101
+   DES key:                 984054d0f1a73e31
+
+
+
+   salt:       "FFFFAAAA"   4646464641414141
+   password:   "NNNN6666"   4e4e4e4e36363636
+   fan-fold result:         1e1e1e1e0e0e0e0e
+   intermediate key:        1f1f1f1f0e0e0efe
+   DES key:                 c4bf6b25adf7a4f8
+
+
+   This trace provided by Simon Josefsson shows the intermediate
+   processing stages of one of the test inputs:
+
+     string_to_key (des-cbc-md5, string, salt)
+            ;; string:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; salt:
+            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+            ;; 65 62 75 72 6e
+     des_string_to_key (string, salt)
+            ;; String:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; Salt:
+            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+            ;; 65 62 75 72 6e
+     odd = 1;
+     s = string | salt;
+
+
+
+
+
+
+Raeburn                                                        [Page 40]
+
+INTERNET DRAFT                                              October 2003
+
+
+     tempstring = 0; /* 56-bit string */
+     pad(s); /* with nulls to 8 byte boundary */
+            ;; s = pad(string|salt):
+            ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
+            ;; (length 32 bytes)
+            ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
+            ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
+     for (8byteblock in s) {
+            ;; loop iteration 0
+            ;; 8byteblock:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; 01110000 01100001 01110011  01110011 01110111 01101111
+            ;; 01110010 01100100
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1110000 1100001 1110011  1110011 1110111 1101111
+            ;; 1110010 1100100
+     if (odd == 0) reverse(56bitstring);    ;; odd=1
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1110000 1100001 1110011  1110011 1110111 1101111
+            ;; 1110010 1100100
+
+     for (8byteblock in s) {
+            ;; loop iteration 1
+            ;; 8byteblock:
+            ;; `ATHENA.M' (length 8 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d
+            ;; 01000001 01010100 01001000  01000101 01001110 01000001
+            ;; 00101110 01001101
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1000001 1010100 1001000  1000101 1001110 1000001
+            ;; 0101110 1001101
+     if (odd == 0) reverse(56bitstring);    ;; odd=0
+     reverse(56bitstring)
+            ;; 56bitstring after reverse
+            ;; 1011001 0111010 1000001  0111001 1010001 0001001
+            ;; 0010101 1000001
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 0101001 1011011 0110010  1001010 0100110 1100110
+            ;; 1100111 0100101
+
+
+
+
+
+Raeburn                                                        [Page 41]
+
+INTERNET DRAFT                                              October 2003
+
+
+     for (8byteblock in s) {
+            ;; loop iteration 2
+            ;; 8byteblock:
+            ;; `IT.EDUra' (length 8 bytes)
+            ;; 49 54 2e 45 44 55 72 61
+            ;; 01001001 01010100 00101110  01000101 01000100 01010101
+            ;; 01110010 01100001
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1001001 1010100 0101110  1000101 1000100 1010101
+            ;; 1110010 1100001
+     if (odd == 0) reverse(56bitstring);    ;; odd=1
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1100000 0001111 0011100  0001111 1100010 0110011
+            ;; 0010101 1000100
+
+     for (8byteblock in s) {
+            ;; loop iteration 3
+            ;; 8byteblock:
+            ;; `eburn\x00\x00\x00' (length 8 bytes)
+            ;; 65 62 75 72 6e 00 00 00
+            ;; 01100101 01100010 01110101  01110010 01101110 00000000
+            ;; 00000000 00000000
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1100101 1100010 1110101  1110010 1101110 0000000
+            ;; 0000000 0000000
+     if (odd == 0) reverse(56bitstring);    ;; odd=0
+     reverse(56bitstring)
+            ;; 56bitstring after reverse
+            ;; 0000000 0000000 0000000  0111011 0100111 1010111
+            ;; 0100011 1010011
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1100000 0001111 0011100  0110100 1000101 1100100
+            ;; 0110110 0010111
+
+     for (8byteblock in s) {
+     }
+            ;; for loop terminated
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 42]
+
+INTERNET DRAFT                                              October 2003
+
+
+     tempkey = key_correction(add_parity_bits(tempstring));
+            ;; tempkey
+            ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
+            ;; c1 1f 38 68 8a c8 6d 2f
+            ;; 11000001 00011111 00111000  01101000 10001010 11001000
+            ;; 01101101 00101111
+
+     key = key_correction(DES-CBC-check(s,tempkey));
+            ;; key
+            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+            ;; cb c2 2f ae 23 52 98 e3
+            ;; 11001011 11000010 00101111  10101110 00100011 01010010
+            ;; 10011000 11100011
+
+            ;; string_to_key key:
+            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+            ;; cb c2 2f ae 23 52 98 e3
+
+
+A.3. DES3 DR and DK
+
+   These tests show the derived-random and derived-key values for the
+   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
+   defined in section 6.3.1.  The input keys were randomly generated;
+   the usage values are from this specification.
+
+
+   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
+   usage:               0000000155
+   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
+   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
+
+   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
+   usage:               00000001aa
+   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
+   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
+
+   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
+   usage:               0000000155
+   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
+   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
+
+   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
+   usage:               00000001aa
+   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
+   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
+
+
+
+
+
+Raeburn                                                        [Page 43]
+
+INTERNET DRAFT                                              October 2003
+
+
+   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
+   usage:               6b65726265726f73 ("kerberos")
+   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
+   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
+
+   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
+   usage:               0000000155
+   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
+   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
+
+   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
+   usage:               00000001aa
+   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
+   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
+
+   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
+   usage:               0000000155
+   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
+   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
+
+   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
+   usage:               00000001aa
+   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
+   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
+
+
+A.4. DES3string_to_key
+
+   These are the keys generated for some of the above input strings for
+   triple-DES with key derivation as defined in section 6.3.1.
+
+    salt:   "ATHENA.MIT.EDUraeburn"
+    passwd: "password"
+    key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
+
+    salt:   "WHITEHOUSE.GOVdanny"
+    passwd: "potatoe"
+    key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
+
+    salt:   "EXAMPLE.COMbuckaroo"
+    passwd: "penny"
+    key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
+
+    salt:   "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
+    passwd: eszett
+    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
+
+
+
+
+
+Raeburn                                                        [Page 44]
+
+INTERNET DRAFT                                              October 2003
+
+
+    salt:   "EXAMPLE.COMpianist"
+    passwd: g-clef
+    key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
+
+A.5. Modified CRC-32
+
+   Below are modified-CRC32 values for various ASCII and octet strings.
+   Only the printable ASCII characters are checksummed, no C-style
+   trailing zero-valued octet.  The 32-bit modified CRC and the sequence
+   of output bytes as used in Kerberos are shown.  (The octet values are
+   separated here to emphasize that they are octet values and not 32-bit
+   numbers, which will be the most convenient form for manipulation in
+   some implementations.  The bit and byte order used internally for
+   such a number is irrelevant; the octet sequence generated is what is
+   important.)
+
+
+    mod-crc-32("foo") =                                     33 bc 32 73
+    mod-crc-32("test0123456789") =                          d6 88 3e b8
+    mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
+    mod-crc-32(8000) =                                      4b 98 83 3b
+    mod-crc-32(0008) =                                      32 88 db 0e
+    mod-crc-32(0080) =                                      20 83 b8 ed
+    mod-crc-32(80) =                                        20 83 b8 ed
+    mod-crc-32(80000000) =                                  3b b6 59 ed
+    mod-crc-32(00000001) =                                  96 30 07 77
+
+
+B. Significant Changes from RFC 1510
+
+   The encryption and checksum mechanism profiles are new.  The old
+   specification defined a few operations for various mechanisms, but
+   didn't outline what should be required of new mechanisms in terms of
+   abstract properties, nor how to ensure that a mechanism specification
+   is complete enough for interoperability between implementations.  The
+   new profiles do differ from the old specification in a few ways:
+
+      Some message definitions in [Kerb1510] could be read as permitting
+      the initial vector to be specified by the application; the text
+      was too vague.  It is specifically not permitted in this
+      specification.  Some encryption algorithms may not use
+      initialization vectors, so relying on chosen, secret
+      initialization vectors for security is unwise.  Also, the
+      prepended confounder in the existing algorithms is roughly
+      equivalent to a per-message initialization vector that is revealed
+      in encrypted form.  However, carrying state across from one
+      encryption to another is explicitly permitted through the opaque
+      "cipher state" object.
+
+
+
+Raeburn                                                        [Page 45]
+
+INTERNET DRAFT                                              October 2003
+
+
+      The use of key derivation is new.
+
+      Several new methods are introduced, including generation of a key
+      in wire-protocol format from random input data.
+
+      The means for influencing the string-to-key algorithm are laid out
+      more clearly.
+
+   Triple-DES support is new.
+
+   The pseudo-random function is new.
+
+   The des-cbc-crc, DES string-to-key and CRC descriptions have been
+   updated to align them with existing implementations.
+
+   [Kerb1510] had no indication what character set or encoding might be
+   used for pass phrases and salts.
+
+   In [Kerb1510], key types, encryption algorithms and checksum
+   algorithms were only loosely associated, and the association was not
+   well described.  In this specification, key types and encryption
+   algorithms have a one-to-one correspondence, and associations between
+   encryption and checksum algorithms are described so that checksums
+   can be computed given negotiated keys, without requiring further
+   negotiation for checksum types.
+
+Notes
+
+   [1] While Message Authentication Code (MAC) or Message Integrity
+       Check (MIC) would be more appropriate terms for many of the
+       uses in this document, we continue to use the term "checksum"
+       for historical reasons.
+
+   [2] Extending CBC mode across messages would be one obvious
+       example of this chaining.  Another might be the use of
+       counter mode, with a counter randomly initialized and
+       attached to the ciphertext; a second message could continue
+       incrementing the counter when chaining the cipher state, thus
+       avoiding having to transmit another counter value.  However,
+       this chaining is only useful for uninterrupted, ordered
+       sequences of messages.
+
+   [3] In the case of Kerberos, the encrypted objects will generally
+       be ASN.1 DER encodings, which contain indications of their
+       length in the first few octets.
+
+   [4] As of the time of this writing, some new modes of operation
+       have been proposed, some of which may permit encryption and
+
+
+
+Raeburn                                                        [Page 46]
+
+INTERNET DRAFT                                              October 2003
+
+
+       integrity protection simultaneously.  After some of these
+       proposals have been subjected to adequate analysis, we may
+       wish to formulate a new simplified profile based on one of
+       them.
+
+   [5] It should be noted that the sample vector in Appendix B.2 of
+       the original paper appears to be incorrect.  Two independent
+       implementations from the specification (one in C by Marc
+       Horowitz, and another in Scheme by Bill Sommerfeld) agree on
+       a value different from that in [Blumenthal96].
+
+   [6] For example, in MIT's implementation of [Kerb1510], the rsa-
+       md5 unkeyed checksum of application data may be included in
+       an authenticator encrypted in a service's key; since rsa-md5
+       is believed to be collision-proof, even if the application
+       data is exposed to an attacker, it cannot be modified without
+       causing the checksum verification to fail.
+
+   [7] 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 0xF0F0F0F0F0F0F0F0 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.
+
+   [8] Perhaps one of the more common reasons for directly
+       performing encryption is direct control over the negotiation
+       and to select a "sufficiently strong" encryption algorithm
+       (whatever that means in the context of a given application).
+       While Kerberos directly provides no facility for negotiating
+       encryption types between the application client and server,
+       there are other means for accomplishing similar goals.  For
+       example, requesting only "strong" session key types from the
+       KDC, and assuming that the type actually returned by the KDC
+       will be understood and supported by the application server.
+
+Normative References
+
+   [Bellare98]
+      Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
+      "Relations Among Notions of Security for Public-Key Encryption
+      Schemes".  Extended abstract published in Advances in Cryptology-
+      Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
+      1462, H. Krawcyzk ed., Springer-Verlag, 1998.
+
+
+
+
+
+Raeburn                                                        [Page 47]
+
+INTERNET DRAFT                                              October 2003
+
+
+   [Blumenthal96]
+      Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
+      Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
+   [CRC]
+      International Organization for Standardization, "ISO Information
+      Processing Systems - Data Communication - High-Level Data Link
+      Control Procedure - Frame Structure," IS 3309, 3rd Edition,
+      October 1984.
+   [DES77]
+      National Bureau of Standards, U.S. Department of Commerce, "Data
+      Encryption Standard," Federal Information Processing Standards
+      Publication 46, Washington, DC, 1977.
+   [DESI81]
+      National Bureau of Standards, U.S. Department of Commerce,
+      "Guidelines for implementing and using NBS Data Encryption
+      Standard," Federal Information Processing Standards Publication
+      74, Washington, DC, 1981.
+   [DESM80]
+      National Bureau of Standards, U.S. Department of Commerce, "DES
+      Modes of Operation," Federal Information Processing Standards
+      Publication 81, Springfield, VA, December 1980.
+   [Dolev91]
+      Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
+      Proceedings of the 23rd Annual Symposium on Theory of Computing,
+      ACM, 1991.
+   [HMAC]
+      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+      for Message Authentication", RFC 2104, February 1997.
+   [KRB5-AES]
+      Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
+      2003.
+   [MD4-92]
+      Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
+      Laboratory for Computer Science, April 1992.
+   [MD5-92]
+      Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
+      Laboratory for Computer Science, April 1992.
+   [RFC2026]
+      Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
+      2026, October 1996.
+   [SG92]
+      Stubblebine, S., and V. D. Gligor, "On Message Integrity in
+      Cryptographic Protocols," in Proceedings of the IEEE Symposium on
+      Research in Security and Privacy, Oakland, California, May 1992.
+
+
+
+
+
+
+
+Raeburn                                                        [Page 48]
+
+INTERNET DRAFT                                              October 2003
+
+
+Informative References
+
+   [Bellovin91]
+      Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos
+      Authentication System", in Proceedings of the Winter 1991 Usenix
+      Security Conference, January, 1991.
+   [Bellovin99]
+      Bellovin, S. M., and D. Atkins, private communications, 1999.
+   [EFF-DES]
+      Electronic Frontier Foundation, "Cracking DES: Secrets of
+      Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
+      & Associates, Inc., May 1998.
+   [ESP-DES]
+      Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
+      With Explicit IV", RFC 2405, November 1998.
+   [GSS-KRB5]
+      Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
+      June 1996.
+   [HMAC-TEST]
+      Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
+      RFC 2202, September 1997.
+   [IPSEC-HMAC]
+      Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
+      AH", RFC 2404, November 1998.
+   [Kerb]
+      Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
+      Raeburn, "The Kerberos Network Authentication Service (V5)",
+      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
+      2002.  Work in progress.
+   [Kerb1510]
+      Kohl, J., and C. Neuman, "The Kerberos Network Authentication
+      Service (V5)", RFC 1510, September 1993.
+   [RC5]
+      Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+      RC5-CTS Algorithms", RFC 2040, October 1996.
+   [Schneier96]
+      Schneier, B., "Applied Cryptography Second Edition", John Wiley &
+      Sons, New York, NY, 1996.  ISBN 0-471-12845-7.
+
+Editor's address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+
+
+
+
+Raeburn                                                        [Page 49]
+
+INTERNET DRAFT                                              October 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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."
+
+Notes to RFC Editor
+
+   Before publication of this document as an RFC, the following changes
+   are needed:
+
+   Change the reference "[KRB5-AES]" in Normative References to indicate
+   the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
+   advancing to RFC at the same time.  The RFC number and publication
+   date are needed.
+
+   If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
+   same time as this document, change the information for [Kerb] in the
+   Informative References section as well.
+
+   Change the first-page headers to indicate the RFC number, network
+   working group, etc, as appropriate for an RFC instead of an I-D.
+
+   Remove the contact-info paragraph from the Abstract.
+
+   Delete this section.
+
+
+
+Raeburn                                                        [Page 50]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-07.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-07.txt
new file mode 100644
index 00000000000..7909c374307
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-crypto-07.txt
@@ -0,0 +1,2858 @@
+
+
+
+
+
+
+
+
+
+INTERNET DRAFT                                                K. Raeburn
+Kerberos Working Group                                               MIT
+Document: draft-ietf-krb-wg-crypto-07.txt              February 10, 2004
+                                                 expires August 10, 2004
+
+                 Encryption and Checksum Specifications
+                             for Kerberos 5
+
+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.html.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   This document describes a framework for defining encryption and
+   checksum mechanisms for use with the Kerberos protocol, defining an
+   abstraction layer between the Kerberos protocol and related
+   protocols, and the actual mechanisms themselves.  Several mechanisms
+   are also defined in this document.  Some are taken from RFC 1510,
+   modified in form to fit this new framework, and occasionally modified
+   in content when the old specification was incorrect.  New mechanisms
+   are presented here as well.  This document does NOT indicate which
+   mechanisms may be considered "required to implement".
+
+   Comments should be sent to the editor, or to the IETF Kerberos
+   working group (ietf-krb-wg@anl.gov).
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                             February 2004
+
+
+                           1mTable of Contents0m
+
+
+Status of this Memo  . . . . . . . . . . . . . . . . . . . . . . . .   1
+Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
+Table of Contents  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+2. Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+3. Encryption algorithm profile  . . . . . . . . . . . . . . . . . .   4
+4. Checksum algorithm profile  . . . . . . . . . . . . . . . . . . .   9
+5. Simplified profile for CBC ciphers with key derivation  . . . . .  10
+5.1. A key derivation function . . . . . . . . . . . . . . . . . . .  11
+5.2. Simplified profile parameters . . . . . . . . . . . . . . . . .  13
+5.3. Cryptosystem profile based on simplified profile  . . . . . . .  14
+5.4. Checksum profiles based on simplified profile . . . . . . . . .  16
+6. Profiles for Kerberos encryption and checksum algorithms  . . . .  16
+6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . .  17
+6.2. DES-based encryption and checksum types . . . . . . . . . . . .  18
+6.3. Triple-DES based encryption and checksum types  . . . . . . . .  28
+7. Use of Kerberos encryption outside this specification . . . . . .  30
+8. Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . . .  31
+9. Implementation Notes  . . . . . . . . . . . . . . . . . . . . . .  33
+10. Security Considerations  . . . . . . . . . . . . . . . . . . . .  33
+11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  35
+12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  36
+A. Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . . .  37
+A.1. n-fold  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  37
+A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . .  39
+A.3. DES3 DR and DK  . . . . . . . . . . . . . . . . . . . . . . . .  43
+A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . .  44
+A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . .  45
+B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . .  45
+Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  46
+Intellectual Property Statement  . . . . . . . . . . . . . . . . . .  47
+Normative References . . . . . . . . . . . . . . . . . . . . . . . .  48
+Informative References . . . . . . . . . . . . . . . . . . . . . . .  49
+Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . .  50
+Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .  50
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                             February 2004
+
+
+1. Introduction
+
+   The Kerberos protocols [Kerb] are designed to encrypt messages of
+   arbitrary sizes, using block encryption ciphers, or less commonly,
+   stream encryption ciphers.  Encryption is used to prove the
+   identities of the network entities participating in message
+   exchanges.  However, nothing in the Kerberos protocol requires any
+   specific encryption algorithm be used, as long as certain operations
+   are available in the algorithm that is used.
+
+   The following sections specify the encryption and checksum mechanisms
+   currently defined for Kerberos, as well as a framework for defining
+   future mechanisms.  The encoding, chaining, padding and other
+   requirements for each are described.  Test vectors for several
+   functions are given in appendix A.
+
+2. Concepts
+
+   Both encryption and checksum mechanisms are defined in terms of
+   profiles, detailed in later sections.  Each specifies a collection of
+   operations and attributes that must be defined for a mechanism.  A
+   Kerberos encryption or checksum mechanism specification is not
+   complete if it does not define all of these operations and
+   attributes.
+
+   An encryption mechanism must provide for confidentiality and
+   integrity of the original plaintext.  (Integrity checking may be
+   achieved by incorporating a checksum, if the encryption mode does not
+   provide an integrity check itself.)  It must also provide non-
+   malleability [Bellare98, Dolev91].  Use of a random confounder
+   prepended to the plaintext is recommended.  It should not be possible
+   to determine if two ciphertexts correspond to the same plaintext,
+   without knowledge of the key.
+
+   A checksum mechanism [1] must provide proof of the integrity of the
+   associated message, and must preserve the confidentiality of the
+   message in case it is not sent in the clear.  It should be infeasible
+   to find two plaintexts which have the same checksum.  It is NOT
+   required that an eavesdropper be unable to determine if two checksums
+   are for the same message; it is assumed that the messages themselves
+   will be visible to any such eavesdropper.
+
+   Due to advances in cryptography, it is considered unwise by some
+   cryptographers to use the same key for multiple purposes.  Since keys
+   are used in performing a number of different functions in Kerberos,
+   it is desirable to use different keys for each of these purposes,
+   even though we start with a single long-term or session key.
+
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                             February 2004
+
+
+   We do this by enumerating the different uses of keys within Kerberos,
+   and making the "usage number" an input to the encryption or checksum
+   mechanisms; this enumeration is outside the scope of this document.
+   Later sections of this document define simplified profile templates
+   for encryption and checksum mechanisms that use a key derivation
+   function applied to a CBC mode (or similar) cipher and a checksum or
+   hash algorithm.
+
+   We distinguish the "base key" specified by other documents from the
+   "specific key" to be used for a particular instance of encryption or
+   checksum operations.  It is expected but not required that the
+   specific key will be one or more separate keys derived from the
+   original protocol key and the key usage number.  The specific key
+   should not be explicitly referenced outside of this document.  The
+   typical language used in other documents should be something like,
+   "encrypt this octet string using this key and this usage number";
+   generation of the specific key and cipher state (described in the
+   next section) are implicit.  The creation of a new cipher-state
+   object, or the re-use of one from a previous encryption operation,
+   may also be explicit.
+
+   New protocols defined in terms of the Kerberos encryption and
+   checksum types should use their own key usage values.  Key usages are
+   unsigned 32 bit integers; zero is not permitted.
+
+   All data is assumed to be in the form of strings of octets or 8-bit
+   bytes.  Environments with other byte sizes will have to emulate this
+   behavior in order to get correct results.
+
+   Each algorithm is assigned an encryption type (or "etype") or
+   checksum type number, for algorithm identification within the
+   Kerberos protocol.  The full list of current type number assignments
+   is given in section 8.
+
+3. Encryption algorithm profile
+
+   An encryption mechanism profile must define the following attributes
+   and operations.  The operations must be defined as functions in the
+   mathematical sense: no additional or implicit inputs (such as
+   Kerberos principal names or message sequence numbers) are permitted.
+
+   protocol key format
+      This describes what octet string values represent valid keys.  For
+      encryption mechanisms that don't have perfectly dense key spaces,
+      this will describe the representation used for encoding keys.  It
+      need not describe specific values that are not valid or desirable
+      for use; such values should be avoid by all key generation
+      routines.
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                             February 2004
+
+
+   specific key structure
+      This is not a protocol format at all, but a description of the
+      keying material derived from the chosen key and used to encrypt or
+      decrypt data or compute or verify a checksum.  It may, for
+      example, be a single key, a set of keys, or a combination of the
+      original key with additional data.  The authors recommend using
+      one or more keys derived from the original key via one-way key
+      derivation functions.
+
+   required checksum mechanism
+      This indicates a checksum mechanism that must be available when
+      this encryption mechanism is used.  Since Kerberos has no built in
+      mechanism for negotiating checksum mechanisms, once an encryption
+      mechanism has been decided upon, the corresponding checksum
+      mechanism can simply be used.
+
+   key-generation seed length, K
+      This is the length of the random bitstring needed to generate a
+      key with the encryption scheme's random-to-key function (described
+      below).  This must be a fixed value so that various techniques for
+      producing a random bitstring of a given length may be used with
+      key generation functions.
+
+   key generation functions
+      Keys must be generated in a number of cases, from different types
+      of inputs.  All function specifications must indicate how to
+      generate keys in the proper wire format, and must avoid generation
+      of keys that significantly compromise the confidentiality of
+      encrypted data, if the cryptosystem has such.  Entropy from each
+      source should be preserved as much as possible.  Many of the
+      inputs, while unknown, may be at least partly predictable (e.g., a
+      password string is likely to be entirely in the ASCII subset and
+      of fairly short length in many environments; a semi-random string
+      may include timestamps); the benefit of such predictability to an
+      attacker must be minimized.
+
+      string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
+         This function generates a key from two UTF-8 strings and an
+         opaque octet string.  One of the strings is normally the
+         principal's pass phrase, but is in general merely a secret
+         string.  The other string is a "salt" string intended to
+         produce different keys from the same password for different
+         users or realms.  While the strings provided will use UTF-8
+         encoding, no specific version of Unicode should be assumed; all
+         valid UTF-8 strings should be allowed.  Strings provided in
+         other encodings MUST first be converted to UTF-8 before
+         applying this function.
+
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                             February 2004
+
+
+         The third argument, the octet string, may be used to pass
+         mechanism-specific parameters in to this function.  Since doing
+         so implies knowledge of the specific encryption system, it is
+         intended that generating non-default parameter values be an
+         uncommon operation, and that normal Kerberos applications be
+         able to treat this parameter block as an opaque object supplied
+         by the Key Distribution Center or defaulted to some mechanism-
+         specific constant value.
+
+         The string-to-key function should be a one-way function, so
+         that compromising a user's key in one realm does not compromise
+         the user's key in another realm, even if the same password (but
+         a different salt) is used.
+
+      random-to-key (bitstring[K])->(protocol-key)
+         This function generates a key from a random bitstring of a
+         specific size.  It may be assumed that all the bits of the
+         input string are equally random, even though the entropy
+         present in the random source may be limited.
+
+      key-derivation (protocol-key, integer)->(specific-key)
+         In this function, the integer input is the key usage value as
+         described above; the usage values must be assumed to be known
+         to an attacker.  The specific-key output value was described in
+         section 2.
+
+   string-to-key parameter format
+      This describes the format of the block of data that can be passed
+      to the string-to-key function above to configure additional
+      parameters for that function.  Along with the mechanism of
+      encoding parameter values, bounds on the allowed parameters should
+      also be described to avoid allowing a spoofed KDC to compromise
+      the user's password.  It may be desirable to construct the
+      encoding such that values weakening the resulting key unacceptably
+      cannot be encoded, if practical.
+
+      Tighter bounds might be permitted by local security policy, or to
+      avoid excess resource consumption; if so, recommended defaults for
+      those bounds should be given in the specification.  The
+      description should also outline possible weaknesses that may be
+      caused by not applying bounds checks or other validation to a
+      parameter string received from the network.
+
+      As mentioned above, this should be considered opaque to most
+      normal applications.
+
+
+
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                             February 2004
+
+
+   default string-to-key parameters (octet string)
+      This default value for the "params" argument to the string-to-key
+      function is to be used when the application protocol (Kerberos or
+      otherwise) does not explicitly set the parameter value.  As
+      indicated above, this parameter block should be treated as an
+      opaque object in most cases.
+
+   cipher state
+      This describes any information that can be carried over from one
+      encryption or decryption operation to the next, for use in
+      conjunction with a given specific key.  For example, a block
+      cipher used in CBC mode may put an initial vector of one block in
+      the cipher state.  Other encryption modes may track nonces or
+      other data.
+
+      This state must be non-empty, and must influence encryption so as
+      to require that messages be decrypted in the same order they were
+      encrypted, if the cipher state is carried over from one encryption
+      to the next.  Distinguishing out-of-order or missing messages from
+      corrupted messages is not required; if desired, this can be done
+      at a higher level by including sequence numbers and not "chaining"
+      the cipher state between encryption operations.
+
+      The cipher state may not be reused in multiple encryption or
+      decryption operations; these operations all generate a new cipher
+      state that may be used for following operations using the same key
+      and operation.
+
+      The contents of the cipher state must be treated as opaque outside
+      of encryption system specifications.
+
+   initial cipher state (specific-key, direction)->(state)
+      This describes the generation of the initial value for the cipher
+      state if it is not being carried over from a previous encryption
+      or decryption operation.
+
+      This describes any initial state setup needed before encrypting
+      arbitrary amounts of data with a given specific key; the specific
+      key and the direction of operations to be performed (encrypt
+      versus decrypt) must be the only input needed for this
+      initialization.
+
+      This state should be treated as opaque in any uses outside of an
+      encryption algorithm definition.
+
+      IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
+      degree an application protocol could exercise control over the
+      initial vector used in DES CBC operations.  Some existing
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                             February 2004
+
+
+      implementations permit the setting of the initial vector.  This
+      framework does not provide for application control of the cipher
+      state (beyond "initialize" and "carry over from previous
+      encryption"), since the form and content of the initial cipher
+      state can vary between encryption systems, and may not always be a
+      single block of random data.
+
+      New Kerberos application protocols should not assume that they can
+      control the initial vector, or that one even exists.  However, a
+      general-purpose implementation may wish to provide the capability,
+      in case applications explicitly setting it are encountered.
+
+   encrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and a non-
+      empty plaintext string as input, and generates ciphertext and a
+      new cipher state as outputs.  If the basic encryption algorithm
+      itself does not provide for integrity protection (as DES in CBC
+      mode does not do), then some form of MAC or checksum must be
+      included that can be verified by the receiver.  Some random factor
+      such as a confounder should be included so that an observer cannot
+      know if two messages contain the same plaintext, even if the
+      cipher state and specific keys are the same.  The exact length of
+      the plaintext need not be encoded, but if it is not and if padding
+      is required, the padding must be added at the end of the string so
+      that the decrypted version may be parsed from the beginning.
+
+      The specification of the encryption function must not only
+      indicate the precise contents of the output octet string, but also
+      the output cipher state.  The application protocol may carry
+      forward the output cipher state from one encryption with a given
+      specific key to another; the effect of this "chaining" must be
+      defined.  [2]
+
+      Assuming correctly-produced values for the specific key and cipher
+      state, no input octet string may result in an error indication.
+
+   decrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and ciphertext
+      as inputs, and verifies the integrity of the supplied ciphertext.
+      If the ciphertext's integrity is intact, this function produces
+      the plaintext and a new cipher state as outputs; otherwise, an
+      error indication must be returned, and the data discarded.
+
+      The result of the decryption may be longer than the original
+      plaintext, for example if the encryption mode adds padding to
+      reach a multiple of a block size.  If this is the case, any extra
+      octets must be after the decoded plaintext.  An application
+      protocol which needs to know the exact length of the message must
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                             February 2004
+
+
+      encode a length or recognizable "end of message" marker within the
+      plaintext.  [3]
+
+      As with the encryption function, a correct specification for this
+      function must indicate not only the contents of the output octet
+      string, but also the resulting cipher state.
+
+   pseudo-random (protocol-key, octet-string)->(octet-string)
+      This pseudo-random function should generate an octet string of
+      some size that independent of the octet string input.  The PRF
+      output string should be suitable for use in key generation, even
+      if the octet string input is public.  It should not reveal the
+      input key, even if the output is made public.
+
+   These operations and attributes are all that is required to support
+   Kerberos and various proposed preauthentication schemes.
+
+   For convenience of certain application protocols that may wish to use
+   the encryption profile, we add the constraint that, for any given
+   plaintext input size, there must be a message size between that given
+   size and that size plus 65535 such that the length of such that the
+   decrypted version of the ciphertext for any message of that size will
+   never have extra octets added at the end.
+
+   Expressed mathematically, for every message length L1, there exists a
+   message size L2 such that:
+
+     L2 >= L1
+     L2 < L1 + 65536
+     for every message M with |M| = L2, decrypt(encrypt(M)) = M
+
+   A document defining a new encryption type should also describe known
+   weaknesses or attacks, so that its security may be fairly assessed,
+   and should include test vectors or other validation procedures for
+   the operations defined.  Specific references to information readily
+   available elsewhere are sufficient.
+
+4. Checksum algorithm profile
+
+   A checksum mechanism profile must define the following attributes and
+   operations:
+
+   associated encryption algorithm(s)
+      This indicates the types of encryption keys this checksum
+      mechanism can be used with.
+
+      A keyed checksum mechanism may have more than one associated
+      encryption algorithm if they share the same wire key format,
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                             February 2004
+
+
+      string-to-key function, and key derivation function. (This
+      combination means that, for example, a checksum type, key usage
+      value and password are adequate to get the specific key used to
+      compute a checksum.)
+
+      An unkeyed checksum mechanism can be used in conjunction with any
+      encryption type, since the key is ignored, but its use must be
+      limited to cases where the checksum itself is protected, to avoid
+      trivial attacks.
+
+   get_mic function
+      This function generates a MIC token for a given specific key (see
+      section 3), and message (represented as an octet string), that may
+      be used to verify the integrity of the associated message.  This
+      function is not required to return the same deterministic result
+      on every use; it need only generate a token that the verify_mic
+      routine can check.
+
+      The output of this function will also dictate the size of the
+      checksum.  It must be no larger than 65535 octets.
+
+   verify_mic function
+      Given a specific key, message, and MIC token, this function
+      ascertains whether the message integrity has been compromised.
+      For a deterministic get_mic routine, the corresponding verify_mic
+      may simply generate another checksum and compare them.
+
+   The get_mic and verify_mic operations must be able to handle inputs
+   of arbitrary length; if any padding is needed, the padding scheme
+   must be specified as part of these functions.
+
+   These operations and attributes are all that should be required to
+   support Kerberos and various proposed preauthentication schemes.
+
+   As with encryption mechanism definition documents, documents defining
+   new checksum mechanisms should indicate validation processes and
+   known weaknesses.
+
+5. Simplified profile for CBC ciphers with key derivation
+
+   The profile outlines in sections 3 and 4 describes a large number of
+   operations that must be defined for encryption and checksum
+   algorithms to be used with Kerberos.  We describe here a simpler
+   profile from which both encryption and checksum mechanism definitions
+   can be generated, filling in uses of key derivation in appropriate
+   places, providing integrity protection, and defining multiple
+   operations for the cryptosystem profile based on a smaller set of
+   operations given in the simplified profile.  Not all of the existing
+
+
+
+Raeburn                                                        [Page 10]
+
+INTERNET DRAFT                                             February 2004
+
+
+   cryptosystems for Kerberos fit into this simplified profile, but we
+   recommend that future cryptosystems use it or something based on it.
+   [4]
+
+   Not all of the operations in the complete profiles are defined
+   through this mechanism; several must still be defined for each new
+   algorithm pair.
+
+5.1. A key derivation function
+
+   Rather than define some scheme by which a "protocol key" is composed
+   of a large number of encryption keys, we use keys derived from a base
+   key to perform cryptographic operations.  The base key must be used
+   only for generating the derived keys, and this derivation must be
+   non-invertible and entropy-preserving.  Given these restrictions,
+   compromise of one derived key does not compromise the other subkeys.
+   Attack of the base key is limited, since it is only used for
+   derivation, and is not exposed to any user data.
+
+   Since the derived key has as much entropy as the base keys (if the
+   cryptosystem is good), password-derived keys have the full benefit of
+   all the entropy in the password.
+
+   To generate a derived key from a base key, we generate a pseudorandom
+   octet string, using an algorithm DR described below, and generate a
+   key from that octet string using a function dependent on the
+   encryption algorithm; the input length needed for that function,
+   which is also dependent on the encryption algorithm, dictates the
+   length of the string to be generated by the DR algorithm (the value
+   "k" below).  These procedures are based on the key derivation in
+   [Blumenthal96].
+
+      Derived Key = DK(Base Key, Well-Known Constant)
+
+      DK(Key, Constant) = random-to-key(DR(Key, Constant))
+
+      DR(Key, Constant) = k-truncate(E(Key, Constant,
+                                       initial-cipher-state))
+
+   Here DR is the random-octet generation function described below, and
+   DK is the key-derivation function produced from it.  In this
+   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
+   a well-known constant determined by the specific usage of this
+   function, and k-truncate truncates its argument by taking the first k
+   bits.  Here, k is the key generation seed length needed for the
+   encryption system.
+
+   The output of the DR function is a string of bits; the actual key is
+
+
+
+Raeburn                                                        [Page 11]
+
+INTERNET DRAFT                                             February 2004
+
+
+   produced by applying the cryptosystem's random-to-key operation on
+   this bitstring.
+
+   If the Constant is smaller than the cipher block size of E, then it
+   must be expanded with n-fold() so it can be encrypted.  If the output
+   of E is shorter than k bits it is fed back into the encryption as
+   many times as necessary.  The construct is as follows (where |
+   indicates concatentation):
+
+      K1 = E(Key, n-fold(Constant), initial-cipher-state)
+      K2 = E(Key, K1, initial-cipher-state)
+      K3 = E(Key, K2, initial-cipher-state)
+      K4 = ...
+
+      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
+
+   n-fold is an algorithm which takes m input bits and ``stretches''
+   them to form n output bits with equal contribution from each input
+   bit to the output, as described in [Blumenthal96]:
+
+      We first define a primitive called n-folding, which takes a
+      variable-length input block and produces a fixed-length output
+      sequence.  The intent is to give each input bit approximately
+      equal weight in determining the value of each output bit.  Note
+      that whenever we need to treat a string of octets as a number, the
+      assumed representation is Big-Endian -- Most Significant Byte
+      first.
+
+      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, with end-around carry) to yield
+      a n-bit result....
+
+
+   Test vectors for n-fold are supplied in Appendix A.  [5]
+
+   In this section, n-fold is always used to produce c bits of output,
+   where c is the cipher block size of E.
+
+   The size of the Constant must not be larger than c, because reducing
+   the length of the Constant by n-folding can cause collisions.
+
+   If the size of the Constant is smaller than c, then the Constant must
+   be n-folded to length c.  This string is used as input to E.  If the
+   block size of E is less than the random-to-key input size, then the
+   output from E is taken as input to a second invocation of E.  This
+
+
+
+Raeburn                                                        [Page 12]
+
+INTERNET DRAFT                                             February 2004
+
+
+   process is repeated until the number of bits accumulated is greater
+   than or equal to the random-to-key input size.  When enough bits have
+   been computed, the first k are taken as the random data used to
+   create the key with the algorithm-dependent random-to-key function.
+
+   Since the derived key is the result of one or more encryptions in the
+   base key, deriving the base key from the derived key is equivalent to
+   determining the key from a very small number of plaintext/ciphertext
+   pairs.  Thus, this construction is as strong as the cryptosystem
+   itself.
+
+5.2. Simplified profile parameters
+
+   These are the operations and attributes that must be defined:
+
+   protocol key format
+   string-to-key function
+   default string-to-key parameters
+   key-generation seed length, k
+   random-to-key function
+      As above for the normal encryption mechanism profile.
+
+   unkeyed hash algorithm, H
+      This should be a collision-resistant hash algorithm with fixed-
+      size output, suitable for use in an HMAC [HMAC].  It must support
+      inputs of arbitrary length.  Its output must be at least the
+      message block size (below).
+
+   HMAC output size, h
+      This indicates the size of the leading substring output by the
+      HMAC function that should be used in transmitted messages.  It
+      should be at least half the output size of the hash function H,
+      and at least 80 bits; it need not match the output size.
+
+   message block size, m
+      This is the size of the smallest units the cipher can handle in
+      the mode in which it is being used.  Messages will be padded to a
+      multiple of this size.  If a block cipher is used in a mode that
+      can handle messages that are not multiples of the cipher block
+      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
+      this value would be one octet.  For traditional CBC mode with
+      padding, it will be the underlying cipher's block size.
+
+      This value must be a multiple of 8 bits (one octet).
+
+
+
+
+
+
+
+Raeburn                                                        [Page 13]
+
+INTERNET DRAFT                                             February 2004
+
+
+   encryption/decryption functions, E and D
+      These are basic encryption and decryption functions for messages
+      of sizes that are multiples of the message block size.  No
+      integrity checking or confounder should be included here.  These
+      functions take as input the IV or similar data, a protocol-format
+      key, and a octet string, returning a new IV and octet string.
+
+      The encryption function is not required to use CBC mode, but is
+      assumed to be using something with similar properties.  In
+      particular, prepending a cipher-block-size confounder to the
+      plaintext should alter the entire ciphertext (comparable to
+      choosing and including a random initial vector for CBC mode).
+
+      The result of encrypting one cipher block (of size c, above) must
+      be deterministic, for the random octet generation function DR in
+      the previous section to work.  For best security, it should also
+      be no larger than c.
+
+   cipher block size, c
+      This is the block size of the block cipher underlying the
+      encryption and decryption functions indicated above, used for key
+      derivation and for the size of the message confounder and initial
+      vector.  (If a block cipher is not in use, some comparable
+      parameter should be determined.)  It must be at least 5 octets.
+
+      This is not actually an independent parameter; rather, it is a
+      property of the functions E and D.  It is listed here to clarify
+      the distinction between it and the message block size, m.
+
+   While there are still a number of properties to specify, they are
+   fewer and simpler than in the full profile.
+
+5.3. Cryptosystem profile based on simplified profile
+
+   The above key derivation function is used to produce three
+   intermediate keys.  One is used for computing checksums of
+   unencrypted data.  The other two are used for encrypting and
+   checksumming plaintext to be sent encrypted.
+
+   The ciphertext output is the concatenation of the output of the basic
+   encryption function E and a (possibly truncated) HMAC using the
+   specified hash function H, both applied to the plaintext with a
+   random confounder prefix and sufficient padding to bring it to a
+   multiple of the message block size.  When the HMAC is computed, the
+   key is used in the protocol key form.
+
+   Decryption is performed by removing the (partial) HMAC, decrypting
+   the remainder, and verifying the HMAC.  The cipher state is an
+
+
+
+Raeburn                                                        [Page 14]
+
+INTERNET DRAFT                                             February 2004
+
+
+   initial vector, initialized to zero.
+
+   The substring notation "[1..h]" in the following table should be read
+   as using 1-based indexing; leading substrings are used.
+
+
+                   cryptosystem from simplified profile
+----------------------------------------------------------------------------
+protocol key format       As given.
+
+specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
+
+key-generation seed       As given.
+length
+
+required checksum         As defined below in section 5.4.
+mechanism
+
+cipher state              initial vector (usually of length c)
+
+initial cipher state      all bits zero
+
+encryption function       conf = random string of length c
+                          pad = shortest string to bring confounder
+                                and plaintext to a length that's a
+                                multiple of m
+                          (C1, newIV) = E(Ke, conf | plaintext | pad,
+                                          oldstate.ivec)
+                          H1 = HMAC(Ki, conf | plaintext | pad)
+                          ciphertext =  C1 | H1[1..h]
+                          newstate.ivec = newIV
+
+decryption function       (C1,H1) = ciphertext
+                          (P1, newIV) = D(Ke, C1, oldstate.ivec)
+                          if (H1 != HMAC(Ki, P1)[1..h])
+                             report error
+                          newstate.ivec = newIV
+
+default string-to-key     As given.
+params
+
+pseudo-random function    tmp1 = H(octet-string)
+                          tmp2 = truncate tmp1 to multiple of m
+                          PRF = E(protocol-key, tmp2, initial-cipher-state)
+
+key generation functions:
+
+
+
+
+
+Raeburn                                                        [Page 15]
+
+INTERNET DRAFT                                             February 2004
+
+
+                   cryptosystem from simplified profile
+----------------------------------------------------------------------------
+string-to-key function    As given.
+
+random-to-key function    As given.
+
+key-derivation function   The "well-known constant" used for the DK
+                          function is the key usage number, expressed as
+                          four octets in big-endian order, followed by one
+                          octet indicated below.
+
+                          Kc = DK(base-key, usage | 0x99);
+                          Ke = DK(base-key, usage | 0xAA);
+                          Ki = DK(base-key, usage | 0x55);
+
+
+5.4. Checksum profiles based on simplified profile
+
+   When an encryption system is defined using the simplified profile
+   given in section 5.2, a checksum algorithm may be defined for it as
+   follows:
+
+
+                checksum mechanism from simplified profile
+             --------------------------------------------------
+             associated cryptosystem   as defined above
+
+             get_mic                   HMAC(Kc, message)[1..h]
+
+             verify_mic                get_mic and compare
+
+   The HMAC function and key Kc are as described in section 5.3.
+
+6. Profiles for Kerberos encryption and checksum algorithms
+
+   These profiles describe the encryption and checksum systems defined
+   for Kerberos.  The astute reader will notice that some of them do not
+   fulfull all of the requirements outlined in previous sections.  These
+   systems are defined for backward compatibility; newer implementations
+   should (whenever possible) attempt to make use of encryption systems
+   which satisfy all of the profile requirements.
+
+   The full list of current encryption and checksum type number
+   assignments, including values currently reserved but not defined in
+   this document, is given in section 8.
+
+
+
+
+
+
+Raeburn                                                        [Page 16]
+
+INTERNET DRAFT                                             February 2004
+
+
+6.1. Unkeyed checksums
+
+   These checksum types use no encryption keys, and thus can be used in
+   combination with any encryption type, but may only be used with
+   caution, in limited circumstances where the lack of a key does not
+   provide a window for an attack, preferably as part of an encrypted
+   message.  [6] Keyed checksum algorithms are recommended.
+
+6.1.1. The RSA MD5 Checksum
+
+   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.
+
+                                  rsa-md5
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   rsa-md5(msg)
+
+               verify_mic                get_mic and compare
+
+   The rsa-md5 checksum algorithm is assigned a checksum type number of
+   seven (7).
+
+6.1.2. The RSA MD4 Checksum
+
+   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.
+
+
+                                  rsa-md4
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   md4(msg)
+
+               verify_mic                get_mic and compare
+
+
+   The rsa-md4 checksum algorithm is assigned a checksum type number of
+   two (2).
+
+
+
+
+
+
+Raeburn                                                        [Page 17]
+
+INTERNET DRAFT                                             February 2004
+
+
+6.1.3. CRC-32 Checksum
+
+   This CRC-32 checksum calculates a checksum based on a cyclic
+   redundancy check as described in ISO 3309 [CRC], modified as
+   described below.  The resulting checksum is four (4) octets in
+   length.  The CRC-32 is neither keyed nor collision-proof; thus, 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 CRC-32 checksum used in the des-cbc-crc encryption mode is
+   identical to the 32-bit FCS described in ISO 3309 with two
+   exceptions: the sum with the all-ones polynomial times x**k is
+   omitted, and the final remainder is not ones-complemented.  ISO 3309
+   describes the FCS in terms of bits, while this document describes the
+   Kerberos protocol in terms of octets.  To disambiguate the ISO 3309
+   definition for the purpose of computing the CRC-32 in the des-cbc-crc
+   encryption mode, the ordering of bits in each octet shall be assumed
+   to be LSB-first.  Given this assumed ordering of bits within an
+   octet, the mapping of bits to polynomial coefficients shall be
+   identical to that specified in ISO 3309.
+
+   Test values for this modified CRC function are included in appendix
+   A.5.
+
+
+                                   crc32
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   crc32(msg)
+
+               verify_mic                get_mic and compare
+
+
+   The crc32 checksum algorithm is assigned a checksum type number of
+   one (1).
+
+6.2. DES-based encryption and checksum types
+
+   These encryption systems encrypt information under the Data
+   Encryption Standard [DES77] using the cipher block chaining mode
+   [DESM80].  A checksum is computed as described below 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 values
+   of the padding bytes are unspecified.
+
+
+
+
+Raeburn                                                        [Page 18]
+
+INTERNET DRAFT                                             February 2004
+
+
+   Plaintext and DES ciphertext 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 MSB used as the DES input block's MSB, 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; this vector
+   is specified for each encryption system, below.
+
+   The DES specifications [DESI81] identify four 'weak' and twelve
+   'semi-weak' keys; those keys SHALL NOT be used for encrypting
+   messages for use in Kerberos.  The "variant keys" generated for the
+   RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive-
+   or of a DES key with a constant are not checked for this property.
+
+   A DES key is 8 octets of data.  This consists of 56 bits of actual
+   key data, 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 most significant bit).  See the
+   [DESM80] introduction for reference.
+
+   Encryption data format
+
+   The format for the data to be encrypted includes a one-block
+   confounder, a checksum, the encoded plaintext, and any necessary
+   padding, as described in the following diagram.  The msg-seq field
+   contains the part of the protocol message which is to be encrypted.
+
+                  +-----------+----------+---------+-----+
+                  |confounder | checksum | msg-seq | pad |
+                  +-----------+----------+---------+-----+
+
+   One generates a random confounder of one block, placing it in
+   'confounder'; zeroes out the 'checksum' field (of length appropriate
+   to exactly hold the checksum to be computed); calculates the
+   appropriate checksum over the whole sequence, placing the result in
+   'checksum'; adds the necessary padding; then encrypts using the
+   specified encryption type and the appropriate key.
+
+   String or random-data to key transformation
+
+   To generate a DES key from two UTF-8 text strings (password and
+
+
+
+Raeburn                                                        [Page 19]
+
+INTERNET DRAFT                                             February 2004
+
+
+   salt), the two strings are concatenated, password first, and the
+   result is then padded with zero-valued octets to a multiple of 8
+   octets.
+
+   The top bit of each octet (always zero if the password is plain
+   ASCII, as was assumed when the original specification was written) is
+   discarded, and a bitstring is formed of the remaining seven bits of
+   each octet.  This bitstring is then fan-folded and eXclusive-ORed
+   with itself to produce a 56-bit string.  An eight-octet key is formed
+   from this string, each octet using seven bits from the bitstring,
+   leaving the least significant bit unassigned.  The key is then
+   "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
+   0x00000000000000F0.  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 then "corrected" as described above to form the
+   result which is returned as the key.
+
+   For purposes of the string-to-key function, the DES CBC checksum is
+   calculated by CBC encrypting a string using the key as IV and using
+   the final 8 byte block as the checksum.
+
+   Pseudocode follows:
+
+        removeMSBits(8byteblock) {
+          /* Treats a 64 bit block as 8 octets and remove the MSB in
+             each octect (in big endian mode) and concatenates the
+             result.  E.g., input octet string:
+                01110000 01100001 11110011  01110011 11110111 01101111
+                11110010 01100100
+             results in output bitstring:
+                1110000 1100001 1110011  1110011 1110111 1101111
+                1110010 1100100  */
+        }
+
+        reverse(56bitblock) {
+          /* Treats a 56-bit block as a binary string and reverse it.
+             E.g., input string:
+                1000001 1010100 1001000  1000101 1001110 1000001
+                0101110 1001101
+             results in output string:
+                1011001 0111010 1000001  0111001 1010001 0001001
+                0010101 1000001  */
+        }
+
+
+
+
+
+
+Raeburn                                                        [Page 20]
+
+INTERNET DRAFT                                             February 2004
+
+
+        add_parity_bits(56bitblock) {
+          /* Copies a 56-bit block into a 64-bit block, left shift
+             content in each octet and add DES parity bit.
+             E.g., input string:
+                1100000 0001111 0011100  0110100 1000101 1100100
+                0110110 0010111
+             results in output string:
+                11000001 00011111 00111000  01101000 10001010 11001000
+                01101101 00101111  */
+        }
+
+        key_correction(key) {
+             fixparity(key);
+             if (is_weak_key(key))
+                  key = key XOR 0xF0;
+             return(key);
+        }
+
+        mit_des_string_to_key(string,salt) {
+             odd = 1;
+             s = string | salt;
+             tempstring = 0; /* 56-bit string */
+             pad(s); /* with nulls to 8 byte boundary */
+             for (8byteblock in s) {
+                  56bitstring = removeMSBits(8byteblock);
+                  if (odd == 0) reverse(56bitstring);
+                  odd = ! odd;
+                  tempstring = tempstring XOR 56bitstring;
+             }
+             tempkey = key_correction(add_parity_bits(tempstring));
+             key = key_correction(DES-CBC-check(s,tempkey));
+             return(key);
+        }
+
+        des_string_to_key(string,salt,params) {
+             if (length(params) == 0)
+                  type = 0;
+             else if (length(params) == 1)
+                  type = params[0];
+             else
+                  error("invalid params");
+             if (type == 0)
+                  mit_des_string_to_key(string,salt);
+             else
+                  error("invalid params");
+        }
+
+   One common extension is to support the "AFS string-to-key" algorithm,
+
+
+
+Raeburn                                                        [Page 21]
+
+INTERNET DRAFT                                             February 2004
+
+
+   which is not defined here, if the type value above is one (1).
+
+   For generation of a key from a random bitstring, we start with a
+   56-bit string, and as with the string-to-key operation above, insert
+   parity bits, and if the result is a weak or semi-weak key, modify it
+   by exclusive-OR with the constart 0x00000000000000F0:
+
+        des_random_to_key(bitstring) {
+             return key_correction(add_parity_bits(bitstring));
+        }
+
+6.2.1. DES with MD5
+
+   The des-cbc-md5 encryption mode encrypts information under DES in CBC
+   mode with an all-zero initial vector, with an MD5 checksum (described
+   in [MD5-92]) computed and placed in the checksum field.
+
+   The encryption system parameters for des-cbc-md5 are:
+
+                                des-cbc-md5
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md5-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     all-zero
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = md5(confounder | 0000...
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+
+
+
+
+Raeburn                                                        [Page 22]
+
+INTERNET DRAFT                                             February 2004
+
+
+                                des-cbc-md5
+    --------------------------------------------------------------------
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            des_random_to_key
+
+    key-derivation           identity
+
+   The des-cbc-md5 encryption type is assigned the etype value three
+   (3).
+
+6.2.2. DES with MD4
+
+   The des-cbc-md4 encryption mode also encrypts information under DES
+   in CBC mode, with an all-zero initial vector.  An MD4 checksum
+   (described in [MD4-92]) is computed and placed in the checksum field.
+
+                                des-cbc-md4
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md4-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+    initial cipher state     all-zero
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = md4(confounder | 0000...
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+
+
+
+Raeburn                                                        [Page 23]
+
+INTERNET DRAFT                                             February 2004
+
+
+                                des-cbc-md4
+    --------------------------------------------------------------------
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            copy input, then fix parity bits
+
+    key-derivation           identity
+
+   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
+
+   The des-cbc-md4 encryption algorithm is assigned the etype value two
+   (2).
+
+6.2.3. DES with CRC
+
+   The des-cbc-crc encryption type uses DES in CBC mode with the key
+   used as the initialization vector, with a 4-octet CRC-based checksum
+   computed as described in section 6.1.3.  Note that this is not a
+   standard CRC-32 checksum, but a slightly modified one.
+
+
+                                des-cbc-crc
+    --------------------------------------------------------------------
+    protocol key format      8 bytes, parity in low bit of each
+
+    specific key structure   copy of original key
+
+    required checksum        rsa-md5-des
+    mechanism
+
+    key-generation seed      8 bytes
+    length
+
+    cipher state             8 bytes (CBC initial vector)
+
+
+
+
+
+Raeburn                                                        [Page 24]
+
+INTERNET DRAFT                                             February 2004
+
+
+                                des-cbc-crc
+    --------------------------------------------------------------------
+    initial cipher state     copy of original key
+
+    encryption function      des-cbc(confounder | checksum | msg | pad,
+                                     ivec=oldstate)
+                             where
+                             checksum = crc(confounder | 00000000
+                                            | msg | pad)
+
+                             newstate = last block of des-cbc output
+
+    decryption function      decrypt encrypted text and verify checksum
+
+                             newstate = last block of ciphertext
+
+    default string-to-key    empty string
+    params
+
+    pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+    key generation functions:
+
+    string-to-key            des_string_to_key
+
+    random-to-key            copy input, then fix parity bits
+
+    key-derivation           identity
+
+   The des-cbc-crc encryption algorithm is assigned the etype value one
+   (1).
+
+6.2.4. RSA MD5 Cryptographic Checksum Using 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 0xF0F0F0F0F0F0F0F0.  The
+   initialization vector should be zero.  The resulting checksum is 24
+   octets long.  This checksum is tamper-proof and believed to be
+   collision-proof.
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 25]
+
+INTERNET DRAFT                                             February 2004
+
+
+                                rsa-md5-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md5(conf | msg))
+
+      verify_mic                decrypt and verify rsa-md5 checksum
+
+
+   The rsa-md5-des checksum algorithm is assigned a checksum type number
+   of eight (8).
+
+6.2.5. RSA MD4 Cryptographic Checksum Using 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 [MD4-92], 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 0xF0F0F0F0F0F0F0F0.  [7] The initialization
+   vector should be zero.  The resulting checksum is 24 octets long.
+   This checksum is tamper-proof and believed to be collision-proof.
+
+                                rsa-md4-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md4(conf | msg),
+                                        ivec=0)
+
+      verify_mic                decrypt and verify rsa-md4 checksum
+
+   The rsa-md4-des checksum algorithm is assigned a checksum type number
+   of three (3).
+
+6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
+
+   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.
+
+
+
+
+
+Raeburn                                                        [Page 26]
+
+INTERNET DRAFT                                             February 2004
+
+
+                               rsa-md4-des-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key, md4(msg), ivec=key)
+
+      verify_mic                decrypt, compute checksum and compare
+
+
+   The rsa-md4-des-k checksum algorithm is assigned a checksum type
+   number of six (6).
+
+6.2.7. DES CBC checksum
+
+   The DES-MAC checksum is computed by prepending an 8 octet confounder
+   to the plaintext, padding with zero-valued octets if necessary to
+   bring the length to a multiple of 8 octets, 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 variant of the key, where the variant is computed
+   by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0.  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.
+
+
+                                  des-mac
+   ----------------------------------------------------------------------
+   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
+   cryptosystem
+
+   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                          conf | des-mac(key, conf | msg | pad, ivec=0),
+                          ivec=0)
+
+   verify_mic     decrypt, compute DES MAC using confounder, compare
+
+
+   The des-mac checksum algorithm is assigned a checksum type number of
+   four (4).
+
+6.2.8. DES CBC checksum alternative
+
+   The DES-MAC-K checksum is computed by performing a DES CBC-mode
+   encryption of the plaintext, with zero-valued padding bytes if
+   necessary to bring the length to a multiple of 8 octets, and using
+   the last block of the ciphertext as the checksum value.  It is keyed
+
+
+
+Raeburn                                                        [Page 27]
+
+INTERNET DRAFT                                             February 2004
+
+
+   with an encryption key which is also used as the 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 DESMAC checksum and
+   it is no longer recommended.
+
+
+                                 des-mac-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-mac(key, msg | pad, ivec=key)
+
+      verify_mic                compute MAC and compare
+
+
+   The des-mac-k checksum algorithm is assigned a checksum type number
+   of five (5).
+
+6.3. Triple-DES based encryption and checksum types
+
+   This encryption and checksum type pair is based on the Triple DES
+   cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
+   authentication algorithm.
+
+   A Triple DES key is the concatenation of three DES keys as described
+   above for des-cbc-md5.  A Triple DES key is generated from random
+   data by creating three DES keys from separate sequences of random
+   data.
+
+   Encrypted data using this type must be generated as described in
+   section 5.3.  If the length of the input data is not a multiple of
+   the block size, zero-valued octets must be used to pad the plaintext
+   to the next eight-octet boundary.  The confounder must be eight
+   random octets (one block).
+
+   The simplified profile for Triple DES, with key derivation as defined
+   in section 5, is as follows:
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              protocol key format     24 bytes, parity in low
+                                      bit of each
+
+              key-generation seed     21 bytes
+              length
+
+
+
+
+
+Raeburn                                                        [Page 28]
+
+INTERNET DRAFT                                             February 2004
+
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              hash function           SHA-1
+
+              HMAC output size        160 bits
+
+              message block size      8 bytes
+
+              default string-to-key   empty string
+              params
+
+              encryption and          triple-DES encrypt and
+              decryption functions    decrypt, in outer-CBC
+                                      mode (cipher block size
+                                      8 octets)
+
+              key generation functions:
+
+              random-to-key           DES3random-to-key (see
+                                      below)
+
+              string-to-key           DES3string-to-key (see
+                                      below)
+
+   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
+   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
+   checksum type number of twelve (12).
+
+6.3.1. Triple DES Key Production (random-to-key, string-to-key)
+
+   The 168 bits of random key data are converted to a protocol key value
+   as follows.  First, the 168 bits are divided into three groups of 56
+   bits, which are expanded individually into 64 bits as follows:
+
+   DES3random-to-key:
+         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, each corrected to avoid "weak" and "semi-
+   weak" keys as in section 6.2, are concatenated to form the protocol
+   key value.
+
+
+
+Raeburn                                                        [Page 29]
+
+INTERNET DRAFT                                             February 2004
+
+
+   The string-to-key function is used to transform UTF-8 passwords into
+   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
+   algorithm and DK function, described in section 5.
+
+   The n-fold algorithm is applied to the password string concatenated
+   with a salt value.  For 3-key triple DES, the operation will involve
+   a 168-fold of the input password string, to generate an intermediate
+   key, from which the user's long-term key will be derived with the DK
+   function.  The DES3 string-to-key function is shown here in
+   pseudocode:
+
+         DES3string-to-key(passwordString, salt, params)
+             if (params != emptyString)
+              error("invalid params");
+             s = passwordString + salt
+             tmpKey = random-to-key(168-fold(s))
+             key = DK (tmpKey, KerberosConstant)
+
+   Weak key checking is performed in the random-to-key and DK
+   operations.  The KerberosConstant value is the byte string {0x6b 0x65
+   0x72 0x62 0x65 0x72 0x6f 0x73}.  These values correspond to the ASCII
+   encoding for the string "kerberos".
+
+7. Use of Kerberos encryption outside this specification
+
+   Several Kerberos-based application protocols and preauthentication
+   systems have been designed and deployed that perform encryption and
+   message integrity checks in various ways.  While in some cases there
+   may be good reason for specifying these protocols in terms of
+   specific encryption or checksum algorithms, we anticipate that in
+   many cases this will not be true, and more generic approaches
+   independent of particular algorithms will be desirable.  Rather than
+   having each protocol designer reinvent schemes for protecting data,
+   using multiple keys, etc, we have attempted to present in this
+   section a general framework that should be sufficient not only for
+   the Kerberos protocol itself but also for many preauthentication
+   systems and application protocols, while trying to avoid some of the
+   assumptions that can work their way into such protocol designs.
+
+   Some problematic assumptions we've seen (and sometimes made) include:
+   that a random bitstring is always valid as a key (not true for DES
+   keys with parity); that the basic block encryption chaining mode
+   provides no integrity checking, or can easily be separated from such
+   checking (not true for many modes in development that do both
+   simultaneously); that a checksum for a message always results in the
+   same value (not true if a confounder is incorporated); that an
+   initial vector is used (may not be true if a block cipher in CBC mode
+   is not in use).
+
+
+
+Raeburn                                                        [Page 30]
+
+INTERNET DRAFT                                             February 2004
+
+
+   Such assumptions, while they may hold for any given set of encryption
+   and checksum algorithms, may not be true of the next algorithms to be
+   defined, leaving the application protocol unable to make use of those
+   algorithms without updates to its specification.
+
+   The Kerberos protocol uses only the attributes and operations
+   described in sections 3 and 4.  Preauthentication systems and
+   application protocols making use of Kerberos are encouraged to use
+   them as well.  The specific key and string-to-key parameters should
+   generally be treated as opaque.  While the string-to-key parameters
+   are manipulated as an octet string, the representation for the
+   specific key structure is implementation-defined; it may not even be
+   a single object.
+
+   While we don't recommend it, some application protocols will
+   undoubtedly continue to use the key data directly, even if only in
+   some of the currently existing protocol specifications.  An
+   implementation intended to support general Kerberos applications may
+   therefore need to make the key data available, as well as the
+   attributes and operations described in sections 3 and 4.  [8]
+
+8. Assigned Numbers
+
+   The following encryption type numbers are already assigned or
+   reserved for use in Kerberos and related protocols.
+
+
+     encryption type                etype      section or comment
+     -----------------------------------------------------------------
+     des-cbc-crc                        1             6.2.3
+     des-cbc-md4                        2             6.2.2
+     des-cbc-md5                        3             6.2.1
+     [reserved]                         4
+     des3-cbc-md5                       5
+     [reserved]                         6
+     des3-cbc-sha1                      7
+     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              6.3
+     aes128-cts-hmac-sha1-96           17          [KRB5-AES]
+     aes256-cts-hmac-sha1-96           18          [KRB5-AES]
+     rc4-hmac                          23          (Microsoft)
+
+
+
+
+Raeburn                                                        [Page 31]
+
+INTERNET DRAFT                                             February 2004
+
+
+     rc4-hmac-exp                      24          (Microsoft)
+     subkey-keymaterial                65     (opaque; PacketCable)
+
+
+   (The "des3-cbc-sha1" assignment is a deprecated version using no key
+   derivation.  It should not be confused with des3-cbc-sha1-kd.)
+
+   Several numbers have been reserved for use in encryption systems not
+   defined here.  Encryption type numbers have unfortunately been
+   overloaded on occasion in Kerberos-related protocols, so some of the
+   reserved numbers do not and will not correspond to encryption systems
+   fitting the profile presented here.
+
+   The following checksum type numbers are assigned or reserved.  As
+   with encryption type numbers, some overloading of checksum numbers
+   has occurred.
+
+
+   Checksum type              sumtype        checksum         section or
+                                value            size         reference
+   ----------------------------------------------------------------------
+   CRC32                            1               4           6.1.3
+   rsa-md4                          2              16           6.1.2
+   rsa-md4-des                      3              24           6.2.5
+   des-mac                          4              16           6.2.7
+   des-mac-k                        5               8           6.2.8
+   rsa-md4-des-k                    6              16           6.2.6
+   rsa-md5                          7              16           6.1.1
+   rsa-md5-des                      8              24           6.2.4
+   rsa-md5-des3                     9              24             ??
+   sha1 (unkeyed)                  10              20             ??
+   hmac-sha1-des3-kd               12              20            6.3
+   hmac-sha1-des3                  13              20             ??
+   sha1 (unkeyed)                  14              20             ??
+   hmac-sha1-96-aes128             15              20         [KRB5-AES]
+   hmac-sha1-96-aes256             16              20         [KRB5-AES]
+   [reserved]                  0x8003               ?         [GSS-KRB5]
+
+
+   Encryption and checksum type numbers are signed 32-bit values.  Zero
+   is invalid, and negative numbers are reserved for local use.  All
+   standardized values must be positive.
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 32]
+
+INTERNET DRAFT                                             February 2004
+
+
+9. Implementation Notes
+
+   The "interface" described here is the minimal information that must
+   be defined to make a cryptosystem useful within Kerberos in an
+   interoperable fashion.  Despite the functional notation used in some
+   places, it is not an attempt to define an API for cryptographic
+   functionality within Kerberos.  Actual implementations providing
+   clean APIs will probably find it useful to make additional
+   information available, which should be possible to derive from a
+   specification written to the framework given here.  For example, an
+   application designer may wish to determine the largest number of
+   bytes that can be encrypted without overflowing a certain size output
+   buffer, or conversely, the maximum number of bytes that might be
+   obtained by decrypting a ciphertext message of a given size.  (In
+   fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
+   will require some of these.)
+
+   The presence of a mechanism in this document should not be taken as
+   an indication that it must be implemented for compliance with any
+   specification; required mechanisms will be specified elsewhere.
+   Indeed, some of the mechanisms described here for backwards
+   compatibility are now considered rather weak for protecting critical
+   data.
+
+10. Security Considerations
+
+   Recent years have brought advancements in the ability to perform
+   large-scale attacks against DES, to such a degree that it is not
+   considered a strong encryption mechanism any longer; triple-DES is
+   generally preferred in its place, despite the poorer performance.
+   See [ESP-DES] for a summary of some of the potential attacks, and
+   [EFF-DES] for a detailed discussion of the implementation of
+   particular attack.  However, most Kerberos implementations still have
+   DES as their primary interoperable encryption type.
+
+   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
+   single-DES here avoids them.  However, DES also has 48 'possibly-
+   weak' keys [Schneier96] (note that the tables in many editions of the
+   reference contains errors) which are not avoided.
+
+   DES weak keys are keys with the property that E1(E1(P)) = P (where E1
+   denotes encryption of a single block with key 1).  DES semi-weak keys
+   or "dual" keys are pairs of keys with the property that E1(P) =
+   D2(P), and thus E2(E1(P)) = P.  Because of the use of CBC mode and
+   leading random confounder, however, these properties are unlikely to
+   present a security problem.
+
+   Many of the choices concerning when weak-key corrections are
+
+
+
+Raeburn                                                        [Page 33]
+
+INTERNET DRAFT                                             February 2004
+
+
+   performed relate more to compatibility with existing implementations
+   than to any risk analysis.
+
+   While checks are also done for the component DES keys in a triple-DES
+   key, the nature of the weak keys is such that it is extremely
+   unlikely that they will weaken the triple-DES encryption -- only
+   slightly more likely than having the middle of the three sub-keys
+   match one of the other two, which effectively converts the encryption
+   to single-DES, which is a case we make no effort to avoid.
+
+   The true 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 of course recommended for environments where such
+   attacks represent a significant threat.  The "simplifications" (read:
+   bugs) introduced when CRC-32 was implemented for Kerberos cause
+   leading zeros to effectively be ignored, so messages differing only
+   in leading zero bits will have the same checksum.
+
+   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
+   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
+   the suggested truncation of the HMAC output.  As pointed out in
+   [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
+   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
+   vectors for HMAC-SHA-1.
+
+   The mit_des_string_to_key function was originally constructed with
+   the assumption that all input would be ASCII; it ignores the top bit
+   of each input byte.  Folding with XOR is also not an especially good
+   mixing mechanism in terms of preserving randomness.
+
+   The n-fold function used in the string-to-key operation for des3-cbc-
+   hmac-sha1-kd was designed to cause each bit of input to contribute
+   equally to the output; it was not designed to maximize or equally
+   distribute randomness in the input, and there are conceivable cases
+   of partially structured input where randomness may be lost.  This
+   should only be an issue for highly structured passwords, however.
+
+   [RFC1851] discusses the relative strength of triple-DES encryption.
+   The relative slow speed of triple-DES encryption may also be an issue
+   for some applications.
+
+   In [Bellovin91], there is a suggestion that analyses of encryption
+   schemes should include a model of an attacker capable of submitting
+   known plaintexts to be encrypted with an unknown key, as well as
+   being able to perform many types of operations on known protocol
+   messages.  Recent experiences with the chosen-plaintext attacks on
+   Kerberos version 4 bear out the value of this suggestion.
+
+
+
+Raeburn                                                        [Page 34]
+
+INTERNET DRAFT                                             February 2004
+
+
+   The use of unkeyed encrypted checksums, such as those used in the
+   single-DES cryptosystems specified in [Kerb1510], allows for cut-and-
+   paste attacks, especially if a confounder is not used.  In addition,
+   unkeyed encrypted checksums are vulnerable to chosen-plaintext
+   attacks: an attacker with access to an encryption oracle can easily
+   encrypt the required unkeyed checksum along with the chosen
+   plaintext. [Bellovin99]  These weaknesses, combined with a common
+   implementation design choice described below, allow for a cross-
+   protocol attack from version 4 to version 5.
+
+   The use of a random confounder is an important means of preventing an
+   attacker from making effective use of protocol exchanges as an
+   encryption oracle.  In Kerberos version 4, the encryption of constant
+   plaintext to constant ciphertext makes an effective encryption oracle
+   for an attacker.  The use of random confounders in [Kerb1510]
+   frustrates this sort of chosen-plaintext attack.
+
+   Using the same key for multiple purposes can enable or increase the
+   scope of chosen-plaintext attacks.  Some software which implements
+   both versions 4 and 5 of the Kerberos protocol uses the same keys for
+   both versions of the protocol.  This enables the encryption oracle of
+   version 4 to be used to attack version 5.  Vulnerabilities such as
+   this cross-protocol attack reinforce the wisdom of not using a key
+   for multiple purposes.
+
+   This document, like the Kerberos protocol, completely ignores the
+   notion of limiting the amount of data a key may be used with to a
+   quantity based on the robustness of the algorithm or size of the key.
+   It is assumed that any defined algorithms and key sizes will be
+   strong enough to support very large amounts of data, or they will be
+   deprecated once significant attacks are known.
+
+   This document also places no bounds on the amount of data that can be
+   handled in various operations.  In order to avoid denial of service
+   attacks, implementations will probably want to restrict message sizes
+   at some higher level.
+
+11. IANA Considerations
+
+   Two registries for numeric values should be created: Kerberos
+   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
+   are signed values ranging from -2147483648 to 2147483647.  Positive
+   values should be assigned only for algorithms specified in accordance
+   with this specification for use with Kerberos or related protocols.
+   Negative values are for private use; local and experimental
+   algorithms should use these values.  Zero is reserved and may not be
+   assigned.
+
+
+
+
+Raeburn                                                        [Page 35]
+
+INTERNET DRAFT                                             February 2004
+
+
+   Positive encryption and checksum type numbers may be assigned
+   following either of two policies described in [BCP26].
+
+   Standards-track specifications may be assigned values under the
+   Standards Action policy.
+
+   Specifications in non-standards track RFCs may be assigned values
+   after Expert Review.  A non-IETF specification may be assigned values
+   by publishing an Informational or standards-track RFC referencing the
+   external specification; that specification must be public and
+   published in some permanent record much like the IETF RFCs.  It is
+   highly desirable, though not required, that the full specification be
+   published as an IETF RFC.
+
+   Smaller encryption type values should be used for IETF standards-
+   track mechanisms, and much higher values (16777216 and above) for
+   other mechanisms.  (Rationale: In the Kerberos ASN.1 encoding,
+   smaller numbers encode to smaller octet sequences, so this favors
+   standards-track mechanisms with slightly smaller messages.)  Aside
+   from that guideline, IANA may choose numbers as it sees fit.
+
+   Internet-Draft specifications should not include values for
+   encryption and checksum type numbers.  Instead, they should indicate
+   that values would be assigned by IANA when the document is approved
+   as an RFC.  For development and interoperability testing, values in
+   the private-use range (negative values) may be used, but should not
+   be included in the draft specification.
+
+   Each registered value should have an associated unique name to refer
+   to it by.  The lists given in section 8 should be used as an initial
+   registry; they include reservations for specifications in progress in
+   parallel with this document, and for certain other values believed to
+   be in use already.
+
+12. Acknowledgments
+
+   This document is an extension of the encryption specification
+   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
+   of the text of the background, concepts, and DES specifications are
+   drawn directly from that document.
+
+   The abstract framework presented in this document was put together by
+   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
+   and Tom Yu, and the details were refined several times based on
+   comments from John Brezak and others.
+
+   Marc Horowitz wrote the original specification of triple-DES and key
+   derivation in a pair of Internet Drafts (under the names draft-
+
+
+
+Raeburn                                                        [Page 36]
+
+INTERNET DRAFT                                             February 2004
+
+
+   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
+   were later folded into a draft revision of [Kerb1510], from which
+   this document was later split off.
+
+   Tom Yu provided the text describing the modifications to the standard
+   CRC algorithm as Kerberos implementations actually use it, and some
+   of the Security Considerations section.
+
+   Miroslav Jurisic provided information for one of the UTF-8 test cases
+   for the string-to-key functions.
+
+   Marcus Watts noticed some errors in earlier drafts, and pointed out
+   that the simplified profile could easily be modified to support
+   cipher text stealing modes.
+
+   Simon Josefsson contributed some clarifications to the DES "CBC
+   checksum", string-to-key and weak key descriptions, and some test
+   vectors.
+
+   Simon Josefsson, Louis LeVay and others also caught some errors in
+   earlier drafts.
+
+A. Test vectors
+
+   This section provides test vectors for various functions defined or
+   described in this document.  For convenience, most inputs are ASCII
+   strings, though some UTF-8 samples are be provided for string-to-key
+   functions.  Keys and other binary data are specified as hexadecimal
+   strings.
+
+A.1. n-fold
+
+   The n-fold function is defined in section 5.1.  As noted there, the
+   sample vector in the original paper defining the algorithm appears to
+   be incorrect.  Here are some test cases provided by Marc Horowitz and
+   Simon Josefsson:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 37]
+
+INTERNET DRAFT                                             February 2004
+
+
+      64-fold("012345") =
+      64-fold(303132333435) = be072631276b1955
+
+      56-fold("password") =
+      56-fold(70617373776f7264) = 78a07b6caf85fa
+
+      64-fold("Rough Consensus, and Running Code") =
+      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
+              6e696e6720436f6465) = bb6ed30870b7f0e0
+
+      168-fold("password") =
+      168-fold(70617373776f7264) =
+               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
+
+      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
+      192-fold(4d41535341434856534554545320494e5354495456544520
+               4f4620544543484e4f4c4f4759) =
+               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
+
+      168-fold("Q") =
+      168-fold(51) =
+               518a54a2 15a8452a 518a54a2 15a8452a
+               518a54a2 15
+
+      168-fold("ba") =
+      168-fold(6261) =
+               fb25d531 ae897449 9f52fd92 ea9857c4
+               ba24cf29 7e
+
+   Here are some additional values corresponding to folded values of the
+   string "kerberos"; the 64-bit form is used in the des3 string-to-key
+   (section 6.3.1).
+
+      64-fold("kerberos") =
+               6b657262 65726f73
+      128-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+      168-fold("kerberos") =
+               8372c236 344e5f15 50cd0747 e15d62ca
+               7a5a3bce a4
+      256-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+               5c9bdcda d95c9899 c4cae4de e6d6cae4
+
+   Note that the initial octets exactly match the input string when the
+   output length is a multiple of the input length.
+
+
+
+
+
+Raeburn                                                        [Page 38]
+
+INTERNET DRAFT                                             February 2004
+
+
+A.2. mit_des_string_to_key
+
+   The function mit_des_string_to_key is defined in section 6.2.  We
+   present here several test values, with some of the intermediate
+   results.  The fourth test demonstrates the use of UTF-8 with three
+   characters.  The last two tests are specifically constructed so as to
+   trigger the weak-key fixups for the intermediate key produced by fan-
+   folding; we have no test cases that cause such fixups for the final
+   key.
+
+   UTF-8 encodings used in test vector:
+   eszett    U+00DF   C3 9F   s-caron   U+0161    C5 A1
+   c-acute   U+0107   C4 87   g-clef    U+1011E   F0 9D 84 9E
+
+   Test vector:
+
+   salt:        "ATHENA.MIT.EDUraeburn"
+                              415448454e412e4d49542e4544557261656275726e
+   password:    "password"    70617373776f7264
+   fan-fold result:           c01e38688ac86c2e
+   intermediate key:          c11f38688ac86d2f
+   DES key:                   cbc22fae235298e3
+
+
+   salt:       "WHITEHOUSE.GOVdanny"
+                           5748495445484f5553452e474f5664616e6e79
+   password:   "potatoe"   706f7461746f65
+   fan-fold result:        a028944ee63c0416
+   intermediate key:       a129944fe63d0416
+   DES key:                df3d32a74fd92a01
+
+
+   salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
+   password:  g-clef (U+1011E)      f09d849e
+   fan-fold result:                 3c4a262c18fab090
+   intermediate key:                3d4a262c19fbb091
+   DES key:                         4ffb26bab0cd9413
+
+
+   salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
+                                   415448454e412e4d49542e4544554a757269c5a169c487
+   password:       eszett(U+00DF)
+                                   c39f
+   fan-fold result:b8f6c40e305afc9e
+   intermediate key:               b9f7c40e315bfd9e
+   DES key:                        62c81a5232b5e69d
+
+
+
+
+
+Raeburn                                                        [Page 39]
+
+INTERNET DRAFT                                             February 2004
+
+
+   salt:       "AAAAAAAA"   4141414141414141
+   password:   "11119999"   3131313139393939
+   fan-fold result:         e0e0e0e0f0f0f0f0
+   intermediate key:        e0e0e0e0f1f1f101
+   DES key:                 984054d0f1a73e31
+
+
+   salt:       "FFFFAAAA"   4646464641414141
+   password:   "NNNN6666"   4e4e4e4e36363636
+   fan-fold result:         1e1e1e1e0e0e0e0e
+   intermediate key:        1f1f1f1f0e0e0efe
+   DES key:                 c4bf6b25adf7a4f8
+
+
+   This trace provided by Simon Josefsson shows the intermediate
+   processing stages of one of the test inputs:
+
+     string_to_key (des-cbc-md5, string, salt)
+            ;; string:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; salt:
+            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+            ;; 65 62 75 72 6e
+     des_string_to_key (string, salt)
+            ;; String:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; Salt:
+            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+            ;; 65 62 75 72 6e
+     odd = 1;
+     s = string | salt;
+     tempstring = 0; /* 56-bit string */
+     pad(s); /* with nulls to 8 byte boundary */
+            ;; s = pad(string|salt):
+            ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
+            ;; (length 32 bytes)
+            ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
+            ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
+     for (8byteblock in s) {
+            ;; loop iteration 0
+            ;; 8byteblock:
+            ;; `password' (length 8 bytes)
+            ;; 70 61 73 73 77 6f 72 64
+            ;; 01110000 01100001 01110011  01110011 01110111 01101111
+
+
+
+Raeburn                                                        [Page 40]
+
+INTERNET DRAFT                                             February 2004
+
+
+            ;; 01110010 01100100
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1110000 1100001 1110011  1110011 1110111 1101111
+            ;; 1110010 1100100
+     if (odd == 0) reverse(56bitstring);    ;; odd=1
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1110000 1100001 1110011  1110011 1110111 1101111
+            ;; 1110010 1100100
+
+     for (8byteblock in s) {
+            ;; loop iteration 1
+            ;; 8byteblock:
+            ;; `ATHENA.M' (length 8 bytes)
+            ;; 41 54 48 45 4e 41 2e 4d
+            ;; 01000001 01010100 01001000  01000101 01001110 01000001
+            ;; 00101110 01001101
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1000001 1010100 1001000  1000101 1001110 1000001
+            ;; 0101110 1001101
+     if (odd == 0) reverse(56bitstring);    ;; odd=0
+     reverse(56bitstring)
+            ;; 56bitstring after reverse
+            ;; 1011001 0111010 1000001  0111001 1010001 0001001
+            ;; 0010101 1000001
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 0101001 1011011 0110010  1001010 0100110 1100110
+            ;; 1100111 0100101
+
+     for (8byteblock in s) {
+            ;; loop iteration 2
+            ;; 8byteblock:
+            ;; `IT.EDUra' (length 8 bytes)
+            ;; 49 54 2e 45 44 55 72 61
+            ;; 01001001 01010100 00101110  01000101 01000100 01010101
+            ;; 01110010 01100001
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1001001 1010100 0101110  1000101 1000100 1010101
+            ;; 1110010 1100001
+     if (odd == 0) reverse(56bitstring);    ;; odd=1
+
+
+
+
+
+Raeburn                                                        [Page 41]
+
+INTERNET DRAFT                                             February 2004
+
+
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1100000 0001111 0011100  0001111 1100010 0110011
+            ;; 0010101 1000100
+
+     for (8byteblock in s) {
+            ;; loop iteration 3
+            ;; 8byteblock:
+            ;; `eburn\x00\x00\x00' (length 8 bytes)
+            ;; 65 62 75 72 6e 00 00 00
+            ;; 01100101 01100010 01110101  01110010 01101110 00000000
+            ;; 00000000 00000000
+     56bitstring = removeMSBits(8byteblock);
+            ;; 56bitstring:
+            ;; 1100101 1100010 1110101  1110010 1101110 0000000
+            ;; 0000000 0000000
+     if (odd == 0) reverse(56bitstring);    ;; odd=0
+     reverse(56bitstring)
+            ;; 56bitstring after reverse
+            ;; 0000000 0000000 0000000  0111011 0100111 1010111
+            ;; 0100011 1010011
+     odd = ! odd
+     tempstring = tempstring XOR 56bitstring;
+            ;; tempstring
+            ;; 1100000 0001111 0011100  0110100 1000101 1100100
+            ;; 0110110 0010111
+
+     for (8byteblock in s) {
+     }
+            ;; for loop terminated
+
+     tempkey = key_correction(add_parity_bits(tempstring));
+            ;; tempkey
+            ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
+            ;; c1 1f 38 68 8a c8 6d 2f
+            ;; 11000001 00011111 00111000  01101000 10001010 11001000
+            ;; 01101101 00101111
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 42]
+
+INTERNET DRAFT                                             February 2004
+
+
+     key = key_correction(DES-CBC-check(s,tempkey));
+            ;; key
+            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+            ;; cb c2 2f ae 23 52 98 e3
+            ;; 11001011 11000010 00101111  10101110 00100011 01010010
+            ;; 10011000 11100011
+
+            ;; string_to_key key:
+            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+            ;; cb c2 2f ae 23 52 98 e3
+
+
+A.3. DES3 DR and DK
+
+   These tests show the derived-random and derived-key values for the
+   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
+   defined in section 6.3.1.  The input keys were randomly generated;
+   the usage values are from this specification.
+
+
+   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
+   usage:               0000000155
+   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
+   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
+
+   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
+   usage:               00000001aa
+   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
+   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
+
+   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
+   usage:               0000000155
+   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
+   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
+
+   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
+   usage:               00000001aa
+   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
+   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
+
+   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
+   usage:               6b65726265726f73 ("kerberos")
+   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
+   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
+
+   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
+   usage:               0000000155
+
+
+
+
+Raeburn                                                        [Page 43]
+
+INTERNET DRAFT                                             February 2004
+
+
+   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
+   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
+
+   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
+   usage:               00000001aa
+   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
+   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
+
+   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
+   usage:               0000000155
+   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
+   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
+
+   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
+   usage:               00000001aa
+   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
+   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
+
+
+A.4. DES3string_to_key
+
+   These are the keys generated for some of the above input strings for
+   triple-DES with key derivation as defined in section 6.3.1.
+
+    salt:   "ATHENA.MIT.EDUraeburn"
+    passwd: "password"
+    key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
+
+    salt:   "WHITEHOUSE.GOVdanny"
+    passwd: "potatoe"
+    key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
+
+    salt:   "EXAMPLE.COMbuckaroo"
+    passwd: "penny"
+    key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
+
+    salt:   "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
+             + c-acute(U+0107)
+    passwd: eszett(U+00DF)
+    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
+
+    salt:   "EXAMPLE.COMpianist"
+    passwd: g-clef(U+1011E)
+    key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
+
+
+
+
+
+
+
+Raeburn                                                        [Page 44]
+
+INTERNET DRAFT                                             February 2004
+
+
+A.5. Modified CRC-32
+
+   Below are modified-CRC32 values for various ASCII and octet strings.
+   Only the printable ASCII characters are checksummed, no C-style
+   trailing zero-valued octet.  The 32-bit modified CRC and the sequence
+   of output bytes as used in Kerberos are shown.  (The octet values are
+   separated here to emphasize that they are octet values and not 32-bit
+   numbers, which will be the most convenient form for manipulation in
+   some implementations.  The bit and byte order used internally for
+   such a number is irrelevant; the octet sequence generated is what is
+   important.)
+
+
+    mod-crc-32("foo") =                                     33 bc 32 73
+    mod-crc-32("test0123456789") =                          d6 88 3e b8
+    mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
+    mod-crc-32(8000) =                                      4b 98 83 3b
+    mod-crc-32(0008) =                                      32 88 db 0e
+    mod-crc-32(0080) =                                      20 83 b8 ed
+    mod-crc-32(80) =                                        20 83 b8 ed
+    mod-crc-32(80000000) =                                  3b b6 59 ed
+    mod-crc-32(00000001) =                                  96 30 07 77
+
+
+B. Significant Changes from RFC 1510
+
+   The encryption and checksum mechanism profiles are new.  The old
+   specification defined a few operations for various mechanisms, but
+   didn't outline what should be required of new mechanisms in terms of
+   abstract properties, nor how to ensure that a mechanism specification
+   is complete enough for interoperability between implementations.  The
+   new profiles do differ from the old specification in a few ways:
+
+      Some message definitions in [Kerb1510] could be read as permitting
+      the initial vector to be specified by the application; the text
+      was too vague.  It is specifically not permitted in this
+      specification.  Some encryption algorithms may not use
+      initialization vectors, so relying on chosen, secret
+      initialization vectors for security is unwise.  Also, the
+      prepended confounder in the existing algorithms is roughly
+      equivalent to a per-message initialization vector that is revealed
+      in encrypted form.  However, carrying state across from one
+      encryption to another is explicitly permitted through the opaque
+      "cipher state" object.
+
+      The use of key derivation is new.
+
+      Several new methods are introduced, including generation of a key
+
+
+
+Raeburn                                                        [Page 45]
+
+INTERNET DRAFT                                             February 2004
+
+
+      in wire-protocol format from random input data.
+
+      The means for influencing the string-to-key algorithm are laid out
+      more clearly.
+
+   Triple-DES support is new.
+
+   The pseudo-random function is new.
+
+   The des-cbc-crc, DES string-to-key and CRC descriptions have been
+   updated to align them with existing implementations.
+
+   [Kerb1510] had no indication what character set or encoding might be
+   used for pass phrases and salts.
+
+   In [Kerb1510], key types, encryption algorithms and checksum
+   algorithms were only loosely associated, and the association was not
+   well described.  In this specification, key types and encryption
+   algorithms have a one-to-one correspondence, and associations between
+   encryption and checksum algorithms are described so that checksums
+   can be computed given negotiated keys, without requiring further
+   negotiation for checksum types.
+
+Notes
+
+   [1] While Message Authentication Code (MAC) or Message Integrity
+       Check (MIC) would be more appropriate terms for many of the
+       uses in this document, we continue to use the term "checksum"
+       for historical reasons.
+
+   [2] Extending CBC mode across messages would be one obvious
+       example of this chaining.  Another might be the use of
+       counter mode, with a counter randomly initialized and
+       attached to the ciphertext; a second message could continue
+       incrementing the counter when chaining the cipher state, thus
+       avoiding having to transmit another counter value.  However,
+       this chaining is only useful for uninterrupted, ordered
+       sequences of messages.
+
+   [3] In the case of Kerberos, the encrypted objects will generally
+       be ASN.1 DER encodings, which contain indications of their
+       length in the first few octets.
+
+   [4] As of the time of this writing, some new modes of operation
+       have been proposed, some of which may permit encryption and
+       integrity protection simultaneously.  After some of these
+       proposals have been subjected to adequate analysis, we may
+       wish to formulate a new simplified profile based on one of
+
+
+
+Raeburn                                                        [Page 46]
+
+INTERNET DRAFT                                             February 2004
+
+
+       them.
+
+   [5] It should be noted that the sample vector in Appendix B.2 of
+       the original paper appears to be incorrect.  Two independent
+       implementations from the specification (one in C by Marc
+       Horowitz, and another in Scheme by Bill Sommerfeld) agree on
+       a value different from that in [Blumenthal96].
+
+   [6] For example, in MIT's implementation of [Kerb1510], the rsa-
+       md5 unkeyed checksum of application data may be included in
+       an authenticator encrypted in a service's key; since rsa-md5
+       is believed to be collision-proof, even if the application
+       data is exposed to an attacker, it cannot be modified without
+       causing the checksum verification to fail.
+
+   [7] 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 0xF0F0F0F0F0F0F0F0 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.
+
+   [8] Perhaps one of the more common reasons for directly
+       performing encryption is direct control over the negotiation
+       and to select a "sufficiently strong" encryption algorithm
+       (whatever that means in the context of a given application).
+       While Kerberos directly provides no facility for negotiating
+       encryption types between the application client and server,
+       there are other means for accomplishing similar goals.  For
+       example, requesting only "strong" session key types from the
+       KDC, and assuming that the type actually returned by the KDC
+       will be understood and supported by the application server.
+
+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 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
+
+
+
+Raeburn                                                        [Page 47]
+
+INTERNET DRAFT                                             February 2004
+
+
+   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.
+
+Normative References
+
+   [Bellare98]
+      Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
+      "Relations Among Notions of Security for Public-Key Encryption
+      Schemes".  Extended abstract published in Advances in Cryptology-
+      Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
+      1462, H. Krawcyzk ed., Springer-Verlag, 1998.
+   [Blumenthal96]
+      Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
+      Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
+   [CRC]
+      International Organization for Standardization, "ISO Information
+      Processing Systems - Data Communication - High-Level Data Link
+      Control Procedure - Frame Structure," IS 3309, 3rd Edition,
+      October 1984.
+   [DES77]
+      National Bureau of Standards, U.S. Department of Commerce, "Data
+      Encryption Standard," Federal Information Processing Standards
+      Publication 46, Washington, DC, 1977.
+   [DESI81]
+      National Bureau of Standards, U.S. Department of Commerce,
+      "Guidelines for implementing and using NBS Data Encryption
+      Standard," Federal Information Processing Standards Publication
+      74, Washington, DC, 1981.
+   [DESM80]
+      National Bureau of Standards, U.S. Department of Commerce, "DES
+      Modes of Operation," Federal Information Processing Standards
+      Publication 81, Springfield, VA, December 1980.
+   [Dolev91]
+      Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
+      Proceedings of the 23rd Annual Symposium on Theory of Computing,
+      ACM, 1991.
+   [HMAC]
+      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+      for Message Authentication", RFC 2104, February 1997.
+
+
+
+
+
+
+Raeburn                                                        [Page 48]
+
+INTERNET DRAFT                                             February 2004
+
+
+   [KRB5-AES]
+      Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
+      2003.
+   [MD4-92]
+      Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
+      Laboratory for Computer Science, April 1992.
+   [MD5-92]
+      Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
+      Laboratory for Computer Science, April 1992.
+   [RFC2026]
+      Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
+      2026, October 1996.
+   [SG92]
+      Stubblebine, S., and V. D. Gligor, "On Message Integrity in
+      Cryptographic Protocols," in Proceedings of the IEEE Symposium on
+      Research in Security and Privacy, Oakland, California, May 1992.
+
+Informative References
+
+   [Bellovin91]
+      Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos
+      Authentication System", in Proceedings of the Winter 1991 Usenix
+      Security Conference, January, 1991.
+   [Bellovin99]
+      Bellovin, S. M., and D. Atkins, private communications, 1999.
+   [EFF-DES]
+      Electronic Frontier Foundation, "Cracking DES: Secrets of
+      Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
+      & Associates, Inc., May 1998.
+   [ESP-DES]
+      Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
+      With Explicit IV", RFC 2405, November 1998.
+   [GSS-KRB5]
+      Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
+      June 1996.
+   [HMAC-TEST]
+      Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
+      RFC 2202, September 1997.
+   [IPSEC-HMAC]
+      Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
+      AH", RFC 2404, November 1998.
+   [Kerb]
+      Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
+      Raeburn, "The Kerberos Network Authentication Service (V5)",
+      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
+      2002.  Work in progress.
+
+
+
+
+
+Raeburn                                                        [Page 49]
+
+INTERNET DRAFT                                             February 2004
+
+
+   [Kerb1510]
+      Kohl, J., and C. Neuman, "The Kerberos Network Authentication
+      Service (V5)", RFC 1510, September 1993.
+   [RC5]
+      Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+      RC5-CTS Algorithms", RFC 2040, October 1996.
+   [Schneier96]
+      Schneier, B., "Applied Cryptography Second Edition", John Wiley &
+      Sons, New York, NY, 1996.  ISBN 0-471-12845-7.
+
+Editor's address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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."
+
+
+
+
+
+Raeburn                                                        [Page 50]
+
+INTERNET DRAFT                                             February 2004
+
+
+Notes to RFC Editor
+
+   Before publication of this document as an RFC, the following changes
+   are needed:
+
+   Change the reference "[KRB5-AES]" in Normative References to indicate
+   the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
+   advancing to RFC at the same time.  The RFC number and publication
+   date are needed.
+
+   If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
+   same time as this document, change the information for [Kerb] in the
+   Informative References section as well.
+
+   Change the first-page headers to indicate the RFC number, network
+   working group, etc, as appropriate for an RFC instead of an I-D.
+
+   Remove the contact-info paragraph from the Abstract.
+
+   Delete this section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 51]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
new file mode 100644
index 00000000000..50700306a8f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
@@ -0,0 +1,673 @@
+
+
+
+NETWORK WORKING GROUP                                           S. Emery
+Internet-Draft                                          Sun Microsystems
+Updates: 4121 (if approved)                             November 9, 2007
+Intended status: Standards Track
+Expires: May 12, 2008
+
+
+        Kerberos Version 5 GSS-API Channel Binding Hash Agility
+              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on May 12, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 1]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+Abstract
+
+   Currently, the Kerberos Version 5 Generic Security Services
+   Application Programming Interface (GSS-API) mechanism [RFC4121] does
+   not have the ability to utilize better hash algorithms used to
+   generate channel binding identities.  The current mechanism for doing
+   this is hard coded to use MD5 only.  The purpose of this document is
+   to outline changes required to update the protocol so that more
+   secure algorithms can be used to create channel binding identities.
+   The extensibility of this solution also provides an eventual
+   replacement of identities based solely on hash algorithms.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
+   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 2]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+1.  Introduction
+
+   With the recently discovered weaknesses in the MD5 hash algorithm
+   there is a need to move stronger hash alogrithms.  Kerberos Version 5
+   Generic Security Services Application Programming Interface (GSS-API)
+   mechanism [RFC4121] uses MD5 to calculate channel binding identities
+   that are required to be unique.  This document specifies an update to
+   the mechanism that allows it to create channel binding identities
+   based on negotiating algorithms securely.  This will prevent lengthy
+   standardizations in the future when new attacks arise and will allow
+   an incremental update to the protocol so that this will interoperate
+   with older implementations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 3]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+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 [RFC2119].
+
+   The term "little endian order" is used for brevity to refer to the
+   least-significant-octet-first encoding, while the term "big endian
+   order" is for the most-significant-octet-first encoding.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 4]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+3.  Channel binding hash agility
+
+   When generating a channel binding identifier, Bnd, a hash is computed
+   from the channel binding information.  Initiators MUST populate the
+   Bnd field in order to maintain interoperability with existing
+   acceptors.  In addition, initiators MUST populate the extension
+   field, Exts, with TYPED-DATA as defined in [RFC4120].  The 0x8003 GSS
+   checksum MUST have the following structure:
+
+      Octet     Name       Description
+      -----------------------------------------------------------------
+      0..3      Lgth       Number of octets in Bnd field;  Represented
+                            in little-endian order;  Currently contains
+                            hex value 10 00 00 00 (16).
+      4..19     Bnd        Channel binding information, as described in
+                            section 4.1.1.2 [RFC4121].
+      20..23    Flags      Four-octet context-establishment flags in
+                            little-endian order as described in section
+                            4.1.1.1 [RFC4121].
+      24..25    DlgOpt     The delegation option identifier (=1) in
+                            little-endian order [optional].  This field
+                            and the next two fields are present if and
+                            only if GSS_C_DELEG_FLAG is set as described
+                            in section 4.1.1.1 [RFC4121].
+      26..27    Dlgth      The length of the Deleg field in
+                            little-endian order [optional].
+      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
+      n..last   Exts       Extensions
+
+      where Exts is the concatenation of zero, one or more individual
+      extensions, each of which consists of:
+        type -- big endian order unsigned integer, 32-bits
+        length -- big endian order unsigned integer, 32-bits
+        data -- octet string of length octets
+      in that order
+
+   When channel binding is used the Exts MUST include the following
+   extension:
+
+      data-type 0x00000000
+
+      data-value
+
+         The output obtained by applying the Kerberos V get_mic()
+         operation [RFC3961], using the sub-session key from the
+         authenticator and key usage number TBD, to the channel binding
+         data as described in [RFC4121], section 4.1.1.2 (using get_mic
+         instead of MD5).
+
+
+
+Emery                     Expires May 12, 2008                  [Page 5]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+   Initiators that are unwilling to use a MD5 hash of the channel
+   bindings should set the Bnd field to all ones (1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 6]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+4.  Security considerations
+
+   Initiators do not know if the acceptor had ignored channel bindings
+   or whether it validated the MD5 hash of the channel bindings
+   [RFC4121].
+
+   Ultimately, it is up to the application whether to use channel
+   binding or not.  This is dependent upon the security policy of these
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 7]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+5.  IANA Considerations
+
+   The IANA is hereby requested to create a new registry of "Kerberos V
+   GSS-API mechanism extension types" with four-field entries (type
+   number, type name, description, and normative reference) and,
+   initially, a single registration: 0x00000000, "Channel Binding MIC,"
+   "Extension for hash function-agile channel binding," <this RFC>.
+
+   Registration of additional extensions SHALL be by IESG Protocol
+   Action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 8]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+6.  Acknowledgements
+
+   Larry Zhu helped in the review of this document overall and provided
+   the suggestions of typed data and server acknowledgement.
+
+   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
+   fields be populated simultaneously.
+
+   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
+   changes to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                  [Page 9]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                 [Page 10]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+Author's Address
+
+   Shawn Emery
+   Sun Microsystems
+   500 Eldorado Blvd
+   M/S UBRM05-171
+   Broomfield, CO  80021
+   US
+
+   Email: shawn.emery@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                     Expires May 12, 2008                 [Page 11]
+
+Internet-Draft        Channel Binding Hash Agility         November 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Emery                     Expires May 12, 2008                 [Page 12]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
new file mode 100644
index 00000000000..54f09380226
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
@@ -0,0 +1,673 @@
+
+
+
+NETWORK WORKING GROUP                                           S. Emery
+Internet-Draft                                          Sun Microsystems
+Updates: 4121 (if approved)                                July 14, 2008
+Intended status: Standards Track
+Expires: January 15, 2009
+
+
+        Kerberos Version 5 GSS-API Channel Binding Hash Agility
+              draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 15, 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 1]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+Abstract
+
+   Currently, channel bindings are implemented using a MD5 hash in the
+   Kerberos Version 5 Generic Security Services Application Programming
+   Interface (GSS-API) mechanism [RFC4121].  This document updates
+   RFC4121 to allow the channel binding restriction to be lifted using
+   algorithms negotiated based on Kerberos crypto framework as defined
+   in RFC3961.  In addition, because this update makes use of the last
+   extensible field in the Kerberos client-server exchange message,
+   extensions are defined to allow future protocol extensions.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
+   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 2]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+1.  Introduction
+
+   With the recently discovered weaknesses in the MD5 hash algorithm
+   there is a need to use stronger hash algorithms.  Kerberos Version 5
+   Generic Security Services Application Programming Interface (GSS-API)
+   mechanism [RFC4121] uses MD5 to calculate channel binding verifiers.
+   This document specifies an update to the mechanism that allows it to
+   create channel binding information based on negotiating algorithms
+   securely.  This will allow deploying new algorithms incrementally
+   without break interoperability with older implementations, when new
+   attacks arise in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 3]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+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 [RFC2119].
+
+   The term "little endian order" is used for brevity to refer to the
+   least-significant-octet-first encoding, while the term "big endian
+   order" is for the most-significant-octet-first encoding.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 4]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+3.  Channel binding hash agility
+
+   When generating a channel binding verifier, Bnd, a hash is computed
+   from the channel binding fields.  Initiators MUST populate the Bnd
+   field in order to maintain interoperability with existing acceptors.
+   In addition, initiators MUST populate the extension field, Exts, with
+   TYPED-DATA as defined in [RFC4120].  All fields before Exts, do not
+   change from what is described in [RFC4121], they are listed for
+   convenience.  The 0x8003 GSS checksum MUST have the following
+   structure:
+
+      Octet     Name       Description
+      -----------------------------------------------------------------
+      0..3      Lgth       Number of octets in Bnd field;  Represented
+                            in little-endian order;  Currently contains
+                            hex value 10 00 00 00 (16).
+      4..19     Bnd        Channel binding information, as described in
+                            section 4.1.1.2 [RFC4121].
+      20..23    Flags      Four-octet context-establishment flags in
+                            little-endian order as described in section
+                            4.1.1.1 [RFC4121].
+      24..25    DlgOpt     The delegation option identifier (=1) in
+                            little-endian order [optional].  This field
+                            and the next two fields are present if and
+                            only if GSS_C_DELEG_FLAG is set as described
+                            in section 4.1.1.1 [RFC4121].
+      26..27    Dlgth      The length of the Deleg field in
+                            little-endian order [optional].
+      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
+      n..last   Exts       Extensions
+
+      where Exts is the concatenation of zero, one or more individual
+      extensions, each of which consists of, in order:
+
+      type -- big endian order unsigned integer, 32-bits, which contains
+              the type of extension
+      data -- octet string of extension information
+
+      If multiple extensions are present then there MUST be at most one
+      instance of a given extension type.
+
+   When channel binding is used the Exts MUST include the following
+   extension:
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 5]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+      data-type 0x00000000
+
+      data-value
+
+         The output obtained by applying the Kerberos V get_mic()
+         operation [RFC3961], using the sub-session key from the
+         authenticator and key usage number 43, to the channel binding
+         data as described in [RFC4121], section 4.1.1.2 (using get_mic
+         instead of MD5).
+
+   Initiators that are unwilling to use a MD5 hash of the channel
+   bindings MUST set the Bnd field to sixteen octets of hex value FF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 6]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+4.  Security considerations
+
+   Initiators do not know if the acceptor had ignored channel bindings
+   or whether it validated the MD5 hash of the channel bindings
+   [RFC4121].
+
+   Ultimately, it is up to the application whether to use channel
+   binding or not.  This is dependent upon the security policy of these
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 7]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+5.  IANA Considerations
+
+   The IANA is hereby requested to create a new registry of "Kerberos V
+   GSS-API mechanism extension types" with four-field entries (type
+   number, type name, description, and normative reference) and,
+   initially, a single registration: 0x00000000, "Channel Binding MIC,"
+   "Extension for the verifier of the channel bindings," <this RFC>.
+
+   Using the guidelines for allocation as described in [RFC5226], type
+   number assignments are as follows:
+
+      0x00000000 - 0x000003FF IETF Consensus
+
+      0x00000400 - 0xFFFFF3FF Specification Required
+
+      0xFFFFF400 - 0xFFFFFFFF Private Use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 8]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+6.  Acknowledgements
+
+   Larry Zhu helped in the review of this document overall and provided
+   the suggestions of typed-data.
+
+   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
+   fields be populated simultaneously.
+
+   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
+   changes to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009                [Page 9]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009               [Page 10]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+Author's Address
+
+   Shawn Emery
+   Sun Microsystems
+   500 Eldorado Blvd
+   M/S UBRM05-171
+   Broomfield, CO  80021
+   US
+
+   Email: shawn.emery@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009               [Page 11]
+
+Internet-Draft        Channel Binding Hash Agility             July 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Emery                   Expires January 15, 2009               [Page 12]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
new file mode 100644
index 00000000000..313236dda41
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
@@ -0,0 +1,673 @@
+
+
+
+NETWORK WORKING GROUP                                           S. Emery
+Internet-Draft                                          Sun Microsystems
+Updates: 4121 (if approved)                             November 3, 2008
+Intended status: Standards Track
+Expires: May 7, 2009
+
+
+        Kerberos Version 5 GSS-API Channel Binding Hash Agility
+              draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on May 7, 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 1]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+Abstract
+
+   Currently, channel bindings are implemented using a MD5 hash in the
+   Kerberos Version 5 Generic Security Services Application Programming
+   Interface (GSS-API) mechanism [RFC4121].  This document updates
+   RFC4121 to allow channel bindings using algorithms negotiated based
+   on Kerberos crypto framework as defined in RFC3961.  In addition,
+   because this update makes use of the last extensible field in the
+   Kerberos client-server exchange message, extensions are defined to
+   allow future protocol extensions.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
+   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 2]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+1.  Introduction
+
+   With the recently discovered weaknesses in the MD5 hash algorithm
+   there is a need to use stronger hash algorithms.  Kerberos Version 5
+   Generic Security Services Application Programming Interface (GSS-API)
+   mechanism [RFC4121] uses MD5 to calculate channel binding verifiers.
+   This document specifies an update to the mechanism that allows it to
+   create channel binding information based on negotiated algorithms.
+   This will allow deploying new algorithms incrementally without break
+   interoperability with older implementations, when new attacks arise
+   in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 3]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+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 [RFC2119].
+
+   The term "little endian order" is used for brevity to refer to the
+   least-significant-octet-first encoding, while the term "big endian
+   order" is for the most-significant-octet-first encoding.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 4]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+3.  Channel binding hash agility
+
+   When generating a channel binding verifier, Bnd, a hash is computed
+   from the channel binding fields.  Initiators MUST populate the Bnd
+   field in order to maintain interoperability with existing acceptors.
+   In addition, initiators MUST populate the extension field, Exts.  All
+   fields before "Exts" do not change from what is described in
+   [RFC4121], they are listed for convenience.  The 0x8003 GSS checksum
+   MUST have the following structure:
+
+      Octet     Name       Description
+      -----------------------------------------------------------------
+      0..3      Lgth       Number of octets in Bnd field;  Represented
+                            in little-endian order;  Currently contains
+                            hex value 10 00 00 00 (16).
+      4..19     Bnd        Channel binding information, as described in
+                            section 4.1.1.2 [RFC4121].
+      20..23    Flags      Four-octet context-establishment flags in
+                            little-endian order as described in section
+                            4.1.1.1 [RFC4121].
+      24..25    DlgOpt     The delegation option identifier (=1) in
+                            little-endian order [optional].  This field
+                            and the next two fields are present if and
+                            only if GSS_C_DELEG_FLAG is set as described
+                            in section 4.1.1.1 [RFC4121].
+      26..27    Dlgth      The length of the Deleg field in
+                            little-endian order [optional].
+      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
+      n..last   Exts       Extensions
+
+      where Exts is the concatenation of zero, one or more individual
+      extensions, each of which consists of, in order:
+
+        type -- big endian order unsigned integer, 32-bits, which
+                contains the type of extension
+        length -- big endian order unsigned integer, 32-bits, which
+                contains the length, in octets, of the extension data
+                encoded as an array of octets immediately following this
+                field
+        data -- octet string of extension information
+      in that order
+
+      If multiple extensions are present then there MUST be at most one
+      instance of a given extension type.
+
+   When channel binding is used the Exts MUST include the following
+   extension:
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 5]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+      data-type 0x00000000
+
+      data-value
+
+         The output obtained by applying the Kerberos V get_mic()
+         operation [RFC3961], using the sub-session key from the
+         authenticator and key usage number 43, to the channel binding
+         data as described in [RFC4121], section 4.1.1.2 (using get_mic
+         instead of MD5).
+
+   Initiators that are unwilling to use a MD5 hash of the channel
+   bindings MUST set the Bnd field to sixteen octets of hex value FF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 6]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+4.  Security considerations
+
+   Initiators do not know if the acceptor had ignored channel bindings
+   or whether it validated the MD5 hash of the channel bindings
+   [RFC4121].
+
+   Ultimately, it is up to the application whether to use channel
+   binding or not.  This is dependent upon the security policy of these
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 7]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+5.  IANA Considerations
+
+   The IANA is hereby requested to create a new registry of "Kerberos V
+   GSS-API mechanism extension types" with four-field entries (type
+   number, type name, description, and normative reference) and,
+   initially, a single registration: 0x00000000, "Channel Binding MIC,"
+   "Extension for the verifier of the channel bindings," <this RFC>.
+
+   Using the guidelines for allocation as described in [RFC5226], type
+   number assignments are as follows:
+
+      0x00000000 - 0x000003FF IETF Consensus
+
+      0x00000400 - 0xFFFFF3FF Specification Required
+
+      0xFFFFF400 - 0xFFFFFFFF Private Use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 8]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+6.  Acknowledgements
+
+   Larry Zhu helped in the review of this document overall and provided
+   the suggestions of typed-data.
+
+   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
+   fields be populated simultaneously.
+
+   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
+   changes to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                  [Page 9]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                 [Page 10]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+Author's Address
+
+   Shawn Emery
+   Sun Microsystems
+   500 Eldorado Blvd
+   M/S UBRM05-171
+   Broomfield, CO  80021
+   US
+
+   Email: shawn.emery@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                 [Page 11]
+
+Internet-Draft        Channel Binding Hash Agility         November 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Emery                      Expires May 7, 2009                 [Page 12]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt
new file mode 100644
index 00000000000..a1466b8e5e7
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt
@@ -0,0 +1,562 @@
+
+
+
+
+
+
+
+
+
+Internet-Draft                                                K. Raeburn
+Kerberos Working Group                                               MIT
+Updates: RFC 1964                                        August 13, 2003
+Document: draft-ietf-krb-wg-gss-crypto-00.txt  expires February 13, 2004
+
+                 General Kerberos Cryptosystem Support
+                  for the Kerberos 5 GSSAPI Mechanism
+
+Abstract
+
+   This document describes an update to the Kerberos 5 mechanism for
+   GSSAPI to allow the use of Kerberos-defined cryptosystems directly in
+   GSSAPI messages, without requiring further changes for each new
+   encryption or checksum algorithm that complies with the Kerberos
+   crypto framework specifications.
+
+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. Introduction
+
+   Kerberos defines an encryption and checksum framework [KCRYPTO] that
+   provides for complete specification and enumeration of cryptosystem
+   specifications in a general way, to be used within Kerberos and
+   associated protocols.  The GSSAPI Kerberos 5 mechanism definition
+   [GSSAPI-KRB5] sets up a framework for enumerating encryption and
+   checksum types, independently of how such schemes may be used in
+   Kerberos, thus requiring updates for any new encryption or checksum
+   algorithm not directly compatible with those already defined.
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                               August 2003
+
+
+   This document describes an update to [GSSAPI-KRB5] to allow the use
+   of any Kerberos-defined cryptosystems directly in GSSAPI messages,
+   without requiring further changes for each new encryption or checksum
+   algorithm that complies with the framework specifications, and
+   without making assumptions concerning block sizes or other
+   characteristics of the underlying encryption operations.
+
+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
+
+   Two new sealing algorithm numbers and one new signing algorithm
+   number are defined, for use in MIC, Wrap and Delete tokens.
+
+
+                 type          name          octet values
+                 -----------------------------------------
+                 seal   KERBEROS5-ENCRYPT       00 01
+                 sign   KERBEROS5-CHECKSUM      00 01
+                 sign          NONE             ff ff
+
+
+   The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos
+   encryption type [KCRYPTO] indicated by the encryption key type (using
+   the session key or initiator's subkey, as described in [GSSAPI-
+   KRB5]), with a key usage value KG_USAGE_SEAL, defined below.  All
+   Kerberos encryption types provide for integrity protection, and
+   specify any padding that might be required; neither needs to be done
+   at the GSS mechanism level when KERBEROS5-ENCRYPT is used.  When
+   KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm
+   MUST be NONE.
+
+   The signing algorithm value NONE MUST be used only with a sealing
+   algorithm that incorporates integrity protection; currently,
+   KERBEROS5-ENCRYPT is the only such sealing algorithm.
+
+   The KERBEROS5-CHECKSUM signing algorithm MAY be used in other cases.
+   The contents of the SGN_CKSUM field are determined by computing a
+   Kerberos checksum [KCRYPTO], using the session key or subkey, and a
+   key usage value of KG_USAGE_SIGN.  The Kerberos checksum algorithm to
+   be used is the required-to-implement checksum algorithm associated
+   with the encryption key type.  It should be noted that the checksum
+   input data in this case is not the same as the "to-be-signed data"
+   described in section 1.2.1.1 of [GSSAPI-KRB5]; see below.
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                               August 2003
+
+
+   The encryption or checksum output incorporated in the MIC and Wrap
+   tokens is the octet string output from the corresponding operation in
+   [KCRYPTO]; it should not be confused with the EncryptedData or
+   Checksum object in [KrbClar].
+
+   For purposes of key derivation, we add two new usage values to the
+   list defined in [KrbClar]; one for signing messages, and one for
+   sealing messages:
+
+
+                               name        value
+                           ----------------------
+                           KG_USAGE_SEAL    22
+                           KG_USAGE_SIGN    23
+
+
+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.
+
+   Since the quality of protection cannot be improved without fully
+   reauthenticating with a stronger key type, the QOP value is now
+   ignored.
+
+4.2. Message Layout
+
+   The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed
+   an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte
+   block size, without integrity protection.  In the crypto framework
+   described in [KCRYPTO], integrity protection is built into the
+   encryption operations.  CBC mode is not assumed, and indeed there may
+   be no initial vector to supply.  While the operations are performed
+   on messages of specific sizes, the underlying cipher may be a stream
+   cipher.
+
+   We modify the message definitions such that the portions after the
+   first 8 bytes (which specify the token identification and the signing
+   and sealing algorithms) are defined by the algorithms chosen.  The
+   remaining bytes must convey sequence number and direction
+   information, and must protect the integrity of the token id and
+   algorithm indicators.  For the DES-based algorithms specified in
+   [GSSAPI-KRB5], the definition for the remaining data is backwards
+   compatible.
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                               August 2003
+
+
+   The revised message descriptions are thus as follows:
+
+
+                                MIC token
+          Byte #    Name         Description
+          -------------------------------------------------------
+            0..1    TOK_ID       Identification field (01 01).
+            2..3    SGN_ALG      Integrity algorithm indicator.
+            4..7    Filler       Contains ff ff ff ff
+            8..N                 Dependent on SGN_ALG.
+
+          If SGN_ALG is 0000, 0100, 0200:
+            8..15   SND_SEQ      Sequence number/direction
+                                 field, encrypted.
+           16..23   SGN_CKSUM    Checksum of bytes 0..7 and
+                                 application data, as described
+                                 in [GSSAPI-KRB5].
+          If SGN_ALG is 0001:
+            8..15   SND_SEQ      Sequence number/direction
+                                 field, NOT encrypted.
+           16..N    SGN_CKSUM    Checksum of bytes 0..15 and
+                                 application data, with key
+                                 usage KG_USAGE_SIGN.
+
+
+      Suggestions from Microsoft: Moving to 64-bit sequence numbers
+      would be better for long sessions with many messages.  Using the
+      direction flag to perturb the encryption or integrity protection
+      is safer than simply including a flag which a buggy but mostly
+      working implementation might fail to check.
+
+      I am considering changing to use 64-bit sequence numbers, and
+      omitting the direction flag from the transmitted cleartext data.
+      How it would factor into the encrypted Wrap token, I haven't
+      figured out yet.
+
+      - Change the key usage values based on the direction?  It's
+      suggested in [KCRYPTO], perhaps not strongly enough, that the key
+      usage numbers should perturb the key, but DES ignores them,
+      although DES shouldn't use this extension.
+
+      - Add a direction flag byte in encrypted data?  Either depends on
+      an implementor remembering to add the check.  Adding it to
+      checksummed data requires that the implementor get it right.
+
+      - Generate one or two new keys using PRF and random-to-key
+      operations, using different keys for each direction?  Pulling the
+      DK function out of the simplified profile is probably not a good
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                               August 2003
+
+
+      way to do this.
+
+   The filler bytes are included in the checksum calculation for
+   simplicity.  There is no security benefit from including them.
+
+   In the Wrap token, the initial bytes, sequence number and direction
+   are incorporated into the data to be encrypted.  In most cases, this
+   is likely to be more efficient in terms of space and computing power
+   than using unencrypted sequence number and direction fields, adding a
+   checksum, and doing the additional work to authenticate that the
+   checksum and encrypted data are part of the same message.  (The
+   framework in [KCRYPTO] has no support for integrity protection of a
+   block of data only some of which is encrypted, except by treating the
+   two portions independently and using some additional means to ensure
+   that the two parts continue to be associated with one another.)
+
+   The length is also included, as a 4-byte value in network byte order,
+   because the decryption operation in the Kerberos crypto framework
+   does not recover the exact length of the original input.  Thus,
+   messages with application data larger than 4 gigabytes are not
+   supported.
+
+      [Q: Should this length be 8 bytes?  ASN.1 wrapper?]
+
+
+                                Wrap token
+       Byte #      Name         Description
+       -------------------------------------------------------------
+         0..1      TOK_ID       Identification field (02 01).
+         2..3      SGN_ALG      Integrity algorithm indicator.
+         4..5      SEAL_ALG     Sealing algorithm indicator.
+         6..7      Filler       Contains ff ff
+         8..last                Dependent on SEAL_ALG and SGN_ALG.
+
+       If SEAL_ALG is 0000:
+         8..15     SND_SEQ      Encrypted sequence number field.
+        16..23     SGN_CKSUM    Checksum of plaintext padded data,
+                                calculated according to algorithm
+                                specified in SGN_ALG field.  (RFC
+                                1964)
+        24..last   Data         Encrypted padded data.
+
+       If SEAL_ALG is 0001 and SGN_ALG is ffff:
+         8..last   Data         Encrypted bytes 0..5, 2-byte
+                                direction flag, sequence number,
+                                4-byte data length, and data.
+
+
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                               August 2003
+
+
+       If SEAL_ALG is ffff, and SGN_ALG is 0000, 0100, 0200:
+         8..15     SND_SEQ      Encrypted sequence number field.
+        16..23     SGN_CKSUM    Checksum of plaintext padded data,
+                                as in RFC 1964.
+        24..last   Data         plaintext padded data
+
+       If SEAL_ALG if ffff, and SGN_ALG is 0001:
+         8..15     SND_SEQ      Sequence number/direction field,
+                                NOT encrypted.
+        16..N      SGN_CKSUM    Checksum of bytes 0..15 and
+                                application data, with key usage
+                                KG_USAGE_SIGN.
+       N+1..last   Data         plaintext data
+
+
+   The direction flag, as in [GSSAPI-KRB5], is made up of bytes
+   indicating the party sending the token: 00 for the context initiator,
+   or hex FF for the context acceptor.  In the KERBEROS5-ENCRYPT case,
+   only two bytes are used, and they replace the fixed filler bytes of
+   the token header, which need no protection; this reduces slightly the
+   redundancy of the data transmitted.
+
+   The context-deletion token is essentially a MIC token with no user
+   data and a different TOK_ID value.  Thus, its modification is
+   straightforward.
+
+
+                          Context deletion token
+          Byte #    Name         Description
+          -------------------------------------------------------
+            0..1    TOK_ID       Identification field (01 02).
+            2..3    SGN_ALG      Integrity algorithm indicator.
+            4..7    Filler       Contains ff ff ff ff
+
+          If SGN_ALG is 0000, 0100, 0200:
+            8..15   SND_SEQ      Sequence number/direction
+                                 field, encrypted.
+           16..23   SGN_CKSUM    Checksum of bytes 0..7, as
+                                 described in [GSSAPI-KRB5].
+
+          If SGN_ALG is 0001:
+            8..15   SND_SEQ      Sequence number/direction
+                                 field, NOT encrypted.
+           16..N    SGN_CKSUM    Checksum of bytes 0..15, with
+                                 key usage KG_USAGE_SIGN.
+
+
+
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                               August 2003
+
+
+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 given the task of 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 (for example) AES but the Kerberos implementation
+   does.  It means that AES session keys cannot be issued for that
+   service principal, which keeps the protection of non-GSSAPI services
+   weaker than necessary.
+
+   It would also be possible to have clients attempt to get DES session
+   keys before trying to get AES session keys, and have the KDC refuse
+   to issue the DES keys only for the most critical of services, for
+   which 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 thus recommend 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 sharing service principal
+   names with GSSAPI services that have not been updated to support this
+   extension.
+
+   [optional:]
+
+   This mechanism extension MUST NOT be used with the DES encryption key
+   types described in [KCRYPTO], which ignore the key usage values.
+
+
+
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                               August 2003
+
+
+6. Implementation Note
+
+   At least two implementations have been done of extensions to the RFC
+   1964 mechanism for specific non-DES encryption types.  These are not
+   standards-track extensions, but implementors may wish to implement
+   them as well for compatibility with existing products.  No guidance
+   is provided as to when an implementation may wish to use these non-
+   standard extensions instead of the extension specified in this
+   document.
+
+7. 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.
+
+   Remember to check direction flag.  Key usage numbers and direction
+   checks?  Considerations depend on the approach taken....
+
+8. Acknowledgements
+
+   Larry Zhu...
+
+9. Normative References
+
+   [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.
+
+   [KCRYPTO]
+      draft-ietf-krb-wg-crypto-XX -> RFC xxxx
+
+   [KrbClar]
+      draft-ietf-krb-wg-kerberos-clarifications-XX -> RFC xxxx
+
+   [RFC2026]
+      RFC 2026 ...
+
+   [RFC2119]
+      RFC 2119 ...
+
+
+
+
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                               August 2003
+
+
+10. Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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."
+
+Document Change History
+
+Version -XX:
+
+   Split up Abstract and create a real Introduction.  Fix RFC 2026
+   reference in Status section.  Added Conventions, Acknowledgements and
+   Implementation Note sections.  Updated References with more
+   placeholders.  Capitalize some uses of "must" etc.
+
+   Fill in case of Wrap token without integrity protection, using
+   KERBEROS5-CHECKSUM for SGN_ALG.  Fix descriptions of which message
+   layout is used for which algorithms.
+
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                               August 2003
+
+
+   Remove discussion of authenticated encryption with additional data.
+
+   Add discussion of 64-bit sequence numbers and data length, and
+   alternate handling of the direction flag.
+
+
+   Version -XX sent in early 2003 to Kerberos working group:
+
+   Initial revision.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 10]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt
new file mode 100644
index 00000000000..a13f67c5a08
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt
@@ -0,0 +1,816 @@
+
+
+<Kerberos Working Group>                                      Larry Zhu 
+Internet Draft                                       Karthik Jaganathan 
+Updates: 1964                                                 Microsoft 
+Category: Standards Track                                   Sam Hartman 
+draft-ietf-krb-wg-gssapi-cfx-01.txt                                 MIT 
+                                                        August 29, 2003 
+                                             Expires: February 29, 2004 
+ 
+          The Kerberos Version 5 GSS-API 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 [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. 
+    
+    
+1. Abstract 
+    
+   [RFC-1964] 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 the Kerberos Version 5 mechanism (as specified in [KRBCLAR]). 
+    
+   This memo obsoletes [RFC-1964] and proposes changes in response to 
+   recent developments such as the introduction of Kerberos crypto 
+   framework.  It is intended that this memo or a subsequent version 
+   will become the Kerberos Version 5 GSS-API mechanism specification 
+   on the standards track. 
+    
+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 
+    
+   [KCRYPTO] defines a generic framework for describing encryption and 
+   checksum types to be used with the Kerberos protocol and associated 
+   protocols. 
+    
+  
+Zhu              Standards Trace - February 16, 2003                1 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+   [RFC-1964] describes the GSSAPI mechanism for Kerberos V5.  It 
+   defines the format of context initiation, per-message and context 
+   deletion tokens and uses algorithm identifiers for each cryptosystem 
+   in per message and context deletion tokens.   
+    
+   The approach taken in this document obviates the need for algorithm 
+   identifiers.  This is accomplished by using the same encryption and 
+   checksum algorithms specified by the crypto profile [KCRYPTO] for 
+   the session key or subkey that is created during context 
+   negotiation.  Message layouts of the per-message and context 
+   deletion tokens are therefore revised to remove algorithm indicators 
+   and also to add extra information to support the generic crypto 
+   framework [KCRYPTO].  
+    
+   Tokens transferred between GSS-API peers for security context 
+   initiation are also described in this document.  The data elements 
+   exchanged between a GSS-API endpoint implementation and the Kerberos 
+   KDC are not specific to GSS-API usage and are therefore defined 
+   within [KRBCLAR] rather than within this specification. 
+    
+   The new token formats specified in this memo MUST be used with all 
+   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
+   encryption types, provided that the initiator and acceptor know, 
+   from the context establishment, that they can both process these new 
+   token formats. 
+    
+   "Newer" encryption types are those which have been specified along 
+   with or since the new Kerberos cryptosystem specification [KCRYPTO] 
+   [KRBCLAR]. 
+    
+   Note that in this document, "AES" is used for brevity to refer 
+   loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 
+   as defined in [AES-KRB5].  AES is used as an example of the new 
+   method defined in this document. 
+    
+4. Key Derivation for Per-Message and Context Deletion Tokens 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.  This document defines four 
+   key usage values below for signing and sealing messages: 
+    
+        Name                         value 
+      ------------------------------------- 
+       KG-USAGE-ACCEPTOR-SEAL         22 
+       KG-USAGE-ACCEPTOR-SIGN         23 
+       KG-USAGE-INITIATOR-SEAL        24 
+       KG-USAGE-INITIATOR-SIGN        25 
+          
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC and context deletion tokens, and KG-USAGE-
+   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 
+   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 
+
+Zhu              Standards Track - February 16, 2004                2 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+   number in the key derivation function for MIC and context deletion 
+   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if 
+   the Wrap token does not provide for confidentiality the same usage 
+   values specified above are used. 
+    
+5. Quality of Protection 
+ 
+   The GSSAPI specification [RFC-2743] provides for Quality of 
+   Protection (QOP) values that can be used by the application to 
+   request a certain type of encryption or signing.  A zero QOP value 
+   is used to indicate the "default" protection; applications which use 
+   the default QOP are not guaranteed to be portable across 
+   implementations or even inter-operate with different deployment 
+   configurations of the same implementation.  Using an algorithm that 
+   is different from the one for which the key is defined may not be 
+   appropriate.  Therefore, when the new method in this document is 
+   used, the QOP value is ignored. 
+    
+   The encryption and checksum algorithms in per-message and context 
+   deletion tokens are now implicitly defined by the algorithms 
+   associated with the session key or subkey.  Algorithms identifiers 
+   as described in [RFC-1964] are therefore no longer needed and 
+   removed from the new token headers. 
+ 
+6. Token Framing 
+    
+   Per [RFC-2743], all tokens emitted by the Kerberos V5 GSS-API 
+   mechanism will have the framing shown below: 
+    
+      GSS-API DEFINITIONS ::= 
+ 
+      BEGIN 
+ 
+      MechType ::= OBJECT IDENTIFIER 
+      -- representing Kerberos V5 mechanism 
+ 
+      GSSAPI-Token ::= 
+      -- option indication (delegation, etc.) indicated within 
+      -- mechanism-specific token 
+      [APPLICATION 0] IMPLICIT SEQUENCE { 
+              thisMech MechType, 
+              innerToken ANY DEFINED BY thisMech 
+                 -- contents mechanism-specific 
+                 -- ASN.1 structure not required 
+              } 
+      END 
+    
+   The innerToken field always starts with a two byte token-identifier 
+   (TOK_ID).  Here are the TOK_ID values: 
+    
+         Token                       TOK_ID Value in hex 
+        ------------------------------------------- 
+         KRB_AP_REQUEST                 01 00 
+         KRB_AP_REQPLY                  02 00 
+
+Zhu              Standards Track - February 16, 2004                3 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+         KRB_ERROR                      03 00 
+         [RFC-1964] MIC                 01 01 
+         [RFC-1964] Wrap                01 02 
+         [RFC-1964] context deletion    02 01  
+         MIC                            04 04 
+         Wrap                           04 05 
+         context deletion               05 04 
+             
+    
+7. Context Initialization Tokens 
+    
+   For context initialization tokens, the body for the innerToken field 
+   contains a Kerberos V5 message (KRB_AP_REQUEST, KRB_AP_REPLY, or 
+   KRB_ERROR) as defined in [KRBCLAR].   
+    
+7.1. Authenticator Checksum 
+ 
+   The authenticator in the KRB_AP_REQ message MUST include the 
+   optional sequence number and the checksum field.  The checksum field 
+   is used to convey service flags, channel binding, and optional 
+   delegation information.  It MUST have a type of 0x8003.  The length 
+   of the checksum MUST be 24 bytes when delegation is not used.  When 
+   delegation is used, a TGT with its FORWARDABLE flag set will be 
+   transferred within the KRB_CRED [KRBCLAR] message. 
+    
+   The format of the authenticator checksum field is as follows. 
+       
+      Byte    Name      Description 
+     ----------------------------------------------------------------- 
+      0..3    Lgth    Number of bytes in Bnd field; 
+                      Currently contains hex 10 00 00 00 
+                      (16, represented in little-endian form) 
+      4..19   Bnd     MD5 hash of channel bindings, taken over all  
+                      non-null components of bindings, in order  
+                      of declaration.  Integer fields within channel  
+                      bindings are represented in little-endian order  
+                      for the purposes of the MD5 calculation. 
+      20..23  Flags   Bit vector of context-establishment flags, 
+                      as defined next. The resulting bit vector is  
+                      encoded into bytes 20..23 in little-endian form. 
+      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
+      26..27  Dlgth   The length of the Deleg field [optional] 
+      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
+  
+   [we need to get input on how to allow additional data for 
+   extensions.  Nicolas will post some text for this.  If that is the 
+   case, do we need to change the checksum type?] 
+ 
+7.1.1. Flags Field 
+ 
+   The checksum flags are used to convey service options or extension 
+   negotiation information.  The bits in the Flags field are allocated 
+   as follows (Most significant bit is bit 0): 
+    
+Zhu              Standards Track - February 16, 2004                4 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+      Bit         Name          Description                  
+    ---------------------------------------------------- 
+      0..11     Mandatory     Critical extension flags 
+      12..15    Optional      Non-critical extension flags 
+      16..31    Standard      Context establishment flags 
+     
+   An extension or context establishment flag can either be critical or 
+   non-critical.  When the context initiator desires a particular 
+   extension or context establishment flag (either critical or non-
+   critical) it sets the appropriate checksum flag.  The context 
+   acceptor MUST ignore unsupported non-critical extensions or flags in 
+   the initiator's context token (i.e., acceptors MUST NOT return an 
+   error just because there were unsupported non-critical extensions or 
+   flags in the initiator's token).  The acceptor MUST return 
+   GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical 
+   extensions or flags in the initiator's context token. 
+     
+   The following context establishment flags are defined in [RFC-2744] 
+    
+        Flag Name                Value     
+      --------------------------------- 
+       GSS_C_DELEG_FLAG           1        
+       GSS_C_MUTUAL_FLAG          2       
+       GSS_C_REPLAY_FLAG          4       
+       GSS_C_SEQUENCE_FLAG        8        
+       GSS_C_CONF_FLAG           16      
+       GSS_C_INTEG_FLAG          32     
+       GSS_C_ANON_FLAG           64 
+        
+   Context establishment flags are exposed to the calling application.  
+   If the calling application desires a particular service option then 
+   it requests that option via GSS_Init_sec_context().  An 
+   implementation that supports a particular extension SHOULD then set 
+   the appropriate flag in the checksum Flags field. 
+    
+   All existing context establishment flags are non-critical, and it is 
+   possible that a new context establishment flag can be added as a 
+   critical flag. 
+    
+7.1.2. Channel Binding Information 
+ 
+   In computing the contents of the "Bnd" field, the following detailed 
+   points apply:  
+    
+   (1) Each integer field shall be formatted into four bytes, using 
+   little-endian byte ordering, for purposes of MD5 hash computation.  
+    
+   (2) All input length fields within gss_buffer_desc [RFC-2744] 
+   elements of a gss_channel_bindings_struct [RFC-2744], even those 
+   which are zero-valued, shall be included in the hash calculation; 
+   the value elements of gss_buffer_desc elements shall be 
+   dereferenced, and the resulting data shall be included within the 
+   hash computation, only for the case of gss_buffer_desc elements 
+   having non-zero length specifiers.  
+
+Zhu              Standards Track - February 16, 2004                5 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+    
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
+   valid channel bindings structure, the Bnd field shall be set to 16 
+   zero-valued bytes.  
+ 
+   [Nicolas suggested that the only change that might be needed here 
+   was the use of SHA1 instead of MD5] 
+ 
+8. Per-Message and Context Deletion Tokens 
+    
+   The new per-message and context deletion token formats defined in 
+   this document are designed to accommodate the requirements of newer 
+   crypto systems.  The token layouts have also been designed to 
+   facilitate scatter-gather and in-place encryption without incurring 
+   significant performance penalties for implementations that do not 
+   allow for either scatter-gather or in-place encryption.   
+    
+   The design along with the rationale behind it is discussed in detail 
+   in the following sections. 
+    
+8.1. Sequence Number and Direction Indicator 
+ 
+   The sequence number for any per-message or context deletion token is 
+   a 64 bit integer (expressed in big endian order).  One separate flag 
+   is used as the direction-indicator as described in section 8.2.  
+   Both the sequence number and the direction-indicator are protected 
+   by the encryption and checksum procedures as specified in section 
+   8.4.  
+ 
+8.2. Flags Field 
+ 
+   The Flags field is a one-byte bit vector used to indicate a set of 
+   attributes.  The meanings of the flags are: 
+    
+        Bit    Name             Description 
+       --------------------------------------------------------------- 
+        0     SentByAcceptor  When set, this flag indicates the sender  
+                              is the context acceptor.  When not set, 
+                              it indicates the sender is the context  
+                              initiator. 
+        1     Sealed          When set in Wrap tokens, this flag  
+                              indicates confidentiality is provided  
+                              for.  It MUST not be set in MIC and  
+                              context deletion tokens. 
+    
+   The rest of available bits are reserved for future use. 
+    
+8.3. EC Field 
+ 
+   The EC (Extra Count) field is a two-byte integer field expressed in 
+   big endian order.   
+    
+
+
+Zhu              Standards Track - February 16, 2004                6 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+   In Wrap tokens with confidentiality, the EC field is used to encode 
+   the size (in bytes) of the random filler, as described in section 
+   8.4. 
+    
+   In Wrap tokens without confidentiality, the EC field is used to 
+   encode the size (in bytes) of the trailing checksum, as described in 
+   section 8.4.   
+    
+   When AES is used, the EC field contains the hex value 00 0C in Wrap 
+   tokens without confidentiality, and 00 00 in Wrap tokens with 
+   confidentiality.   
+ 
+8.4. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection.  Therefore no separate checksum is needed.  
+    
+   The result of decryption can be longer than the original plaintext 
+   [KCRYPTO] and the extra trailing bytes are called "crypto-system 
+   garbage".  However, given the size of any plaintext data, one can 
+   always find the next (possibly larger) size so that, when padding 
+   the to-be-encrypted text to that size, there will be no crypto-
+   system garbage added [KCRYPTO].  
+    
+   In Wrap tokens that provide for confidentiality, the "header" (the 
+   first 16 bytes of the Wrap token) is appended to the plaintext data 
+   before encryption.  Random filler is inserted between the plaintext-
+   data and the "header", and there SHALL NOT be crypto-system garbage 
+   added by the decryption operation.  The resulting Wrap token is 
+   {"header" | encrypt(plaintext-data | random-filler | "header")}, 
+   where encrypt() is the encryption operation (which provides for 
+   integrity protection) defined in the crypto profile [KCRYPTO].   
+    
+   [A note from the design team (Sam, Nicolas, Ken, JK and Larry):  
+   constraints need to be added to kcrypto to keep the header at the 
+   end of the decrypted data.  Without these constraints, we might have 
+   the header pre-pended to the front of the data and encode an 8 byte 
+   length for the plaintext data, which is less efficient.  
+    
+   Constraints to be added: Given the length of any plaintext data, 
+   there should always exist the next (possibly larger) size for which, 
+   when padding the to-be-encrypted data to that size, there will be no 
+   cryptosystem garbage added, and the number of bytes needed to pad to 
+   the next size is no larger than 64K.  This is a small addition to 
+   kcrypto and we will bring it up at the IETF last call for kcrypto] 
+    
+   In Wrap tokens that do not provide for confidentiality, the checksum 
+   is calculated over the plaintext data concatenated with the token 
+   header (the first 16 bytes of the Wrap token).  The resulting Wrap 
+   token is {"header" | plaintext-data | get_mic(plaintext-data | 
+   "header")},  where get_mic() is the checksum operation defined in 
+   the crypto profile [KCRYPTO].  
+    
+
+Zhu              Standards Track - February 16, 2004                7 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+   The parameters for the key and the cipher-state in the encrypt() and 
+   get_mic() operations have been omitted for brevity.   
+        
+   The resulting Wrap tokens bind the data to the token header, 
+   including the sequence number and the directional indicator.  
+     
+   [With AEAD, Wrap tokens with confidentiality do not need to encrypt 
+   the header and the overhead can be reduced slightly] 
+   
+   For MIC tokens, the checksum is first calculated over the token 
+   header (the first 16 bytes of the MIC token) and then the to-be-
+   signed plaintext data.   
+   
+   For context deletion tokens, the checksum is calculated over the 
+   token header (the first 16 bytes of the context deletion token). 
+   
+   When AES is used, the checksum algorithm is HMAC_SHA1_96 and the 
+   checksum size is 12 bytes.  Data is pre-pended with a 16 byte 
+   confounder before encryption, and no padding is needed. 
+   
+8.5. RRC Field 
+ 
+   The RRC (Right Rotation Count) field in Wrap tokens is added to 
+   allow the data to be encrypted in-place by existing [SSPI] 
+   applications that do not provide an additional buffer for the 
+   trailer (the cipher text after the in-place-encrypted data) in 
+   addition to the buffer for the header (the cipher text before the 
+   in-place-encrypted data).  The resulting Wrap token in the previous 
+   section, excluding the first 16 bytes of the token header, is 
+   rotated to the right by "RRC" bytes.  The net result is that "RRC" 
+   bytes of trailing octets are moved toward the header.  Consider the 
+   following as an example of this rotation operation: Assume that the 
+   RRC value is 3 and the token before the rotation is {"header" | aa | 
+   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
+   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
+   | cc |...| hh} is used to indicate the byte sequence. 
+  
+   The RRC field is expressed as a two-byte integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values. 
+ 
+8.6. Message Layout for Per-message and Context Deletion Tokens 
+    
+   The new message layouts are as follows. 
+    
+   MIC Token: 
+    
+      Byte no           Name           Description 
+       0..1            TOK_ID       Identification field. 
+                                    Tokens emitted by GSS_GetMIC()   
+                                    contain the hex value 04 04 in  
+
+Zhu              Standards Track - February 16, 2004                8 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+                                    this field. 
+       2               Flags        Attributes field, as described in                 
+                                    Section 8.2. 
+       3..7            Filler       Contains 5 bytes of hex value FF. 
+       8..15           SND_SEQ      Sequence number field in  
+                                    cleartext, in big endian order.  
+       16..last        SGN_CKSUM    Checksum of byte 0..15 and the 
+                                    "to-be-signed" data, where the 
+                                    checksum algorithm is defined by      
+                                    the crypto profile for the  
+                                    session key or subkey. 
+ 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.  This is common to both MIC and context deletion token 
+   checksum calculations. 
+ 
+   Wrap Token: 
+    
+      Byte no           Name           Description 
+       0..1            TOK_ID       Identification field. 
+                                    Tokens emitted by GSS_Wrap()                     
+                                    contain the hex value 05 04  
+                                    in this field. 
+       2               Flags        Attributes field, as described in                 
+                                    Section 8.2. 
+       3               Filler       Contains the hex value FF. 
+       4..5            EC           Contains the "extra count" field,   
+                                    in big endian order as described in  
+                                    section 8.3. 
+       6..7            RRC          Contains the "right rotation                      
+                                    count" in big endian order, as  
+                                    described in section 8.5. 
+       8..15           SND_SEQ      Sequence number field in                      
+                                    cleartext, in big endian order. 
+       16..last        Data         Encrypted data or (plaintext data +  
+                                    checksum), as described in section  
+                                    8.4, where the encryption or  
+                                    checksum algorithm is defined by  
+                                    the crypto profile for the session 
+                                    key or subkey. 
+                                    
+                                   
+   Context Deletion Token:       
+    
+      Byte no          Name             Description 
+       0..1           TOK_ID        Identification field. 
+                                    Tokens emitted by 
+                                    GSS_Delete_sec_context() contain 
+                                    the hex value 04 05 in this  
+                                    field. 
+       2              Flags         Attributes field, as described in                 
+                                    Section 8.2. 
+
+Zhu              Standards Track - February 16, 2004                9 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+       3..7           Filler        Contains 5 bytes of hex value FF. 
+       8..15          SND_SEQ       Sequence number field in  
+                                    cleartext, in big endian order.  
+       16..N          SGN_CKSUM     Checksum of byte 0..15, where the 
+                                    checksum algorithm is defined by      
+                                    the crypto profile for the  
+                                    session key or subkey. 
+    
+                                 
+9. Parameter Definitions 
+    
+   This section defines parameter values used by the Kerberos V5 GSS-
+   API mechanism. It defines interface elements in support of 
+   portability, and assumes use of C language bindings per [RFC-2744]. 
+    
+9.1. Minor Status Codes 
+ 
+   This section recommends common symbolic names for minor_status 
+   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
+   these definitions will enable independent implementers 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 GSS-API 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.  
+    
+9.1.1. Non-Kerberos-specific codes 
+ 
+      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 
+
+Zhu              Standards Track - February 16, 2004               10 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+              /* "Credential usage type is unknown" */ 
+      GSS_KRB5_S_G_UNKNOWN_QOP 
+              /* "Unknown quality of protection specified" */ 
+    
+9.1.2. Kerberos-specific-codes 
+    
+      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" */ 
+ 
+9.2. Buffer Sizes 
+ 
+   All implementations of this specification shall be capable of 
+   accepting buffers of at least 16K bytes as input to GSS_GetMIC(), 
+   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
+   the output_token generated by GSS_Wrap() for a 16K byte input buffer 
+   as input to GSS_Unwrap().  Support for larger buffer sizes is 
+   optional but recommended. 
+ 
+10. Backwards Compatibility Considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  To address this, implementations 
+   can always use the explicit sign or seal algorithm in [GSSAPI-KRB5] 
+   when the key type corresponds to "older" algorithms.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [GSSAPI-KRB5].  However this 
+   would require the use of a mechanism such as [RFC-2478] to securely 
+   negotiate the algorithm or the use out of band mechanism to choose 
+   appropriate algorithms.  For this reason, it is RECOMMENDED that the 
+   new token formats defined in this document can be used only if both 
+   peers are known during context negotiation to support the new 
+   mechanism (either because of the use of "new" enctypes or because of 
+   the use of Kerberos V extensions). 
+ 
+11. Security Considerations 
+ 
+   It is possible that the KDC returns a session-key type that is not 
+   supported by the GSSAPI implementation (either on the client and the 
+   server). In this case the implementation MUST not try to use the key 
+
+Zhu              Standards Track - February 16, 2004               11 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+   with a supported cryptosystem. This will ensure that no security 
+   weaknesses arise due to the use of an inappropriate key with an 
+   encryption algorithm. 
+    
+   In addition the security problem described in [3DES] arising from 
+   the use of a service implementation with a GSSAPI mechanism 
+   supporting only DES and a Kerberos mechanism supporting both DES and 
+   Triple DES is actually a more generic one.  It arises whenever the 
+   GSSAPI implementation does not support a stronger cryptosystem 
+   supported by the Kerberos mechanism.  KDC administrators desiring to 
+   limit the session key types to support interoperability with such 
+   GSSAPI implementations should carefully weigh the reduction in 
+   protection offered by such mechanisms against the benefits of 
+   interoperability. 
+    
+    
+12. Acknowledgments 
+   
+  The authors wish to acknowledge the contributions from the following 
+  individuals:  
+ 
+  Ken Raeburn and Nicolas Willams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of this 
+  draft.  
+   
+  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments.  
+   
+  Scott Field, Richard Ward, Dan Simon also provided valuable inputs on 
+  this draft. 
+ 
+13. References 
+    
+13.1. Normative References 
+    
+   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
+   3", BCP 9, RFC 2026, October 1996.  
+        
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
+   Requirement Levels", BCP 14, RFC 2119, March 1997. 
+    
+   [AES] National Institute of Standards and Technology, U.S. 
+   Department of Commerce, "Advanced Encryption Standard", Federal 
+   Information Processing Standards Publication 197, Washington, DC, 
+   November 2001. 
+    
+
+
+Zhu              Standards Track - February 16, 2004               12 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
+   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress. 
+    
+   [3DES] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI    
+   Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT    
+   distribution, June 2000. 
+    
+   [RFC-2743] Linn, J., "Generic Security Service Application Program    
+   Interface Version 2, Update 1", RFC 2743, January 2000. 
+    
+   [RFC-2744] Wray, J., "Generic Security Service API Version 2 : C-
+   bindings", RFC 2744, January 2000. 
+    
+   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
+   RFC 1964, June 1996. 
+    
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
+   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
+   progress.  
+    
+   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
+   Raeburn, K., "The Kerveros Network Authentication Service (V5)",    
+   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
+   Work in progress. 
+    
+   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism.", RFC 2478, December 1998. 
+ 
+13.2. Informative References 
+ 
+   [SSPI] Leach, P., Security Service Provider Interface, MSDN, April 
+   2003 
+    
+14. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: karthikj@microsoft.com 
+ 
+   Sam Hartman 
+   Massachusetts Institute of Technology 
+   77 Massachusetts Avenue 
+   Cambridge, MA 02139 - USA 
+   Email: hartmans@MIT.EDU 
+    
+    
+Zhu              Standards Track - February 16, 2004               13 
+                  Kerberos Version 5 GSS-API      August 2003 
+ 
+ 
+    
+Full Copyright Statement 
+    
+   "Copyright (C) The Internet Society (date). 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. 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu              Standards Track - February 16, 2004               14 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-02.txt
new file mode 100644
index 00000000000..96fe594f41a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-02.txt
@@ -0,0 +1,883 @@
+
+ 
+
+<Network Working Group>                                       Larry Zhu 
+Internet Draft                                       Karthik Jaganathan 
+Updates: 1964                                                 Microsoft 
+Category: Standards Track                                   Sam Hartman 
+draft-ietf-krb-wg-gssapi-cfx-02.txt                                 MIT 
+                                                     September 29, 2003 
+                                                Expires: March 29, 2004 
+ 
+          The Kerberos Version 5 GSS-API 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 [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. 
+    
+Abstract 
+    
+   This memo defines protocols, procedures, and conventions to be 
+   employed by peers implementing the Generic Security Service 
+   Application Program Interface (GSS-API as specified in [RFC-2743]) 
+   when using the Kerberos Version 5 mechanism (as specified in 
+   [KRBCLAR]). 
+    
+   [RFC-1964] is updated and incremental changes are proposed in 
+   response to recent developments such as the introduction of Kerberos 
+   crypto framework [KCRYPTO].  These changes support the inclusion of 
+   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
+   new per-message and context-deletion tokens along with their 
+   encryption and checksum algorithms.   
+    
+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]. 
+    
+1. Introduction 
+    
+
+  
+Zhu                         Internet Draft                           1 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+   [KCRYPTO] defines a generic framework for describing encryption and 
+   checksum types to be used with the Kerberos protocol and associated 
+   protocols. 
+    
+   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
+   It defines the format of context initiation, per-message and context 
+   deletion tokens and uses algorithm identifiers for each cryptosystem 
+   in per message and context deletion tokens.   
+    
+   The approach taken in this document obviates the need for algorithm 
+   identifiers.  This is accomplished by using the same encryption and 
+   checksum algorithms specified by the crypto profile [KCRYPTO] for 
+   the session key or subkey that is created during context 
+   negotiation.  Message layouts of the per-message and context 
+   deletion tokens are therefore revised to remove algorithm indicators 
+   and also to add extra information to support the generic crypto 
+   framework [KCRYPTO].  
+    
+   Tokens transferred between GSS-API peers for security context 
+   initiation are also described in this document.  The data elements 
+   exchanged between a GSS-API endpoint implementation and the Kerberos 
+   KDC are not specific to GSS-API usage and are therefore defined 
+   within [KRBCLAR] rather than within this specification. 
+    
+   The new token formats specified in this memo MUST be used with all 
+   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
+   encryption types, provided that the initiator and acceptor know, 
+   from the context establishment, that they can both process these new 
+   token formats. 
+    
+   "Newer" encryption types are those which have been specified along 
+   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
+   as defined in section 3.1.3 of [KRBCLAR]. 
+    
+   Note that in this document, the term "little endian order" is used 
+   for brevity to refer to the least-significant-byte-first encoding, 
+   while the term "big endian order" is for the most-significant-byte-
+   first encoding. 
+    
+2. Key Derivation for Per-Message and Context Deletion Tokens 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.  This document defines four 
+   key usage values below for signing and sealing messages: 
+    
+        Name                         Value 
+      ------------------------------------- 
+       KG-USAGE-ACCEPTOR-SEAL         22 
+       KG-USAGE-ACCEPTOR-SIGN         23 
+       KG-USAGE-INITIATOR-SEAL        24 
+       KG-USAGE-INITIATOR-SIGN        25 
+          
+
+Zhu                         Internet Draft                           2 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC and context deletion tokens, and KG-USAGE-
+   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 
+   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 
+   number in the key derivation function for MIC and context deletion 
+   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if 
+   the Wrap token does not provide for confidentiality the same usage 
+   values specified above are used. 
+    
+   During context initiation, the acceptor MAY assert a subkey, and if 
+   so, subsequent messages MUST use this subkey as the protocol key and 
+   these messages MUST be flagged as "AcceptorSubkey" as described in 
+   section 4.2.2. 
+    
+3. Quality of Protection 
+ 
+   The GSS-API specification [RFC-2743] provides for Quality of 
+   Protection (QOP) values that can be used by applications to request 
+   a certain type of encryption or signing.  A zero QOP value is used 
+   to indicate the "default" protection; applications which use the 
+   default QOP are not guaranteed to be portable across implementations 
+   or even inter-operate with different deployment configurations of 
+   the same implementation.  Using an algorithm that is different from 
+   the one for which the key is defined may not be appropriate.  
+   Therefore, when the new method in this document is used, the QOP 
+   value is ignored. 
+    
+   The encryption and checksum algorithms in per-message and context 
+   deletion tokens are now implicitly defined by the algorithms 
+   associated with the session key or subkey.  Algorithms identifiers 
+   as described in [RFC-1964] are therefore no longer needed and 
+   removed from the new token headers. 
+ 
+4. Definitions and Token Formats 
+    
+   This section provides terms and definitions, as well as descriptions 
+   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
+    
+4.1. Initial Context Tokens 
+    
+   Per [RFC-2743], all context initiation tokens emitted by the 
+   Kerberos V5 GSS-API mechanism will have the framing shown below: 
+    
+         GSS-API DEFINITIONS ::= 
+    
+         BEGIN 
+    
+         MechType ::= OBJECT IDENTIFIER 
+         -- representing Kerberos V5 mechanism 
+    
+         GSSAPI-Token ::= 
+         -- option indication (delegation, etc.) indicated within 
+         -- mechanism-specific token 
+
+Zhu                         Internet Draft                           3 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+         [APPLICATION 0] IMPLICIT SEQUENCE { 
+                 thisMech MechType, 
+                 innerToken ANY DEFINED BY thisMech 
+                    -- contents mechanism-specific 
+                    -- ASN.1 structure not required 
+                 } 
+    
+         END 
+    
+   The innerToken field starts with a two-byte token-identifier 
+   (TOK_ID) expressed in big endian order, followed by a Kerberos 
+   message.   
+    
+   Here are the TOK_ID values used in the initial tokens: 
+    
+         Token               TOK_ID Value in Hex  
+        ----------------------------------------- 
+         KRB_AP_REQUEST        01 00 
+         KRB_AP_REPLY          02 00 
+         KRB_ERROR             03 00 
+             
+   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
+   are defined in [KRBCLAR].   
+    
+   If an unknown token ID is received in the first context token, the 
+   receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the 
+   returned output token MUST contain a KRB_ERROR message with the 
+   error code KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
+    
+4.1.1. Authenticator Checksum 
+ 
+   The authenticator in the KRB_AP_REQ message MUST include the 
+   optional sequence number and the checksum field.  The checksum field 
+   is used to convey service flags, channel bindings, and optional 
+   delegation information.  It MUST have a type of 0x8003.  The length 
+   of the checksum MUST be 24 bytes when delegation is not used.  When 
+   delegation is used, a ticket-granting ticket will be transferred in 
+   a KRB_CRED message.  The ticket SHOULD have its forwardable flag 
+   set.  The KRB_CRED message MUST be encrypted in the session key of 
+   the ticket used to authenticate the context. 
+    
+   The format of the authenticator checksum field is as follows. 
+       
+      Byte    Name      Description 
+     ----------------------------------------------------------------- 
+      0..3    Lgth    Number of bytes in Bnd field;  Currently contains  
+                      hex value 10 00 00 00 (16, represented in little- 
+                      endian order) 
+      4..19   Bnd     Channel binding information, as describe in  
+                      section 4.1.1.2. 
+      20..23  Flags   Four-byte context-establishment flags in little- 
+                      endian order as described in section 4.1.1.1.  
+      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
+      26..27  Dlgth   The length of the Deleg field [optional] 
+
+
+Zhu                         Internet Draft                           4 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
+ 
+4.1.1.1. Checksum Flags Field 
+    
+   The checksum "Flags" field is used to convey service options or 
+   extension negotiation information.  The following context 
+   establishment flags are defined in [RFC-2744]. 
+    
+        Flag Name              Value     
+      --------------------------------- 
+       GSS_C_DELEG_FLAG           1        
+       GSS_C_MUTUAL_FLAG          2       
+       GSS_C_REPLAY_FLAG          4       
+       GSS_C_SEQUENCE_FLAG        8        
+       GSS_C_CONF_FLAG           16      
+       GSS_C_INTEG_FLAG          32     
+       GSS_C_ANON_FLAG           64 
+        
+   Context establishment flags are exposed to the calling application.  
+   If the calling application desires a particular service option then 
+   it requests that option via GSS_Init_sec_context() [RFC-2743].  An 
+   implementation that supports a particular option or extension SHOULD 
+   then set the appropriate flag in the checksum Flags field.   
+    
+   The receiver MUST ignore unknown checksum flags. 
+    
+4.1.1.2. Channel Binding Information 
+ 
+   Channel bindings are user-specified tags to identify a given context 
+   to the peer application.  These tags are intended to be used to 
+   identify the particular communications channel that carries the 
+   context. 
+    
+   When using C language bindings, channel bindings are communicated to 
+   the GSS-API using the following structure [RFC-2744]: 
+ 
+      typedef struct gss_channel_bindings_struct { 
+         OM_uint32       initiator_addrtype; 
+         gss_buffer_desc initiator_address; 
+         OM_uint32       acceptor_addrtype; 
+         gss_buffer_desc acceptor_address; 
+         gss_buffer_desc application_data; 
+      } *gss_channel_bindings_t; 
+    
+   The member fields and constants used for different address types are 
+   defined in [RFC-2744]. 
+    
+   The "Bnd" field contains the MD5 hash of channel bindings, taken 
+   over all non-null components of bindings, in order of declaration.  
+   Integer fields within channel bindings are represented in little-
+   endian order for the purposes of the MD5 calculation. 
+    
+   In computing the contents of the Bnd field, the following detailed 
+   points apply:  
+
+
+Zhu                         Internet Draft                           5 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+    
+   (1) Each integer field shall be formatted into four bytes, using 
+   little endian byte ordering, for purposes of MD5 hash computation.  
+    
+   (2) All input length fields within gss_buffer_desc elements of a 
+   gss_channel_bindings_struct even those which are zero-valued, shall 
+   be included in the hash calculation; the value elements of 
+   gss_buffer_desc elements shall be dereferenced, and the resulting 
+   data shall be included within the hash computation, only for the 
+   case of gss_buffer_desc elements having non-zero length specifiers.  
+    
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
+   valid channel binding structure, the Bnd field shall be set to 16 
+   zero-valued bytes.  
+ 
+4.2. Per-Message and Context Deletion Tokens 
+    
+   Three classes of tokens are defined in this section:  "MIC" tokens, 
+   emitted by calls to GSS_GetMIC() and consumed by calls to 
+   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
+   consumed by calls to GSS_Unwrap(), and context deletion tokens, 
+   emitted by calls to GSS_Delete_sec_context() and consumed by calls 
+   to GSS_Process_context_token(). 
+    
+   The new per-message and context deletion tokens introduced here do 
+   not include the pseudo ASN.1 header used by the initial context 
+   tokens.  These new tokens are designed to be used with newer crypto 
+   systems that can, for example, have variable-size checksums.   
+    
+4.2.1. Sequence Number and Direction Indicator 
+ 
+   To distinguish intentionally-repeated messages from maliciously-
+   replayed ones, per-message and context deletion tokens contain a 
+   sequence number field, which is a 64 bit integer expressed in big 
+   endian order.  One separate bit is used as the direction-indicator 
+   in the Flags field as described in section 4.2.2, thus preventing an 
+   adversary from sending back the same message in the reverse 
+   direction and having it accepted.  Both the sequence number and the 
+   direction-indicator are protected by the encryption and checksum 
+   procedures specified in section 4.2.4.  
+    
+   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's 
+   sequence numbers are incremented by one. 
+ 
+4.2.2. Flags Field 
+ 
+   The "Flags" field is a one-byte integer used to indicate a set of 
+   attributes.  The meanings of bits in this field (the least 
+   significant bit is bit 0) are as follows: 
+    
+        Bit    Name             Description 
+       --------------------------------------------------------------- 
+        0   SentByAcceptor    When set, this flag indicates the sender  
+                              is the context acceptor.  When not set, 
+
+
+Zhu                         Internet Draft                           6 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+                              it indicates the sender is the context  
+                              initiator. 
+        1   Sealed            When set in Wrap tokens, this flag  
+                              indicates confidentiality is provided  
+                              for.  It SHALL NOT be set in MIC and  
+                              context deletion tokens. 
+        2   AcceptorSubkey    A subkey asserted by the context acceptor 
+                              is used to protect the message. 
+    
+   The rest of available bits are reserved for future use and MUST be 
+   cleared.  The receiver MUST ignore unknown flags. 
+    
+4.2.3. EC Field 
+ 
+   The "EC" (Extra Count) field is a two-byte integer field expressed 
+   in big endian order.   
+    
+   In Wrap tokens with confidentiality, the EC field is used to encode 
+   the number of bytes in the filler, as described in section 4.2.4. 
+    
+   In Wrap tokens without confidentiality, the EC field is used to 
+   encode the number of bytes in the trailing checksum, as described in 
+   section 4.2.4.   
+ 
+4.2.4. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection [KCRYPTO].  Therefore no separate checksum is 
+   needed.  
+    
+   The result of decryption can be longer than the original plaintext 
+   [KCRYPTO] and the extra trailing bytes are called "crypto-system 
+   garbage".  However, given the size of any plaintext data, one can 
+   always find the next (possibly larger) size so that, when padding 
+   the to-be-encrypted text to that size, there will be no crypto-
+   system garbage added [KCRYPTO].  
+    
+   In Wrap tokens that provide for confidentiality, the first 16 bytes 
+   of the Wrap token (the "header") are appended to the plaintext data 
+   before encryption.  Filler bytes can be inserted between the 
+   plaintext-data and the "header", and the values and size of the 
+   filler octets are chosen by implementations, such that there is no 
+   crypto-system garbage present after the decryption.  The resulting 
+   Wrap token is {"header" | encrypt(plaintext-data | filler | 
+   "header")}, where encrypt() is the encryption operation (which 
+   provides for integrity protection) defined in the crypto profile 
+   [KCRYPTO], and the RRC field in the to-be-encrypted header contains 
+   the hex value 00 00.   
+           
+   In Wrap tokens that do not provide for confidentiality, the checksum 
+   is calculated first over the plaintext data, and then the first 16 
+   bytes of the Wrap token (the "header").  Both the EC field and the 
+   RRC field in the token header are filled with zeroes for the purpose 
+   of calculating the checksum.  The resulting Wrap token is {"header" 
+
+
+Zhu                         Internet Draft                           7 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+   | plaintext-data | get_mic(plaintext-data | "header")},  where 
+   get_mic() is the checksum operation defined in the crypto profile 
+   [KCRYPTO].  
+    
+   The parameters for the key and the cipher-state in the encrypt() and 
+   get_mic() operations have been omitted for brevity.   
+        
+   For MIC tokens, the checksum is first calculated over the first 16 
+   bytes of the MIC token and then the to-be-signed plaintext data.   
+   
+   The resulting Wrap and MIC tokens bind the data to the token header, 
+   including the sequence number and the directional indicator.  
+   
+   For context deletion tokens, the checksum is calculated over the 
+   first 16 bytes of the token message. 
+   
+4.2.5. RRC Field 
+ 
+   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
+   allow the data to be encrypted in-place by existing [SSPI] 
+   applications that do not provide an additional buffer for the 
+   trailer (the cipher text after the in-place-encrypted data) in 
+   addition to the buffer for the header (the cipher text before the 
+   in-place-encrypted data).  The resulting Wrap token in the previous 
+   section, excluding the first 16 bytes of the token header, is 
+   rotated to the right by "RRC" bytes.  The net result is that "RRC" 
+   bytes of trailing octets are moved toward the header.  Consider the 
+   following as an example of this rotation operation:  Assume that the 
+   RRC value is 3 and the token before the rotation is {"header" | aa | 
+   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
+   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
+   | cc |...| hh} is used to indicate the byte sequence. 
+  
+   The RRC field is expressed as a two-byte integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values. 
+ 
+4.2.6. Message Layouts 
+    
+   Per-message and context deletion token messages start with a two-
+   byte token identifier (TOK_ID) field, expressed in big endian order. 
+   These tokens are defined separately in subsequent sub-sections. 
+    
+4.2.6.1. MIC Tokens 
+    
+   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 as received.  The token has the following format: 
+    
+
+Zhu                         Internet Draft                           8 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+
+      Byte no     Name       Description 
+      -----------------------------------------------------------------  
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_GetMIC() contain the hex value 04 04  
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3..7     Filler     Contains five bytes of hex value FF. 
+       8..15    SND_SEQ    Sequence number field in clear text,  
+                           expressed in big endian order.  
+       16..last SGN_CKSUM  Checksum of byte 0..15 and the "to-be- 
+                           signed" data, where the checksum algorithm  
+                           is defined by the crypto profile for the  
+                           session key or subkey. 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.  This is common to both MIC and context deletion token 
+   checksum calculations. 
+    
+4.2.6.2. Wrap Tokens 
+    
+   Use of the GSS_Wrap() call yields a token, which consists of a 
+   descriptive header, followed by a body portion that contains either 
+   the input user data in plaintext concatenated with the checksum, or 
+   the input user data encrypted.  The GSS_Wrap() token has the 
+   following format: 
+    
+      Byte no     Name       Description 
+      --------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_Wrap() contain the the hex value 05 04                 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3        Filler     Contains the hex value FF. 
+       4..5     EC         Contains the "extra count" field, in big  
+                           endian order as described in section 4.2.3. 
+       6..7     RRC        Contains the "right rotation count" in big  
+                           endian order, as described in section 4.2.5. 
+       8..15    SND_SEQ    Sequence number field in clear text, 
+                           expressed in big endian order. 
+       16..last Data       Encrypted data for Wrap tokens with  
+                           confidentiality, or plaintext data followed  
+                           by the checksum for Wrap tokens without  
+                           confidentiality, as described in section  
+                           4.2.4, where the encryption or checksum 
+                           algorithm is defined by the crypto profile  
+                           for the session key or subkey. 
+                                   
+4.2.6.3. Context Deletion Tokens        
+    
+   The token emitted by GSS_Delete_sec_context() is based on the packet 
+   format for tokens emitted by GSS_GetMIC().  The context-deletion 
+   token has the following format: 
+    
+
+Zhu                         Internet Draft                           9 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+      Byte no     Name       Description 
+      ----------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_Delete_sec_context() contain the hex  
+                           value 04 05 expressed in big endian order in  
+                           this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3..7     Filler     Contains five bytes of hex value FF. 
+       8..15    SND_SEQ    Sequence number field in clear text,  
+                           expressed in big endian order.  
+       16..N    SGN_CKSUM  Checksum of byte 0..15, where the checksum  
+                           algorithm is defined by the crypto profile  
+                           for the session key or subkey. 
+                                 
+5. Parameter Definitions 
+    
+   This section defines parameter values used by the Kerberos V5 GSS-
+   API mechanism. It defines interface elements in support of 
+   portability, and assumes use of C language bindings per [RFC-2744]. 
+    
+5.1. Minor Status Codes 
+ 
+   This section recommends common symbolic names for minor_status 
+   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
+   these definitions will enable independent implementers 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 GSS-API 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.  
+    
+5.1.1. Non-Kerberos-specific codes 
+ 
+      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" */ 
+
+
+Zhu                         Internet Draft                          10 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+      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" */ 
+    
+5.1.2. Kerberos-specific-codes 
+    
+      GSS_KRB5_S_KG_CCACHE_NOMATCH  
+              /* "Client principal in credentials does not match   
+                 specified name" */ 
+      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
+              /* "No key available for specified service principal" */ 
+      GSS_KRB5_S_KG_TGT_MISSING 
+              /* "No Kerberos ticket-granting ticket available" */ 
+      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" */ 
+ 
+5.2. Buffer Sizes 
+ 
+   All implementations of this specification shall be capable of 
+   accepting buffers of at least 16K bytes as input to GSS_GetMIC(), 
+   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
+   the output_token generated by GSS_Wrap() for a 16K byte input buffer 
+   as input to GSS_Unwrap().  Support for larger buffer sizes is 
+   optional but recommended. 
+ 
+6. Backwards Compatibility Considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  To address this, implementations 
+   can always use the explicit sign or seal algorithm in [RFC-1964] 
+   when the key type corresponds to "older" enctypes.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [RFC-1964].  However this would 
+   require either the use of a mechanism such as [RFC-2478] to securely 
+   negotiate the method or the use out of band mechanism to choose 
+   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
+   new token formats defined in this document SHOULD be used only if 
+   both peers are known to support the new mechanism during context 
+   negotiation, for example, either because of the use of "new" 
+   enctypes or because of the use of Kerberos Version 5 extensions. 
+
+ 
+Zhu                         Internet Draft                          11 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+7. Security Considerations 
+    
+   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 given the task of 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 (for example) AES [AES-KRB5] but the Kerberos 
+   implementation does.  It means that AES session keys cannot be 
+   issued for that service principal, which keeps the protection of 
+   non-GSSAPI services weaker than necessary.  KDC administrators 
+   desiring to limit the session key types to support interoperability 
+   with such GSSAPI implementations should carefully weigh the 
+   reduction in protection offered by such mechanisms against the 
+   benefits of interoperability. 
+    
+8. Acknowledgments 
+   
+  The authors wish to acknowledge the contributions from the following 
+  individuals:  
+ 
+  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of this 
+  draft.  
+   
+  The text for security considerations was contributed by Ken Raeburn. 
+   
+  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
+  namely the encoding of the RRC field.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments.  
+   
+  Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 
+  valuable inputs on this draft. 
+   
+  Jeffrey Hutzelman provided comments on channel bindings and suggested 
+  many editorial changes. 
+ 
+  This document retains some of the text of RFC-1964 in relevant 
+  sections. 
+
+Zhu                         Internet Draft                          12 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+   
+9. References 
+    
+9.1. Normative References 
+    
+   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
+   3", BCP 9, RFC 2026, October 1996.  
+        
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
+   Requirement Levels", BCP 14, RFC 2119, March 1997. 
+    
+   [RFC-2743] Linn, J., "Generic Security Service Application Program    
+   Interface Version 2, Update 1", RFC 2743, January 2000. 
+    
+   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
+   bindings", RFC 2744, January 2000. 
+    
+   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
+   RFC 1964, June 1996. 
+    
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
+   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
+   progress.  
+    
+   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
+   Raeburn, K., "The Kerveros Network Authentication Service (V5)",    
+   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
+   Work in progress. 
+    
+   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
+   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress.  
+    
+   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism", RFC 2478, December 1998. 
+ 
+9.2. Informative References 
+ 
+   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
+   Developer Network (MSDN), April 2003. 
+    
+10. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: karthikj@microsoft.com 
+ 
+Zhu                         Internet Draft                          13 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+   Sam Hartman 
+   Massachusetts Institute of Technology 
+   77 Massachusetts Avenue 
+   Cambridge, MA 02139 - USA 
+   Email: hartmans@MIT.EDU 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Internet Draft                          14 
+                 Kerberos Version 5 GSS-API      September 2003 
+ 
+ 
+    
+Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (date). 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Internet Draft                          15 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-03.txt
new file mode 100644
index 00000000000..ab7641e2ed5
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-03.txt
@@ -0,0 +1,880 @@
+
+
+<Network Working Group>                                       Larry Zhu 
+Internet Draft                                       Karthik Jaganathan 
+Updates: 1964                                                 Microsoft 
+Category: Standards Track                                   Sam Hartman 
+draft-ietf-krb-wg-gssapi-cfx-03.txt                                 MIT 
+                                                       October 26, 2003 
+                                                Expires: April 26, 2004 
+ 
+          The Kerberos Version 5 GSS-API 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 [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. 
+    
+Abstract 
+    
+   This memo defines protocols, procedures, and conventions to be 
+   employed by peers implementing the Generic Security Service 
+   Application Program Interface (GSS-API as specified in [RFC-2743]) 
+   when using the Kerberos Version 5 mechanism (as specified in 
+   [KRBCLAR]). 
+    
+   [RFC-1964] is updated and incremental changes are proposed in 
+   response to recent developments such as the introduction of Kerberos 
+   crypto framework [KCRYPTO].  These changes support the inclusion of 
+   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
+   new per-message tokens along with their encryption and checksum 
+   algorithms.   
+    
+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]. 
+    
+1. Introduction 
+    
+
+  
+Zhu                         Internet Draft                           1 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   [KCRYPTO] defines a generic framework for describing encryption and 
+   checksum types to be used with the Kerberos protocol and associated 
+   protocols. 
+    
+   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
+   It defines the format of context establishment, per-message and 
+   context deletion tokens and uses algorithm identifiers for each 
+   cryptosystem in per message and context deletion tokens.   
+    
+   The approach taken in this document obviates the need for algorithm 
+   identifiers.  This is accomplished by using the same encryption 
+   algorithm, specified by the crypto profile [KCRYPTO] for the session 
+   key or subkey that is created during context negotiation, and its 
+   required checksum algorithm.  Message layouts of the per-message 
+   tokens are therefore revised to remove algorithm indicators and also 
+   to add extra information to support the generic crypto framework 
+   [KCRYPTO].  
+    
+   Tokens transferred between GSS-API peers for security context 
+   establishment are also described in this document.  The data 
+   elements exchanged between a GSS-API endpoint implementation and the 
+   Kerberos KDC are not specific to GSS-API usage and are therefore 
+   defined within [KRBCLAR] rather than within this specification. 
+    
+   The new token formats specified in this memo MUST be used with all 
+   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
+   encryption types, provided that the initiator and acceptor know, 
+   from the context establishment, that they can both process these new 
+   token formats. 
+    
+   "Newer" encryption types are those which have been specified along 
+   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
+   as defined in section 3.1.3 of [KRBCLAR]. 
+    
+   Note that in this document, the term "little endian order" is used 
+   for brevity to refer to the least-significant-octet-first encoding, 
+   while the term "big endian order" is for the most-significant-octet-
+   first encoding. 
+    
+2. Key Derivation for Per-Message Tokens 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.  This document defines four 
+   key usage values below for signing and sealing messages: 
+    
+        Name                         Value 
+      ------------------------------------- 
+       KG-USAGE-ACCEPTOR-SEAL         22 
+       KG-USAGE-ACCEPTOR-SIGN         23 
+       KG-USAGE-INITIATOR-SEAL        24 
+       KG-USAGE-INITIATOR-SIGN        25 
+          
+
+Zhu                         Internet Draft                           2 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used 
+   for Wrap tokens; similarly when the sender is the context initiator, 
+   KG-USAGE-INITIATOR-SIGN is used as the usage number in the key 
+   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
+   for Wrap Tokens.  Even if the Wrap token does not provide for 
+   confidentiality the same usage values specified above are used. 
+    
+   During the context initiation and acceptance sequence, the acceptor 
+   MAY assert a subkey.  If the acceptor asserts a subkey, subsequent 
+   messages SHOULD use this subkey as the protocol key and these 
+   messages MUST be flagged as "AcceptorSubkey" as described in section 
+   4.2.2.  
+    
+3. Quality of Protection 
+ 
+   The GSS-API specification [RFC-2743] provides for Quality of 
+   Protection (QOP) values that can be used by applications to request 
+   a certain type of encryption or signing.  A zero QOP value is used 
+   to indicate the "default" protection; applications which do not use 
+   the default QOP are not guaranteed to be portable across 
+   implementations or even inter-operate with different deployment 
+   configurations of the same implementation.  Using an algorithm that 
+   is different from the one for which the key is defined may not be 
+   appropriate.  Therefore, when the new method in this document is 
+   used, the QOP value is ignored. 
+    
+   The encryption and checksum algorithms in per-message tokens are now 
+   implicitly defined by the algorithms associated with the session key 
+   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
+   therefore no longer needed and removed from the new token headers. 
+ 
+4. Definitions and Token Formats 
+    
+   This section provides terms and definitions, as well as descriptions 
+   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
+                                    
+4.1. Context Establishment Tokens 
+    
+   All context establishment tokens emitted by the Kerberos V5 GSS-API 
+   mechanism will have the framing shown below: 
+    
+         GSS-API DEFINITIONS ::= 
+    
+         BEGIN 
+    
+         MechType ::= OBJECT IDENTIFIER 
+         -- representing Kerberos V5 mechanism 
+    
+         GSSAPI-Token ::= 
+         -- option indication (delegation, etc.) indicated within 
+         -- mechanism-specific token 
+         [APPLICATION 0] IMPLICIT SEQUENCE { 
+
+
+Zhu                         Internet Draft                           3 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+                 thisMech MechType, 
+                 innerToken ANY DEFINED BY thisMech 
+                    -- contents mechanism-specific 
+                    -- ASN.1 structure not required 
+                 } 
+    
+         END 
+    
+   Where the notation and encoding of this pseudo ASN.1 header, which 
+   is referred as the generic GSS-API token framing later in this 
+   document, are described in [RFC-2743], and the innerToken field 
+   starts with a two-octet token-identifier (TOK_ID) expressed in big 
+   endian order, followed by a Kerberos message.   
+    
+   Here are the TOK_ID values used in the context establishment tokens: 
+    
+         Token               TOK_ID Value in Hex  
+        ----------------------------------------- 
+         KRB_AP_REQUEST        01 00 
+         KRB_AP_REPLY          02 00 
+         KRB_ERROR             03 00 
+             
+   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
+   are defined in [KRBCLAR].   
+    
+   If an unknown token identifier (TOK_ID) is received in the initial 
+   context estalishment token, the receiver MUST return 
+   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
+   MUST contain a KRB_ERROR message with the error code 
+   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
+    
+4.1.1. Authenticator Checksum 
+ 
+   The authenticator in the KRB_AP_REQ message MUST include the 
+   optional sequence number and the checksum field.  The checksum field 
+   is used to convey service flags, channel bindings, and optional 
+   delegation information.  The checksum type MUST be 0x8003.  The 
+   length of the checksum MUST be 24 octets when delegation is not 
+   used.  When delegation is used, a ticket-granting ticket will be 
+   transferred in a KRB_CRED message.  This ticket SHOULD have its 
+   forwardable flag set.  The KRB_CRED message MUST be encrypted in the 
+   session key of the ticket used to authenticate the context. 
+    
+   The format of the authenticator checksum field is as follows. 
+       
+      Octet    Name      Description 
+     ----------------------------------------------------------------- 
+      0..3    Lgth    Number of octets in Bnd field;  Currently  
+                      contains hex value 10 00 00 00 (16, represented  
+                      in little-endian order) 
+      4..19   Bnd     Channel binding information, as described in  
+                      section 4.1.1.2. 
+      20..23  Flags   Four-octet context-establishment flags in little- 
+                      endian order as described in section 4.1.1.1.  
+
+
+Zhu                         Internet Draft                           4 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
+      26..27  Dlgth   The length of the Deleg field [optional] 
+      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
+ 
+4.1.1.1. Checksum Flags Field 
+    
+   The checksum "Flags" field is used to convey service options or 
+   extension negotiation information.  The following context 
+   establishment flags are defined in [RFC-2744]. 
+    
+        Flag Name              Value     
+      --------------------------------- 
+       GSS_C_DELEG_FLAG           1        
+       GSS_C_MUTUAL_FLAG          2       
+       GSS_C_REPLAY_FLAG          4       
+       GSS_C_SEQUENCE_FLAG        8        
+       GSS_C_CONF_FLAG           16      
+       GSS_C_INTEG_FLAG          32     
+        
+   Context establishment flags are exposed to the calling application.  
+   If the calling application desires a particular service option then 
+   it requests that option via GSS_Init_sec_context() [RFC-2743].  An 
+   implementation that supports a particular option or extension SHOULD 
+   then set the appropriate flag in the checksum Flags field.   
+    
+   The most significant eight bits of the checksum flags are reserved 
+   for future use.  The receiver MUST ignore unknown checksum flags. 
+    
+4.1.1.2. Channel Binding Information 
+ 
+   Channel bindings are user-specified tags to identify a given context 
+   to the peer application.  These tags are intended to be used to 
+   identify the particular communications channel that carries the 
+   context [RFC-2743] [RFC-2744]. 
+    
+   When using C language bindings, channel bindings are communicated to 
+   the GSS-API using the following structure [RFC-2744]: 
+ 
+      typedef struct gss_channel_bindings_struct { 
+         OM_uint32       initiator_addrtype; 
+         gss_buffer_desc initiator_address; 
+         OM_uint32       acceptor_addrtype; 
+         gss_buffer_desc acceptor_address; 
+         gss_buffer_desc application_data; 
+      } *gss_channel_bindings_t; 
+    
+   The member fields and constants used for different address types are 
+   defined in [RFC-2744]. 
+    
+   The "Bnd" field contains the MD5 hash of channel bindings, taken 
+   over all non-null components of bindings, in order of declaration.  
+   Integer fields within channel bindings are represented in little-
+   endian order for the purposes of the MD5 calculation.
+ 
+    
+Zhu                         Internet Draft                           5 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   In computing the contents of the Bnd field, the following detailed 
+   points apply:  
+    
+   (1) Each integer field shall be formatted into four octets, using 
+   little endian octet ordering, for purposes of MD5 hash computation.  
+    
+   (2) All input length fields within gss_buffer_desc elements of a 
+   gss_channel_bindings_struct even those which are zero-valued, shall 
+   be included in the hash calculation; the value elements of 
+   gss_buffer_desc elements shall be dereferenced, and the resulting 
+   data shall be included within the hash computation, only for the 
+   case of gss_buffer_desc elements having non-zero length specifiers.  
+    
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
+   valid channel binding structure, the Bnd field shall be set to 16 
+   zero-valued octets.  
+ 
+4.2. Per-Message Tokens 
+    
+   Two classes of tokens are defined in this section:  "MIC" tokens, 
+   emitted by calls to GSS_GetMIC() and consumed by calls to 
+   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
+   consumed by calls to GSS_Unwrap(). 
+    
+   The new per-message tokens introduced here do not include the 
+   generic GSS-API token framing used by the context establishment 
+   tokens.  These new tokens are designed to be used with newer crypto 
+   systems that can, for example, have variable-size checksums.   
+    
+4.2.1. Sequence Number 
+ 
+   To distinguish intentionally-repeated messages from maliciously-
+   replayed ones, per-message tokens contain a sequence number field, 
+   which is a 64 bit integer expressed in big endian order.  After 
+   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
+   numbers are incremented by one. 
+ 
+4.2.2. Flags Field 
+ 
+   The "Flags" field is a one-octet integer used to indicate a set of 
+   attributes for the protected message.  For example, one flag is 
+   allocated as the direction-indicator, thus preventing an adversary 
+   from sending back the same message in the reverse direction and 
+   having it accepted.   
+    
+   The meanings of bits in this field (the least significant bit is bit 
+   0) are as follows: 
+    
+        Bit    Name             Description 
+       --------------------------------------------------------------- 
+        0   SentByAcceptor    When set, this flag indicates the sender  
+                              is the context acceptor.  When not set, 
+                              it indicates the sender is the context  
+                              initiator. 
+
+
+Zhu                         Internet Draft                           6 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+        1   Sealed            When set in Wrap tokens, this flag  
+                              indicates confidentiality is provided  
+                              for.  It SHALL NOT be set in MIC tokens. 
+        2   AcceptorSubkey    A subkey asserted by the context acceptor 
+                              is used to protect the message. 
+    
+   The rest of available bits are reserved for future use and MUST be 
+   cleared.  The receiver MUST ignore unknown flags. 
+    
+4.2.3. EC Field 
+ 
+   The "EC" (Extra Count) field is a two-octet integer field expressed 
+   in big endian order.   
+    
+   In Wrap tokens with confidentiality, the EC field is used to encode 
+   the number of octets in the filler, as described in section 4.2.4. 
+    
+   In Wrap tokens without confidentiality, the EC field is used to 
+   encode the number of octets in the trailing checksum, as described 
+   in section 4.2.4.   
+ 
+4.2.4. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection [KCRYPTO].  Therefore no separate checksum is 
+   needed.  
+    
+   The result of decryption can be longer than the original plaintext 
+   [KCRYPTO] and the extra trailing octets are called "crypto-system 
+   garbage".  However, given the size of any plaintext data, one can 
+   always find the next (possibly larger) size so that, when padding 
+   the to-be-encrypted text to that size, there will be no crypto-
+   system garbage added [KCRYPTO].  
+ 
+   In Wrap tokens that provide for confidentiality, the first 16 octets 
+   of the Wrap token (the "header", as defined in section 4.2.6), are 
+   appended to the plaintext data before encryption.  Filler octets can 
+   be inserted between the plaintext data and the "header", and the 
+   values and size of the filler octets are chosen by implementations, 
+   such that there is no crypto-system garbage present after the 
+   decryption.  The resulting Wrap token is {"header" | 
+   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
+   encryption operation (which provides for integrity protection) 
+   defined in the crypto profile [KCRYPTO], and the RRC field in the 
+   to-be-encrypted header contains the hex value 00 00.   
+           
+   In Wrap tokens that do not provide for confidentiality, the checksum 
+   is calculated first over the to-be-signed plaintext data, and then 
+   the first 16 octets of the Wrap token (the "header", as defined in 
+   section 4.2.6).  Both the EC field and the RRC field in the token 
+   header are filled with zeroes for the purpose of calculating the 
+   checksum.  The resulting Wrap token is {"header" | plaintext-data | 
+   get_mic(plaintext-data | "header")},  where get_mic() is the 
+
+Zhu                         Internet Draft                           7 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   checksum operation for the required checksum mechanism of the chosen 
+   encryption mechanism defined in the crypto profile [KCRYPTO].  
+    
+   The parameters for the key and the cipher-state in the encrypt() and 
+   get_mic() operations have been omitted for brevity.   
+        
+   For MIC tokens, the checksum is first calculated over the to-be-
+   signed plaintext data, and then the first 16 octets of the MIC 
+   token, where the checksum mechanism is the required checksum 
+   mechanism of the chosen encryption mechanism defined in the crypto 
+   profile [KCRYPTO]. 
+   
+   The resulting Wrap and MIC tokens bind the data to the token header, 
+   including the sequence number and the direction indicator.  
+   
+4.2.5. RRC Field 
+ 
+   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
+   allow the data to be encrypted in-place by existing [SSPI] 
+   applications that do not provide an additional buffer for the 
+   trailer (the cipher text after the in-place-encrypted data) in 
+   addition to the buffer for the header (the cipher text before the 
+   in-place-encrypted data).  The resulting Wrap token in the previous 
+   section, excluding the first 16 octets of the token header, is 
+   rotated to the right by "RRC" octets.  The net result is that "RRC" 
+   octets of trailing octets are moved toward the header.  Consider the 
+   following as an example of this rotation operation:  Assume that the 
+   RRC value is 3 and the token before the rotation is {"header" | aa | 
+   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
+   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
+   | cc |...| hh} is used to indicate the octet sequence. 
+  
+   The RRC field is expressed as a two-octet integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values. 
+ 
+4.2.6. Message Layouts 
+    
+   Per-message tokens start with a two-octet token identifier (TOK_ID) 
+   field, expressed in big endian order.  These tokens are defined 
+   separately in subsequent sub-sections. 
+    
+4.2.6.1. MIC Tokens 
+    
+   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 as received.  The token has the following format: 
+    
+      Octet no     Name       Description 
+      ----------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+
+
+Zhu                         Internet Draft                           8 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+                           GSS_GetMIC() contain the hex value 04 04  
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3..7     Filler     Contains five octets of hex value FF. 
+       8..15    SND_SEQ    Sequence number field in clear text,  
+                           expressed in big endian order.  
+       16..last SGN_CKSUM  Checksum of octet 0..15 and the "to-be- 
+                           signed" data, as described in section 4.2.4. 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.   
+    
+4.2.6.2. Wrap Tokens 
+    
+   Use of the GSS_Wrap() call yields a token, which consists of a 
+   descriptive header, followed by a body portion that contains either 
+   the input user data in plaintext concatenated with the checksum, or 
+   the input user data encrypted.  The GSS_Wrap() token has the 
+   following format: 
+    
+      Octet no     Name       Description 
+      --------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_Wrap() contain the the hex value 05 04                 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3        Filler     Contains the hex value FF. 
+       4..5     EC         Contains the "extra count" field, in big  
+                           endian order as described in section 4.2.3. 
+       6..7     RRC        Contains the "right rotation count" in big  
+                           endian order, as described in section 4.2.5. 
+       8..15    SND_SEQ    Sequence number field in clear text, 
+                           expressed in big endian order. 
+       16..last Data       Encrypted data for Wrap tokens with  
+                           confidentiality, or plaintext data followed  
+                           by the checksum for Wrap tokens without  
+                           confidentiality, as described in section  
+                           4.2.4.         
+             
+4.3. Context Deletion Tokens 
+ 
+   Context deletion tokens are empty in this mechanism.  Both peers to 
+   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
+   independently, passing a null output_context_token buffer to 
+   indicate that no context_token is required.  Implementations of 
+   GSS_Delete_sec_context() should delete relevant locally-stored 
+   context information. 
+        
+4.4. Token Identifier Assignment Considerations 
+    
+   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
+   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
+
+
+Zhu                         Internet Draft                           9 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   the first two octets of a token, one can tell unambiguously if it is 
+   wrapped with the generic GSS-API token framing.   
+    
+5. Parameter Definitions 
+    
+   This section defines parameter values used by the Kerberos V5 GSS-
+   API mechanism.  It defines interface elements in support of 
+   portability, and assumes use of C language bindings per [RFC-2744]. 
+    
+5.1. Minor Status Codes 
+ 
+   This section recommends common symbolic names for minor_status 
+   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
+   these definitions will enable independent implementers 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 GSS-API 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.  
+    
+5.1.1. Non-Kerberos-specific codes 
+ 
+      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" */ 
+    
+5.1.2. Kerberos-specific-codes 
+    
+Zhu                         Internet Draft                          10 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+      GSS_KRB5_S_KG_CCACHE_NOMATCH  
+              /* "Client principal in credentials does not match   
+                 specified name" */ 
+      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
+              /* "No key available for specified service principal" */ 
+      GSS_KRB5_S_KG_TGT_MISSING 
+              /* "No Kerberos ticket-granting ticket available" */ 
+      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" */ 
+ 
+5.2. Buffer Sizes 
+ 
+   All implementations of this specification shall be capable of 
+   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
+   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
+   the output_token generated by GSS_Wrap() for a 16K octet input 
+   buffer as input to GSS_Unwrap().  Support for larger buffer sizes is 
+   optional but recommended. 
+ 
+6. Backwards Compatibility Considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  To address this, implementations 
+   can always use the explicit sign or seal algorithm in [RFC-1964] 
+   when the key type corresponds to "older" enctypes.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [RFC-1964].  However this would 
+   require either the use of a mechanism such as [RFC-2478] to securely 
+   negotiate the method or the use out of band mechanism to choose 
+   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
+   new token formats defined in this document SHOULD be used only if 
+   both peers are known to support the new mechanism during context 
+   negotiation because of, for example, the use of "new" enctypes. 
+ 
+   GSS_Unwrap() or GSS_Verify_MIC() can process a message token as 
+   follows: it can look at the first octet of the token header, if it 
+   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
+   framing, otherwise the first two octets of the token contain the 
+   TOK_ID that uniquely identify the token message format. 
+    
+7. Security Considerations 
+    
+   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. 
+
+Zhu                         Internet Draft                          11 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   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 given the task of 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 (for example) AES [AES-KRB5] but the Kerberos 
+   implementation does.  It means that AES session keys cannot be 
+   issued for that service principal, which keeps the protection of 
+   non-GSSAPI services weaker than necessary.  KDC administrators 
+   desiring to limit the session key types to support interoperability 
+   with such GSSAPI implementations should carefully weigh the 
+   reduction in protection offered by such mechanisms against the 
+   benefits of interoperability. 
+    
+8. Acknowledgments 
+ 
+  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of this 
+  memo.  
+   
+  The text for security considerations was contributed by Ken Raeburn. 
+   
+  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
+  namely the encoding of the RRC field.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments.  
+   
+  Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 
+  valuable inputs on this memo. 
+   
+  Jeffrey Hutzelman provided comments on channel bindings and suggested 
+  many editorial changes. 
+ 
+  Luke Howard provided implementations of this memo for the Heimdal 
+  code base, and helped inter-operability testing with the Microsoft 
+  code base, together with Love.  These experiments formed the basis of 
+  this memo. 
+   
+  Martin Rex provided suggestions of TOK_ID assignment recommendations 
+  thus the token tagging in this memo is unambiguous if the token is 
+  wrapped with the pseudo ASN.1 header.  
+   
+
+
+Zhu                         Internet Draft                          12 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+  This document retains some of the text of RFC-1964 in relevant 
+  sections. 
+   
+9. References 
+    
+9.1. Normative References 
+    
+   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
+   3", BCP 9, RFC 2026, October 1996.  
+        
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
+   Requirement Levels", BCP 14, RFC 2119, March 1997. 
+    
+   [RFC-2743] Linn, J., "Generic Security Service Application Program    
+   Interface Version 2, Update 1", RFC 2743, January 2000. 
+    
+   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
+   bindings", RFC 2744, January 2000. 
+    
+   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
+   RFC 1964, June 1996. 
+    
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
+   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
+   progress.  
+    
+   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
+   Raeburn, K., "The Kerberos Network Authentication Service (V5)",    
+   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
+   Work in progress. 
+    
+   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
+   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress.  
+    
+   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism", RFC 2478, December 1998. 
+ 
+9.2. Informative References 
+ 
+   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
+   Developer Network (MSDN), April 2003. 
+    
+10. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA
+
+ 
+Zhu                         Internet Draft                          13 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+   EMail: karthikj@microsoft.com 
+ 
+   Sam Hartman 
+   Massachusetts Institute of Technology 
+   77 Massachusetts Avenue 
+   Cambridge, MA 02139 - USA 
+   Email: hartmans@MIT.EDU 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Internet Draft                          14 
+                  Kerberos Version 5 GSS-API      October 2003 
+ 
+ 
+    
+Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (date). 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Internet Draft                          15 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt
new file mode 100644
index 00000000000..7d407186511
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt
@@ -0,0 +1,884 @@
+
+
+<Network Working Group>                                       Larry Zhu 
+Internet Draft                                       Karthik Jaganathan 
+Updates: 1964                                                 Microsoft 
+Category: Standards Track                                   Sam Hartman 
+draft-ietf-krb-wg-gssapi-cfx-04.txt                                 MIT 
+                                                      November 21, 2003 
+                                                  Expires: May 21, 2004 
+ 
+          The Kerberos Version 5 GSS-API 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 [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. 
+    
+Abstract 
+    
+   This memo defines protocols, procedures, and conventions to be 
+   employed by peers implementing the Generic Security Service 
+   Application Program Interface (GSS-API as specified in [RFC-2743]) 
+   when using the Kerberos Version 5 mechanism (as specified in 
+   [KRBCLAR]). 
+    
+   [RFC-1964] is updated and incremental changes are proposed in 
+   response to recent developments such as the introduction of Kerberos 
+   crypto framework [KCRYPTO].  These changes support the inclusion of 
+   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
+   new per-message tokens along with their encryption and checksum 
+   algorithms.   
+    
+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]. 
+    
+1. Introduction 
+    
+
+  
+Zhu                         Internet Draft                           1 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   [KCRYPTO] defines a generic framework for describing encryption and 
+   checksum types to be used with the Kerberos protocol and associated 
+   protocols. 
+    
+   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
+   It defines the format of context establishment, per-message and 
+   context deletion tokens and uses algorithm identifiers for each 
+   cryptosystem in per message and context deletion tokens.   
+    
+   The approach taken in this document obviates the need for algorithm 
+   identifiers.  This is accomplished by using the same encryption 
+   algorithm, specified by the crypto profile [KCRYPTO] for the session 
+   key or subkey that is created during context negotiation, and its 
+   required checksum algorithm.  Message layouts of the per-message 
+   tokens are therefore revised to remove algorithm indicators and also 
+   to add extra information to support the generic crypto framework 
+   [KCRYPTO].  
+    
+   Tokens transferred between GSS-API peers for security context 
+   establishment are also described in this document.  The data 
+   elements exchanged between a GSS-API endpoint implementation and the 
+   Kerberos KDC are not specific to GSS-API usage and are therefore 
+   defined within [KRBCLAR] rather than within this specification. 
+    
+   The new token formats specified in this memo MUST be used with all 
+   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
+   encryption types, provided that the initiator and acceptor know, 
+   from the context establishment, that they can both process these new 
+   token formats. 
+    
+   "Newer" encryption types are those which have been specified along 
+   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
+   as defined in section 3.1.3 of [KRBCLAR].  The list of not-newer 
+   encryption types is as follows [KCRYPTO]: 
+    
+             Encryption Type             Assigned Number     
+           ---------------------------------------------- 
+            des-cbc-crc                        1              
+            des-cbc-md4                        2              
+            des-cbc-md5                        3              
+            des3-cbc-md5                       5 
+            des3-cbc-sha1                      7 
+            dsaWithSHA1-CmsOID                 9            
+            md5WithRSAEncryption-CmsOID       10            
+            sha1WithRSAEncryption-CmsOID      11           
+            rc2CBC-EnvOID                     12            
+            rsaEncryption-EnvOID              13    
+            rsaES-OAEP-ENV-OID                14    
+            des-ede3-cbc-Env-OID              15            
+            des3-cbc-sha1-kd                  16                       
+            rc4-hmac                          23          
+    
+   Note that in this document, the term "little endian order" is used 
+   for brevity to refer to the least-significant-octet-first encoding,
+ 
+
+Zhu                         Internet Draft                           2 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   while the term "big endian order" is for the most-significant-octet-
+   first encoding. 
+    
+2. Key Derivation for Per-Message Tokens 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.   
+    
+   This document defines four key usage values below that are used to 
+   derive a specific key for signing and sealing messages, from the 
+   session key or subkey [KRBCLAR] created during the context 
+   establishment. 
+    
+        Name                         Value 
+      ------------------------------------- 
+       KG-USAGE-ACCEPTOR-SEAL         22 
+       KG-USAGE-ACCEPTOR-SIGN         23 
+       KG-USAGE-INITIATOR-SEAL        24 
+       KG-USAGE-INITIATOR-SIGN        25 
+          
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used 
+   for Wrap tokens; similarly when the sender is the context initiator, 
+   KG-USAGE-INITIATOR-SIGN is used as the usage number in the key 
+   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
+   for Wrap Tokens.  Even if the Wrap token does not provide for 
+   confidentiality the same usage values specified above are used. 
+    
+   During the context initiation and acceptance sequence, the acceptor 
+   MAY assert a subkey, and if so, subsequent messages MUST use this 
+   subkey as the protocol key and these messages MUST be flagged as 
+   "AcceptorSubkey" as described in section 4.2.2. 
+ 
+3. Quality of Protection 
+ 
+   The GSS-API specification [RFC-2743] provides for Quality of 
+   Protection (QOP) values that can be used by applications to request 
+   a certain type of encryption or signing.  A zero QOP value is used 
+   to indicate the "default" protection; applications which do not use 
+   the default QOP are not guaranteed to be portable across 
+   implementations or even inter-operate with different deployment 
+   configurations of the same implementation.  Using an algorithm that 
+   is different from the one for which the key is defined may not be 
+   appropriate.  Therefore, when the new method in this document is 
+   used, the QOP value is ignored. 
+    
+   The encryption and checksum algorithms in per-message tokens are now 
+   implicitly defined by the algorithms associated with the session key 
+   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
+   therefore no longer needed and removed from the new token headers. 
+ 
+4. Definitions and Token Formats 
+
+
+Zhu                         Internet Draft                           3 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+    
+   This section provides terms and definitions, as well as descriptions 
+   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
+                                    
+4.1. Context Establishment Tokens 
+    
+   All context establishment tokens emitted by the Kerberos V5 GSS-API 
+   mechanism will have the framing shown below: 
+    
+         GSS-API DEFINITIONS ::= 
+    
+         BEGIN 
+    
+         MechType ::= OBJECT IDENTIFIER 
+         -- representing Kerberos V5 mechanism 
+    
+         GSSAPI-Token ::= 
+         -- option indication (delegation, etc.) indicated within 
+         -- mechanism-specific token 
+         [APPLICATION 0] IMPLICIT SEQUENCE { 
+                 thisMech MechType, 
+                 innerToken ANY DEFINED BY thisMech 
+                    -- contents mechanism-specific 
+                    -- ASN.1 structure not required 
+                 } 
+    
+         END 
+    
+   Where the notation and encoding of this pseudo ASN.1 header, which 
+   is referred as the generic GSS-API token framing later in this 
+   document, are described in [RFC-2743], and the innerToken field 
+   starts with a two-octet token-identifier (TOK_ID) expressed in big 
+   endian order, followed by a Kerberos message.   
+    
+   Here are the TOK_ID values used in the context establishment tokens: 
+    
+         Token               TOK_ID Value in Hex  
+        ----------------------------------------- 
+         KRB_AP_REQUEST        01 00 
+         KRB_AP_REPLY          02 00 
+         KRB_ERROR             03 00 
+             
+   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
+   are defined in [KRBCLAR].   
+    
+   If an unknown token identifier (TOK_ID) is received in the initial 
+   context estalishment token, the receiver MUST return 
+   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
+   MUST contain a KRB_ERROR message with the error code 
+   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
+    
+4.1.1. Authenticator Checksum 
+ 
+
+Zhu                         Internet Draft                           4 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   The authenticator in the KRB_AP_REQ message MUST include the 
+   optional sequence number and the checksum field.  The checksum field 
+   is used to convey service flags, channel bindings, and optional 
+   delegation information.  The checksum type MUST be 0x8003.  The 
+   length of the checksum MUST be 24 octets when delegation is not 
+   used.  When delegation is used, a ticket-granting ticket will be 
+   transferred in a KRB_CRED message.  This ticket SHOULD have its 
+   forwardable flag set.  The KRB_CRED message MUST be encrypted in the 
+   session key of the ticket used to authenticate the context. 
+    
+   The format of the authenticator checksum field is as follows. 
+       
+      Octet    Name      Description 
+     ----------------------------------------------------------------- 
+      0..3    Lgth    Number of octets in Bnd field;  Currently  
+                      contains hex value 10 00 00 00 (16, represented  
+                      in little-endian order) 
+      4..19   Bnd     Channel binding information, as described in  
+                      section 4.1.1.2. 
+      20..23  Flags   Four-octet context-establishment flags in little- 
+                      endian order as described in section 4.1.1.1.  
+      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
+      26..27  Dlgth   The length of the Deleg field [optional] 
+      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
+ 
+4.1.1.1. Checksum Flags Field 
+    
+   The checksum "Flags" field is used to convey service options or 
+   extension negotiation information.  The following context 
+   establishment flags are defined in [RFC-2744]. 
+    
+        Flag Name              Value     
+      --------------------------------- 
+       GSS_C_DELEG_FLAG           1        
+       GSS_C_MUTUAL_FLAG          2       
+       GSS_C_REPLAY_FLAG          4       
+       GSS_C_SEQUENCE_FLAG        8        
+       GSS_C_CONF_FLAG           16      
+       GSS_C_INTEG_FLAG          32     
+        
+   Context establishment flags are exposed to the calling application.  
+   If the calling application desires a particular service option then 
+   it requests that option via GSS_Init_sec_context() [RFC-2743].  An 
+   implementation that supports a particular option or extension SHOULD 
+   then set the appropriate flag in the checksum Flags field.   
+    
+   The most significant eight bits of the checksum flags are reserved 
+   for future use.  The receiver MUST ignore unknown checksum flags. 
+    
+4.1.1.2. Channel Binding Information 
+ 
+   Channel bindings are user-specified tags to identify a given context 
+   to the peer application.  These tags are intended to be used to 
+
+
+Zhu                         Internet Draft                           5 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   identify the particular communications channel that carries the 
+   context [RFC-2743] [RFC-2744]. 
+    
+   When using C language bindings, channel bindings are communicated to 
+   the GSS-API using the following structure [RFC-2744]: 
+ 
+      typedef struct gss_channel_bindings_struct { 
+         OM_uint32       initiator_addrtype; 
+         gss_buffer_desc initiator_address; 
+         OM_uint32       acceptor_addrtype; 
+         gss_buffer_desc acceptor_address; 
+         gss_buffer_desc application_data; 
+      } *gss_channel_bindings_t; 
+    
+   The member fields and constants used for different address types are 
+   defined in [RFC-2744]. 
+    
+   The "Bnd" field contains the MD5 hash of channel bindings, taken 
+   over all non-null components of bindings, in order of declaration.  
+   Integer fields within channel bindings are represented in little-
+   endian order for the purposes of the MD5 calculation. 
+    
+   In computing the contents of the Bnd field, the following detailed 
+   points apply:  
+    
+   (1) Each integer field shall be formatted into four octets, using 
+   little endian octet ordering, for purposes of MD5 hash computation.  
+    
+   (2) All input length fields within gss_buffer_desc elements of a 
+   gss_channel_bindings_struct even those which are zero-valued, shall 
+   be included in the hash calculation; the value elements of 
+   gss_buffer_desc elements shall be dereferenced, and the resulting 
+   data shall be included within the hash computation, only for the 
+   case of gss_buffer_desc elements having non-zero length specifiers.  
+    
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
+   valid channel binding structure, the Bnd field shall be set to 16 
+   zero-valued octets.  
+ 
+4.2. Per-Message Tokens 
+    
+   Two classes of tokens are defined in this section:  "MIC" tokens, 
+   emitted by calls to GSS_GetMIC() and consumed by calls to 
+   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
+   consumed by calls to GSS_Unwrap(). 
+    
+   The new per-message tokens introduced here do not include the 
+   generic GSS-API token framing used by the context establishment 
+   tokens.  These new tokens are designed to be used with newer crypto 
+   systems that can, for example, have variable-size checksums.   
+    
+4.2.1. Sequence Number 
+ 
+
+Zhu                         Internet Draft                           6 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   To distinguish intentionally-repeated messages from maliciously-
+   replayed ones, per-message tokens contain a sequence number field, 
+   which is a 64 bit integer expressed in big endian order.  After 
+   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
+   numbers are incremented by one. 
+ 
+4.2.2. Flags Field 
+ 
+   The "Flags" field is a one-octet integer used to indicate a set of 
+   attributes for the protected message.  For example, one flag is 
+   allocated as the direction-indicator, thus preventing an adversary 
+   from sending back the same message in the reverse direction and 
+   having it accepted.   
+    
+   The meanings of bits in this field (the least significant bit is bit 
+   0) are as follows: 
+    
+        Bit    Name             Description 
+       --------------------------------------------------------------- 
+        0   SentByAcceptor    When set, this flag indicates the sender  
+                              is the context acceptor.  When not set, 
+                              it indicates the sender is the context  
+                              initiator. 
+        1   Sealed            When set in Wrap tokens, this flag  
+                              indicates confidentiality is provided  
+                              for.  It SHALL NOT be set in MIC tokens. 
+        2   AcceptorSubkey    A subkey asserted by the context acceptor 
+                              is used to protect the message. 
+    
+   The rest of available bits are reserved for future use and MUST be 
+   cleared.  The receiver MUST ignore unknown flags. 
+    
+4.2.3. EC Field 
+ 
+   The "EC" (Extra Count) field is a two-octet integer field expressed 
+   in big endian order.   
+    
+   In Wrap tokens with confidentiality, the EC field is used to encode 
+   the number of octets in the filler, as described in section 4.2.4. 
+    
+   In Wrap tokens without confidentiality, the EC field is used to 
+   encode the number of octets in the trailing checksum, as described 
+   in section 4.2.4.   
+ 
+4.2.4. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection [KCRYPTO].  Therefore no separate checksum is 
+   needed.  
+    
+   The result of decryption can be longer than the original plaintext 
+   [KCRYPTO] and the extra trailing octets are called "crypto-system 
+   garbage".  However, given the size of any plaintext data, one can 
+   always find the next (possibly larger) size so that, when padding 
+
+
+Zhu                         Internet Draft                           7 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   the to-be-encrypted text to that size, there will be no crypto-
+   system garbage added [KCRYPTO].  
+ 
+   In Wrap tokens that provide for confidentiality, the first 16 octets 
+   of the Wrap token (the "header", as defined in section 4.2.6), are 
+   appended to the plaintext data before encryption.  Filler octets can 
+   be inserted between the plaintext data and the "header", and the 
+   values and size of the filler octets are chosen by implementations, 
+   such that there is no crypto-system garbage present after the 
+   decryption.  The resulting Wrap token is {"header" | 
+   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
+   encryption operation (which provides for integrity protection) 
+   defined in the crypto profile [KCRYPTO], and the RRC field in the 
+   to-be-encrypted header contains the hex value 00 00.   
+           
+   In Wrap tokens that do not provide for confidentiality, the checksum 
+   is calculated first over the to-be-signed plaintext data, and then 
+   the first 16 octets of the Wrap token (the "header", as defined in 
+   section 4.2.6).  Both the EC field and the RRC field in the token 
+   header are filled with zeroes for the purpose of calculating the 
+   checksum.  The resulting Wrap token is {"header" | plaintext-data | 
+   get_mic(plaintext-data | "header")},  where get_mic() is the 
+   checksum operation for the required checksum mechanism of the chosen 
+   encryption mechanism defined in the crypto profile [KCRYPTO].  
+    
+   The parameters for the key and the cipher-state in the encrypt() and 
+   get_mic() operations have been omitted for brevity.   
+        
+   For MIC tokens, the checksum is first calculated over the to-be-
+   signed plaintext data, and then the first 16 octets of the MIC 
+   token, where the checksum mechanism is the required checksum 
+   mechanism of the chosen encryption mechanism defined in the crypto 
+   profile [KCRYPTO]. 
+   
+   The resulting Wrap and MIC tokens bind the data to the token header, 
+   including the sequence number and the direction indicator.  
+   
+4.2.5. RRC Field 
+ 
+   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
+   allow the data to be encrypted in-place by existing [SSPI] 
+   applications that do not provide an additional buffer for the 
+   trailer (the cipher text after the in-place-encrypted data) in 
+   addition to the buffer for the header (the cipher text before the 
+   in-place-encrypted data).  The resulting Wrap token in the previous 
+   section, excluding the first 16 octets of the token header, is 
+   rotated to the right by "RRC" octets.  The net result is that "RRC" 
+   octets of trailing octets are moved toward the header.  Consider the 
+   following as an example of this rotation operation:  Assume that the 
+   RRC value is 3 and the token before the rotation is {"header" | aa | 
+   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
+   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
+   | cc |...| hh} is used to indicate the octet sequence. 
+  
+
+Zhu                         Internet Draft                           8 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   The RRC field is expressed as a two-octet integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values. 
+ 
+4.2.6. Message Layouts 
+    
+   Per-message tokens start with a two-octet token identifier (TOK_ID) 
+   field, expressed in big endian order.  These tokens are defined 
+   separately in subsequent sub-sections. 
+    
+4.2.6.1. MIC Tokens 
+    
+   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 as received.  The token has the following format: 
+    
+      Octet no     Name       Description 
+      ----------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_GetMIC() contain the hex value 04 04  
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3..7     Filler     Contains five octets of hex value FF. 
+       8..15    SND_SEQ    Sequence number field in clear text,  
+                           expressed in big endian order.  
+       16..last SGN_CKSUM  Checksum of octet 0..15 and the "to-be- 
+                           signed" data, as described in section 4.2.4. 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.   
+    
+4.2.6.2. Wrap Tokens 
+    
+   Use of the GSS_Wrap() call yields a token, which consists of a 
+   descriptive header, followed by a body portion that contains either 
+   the input user data in plaintext concatenated with the checksum, or 
+   the input user data encrypted.  The GSS_Wrap() token has the 
+   following format: 
+    
+      Octet no     Name       Description 
+      --------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_Wrap() contain the the hex value 05 04                 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3        Filler     Contains the hex value FF. 
+       4..5     EC         Contains the "extra count" field, in big  
+                           endian order as described in section 4.2.3. 
+       6..7     RRC        Contains the "right rotation count" in big  
+
+
+Zhu                         Internet Draft                           9 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+                           endian order, as described in section 4.2.5. 
+       8..15    SND_SEQ    Sequence number field in clear text, 
+                           expressed in big endian order. 
+       16..last Data       Encrypted data for Wrap tokens with  
+                           confidentiality, or plaintext data followed  
+                           by the checksum for Wrap tokens without  
+                           confidentiality, as described in section  
+                           4.2.4.         
+             
+4.3. Context Deletion Tokens 
+ 
+   Context deletion tokens are empty in this mechanism.  Both peers to 
+   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
+   independently, passing a null output_context_token buffer to 
+   indicate that no context_token is required.  Implementations of 
+   GSS_Delete_sec_context() should delete relevant locally-stored 
+   context information. 
+        
+4.4. Token Identifier Assignment Considerations 
+    
+   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
+   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
+   the first two octets of a token, one can tell unambiguously if it is 
+   wrapped with the generic GSS-API token framing.   
+    
+5. Parameter Definitions 
+    
+   This section defines parameter values used by the Kerberos V5 GSS-
+   API mechanism.  It defines interface elements in support of 
+   portability, and assumes use of C language bindings per [RFC-2744]. 
+    
+5.1. Minor Status Codes 
+ 
+   This section recommends common symbolic names for minor_status 
+   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
+   these definitions will enable independent implementers 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 GSS-API 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.  
+    
+5.1.1. Non-Kerberos-specific codes 
+
+
+Zhu                         Internet Draft                          10 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+ 
+      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" */ 
+    
+5.1.2. Kerberos-specific-codes 
+    
+      GSS_KRB5_S_KG_CCACHE_NOMATCH  
+              /* "Client principal in credentials does not match   
+                 specified name" */ 
+      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
+              /* "No key available for specified service principal" */ 
+      GSS_KRB5_S_KG_TGT_MISSING 
+              /* "No Kerberos ticket-granting ticket available" */ 
+      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" */ 
+ 
+5.2. Buffer Sizes 
+ 
+   All implementations of this specification shall be capable of 
+   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
+   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
+   the output_token generated by GSS_Wrap() for a 16K octet input 
+   buffer as input to GSS_Unwrap().  Support for larger buffer sizes is 
+   optional but recommended. 
+ 
+6. Backwards Compatibility Considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  To address this, implementations 
+   can always use the explicit sign or seal algorithm in [RFC-1964] 
+
+
+Zhu                         Internet Draft                          11 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+   when the key type corresponds to "older" enctypes.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [RFC-1964].  However this would 
+   require either the use of a mechanism such as [RFC-2478] to securely 
+   negotiate the method or the use out of band mechanism to choose 
+   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
+   new token formats defined in this document SHOULD be used only if 
+   both peers are known to support the new mechanism during context 
+   negotiation because of, for example, the use of "new" enctypes. 
+ 
+   GSS_Unwrap() or GSS_Verify_MIC() can process a message token as 
+   follows: it can look at the first octet of the token header, if it 
+   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
+   framing, otherwise the first two octets of the token contain the 
+   TOK_ID that uniquely identify the token message format. 
+    
+7. Security Considerations 
+    
+   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 given the task of 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 (for example) AES [AES-KRB5] but the Kerberos 
+   implementation does.  It means that AES session keys cannot be 
+   issued for that service principal, which keeps the protection of 
+   non-GSSAPI services weaker than necessary.  KDC administrators 
+   desiring to limit the session key types to support interoperability 
+   with such GSSAPI implementations should carefully weigh the 
+   reduction in protection offered by such mechanisms against the 
+   benefits of interoperability. 
+    
+8. Acknowledgments 
+ 
+  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of this 
+  memo.  
+   
+  The text for security considerations was contributed by Ken Raeburn. 
+   
+  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
+  namely the encoding of the RRC field.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+
+
+Zhu                         Internet Draft                          12 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments.  
+   
+  Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 
+  valuable inputs on this memo. 
+   
+  Jeffrey Hutzelman provided comments on channel bindings and suggested 
+  many editorial changes. 
+ 
+  Luke Howard provided implementations of this memo for the Heimdal 
+  code base, and helped inter-operability testing with the Microsoft 
+  code base, together with Love Hornquist Astrand.  These experiments 
+  formed the basis of this memo. 
+   
+  Martin Rex provided suggestions of TOK_ID assignment recommendations 
+  thus the token tagging in this memo is unambiguous if the token is 
+  wrapped with the pseudo ASN.1 header.  
+   
+  This document retains some of the text of RFC-1964 in relevant 
+  sections. 
+   
+9. References 
+    
+9.1. Normative References 
+    
+   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
+   3", BCP 9, RFC 2026, October 1996.  
+        
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
+   Requirement Levels", BCP 14, RFC 2119, March 1997. 
+    
+   [RFC-2743] Linn, J., "Generic Security Service Application Program    
+   Interface Version 2, Update 1", RFC 2743, January 2000. 
+    
+   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
+   bindings", RFC 2744, January 2000. 
+    
+   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
+   RFC 1964, June 1996. 
+    
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
+   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
+   progress.  
+    
+   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
+   Raeburn, K., "The Kerberos Network Authentication Service (V5)",    
+   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
+   Work in progress. 
+    
+   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
+   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress. 
+
+ 
+Zhu                         Internet Draft                          13 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+    
+   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism", RFC 2478, December 1998. 
+ 
+9.2. Informative References 
+ 
+   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
+   Developer Network (MSDN), April 2003. 
+    
+10. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: karthikj@microsoft.com 
+ 
+   Sam Hartman 
+   Massachusetts Institute of Technology 
+   77 Massachusetts Avenue 
+   Cambridge, MA 02139 - USA 
+   Email: hartmans@MIT.EDU 
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Internet Draft                          14 
+                 Kerberos Version 5 GSS-API      November 2003 
+ 
+ 
+    
+Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (date). 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Internet Draft                          15 
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt
new file mode 100644
index 00000000000..92c66589602
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt
@@ -0,0 +1,988 @@
+
+ 
+
+<Network Working Group>                                       Larry Zhu 
+Internet Draft                                       Karthik Jaganathan 
+Updates: 1964                                                 Microsoft 
+Category: Standards Track                                   Sam Hartman 
+draft-ietf-krb-wg-gssapi-cfx-06.txt                                 MIT 
+                                                      February 16, 2004 
+                                               Expires: August 16, 2004 
+ 
+          The Kerberos Version 5 GSS-API 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 [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-krb-wg-gssapi-cfx-06.txt, and expires on August 10 
+   2004.  Please send comments to: ietf-krb-wg@anl.gov. 
+    
+Abstract 
+    
+   This document defines protocols, procedures, and conventions to be 
+   employed by peers implementing the Generic Security Service 
+   Application Program Interface (GSS-API) when using the Kerberos 
+   Version 5 mechanism. 
+    
+   RFC-1964 is updated and incremental changes are proposed in response 
+   to recent developments such as the introduction of Kerberos 
+   cryptosystem framework.  These changes support the inclusion of new 
+   cryptosystems, by defining new per-message tokens along with their 
+   encryption and checksum algorithms based on the cryptosystem 
+   profiles.   
+    
+Conventions used in this document 
+  
+Zhu                                                                   1 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+    
+   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]. 
+    
+   The term "little endian order" is used for brevity to refer to the 
+   least-significant-octet-first encoding, while the term "big endian 
+   order" is for the most-significant-octet-first encoding. 
+    
+Table of Contents 
+
+   1. Introduction ...............................................  2 
+   2. Key Derivation for Per-Message Tokens ......................  3 
+   3. Quality of Protection ......................................  4 
+   4. Definitions and Token Formats ..............................  4 
+   4.1. Context Establishment Tokens .............................  4 
+   4.1.1. Authenticator Checksum .................................  5 
+   4.2. Per-Message Tokens .......................................  8 
+   4.2.1. Sequence Number ........................................  8 
+   4.2.2. Flags Field ............................................  8 
+   4.2.3. EC Field ...............................................  9 
+   4.2.4. Encryption and Checksum Operations .....................  9 
+   4.2.5. RRC Field .............................................. 10 
+   4.2.6. Message Layouts ........................................ 10 
+   4.3. Context Deletion Tokens .................................. 11 
+   4.4. Token Identifier Assignment Considerations ............... 11 
+   5. Parameter Definitions ...................................... 12 
+   5.1. Minor Status Codes ....................................... 12 
+   5.1.1. Non-Kerberos-specific codes ............................ 12 
+   5.1.2. Kerberos-specific-codes ................................ 12 
+   5.2. Buffer Sizes ............................................. 13 
+   6. Backwards Compatibility Considerations ..................... 13 
+   7. Security Considerations .................................... 13 
+   8. Acknowledgments ............................................ 14 
+   9. Intellectual Property Statement ............................ 15
+   10. References ................................................ 15 
+   10.1. Normative References .................................... 15 
+   10.2. Informative References .................................. 15 
+   11. Author's Address .......................................... 15
+   Full Copyright Statement ...................................... 17  
+   
+1. Introduction 
+    
+   [KCRYPTO] defines a generic framework for describing encryption and 
+   checksum types to be used with the Kerberos protocol and associated 
+   protocols. 
+    
+   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
+   It defines the format of context establishment, per-message and 
+   context deletion tokens and uses algorithm identifiers for each 
+   cryptosystem in per message and context deletion tokens.   
+    
+   The approach taken in this document obviates the need for algorithm 
+   identifiers.  This is accomplished by using the same encryption 
+   algorithm, specified by the crypto profile [KCRYPTO] for the session 
+   key or subkey that is created during context negotiation, and its 
+   required checksum algorithm.  Message layouts of the per-message 
+Zhu                                                                  2 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+   tokens are therefore revised to remove algorithm indicators and also 
+   to add extra information to support the generic crypto framework 
+   [KCRYPTO].  
+    
+   Tokens transferred between GSS-API peers for security context 
+   establishment are also described in this document.  The data 
+   elements exchanged between a GSS-API endpoint implementation and the 
+   Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to 
+   GSS-API usage and are therefore defined within [KRBCLAR] rather than 
+   within this specification. 
+    
+   The new token formats specified in this document MUST be used with 
+   all "newer" encryption types [KRBCLAR] and MAY be used with "older" 
+   encryption types, provided that the initiator and acceptor know, 
+   from the context establishment, that they can both process these new 
+   token formats. 
+    
+   "Newer" encryption types are those which have been specified along 
+   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
+   as defined in section 3.1.3 of [KRBCLAR].  The list of not-newer 
+   encryption types is as follows [KCRYPTO]: 
+    
+             Encryption Type             Assigned Number     
+           ---------------------------------------------- 
+            des-cbc-crc                        1              
+            des-cbc-md4                        2              
+            des-cbc-md5                        3              
+            des3-cbc-md5                       5 
+            des3-cbc-sha1                      7 
+            dsaWithSHA1-CmsOID                 9            
+            md5WithRSAEncryption-CmsOID       10            
+            sha1WithRSAEncryption-CmsOID      11           
+            rc2CBC-EnvOID                     12            
+            rsaEncryption-EnvOID              13    
+            rsaES-OAEP-ENV-OID                14    
+            des-ede3-cbc-Env-OID              15            
+            des3-cbc-sha1-kd                  16                       
+            rc4-hmac                          23          
+    
+2. Key Derivation for Per-Message Tokens 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.   
+    
+   This document defines four key usage values below that are used to 
+   derive a specific key for signing and sealing messages, from the 
+   session key or subkey [KRBCLAR] created during the context 
+   establishment. 
+    
+        Name                         Value 
+      ------------------------------------- 
+       KG-USAGE-ACCEPTOR-SEAL         22 
+       KG-USAGE-ACCEPTOR-SIGN         23 
+       KG-USAGE-INITIATOR-SEAL        24 
+
+Zhu                                                                  3 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+       KG-USAGE-INITIATOR-SIGN        25 
+          
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC tokens (as defined in section 4.2.6.1), and 
+   KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section 
+   4.2.6.2); similarly when the sender is the context initiator, KG-
+   USAGE-INITIATOR-SIGN is used as the usage number in the key 
+   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
+   for Wrap Tokens.  Even if the Wrap token does not provide for 
+   confidentiality the same usage values specified above are used. 
+    
+   During the context initiation and acceptance sequence, the acceptor 
+   MAY assert a subkey, and if so, subsequent messages MUST use this 
+   subkey as the protocol key and these messages MUST be flagged as 
+   "AcceptorSubkey" as described in section 4.2.2. 
+ 
+3. Quality of Protection 
+ 
+   The GSS-API specification [RFC-2743] provides for Quality of 
+   Protection (QOP) values that can be used by applications to request 
+   a certain type of encryption or signing.  A zero QOP value is used 
+   to indicate the "default" protection; applications which do not use 
+   the default QOP are not guaranteed to be portable across 
+   implementations or even inter-operate with different deployment 
+   configurations of the same implementation.  Using an algorithm that 
+   is different from the one for which the key is defined may not be 
+   appropriate.  Therefore, when the new method in this document is 
+   used, the QOP value is ignored. 
+    
+   The encryption and checksum algorithms in per-message tokens are now 
+   implicitly defined by the algorithms associated with the session key 
+   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
+   therefore no longer needed and removed from the new token headers. 
+ 
+4. Definitions and Token Formats 
+    
+   This section provides terms and definitions, as well as descriptions 
+   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
+                                    
+4.1. Context Establishment Tokens 
+    
+   All context establishment tokens emitted by the Kerberos Version 5 
+   GSS-API mechanism SHALL have the framing described in section 3.1 of 
+   [RFC-2743], as illustrated by the following pseudo-ASN.1 structures: 
+    
+         GSS-API DEFINITIONS ::= 
+    
+         BEGIN 
+    
+         MechType ::= OBJECT IDENTIFIER 
+         -- representing Kerberos V5 mechanism 
+    
+         GSSAPI-Token ::= 
+         -- option indication (delegation, etc.) indicated within 
+Zhu                                                                  4 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+         -- mechanism-specific token 
+         [APPLICATION 0] IMPLICIT SEQUENCE { 
+                 thisMech MechType, 
+                 innerToken ANY DEFINED BY thisMech 
+                    -- contents mechanism-specific 
+                    -- ASN.1 structure not required 
+                 } 
+    
+         END 
+    
+   Where the innerToken field starts with a two-octet token-identifier 
+   (TOK_ID) expressed in big endian order, followed by a Kerberos 
+   message.   
+    
+   Here are the TOK_ID values used in the context establishment tokens: 
+    
+         Token               TOK_ID Value in Hex  
+        ----------------------------------------- 
+         KRB_AP_REQ            01 00 
+         KRB_AP_REP            02 00 
+         KRB_ERROR             03 00 
+             
+   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
+   are defined in [KRBCLAR].   
+    
+   If an unknown token identifier (TOK_ID) is received in the initial 
+   context establishment token, the receiver MUST return 
+   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
+   MUST contain a KRB_ERROR message with the error code 
+   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
+    
+4.1.1. Authenticator Checksum 
+ 
+   The authenticator in the KRB_AP_REQ message MUST include the 
+   optional sequence number and the checksum field.  The checksum field 
+   is used to convey service flags, channel bindings, and optional 
+   delegation information.   
+    
+   The checksum type MUST be 0x8003. When delegation is used, a ticket-
+   granting ticket will be transferred in a KRB_CRED message.  This 
+   ticket SHOULD have its forwardable flag set.  The EncryptedData 
+   field of the KRB_CRED message [KRBCLAR] MUST be encrypted in the 
+   session key of the ticket used to authenticate the context. 
+    
+   The authenticator checksum field SHALL have the following format: 
+       
+      Octet        Name      Description 
+     ----------------------------------------------------------------- 
+      0..3         Lgth    Number of octets in Bnd field;  Represented  
+                           in little-endian order;  Currently contains   
+                           hex value 10 00 00 00 (16). 
+      4..19        Bnd     Channel binding information, as described in  
+                           section 4.1.1.2. 
+      20..23       Flags   Four-octet context-establishment flags in 
+                           little-endian order as described in section  
+Zhu                                                                  5 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+                           4.1.1.1.  
+      24..25       DlgOpt  The delegation option identifier (=1) in  
+                           little-endian order [optional].  This field  
+                           and the next two fields are present if and  
+                           only if GSS_C_DELEG_FLAG is set as described  
+                           in section 4.1.1.1.   
+      26..27       Dlgth   The length of the Deleg field in little- 
+                           endian order [optional]. 
+      28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)  
+                           [optional].  
+      n..last      Exts    Extensions [optional]. 
+    
+   The length of the checksum field MUST be at least 24 octets when 
+   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and 
+   at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  
+   When GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and Deleg fields 
+   of the checksum data MUST immediately follow the Flags field.  The 
+   optional trailing octets (namely the "Exts" field) facilitate 
+   future extensions to this mechanism.  When delegation is not used 
+   but the Exts field is present, the Exts field starts at octet 24 
+   (DlgOpt, Dlgth and Deleg are absent). 
+    
+   Initiators that do not support the extensions MUST NOT include more 
+   than 24 octets in the checksum field, when GSS_C_DELEG_FLAG is not 
+   set, or more than 28 octets plus the KRB_CRED in the Deleg field, 
+   when GSS_C_DELEG_FLAG is set.  Acceptors that do not understand the 
+   extensions MUST ignore any octets past the Deleg field of the 
+   checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field 
+   of the checksum data, when GSS_C_DELEG_FLAG is not set. 
+ 
+4.1.1.1. Checksum Flags Field 
+    
+   The checksum "Flags" field is used to convey service options or 
+   extension negotiation information. 
+    
+   The following context establishment flags are defined in [RFC-2744].   
+    
+        Flag Name              Value     
+      --------------------------------- 
+       GSS_C_DELEG_FLAG           1        
+       GSS_C_MUTUAL_FLAG          2       
+       GSS_C_REPLAY_FLAG          4       
+       GSS_C_SEQUENCE_FLAG        8        
+       GSS_C_CONF_FLAG           16      
+       GSS_C_INTEG_FLAG          32     
+        
+   Context establishment flags are exposed to the calling application.  
+   If the calling application desires a particular service option then 
+   it requests that option via GSS_Init_sec_context() [RFC-2743].  If 
+   the corresponding return state values [RFC-2743] indicate that any 
+   of above optional context level services will be active on the 
+   context, the corresponding flag values in the table above MUST be 
+   set in the checksum Flags field. 
+    
+
+Zhu                                                                  6 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for 
+   use with legacy vendor-specific extensions to this mechanism. 
+    
+   All other flag values not specified herein are reserved for future 
+   use.  Future revisions of this mechanism may use these reserved 
+   flags and may rely on implementations of this version to not use 
+   such flags in order to properly negotiate mechanism versions.  
+   Undefined flag values MUST be cleared by the sender, and unknown 
+   flags MUST be ignored by the receiver.   
+    
+4.1.1.2. Channel Binding Information 
+    
+   These tags are intended to be used to identify the particular 
+   communications channel for which the GSS-API security context 
+   establishment tokens are intended, thus limiting the scope within 
+   which an intercepted context establishment token can be reused by an 
+   attacker (see [RFC-2743], section 1.1.6). 
+    
+   When using C language bindings, channel bindings are communicated 
+   to the GSS-API using the following structure [RFC-2744]: 
+ 
+      typedef struct gss_channel_bindings_struct { 
+         OM_uint32       initiator_addrtype; 
+         gss_buffer_desc initiator_address; 
+         OM_uint32       acceptor_addrtype; 
+         gss_buffer_desc acceptor_address; 
+         gss_buffer_desc application_data; 
+      } *gss_channel_bindings_t; 
+    
+   The member fields and constants used for different address types 
+   are defined in [RFC-2744]. 
+    
+   The "Bnd" field contains the MD5 hash of channel bindings, taken 
+   over all non-null components of bindings, in order of declaration.  
+   Integer fields within channel bindings are represented in little-
+   endian order for the purposes of the MD5 calculation. 
+    
+   In computing the contents of the Bnd field, the following detailed 
+   points apply:  
+    
+   (1) For purposes of MD5 hash computation, each integer field and 
+   input length field SHALL be formatted into four octets, using 
+   little endian octet ordering.  
+    
+   (2) All input length fields within gss_buffer_desc elements of a 
+   gss_channel_bindings_struct even those which are zero-valued, SHALL 
+   be included in the hash calculation; the value elements of 
+   gss_buffer_desc elements SHALL be dereferenced, and the resulting 
+   data SHALL be included within the hash computation, only for the 
+   case of gss_buffer_desc elements having non-zero length specifiers.  
+    
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
+   valid channel binding structure, the Bnd field SHALL be set to 16 
+   zero-valued octets.  
+ 
+Zhu                                                                  7 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+   If the caller to GSS_Accept_sec_context [RFC-2743] passes in 
+   GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then 
+   the acceptor MAY ignore any channel bindings supplied by the 
+   initiator, returning success even if the initiator did pass in 
+   channel bindings. 
+    
+   If the application supply, in the channel bindings, a buffer with a 
+   length field larger than 4294967295 (2^32 - 1), the implementation 
+   of this mechanism MAY chose to reject the channel bindings 
+   altogether, using major status GSS_S_BAD_BINDINGS [RFC-2743].  In 
+   any case, the size of channel binding data buffers that can be used 
+   (interoperable, without extensions) with this specification is 
+   limited to 4294967295 octets. 
+    
+4.2. Per-Message Tokens 
+    
+   Two classes of tokens are defined in this section:  "MIC" tokens, 
+   emitted by calls to GSS_GetMIC() and consumed by calls to 
+   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
+   consumed by calls to GSS_Unwrap(). 
+    
+   The new per-message tokens introduced here do not include the 
+   generic GSS-API token framing used by the context establishment 
+   tokens.  These new tokens are designed to be used with newer crypto 
+   systems that can, for example, have variable-size checksums.   
+    
+4.2.1. Sequence Number 
+ 
+   To distinguish intentionally-repeated messages from maliciously-
+   replayed ones, per-message tokens contain a sequence number field, 
+   which is a 64 bit integer expressed in big endian order.  After 
+   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
+   numbers SHALL be incremented by one. 
+ 
+4.2.2. Flags Field 
+ 
+   The "Flags" field is a one-octet integer used to indicate a set of 
+   attributes for the protected message.  For example, one flag is 
+   allocated as the direction-indicator, thus preventing an adversary 
+   from sending back the same message in the reverse direction and 
+   having it accepted.   
+    
+   The meanings of bits in this field (the least significant bit is 
+   bit 0) are as follows: 
+    
+        Bit    Name             Description 
+       --------------------------------------------------------------- 
+        0   SentByAcceptor    When set, this flag indicates the sender  
+                              is the context acceptor.  When not set, 
+                              it indicates the sender is the context  
+                              initiator. 
+        1   Sealed            When set in Wrap tokens, this flag  
+                              indicates confidentiality is provided  
+                              for.  It SHALL NOT be set in MIC tokens. 
+        2   AcceptorSubkey    A subkey asserted by the context acceptor 
+Zhu                                                                  8 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+                              is used to protect the message. 
+    
+   The rest of available bits are reserved for future use and MUST be 
+   cleared.  The receiver MUST ignore unknown flags. 
+    
+4.2.3. EC Field 
+ 
+   The "EC" (Extra Count) field is a two-octet integer field expressed 
+   in big endian order.   
+    
+   In Wrap tokens with confidentiality, the EC field SHALL be used to 
+   encode the number of octets in the filler, as described in section 
+   4.2.4. 
+    
+   In Wrap tokens without confidentiality, the EC field SHALL be used 
+   to encode the number of octets in the trailing checksum, as 
+   described in section 4.2.4.   
+ 
+4.2.4. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection [KCRYPTO].  Therefore no separate checksum is 
+   needed.  
+    
+   The result of decryption can be longer than the original plaintext 
+   [KCRYPTO] and the extra trailing octets are called "crypto-system 
+   garbage" in this document.  However, given the size of any plaintext 
+   data, one can always find a (possibly larger) size so that, when 
+   padding the to-be-encrypted text to that size, there will be no 
+   crypto-system garbage added [KCRYPTO].  
+ 
+   In Wrap tokens that provide for confidentiality, the first 16 octets 
+   of the Wrap token (the "header", as defined in section 4.2.6), SHALL 
+   be appended to the plaintext data before encryption.  Filler octets 
+   MAY be inserted between the plaintext data and the "header", and the 
+   values and size of the filler octets are chosen by implementations, 
+   such that there SHALL be no crypto-system garbage present after the 
+   decryption.  The resulting Wrap token is {"header" | 
+   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
+   encryption operation (which provides for integrity protection) 
+   defined in the crypto profile [KCRYPTO], and the RRC field (as 
+   defined in section 4.2.5) in the to-be-encrypted header contain the 
+   hex value 00 00.   
+           
+   In Wrap tokens that do not provide for confidentiality, the checksum 
+   SHALL be calculated first over the to-be-signed plaintext data, and 
+   then the first 16 octets of the Wrap token (the "header", as defined 
+   in section 4.2.6).  Both the EC field and the RRC field in the token 
+   header SHALL be filled with zeroes for the purpose of calculating 
+   the checksum.  The resulting Wrap token is {"header" | plaintext-
+   data | get_mic(plaintext-data | "header")},  where get_mic() is the 
+   checksum operation for the required checksum mechanism of the chosen 
+   encryption mechanism defined in the crypto profile [KCRYPTO].  
+    
+
+Zhu                                                                  9 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+   The parameters for the key and the cipher-state in the encrypt() and 
+   get_mic() operations have been omitted for brevity.   
+        
+   For MIC tokens, the checksum SHALL be calculated as follows: the 
+   checksum operation is calculated first over the to-be-signed 
+   plaintext data, and then the first 16 octets of the MIC token, where 
+   the checksum mechanism is the required checksum mechanism of the 
+   chosen encryption mechanism defined in the crypto profile [KCRYPTO]. 
+   
+   The resulting Wrap and MIC tokens bind the data to the token header, 
+   including the sequence number and the direction indicator.  
+   
+4.2.5. RRC Field 
+ 
+   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
+   allow the data to be encrypted in-place by existing SSPI (Security 
+   Service Provider Interface) [SSPI] applications that do not provide 
+   an additional buffer for the trailer (the cipher text after the in-
+   place-encrypted data) in addition to the buffer for the header (the 
+   cipher text before the in-place-encrypted data).  The resulting Wrap 
+   token in the previous section, excluding the first 16 octets of the 
+   token header, is rotated to the right by "RRC" octets.  The net 
+   result is that "RRC" octets of trailing octets are moved toward the 
+   header.  Consider the following as an example of this rotation 
+   operation:  Assume that the RRC value is 3 and the token before the 
+   rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the 
+   token after rotation would be {"header" | ff | gg | hh | aa | bb | 
+   cc | dd | ee }, where {aa | bb | cc |...| hh} is used to indicate 
+   the octet sequence. 
+  
+   The RRC field is expressed as a two-octet integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values, including rotation counts 
+   greater than the length of the token. 
+ 
+4.2.6. Message Layouts 
+    
+   Per-message tokens start with a two-octet token identifier (TOK_ID) 
+   field, expressed in big endian order.  These tokens are defined 
+   separately in subsequent sub-sections. 
+    
+4.2.6.1. MIC Tokens 
+    
+   Use of the GSS_GetMIC() call yields a token (referred as the MIC 
+   token in this document), separate from the user  
+   data being protected, which can be used to verify the integrity of  
+   that data as received.  The token has the following format: 
+    
+      Octet no   Name        Description 
+      ----------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_GetMIC() contain the hex value 04 04  
+Zhu                                                                 10 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3..7     Filler     Contains five octets of hex value FF. 
+       8..15    SND_SEQ    Sequence number field in clear text,  
+                           expressed in big endian order.  
+       16..last SGN_CKSUM  Checksum of the "to-be-signed" data and  
+                           octet 0..15, as described in section 4.2.4. 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.   
+    
+4.2.6.2. Wrap Tokens 
+    
+   Use of the GSS_Wrap() call yields a token (referred as the Wrap 
+   token in this document), which consists of a descriptive header, 
+   followed by a body portion that contains either the input user data 
+   in plaintext concatenated with the checksum, or the input user data 
+   encrypted.  The GSS_Wrap() token SHALL have the following format: 
+    
+      Octet no   Name        Description 
+      --------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_Wrap() contain the the hex value 05 04                 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3        Filler     Contains the hex value FF. 
+       4..5     EC         Contains the "extra count" field, in big  
+                           endian order as described in section 4.2.3. 
+       6..7     RRC        Contains the "right rotation count" in big  
+                           endian order, as described in section 4.2.5. 
+       8..15    SND_SEQ    Sequence number field in clear text, 
+                           expressed in big endian order. 
+       16..last Data       Encrypted data for Wrap tokens with  
+                           confidentiality, or plaintext data followed  
+                           by the checksum for Wrap tokens without  
+                           confidentiality, as described in section  
+                           4.2.4.         
+             
+4.3. Context Deletion Tokens 
+ 
+   Context deletion tokens are empty in this mechanism.  Both peers to 
+   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
+   independently, passing a null output_context_token buffer to 
+   indicate that no context_token is required.  Implementations of 
+   GSS_Delete_sec_context() should delete relevant locally-stored 
+   context information. 
+        
+4.4. Token Identifier Assignment Considerations 
+    
+   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
+   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
+   the first two octets of a token, one can tell unambiguously if it is 
+   wrapped with the generic GSS-API token framing.   
+Zhu                                                                 11 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+    
+5. Parameter Definitions 
+    
+   This section defines parameter values used by the Kerberos V5 GSS-
+   API mechanism.  It defines interface elements in support of 
+   portability, and assumes use of C language bindings per [RFC-2744]. 
+    
+5.1. Minor Status Codes 
+ 
+   This section recommends common symbolic names for minor_status 
+   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
+   these definitions will enable independent implementers 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 GSS-API 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.  
+    
+5.1.1. Non-Kerberos-specific codes 
+ 
+      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" */ 
+    
+5.1.2. Kerberos-specific-codes 
+    
+      GSS_KRB5_S_KG_CCACHE_NOMATCH  
+              /* "Client principal in credentials does not match   
+                 specified name" */ 
+Zhu                                                                 12 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
+              /* "No key available for specified service principal" */ 
+      GSS_KRB5_S_KG_TGT_MISSING 
+              /* "No Kerberos ticket-granting ticket available" */ 
+      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" */ 
+ 
+5.2. Buffer Sizes 
+ 
+   All implementations of this specification MUST be capable of 
+   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
+   GSS_VerifyMIC(), and GSS_Wrap(), and MUST be capable of accepting 
+   the output_token generated by GSS_Wrap() for a 16K octet input 
+   buffer as input to GSS_Unwrap().  Implementations SHOULD support 64K 
+   octet input buffers, and MAY support even larger input buffer sizes. 
+ 
+6. Backwards Compatibility Considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  To address this, implementations 
+   can always use the explicit sign or seal algorithm in [RFC-1964] 
+   when the key type corresponds to "older" enctypes.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [RFC-1964].  However this would 
+   require either the use of a mechanism such as [RFC-2478] to securely 
+   negotiate the method or the use out of band mechanism to choose 
+   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
+   new token formats defined in this document SHOULD be used only if 
+   both peers are known to support the new mechanism during context 
+   negotiation because of, for example, the use of "new" enctypes. 
+ 
+   GSS_Unwrap() or GSS_VerifyMIC() can process a message token as 
+   follows: it can look at the first octet of the token header, if it 
+   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
+   framing, otherwise the first two octets of the token contain the 
+   TOK_ID that uniquely identify the token message format. 
+    
+7. Security Considerations 
+    
+   Channel bindings are validated by the acceptor.  The acceptor can 
+   ignore the channel bindings restriction supplied by the initiator 
+   and carried in the authenticator checksum, if channel bindings are 
+   not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does 
+   not prove to the initiator that it has the same channel bindings as 
+   the initiator, even if the client requested mutual authentication.  
+   This limitation should be taken into consideration by designers of 
+   applications that would use channel bindings, whether to limit the 
+Zhu                                                                 13 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+   use of GSS-API contexts to nodes with specific network addresses, to 
+   authenticate other established, secure channels using Kerberos 
+   Version 5, or for any other purpose. 
+    
+   Session key types are selected by the KDC.  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, 
+   administrators can control what enctypes can be used for session 
+   keys for this mechanism by controlling the set of the ticket session 
+   key enctypes which the KDC is willing to use in tickets for a given 
+   acceptor principal.  The KDC could therefore be given the task of 
+   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 (for example) AES [AES-KRB5] but the Kerberos 
+   implementation does.  It means that AES session keys cannot be 
+   issued for that service principal, which keeps the protection of 
+   non-GSSAPI services weaker than necessary.  KDC administrators 
+   desiring to limit the session key types to support interoperability 
+   with such GSSAPI implementations should carefully weigh the 
+   reduction in protection offered by such mechanisms against the 
+   benefits of interoperability. 
+    
+8. Acknowledgments 
+ 
+  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of 
+  this document.  
+   
+  The text for security considerations was contributed by Nicolas 
+  Williams and Ken Raeburn. 
+   
+  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
+  namely the encoding of the RRC field.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments.  
+   
+  Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon 
+  Josefsson also provided valuable inputs on this document. 
+   
+  Jeffrey Hutzelman provided comments and clarifications for the text 
+  related to the channel bindings.  
+   
+  Jeffrey Hutzelman and Russ Housley suggested many editorial changes. 
+ 
+
+
+Zhu                                                                 14 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+  Luke Howard provided implementations of this document for the 
+  Heimdal code base, and helped inter-operability testing with the 
+  Microsoft code base, together with Love Hornquist Astrand.  These 
+  experiments formed the basis of this document. 
+   
+  Martin Rex provided suggestions of TOK_ID assignment recommendations 
+  thus the token tagging in this document is unambiguous if the token 
+  is wrapped with the pseudo ASN.1 header.  
+   
+  This document retains some of the text of RFC-1964 in relevant 
+  sections. 
+   
+9. 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 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. 
+    
+   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. 
+   
+10. References 
+    
+10.1. Normative References 
+    
+   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
+   3", BCP 9, RFC 2026, October 1996.  
+        
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
+   Requirement Levels", BCP 14, RFC 2119, March 1997. 
+    
+   [RFC-2743] Linn, J., "Generic Security Service Application Program    
+   Interface Version 2, Update 1", RFC 2743, January 2000. 
+    
+   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
+   bindings", RFC 2744, January 2000. 
+    
+   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
+   RFC 1964, June 1996. 
+    
+
+
+Zhu                                                                 15 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+   [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
+   krb-wg-crypto.  Work in Progress. 
+    
+   [KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
+   krb-wg-kerberos-clarifications.  Work in Progress. 
+ 
+10.2. Informative References 
+ 
+   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
+   Developer Network (MSDN), April 2003. 
+    
+   [AES-KRB5] RFC-Editor: To be replaced by RFC number for draft-
+   raeburn-krb-rijndael-krb.  Work in Progress. 
+    
+   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism", RFC 2478, December 1998. 
+    
+11. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: karthikj@microsoft.com 
+ 
+   Sam Hartman 
+   Massachusetts Institute of Technology 
+   77 Massachusetts Avenue 
+   Cambridge, MA 02139 - USA 
+   Email: hartmans@MIT.EDU 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                                                                 16 
+DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
+ 
+    
+Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (date). 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                                                                 17 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-07.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-07.txt
new file mode 100644
index 00000000000..9f07400deff
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-07.txt
@@ -0,0 +1,985 @@
+
+<Network Working Group>                                       Larry Zhu 
+Internet Draft                                       Karthik Jaganathan 
+Updates: 1964                                                 Microsoft 
+Category: Standards Track                                   Sam Hartman 
+draft-ietf-krb-wg-gssapi-cfx-07.txt                                 MIT 
+                                                          March 9, 2004 
+                                             Expires: September 9, 2004 
+ 
+          The Kerberos Version 5 GSS-API 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 [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-krb-wg-gssapi-cfx-07.txt, and expires on September 9 
+   2004.  Please send comments to: ietf-krb-wg@anl.gov. 
+    
+Abstract 
+    
+   This document defines protocols, procedures, and conventions to be 
+   employed by peers implementing the Generic Security Service 
+   Application Program Interface (GSS-API) when using the Kerberos 
+   Version 5 mechanism. 
+    
+   RFC-1964 is updated and incremental changes are proposed in response 
+   to recent developments such as the introduction of Kerberos 
+   cryptosystem framework.  These changes support the inclusion of new 
+   cryptosystems, by defining new per-message tokens along with their 
+   encryption and checksum algorithms based on the cryptosystem 
+   profiles.   
+    
+Conventions used in this document 
+  
+Zhu                                                                   1 
+DRAFT             Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+    
+   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]. 
+    
+   The term "little endian order" is used for brevity to refer to the 
+   least-significant-octet-first encoding, while the term "big endian 
+   order" is for the most-significant-octet-first encoding. 
+    
+Table of Contents 
+
+   1. Introduction ...............................................  2 
+   2. Key Derivation for Per-Message Tokens ......................  3 
+   3. Quality of Protection ......................................  4 
+   4. Definitions and Token Formats ..............................  4 
+   4.1. Context Establishment Tokens .............................  4 
+   4.1.1. Authenticator Checksum .................................  5 
+   4.2. Per-Message Tokens .......................................  8 
+   4.2.1. Sequence Number ........................................  8 
+   4.2.2. Flags Field ............................................  8 
+   4.2.3. EC Field ...............................................  9 
+   4.2.4. Encryption and Checksum Operations .....................  9 
+   4.2.5. RRC Field .............................................. 10 
+   4.2.6. Message Layouts ........................................ 10 
+   4.3. Context Deletion Tokens .................................. 11 
+   4.4. Token Identifier Assignment Considerations ............... 11 
+   5. Parameter Definitions ...................................... 12 
+   5.1. Minor Status Codes ....................................... 12 
+   5.1.1. Non-Kerberos-specific codes ............................ 12 
+   5.1.2. Kerberos-specific-codes ................................ 12 
+   5.2. Buffer Sizes ............................................. 13 
+   6. Backwards Compatibility Considerations ..................... 13 
+   7. Security Considerations .................................... 13 
+   8. Acknowledgments ............................................ 14 
+   9. Intellectual Property Statement ............................ 15
+   10. References ................................................ 15 
+   10.1. Normative References .................................... 15 
+   10.2. Informative References .................................. 15 
+   11. Author's Address .......................................... 15
+   Full Copyright Statement ...................................... 17  
+   
+1. Introduction 
+    
+   [KCRYPTO] defines a generic framework for describing encryption and 
+   checksum types to be used with the Kerberos protocol and associated 
+   protocols. 
+    
+   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
+   It defines the format of context establishment, per-message and 
+   context deletion tokens and uses algorithm identifiers for each 
+   cryptosystem in per message and context deletion tokens.   
+    
+   The approach taken in this document obviates the need for algorithm 
+   identifiers.  This is accomplished by using the same encryption 
+   algorithm, specified by the crypto profile [KCRYPTO] for the session 
+   key or subkey that is created during context negotiation, and its 
+   required checksum algorithm.  Message layouts of the per-message 
+Zhu                                                                  2 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+   tokens are therefore revised to remove algorithm indicators and also 
+   to add extra information to support the generic crypto framework 
+   [KCRYPTO].  
+    
+   Tokens transferred between GSS-API peers for security context 
+   establishment are also described in this document.  The data 
+   elements exchanged between a GSS-API endpoint implementation and the 
+   Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to 
+   GSS-API usage and are therefore defined within [KRBCLAR] rather than 
+   within this specification. 
+    
+   The new token formats specified in this document MUST be used with 
+   all "newer" encryption types [KRBCLAR] and MAY be used with "older" 
+   encryption types, provided that the initiator and acceptor know, 
+   from the context establishment, that they can both process these new 
+   token formats. 
+    
+   "Newer" encryption types are those which have been specified along 
+   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
+   as defined in section 3.1.3 of [KRBCLAR].  The list of not-newer 
+   encryption types is as follows [KCRYPTO]: 
+    
+             Encryption Type             Assigned Number     
+           ---------------------------------------------- 
+            des-cbc-crc                        1              
+            des-cbc-md4                        2              
+            des-cbc-md5                        3              
+            des3-cbc-md5                       5 
+            des3-cbc-sha1                      7 
+            dsaWithSHA1-CmsOID                 9            
+            md5WithRSAEncryption-CmsOID       10            
+            sha1WithRSAEncryption-CmsOID      11           
+            rc2CBC-EnvOID                     12            
+            rsaEncryption-EnvOID              13    
+            rsaES-OAEP-ENV-OID                14    
+            des-ede3-cbc-Env-OID              15            
+            des3-cbc-sha1-kd                  16                       
+            rc4-hmac                          23          
+    
+2. Key Derivation for Per-Message Tokens 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.   
+    
+   This document defines four key usage values below that are used to 
+   derive a specific key for signing and sealing messages, from the 
+   session key or subkey [KRBCLAR] created during the context 
+   establishment. 
+    
+        Name                         Value 
+      ------------------------------------- 
+       KG-USAGE-ACCEPTOR-SEAL         22 
+       KG-USAGE-ACCEPTOR-SIGN         23 
+       KG-USAGE-INITIATOR-SEAL        24 
+
+Zhu                                                                  3 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+       KG-USAGE-INITIATOR-SIGN        25 
+          
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC tokens (as defined in section 4.2.6.1), and 
+   KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section 
+   4.2.6.2); similarly when the sender is the context initiator, KG-
+   USAGE-INITIATOR-SIGN is used as the usage number in the key 
+   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
+   for Wrap Tokens.  Even if the Wrap token does not provide for 
+   confidentiality the same usage values specified above are used. 
+    
+   During the context initiation and acceptance sequence, the acceptor 
+   MAY assert a subkey, and if so, subsequent messages MUST use this 
+   subkey as the protocol key and these messages MUST be flagged as 
+   "AcceptorSubkey" as described in section 4.2.2. 
+ 
+3. Quality of Protection 
+ 
+   The GSS-API specification [RFC-2743] provides for Quality of 
+   Protection (QOP) values that can be used by applications to request 
+   a certain type of encryption or signing.  A zero QOP value is used 
+   to indicate the "default" protection; applications which do not use 
+   the default QOP are not guaranteed to be portable across 
+   implementations or even inter-operate with different deployment 
+   configurations of the same implementation.  Using an algorithm that 
+   is different from the one for which the key is defined may not be 
+   appropriate.  Therefore, when the new method in this document is 
+   used, the QOP value is ignored. 
+    
+   The encryption and checksum algorithms in per-message tokens are now 
+   implicitly defined by the algorithms associated with the session key 
+   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
+   therefore no longer needed and removed from the new token headers. 
+ 
+4. Definitions and Token Formats 
+    
+   This section provides terms and definitions, as well as descriptions 
+   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
+                                    
+4.1. Context Establishment Tokens 
+    
+   All context establishment tokens emitted by the Kerberos Version 5 
+   GSS-API mechanism SHALL have the framing described in section 3.1 of 
+   [RFC-2743], as illustrated by the following pseudo-ASN.1 structures: 
+    
+         GSS-API DEFINITIONS ::= 
+    
+         BEGIN 
+    
+         MechType ::= OBJECT IDENTIFIER 
+         -- representing Kerberos V5 mechanism 
+    
+         GSSAPI-Token ::= 
+         -- option indication (delegation, etc.) indicated within 
+Zhu                                                                  4 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+         -- mechanism-specific token 
+         [APPLICATION 0] IMPLICIT SEQUENCE { 
+                 thisMech MechType, 
+                 innerToken ANY DEFINED BY thisMech 
+                    -- contents mechanism-specific 
+                    -- ASN.1 structure not required 
+                 } 
+    
+         END 
+    
+   Where the innerToken field starts with a two-octet token-identifier 
+   (TOK_ID) expressed in big endian order, followed by a Kerberos 
+   message.   
+    
+   Here are the TOK_ID values used in the context establishment tokens: 
+    
+         Token               TOK_ID Value in Hex  
+        ----------------------------------------- 
+         KRB_AP_REQ            01 00 
+         KRB_AP_REP            02 00 
+         KRB_ERROR             03 00 
+             
+   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
+   are defined in [KRBCLAR].   
+    
+   If an unknown token identifier (TOK_ID) is received in the initial 
+   context establishment token, the receiver MUST return 
+   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
+   MUST contain a KRB_ERROR message with the error code 
+   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
+    
+4.1.1. Authenticator Checksum 
+ 
+   The authenticator in the KRB_AP_REQ message MUST include the 
+   optional sequence number and the checksum field.  The checksum field 
+   is used to convey service flags, channel bindings, and optional 
+   delegation information.   
+    
+   The checksum type MUST be 0x8003. When delegation is used, a ticket-
+   granting ticket will be transferred in a KRB_CRED message.  This 
+   ticket SHOULD have its forwardable flag set.  The EncryptedData 
+   field of the KRB_CRED message [KRBCLAR] MUST be encrypted in the 
+   session key of the ticket used to authenticate the context. 
+    
+   The authenticator checksum field SHALL have the following format: 
+       
+      Octet        Name      Description 
+     ----------------------------------------------------------------- 
+      0..3         Lgth    Number of octets in Bnd field;  Represented  
+                           in little-endian order;  Currently contains   
+                           hex value 10 00 00 00 (16). 
+      4..19        Bnd     Channel binding information, as described in  
+                           section 4.1.1.2. 
+      20..23       Flags   Four-octet context-establishment flags in 
+                           little-endian order as described in section  
+Zhu                                                                  5 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+                           4.1.1.1.  
+      24..25       DlgOpt  The delegation option identifier (=1) in  
+                           little-endian order [optional].  This field  
+                           and the next two fields are present if and  
+                           only if GSS_C_DELEG_FLAG is set as described  
+                           in section 4.1.1.1.   
+      26..27       Dlgth   The length of the Deleg field in little- 
+                           endian order [optional]. 
+      28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)  
+                           [optional].  
+      n..last      Exts    Extensions [optional]. 
+    
+   The length of the checksum field MUST be at least 24 octets when 
+   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and 
+   at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  
+   When GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and Deleg fields 
+   of the checksum data MUST immediately follow the Flags field.  The 
+   optional trailing octets (namely the "Exts" field) facilitate 
+   future extensions to this mechanism.  When delegation is not used 
+   but the Exts field is present, the Exts field starts at octet 24 
+   (DlgOpt, Dlgth and Deleg are absent). 
+    
+   Initiators that do not support the extensions MUST NOT include more 
+   than 24 octets in the checksum field, when GSS_C_DELEG_FLAG is not 
+   set, or more than 28 octets plus the KRB_CRED in the Deleg field, 
+   when GSS_C_DELEG_FLAG is set.  Acceptors that do not understand the 
+   extensions MUST ignore any octets past the Deleg field of the 
+   checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field 
+   of the checksum data, when GSS_C_DELEG_FLAG is not set. 
+ 
+4.1.1.1. Checksum Flags Field 
+    
+   The checksum "Flags" field is used to convey service options or 
+   extension negotiation information. 
+    
+   The following context establishment flags are defined in [RFC-2744].   
+    
+        Flag Name              Value     
+      --------------------------------- 
+       GSS_C_DELEG_FLAG           1        
+       GSS_C_MUTUAL_FLAG          2       
+       GSS_C_REPLAY_FLAG          4       
+       GSS_C_SEQUENCE_FLAG        8        
+       GSS_C_CONF_FLAG           16      
+       GSS_C_INTEG_FLAG          32     
+        
+   Context establishment flags are exposed to the calling application.  
+   If the calling application desires a particular service option then 
+   it requests that option via GSS_Init_sec_context() [RFC-2743].  If 
+   the corresponding return state values [RFC-2743] indicate that any 
+   of above optional context level services will be active on the 
+   context, the corresponding flag values in the table above MUST be 
+   set in the checksum Flags field. 
+    
+
+Zhu                                                                  6 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for 
+   use with legacy vendor-specific extensions to this mechanism. 
+    
+   All other flag values not specified herein are reserved for future 
+   use.  Future revisions of this mechanism may use these reserved 
+   flags and may rely on implementations of this version to not use 
+   such flags in order to properly negotiate mechanism versions.  
+   Undefined flag values MUST be cleared by the sender, and unknown 
+   flags MUST be ignored by the receiver.   
+    
+4.1.1.2. Channel Binding Information 
+    
+   These tags are intended to be used to identify the particular 
+   communications channel for which the GSS-API security context 
+   establishment tokens are intended, thus limiting the scope within 
+   which an intercepted context establishment token can be reused by an 
+   attacker (see [RFC-2743], section 1.1.6). 
+    
+   When using C language bindings, channel bindings are communicated 
+   to the GSS-API using the following structure [RFC-2744]: 
+ 
+      typedef struct gss_channel_bindings_struct { 
+         OM_uint32       initiator_addrtype; 
+         gss_buffer_desc initiator_address; 
+         OM_uint32       acceptor_addrtype; 
+         gss_buffer_desc acceptor_address; 
+         gss_buffer_desc application_data; 
+      } *gss_channel_bindings_t; 
+    
+   The member fields and constants used for different address types 
+   are defined in [RFC-2744]. 
+    
+   The "Bnd" field contains the MD5 hash of channel bindings, taken 
+   over all non-null components of bindings, in order of declaration.  
+   Integer fields within channel bindings are represented in little-
+   endian order for the purposes of the MD5 calculation. 
+    
+   In computing the contents of the Bnd field, the following detailed 
+   points apply:  
+    
+   (1) For purposes of MD5 hash computation, each integer field and 
+   input length field SHALL be formatted into four octets, using 
+   little endian octet ordering.  
+    
+   (2) All input length fields within gss_buffer_desc elements of a 
+   gss_channel_bindings_struct even those which are zero-valued, SHALL 
+   be included in the hash calculation; the value elements of 
+   gss_buffer_desc elements SHALL be dereferenced, and the resulting 
+   data SHALL be included within the hash computation, only for the 
+   case of gss_buffer_desc elements having non-zero length specifiers.  
+    
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
+   valid channel binding structure, the Bnd field SHALL be set to 16 
+   zero-valued octets.  
+ 
+Zhu                                                                  7 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+   If the caller to GSS_Accept_sec_context [RFC-2743] passes in 
+   GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then 
+   the acceptor MAY ignore any channel bindings supplied by the 
+   initiator, returning success even if the initiator did pass in 
+   channel bindings. 
+    
+   If the application supply, in the channel bindings, a buffer with a 
+   length field larger than 4294967295 (2^32 - 1), the implementation 
+   of this mechanism MAY chose to reject the channel bindings 
+   altogether, using major status GSS_S_BAD_BINDINGS [RFC-2743].  In 
+   any case, the size of channel binding data buffers that can be used 
+   (interoperable, without extensions) with this specification is 
+   limited to 4294967295 octets. 
+    
+4.2. Per-Message Tokens 
+    
+   Two classes of tokens are defined in this section:  "MIC" tokens, 
+   emitted by calls to GSS_GetMIC() and consumed by calls to 
+   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
+   consumed by calls to GSS_Unwrap(). 
+    
+   The new per-message tokens introduced here do not include the 
+   generic GSS-API token framing used by the context establishment 
+   tokens.  These new tokens are designed to be used with newer crypto 
+   systems that can, for example, have variable-size checksums.   
+    
+4.2.1. Sequence Number 
+ 
+   To distinguish intentionally-repeated messages from maliciously-
+   replayed ones, per-message tokens contain a sequence number field, 
+   which is a 64 bit integer expressed in big endian order.  After 
+   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
+   numbers SHALL be incremented by one. 
+ 
+4.2.2. Flags Field 
+ 
+   The "Flags" field is a one-octet integer used to indicate a set of 
+   attributes for the protected message.  For example, one flag is 
+   allocated as the direction-indicator, thus preventing an adversary 
+   from sending back the same message in the reverse direction and 
+   having it accepted.   
+    
+   The meanings of bits in this field (the least significant bit is 
+   bit 0) are as follows: 
+    
+        Bit    Name             Description 
+       --------------------------------------------------------------- 
+        0   SentByAcceptor    When set, this flag indicates the sender  
+                              is the context acceptor.  When not set, 
+                              it indicates the sender is the context  
+                              initiator. 
+        1   Sealed            When set in Wrap tokens, this flag  
+                              indicates confidentiality is provided  
+                              for.  It SHALL NOT be set in MIC tokens. 
+        2   AcceptorSubkey    A subkey asserted by the context acceptor 
+Zhu                                                                  8 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+                              is used to protect the message. 
+    
+   The rest of available bits are reserved for future use and MUST be 
+   cleared.  The receiver MUST ignore unknown flags. 
+    
+4.2.3. EC Field 
+ 
+   The "EC" (Extra Count) field is a two-octet integer field expressed 
+   in big endian order.   
+    
+   In Wrap tokens with confidentiality, the EC field SHALL be used to 
+   encode the number of octets in the filler, as described in section 
+   4.2.4. 
+    
+   In Wrap tokens without confidentiality, the EC field SHALL be used 
+   to encode the number of octets in the trailing checksum, as 
+   described in section 4.2.4.   
+ 
+4.2.4. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection [KCRYPTO].  Therefore no separate checksum is 
+   needed.  
+    
+   The result of decryption can be longer than the original plaintext 
+   [KCRYPTO] and the extra trailing octets are called "crypto-system 
+   residue" in this document.  However, given the size of any plaintext 
+   data, one can always find a (possibly larger) size so that, when 
+   padding the to-be-encrypted text to that size, there will be no 
+   crypto-system residue added [KCRYPTO].  
+ 
+   In Wrap tokens that provide for confidentiality, the first 16 octets 
+   of the Wrap token (the "header", as defined in section 4.2.6), SHALL 
+   be appended to the plaintext data before encryption.  Filler octets 
+   MAY be inserted between the plaintext data and the "header", and the 
+   values and size of the filler octets are chosen by implementations, 
+   such that there SHALL be no crypto-system residue present after the 
+   decryption.  The resulting Wrap token is {"header" | 
+   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
+   encryption operation (which provides for integrity protection) 
+   defined in the crypto profile [KCRYPTO], and the RRC field (as 
+   defined in section 4.2.5) in the to-be-encrypted header contain the 
+   hex value 00 00.   
+           
+   In Wrap tokens that do not provide for confidentiality, the checksum 
+   SHALL be calculated first over the to-be-signed plaintext data, and 
+   then the first 16 octets of the Wrap token (the "header", as defined 
+   in section 4.2.6).  Both the EC field and the RRC field in the token 
+   header SHALL be filled with zeroes for the purpose of calculating 
+   the checksum.  The resulting Wrap token is {"header" | plaintext-
+   data | get_mic(plaintext-data | "header")},  where get_mic() is the 
+   checksum operation for the required checksum mechanism of the chosen 
+   encryption mechanism defined in the crypto profile [KCRYPTO].  
+    
+
+Zhu                                                                  9 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+   The parameters for the key and the cipher-state in the encrypt() and 
+   get_mic() operations have been omitted for brevity.   
+        
+   For MIC tokens, the checksum SHALL be calculated as follows: the 
+   checksum operation is calculated first over the to-be-signed 
+   plaintext data, and then the first 16 octets of the MIC token, where 
+   the checksum mechanism is the required checksum mechanism of the 
+   chosen encryption mechanism defined in the crypto profile [KCRYPTO]. 
+   
+   The resulting Wrap and MIC tokens bind the data to the token header, 
+   including the sequence number and the direction indicator.  
+   
+4.2.5. RRC Field 
+ 
+   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
+   allow the data to be encrypted in-place by existing SSPI (Security 
+   Service Provider Interface) [SSPI] applications that do not provide 
+   an additional buffer for the trailer (the cipher text after the in-
+   place-encrypted data) in addition to the buffer for the header (the 
+   cipher text before the in-place-encrypted data).  The resulting Wrap 
+   token in the previous section, excluding the first 16 octets of the 
+   token header, is rotated to the right by "RRC" octets.  The net 
+   result is that "RRC" octets of trailing octets are moved toward the 
+   header.  Consider the following as an example of this rotation 
+   operation:  Assume that the RRC value is 3 and the token before the 
+   rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the 
+   token after rotation would be {"header" | ff | gg | hh | aa | bb | 
+   cc | dd | ee }, where {aa | bb | cc |...| hh} is used to indicate 
+   the octet sequence. 
+  
+   The RRC field is expressed as a two-octet integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values, including rotation counts 
+   greater than the length of the token. 
+ 
+4.2.6. Message Layouts 
+    
+   Per-message tokens start with a two-octet token identifier (TOK_ID) 
+   field, expressed in big endian order.  These tokens are defined 
+   separately in subsequent sub-sections. 
+    
+4.2.6.1. MIC Tokens 
+    
+   Use of the GSS_GetMIC() call yields a token (referred as the MIC 
+   token in this document), separate from the user  
+   data being protected, which can be used to verify the integrity of  
+   that data as received.  The token has the following format: 
+    
+      Octet no   Name        Description 
+      ----------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_GetMIC() contain the hex value 04 04  
+Zhu                                                                 10 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3..7     Filler     Contains five octets of hex value FF. 
+       8..15    SND_SEQ    Sequence number field in clear text,  
+                           expressed in big endian order.  
+       16..last SGN_CKSUM  Checksum of the "to-be-signed" data and  
+                           octet 0..15, as described in section 4.2.4. 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.   
+    
+4.2.6.2. Wrap Tokens 
+    
+   Use of the GSS_Wrap() call yields a token (referred as the Wrap 
+   token in this document), which consists of a descriptive header, 
+   followed by a body portion that contains either the input user data 
+   in plaintext concatenated with the checksum, or the input user data 
+   encrypted.  The GSS_Wrap() token SHALL have the following format: 
+    
+      Octet no   Name        Description 
+      --------------------------------------------------------------- 
+       0..1     TOK_ID     Identification field.  Tokens emitted by  
+                           GSS_Wrap() contain the the hex value 05 04                 
+                           expressed in big endian order in this field. 
+       2        Flags      Attributes field, as described in section  
+                           4.2.2. 
+       3        Filler     Contains the hex value FF. 
+       4..5     EC         Contains the "extra count" field, in big  
+                           endian order as described in section 4.2.3. 
+       6..7     RRC        Contains the "right rotation count" in big  
+                           endian order, as described in section 4.2.5. 
+       8..15    SND_SEQ    Sequence number field in clear text, 
+                           expressed in big endian order. 
+       16..last Data       Encrypted data for Wrap tokens with  
+                           confidentiality, or plaintext data followed  
+                           by the checksum for Wrap tokens without  
+                           confidentiality, as described in section  
+                           4.2.4.         
+             
+4.3. Context Deletion Tokens 
+ 
+   Context deletion tokens are empty in this mechanism.  Both peers to 
+   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
+   independently, passing a null output_context_token buffer to 
+   indicate that no context_token is required.  Implementations of 
+   GSS_Delete_sec_context() should delete relevant locally-stored 
+   context information. 
+        
+4.4. Token Identifier Assignment Considerations 
+    
+   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
+   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
+   the first two octets of a token, one can tell unambiguously if it is 
+   wrapped with the generic GSS-API token framing.   
+Zhu                                                                 11 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+    
+5. Parameter Definitions 
+    
+   This section defines parameter values used by the Kerberos V5 GSS-
+   API mechanism.  It defines interface elements in support of 
+   portability, and assumes use of C language bindings per [RFC-2744]. 
+    
+5.1. Minor Status Codes 
+ 
+   This section recommends common symbolic names for minor_status 
+   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
+   these definitions will enable independent implementers 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 GSS-API 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.  
+    
+5.1.1. Non-Kerberos-specific codes 
+ 
+      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" */ 
+    
+5.1.2. Kerberos-specific-codes 
+    
+      GSS_KRB5_S_KG_CCACHE_NOMATCH  
+              /* "Client principal in credentials does not match   
+                 specified name" */ 
+Zhu                                                                 12 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
+              /* "No key available for specified service principal" */ 
+      GSS_KRB5_S_KG_TGT_MISSING 
+              /* "No Kerberos ticket-granting ticket available" */ 
+      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" */ 
+ 
+5.2. Buffer Sizes 
+ 
+   All implementations of this specification MUST be capable of 
+   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
+   GSS_VerifyMIC(), and GSS_Wrap(), and MUST be capable of accepting 
+   the output_token generated by GSS_Wrap() for a 16K octet input 
+   buffer as input to GSS_Unwrap().  Implementations SHOULD support 64K 
+   octet input buffers, and MAY support even larger input buffer sizes. 
+ 
+6. Backwards Compatibility Considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  To address this, implementations 
+   can always use the explicit sign or seal algorithm in [RFC-1964] 
+   when the key type corresponds to "older" enctypes.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [RFC-1964].  However this would 
+   require either the use of a mechanism such as [RFC-2478] to securely 
+   negotiate the method or the use out of band mechanism to choose 
+   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
+   new token formats defined in this document SHOULD be used only if 
+   both peers are known to support the new mechanism during context 
+   negotiation because of, for example, the use of "new" enctypes. 
+ 
+   GSS_Unwrap() or GSS_VerifyMIC() can process a message token as 
+   follows: it can look at the first octet of the token header, if it 
+   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
+   framing, otherwise the first two octets of the token contain the 
+   TOK_ID that uniquely identify the token message format. 
+    
+7. Security Considerations 
+    
+   Channel bindings are validated by the acceptor.  The acceptor can 
+   ignore the channel bindings restriction supplied by the initiator 
+   and carried in the authenticator checksum, if channel bindings are 
+   not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does 
+   not prove to the initiator that it has the same channel bindings as 
+   the initiator, even if the client requested mutual authentication.  
+   This limitation should be taken into consideration by designers of 
+   applications that would use channel bindings, whether to limit the 
+Zhu                                                                 13 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+   use of GSS-API contexts to nodes with specific network addresses, to 
+   authenticate other established, secure channels using Kerberos 
+   Version 5, or for any other purpose. 
+    
+   Session key types are selected by the KDC.  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, 
+   administrators can control what enctypes can be used for session 
+   keys for this mechanism by controlling the set of the ticket session 
+   key enctypes which the KDC is willing to use in tickets for a given 
+   acceptor principal.  The KDC could therefore be given the task of 
+   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 (for example) AES [AES-KRB5] but the Kerberos 
+   implementation does.  It means that AES session keys cannot be 
+   issued for that service principal, which keeps the protection of 
+   non-GSSAPI services weaker than necessary.  KDC administrators 
+   desiring to limit the session key types to support interoperability 
+   with such GSSAPI implementations should carefully weigh the 
+   reduction in protection offered by such mechanisms against the 
+   benefits of interoperability. 
+    
+8. Acknowledgments 
+ 
+  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of 
+  this document.  
+   
+  The text for security considerations was contributed by Nicolas 
+  Williams and Ken Raeburn. 
+   
+  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
+  namely the encoding of the RRC field.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments.  
+   
+  Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon 
+  Josefsson also provided valuable inputs on this document. 
+   
+  Jeffrey Hutzelman provided comments and clarifications for the text 
+  related to the channel bindings.  
+   
+  Jeffrey Hutzelman and Russ Housley suggested many editorial changes. 
+ 
+
+
+Zhu                                                                 14 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+  Luke Howard provided implementations of this document for the 
+  Heimdal code base, and helped inter-operability testing with the 
+  Microsoft code base, together with Love Hornquist Astrand.  These 
+  experiments formed the basis of this document. 
+   
+  Martin Rex provided suggestions of TOK_ID assignment recommendations 
+  thus the token tagging in this document is unambiguous if the token 
+  is wrapped with the pseudo ASN.1 header.  
+   
+  John Linn wrote the original Kerberos Version 5 mechanism 
+  specification [RFC-1964], of which some of the text has been retained
+  in this document. 
+   
+9. 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 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. 
+    
+   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. 
+   
+10. References 
+    
+10.1. Normative References 
+    
+   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
+   3", BCP 9, RFC 2026, October 1996.  
+        
+   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
+   Requirement Levels", BCP 14, RFC 2119, March 1997. 
+    
+   [RFC-2743] Linn, J., "Generic Security Service Application Program    
+   Interface Version 2, Update 1", RFC 2743, January 2000. 
+    
+   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
+   bindings", RFC 2744, January 2000. 
+    
+   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
+   RFC 1964, June 1996. 
+    
+Zhu                                                                 15 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+   [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
+   krb-wg-crypto.  Work in Progress. 
+    
+   [KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
+   krb-wg-kerberos-clarifications.  Work in Progress. 
+ 
+10.2. Informative References 
+ 
+   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
+   Developer Network (MSDN), April 2003. 
+    
+   [AES-KRB5] RFC-Editor: To be replaced by RFC number for draft-
+   raeburn-krb-rijndael-krb.  Work in Progress. 
+    
+   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism", RFC 2478, December 1998. 
+    
+11. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: karthikj@microsoft.com 
+ 
+   Sam Hartman 
+   Massachusetts Institute of Technology 
+   77 Massachusetts Avenue 
+   Cambridge, MA 02139 - USA 
+   Email: hartmans@MIT.EDU 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                                                                 16 
+DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
+ 
+    
+Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (date). 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. 
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                                                                 17 
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-hw-auth-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-hw-auth-03.txt
new file mode 100644
index 00000000000..54a8db94193
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-hw-auth-03.txt
@@ -0,0 +1,329 @@
+
+Kerberos Working Group                                     Matt Crawford
+Internet Draft                                                  Fermilab
+                                                       10 September 2003
+
+              Passwordless Initial Authentication to Kerberos
+                       by Hardware Preauthentication
+                     <draft-ietf-krb-wg-hw-auth-03.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."
+
+    To view the list Internet-Draft Shadow Directories, see
+    http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+    This document specifies an extension to the Kerberos protocol for
+    performing initial authentication of a user without using that
+    user's long-lived password.  Any "hardware preauthentication" method
+    may be employed instead of the password, and the key of another
+    principal must be nominated to encrypt the returned credential.
+
+    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 [KWORD].
+
+
+1.  Motivation
+
+    Many sites using Kerberos for authentication have users who are
+    often, or even always, away from the site.  Sometimes these users
+
+
+
+Expires March 15, 2004          Crawford                        [Page 1]
+
+Internet Draft    Passwordless Hardware Authentication 10 September 2003
+
+
+    may need to connect to their site while they have no immediate
+    access to a computer with Kerberos software or any other trusted
+    secure remote-access mechanism.  Requiring hardware
+    preauthentication in addition to a password for all such users is an
+    incomplete solution because an eavesdropper with access to both the
+    remote users' path to the host in the site and that host's path to
+    the KDC can still steal the user's credential.
+
+    This document specifies a method by which a Kerberos application
+    server can request that a KDC authenticate a user using a hardware
+    preauthentication method and use a key held by the server in the
+    decryption of the KDC's reply, in place of the user's password.
+
+
+2.  Definitions
+
+    The following terms used here are defined in [KRB5] and [KRB5bis]:
+
+        KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ,
+        KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc-
+        options, padata-type, padata-value.
+
+    These terms are defined in [KRB5bis]:
+
+        PA-SAM-CHALLENGE, PA-SAM-RESPONSE.
+
+    The term "service" denotes some Kerberos service which normally
+    requires a client/server authentication exchange [KRB5] for access
+    and which is capable of both communicating with the KDC's
+    Authentication Service and interacting with the user to the extent
+    required to carry out a single-use authentication mechanism (SAM).
+    It must have access to some principal's long-lived key.  Telnet and
+    FTP services are examples.
+
+    The Kerberos Authentication Service will be denoted by "AS" to avoid
+    confusion with the service.
+
+
+3.  Method
+
+    This mechanism is intended to be employed when a user connects to a
+    service which normally allows only Kerberos-authenticated access.
+    When the service determines that the user will not authenticate (for
+    example, it receives a telnet "WONT AUTHENTICATION" command
+    [TELAUTH], or an FTP "USER" command without a preceding "AUTH"
+    command [FTPSEC]), it may accept a user principal name and attempt
+    to perform passwordless hardware authentication in the following
+    manner.
+
+
+
+Expires March 15, 2004          Crawford                        [Page 2]
+
+Internet Draft    Passwordless Hardware Authentication 10 September 2003
+
+
+3.1.  Initial AS Request and reply
+
+    The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5]
+    message with the flag OPT-HARDWARE-AUTH set in the kdc-options
+    field, in addition to any other desired options and lifetimes.  The
+    service sends this message to a KDC.  If the KDC's policy permits
+    this form of authentication for the user named in the request, and
+    the request is acceptable in all other respects, the KDC determines
+    what hardware preauthentication methods are available for the user
+    principal and constructs a KRB_ERROR message with the error-code set
+    to KDC_ERR_PREAUTH_REQUIRED.  The e-data field of this KRB_ERROR
+    message contains a sequence of PA-DATA which includes an element
+    with padata-type equal to PA-ALT-PRINC and an empty padata-value.
+    In addition to that are any elements needed for hardware
+    preauthentication of the user.  Typically this will consist of an
+    element with padata-type PA-SAM-CHALLENGE and padata-value
+    appropriate to the authentication method.
+
+
+3.2.  Second AS Request
+
+    The service, upon receiving the KRB_ERROR message from the KDC, must
+    process the PA-ALT-PRINC element by selecting a principal whose
+    long-lived key it has access to, and which is in the same realm as
+    the client.  This principal will be referred to as the alternate
+    principal.  It processes the PA-SAM-CHALLENGE normally, except that
+    whenever the user's long-lived (password-derived) encryption key is
+    called for, it uses the alternate principal's key instead.
+
+    The service constructs a second KRB_AS_REQ, again with the OPT-
+    HARDWARE-AUTH flag set in the kdc-options field, and this time with
+    a padata field which includes at least these two PA-DATA items, in
+    this order:
+
+        One with padata-type equal to PA-ALT-PRINC and as padata-value
+        the encoded PrincipalName of the alternate principal,
+
+        One with padata-type equal to PA-SAM-RESPONSE and padata-value
+        constructed as it would be for normal hardware
+        preauthentication, but with the alternate principal's key used
+        in place of the user's key.
+
+    Other PA-DATA may be present before, between or after these items.
+
+    The service sends this second KRB_AS_REQ to a KDC.
+
+
+
+
+
+
+Expires March 15, 2004          Crawford                        [Page 3]
+
+Internet Draft    Passwordless Hardware Authentication 10 September 2003
+
+
+3.3.  Final AS Reply
+
+    The KDC begins processing the AS request normally.  When the PA-ALT-
+    PRINC field is encountered, the KDC does the following:
+
+        First, if this use of the alternate principal named in the
+        request is against local policy, or if the alternate principal
+        does not exist in the database, a KRB_ERROR message with error-
+        code KDC_ERR_PREAUTH_FAILED is returned and processing ends.
+
+        Then, the alternate principal's key is fetched from the database
+        and held for use in subsequent processing.  It will be needed to
+        process the PA-SAM-RESPONSE and to encrypt the enc-part of the
+        KRB_AS_REP if authentication is successful.
+
+    The remainder of the AS request processing is normal, with the noted
+    substitution of the alternate principal's key for the user's.
+
+    The service, upon receiving a KRB_AS_REP, uses the alternate
+    principal's key to decrypt the enc-part, saves the user's credential
+    and takes appropriate measures to ensure that the KRB_AS_REP came
+    from a legitimate KDC and not an imposter.
+
+
+4.  IANA Considerations
+
+    As of this writing, management of Kerberos protocol parameters has
+    not been delegated to IANA.  No new naming or numbering spaces are
+    created by this specification.  Two new values from existing spaces
+    are defined:
+
+        The flag OPT-HARDWARE-AUTH is a previously unused bit in the
+        kdc-options field of a KDC-REQ-BODY [KRB5].  The assignment of
+        bit 11 is expected [BCN].
+
+        The preauthentication type PA-ALT-PRINC is denoted by padata-
+        type 24 [KRB5bis].
+
+
+5.  Security Considerations
+
+    There are no means provided here for protecting the traffic between
+    the user and the service, so it may be susceptible to eavesdropping,
+    hijacking and alteration.  This authentication mechanism is not
+    intended to be used as an alternative to the Kerberos client/server
+    authentication exchange, but as an improvement over making an
+    unprotected connection with a Kerberos password alone, or a password
+    plus a single-use authenticator.
+
+
+
+Expires March 15, 2004          Crawford                        [Page 4]
+
+Internet Draft    Passwordless Hardware Authentication 10 September 2003
+
+
+    The alternate principal's key MUST be involved in construction of
+    the PA-SAM-RESPONSE padata-value, to prevent an adversary
+    constructing a KRB_AS_REQ using that data but a different alternate
+    principal.  In practice, this means that the response data alone
+    must not determine the encryption key for the padata-value.
+
+    A service impersonator can obtain a presumably-valid SAM response
+    from the user which may (or may not) be usable for impersonating the
+    user at a later time.  And of course in the case of successful
+    authentication the service obtains access to the user's credentials.
+    As always, if the service host is compromised, so are the
+    credentials; but at least the service host never has access to the
+    user's password.
+
+    A service host which accepts a Kerberos password for access
+    typically protects itself against an impostor KDC by using the
+    received ticket-granting credential to get a ticket for a service
+    for which it has the key.  This step may be unnecessary when the
+    service host has already successfully used such a key to decrypt the
+    ticket-granting credential itself.
+
+    Use of this authentication method employs the service's long-term
+    key, providing more ciphertext in that key to an eavesdropper.  This
+    key is generally of better quality than a password-derived key and
+    any remaining concerns about the strength of the KRB_AS_REP are
+    better addressed by a general mechanism applicable to all AS
+    exchanges.
+
+
+6.  Acknowledgments
+
+    The first implementation of this extension grew from a beginning by
+    Ken Hornstein, which in turn was built on code released by the MIT
+    Kerberos Team.
+
+
+7.  References
+
+    [BCN]     Newman, C., private communication.
+
+    [FTPSEC]  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
+              2228.
+
+    [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510.
+
+    [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", Work in
+
+
+
+Expires March 15, 2004          Crawford                        [Page 5]
+
+Internet Draft    Passwordless Hardware Authentication 10 September 2003
+
+
+              progress.  (Currently draft-ietf-krb-wg-kerberos-
+              clarifications-04.txt.)
+
+    [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
+        Requirement Levels," RFC 2119, March 1997.
+
+    [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option",
+              RFC 2941.
+
+8.  Author's Address
+
+    Matt Crawford
+    Fermilab MS 369
+    PO Box 500
+    Batavia, IL 60510
+    USA
+
+    Phone: +1 630 840-3461
+    EMail: crawdad@fnal.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires March 15, 2004          Crawford                        [Page 6]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt
new file mode 100644
index 00000000000..c6c37b3d320
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt
@@ -0,0 +1,394 @@
+
+
+
+
+
+
+
+
+
+
+Kerberos Working Group                                     Matt Crawford
+Internet Draft                                                  Fermilab
+                                                         21 October 2006
+
+              Passwordless Initial Authentication to Kerberos
+                       by Hardware Preauthentication
+                     <draft-ietf-krb-wg-hw-auth-04.txt>
+
+
+
+Status of this Memo
+
+    By submitting this Internet-Draft, each author represents that any
+    applicable patent or other IPR claims of which he or she is aware
+    have been or will be disclosed, and any of which he or she becomes
+    aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+    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/1id-abstracts.html.
+
+    To view the list Internet-Draft Shadow Directories, see
+    http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+    This document specifies an extension to the Kerberos protocol for
+    performing initial authentication of a user without using that
+    user's long-lived password.  Any "hardware preauthentication" method
+    may be employed instead of the password, and the key of another
+    principal must be nominated to encrypt the returned credential.
+
+    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+
+
+
+Expires April 26, 2007          Crawford                        [Page 1]
+
+Internet Draft    Passwordless Hardware Authentication   21 October 2006
+
+
+    document are to be interpreted as described in [KWORD].
+
+
+1.  Motivation
+
+    Many sites using Kerberos for authentication have users who are
+    often, or even always, away from the site.  Sometimes these users
+    may need to connect to their site while they have no immediate
+    access to a trustworthy computer with Kerberos software or any other
+    trusted secure remote-access mechanism.  Requiring hardware
+    preauthentication in addition to a password for all such users is an
+    incomplete solution because an eavesdropper with access to both the
+    remote users' path to the host in the site and that host's path to
+    the KDC can still steal the user's credential.
+
+    This document specifies a method by which a Kerberos application
+    server can request that a KDC authenticate a user using a hardware
+    preauthentication method and use a key held by the server in the
+    decryption of the KDC's reply, in place of the user's password.
+
+
+2.  Definitions
+
+    The following terms used here are defined in [KRB5] and [KRB5bis]:
+
+        KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ,
+        KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc-
+        options, padata-type, padata-value.
+
+    These terms are defined in [KRB5bis]:
+
+        PA-SAM-CHALLENGE, PA-SAM-CHALLENGE2, PA-SAM-RESPONSE, PA-SAM-
+        RESPONSE2.
+
+    The term "service" denotes some Kerberos service which normally
+    requires a client/server authentication exchange [KRB5] for access
+    and which is capable of both communicating with the KDC's
+    Authentication Service and interacting with the user to the extent
+    required to carry out a single-use authentication mechanism (SAM).
+    It must have access to some principal's long-lived key.  Telnet and
+    FTP services are examples.
+
+    The Kerberos Authentication Service will be denoted by "AS" to avoid
+    confusion with the service.
+
+
+
+
+
+
+
+Expires April 26, 2007          Crawford                        [Page 2]
+
+Internet Draft    Passwordless Hardware Authentication   21 October 2006
+
+
+3.  Method
+
+    This mechanism is intended to be employed when a user connects to a
+    service which normally allows only Kerberos-authenticated access.
+    When the service determines that the user will not authenticate (for
+    example, it receives a telnet "WONT AUTHENTICATION" command
+    [TELAUTH], or an FTP "USER" command without a preceding "AUTH"
+    command [FTPSEC]), it may accept a user principal name and attempt
+    to perform passwordless hardware authentication in the following
+    manner.
+
+
+3.1.  Initial AS Request and reply
+
+    The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5]
+    message with the flag OPT-HARDWARE-AUTH set in the kdc-options
+    field, in addition to any other desired options and lifetimes.  The
+    service sends this message to a KDC.  If the KDC's policy permits
+    this form of authentication for the user named in the request, and
+    the request is acceptable in all other respects, the KDC determines
+    what hardware preauthentication methods are available for the user
+    principal and constructs a KRB_ERROR message with the error-code set
+    to KDC_ERR_PREAUTH_REQUIRED.  The e-data field of this KRB_ERROR
+    message contains a sequence of PA-DATA which includes an element
+    with padata-type equal to PA-ALT-PRINC and an empty padata-value.
+    In addition to that are any elements needed for hardware
+    preauthentication of the user.  Typically this will include an
+    element with padata-type PA-SAM-CHALLENGE or PA-SAM-CHALLENGE2 and
+    padata-value appropriate to the authentication method.
+
+
+3.2.  Second AS Request
+
+    The service, upon receiving the KRB_ERROR message from the KDC, must
+    process the PA-ALT-PRINC element by selecting a principal whose
+    long-lived key it has access to, and which is in the same realm as
+    the client.  This principal will be referred to as the alternate
+    principal.  It processes the PA-SAM-CHALLENGE normally, except that
+    whenever the user's long-lived (password-derived) encryption key is
+    called for, it uses the alternate principal's key instead.
+
+    The service constructs a second KRB_AS_REQ, again with the OPT-
+    HARDWARE-AUTH flag set in the kdc-options field, and this time with
+    a padata field which includes at least these two PA-DATA items, in
+    this order:
+
+        One with padata-type equal to PA-ALT-PRINC and as padata-value
+        the encoded PrincipalName of the alternate principal,
+
+
+
+Expires April 26, 2007          Crawford                        [Page 3]
+
+Internet Draft    Passwordless Hardware Authentication   21 October 2006
+
+
+        One with padata-type appropriate for hardware token-based
+        preauthentication, such as PA-SAM-RESPONSE or PA-SAM-RESPONSE2,
+        and padata-value constructed as it would be for normal hardware
+        preauthentication, but with the alternate principal's key used
+        in place of the user's key.
+
+    Other PA-DATA may be present before, between or after these items.
+
+    The service sends this second KRB_AS_REQ to a KDC.
+
+
+3.3.  Final AS Reply
+
+    The KDC begins processing the AS request normally.  When the PA-ALT-
+    PRINC field is encountered, the KDC does the following:
+
+        First, if this use of the alternate principal named in the
+        request is against local policy, or if the alternate principal
+        does not exist in the database, a KRB_ERROR message with error-
+        code KDC_ERR_PREAUTH_FAILED is returned and processing ends.
+
+        Then, the alternate principal's key is fetched from the database
+        and held for use in subsequent processing.  It will be needed to
+        process the PA-SAM-RESPONSE, PA-SAM-RESPONSE2, or similar
+        preauthentication data, and to encrypt the enc-part of the
+        KRB_AS_REP if authentication is successful.
+
+    The remainder of the AS request processing is normal, with the noted
+    substitution of the alternate principal's key for the user's.
+
+    The service, upon receiving a KRB_AS_REP, uses the alternate
+    principal's key to decrypt the enc-part, saves the user's credential
+    and takes appropriate measures to ensure that the KRB_AS_REP came
+    from a legitimate KDC and not an imposter.
+
+
+4.  IANA Considerations
+
+    No new naming or numbering spaces are created by this specification.
+    Two values from existing spaces are defined in [KRB5bis] for the
+    mechanism of this document:
+
+        The flag OPT-HARDWARE-AUTH is bit 11 in the kdc-options field of
+        a KDC-REQ-BODY.
+
+        The preauthentication type PA-ALT-PRINC is denoted by padata-
+        type 24.
+
+
+
+
+Expires April 26, 2007          Crawford                        [Page 4]
+
+Internet Draft    Passwordless Hardware Authentication   21 October 2006
+
+
+5.  Security Considerations
+
+    There are no means provided here for protecting the traffic between
+    the user and the service, so it may be susceptible to eavesdropping,
+    hijacking and alteration.  This authentication mechanism is not
+    intended to be used as an alternative to the Kerberos client/server
+    authentication exchange, but as an improvement over making an
+    unprotected connection with a Kerberos password alone, or a password
+    plus a single-use authenticator.
+
+    The alternate principal's key MUST be involved in construction of
+    the PA-SAM-RESPONSE (or PA-SAM-RESPONSE2) padata-value, to prevent
+    an adversary constructing a KRB_AS_REQ using that data but a
+    different alternate principal.  In practice, this means that the
+    response data alone must not determine the encryption key for the
+    padata-value.
+
+    A service impersonator can obtain a presumably-valid SAM response
+    from the user which may (or may not) be usable for impersonating the
+    user at a later time.  And of course in the case of successful
+    authentication the service obtains access to the user's credentials.
+    As always, if the service host is compromised, so are the
+    credentials; but, with this mechanism, at least the service host
+    never has access to the user's password.
+
+    A service host which accepts a Kerberos password for access
+    typically protects itself against an impostor KDC by using the
+    received ticket-granting credential to get a ticket for a service
+    for which it has the key.  This step may be unnecessary when the
+    service host has already successfully used such a key to decrypt the
+    ticket-granting credential itself.
+
+    Use of this authentication method employs the service's long-term
+    key, providing more ciphertext in that key to an eavesdropper.  This
+    key is generally of better quality than a password-derived key and
+    any remaining concerns about the strength of the KRB_AS_REP are
+    better addressed by a general mechanism applicable to all AS
+    exchanges.
+
+
+6.  Acknowledgments
+
+    The first implementation of this extension grew from a beginning by
+    Ken Hornstein, which in turn was built on code released by the MIT
+    Kerberos Team.
+
+
+
+
+
+
+Expires April 26, 2007          Crawford                        [Page 5]
+
+Internet Draft    Passwordless Hardware Authentication   21 October 2006
+
+
+7.  References
+
+    [FTPSEC]  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
+              2228.
+
+    [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510.
+
+    [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120.
+
+    [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
+        Requirement Levels," RFC 2119, March 1997.
+
+    [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option",
+              RFC 2941.
+
+8.  Author's Address
+
+    Matt Crawford
+    Fermilab MS 368
+    PO Box 500
+    Batavia, IL 60510
+    USA
+
+    Phone: +1 630 840-3461
+    EMail: crawdad@fnal.gov
+
+Disclaimer of Validity
+
+    This document and the information contained herein are provided on
+    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+    INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+    Copyright (C) The Internet Trust (2006).  This document is subject
+    to the rights, licenses and restrictions contained in BCP 78, and
+    except as set forth therein, the authors retain all their rights.
+
+
+    Acknowledgment
+
+
+
+
+Expires April 26, 2007          Crawford                        [Page 6]
+
+Internet Draft    Passwordless Hardware Authentication   21 October 2006
+
+
+    Funding for the RFC Editor function is currently provided by the
+    Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires April 26, 2007          Crawford                        [Page 7]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kdc-model-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kdc-model-03.txt
new file mode 100644
index 00000000000..39c123a686a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kdc-model-03.txt
@@ -0,0 +1,1064 @@
+
+
+
+KERBEROS WORKING GROUP                                         Johansson
+Internet-Draft                                      Stockholm university
+Intended status: Standards Track                        November 3, 2008
+Expires: May 7, 2009
+
+
+              An information model for Kerberos version 5
+                     draft-ietf-krb-wg-kdc-model-03
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on May 7, 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 1]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+Abstract
+
+   This document describes an information model for Kerberos version 5
+   from the point of view of an administrative service.  There is no
+   standard for administrating a kerberos 5 KDC.  This document
+   describes the services exposed by an administrative interface to a
+   KDC.
+
+
+Table of Contents
+
+   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  How to interpret RFC2119 terms . . . . . . . . . . . . . . . .  5
+   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Information model demarcation  . . . . . . . . . . . . . . . .  7
+   6.  Information model specification  . . . . . . . . . . . . . . .  8
+     6.1.  Principal  . . . . . . . . . . . . . . . . . . . . . . . .  8
+       6.1.1.  Principal: Attributes  . . . . . . . . . . . . . . . .  8
+       6.1.2.  Principal: Associations  . . . . . . . . . . . . . . .  9
+       6.1.3.  Principal: Remarks . . . . . . . . . . . . . . . . . . 10
+     6.2.  KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+       6.2.1.  KeySet: Attributes . . . . . . . . . . . . . . . . . . 10
+       6.2.2.  KeySet: Associations . . . . . . . . . . . . . . . . . 10
+       6.2.3.  KeySet: Remarks  . . . . . . . . . . . . . . . . . . . 10
+     6.3.  Key  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+       6.3.1.  Key: Attributes  . . . . . . . . . . . . . . . . . . . 11
+       6.3.2.  Key: Associations  . . . . . . . . . . . . . . . . . . 12
+       6.3.3.  Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12
+     6.4.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+       6.4.1.  Policy: Attributes . . . . . . . . . . . . . . . . . . 12
+       6.4.2.  Mandatory-to-implement Policy  . . . . . . . . . . . . 13
+   7.  Implementation Scenarios . . . . . . . . . . . . . . . . . . . 14
+     7.1.  LDAP backend to KDC  . . . . . . . . . . . . . . . . . . . 14
+     7.2.  LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 14
+     7.3.  SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
+   Intellectual Property and Copyright Statements . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 2]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+1.  Requirements notation
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 3]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+2.  Introduction
+
+   The Kerberos version 5 authentication service described in [RFC4120]
+   describes how a Key Distribution Service (KDC) provides
+   authentication to clients.  The standard does not stipulate how a KDC
+   is managed and several "kadmin" servers have evolved.  This document
+   describes the services required to administrate a KDC and the
+   underlying information model assumed by a kadmin-type service.
+
+   The information model is written in terms of "attributes" and
+   "services" or "interfaces" but the use of these particular words MUST
+   NOT be taken to imply any particular modeling paradigm so that
+   neither an object oriented model or an LDAP schema is intended.  The
+   author has attempted to describe in natural language the intended
+   semantics and syntax of the components of the model.  An LDAP schema
+   (for instance) based on this model will be more precise in the
+   expression of the syntax while preserving the semantics of this
+   model.
+
+   Implementations of this document MAY decide to change the names used
+   (eg principalName).  If so an implementation MUST provide a name to
+   name mapping to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 4]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+3.  How to interpret RFC2119 terms
+
+   This document describes an information model for kerberos 5 but does
+   not directly describe any mapping onto a particular schema- or
+   modelling language.  Hence an implementation of this model consists
+   of a mapping to such a language - eg an LDAP or SQL schema.  The
+   precise interpretation of terms from [RFC2119] therefore require some
+   extra explanation.  The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL
+   NOT mean that an implementation MUST provide a feature but does not
+   mean that this feature MUST be REQUIRED by the implementation - eg an
+   attribute is available in an LDAP schema but marked as OPTIONAL.  If
+   a feature must be implemented and REQUIRED this is made explicit in
+   this model.  The term MAY, OPTIONAL and RECOMMENDED means that an
+   implementation MAY need to REQUIRE the feature due to the particular
+   nature of the schema/modelling language.  In some cases this is
+   expressly forbidden by this model (feature X MUST NOT be REQUIRED by
+   an implementation).
+
+   Note that any implementation of this model SHOULD be published as an
+   RFC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 5]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+4.  Acknowledgments
+
+   Love Hoernquist-Aestrand <lha@it.su.se> for important contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 6]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+5.  Information model demarcation
+
+   The information model specified in the next chapter describes
+   objects, properties of those objects and relations between those
+   objects.  These elements comprise an abstract view of the data
+   represented in a KDC.  It is important to understand that the
+   information model is not a schema.  In particular the way objects are
+   compared for equality beyond that which is implied by the
+   specification of a syntax is not part of this specification.  Nor is
+   ordering specified between elements of a particular syntax.
+
+   Further work on Kerberos will undoubtedly prompt updates to this
+   information model to reflect changes in the functions performed by
+   the KDC.  Such extensions to the information model MUST always use a
+   normative reference to the relevant RFCs detailing the change in KDC
+   function.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 7]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+6.  Information model specification
+
+6.1.  Principal
+
+   The fundamental entity stored in a KDC is the principal.  The
+   principal is associated to keys and generalizes the "user" concept.
+   The principal MUST be implemented in full and MUST NOT be optional in
+   an implementation
+
+6.1.1.  Principal: Attributes
+
+6.1.1.1.  principalName
+
+   The principalName MUST uniquely identify the principal within the
+   administrative context of the KDC.  The type of the principalName is
+   not described in this document.  It is a unique identifier and can be
+   viewed as an opaque byte string which can be compared for equality.
+   The attribute SHOULD be single valued.  If an implementation supports
+   multiple values it MUST treat one of the values as special and allow
+   it to be fetched as if it was a single value.
+
+6.1.1.2.  principalNotUsedBefore
+
+   The principal may not be used before this date.  The syntax of the
+   attribute MUST be semantically equivalent with the standard ISO date
+   format.  The attribute MUST be single valued.
+
+6.1.1.3.  principalNotUsedAfter
+
+   The principal may not be used after this date.  The syntax of the
+   attribute MUST be semantically equivalent with the standard ISO date
+   format.  The attribute MUST be single valued.
+
+6.1.1.4.  principalIsDisabled
+
+   A boolean attribute used to (temporarily) disable a principal.  The
+   attribute MUST default to false.
+
+6.1.1.5.  principalAliases
+
+   This multivalued attribute contains an unordered set of aliases for
+   the principal.  Each alias SHOULD be unique within the administrative
+   domain represented by the KDC.  The syntax of an alias is an opaque
+   identifier which can be compared for equality.
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 8]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+6.1.1.6.  principalNumberOfFailedAuthenticationAttempts
+
+   This single valued integer attribute contains a count of the number
+   of times an authentication attempt was unsuccessful for this
+   principal.  Implementations SHOULD NOT allow this counter to be
+   reset.
+
+6.1.1.7.  principalLastFailedAuthentication
+
+   This single valued attribute contains the time and date for the last
+   failed authentication attempt for this principal.
+
+6.1.1.8.  principalLastSuccessfulAuthentication
+
+   This single valued attribute contains the time and date for the last
+   successful authentication attempt for this principal.
+
+6.1.1.9.  principalLastCredentialChange
+
+   This single valued attribute contains the time and date for the last
+   successful change of credential (eg password) this principal.
+
+6.1.1.10.  principalCreateTime
+
+   This single valued attribute contains the time and date when this
+   principal was created
+
+6.1.1.11.  principalModdifyTime
+
+   This single valued attribute contains the time and date when this
+   principal was modified excluding credentials change.
+
+6.1.1.12.  principalMaximumTicketLifetime
+
+   This single valued attribute contains the delta time in seconds
+   representing the maximum ticket lifetime for tickets issued for this
+   principal.
+
+6.1.1.13.  principalMaximumRenewableTicketLifetime
+
+   This single valued attribute contains the delta time in seconds
+   representing the maximum amount of time a ticket may be renewed for.
+
+6.1.2.  Principal: Associations
+
+   Each principal MAY be associated with 1 or more KeySet and MAY be
+   associated with 1 or more Policies.  The KeySet is represented as an
+   object in this model since it has attributes associated with it (the
+
+
+
+Johansson                  Expires May 7, 2009                  [Page 9]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+   key version number).  In typical situations the principal is
+   associated with exactly 1 KeySet but implementations MUST NOT assume
+   this case, i.e an implemenation of this standard (e.g an LDAP schema)
+   MUST be able to handle the general case of multiple KeySet associated
+   with each principal.
+
+6.1.3.  Principal: Remarks
+
+   Traditionally a principal consists of a local-part and a realm
+   denoted in string form by local-part@REALM.  The realm concept is
+   used to provide administrative boundaries and together with cross-
+   realm authentication provides scalability to Kerberos 5.  However the
+   realm is not central to an administrative information model.  For
+   instance the initialization or creation of a realm is equivalent to
+   creating a specific set of principals (krbtgt@REALM, etc) which is
+   covered by the model and services described in this document.  A
+   realm is typically associated with policy covering (for instance)
+   keying and password management.  The management of such policy and
+   their association to realms is beyond the scope of this document.
+
+6.2.  KeySet
+
+   A KeySet is a set of keys associated with exactly one principal.
+   This object and its associations MUST NOT be REQUIRED by an
+   implementation.  It is expected that most implementations of this
+   standard will use the set/change password protocol for all aspects of
+   key management [I-D.ietf-krb-wg-kerberos-set-passwd].  This
+   information model only includes these objects for the sake of
+   completenes.
+
+6.2.1.  KeySet: Attributes
+
+6.2.1.1.  keySetVersionNumber
+
+   This is traditionally called the key version number (kvno).  This is
+   a single valued attribute containing a positive integer.
+
+6.2.2.  KeySet: Associations
+
+   To each KeySet MUST be associated a set of 1 or more Keys.
+
+6.2.3.  KeySet: Remarks
+
+   The reason for separating the KeySet from the Principal is security.
+   The security of Kerberos 5 depends absolutely on the security of the
+   keys stored in the KDC.  The KeySet type is provided to make this
+   clear and to make separation of keys from other parts of the model
+   clear.
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 10]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+   Implementations of this standard (eg an LDAP schema) MUST make a
+   clear separation between the representation of KeySet from other
+   information objects.
+
+6.3.  Key
+
+   Implementations of this model MUST NOT REQUIRE keys to be
+   represented.
+
+6.3.1.  Key: Attributes
+
+6.3.1.1.  keyEncryptionType
+
+   The enctype SHOULD be represented as an enumeration of the enctypes
+   supported by the KDC.
+
+6.3.1.2.  keyValue
+
+   The binary representation of the key data.  This MUST be a single
+   valued octet string.
+
+6.3.1.3.  keySaltValue
+
+   The binary representation of the key salt.  This MUST be a single
+   valued octet string.
+
+6.3.1.4.  keyStringToKeyParameter
+
+   This MUST be a single valued octet string representing an opaque
+   parameter associated with the enctype.
+
+6.3.1.5.  keyNotUsedAfter
+
+   This key MUST NOT be used after this date.  The syntax of the
+   attribute MUST be semantically equivalent with the standard ISO date
+   format.  This MUST be a single-valued attribute.
+
+6.3.1.6.  keyNotUsedBefore
+
+   This key MUST NOT be used before this date.  The syntax of the
+   attribute MUST be semantically equivalent with the standard ISO date
+   format.  This MUST be a single-valued attribute.
+
+6.3.1.7.  keyIsDisabled
+
+   This is a boolean attribute which must be set to false by default.
+   If this attribute is true the key MUST NOT be used.  This is used to
+   temporarily disable a key.
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 11]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+6.3.2.  Key: Associations
+
+   None
+
+6.3.3.  Key: Remarks
+
+   The security of the keys is an absolute requirement for the operation
+   of Kerberos 5.  If keys are implemented adequate protection from
+   unauthorized modification and disclosure MUST be available and
+   REQUIRED by the implementation.
+
+6.4.  Policy
+
+   Implementations SHOULD implement policy but MAY allow them to be
+   OPTIONAL.  The Policy should be thought of as a 'typed hole'. i.e an
+   opaque binary value paired with an identifier of type of data
+   contained in the binary value.  Both attributes (type and value) must
+   be present.
+
+6.4.1.  Policy: Attributes
+
+6.4.1.1.  policyIdentifier
+
+   The policyIdentifier MUST be unique within the local administrative
+   context and MUST be globally unique.  Possible types of identifiers
+   include:
+
+      An Object Identifier (OID)
+
+      A URN
+
+      A UUID
+
+   The use of OIDs is recommended for this purpose.
+
+6.4.1.2.  policyIsCritical
+
+   This boolean attribute indicates that the KDC MUST be able to
+   correctly interpret and apply this policy for the key to be used.
+
+6.4.1.3.  policyContent
+
+   This is an optional single opaque binary value used to store a
+   representation of the policy.  In general a policy cannot be fully
+   expressed using attribute-value pairs.  The policyContent is OPTIONAL
+   in the sense that an implementation MAY use it to store an opaque
+   value for those policy-types which are not directly representable in
+   that implementation.
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 12]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+6.4.1.4.  policyUse
+
+   This is an optional single enumerated string value used to describe
+   the applicability of the policy.  Implementations SHOULD provide this
+   attribute and MUST (if the attribute is implemented) describe the
+   enumerated set of possible values.
+
+6.4.2.  Mandatory-to-implement Policy
+
+   All implementations MUST be able to represent the policies listed in
+   this section.  Implementations are not required to use the same
+   underlying data-representation for the policyContent binary value but
+   SHOULD use the same OIDs as the policyIdentifier.
+
+6.4.2.1.  Password Quality Policy
+
+   Password quality policy controls the requirements placed by the KDC
+   on new passwords.  This policy SHOULD be identified by the OID <TBD>.
+
+6.4.2.2.  Password Management Policy
+
+   Password management policy controls how passwords are changed.  This
+   policy SHOULD be identified by the OID <TBD>.
+
+6.4.2.3.  Keying Policy
+
+   A keying policy specifies the association of enctypes with new
+   principals, i.e when a principal is created one of the possibly many
+   applicable keying policies determine the set of keys to associate
+   with the principal.  In general the expression of a keying policy may
+   require a Turing-complete language.  This policy SHOULD be identified
+   by the OID <TBD>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 13]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+7.  Implementation Scenarios
+
+   There are several ways to implement an administrative service for
+   Kerberos 5 based on this information model.  In this section we list
+   a few of them.
+
+7.1.  LDAP backend to KDC
+
+   Given an LDAP schema implementation of this information model it
+   would be possible to build an administrative service by backending
+   the KDC to a directory server where principals and keys are stored.
+   Using the security mechanisms available on the directory server keys
+   are protected from access by anyone apart from the KDC.
+   Administration of the principals, policy and other non-key data is
+   done through the directory server while the keys are modified using
+   the set/change password protocol
+   [I-D.ietf-krb-wg-kerberos-set-passwd].
+
+7.2.  LDAP frontend to KDC
+
+   An alternative way to provide a directory interface to the KDC is to
+   implement an LDAP-frontend to the KDC which exposes all non-key
+   objects as entries and attributes.  As in the example above all keys
+   are modified using the set/change password protocol
+   [I-D.ietf-krb-wg-kerberos-set-passwd].  In this scenario the
+   implementation would typically not use a traditional LDAP
+   implementation but treat LDAP as an access-protocol to data in the
+   native KDC database.
+
+7.3.  SOAP
+
+   Given an XML schema implementation of this information model it would
+   be possible to build a SOAP-interface to the KDC.  This demonstrates
+   the value of creating an abstract information model which is mappable
+   to multiple schema representations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 14]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+8.  Security Considerations
+
+   This document describes an abstract information model for Kerberos 5.
+   The Kerberos 5 protocol depends on the security of the keys stored in
+   the KDC.  The model described here assumes that keys MUST NOT be
+   transported in the clear over the network and furthermore that keys
+   are treated as write-only attributes that SHALL only be modified
+   (using the administrative interface) by the change-password protocol
+   [I-D.ietf-krb-wg-kerberos-set-passwd].
+
+   Exposing the object model of a KDC typically implies that objects can
+   be modified and/or deleted.  In a KDC not all principals are created
+   equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM
+   effectively disables the EXAMPLE.COM realm.  Hence access control is
+   paramount to the security of any implementation.  This document does
+   not (at the time of writing - leifj) mandate access control.  This
+   only implies that access control is beyond the scope of the standard
+   information model, i.e that access control may not be accessible via
+   any protocol based on this model.  If access control objects is
+   exposed via an extension to this model the presence of access control
+   may in itself provide points of attack by giving away information
+   about principals with elevated rights etc. etc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 15]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+9.  IANA Considerations
+
+   None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 16]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+10.2.  Informative References
+
+   [I-D.ietf-krb-wg-kerberos-set-passwd]
+              Williams, N., "Kerberos Set/Change Key/Password Protocol
+              Version 2", draft-ietf-krb-wg-kerberos-set-passwd-07 (work
+              in progress), September 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 17]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+Author's Address
+
+   Leif Johansson
+   Stockholm university
+   Avdelningen foer IT och Media
+   Stockholm  SE-106 91
+
+   Email: leifj@it.su.se
+   URI:   http://people.su.se/~leifj/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 18]
+
+Internet-Draft            KDC Information Model            November 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Johansson                  Expires May 7, 2009                 [Page 19]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt
new file mode 100644
index 00000000000..005ea86b0b7
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt
@@ -0,0 +1,7975 @@
+
+INTERNET-DRAFT                                          Clifford Neuman
+                                                                USC-ISI
+                                                                 Tom Yu
+                                                            Sam Hartman
+                                                            Ken Raeburn
+                                                                    MIT
+                                                          March 2, 2003
+                                              Expires 2 September, 2003
+
+            The Kerberos Network Authentication Service (V5)
+            draft-ietf-krb-wg-kerberos-clarifications-03.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-krb-wg-kerberos-clarifications-03.txt, and expires 2 September
+   2003.  Please send comments to: ietf-krb-wg@anl.gov
+
+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.
+
+
+
+March 2003                                                      [Page 1]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   This document contains a subset of the changes considered and
+   discussed in the Kerberos working group and is intended as an interim
+   description of Kerberos. Additional changes to the Kerberos protocol
+   have been proposed and will appear in a subsequent extensions
+   document.
+
+   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 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.
+
+
+
+
+March 2003                                                      [Page 2]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 Ts'o, 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 [KNT94].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+March 2003                                                      [Page 3]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                           TTaabbllee ooff CCoonntteennttss
+
+
+1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . .   9
+1.2. Choosing a principal with which to communicate  . . . . . . . .  10
+1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . .  11
+1.4. Extending Kerberos Without Breaking Interoperability  . . . . .  11
+1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . .  12
+1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . .  13
+1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . .  13
+1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . .  14
+2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . .  16
+2.1. Initial, pre-authenticated, and hardware authenticated
+      tickets  . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . .  17
+2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . .  18
+2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . .  18
+2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . .  19
+2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . .  20
+2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . .  21
+2.8. OK as Delegate  . . . . . . . . . . . . . . . . . . . . . . . .  21
+2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . .  22
+2.9.1. Renewable-OK  . . . . . . . . . . . . . . . . . . . . . . . .  22
+2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . .  22
+2.9.3. Passwordless Hardware Authentication  . . . . . . . . . . . .  22
+3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . .  23
+3.1. The Authentication Service Exchange . . . . . . . . . . . . . .  23
+3.1.1. Generation of KRB_AS_REQ message  . . . . . . . . . . . . . .  24
+3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . .  24
+3.1.3. Generation of KRB_AS_REP message  . . . . . . . . . . . . . .  25
+3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . .  27
+3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . .  28
+3.1.6. Receipt of KRB_ERROR message  . . . . . . . . . . . . . . . .  29
+3.2. The Client/Server Authentication Exchange . . . . . . . . . . .  29
+3.2.1. The KRB_AP_REQ message  . . . . . . . . . . . . . . . . . . .  29
+3.2.2. Generation of a KRB_AP_REQ message  . . . . . . . . . . . . .  29
+3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . .  30
+3.2.4. Generation of a KRB_AP_REP message  . . . . . . . . . . . . .  32
+3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . .  33
+3.2.6. Using the encryption key  . . . . . . . . . . . . . . . . . .  33
+3.3. The Ticket-Granting Service (TGS) Exchange  . . . . . . . . . .  34
+3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . .  35
+3.3.2. Receipt of KRB_TGS_REQ message  . . . . . . . . . . . . . . .  37
+3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . .  37
+3.3.3.1. Checking for revoked tickets  . . . . . . . . . . . . . . .  40
+3.3.3.2. Encoding the transited field  . . . . . . . . . . . . . . .  40
+3.3.4. Receipt of KRB_TGS_REP message  . . . . . . . . . . . . . . .  42
+
+
+
+March 2003                                                      [Page 4]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . .  42
+3.4.1. Generation of a KRB_SAFE message  . . . . . . . . . . . . . .  42
+3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . .  43
+3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . .  44
+3.5.1. Generation of a KRB_PRIV message  . . . . . . . . . . . . . .  44
+3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . .  44
+3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . .  45
+3.6.1. Generation of a KRB_CRED message  . . . . . . . . . . . . . .  45
+3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . .  46
+3.7. User to User Authentication Exchanges . . . . . . . . . . . . .  46
+4. Encryption and Checksum Specifications  . . . . . . . . . . . . .  48
+5. Message Specifications  . . . . . . . . . . . . . . . . . . . . .  49
+5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . .  51
+5.1.1. ASN.1 Distinguished Encoding Rules  . . . . . . . . . . . . .  51
+5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . .  51
+5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . .  51
+5.1.4. Unrecognized Tag Numbers  . . . . . . . . . . . . . . . . . .  52
+5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . .  52
+5.2. Basic Kerberos Types  . . . . . . . . . . . . . . . . . . . . .  52
+5.2.1. KerberosString  . . . . . . . . . . . . . . . . . . . . . . .  52
+5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . .  54
+5.2.3. KerberosTime  . . . . . . . . . . . . . . . . . . . . . . . .  54
+5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . .  55
+5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . .  55
+5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . .  56
+5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . .  57
+5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . .  57
+5.2.6.3. AND-OR  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
+5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . .  59
+5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . .  59
+5.2.7.1. PA-TGS-REQ  . . . . . . . . . . . . . . . . . . . . . . . .  60
+5.2.7.2. Encrypted Timestamp Pre-authentication  . . . . . . . . . .  60
+5.2.7.3. PA-PW-SALT  . . . . . . . . . . . . . . . . . . . . . . . .  61
+5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . .  61
+5.2.7.5. PA-ETYPE-INFO2  . . . . . . . . . . . . . . . . . . . . . .  62
+5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . .  63
+5.2.9. Cryptosystem-related Types  . . . . . . . . . . . . . . . . .  64
+5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . .  65
+5.4. Specifications for the AS and TGS exchanges . . . . . . . . . .  73
+5.4.1. KRB_KDC_REQ definition  . . . . . . . . . . . . . . . . . . .  73
+5.4.2. KRB_KDC_REP definition  . . . . . . . . . . . . . . . . . . .  80
+5.5. Client/Server (CS) message specifications . . . . . . . . . . .  84
+5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . .  84
+5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . .  87
+5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . .  88
+5.6. KRB_SAFE message specification  . . . . . . . . . . . . . . . .  88
+5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . .  88
+5.7. KRB_PRIV message specification  . . . . . . . . . . . . . . . .  90
+
+
+
+March 2003                                                      [Page 5]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . .  90
+5.8. KRB_CRED message specification  . . . . . . . . . . . . . . . .  91
+5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . .  91
+5.9. Error message specification . . . . . . . . . . . . . . . . . .  93
+5.9.1. KRB_ERROR definition  . . . . . . . . . . . . . . . . . . . .  93
+5.10. Application Tag Numbers  . . . . . . . . . . . . . . . . . . .  95
+6. Naming Constraints  . . . . . . . . . . . . . . . . . . . . . . .  96
+6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . .  96
+6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . .  98
+6.2.1. Name of server principals . . . . . . . . . . . . . . . . . .  99
+7. Constants and other defined values  . . . . . . . . . . . . . . . 100
+7.1. Host address types  . . . . . . . . . . . . . . . . . . . . . . 100
+7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101
+7.2.1. UDP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 101
+7.2.2. TCP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 101
+7.2.3. KDC Discovery on IP Networks  . . . . . . . . . . . . . . . . 103
+7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names  . . . . 103
+7.2.3.2. Specifying KDC Location information with DNS SRV
+      records  . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
+7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
+      Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
+7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 104
+7.4. OID arc for KerberosV5  . . . . . . . . . . . . . . . . . . . . 104
+7.5. Protocol constants and associated values  . . . . . . . . . . . 104
+7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105
+7.5.2. PreAuthentication Data Types  . . . . . . . . . . . . . . . . 106
+7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 107
+7.5.4. Authorization Data Types  . . . . . . . . . . . . . . . . . . 107
+7.5.5. Transited Encoding Types  . . . . . . . . . . . . . . . . . . 107
+7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 107
+7.5.7. Kerberos Message Types  . . . . . . . . . . . . . . . . . . . 108
+7.5.8. Name Types  . . . . . . . . . . . . . . . . . . . . . . . . . 108
+7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 108
+8. Interoperability requirements . . . . . . . . . . . . . . . . . . 110
+8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 110
+8.2. Recommended KDC values  . . . . . . . . . . . . . . . . . . . . 113
+9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 113
+10. Security Considerations  . . . . . . . . . . . . . . . . . . . . 113
+11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
+12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 117
+13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
+A. ASN.1 module  . . . . . . . . . . . . . . . . . . . . . . . . . . 120
+B. Changes since RFC-1510  . . . . . . . . . . . . . . . . . . . . . 129
+END NOTES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
+
+
+
+
+
+
+
+March 2003                                                      [Page 6]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+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 (outside the scope of this
+   document) can provide for the use of public key cryptography during
+   certain phases of the authentication protocol [@RFCE: if PKINIT
+   advances concurrently include reference to the RFC here]. Such
+   extensions support Kerberos authentication for users registered with
+   public key certification authorities and 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 a "ticket" for the server and 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 [ref to GSSAPI RFC]. 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
+
+
+
+March 2003                                                      [Page 7]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 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 sub-session 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
+
+
+
+March 2003                                                      [Page 8]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 may be 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.
+
+
+
+March 2003                                                      [Page 9]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 KDCs
+   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 KDCs not check
+   the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
+   are encouraged but not required to honor this flag.
+
+1.2. Choosing a principal with which to communicate
+
+   The Kerberos protocol provides the means for verifying (subject to
+   the assumptions in 1.5) that the entity with which one communicates
+   is the same entity that was registered with the KDC using the claimed
+   identity (principal name). It is still necessary to determine whether
+   that identity corresponds to the entity with which one intends to
+   communicate.
+
+   When appropriate data has been exchanged in advance, this
+   determination may be performed syntactically by the application based
+   on the application protocol specification, information provided by
+   the user, and configuration files. For example, the server principal
+   name (including realm) for a telnet server might be derived from the
+   user specified host name (from the telnet command line), the "host/"
+   prefix specified in the application protocol specification, and a
+   mapping to a Kerberos realm derived syntactically from the domain
+   part of the specified hostname and information from the local
+   Kerberos realms database.
+
+   One can also rely on trusted third parties to make this
+   determination, but only when the data obtained from the third party
+   is suitably integrity protected while resident on the third party
+   server and when transmitted.  Thus, for example, one should not rely
+   on an unprotected domain name system record to map a host alias to
+   the primary name of a server, accepting the primary name as the party
+   one intends to contact, since an attacker can modify the mapping and
+   impersonate the party with which one intended to communicate.
+
+   Implementations of Kerberos and protocols based on Kerberos MUST NOT
+   use insecure DNS queries to canonicalize the hostname components of
+   the service principal names.  In an environment without secure name
+   service, application authors MAY append a statically configured
+   domain name to unqualified hostnames before passing the name to the
+   security mechanisms, but should do no more than that.  Secure name
+   service facilities, if available, might be trusted for hostname
+   canonicalization, but such canonicalization by the client SHOULD NOT
+
+
+
+March 2003                                                     [Page 10]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   be required by an KDC implementation.
+
+   Implementation note: Many current implementations do some degree of
+   canonicalization of the provided service name, often using DNS even
+   though it creates security problems. However there is no consistency
+   among implementations about whether the service name is case folded
+   to lower case or whether reverse resolution is used. To maximize
+   interoperability and security, applications SHOULD provide security
+   mechanisms with names which result from folding the user-entered name
+   to lower case, without performing any other modifications or
+   canonicalization.
+
+1.3. 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 utilize files on 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 ticket's authorization data when encapsulated by the
+   KDC-issued authorization data element.
+
+   Applications should not 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.4. Extending Kerberos Without Breaking Interoperability
+
+   As the deployed base of Kerberos implementations grows, extending
+   Kerberos becomes more important. Unfortunately some extensions to the
+   existing Kerberos protocol create interoperability issues because of
+   uncertainty regarding the treatment of certain extensibility options
+   by some implementations. This section includes guidelines that will
+
+
+
+March 2003                                                     [Page 11]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   enable future implementations to maintain interoperability.
+
+   Kerberos provides a general mechanism for protocol extensibility.
+   Some protocol messages contain typed holes -- sub-messages that
+   contain an octet-string along with an integer that defines how to
+   interpret the octet-string. The integer types are registered
+   centrally, but can be used both for vendor extensions and for
+   extensions standardized through the IETF.
+
+1.4.1. Compatibility with RFC 1510
+
+   It is important to note that existing Kerberos message formats can
+   not be readily extended by adding fields to the ASN.1 types. Sending
+   additional fields often results in the entire message being discarded
+   without an error indication. Future versions of this specification
+   will provide guidelines to ensure that ASN.1 fields can be added
+   without creating an interoperability problem.
+
+   In the meantime, all new or modified implementations of Kerberos that
+   receive an unknown message extension SHOULD preserve the encoding of
+   the extension but otherwise ignore the presence of the extension.
+   Recipients MUST NOT decline a request simply because an extension is
+   present.
+
+   There is one exception to this rule. If an unknown authorization data
+   element type is received by a server other than the ticket granting
+   service either in an AP-REQ or in a ticket contained in an AP-REQ,
+   then authentication MUST fail. One of the primary uses of
+   authorization data is to restrict the use of the ticket. If the
+   service cannot determine whether the restriction applies to that
+   service then a security weakness may result if the ticket can be used
+   for that service. Authorization elements that are optional SHOULD be
+   enclosed in the AD-IF-RELEVANT element.
+
+   The ticket granting service MUST ignore but propagate to derivative
+   tickets any unknown authorization data types, unless those data types
+   are embedded in a MANDATORY-FOR-KDC element, in which case the
+   request will be rejected.  This behavior is appropriate because
+   requiring that the ticket granting service understand unknown
+   authorization data types would require that KDC software be upgraded
+   to understand new application-level restrictions before applications
+   used these restrictions, decreasing the utility of authorization data
+   as a mechanism for restricting the use of tickets. No security
+   problem is created because services to which the tickets are issued
+   will verify the authorization data.
+
+   Implementation note: Many RFC 1510 implementations ignore unknown
+   authorization data elements. Depending on these implementations to
+
+
+
+March 2003                                                     [Page 12]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   honor authorization data restrictions may create a security weakness.
+
+1.4.2. Sending Extensible Messages
+
+   Care must be taken to ensure that old implementations can understand
+   messages sent to them even if they do not understand an extension
+   that is used. Unless the sender knows an extension is supported, the
+   extension cannot change the semantics of the core message or
+   previously defined extensions.
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence. The KDC should
+   only use the extension if this padata element is present in the AS-
+   REQ. Even if policy requires the use of the extension, it is better
+   to return an error indicating that the extension is required than to
+   use the extension when the recipient may not support it; debugging
+   why implementations do not interoperate is easier when errors are
+   returned.
+
+1.5. 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 the 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 not-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.
+
+
+
+March 2003                                                     [Page 13]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   *  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.6. 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.
+
+
+
+March 2003                                                     [Page 14]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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.
+
+   Encryption Type (etype)
+      When associated with encrypted data, an encryption type identifies
+      the algorithm used to encrypt the data and is used to select the
+      appropriate algorithm for decrypting the data.  Encryption type
+      tags are communicated in other messages to enumerate algorithms
+      that are desired, supported, preferred, or allowed to be used for
+      encryption of data between parties.  This preference is combined
+      with local information and policy to select an algorithm to be
+      used.
+
+   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
+      The name given to the Project Athena's authentication service, the
+      protocol used by that service, or the code used to implement the
+      authentication service.  The name is adopted from the three-headed
+      dog which guards Hades.
+
+   Key Version Number (kvno)
+      A tag associated with encrypted data identifies which key was used
+      for encryption when a long lived key associated with a principal
+      changes over time.  It is used during the transition to a new key
+      so that the party decrypting a message can tell whether the data
+      was encrypted using the old or the new key.
+
+   Plaintext
+      The input to an encryption function or the output of a decryption
+
+
+
+March 2003                                                     [Page 15]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      function. Decryption transforms ciphertext into plaintext.
+
+   Principal
+      A named client or server entity that participates in a network
+      communication, with one name that is considered canonical.
+
+   Principal identifier
+      The canonical 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 MAY be derived
+      from a password.
+
+   Server
+      A particular Principal which provides a resource to network
+      clients.  The server is sometimes referred 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
+
+
+
+March 2003                                                     [Page 16]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   Each Kerberos ticket contains a set of flags which are used to
+   indicate 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 give examples of reasons to
+   use them. With the exception of the INVALID flag clients MUST ignore
+   ticket flags that are not recognized. KDCs MUST ignore KDC options
+   that are not recognized. Some implementations of RFC 1510 are known
+   to reject unknown KDC options, so clients may need to resend a
+   request without KDC new options absent if the request was rejected
+   when sent with option added since RFC 1510. Since new KDCs will
+   ignore unknown options, clients MUST confirm that the ticket returned
+   by the KDC meets their needs.
+
+   Note that it is not, in general, possible to determine whether an
+   option was not honored because it was not understood or because it
+   was rejected either through configuration or policy. When adding a
+   new option to the Kerberos protocol, designers should consider
+   whether the distinction is important for their option. In cases where
+   it is, a mechanism for the KDC to return an indication that the
+   option was understood but rejected needs to be provided in the
+   specification of the option. Often in such cases, the mechanism needs
+   to be broad enough to permit an error or reason to be returned.
+
+2.1. Initial, pre-authenticated, and hardware authenticated tickets
+
+   The INITIAL flag indicates that a ticket was issued using the AS
+   protocol, rather than 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 additional 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 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
+
+
+
+March 2003                                                     [Page 17]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 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
+
+
+
+March 2003                                                     [Page 18]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   leave them "dormant" until they are activated and validated by a
+   further request of the KDC. If a ticket theft were reported in the
+   interim, the KDC would refuse to validate the ticket, and the thief
+   would be foiled.
+
+   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
+   ticket-granting service. It can be ignored by application servers.
+   This flag MUST be set in a ticket-granting ticket in order to issue a
+   postdated ticket based on the presented ticket. It is reset by
+   default; it MAY be requested by a client by setting the ALLOW-
+   POSTDATE option in the KRB_AS_REQ message.  This flag does not allow
+   a client to obtain a postdated ticket-granting ticket; postdated
+   ticket-granting tickets can only by obtained by requesting the
+   postdating in the KRB_AS_REQ message. The life (endtime-starttime) of
+   a postdated ticket will be the remaining life of the ticket-granting
+   ticket at the time of the request, unless the RENEWABLE option is
+   also set, in which case it can be the full life (endtime-starttime)
+   of the ticket-granting ticket. The KDC MAY limit how far in the
+   future a ticket may be postdated.
+
+   The POSTDATED flag indicates that a ticket has been postdated. The
+   application server can check the authtime field in the ticket to see
+   when the original authentication occurred. Some services MAY choose
+   to reject postdated tickets, or they may only accept them within a
+   certain period after the original authentication. When the KDC issues
+   a POSTDATED ticket, it will also be marked as INVALID, so that the
+   application client MUST present the ticket to the KDC to be validated
+   before use.
+
+2.5. Proxiable and proxy tickets
+
+   At times it may be necessary for a principal to allow a service to
+   perform an operation on its behalf. The service must be able to take
+   on the identity of the client, but only for a particular purpose. A
+   principal can allow a service to take on the principal's identity for
+   a particular purpose by granting it a proxy.
+
+   The process of granting a proxy using the proxy and proxiable flags
+   is used to provide credentials for use with specific services. Though
+   conceptually also a proxy, users wishing to delegate their identity
+   in a form usable for all 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
+
+
+
+March 2003                                                     [Page 19]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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
+   granted is 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
+
+
+
+March 2003                                                     [Page 20]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   tickets with the FORWARDED flag set. Application servers may choose
+   to process FORWARDED tickets differently than non-FORWARDED tickets.
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+2.7. Transited Policy Checking
+
+   In Kerberos, the application server is ultimately responsible for
+   accepting or rejecting authentication and SHOULD check that only
+   suitably trusted KDCs are relied upon to authenticate a principal.
+   The transited field in the ticket identifies which realms (and thus
+   which KDCs) were involved in the authentication process and an
+   application server would normally check this field. If any of these
+   are untrusted to authenticate the indicated client principal
+   (probably determined by a realm-based policy), the authentication
+   attempt MUST be rejected. The presence of trusted KDCs in this list
+   does not provide any guarantee; an untrusted KDC may have fabricated
+   the list.
+
+   While the end server ultimately decides whether authentication is
+   valid, the KDC for the end server's realm MAY apply a realm specific
+   policy for validating the transited field and accepting credentials
+   for cross-realm authentication. When the KDC applies such checks and
+   accepts such cross-realm authentication it will set the TRANSITED-
+   POLICY-CHECKED flag in the service tickets it issues based on the
+   cross-realm TGT. A client MAY request that the KDCs not check the
+   transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are
+   encouraged but not required to honor this flag.
+
+   Application servers MUST either do the transited-realm checks
+   themselves, or reject cross-realm tickets without TRANSITED-POLICY-
+   CHECKED set.
+
+2.8. OK as Delegate
+
+   For some applications a client may need to delegate authority to a
+   server to act on its behalf in contacting other services.  This
+   requires that the client forward credentials to an intermediate
+   server.  The ability for a client to obtain a service ticket to a
+   server conveys no information to the client about whether the server
+   should be trusted to accept delegated credentials.  The OK-AS-
+   DELEGATE provides a way for a KDC to communicate local realm policy
+   to a client regarding whether an intermediate server is trusted to
+   accept such credentials.
+
+   The OK-AS-DELEGATE flag from the copy of the ticket flags in the
+
+
+
+March 2003                                                     [Page 21]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   encrypted part of the KDC reply indicates to the client 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.  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.
+
+2.9. Other KDC options
+
+   There are three additional options which MAY be set in a client's
+   request of the KDC.
+
+2.9.1. Renewable-OK
+
+   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 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.
+
+2.9.2. ENC-TKT-IN-SKEY
+
+   In its basic form the Kerberos protocol supports authentication in a
+   client-server
+    setting and is not well suited to authentication in a peer-to-peer
+   environment because the long term key of the user does not remain on
+   the workstation after initial login. Authentication of such peers may
+   be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-
+   SKEY option supports user-to-user authentication by allowing the KDC
+   to issue a service ticket encrypted using the session key from
+   another ticket-granting ticket issued to another user. 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 additional second ticket-
+   granting ticket provided with the request. See section 3.3.3 for
+   specific details.
+
+2.9.3. Passwordless Hardware Authentication
+
+   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
+   some form of hardware authentication instead of or in addition to the
+   client's password or other long-lived encryption key. OPT-HARDWARE-
+
+
+
+March 2003                                                     [Page 22]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   AUTH is honored only by the authentication service. If supported and
+   allowed by policy, the KDC will return an errorcode
+   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
+   perform such authentication.
+
+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 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,
+   other information about the credentials it is requesting, and a
+   randomly generated nonce which can be used to detect replays, and to
+   associate replies with the matching requests. This nonce MUST be
+   generated randomly by the client and remembered for checking against
+   the nonce in the expected reply. 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.
+
+
+
+March 2003                                                     [Page 23]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   The encrypted part of the KRB_AS_REP message also contains the nonce
+   which MUST be matched with the nonce from the KRB_AS_REQ message.
+
+   Without pre-authentication, 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. However,
+   an attacker can send a KRB_AS_REQ message to get known plaintext in
+   order to attack the principal's key. Especially if the key is based
+   on a password, this may create a security exposure. So, 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 SHOULD be used for pre-authentication as described in
+   sections 3.1.1 and 5.2.7.
+
+   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
+   contents of the KRB_ERROR message are not integrity-protected. As
+   such, the client cannot detect replays, fabrications or
+   modifications. A solution to this problem will be included in a
+   future version of the protocol.
+
+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).
+
+   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. The contents of
+   the ticket are determined as follows.
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+
+
+
+March 2003                                                     [Page 24]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   If a KDC receives a request identical to one it has recently
+   successfully processed, the KDC MUST respond with a KRB_AS_REP
+   message rather than a replay error.  In order to reduce ciphertext
+   given to a potential attacker, KDCs MAY send the same response
+   generated when the request was first handled. KDCs MUST obey this
+   replay behavior even if the actual transport in use is reliable.
+
+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
+   known because it doesn't exist in the KDC's principal database, then
+   an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
+
+   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 pre-authentication is
+   required, but was not present in the request, an error message with
+   the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA
+   object will be stored in the e-data field of the KRB-ERROR message to
+   specify which pre-authentication mechanisms are acceptable.  Usually
+   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
+   described below. If the server cannot accommodate any encryption type
+   requested by the client, an error message with code
+   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
+   'random' session key[7].
+
+   When responding to an AS request, if there are multiple encryption
+   keys registered for a client in the Kerberos database, then the etype
+   field from the AS request is used by the KDC to select the encryption
+   method to be used to protect the encrypted part of the KRB_AS_REP
+   message which is sent to the client. If there is more than one
+   supported strong encryption type in the etype list, the KDC SHOULD
+   use the first valid strong etype for which an encryption key is
+   available.
+
+   When the user's key is generated from a password or pass phrase, the
+   string-to-key function for the particular encryption key type is
+   used, as specified in [@KCRYPTO]. The salt value and additional
+   parameters for the string-to-key function have default values
+   (specified by section 4 and by the encryption mechanism
+   specification, respectively) that may be overridden by pre-
+   authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
+   ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the
+   resulting key only, these values should not be changed for password-
+   based keys except when changing the principal's key.
+
+
+
+
+March 2003                                                     [Page 25]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   When the AS server is to include pre-authentication data in a KRB-
+   ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
+   if the etype field of the client's AS-REQ lists at least one "newer"
+   encryption type.  Otherwise (when the etype field of the client's AS-
+   REQ does not list any "newer" encryption types) it MUST send both,
+   PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
+   enctype).  A "newer" enctype is any enctype first officially
+   specified concurrently with or subsequent to the issue of this RFC.
+   The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
+   newer enctypes.
+
+   It is not possible to reliably generate a user's key given a pass
+   phrase without contacting the KDC, since it will not be known whether
+   alternate salt or parameter values are required.
+
+   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 earlier of the
+   requested endtime and a time determined by local policy, possibly
+   determined using realm or principal specific factors. For example,
+   the expiration time MAY be set to the earliest 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 from the authentication
+         server's database.
+
+
+
+
+March 2003                                                     [Page 26]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      *  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 MAY be set to the earliest 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 postdated (the start time is in the future), its
+   INVALID flag will also be set.
+
+   If all of the above succeed, the server will encrypt the ciphertext
+   part of the ticket using the encryption key extracted from the server
+   principal's record in the Kerberos database using the encryption type
+   associated with the server principal's key (this choice is NOT
+   affected by the etype field in the request). It then 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 an acceptable encryption
+   method requested in the etype field of the request, or in some key
+   specified by pre-authentication mechanisms being used.
+
+3.1.4. Generation of KRB_ERROR message
+
+
+
+
+March 2003                                                     [Page 27]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 last-
+   req field (and the deprecated key-expiration field) from the
+   encrypted part of the response MAY be checked to notify the user of
+   impending key expiration. This enables the client program to suggest
+   remedial action, such as a password change.
+
+   Upon validation of the KRB_AS_REP message (by checking the returned
+   nonce against that sent in the KRB_AS_REQ message) the client knows
+   that the current time on the KDC is that read from the authtime field
+   of the encrypted part of the reply. The client can optionally use
+   this value for clock synchronization in subsequent messages by
+   recording with the ticket the difference (offset) between the
+   authtime value and the local clock. This offset can then be used by
+   the same user to adjust the time read from the system clock when
+   generating messages [DGT96].
+
+   This technique MUST be used when adjusting for clock skew instead of
+   directly changing the system clock because the KDC reply is only
+   authenticated to the user whose secret key was used, but not to the
+   system or workstation. If the clock were adjusted, an attacker
+   colluding with a user logging into a workstation could agree on a
+   password, resulting in a KDC reply that would be correctly validated
+   even though it did not originate from a KDC trusted by the
+   workstation.
+
+   Proper decryption of the KRB_AS_REP message is not sufficient for the
+   host 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
+
+
+
+March 2003                                                     [Page 28]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   securely-stored secret key for the host. If those credentials can be
+   verified, then the identity of the user can be assured.
+
+3.1.6. Receipt of KRB_ERROR message
+
+   If the reply message type is KRB_ERROR, then the client interprets it
+   as an error and performs whatever application-specific tasks are
+   necessary to recover.
+
+3.2. The Client/Server Authentication Exchange
+
+                                Summary
+   Message direction                         Message type    Section
+   Client to Application server              KRB_AP_REQ      5.5.1
+   [optional] Application server to client   KRB_AP_REP or   5.5.2
+                                             KRB_ERROR       5.9.1
+
+   The client/server authentication (CS) exchange is used by network
+   applications to authenticate the client to the server and vice versa.
+   The client MUST have already acquired credentials for the server
+   using the AS or TGS exchange.
+
+3.2.1. The KRB_AP_REQ message
+
+   The KRB_AP_REQ contains authentication information which SHOULD be
+   part of the first message in an authenticated transaction. It
+   contains a ticket, an authenticator, and some additional bookkeeping
+   information (see section 5.5.1 for the exact format). The ticket by
+   itself is insufficient to authenticate a client, since tickets are
+   passed across the network in cleartext[8], 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 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[9]. If a sequence number
+   is to be included, it SHOULD be randomly chosen so that even after
+
+
+
+March 2003                                                     [Page 29]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 (for user to user authentication -
+   see section 3.7) 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.
+
+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 user-to-user authentication is in use, and that the ticket is
+   encrypted in the session key from the server's ticket-granting ticket
+   rather than in the server's secret key. See section 3.7 for a more
+   complete description of the affect of user to user authentication on
+   all messages in the Kerberos protocol.
+
+   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
+
+
+
+March 2003                                                     [Page 30]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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; this normally is caused by a client error or
+   attempted attack. 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.
+
+   Unless the application server provides its own suitable means to
+   protect against replay (for example, a challenge-response sequence
+   initiated by the server after authentication, or use of a server-
+   generated encryption subkey), the server MUST utilize a replay cache
+   to remember any authenticator presented within the allowable clock
+   skew. Careful analysis of the application protocol and implementation
+   is recommended before eliminating this cache. The replay cache will
+   store at least the server name, along with the client name, time and
+   microsecond fields from the recently-seen authenticators and if a
+   matching tuple is found, the KRB_AP_ERR_REPEAT error is returned
+   [10]. If a server loses track of authenticators presented within the
+   allowable clock skew, it MUST reject all requests until the clock
+   skew interval has passed, providing assurance that any lost or
+   replayed authenticators will fall outside the allowable clock skew
+   and can no longer be successfully replayed [11].
+
+   Implementation note: If a client generates multiple requests to the
+   KDC with the same timestamp, including the microsecond field, all but
+   the first of the requests received will be rejected as replays. This
+   might happen, for example, if the resolution of the client's clock is
+   too coarse.  Implementations SHOULD ensure that the timestamps are
+   not reused, possibly by incrementing the microseconds field in the
+   time stamp when the clock returns the same time for multiple
+   requests.
+
+   If multiple servers (for example, different services on one machine,
+   or a single service implemented on multiple machines) share a service
+   principal (a practice we do not recommend in general, but acknowledge
+   will be used in some cases), they should also share this replay
+   cache, or the application protocol should be designed so as to
+   eliminate the need for it. Note that this applies to all of the
+
+
+
+March 2003                                                     [Page 31]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   services, if any of the application protocols does not have replay
+   protection built in; an authenticator used with such a service could
+   later be replayed to a different service with the same service
+   principal but no replay protection, if the former doesn't record the
+   authenticator information in the common replay cache.
+
+   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.
+
+   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
+   access 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
+
+
+
+March 2003                                                     [Page 32]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   subkey. The KRB_AP_REP message is encrypted in the session key
+   extracted from the ticket.
+
+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.
+
+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.
+   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. 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 session key from the ticket and subkeys in
+   the KRB_AP_REP message and the authenticator [14]. To mitigate the
+   effect of failures in random number generation on the client it is
+   strongly encouraged that any key derived by an application for
+   subsequent use include the full key entropy derived from the KDC
+   generated session key carried in the ticket. 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 subsequent 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 communication patterns of
+   an application dictates the use of encryption modes of operation
+   incompatible with the encryption system used for the authenticator,
+   then a key compatible with the required encryption system may be
+   generated by either the client, the server, or collaboratively by
+   both and exchanged using the subkey field.  This generation might
+   involve the use of a random number as a pre-key, initially generated
+   by either party, which could then be encrypted using the session key
+   from the ticket, and the result exchanged and used for subsequent
+
+
+
+March 2003                                                     [Page 33]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   encryption. By encrypting the pre-key with the session key from the
+   ticket, randomness from the KDC generated key is assured of being
+   present in the negotiated key. Application developers must be careful
+   however, to use a means of introducing this entropy that does not
+   allow an attacker to learn the session key from the ticket if it
+   learns the key generated and used for subsequent communication. The
+   reader should note that this is only an example, and that an analysis
+   of the particular cryptosystem to be used, must be made before
+   deciding how to generate values for the subkey fields, and the key to
+   be used for subsequent communication.
+
+   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
+
+
+
+March 2003                                                     [Page 34]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   (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. The same comments about
+   integrity protection of KRB_ERROR messages mentioned in section 3.1
+   apply to the TGS exchange.
+
+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 believed to
+   be registered [15]. If the client knows 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 possesses 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 between the client's realm and the
+   requested realm server's realm). It should be noted in this case that
+   misconfiguration of the Kerberos servers may cause loops in the
+   resulting authentication path, which the client should be careful to
+   detect and avoid.
+
+   If the Kerberos server returns a TGT for a 'closer' realm other than
+   the desired realm, the client MAY use local policy configuration to
+   verify that the authentication path used is an acceptable one.
+   Alternatively, a client MAY choose its own authentication path,
+   rather than relying on the Kerberos server to select one. In either
+   case, any policy or configuration information used to choose or
+   validate authentication paths, whether by the Kerberos server or
+
+
+
+March 2003                                                     [Page 35]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   client, MUST be obtained from a trusted source.
+
+   When a client obtains a ticket-granting ticket that is 'closer' to
+   the destination realm, the client MAY cache this ticket and reuse it
+   in future KRB-TGS exchanges with services in the 'closer' realm.
+   However, if the client were to obtain a ticket-granting ticket for
+   the 'closer' realm by starting at the initial KDC rather than as part
+   of obtaining another ticket, then a shorter path to the 'closer'
+   realm might be used. This shorter path may be desirable because fewer
+   intermediate KDCs would know the session key of the ticket involved.
+   For this reason, clients SHOULD evaluate whether they trust the
+   realms transited in obtaining the 'closer' ticket when making a
+   decision to use the ticket in future.
+
+   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.
+
+   (This paragraph changed) As in the AS exchange, the client MAY
+   specify a number of options in the KRB_TGS_REQ message. One of these
+   options is the ENC-TKT-IN-SKEY option used for user-to-user
+   authentication. An overview of user to user authentication can be
+   found in section 3.7. When generating the KRB_TGS_REQ message, this
+   option indicates that the client is including a ticket-granting
+   ticket obtained from the application server in the additional tickets
+   field of the request and that the KDC SHOULD encrypt the ticket for
+   the application server using the session key from this additional
+   ticket, instead of using a server key from the principal database.
+
+   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-authorizatfion-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.
+
+
+
+
+March 2003                                                     [Page 36]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   Once prepared, the message is sent to a Kerberos server for the
+   destination realm.
+
+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.
+
+   As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
+   message if it receives a KRB_TGS_REQ message identical to one it has
+   recently processed. However, if the authenticator is a replay, but
+   the rest of the request is not identical, then the KDC SHOULD return
+   KRB_AP_ERR_REPEAT.
+
+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 or for a
+   ticket granting server of an intermediate KDC to be contacted to
+
+
+
+March 2003                                                     [Page 37]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   obtain the requested ticket. The Kerberos database is queried to
+   retrieve the record for the appropriate 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 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
+
+
+
+March 2003                                                     [Page 38]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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, it indicates that the client
+   is using user- to-user authentication to prove its identity to a
+   server that does not have access to a persistent key. Section 3.7
+   describes the affect of this option on the entire Kerberos protocol.
+   When generating the KRB_TGS_REP message, this option in the
+   KRB_TGS_REQ message tells the KDC to 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.
+
+   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 requested, 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 section, the KDC will issue the
+   appropriate new ticket.
+
+   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 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.
+
+
+
+March 2003                                                     [Page 39]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+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 to the KDC for the realm in which
+   the server resides. 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. If TGT's have
+   been issued for cross-realm authentication, use of the cross-realm
+   TGT will not be affected unless the hot-list is propagated to the
+   KDCs for the realms for which such cross-realm tickets were issued.
+
+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, if it is not the realm of the
+   client principal, 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.
+
+
+
+
+March 2003                                                     [Page 40]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 preceding 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.  For the purpose of appending, the realm
+   preceding the first listed realm is considered to be the null realm
+   ("").  If a realm name beginning with a "/" 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 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.  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.  Thus, "," means
+   that all realms along the path between the client and the server have
+   been traversed. ",EDU, /COM," means 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
+
+
+
+March 2003                                                     [Page 41]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 sub-session key from the Authenticator, if it
+   was specified in the request, or 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.
+
+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 occurred).
+
+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 the keyed
+   checksum mandated to be implemented along with the crypto system used
+   for the sub-session or session key. The checksum is generated using
+   the sub-session key if present, and the session key. Some
+   implementations use a different checksum algorithm for the KRB_SAFE
+   messages but doing so in a interoperable manner is not always
+   possible.
+
+   Implementations SHOULD accept any checksum algorithm they implement
+   that both have adequate security and that have keys compatible with
+   the sub-session or session key. 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.
+
+
+
+March 2003                                                     [Page 42]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 that uses keys compatible with the
+   sub-session or session key as appropriate (or with the application
+   key derived from the session or sub-session keys), and if it is not,
+   a KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address
+   MUST be 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. To work with network address translation, senders MAY use
+   the directional address type specified in section 8.1 for the sender
+   address and not include recipient addresses. 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) 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
+
+
+
+March 2003                                                     [Page 43]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   message was generated by its peer and was not modified 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 occurred). 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.
+
+   The sender's address MUST be 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.  If a recipient
+   address is specified or the recipient requires an address then one of
+   the recipient's addresses MUST also appear as the recipient's address
+   in the message.  Where a sender's or receiver's address might not
+   otherwise match the address in a message because of network address
+   translation, an application MAY be written to use addresses of the
+   directional address type in place of the actual network address.
+
+   A failed match for either case generates a KRB_AP_ERR_BADADDR error.
+   To work with network address translation, implementations MAY use the
+   directional address type defined in section 7.1 for the sender
+
+
+
+March 2003                                                     [Page 44]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   address and include no recipient address. 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 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 (and
+   communicated from the recipient to the sender by application specific
+   means) 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 previously exchanged in the KRB_AP exchange
+   (usually the last key negotiated via subkeys, or the session key if
+   no negotiation has occurred).
+
+   Implementation note: When constructing a KRB_CRED message for
+   inclusion in a GSSAPI initial context token, the MIT implementation
+   of Kerberos will not encrypt the KRB_CRED message if the session key
+   is a DES or triple DES key.  For interoperability with MIT, the
+   Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
+
+
+
+March 2003                                                     [Page 45]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   token if it is using a DES session key. Starting at version 1.2.5,
+   MIT Kerberos can receive and decode either encrypted or unencrypted
+   KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of
+   Kerberos can also accept either encrypted or unencrypted KRB_CRED
+   messages. Since the KRB_CRED message in a GSSAPI token is encrypted
+   in the authenticator, the MIT behavior does not present a security
+   problem, although it is a violation of the Kerberos specification.
+
+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 MAY verify 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. The address check does not
+   provide any added security, since the address if present has already
+   been checked in the KRB_AP_REQ message and there is not any benefit
+   to be gained by an attacker in reflecting a KRB_CRED message back to
+   its originator. Thus, the recipient MAY ignore the address even if
+   present in order to work better in NAT environments. A failed match
+   for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY
+   skip the address check as the KRB_CRED message cannot generally be
+   reflected back to the originator.  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 credentials cache together with the session key and
+   other information in the corresponding KrbCredInfo sequence from the
+   encrypted part of the KRB_CRED message.
+
+3.7. User to User Authentication Exchanges
+
+   User to User authentication provides a method to perform
+   authentication when the verifier does not have a access to long term
+   service key. This might be the case when running a server (for
+   example a window server) as a user on a workstation. In such cases,
+   the server may have access to the ticket-granting ticket obtained
+
+
+
+March 2003                                                     [Page 46]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   when the user logged in to the workstation, but because the server is
+   running as an unprivileged user it might not have access to system
+   keys. Similar situations may arise when running peer-to-peer
+   applications.
+
+                             Summary
+       Message direction                    Message type     Sections
+       0. Message from application server   Not Specified
+       1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
+       2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
+                                            KRB_ERROR        5.9.1
+       3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
+
+   To address this problem, the Kerberos protocol allows the client to
+   request that the ticket issued by the KDC be encrypted using a
+   session key from a ticket-granting ticket issued to the party that
+   will verify the authentication.  This ticket-granting ticket must be
+   obtained from the verifier by means of an exchange external to the
+   Kerberos protocol, usually as part of the application protocol. This
+   message is shown in the summary above as message 0. Note that because
+   the ticket-granting ticket is encrypted in the KDC's secret key, it
+   can not be used for authentication without posession of the
+   corresponding secret key.  Furthermore, because the verifier does not
+   reveal the corresponding secret key, providing a copy of the
+   verifier's ticket-granting ticket does not allow impersonation of the
+   verifier.
+
+   Message 0 in the table above represents an application specific
+   negotation between the client and server, at the end of which both
+   have determined that they will use user to user authentication and
+   the client has obtained the server's TGT.
+
+   Next, the client includes the server's TGT as an additional ticket in
+   its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
+   specifyies the ENC-TKT-IN-SKEY option in its request.
+
+   If validated according to the instructions in 3.3.3, the application
+   ticket returned to the client (message 2 in the table above) will be
+   encrypted using the session key from the additional ticket and the
+   client will note this when it uses or stores the application ticket.
+
+   When contacting the server using a ticket obtained for user to user
+   authentication (message 3 in the table above), the client MUST
+   specify the USE-SESSION-KEY flag in the ap-options field. This tells
+   the application server to use the session key associated with its
+   ticket-granting ticket to decrypt the server ticket provided in the
+   application request.
+
+
+
+
+March 2003                                                     [Page 47]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+4. Encryption and Checksum Specifications
+
+   The Kerberos protocols described in this document are designed to
+   encrypt messages of arbitrary sizes, using stream or block encryption
+   ciphers.  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.
+
+   [@KCRYPTO] defines a framework for defining encryption and checksum
+   mechanisms for use with Kerberos. It also defines several such
+   mechanisms, and more may be added in future updates to that document.
+
+   The string-to-key operation provided by [@KCRYPTO] is used to produce
+   a long-term key for a principal (generally for a user). The default
+   salt string, if none is provided via pre-authentication data, is the
+   concatenation of the principal's realm and name components, in order,
+   with no separators.  Unless otherwise indicated, the default string-
+   to-key opaque parameter set as defined in [@KCRYPTO] is used.
+
+   Encrypted data, keys and checksums are transmitted using the
+   EncryptedData, EncryptionKey and Checksum data objects defined in
+   section 5.2.9. The encryption, decryption, and checksum operations
+   described in this document use the corresponding encryption,
+   decryption, and get_mic operations described in [@KCRYPTO], with
+   implicit "specific key" generation using the "key usage" values
+   specified in the description of each EncryptedData or Checksum object
+   to vary the key for each operation. Note that in some cases, the
+   value to be used is dependent on the method of choosing the key or
+   the context of the message.
+
+   Key usages are unsigned 32 bit integers; zero is not permitted. The
+   key usage values for encrypting or checksumming Kerberos messages are
+   indicated in section 5 along with the message definitions. Key usage
+   values 512-1023 are reserved for uses internal to a Kerberos
+   implementation. (For example, seeding a pseudo-random number
+
+
+
+March 2003                                                     [Page 48]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   generator with a value produced by encrypting something with a
+   session key and a key usage value not used for any other purpose.)
+   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. Key usage values are
+   also summarized in a table in section 7.5.1.
+
+   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 specifications
+   continue to be meaningful until they are updated, if not key usage
+   values are specified then key usages 1024 and 1025 must be used to
+   derive keys for encryption and checksums, respectively (this does not
+   apply to protocols that do their own encryption independent of this
+   framework, directly using the key resulting from the Kerberos
+   authentication exchange.) New protocols defined in terms of the
+   Kerberos encryption and checksum types SHOULD use their own key usage
+   values.
+
+   Unless otherwise indicated, no cipher state chaining is done from one
+   encryption operation to another.
+
+   Implementation note: While not recommended, some application
+   protocols will continue to use the key data directly, even if only in
+   currently existing protocol specifications. An implementation
+   intended to support general Kerberos applications may therefore need
+   to make key data available, as well as the attributes and operations
+   described in [@KCRYPTO].  One of the more common reasons for directly
+   performing encryption is direct control over negotiation and
+   selection of a "sufficiently strong" encryption algorithm (in the
+   context of a given application). While Kerberos does not directly
+   provide a facility for negotiating encryption types between the
+   application client and server, there are approaches for using
+   Kerberos to facilitate this negotiation - for example, a client may
+   request only "sufficiently strong" session key types from the KDC and
+   expect that any type returned by the KDC will be understood and
+   supported by the application server.
+
+5. Message Specifications
+
+   NOTE: The ASN.1 collected here should be identical to the contents of
+   Appendix A. In case of conflict, the contents of Appendix A shall
+   take precedence.
+
+   The Kerberos protocol is defined here in terms of Abstract Syntax
+   Notation One (ASN.1) [X680], which provides a syntax for specifying
+   both the abstract layout of protocol messages as well as their
+   encodings. Implementors not utilizing an existing ASN.1 compiler or
+
+
+
+March 2003                                                     [Page 49]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   support library are cautioned to thoroughly understand the actual
+   ASN.1 specification to ensure correct implementation behavior, as
+   there is more complexity in the notation than is immediately obvious,
+   and some tutorials and guides to ASN.1 are misleading or erroneous.
+
+   Note that in several places, there have been changes here from RFC
+   1510 that change the abstract types. This is in part to address
+   widespread assumptions that various implementors have made, in some
+   cases resulting in unintentional violations of the ASN.1 standard.
+   These are clearly flagged where they occur. The differences between
+   the abstract types in RFC 1510 and abstract types in this document
+   can cause incompatible encodings to be emitted when certain encoding
+   rules, e.g. the Packed Encoding Rules (PER), are used. This
+   theoretical incompatibility should not be relevant for Kerberos,
+   since Kerberos explicitly specifies the use of the Distinguished
+   Encoding Rules (DER). It might be an issue for protocols wishing to
+   use Kerberos types with other encoding rules. (This practice is not
+   recommended.) With very few exceptions (most notably the usages of
+   BIT STRING), the encodings resulting from using the DER remain
+   identical between the types defined in RFC 1510 and the types defined
+   in this document.
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+   KerberosV5Spec2 {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) krb5spec2(2)
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   -- rest of definitions here
+
+   END
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   Note that in some other publications [RFC1510] [RFC1964], the "dod"
+   portion of the object identifier is erroneously specified as having
+   the value "5".  In the case of RFC 1964, use of the "correct" OID
+   value would result in a change in the wire protocol; therefore, it
+   remains unchanged for now.
+
+   Note that elsewhere in this document, nomenclature for various
+   message types is inconsistent, but seems to largely follow C language
+   conventions, including use of underscore (_) characters and all-caps
+   spelling of names intended to be numeric constants. Also, in some
+   places, identifiers (especially ones refering to constants) are
+
+
+
+March 2003                                                     [Page 50]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   written in all-caps in order to distinguish them from surrounding
+   explanatory text.
+
+   The ASN.1 notation does not permit underscores in identifiers, so in
+   actual ASN.1 definitions, underscores are replaced with hyphens (-).
+   Additionally, structure member names and defined values in ASN.1 MUST
+   begin with a lowercase letter, while type names MUST begin with an
+   uppercase letter.
+
+5.1. Specific Compatibility Notes on ASN.1
+
+   For compatibility purposes, implementors should heed the following
+   specific notes regarding the use of ASN.1 in Kerberos. These notes do
+   not describe deviations from standard usage of ASN.1. The purpose of
+   these notes is to instead describe some historical quirks and non-
+   compliance of various implementations, as well as historical
+   ambiguities, which, while being valid ASN.1, can lead to confusion
+   during implementation.
+
+5.1.1. ASN.1 Distinguished Encoding Rules
+
+   The encoding of Kerberos protocol messages shall obey the
+   Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
+   Some implementations (believed to be primarly ones derived from DCE
+   1.1 and earlier) are known to use the more general Basic Encoding
+   Rules (BER); in particular, these implementations send indefinite
+   encodings of lengths. Implementations MAY accept such encodings in
+   the interests of backwards compatibility, though implementors are
+   warned that decoding fully-general BER is fraught with peril.
+
+5.1.2. Optional Integer Fields
+
+   Some implementations do not internally distinguish between an omitted
+   optional integer value and a transmitted value of zero. The places in
+   the protocol where this is relevant include various microseconds
+   fields, nonces, and sequence numbers. Implementations SHOULD treat
+   omitted optional integer values as having been transmitted with a
+   value of zero, if the application is expecting this.
+
+5.1.3. Empty SEQUENCE OF Types
+
+   There are places in the protocol where a message contains a SEQUENCE
+   OF type as an optional member. This can result in an encoding that
+   contains an empty SEQUENCE OF encoding. The Kerberos protocol does
+   not semantically distinguish between an absent optional SEQUENCE OF
+   type and a present optional but empty SEQUENCE OF type.
+   Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
+   marked OPTIONAL, but SHOULD accept them as being equivalent to an
+
+
+
+March 2003                                                     [Page 51]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
+   messages, instances of these problematic optional SEQUENCE OF types
+   are indicated with a comment.
+
+5.1.4. Unrecognized Tag Numbers
+
+   Future revisions to this protocol may include new message types with
+   different APPLICATION class tag numbers. Such revisions should
+   protect older implementations by only sending the message types to
+   parties that are known to understand them, e.g. by means of a flag
+   bit set by the receiver in a preceding request. In the interest of
+   robust error handling, implementations SHOULD gracefully handle
+   receiving a message with an unrecognized tag anyway, and return an
+   error message if appropriate.
+
+5.1.5. Tag Numbers Greater Than 30
+
+   A naive implementation of a DER ASN.1 decoder may experience problems
+   with ASN.1 tag numbers greater than 30, due to such tag numbers being
+   encoded using more than one byte. Future revisions of this protocol
+   may utilize tag numbers greater than 30, and implementations SHOULD
+   be prepared to gracefully return an error, if appropriate, if they do
+   not recognize the tag.
+
+5.2. Basic Kerberos Types
+
+   This section defines a number of basic types that are potentially
+   used in multiple Kerberos protocol messages.
+
+5.2.1. KerberosString
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO-2022/ECMA-35
+   [ISO-2022/ECMA-35] to switch character sets, and the default
+   character set that is designated as G0 is the ISO-646/ECMA-6
+   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
+   ASCII), which mostly works.
+
+   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1). DER prohibits the
+   designation of character sets as any but the G0 and C0 sets.
+   Unfortunately, this seems to have the side effect of prohibiting the
+   use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
+   character-sets that utilize a 96-character set, since it is
+   prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
+
+
+
+March 2003                                                     [Page 52]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   element. This side effect is being investigated in the ASN.1
+   standards community.
+
+   In practice, many implementations treat GeneralStrings as if they
+   were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences. The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString. This failure to adhere to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   The new (post-RFC 1510) type KerberosString, defined below, is a
+   GeneralString that is constrained to only contain characters in
+   IA5String
+
+      KerberosString  ::= GeneralString (IA5String)
+
+   US-ASCII control characters should in general not be used in
+   KerberosString, except for cases such as newlines in lengthy error
+   messages. Control characters SHOULD NOT be used in principal names or
+   realm names.
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way. Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters. This is a violation of the ASN.1
+   standard. Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard. As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
+
+
+
+March 2003                                                     [Page 53]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+   Future revisions to this protocol will almost certainly allow for a
+   more interoperable representation of principal names, probably
+   including UTF8String.
+
+   Note that applying a new constraint to a previously unconstrained
+   type constitutes creation of a new ASN.1 type. In this particular
+   case, the change does not result in a changed encoding under DER.
+
+5.2.2. Realm and PrincipalName
+
+   Realm           ::= KerberosString
+
+   PrincipalName   ::= SEQUENCE {
+           name-type       [0] Int32,
+           name-string     [1] SEQUENCE OF KerberosString
+   }
+
+   Kerberos realm names are encoded as KerberosStrings. Realms shall not
+   contain a character with the code 0 (the US-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 6.1.. 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 6.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).
+
+   name-string
+      This field encodes a sequence of components that form a name, each
+      component encoded as a KerberosString. Taken together, a
+      PrincipalName and a Realm form a principal identifier. Most
+      PrincipalNames will have only a few components (typically one or
+      two).
+
+5.2.3. KerberosTime
+
+
+
+March 2003                                                     [Page 54]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes. A
+   KerberosTime value shall not include any fractional portions of the
+   seconds.  As required by the DER, it further shall not include any
+   separators, and it shall specify the UTC time zone (Z). Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is 19851106210627Z.
+
+5.2.4. Constrained Integer types
+
+   Some integer members of types SHOULD be constrained to values
+   representable in 32 bits, for compatibility with reasonable
+   implementation limits.
+
+   Int32           ::= INTEGER (-2147483648..2147483647)
+                       -- signed values representable in 32 bits
+
+   UInt32          ::= INTEGER (0..4294967295)
+                       -- unsigned 32 bit values
+
+   Microseconds    ::= INTEGER (0..999999)
+                       -- microseconds
+
+   While this results in changes to the abstract types from the RFC 1510
+   version, the encoding in DER should be unaltered. Historical
+   implementations were typically limited to 32-bit integer values
+   anyway, and assigned numbers SHOULD fall in the space of integer
+   values representable in 32 bits in order to promote interoperability
+   anyway.
+
+   There are several integer fields in messages that are constrained to
+   fixed values.
+
+   pvno
+      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
+      the constant integer 5. There is no easy way to make this field
+      into a useful protocol version number, so its value is fixed.
+
+   msg-type
+      this integer field is usually identical to the application tag
+      number of the containing message type.
+
+5.2.5. HostAddress and HostAddresses
+
+   HostAddress     ::= SEQUENCE  {
+           addr-type       [0] Int32,
+           address         [1] OCTET STRING
+
+
+
+March 2003                                                     [Page 55]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   }
+
+   -- NOTE: HostAddresses is always used as an OPTIONAL field and
+   -- should not be empty.
+   HostAddresses   -- NOTE: subtly different from rfc1510,
+                   -- but has a value mapping and encodes the same
+           ::= SEQUENCE OF HostAddress
+
+   The host address 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 7.5.3.
+
+   address
+      This field encodes a single address of type addr-type.
+
+5.2.6. AuthorizationData
+
+      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+      -- should not be empty.
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+              ad-type         [0] Int32,
+              ad-data         [1] OCTET STRING
+      }
+
+   ad-data
+      This field contains authorization data to be interpreted according
+      to the value of the corresponding ad-type field.
+
+   ad-type
+      This field specifies the format for the ad-data subfield. All
+      negative values are reserved for local use. Non-negative values
+      are reserved for registered use.
+
+   Each sequence of type and data is referred 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.
+
+   These common authorization data elements are recursively 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
+
+
+
+March 2003                                                     [Page 56]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator. Unless encapsulated in a known authorization
+   data element amending the criticality of the elements it contains, if
+   an unknown authorization data element type is received by a server
+   either in an AP-REQ or in a ticket contained in an AP-REQ, then
+   authentication MUST fail.  Authorization data is intended to restrict
+   the use of a ticket. If the service cannot determine whether the
+   restriction applies to that service then a security weakness may
+   result if the ticket can be used for that service. Authorization
+   elements that are optional can be enclosed in AD-IF-RELEVANT element.
+
+   In the definitions that follow, the value of the ad-type for the
+   element will be specified as the least significant part of the
+   subsection number, and the value of the ad-data will be as shown in
+   the ASN.1 structure that follows the subsection heading.
+
+             contents of ad-data          ad-type
+
+    DER encoding of AD-IF-RELEVANT        1
+
+    DER encoding of AD-KDCIssued          4
+
+    DER encoding of AD-AND-OR             5
+
+    DER encoding of AD-MANDATORY-FOR-KDC  8
+
+5.2.6.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.  The ad-type for AD-IF-RELEVANT is (1).
+
+5.2.6.2. KDCIssued
+
+   AD-KDCIssued            ::= SEQUENCE {
+
+
+
+March 2003                                                     [Page 57]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           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) using the key
+      used to protect the ticket, and a key usage value of 19.
+
+   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 privileges 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.
+
+
+
+March 2003                                                     [Page 58]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   This element and the elements it encapulates MAY be safely ignored by
+   applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+5.2.6.3. AND-OR
+
+   AD-AND-OR               ::= SEQUENCE {
+           condition-count [0] INTEGER,
+           elements        [1] AuthorizationData
+   }
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisifed.  Therefore, 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.
+
+   The ad-type for AD-AND-OR is (5).
+
+5.2.6.4. MANDATORY-FOR-KDC
+
+   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+   be interpreted by the KDC. KDCs that do not understand the type of an
+   element embedded within the mandatory-for-kdc element MUST reject the
+   request.
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+5.2.7. PA-DATA
+
+   Historically, PA-DATA have been known as "pre-authentication data",
+   meaning that they were used to augment the initial authentication
+   with the KDC.  Since that time, they have also been used as a typed
+   hole with which to extend protocol exchanges with the KDC.
+
+   PA-DATA         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           padata-type     [1] Int32,
+           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+
+
+
+March 2003                                                     [Page 59]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   }
+
+   padata-type
+      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.
+
+   padata-value
+      Usually contains the DER encoding of another type; the padata-type
+      field identifies which type is encoded here.
+
+       padata-type        name           contents of padata-value
+
+       1            pa-tgs-req       DER encoding of AP-REQ
+
+       2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
+
+       3            pa-pw-salt       salt (not ASN.1 encoded)
+
+       11           pa-etype-info    DER encoding of ETYPE-INFO
+
+       19           pa-etype-info2   DER encoding of ETYPE-INFO2
+
+      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.
+
+      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.
+
+5.2.7.1. PA-TGS-REQ
+
+   In the case of requests for additional tickets (KRB_TGS_REQ), padata-
+   value will contain an encoded AP-REQ. The checksum in the
+   authenticator (which MUST be collision-proof) is to be computed over
+   the KDC-REQ-BODY encoding.
+
+5.2.7.2. Encrypted Timestamp Pre-authentication
+
+   There are pre-authentication types that may be used to pre-
+   authenticate a client by means of an encrypted timestamp.
+
+
+
+
+March 2003                                                     [Page 60]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+   PA-ENC-TS-ENC           ::= SEQUENCE {
+           patimestamp     [0] KerberosTime -- client's time --,
+           pausec          [1] Microseconds OPTIONAL
+   }
+
+   Patimestamp contains the client's time, and pausec contains 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 encoding, encrypted using the client's secret
+   key and a key usage value of 1.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations support it.
+
+5.2.7.3. PA-PW-SALT
+
+   The padata-value for this pre-authentication type contains the salt
+   for the string-to-key to be used by the client to obtain the key for
+   decrypting the encrypted part of an AS-REP message. Unfortunately,
+   for historical reasons, the character set to be used is unspecified
+   and probably locale-specific.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations support it. It is necessary in any case where the
+   salt for the string-to-key algorithm is not the default.
+
+   In the trivial example, a zero-length salt string is very commonplace
+   for realms that have converted their principal databases from
+   Kerberos 4.
+
+   A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
+   that requests additional pre-authentication. Implementation note:
+   some KDC implementations issue an erroneous PA-PW-SALT when issuing a
+   KRB-ERROR message that requests additional pre-authentication.
+   Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-
+   ERROR message that requests additional pre-authentication.
+
+5.2.7.4. PA-ETYPE-INFO
+
+   The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-
+   ERROR indicating a requirement for additional pre-authentication. It
+   is usually used to notify a client of which key to use for the
+   encryption of an encrypted timestamp for the purposes of sending a
+   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
+   AS-REP to provide information to the client about which key salt to
+   use for the string-to-key to be used by the client to obtain the key
+
+
+
+March 2003                                                     [Page 61]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   for decrypting the encrypted part the AS-REP.
+
+   ETYPE-INFO-ENTRY        ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+   The salt, like that of PA-PW-SALT, is also completely unspecified
+   with respect to character set and is probably locale-specific.
+
+   If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-
+   INFO-ENTRY, and its etype shall match that of the enc-part in the AS-
+   REP.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations that support encrypted timestamps for pre-
+   authentication need to support ETYPE-INFO as well.
+
+5.2.7.5. PA-ETYPE-INFO2
+
+   The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-
+   ERROR indicating a requirement for additional pre-authentication. It
+   is usually used to notify a client of which key to use for the
+   encryption of an encrypted timestamp for the purposes of sending a
+   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
+   AS-REP to provide information to the client about which key salt to
+   use for the string-to-key to be used by the client to obtain the key
+   for decrypting the encrypted part the AS-REP.
+
+   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] KerberosString OPTIONAL,
+           s2kparams       [2] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY
+
+   The type of the salt is KerberosString, but existing installations
+   might have locale-specific characters stored in salt strings, and
+   implementors MAY choose to handle them.
+
+   The interpretation of s2kparams is specified in the cryptosystem
+   description associated with the etype. Each cryptosystem has a
+   default interpretation of s2kparams that will hold if that element is
+   omitted from the encoding of ETYPE-INFO2-ENTRY.
+
+
+
+
+March 2003                                                     [Page 62]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
+   ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
+   the AS-REP.
+
+   The preferred ordering of pre-authentication data that modify client
+   key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by
+   PW-SALT. A KDC shall send all of these pre-authentication data that
+   it supports, in the preferred ordering, when issuing an AS-REP or
+   when issuing a KRB-ERROR requesting additional pre-authentication.
+
+   The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
+
+5.2.8. KerberosFlags
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
+                       -- shall be sent, but no fewer than 32
+
+   Compatibility note: the following paragraphs describe a change from
+   the RFC1510 description of bit strings that would result in
+   incompatility in the case of an implementation that strictly
+   conformed to ASN.1 DER and RFC1510.
+
+   ASN.1 bit strings have multiple uses. The simplest use of a bit
+   string is to contain a vector of bits, with no particular meaning
+   attached to individual bits. This vector of bits is not necessarily a
+   multiple of eight bits long.  The use in Kerberos of a bit string as
+   a compact boolean vector wherein each element has a distinct meaning
+   poses some problems. The natural notation for a compact boolean
+   vector is the ASN.1 "NamedBit" notation, and the DER require that
+   encodings of a bit string using "NamedBit" notation exclude any
+   trailing zero bits. This truncation is easy to neglect, especially
+   given C language implementations that naturally choose to store
+   boolean vectors as 32 bit integers.
+
+   For example, if the notation for KDCOptions were to include the
+   "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
+   encoded had only the "forwardable" (bit number one) bit set, the DER
+   encoding MUST include only two bits: the first reserved bit
+   ("reserved", bit number zero, value zero) and the one-valued bit (bit
+   number one) for "forwardable".
+
+   Most existing implementations of Kerberos unconditionally send 32
+   bits on the wire when encoding bit strings used as boolean vectors.
+   This behavior violates the ASN.1 syntax used for flag values in RFC
+   1510, but occurs on such a widely installed base that the protocol
+
+
+
+March 2003                                                     [Page 63]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   description is being modified to accomodate it.
+
+   Consequently, this document removes the "NamedBit" notations for
+   individual bits, relegating them to comments. The size constraint on
+   the KerberosFlags type requires that at least 32 bits be encoded at
+   all times, though a lenient implementation MAY choose to accept fewer
+   than 32 bits and to treat the missing bits as set to zero.
+
+   Currently, no uses of KerberosFlags specify more than 32 bits worth
+   of flags, although future revisions of this document may do so. When
+   more than 32 bits are to be transmitted in a KerberosFlags value,
+   future revisions to this document will likely specify that the
+   smallest number of bits needed to encode the highest-numbered one-
+   valued bit should be sent. This is somewhat similar to the DER
+   encoding of a bit string that is declared with the "NamedBit"
+   notation.
+
+5.2.9. Cryptosystem-related Types
+
+   Many Kerberos protocol messages contain an EncryptedData as a
+   container for arbitrary encrypted data, which is often the encrypted
+   encoding of another data type. Fields within EncryptedData assist the
+   recipient in selecting a key with which to decrypt the enclosed data.
+
+   EncryptedData   ::= SEQUENCE {
+           etype   [0] Int32 -- EncryptionType --,
+           kvno    [1] UInt32 OPTIONAL,
+           cipher  [2] OCTET STRING -- ciphertext
+   }
+
+   etype
+      This field identifies which encryption algorithm was used to
+      encipher the cipher.
+
+   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.  (Note that the encryption mechanisms defined in
+      [@KCRYPTO] MUST incorporate integrity protection as well, so no
+      additional checksum is required.)
+
+   The EncryptionKey type is the means by which cryptographic keys used
+   for encryption are transfered.
+
+
+
+
+March 2003                                                     [Page 64]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   EncryptionKey   ::= SEQUENCE {
+           keytype         [0] Int32 -- actually encryption type --,
+           keyvalue        [1] OCTET STRING
+   }
+
+   keytype
+      This field specifies the encryption type of the encryption key
+      that follows in the keyvalue field. While its name is "keytype",
+      it actually specifies an encryption type. Previously, multiple
+      cryptosystems that performed encryption differently but were
+      capable of using keys with the same characteristics were permitted
+      to share an assigned number to designate the type of key; this
+      usage is now deprecated.
+
+   keyvalue
+      This field contains the key itself, encoded as an octet string.
+
+   Messages containing cleartext data to be authenticated will usually
+   do so by using a member of type Checksum. Most instances of Checksum
+   use a keyed hash, though exceptions will be noted.
+
+   Checksum        ::= SEQUENCE {
+           cksumtype       [0] Int32,
+           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.
+
+   See section 4 for a brief description of the use of encryption and
+   checksums in Kerberos.
+
+5.3. Tickets
+
+   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. 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 (5),
+           realm           [1] Realm,
+
+
+
+March 2003                                                     [Page 65]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           sname           [2] PrincipalName,
+           enc-part        [3] EncryptedData -- EncTicketPart
+   }
+
+   -- 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] Int32 -- must be registered --,
+           contents        [1] OCTET STRING
+   }
+
+   TicketFlags     ::= KerberosFlags
+           -- 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),
+   -- the following are new since 1510
+           -- transited-policy-checked(12),
+           -- ok-as-delegate(13)
+
+   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
+
+
+
+March 2003                                                     [Page 66]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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.  It is encrypted in the key shared by Kerberos and the
+      end server (the server's secret key), using a key usage value of
+      2.
+
+   flags
+      This field indicates which of various options were used or
+      requested when the ticket was issued. The meanings of the flags
+      are:
+
+         Bit(s)  Name                   Description
+
+         0       reserved               Reserved for future expansion of this
+                                        field.
+
+                                        The FORWARDABLE flag is normally only
+                                        interpreted by the TGS, and can be
+                                        ignored by end servers. When set, this
+         1       forwardable            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.
+
+                                        When set, this flag indicates that the
+                                        ticket has either been forwarded or
+         2       forwarded              was issued based on authentication
+                                        involving a forwarded ticket-granting
+                                        ticket.
+
+                                        The PROXIABLE flag is normally only
+                                        interpreted by the TGS, and can be
+                                        ignored by end servers. The PROXIABLE
+                                        flag has an interpretation identical
+         3       proxiable              to that of the FORWARDABLE flag,
+                                        except that the PROXIABLE flag tells
+                                        the ticket-granting server that only
+                                        non-ticket-granting tickets may be
+
+
+
+March 2003                                                     [Page 67]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                                        issued with different network
+                                        addresses.
+
+         4       proxy                  When set, this flag indicates that a
+                                        ticket is a proxy.
+
+                                        The MAY-POSTDATE flag is normally only
+                                        interpreted by the TGS, and can be
+         5       may-postdate           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.
+
+                                        This flag indicates that this ticket
+                                        has been postdated. The end-service
+         6       postdated              can check the authtime field to see
+                                        when the original authentication
+                                        occurred.
+
+                                        This flag indicates that a ticket is
+                                        invalid, and it must be validated by
+         7       invalid                the KDC before use. Application
+                                        servers must reject tickets which have
+                                        this flag set.
+
+                                        The RENEWABLE flag is normally only
+                                        interpreted by the TGS, and can
+                                        usually be ignored by end servers
+         8       renewable              (some particularly careful servers MAY
+                                        disallow renewable tickets). A
+                                        renewable ticket can be used to obtain
+                                        a replacement ticket that expires at a
+                                        later date.
+
+                                        This flag indicates that this ticket
+         9       initial                was issued using the AS protocol, and
+                                        not issued based on a ticket-granting
+                                        ticket.
+
+                                        This flag indicates that during
+                                        initial authentication, the client was
+                                        authenticated by the KDC before a
+         10      pre-authent            ticket was issued. The strength of the
+                                        pre-authentication method is not
+                                        indicated, but is acceptable to the
+                                        KDC.
+
+                                        This flag indicates that the protocol
+
+
+
+March 2003                                                     [Page 68]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                                        employed for initial authentication
+                                        required the use of hardware expected
+         11      hw-authent             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.
+
+                                        This flag indicates that the KDC for
+                                        the 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
+         12      transited-             is set (1) then the application server
+                 policy-checked         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.
+
+                                        This flag is new since RFC 1510.
+
+                                        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
+         13      ok-as-delegate         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.
+
+                                        This flag is new since RFC 1510.
+
+         14-31   reserved               Reserved for future use.
+
+
+
+
+March 2003                                                     [Page 69]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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.
+
+   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 in
+      the transited field (as specified for some extensions 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.  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.
+
+
+   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 the starttime field is absent from the ticket, then
+      the authtime field SHOULD be used in its place to determine the
+      life of the ticket.
+
+
+
+
+March 2003                                                     [Page 70]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 addressless tickets is a policy decision and
+      is left to the Kerberos and end-service administrators; they MAY
+      refuse to issue or accept such tickets. Because of the wide
+      deployment of network address translation, it is recommended that
+      policy allow the issue and acceptance of such tickets.
+
+      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.
+
+
+
+March 2003                                                     [Page 71]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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
+      encapsulation 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 privileges 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.6.  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 privilege 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 5.2.6.2).
+
+      Similarly, if one specifies the authorization-data field of a
+      proxy and leaves the host addresses blank, the resulting ticket
+
+
+
+March 2003                                                     [Page 72]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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.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 application tag number of its own.
+   Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
+   which each have an application tag, 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 KDC 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 {
+           -- NOTE: first tag is [1], not [0]
+           pvno            [1] INTEGER (5) ,
+           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                               -- NOTE: not empty --,
+           req-body        [4] KDC-REQ-BODY
+   }
+
+   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,
+           rtime                   [6] KerberosTime OPTIONAL,
+           nonce                   [7] UInt32,
+
+
+
+March 2003                                                     [Page 73]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                       -- in preference order --,
+           addresses               [9] HostAddresses OPTIONAL,
+           enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
+           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                           -- NOTE: not empty
+   }
+
+   KDCOptions      ::= KerberosFlags
+           -- reserved(0),
+           -- forwardable(1),
+           -- forwarded(2),
+           -- proxiable(3),
+           -- proxy(4),
+           -- allow-postdate(5),
+           -- postdated(6),
+           -- unused7(7),
+           -- renewable(8),
+           -- unused9(9),
+           -- unused10(10),
+           -- opt-hardware-auth(11),
+           -- unused12(12),
+           -- unused13(13),
+   -- 15 is reserved for canonicalize
+           -- unused15(15),
+   -- 26 was unused in 1510
+           -- disable-transited-check(26),
+   --
+           -- renewable-ok(27),
+           -- enc-tkt-in-skey(28),
+           -- renew(30),
+           -- validate(31)
+
+   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
+      Contains pre-authentication data. Requests for additional tickets
+
+
+
+March 2003                                                     [Page 74]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
+
+      The padata (pre-authentication data) field contains a sequence of
+      authentication information which may be needed before credentials
+      can be issued or decrypted.
+
+   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:
+
+         Bits    Name                     Description
+
+         0       RESERVED                 Reserved for future expansion of
+                                          this field.
+
+                                          The FORWARDABLE option indicates
+                                          that the ticket to be issued is to
+                                          have its forwardable flag set. It
+         1       FORWARDABLE              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
+                                          forwardable.
+
+                                          The FORWARDED option is only
+                                          specified in a request to the
+                                          ticket-granting server and will only
+                                          be honored if the ticket-granting
+
+
+
+March 2003                                                     [Page 75]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                                          ticket in the request has its
+         2       FORWARDED                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.
+
+                                          The PROXIABLE option indicates that
+                                          the ticket to be issued is to have
+                                          its proxiable flag set. It may only
+         3       PROXIABLE                be set on the initial request, or in
+                                          a subsequent request if the
+                                          ticket-granting ticket on which it
+                                          is based is also proxiable.
+
+                                          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
+         4       PROXY                    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.
+
+                                          The ALLOW-POSTDATE option indicates
+                                          that the ticket to be issued is to
+                                          have its MAY-POSTDATE flag set. It
+         5       ALLOW-POSTDATE           may only be set on the initial
+                                          request, or in a subsequent request
+                                          if the ticket-granting ticket on
+                                          which it is based also has its
+                                          MAY-POSTDATE flag set.
+
+                                          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
+         6       POSTDATED                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       RESERVED                 This option is presently unused.
+
+
+
+March 2003                                                     [Page 76]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                                          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
+         8       RENEWABLE                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      RESERVED                 Reserved for future use.
+
+         11      RESERVED                 Reserved for opt-hardware-auth.
+
+         12-25   RESERVED                 Reserved for future use.
+
+                                          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
+         26      DISABLE-TRANSITED-CHECK  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. KDCs are
+                                          encouraged but not required to honor
+                                          the DISABLE-TRANSITED-CHECK option.
+
+                                          This flag is new since RFC 1510
+
+                                          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,
+         27      RENEWABLE-OK             then a renewable ticket may be
+                                          issued with a renew-till equal to
+
+
+
+March 2003                                                     [Page 77]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                                          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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The
+                                          ENC-TKT-IN-SKEY option indicates
+         28      ENC-TKT-IN-SKEY          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.
+
+                                          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
+         30      RENEW                    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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The
+                                          VALIDATE option indicates that the
+                                          request is to validate a postdated
+                                          ticket. It will only be honored if
+                                          the ticket presented is postdated,
+                                          presently has its INVALID flag set,
+         31      VALIDATE                 and would be otherwise usable at
+                                          this time. A ticket cannot be
+                                          validated 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. The sname may only be absent when the ENC-TKT-IN-SKEY
+
+
+
+March 2003                                                     [Page 78]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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 the Authenticator and ticket-granting
+      ticket come from the padata field in the KRB_TGS_REQ). The key
+      usage value used when encrypting is 5 if a sub-session key is
+      used, or 4 if the session key is used.
+
+   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 not optional, but if the requested endtime
+      is "19700101000000Z", the requested ticket is to have the maximum
+      endtime permitted according to KDC policy. Implementation note:
+      This special timestamp corresponds to a UNIX time_t value of zero
+      on most systems.
+
+   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 is 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 reused.
+
+   etype
+      This field specifies the desired encryption algorithm to be used
+      in the response.
+
+
+
+
+March 2003                                                     [Page 79]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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
+      the 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 tag number 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,
+
+
+
+March 2003                                                     [Page 80]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 (5),
+           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                   -- NOTE: not empty --,
+           crealm          [3] Realm,
+           cname           [4] PrincipalName,
+           ticket          [5] Ticket,
+           enc-part        [6] EncryptedData
+                                   -- EncASRepPart or EncTGSRepPart,
+                                   -- as appropriate
+   }
+
+   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+   EncKDCRepPart   ::= SEQUENCE {
+           key             [0] EncryptionKey,
+           last-req        [1] LastReq,
+           nonce           [2] UInt32,
+           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
+   }
+
+   LastReq         ::=     SEQUENCE OF SEQUENCE {
+           lr-type         [0] Int32,
+           lr-value        [1] KerberosTime
+   }
+
+   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.
+
+
+
+March 2003                                                     [Page 81]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   padata
+      This field is described in detail in section 5.4.1. One possible
+      use for this field is to encode an alternate "salt" string to be
+      used with a string-to-key algorithm. 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
+      salt 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.
+
+   ticket
+      The newly-issued ticket, from section 5.3.
+
+   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 key usage value for encrypting this field is 3 in an AS-REP
+      message, using the client's long-term key or another key selected
+      via pre-authentication mechanisms. In a TGS-REP message, the key
+      usage value is 8 if the TGS session key is used, or 9 if a TGS
+      authenticator subkey is used.
+
+      Compatibility note: Some implementations unconditionally send an
+      encrypted EncTGSRepPart (application tag number 26) in this field
+      regardless of whether the reply is a AS-REP or a TGS-REP. In the
+      interests of compatibility, implementors MAY relax the check on
+      the tag number of the decrypted ENC-PART.
+
+   key
+      This field is the same as described for the ticket in section 5.3.
+
+   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.
+
+
+
+March 2003                                                     [Page 82]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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.  If
+         it is (7), then the lr-value subfield is the time when the
+         account 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.
+
+   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. If present, it SHOULD be set to the earliest of the
+      user's key expiration and account expiration.  The use of this
+      field is deprecated and the last-req field SHOULD be used to
+      convey this information instead.  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), 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
+
+
+
+March 2003                                                     [Page 83]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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 (5),
+           msg-type        [1] INTEGER (14),
+           ap-options      [2] APOptions,
+           ticket          [3] Ticket,
+           authenticator   [4] EncryptedData -- Authenticator
+   }
+
+   APOptions       ::= KerberosFlags
+           -- 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.
+
+                                 The USE-SESSION-KEY option indicates that the
+
+
+
+March 2003                                                     [Page 84]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+                                 ticket the client is presenting to a server
+         1       use-session-key is encrypted in the session key from the
+                                 server's ticket-granting ticket. When this
+                                 option is not specified, the ticket is
+                                 encrypted in the server's secret key.
+
+                                 The MUTUAL-REQUIRED option tells the server
+         2       mutual-required 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 encrypted authenticator, which includes the
+      client's choice of a subkey.
+
+   The encrypted authenticator is included in the AP-REQ; it certifies
+   to a server that the sender has recent knowledge of the encryption
+   key in the accompanying ticket, to help the server detect replays. It
+   also assists in the selection of a "true session key" to use with the
+   particular session.  The DER encoding of the following is encrypted
+   in the ticket's session key, with a key usage value of 11 in normal
+   application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
+   of a TGS-REQ exchange (see section 5.4.1):
+
+   -- Unencrypted authenticator
+   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+           authenticator-vno       [0] INTEGER (5),
+           crealm                  [1] Realm,
+           cname                   [2] PrincipalName,
+           cksum                   [3] Checksum OPTIONAL,
+           cusec                   [4] Microseconds,
+           ctime                   [5] KerberosTime,
+           subkey                  [6] EncryptionKey OPTIONAL,
+           seq-number              [7] UInt32 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
+
+
+
+March 2003                                                     [Page 85]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      section 5.3.
+
+   cksum
+      This field contains a checksum of the application data that
+      accompanies the KRB_AP_REQ, computed using a key usage value of 10
+      in normal application exchanges, or 6 when used in the TGS-REQ PA-
+      TGS-REQ AP-DATA field.
+
+   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.
+
+      Implmentation note: historically, some implementations transmit
+      signed twos-complement numbers for sequence numbers. In the
+      interests of compatibility, implementations MAY accept the
+      equivalent negative number where a positive number greater than
+
+
+
+March 2003                                                     [Page 86]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      2^31 - 1 is expected.
+
+      Implementation note: as noted before, some implementations omit
+      the optional sequence number when its value would be zero.
+      Implementations MAY accept an omitted sequence number when
+      expecting a value of zero, and SHOULD NOT transmit an
+      Authenticator with a initial sequence number of zero.
+
+   authorization-data
+      This field is the same as described for the ticket in section 5.3.
+      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.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
+   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 (5),
+           msg-type        [1] INTEGER (15),
+           enc-part        [2] EncryptedData -- EncAPRepPart
+   }
+
+   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+           ctime           [0] KerberosTime,
+           cusec           [1] Microseconds,
+           subkey          [2] EncryptionKey OPTIONAL,
+           seq-number      [3] UInt32 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. It is computed
+      with a key usage value of 12.
+
+   ctime
+      This field contains the current time on the client's host.
+
+
+
+March 2003                                                     [Page 87]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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.
+
+   seq-number
+      This field is described above in section 5.3.2.
+
+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 occurred. The message fields
+   are:
+
+   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (20),
+           safe-body       [2] KRB-SAFE-BODY,
+           cksum           [3] Checksum
+   }
+
+   KRB-SAFE-BODY   ::= SEQUENCE {
+
+
+
+March 2003                                                     [Page 88]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress,
+           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, computed
+      with a key usage value of 15.
+
+      The checksum is computed over the encoding of the KRB-SAFE
+      sequence.  First, the cksum is set to a type zero, zero-length
+      value 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.
+      This method, while different than the one specified in RFC 1510,
+      corresponds to existing practice.
+
+   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
+      Sender's address.
+
+
+
+March 2003                                                     [Page 89]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      This field specifies the address in use by the sender of the
+      message.  It MAY be omitted if not required by the application
+      protocol.
+
+   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 (5),
+           msg-type        [1] INTEGER (21),
+                           -- NOTE: there is no [2] tag
+           enc-part        [3] EncryptedData -- EncKrbPrivPart
+   }
+
+   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress -- 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, with a key usage value of 13.
+
+
+
+March 2003                                                     [Page 90]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      This encrypted encoding is used for the enc-part field of the KRB-
+      PRIV message.
+
+   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 (5),
+           msg-type        [1] INTEGER (22),
+           tickets         [2] SEQUENCE OF Ticket,
+           enc-part        [3] EncryptedData -- EncKrbCredPart
+   }
+
+   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+           ticket-info     [0] SEQUENCE OF KrbCredInfo,
+           nonce           [1] UInt32 OPTIONAL,
+           timestamp       [2] KerberosTime OPTIONAL,
+           usec            [3] Microseconds 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,
+
+
+
+March 2003                                                     [Page 91]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           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, with a key usage value of 14. This encrypted
+      encoding is used for the enc-part field of the KRB-CRED message.
+
+      Implementation note: implementations of certain applications, most
+      notably certain implementations of the Kerberos GSS-API mechanism,
+      do not separately encrypt the contents of the EncKrbCredPart of
+      the KRB-CRED message when sending it.  In the case of those GSS-
+      API mechanisms, this is not a security vulnerability, as the
+      entire KRB-CRED message is itself embedded in an encrypted
+      message.
+
+   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 reused; 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
+
+
+
+March 2003                                                     [Page 92]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      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 5.2.9.
+
+   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 corresponding 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 not integrity protected, it
+   is quite possible for an intruder to synthesize or modify such a
+   message. In particular, this means that 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 (5),
+           msg-type        [1] INTEGER (30),
+
+
+
+March 2003                                                     [Page 93]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           ctime           [2] KerberosTime OPTIONAL,
+           cusec           [3] Microseconds OPTIONAL,
+           stime           [4] KerberosTime,
+           susec           [5] Microseconds,
+           error-code      [6] Int32,
+           crealm          [7] Realm OPTIONAL,
+           cname           [8] PrincipalName OPTIONAL,
+           realm           [9] Realm -- service realm --,
+           sname           [10] PrincipalName -- service name --,
+           e-text          [11] KerberosString OPTIONAL,
+           e-data          [12] OCTET STRING OPTIONAL
+   }
+
+   pvno and msg-type
+      These fields are described above in section 5.4.1. +A 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 7.5.9. 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.
+
+   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).
+
+
+
+
+March 2003                                                     [Page 94]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 the
+      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
+      contain an encoding of a sequence of padata fields, each
+      corresponding to an acceptable pre-authentication method and
+      optionally containing data for the method:
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+   For error codes defined in this document other than
+   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
+   are implementation-defined. Similarly, for future error codes, the
+   format and contents of the e-data field are implementation-defined
+   unless specified. Whether defined by the implementation or in a
+   future document, the e-data field MAY take the form of TYPED-DATA:
+
+   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+           data-type       [0] INTEGER,
+           data-value      [1] OCTET STRING OPTIONAL
+   }
+
+5.10. Application Tag Numbers
+
+   The following table lists the application class tag numbers used by
+   various data types defined in this section.
+
+    Tag Number(s)    Type Name    Comments
+
+    0                             unused
+
+    1              Ticket         PDU
+
+    2              Authenticator  non-PDU
+
+    3              EncTicketPart  non-PDU
+
+    4-9                           unused
+
+    10             AS-REQ         PDU
+
+    11             AS-REP         PDU
+
+    12             TGS-REQ        PDU
+
+    13             TGS-REP        PDU
+
+    14             AP-REQ         PDU
+
+
+
+March 2003                                                     [Page 95]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+    15             AP-REP         PDU
+
+    16             RESERVED16     TGT-REQ (for user-to-user)
+
+    17             RESERVED17     TGT-REP (for user-to-user)
+
+    18-19                         unused
+
+    20             KRB-SAFE       PDU
+
+    21             KRB-PRIV       PDU
+
+    22             KRB-CRED       PDU
+
+    23-24                         unused
+
+    25             EncASRepPart   non-PDU
+
+    26             EncTGSRepPart  non-PDU
+
+    27             EncApRepPart   non-PDU
+
+    28             EncKrbPrivPart non-PDU
+
+    29             EncKrbCredPart non-PDU
+
+    30             KRB-ERROR      PDU
+
+   The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are
+   the only ASN.1 types intended as top-level types of the Kerberos
+   protcol, and are the only types that may be used as elements in
+   another protocol that makes use of Kerberos.
+
+6. Naming Constraints
+
+6.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
+
+
+
+March 2003                                                     [Page 96]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   in the case of the characters are not equivalent. There are presently
+   three styles of realm names: domain, X500, and other. Examples of
+   each style follow:
+
+        domain:   ATHENA.MIT.EDU
+          X500:   C=US/O=OSF
+         other:   NAMETYPE:rest/of.name=without-restrictions
+
+   Domain syle realm 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. Note that the
+   slash separator is consistent with Kerberos implementations based on
+   RFC1510, but it is different from the separator recommended in
+   RFC2253.
+
+   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
+
+
+
+March 2003                                                     [Page 97]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 exist a name identical to the
+   realm name of the child unless it is assigned to the same entity as
+   the realm name.
+
+6.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 only as a hint to interpreting the meaning of a name. It is
+   not significant when checking for equivalence. Principal names that
+   differ only in the name-type identify the same principal. The name
+   type does not partition the name space. 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
+
+   name types
+
+   NT-UNKNOWN        0  Name type not known
+   NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
+   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 host as remaining components
+   NT-UID            5  Unique ID
+   NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
+   NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
+   NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
+
+   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.
+
+
+
+
+March 2003                                                     [Page 98]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   If the first component of a name identifies a service and there is a
+   single component following the service name identifying the instance
+   as 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 certificate 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, including an "@" and a domain name, is
+   used as the one component of the principal name.
+
+   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 7.5.8 for the
+   form of such names.
+
+6.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 and the official name can be reliably
+   determined, the official name of the host SHOULD be used when
+   constructing the name of the server principal.
+
+
+
+
+March 2003                                                     [Page 99]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+7. Constants and other defined values
+
+7.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.
+
+   Internet (IPv4) Addresses
+
+      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
+      in MSB order. The IPv4 loopback address SHOULD NOT appear in a
+      Kerberos packet. The type of IPv4 addresses is two (2).
+
+   Internet (IPv6) Addresses
+
+      IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
+      encoded in MSB order. The type of IPv6 addresses is twenty-four
+      (24). The following addresses MUST NOT appear in any Kerberos
+      packet:
+
+         *  the Unspecified Address
+         *  the Loopback Address
+         *  Link-Local addresses
+
+      IPv4-mapped IPv6 addresses MUST be represented as addresses of
+      type 2.
+
+   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 alphanumeric characters and padded with the US-ASCII SPC
+      character (code 32).  The 16th octet MUST be the US-ASCII NUL
+      character (code 0).  The type of Netbios addresses is twenty (20).
+
+   Directional Addresses
+
+      In many environments, including the sender address in KRB_SAFE and
+      KRB_PRIV messages is undesirable because the addresses may be
+      changed in transport by network address translators. However, if
+      these addresses are removed, the messages may be subject to a
+      reflection attack in which a message is reflected back to its
+      originator. The directional address type provides a way to avoid
+
+
+
+March 2003                                                    [Page 100]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      transport addresses and reflection attacks. Directional addresses
+      are encoded as four byte unsigned integers in network byte order.
+      If the message is originated by the party sending the original
+      KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
+      message is originated by the party to whom that KRB_AP_REQ was
+      sent, then the address 1 SHOULD be used. Applications involving
+      multiple parties can specify the use of other addresses.
+
+      Directional addresses MUST only be used for the sender address
+      field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
+      as a ticket address or in a KRB_AP_REQ message. This address type
+      SHOULD only be used in situations where the sending party knows
+      that the receiving party supports the address type. This generally
+      means that directional addresses may only be used when the
+      application protocol requires their support. Directional addresses
+      are type (3).
+
+7.2. KDC messaging - IP Transports
+
+   Kerberos defines two IP transport mechanisms for communication
+   between clients and servers: UDP/IP and TCP/IP.
+
+7.2.1. UDP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify
+   the IP address and port to which they will send their request.
+
+   When contacting a 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 the KDC. 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. The response to a request made through UDP/IP transport MUST
+   also use UDP/IP transport. If the response can not be handled using
+   UDP (for example because it is too large), the KDC MUST return
+   KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request
+   using the TCP transport.
+
+7.2.2. TCP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+
+
+
+March 2003                                                    [Page 101]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   intially try a request using the UDP transport. Clients SHOULD use
+   KDC discovery [7.2.3] to identify the IP address and port to which
+   they will send their request.
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
+   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
+   the client on the same TCP stream that was established for the
+   request. The KDC MAY close the TCP stream after sending a response,
+   but MAY leave the stream open for a reasonable period of time if it
+   expects a followup. Care must be taken in managing TCP/IP connections
+   on the KDC to prevent denial of service attacks based on the number
+   of open TCP/IP connections.
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   anytime after the receipt of a response. A stream closure SHOULD NOT
+   be treated as a fatal error. Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication) the client may
+   need to establish a new connection when it is ready to send
+   subsequent messages. A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   followup messages.
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
+   sent over the TCP stream is preceded by the length of the request as
+   4 octets in network byte order. The high bit of the length is
+   reserved for future expansion and MUST currently be set to zero.
+
+   If multiple requests are sent over a single TCP connection, and the
+   KDC sends multiple responses, the KDC is not required to send the
+   responses in the order of the corresponding requests. This may permit
+   some implementations to send each response as soon as it is ready
+   even if earlier requests are still being processed (for example,
+   waiting for a response from an external device or database).
+
+
+
+March 2003                                                    [Page 102]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+7.2.3. KDC Discovery on IP Networks
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored 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 using cross-realm authentication. This section
+   describes a method for using the Domain Name System [RFC 1035] for
+   storing KDC location information.
+
+7.2.3.1. 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
+   insensitive for queries. Since "MYREALM", "myrealm", and "MyRealm"
+   are all different it is necessary that only one of the possible
+   combinations of upper and lower case characters be used. This
+   restriction may be lifted in the future as the DNS naming scheme is
+   expanded to support non-US-ASCII names.
+
+7.2.3.2. Specifying KDC Location information with DNS SRV records
+
+   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 one of "_udp", "_tcp". If these SRV records are to
+   be used, both "_udp" and "_tcp" records MUST be specified for all KDC
+   deployments.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2052.
+
+   As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal) unless the KDC is configured
+   to listen on an alternate TCP port.
+
+   Implementation note: Many existing client implementations do not
+
+
+
+March 2003                                                    [Page 103]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority. Weights are not used in these sample records.
+
+     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+
+7.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).
+
+7.4. OID arc for KerberosV5
+
+   This OID MAY be used to identify Kerberos protocol messages
+   encapsulated in other protocols. It also designates the OID arc for
+   KerberosV5-related OIDs assigned by future IETF action.
+   Implementation note:: RFC 1510 had an incorrect value (5) for "dod"
+   in its OID.
+
+   id-krb5         OBJECT IDENTIFIER ::= {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2)
+   }
+
+   Assignment of OIDs beneath the id-krb5 arc must be obtained by
+   contacting krb5-oid-registrar@mit.edu.
+
+7.5. Protocol constants and associated values
+
+
+
+
+March 2003                                                    [Page 104]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   The following tables list constants used in the protocol and define
+   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.
+
+7.5.1. Key usage numbers
+
+   The encryption and checksum specifications in [@KCRYPTO] require as
+   input a "key usage number", to alter the encryption key used in any
+   specific message, to make certain types of cryptographic attack more
+   difficult. These are the key usage values assigned in this document:
+
+           1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
+                       with the client key (section 5.2.7.2)
+           2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
+                       key or application session key), encrypted with the
+                       service key (section 5.3)
+           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.5.1)
+           7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
+                       (includes TGS authenticator subkey), encrypted with the
+                       TGS session key (section 5.5.1)
+           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.5.1)
+           11.         AP-REQ Authenticator (includes application
+                       authenticator subkey), encrypted with the application
+                       session key (section 5.5.1)
+           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)
+
+
+
+March 2003                                                    [Page 105]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           14.         KRB-CRED encrypted part, encrypted with a key chosen by
+                       the application (section 5.8.1)
+           15.         KRB-SAFE cksum, keyed with a key chosen by the
+                       application (section 5.6.1)
+           19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
+         22-24.        Reserved for use in GSSAPI mechanisms derived from RFC
+                       1964. (raeburn/MIT)
+    16-18,20-21,25-511. Reserved for future use in Kerberos and related
+                       protocols.
+        512-1023.      Reserved for uses internal to a Kerberos
+                       implementation.
+         1024.         Encryption for application use in protocols that
+                       do not specify key usage values
+         1025.         Checksums for application use in protocols that
+                       do not specify key usage values
+       1026-2047.      Reserved for application use.
+
+
+7.5.2. PreAuthentication Data Types
+
+   padata and data types           padata-type value  comment
+
+   PA-TGS-REQ                      1
+   PA-ENC-TIMESTAMP                2
+   PA-PW-SALT                      3
+   [reserved]                      4
+   PA-ENC-UNIX-TIME                5        (deprecated)
+   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-ETYPE-INFO2                  19       (replaces pa-etype-info)
+   PA-USE-SPECIFIED-KVNO           20
+   PA-SAM-REDIRECT                 21       (sam/otp)
+   PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
+   TD-PADATA                       22       (embeds padata)
+   PA-SAM-ETYPE-INFO               23       (sam/otp)
+   PA-ALT-PRINC                    24       (crawdad@fnal.gov)
+   PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
+   PA-SAM-RESPONSE2                31       (kenh@pobox.com)
+   PA-EXTRA-TGT                    41       Reserved extra TGT
+   TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
+
+
+
+March 2003                                                    [Page 106]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   TD-KRB-PRINCIPAL                102      PrincipalName
+   TD-KRB-REALM                    103      Realm
+   TD-TRUSTED-CERTIFIERS           104      from PKINIT
+   TD-CERTIFICATE-INDEX            105      from PKINIT
+   TD-APP-DEFINED-ERROR            106      application specific
+   TD-REQ-NONCE                    107      INTEGER
+   TD-REQ-SEQ                      108      INTEGER
+   PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
+
+7.5.3. Address Types
+
+   Address type                   value
+
+   IPv4                             2
+   Directional                      3
+   ChaosNet                         5
+   XNS                              6
+   ISO                              7
+   DECNET Phase IV                 12
+   AppleTalk DDP                   16
+   NetBios                         20
+   IPv6                            24
+
+7.5.4. Authorization Data Types
+
+   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-AND-OR                          5
+   AD-MANDATORY-TICKET-EXTENSIONS     6
+   AD-IN-TICKET-EXTENSIONS            7
+   AD-MANDATORY-FOR-KDC               8
+   reserved values                    9-63
+   OSF-DCE                            64
+   SESAME                             65
+   AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
+   AD-WIN2K-PAC                      128         (jbrezak@exchange.microsoft.com)
+
+7.5.5. Transited Encoding Types
+
+   transited encoding type         tr-type value
+   DOMAIN-X500-COMPRESS            1
+   reserved values                 all others
+
+7.5.6. Protocol Version Number
+
+
+
+
+March 2003                                                    [Page 107]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   Label               Value   Meaning or MIT code
+
+   pvno                    5   current Kerberos protocol version number
+
+7.5.7. Kerberos Message Types
+
+   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_RESERVED16         16   Reserved for user-to-user krb_tgt_request
+   KRB_RESERVED17         17   Reserved for user-to-user krb_tgt_reply
+   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
+
+7.5.8. Name Types
+
+   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]
+   KRB_NT_SMTP_NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
+   KRB_NT_ENTERPRISE    10   Enterprise name - may be mapped to principal name
+
+7.5.9. Error Codes
+
+   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
+
+
+
+March 2003                                                    [Page 108]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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
+   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 Reserved for PKINIT
+   KDC_ERROR_KDC_NOT_TRUSTED         63 Reserved for PKINIT
+
+
+
+March 2003                                                    [Page 109]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   KDC_ERROR_INVALID_SIG             64 Reserved for PKINIT
+   KDC_ERR_KEY_TOO_WEAK              65 Reserved for PKINIT
+   KDC_ERR_CERTIFICATE_MISMATCH      66 Reserved for PKINIT
+   KRB_AP_ERR_NO_TGT                 67 No TGT available to validate USER-TO-USER
+   KDC_ERR_WRONG_REALM               68 USER-TO-USER TGT issued different KDC
+   KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
+   KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
+   KDC_ERR_INVALID_CERTIFICATE             71 Reserved for PKINIT
+   KDC_ERR_REVOKED_CERTIFICATE             72 Reserved for PKINIT
+   KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
+   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
+   KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
+   KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
+
+8. 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.
+
+8.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.2). Specification 1
+   (deprecated) may be found in RFC1510.
+
+   Transport
+
+      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
+      claiming conformance to specification 2.
+
+   Encryption and checksum methods
+
+      The following encryption and checksum mechanisms MUST be
+      supported.
+
+
+
+
+March 2003                                                    [Page 110]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      Encryption: AES256-CTS-HMAC-SHA1-96
+      Checksums: HMAC-SHA1-96-AES256
+
+      Implementations SHOULD support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them. The mechanisms that SHOULD
+      be supported are:
+
+      Encryption:  DES-CBC-MD5, DES3-CBC-SHA1-KD
+      Checksums:   DES-MD5, HMAC-SHA1-DES3-KD
+
+      Implementations MAY support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them.
+
+      Implementation note: earlier implementations of Kerberos generate
+      messages using the CRC-32, RSA-MD5 checksum methods. For
+      interoperability with these earlier releases implementors MAY
+      consider supporting these checksum methods but should carefully
+      analyze the security impplications to limit the situations within
+      which these methods are accepted.
+
+   Realm Names
+
+      All implementations MUST understand hierarchical realms in both
+      the Internet Domain and the X.500 style. When a ticket-granting
+      ticket for an unknown realm is requested, the KDC MUST be able to
+      determine the names of the intermediate realms between the KDCs
+      realm and the requested realm.
+
+   Transited field encoding
+
+      DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
+      supported.  Alternative encodings MAY be supported, but they may
+      be used only when that encoding is supported by ALL intermediate
+      realms.
+
+   Pre-authentication methods
+
+      The TGS-REQ method MUST be supported. The TGS-REQ method is not
+      used on the initial request. The PA-ENC-TIMESTAMP method MUST be
+      supported by clients but whether it is enabled by default MAY be
+      determined on a realm by realm basis. If not used in the initial
+      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
+      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
+      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
+      authentication method. Servers need not support the PA-ENC-
+      TIMESTAMP method, but if not supported the server SHOULD ignore
+
+
+
+March 2003                                                    [Page 111]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
+
+      The ETYPE-INFO2 method MUST be supported; this method is used to
+      communicate the set of supported encryption types, and
+      corresponding salt and string to key paramters. The ETYPE-INFO
+      method SHOULD be supported for interoperability with older
+      implementation.
+
+   Mutual authentication
+
+      Mutual authentication (via the KRB_AP_REP message) MUST be
+      supported.
+
+   Ticket addresses and flags
+
+      All KDCs MUST pass through tickets that carry no addresses (i.e.
+      if a TGT contains no addresses, the KDC will return derivative
+      tickets).  Implementations SHOULD default to requesting
+      addressless tickets as this significantly increases
+      interoperability with network address translation.  In some cases
+      realms or application servers MAY require that tickets have an
+      address.
+
+      Implementations SHOULD accept directional address type for the
+      KRB_SAFE and KRB_PRIV message and SHOULD include directional
+      addresses in these messages when other address types are not
+      available.
+
+      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
+
+
+
+
+March 2003                                                    [Page 112]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      Implementations MUST pass all authorization data subfields from
+      ticket-granting tickets to any derivative tickets unless directed
+      to suppress a subfield as part of the definition of that
+      registered subfield type (it is never incorrect to pass on a
+      subfield, and no registered subfield types presently specify
+      suppression at the KDC).
+
+      Implementations MUST make the contents of any authorization data
+      subfields available to the server when a ticket is used.
+      Implementations are not required to allow clients to specify the
+      contents of the authorization data fields.
+
+   Constant ranges
+
+      All protocol constants are constrained to 32 bit (signed) values
+      unless further constrained by the protocol definition. This limit
+      is provided to allow implementations to make assumptions about the
+      maximum values that will be received for these constants.
+      Implementation receiving values outside this range MAY reject the
+      request, but they MUST recover cleanly.
+
+8.2. Recommended KDC values
+
+   Following is a list of recommended values for a KDC configuration.
+
+   minimum lifetime              5 minutes
+   maximum renewable lifetime    1 week
+   maximum ticket lifetime       1 day
+   acceptable clock skew         5 minutes
+   empty addresses               Allowed.
+   proxiable, etc.               Allowed.
+
+9. IANA considerations
+
+   Section 7 of this document specifies protocol constants and other
+   defined values required for the interoperability of multiple
+   implementations. Until otherwise specified in a subsequent RFC,
+   allocations of additional protocol constants and other defined values
+   required for extensions to the Kerberos protocol will be administered
+   by the Kerberos Working Group.
+
+10. Security Considerations
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network. Kerberos does not, by
+   itself, provide authorization. Applications should not accept the
+   issuance of a service ticket by the Kerberos server as granting
+   authority to use the service, since such applications may become
+
+
+
+March 2003                                                    [Page 113]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   vulnerable to the bypass of this authorization check in an
+   environment if they inter-operate with other KDCs or where other
+   options for application authentication are provided.
+
+   Denial of service attacks are not solved with Kerberos. There are
+   places in the protocols where an intruder can prevent an application
+   from participating in the proper authentication steps. Because
+   authentication is a required step for the use of many services,
+   successful denial of service attacks on a Kerberos server might
+   result in the denial of other network services that rely on Kerberos
+   for authentication. Kerberos is vulnerable to many kinds of denial of
+   service attacks: denial of service attacks on the network which would
+   prevent clients from contacting the KDC; denial of service attacks on
+   the domain name system which could prevent a client from finding the
+   IP address of the Kerberos server; and denial of service attack by
+   overloading the Kerberos KDC itself with repeated requests.
+
+   Interoperability conflicts caused by incompatible character-set usage
+   (see 5.2.1) can result in denial of service for clients that utilize
+   character-sets in Kerberos strings other than those stored in the KDC
+   database.
+
+   Authentication servers maintain a database of principals (i.e., users
+   and servers) and their secret keys. The security of the
+   authentication server machines is critical. The breach of security of
+   an authentication server will compromise the security of all servers
+   that rely upon the compromised KDC, and will compromise the
+   authentication of any principals registered in the realm of the
+   compromised KDC.
+
+   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 off-line 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.
+
+   Unless pre-authentication options are required by the policy of a
+   realm, the KDC will not know whether a request for authentication
+   succeeds. An attacker can request a reply with credentials for any
+   principal. These credentials will likely not be of much use to the
+   attacker unless it knows the client's secret key, but the
+   availability of the response encrypted in the client's secret key
+   provides the attacker with ciphertext that may be used to mount brute
+
+
+
+March 2003                                                    [Page 114]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   force or dictionary attacks to decrypt the credentials, by guessing
+   the user's password. For this reason it is strongly encouraged that
+   Kerberos realms require the use of pre-authentication. Even with pre-
+   authentication, attackers may try brute force or dictionary attacks
+   against credentials that are observed by eavesdropping on the
+   network.
+
+   Because a client can request a ticket for any server principal and
+   can attempt a brute force or dictionary attack against the server
+   principal's key using that ticket, it is strongly encouraged that
+   keys be randomly generated (rather than generated from passwords) for
+   any principals that are usable as the target principal for a
+   KRB_TGS_REQ or KRB_AS_REQ messages.
+
+   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 must 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 reusing principal identifiers, the danger of
+   inadvertent access is removed.
+
+   Proper decryption of an KRB_AS_REP message from the KDC is not
+   sufficient for the host 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. 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.
+
+   Kerberos credentials contain clear-text information identifying the
+   principals to which they apply. If privacy of this information is
+   needed, this exchange should itself be encapsulated in a protocol
+   providing for confidentiality on the exchange of these credentials.
+
+   Applications must take care to protect communications subsequent to
+   authentication either by using the KRB_PRIV or KRB_SAFE messages as
+   appropriate, or by applying their own confidentiality or integrity
+
+
+
+March 2003                                                    [Page 115]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   mechanisms on such communications. Completion of the KRB_AP_REQ and
+   KRB_AP_REP exchange without subsequent use of confidentiality and
+   integrity mechanisms provides only for authentication of the parties
+   to the communication and not confidentiality and integrity of the
+   subsequent communication. Application applying confidentiality and
+   protections mechanisms other than KRB_PRIV and KRB_SAFE must make
+   sure that the authentication step is appropriately linked with the
+   protected communication channel that is established by the
+   application.
+
+   Unless the application server provides its own suitable means to
+   protect against replay (for example, a challenge-response sequence
+   initiated by the server after authentication, or use of a server-
+   generated encryption subkey), the server must utilize a replay cache
+   to remember any authenticator presented within the allowable clock
+   skew. All services sharing a key need to use the same replay cache.
+   If separate replay caches are used, then and authenticator used with
+   one such service could later be replayed to a different service with
+   the same service principal.
+
+   If a server loses track of authenticators presented within the
+   allowable clock skew, it must reject all requests until the clock
+   skew interval has passed, providing assurance that any lost or
+   replayed authenticators will fall outside the allowable clock skew
+   and can no longer be successfully replayed.
+
+   Implementations of Kerberos should not use untrusted directory
+   servers to determine the realm of a host. To allow such would allow
+   the compromise of the directory server to enable an attacker to
+   direct the client to accept authentication with the wrong principal
+   (i.e. one with a similar name, but in a realm with which the
+   legitimate host was not registered).
+
+   Implementations of Kerberos must not use DNS to canonicalize the host
+   components of service principal names. To allow such canonicalization
+   would allow a compromise of the DNS to result in a client obtaining
+   credentials and correctly authenticating to the wrong principal.
+   Though the client will know who it is communicating with, it will not
+   be the principal with which it intended to communicate.
+
+   If the Kerberos server returns a TGT for a 'closer' realm other than
+   the desired realm, the client may use local policy configuration to
+   verify that the authentication path used is an acceptable one.
+   Alternatively, a client may choose its own authentication path,
+   rather than relying on the Kerberos server to select one. In either
+   case, any policy or configuration information used to choose or
+   validate authentication paths, whether by the Kerberos server or
+   client, must be obtained from a trusted source.
+
+
+
+March 2003                                                    [Page 116]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications. If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB_PRIV message,
+   or messages encrypted using application specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered. This
+   is because the session key use to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the KRB_TGS_REP
+   message. The session key from the ticket-granting ticket was sent to
+   the user in the KRB_AS_REP message encrypted in the user's secret
+   key, and embedded in the ticket-granting ticket, which was encrypted
+   in the key of the KDC. Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+11. Author's Addresses
+
+
+       Clifford Neuman
+       Information Sciences Institute
+       University of Southern California
+       4676 Admiralty Way
+       Marina del Rey, CA 90292, USA
+       Email: bcn@isi.edu
+
+       Tom Yu
+       Massachusetts Institute of Technology
+       77 Massachusetts Avenue
+       Cambridge, MA 02139, USA
+       Email: tlyu@mit.edu
+
+       Sam Hartman
+       Massachusetts Institute of Technology
+       77 Massachusetts Avenue
+       Cambridge, MA 02139, USA
+       Email: hartmans@mit.edu
+
+       Kenneth Raeburn
+       Massachusetts Institute of Technology
+       77 Massachusetts Avenue
+       Cambridge, MA 02139, USA
+       Email: raeburn@MIT.EDU
+
+
+12. Acknowledgements
+
+
+
+March 2003                                                    [Page 117]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   This document is a revision to RFC1510 which was co-authored with
+   John Kohl.  The specification of the Kerberos protocol described in
+   this document is the result of many years of effort.  Over this
+   period many individuals have contributed to the definition of the
+   protocol and to the writing of the specification. Unfortunately it is
+   not possible to list all contributors as authors of this document,
+   though there are many not listed who are authors in spirit, because
+   they contributed text for parts of some sections, because they
+   contributed to the design of parts of the protocol, or because they
+   contributed significantly to the discussion of the protocol in the
+   IETF common authentication technology (CAT) and Kerberos working
+   groups.
+
+   Among those contributing to the development and specification of
+   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
+   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
+   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
+   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
+   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
+   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
+   Westerlund, and Nicolas Williams. Many other members of MIT Project
+   Athena, the MIT networking group, and the Kerberos and CAT working
+   groups of the IETF contributed but are not listed.
+
+13. REFERENCES
+
+   [@KRYPTO]
+      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
+      crypto.
+
+   [@AES]
+      RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
+      rijndael-krb.
+
+   [DGT96]
+      Don Davis, Daniel Geer, and Theodore Ts'0, "Kerberos With Clocks
+      Adrift: History, Protocols, and Implementation", USENIX Computing
+      Systems 9:1 (Januart 1996).
+
+   [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).
+
+   [ISO-646/ECMA-6]
+      7-bit Coded Character Set
+
+   [ISO-2022/ECMA-35]
+
+
+
+March 2003                                                    [Page 118]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      Character Code Structure and Extension Techniques
+
+   [ISO-4873/ECMA-43]
+      8-bit Coded Character Set Structure and Rules
+
+   [KNT94]
+
+      John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+      Evolution of the Kerberos Authentication System". In Distributed
+      Open Systems, pages 78-94. IEEE Computer Society Press, 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).
+
+   [Neu93]
+      B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
+      Distributed Systems," in Proceedings of the 13th International
+      Conference on Distributed Computing Systems, Pittsburgh, PA (May,
+      1993).
+
+   [NS78]
+      Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+      Authentication in Large Networks of Computers," Communications of
+      the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+   [NT94]
+      B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
+      Service for Computer Networks," IEEE Communications Magazine, Vol.
+      32(9), pp.  33-38 (September 1994).
+
+   [Pat92].
+      J. Pato, Using Pre-Authentication to Avoid Password Guessing
+      Attacks, Open Software Foundation DCE Request for Comments 26
+      (December 1992).
+
+   [RFC1035]
+      P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
+      Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
+      RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
+      RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
+      RFC2535, RFC2845, and RFC3425. Status: Standard.
+
+   [RFC1510]
+      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
+      Authentication Service (v5)," September 1993, Status: Proposed
+
+
+
+March 2003                                                    [Page 119]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+      Standard.
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2052]
+      A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying the
+      Location of Services (DNS SRV)," October 1996, Obseleted by
+      RFC2782, Status: Experimental
+
+   [RFC2253]
+      M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
+      Access Protocol (v3): UTF-8 String Representation or Distinguished
+      Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
+      Status: Proposed Standard.
+
+   [RFC2273]
+      D. Levi, P. Meyer, and B. Stewart, RFC2273: "SNMPv3 Applications,"
+      January 1998, Obsoletes - RFC2263, Obsoleted by RFC2573, Status:
+      Proposed Standard.
+
+   [RFC2373]
+      R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
+      Architecture," July 1998, Status: Proposed Standard.
+
+   [SNS88]
+      J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
+      Authentication Service for Open Network Systems," pp. 191-202 in
+      Usenix Conference Proceedings, Dallas, Texas (February, 1988).
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+
+A. ASN.1 module
+
+   KerberosV5Spec2 {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) krb5spec2(2)
+
+
+
+March 2003                                                    [Page 120]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   -- OID arc for KerberosV5
+   --
+   -- This OID may be used to identify Kerberos protocol messages
+   -- encapsulated in other protocols.
+   --
+   -- This OID also designates the OID arc for KerberosV5-related OIDs.
+   --
+   -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
+   id-krb5         OBJECT IDENTIFIER ::= {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2)
+   }
+
+   Int32           ::= INTEGER (-2147483648..2147483647)
+                       -- signed values representable in 32 bits
+
+   UInt32          ::= INTEGER (0..4294967295)
+                       -- unsigned 32 bit values
+
+   Microseconds    ::= INTEGER (0..999999)
+                       -- microseconds
+
+   KerberosString  ::= GeneralString (IA5String)
+
+   Realm           ::= KerberosString
+
+   PrincipalName   ::= SEQUENCE {
+           name-type       [0] Int32,
+           name-string     [1] SEQUENCE OF KerberosString
+   }
+
+   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+   HostAddress     ::= SEQUENCE  {
+           addr-type       [0] Int32,
+           address         [1] OCTET STRING
+   }
+
+   -- NOTE: HostAddresses is always used as an OPTIONAL field and
+   -- should not be empty.
+   HostAddresses   -- NOTE: subtly different from rfc1510,
+                   -- but has a value mapping and encodes the same
+           ::= SEQUENCE OF HostAddress
+
+   -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+   -- should not be empty.
+
+
+
+March 2003                                                    [Page 121]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+           ad-type         [0] Int32,
+           ad-data         [1] OCTET STRING
+   }
+
+   PA-DATA         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           padata-type     [1] Int32,
+           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+   }
+
+   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
+                       -- shall be sent, but no fewer than 32
+
+   EncryptedData   ::= SEQUENCE {
+           etype   [0] Int32 -- EncryptionType --,
+           kvno    [1] UInt32 OPTIONAL,
+           cipher  [2] OCTET STRING -- ciphertext
+   }
+
+   EncryptionKey   ::= SEQUENCE {
+           keytype         [0] Int32 -- actually encryption type --,
+           keyvalue        [1] OCTET STRING
+   }
+
+   Checksum        ::= SEQUENCE {
+           cksumtype       [0] Int32,
+           checksum        [1] OCTET STRING
+   }
+
+   Ticket          ::= [APPLICATION 1] SEQUENCE {
+           tkt-vno         [0] INTEGER (5),
+           realm           [1] Realm,
+           sname           [2] PrincipalName,
+           enc-part        [3] EncryptedData -- EncTicketPart
+   }
+
+   -- 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,
+
+
+
+March 2003                                                    [Page 122]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           caddr                   [9] HostAddresses OPTIONAL,
+           authorization-data      [10] AuthorizationData OPTIONAL
+   }
+
+   -- encoded Transited field
+   TransitedEncoding       ::= SEQUENCE {
+           tr-type         [0] Int32 -- must be registered --,
+           contents        [1] OCTET STRING
+   }
+
+   TicketFlags     ::= KerberosFlags
+           -- 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),
+   -- the following are new since 1510
+           -- transited-policy-checked(12),
+           -- ok-as-delegate(13)
+
+   AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+   KDC-REQ         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           pvno            [1] INTEGER (5) ,
+           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                               -- NOTE: not empty --,
+           req-body        [4] KDC-REQ-BODY
+   }
+
+   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,
+
+
+
+March 2003                                                    [Page 123]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           from                    [4] KerberosTime OPTIONAL,
+           till                    [5] KerberosTime,
+           rtime                   [6] KerberosTime OPTIONAL,
+           nonce                   [7] UInt32,
+           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                       -- in preference order --,
+           addresses               [9] HostAddresses OPTIONAL,
+           enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
+           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                           -- NOTE: not empty
+   }
+
+   KDCOptions      ::= KerberosFlags
+           -- reserved(0),
+           -- forwardable(1),
+           -- forwarded(2),
+           -- proxiable(3),
+           -- proxy(4),
+           -- allow-postdate(5),
+           -- postdated(6),
+           -- unused7(7),
+           -- renewable(8),
+           -- unused9(9),
+           -- unused10(10),
+           -- opt-hardware-auth(11),
+           -- unused12(12),
+           -- unused13(13),
+   -- 15 is reserved for canonicalize
+           -- unused15(15),
+   -- 26 was unused in 1510
+           -- disable-transited-check(26),
+   --
+           -- renewable-ok(27),
+           -- enc-tkt-in-skey(28),
+           -- renew(30),
+           -- validate(31)
+
+   AS-REP          ::= [APPLICATION 11] KDC-REP
+
+   TGS-REP         ::= [APPLICATION 13] KDC-REP
+
+   KDC-REP         ::= SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                   -- NOTE: not empty --,
+           crealm          [3] Realm,
+           cname           [4] PrincipalName,
+
+
+
+March 2003                                                    [Page 124]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           ticket          [5] Ticket,
+           enc-part        [6] EncryptedData
+                                   -- EncASRepPart or EncTGSRepPart,
+                                   -- as appropriate
+   }
+
+   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+   EncKDCRepPart   ::= SEQUENCE {
+           key             [0] EncryptionKey,
+           last-req        [1] LastReq,
+           nonce           [2] UInt32,
+           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
+   }
+
+   LastReq         ::=     SEQUENCE OF SEQUENCE {
+           lr-type         [0] Int32,
+           lr-value        [1] KerberosTime
+   }
+
+   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (14),
+           ap-options      [2] APOptions,
+           ticket          [3] Ticket,
+           authenticator   [4] EncryptedData -- Authenticator
+   }
+
+   APOptions       ::= KerberosFlags
+           -- reserved(0),
+           -- use-session-key(1),
+           -- mutual-required(2)
+
+   -- Unencrypted authenticator
+   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+           authenticator-vno       [0] INTEGER (5),
+           crealm                  [1] Realm,
+           cname                   [2] PrincipalName,
+
+
+
+March 2003                                                    [Page 125]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           cksum                   [3] Checksum OPTIONAL,
+           cusec                   [4] Microseconds,
+           ctime                   [5] KerberosTime,
+           subkey                  [6] EncryptionKey OPTIONAL,
+           seq-number              [7] UInt32 OPTIONAL,
+           authorization-data      [8] AuthorizationData OPTIONAL
+   }
+
+   AP-REP          ::= [APPLICATION 15] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (15),
+           enc-part        [2] EncryptedData -- EncAPRepPart
+   }
+
+   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+           ctime           [0] KerberosTime,
+           cusec           [1] Microseconds,
+           subkey          [2] EncryptionKey OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL
+   }
+
+   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (20),
+           safe-body       [2] KRB-SAFE-BODY,
+           cksum           [3] Checksum
+   }
+
+   KRB-SAFE-BODY   ::= SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress,
+           r-address       [5] HostAddress OPTIONAL
+   }
+
+   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (21),
+                           -- NOTE: there is no [2] tag
+           enc-part        [3] EncryptedData -- EncKrbPrivPart
+   }
+
+   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+
+
+
+March 2003                                                    [Page 126]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress -- sender's addr --,
+           r-address       [5] HostAddress OPTIONAL -- recip's addr
+   }
+
+   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (22),
+           tickets         [2] SEQUENCE OF Ticket,
+           enc-part        [3] EncryptedData -- EncKrbCredPart
+   }
+
+   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+           ticket-info     [0] SEQUENCE OF KrbCredInfo,
+           nonce           [1] UInt32 OPTIONAL,
+           timestamp       [2] KerberosTime OPTIONAL,
+           usec            [3] Microseconds 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
+   }
+
+   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (30),
+           ctime           [2] KerberosTime OPTIONAL,
+           cusec           [3] Microseconds OPTIONAL,
+           stime           [4] KerberosTime,
+           susec           [5] Microseconds,
+           error-code      [6] Int32,
+           crealm          [7] Realm OPTIONAL,
+           cname           [8] PrincipalName OPTIONAL,
+           realm           [9] Realm -- service realm --,
+           sname           [10] PrincipalName -- service name --,
+           e-text          [11] KerberosString OPTIONAL,
+
+
+
+March 2003                                                    [Page 127]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+           e-data          [12] OCTET STRING OPTIONAL
+   }
+
+   METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+           data-type       [0] INTEGER,
+           data-value      [1] OCTET STRING OPTIONAL
+   }
+
+   -- preauth stuff follows
+
+   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+   PA-ENC-TS-ENC           ::= SEQUENCE {
+           patimestamp     [0] KerberosTime -- client's time --,
+           pausec          [1] Microseconds OPTIONAL
+   }
+
+   ETYPE-INFO-ENTRY        ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] KerberosString OPTIONAL,
+           s2kparams       [2] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY
+
+   AD-IF-RELEVANT          ::= AuthorizationData
+
+   AD-KDCIssued            ::= SEQUENCE {
+           ad-checksum     [0] Checksum,
+           i-realm         [1] Realm OPTIONAL,
+           i-sname         [2] PrincipalName OPTIONAL,
+           elements        [3] AuthorizationData
+   }
+
+   AD-AND-OR               ::= SEQUENCE {
+           condition-count [0] INTEGER,
+           elements        [1] AuthorizationData
+   }
+
+
+
+
+March 2003                                                    [Page 128]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+   END
+
+B. Changes since RFC-1510
+
+   This document replaces RFC-1510 and clarifies specification of items
+   that were not completely specified. Where changes to recommended
+   implementation choices were made, or where new options were added,
+   those changes are described within the document and listed in this
+   section. More significantly, "Specification 2" in section 8 changes
+   the required encryption and checksum methods to bring them in line
+   with the best current practices and to deprecate methods that are no
+   longer considered sufficiently strong.
+
+   Discussion was added to section 1 regarding the ability to rely on
+   the KDC to check the transited field, and on the inclusion of a flag
+   in a ticket indicating that this check has occurred. This is a new
+   capability not present in RFC1510. Pre-existing implementations may
+   ignore or not set this flag without negative security implications.
+
+   The definition of the secret key says that in the case of a user the
+   key may be derived from a password. In 1510, it said that the key was
+   derived from the password. This change was made to accommodate
+   situations where the user key might be stored on a smart-card, or
+   otherwise obtained independent of a password.
+
+   The introduction mentions the use of public key cryptography for
+   initial authentication in Kerberos by reference. RFC1510 did not
+   include such a reference.
+
+   Section 1.2 was added to explain that while Kerberos provides
+   authentication of a named principal, it is still the responsibility
+   of the application to ensure that the authenticated name is the
+   entity with which the application wishes to communicate.
+
+   Discussion of extensibility has been added to the introduction.
+
+   Discussion of how extensibility affects ticket flags and KDC options
+   was added to the introduction of section 2. No changes were made to
+   existing options and flags specified in RFC1510, though some of the
+   sections in the specification were renumbered, and text was revised
+   to make the description and intent of existing options clearer,
+   especially with respect to the ENC-TKT-IN-SKEY option (now section
+   2.9.2) which is used for user-to-user authentication.  The new option
+   and ticket flag transited policy checking (section 2.7) was added.
+
+   A warning regarding generation of session keys for application use
+
+
+
+March 2003                                                    [Page 129]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   was added to section 3, urging the inclusion of key entropy from the
+   KDC generated session key in the ticket. An example regarding use of
+   the sub-session key was added to section 3.2.6. Descriptions of the
+   pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
+   items were added. The recommendation for use of pre-authentication
+   was changed from "may" to "should" and a note was added regarding
+   known plaintext attacks.
+
+   In RFC 1510, section 4 described the database in the KDC. This
+   discussion was not necessary for interoperability and unnecessarily
+   constrained implementation. The old section 4 was removed.
+
+   The current section 4 was formerly section 6 on encryption and
+   checksum specifications. The major part of this section was brought
+   up to date to support new encryption methods, and move to a separate
+   document. Those few remaining aspects of the encryption and checksum
+   specification specific to Kerberos are now specified in section 4.
+
+   Significant changes were made to the layout of section 5 to clarify
+   the correct behavior for optional fields. Many of these changes were
+   made necessary because of improper ASN.1 description in the original
+   Kerberos specification which left the correct behavior
+   underspecified. Additionally, the wording in this section was
+   tightened wherever possible to ensure that implementations conforming
+   to this specification will be extensible with the addition of new
+   fields in future specifications.
+
+   Text was added describing time_t=0 issues in the ASN.1. Text was also
+   added, clarifying issues with implementations treating omitted
+   optional integers as zero. Text was added clarifying behavior for
+   optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was
+   added regarding sequence numbers and behavior of some
+   implementations, including "zero" behavior and negative numbers. A
+   compatibility note was added regarding the unconditional sending of
+   EncTGSRepPart regardless of the enclosing reply type. Minor changes
+   were made to the description of the HostAddresses type. Integer types
+   were constrained. KerberosString was defined as a (significantly)
+   constrained GeneralString. KerberosFlags was defined to reflect
+   existing implementation behavior that departs from the definition in
+   RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13)
+   ticket flags were added. The disable-transited-check(26) KDC option
+   was added.
+
+   Descriptions of commonly implemented PA-DATA were added to section 5.
+   The description of KRB-SAFE has been updated to note the existing
+   implementation behavior of double-encoding.
+
+   There were two definitions of METHOD-DATA in RFC 1510. The second
+
+
+
+March 2003                                                    [Page 130]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
+   SEQUENCE OF PA-DATA definition.
+
+   Section 7, naming constraints, from RFC1510 was moved to section 6.
+
+   Words were added describing the convention that domain based realm
+   names for newly created realms should be specified as upper case.
+   This recommendation does not make lower case realm names illegal.
+   Words were added highlighting that the slash separated components in
+   the X500 style of realm names is consistent with existing RFC1510
+   based implementations, but that it conflicts with the general
+   recommendation of X.500 name representation specified in RFC2253.
+
+   Section 8, network transport, constants and defined values, from
+   RFC1510 was moved to section 7.  Since RFC1510, the definition of the
+   TCP transport for Kerberos messages was added, and the encryption and
+   checksum number assignments have been moved into a separate document.
+
+   "Specification 2" in section 8 of the current document changes the
+   required encryption and checksum methods to bring them in line with
+   the best current practices and to deprecate methods that are no
+   longer considered sufficiently strong.
+
+   Two new sections, on IANA considerations and security considerations
+   were added.
+
+   The pseudo-code has been removed from the appendix. The pseudo-code
+   was sometimes misinterpreted to limit implementation choices and in
+   RFC 1510, it was not always consistent with the words in the
+   specification. Effort was made to clear up any ambiguities in the
+   specification, rather than to rely on the pseudo-code.
+
+   An appendix was added containing the complete ASN.1 module drawn from
+   the discussion in section 5 of the current document.
+
+   An appendix was added defining those authorization data elements that
+   must be understood by all Kerberos implementations.
+
+END NOTES
+
+   [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
+
+
+
+March 2003                                                    [Page 131]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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 principal 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 tickets 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 session 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] Note also that the rejection here is restricted to
+
+
+
+March 2003                                                    [Page 132]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
+
+
+   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.
+
+   [11] If this is not done, an attacker could subvert the
+   authentication by recording the ticket and authenticator sent over
+   the network to a server and replaying them following an event that
+   caused the server to lose track of recently seen authenticators.
+
+   [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 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
+   configuration 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 authenticated.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+March 2003                                                    [Page 133]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt
new file mode 100644
index 00000000000..1d62a9589dd
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt
@@ -0,0 +1,8267 @@
+INTERNET-DRAFT                                          Clifford Neuman
+Obsoletes: 1510                                                 USC-ISI
+                                                                 Tom Yu
+                                                            Sam Hartman
+                                                            Ken Raeburn
+                                                                    MIT
+                                                      February 15, 2004
+                                                Expires 15 August, 2004
+
+            The Kerberos Network Authentication Service (V5)
+
+STATUS OF THIS MEMO
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of 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-krb-wg-kerberos-clarifications-05.txt, and expires 15 August
+   2004.  Please send comments to: ietf-krb-wg@anl.gov
+
+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.
+
+
+
+February 2004                                                   [Page 1]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+OVERVIEW
+
+   This document 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].
+
+   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.
+
+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 Ts'o, 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 [KNT94].
+
+   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.
+
+
+February 2004                                                   [Page 2]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                            Table of Contents
+
+
+
+1. Introduction ...................................................    7
+1.1. Cross-realm operation ........................................    9
+1.2. Choosing a principal with which to communicate ...............   10
+1.3. Authorization ................................................   11
+1.4. Extending Kerberos Without Breaking Interoperability .........   12
+1.4.1. Compatibility with RFC 1510 ................................   12
+1.4.2. Sending Extensible Messages ................................   13
+1.5. Environmental assumptions ....................................   14
+1.6. Glossary of terms ............................................   14
+2. Ticket flag uses and requests ..................................   17
+2.1. Initial, pre-authenticated, and hardware authenticated
+      tickets .....................................................   18
+2.2. Invalid tickets ..............................................   18
+2.3. Renewable tickets ............................................   18
+2.4. Postdated tickets ............................................   19
+2.5. Proxiable and proxy tickets ..................................   20
+2.6. Forwardable tickets ..........................................   21
+2.7. Transited Policy Checking ....................................   21
+2.8. OK as Delegate ...............................................   22
+2.9. Other KDC options ............................................   23
+2.9.1. Renewable-OK ...............................................   23
+2.9.2. ENC-TKT-IN-SKEY ............................................   23
+2.9.3. Passwordless Hardware Authentication .......................   23
+3. Message Exchanges ..............................................   23
+3.1. The Authentication Service Exchange ..........................   23
+3.1.1. Generation of KRB_AS_REQ message ...........................   25
+3.1.2. Receipt of KRB_AS_REQ message ..............................   25
+3.1.3. Generation of KRB_AS_REP message ...........................   25
+3.1.4. Generation of KRB_ERROR message ............................   28
+3.1.5. Receipt of KRB_AS_REP message ..............................   28
+3.1.6. Receipt of KRB_ERROR message ...............................   29
+3.2. The Client/Server Authentication Exchange ....................   30
+3.2.1. The KRB_AP_REQ message .....................................   30
+3.2.2. Generation of a KRB_AP_REQ message .........................   30
+3.2.3. Receipt of KRB_AP_REQ message ..............................   31
+3.2.4. Generation of a KRB_AP_REP message .........................   33
+3.2.5. Receipt of KRB_AP_REP message ..............................   33
+3.2.6. Using the encryption key ...................................   34
+3.3. The Ticket-Granting Service (TGS) Exchange ...................   34
+3.3.1. Generation of KRB_TGS_REQ message ..........................   36
+3.3.2. Receipt of KRB_TGS_REQ message .............................   37
+
+
+
+February 2004                                                   [Page 3]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+3.3.3. Generation of KRB_TGS_REP message ..........................   38
+3.3.3.1. Checking for revoked tickets .............................   40
+3.3.3.2. Encoding the transited field .............................   41
+3.3.4. Receipt of KRB_TGS_REP message .............................   42
+3.4. The KRB_SAFE Exchange ........................................   43
+3.4.1. Generation of a KRB_SAFE message ...........................   43
+3.4.2. Receipt of KRB_SAFE message ................................   43
+3.5. The KRB_PRIV Exchange ........................................   44
+3.5.1. Generation of a KRB_PRIV message ...........................   45
+3.5.2. Receipt of KRB_PRIV message ................................   45
+3.6. The KRB_CRED Exchange ........................................   46
+3.6.1. Generation of a KRB_CRED message ...........................   46
+3.6.2. Receipt of KRB_CRED message ................................   47
+3.7. User-to-User Authentication Exchanges ........................   47
+4. Encryption and Checksum Specifications .........................   49
+5. Message Specifications .........................................   50
+5.1. Specific Compatibility Notes on ASN.1 ........................   52
+5.1.1. ASN.1 Distinguished Encoding Rules .........................   52
+5.1.2. Optional Integer Fields ....................................   52
+5.1.3. Empty SEQUENCE OF Types ....................................   52
+5.1.4. Unrecognized Tag Numbers ...................................   53
+5.1.5. Tag Numbers Greater Than 30 ................................   53
+5.2. Basic Kerberos Types .........................................   53
+5.2.1. KerberosString .............................................   53
+5.2.2. Realm and PrincipalName ....................................   55
+5.2.3. KerberosTime ...............................................   56
+5.2.4. Constrained Integer types ..................................   56
+5.2.5. HostAddress and HostAddresses ..............................   57
+5.2.6. AuthorizationData ..........................................   57
+5.2.6.1. IF-RELEVANT ..............................................   59
+5.2.6.2. KDCIssued ................................................   59
+5.2.6.3. AND-OR ...................................................   60
+5.2.6.4. MANDATORY-FOR-KDC ........................................   60
+5.2.7. PA-DATA ....................................................   61
+5.2.7.1. PA-TGS-REQ ...............................................   62
+5.2.7.2. Encrypted Timestamp Pre-authentication ...................   62
+5.2.7.3. PA-PW-SALT ...............................................   62
+5.2.7.4. PA-ETYPE-INFO ............................................   63
+5.2.7.5. PA-ETYPE-INFO2 ...........................................   63
+5.2.8. KerberosFlags ..............................................   64
+5.2.9. Cryptosystem-related Types .................................   65
+5.3. Tickets ......................................................   67
+5.4. Specifications for the AS and TGS exchanges ..................   74
+5.4.1. KRB_KDC_REQ definition .....................................   74
+5.4.2. KRB_KDC_REP definition .....................................   82
+5.5. Client/Server (CS) message specifications ....................   85
+5.5.1. KRB_AP_REQ definition ......................................   85
+5.5.2. KRB_AP_REP definition ......................................   89
+
+
+
+February 2004                                                   [Page 4]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+5.5.3. Error message reply ........................................   90
+5.6. KRB_SAFE message specification ...............................   90
+5.6.1. KRB_SAFE definition ........................................   90
+5.7. KRB_PRIV message specification ...............................   92
+5.7.1. KRB_PRIV definition ........................................   92
+5.8. KRB_CRED message specification ...............................   92
+5.8.1. KRB_CRED definition ........................................   93
+5.9. Error message specification ..................................   95
+5.9.1. KRB_ERROR definition .......................................   95
+5.10. Application Tag Numbers .....................................   97
+6. Naming Constraints .............................................   98
+6.1. Realm Names ..................................................   98
+6.2. Principal Names ..............................................   99
+6.2.1. Name of server principals ..................................  101
+7. Constants and other defined values .............................  101
+7.1. Host address types ...........................................  101
+7.2. KDC messaging - IP Transports ................................  103
+7.2.1. UDP/IP transport ...........................................  103
+7.2.2. TCP/IP transport ...........................................  103
+7.2.3. KDC Discovery on IP Networks ...............................  104
+7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names .......  105
+7.2.3.2. Specifying KDC Location information with DNS SRV
+      records .....................................................  105
+7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
+      Networks ....................................................  106
+7.3. Name of the TGS ..............................................  106
+7.4. OID arc for KerberosV5 .......................................  106
+7.5. Protocol constants and associated values .....................  106
+7.5.1. Key usage numbers ..........................................  107
+7.5.2. PreAuthentication Data Types
+      .............................................................  108
+7.5.3. Address Types
+      .............................................................  109
+7.5.4. Authorization Data Types
+      .............................................................  109
+7.5.5. Transited Encoding Types
+      .............................................................  109
+7.5.6. Protocol Version Number
+      .............................................................  110
+7.5.7. Kerberos Message Types
+      .............................................................  110
+7.5.8. Name Types
+      .............................................................  110
+7.5.9. Error Codes
+      .............................................................  110
+8. Interoperability requirements ..................................  112
+8.1. Specification 2 ..............................................  112
+8.2. Recommended KDC values .......................................  115
+
+
+
+February 2004                                                   [Page 5]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+9. IANA considerations ............................................  115
+10. Security Considerations .......................................  116
+11. Author's Addresses ............................................  120
+12. Acknowledgements ..............................................  121
+13. REFERENCES ....................................................  122
+13.1 NORMATIVE REFERENCES .........................................  122
+13.2 INFORMATIVE REFERENCES .......................................  123
+14. Copyright Statement ...........................................  124
+15. Intellectual Property .........................................  125
+A. ASN.1 module ...................................................  125
+B. Changes since RFC-1510 .........................................  133
+END NOTES .........................................................  136
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+February 2004                                                   [Page 6]
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+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 (outside the scope of this document) can provide for
+      the use of public key cryptography during certain phases of the
+      authentication protocol [@RFCE: if PKINIT advances concurrently
+      include reference to the RFC here]. Such extensions support
+      Kerberos authentication for users registered with public key
+      certification authorities and 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 a "ticket" for the server and 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 calls to the Kerberos library directly or through the Generic
+      Security Services Application Programming Interface, GSSAPI,
+      described in separate document [ref to GSSAPI RFC]. 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
+
+
+
+February 2004                                                   [Page 7]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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
+      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 sub-session key found in the
+      authenticator.
+
+      The authentication exchanges mentioned above require read-only
+
+
+
+February 2004                                                   [Page 8]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 may be 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
+
+
+
+February 2004                                                   [Page 9]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 KDCs 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 KDCs not check the transited field by setting the
+      DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this flag.
+
+1.2. Choosing a principal with which to communicate
+
+      The Kerberos protocol provides the means for verifying (subject to
+      the assumptions in 1.5) that the entity with which one
+      communicates is the same entity that was registered with the KDC
+      using the claimed identity (principal name). It is still necessary
+      to determine whether that identity corresponds to the entity with
+      which one intends to communicate.
+
+      When appropriate data has been exchanged in advance, this
+      determination may be performed syntactically by the application
+      based on the application protocol specification, information
+      provided by the user, and configuration files. For example, the
+      server principal name (including realm) for a telnet server might
+      be derived from the user specified host name (from the telnet
+      command line), the "host/" prefix specified in the application
+      protocol specification, and a mapping to a Kerberos realm derived
+      syntactically from the domain part of the specified hostname and
+      information from the local Kerberos realms database.
+
+      One can also rely on trusted third parties to make this
+      determination, but only when the data obtained from the third
+      party is suitably integrity protected while resident on the third
+      party server and when transmitted.  Thus, for example, one should
+      not rely on an unprotected domain name system record to map a host
+      alias to the primary name of a server, accepting the primary name
+      as the party one intends to contact, since an attacker can modify
+      the mapping and impersonate the party with which one intended to
+
+
+
+February 2004                                                  [Page 10]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      communicate.
+
+      Implementations of Kerberos and protocols based on Kerberos MUST
+      NOT use insecure DNS queries to canonicalize the hostname
+      components of the service principal names (i.e. MUST NOT use
+      insecure DNS queries to map one name to another to determine the
+      host part of the principal name with which one is to communicate).
+      In an environment without secure name service, application authors
+      MAY append a statically configured domain name to unqualified
+      hostnames before passing the name to the security mechanisms, but
+      should do no more than that.  Secure name service facilities, if
+      available, might be trusted for hostname canonicalization, but
+      such canonicalization by the client SHOULD NOT be required by KDC
+      implementations.
+
+      Implementation note: Many current implementations do some degree
+      of canonicalization of the provided service name, often using DNS
+      even though it creates security problems. However there is no
+      consistency among implementations about whether the service name
+      is case folded to lower case or whether reverse resolution is
+      used. To maximize interoperability and security, applications
+      SHOULD provide security mechanisms with names which result from
+      folding the user-entered name to lower case, without performing
+      any other modifications or canonicalization.
+
+1.3. 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 utilize
+      files on 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 ticket's
+      authorization data when encapsulated by the KDC-issued
+      authorization data element.
+
+
+
+
+February 2004                                                  [Page 11]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Applications should not 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 are provided.
+
+1.4. Extending Kerberos Without Breaking Interoperability
+
+      As the deployed base of Kerberos implementations grows, extending
+      Kerberos becomes more important. Unfortunately some extensions to
+      the existing Kerberos protocol create interoperability issues
+      because of uncertainty regarding the treatment of certain
+      extensibility options by some implementations. This section
+      includes guidelines that will enable future implementations to
+      maintain interoperability.
+
+      Kerberos provides a general mechanism for protocol extensibility.
+      Some protocol messages contain typed holes -- sub-messages that
+      contain an octet-string along with an integer that defines how to
+      interpret the octet-string. The integer types are registered
+      centrally, but can be used both for vendor extensions and for
+      extensions standardized through the IETF.
+
+      In this document, the word "extension" means an extension by
+      defining a new type to insert into an existing typed hole in a
+      protocol message.  It does not mean extension by addition of new
+      fields to ASN.1 types, unless explicitly indicated otherwise in
+      the text.
+
+1.4.1. Compatibility with RFC 1510
+
+      It is important to note that existing Kerberos message formats can
+      not be readily extended by adding fields to the ASN.1 types.
+      Sending additional fields often results in the entire message
+      being discarded without an error indication. Future versions of
+      this specification will provide guidelines to ensure that ASN.1
+      fields can be added without creating an interoperability problem.
+
+      In the meantime, all new or modified implementations of Kerberos
+      that receive an unknown message extension SHOULD preserve the
+      encoding of the extension but otherwise ignore the presence of the
+      extension. Recipients MUST NOT decline a request simply because an
+      extension is present.
+
+      There is one exception to this rule. If an unknown authorization
+      data element type is received by a server other than the ticket
+      granting service either in an AP-REQ or in a ticket contained in
+
+
+
+February 2004                                                  [Page 12]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      an AP-REQ, then authentication MUST fail. One of the primary uses
+      of authorization data is to restrict the use of the ticket. If the
+      service cannot determine whether the restriction applies to that
+      service then a security weakness may result if the ticket can be
+      used for that service. Authorization elements that are optional
+      SHOULD be enclosed in the AD-IF-RELEVANT element.
+
+      The ticket granting service MUST ignore but propagate to
+      derivative tickets any unknown authorization data types, unless
+      those data types are embedded in a MANDATORY-FOR-KDC element, in
+      which case the request will be rejected.  This behavior is
+      appropriate because requiring that the ticket granting service
+      understand unknown authorization data types would require that KDC
+      software be upgraded to understand new application-level
+      restrictions before applications used these restrictions,
+      decreasing the utility of authorization data as a mechanism for
+      restricting the use of tickets. No security problem is created
+      because services to which the tickets are issued will verify the
+      authorization data.
+
+      Implementation note: Many RFC 1510 implementations ignore unknown
+      authorization data elements. Depending on these implementations to
+      honor authorization data restrictions may create a security
+      weakness.
+
+1.4.2. Sending Extensible Messages
+
+      Care must be taken to ensure that old implementations can
+      understand messages sent to them even if they do not understand an
+      extension that is used. Unless the sender knows an extension is
+      supported, the extension cannot change the semantics of the core
+      message or previously defined extensions.
+
+      For example, an extension including key information necessary to
+      decrypt the encrypted part of a KDC-REP could only be used in
+      situations where the recipient was known to support the extension.
+      Thus when designing such extensions it is important to provide a
+      way for the recipient to notify the sender of support for the
+      extension. For example in the case of an extension that changes
+      the KDC-REP reply key, the client could indicate support for the
+      extension by including a padata element in the AS-REQ sequence.
+      The KDC should only use the extension if this padata element is
+      present in the AS-REQ. Even if policy requires the use of the
+      extension, it is better to return an error indicating that the
+      extension is required than to use the extension when the recipient
+      may not support it; debugging why implementations do not
+      interoperate is easier when errors are returned.
+
+
+
+
+February 2004                                                  [Page 13]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+1.5. 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 the 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 not-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 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.6. Glossary of terms
+
+      Below is a list of terms used throughout this document.
+
+   Authentication
+      Verifying the claimed identity of a principal.
+
+
+
+
+February 2004                                                  [Page 14]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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.
+
+   Encryption Type (etype)
+      When associated with encrypted data, an encryption type identifies
+      the algorithm used to encrypt the data and is used to select the
+      appropriate algorithm for decrypting the data.  Encryption type
+      tags are communicated in other messages to enumerate algorithms
+      that are desired, supported, preferred, or allowed to be used for
+      encryption of data between parties.  This preference is combined
+      with local information and policy to select an algorithm to be
+      used.
+
+
+
+February 2004                                                  [Page 15]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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
+      The name given to the Project Athena's authentication service, the
+      protocol used by that service, or the code used to implement the
+      authentication service.  The name is adopted from the three-headed
+      dog which guards Hades.
+
+   Key Version Number (kvno)
+      A tag associated with encrypted data identifies which key was used
+      for encryption when a long lived key associated with a principal
+      changes over time.  It is used during the transition to a new key
+      so that the party decrypting a message can tell whether the data
+      was encrypted using the old or the new key.
+
+   Plaintext
+      The input to an encryption function or the output of a decryption
+      function. Decryption transforms ciphertext into plaintext.
+
+   Principal
+      A named client or server entity that participates in a network
+      communication, with one name that is considered canonical.
+
+   Principal identifier
+      The canonical 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 MAY be derived
+      from a password.
+
+   Server
+      A particular Principal which provides a resource to network
+      clients.  The server is sometimes referred to as the Application
+
+
+
+February 2004                                                  [Page 16]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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".  In
+      the Kerberos system, a session key is generated by the KDC.  The
+      session key is distinct from the sub-session key, described next..
+
+   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. The sub-
+      session key is also referred to as the subkey.
+
+   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 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 give examples of
+      reasons to use them. With the exception of the INVALID flag
+      clients MUST ignore ticket flags that are not recognized. KDCs
+      MUST ignore KDC options that are not recognized. Some
+      implementations of RFC 1510 are known to reject unknown KDC
+      options, so clients may need to resend a request without new KDC
+      options if the request was rejected when sent with options added
+      since RFC 1510. Since new KDCs will ignore unknown options,
+      clients MUST confirm that the ticket returned by the KDC meets
+      their needs.
+
+      Note that it is not, in general, possible to determine whether an
+      option was not honored because it was not understood or because it
+      was rejected either through configuration or policy. When adding a
+      new option to the Kerberos protocol, designers should consider
+      whether the distinction is important for their option. In cases
+
+
+
+February 2004                                                  [Page 17]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      where it is, a mechanism for the KDC to return an indication that
+      the option was understood but rejected needs to be provided in the
+      specification of the option. Often in such cases, the mechanism
+      needs to be broad enough to permit an error or reason to be
+      returned.
+
+2.1. Initial, pre-authenticated, and hardware authenticated tickets
+
+      The INITIAL flag indicates that a ticket was issued using the AS
+      protocol, rather than 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 additional
+      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 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
+
+
+
+February 2004                                                  [Page 18]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 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
+
+
+
+February 2004                                                  [Page 19]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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, users wishing to
+      delegate their identity in a form usable for all 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
+
+
+
+February 2004                                                  [Page 20]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 that is granted is 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.
+
+      If addressless tickets are forwarded from one system to another,
+      clients SHOULD still use this option to obtain a new TGT in order
+      to have different session keys on the different systems.
+
+2.7. Transited Policy Checking
+
+      In Kerberos, the application server is ultimately responsible for
+      accepting or rejecting authentication and SHOULD check that only
+
+
+
+February 2004                                                  [Page 21]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      suitably trusted KDCs are relied upon to authenticate a principal.
+      The transited field in the ticket identifies which realms (and
+      thus which KDCs) were involved in the authentication process and
+      an application server would normally check this field. If any of
+      these are untrusted to authenticate the indicated client principal
+      (probably determined by a realm-based policy), the authentication
+      attempt MUST be rejected. The presence of trusted KDCs in this
+      list does not provide any guarantee; an untrusted KDC may have
+      fabricated the list.
+
+      While the end server ultimately decides whether authentication is
+      valid, the KDC for the end server's realm MAY apply a realm
+      specific policy for validating the transited field and accepting
+      credentials for cross-realm authentication. When the KDC applies
+      such checks and accepts such cross-realm authentication it will
+      set the TRANSITED-POLICY-CHECKED flag in the service tickets it
+      issues based on the cross-realm TGT. A client MAY request that the
+      KDCs not check the transited field by setting the DISABLE-
+      TRANSITED-CHECK flag. KDCs are encouraged but not required to
+      honor this flag.
+
+      Application servers MUST either do the transited-realm checks
+      themselves, or reject cross-realm tickets without TRANSITED-
+      POLICY-CHECKED set.
+
+2.8. OK as Delegate
+
+      For some applications a client may need to delegate authority to a
+      server to act on its behalf in contacting other services.  This
+      requires that the client forward credentials to an intermediate
+      server.  The ability for a client to obtain a service ticket to a
+      server conveys no information to the client about whether the
+      server should be trusted to accept delegated credentials.  The OK-
+      AS-DELEGATE provides a way for a KDC to communicate local realm
+      policy to a client regarding whether an intermediate server is
+      trusted to accept such credentials.
+
+      The copy of the ticket flags in the encrypted part of the KDC
+      reply may have the OK-AS-DELEGATE flag set to indicates to the
+      client that the server 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.  It is
+      acceptable 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.
+
+
+
+February 2004                                                  [Page 22]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+2.9. Other KDC options
+
+      There are three additional options which MAY be set in a client's
+      request of the KDC.
+
+2.9.1. Renewable-OK
+
+      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 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.
+
+2.9.2. ENC-TKT-IN-SKEY
+
+      In its basic form the Kerberos protocol supports authentication in
+      a client-server
+       setting and is not well suited to authentication in a peer-to-
+      peer environment because the long term key of the user does not
+      remain on the workstation after initial login. Authentication of
+      such peers may be supported by Kerberos in its user-to-user
+      variant. The ENC-TKT-IN-SKEY option supports user-to-user
+      authentication by allowing the KDC to issue a service ticket
+      encrypted using the session key from another ticket-granting
+      ticket issued to another user. 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 additional second ticket-granting ticket
+      provided with the request. See section 3.3.3 for specific details.
+
+2.9.3. Passwordless Hardware Authentication
+
+      The OPT-HARDWARE-AUTH option indicates that the client wishes to
+      use some form of hardware authentication instead of or in addition
+      to the client's password or other long-lived encryption key. OPT-
+      HARDWARE-AUTH is honored only by the authentication service. If
+      supported and allowed by policy, the KDC will return an errorcode
+      KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
+      perform such authentication.
+
+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
+
+
+
+February 2004                                                  [Page 23]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                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 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, other information about the credentials it is
+      requesting, and a randomly generated nonce which can be used to
+      detect replays, and to associate replies with the matching
+      requests. This nonce MUST be generated randomly by the client and
+      remembered for checking against the nonce in the expected reply.
+      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
+      encrypted part of the KRB_AS_REP message also contains the nonce
+      which MUST be matched with the nonce from the KRB_AS_REQ message.
+
+      Without pre-authentication, 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. However, an attacker can send a KRB_AS_REQ
+      message to get known plaintext in order to attack the principal's
+
+
+
+February 2004                                                  [Page 24]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      key. Especially if the key is based on a password, this may create
+      a security exposure. So, 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 SHOULD be used for
+      pre-authentication as described in sections 3.1.1 and 5.2.7.
+
+      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 contents of the KRB_ERROR message are not integrity-protected.
+      As such, the client cannot detect replays, fabrications or
+      modifications. A solution to this problem will be included in a
+      future version of the protocol.
+
+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).
+
+      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.
+
+      Because Kerberos can run over unreliable transports such as UDP,
+      the KDC MUST be prepared to retransmit responses in case they are
+      lost. If a KDC receives a request identical to one it has recently
+      successfully processed, the KDC MUST respond with a KRB_AS_REP
+      message rather than a replay error.  In order to reduce ciphertext
+      given to a potential attacker, KDCs MAY send the same response
+      generated when the request was first handled. KDCs MUST obey this
+      replay behavior even if the actual transport in use is reliable.
+
+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
+
+
+
+February 2004                                                  [Page 25]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      their respective keys. If the requested client principal named in
+      the request is not known because it doesn't exist in the KDC's
+      principal database, then an error message with a
+      KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
+
+      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 pre-authentication is
+      required, but was not present in the request, an error message
+      with the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-
+      DATA object will be stored in the e-data field of the KRB-ERROR
+      message to specify which pre-authentication mechanisms are
+      acceptable.  Usually this will include PA-ETYPE-INFO and/or PA-
+      ETYPE-INFO2 elements as described below. If the server cannot
+      accommodate any encryption type requested by the client, an error
+      message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the
+      KDC generates a 'random' session key[7].
+
+      When responding to an AS request, if there are multiple encryption
+      keys registered for a client in the Kerberos database, then the
+      etype field from the AS request is used by the KDC to select the
+      encryption method to be used to protect the encrypted part of the
+      KRB_AS_REP message which is sent to the client. If there is more
+      than one supported strong encryption type in the etype list, the
+      KDC SHOULD use the first valid strong etype for which an
+      encryption key is available.
+
+      When the user's key is generated from a password or pass phrase,
+      the string-to-key function for the particular encryption key type
+      is used, as specified in [@KCRYPTO]. The salt value and additional
+      parameters for the string-to-key function have default values
+      (specified by section 4 and by the encryption mechanism
+      specification, respectively) that may be overridden by pre-
+      authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
+      ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of
+      the resulting key only, these values should not be changed for
+      password-based keys except when changing the principal's key.
+
+      When the AS server is to include pre-authentication data in a KRB-
+      ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
+      INFO, if the etype field of the client's AS-REQ lists at least one
+      "newer" encryption type.  Otherwise (when the etype field of the
+      client's AS-REQ does not list any "newer" encryption types) it
+      MUST send both, PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an
+      entry for each enctype).  A "newer" enctype is any enctype first
+      officially specified concurrently with or subsequent to the issue
+      of this RFC.  The enctypes DES, 3DES or RC4 and any defined in
+      [RFC1510] are not "newer" enctypes.
+
+
+
+February 2004                                                  [Page 26]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      It is not possible to reliably generate a user's key given a pass
+      phrase without contacting the KDC, since it will not be known
+      whether alternate salt or parameter values are required.
+
+      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 earlier of
+      the requested endtime and a time determined by local policy,
+      possibly determined using realm or principal specific factors. For
+      example, the expiration time MAY be set to the earliest 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 from the authentication
+         server's database.
+
+      *  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,
+
+
+
+February 2004                                                  [Page 27]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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 MAY be set to the earliest 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 postdated (the start time is in the future), its
+   INVALID flag will also be set.
+
+   If all of the above succeed, the server will encrypt the ciphertext
+   part of the ticket using the encryption key extracted from the server
+   principal's record in the Kerberos database using the encryption type
+   associated with the server principal's key (this choice is NOT
+   affected by the etype field in the request). It then 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 an acceptable encryption
+   method requested in the etype field of the request, or in some key
+   specified by pre-authentication mechanisms being used.
+
+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,
+
+
+
+February 2004                                                  [Page 28]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 last-req field (and the
+      deprecated key-expiration field) from the encrypted part of the
+      response MAY be checked to notify the user of impending key
+      expiration. This enables the client program to suggest remedial
+      action, such as a password change.
+
+      Upon validation of the KRB_AS_REP message (by checking the
+      returned nonce against that sent in the KRB_AS_REQ message) the
+      client knows that the current time on the KDC is that read from
+      the authtime field of the encrypted part of the reply. The client
+      can optionally use this value for clock synchronization in
+      subsequent messages by recording with the ticket the difference
+      (offset) between the authtime value and the local clock. This
+      offset can then be used by the same user to adjust the time read
+      from the system clock when generating messages [DGT96].
+
+      This technique MUST be used when adjusting for clock skew instead
+      of directly changing the system clock because the KDC reply is
+      only authenticated to the user whose secret key was used, but not
+      to the system or workstation. If the clock were adjusted, an
+      attacker colluding with a user logging into a workstation could
+      agree on a password, resulting in a KDC reply that would be
+      correctly validated even though it did not originate from a KDC
+      trusted by the workstation.
+
+      Proper decryption of the KRB_AS_REP message is not sufficient for
+      the host 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.
+
+
+
+February 2004                                                  [Page 29]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+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[8], 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 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 SHOULD be rejected
+      if replayed to a server[9]. 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 (for user-to-user
+      authentication - see section 3.7) by setting the appropriate
+      flag(s) in the ap-options field of the message.
+
+
+
+
+February 2004                                                  [Page 30]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+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 user-to-user authentication is in use, and that
+      the ticket is encrypted in the session key from the server's
+      ticket-granting ticket rather than in the server's secret key. See
+      section 3.7 for a more complete description of the effect of user-
+      to-user authentication on all messages in the Kerberos protocol.
+
+      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), 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; this normally is caused by
+
+
+
+February 2004                                                  [Page 31]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      a client error or attempted attack. 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.
+
+      Unless the application server provides its own suitable means to
+      protect against replay (for example, a challenge-response sequence
+      initiated by the server after authentication, or use of a server-
+      generated encryption subkey), the server MUST utilize a replay
+      cache to remember any authenticator presented within the allowable
+      clock skew. Careful analysis of the application protocol and
+      implementation is recommended before eliminating this cache. The
+      replay cache will store at least the server name, along with the
+      client name, time and microsecond fields from the recently-seen
+      authenticators and if a matching tuple is found, the
+      KRB_AP_ERR_REPEAT error is returned [10]. If a server loses track
+      of authenticators presented within the allowable clock skew, it
+      MUST reject all requests until the clock skew interval has passed,
+      providing assurance that any lost or replayed authenticators will
+      fall outside the allowable clock skew and can no longer be
+      successfully replayed [11].
+
+      Implementation note: If a client generates multiple requests to
+      the KDC with the same timestamp, including the microsecond field,
+      all but the first of the requests received will be rejected as
+      replays. This might happen, for example, if the resolution of the
+      client's clock is too coarse.  Client implementations SHOULD
+      ensure that the timestamps are not reused, possibly by
+      incrementing the microseconds field in the time stamp when the
+      clock returns the same time for multiple requests.
+
+      If multiple servers (for example, different services on one
+      machine, or a single service implemented on multiple machines)
+      share a service principal (a practice we do not recommend in
+      general, but acknowledge will be used in some cases), they MUST
+      either share this replay cache, or the application protocol MUST
+      be designed so as to eliminate the need for it. Note that this
+      applies to all of the services, if any of the application
+      protocols does not have replay protection built in; an
+      authenticator used with such a service could later be replayed to
+      a different service with the same service principal but no replay
+      protection, if the former doesn't record the authenticator
+      information in the common replay cache.
+
+
+
+
+February 2004                                                  [Page 32]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+      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 decision
+      based upon the authenticated name of the user, the requested
+      operation, local access 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.
+
+3.2.5. Receipt of KRB_AP_REP message
+
+
+
+
+February 2004                                                  [Page 33]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+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. 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. The actual encryption key to be
+      used for KRB_PRIV, KRB_SAFE, or other application-specific uses
+      MAY be chosen by the application based on the session key from the
+      ticket and subkeys in the KRB_AP_REP message and the authenticator
+      [14]. To mitigate the effect of failures in random number
+      generation on the client it is strongly encouraged that any key
+      derived by an application for subsequent use include the full key
+      entropy derived from the KDC generated session key carried in the
+      ticket. 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 subsequent 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.
+
+      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
+
+
+
+
+February 2004                                                  [Page 34]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                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. The same comments about integrity
+      protection of KRB_ERROR messages mentioned in section 3.1 apply to
+
+
+
+February 2004                                                  [Page 35]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      the TGS exchange.
+
+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
+      believed to be registered [15]. If the client knows 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 possesses 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 between the client's realm and the requested
+      realm server's realm). It should be noted in this case that
+      misconfiguration of the Kerberos servers may cause loops in the
+      resulting authentication path, which the client should be careful
+      to detect and avoid.
+
+      If the Kerberos server returns a TGT for a 'closer' realm other
+      than the desired realm, the client MAY use local policy
+      configuration to verify that the authentication path used is an
+      acceptable one.  Alternatively, a client MAY choose its own
+      authentication path, rather than relying on the Kerberos server to
+      select one. In either case, any policy or configuration
+      information used to choose or validate authentication paths,
+      whether by the Kerberos server or client, MUST be obtained from a
+      trusted source.
+
+      When a client obtains a ticket-granting ticket that is 'closer' to
+      the destination realm, the client MAY cache this ticket and reuse
+      it in future KRB-TGS exchanges with services in the 'closer'
+      realm. However, if the client were to obtain a ticket-granting
+      ticket for the 'closer' realm by starting at the initial KDC
+      rather than as part of obtaining another ticket, then a shorter
+      path to the 'closer' realm might be used. This shorter path may be
+      desirable because fewer intermediate KDCs would know the session
+      key of the ticket involved. For this reason, clients SHOULD
+      evaluate whether they trust the realms transited in obtaining the
+      'closer' ticket when making a decision to use the ticket in
+      future.
+
+      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
+
+
+
+February 2004                                                  [Page 36]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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. One of these options is the ENC-TKT-
+      IN-SKEY option used for user-to-user authentication. An overview
+      of user-to-user authentication can be found in section 3.7. When
+      generating the KRB_TGS_REQ message, this option indicates that the
+      client is including a ticket-granting ticket obtained from the
+      application server in the additional tickets field of the request
+      and that the KDC SHOULD encrypt the ticket for the application
+      server using the session key from this additional ticket, instead
+      of using a server key from the principal database.
+
+      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-authorizatfion-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.
+
+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
+
+
+
+February 2004                                                  [Page 37]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 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.
+
+      As discussed in section 3.1.2, the KDC MUST send a valid
+      KRB_TGS_REP message if it receives a KRB_TGS_REQ message identical
+      to one it has recently processed. However, if the authenticator is
+      a replay, but the rest of the request is not identical, then the
+      KDC SHOULD return KRB_AP_ERR_REPEAT.
+
+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 or for
+      a ticket granting server of an intermediate KDC to be contacted to
+      obtain the requested ticket. The Kerberos database is queried to
+      retrieve the record for the appropriate 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 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
+
+
+
+February 2004                                                  [Page 38]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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, it indicates that the
+      client is using user- to-user authentication to prove its identity
+      to a server that does not have access to a persistent key. Section
+      3.7 describes the affect of this option on the entire Kerberos
+      protocol. When generating the KRB_TGS_REP message, this option in
+      the KRB_TGS_REQ message tells the KDC to decrypt the additional
+
+
+
+February 2004                                                  [Page 39]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+      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 requested,
+      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 section, the KDC will issue the appropriate new ticket.
+
+      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 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.
+
+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 to the
+      KDC for the realm in which the server resides. 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. If TGT's have been issued for cross-
+      realm authentication, use of the cross-realm TGT will not be
+
+
+
+February 2004                                                  [Page 40]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      affected unless the hot-list is propagated to the KDCs for the
+      realms for which such cross-realm tickets were issued.
+
+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, if it is not the realm of the client principal,
+      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 preceding them with a "\".
+
+
+
+
+February 2004                                                  [Page 41]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.  For the purpose of appending, the realm
+      preceding the first listed realm is considered to be the null
+      realm ("").  If a realm name beginning with a "/" 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 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.  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.  Thus,
+      "," means that all realms along the path between the client and
+      the server have been traversed. ",EDU, /COM," means 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 sub-session key from the
+      Authenticator, if it was specified in the request, or the session
+
+
+
+February 2004                                                  [Page 42]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+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 occurred).
+
+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 the keyed
+      checksum mandated to be implemented along with the crypto system
+      used for the sub-session or session key. The checksum is generated
+      using the sub-session key if present or the session key. Some
+      implementations use a different checksum algorithm for the
+      KRB_SAFE messages but doing so in a interoperable manner is not
+      always possible.
+
+      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
+
+
+
+February 2004                                                  [Page 43]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 that uses keys
+      compatible with the sub-session or session key as appropriate (or
+      with the application key derived from the session or sub-session
+      keys), and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is
+      generated.  The sender's address MUST be 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. To work with network
+      address translation, senders MAY use the directional address type
+      specified in section 8.1 for the sender address and not include
+      recipient addresses. 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. Timestamps are not required to
+      be strictly ordered; they are only required to be in the skew
+      window.  If the server name, along with the client name, time and
+      microsecond fields from the Authenticator match any recently-seen
+      (sent or received) 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 modified in transit.
+
+      Implementations SHOULD accept any checksum algorithm they
+      implement that both have adequate security and that have keys
+      compatible with the sub-session or session key. Unkeyed or non-
+      collision-proof checksums are not suitable for this use.
+
+3.5. The KRB_PRIV Exchange
+
+      The KRB_PRIV message MAY be used by clients requiring
+
+
+
+February 2004                                                  [Page 44]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 occurred). 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.
+
+      The sender's address MUST be 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.  If
+      a recipient address is specified or the recipient requires an
+      address then one of the recipient's addresses MUST also appear as
+      the recipient's address in the message.  Where a sender's or
+      receiver's address might not otherwise match the address in a
+      message because of network address translation, an application MAY
+      be written to use addresses of the directional address type in
+      place of the actual network address.
+
+      A failed match for either case generates a KRB_AP_ERR_BADADDR
+      error. To work with network address translation, implementations
+      MAY use the directional address type defined in section 7.1 for
+      the sender address and include no recipient address.
+
+      Then the timestamp and usec and/or the sequence number fields are
+
+
+
+February 2004                                                  [Page 45]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 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 previously exchanged in the
+      KRB_AP exchange (usually the last key negotiated via subkeys, or
+      the session key if no negotiation has occurred).
+
+      Implementation note: When constructing a KRB_CRED message for
+      inclusion in a GSSAPI initial context token, the MIT
+      implementation of Kerberos will not encrypt the KRB_CRED message
+      if the session key is a DES or triple DES key.  For
+      interoperability with MIT, the Microsoft implementation will not
+      encrypt the KRB_CRED in a GSSAPI token if it is using a DES
+      session key. Starting at version 1.2.5, MIT Kerberos can receive
+
+
+
+February 2004                                                  [Page 46]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      and decode either encrypted or unencrypted KRB_CRED tokens in the
+      GSSAPI exchange. The Heimdal implementation of Kerberos can also
+      accept either encrypted or unencrypted KRB_CRED messages. Since
+      the KRB_CRED message in a GSSAPI token is encrypted in the
+      authenticator, the MIT behavior does not present a security
+      problem, although it is a violation of the Kerberos specification.
+
+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 MAY verify 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. The
+      address check does not provide any added security, since the
+      address if present has already been checked in the KRB_AP_REQ
+      message and there is not any benefit to be gained by an attacker
+      in reflecting a KRB_CRED message back to its originator. Thus, the
+      recipient MAY ignore the address even if present in order to work
+      better in NAT environments. A failed match for either case
+      generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the
+      address check as the KRB_CRED message cannot generally be
+      reflected back to the originator.  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 credentials cache together with the session key and
+      other information in the corresponding KrbCredInfo sequence from
+      the encrypted part of the KRB_CRED message.
+
+3.7. User-to-User Authentication Exchanges
+
+      User-to-User authentication provides a method to perform
+      authentication when the verifier does not have a access to long
+      term service key. This might be the case when running a server
+      (for example a window server) as a user on a workstation. In such
+      cases, the server may have access to the ticket-granting ticket
+
+
+
+February 2004                                                  [Page 47]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      obtained when the user logged in to the workstation, but because
+      the server is running as an unprivileged user it might not have
+      access to system keys. Similar situations may arise when running
+      peer-to-peer applications.
+
+                                Summary
+          Message direction                    Message type     Sections
+          0. Message from application server   Not Specified
+          1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
+          2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
+                                               KRB_ERROR        5.9.1
+          3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
+
+      To address this problem, the Kerberos protocol allows the client
+      to request that the ticket issued by the KDC be encrypted using a
+      session key from a ticket-granting ticket issued to the party that
+      will verify the authentication.  This ticket-granting ticket must
+      be obtained from the verifier by means of an exchange external to
+      the Kerberos protocol, usually as part of the application
+      protocol. This message is shown in the summary above as message 0.
+      Note that because the ticket-granting ticket is encrypted in the
+      KDC's secret key, it can not be used for authentication without
+      possession of the corresponding secret key.  Furthermore, because
+      the verifier does not reveal the corresponding secret key,
+      providing a copy of the verifier's ticket-granting ticket does not
+      allow impersonation of the verifier.
+
+      Message 0 in the table above represents an application specific
+      negotiation between the client and server, at the end of which
+      both have determined that they will use user-to-user
+      authentication and the client has obtained the server's TGT.
+
+      Next, the client includes the server's TGT as an additional ticket
+      in its KRB_TGS_REQ request to the KDC (message 1 in the table
+      above) and specifies the ENC-TKT-IN-SKEY option in its request.
+
+      If validated according to the instructions in 3.3.3, the
+      application ticket returned to the client (message 2 in the table
+      above) will be encrypted using the session key from the additional
+      ticket and the client will note this when it uses or stores the
+      application ticket.
+
+      When contacting the server using a ticket obtained for user-to-
+      user authentication (message 3 in the table above), the client
+      MUST specify the USE-SESSION-KEY flag in the ap-options field.
+      This tells the application server to use the session key
+      associated with its ticket-granting ticket to decrypt the server
+      ticket provided in the application request.
+
+
+
+February 2004                                                  [Page 48]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+4. Encryption and Checksum Specifications
+
+      The Kerberos protocols described in this document are designed to
+      encrypt messages of arbitrary sizes, using stream or block
+      encryption ciphers.  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.
+
+      [@KCRYPTO] defines a framework for defining encryption and
+      checksum mechanisms for use with Kerberos. It also defines several
+      such mechanisms, and more may be added in future updates to that
+      document.
+
+      The string-to-key operation provided by [@KCRYPTO] is used to
+      produce a long-term key for a principal (generally for a user).
+      The default salt string, if none is provided via pre-
+      authentication data, is the concatenation of the principal's realm
+      and name components, in order, with no separators.  Unless
+      otherwise indicated, the default string-to-key opaque parameter
+      set as defined in [@KCRYPTO] is used.
+
+      Encrypted data, keys and checksums are transmitted using the
+      EncryptedData, EncryptionKey and Checksum data objects defined in
+      section 5.2.9. The encryption, decryption, and checksum operations
+      described in this document use the corresponding encryption,
+      decryption, and get_mic operations described in [@KCRYPTO], with
+      implicit "specific key" generation using the "key usage" values
+      specified in the description of each EncryptedData or Checksum
+      object to vary the key for each operation. Note that in some
+      cases, the value to be used is dependent on the method of choosing
+      the key or the context of the message.
+
+      Key usages are unsigned 32 bit integers; zero is not permitted.
+
+
+
+February 2004                                                  [Page 49]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      The key usage values for encrypting or checksumming Kerberos
+      messages are indicated in section 5 along with the message
+      definitions. Key usage values 512-1023 are reserved for uses
+      internal to a Kerberos implementation. (For example, seeding a
+      pseudo-random number generator with a value produced by encrypting
+      something with a session key and a key usage value not used for
+      any other purpose.) 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. Key usage values are also summarized in a table in
+      section 7.5.1.
+
+      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
+      specifications continue to be meaningful until they are updated,
+      if no key usage values are specified then key usages 1024 and 1025
+      must be used to derive keys for encryption and checksums,
+      respectively (this does not apply to protocols that do their own
+      encryption independent of this framework, directly using the key
+      resulting from the Kerberos authentication exchange.) New
+      protocols defined in terms of the Kerberos encryption and checksum
+      types SHOULD use their own key usage values.
+
+      Unless otherwise indicated, no cipher state chaining is done from
+      one encryption operation to another.
+
+      Implementation note: While not recommended, some application
+      protocols will continue to use the key data directly, even if only
+      in currently existing protocol specifications. An implementation
+      intended to support general Kerberos applications may therefore
+      need to make key data available, as well as the attributes and
+      operations described in [@KCRYPTO].  One of the more common
+      reasons for directly performing encryption is direct control over
+      negotiation and selection of a "sufficiently strong" encryption
+      algorithm (in the context of a given application). While Kerberos
+      does not directly provide a facility for negotiating encryption
+      types between the application client and server, there are
+      approaches for using Kerberos to facilitate this negotiation - for
+      example, a client may request only "sufficiently strong" session
+      key types from the KDC and expect that any type returned by the
+      KDC will be understood and supported by the application server.
+
+5. Message Specifications
+
+      NOTE: The ASN.1 collected here should be identical to the contents
+      of Appendix A. In case of conflict, the contents of Appendix A
+      shall take precedence.
+
+
+
+February 2004                                                  [Page 50]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      The Kerberos protocol is defined here in terms of Abstract Syntax
+      Notation One (ASN.1) [X680], which provides a syntax for
+      specifying both the abstract layout of protocol messages as well
+      as their encodings. Implementors not utilizing an existing ASN.1
+      compiler or support library are cautioned to thoroughly understand
+      the actual ASN.1 specification to ensure correct implementation
+      behavior, as there is more complexity in the notation than is
+      immediately obvious, and some tutorials and guides to ASN.1 are
+      misleading or erroneous.
+
+      Note that in several places, there have been changes here from RFC
+      1510 that change the abstract types. This is in part to address
+      widespread assumptions that various implementors have made, in
+      some cases resulting in unintentional violations of the ASN.1
+      standard. These are clearly flagged where they occur. The
+      differences between the abstract types in RFC 1510 and abstract
+      types in this document can cause incompatible encodings to be
+      emitted when certain encoding rules, e.g. the Packed Encoding
+      Rules (PER), are used. This theoretical incompatibility should not
+      be relevant for Kerberos, since Kerberos explicitly specifies the
+      use of the Distinguished Encoding Rules (DER). It might be an
+      issue for protocols wishing to use Kerberos types with other
+      encoding rules. (This practice is not recommended.) With very few
+      exceptions (most notably the usages of BIT STRING), the encodings
+      resulting from using the DER remain identical between the types
+      defined in RFC 1510 and the types defined in this document.
+
+      The type definitions in this section assume an ASN.1 module
+      definition of the following form:
+
+      KerberosV5Spec2 {
+              iso(1) identified-organization(3) dod(6) internet(1)
+              security(5) kerberosV5(2) modules(4) krb5spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- rest of definitions here
+
+      END
+
+      This specifies that the tagging context for the module will be
+      explicit and non-automatic.
+
+      Note that in some other publications [RFC1510] [RFC1964], the
+      "dod" portion of the object identifier is erroneously specified as
+      having the value "5".  In the case of RFC 1964, use of the
+      "correct" OID value would result in a change in the wire protocol;
+      therefore, it remains unchanged for now.
+
+
+
+
+February 2004                                                  [Page 51]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Note that elsewhere in this document, nomenclature for various
+      message types is inconsistent, but largely follows C language
+      conventions, including use of underscore (_) characters and all-
+      caps spelling of names intended to be numeric constants. Also, in
+      some places, identifiers (especially ones referring to constants)
+      are written in all-caps in order to distinguish them from
+      surrounding explanatory text.
+
+      The ASN.1 notation does not permit underscores in identifiers, so
+      in actual ASN.1 definitions, underscores are replaced with hyphens
+      (-). Additionally, structure member names and defined values in
+      ASN.1 MUST begin with a lowercase letter, while type names MUST
+      begin with an uppercase letter.
+
+5.1. Specific Compatibility Notes on ASN.1
+
+      For compatibility purposes, implementors should heed the following
+      specific notes regarding the use of ASN.1 in Kerberos. These notes
+      do not describe deviations from standard usage of ASN.1. The
+      purpose of these notes is to instead describe some historical
+      quirks and non-compliance of various implementations, as well as
+      historical ambiguities, which, while being valid ASN.1, can lead
+      to confusion during implementation.
+
+5.1.1. ASN.1 Distinguished Encoding Rules
+
+      The encoding of Kerberos protocol messages shall obey the
+      Distinguished Encoding Rules (DER) of ASN.1 as described in
+      [X690]. Some implementations (believed to be primarily ones
+      derived from DCE 1.1 and earlier) are known to use the more
+      general Basic Encoding Rules (BER); in particular, these
+      implementations send indefinite encodings of lengths.
+      Implementations MAY accept such encodings in the interests of
+      backwards compatibility, though implementors are warned that
+      decoding fully-general BER is fraught with peril.
+
+5.1.2. Optional Integer Fields
+
+      Some implementations do not internally distinguish between an
+      omitted optional integer value and a transmitted value of zero.
+      The places in the protocol where this is relevant include various
+      microseconds fields, nonces, and sequence numbers. Implementations
+      SHOULD treat omitted optional integer values as having been
+      transmitted with a value of zero, if the application is expecting
+      this.
+
+5.1.3. Empty SEQUENCE OF Types
+
+
+
+
+February 2004                                                  [Page 52]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      There are places in the protocol where a message contains a
+      SEQUENCE OF type as an optional member. This can result in an
+      encoding that contains an empty SEQUENCE OF encoding. The Kerberos
+      protocol does not semantically distinguish between an absent
+      optional SEQUENCE OF type and a present optional but empty
+      SEQUENCE OF type. Implementations SHOULD NOT send empty SEQUENCE
+      OF encodings that are marked OPTIONAL, but SHOULD accept them as
+      being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax
+      describing Kerberos messages, instances of these problematic
+      optional SEQUENCE OF types are indicated with a comment.
+
+5.1.4. Unrecognized Tag Numbers
+
+      Future revisions to this protocol may include new message types
+      with different APPLICATION class tag numbers. Such revisions
+      should protect older implementations by only sending the message
+      types to parties that are known to understand them, e.g. by means
+      of a flag bit set by the receiver in a preceding request. In the
+      interest of robust error handling, implementations SHOULD
+      gracefully handle receiving a message with an unrecognized tag
+      anyway, and return an error message if appropriate.
+
+      In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
+      incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
+      respond to messages received with an unknown tag over UDP
+      transport in order to avoid denial of service attacks.  For non-
+      KDC applications, the Kerberos implementation typically indicates
+      an error to the application which takes appropriate steps based on
+      the application protocol.
+
+5.1.5. Tag Numbers Greater Than 30
+
+      A naive implementation of a DER ASN.1 decoder may experience
+      problems with ASN.1 tag numbers greater than 30, due to such tag
+      numbers being encoded using more than one byte. Future revisions
+      of this protocol may utilize tag numbers greater than 30, and
+      implementations SHOULD be prepared to gracefully return an error,
+      if appropriate, if they do not recognize the tag.
+
+5.2. Basic Kerberos Types
+
+      This section defines a number of basic types that are potentially
+      used in multiple Kerberos protocol messages.
+
+5.2.1. KerberosString
+
+      The original specification of the Kerberos protocol in RFC 1510
+      uses GeneralString in numerous places for human-readable string
+
+
+
+February 2004                                                  [Page 53]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      data. Historical implementations of Kerberos cannot utilize the
+      full power of GeneralString.  This ASN.1 type requires the use of
+      designation and invocation escape sequences as specified in
+      ISO-2022/ECMA-35 [ISO-2022/ECMA-35] to switch character sets, and
+      the default character set that is designated as G0 is the
+      ISO-646/ECMA-6 [ISO-646,ECMA-6] International Reference Version
+      (IRV) (aka U.S. ASCII), which mostly works.
+
+      ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
+      and two Control-function code elements (C0..C1). DER prohibits the
+      designation of character sets as any but the G0 and C0 sets.
+      Unfortunately, this seems to have the side effect of prohibiting
+      the use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any
+      other character-sets that utilize a 96-character set, since it is
+      prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
+      element. This side effect is being investigated in the ASN.1
+      standards community.
+
+      In practice, many implementations treat GeneralStrings as if they
+      were 8-bit strings of whichever character set the implementation
+      defaults to, without regard for correct usage of character-set
+      designation escape sequences. The default character set is often
+      determined by the current user's operating system dependent
+      locale. At least one major implementation places unescaped UTF-8
+      encoded Unicode characters in the GeneralString. This failure to
+      adhere to the GeneralString specifications results in
+      interoperability issues when conflicting character encodings are
+      utilized by the Kerberos clients, services, and KDC.
+
+      This unfortunate situation is the result of improper documentation
+      of the restrictions of the ASN.1 GeneralString type in prior
+      Kerberos specifications.
+
+      The new (post-RFC 1510) type KerberosString, defined below, is a
+      GeneralString that is constrained to only contain characters in
+      IA5String
+
+         KerberosString  ::= GeneralString (IA5String)
+
+      In general, US-ASCII control characters should not be used in
+      KerberosString. Control characters SHOULD NOT be used in principal
+      names or realm names.
+
+      For compatibility, implementations MAY choose to accept
+      GeneralString values that contain characters other than those
+      permitted by IA5String, but they should be aware that character
+      set designation codes will likely be absent, and that the encoding
+      should probably be treated as locale-specific in almost every way.
+
+
+
+February 2004                                                  [Page 54]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Implementations MAY also choose to emit GeneralString values that
+      are beyond those permitted by IA5String, but should be aware that
+      doing so is extraordinarily risky from an interoperability
+      perspective.
+
+      Some existing implementations use GeneralString to encode
+      unescaped locale-specific characters. This is a violation of the
+      ASN.1 standard. Most of these implementations encode US-ASCII in
+      the left-hand half, so as long the implementation transmits only
+      US-ASCII, the ASN.1 standard is not violated in this regard. As
+      soon as such an implementation encodes unescaped locale-specific
+      characters with the high bit set, it violates the ASN.1 standard.
+
+      Other implementations have been known to use GeneralString to
+      contain a UTF-8 encoding. This also violates the ASN.1 standard,
+      since UTF-8 is a different encoding, not a 94 or 96 character "G"
+      set as defined by ISO 2022.  It is believed that these
+      implementations do not even use the ISO 2022 escape sequence to
+      change the character encoding. Even if implementations were to
+      announce the change of encoding by using that escape sequence, the
+      ASN.1 standard prohibits the use of any escape sequences other
+      than those used to designate/invoke "G" or "C" sets allowed by
+      GeneralString.
+
+      Future revisions to this protocol will almost certainly allow for
+      a more interoperable representation of principal names, probably
+      including UTF8String.
+
+      Note that applying a new constraint to a previously unconstrained
+      type constitutes creation of a new ASN.1 type. In this particular
+      case, the change does not result in a changed encoding under DER.
+
+5.2.2. Realm and PrincipalName
+
+      Realm           ::= KerberosString
+
+      PrincipalName   ::= SEQUENCE {
+              name-type       [0] Int32,
+              name-string     [1] SEQUENCE OF KerberosString
+      }
+
+      Kerberos realm names are encoded as KerberosStrings. Realms shall
+      not contain a character with the code 0 (the US-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 6.1.. A PrincipalName is a
+      typed sequence of components consisting of the following sub-
+
+
+
+February 2004                                                  [Page 55]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      fields:
+
+   name-type
+      This field specifies the type of name that follows. Pre-defined
+      values for this field are specified in section 6.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).
+
+   name-string
+      This field encodes a sequence of components that form a name, each
+      component encoded as a KerberosString. Taken together, a
+      PrincipalName and a Realm form a principal identifier. Most
+      PrincipalNames will have only a few components (typically one or
+      two).
+
+5.2.3. KerberosTime
+
+      KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+      The timestamps used in Kerberos are encoded as GeneralizedTimes. A
+      KerberosTime value shall not include any fractional portions of
+      the seconds.  As required by the DER, it further shall not include
+      any separators, and it shall specify the UTC time zone (Z).
+      Example: The only valid format for UTC time 6 minutes, 27 seconds
+      after 9 pm on 6 November 1985 is 19851106210627Z.
+
+5.2.4. Constrained Integer types
+
+      Some integer members of types SHOULD be constrained to values
+      representable in 32 bits, for compatibility with reasonable
+      implementation limits.
+
+      Int32           ::= INTEGER (-2147483648..2147483647)
+                          -- signed values representable in 32 bits
+
+      UInt32          ::= INTEGER (0..4294967295)
+                          -- unsigned 32 bit values
+
+      Microseconds    ::= INTEGER (0..999999)
+                          -- microseconds
+
+      While this results in changes to the abstract types from the RFC
+      1510 version, the encoding in DER should be unaltered. Historical
+      implementations were typically limited to 32-bit integer values
+      anyway, and assigned numbers SHOULD fall in the space of integer
+      values representable in 32 bits in order to promote
+      interoperability anyway.
+
+
+
+February 2004                                                  [Page 56]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      There are several integer fields in messages that are constrained
+      to fixed values.
+
+   pvno
+      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
+      the constant integer 5. There is no easy way to make this field
+      into a useful protocol version number, so its value is fixed.
+
+   msg-type
+      this integer field is usually identical to the application tag
+      number of the containing message type.
+
+5.2.5. HostAddress and HostAddresses
+
+      HostAddress     ::= SEQUENCE  {
+              addr-type       [0] Int32,
+              address         [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be empty.
+      HostAddresses   -- NOTE: subtly different from rfc1510,
+                      -- but has a value mapping and encodes the same
+              ::= SEQUENCE OF HostAddress
+
+      The host address 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 7.5.3.
+
+   address
+      This field encodes a single address of type addr-type.
+
+5.2.6. AuthorizationData
+
+      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+      -- should not be empty.
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+              ad-type         [0] Int32,
+              ad-data         [1] OCTET STRING
+      }
+
+   ad-data
+      This field contains authorization data to be interpreted according
+      to the value of the corresponding ad-type field.
+
+   ad-type
+
+
+
+February 2004                                                  [Page 57]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 referred 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.
+
+   These common authorization data elements are recursively 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.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator. Unless encapsulated in a known authorization
+   data element amending the criticality of the elements it contains, if
+   an unknown authorization data element type is received by a server
+   either in an AP-REQ or in a ticket contained in an AP-REQ, then
+   authentication MUST fail.  Authorization data is intended to restrict
+   the use of a ticket. If the service cannot determine whether the
+   restriction applies to that service then a security weakness may
+   result if the ticket can be used for that service. Authorization
+   elements that are optional can be enclosed in AD-IF-RELEVANT element.
+
+   In the definitions that follow, the value of the ad-type for the
+   element will be specified as the least significant part of the
+   subsection number, and the value of the ad-data will be as shown in
+   the ASN.1 structure that follows the subsection heading.
+
+             contents of ad-data          ad-type
+
+    DER encoding of AD-IF-RELEVANT        1
+
+    DER encoding of AD-KDCIssued          4
+
+    DER encoding of AD-AND-OR             5
+
+
+
+
+February 2004                                                  [Page 58]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+    DER encoding of AD-MANDATORY-FOR-KDC  8
+
+5.2.6.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.  The ad-type for AD-IF-RELEVANT is (1).
+
+5.2.6.2. KDCIssued
+
+      AD-KDCIssued            ::= SEQUENCE {
+              ad-checksum     [0] Checksum,
+              i-realm         [1] Realm OPTIONAL,
+              i-sname         [2] PrincipalName OPTIONAL,
+              elements        [3] AuthorizationData
+      }
+
+   ad-checksum
+      A cryptographic checksum computed over the DER encoding of the
+      AuthorizationData in the "elements" field, keyed with the session
+      key.  Its checksumtype is the mandatory checksum type for the
+      encryption type of the session key, and its key usage value is 19.
+
+   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 privileges 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
+
+
+
+February 2004                                                  [Page 59]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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 MUST  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 encapsulates MAY be safely ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+5.2.6.3. AND-OR
+
+      AD-AND-OR               ::= SEQUENCE {
+              condition-count [0] INTEGER,
+              elements        [1] AuthorizationData
+      }
+
+
+      When restrictive AD elements are encapsulated within the and-or
+      element, the and-or element is considered satisfied if and only if
+      at least the number of encapsulated elements specified in
+      condition-count are satisfied.  Therefore, 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.
+
+      The ad-type for AD-AND-OR is (5).
+
+5.2.6.4. MANDATORY-FOR-KDC
+
+      AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+
+
+
+February 2004                                                  [Page 60]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      AD elements encapsulated within the mandatory-for-kdc element are
+      to be interpreted by the KDC. KDCs that do not understand the type
+      of an element embedded within the mandatory-for-kdc element MUST
+      reject the request.
+
+      The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+5.2.7. PA-DATA
+
+      Historically, PA-DATA have been known as "pre-authentication
+      data", meaning that they were used to augment the initial
+      authentication with the KDC.  Since that time, they have also been
+      used as a typed hole with which to extend protocol exchanges with
+      the KDC.
+
+      PA-DATA         ::= SEQUENCE {
+              -- NOTE: first tag is [1], not [0]
+              padata-type     [1] Int32,
+              padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+      }
+
+   padata-type
+      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.
+
+   padata-value
+      Usually contains the DER encoding of another type; the padata-type
+      field identifies which type is encoded here.
+
+       padata-type        name           contents of padata-value
+
+       1            pa-tgs-req       DER encoding of AP-REQ
+
+       2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
+
+       3            pa-pw-salt       salt (not ASN.1 encoded)
+
+       11           pa-etype-info    DER encoding of ETYPE-INFO
+
+       19           pa-etype-info2   DER encoding of ETYPE-INFO2
+
+      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.
+
+
+
+
+February 2004                                                  [Page 61]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+5.2.7.1. PA-TGS-REQ
+
+      In the case of requests for additional tickets (KRB_TGS_REQ),
+      padata-value will contain an encoded AP-REQ. The checksum in the
+      authenticator (which MUST be collision-proof) is to be computed
+      over the KDC-REQ-BODY encoding.
+
+5.2.7.2. Encrypted Timestamp Pre-authentication
+
+      There are pre-authentication types that may be used to pre-
+      authenticate a client by means of an encrypted timestamp.
+
+      PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+      Patimestamp contains the client's time, and pausec contains 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 encoding, encrypted using the
+      client's secret key and a key usage value of 1.
+
+      This pre-authentication type was not present in RFC 1510, but many
+      implementations support it.
+
+5.2.7.3. PA-PW-SALT
+
+      The padata-value for this pre-authentication type contains the
+      salt for the string-to-key to be used by the client to obtain the
+      key for decrypting the encrypted part of an AS-REP message.
+      Unfortunately, for historical reasons, the character set to be
+      used is unspecified and probably locale-specific.
+
+      This pre-authentication type was not present in RFC 1510, but many
+      implementations support it. It is necessary in any case where the
+      salt for the string-to-key algorithm is not the default.
+
+      In the trivial example, a zero-length salt string is very
+
+
+
+February 2004                                                  [Page 62]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      commonplace for realms that have converted their principal
+      databases from Kerberos 4.
+
+      A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
+      that requests additional pre-authentication. Implementation note:
+      some KDC implementations issue an erroneous PA-PW-SALT when
+      issuing a KRB-ERROR message that requests additional pre-
+      authentication. Therefore, clients SHOULD ignore a PA-PW-SALT
+      accompanying a KRB-ERROR message that requests additional pre-
+      authentication.  As noted in section 3.1.3, a KDC MUST NOT send
+      PA-PW-SALT when the client's AS-REQ includes at least one "newer"
+      etype.
+
+5.2.7.4. PA-ETYPE-INFO
+
+      The ETYPE-INFO pre-authentication type is sent by the KDC in a
+      KRB-ERROR indicating a requirement for additional pre-
+      authentication. It is usually used to notify a client of which key
+      to use for the encryption of an encrypted timestamp for the
+      purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.
+      It MAY also be sent in an AS-REP to provide information to the
+      client about which key salt to use for the string-to-key to be
+      used by the client to obtain the key for decrypting the encrypted
+      part the AS-REP.
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] Int32,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+      The salt, like that of PA-PW-SALT, is also completely unspecified
+      with respect to character set and is probably locale-specific.
+
+      If ETYPE-INFO is sent in an AS-REP, there shall be exactly one
+      ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part
+      in the AS-REP.
+
+      This pre-authentication type was not present in RFC 1510, but many
+      implementations that support encrypted timestamps for pre-
+      authentication need to support ETYPE-INFO as well.  As noted in
+      section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
+      AS-REQ includes at least one "newer" etype.
+
+5.2.7.5. PA-ETYPE-INFO2
+
+      The ETYPE-INFO2 pre-authentication type is sent by the KDC in a
+
+
+
+February 2004                                                  [Page 63]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      KRB-ERROR indicating a requirement for additional pre-
+      authentication. It is usually used to notify a client of which key
+      to use for the encryption of an encrypted timestamp for the
+      purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.
+      It MAY also be sent in an AS-REP to provide information to the
+      client about which key salt to use for the string-to-key to be
+      used by the client to obtain the key for decrypting the encrypted
+      part the AS-REP.
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] Int32,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+      ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
+
+      The type of the salt is KerberosString, but existing installations
+      might have locale-specific characters stored in salt strings, and
+      implementors MAY choose to handle them.
+
+      The interpretation of s2kparams is specified in the cryptosystem
+      description associated with the etype. Each cryptosystem has a
+      default interpretation of s2kparams that will hold if that element
+      is omitted from the encoding of ETYPE-INFO2-ENTRY.
+
+      If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
+      ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part
+      in the AS-REP.
+
+      The preferred ordering of the "hint" pre-authentication data that
+      affect client key selection is: ETYPE-INFO2, followed by ETYPE-
+      INFO, followed by PW-SALT.  As noted in section 3.1.3, a KDC MUST
+      NOT send ETYPE-INFO or PW-SALT when the client's AS-REQ includes
+      at least one "newer" etype.
+
+      The ETYPE-INFO2 pre-authentication type was not present in RFC
+      1510.
+
+5.2.8. KerberosFlags
+
+      For several message types, a specific constrained bit string type,
+      KerberosFlags, is used.
+
+      KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
+                          -- shall be sent, but no fewer than 32
+
+      Compatibility note: the following paragraphs describe a change
+
+
+
+February 2004                                                  [Page 64]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      from the RFC1510 description of bit strings that would result in
+      incompatility in the case of an implementation that strictly
+      conformed to ASN.1 DER and RFC1510.
+
+      ASN.1 bit strings have multiple uses. The simplest use of a bit
+      string is to contain a vector of bits, with no particular meaning
+      attached to individual bits. This vector of bits is not
+      necessarily a multiple of eight bits long.  The use in Kerberos of
+      a bit string as a compact boolean vector wherein each element has
+      a distinct meaning poses some problems. The natural notation for a
+      compact boolean vector is the ASN.1 "NamedBit" notation, and the
+      DER require that encodings of a bit string using "NamedBit"
+      notation exclude any trailing zero bits. This truncation is easy
+      to neglect, especially given C language implementations that
+      naturally choose to store boolean vectors as 32 bit integers.
+
+      For example, if the notation for KDCOptions were to include the
+      "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
+      encoded had only the "forwardable" (bit number one) bit set, the
+      DER encoding MUST include only two bits: the first reserved bit
+      ("reserved", bit number zero, value zero) and the one-valued bit
+      (bit number one) for "forwardable".
+
+      Most existing implementations of Kerberos unconditionally send 32
+      bits on the wire when encoding bit strings used as boolean
+      vectors. This behavior violates the ASN.1 syntax used for flag
+      values in RFC 1510, but occurs on such a widely installed base
+      that the protocol description is being modified to accommodate it.
+
+      Consequently, this document removes the "NamedBit" notations for
+      individual bits, relegating them to comments. The size constraint
+      on the KerberosFlags type requires that at least 32 bits be
+      encoded at all times, though a lenient implementation MAY choose
+      to accept fewer than 32 bits and to treat the missing bits as set
+      to zero.
+
+      Currently, no uses of KerberosFlags specify more than 32 bits
+      worth of flags, although future revisions of this document may do
+      so. When more than 32 bits are to be transmitted in a
+      KerberosFlags value, future revisions to this document will likely
+      specify that the smallest number of bits needed to encode the
+      highest-numbered one-valued bit should be sent. This is somewhat
+      similar to the DER encoding of a bit string that is declared with
+      the "NamedBit" notation.
+
+5.2.9. Cryptosystem-related Types
+
+      Many Kerberos protocol messages contain an EncryptedData as a
+
+
+
+February 2004                                                  [Page 65]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      container for arbitrary encrypted data, which is often the
+      encrypted encoding of another data type. Fields within
+      EncryptedData assist the recipient in selecting a key with which
+      to decrypt the enclosed data.
+
+      EncryptedData   ::= SEQUENCE {
+              etype   [0] Int32 -- EncryptionType --,
+              kvno    [1] UInt32 OPTIONAL,
+              cipher  [2] OCTET STRING -- ciphertext
+      }
+
+   etype
+      This field identifies which encryption algorithm was used to
+      encipher the cipher.
+
+   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.  (Note that the encryption mechanisms defined in
+      [@KCRYPTO] MUST incorporate integrity protection as well, so no
+      additional checksum is required.)
+
+   The EncryptionKey type is the means by which cryptographic keys used
+   for encryption are transferred.
+
+   EncryptionKey   ::= SEQUENCE {
+           keytype         [0] Int32 -- actually encryption type --,
+           keyvalue        [1] OCTET STRING
+   }
+
+   keytype
+      This field specifies the encryption type of the encryption key
+      that follows in the keyvalue field. While its name is "keytype",
+      it actually specifies an encryption type. Previously, multiple
+      cryptosystems that performed encryption differently but were
+      capable of using keys with the same characteristics were permitted
+      to share an assigned number to designate the type of key; this
+      usage is now deprecated.
+
+   keyvalue
+      This field contains the key itself, encoded as an octet string.
+
+   Messages containing cleartext data to be authenticated will usually
+   do so by using a member of type Checksum. Most instances of Checksum
+
+
+
+February 2004                                                  [Page 66]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   use a keyed hash, though exceptions will be noted.
+
+   Checksum        ::= SEQUENCE {
+           cksumtype       [0] Int32,
+           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.
+
+   See section 4 for a brief description of the use of encryption and
+   checksums in Kerberos.
+
+5.3. Tickets
+
+      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.
+      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 (5),
+              realm           [1] Realm,
+              sname           [2] PrincipalName,
+              enc-part        [3] EncryptedData -- EncTicketPart
+      }
+
+      -- 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
+      }
+
+
+
+
+February 2004                                                  [Page 67]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+              tr-type         [0] Int32 -- must be registered --,
+              contents        [1] OCTET STRING
+      }
+
+      TicketFlags     ::= KerberosFlags
+              -- 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),
+      -- the following are new since 1510
+              -- transited-policy-checked(12),
+              -- ok-as-delegate(13)
+
+   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.  It is encrypted in the key shared by Kerberos and the
+      end server (the server's secret key), using a key usage value of
+      2.
+
+   flags
+      This field indicates which of various options were used or
+      requested when the ticket was issued. The meanings of the flags
+      are:
+
+
+
+February 2004                                                  [Page 68]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+         Bit(s)  Name                   Description
+
+         0       reserved               Reserved for future expansion of this
+                                        field.
+
+                                        The FORWARDABLE flag is normally only
+                                        interpreted by the TGS, and can be
+                                        ignored by end servers. When set, this
+         1       forwardable            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.
+
+                                        When set, this flag indicates that the
+                                        ticket has either been forwarded or
+         2       forwarded              was issued based on authentication
+                                        involving a forwarded ticket-granting
+                                        ticket.
+
+                                        The PROXIABLE flag is normally only
+                                        interpreted by the TGS, and can be
+                                        ignored by end servers. The PROXIABLE
+                                        flag has an interpretation identical
+         3       proxiable              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.
+
+                                        The MAY-POSTDATE flag is normally only
+                                        interpreted by the TGS, and can be
+         5       may-postdate           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.
+
+                                        This flag indicates that this ticket
+                                        has been postdated. The end-service
+         6       postdated              can check the authtime field to see
+                                        when the original authentication
+                                        occurred.
+
+                                        This flag indicates that a ticket is
+
+
+
+February 2004                                                  [Page 69]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                        invalid, and it must be validated by
+         7       invalid                the KDC before use. Application
+                                        servers must reject tickets which have
+                                        this flag set.
+
+                                        The RENEWABLE flag is normally only
+                                        interpreted by the TGS, and can
+                                        usually be ignored by end servers
+         8       renewable              (some particularly careful servers MAY
+                                        disallow renewable tickets). A
+                                        renewable ticket can be used to obtain
+                                        a replacement ticket that expires at a
+                                        later date.
+
+                                        This flag indicates that this ticket
+         9       initial                was issued using the AS protocol, and
+                                        not issued based on a ticket-granting
+                                        ticket.
+
+                                        This flag indicates that during
+                                        initial authentication, the client was
+                                        authenticated by the KDC before a
+         10      pre-authent            ticket was issued. The strength of the
+                                        pre-authentication method is not
+                                        indicated, but is acceptable to the
+                                        KDC.
+
+                                        This flag indicates that the protocol
+                                        employed for initial authentication
+                                        required the use of hardware expected
+         11      hw-authent             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.
+
+                                        This flag indicates that the KDC for
+                                        the 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
+         12      transited-             is set (1) then the application server
+                 policy-checked         MAY skip its own validation of the
+                                        transited field, relying on the
+                                        validation performed by the KDC. At
+
+
+
+February 2004                                                  [Page 70]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                        its option the application server MAY
+                                        still apply its own validation based
+                                        on a separate policy for acceptance.
+
+                                        This flag is new since RFC 1510.
+
+                                        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
+         13      ok-as-delegate         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.
+
+                                        This flag is new since RFC 1510.
+
+         14-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.
+
+   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 in
+      the transited field (as specified for some extensions to the
+
+
+
+February 2004                                                  [Page 71]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.  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.
+
+
+   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 the starttime field is absent from the ticket, then
+      the authtime field SHOULD be used in its place to determine the
+      life of the ticket.
+
+   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 addressless tickets is a policy decision and
+      is left to the Kerberos and end-service administrators; they MAY
+
+
+
+February 2004                                                  [Page 72]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      refuse to issue or accept such tickets. Because of the wide
+      deployment of network address translation, it is recommended that
+      policy allow the issue and acceptance of such tickets.
+
+      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 possession 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
+      encapsulation 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 privileges 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
+
+
+
+February 2004                                                  [Page 73]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      rights to those objects. The format for this field is described in
+      section 5.2.6.  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 privilege 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 5.2.6.2).
+
+      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.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 application tag number of its own.
+      Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
+      which each have an application tag, 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 KDC to
+
+
+
+February 2004                                                  [Page 74]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      request credentials for a service.
+
+      The message fields are:
+
+      AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+      TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+      KDC-REQ         ::= SEQUENCE {
+              -- NOTE: first tag is [1], not [0]
+              pvno            [1] INTEGER (5) ,
+              msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+              padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                                  -- NOTE: not empty --,
+              req-body        [4] KDC-REQ-BODY
+      }
+
+      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,
+              rtime                   [6] KerberosTime OPTIONAL,
+              nonce                   [7] UInt32,
+              etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                          -- in preference order --,
+              addresses               [9] HostAddresses OPTIONAL,
+              enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
+              additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                              -- NOTE: not empty
+      }
+
+      KDCOptions      ::= KerberosFlags
+              -- reserved(0),
+              -- forwardable(1),
+              -- forwarded(2),
+              -- proxiable(3),
+              -- proxy(4),
+              -- allow-postdate(5),
+              -- postdated(6),
+              -- unused7(7),
+              -- renewable(8),
+              -- unused9(9),
+
+
+
+February 2004                                                  [Page 75]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              -- unused10(10),
+              -- opt-hardware-auth(11),
+              -- unused12(12),
+              -- unused13(13),
+      -- 15 is reserved for canonicalize
+              -- unused15(15),
+      -- 26 was unused in 1510
+              -- disable-transited-check(26),
+      --
+              -- renewable-ok(27),
+              -- enc-tkt-in-skey(28),
+              -- renew(30),
+              -- validate(31)
+
+   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
+      Contains pre-authentication data. Requests for additional tickets
+      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
+
+      The padata (pre-authentication data) field contains a sequence of
+      authentication information which may be needed before credentials
+      can be issued or decrypted.
+
+   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
+
+
+
+February 2004                                                  [Page 76]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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:
+
+         Bits    Name                     Description
+
+         0       RESERVED                 Reserved for future expansion of
+                                          this field.
+
+                                          The FORWARDABLE option indicates
+                                          that the ticket to be issued is to
+                                          have its forwardable flag set. It
+         1       FORWARDABLE              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
+                                          forwardable.
+
+                                          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
+         2       FORWARDED                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.
+
+                                          The PROXIABLE option indicates that
+                                          the ticket to be issued is to have
+                                          its proxiable flag set. It may only
+         3       PROXIABLE                be set on the initial request, or in
+                                          a subsequent request if the
+                                          ticket-granting ticket on which it
+                                          is based is also proxiable.
+
+                                          The PROXY option indicates that this
+                                          is a request for a proxy. This
+                                          option will only be honored if the
+
+
+
+February 2004                                                  [Page 77]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                          ticket-granting ticket in the
+         4       PROXY                    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.
+
+                                          The ALLOW-POSTDATE option indicates
+                                          that the ticket to be issued is to
+                                          have its MAY-POSTDATE flag set. It
+         5       ALLOW-POSTDATE           may only be set on the initial
+                                          request, or in a subsequent request
+                                          if the ticket-granting ticket on
+                                          which it is based also has its
+                                          MAY-POSTDATE flag set.
+
+                                          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
+         6       POSTDATED                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       RESERVED                 This option is presently unused.
+
+                                          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
+         8       RENEWABLE                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      RESERVED                 Reserved for future use.
+
+         11      RESERVED                 Reserved for opt-hardware-auth.
+
+
+
+
+February 2004                                                  [Page 78]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+         12-25   RESERVED                 Reserved for future use.
+
+                                          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
+         26      DISABLE-TRANSITED-CHECK  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. KDCs are
+                                          encouraged but not required to honor
+                                          the DISABLE-TRANSITED-CHECK option.
+
+                                          This flag is new since RFC 1510
+
+                                          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,
+         27      RENEWABLE-OK             then a renewable ticket may be
+                                          issued with a renew-till equal to
+                                          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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The
+                                          ENC-TKT-IN-SKEY option indicates
+         28      ENC-TKT-IN-SKEY          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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The RENEW
+
+
+
+February 2004                                                  [Page 79]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                          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
+         30      RENEW                    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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The
+                                          VALIDATE option indicates that the
+                                          request is to validate a postdated
+                                          ticket. It will only be honored if
+                                          the ticket presented is postdated,
+                                          presently has its INVALID flag set,
+         31      VALIDATE                 and would be otherwise usable at
+                                          this time. A ticket cannot be
+                                          validated 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. The 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 the Authenticator and ticket-granting
+      ticket come from the padata field in the KRB_TGS_REQ). The key
+      usage value used when encrypting is 5 if a sub-session key is
+      used, or 4 if the session key is used.
+
+   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.
+
+
+
+February 2004                                                  [Page 80]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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 not optional, but if the requested endtime
+      is "19700101000000Z", the requested ticket is to have the maximum
+      endtime permitted according to KDC policy. Implementation note:
+      This special timestamp corresponds to a UNIX time_t value of zero
+      on most systems.
+
+   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 is 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 reused.
+
+   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
+      the ENC-TKT-IN-SKEY option is used for user-to-user
+      authentication, this additional 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
+
+
+
+February 2004                                                  [Page 81]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 tag number 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 (5),
+              msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+              padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                      -- NOTE: not empty --,
+              crealm          [3] Realm,
+              cname           [4] PrincipalName,
+              ticket          [5] Ticket,
+              enc-part        [6] EncryptedData
+                                      -- EncASRepPart or EncTGSRepPart,
+
+
+
+February 2004                                                  [Page 82]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+                                      -- as appropriate
+      }
+
+      EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+      EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+      EncKDCRepPart   ::= SEQUENCE {
+              key             [0] EncryptionKey,
+              last-req        [1] LastReq,
+              nonce           [2] UInt32,
+              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
+      }
+
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+              lr-type         [0] Int32,
+              lr-value        [1] KerberosTime
+      }
+
+   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 "salt" string to be
+      used with a string-to-key algorithm. 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
+      salt 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.
+
+   ticket
+      The newly-issued ticket, from section 5.3.
+
+   enc-part
+
+
+
+February 2004                                                  [Page 83]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 key usage value for encrypting this field is 3 in an AS-REP
+      message, using the client's long-term key or another key selected
+      via pre-authentication mechanisms. In a TGS-REP message, the key
+      usage value is 8 if the TGS session key is used, or 9 if a TGS
+      authenticator subkey is used.
+
+      Compatibility note: Some implementations unconditionally send an
+      encrypted EncTGSRepPart (application tag number 26) in this field
+      regardless of whether the reply is a AS-REP or a TGS-REP. In the
+      interests of compatibility, implementors MAY relax the check on
+      the tag number of the decrypted ENC-PART.
+
+   key
+      This field is the same as described for the ticket in section 5.3.
+
+   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.
+
+      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-
+
+
+
+February 2004                                                  [Page 84]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+         value subfield is the time when the password will expire.  If
+         it is (7), then the lr-value subfield is the time when the
+         account 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.
+
+   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. If present, it SHOULD be set to the earliest of the
+      user's key expiration and account expiration.  The use of this
+      field is deprecated and the last-req field SHOULD be used to
+      convey this information instead.  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), 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.
+
+
+
+February 2004                                                  [Page 85]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      The KRB_AP_REQ message is often referred to as the 'authentication
+      header'.
+
+      AP-REQ          ::= [APPLICATION 14] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (14),
+              ap-options      [2] APOptions,
+              ticket          [3] Ticket,
+              authenticator   [4] EncryptedData -- Authenticator
+      }
+
+      APOptions       ::= KerberosFlags
+              -- 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.
+
+                                 The USE-SESSION-KEY option indicates that the
+                                 ticket the client is presenting to a server
+         1       use-session-key is encrypted in the session key from the
+                                 server's ticket-granting ticket. When this
+                                 option is not specified, the ticket is
+                                 encrypted in the server's secret key.
+
+                                 The MUTUAL-REQUIRED option tells the server
+         2       mutual-required 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.
+
+
+
+February 2004                                                  [Page 86]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   authenticator
+      This contains the encrypted authenticator, which includes the
+      client's choice of a subkey.
+
+   The encrypted authenticator is included in the AP-REQ; it certifies
+   to a server that the sender has recent knowledge of the encryption
+   key in the accompanying ticket, to help the server detect replays. It
+   also assists in the selection of a "true session key" to use with the
+   particular session.  The DER encoding of the following is encrypted
+   in the ticket's session key, with a key usage value of 11 in normal
+   application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
+   of a TGS-REQ exchange (see section 5.4.1):
+
+   -- Unencrypted authenticator
+   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+           authenticator-vno       [0] INTEGER (5),
+           crealm                  [1] Realm,
+           cname                   [2] PrincipalName,
+           cksum                   [3] Checksum OPTIONAL,
+           cusec                   [4] Microseconds,
+           ctime                   [5] KerberosTime,
+           subkey                  [6] EncryptionKey OPTIONAL,
+           seq-number              [7] UInt32 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.
+
+   cksum
+      This field contains a checksum of the application data that
+      accompanies the KRB_AP_REQ, computed using a key usage value of 10
+      in normal application exchanges, or 6 when used in the TGS-REQ PA-
+      TGS-REQ AP-DATA field.
+
+   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.
+
+
+
+February 2004                                                  [Page 87]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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.  In the event that more than 2^32 messages are to be
+      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
+      SHOULD be performed before sequence numbers are reused with the
+      same encryption key.
+
+      Implmentation note: historically, some implementations transmit
+      signed twos-complement numbers for sequence numbers. In the
+      interests of compatibility, implementations MAY accept the
+      equivalent negative number where a positive number greater than
+      2^31 - 1 is expected.
+
+      Implementation note: as noted before, some implementations omit
+      the optional sequence number when its value would be zero.
+      Implementations MAY accept an omitted sequence number when
+      expecting a value of zero, and SHOULD NOT transmit an
+      Authenticator with a initial sequence number of zero.
+
+   authorization-data
+      This field is the same as described for the ticket in section 5.3.
+      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.
+
+
+
+
+February 2004                                                  [Page 88]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+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 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 (5),
+              msg-type        [1] INTEGER (15),
+              enc-part        [2] EncryptedData -- EncAPRepPart
+      }
+
+      EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+              ctime           [0] KerberosTime,
+              cusec           [1] Microseconds,
+              subkey          [2] EncryptionKey OPTIONAL,
+              seq-number      [3] UInt32 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. It is computed
+      with a key usage value of 12.
+
+   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.
+
+
+
+February 2004                                                  [Page 89]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   seq-number
+      This field is described above in section 5.3.2.
+
+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 occurred. The
+      message fields are:
+
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (20),
+              safe-body       [2] KRB-SAFE-BODY,
+              cksum           [3] Checksum
+      }
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+              user-data       [0] OCTET STRING,
+              timestamp       [1] KerberosTime OPTIONAL,
+              usec            [2] Microseconds OPTIONAL,
+              seq-number      [3] UInt32 OPTIONAL,
+              s-address       [4] HostAddress,
+              r-address       [5] HostAddress OPTIONAL
+      }
+
+   pvno and msg-type
+      These fields are described above in section 5.4.1. msg-type is
+      KRB_SAFE.
+
+
+
+
+February 2004                                                  [Page 90]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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, computed
+      with a key usage value of 15.
+
+      The checksum is computed over the encoding of the KRB-SAFE
+      sequence.  First, the cksum is set to a type zero, zero-length
+      value 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.
+      This method, while different than the one specified in RFC 1510,
+      corresponds to existing practice.
+
+   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
+      Sender's address.
+
+      This field specifies the address in use by the sender of the
+      message.
+
+   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.
+
+
+
+
+February 2004                                                  [Page 91]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+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 (5),
+              msg-type        [1] INTEGER (21),
+                              -- NOTE: there is no [2] tag
+              enc-part        [3] EncryptedData -- EncKrbPrivPart
+      }
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+              user-data       [0] OCTET STRING,
+              timestamp       [1] KerberosTime OPTIONAL,
+              usec            [2] Microseconds OPTIONAL,
+              seq-number      [3] UInt32 OPTIONAL,
+              s-address       [4] HostAddress -- 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, with a key usage value of 13.
+      This encrypted encoding is used for the enc-part field of the KRB-
+      PRIV message.
+
+   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
+
+
+
+February 2004                                                  [Page 92]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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 (5),
+              msg-type        [1] INTEGER (22),
+              tickets         [2] SEQUENCE OF Ticket,
+              enc-part        [3] EncryptedData -- EncKrbCredPart
+      }
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+              ticket-info     [0] SEQUENCE OF KrbCredInfo,
+              nonce           [1] UInt32 OPTIONAL,
+              timestamp       [2] KerberosTime OPTIONAL,
+              usec            [3] Microseconds 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.
+
+
+
+February 2004                                                  [Page 93]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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, with a key usage value of 14. This encrypted
+      encoding is used for the enc-part field of the KRB-CRED message.
+
+      Implementation note: implementations of certain applications, most
+      notably certain implementations of the Kerberos GSS-API mechanism,
+      do not separately encrypt the contents of the EncKrbCredPart of
+      the KRB-CRED message when sending it.  In the case of those GSS-
+      API mechanisms, this is not a security vulnerability, as the
+      entire KRB-CRED message is itself embedded in an encrypted
+      message.
+
+   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 reused.
+
+   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 5.2.9.
+
+   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.
+
+
+
+
+February 2004                                                  [Page 94]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   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 corresponding 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 not integrity protected,
+      it is quite possible for an intruder to synthesize or modify such
+      a message. In particular, this means that 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 (5),
+              msg-type        [1] INTEGER (30),
+              ctime           [2] KerberosTime OPTIONAL,
+              cusec           [3] Microseconds OPTIONAL,
+              stime           [4] KerberosTime,
+              susec           [5] Microseconds,
+              error-code      [6] Int32,
+              crealm          [7] Realm OPTIONAL,
+              cname           [8] PrincipalName OPTIONAL,
+              realm           [9] Realm -- service realm --,
+              sname           [10] PrincipalName -- service name --,
+              e-text          [11] KerberosString OPTIONAL,
+              e-data          [12] OCTET STRING OPTIONAL
+      }
+
+   pvno and msg-type
+
+
+
+February 2004                                                  [Page 95]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      These fields are described above in section 5.4.1. msg-type is
+      KRB_ERROR.
+
+   ctime
+      This field is described above in section 5.5.2.
+
+   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 7.5.9. Implementations are
+      encouraged to provide for national language support in the display
+      of error messages.
+
+   crealm, cname, realm and sname
+      These fields are described above in section 5.3.
+
+   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 the
+      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
+      contain an encoding of a sequence of padata fields, each
+      corresponding to an acceptable pre-authentication method and
+      optionally containing data for the method:
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+   For error codes defined in this document other than
+   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
+   are implementation-defined. Similarly, for future error codes, the
+   format and contents of the e-data field are implementation-defined
+
+
+
+February 2004                                                  [Page 96]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   unless specified. Whether defined by the implementation or in a
+   future document, the e-data field MAY take the form of TYPED-DATA:
+
+   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+           data-type       [0] INTEGER,
+           data-value      [1] OCTET STRING OPTIONAL
+   }
+
+5.10. Application Tag Numbers
+
+      The following table lists the application class tag numbers used
+      by various data types defined in this section.
+
+       Tag Number(s)    Type Name    Comments
+
+       0                             unused
+
+       1              Ticket         PDU
+
+       2              Authenticator  non-PDU
+
+       3              EncTicketPart  non-PDU
+
+       4-9                           unused
+
+       10             AS-REQ         PDU
+
+       11             AS-REP         PDU
+
+       12             TGS-REQ        PDU
+
+       13             TGS-REP        PDU
+
+       14             AP-REQ         PDU
+
+       15             AP-REP         PDU
+
+       16             RESERVED16     TGT-REQ (for user-to-user)
+
+       17             RESERVED17     TGT-REP (for user-to-user)
+
+       18-19                         unused
+
+       20             KRB-SAFE       PDU
+
+       21             KRB-PRIV       PDU
+
+       22             KRB-CRED       PDU
+
+
+
+February 2004                                                  [Page 97]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+       23-24                         unused
+
+       25             EncASRepPart   non-PDU
+
+       26             EncTGSRepPart  non-PDU
+
+       27             EncApRepPart   non-PDU
+
+       28             EncKrbPrivPart non-PDU
+
+       29             EncKrbCredPart non-PDU
+
+       30             KRB-ERROR      PDU
+
+      The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above
+      are the only ASN.1 types intended as top-level types of the
+      Kerberos protocol, and are the only types that may be used as
+      elements in another protocol that makes use of Kerberos.
+
+6. Naming Constraints
+
+6.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 three styles of realm names: domain, X500, and other.
+      Examples of each style follow:
+
+           domain:   ATHENA.MIT.EDU
+             X500:   C=US/O=OSF
+            other:   NAMETYPE:rest/of.name=without-restrictions
+
+      Domain style realm 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
+
+
+
+February 2004                                                  [Page 98]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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. Note that the
+      slash separator is consistent with Kerberos implementations based
+      on RFC1510, but it is different from the separator recommended in
+      RFC2253.
+
+      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
+      expect those beginning with 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 exist a name
+      identical to the realm name of the child unless it is assigned to
+      the same entity as the realm name.
+
+6.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
+
+
+
+February 2004                                                  [Page 99]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      be treated only as a hint to interpreting the meaning of a name.
+      It is not significant when checking for equivalence. Principal
+      names that differ only in the name-type identify the same
+      principal. The name type does not partition the name space.
+      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
+
+      name types
+
+      NT-UNKNOWN        0  Name type not known
+      NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
+      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 host as remaining components
+      NT-UID            5  Unique ID
+      NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
+      NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
+      NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
+
+      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 the first component of a name identifies a service and there is
+      a single component following the service name identifying the
+      instance as 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.
+
+
+
+February 2004                                                 [Page 100]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      A name type of NT-X500-PRINCIPAL SHOULD be used when a name from
+      an X.509 certificate 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, including an "@" and a domain name, is
+      used as the one component of the principal name.
+
+      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 7.3
+      for the form of such names.
+
+6.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.
+
+7. Constants and other defined values
+
+7.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.
+
+   Internet (IPv4) Addresses
+
+      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
+      in MSB order. The IPv4 loopback address SHOULD NOT appear in a
+
+
+
+February 2004                                                 [Page 101]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Kerberos packet. The type of IPv4 addresses is two (2).
+
+   Internet (IPv6) Addresses
+
+      IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
+      encoded in MSB order. The type of IPv6 addresses is twenty-four
+      (24). The following addresses MUST NOT appear in any Kerberos
+      packet:
+
+         *  the Unspecified Address
+         *  the Loopback Address
+         *  Link-Local addresses
+
+      IPv4-mapped IPv6 addresses MUST be represented as addresses of
+      type 2.
+
+   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 alphanumeric characters and padded with the US-ASCII SPC
+      character (code 32).  The 16th octet MUST be the US-ASCII NUL
+      character (code 0).  The type of Netbios addresses is twenty (20).
+
+   Directional Addresses
+
+      In many environments, including the sender address in KRB_SAFE and
+      KRB_PRIV messages is undesirable because the addresses may be
+      changed in transport by network address translators. However, if
+      these addresses are removed, the messages may be subject to a
+      reflection attack in which a message is reflected back to its
+      originator. The directional address type provides a way to avoid
+      transport addresses and reflection attacks. Directional addresses
+      are encoded as four byte unsigned integers in network byte order.
+      If the message is originated by the party sending the original
+      KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
+      message is originated by the party to whom that KRB_AP_REQ was
+      sent, then the address 1 SHOULD be used. Applications involving
+      multiple parties can specify the use of other addresses.
+
+      Directional addresses MUST only be used for the sender address
+      field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
+      as a ticket address or in a KRB_AP_REQ message. This address type
+      SHOULD only be used in situations where the sending party knows
+
+
+
+February 2004                                                 [Page 102]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      that the receiving party supports the address type. This generally
+      means that directional addresses may only be used when the
+      application protocol requires their support. Directional addresses
+      are type (3).
+
+7.2. KDC messaging - IP Transports
+
+      Kerberos defines two IP transport mechanisms for communication
+      between clients and servers: UDP/IP and TCP/IP.
+
+7.2.1. UDP/IP transport
+
+      Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+      requests and SHOULD listen for such requests on port 88 (decimal)
+      unless specifically configured to listen on an alternative UDP
+      port. Alternate ports MAY be used when running multiple KDCs for
+      multiple realms on the same host.
+
+      Kerberos clients supporting IP transports SHOULD support the
+      sending of UDP requests. Clients SHOULD use KDC discovery [7.2.3]
+      to identify the IP address and port to which they will send their
+      request.
+
+      When contacting a 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 the KDC. 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. The response to a request made through UDP/IP
+      transport MUST also use UDP/IP transport. If the response can not
+      be handled using UDP (for example because it is too large), the
+      KDC MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to
+      retry the request using the TCP transport.
+
+7.2.2. TCP/IP transport
+
+      Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+      requests and SHOULD listen for such requests on port 88 (decimal)
+      unless specifically configured to listen on an alternate TCP port.
+      Alternate ports MAY be used when running multiple KDCs for
+      multiple realms on the same host.
+
+      Clients MUST support the sending of TCP requests, but MAY choose
+      to initially try a request using the UDP transport. Clients SHOULD
+      use KDC discovery [7.2.3] to identify the IP address and port to
+      which they will send their request.
+
+      Implementation note: Some extensions to the Kerberos protocol will
+
+
+
+February 2004                                                 [Page 103]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      not succeed if any client or KDC not supporting the TCP transport
+      is involved.  Implementations of RFC 1510 were not required to
+      support TCP/IP transports.
+
+      When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
+      the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned
+      to the client on the same TCP stream that was established for the
+      request. The KDC MAY close the TCP stream after sending a
+      response, but MAY leave the stream open for a reasonable period of
+      time if it expects a followup. Care must be taken in managing
+      TCP/IP connections on the KDC to prevent denial of service attacks
+      based on the number of open TCP/IP connections.
+
+      The client MUST be prepared to have the stream closed by the KDC
+      at anytime after the receipt of a response. A stream closure
+      SHOULD NOT be treated as a fatal error. Instead, if multiple
+      exchanges are required (e.g., certain forms of pre-authentication)
+      the client may need to establish a new connection when it is ready
+      to send subsequent messages. A client MAY close the stream after
+      receiving a response, and SHOULD close the stream if it does not
+      expect to send followup messages.
+
+      A client MAY send multiple requests before receiving responses,
+      though it must be prepared to handle the connection being closed
+      after the first response.
+
+      Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
+      sent over the TCP stream is preceded by the length of the request
+      as 4 octets in network byte order. The high bit of the length is
+      reserved for future expansion and MUST currently be set to zero.
+      If a KDC that does not understand how to interpret a set high bit
+      of the length encoding receives a request with the high order bit
+      of the length set, it MUST return a KRB-ERROR message with the
+      error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
+
+      If multiple requests are sent over a single TCP connection, and
+      the KDC sends multiple responses, the KDC is not required to send
+      the responses in the order of the corresponding requests. This may
+      permit some implementations to send each response as soon as it is
+      ready even if earlier requests are still being processed (for
+      example, waiting for a response from an external device or
+      database).
+
+7.2.3. KDC Discovery on IP Networks
+
+      Kerberos client implementations MUST provide a means for the
+      client to determine the location of the Kerberos Key Distribution
+      Centers (KDCs).  Traditionally, Kerberos implementations have
+
+
+
+February 2004                                                 [Page 104]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      stored 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 using cross-realm
+      authentication. This section describes a method for using the
+      Domain Name System [RFC 1035] for storing KDC location
+      information.
+
+7.2.3.1. 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 insensitive for queries. Since the realm names
+      "MYREALM", "myrealm", and "MyRealm" are all different, but resolve
+      the same in the domain name system, it is necessary that only one
+      of the possible combinations of upper and lower case characters be
+      used in realm names.
+
+7.2.3.2. Specifying KDC Location information with DNS SRV records
+
+      KDC location information is to be stored using the DNS SRV RR [RFC
+      2782].  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 one of "udp", "tcp". If these SRV records are to
+      be used, both "udp" and "tcp" records MUST be specified for all
+      KDC deployments.
+
+      The Realm is the Kerberos realm that this record corresponds to.
+      The realm MUST be a domain style realm name.
+
+      TTL, Class, SRV, Priority, Weight, and Target have the standard
+      meaning as defined in RFC 2782.
+
+      As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
+      records SHOULD be the value assigned to "kerberos" by the Internet
+      Assigned Number Authority: 88 (decimal) unless the KDC is
+      configured to listen on an alternate TCP port.
+
+      Implementation note: Many existing client implementations do not
+      support KDC Discovery and are configured to send requests to the
+      IANA assigned port (88 decimal), so it is strongly recommended
+      that KDCs be configured to listen on that port.
+
+
+
+February 2004                                                 [Page 105]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
+
+      These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+      Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
+      should be directed to kdc1.example.com first as per the specified
+      priority. Weights are not used in these sample records.
+
+        _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+        _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+        _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+        _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+
+7.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).
+
+7.4. OID arc for KerberosV5
+
+      This OID MAY be used to identify Kerberos protocol messages
+      encapsulated in other protocols. It also designates the OID arc
+      for KerberosV5-related OIDs assigned by future IETF action.
+      Implementation note:: RFC 1510 had an incorrect value (5) for
+      "dod" in its OID.
+
+      id-krb5         OBJECT IDENTIFIER ::= {
+              iso(1) identified-organization(3) dod(6) internet(1)
+              security(5) kerberosV5(2)
+      }
+
+
+      Assignment of OIDs beneath the id-krb5 arc must be obtained by
+      contacting the registrar for the id-krb5 arc, or its designee.  At
+      the time of the issuance of this RFC, such registrations can be
+      obtained by contacting krb5-oid-registrar@mit.edu.
+
+7.5. Protocol constants and associated values
+
+
+
+
+February 2004                                                 [Page 106]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      The following tables list constants used in the protocol and
+      define 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.
+
+7.5.1. Key usage numbers
+
+      The encryption and checksum specifications in [@KCRYPTO] require
+      as input a "key usage number", to alter the encryption key used in
+      any specific message, to make certain types of cryptographic
+      attack more difficult. These are the key usage values assigned in
+      this document:
+
+              1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
+                          with the client key (section 5.2.7.2)
+              2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
+                          key or application session key), encrypted with the
+                          service key (section 5.3)
+              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.5.1)
+              7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
+                          (includes TGS authenticator subkey), encrypted with the
+                          TGS session key (section 5.5.1)
+              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.5.1)
+              11.         AP-REQ Authenticator (includes application
+                          authenticator subkey), encrypted with the application
+                          session key (section 5.5.1)
+              12.         AP-REP encrypted part (includes application session
+                          subkey), encrypted with the application session key
+                          (section 5.5.2)
+
+
+
+February 2004                                                 [Page 107]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              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.8.1)
+              15.         KRB-SAFE cksum, keyed with a key chosen by the
+                          application (section 5.6.1)
+              19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
+            22-25.        Reserved for use in GSSAPI mechanisms derived from RFC
+                          1964. (raeburn/MIT)
+       16-18,20-21,26-511. Reserved for future use in Kerberos and related
+                          protocols.
+           512-1023.      Reserved for uses internal to a Kerberos
+                          implementation.
+            1024.         Encryption for application use in protocols that
+                          do not specify key usage values
+            1025.         Checksums for application use in protocols that
+                          do not specify key usage values
+          1026-2047.      Reserved for application use.
+
+
+7.5.2. PreAuthentication Data Types
+
+      padata and data types           padata-type value  comment
+
+      PA-TGS-REQ                      1
+      PA-ENC-TIMESTAMP                2
+      PA-PW-SALT                      3
+      [reserved]                      4
+      PA-ENC-UNIX-TIME                5        (deprecated)
+      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-ETYPE-INFO2                  19       (replaces pa-etype-info)
+      PA-USE-SPECIFIED-KVNO           20
+      PA-SAM-REDIRECT                 21       (sam/otp)
+      PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
+      TD-PADATA                       22       (embeds padata)
+      PA-SAM-ETYPE-INFO               23       (sam/otp)
+      PA-ALT-PRINC                    24       (crawdad@fnal.gov)
+      PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
+      PA-SAM-RESPONSE2                31       (kenh@pobox.com)
+
+
+
+February 2004                                                 [Page 108]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      PA-EXTRA-TGT                    41       Reserved extra TGT
+      TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
+      TD-KRB-PRINCIPAL                102      PrincipalName
+      TD-KRB-REALM                    103      Realm
+      TD-TRUSTED-CERTIFIERS           104      from PKINIT
+      TD-CERTIFICATE-INDEX            105      from PKINIT
+      TD-APP-DEFINED-ERROR            106      application specific
+      TD-REQ-NONCE                    107      INTEGER
+      TD-REQ-SEQ                      108      INTEGER
+      PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
+
+7.5.3. Address Types
+
+      Address type                   value
+
+      IPv4                             2
+      Directional                      3
+      ChaosNet                         5
+      XNS                              6
+      ISO                              7
+      DECNET Phase IV                 12
+      AppleTalk DDP                   16
+      NetBios                         20
+      IPv6                            24
+
+7.5.4. Authorization Data Types
+
+      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-AND-OR                          5
+      AD-MANDATORY-TICKET-EXTENSIONS     6
+      AD-IN-TICKET-EXTENSIONS            7
+      AD-MANDATORY-FOR-KDC               8
+      reserved values                    9-63
+      OSF-DCE                            64
+      SESAME                             65
+      AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
+      AD-WIN2K-PAC                      128         (jbrezak@exchange.microsoft.com)
+
+7.5.5. Transited Encoding Types
+
+      transited encoding type         tr-type value
+      DOMAIN-X500-COMPRESS            1
+      reserved values                 all others
+
+
+
+
+February 2004                                                 [Page 109]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+7.5.6. Protocol Version Number
+
+      Label               Value   Meaning or MIT code
+
+      pvno                    5   current Kerberos protocol version number
+
+7.5.7. Kerberos Message Types
+
+      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_RESERVED16         16   Reserved for user-to-user krb_tgt_request
+      KRB_RESERVED17         17   Reserved for user-to-user krb_tgt_reply
+      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
+
+7.5.8. Name Types
+
+      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]
+      KRB_NT_SMTP_NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
+      KRB_NT_ENTERPRISE    10   Enterprise name - may be mapped to principal name
+
+7.5.9. Error Codes
+
+      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
+
+
+
+February 2004                                                 [Page 110]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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
+      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
+
+
+
+February 2004                                                 [Page 111]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      KDC_ERROR_CLIENT_NOT_TRUSTED      62 Reserved for PKINIT
+      KDC_ERROR_KDC_NOT_TRUSTED         63 Reserved for PKINIT
+      KDC_ERROR_INVALID_SIG             64 Reserved for PKINIT
+      KDC_ERR_KEY_TOO_WEAK              65 Reserved for PKINIT
+      KDC_ERR_CERTIFICATE_MISMATCH      66 Reserved for PKINIT
+      KRB_AP_ERR_NO_TGT                 67 No TGT available to validate USER-TO-USER
+      KDC_ERR_WRONG_REALM               68 USER-TO-USER TGT issued different KDC
+      KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
+      KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
+      KDC_ERR_INVALID_CERTIFICATE             71 Reserved for PKINIT
+      KDC_ERR_REVOKED_CERTIFICATE             72 Reserved for PKINIT
+      KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
+      KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
+      KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
+      KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
+
+8. 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.
+
+8.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.2). Specification 1
+      (deprecated) may be found in RFC1510.
+
+   Transport
+
+      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
+      claiming conformance to specification 2.
+
+   Encryption and checksum methods
+
+
+
+
+February 2004                                                 [Page 112]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      The following encryption and checksum mechanisms MUST be
+      supported.
+
+      Encryption: AES256-CTS-HMAC-SHA1-96
+      Checksums: HMAC-SHA1-96-AES256
+
+      Implementations SHOULD support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them. The mechanisms that SHOULD
+      be supported are:
+
+      Encryption:  DES-CBC-MD5, DES3-CBC-SHA1-KD
+      Checksums:   DES-MD5, HMAC-SHA1-DES3-KD
+
+      Implementations MAY support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them.
+
+      Implementation note: earlier implementations of Kerberos generate
+      messages using the CRC-32, RSA-MD5 checksum methods. For
+      interoperability with these earlier releases implementors MAY
+      consider supporting these checksum methods but should carefully
+      analyze the security impplications to limit the situations within
+      which these methods are accepted.
+
+   Realm Names
+
+      All implementations MUST understand hierarchical realms in both
+      the Internet Domain and the X.500 style. When a ticket-granting
+      ticket for an unknown realm is requested, the KDC MUST be able to
+      determine the names of the intermediate realms between the KDCs
+      realm and the requested realm.
+
+   Transited field encoding
+
+      DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
+      supported.  Alternative encodings MAY be supported, but they may
+      be used only when that encoding is supported by ALL intermediate
+      realms.
+
+   Pre-authentication methods
+
+      The TGS-REQ method MUST be supported. The TGS-REQ method is not
+      used on the initial request. The PA-ENC-TIMESTAMP method MUST be
+      supported by clients but whether it is enabled by default MAY be
+      determined on a realm by realm basis. If not used in the initial
+      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
+      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
+
+
+
+February 2004                                                 [Page 113]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
+      authentication 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.
+
+      The ETYPE-INFO2 method MUST be supported; this method is used to
+      communicate the set of supported encryption types, and
+      corresponding salt and string to key paramters. The ETYPE-INFO
+      method SHOULD be supported for interoperability with older
+      implementation.
+
+   Mutual authentication
+
+      Mutual authentication (via the KRB_AP_REP message) MUST be
+      supported.
+
+   Ticket addresses and flags
+
+      All KDCs MUST pass through tickets that carry no addresses (i.e.
+      if a TGT contains no addresses, the KDC will return derivative
+      tickets).  Implementations SHOULD default to requesting
+      addressless tickets as this significantly increases
+      interoperability with network address translation.  In some cases
+      realms or application servers MAY require that tickets have an
+      address.
+
+      Implementations SHOULD accept directional address type for the
+      KRB_SAFE and KRB_PRIV message and SHOULD include directional
+      addresses in these messages when other address types are not
+      available.
+
+      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.
+
+
+
+February 2004                                                 [Page 114]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+   Authorization data
+
+      Implementations MUST pass all authorization data subfields from
+      ticket-granting tickets to any derivative tickets unless directed
+      to suppress a subfield as part of the definition of that
+      registered subfield type (it is never incorrect to pass on a
+      subfield, and no registered subfield types presently specify
+      suppression at the KDC).
+
+      Implementations MUST make the contents of any authorization data
+      subfields available to the server when a ticket is used.
+      Implementations are not required to allow clients to specify the
+      contents of the authorization data fields.
+
+   Constant ranges
+
+      All protocol constants are constrained to 32 bit (signed) values
+      unless further constrained by the protocol definition. This limit
+      is provided to allow implementations to make assumptions about the
+      maximum values that will be received for these constants.
+      Implementation receiving values outside this range MAY reject the
+      request, but they MUST recover cleanly.
+
+8.2. Recommended KDC values
+
+      Following is a list of recommended values for a KDC configuration.
+
+      minimum lifetime              5 minutes
+      maximum renewable lifetime    1 week
+      maximum ticket lifetime       1 day
+      acceptable clock skew         5 minutes
+      empty addresses               Allowed.
+      proxiable, etc.               Allowed.
+
+9. IANA considerations
+
+      Section 7 of this document specifies protocol constants and other
+      defined values required for the interoperability of multiple
+      implementations. Until otherwise specified in a subsequent RFC, or
+      upon disbanding of the Kerberos working group, allocations of
+      additional protocol constants and other defined values required
+      for extensions to the Kerberos protocol will be administered by
+      the kerberos working group.  Following the recomendations outlined
+      in [RFC 2434], guidance is provided to the IANA as follows:
+
+      "reserved" realm name types in section 6.1 and "other" realm types
+      except those beginning with "X-" or "x-" will not be registered
+      without IETF standards action, at which point guidlines for
+
+
+
+February 2004                                                 [Page 115]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      further assignment will be specified.  Realm name types beginning
+      with "X-" or "x-" are for private use.
+
+      For host address types described in section 7.1, negative values
+      are for private use.  Assignment of additional positive numbers is
+      subject to review by the kerberos working group or other expert
+      review.
+
+      Additional key usage numbers as defined in section 7.5.1 will be
+      assigned subject to review by the kerberos working group or other
+      expert review.
+
+      Additional preauthentciation data type values as defined in
+      section 7.5.2 will be assigned subject to review by the kerberos
+      working group or other expert review.
+
+      Additional Authorization Data Types as defined in section 7.5.4
+      will be assigned subject to review by the kerberos working group
+      or other expert review.  Although it is anticipated that there may
+      be significant demand for private use types, provision is
+      intentionaly not made for a private use portion of the namespace
+      because conficts between privately assigned values coule have
+      detrimental security implications.
+
+      Additional Transited Encoding Types as defined in section 7.5.5
+      present special concerns for interoperability with existing
+      implementations.  As such, such assignments will only be made by
+      standards action, except that the Kerberos working group or
+      another other working group with competent jurisdiction may make
+      preliminary assignments for documents which are moving through the
+      standards process.
+
+      Additional Kerberos Message Types as described in section 7.5.7
+      will be assigned subject to review by the kerberos working group
+      or other expert review.
+
+      Additional Name Types as described in section 7.5.8 will be
+      assigned subject to review by the kerberos working group or other
+      expert review.
+
+      Additional error codes described in section 7.5.9 will be assigned
+      subject to review by the kerberos working group or other expert
+      review.
+
+10. Security Considerations
+
+      As an authentication service, Kerberos provides a means of
+      verifying the identity of principals on a network. Kerberos does
+
+
+
+February 2004                                                 [Page 116]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      not, by itself, provide authorization. Applications should not
+      accept the issuance of a service ticket by the 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 inter-operate with other KDCs or where other
+      options for application authentication are provided.
+
+      Denial of service attacks are not solved with Kerberos. There are
+      places in the protocols where an intruder can prevent an
+      application from participating in the proper authentication steps.
+      Because authentication is a required step for the use of many
+      services, successful denial of service attacks on a Kerberos
+      server might result in the denial of other network services that
+      rely on Kerberos for authentication. Kerberos is vulnerable to
+      many kinds of denial of service attacks: denial of service attacks
+      on the network which would prevent clients from contacting the
+      KDC; denial of service attacks on the domain name system which
+      could prevent a client from finding the IP address of the Kerberos
+      server; and denial of service attack by overloading the Kerberos
+      KDC itself with repeated requests.
+
+      Interoperability conflicts caused by incompatible character-set
+      usage (see 5.2.1) can result in denial of service for clients that
+      utilize character-sets in Kerberos strings other than those stored
+      in the KDC database.
+
+      Authentication servers maintain a database of principals (i.e.,
+      users and servers) and their secret keys. The security of the
+      authentication server machines is critical. The breach of security
+      of an authentication server will compromise the security of all
+      servers that rely upon the compromised KDC, and will compromise
+      the authentication of any principals registered in the realm of
+      the compromised KDC.
+
+      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 off-line 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.
+
+      Unless pre-authentication options are required by the policy of a
+      realm, the KDC will not know whether a request for authentication
+
+
+
+February 2004                                                 [Page 117]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      succeeds. An attacker can request a reply with credentials for any
+      principal. These credentials will likely not be of much use to the
+      attacker unless it knows the client's secret key, but the
+      availability of the response encrypted in the client's secret key
+      provides the attacker with ciphertext that may be used to mount
+      brute force or dictionary attacks to decrypt the credentials, by
+      guessing the user's password. For this reason it is strongly
+      encouraged that Kerberos realms require the use of pre-
+      authentication. Even with pre-authentication, attackers may try
+      brute force or dictionary attacks against credentials that are
+      observed by eavesdropping on the network.
+
+      Because a client can request a ticket for any server principal and
+      can attempt a brute force or dictionary attack against the server
+      principal's key using that ticket, it is strongly encouraged that
+      keys be randomly generated (rather than generated from passwords)
+      for any principals that are usable as the target principal for a
+      KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750]
+
+      Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
+      methods are listed as SHOULD be implemented for backward
+      compatibility, the single DES encryption algorithm on which these
+      are based is weak and stronger algorithms should be used whenever
+      possible.
+
+      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 must 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 reusing principal
+      identifiers, the danger of inadvertent access is removed.
+
+      Proper decryption of an KRB_AS_REP message from the KDC is not
+      sufficient for the host 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. To authenticate a user logging on to a local system, the
+      credentials obtained in the AS exchange may first be used in a TGS
+
+
+
+February 2004                                                 [Page 118]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      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.
+
+      Many RFC 1510 compliant implementations ignore unknown
+      authorization data elements. Depending on these implementations to
+      honor authorization data restrictions may create a security
+      weakness.
+
+      Kerberos credentials contain clear-text information identifying
+      the principals to which they apply. If privacy of this information
+      is needed, this exchange should itself be encapsulated in a
+      protocol providing for confidentiality on the exchange of these
+      credentials.
+
+      Applications must take care to protect communications subsequent
+      to authentication either by using the KRB_PRIV or KRB_SAFE
+      messages as appropriate, or by applying their own confidentiality
+      or integrity mechanisms on such communications. Completion of the
+      KRB_AP_REQ and KRB_AP_REP exchange without subsequent use of
+      confidentiality and integrity mechanisms provides only for
+      authentication of the parties to the communication and not
+      confidentiality and integrity of the subsequent communication.
+      Application applying confidentiality and integrity protection
+      mechanisms other than KRB_PRIV and KRB_SAFE must make sure that
+      the authentication step is appropriately linked with the protected
+      communication channel that is established by the application.
+
+      Unless the application server provides its own suitable means to
+      protect against replay (for example, a challenge-response sequence
+      initiated by the server after authentication, or use of a server-
+      generated encryption subkey), the server must utilize a replay
+      cache to remember any authenticator presented within the allowable
+      clock skew. All services sharing a key need to use the same replay
+      cache. If separate replay caches are used, then and authenticator
+      used with one such service could later be replayed to a different
+      service with the same service principal.
+
+      If a server loses track of authenticators presented within the
+      allowable clock skew, it must reject all requests until the clock
+      skew interval has passed, providing assurance that any lost or
+      replayed authenticators will fall outside the allowable clock skew
+      and can no longer be successfully replayed.
+
+      Implementations of Kerberos should not use untrusted directory
+      servers to determine the realm of a host. To allow such would
+      allow the compromise of the directory server to enable an attacker
+      to direct the client to accept authentication with the wrong
+
+
+
+February 2004                                                 [Page 119]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      principal (i.e. one with a similar name, but in a realm with which
+      the legitimate host was not registered).
+
+      Implementations of Kerberos must not use DNS to map one name to
+      another (canonicalize) to determine the host part of the principal
+      name with which one is to communicate.  To allow such
+      canonicalization would allow a compromise of the DNS to result in
+      a client obtaining credentials and correctly authenticating to the
+      wrong principal. Though the client will know who it is
+      communicating with, it will not be the principal with which it
+      intended to communicate.
+
+      If the Kerberos server returns a TGT for a 'closer' realm other
+      than the desired realm, the client may use local policy
+      configuration to verify that the authentication path used is an
+      acceptable one.  Alternatively, a client may choose its own
+      authentication path, rather than relying on the Kerberos server to
+      select one. In either case, any policy or configuration
+      information used to choose or validate authentication paths,
+      whether by the Kerberos server or client, must be obtained from a
+      trusted source.
+
+      The Kerberos protocol in its basic form does not provide perfect
+      forward secrecy for communications. If traffic has been recorded
+      by an eavesdropper, then messages encrypted using the KRB_PRIV
+      message, or messages encrypted using application specific
+      encryption under keys exchanged using Kerberos can be decrypted if
+      any of the user's, application server's, or KDC's key is
+      subsequently discovered. This is because the session key use to
+      encrypt such messages is transmitted over the network encrypted in
+      the key of the application server, and also encrypted under the
+      session key from the user's ticket-granting ticket when returned
+      to the user in the KRB_TGS_REP message. The session key from the
+      ticket-granting ticket was sent to the user in the KRB_AS_REP
+      message encrypted in the user's secret key, and embedded in the
+      ticket-granting ticket, which was encrypted in the key of the KDC.
+      Application requiring perfect forward secrecy must exchange keys
+      through mechanisms that provide such assurance, but may use
+      Kerberos for authentication of the encrypted channel established
+      through such other means.
+
+11. Author's Addresses
+
+
+          Clifford Neuman
+          Information Sciences Institute
+          University of Southern California
+          4676 Admiralty Way
+
+
+
+February 2004                                                 [Page 120]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+          Marina del Rey, CA 90292, USA
+          Email: bcn@isi.edu
+
+          Tom Yu
+          Massachusetts Institute of Technology
+          77 Massachusetts Avenue
+          Cambridge, MA 02139, USA
+          Email: tlyu@mit.edu
+
+          Sam Hartman
+          Massachusetts Institute of Technology
+          77 Massachusetts Avenue
+          Cambridge, MA 02139, USA
+          Email: hartmans@mit.edu
+
+          Kenneth Raeburn
+          Massachusetts Institute of Technology
+          77 Massachusetts Avenue
+          Cambridge, MA 02139, USA
+          Email: raeburn@MIT.EDU
+
+
+12. Acknowledgements
+
+      This document is a revision to RFC1510 which was co-authored with
+      John Kohl.  The specification of the Kerberos protocol described
+      in this document is the result of many years of effort.  Over this
+      period many individuals have contributed to the definition of the
+      protocol and to the writing of the specification. Unfortunately it
+      is not possible to list all contributors as authors of this
+      document, though there are many not listed who are authors in
+      spirit, because they contributed text for parts of some sections,
+      because they contributed to the design of parts of the protocol,
+      or because they contributed significantly to the discussion of the
+      protocol in the IETF common authentication technology (CAT) and
+      Kerberos working groups.
+
+      Among those contributing to the development and specification of
+      Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
+      Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John
+      Kohl, Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John
+      Linn, Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis,
+      Jerome Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick,
+      Mike Swift, Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques
+      Vidrine, Assar Westerlund, and Nicolas Williams. Many other
+      members of MIT Project Athena, the MIT networking group, and the
+      Kerberos and CAT working groups of the IETF contributed but are
+      not listed.
+
+
+
+February 2004                                                 [Page 121]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Funding for the RFC Editor function is currently provided by the
+      Internet Society.
+
+13. REFERENCES
+
+13.1 NORMATIVE REFERENCES
+
+   [@KCRYPTO]
+      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
+      crypto.
+
+   [@AES]
+      RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
+      rijndael-krb.
+
+   [ISO-646/ECMA-6]
+      7-bit Coded Character Set
+
+   [ISO-2022/ECMA-35]
+      Character Code Structure and Extension Techniques
+
+   [ISO-4873/ECMA-43]
+      8-bit Coded Character Set Structure and Rules
+
+   [RFC1035]
+      P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
+      Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
+      RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
+      RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
+      RFC2535, RFC2845, and RFC3425. Status: Standard.
+
+   [RFC2119]
+
+      S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+      Requirement Levels", March 1997.
+
+   [RFC2434]
+      T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA
+      Consideration Secionts in RFCs" October, 1998.
+
+   [RFC2782]
+      A. Gulbrandsen,  P. Vixie and L. Esibov., RFC2782: "A DNS RR for
+      Specifying the Location of Services (DNS SRV)," February 2000.
+
+   [RFC2253]
+      M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
+      Access Protocol (v3): UTF-8 String Representation or Distinguished
+      Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
+
+
+
+February 2004                                                 [Page 122]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Status: Proposed Standard.
+
+   [RFC2373]
+      R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
+      Architecture," July 1998, Status: Proposed Standard.
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+
+13.2 INFORMATIVE REFERENCES
+
+   [DGT96]
+      Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks
+      Adrift: History, Protocols, and Implementation", USENIX Computing
+      Systems 9:1 (January 1996).
+
+   [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).
+
+   [KNT94]
+
+      John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+      Evolution of the Kerberos Authentication System". In Distributed
+      Open Systems, pages 78-94. IEEE Computer Society Press, 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).
+
+   [NS78]
+      Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+      Authentication in Large Networks of Computers," Communications of
+      the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+   [Neu93]
+      B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
+
+
+
+February 2004                                                 [Page 123]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      Distributed Systems," in Proceedings of the 13th International
+      Conference on Distributed Computing Systems, Pittsburgh, PA (May,
+      1993).
+
+   [NT94]
+      B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
+      Service for Computer Networks," IEEE Communications Magazine, Vol.
+      32(9), pp.  33-38 (September 1994).
+
+   [Pat92].
+      J. Pato, Using Pre-Authentication to Avoid Password Guessing
+      Attacks, Open Software Foundation DCE Request for Comments 26
+      (December 1992).
+
+   [RFC1510]
+      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
+      Authentication Service (v5)," September 1993, Status: Proposed
+      Standard.
+
+   [RFC1750]
+      D. Eastlake, S. Crocker, and J. Schiller "Randomness
+      Recommendation for Security" December 1994, Status: Informational.
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [SNS88]
+      J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
+      Authentication Service for Open Network Systems," pp. 191-202 in
+      Usenix Conference Proceedings, Dallas, Texas (February, 1988).
+
+
+14. Copyright Statement
+
+      Copyright (C) The Internet Society (2004).  This document is
+      subject to the rights, licenses and restrictions contained in BCP
+      78 and except as set forth therein, the authors retain all their
+      rights.
+
+      This document and the information contained herein are provided on
+      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+      THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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
+
+
+
+February 2004                                                 [Page 124]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      PARTICULAR PURPOSE.
+
+15. Intellectual Property
+
+      The IETF takes no position regarding the validity or scope of any
+      Intellectual Property Rights 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; nor does it
+      represent that it has made any independent effort to identify any
+      such rights.  Information on the procedures with respect to rights
+      in RFC documents can be found in BCP 78 and BCP 79.
+
+      Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository
+      at http://www.ietf.org/ipr.
+
+      The IETF invites any interested party to bring to its attention
+      any copyrights, patents or patent applications, or other
+      proprietary rights that may cover technology that may be required
+      to implement this standard.  Please address the information to the
+      IETF at ietf-ipr@ietf.org.
+
+A. ASN.1 module
+
+      KerberosV5Spec2 {
+              iso(1) identified-organization(3) dod(6) internet(1)
+              security(5) kerberosV5(2) modules(4) krb5spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+              iso(1) identified-organization(3) dod(6) internet(1)
+              security(5) kerberosV5(2)
+      }
+
+      Int32           ::= INTEGER (-2147483648..2147483647)
+                          -- signed values representable in 32 bits
+
+
+
+February 2004                                                 [Page 125]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      UInt32          ::= INTEGER (0..4294967295)
+                          -- unsigned 32 bit values
+
+      Microseconds    ::= INTEGER (0..999999)
+                          -- microseconds
+
+      KerberosString  ::= GeneralString (IA5String)
+
+      Realm           ::= KerberosString
+
+      PrincipalName   ::= SEQUENCE {
+              name-type       [0] Int32,
+              name-string     [1] SEQUENCE OF KerberosString
+      }
+
+      KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+      HostAddress     ::= SEQUENCE  {
+              addr-type       [0] Int32,
+              address         [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be empty.
+      HostAddresses   -- NOTE: subtly different from rfc1510,
+                      -- but has a value mapping and encodes the same
+              ::= SEQUENCE OF HostAddress
+
+      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+      -- should not be empty.
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+              ad-type         [0] Int32,
+              ad-data         [1] OCTET STRING
+      }
+
+      PA-DATA         ::= SEQUENCE {
+              -- NOTE: first tag is [1], not [0]
+              padata-type     [1] Int32,
+              padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+      }
+
+      KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
+                          -- shall be sent, but no fewer than 32
+
+      EncryptedData   ::= SEQUENCE {
+              etype   [0] Int32 -- EncryptionType --,
+              kvno    [1] UInt32 OPTIONAL,
+              cipher  [2] OCTET STRING -- ciphertext
+
+
+
+February 2004                                                 [Page 126]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      }
+
+      EncryptionKey   ::= SEQUENCE {
+              keytype         [0] Int32 -- actually encryption type --,
+              keyvalue        [1] OCTET STRING
+      }
+
+      Checksum        ::= SEQUENCE {
+              cksumtype       [0] Int32,
+              checksum        [1] OCTET STRING
+      }
+
+      Ticket          ::= [APPLICATION 1] SEQUENCE {
+              tkt-vno         [0] INTEGER (5),
+              realm           [1] Realm,
+              sname           [2] PrincipalName,
+              enc-part        [3] EncryptedData -- EncTicketPart
+      }
+
+      -- 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] Int32 -- must be registered --,
+              contents        [1] OCTET STRING
+      }
+
+      TicketFlags     ::= KerberosFlags
+              -- reserved(0),
+              -- forwardable(1),
+              -- forwarded(2),
+              -- proxiable(3),
+              -- proxy(4),
+              -- may-postdate(5),
+              -- postdated(6),
+
+
+
+February 2004                                                 [Page 127]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              -- invalid(7),
+              -- renewable(8),
+              -- initial(9),
+              -- pre-authent(10),
+              -- hw-authent(11),
+      -- the following are new since 1510
+              -- transited-policy-checked(12),
+              -- ok-as-delegate(13)
+
+      AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+      TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+      KDC-REQ         ::= SEQUENCE {
+              -- NOTE: first tag is [1], not [0]
+              pvno            [1] INTEGER (5) ,
+              msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+              padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                                  -- NOTE: not empty --,
+              req-body        [4] KDC-REQ-BODY
+      }
+
+      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,
+              rtime                   [6] KerberosTime OPTIONAL,
+              nonce                   [7] UInt32,
+              etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                          -- in preference order --,
+              addresses               [9] HostAddresses OPTIONAL,
+              enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
+              additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                              -- NOTE: not empty
+      }
+
+      KDCOptions      ::= KerberosFlags
+              -- reserved(0),
+              -- forwardable(1),
+              -- forwarded(2),
+              -- proxiable(3),
+              -- proxy(4),
+
+
+
+February 2004                                                 [Page 128]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              -- allow-postdate(5),
+              -- postdated(6),
+              -- unused7(7),
+              -- renewable(8),
+              -- unused9(9),
+              -- unused10(10),
+              -- opt-hardware-auth(11),
+              -- unused12(12),
+              -- unused13(13),
+      -- 15 is reserved for canonicalize
+              -- unused15(15),
+      -- 26 was unused in 1510
+              -- disable-transited-check(26),
+      --
+              -- renewable-ok(27),
+              -- enc-tkt-in-skey(28),
+              -- renew(30),
+              -- validate(31)
+
+      AS-REP          ::= [APPLICATION 11] KDC-REP
+
+      TGS-REP         ::= [APPLICATION 13] KDC-REP
+
+      KDC-REP         ::= SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+              padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                      -- NOTE: not empty --,
+              crealm          [3] Realm,
+              cname           [4] PrincipalName,
+              ticket          [5] Ticket,
+              enc-part        [6] EncryptedData
+                                      -- EncASRepPart or EncTGSRepPart,
+                                      -- as appropriate
+      }
+
+      EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+      EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+      EncKDCRepPart   ::= SEQUENCE {
+              key             [0] EncryptionKey,
+              last-req        [1] LastReq,
+              nonce           [2] UInt32,
+              key-expiration  [3] KerberosTime OPTIONAL,
+              flags           [4] TicketFlags,
+              authtime        [5] KerberosTime,
+              starttime       [6] KerberosTime OPTIONAL,
+
+
+
+February 2004                                                 [Page 129]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              endtime         [7] KerberosTime,
+              renew-till      [8] KerberosTime OPTIONAL,
+              srealm          [9] Realm,
+              sname           [10] PrincipalName,
+              caddr           [11] HostAddresses OPTIONAL
+      }
+
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+              lr-type         [0] Int32,
+              lr-value        [1] KerberosTime
+      }
+
+      AP-REQ          ::= [APPLICATION 14] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (14),
+              ap-options      [2] APOptions,
+              ticket          [3] Ticket,
+              authenticator   [4] EncryptedData -- Authenticator
+      }
+
+      APOptions       ::= KerberosFlags
+              -- reserved(0),
+              -- use-session-key(1),
+              -- mutual-required(2)
+
+      -- Unencrypted authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+              authenticator-vno       [0] INTEGER (5),
+              crealm                  [1] Realm,
+              cname                   [2] PrincipalName,
+              cksum                   [3] Checksum OPTIONAL,
+              cusec                   [4] Microseconds,
+              ctime                   [5] KerberosTime,
+              subkey                  [6] EncryptionKey OPTIONAL,
+              seq-number              [7] UInt32 OPTIONAL,
+              authorization-data      [8] AuthorizationData OPTIONAL
+      }
+
+      AP-REP          ::= [APPLICATION 15] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (15),
+              enc-part        [2] EncryptedData -- EncAPRepPart
+      }
+
+      EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+              ctime           [0] KerberosTime,
+              cusec           [1] Microseconds,
+              subkey          [2] EncryptionKey OPTIONAL,
+
+
+
+February 2004                                                 [Page 130]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              seq-number      [3] UInt32 OPTIONAL
+      }
+
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (20),
+              safe-body       [2] KRB-SAFE-BODY,
+              cksum           [3] Checksum
+      }
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+              user-data       [0] OCTET STRING,
+              timestamp       [1] KerberosTime OPTIONAL,
+              usec            [2] Microseconds OPTIONAL,
+              seq-number      [3] UInt32 OPTIONAL,
+              s-address       [4] HostAddress,
+              r-address       [5] HostAddress OPTIONAL
+      }
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (21),
+                              -- NOTE: there is no [2] tag
+              enc-part        [3] EncryptedData -- EncKrbPrivPart
+      }
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+              user-data       [0] OCTET STRING,
+              timestamp       [1] KerberosTime OPTIONAL,
+              usec            [2] Microseconds OPTIONAL,
+              seq-number      [3] UInt32 OPTIONAL,
+              s-address       [4] HostAddress -- sender's addr --,
+              r-address       [5] HostAddress OPTIONAL -- recip's addr
+      }
+
+      KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (22),
+              tickets         [2] SEQUENCE OF Ticket,
+              enc-part        [3] EncryptedData -- EncKrbCredPart
+      }
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+              ticket-info     [0] SEQUENCE OF KrbCredInfo,
+              nonce           [1] UInt32 OPTIONAL,
+              timestamp       [2] KerberosTime OPTIONAL,
+              usec            [3] Microseconds OPTIONAL,
+              s-address       [4] HostAddress OPTIONAL,
+
+
+
+February 2004                                                 [Page 131]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+              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
+      }
+
+      KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
+              pvno            [0] INTEGER (5),
+              msg-type        [1] INTEGER (30),
+              ctime           [2] KerberosTime OPTIONAL,
+              cusec           [3] Microseconds OPTIONAL,
+              stime           [4] KerberosTime,
+              susec           [5] Microseconds,
+              error-code      [6] Int32,
+              crealm          [7] Realm OPTIONAL,
+              cname           [8] PrincipalName OPTIONAL,
+              realm           [9] Realm -- service realm --,
+              sname           [10] PrincipalName -- service name --,
+              e-text          [11] KerberosString OPTIONAL,
+              e-data          [12] OCTET STRING OPTIONAL
+      }
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+              data-type       [0] INTEGER,
+              data-value      [1] OCTET STRING OPTIONAL
+      }
+
+      -- preauth stuff follows
+
+      PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+
+February 2004                                                 [Page 132]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] Int32,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] Int32,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+      ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
+
+      AD-IF-RELEVANT          ::= AuthorizationData
+
+      AD-KDCIssued            ::= SEQUENCE {
+              ad-checksum     [0] Checksum,
+              i-realm         [1] Realm OPTIONAL,
+              i-sname         [2] PrincipalName OPTIONAL,
+              elements        [3] AuthorizationData
+      }
+
+      AD-AND-OR               ::= SEQUENCE {
+              condition-count [0] INTEGER,
+              elements        [1] AuthorizationData
+      }
+
+      AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+      END
+
+B. Changes since RFC-1510
+
+      This document replaces RFC-1510 and clarifies specification of
+      items that were not completely specified. Where changes to
+      recommended implementation choices were made, or where new options
+      were added, those changes are described within the document and
+      listed in this section. More significantly, "Specification 2" in
+      section 8 changes the required encryption and checksum methods to
+      bring them in line with the best current practices and to
+      deprecate methods that are no longer considered sufficiently
+      strong.
+
+      Discussion was added to section 1 regarding the ability to rely on
+      the KDC to check the transited field, and on the inclusion of a
+      flag in a ticket indicating that this check has occurred. This is
+
+
+
+February 2004                                                 [Page 133]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      a new capability not present in RFC1510. Pre-existing
+      implementations may ignore or not set this flag without negative
+      security implications.
+
+      The definition of the secret key says that in the case of a user
+      the key may be derived from a password. In 1510, it said that the
+      key was derived from the password. This change was made to
+      accommodate situations where the user key might be stored on a
+      smart-card, or otherwise obtained independent of a password.
+
+      The introduction mentions the use of public key cryptography for
+      initial authentication in Kerberos by reference. RFC1510 did not
+      include such a reference.
+
+      Section 1.2 was added to explain that while Kerberos provides
+      authentication of a named principal, it is still the
+      responsibility of the application to ensure that the authenticated
+      name is the entity with which the application wishes to
+      communicate.
+
+      Discussion of extensibility has been added to the introduction.
+
+      Discussion of how extensibility affects ticket flags and KDC
+      options was added to the introduction of section 2. No changes
+      were made to existing options and flags specified in RFC1510,
+      though some of the sections in the specification were renumbered,
+      and text was revised to make the description and intent of
+      existing options clearer, especially with respect to the ENC-TKT-
+      IN-SKEY option (now section 2.9.2) which is used for user-to-user
+      authentication.  The new option and ticket flag transited policy
+      checking (section 2.7) was added.
+
+      A warning regarding generation of session keys for application use
+      was added to section 3, urging the inclusion of key entropy from
+      the KDC generated session key in the ticket. An example regarding
+      use of the sub-session key was added to section 3.2.6.
+      Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt
+      pre-authentication data items were added. The recommendation for
+      use of pre-authentication was changed from "may" to "should" and a
+      note was added regarding known plaintext attacks.
+
+      In RFC 1510, section 4 described the database in the KDC. This
+      discussion was not necessary for interoperability and
+      unnecessarily constrained implementation. The old section 4 was
+      removed.
+
+      The current section 4 was formerly section 6 on encryption and
+      checksum specifications. The major part of this section was
+
+
+
+February 2004                                                 [Page 134]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      brought up to date to support new encryption methods, and move to
+      a separate document. Those few remaining aspects of the encryption
+      and checksum specification specific to Kerberos are now specified
+      in section 4.
+
+      Significant changes were made to the layout of section 5 to
+      clarify the correct behavior for optional fields. Many of these
+      changes were made necessary because of improper ASN.1 description
+      in the original Kerberos specification which left the correct
+      behavior underspecified. Additionally, the wording in this section
+      was tightened wherever possible to ensure that implementations
+      conforming to this specification will be extensible with the
+      addition of new fields in future specifications.
+
+      Text was added describing time_t=0 issues in the ASN.1. Text was
+      also added, clarifying issues with implementations treating
+      omitted optional integers as zero. Text was added clarifying
+      behavior for optional SEQUENCE or SEQUENCE OF that may be empty.
+      Discussion was added regarding sequence numbers and behavior of
+      some implementations, including "zero" behavior and negative
+      numbers. A compatibility note was added regarding the
+      unconditional sending of EncTGSRepPart regardless of the enclosing
+      reply type. Minor changes were made to the description of the
+      HostAddresses type. Integer types were constrained. KerberosString
+      was defined as a (significantly) constrained GeneralString.
+      KerberosFlags was defined to reflect existing implementation
+      behavior that departs from the definition in RFC 1510. The
+      transited-policy-checked(12) and the ok-as-delegate(13) ticket
+      flags were added. The disable-transited-check(26) KDC option was
+      added.
+
+      Descriptions of commonly implemented PA-DATA were added to section
+      5. The description of KRB-SAFE has been updated to note the
+      existing implementation behavior of double-encoding.
+
+      There were two definitions of METHOD-DATA in RFC 1510. The second
+      one, intended for use with KRB_AP_ERR_METHOD was removed leaving
+      the SEQUENCE OF PA-DATA definition.
+
+      Section 7, naming constraints, from RFC1510 was moved to section
+      6.
+
+      Words were added describing the convention that domain based realm
+      names for newly created realms should be specified as upper case.
+      This recommendation does not make lower case realm names illegal.
+      Words were added highlighting that the slash separated components
+      in the X500 style of realm names is consistent with existing
+      RFC1510 based implementations, but that it conflicts with the
+
+
+
+February 2004                                                 [Page 135]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      general recommendation of X.500 name representation specified in
+      RFC2253.
+
+      Section 8, network transport, constants and defined values, from
+      RFC1510 was moved to section 7.  Since RFC1510, the definition of
+      the TCP transport for Kerberos messages was added, and the
+      encryption and checksum number assignments have been moved into a
+      separate document.
+
+      "Specification 2" in section 8 of the current document changes the
+      required encryption and checksum methods to bring them in line
+      with the best current practices and to deprecate methods that are
+      no longer considered sufficiently strong.
+
+      Two new sections, on IANA considerations and security
+      considerations were added.
+
+      The pseudo-code has been removed from the appendix. The pseudo-
+      code was sometimes misinterpreted to limit implementation choices
+      and in RFC 1510, it was not always consistent with the words in
+      the specification. Effort was made to clear up any ambiguities in
+      the specification, rather than to rely on the pseudo-code.
+
+      An appendix was added containing the complete ASN.1 module drawn
+      from the discussion in section 5 of the current document.
+
+END NOTES
+
+      [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
+
+
+
+February 2004                                                 [Page 136]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      arrange registration of a separately-named principal 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 tickets 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 session 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.  See [RFC1750]
+      for an in depth discussion of randomness.
+
+      [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] Note also 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.
+
+      [11] If this is not done, an attacker could subvert the
+
+
+
+February 2004                                                 [Page 137]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
+
+
+      authentication by recording the ticket and authenticator sent over
+      the network to a server and replaying them following an event that
+      caused the server to lose track of recently seen authenticators.
+
+      [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 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
+      configuration 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 authenticated.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+February 2004                                                 [Page 138]
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt
new file mode 100644
index 00000000000..a607843efbd
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt
@@ -0,0 +1,8039 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                          Clifford Neuman
+Obsoletes: 1510                                                 USC-ISI
+                                                                 Tom Yu
+                                                            Sam Hartman
+                                                            Ken Raeburn
+                                                                    MIT
+                                                          June 29, 2004
+                                              Expires 29 December, 2004
+
+            The Kerberos Network Authentication Service (V5)
+            draft-ietf-krb-wg-kerberos-clarifications-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-krb-wg-kerberos-clarifications-06.txt, and expires 29 December
+   2004.  Please send comments to: ietf-krb-wg@anl.gov
+
+ABSTRACT
+
+   This document provides an overview and specification of Version 5 of
+   the Kerberos protocol, and obsoletes 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.
+
+
+
+June 2004                                                       [Page 1]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+OVERVIEW
+
+   This document 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].
+
+   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.
+
+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 Ts'o, 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 [KNT94].
+
+   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.
+
+
+June 2004                                                       [Page 2]
+
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                           Table of Contents
+
+
+1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . .   8
+1.2. Choosing a principal with which to communicate  . . . . . . . .   9
+1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . .  10
+1.4. Extending Kerberos Without Breaking Interoperability  . . . . .  11
+1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . .  11
+1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . .  12
+1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . .  12
+1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . .  13
+2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . .  16
+2.1. Initial, pre-authenticated, and hardware authenticated
+      tickets  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
+2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . .  17
+2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . .  17
+2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . .  18
+2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . .  19
+2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . .  19
+2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . .  20
+2.8. OK as Delegate  . . . . . . . . . . . . . . . . . . . . . . . .  21
+2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . .  21
+2.9.1. Renewable-OK  . . . . . . . . . . . . . . . . . . . . . . . .  21
+2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . .  22
+2.9.3. Passwordless Hardware Authentication  . . . . . . . . . . . .  22
+3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . .  22
+3.1. The Authentication Service Exchange . . . . . . . . . . . . . .  22
+3.1.1. Generation of KRB_AS_REQ message  . . . . . . . . . . . . . .  24
+3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . .  24
+3.1.3. Generation of KRB_AS_REP message  . . . . . . . . . . . . . .  24
+3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . .  27
+3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . .  27
+3.1.6. Receipt of KRB_ERROR message  . . . . . . . . . . . . . . . .  28
+3.2. The Client/Server Authentication Exchange . . . . . . . . . . .  28
+3.2.1. The KRB_AP_REQ message  . . . . . . . . . . . . . . . . . . .  29
+3.2.2. Generation of a KRB_AP_REQ message  . . . . . . . . . . . . .  29
+3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . .  30
+3.2.4. Generation of a KRB_AP_REP message  . . . . . . . . . . . . .  32
+3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . .  33
+3.2.6. Using the encryption key  . . . . . . . . . . . . . . . . . .  33
+3.3. The Ticket-Granting Service (TGS) Exchange  . . . . . . . . . .  34
+3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . .  35
+3.3.2. Receipt of KRB_TGS_REQ message  . . . . . . . . . . . . . . .  37
+3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . .  38
+3.3.3.1. Checking for revoked tickets  . . . . . . . . . . . . . . .  40
+3.3.3.2. Encoding the transited field  . . . . . . . . . . . . . . .  40
+3.3.4. Receipt of KRB_TGS_REP message  . . . . . . . . . . . . . . .  42
+
+
+
+June 2004                                                       [Page 3]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . .  42
+3.4.1. Generation of a KRB_SAFE message  . . . . . . . . . . . . . .  42
+3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . .  43
+3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . .  44
+3.5.1. Generation of a KRB_PRIV message  . . . . . . . . . . . . . .  44
+3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . .  44
+3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . .  45
+3.6.1. Generation of a KRB_CRED message  . . . . . . . . . . . . . .  45
+3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . .  46
+3.7. User-to-User Authentication Exchanges . . . . . . . . . . . . .  47
+4. Encryption and Checksum Specifications  . . . . . . . . . . . . .  48
+5. Message Specifications  . . . . . . . . . . . . . . . . . . . . .  50
+5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . .  51
+5.1.1. ASN.1 Distinguished Encoding Rules  . . . . . . . . . . . . .  51
+5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . .  51
+5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . .  52
+5.1.4. Unrecognized Tag Numbers  . . . . . . . . . . . . . . . . . .  52
+5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . .  52
+5.2. Basic Kerberos Types  . . . . . . . . . . . . . . . . . . . . .  52
+5.2.1. KerberosString  . . . . . . . . . . . . . . . . . . . . . . .  53
+5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . .  54
+5.2.3. KerberosTime  . . . . . . . . . . . . . . . . . . . . . . . .  55
+5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . .  55
+5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . .  56
+5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . .  56
+5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . .  58
+5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . .  58
+5.2.6.3. AND-OR  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
+5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . .  59
+5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . .  60
+5.2.7.1. PA-TGS-REQ  . . . . . . . . . . . . . . . . . . . . . . . .  61
+5.2.7.2. Encrypted Timestamp Pre-authentication  . . . . . . . . . .  61
+5.2.7.3. PA-PW-SALT  . . . . . . . . . . . . . . . . . . . . . . . .  61
+5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . .  62
+5.2.7.5. PA-ETYPE-INFO2  . . . . . . . . . . . . . . . . . . . . . .  62
+5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . .  63
+5.2.9. Cryptosystem-related Types  . . . . . . . . . . . . . . . . .  64
+5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . .  66
+5.4. Specifications for the AS and TGS exchanges . . . . . . . . . .  73
+5.4.1. KRB_KDC_REQ definition  . . . . . . . . . . . . . . . . . . .  73
+5.4.2. KRB_KDC_REP definition  . . . . . . . . . . . . . . . . . . .  81
+5.5. Client/Server (CS) message specifications . . . . . . . . . . .  84
+5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . .  84
+5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . .  87
+5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . .  88
+5.6. KRB_SAFE message specification  . . . . . . . . . . . . . . . .  89
+5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . .  89
+5.7. KRB_PRIV message specification  . . . . . . . . . . . . . . . .  90
+
+
+
+June 2004                                                       [Page 4]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . .  91
+5.8. KRB_CRED message specification  . . . . . . . . . . . . . . . .  91
+5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . .  91
+5.9. Error message specification . . . . . . . . . . . . . . . . . .  94
+5.9.1. KRB_ERROR definition  . . . . . . . . . . . . . . . . . . . .  94
+5.10. Application Tag Numbers  . . . . . . . . . . . . . . . . . . .  96
+6. Naming Constraints  . . . . . . . . . . . . . . . . . . . . . . .  97
+6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . .  97
+6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . .  98
+6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 100
+7. Constants and other defined values  . . . . . . . . . . . . . . . 100
+7.1. Host address types  . . . . . . . . . . . . . . . . . . . . . . 100
+7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101
+7.2.1. UDP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 102
+7.2.2. TCP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 102
+7.2.3. KDC Discovery on IP Networks  . . . . . . . . . . . . . . . . 103
+7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names  . . . . 103
+7.2.3.2. Specifying KDC Location information with DNS SRV
+      records  . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
+7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
+      Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
+7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 105
+7.4. OID arc for KerberosV5  . . . . . . . . . . . . . . . . . . . . 105
+7.5. Protocol constants and associated values  . . . . . . . . . . . 105
+7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105
+7.5.2. PreAuthentication Data Types  . . . . . . . . . . . . . . . . 107
+7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 108
+7.5.4. Authorization Data Types  . . . . . . . . . . . . . . . . . . 108
+7.5.5. Transited Encoding Types  . . . . . . . . . . . . . . . . . . 108
+7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 108
+7.5.7. Kerberos Message Types  . . . . . . . . . . . . . . . . . . . 108
+7.5.8. Name Types  . . . . . . . . . . . . . . . . . . . . . . . . . 109
+7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 109
+8. Interoperability requirements . . . . . . . . . . . . . . . . . . 111
+8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 111
+8.2. Recommended KDC values  . . . . . . . . . . . . . . . . . . . . 114
+9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 114
+10. Security Considerations  . . . . . . . . . . . . . . . . . . . . 115
+11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
+12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 120
+13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
+13.1 NORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . . 120
+13.2 INFORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . 121
+14. Copyright Statement  . . . . . . . . . . . . . . . . . . . . . . 123
+15. Intellectual Property  . . . . . . . . . . . . . . . . . . . . . 123
+A. ASN.1 module  . . . . . . . . . . . . . . . . . . . . . . . . . . 124
+B. Changes since RFC-1510  . . . . . . . . . . . . . . . . . . . . . 132
+END NOTES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
+
+
+
+June 2004                                                       [Page 5]
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+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. Kerberos
+   performs authentication under these conditions as a trusted third-
+   party authentication service by using conventional (shared secret
+   key) cryptography.  Extensions to Kerberos (outside the scope of this
+   document) can provide for the use of public key cryptography during
+   certain phases of the authentication protocol [@RFCE: if PKINIT
+   advances concurrently include reference to the RFC here]. Such
+   extensions support Kerberos authentication for users registered with
+   public key certification authorities and 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 a "ticket" for the server and 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.  Note that many applications use Kerberos' functions
+   only upon the initiation of a stream-based network connection. Unless
+   an application performs encryption or 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.
+
+   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 calls to the
+   Kerberos library directly or through the Generic Security Services
+   Application Programming Interface, GSSAPI, described in separate
+   document [ref to GSSAPI RFC]. These calls result in the transmission
+   of the necessary messages to achieve authentication.
+
+
+
+June 2004                                                       [Page 6]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 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 sub-session 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
+
+
+
+June 2004                                                       [Page 7]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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. 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.
+
+   WIthout cross-realm operation, and with appropriate permission the
+   client can arrange registration of a separately-named principal 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.
+
+   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 may be 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
+
+
+
+June 2004                                                       [Page 8]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 KDCs
+   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 KDCs not check
+   the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
+   SHOULD honor this flag.
+
+1.2. Choosing a principal with which to communicate
+
+   The Kerberos protocol provides the means for verifying (subject to
+   the assumptions in 1.5) that the entity with which one communicates
+   is the same entity that was registered with the KDC using the claimed
+   identity (principal name). It is still necessary to determine whether
+   that identity corresponds to the entity with which one intends to
+   communicate.
+
+   When appropriate data has been exchanged in advance, this
+   determination may be performed syntactically by the application based
+   on the application protocol specification, information provided by
+   the user, and configuration files. For example, the server principal
+   name (including realm) for a telnet server might be derived from the
+   user specified host name (from the telnet command line), the "host/"
+   prefix specified in the application protocol specification, and a
+   mapping to a Kerberos realm derived syntactically from the domain
+   part of the specified hostname and information from the local
+   Kerberos realms database.
+
+   One can also rely on trusted third parties to make this
+   determination, but only when the data obtained from the third party
+   is suitably integrity protected while resident on the third party
+   server and when transmitted.  Thus, for example, one should not rely
+   on an unprotected domain name system record to map a host alias to
+   the primary name of a server, accepting the primary name as the party
+
+
+
+June 2004                                                       [Page 9]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   one intends to contact, since an attacker can modify the mapping and
+   impersonate the party with which one intended to communicate.
+
+   Implementations of Kerberos and protocols based on Kerberos MUST NOT
+   use insecure DNS queries to canonicalize the hostname components of
+   the service principal names (i.e. MUST NOT use insecure DNS queries
+   to map one name to another to determine the host part of the
+   principal name with which one is to communicate).  In an environment
+   without secure name service, application authors MAY append a
+   statically configured domain name to unqualified hostnames before
+   passing the name to the security mechanisms, but should do no more
+   than that.  Secure name service facilities, if available, might be
+   trusted for hostname canonicalization, but such canonicalization by
+   the client SHOULD NOT be required by KDC implementations.
+
+   Implementation note: Many current implementations do some degree of
+   canonicalization of the provided service name, often using DNS even
+   though it creates security problems. However there is no consistency
+   among implementations about whether the service name is case folded
+   to lower case or whether reverse resolution is used. To maximize
+   interoperability and security, applications SHOULD provide security
+   mechanisms with names which result from folding the user-entered name
+   to lower case, without performing any other modifications or
+   canonicalization.
+
+1.3. 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 utilize files on 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 ticket's authorization data when encapsulated by the
+   KDC-issued authorization data element.
+
+   Applications should not accept the mere issuance of a service ticket
+   by the Kerberos server (even by a modified Kerberos server) as
+
+
+
+June 2004                                                      [Page 10]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 are provided.
+
+1.4. Extending Kerberos Without Breaking Interoperability
+
+   As the deployed base of Kerberos implementations grows, extending
+   Kerberos becomes more important. Unfortunately some extensions to the
+   existing Kerberos protocol create interoperability issues because of
+   uncertainty regarding the treatment of certain extensibility options
+   by some implementations. This section includes guidelines that will
+   enable future implementations to maintain interoperability.
+
+   Kerberos provides a general mechanism for protocol extensibility.
+   Some protocol messages contain typed holes -- sub-messages that
+   contain an octet-string along with an integer that defines how to
+   interpret the octet-string. The integer types are registered
+   centrally, but can be used both for vendor extensions and for
+   extensions standardized through the IETF.
+
+   In this document, the word "extension" means an extension by defining
+   a new type to insert into an existing typed hole in a protocol
+   message.  It does not mean extension by addition of new fields to
+   ASN.1 types, unless explicitly indicated otherwise in the text.
+
+1.4.1. Compatibility with RFC 1510
+
+   It is important to note that existing Kerberos message formats can
+   not be readily extended by adding fields to the ASN.1 types. Sending
+   additional fields often results in the entire message being discarded
+   without an error indication. Future versions of this specification
+   will provide guidelines to ensure that ASN.1 fields can be added
+   without creating an interoperability problem.
+
+   In the meantime, all new or modified implementations of Kerberos that
+   receive an unknown message extension SHOULD preserve the encoding of
+   the extension but otherwise ignore the presence of the extension.
+   Recipients MUST NOT decline a request simply because an extension is
+   present.
+
+   There is one exception to this rule. If an unknown authorization data
+   element type is received by a server other than the ticket granting
+   service either in an AP-REQ or in a ticket contained in an AP-REQ,
+   then authentication MUST fail. One of the primary uses of
+   authorization data is to restrict the use of the ticket. If the
+   service cannot determine whether the restriction applies to that
+   service then a security weakness may result if the ticket can be used
+
+
+
+June 2004                                                      [Page 11]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   for that service. Authorization elements that are optional SHOULD be
+   enclosed in the AD-IF-RELEVANT element.
+
+   The ticket granting service MUST ignore but propagate to derivative
+   tickets any unknown authorization data types, unless those data types
+   are embedded in a MANDATORY-FOR-KDC element, in which case the
+   request will be rejected.  This behavior is appropriate because
+   requiring that the ticket granting service understand unknown
+   authorization data types would require that KDC software be upgraded
+   to understand new application-level restrictions before applications
+   used these restrictions, decreasing the utility of authorization data
+   as a mechanism for restricting the use of tickets. No security
+   problem is created because services to which the tickets are issued
+   will verify the authorization data.
+
+   Implementation note: Many RFC 1510 implementations ignore unknown
+   authorization data elements. Depending on these implementations to
+   honor authorization data restrictions may create a security weakness.
+
+1.4.2. Sending Extensible Messages
+
+   Care must be taken to ensure that old implementations can understand
+   messages sent to them even if they do not understand an extension
+   that is used. Unless the sender knows an extension is supported, the
+   extension cannot change the semantics of the core message or
+   previously defined extensions.
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence. The KDC should
+   only use the extension if this padata element is present in the AS-
+   REQ. Even if policy requires the use of the extension, it is better
+   to return an error indicating that the extension is required than to
+   use the extension when the recipient may not support it; debugging
+   why implementations do not interoperate is easier when errors are
+   returned.
+
+1.5. 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
+
+
+
+June 2004                                                      [Page 12]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      are places in the 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 not-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 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.6. 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
+
+
+
+June 2004                                                      [Page 13]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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.
+
+   Encryption Type (etype)
+      When associated with encrypted data, an encryption type identifies
+      the algorithm used to encrypt the data and is used to select the
+      appropriate algorithm for decrypting the data.  Encryption type
+      tags are communicated in other messages to enumerate algorithms
+      that are desired, supported, preferred, or allowed to be used for
+      encryption of data between parties.  This preference is combined
+      with local information and policy to select an algorithm to be
+      used.
+
+   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
+
+
+
+June 2004                                                      [Page 14]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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
+      The name given to the Project Athena's authentication service, the
+      protocol used by that service, or the code used to implement the
+      authentication service.  The name is adopted from the three-headed
+      dog which guards Hades.
+
+   Key Version Number (kvno)
+      A tag associated with encrypted data identifies which key was used
+      for encryption when a long lived key associated with a principal
+      changes over time.  It is used during the transition to a new key
+      so that the party decrypting a message can tell whether the data
+      was encrypted using the old or the new key.
+
+   Plaintext
+      The input to an encryption function or the output of a decryption
+      function. Decryption transforms ciphertext into plaintext.
+
+   Principal
+      A named client or server entity that participates in a network
+      communication, with one name that is considered canonical.
+
+   Principal identifier
+      The canonical 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 MAY be derived
+      from a password.
+
+   Server
+      A particular Principal which provides a resource to network
+      clients.  The server is sometimes referred to as the Application
+      Server.
+
+   Service
+      A resource provided to network clients; often provided by more
+      than one server (for example, remote file service).
+
+
+
+June 2004                                                      [Page 15]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   Session key
+      A temporary encryption key used between two principals, with a
+      lifetime limited to the duration of a single login "session".  In
+      the Kerberos system, a session key is generated by the KDC.  The
+      session key is distinct from the sub-session key, described next..
+
+   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. The sub-
+      session key is also referred to as the subkey.
+
+   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 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 give examples of reasons to
+   use them. With the exception of the INVALID flag clients MUST ignore
+   ticket flags that are not recognized. KDCs MUST ignore KDC options
+   that are not recognized. Some implementations of RFC 1510 are known
+   to reject unknown KDC options, so clients may need to resend a
+   request without new KDC options if the request was rejected when sent
+   with options added since RFC 1510. Since new KDCs will ignore unknown
+   options, clients MUST confirm that the ticket returned by the KDC
+   meets their needs.
+
+   Note that it is not, in general, possible to determine whether an
+   option was not honored because it was not understood or because it
+   was rejected either through configuration or policy. When adding a
+   new option to the Kerberos protocol, designers should consider
+   whether the distinction is important for their option. In cases where
+   it is, a mechanism for the KDC to return an indication that the
+   option was understood but rejected needs to be provided in the
+   specification of the option. Often in such cases, the mechanism needs
+   to be broad enough to permit an error or reason to be returned.
+
+2.1. Initial, pre-authenticated, and hardware authenticated tickets
+
+
+
+
+June 2004                                                      [Page 16]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   The INITIAL flag indicates that a ticket was issued using the AS
+   protocol, rather than 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 additional 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 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
+
+
+
+June 2004                                                      [Page 17]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 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
+
+
+
+June 2004                                                      [Page 18]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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, users wishing to delegate their identity
+   in a form usable for all 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 often valid from only those network addresses
+   specifically included in the ticket, but it is permissible as a
+   policy option to allow requests and issue tickets with no network
+   addresses specified.  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
+
+
+
+June 2004                                                      [Page 19]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   that is granted is 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.
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+2.7. Transited Policy Checking
+
+   In Kerberos, the application server is ultimately responsible for
+   accepting or rejecting authentication and SHOULD check that only
+   suitably trusted KDCs are relied upon to authenticate a principal.
+   The transited field in the ticket identifies which realms (and thus
+   which KDCs) were involved in the authentication process and an
+   application server would normally check this field. If any of these
+   are untrusted to authenticate the indicated client principal
+   (probably determined by a realm-based policy), the authentication
+   attempt MUST be rejected. The presence of trusted KDCs in this list
+   does not provide any guarantee; an untrusted KDC may have fabricated
+   the list.
+
+   While the end server ultimately decides whether authentication is
+   valid, the KDC for the end server's realm MAY apply a realm specific
+   policy for validating the transited field and accepting credentials
+
+
+
+June 2004                                                      [Page 20]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   for cross-realm authentication. When the KDC applies such checks and
+   accepts such cross-realm authentication it will set the TRANSITED-
+   POLICY-CHECKED flag in the service tickets it issues based on the
+   cross-realm TGT. A client MAY request that the KDCs not check the
+   transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are
+   encouraged but not required to honor this flag.
+
+   Application servers MUST either do the transited-realm checks
+   themselves, or reject cross-realm tickets without TRANSITED-POLICY-
+   CHECKED set.
+
+2.8. OK as Delegate
+
+   For some applications a client may need to delegate authority to a
+   server to act on its behalf in contacting other services.  This
+   requires that the client forward credentials to an intermediate
+   server.  The ability for a client to obtain a service ticket to a
+   server conveys no information to the client about whether the server
+   should be trusted to accept delegated credentials.  The OK-AS-
+   DELEGATE provides a way for a KDC to communicate local realm policy
+   to a client regarding whether an intermediate server is trusted to
+   accept such credentials.
+
+   The copy of the ticket flags in the encrypted part of the KDC reply
+   may have the OK-AS-DELEGATE flag set to indicates to the client that
+   the server 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.  It is acceptable 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.
+
+2.9. Other KDC options
+
+   There are three additional options which MAY be set in a client's
+   request of the KDC.
+
+2.9.1. Renewable-OK
+
+   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 requested endtime. The value of the renew-till field MAY still be
+   adjusted by site-determined limits or limits imposed by the
+
+
+
+June 2004                                                      [Page 21]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   individual principal or server.
+
+2.9.2. ENC-TKT-IN-SKEY
+
+   In its basic form the Kerberos protocol supports authentication in a
+   client-server
+    setting and is not well suited to authentication in a peer-to-peer
+   environment because the long term key of the user does not remain on
+   the workstation after initial login. Authentication of such peers may
+   be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-
+   SKEY option supports user-to-user authentication by allowing the KDC
+   to issue a service ticket encrypted using the session key from
+   another ticket-granting ticket issued to another user. 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 additional second ticket-
+   granting ticket provided with the request. See section 3.3.3 for
+   specific details.
+
+2.9.3. Passwordless Hardware Authentication
+
+   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
+   some form of hardware authentication instead of or in addition to the
+   client's password or other long-lived encryption key. OPT-HARDWARE-
+   AUTH is honored only by the authentication service. If supported and
+   allowed by policy, the KDC will return an errorcode
+   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
+   perform such authentication.
+
+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 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
+
+
+
+June 2004                                                      [Page 22]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 for which the request must not be honored unless the
+   requester can provide the users old password (preventing someone from
+   walking up to an unattended session and changing another user's
+   password).
+
+   This exchange does not by itself provide any assurance of the
+   identity of the user. 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.
+
+   The AS 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,
+   other information about the credentials it is requesting, and a
+   randomly generated nonce which can be used to detect replays, and to
+   associate replies with the matching requests. This nonce MUST be
+   generated randomly by the client and remembered for checking against
+   the nonce in the expected reply. 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 encrypted part of the KRB_AS_REP message also contains the nonce
+   which MUST be matched with the nonce from the KRB_AS_REQ message.
+
+   Without pre-authentication, 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. However,
+   an attacker can send a KRB_AS_REQ message to get known plaintext in
+   order to attack the principal's key. Especially if the key is based
+   on a password, this may create a security exposure. So, 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 SHOULD be used for pre-authentication as described in
+   sections 3.1.1 and 5.2.7.
+
+
+
+June 2004                                                      [Page 23]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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
+   contents of the KRB_ERROR message are not integrity-protected. As
+   such, the client cannot detect replays, fabrications or
+   modifications. A solution to this problem will be included in a
+   future version of the protocol.
+
+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).
+
+   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.
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+   successfully processed, the KDC MUST respond with a KRB_AS_REP
+   message rather than a replay error.  In order to reduce ciphertext
+   given to a potential attacker, KDCs MAY send the same response
+   generated when the request was first handled. KDCs MUST obey this
+   replay behavior even if the actual transport in use is reliable.
+
+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
+   known because it doesn't exist in the KDC's principal database, then
+   an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
+
+   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 pre-authentication is
+
+
+
+June 2004                                                      [Page 24]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   required, but was not present in the request, an error message with
+   the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA
+   object will be stored in the e-data field of the KRB-ERROR message to
+   specify which pre-authentication mechanisms are acceptable.  Usually
+   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
+   described below. If the server cannot accommodate any encryption type
+   requested by the client, an error message with code
+   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
+   'random' session key, meaning 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.  See [RFC1750] for an
+   in depth discussion of randomness.
+
+   When responding to an AS request, if there are multiple encryption
+   keys registered for a client in the Kerberos database, then the etype
+   field from the AS request is used by the KDC to select the encryption
+   method to be used to protect the encrypted part of the KRB_AS_REP
+   message which is sent to the client. If there is more than one
+   supported strong encryption type in the etype list, the KDC SHOULD
+   use the first valid strong etype for which an encryption key is
+   available.
+
+   When the user's key is generated from a password or pass phrase, the
+   string-to-key function for the particular encryption key type is
+   used, as specified in [@KCRYPTO]. The salt value and additional
+   parameters for the string-to-key function have default values
+   (specified by section 4 and by the encryption mechanism
+   specification, respectively) that may be overridden by pre-
+   authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
+   ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the
+   resulting key only, these values should not be changed for password-
+   based keys except when changing the principal's key.
+
+   When the AS server is to include pre-authentication data in a KRB-
+   ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
+   if the etype field of the client's AS-REQ lists at least one "newer"
+   encryption type.  Otherwise (when the etype field of the client's AS-
+   REQ does not list any "newer" encryption types) it MUST send both,
+   PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
+   enctype).  A "newer" enctype is any enctype first officially
+   specified concurrently with or subsequent to the issue of this RFC.
+   The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
+   "newer" enctypes.
+
+   It is not possible to reliably generate a user's key given a pass
+
+
+
+June 2004                                                      [Page 25]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   phrase without contacting the KDC, since it will not be known whether
+   alternate salt or parameter values are required.
+
+   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 earlier of the
+   requested endtime and a time determined by local policy, possibly
+   determined using realm or principal specific factors. For example,
+   the expiration time MAY be set to the earliest 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 from the authentication
+         server's database.
+
+      *  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
+
+
+
+June 2004                                                      [Page 26]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 MAY be set to the earliest 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 postdated (the start time is in the future), its
+   INVALID flag will also be set.
+
+   If all of the above succeed, the server will encrypt the ciphertext
+   part of the ticket using the encryption key extracted from the server
+   principal's record in the Kerberos database using the encryption type
+   associated with the server principal's key (this choice is NOT
+   affected by the etype field in the request). It then 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 an acceptable encryption
+   method requested in the etype field of the request, or in some key
+   specified by pre-authentication mechanisms being used.
+
+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
+
+
+
+June 2004                                                      [Page 27]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 last-
+   req field (and the deprecated key-expiration field) from the
+   encrypted part of the response MAY be checked to notify the user of
+   impending key expiration. This enables the client program to suggest
+   remedial action, such as a password change.
+
+   Upon validation of the KRB_AS_REP message (by checking the returned
+   nonce against that sent in the KRB_AS_REQ message) the client knows
+   that the current time on the KDC is that read from the authtime field
+   of the encrypted part of the reply. The client can optionally use
+   this value for clock synchronization in subsequent messages by
+   recording with the ticket the difference (offset) between the
+   authtime value and the local clock. This offset can then be used by
+   the same user to adjust the time read from the system clock when
+   generating messages [DGT96].
+
+   This technique MUST be used when adjusting for clock skew instead of
+   directly changing the system clock because the KDC reply is only
+   authenticated to the user whose secret key was used, but not to the
+   system or workstation. If the clock were adjusted, an attacker
+   colluding with a user logging into a workstation could agree on a
+   password, resulting in a KDC reply that would be correctly validated
+   even though it did not originate from a KDC trusted by the
+   workstation.
+
+   Proper decryption of the KRB_AS_REP message is not sufficient for the
+   host to verify the identity of the user; the user and an attacker
+   could cooperate to generate a KRB_AS_REP format message which
+   decrypts properly but is not from the proper KDC. If the host wishes
+   to verify the identity of the user, it MUST require the user to
+   present application credentials which can be verified using a
+   securely-stored secret key for the host. If those credentials can be
+   verified, then the identity of the user can be assured.
+
+3.1.6. Receipt of KRB_ERROR message
+
+   If the reply message type is KRB_ERROR, then the client interprets it
+   as an error and performs whatever application-specific tasks are
+   necessary to recover.
+
+3.2. The Client/Server Authentication Exchange
+
+                                Summary
+
+
+
+June 2004                                                      [Page 28]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 (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), 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 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 MUST NOT be re-
+   used and SHOULD be rejected if replayed to a server.  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.
+
+   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.
+
+
+
+
+June 2004                                                      [Page 29]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   The client MAY indicate a requirement of mutual authentication or the
+   use of a session-key based ticket (for user-to-user authentication -
+   see section 3.7) 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.
+
+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 user-to-user authentication is in use, and that the ticket is
+   encrypted in the session key from the server's ticket-granting ticket
+   rather than in the server's secret key. See section 3.7 for a more
+   complete description of the effect of user-to-user authentication on
+   all messages in the Kerberos protocol.
+
+   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), 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
+
+
+
+June 2004                                                      [Page 30]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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; this normally is caused by a client error or
+   attempted attack. 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.
+
+   Unless the application server provides its own suitable means to
+   protect against replay (for example, a challenge-response sequence
+   initiated by the server after authentication, or use of a server-
+   generated encryption subkey), the server MUST utilize a replay cache
+   to remember any authenticator presented within the allowable clock
+   skew. Careful analysis of the application protocol and implementation
+   is recommended before eliminating this cache. The replay cache will
+   store at least the server name, along with the client name, time and
+   microsecond fields from the recently-seen authenticators and if a
+   matching tuple is found, the KRB_AP_ERR_REPEAT error is returned.
+   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 have their
+   authenticators rejected if the time and microsecond fields happen to
+   match some other client's authenticator.
+
+   If a server loses track of authenticators presented within the
+   allowable clock skew, it MUST reject all requests until the clock
+   skew interval has passed, providing assurance that any lost or
+   replayed authenticators will fall outside the allowable clock skew
+   and can no longer be successfully replayed.  If this were not done,
+   an attacker could subvert the authentication by recording the ticket
+   and authenticator sent over the network to a server and replaying
+   them following an event that caused the server to lose track of
+   recently seen authenticators.
+
+   Implementation note: If a client generates multiple requests to the
+   KDC with the same timestamp, including the microsecond field, all but
+   the first of the requests received will be rejected as replays. This
+   might happen, for example, if the resolution of the client's clock is
+   too coarse.  Client implementations SHOULD ensure that the timestamps
+   are not reused, possibly by incrementing the microseconds field in
+   the time stamp when the clock returns the same time for multiple
+   requests.
+
+
+
+June 2004                                                      [Page 31]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   If multiple servers (for example, different services on one machine,
+   or a single service implemented on multiple machines) share a service
+   principal (a practice we do not recommend in general, but acknowledge
+   will be used in some cases), they MUST either share this replay
+   cache, or the application protocol MUST be designed so as to
+   eliminate the need for it. Note that this applies to all of the
+   services, if any of the application protocols does not have replay
+   protection built in; an authenticator used with such a service could
+   later be replayed to a different service with the same service
+   principal but no replay protection, if the former doesn't record the
+   authenticator information in the common replay cache.
+
+   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.
+
+   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 decision based upon
+   the authenticated name of the user, the requested operation, local
+   access 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
+
+
+
+June 2004                                                      [Page 32]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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). 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.
+
+   Note that 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.
+
+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 to decrypt the message
+   (Note that for encrypting the KRB_AP_REP message, the sub-session key
+   is not used, even if present in the Authenticator), 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.
+
+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.
+   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. The actual encryption key to be used for KRB_PRIV,
+   KRB_SAFE, or other application-specific uses MAY be chosen by the
+   application based on the session key from the ticket and subkeys in
+   the KRB_AP_REP message and the authenticator.  Implementations of the
+   protocol MAY 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.
+
+   To mitigate the effect of failures in random number generation on the
+   client it is strongly encouraged that any key derived by an
+   application for subsequent use include the full key entropy derived
+   from the KDC generated session key carried in the ticket. 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
+
+
+
+June 2004                                                      [Page 33]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   an example of how this might be done follows.
+
+   One way that an application may choose to negotiate a key to be used
+   for subsequent 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.
+
+   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
+
+
+
+June 2004                                                      [Page 34]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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. The same comments about
+   integrity protection of KRB_ERROR messages mentioned in section 3.1
+   apply to the TGS exchange.
+
+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 believed to
+   be registered. 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 configuration 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 authenticated.  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.
+
+   If the client knows 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 possesses 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 between the client's realm and the
+   requested realm server's realm). It should be noted in this case that
+   misconfiguration of the Kerberos servers may cause loops in the
+   resulting authentication path, which the client should be careful to
+
+
+
+June 2004                                                      [Page 35]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   detect and avoid.
+
+   If the Kerberos server returns a TGT for a 'closer' realm other than
+   the desired realm, the client MAY use local policy configuration to
+   verify that the authentication path used is an acceptable one.
+   Alternatively, a client MAY choose its own authentication path,
+   rather than relying on the Kerberos server to select one. In either
+   case, any policy or configuration information used to choose or
+   validate authentication paths, whether by the Kerberos server or
+   client, MUST be obtained from a trusted source.
+
+   When a client obtains a ticket-granting ticket that is 'closer' to
+   the destination realm, the client MAY cache this ticket and reuse it
+   in future KRB-TGS exchanges with services in the 'closer' realm.
+   However, if the client were to obtain a ticket-granting ticket for
+   the 'closer' realm by starting at the initial KDC rather than as part
+   of obtaining another ticket, then a shorter path to the 'closer'
+   realm might be used. This shorter path may be desirable because fewer
+   intermediate KDCs would know the session key of the ticket involved.
+   For this reason, clients SHOULD evaluate whether they trust the
+   realms transited in obtaining the 'closer' ticket when making a
+   decision to use the ticket in future.
+
+   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. One of these options is the ENC-TKT-IN-SKEY
+   option used for user-to-user authentication. An overview of user-to-
+   user authentication can be found in section 3.7. When generating the
+   KRB_TGS_REQ message, this option indicates that the client is
+   including a ticket-granting ticket obtained from the application
+   server in the additional tickets field of the request and that the
+   KDC SHOULD encrypt the ticket for the application server using the
+   session key from this additional ticket, instead of using a server
+   key from the principal database.
+
+   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-authorizatfion-data field for
+   application server use and additional tickets required by some
+   options.
+
+
+
+
+June 2004                                                      [Page 36]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   In preparing the authentication header, the client can select a sub-
+   session key under which the response from the Kerberos server will be
+   encrypted. 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.
+
+   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.
+
+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 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.
+
+   As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
+
+
+
+June 2004                                                      [Page 37]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   message if it receives a KRB_TGS_REQ message identical to one it has
+   recently processed. However, if the authenticator is a replay, but
+   the rest of the request is not identical, then the KDC SHOULD return
+   KRB_AP_ERR_REPEAT.
+
+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 or for a
+   ticket granting server of an intermediate KDC to be contacted to
+   obtain the requested ticket. The Kerberos database is queried to
+   retrieve the record for the appropriate 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 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
+
+
+
+June 2004                                                      [Page 38]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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, it indicates that the client
+   is using user- to-user authentication to prove its identity to a
+   server that does not have access to a persistent key. Section 3.7
+   describes the affect of this option on the entire Kerberos protocol.
+   When generating the KRB_TGS_REP message, this option in the
+   KRB_TGS_REQ message tells the KDC to 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.
+
+   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 requested, 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 section, the KDC will issue the
+   appropriate new ticket.
+
+
+
+June 2004                                                      [Page 39]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 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.
+
+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 to the KDC for the realm in which
+   the server resides. 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. If TGT's have
+   been issued for cross-realm authentication, use of the cross-realm
+   TGT will not be affected unless the hot-list is propagated to the
+   KDCs for the realms for which such cross-realm tickets were issued.
+
+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, if it is not the realm of the
+   client principal, 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
+
+
+
+June 2004                                                      [Page 40]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 preceding 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.  For the purpose of appending, the realm
+   preceding the first listed realm is considered to be the null realm
+   ("").  If a realm name beginning with a "/" 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 would not be included in this field, and we would have:
+
+      "/COM,/HP"
+
+   A null subfield preceding or following a "," indicates that all
+
+
+
+June 2004                                                      [Page 41]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   realms between the previous realm and the next realm have been
+   traversed.  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.  Thus, "," means
+   that all realms along the path between the client and the server have
+   been traversed. ",EDU, /COM," means 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 sub-session key from the Authenticator, if it
+   was specified in the request, or 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.
+
+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 occurred).
+
+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 the keyed
+   checksum mandated to be implemented along with the crypto system used
+   for the sub-session or session key. The checksum is generated using
+   the sub-session key if present or the session key. Some
+   implementations use a different checksum algorithm for the KRB_SAFE
+   messages but doing so in a interoperable manner is not always
+   possible.
+
+   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.
+
+
+
+
+June 2004                                                      [Page 42]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 that uses keys compatible with the
+   sub-session or session key as appropriate (or with the application
+   key derived from the session or sub-session keys), and if it is not,
+   a KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address
+   MUST be 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. To work with network address translation, senders MAY use
+   the directional address type specified in section 8.1 for the sender
+   address and not include recipient addresses. 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. Timestamps are not
+   required to be strictly ordered; they are only required to be in the
+   skew window.  If the server name, along with the client name, time
+   and microsecond fields from the Authenticator match any recently-seen
+   (sent or received) 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
+
+
+
+June 2004                                                      [Page 43]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 modified in transit.
+
+   Implementations SHOULD accept any checksum algorithm they implement
+   that both have adequate security and that have keys compatible with
+   the sub-session or session key. Unkeyed or non-collision-proof
+   checksums are not suitable for this use.
+
+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 occurred). 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.
+
+   The sender's address MUST be included in the control information; the
+
+
+
+June 2004                                                      [Page 44]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   recipient verifies that the operating system's report of the sender's
+   address matches the sender's address in the message.  If a recipient
+   address is specified or the recipient requires an address then one of
+   the recipient's addresses MUST also appear as the recipient's address
+   in the message.  Where a sender's or receiver's address might not
+   otherwise match the address in a message because of network address
+   translation, an application MAY be written to use addresses of the
+   directional address type in place of the actual network address.
+
+   A failed match for either case generates a KRB_AP_ERR_BADADDR error.
+   To work with network address translation, implementations MAY use the
+   directional address type defined in section 7.1 for the sender
+   address and include no recipient address.
+
+   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 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
+
+
+
+June 2004                                                      [Page 45]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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
+   previously exchanged in the KRB_AP exchange (usually the last key
+   negotiated via subkeys, or the session key if no negotiation has
+   occurred).
+
+   Implementation note: When constructing a KRB_CRED message for
+   inclusion in a GSSAPI initial context token, the MIT implementation
+   of Kerberos will not encrypt the KRB_CRED message if the session key
+   is a DES or triple DES key.  For interoperability with MIT, the
+   Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
+   token if it is using a DES session key. Starting at version 1.2.5,
+   MIT Kerberos can receive and decode either encrypted or unencrypted
+   KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of
+   Kerberos can also accept either encrypted or unencrypted KRB_CRED
+   messages. Since the KRB_CRED message in a GSSAPI token is encrypted
+   in the authenticator, the MIT behavior does not present a security
+   problem, although it is a violation of the Kerberos specification.
+
+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 MAY verify 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. The address check does not
+   provide any added security, since the address if present has already
+   been checked in the KRB_AP_REQ message and there is not any benefit
+   to be gained by an attacker in reflecting a KRB_CRED message back to
+   its originator. Thus, the recipient MAY ignore the address even if
+   present in order to work better in NAT environments. A failed match
+   for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY
+   skip the address check as the KRB_CRED message cannot generally be
+   reflected back to the originator.  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.
+
+
+
+
+June 2004                                                      [Page 46]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   If all the checks succeed, the application stores each of the new
+   tickets in its credentials cache together with the session key and
+   other information in the corresponding KrbCredInfo sequence from the
+   encrypted part of the KRB_CRED message.
+
+3.7. User-to-User Authentication Exchanges
+
+   User-to-User authentication provides a method to perform
+   authentication when the verifier does not have a access to long term
+   service key. This might be the case when running a server (for
+   example a window server) as a user on a workstation. In such cases,
+   the server may have access to the ticket-granting ticket obtained
+   when the user logged in to the workstation, but because the server is
+   running as an unprivileged user it might not have access to system
+   keys. Similar situations may arise when running peer-to-peer
+   applications.
+
+                             Summary
+       Message direction                    Message type     Sections
+       0. Message from application server   Not Specified
+       1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
+       2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
+                                            KRB_ERROR        5.9.1
+       3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
+
+   To address this problem, the Kerberos protocol allows the client to
+   request that the ticket issued by the KDC be encrypted using a
+   session key from a ticket-granting ticket issued to the party that
+   will verify the authentication.  This ticket-granting ticket must be
+   obtained from the verifier by means of an exchange external to the
+   Kerberos protocol, usually as part of the application protocol. This
+   message is shown in the summary above as message 0. Note that because
+   the ticket-granting ticket is encrypted in the KDC's secret key, it
+   can not be used for authentication without possession of the
+   corresponding secret key.  Furthermore, because the verifier does not
+   reveal the corresponding secret key, providing a copy of the
+   verifier's ticket-granting ticket does not allow impersonation of the
+   verifier.
+
+   Message 0 in the table above represents an application specific
+   negotiation between the client and server, at the end of which both
+   have determined that they will use user-to-user authentication and
+   the client has obtained the server's TGT.
+
+   Next, the client includes the server's TGT as an additional ticket in
+   its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
+   specifies the ENC-TKT-IN-SKEY option in its request.
+
+
+
+
+June 2004                                                      [Page 47]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   If validated according to the instructions in 3.3.3, the application
+   ticket returned to the client (message 2 in the table above) will be
+   encrypted using the session key from the additional ticket and the
+   client will note this when it uses or stores the application ticket.
+
+   When contacting the server using a ticket obtained for user-to-user
+   authentication (message 3 in the table above), the client MUST
+   specify the USE-SESSION-KEY flag in the ap-options field. This tells
+   the application server to use the session key associated with its
+   ticket-granting ticket to decrypt the server ticket provided in the
+   application request.
+
+4. Encryption and Checksum Specifications
+
+   The Kerberos protocols described in this document are designed to
+   encrypt messages of arbitrary sizes, using stream or block encryption
+   ciphers.  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.
+
+   [@KCRYPTO] defines a framework for defining encryption and checksum
+   mechanisms for use with Kerberos. It also defines several such
+   mechanisms, and more may be added in future updates to that document.
+
+   The string-to-key operation provided by [@KCRYPTO] is used to produce
+   a long-term key for a principal (generally for a user). The default
+   salt string, if none is provided via pre-authentication data, is the
+   concatenation of the principal's realm and name components, in order,
+   with no separators.  Unless otherwise indicated, the default string-
+   to-key opaque parameter set as defined in [@KCRYPTO] is used.
+
+   Encrypted data, keys and checksums are transmitted using the
+   EncryptedData, EncryptionKey and Checksum data objects defined in
+   section 5.2.9. The encryption, decryption, and checksum operations
+   described in this document use the corresponding encryption,
+
+
+
+June 2004                                                      [Page 48]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   decryption, and get_mic operations described in [@KCRYPTO], with
+   implicit "specific key" generation using the "key usage" values
+   specified in the description of each EncryptedData or Checksum object
+   to vary the key for each operation. Note that in some cases, the
+   value to be used is dependent on the method of choosing the key or
+   the context of the message.
+
+   Key usages are unsigned 32 bit integers; zero is not permitted. The
+   key usage values for encrypting or checksumming Kerberos messages are
+   indicated in section 5 along with the message definitions. Key usage
+   values 512-1023 are reserved for uses internal to a Kerberos
+   implementation. (For example, seeding a pseudo-random number
+   generator with a value produced by encrypting something with a
+   session key and a key usage value not used for any other purpose.)
+   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. Key usage values are
+   also summarized in a table in section 7.5.1.
+
+   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 specifications
+   continue to be meaningful until they are updated, if no key usage
+   values are specified then key usages 1024 and 1025 must be used to
+   derive keys for encryption and checksums, respectively (this does not
+   apply to protocols that do their own encryption independent of this
+   framework, directly using the key resulting from the Kerberos
+   authentication exchange.) New protocols defined in terms of the
+   Kerberos encryption and checksum types SHOULD use their own key usage
+   values.
+
+   Unless otherwise indicated, no cipher state chaining is done from one
+   encryption operation to another.
+
+   Implementation note: While not recommended, some application
+   protocols will continue to use the key data directly, even if only in
+   currently existing protocol specifications. An implementation
+   intended to support general Kerberos applications may therefore need
+   to make key data available, as well as the attributes and operations
+   described in [@KCRYPTO].  One of the more common reasons for directly
+   performing encryption is direct control over negotiation and
+   selection of a "sufficiently strong" encryption algorithm (in the
+   context of a given application). While Kerberos does not directly
+   provide a facility for negotiating encryption types between the
+   application client and server, there are approaches for using
+   Kerberos to facilitate this negotiation - for example, a client may
+   request only "sufficiently strong" session key types from the KDC and
+   expect that any type returned by the KDC will be understood and
+
+
+
+June 2004                                                      [Page 49]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   supported by the application server.
+
+5. Message Specifications
+
+   NOTE: The ASN.1 collected here should be identical to the contents of
+   Appendix A. In case of conflict, the contents of Appendix A shall
+   take precedence.
+
+   The Kerberos protocol is defined here in terms of Abstract Syntax
+   Notation One (ASN.1) [X680], which provides a syntax for specifying
+   both the abstract layout of protocol messages as well as their
+   encodings. Implementors not utilizing an existing ASN.1 compiler or
+   support library are cautioned to thoroughly understand the actual
+   ASN.1 specification to ensure correct implementation behavior, as
+   there is more complexity in the notation than is immediately obvious,
+   and some tutorials and guides to ASN.1 are misleading or erroneous.
+
+   Note that in several places, there have been changes here from RFC
+   1510 that change the abstract types. This is in part to address
+   widespread assumptions that various implementors have made, in some
+   cases resulting in unintentional violations of the ASN.1 standard.
+   These are clearly flagged where they occur. The differences between
+   the abstract types in RFC 1510 and abstract types in this document
+   can cause incompatible encodings to be emitted when certain encoding
+   rules, e.g. the Packed Encoding Rules (PER), are used. This
+   theoretical incompatibility should not be relevant for Kerberos,
+   since Kerberos explicitly specifies the use of the Distinguished
+   Encoding Rules (DER). It might be an issue for protocols wishing to
+   use Kerberos types with other encoding rules. (This practice is not
+   recommended.) With very few exceptions (most notably the usages of
+   BIT STRING), the encodings resulting from using the DER remain
+   identical between the types defined in RFC 1510 and the types defined
+   in this document.
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+   KerberosV5Spec2 {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) krb5spec2(2)
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   -- rest of definitions here
+
+   END
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+
+
+June 2004                                                      [Page 50]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   Note that in some other publications [RFC1510] [RFC1964], the "dod"
+   portion of the object identifier is erroneously specified as having
+   the value "5".  In the case of RFC 1964, use of the "correct" OID
+   value would result in a change in the wire protocol; therefore, it
+   remains unchanged for now.
+
+   Note that elsewhere in this document, nomenclature for various
+   message types is inconsistent, but largely follows C language
+   conventions, including use of underscore (_) characters and all-caps
+   spelling of names intended to be numeric constants. Also, in some
+   places, identifiers (especially ones referring to constants) are
+   written in all-caps in order to distinguish them from surrounding
+   explanatory text.
+
+   The ASN.1 notation does not permit underscores in identifiers, so in
+   actual ASN.1 definitions, underscores are replaced with hyphens (-).
+   Additionally, structure member names and defined values in ASN.1 MUST
+   begin with a lowercase letter, while type names MUST begin with an
+   uppercase letter.
+
+5.1. Specific Compatibility Notes on ASN.1
+
+   For compatibility purposes, implementors should heed the following
+   specific notes regarding the use of ASN.1 in Kerberos. These notes do
+   not describe deviations from standard usage of ASN.1. The purpose of
+   these notes is to instead describe some historical quirks and non-
+   compliance of various implementations, as well as historical
+   ambiguities, which, while being valid ASN.1, can lead to confusion
+   during implementation.
+
+5.1.1. ASN.1 Distinguished Encoding Rules
+
+   The encoding of Kerberos protocol messages shall obey the
+   Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
+   Some implementations (believed to be primarily ones derived from DCE
+   1.1 and earlier) are known to use the more general Basic Encoding
+   Rules (BER); in particular, these implementations send indefinite
+   encodings of lengths. Implementations MAY accept such encodings in
+   the interests of backwards compatibility, though implementors are
+   warned that decoding fully-general BER is fraught with peril.
+
+5.1.2. Optional Integer Fields
+
+   Some implementations do not internally distinguish between an omitted
+   optional integer value and a transmitted value of zero. The places in
+   the protocol where this is relevant include various microseconds
+   fields, nonces, and sequence numbers. Implementations SHOULD treat
+   omitted optional integer values as having been transmitted with a
+
+
+
+June 2004                                                      [Page 51]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   value of zero, if the application is expecting this.
+
+5.1.3. Empty SEQUENCE OF Types
+
+   There are places in the protocol where a message contains a SEQUENCE
+   OF type as an optional member. This can result in an encoding that
+   contains an empty SEQUENCE OF encoding. The Kerberos protocol does
+   not semantically distinguish between an absent optional SEQUENCE OF
+   type and a present optional but empty SEQUENCE OF type.
+   Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
+   marked OPTIONAL, but SHOULD accept them as being equivalent to an
+   omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
+   messages, instances of these problematic optional SEQUENCE OF types
+   are indicated with a comment.
+
+5.1.4. Unrecognized Tag Numbers
+
+   Future revisions to this protocol may include new message types with
+   different APPLICATION class tag numbers. Such revisions should
+   protect older implementations by only sending the message types to
+   parties that are known to understand them, e.g. by means of a flag
+   bit set by the receiver in a preceding request. In the interest of
+   robust error handling, implementations SHOULD gracefully handle
+   receiving a message with an unrecognized tag anyway, and return an
+   error message if appropriate.
+
+   In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
+   incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
+   respond to messages received with an unknown tag over UDP transport
+   in order to avoid denial of service attacks.  For non-KDC
+   applications, the Kerberos implementation typically indicates an
+   error to the application which takes appropriate steps based on the
+   application protocol.
+
+5.1.5. Tag Numbers Greater Than 30
+
+   A naive implementation of a DER ASN.1 decoder may experience problems
+   with ASN.1 tag numbers greater than 30, due to such tag numbers being
+   encoded using more than one byte. Future revisions of this protocol
+   may utilize tag numbers greater than 30, and implementations SHOULD
+   be prepared to gracefully return an error, if appropriate, if they do
+   not recognize the tag.
+
+5.2. Basic Kerberos Types
+
+   This section defines a number of basic types that are potentially
+   used in multiple Kerberos protocol messages.
+
+
+
+
+June 2004                                                      [Page 52]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+5.2.1. KerberosString
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO-2022/ECMA-35
+   [ISO-2022/ECMA-35] to switch character sets, and the default
+   character set that is designated as G0 is the ISO-646/ECMA-6
+   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
+   ASCII), which mostly works.
+
+   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1). DER prohibits the
+   designation of character sets as any but the G0 and C0 sets.
+   Unfortunately, this seems to have the side effect of prohibiting the
+   use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
+   character-sets that utilize a 96-character set, since it is
+   prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
+   element. This side effect is being investigated in the ASN.1
+   standards community.
+
+   In practice, many implementations treat GeneralStrings as if they
+   were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences. The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString. This failure to adhere to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   The new (post-RFC 1510) type KerberosString, defined below, is a
+   GeneralString that is constrained to only contain characters in
+   IA5String
+
+      KerberosString  ::= GeneralString (IA5String)
+
+   In general, US-ASCII control characters should not be used in
+   KerberosString. Control characters SHOULD NOT be used in principal
+   names or realm names.
+
+   For compatibility, implementations MAY choose to accept GeneralString
+
+
+
+June 2004                                                      [Page 53]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way. Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters. This is a violation of the ASN.1
+   standard. Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard. As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+   Future revisions to this protocol will almost certainly allow for a
+   more interoperable representation of principal names, probably
+   including UTF8String.
+
+   Note that applying a new constraint to a previously unconstrained
+   type constitutes creation of a new ASN.1 type. In this particular
+   case, the change does not result in a changed encoding under DER.
+
+5.2.2. Realm and PrincipalName
+
+   Realm           ::= KerberosString
+
+   PrincipalName   ::= SEQUENCE {
+           name-type       [0] Int32,
+           name-string     [1] SEQUENCE OF KerberosString
+   }
+
+   Kerberos realm names are encoded as KerberosStrings. Realms shall not
+   contain a character with the code 0 (the US-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
+
+
+
+June 2004                                                      [Page 54]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   specified in section 6.1.. 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 6.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).
+
+   name-string
+      This field encodes a sequence of components that form a name, each
+      component encoded as a KerberosString. Taken together, a
+      PrincipalName and a Realm form a principal identifier. Most
+      PrincipalNames will have only a few components (typically one or
+      two).
+
+5.2.3. KerberosTime
+
+   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes. A
+   KerberosTime value shall not include any fractional portions of the
+   seconds.  As required by the DER, it further shall not include any
+   separators, and it shall specify the UTC time zone (Z). Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is 19851106210627Z.
+
+5.2.4. Constrained Integer types
+
+   Some integer members of types SHOULD be constrained to values
+   representable in 32 bits, for compatibility with reasonable
+   implementation limits.
+
+   Int32           ::= INTEGER (-2147483648..2147483647)
+                       -- signed values representable in 32 bits
+
+   UInt32          ::= INTEGER (0..4294967295)
+                       -- unsigned 32 bit values
+
+   Microseconds    ::= INTEGER (0..999999)
+                       -- microseconds
+
+   While this results in changes to the abstract types from the RFC 1510
+   version, the encoding in DER should be unaltered. Historical
+   implementations were typically limited to 32-bit integer values
+   anyway, and assigned numbers SHOULD fall in the space of integer
+   values representable in 32 bits in order to promote interoperability
+
+
+
+June 2004                                                      [Page 55]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   anyway.
+
+   There are several integer fields in messages that are constrained to
+   fixed values.
+
+   pvno
+      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
+      the constant integer 5. There is no easy way to make this field
+      into a useful protocol version number, so its value is fixed.
+
+   msg-type
+      this integer field is usually identical to the application tag
+      number of the containing message type.
+
+5.2.5. HostAddress and HostAddresses
+
+   HostAddress     ::= SEQUENCE  {
+           addr-type       [0] Int32,
+           address         [1] OCTET STRING
+   }
+
+   -- NOTE: HostAddresses is always used as an OPTIONAL field and
+   -- should not be empty.
+   HostAddresses   -- NOTE: subtly different from rfc1510,
+                   -- but has a value mapping and encodes the same
+           ::= SEQUENCE OF HostAddress
+
+   The host address 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 7.5.3.
+
+   address
+      This field encodes a single address of type addr-type.
+
+5.2.6. AuthorizationData
+
+      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+      -- should not be empty.
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+              ad-type         [0] Int32,
+              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.
+
+
+
+June 2004                                                      [Page 56]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 referred 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.
+
+   These common authorization data elements are recursively 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.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator. Unless encapsulated in a known authorization
+   data element amending the criticality of the elements it contains, if
+   an unknown authorization data element type is received by a server
+   either in an AP-REQ or in a ticket contained in an AP-REQ, then
+   authentication MUST fail.  Authorization data is intended to restrict
+   the use of a ticket. If the service cannot determine whether the
+   restriction applies to that service then a security weakness may
+   result if the ticket can be used for that service. Authorization
+   elements that are optional can be enclosed in AD-IF-RELEVANT element.
+
+   In the definitions that follow, the value of the ad-type for the
+   element will be specified as the least significant part of the
+   subsection number, and the value of the ad-data will be as shown in
+   the ASN.1 structure that follows the subsection heading.
+
+             contents of ad-data          ad-type
+
+    DER encoding of AD-IF-RELEVANT        1
+
+    DER encoding of AD-KDCIssued          4
+
+    DER encoding of AD-AND-OR             5
+
+
+
+June 2004                                                      [Page 57]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+    DER encoding of AD-MANDATORY-FOR-KDC  8
+
+5.2.6.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.  The ad-type for AD-IF-RELEVANT is (1).
+
+5.2.6.2. KDCIssued
+
+   AD-KDCIssued            ::= SEQUENCE {
+           ad-checksum     [0] Checksum,
+           i-realm         [1] Realm OPTIONAL,
+           i-sname         [2] PrincipalName OPTIONAL,
+           elements        [3] AuthorizationData
+   }
+
+   ad-checksum
+      A cryptographic checksum computed over the DER encoding of the
+      AuthorizationData in the "elements" field, keyed with the session
+      key.  Its checksumtype is the mandatory checksum type for the
+      encryption type of the session key, and its key usage value is 19.
+
+   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 privileges 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
+
+
+
+June 2004                                                      [Page 58]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 MUST  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 encapsulates MAY be safely ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+5.2.6.3. AND-OR
+
+   AD-AND-OR               ::= SEQUENCE {
+           condition-count [0] INTEGER,
+           elements        [1] AuthorizationData
+   }
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisfied.  Therefore, 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.
+
+   The ad-type for AD-AND-OR is (5).
+
+5.2.6.4. MANDATORY-FOR-KDC
+
+   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+
+
+
+June 2004                                                      [Page 59]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   be interpreted by the KDC. KDCs that do not understand the type of an
+   element embedded within the mandatory-for-kdc element MUST reject the
+   request.
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+5.2.7. PA-DATA
+
+   Historically, PA-DATA have been known as "pre-authentication data",
+   meaning that they were used to augment the initial authentication
+   with the KDC.  Since that time, they have also been used as a typed
+   hole with which to extend protocol exchanges with the KDC.
+
+   PA-DATA         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           padata-type     [1] Int32,
+           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+   }
+
+   padata-type
+      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.
+
+   padata-value
+      Usually contains the DER encoding of another type; the padata-type
+      field identifies which type is encoded here.
+
+       padata-type        name           contents of padata-value
+
+       1            pa-tgs-req       DER encoding of AP-REQ
+
+       2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
+
+       3            pa-pw-salt       salt (not ASN.1 encoded)
+
+       11           pa-etype-info    DER encoding of ETYPE-INFO
+
+       19           pa-etype-info2   DER encoding of ETYPE-INFO2
+
+      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.
+
+      The padata field can also contain information needed to help the
+      KDC or the client select the key needed for generating or
+
+
+
+June 2004                                                      [Page 60]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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.
+
+5.2.7.1. PA-TGS-REQ
+
+   In the case of requests for additional tickets (KRB_TGS_REQ), padata-
+   value will contain an encoded AP-REQ. The checksum in the
+   authenticator (which MUST be collision-proof) is to be computed over
+   the KDC-REQ-BODY encoding.
+
+5.2.7.2. Encrypted Timestamp Pre-authentication
+
+   There are pre-authentication types that may be used to pre-
+   authenticate a client by means of an encrypted timestamp.
+
+   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+   PA-ENC-TS-ENC           ::= SEQUENCE {
+           patimestamp     [0] KerberosTime -- client's time --,
+           pausec          [1] Microseconds OPTIONAL
+   }
+
+   Patimestamp contains the client's time, and pausec contains 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 encoding, encrypted using the client's secret
+   key and a key usage value of 1.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations support it.
+
+5.2.7.3. PA-PW-SALT
+
+   The padata-value for this pre-authentication type contains the salt
+   for the string-to-key to be used by the client to obtain the key for
+   decrypting the encrypted part of an AS-REP message. Unfortunately,
+   for historical reasons, the character set to be used is unspecified
+   and probably locale-specific.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations support it. It is necessary in any case where the
+   salt for the string-to-key algorithm is not the default.
+
+   In the trivial example, a zero-length salt string is very commonplace
+   for realms that have converted their principal databases from
+   Kerberos 4.
+
+
+
+June 2004                                                      [Page 61]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
+   that requests additional pre-authentication. Implementation note:
+   some KDC implementations issue an erroneous PA-PW-SALT when issuing a
+   KRB-ERROR message that requests additional pre-authentication.
+   Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-
+   ERROR message that requests additional pre-authentication.  As noted
+   in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client's
+   AS-REQ includes at least one "newer" etype.
+
+5.2.7.4. PA-ETYPE-INFO
+
+   The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-
+   ERROR indicating a requirement for additional pre-authentication. It
+   is usually used to notify a client of which key to use for the
+   encryption of an encrypted timestamp for the purposes of sending a
+   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
+   AS-REP to provide information to the client about which key salt to
+   use for the string-to-key to be used by the client to obtain the key
+   for decrypting the encrypted part the AS-REP.
+
+   ETYPE-INFO-ENTRY        ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+   The salt, like that of PA-PW-SALT, is also completely unspecified
+   with respect to character set and is probably locale-specific.
+
+   If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-
+   INFO-ENTRY, and its etype shall match that of the enc-part in the AS-
+   REP.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations that support encrypted timestamps for pre-
+   authentication need to support ETYPE-INFO as well.  As noted in
+   section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
+   AS-REQ includes at least one "newer" etype.
+
+5.2.7.5. PA-ETYPE-INFO2
+
+   The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-
+   ERROR indicating a requirement for additional pre-authentication. It
+   is usually used to notify a client of which key to use for the
+   encryption of an encrypted timestamp for the purposes of sending a
+   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
+   AS-REP to provide information to the client about which key salt to
+
+
+
+June 2004                                                      [Page 62]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   use for the string-to-key to be used by the client to obtain the key
+   for decrypting the encrypted part the AS-REP.
+
+   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] KerberosString OPTIONAL,
+           s2kparams       [2] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
+
+   The type of the salt is KerberosString, but existing installations
+   might have locale-specific characters stored in salt strings, and
+   implementors MAY choose to handle them.
+
+   The interpretation of s2kparams is specified in the cryptosystem
+   description associated with the etype. Each cryptosystem has a
+   default interpretation of s2kparams that will hold if that element is
+   omitted from the encoding of ETYPE-INFO2-ENTRY.
+
+   If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
+   ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
+   the AS-REP.
+
+   The preferred ordering of the "hint" pre-authentication data that
+   affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO,
+   followed by PW-SALT.  As noted in section 3.1.3, a KDC MUST NOT send
+   ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one
+   "newer" etype.
+
+   The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
+
+5.2.8. KerberosFlags
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
+                       -- shall be sent, but no fewer than 32
+
+   Compatibility note: the following paragraphs describe a change from
+   the RFC1510 description of bit strings that would result in
+   incompatility in the case of an implementation that strictly
+   conformed to ASN.1 DER and RFC1510.
+
+   ASN.1 bit strings have multiple uses. The simplest use of a bit
+   string is to contain a vector of bits, with no particular meaning
+   attached to individual bits. This vector of bits is not necessarily a
+
+
+
+June 2004                                                      [Page 63]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   multiple of eight bits long.  The use in Kerberos of a bit string as
+   a compact boolean vector wherein each element has a distinct meaning
+   poses some problems. The natural notation for a compact boolean
+   vector is the ASN.1 "NamedBit" notation, and the DER require that
+   encodings of a bit string using "NamedBit" notation exclude any
+   trailing zero bits. This truncation is easy to neglect, especially
+   given C language implementations that naturally choose to store
+   boolean vectors as 32 bit integers.
+
+   For example, if the notation for KDCOptions were to include the
+   "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
+   encoded had only the "forwardable" (bit number one) bit set, the DER
+   encoding MUST include only two bits: the first reserved bit
+   ("reserved", bit number zero, value zero) and the one-valued bit (bit
+   number one) for "forwardable".
+
+   Most existing implementations of Kerberos unconditionally send 32
+   bits on the wire when encoding bit strings used as boolean vectors.
+   This behavior violates the ASN.1 syntax used for flag values in RFC
+   1510, but occurs on such a widely installed base that the protocol
+   description is being modified to accommodate it.
+
+   Consequently, this document removes the "NamedBit" notations for
+   individual bits, relegating them to comments. The size constraint on
+   the KerberosFlags type requires that at least 32 bits be encoded at
+   all times, though a lenient implementation MAY choose to accept fewer
+   than 32 bits and to treat the missing bits as set to zero.
+
+   Currently, no uses of KerberosFlags specify more than 32 bits worth
+   of flags, although future revisions of this document may do so. When
+   more than 32 bits are to be transmitted in a KerberosFlags value,
+   future revisions to this document will likely specify that the
+   smallest number of bits needed to encode the highest-numbered one-
+   valued bit should be sent. This is somewhat similar to the DER
+   encoding of a bit string that is declared with the "NamedBit"
+   notation.
+
+5.2.9. Cryptosystem-related Types
+
+   Many Kerberos protocol messages contain an EncryptedData as a
+   container for arbitrary encrypted data, which is often the encrypted
+   encoding of another data type. Fields within EncryptedData assist the
+   recipient in selecting a key with which to decrypt the enclosed data.
+
+   EncryptedData   ::= SEQUENCE {
+           etype   [0] Int32 -- EncryptionType --,
+           kvno    [1] UInt32 OPTIONAL,
+           cipher  [2] OCTET STRING -- ciphertext
+
+
+
+June 2004                                                      [Page 64]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   }
+
+   etype
+      This field identifies which encryption algorithm was used to
+      encipher the cipher.
+
+   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.  (Note that the encryption mechanisms defined in
+      [@KCRYPTO] MUST incorporate integrity protection as well, so no
+      additional checksum is required.)
+
+   The EncryptionKey type is the means by which cryptographic keys used
+   for encryption are transferred.
+
+   EncryptionKey   ::= SEQUENCE {
+           keytype         [0] Int32 -- actually encryption type --,
+           keyvalue        [1] OCTET STRING
+   }
+
+   keytype
+      This field specifies the encryption type of the encryption key
+      that follows in the keyvalue field. While its name is "keytype",
+      it actually specifies an encryption type. Previously, multiple
+      cryptosystems that performed encryption differently but were
+      capable of using keys with the same characteristics were permitted
+      to share an assigned number to designate the type of key; this
+      usage is now deprecated.
+
+   keyvalue
+      This field contains the key itself, encoded as an octet string.
+
+   Messages containing cleartext data to be authenticated will usually
+   do so by using a member of type Checksum. Most instances of Checksum
+   use a keyed hash, though exceptions will be noted.
+
+   Checksum        ::= SEQUENCE {
+           cksumtype       [0] Int32,
+           checksum        [1] OCTET STRING
+   }
+
+   cksumtype
+      This field indicates the algorithm used to generate the
+
+
+
+June 2004                                                      [Page 65]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      accompanying checksum.
+
+   checksum
+      This field contains the checksum itself, encoded as an octet
+      string.
+
+   See section 4 for a brief description of the use of encryption and
+   checksums in Kerberos.
+
+5.3. Tickets
+
+   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. 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 (5),
+           realm           [1] Realm,
+           sname           [2] PrincipalName,
+           enc-part        [3] EncryptedData -- EncTicketPart
+   }
+
+   -- 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] Int32 -- must be registered --,
+           contents        [1] OCTET STRING
+   }
+
+   TicketFlags     ::= KerberosFlags
+           -- reserved(0),
+           -- forwardable(1),
+
+
+
+June 2004                                                      [Page 66]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           -- forwarded(2),
+           -- proxiable(3),
+           -- proxy(4),
+           -- may-postdate(5),
+           -- postdated(6),
+           -- invalid(7),
+           -- renewable(8),
+           -- initial(9),
+           -- pre-authent(10),
+           -- hw-authent(11),
+   -- the following are new since 1510
+           -- transited-policy-checked(12),
+           -- ok-as-delegate(13)
+
+   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.  It is encrypted in the key shared by Kerberos and the
+      end server (the server's secret key), using a key usage value of
+      2.
+
+   flags
+      This field indicates which of various options were used or
+      requested when the ticket was issued. The meanings of the flags
+      are:
+
+         Bit(s)  Name                   Description
+
+         0       reserved               Reserved for future expansion of this
+                                        field.
+
+                                        The FORWARDABLE flag is normally only
+                                        interpreted by the TGS, and can be
+                                        ignored by end servers. When set, this
+
+
+
+June 2004                                                      [Page 67]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+         1       forwardable            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.
+
+                                        When set, this flag indicates that the
+                                        ticket has either been forwarded or
+         2       forwarded              was issued based on authentication
+                                        involving a forwarded ticket-granting
+                                        ticket.
+
+                                        The PROXIABLE flag is normally only
+                                        interpreted by the TGS, and can be
+                                        ignored by end servers. The PROXIABLE
+                                        flag has an interpretation identical
+         3       proxiable              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.
+
+                                        The MAY-POSTDATE flag is normally only
+                                        interpreted by the TGS, and can be
+         5       may-postdate           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.
+
+                                        This flag indicates that this ticket
+                                        has been postdated. The end-service
+         6       postdated              can check the authtime field to see
+                                        when the original authentication
+                                        occurred.
+
+                                        This flag indicates that a ticket is
+                                        invalid, and it must be validated by
+         7       invalid                the KDC before use. Application
+                                        servers must reject tickets which have
+                                        this flag set.
+
+                                        The RENEWABLE flag is normally only
+                                        interpreted by the TGS, and can
+                                        usually be ignored by end servers
+
+
+
+June 2004                                                      [Page 68]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+         8       renewable              (some particularly careful servers MAY
+                                        disallow renewable tickets). A
+                                        renewable ticket can be used to obtain
+                                        a replacement ticket that expires at a
+                                        later date.
+
+                                        This flag indicates that this ticket
+         9       initial                was issued using the AS protocol, and
+                                        not issued based on a ticket-granting
+                                        ticket.
+
+                                        This flag indicates that during
+                                        initial authentication, the client was
+                                        authenticated by the KDC before a
+         10      pre-authent            ticket was issued. The strength of the
+                                        pre-authentication method is not
+                                        indicated, but is acceptable to the
+                                        KDC.
+
+                                        This flag indicates that the protocol
+                                        employed for initial authentication
+                                        required the use of hardware expected
+         11      hw-authent             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.
+
+                                        This flag indicates that the KDC for
+                                        the 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
+         12      transited-             is set (1) then the application server
+                 policy-checked         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.
+
+                                        This flag is new since RFC 1510.
+
+                                        This flag indicates that the server
+                                        (not the client) specified in the
+
+
+
+June 2004                                                      [Page 69]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                                        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
+         13      ok-as-delegate         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.
+
+                                        This flag is new since RFC 1510.
+
+         14-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.
+
+   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 in
+      the transited field (as specified for some extensions 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
+
+
+
+June 2004                                                      [Page 70]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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.  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.
+
+
+   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 the starttime field is absent from the ticket, then
+      the authtime field SHOULD be used in its place to determine the
+      life of the ticket.
+
+   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 addressless tickets is a policy decision and
+      is left to the Kerberos and end-service administrators; they MAY
+      refuse to issue or accept such tickets. Because of the wide
+      deployment of network address translation, it is recommended that
+      policy allow the issue and acceptance of such tickets.
+
+      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
+
+
+
+June 2004                                                      [Page 71]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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 possession 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
+      encapsulation 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 privileges 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.6.  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
+
+
+
+June 2004                                                      [Page 72]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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 privilege 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 5.2.6.2).
+
+      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.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 application tag number of its own.
+   Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
+   which each have an application tag, 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 KDC to request credentials for
+   a service.
+
+   The message fields are:
+
+   AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+
+
+
+June 2004                                                      [Page 73]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   KDC-REQ         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           pvno            [1] INTEGER (5) ,
+           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                               -- NOTE: not empty --,
+           req-body        [4] KDC-REQ-BODY
+   }
+
+   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,
+           rtime                   [6] KerberosTime OPTIONAL,
+           nonce                   [7] UInt32,
+           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                       -- in preference order --,
+           addresses               [9] HostAddresses OPTIONAL,
+           enc-authorization-data  [10] EncryptedData OPTIONAL
+                                       -- AuthorizationData --,
+           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                           -- NOTE: not empty
+   }
+
+   KDCOptions      ::= KerberosFlags
+           -- reserved(0),
+           -- forwardable(1),
+           -- forwarded(2),
+           -- proxiable(3),
+           -- proxy(4),
+           -- allow-postdate(5),
+           -- postdated(6),
+           -- unused7(7),
+           -- renewable(8),
+           -- unused9(9),
+           -- unused10(10),
+           -- opt-hardware-auth(11),
+           -- unused12(12),
+           -- unused13(13),
+   -- 15 is reserved for canonicalize
+           -- unused15(15),
+   -- 26 was unused in 1510
+
+
+
+June 2004                                                      [Page 74]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           -- disable-transited-check(26),
+   --
+           -- renewable-ok(27),
+           -- enc-tkt-in-skey(28),
+           -- renew(30),
+           -- validate(31)
+
+   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
+      Contains pre-authentication data. Requests for additional tickets
+      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
+
+      The padata (pre-authentication data) field contains a sequence of
+      authentication information which may be needed before credentials
+      can be issued or decrypted.
+
+   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
+
+
+
+June 2004                                                      [Page 75]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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:
+
+         Bits    Name                     Description
+
+         0       RESERVED                 Reserved for future expansion of
+                                          this field.
+
+                                          The FORWARDABLE option indicates
+                                          that the ticket to be issued is to
+                                          have its forwardable flag set. It
+         1       FORWARDABLE              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
+                                          forwardable.
+
+                                          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
+         2       FORWARDED                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.
+
+                                          The PROXIABLE option indicates that
+                                          the ticket to be issued is to have
+                                          its proxiable flag set. It may only
+         3       PROXIABLE                be set on the initial request, or in
+                                          a subsequent request if the
+                                          ticket-granting ticket on which it
+                                          is based is also proxiable.
+
+                                          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
+         4       PROXY                    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.
+
+
+
+
+June 2004                                                      [Page 76]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                                          The ALLOW-POSTDATE option indicates
+                                          that the ticket to be issued is to
+                                          have its MAY-POSTDATE flag set. It
+         5       ALLOW-POSTDATE           may only be set on the initial
+                                          request, or in a subsequent request
+                                          if the ticket-granting ticket on
+                                          which it is based also has its
+                                          MAY-POSTDATE flag set.
+
+                                          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
+         6       POSTDATED                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       RESERVED                 This option is presently unused.
+
+                                          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
+         8       RENEWABLE                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      RESERVED                 Reserved for future use.
+
+         11      RESERVED                 Reserved for opt-hardware-auth.
+
+         12-25   RESERVED                 Reserved for future use.
+
+                                          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
+
+
+
+June 2004                                                      [Page 77]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                                          on the ticket-granting ticket. If
+                                          this flag is set in the request,
+                                          checking of the transited field is
+                                          disabled. Tickets issued without the
+         26      DISABLE-TRANSITED-CHECK  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. KDCs are
+                                          encouraged but not required to honor
+                                          the DISABLE-TRANSITED-CHECK option.
+
+                                          This flag is new since RFC 1510
+
+                                          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,
+         27      RENEWABLE-OK             then a renewable ticket may be
+                                          issued with a renew-till equal to
+                                          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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The
+                                          ENC-TKT-IN-SKEY option indicates
+         28      ENC-TKT-IN-SKEY          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.
+
+                                          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
+         30      RENEW                    valid. This option will only be
+                                          honored if the ticket to be renewed
+                                          has its RENEWABLE flag set and if
+
+
+
+June 2004                                                      [Page 78]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                                          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.
+
+                                          This option is used only by the
+                                          ticket-granting service. The
+                                          VALIDATE option indicates that the
+                                          request is to validate a postdated
+                                          ticket. It will only be honored if
+                                          the ticket presented is postdated,
+                                          presently has its INVALID flag set,
+         31      VALIDATE                 and would be otherwise usable at
+                                          this time. A ticket cannot be
+                                          validated 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. The 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 the Authenticator and ticket-granting
+      ticket come from the padata field in the KRB_TGS_REQ). The key
+      usage value used when encrypting is 5 if a sub-session key is
+      used, or 4 if the session key is used.
+
+   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.
+
+
+
+
+June 2004                                                      [Page 79]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   till
+      This field contains the expiration date requested by the client in
+      a ticket request. It is not optional, but if the requested endtime
+      is "19700101000000Z", the requested ticket is to have the maximum
+      endtime permitted according to KDC policy. Implementation note:
+      This special timestamp corresponds to a UNIX time_t value of zero
+      on most systems.
+
+   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 is 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 reused.
+
+   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
+      the ENC-TKT-IN-SKEY option is used for user-to-user
+      authentication, this additional 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 tag number will be either ten (10) or twelve (12)
+   depending on whether the request is for an initial ticket (AS-REQ) or
+
+
+
+June 2004                                                      [Page 80]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 (5),
+           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                   -- NOTE: not empty --,
+           crealm          [3] Realm,
+           cname           [4] PrincipalName,
+           ticket          [5] Ticket,
+           enc-part        [6] EncryptedData
+                                   -- EncASRepPart or EncTGSRepPart,
+                                   -- as appropriate
+   }
+
+   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+
+
+
+June 2004                                                      [Page 81]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   EncKDCRepPart   ::= SEQUENCE {
+           key             [0] EncryptionKey,
+           last-req        [1] LastReq,
+           nonce           [2] UInt32,
+           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
+   }
+
+   LastReq         ::=     SEQUENCE OF SEQUENCE {
+           lr-type         [0] Int32,
+           lr-value        [1] KerberosTime
+   }
+
+   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 "salt" string to be
+      used with a string-to-key algorithm. 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
+      salt 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.
+
+   ticket
+      The newly-issued ticket, from section 5.3.
+
+   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 key usage value for encrypting this field is 3 in an AS-REP
+      message, using the client's long-term key or another key selected
+
+
+
+June 2004                                                      [Page 82]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      via pre-authentication mechanisms. In a TGS-REP message, the key
+      usage value is 8 if the TGS session key is used, or 9 if a TGS
+      authenticator subkey is used.
+
+      Compatibility note: Some implementations unconditionally send an
+      encrypted EncTGSRepPart (application tag number 26) in this field
+      regardless of whether the reply is a AS-REP or a TGS-REP. In the
+      interests of compatibility, implementors MAY relax the check on
+      the tag number of the decrypted ENC-PART.
+
+   key
+      This field is the same as described for the ticket in section 5.3.
+
+   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.
+
+      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.  If
+         it is (7), then the lr-value subfield is the time when the
+         account 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
+
+
+
+June 2004                                                      [Page 83]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+         lr-type subfield.
+
+   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. If present, it SHOULD be set to the earliest of the
+      user's key expiration and account expiration.  The use of this
+      field is deprecated and the last-req field SHOULD be used to
+      convey this information instead.  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), 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 (5),
+           msg-type        [1] INTEGER (14),
+           ap-options      [2] APOptions,
+           ticket          [3] Ticket,
+
+
+
+June 2004                                                      [Page 84]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           authenticator   [4] EncryptedData -- Authenticator
+   }
+
+   APOptions       ::= KerberosFlags
+           -- 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.
+
+                                 The USE-SESSION-KEY option indicates that the
+                                 ticket the client is presenting to a server
+         1       use-session-key is encrypted in the session key from the
+                                 server's ticket-granting ticket. When this
+                                 option is not specified, the ticket is
+                                 encrypted in the server's secret key.
+
+                                 The MUTUAL-REQUIRED option tells the server
+         2       mutual-required 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 encrypted authenticator, which includes the
+      client's choice of a subkey.
+
+   The encrypted authenticator is included in the AP-REQ; it certifies
+   to a server that the sender has recent knowledge of the encryption
+   key in the accompanying ticket, to help the server detect replays. It
+
+
+
+June 2004                                                      [Page 85]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   also assists in the selection of a "true session key" to use with the
+   particular session.  The DER encoding of the following is encrypted
+   in the ticket's session key, with a key usage value of 11 in normal
+   application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
+   of a TGS-REQ exchange (see section 5.4.1):
+
+   -- Unencrypted authenticator
+   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+           authenticator-vno       [0] INTEGER (5),
+           crealm                  [1] Realm,
+           cname                   [2] PrincipalName,
+           cksum                   [3] Checksum OPTIONAL,
+           cusec                   [4] Microseconds,
+           ctime                   [5] KerberosTime,
+           subkey                  [6] EncryptionKey OPTIONAL,
+           seq-number              [7] UInt32 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.
+
+   cksum
+      This field contains a checksum of the application data that
+      accompanies the KRB_AP_REQ, computed using a key usage value of 10
+      in normal application exchanges, or 6 when used in the TGS-REQ PA-
+      TGS-REQ AP-DATA field.
+
+   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.
+
+
+
+
+June 2004                                                      [Page 86]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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.  In the event that more than 2^32 messages are to be
+      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
+      SHOULD be performed before sequence numbers are reused with the
+      same encryption key.
+
+      Implmentation note: historically, some implementations transmit
+      signed twos-complement numbers for sequence numbers. In the
+      interests of compatibility, implementations MAY accept the
+      equivalent negative number where a positive number greater than
+      2^31 - 1 is expected.
+
+      Implementation note: as noted before, some implementations omit
+      the optional sequence number when its value would be zero.
+      Implementations MAY accept an omitted sequence number when
+      expecting a value of zero, and SHOULD NOT transmit an
+      Authenticator with a initial sequence number of zero.
+
+   authorization-data
+      This field is the same as described for the ticket in section 5.3.
+      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.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
+   response to an application request (KRB_AP_REQ) where the mutual
+   authentication option has been selected in the ap-options field.
+
+
+
+June 2004                                                      [Page 87]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   AP-REP          ::= [APPLICATION 15] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (15),
+           enc-part        [2] EncryptedData -- EncAPRepPart
+   }
+
+   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+           ctime           [0] KerberosTime,
+           cusec           [1] Microseconds,
+           subkey          [2] EncryptionKey OPTIONAL,
+           seq-number      [3] UInt32 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. It is computed
+      with a key usage value of 12.
+
+   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.
+
+   seq-number
+      This field is described above in section 5.3.2.
+
+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
+
+
+
+June 2004                                                      [Page 88]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 occurred. The message fields
+   are:
+
+   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (20),
+           safe-body       [2] KRB-SAFE-BODY,
+           cksum           [3] Checksum
+   }
+
+   KRB-SAFE-BODY   ::= SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress,
+           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, computed
+      with a key usage value of 15.
+
+      The checksum is computed over the encoding of the KRB-SAFE
+
+
+
+June 2004                                                      [Page 89]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      sequence.  First, the cksum is set to a type zero, zero-length
+      value 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.
+      This method, while different than the one specified in RFC 1510,
+      corresponds to existing practice.
+
+   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
+      Sender's address.
+
+      This field specifies the address in use by the sender of the
+      message.
+
+   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).
+
+
+
+
+June 2004                                                      [Page 90]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+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 (5),
+           msg-type        [1] INTEGER (21),
+                           -- NOTE: there is no [2] tag
+           enc-part        [3] EncryptedData -- EncKrbPrivPart
+   }
+
+   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress -- 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, with a key usage value of 13.
+      This encrypted encoding is used for the enc-part field of the KRB-
+      PRIV message.
+
+   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
+
+
+
+
+June 2004                                                      [Page 91]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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 (5),
+           msg-type        [1] INTEGER (22),
+           tickets         [2] SEQUENCE OF Ticket,
+           enc-part        [3] EncryptedData -- EncKrbCredPart
+   }
+
+   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+           ticket-info     [0] SEQUENCE OF KrbCredInfo,
+           nonce           [1] UInt32 OPTIONAL,
+           timestamp       [2] KerberosTime OPTIONAL,
+           usec            [3] Microseconds 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
+
+
+
+June 2004                                                      [Page 92]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      encrypted under the session key shared between the sender and the
+      intended recipient, with a key usage value of 14. This encrypted
+      encoding is used for the enc-part field of the KRB-CRED message.
+
+      Implementation note: implementations of certain applications, most
+      notably certain implementations of the Kerberos GSS-API mechanism,
+      do not separately encrypt the contents of the EncKrbCredPart of
+      the KRB-CRED message when sending it.  In the case of those GSS-
+      API mechanisms, this is not a security vulnerability, as the
+      entire KRB-CRED message is itself embedded in an encrypted
+      message.
+
+   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 reused.
+
+   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 5.2.9.
+
+   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 corresponding fields from
+      the ticket found in the ticket field. Descriptions of the fields
+      are identical to the descriptions in the KDC-REP message.
+
+
+
+June 2004                                                      [Page 93]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+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 not integrity protected, it
+   is quite possible for an intruder to synthesize or modify such a
+   message. In particular, this means that 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 (5),
+           msg-type        [1] INTEGER (30),
+           ctime           [2] KerberosTime OPTIONAL,
+           cusec           [3] Microseconds OPTIONAL,
+           stime           [4] KerberosTime,
+           susec           [5] Microseconds,
+           error-code      [6] Int32,
+           crealm          [7] Realm OPTIONAL,
+           cname           [8] PrincipalName OPTIONAL,
+           realm           [9] Realm -- service realm --,
+           sname           [10] PrincipalName -- service name --,
+           e-text          [11] KerberosString OPTIONAL,
+           e-data          [12] OCTET STRING OPTIONAL
+   }
+
+   pvno and msg-type
+      These fields are described above in section 5.4.1. msg-type is
+      KRB_ERROR.
+
+   ctime, cusec
+      These fields are described above in section 5.5.2.  If the values
+      for these fields are known to the entity generating the error
+      (such as it would if the KRB-ERROR is generated in reply to, e.g.,
+      a failed authentication service request), they should be populated
+      in the KRB-ERROR.  If the values are not available, these fields
+
+
+
+June 2004                                                      [Page 94]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      can be omitted.
+
+   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 7.5.9. Implementations are
+      encouraged to provide for national language support in the display
+      of error messages.
+
+   crealm, and cname
+      These fields are described above in section 5.3.  When the entity
+      generating the error knows these values, they should be populated
+      in the KRB-ERROR.  If the values are not known, the crealm and
+      cname fields SHOULD be omitted.
+
+   realm and sname
+      These fields are described above in section 5.3.
+
+   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 the
+      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
+      contain an encoding of a sequence of padata fields, each
+      corresponding to an acceptable pre-authentication method and
+      optionally containing data for the method:
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+   For error codes defined in this document other than
+   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
+   are implementation-defined. Similarly, for future error codes, the
+   format and contents of the e-data field are implementation-defined
+   unless specified. Whether defined by the implementation or in a
+
+
+
+June 2004                                                      [Page 95]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   future document, the e-data field MAY take the form of TYPED-DATA:
+
+   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+           data-type       [0] INTEGER,
+           data-value      [1] OCTET STRING OPTIONAL
+   }
+
+5.10. Application Tag Numbers
+
+   The following table lists the application class tag numbers used by
+   various data types defined in this section.
+
+    Tag Number(s)    Type Name    Comments
+
+    0                             unused
+
+    1              Ticket         PDU
+
+    2              Authenticator  non-PDU
+
+    3              EncTicketPart  non-PDU
+
+    4-9                           unused
+
+    10             AS-REQ         PDU
+
+    11             AS-REP         PDU
+
+    12             TGS-REQ        PDU
+
+    13             TGS-REP        PDU
+
+    14             AP-REQ         PDU
+
+    15             AP-REP         PDU
+
+    16             RESERVED16     TGT-REQ (for user-to-user)
+
+    17             RESERVED17     TGT-REP (for user-to-user)
+
+    18-19                         unused
+
+    20             KRB-SAFE       PDU
+
+    21             KRB-PRIV       PDU
+
+    22             KRB-CRED       PDU
+
+
+
+
+June 2004                                                      [Page 96]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+    23-24                         unused
+
+    25             EncASRepPart   non-PDU
+
+    26             EncTGSRepPart  non-PDU
+
+    27             EncApRepPart   non-PDU
+
+    28             EncKrbPrivPart non-PDU
+
+    29             EncKrbCredPart non-PDU
+
+    30             KRB-ERROR      PDU
+
+   The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are
+   the only ASN.1 types intended as top-level types of the Kerberos
+   protocol, and are the only types that may be used as elements in
+   another protocol that makes use of Kerberos.
+
+6. Naming Constraints
+
+6.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
+   three styles of realm names: domain, X500, and other. Examples of
+   each style follow:
+
+        domain:   ATHENA.MIT.EDU
+          X500:   C=US/O=OSF
+         other:   NAMETYPE:rest/of.name=without-restrictions
+
+   Domain style realm 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
+
+
+
+June 2004                                                      [Page 97]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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. Note that the
+   slash separator is consistent with Kerberos implementations based on
+   RFC1510, but it is different from the separator recommended in
+   RFC2253.
+
+   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 expect those
+   beginning with 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 exist a name identical to the
+   realm name of the child unless it is assigned to the same entity as
+   the realm name.
+
+6.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 only as a hint to interpreting the meaning of a name. It is
+   not significant when checking for equivalence. Principal names that
+
+
+
+June 2004                                                      [Page 98]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   differ only in the name-type identify the same principal. The name
+   type does not partition the name space. 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
+
+   name types
+
+   NT-UNKNOWN        0  Name type not known
+   NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
+   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 host as remaining components
+   NT-UID            5  Unique ID
+   NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
+   NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
+   NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
+
+   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 the first component of a name identifies a service and there is a
+   single component following the service name identifying the instance
+   as 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 certificate 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.
+
+
+
+June 2004                                                      [Page 99]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   A name type of SMTP allows a name to be of a form that resembles a
+   SMTP email name. This name, including an "@" and a domain name, is
+   used as the one component of the principal name.
+
+   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 7.3 for the
+   form of such names.
+
+6.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.
+
+7. Constants and other defined values
+
+7.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.
+
+   Internet (IPv4) Addresses
+
+      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
+      in MSB order. The IPv4 loopback address SHOULD NOT appear in a
+      Kerberos packet. The type of IPv4 addresses is two (2).
+
+   Internet (IPv6) Addresses
+
+      IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
+      encoded in MSB order. The type of IPv6 addresses is twenty-four
+
+
+
+June 2004                                                     [Page 100]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      (24). The following addresses MUST NOT appear in any Kerberos
+      packet:
+
+         *  the Unspecified Address
+         *  the Loopback Address
+         *  Link-Local addresses
+
+      IPv4-mapped IPv6 addresses MUST be represented as addresses of
+      type 2.
+
+   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 alphanumeric characters and padded with the US-ASCII SPC
+      character (code 32).  The 16th octet MUST be the US-ASCII NUL
+      character (code 0).  The type of Netbios addresses is twenty (20).
+
+   Directional Addresses
+
+      In many environments, including the sender address in KRB_SAFE and
+      KRB_PRIV messages is undesirable because the addresses may be
+      changed in transport by network address translators. However, if
+      these addresses are removed, the messages may be subject to a
+      reflection attack in which a message is reflected back to its
+      originator. The directional address type provides a way to avoid
+      transport addresses and reflection attacks. Directional addresses
+      are encoded as four byte unsigned integers in network byte order.
+      If the message is originated by the party sending the original
+      KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
+      message is originated by the party to whom that KRB_AP_REQ was
+      sent, then the address 1 SHOULD be used. Applications involving
+      multiple parties can specify the use of other addresses.
+
+      Directional addresses MUST only be used for the sender address
+      field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
+      as a ticket address or in a KRB_AP_REQ message. This address type
+      SHOULD only be used in situations where the sending party knows
+      that the receiving party supports the address type. This generally
+      means that directional addresses may only be used when the
+      application protocol requires their support. Directional addresses
+      are type (3).
+
+7.2. KDC messaging - IP Transports
+
+
+
+June 2004                                                     [Page 101]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   Kerberos defines two IP transport mechanisms for communication
+   between clients and servers: UDP/IP and TCP/IP.
+
+7.2.1. UDP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify
+   the IP address and port to which they will send their request.
+
+   When contacting a 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 the KDC. 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. The response to a request made through UDP/IP transport MUST
+   also use UDP/IP transport. If the response can not be handled using
+   UDP (for example because it is too large), the KDC MUST return
+   KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request
+   using the TCP transport.
+
+7.2.2. TCP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   initially try a request using the UDP transport. Clients SHOULD use
+   KDC discovery [7.2.3] to identify the IP address and port to which
+   they will send their request.
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
+   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
+   the client on the same TCP stream that was established for the
+   request. The KDC MAY close the TCP stream after sending a response,
+
+
+
+June 2004                                                     [Page 102]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   but MAY leave the stream open for a reasonable period of time if it
+   expects a followup. Care must be taken in managing TCP/IP connections
+   on the KDC to prevent denial of service attacks based on the number
+   of open TCP/IP connections.
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   anytime after the receipt of a response. A stream closure SHOULD NOT
+   be treated as a fatal error. Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication) the client may
+   need to establish a new connection when it is ready to send
+   subsequent messages. A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   followup messages.
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
+   sent over the TCP stream is preceded by the length of the request as
+   4 octets in network byte order. The high bit of the length is
+   reserved for future expansion and MUST currently be set to zero.  If
+   a KDC that does not understand how to interpret a set high bit of the
+   length encoding receives a request with the high order bit of the
+   length set, it MUST return a KRB-ERROR message with the error
+   KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
+
+   If multiple requests are sent over a single TCP connection, and the
+   KDC sends multiple responses, the KDC is not required to send the
+   responses in the order of the corresponding requests. This may permit
+   some implementations to send each response as soon as it is ready
+   even if earlier requests are still being processed (for example,
+   waiting for a response from an external device or database).
+
+7.2.3. KDC Discovery on IP Networks
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored 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 using cross-realm authentication. This section
+   describes a method for using the Domain Name System [RFC 1035] for
+   storing KDC location information.
+
+7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
+
+
+
+
+June 2004                                                     [Page 103]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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
+   insensitive for queries. Since the realm names "MYREALM", "myrealm",
+   and "MyRealm" are all different, but resolve the same in the domain
+   name system, it is necessary that only one of the possible
+   combinations of upper and lower case characters be used in realm
+   names.
+
+7.2.3.2. Specifying KDC Location information with DNS SRV records
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2782].  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 one of "udp", "tcp". If these SRV records are to be
+   used, both "udp" and "tcp" records MUST be specified for all KDC
+   deployments.
+
+   The Realm is the Kerberos realm that this record corresponds to.  The
+   realm MUST be a domain style realm name.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2782.
+
+   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal) unless the KDC is configured
+   to listen on an alternate TCP port.
+
+   Implementation note: Many existing client implementations do not
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority. Weights are not used in these sample records.
+
+     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+
+
+
+June 2004                                                     [Page 104]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+
+7.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).
+
+7.4. OID arc for KerberosV5
+
+   This OID MAY be used to identify Kerberos protocol messages
+   encapsulated in other protocols. It also designates the OID arc for
+   KerberosV5-related OIDs assigned by future IETF action.
+   Implementation note:: RFC 1510 had an incorrect value (5) for "dod"
+   in its OID.
+
+   id-krb5         OBJECT IDENTIFIER ::= {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2)
+   }
+
+
+   Assignment of OIDs beneath the id-krb5 arc must be obtained by
+   contacting the registrar for the id-krb5 arc, or its designee.  At
+   the time of the issuance of this RFC, such registrations can be
+   obtained by contacting krb5-oid-registrar@mit.edu.
+
+7.5. Protocol constants and associated values
+
+   The following tables list constants used in the protocol and define
+   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.
+
+7.5.1. Key usage numbers
+
+
+
+
+June 2004                                                     [Page 105]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   The encryption and checksum specifications in [@KCRYPTO] require as
+   input a "key usage number", to alter the encryption key used in any
+   specific message, to make certain types of cryptographic attack more
+   difficult. These are the key usage values assigned in this document:
+
+           1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
+                       with the client key (section 5.2.7.2)
+           2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
+                       key or application session key), encrypted with the
+                       service key (section 5.3)
+           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.5.1)
+           7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
+                       (includes TGS authenticator subkey), encrypted with the
+                       TGS session key (section 5.5.1)
+           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.5.1)
+           11.         AP-REQ Authenticator (includes application
+                       authenticator subkey), encrypted with the application
+                       session key (section 5.5.1)
+           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.8.1)
+           15.         KRB-SAFE cksum, keyed with a key chosen by the
+                       application (section 5.6.1)
+           19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
+         22-25.        Reserved for use in GSSAPI mechanisms derived from RFC
+                       1964. (raeburn/MIT)
+    16-18,20-21,26-511. Reserved for future use in Kerberos and related
+                       protocols.
+        512-1023.      Reserved for uses internal to a Kerberos
+
+
+
+June 2004                                                     [Page 106]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                       implementation.
+         1024.         Encryption for application use in protocols that
+                       do not specify key usage values
+         1025.         Checksums for application use in protocols that
+                       do not specify key usage values
+       1026-2047.      Reserved for application use.
+
+
+7.5.2. PreAuthentication Data Types
+
+   padata and data types           padata-type value  comment
+
+   PA-TGS-REQ                      1
+   PA-ENC-TIMESTAMP                2
+   PA-PW-SALT                      3
+   [reserved]                      4
+   PA-ENC-UNIX-TIME                5        (deprecated)
+   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-ETYPE-INFO2                  19       (replaces pa-etype-info)
+   PA-USE-SPECIFIED-KVNO           20
+   PA-SAM-REDIRECT                 21       (sam/otp)
+   PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
+   TD-PADATA                       22       (embeds padata)
+   PA-SAM-ETYPE-INFO               23       (sam/otp)
+   PA-ALT-PRINC                    24       (crawdad@fnal.gov)
+   PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
+   PA-SAM-RESPONSE2                31       (kenh@pobox.com)
+   PA-EXTRA-TGT                    41       Reserved extra TGT
+   TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
+   TD-KRB-PRINCIPAL                102      PrincipalName
+   TD-KRB-REALM                    103      Realm
+   TD-TRUSTED-CERTIFIERS           104      from PKINIT
+   TD-CERTIFICATE-INDEX            105      from PKINIT
+   TD-APP-DEFINED-ERROR            106      application specific
+   TD-REQ-NONCE                    107      INTEGER
+   TD-REQ-SEQ                      108      INTEGER
+   PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
+
+7.5.3. Address Types
+
+
+
+June 2004                                                     [Page 107]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   Address type                   value
+
+   IPv4                             2
+   Directional                      3
+   ChaosNet                         5
+   XNS                              6
+   ISO                              7
+   DECNET Phase IV                 12
+   AppleTalk DDP                   16
+   NetBios                         20
+   IPv6                            24
+
+7.5.4. Authorization Data Types
+
+   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-AND-OR                          5
+   AD-MANDATORY-TICKET-EXTENSIONS     6
+   AD-IN-TICKET-EXTENSIONS            7
+   AD-MANDATORY-FOR-KDC               8
+   reserved values                    9-63
+   OSF-DCE                            64
+   SESAME                             65
+   AD-OSF-DCE-PKI-CERTID              66     (hemsath@us.ibm.com)
+   AD-WIN2K-PAC                      128     (jbrezak@exchange.microsoft.com)
+
+7.5.5. Transited Encoding Types
+
+   transited encoding type         tr-type value
+   DOMAIN-X500-COMPRESS            1
+   reserved values                 all others
+
+7.5.6. Protocol Version Number
+
+   Label               Value   Meaning or MIT code
+
+   pvno                    5   current Kerberos protocol version number
+
+7.5.7. Kerberos Message Types
+
+   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
+
+
+
+June 2004                                                     [Page 108]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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_RESERVED16      16   Reserved for user-to-user krb_tgt_request
+   KRB_RESERVED17      17   Reserved for user-to-user krb_tgt_reply
+   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
+
+7.5.8. Name Types
+
+   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]
+   KRB_NT_SMTP_NAME   7  Name in form of SMTP email name (e.g. user@foo.com)
+   KRB_NT_ENTERPRISE 10   Enterprise name - may be mapped to principal name
+
+7.5.9. Error Codes
+
+   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
+
+
+
+June 2004                                                     [Page 109]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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
+   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 Reserved for PKINIT
+   KDC_ERROR_KDC_NOT_TRUSTED       63 Reserved for PKINIT
+   KDC_ERROR_INVALID_SIG           64 Reserved for PKINIT
+   KDC_ERR_KEY_TOO_WEAK            65 Reserved for PKINIT
+   KDC_ERR_CERTIFICATE_MISMATCH    66 Reserved for PKINIT
+   KRB_AP_ERR_NO_TGT               67 No TGT available to validate USER-TO-USER
+   KDC_ERR_WRONG_REALM             68 USER-TO-USER TGT issued different KDC
+   KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
+   KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
+   KDC_ERR_INVALID_CERTIFICATE             71 Reserved for PKINIT
+   KDC_ERR_REVOKED_CERTIFICATE             72 Reserved for PKINIT
+   KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
+   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
+
+
+
+June 2004                                                     [Page 110]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
+   KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
+
+8. 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.
+
+8.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.2). Specification 1
+   (deprecated) may be found in RFC1510.
+
+   Transport
+
+      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
+      claiming conformance to specification 2.
+
+   Encryption and checksum methods
+
+      The following encryption and checksum mechanisms MUST be
+      supported.
+
+      Encryption: AES256-CTS-HMAC-SHA1-96
+      Checksums: HMAC-SHA1-96-AES256
+
+      Implementations SHOULD support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them. The mechanisms that SHOULD
+      be supported are:
+
+      Encryption:  DES-CBC-MD5, DES3-CBC-SHA1-KD
+      Checksums:   DES-MD5, HMAC-SHA1-DES3-KD
+
+
+
+
+June 2004                                                     [Page 111]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      Implementations MAY support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them.
+
+      Implementation note: earlier implementations of Kerberos generate
+      messages using the CRC-32, RSA-MD5 checksum methods. For
+      interoperability with these earlier releases implementors MAY
+      consider supporting these checksum methods but should carefully
+      analyze the security impplications to limit the situations within
+      which these methods are accepted.
+
+   Realm Names
+
+      All implementations MUST understand hierarchical realms in both
+      the Internet Domain and the X.500 style. When a ticket-granting
+      ticket for an unknown realm is requested, the KDC MUST be able to
+      determine the names of the intermediate realms between the KDCs
+      realm and the requested realm.
+
+   Transited field encoding
+
+      DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
+      supported.  Alternative encodings MAY be supported, but they may
+      be used only when that encoding is supported by ALL intermediate
+      realms.
+
+   Pre-authentication methods
+
+      The TGS-REQ method MUST be supported. The TGS-REQ method is not
+      used on the initial request. The PA-ENC-TIMESTAMP method MUST be
+      supported by clients but whether it is enabled by default MAY be
+      determined on a realm by realm basis. If not used in the initial
+      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
+      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
+      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
+      authentication 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.
+
+      The ETYPE-INFO2 method MUST be supported; this method is used to
+      communicate the set of supported encryption types, and
+      corresponding salt and string to key paramters. The ETYPE-INFO
+      method SHOULD be supported for interoperability with older
+      implementation.
+
+   Mutual authentication
+
+      Mutual authentication (via the KRB_AP_REP message) MUST be
+
+
+
+June 2004                                                     [Page 112]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      supported.
+
+   Ticket addresses and flags
+
+      All KDCs MUST pass through tickets that carry no addresses (i.e.
+      if a TGT contains no addresses, the KDC will return derivative
+      tickets).  Implementations SHOULD default to requesting
+      addressless tickets as this significantly increases
+      interoperability with network address translation.  In some cases
+      realms or application servers MAY require that tickets have an
+      address.
+
+      Implementations SHOULD accept directional address type for the
+      KRB_SAFE and KRB_PRIV message and SHOULD include directional
+      addresses in these messages when other address types are not
+      available.
+
+      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.
+
+
+
+June 2004                                                     [Page 113]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   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.
+
+8.2. Recommended KDC values
+
+   Following is a list of recommended values for a KDC configuration.
+
+   minimum lifetime              5 minutes
+   maximum renewable lifetime    1 week
+   maximum ticket lifetime       1 day
+   acceptable clock skew         5 minutes
+   empty addresses               Allowed.
+   proxiable, etc.               Allowed.
+
+9. IANA considerations
+
+   Section 7 of this document specifies protocol constants and other
+   defined values required for the interoperability of multiple
+   implementations. Until otherwise specified in a subsequent RFC, or
+   upon disbanding of the Kerberos working group, allocations of
+   additional protocol constants and other defined values required for
+   extensions to the Kerberos protocol will be administered by the
+   kerberos working group.  Following the recomendations outlined in
+   [RFC 2434], guidance is provided to the IANA as follows:
+
+   "reserved" realm name types in section 6.1 and "other" realm types
+   except those beginning with "X-" or "x-" will not be registered
+   without IETF standards action, at which point guidlines for further
+   assignment will be specified.  Realm name types beginning with "X-"
+   or "x-" are for private use.
+
+   For host address types described in section 7.1, negative values are
+   for private use.  Assignment of additional positive numbers is
+   subject to review by the kerberos working group or other expert
+   review.
+
+   Additional key usage numbers as defined in section 7.5.1 will be
+   assigned subject to review by the kerberos working group or other
+   expert review.
+
+   Additional preauthentciation data type values as defined in section
+   7.5.2 will be assigned subject to review by the kerberos working
+
+
+
+June 2004                                                     [Page 114]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   group or other expert review.
+
+   Additional Authorization Data Types as defined in section 7.5.4 will
+   be assigned subject to review by the kerberos working group or other
+   expert review.  Although it is anticipated that there may be
+   significant demand for private use types, provision is intentionaly
+   not made for a private use portion of the namespace because conficts
+   between privately assigned values coule have detrimental security
+   implications.
+
+   Additional Transited Encoding Types as defined in section 7.5.5
+   present special concerns for interoperability with existing
+   implementations.  As such, such assignments will only be made by
+   standards action, except that the Kerberos working group or another
+   other working group with competent jurisdiction may make preliminary
+   assignments for documents which are moving through the standards
+   process.
+
+   Additional Kerberos Message Types as described in section 7.5.7 will
+   be assigned subject to review by the kerberos working group or other
+   expert review.
+
+   Additional Name Types as described in section 7.5.8 will be assigned
+   subject to review by the kerberos working group or other expert
+   review.
+
+   Additional error codes described in section 7.5.9 will be assigned
+   subject to review by the kerberos working group or other expert
+   review.
+
+10. Security Considerations
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network. Kerberos does not, by
+   itself, provide authorization. Applications should not accept the
+   issuance of a service ticket by the 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 inter-operate with other KDCs or where other
+   options for application authentication are provided.
+
+   Denial of service attacks are not solved with Kerberos. There are
+   places in the protocols where an intruder can prevent an application
+   from participating in the proper authentication steps. Because
+   authentication is a required step for the use of many services,
+   successful denial of service attacks on a Kerberos server might
+   result in the denial of other network services that rely on Kerberos
+   for authentication. Kerberos is vulnerable to many kinds of denial of
+
+
+
+June 2004                                                     [Page 115]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   service attacks: denial of service attacks on the network which would
+   prevent clients from contacting the KDC; denial of service attacks on
+   the domain name system which could prevent a client from finding the
+   IP address of the Kerberos server; and denial of service attack by
+   overloading the Kerberos KDC itself with repeated requests.
+
+   Interoperability conflicts caused by incompatible character-set usage
+   (see 5.2.1) can result in denial of service for clients that utilize
+   character-sets in Kerberos strings other than those stored in the KDC
+   database.
+
+   Authentication servers maintain a database of principals (i.e., users
+   and servers) and their secret keys. The security of the
+   authentication server machines is critical. The breach of security of
+   an authentication server will compromise the security of all servers
+   that rely upon the compromised KDC, and will compromise the
+   authentication of any principals registered in the realm of the
+   compromised KDC.
+
+   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 off-line 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.
+
+   Unless pre-authentication options are required by the policy of a
+   realm, the KDC will not know whether a request for authentication
+   succeeds. An attacker can request a reply with credentials for any
+   principal. These credentials will likely not be of much use to the
+   attacker unless it knows the client's secret key, but the
+   availability of the response encrypted in the client's secret key
+   provides the attacker with ciphertext that may be used to mount brute
+   force or dictionary attacks to decrypt the credentials, by guessing
+   the user's password. For this reason it is strongly encouraged that
+   Kerberos realms require the use of pre-authentication. Even with pre-
+   authentication, attackers may try brute force or dictionary attacks
+   against credentials that are observed by eavesdropping on the
+   network.
+
+   Because a client can request a ticket for any server principal and
+   can attempt a brute force or dictionary attack against the server
+   principal's key using that ticket, it is strongly encouraged that
+   keys be randomly generated (rather than generated from passwords) for
+
+
+
+June 2004                                                     [Page 116]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   any principals that are usable as the target principal for a
+   KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750]
+
+   Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
+   methods are listed as SHOULD be implemented for backward
+   compatibility, the single DES encryption algorithm on which these are
+   based is weak and stronger algorithms should be used whenever
+   possible.
+
+   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 must 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 reusing principal identifiers, the danger of
+   inadvertent access is removed.
+
+   Proper decryption of an KRB_AS_REP message from the KDC is not
+   sufficient for the host 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. 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.
+
+   Many RFC 1510 compliant implementations ignore unknown authorization
+   data elements. Depending on these implementations to honor
+   authorization data restrictions may create a security weakness.
+
+   Kerberos credentials contain clear-text information identifying the
+   principals to which they apply. If privacy of this information is
+   needed, this exchange should itself be encapsulated in a protocol
+   providing for confidentiality on the exchange of these credentials.
+
+   Applications must take care to protect communications subsequent to
+   authentication either by using the KRB_PRIV or KRB_SAFE messages as
+   appropriate, or by applying their own confidentiality or integrity
+   mechanisms on such communications. Completion of the KRB_AP_REQ and
+
+
+
+June 2004                                                     [Page 117]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   KRB_AP_REP exchange without subsequent use of confidentiality and
+   integrity mechanisms provides only for authentication of the parties
+   to the communication and not confidentiality and integrity of the
+   subsequent communication. Application applying confidentiality and
+   integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must
+   make sure that the authentication step is appropriately linked with
+   the protected communication channel that is established by the
+   application.
+
+   Unless the application server provides its own suitable means to
+   protect against replay (for example, a challenge-response sequence
+   initiated by the server after authentication, or use of a server-
+   generated encryption subkey), the server must utilize a replay cache
+   to remember any authenticator presented within the allowable clock
+   skew. All services sharing a key need to use the same replay cache.
+   If separate replay caches are used, then and authenticator used with
+   one such service could later be replayed to a different service with
+   the same service principal.
+
+   If a server loses track of authenticators presented within the
+   allowable clock skew, it must reject all requests until the clock
+   skew interval has passed, providing assurance that any lost or
+   replayed authenticators will fall outside the allowable clock skew
+   and can no longer be successfully replayed.
+
+   Implementations of Kerberos should not use untrusted directory
+   servers to determine the realm of a host. To allow such would allow
+   the compromise of the directory server to enable an attacker to
+   direct the client to accept authentication with the wrong principal
+   (i.e. one with a similar name, but in a realm with which the
+   legitimate host was not registered).
+
+   Implementations of Kerberos must not use DNS to map one name to
+   another (canonicalize) to determine the host part of the principal
+   name with which one is to communicate.  To allow such
+   canonicalization would allow a compromise of the DNS to result in a
+   client obtaining credentials and correctly authenticating to the
+   wrong principal. Though the client will know who it is communicating
+   with, it will not be the principal with which it intended to
+   communicate.
+
+   If the Kerberos server returns a TGT for a 'closer' realm other than
+   the desired realm, the client may use local policy configuration to
+   verify that the authentication path used is an acceptable one.
+   Alternatively, a client may choose its own authentication path,
+   rather than relying on the Kerberos server to select one. In either
+   case, any policy or configuration information used to choose or
+   validate authentication paths, whether by the Kerberos server or
+
+
+
+June 2004                                                     [Page 118]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   client, must be obtained from a trusted source.
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications. If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB_PRIV message,
+   or messages encrypted using application specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered. This
+   is because the session key use to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the KRB_TGS_REP
+   message. The session key from the ticket-granting ticket was sent to
+   the user in the KRB_AS_REP message encrypted in the user's secret
+   key, and embedded in the ticket-granting ticket, which was encrypted
+   in the key of the KDC. Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+11. Author's Addresses
+
+
+       Clifford Neuman
+       Information Sciences Institute
+       University of Southern California
+       4676 Admiralty Way
+       Marina del Rey, CA 90292, USA
+       Email: bcn@isi.edu
+
+       Tom Yu
+       Massachusetts Institute of Technology
+       77 Massachusetts Avenue
+       Cambridge, MA 02139, USA
+       Email: tlyu@mit.edu
+
+       Sam Hartman
+       Massachusetts Institute of Technology
+       77 Massachusetts Avenue
+       Cambridge, MA 02139, USA
+       Email: hartmans@mit.edu
+
+       Kenneth Raeburn
+       Massachusetts Institute of Technology
+       77 Massachusetts Avenue
+       Cambridge, MA 02139, USA
+       Email: raeburn@MIT.EDU
+
+
+
+
+June 2004                                                     [Page 119]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+12. Acknowledgements
+
+   This document is a revision to RFC1510 which was co-authored with
+   John Kohl.  The specification of the Kerberos protocol described in
+   this document is the result of many years of effort.  Over this
+   period many individuals have contributed to the definition of the
+   protocol and to the writing of the specification. Unfortunately it is
+   not possible to list all contributors as authors of this document,
+   though there are many not listed who are authors in spirit, because
+   they contributed text for parts of some sections, because they
+   contributed to the design of parts of the protocol, or because they
+   contributed significantly to the discussion of the protocol in the
+   IETF common authentication technology (CAT) and Kerberos working
+   groups.
+
+   Among those contributing to the development and specification of
+   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
+   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
+   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
+   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
+   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
+   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
+   Westerlund, and Nicolas Williams. Many other members of MIT Project
+   Athena, the MIT networking group, and the Kerberos and CAT working
+   groups of the IETF contributed but are not listed.
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+13. REFERENCES
+
+13.1 NORMATIVE REFERENCES
+
+   [@KCRYPTO]
+      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
+      crypto.
+
+   [@AES]
+      RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
+      rijndael-krb.
+
+   [ISO-646/ECMA-6]
+      7-bit Coded Character Set
+
+   [ISO-2022/ECMA-35]
+      Character Code Structure and Extension Techniques
+
+   [RFC1035]
+
+
+
+June 2004                                                     [Page 120]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
+      Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
+      RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
+      RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
+      RFC2535, RFC2845, and RFC3425. Status: Standard.
+
+   [RFC2119]
+
+      S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+      Requirement Levels", March 1997.
+
+   [RFC2434]
+      T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA
+      Consideration Secionts in RFCs" October, 1998.
+
+   [RFC2782]
+      A. Gulbrandsen,  P. Vixie and L. Esibov., RFC2782: "A DNS RR for
+      Specifying the Location of Services (DNS SRV)," February 2000.
+
+   [RFC2253]
+      M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
+      Access Protocol (v3): UTF-8 String Representation or Distinguished
+      Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
+      Status: Proposed Standard.
+
+   [RFC2373]
+      R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
+      Architecture," July 1998, Status: Proposed Standard.
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+
+13.2 INFORMATIVE REFERENCES
+
+   [DGT96]
+      Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks
+      Adrift: History, Protocols, and Implementation", USENIX Computing
+      Systems 9:1 (January 1996).
+
+   [DS81]
+
+
+
+June 2004                                                     [Page 121]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      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).
+
+   [KNT94]
+
+      John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+      Evolution of the Kerberos Authentication System". In Distributed
+      Open Systems, pages 78-94. IEEE Computer Society Press, 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).
+
+   [NS78]
+      Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+      Authentication in Large Networks of Computers," Communications of
+      the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+   [Neu93]
+      B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
+      Distributed Systems," in Proceedings of the 13th International
+      Conference on Distributed Computing Systems, Pittsburgh, PA (May,
+      1993).
+
+   [NT94]
+      B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
+      Service for Computer Networks," IEEE Communications Magazine, Vol.
+      32(9), pp.  33-38 (September 1994).
+
+   [Pat92].
+      J. Pato, Using Pre-Authentication to Avoid Password Guessing
+      Attacks, Open Software Foundation DCE Request for Comments 26
+      (December 1992).
+
+   [RFC1510]
+      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
+      Authentication Service (v5)," September 1993, Status: Proposed
+      Standard.
+
+   [RFC1750]
+      D. Eastlake, S. Crocker, and J. Schiller "Randomness
+      Recommendation for Security" December 1994, Status: Informational.
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+
+
+
+June 2004                                                     [Page 122]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [SNS88]
+      J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
+      Authentication Service for Open Network Systems," pp. 191-202 in
+      Usenix Conference Proceedings, Dallas, Texas (February, 1988).
+
+
+14. Copyright Statement
+
+      Copyright (C) The Internet Society (2004).  This document is
+      subject to the rights, licenses and restrictions contained in BCP
+      78 and except as set forth therein, the authors retain all their
+      rights.
+
+      This document and the information contained herein are provided on
+      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+      THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+15. Intellectual Property
+
+      The IETF takes no position regarding the validity or scope of any
+      Intellectual Property Rights 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; nor does it
+      represent that it has made any independent effort to identify any
+      such rights.  Information on the procedures with respect to rights
+      in RFC documents can be found in BCP 78 and BCP 79.
+
+      Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository
+      at http://www.ietf.org/ipr.
+
+      The IETF invites any interested party to bring to its attention
+      any copyrights, patents or patent applications, or other
+      proprietary rights that may cover technology that may be required
+      to implement this standard.  Please address the information to the
+      IETF at ietf-ipr@ietf.org.
+
+
+
+June 2004                                                     [Page 123]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+A. ASN.1 module
+
+   KerberosV5Spec2 {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) krb5spec2(2)
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   -- OID arc for KerberosV5
+   --
+   -- This OID may be used to identify Kerberos protocol messages
+   -- encapsulated in other protocols.
+   --
+   -- This OID also designates the OID arc for KerberosV5-related OIDs.
+   --
+   -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
+   id-krb5         OBJECT IDENTIFIER ::= {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2)
+   }
+
+   Int32           ::= INTEGER (-2147483648..2147483647)
+                       -- signed values representable in 32 bits
+
+   UInt32          ::= INTEGER (0..4294967295)
+                       -- unsigned 32 bit values
+
+   Microseconds    ::= INTEGER (0..999999)
+                       -- microseconds
+
+   KerberosString  ::= GeneralString (IA5String)
+
+   Realm           ::= KerberosString
+
+   PrincipalName   ::= SEQUENCE {
+           name-type       [0] Int32,
+           name-string     [1] SEQUENCE OF KerberosString
+   }
+
+   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+   HostAddress     ::= SEQUENCE  {
+           addr-type       [0] Int32,
+           address         [1] OCTET STRING
+   }
+
+   -- NOTE: HostAddresses is always used as an OPTIONAL field and
+   -- should not be empty.
+   HostAddresses   -- NOTE: subtly different from rfc1510,
+
+
+
+June 2004                                                     [Page 124]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                   -- but has a value mapping and encodes the same
+           ::= SEQUENCE OF HostAddress
+
+   -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+   -- should not be empty.
+   AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+           ad-type         [0] Int32,
+           ad-data         [1] OCTET STRING
+   }
+
+   PA-DATA         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           padata-type     [1] Int32,
+           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+   }
+
+   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
+                       -- shall be sent, but no fewer than 32
+
+   EncryptedData   ::= SEQUENCE {
+           etype   [0] Int32 -- EncryptionType --,
+           kvno    [1] UInt32 OPTIONAL,
+           cipher  [2] OCTET STRING -- ciphertext
+   }
+
+   EncryptionKey   ::= SEQUENCE {
+           keytype         [0] Int32 -- actually encryption type --,
+           keyvalue        [1] OCTET STRING
+   }
+
+   Checksum        ::= SEQUENCE {
+           cksumtype       [0] Int32,
+           checksum        [1] OCTET STRING
+   }
+
+   Ticket          ::= [APPLICATION 1] SEQUENCE {
+           tkt-vno         [0] INTEGER (5),
+           realm           [1] Realm,
+           sname           [2] PrincipalName,
+           enc-part        [3] EncryptedData -- EncTicketPart
+   }
+
+   -- Encrypted part of ticket
+   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
+           flags                   [0] TicketFlags,
+           key                     [1] EncryptionKey,
+           crealm                  [2] Realm,
+           cname                   [3] PrincipalName,
+
+
+
+June 2004                                                     [Page 125]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           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] Int32 -- must be registered --,
+           contents        [1] OCTET STRING
+   }
+
+   TicketFlags     ::= KerberosFlags
+           -- 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),
+   -- the following are new since 1510
+           -- transited-policy-checked(12),
+           -- ok-as-delegate(13)
+
+   AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+   KDC-REQ         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           pvno            [1] INTEGER (5) ,
+           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                               -- NOTE: not empty --,
+           req-body        [4] KDC-REQ-BODY
+   }
+
+   KDC-REQ-BODY    ::= SEQUENCE {
+           kdc-options             [0] KDCOptions,
+           cname                   [1] PrincipalName OPTIONAL
+
+
+
+June 2004                                                     [Page 126]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+                                       -- 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,
+           rtime                   [6] KerberosTime OPTIONAL,
+           nonce                   [7] UInt32,
+           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                       -- in preference order --,
+           addresses               [9] HostAddresses OPTIONAL,
+           enc-authorization-data  [10] EncryptedData OPTIONAL
+                                       -- AuthorizationData --,
+           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                           -- NOTE: not empty
+   }
+
+   KDCOptions      ::= KerberosFlags
+           -- reserved(0),
+           -- forwardable(1),
+           -- forwarded(2),
+           -- proxiable(3),
+           -- proxy(4),
+           -- allow-postdate(5),
+           -- postdated(6),
+           -- unused7(7),
+           -- renewable(8),
+           -- unused9(9),
+           -- unused10(10),
+           -- opt-hardware-auth(11),
+           -- unused12(12),
+           -- unused13(13),
+   -- 15 is reserved for canonicalize
+           -- unused15(15),
+   -- 26 was unused in 1510
+           -- disable-transited-check(26),
+   --
+           -- renewable-ok(27),
+           -- enc-tkt-in-skey(28),
+           -- renew(30),
+           -- validate(31)
+
+   AS-REP          ::= [APPLICATION 11] KDC-REP
+
+   TGS-REP         ::= [APPLICATION 13] KDC-REP
+
+   KDC-REP         ::= SEQUENCE {
+
+
+
+June 2004                                                     [Page 127]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                   -- NOTE: not empty --,
+           crealm          [3] Realm,
+           cname           [4] PrincipalName,
+           ticket          [5] Ticket,
+           enc-part        [6] EncryptedData
+                                   -- EncASRepPart or EncTGSRepPart,
+                                   -- as appropriate
+   }
+
+   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+   EncKDCRepPart   ::= SEQUENCE {
+           key             [0] EncryptionKey,
+           last-req        [1] LastReq,
+           nonce           [2] UInt32,
+           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
+   }
+
+   LastReq         ::=     SEQUENCE OF SEQUENCE {
+           lr-type         [0] Int32,
+           lr-value        [1] KerberosTime
+   }
+
+   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (14),
+           ap-options      [2] APOptions,
+           ticket          [3] Ticket,
+           authenticator   [4] EncryptedData -- Authenticator
+   }
+
+   APOptions       ::= KerberosFlags
+           -- reserved(0),
+           -- use-session-key(1),
+           -- mutual-required(2)
+
+
+
+June 2004                                                     [Page 128]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   -- Unencrypted authenticator
+   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+           authenticator-vno       [0] INTEGER (5),
+           crealm                  [1] Realm,
+           cname                   [2] PrincipalName,
+           cksum                   [3] Checksum OPTIONAL,
+           cusec                   [4] Microseconds,
+           ctime                   [5] KerberosTime,
+           subkey                  [6] EncryptionKey OPTIONAL,
+           seq-number              [7] UInt32 OPTIONAL,
+           authorization-data      [8] AuthorizationData OPTIONAL
+   }
+
+   AP-REP          ::= [APPLICATION 15] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (15),
+           enc-part        [2] EncryptedData -- EncAPRepPart
+   }
+
+   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+           ctime           [0] KerberosTime,
+           cusec           [1] Microseconds,
+           subkey          [2] EncryptionKey OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL
+   }
+
+   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (20),
+           safe-body       [2] KRB-SAFE-BODY,
+           cksum           [3] Checksum
+   }
+
+   KRB-SAFE-BODY   ::= SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress,
+           r-address       [5] HostAddress OPTIONAL
+   }
+
+   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (21),
+                           -- NOTE: there is no [2] tag
+           enc-part        [3] EncryptedData -- EncKrbPrivPart
+   }
+
+
+
+June 2004                                                     [Page 129]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress -- sender's addr --,
+           r-address       [5] HostAddress OPTIONAL -- recip's addr
+   }
+
+   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (22),
+           tickets         [2] SEQUENCE OF Ticket,
+           enc-part        [3] EncryptedData -- EncKrbCredPart
+   }
+
+   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+           ticket-info     [0] SEQUENCE OF KrbCredInfo,
+           nonce           [1] UInt32 OPTIONAL,
+           timestamp       [2] KerberosTime OPTIONAL,
+           usec            [3] Microseconds 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
+   }
+
+   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (30),
+           ctime           [2] KerberosTime OPTIONAL,
+           cusec           [3] Microseconds OPTIONAL,
+           stime           [4] KerberosTime,
+           susec           [5] Microseconds,
+           error-code      [6] Int32,
+           crealm          [7] Realm OPTIONAL,
+
+
+
+June 2004                                                     [Page 130]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           cname           [8] PrincipalName OPTIONAL,
+           realm           [9] Realm -- service realm --,
+           sname           [10] PrincipalName -- service name --,
+           e-text          [11] KerberosString OPTIONAL,
+           e-data          [12] OCTET STRING OPTIONAL
+   }
+
+   METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+           data-type       [0] INTEGER,
+           data-value      [1] OCTET STRING OPTIONAL
+   }
+
+   -- preauth stuff follows
+
+   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+   PA-ENC-TS-ENC           ::= SEQUENCE {
+           patimestamp     [0] KerberosTime -- client's time --,
+           pausec          [1] Microseconds OPTIONAL
+   }
+
+   ETYPE-INFO-ENTRY        ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] KerberosString OPTIONAL,
+           s2kparams       [2] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
+
+   AD-IF-RELEVANT          ::= AuthorizationData
+
+   AD-KDCIssued            ::= SEQUENCE {
+           ad-checksum     [0] Checksum,
+           i-realm         [1] Realm OPTIONAL,
+           i-sname         [2] PrincipalName OPTIONAL,
+           elements        [3] AuthorizationData
+   }
+
+   AD-AND-OR               ::= SEQUENCE {
+
+
+
+June 2004                                                     [Page 131]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+           condition-count [0] INTEGER,
+           elements        [1] AuthorizationData
+   }
+
+   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+   END
+
+B. Changes since RFC-1510
+
+   This document replaces RFC-1510 and clarifies specification of items
+   that were not completely specified. Where changes to recommended
+   implementation choices were made, or where new options were added,
+   those changes are described within the document and listed in this
+   section. More significantly, "Specification 2" in section 8 changes
+   the required encryption and checksum methods to bring them in line
+   with the best current practices and to deprecate methods that are no
+   longer considered sufficiently strong.
+
+   Discussion was added to section 1 regarding the ability to rely on
+   the KDC to check the transited field, and on the inclusion of a flag
+   in a ticket indicating that this check has occurred. This is a new
+   capability not present in RFC1510. Pre-existing implementations may
+   ignore or not set this flag without negative security implications.
+
+   The definition of the secret key says that in the case of a user the
+   key may be derived from a password. In 1510, it said that the key was
+   derived from the password. This change was made to accommodate
+   situations where the user key might be stored on a smart-card, or
+   otherwise obtained independent of a password.
+
+   The introduction mentions the use of public key cryptography for
+   initial authentication in Kerberos by reference. RFC1510 did not
+   include such a reference.
+
+   Section 1.2 was added to explain that while Kerberos provides
+   authentication of a named principal, it is still the responsibility
+   of the application to ensure that the authenticated name is the
+   entity with which the application wishes to communicate.
+
+   Discussion of extensibility has been added to the introduction.
+
+   Discussion of how extensibility affects ticket flags and KDC options
+   was added to the introduction of section 2. No changes were made to
+   existing options and flags specified in RFC1510, though some of the
+   sections in the specification were renumbered, and text was revised
+   to make the description and intent of existing options clearer,
+   especially with respect to the ENC-TKT-IN-SKEY option (now section
+
+
+
+June 2004                                                     [Page 132]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   2.9.2) which is used for user-to-user authentication.  The new option
+   and ticket flag transited policy checking (section 2.7) was added.
+
+   A warning regarding generation of session keys for application use
+   was added to section 3, urging the inclusion of key entropy from the
+   KDC generated session key in the ticket. An example regarding use of
+   the sub-session key was added to section 3.2.6. Descriptions of the
+   pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
+   items were added. The recommendation for use of pre-authentication
+   was changed from "may" to "should" and a note was added regarding
+   known plaintext attacks.
+
+   In RFC 1510, section 4 described the database in the KDC. This
+   discussion was not necessary for interoperability and unnecessarily
+   constrained implementation. The old section 4 was removed.
+
+   The current section 4 was formerly section 6 on encryption and
+   checksum specifications. The major part of this section was brought
+   up to date to support new encryption methods, and move to a separate
+   document. Those few remaining aspects of the encryption and checksum
+   specification specific to Kerberos are now specified in section 4.
+
+   Significant changes were made to the layout of section 5 to clarify
+   the correct behavior for optional fields. Many of these changes were
+   made necessary because of improper ASN.1 description in the original
+   Kerberos specification which left the correct behavior
+   underspecified. Additionally, the wording in this section was
+   tightened wherever possible to ensure that implementations conforming
+   to this specification will be extensible with the addition of new
+   fields in future specifications.
+
+   Text was added describing time_t=0 issues in the ASN.1. Text was also
+   added, clarifying issues with implementations treating omitted
+   optional integers as zero. Text was added clarifying behavior for
+   optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was
+   added regarding sequence numbers and behavior of some
+   implementations, including "zero" behavior and negative numbers. A
+   compatibility note was added regarding the unconditional sending of
+   EncTGSRepPart regardless of the enclosing reply type. Minor changes
+   were made to the description of the HostAddresses type. Integer types
+   were constrained. KerberosString was defined as a (significantly)
+   constrained GeneralString. KerberosFlags was defined to reflect
+   existing implementation behavior that departs from the definition in
+   RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13)
+   ticket flags were added. The disable-transited-check(26) KDC option
+   was added.
+
+   Descriptions of commonly implemented PA-DATA were added to section 5.
+
+
+
+June 2004                                                     [Page 133]
+
+
+
+
+
+Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
+
+
+   The description of KRB-SAFE has been updated to note the existing
+   implementation behavior of double-encoding.
+
+   There were two definitions of METHOD-DATA in RFC 1510. The second
+   one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
+   SEQUENCE OF PA-DATA definition.
+
+   Section 7, naming constraints, from RFC1510 was moved to section 6.
+
+   Words were added describing the convention that domain based realm
+   names for newly created realms should be specified as upper case.
+   This recommendation does not make lower case realm names illegal.
+   Words were added highlighting that the slash separated components in
+   the X500 style of realm names is consistent with existing RFC1510
+   based implementations, but that it conflicts with the general
+   recommendation of X.500 name representation specified in RFC2253.
+
+   Section 8, network transport, constants and defined values, from
+   RFC1510 was moved to section 7.  Since RFC1510, the definition of the
+   TCP transport for Kerberos messages was added, and the encryption and
+   checksum number assignments have been moved into a separate document.
+
+   "Specification 2" in section 8 of the current document changes the
+   required encryption and checksum methods to bring them in line with
+   the best current practices and to deprecate methods that are no
+   longer considered sufficiently strong.
+
+   Two new sections, on IANA considerations and security considerations
+   were added.
+
+   The pseudo-code has been removed from the appendix. The pseudo-code
+   was sometimes misinterpreted to limit implementation choices and in
+   RFC 1510, it was not always consistent with the words in the
+   specification. Effort was made to clear up any ambiguities in the
+   specification, rather than to rely on the pseudo-code.
+
+   An appendix was added containing the complete ASN.1 module drawn from
+   the discussion in section 5 of the current document.
+
+END NOTES
+
+   (*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.
+
+
+
+
+
+
+
+June 2004                                                     [Page 134]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt
new file mode 100644
index 00000000000..5845995f2d9
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt
@@ -0,0 +1,725 @@
+
+
+Kerberos Working Group                                         M. Swift 
+Internet Draft                                         University of WA 
+Document: draft-ietf-krb-wg-kerberos-referrals-00.txt         J. Brezak 
+Category: Standards Track                                     Microsoft 
+                                                             J. Trostle 
+                                                          Cisco Systems 
+                                                             K. Raeburn 
+                                                                    MIT 
+                                                          February 2001 
+
+ 
+           Generating KDC Referrals to locate Kerberos realms 
+ 
+ 
+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 draft documents a new method for a Kerberos Key Distribution 
+   Center (KDC) to respond to client requests for kerberos tickets when 
+   the client does not have detailed configuration information on the 
+   realms of users or services. The KDC will handle requests for 
+   principals in other realms by returning either a referral error or a 
+   cross-realm TGT to another realm on the referral path. The clients 
+   will use this referral information to reach the realm of the target 
+   principal and then receive the ticket. 
+    
+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. Introduction 
+    
+
+
+  
+Swift                 Category - Standards Track                     1 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+   Current implementations of the Kerberos AS and TGS protocols, as 
+   defined in RFC 1510 [3], use principal names constructed from a 
+   known user or service name and realm. A service name is typically 
+   constructed from a name of the service and the DNS host name of the 
+   computer that is providing the service. Many existing deployments of 
+   Kerberos use a single Kerberos realm where all users and services 
+   would be using the same realm. However in an environment where there 
+   are multiple trusted Kerberos realms, the client needs to be able to 
+   determine what realm a particular user or service is in before 
+   making an AS or TGS request. Traditionally this requires client 
+   configuration to make this possible. 
+    
+   When having to deal with multiple trusted realms, users are forced 
+   to know what realm they are in before they can obtain a ticket 
+   granting ticket (TGT) with an AS request. However, in many cases the 
+   user would like to use a more familiar name that is not directly 
+   related to the realm of their Kerberos principal name. A good 
+   example of this is an RFC-822 style email name. This document 
+   describes a mechanism that would allow a user to specify a user 
+   principal name that is an alias for the user's Kerberos principal 
+   name. In practice this would be the name that the user specifies to 
+   obtain a TGT from a Kerberos KDC. The user principal name no longer 
+   has a direct relationship with the Kerberos principal or realm. Thus 
+   the administrator is able to move the user's principal to other 
+   realms without the user having to know that it happened. 
+    
+   Once a user has a TGT, they would like to be able to access services 
+   in any trusted Kerberos realm. To do this requires that the client 
+   be able to determine what realm the target service's host is in 
+   before making the TGS request. Current implementations of Kerberos 
+   typically have a table that maps DNS host names to corresponding 
+   Kerberos realms. In order for this to work on the client, each 
+   application canonicalizes the host name of the service by doing a 
+   DNS lookup followed by a reverse lookup using the returned IP 
+   address. The returned primary host name is then used in the 
+   construction of the principal name for the target service. In order 
+   for the correct realm to be added for the target host, the mapping 
+   table [domain_to_realm] is consulted for the realm corresponding to 
+   the DNS host name. The corresponding realm is then used to complete 
+   the target service principal name. 
+    
+   This traditional mechanism requires that each client have very 
+   detailed configuration information about the hosts that are 
+   providing services and their corresponding realms. Having client 
+   side configuration information can be very costly from an 
+   administration point of view - especially if there are many realms 
+   and computers in the environment. 
+    
+   Current implementations of Kerberos also have difficulty with 
+   services on hosts that can have multiple host names (multi-homed 
+   hosts). Traditionally, each host name would need to have a distinct 
+   principal and a corresponding key. An extreme example of this would 
+   be a Web server with multiple host names for each domain that it is 
+  
+Swift                 Category - Standards Track                     2 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+   supporting. Principal aliases allow multi-homed hosts to have a 
+   single Kerberos principal (with a single key) that can have 
+   identities for each distinct host name. This mechanism allows the 
+   Kerberos client to request a service ticket for the distinct 
+   hostname and allows the KDC to return a ticket for the single 
+   principal that the host is using. This canonical principal name 
+   allows the host to only have to manage a single key for all of the 
+   identities that it supports. In addition, the client only needs to 
+   know the realm of the canonical service name, not all of the 
+   identities. 
+    
+   This draft proposes a solution for these problems and simplifies 
+   administration by minimizing the configuration information needed on 
+   each computer using Kerberos. Specifically it describes a mechanism 
+   to allow the KDC to handle Canonicalization of names, provide for 
+   principal aliases for users and services and provide a mechanism for 
+   the KDC to determine the trusted realm authentication path by being 
+   able to generate referrals to other realms in order to locate 
+   principals. 
+    
+   To rectify these problems, this draft introduces three new kinds of   
+   KDC referrals: 
+        
+   1. AS ticket referrals, in which the client doesn't know which realm 
+      contains a user account.  
+   2. TGS ticket referrals, in which the client doesn't know which 
+      realm contains a server account.  
+   3. Cross realm shortcut referrals, in which the KDC chooses the next 
+      path on a referral chain 
+    
+4. Realm Organization Model 
+    
+   This draft assumes that the world of principals is arranged on 
+   multiple levels: the realm, the enterprise, and the world. A KDC may 
+   issue tickets for any principal in its realm or cross-realm tickets 
+   for realms with which it has a direct trust relationship. The KDC 
+   also has access to a trusted name service that can resolve any name 
+   from within its enterprise into a realm. This trusted name service 
+   removes the need to use an untrusted DNS lookup for name resolution. 
+    
+   For example, consider the following configuration, where lines 
+   indicate trust relationships: 
+    
+                  MS.COM  
+                /        \ 
+               /          \ 
+        OFFICE.MS.COM    NT.MS.COM 
+    
+   In this configuration, all users in the MS.COM enterprise could have 
+   a principal name such as alice@MS.COM, with the same realm portion. 
+   In addition, servers at MS.COM should be able to have DNS host names 
+   from any DNS domain independent of what Kerberos realm their 
+   principal resides in. 
+  
+Swift                 Category - Standards Track                     3 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+    
+5. Principal Names 
+    
+5.1 Service Principal Names 
+    
+   The standard Kerberos model in RFC 1510 [3] gives each Kerberos 
+   principal a single name. However, if a service is reachable by 
+   several addresses, it is useful for a principal to have multiple 
+   names. Consider a service running on a multi-homed machine. Rather 
+   than requiring a separate principal and password for each name it 
+   exports, a single account with multiple names could be used. 
+    
+   Multiple names are also useful for services in that clients need not 
+   perform DNS lookups to resolve a host name into a full DNS address. 
+   Instead, the service may have a name for each of its supported host 
+   names, including its IP address. Nonetheless, it is still convenient 
+   for the service to not have to be aware of all these names. Thus a 
+   new name may be added to DNS for a service by updating DNS and the 
+   KDC database without having to notify the service. In addition, it 
+   implies that these aliases are globally unique: they do not include 
+   a specifier dictating what realm contains the principal. Thus, an 
+   alias for a server is of the form "class/instance/name" and may be 
+   transmitted as any name type. 
+    
+5.2 Client Principal Names 
+    
+   Similarly, a client account may also have multiple principal names. 
+   More useful, though, is a globally unique name that allows 
+   unification of email and security principal names. For example, all 
+   users at MS may have a client principal name of the form 
+   "joe@MS.COM" even though the principals are contained in multiple 
+   realms. This global name is again an alias for the true client 
+   principal name, which is indicates what realm contains the 
+   principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 
+   "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 
+   This requires a new client principal name type, as the AS-REQ 
+   message only contains a single realm field, and the realm portion of 
+   this name doesn't correspond to any Kerberos realm. Thus, the entire 
+   name "alice@MS.COM" is transmitted in the client name field of the 
+   AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 
+    
+        KRB-NT-ENTERPRISE-PRINCIPAL     10 
+    
+5.3 Name Canonicalization 
+    
+   In order to support name aliases, the Kerberos client must 
+   explicitly request the name-canonicalization KDC option (bit 15) in 
+   the ticket flags for the TGS-REQ. This flag indicates to the KDC 
+   that the client is prepared to receive a reply with a different 
+   client or server principal name than the request. Thus, the 
+   KDCOptions types is redefined as: 
+    
+        KDCOptions ::=   BIT STRING { 
+  
+Swift                 Category - Standards Track                     4 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+                          reserved(0), 
+                          forwardable(1), 
+                          forwarded(2), 
+                          proxiable(3), 
+                          proxy(4), 
+                          allow-postdate(5), 
+                          postdated(6), 
+                          unused7(7), 
+                          renewable(8), 
+                          unused9(9), 
+                          unused10(10), 
+                          unused11(11), 
+                          name-canonicalize(15), 
+                          renewable-ok(27), 
+                          enc-tkt-in-skey(28), 
+                          renew(30), 
+                          validate(31) 
+         } 
+    
+6. Client Referrals 
+    
+   The simplest form of ticket referral is for a user requesting a 
+   ticket using an AS-REQ. In this case, the client machine will send 
+   the AS request to a convenient trusted realm, either the realm of 
+   the client machine or the realm of the client name. In the case of 
+   the name Alice@MS.COM, the client may optimistically choose to send 
+   the request to MS.COM. 
+    
+   The client will send the string "alice@MS.COM" in the client 
+   principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 
+   with the crealm set to MS.COM. The KDC will try to lookup the name 
+   in its local account database. If the account is present in the 
+   crealm of the request, it MUST return a KDC reply structure with the 
+   appropriate ticket. If the account is not present in the crealm 
+   specified in the request and the name-canonicalize flag in the 
+   KDCoptions is set, the KDC will try to lookup the entire name, 
+   Alice@MS.COM, using a name service. If this lookup is unsuccessful, 
+   it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup 
+   is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44) 
+   and in the error message the cname and crealm field MUST contain the 
+   client name and the true realm of the client. If the KDC contains 
+   the account locally, it MUST return a normal ticket. The client name 
+   and realm portions of the ticket and KDC reply message MUST be the 
+   client's true name in the realm, not the globally unique name. 
+    
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 
+   new AS request with the same client principal name used to generate 
+   the first referral to the realm specified by the crealm field of the 
+   kerberos error message from the first request. This request MUST 
+   produce a valid AS response with a ticket for the canonical user 
+   name. The ticket MUST also include the ticket extension containing 
+   the TE-REFERRAL-DATA with the referred-names set to the name from 
+
+  
+Swift                 Category - Standards Track                     5 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+   the AS request. Any other error or referral will terminate the 
+   request and result in a failed AS request. 
+    
+7. Server Referrals 
+    
+   The server referral mechanism is a bit more complex than the client 
+   referral mechanism. The primary problem is that the KDC must return 
+   a referral ticket rather than an error message, so it will include 
+   in the TGS response information about what realm contains the 
+   service. This is done by returning information about the server name 
+   in the pre-auth data field of the KDC reply. 
+    
+   If the KDC resolves the server principal name into a principal in 
+   its realm, it may return a normal ticket. If the name-canonicalize 
+   flag in the KDCoptions is not set, then the KDC MUST only look up 
+   the name as a normal principal name. Otherwise, it MUST search all 
+   aliases as well. The server principal name in both the ticket and 
+   the KDC reply MUST be the true server principal name instead of one 
+   of the aliases. This frees the application server from needing to 
+   know about all its aliases. 
+    
+   If the name-canonicalize flag in the KDCoptions is set and the KDC 
+   doesn't find the principal locally, the KDC can return a cross-realm 
+   ticket granting ticket to the next hop on the trust path towards a 
+   realm that may be able to resolve the principal name. 
+    
+   If the KDC can determine the service principal's realm, it can 
+   return the server realm as ticket extension data. The ticket 
+   extension MUST be encrypted using the session key from the ticket, 
+   and the same etype as is used to protect the TGS reply body. 
+    
+   The data itself is an ASN.1 encoded structure containing the 
+   server's realm, and if known, canonical principal name and alias 
+   names. The first name in the sequence is the canonical principal 
+   name. 
+    
+                TE-REFERRAL-INFO        20 
+                 
+                TE-REFERRAL-DATA ::= SEQUENCE { 
+                        referred-server-realm[0]  KERB-REALM 
+                        referred-names[1]         SEQUENCE OF 
+                        PrincipalNames OPTIONAL 
+                } 
+    
+    
+   The client can use this information to request a chain of cross-
+   realm ticket granting tickets until it reaches the realm of the 
+   server, and can then expect to receive a valid service ticket. 
+    
+   In order to facilitate cross-realm interoperability, a client SHOULD 
+   NOT send short names in TGS requests to the KDC. A short name is 
+   defined as a Kerberos name that includes a DNS name that is not 
+   fully qualified. The client MAY use forward DNS lookups to obtain 
+  
+Swift                 Category - Standards Track                     6 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+   the long name that corresponds to the user entered short name (the 
+   short name will be a prefix of the corresponding long name). 
+    
+   The client may use the referred-names field to tell if it already 
+   has a ticket to the server in its ticket cache. 
+    
+   The client can use this information to request a chain of cross-
+   realm ticket granting tickets until it reaches the realm of the 
+   server, and can then expect to receive a valid service ticket. 
+   However an implementation should limit the number of referrals that 
+   it processes to avoid infinite referral loops. A suggested limit is 
+   5 referrals before giving up. 
+    
+8. Cross Realm Routing 
+    
+   The current Kerberos protocol requires the client to explicitly 
+   request a cross-realm TGT for each pair of realms on a referral 
+   chain. As a result, the client machines need to be aware of the 
+   trust hierarchy and of any short-cut trusts (those that aren't 
+   parent-child trusts). This requires more configurations on the 
+   client. Instead, the client should be able to request a TGT to the 
+   target realm from each realm on the route. The KDC will determine 
+   the best path for the client and return a cross-realm TGT. The 
+   client has to be aware that a request for a cross-realm TGT may 
+   return a TGT for a realm different from the one requested. 
+    
+9. Security Considerations 
+ 
+   The original Kerberos specification stated that the server principal 
+   name in the KDC reply was the same as the server name in the 
+   request. These protocol changes break that assumption, so the client 
+   may be vulnerable to a denial of service attack by an attacker that 
+   replays replies from previous requests. It can verify that the 
+   request was one of its own by checking the client-address field or 
+   authtime field, though, so the damage is limited and detectable. 
+    
+   For the AS exchange case, it is important that the logon mechanism 
+   not trust a name that has not been used to authenticate the user. 
+   For example, the name that the user enters as part of a logon 
+   exchange may not be the name that the user authenticates as, given 
+   that the KDC_ERR_WRONG_REALM error may have been returned. The 
+   relevant Kerberos naming information for logon (if any), is the 
+   client name and client realm in the service ticket targeted at the 
+   workstation that was obtained using the user's initial TGT. 
+    
+   How the client name and client realm is mapped into a local account 
+   for logon is a local matter, but the client logon mechanism MUST use 
+   additional information such as the client realm and/or authorization 
+   attributes from the service ticket presented to the workstation by 
+   the user, when mapping the logon credentials to a local account on 
+   the workstation. 
+    
+10. Discussion 
+  
+Swift                 Category - Standards Track                     7 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+ 
+   This section contains issues and suggestions that need to be 
+   incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]: 
+    
+   1) No means to do name canonicalization if you're not 
+      authenticating. Is it okay to require credentials in order to do 
+      canonicalization? If so, how about this: Send a TGS_REQ for the 
+      service name you have.  If you get back a TGS_REP for a service, 
+      great; pull out the name and throw out the credentials.  If you 
+      get back a TGS_REP for a TGT service, ask again in the specified 
+      realm.  If you get back a KRB_ERROR because policy prohibits you 
+      from authenticating to that service, we can add to the 
+      specification that the {realm,sname} in the KRB_ERROR must be the 
+      canonical name, and the checksum must be used.  As long as the 
+      checksum is present, it's still a secure exchange with the KDC.  
+       
+      If we have to be able to do name canonicalization without any 
+      sort of credentials, either client-side (tickets) or server-side 
+      (tickets automatically acquired via service key), I think we just 
+      lose. But maybe GSSAPI should be changed if that's the case. 
+    
+   2) Can't refer to another realm and specify a different service name 
+      to give to that realm's KDC.  The local KDC can tell you a 
+      different service name or a different realm name, but not both. 
+      This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type 
+      of case I've mentioned. 
+       
+      Except ... the KDC-REP structure includes padata and ticket 
+      extensions fields that are extensible.  We could add a required 
+      value to one of them -- perhaps only in the case where you return 
+      a TGT when not asked -- that contains signed information about 
+      the principal name to ask for in the other realm.  (It would have 
+      to be required, otherwise a man-in-the-middle could make it go 
+      away.) Signing would be done using the session key for the TGS. 
+    
+   3) Secure canonicalization of service name in AS_REQ. If the 
+      response is an AS_REP, we need a way to tell that the altered 
+      server name wasn't a result of a MITM attack on the AS_REQ 
+      message.  Again, the KDC-REP extensible fields could have a new 
+      required value added when name canonicalization happens, 
+      indicating what the original principal name (in the AS_REQ 
+      message) was, and signed using the same key as protects the 
+      AS_REP.  If it doesn't match what the client requested, the 
+      messages were altered in transit. 
+    
+   4) Client name needs referral to another realm, and server name 
+      needs canonicalization of some sort. The above fixes wouldn't 
+      work for this case, and I'm not even sure which KDC should be 
+      doing the canonicalization anyways. 
+    
+    
+   The other-principal-name datum would probably look something like: 
+    
+  
+Swift                 Category - Standards Track                     8 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+       PrincipalAndNonce ::= SEQUENCE { 
+                    name[0]     PrincipalName, 
+                    nonce[1]    INTEGER         -- copied from KDC_REQ 
+       } 
+       SignedPrincipal ::= SEQUENCE { 
+                    name-and-nonce[0]   PrincipalAndNonce, 
+                    cksum[1]    Checksum 
+       } 
+       {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal 
+       {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal 
+    
+   with the checksum computed over the encoding of the 'name-and-nonce' 
+   field, and appropriate PA- or TE- numbers assigned.  I don't have a 
+   strong opinion on whether it'd be a pa-data or ticket extension; 
+   conceptually it seems like an abuse of either, but, well, I think 
+   I'd rather abuse them than leave the facility both in and 
+   inadequate. 
+    
+   The nonce is needed because multiple exchanges may be made with the 
+   same key, and these extension fields aren't packed in with the other 
+   encrypted data in the same response, so a MITM could pick apart 
+   multiple messages and mix-and-match components.  (In a TGS_REQ 
+   exchange, a subsession key would help, but it's not required.) 
+    
+   The extension field would be required to prevent a MITM from 
+   discarding the field from a response; a flag bit in a protected part 
+   of the message (probably in 'flags' in EncKDCRepPart) could also let 
+   us know of a cases where the information can be omitted, namely, 
+   when no name change is done.  Perhaps the bit should be set to 
+   indicate that a name change *was* done, and clear if it wasn't, 
+   making the no-change case more directly compatible with RFC1510. 
+ 
+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  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+    
+    
+12. Author's Addresses 
+    
+   Michael Swift 
+   University of Washington 
+   Seattle, Washington 
+   Email: mikesw@cs.washington.edu 
+    
+   John Brezak 
+  
+Swift                 Category - Standards Track                     9 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@Microsoft.com 
+    
+   Jonathan Trostle 
+   Cisco Systems 
+   170 W. Tasman Dr. 
+   San Jose, CA 95134 
+   Email: jtrostle@cisco.com 
+    
+   Kenneth Raeburn 
+   Massachusetts Institute of Technology 77 
+   Massachusetts Avenue 
+   Cambridge, Massachusetts 02139 
+   Email: raeburn@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                 Category - Standards Track                    10 
+
+
+
+
+
+
+
+
+                            KDC Referrals               February 2001 
+ 
+ 
+   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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                 Category - Standards Track                    11 
+
+
+
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt
new file mode 100644
index 00000000000..cbe29448224
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt
@@ -0,0 +1,638 @@
+
+
+
+Kerberos Working Group                                          Karthik 
+                                                             Jaganathan 
+Internet Draft                                                Larry Zhu 
+Document: draft-ietf-krb-wg-kerberos-referrals-03.txt       John Brezak 
+Category: Standards Track                                     Microsoft 
+                                                             Mike Swift 
+                                                          University of  
+                                                             Washington 
+                                                       Jonathan Trostle 
+                                                          Cisco Systems 
+                                                        Expires: August 
+                                                                   2004 
+ 
+ 
+           Generating KDC Referrals to locate Kerberos realms 
+ 
+ 
+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 draft documents a new method for a Kerberos Key Distribution 
+   Center (KDC) to respond to client requests for kerberos tickets when 
+   the client does not have detailed configuration information on the 
+   realms of users or services. The KDC will handle requests for 
+   principals in other realms by returning either a referral error or a 
+   cross-realm TGT to another realm on the referral path. The clients 
+   will use this referral information to reach the realm of the target 
+   principal and then receive the ticket. 
+    
+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]. 
+    
+
+  
+Jaganathan            Category - Standards Track                     1 
+                            KDC Referrals                 August 2004 
+ 
+ 
+3. Introduction 
+    
+   Current implementations of the Kerberos AS and TGS protocols, as 
+   defined in [3], use principal names constructed from a known user or 
+   service name and realm. A service name is typically constructed from 
+   a name of the service and the DNS host name of the computer that is 
+   providing the service. Many existing deployments of Kerberos use a 
+   single Kerberos realm where all users and services would be using 
+   the same realm. However in an environment where there are multiple 
+   trusted Kerberos realms, the client needs to be able to determine 
+   what realm a particular user or service is in before making an AS or 
+   TGS request. Traditionally this requires client configuration to 
+   make this possible. 
+    
+   When having to deal with multiple trusted realms, users are forced 
+   to know what realm they are in before they can obtain a ticket 
+   granting ticket (TGT) with an AS request. However, in many cases the 
+   user would like to use a more familiar name that is not directly 
+   related to the realm of their Kerberos principal name. A good 
+   example of this is an RFC-822 style email name. This document 
+   describes a mechanism that would allow a user to specify a user 
+   principal name that is an alias for the user's Kerberos principal 
+   name. In practice this would be the name that the user specifies to 
+   obtain a TGT from a Kerberos KDC. The user principal name no longer 
+   has a direct relationship with the Kerberos principal or realm. Thus 
+   the administrator is able to move the user's principal to other 
+   realms without the user having to know that it happened. 
+    
+   Once a user has a TGT, they would like to be able to access services 
+   in any trusted Kerberos realm. To do this requires that the client 
+   be able to determine what realm the target service's host is in 
+   before making the TGS request. Current implementations of Kerberos 
+   typically have a table that maps DNS host names to corresponding 
+   Kerberos realms. In order for this to work on the client, each 
+   application canonicalizes the host name of the service by doing a 
+   DNS lookup followed by a reverse lookup using the returned IP 
+   address. The returned primary host name is then used in the 
+   construction of the principal name for the target service. In order 
+   for the correct realm to be added for the target host, the mapping 
+   table [domain_to_realm] is consulted for the realm corresponding to 
+   the DNS host name. The corresponding realm is then used to complete 
+   the target service principal name. 
+    
+   This traditional mechanism requires that each client have very 
+   detailed configuration information about the hosts that are 
+   providing services and their corresponding realms. Having client 
+   side configuration information can be very costly from an 
+   administration point of view - especially if there are many realms 
+   and computers in the environment. 
+    
+   There are also cases where specific DNS aliases (local names) have 
+   been setup in an organization to refer to a server in another 
+   organization (remote server). The server has different DNS names in 
+  
+Jaganathan            Category - Standards Track                     2 
+                            KDC Referrals                 August 2004 
+ 
+ 
+   each organization and each organization has a Kerberos realm that is 
+   configured to service DNS names within that organization. Ideally 
+   users are able to authenticate to the server in the other 
+   organization using the local server name. This would mean that the 
+   local realm be able to produce a ticket to the remote server under 
+   its name. You could give that remote server an identity in the local 
+   realm and then have that remote server maintain a separate secret 
+   for each alias it is known as. Alternatively you could arrange to 
+   have the local realm issue a referral to the remote realm and notify 
+   the requesting client of the server's remote name that should be 
+   used in order to request a ticket. 
+    
+   This draft proposes a solution for these problems and simplifies 
+   administration by minimizing the configuration information needed on 
+   each computer using Kerberos. Specifically it describes a mechanism 
+   to allow the KDC to handle Canonicalization of names, provide for 
+   principal aliases for users and services and provide a mechanism for 
+   the KDC to determine the trusted realm authentication path by being 
+   able to generate referrals to other realms in order to locate 
+   principals. 
+    
+   To rectify these problems, this draft introduces three new kinds of   
+   KDC referrals: 
+        
+   1. AS ticket referrals, in which the client doesn't know which realm 
+      contains a user account.  
+   2. TGS ticket referrals, in which the client doesn't know which 
+      realm contains a server account.  
+   3. Cross realm shortcut referrals, in which the KDC chooses the next 
+      path on a referral chain 
+    
+4. Realm Organization Model 
+    
+   This draft assumes that the world of principals is arranged on 
+   multiple levels: the realm, the enterprise, and the world. A KDC may 
+   issue tickets for any principal in its realm or cross-realm tickets 
+   for realms with which it has a direct trust relationship. The KDC 
+   also has access to a trusted name service that can resolve any name 
+   from within its enterprise into a realm. This trusted name service 
+   removes the need to use an untrusted DNS lookup for name resolution. 
+    
+   For example, consider the following configuration, where lines 
+   indicate trust relationships: 
+    
+                  MS.COM  
+                /        \ 
+               /          \ 
+        OFFICE.MS.COM    NT.MS.COM 
+    
+   In this configuration, all users in the MS.COM enterprise could have 
+   a principal name such as alice@MS.COM, with the same realm portion. 
+   In addition, servers at MS.COM should be able to have DNS host names 
+
+  
+Jaganathan            Category - Standards Track                     3 
+                            KDC Referrals                 August 2004 
+ 
+ 
+   from any DNS domain independent of what Kerberos realm their 
+   principal resides in. 
+    
+5. Client Name Canonicalization 
+    
+   A client account may have multiple principal names. More useful, 
+   though, is a globally unique name that allows unification of email 
+   and security principal names. For example, all users at MS may have 
+   a client principal name of the form "joe@MS.COM" even though the 
+   principals are contained in multiple realms. This global name is 
+   again an alias for the true client principal name, which indicates 
+   what realm contains the principal. Thus, accounts "alice" in the 
+   realm NT.MS.COM and "bob" in OFFICE.MS.COM may logon as 
+   "alice@MS.COM" and "bob@MS.COM". 
+    
+   This utilizes a new client principal name type, as the AS-REQ 
+   message only contains a single realm field, and the realm portion of 
+   this name doesn't correspond to any Kerberos realm. Thus, the entire 
+   name "alice@MS.COM" is transmitted in the client name field of the 
+   AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 
+    
+        KRB-NT-ENTERPRISE-PRINCIPAL     10 
+    
+   The KDC will recognize this name type and then transform the 
+   requested name into the true principal name. The true principal name 
+   can be using a name type different from the requested name type. 
+   Typically the returned principal name will be a KRB-NT-PRINCIPAL. 
+   The returned name will be the same in the AS response and in the 
+   ticket. The KDC will always return a different name type than KRB-
+   NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the 
+   "canonicalize" KDC option. 
+    
+   If the "canonicalize" KDC option is set, then the KDC MAY change the 
+   client principal name and type in the AS response and ticket 
+   regardless of the name type of the client name in the request. For 
+   example the AS request may specify a client name of "fred@MS.COM" as 
+   an KRB-NT-PRINCIPAL with the "canonicalize" KDC option set and the 
+   KDC will return with a client name of "104567" as a KRB-NT-UID. 
+     
+6. Requesting a referral 
+    
+   In order to request referrals, the Kerberos client must explicitly 
+   request the canonicalize KDC option (bit 15) in the KDC options for 
+   the TGS-REQ. This flag indicates to the KDC that the client is 
+   prepared to receive a reply that contains a principal name other 
+   than the one requested. Thus, the KDCOptions types is redefined as: 
+    
+        KDCOptions ::=   BIT STRING { 
+                          reserved(0), 
+                          forwardable(1), 
+                          forwarded(2), 
+                          proxiable(3), 
+                          proxy(4), 
+  
+Jaganathan            Category - Standards Track                     4 
+                            KDC Referrals                 August 2004 
+ 
+ 
+                          allow-postdate(5), 
+                          postdated(6), 
+                          unused7(7), 
+                          renewable(8), 
+                          unused9(9), 
+                          unused10(10), 
+                          unused11(11), 
+                          canonicalize(15), 
+                          renewable-ok(27), 
+                          enc-tkt-in-skey(28), 
+                          renew(30), 
+                          validate(31) 
+         } 
+         
+   The client should expect, when sending names with the "canonicalize" 
+   KDC option, that names in the KDC's reply will be different than the 
+   name in the request. 
+    
+6.1 Client Referrals 
+    
+   The simplest form of ticket referral is for a user requesting a 
+   ticket using an AS-REQ. In this case, the client machine will send 
+   the AS request to a convenient trusted realm, either the realm of 
+   the client machine or the realm of the client name. In the case of 
+   the name Alice@MS.COM, the client may optimistically choose to send 
+   the request to MS.COM. The realm in the AS request is always the 
+   name of the realm that the request is for as specified in [3]. 
+    
+   The client will send the string "alice@MS.COM" in the client 
+   principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 
+   with the crealm set to MS.COM. The KDC will try to lookup the name 
+   in its local account database. If the account is present in the 
+   realm of the request, it MUST return a KDC reply structure with the 
+   appropriate ticket. 
+    
+   If the account is not present in the realm specified in the request 
+   and the "canonicalize" KDC option is set, the KDC will try to lookup 
+   the entire name, Alice@MS.COM, using a name service. If this lookup 
+   is unsuccessful, it MUST return the error 
+   KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it MUST 
+   return an error KDC_ERR_WRONG_REALM (0x44) and in the error message 
+   the crealm field will contain the the true realm of the client or 
+   another realm that has better information about the client's true 
+   realm. The client MUST NOT use a cname returned from a referral. 
+    
+   If the KDC contains the account locally and "canonicalize" KDC 
+   option is not set, it MUST return a normal ticket. The client name 
+   and realm portions of the ticket and KDC reply message MUST be the 
+   client's true name in the realm, not the globally unique name. 
+    
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 
+   new AS request with the same client principal name used to generate 
+   the first referral to the realm specified by the realm field of the 
+  
+Jaganathan            Category - Standards Track                     5 
+                            KDC Referrals                 August 2004 
+ 
+ 
+   kerberos error message from the first request. This request MUST 
+   produce a valid AS response with a ticket for the canonical user 
+   name.  
+    
+   An implementation should limit the number of referrals that it 
+   processes to avoid infinite referral loops. A suggested limit is 5 
+   referrals before giving up. In MicrosoftÆs implementation the 
+   default limit is 3 since through the use of the global catalog any 
+   domain in one forest is reachable from any other domain in another 
+   trusting forest with 3 or less referrals.  
+    
+6.2 Service Referrals 
+    
+   The primary problem is that the KDC must return a referral ticket 
+   rather than an error message as is done in AS request referrals. 
+   There needs to be a place to include in the TGS response information 
+   about what realm contains the service. This is done by returning 
+   information about the service name in the pre-auth data field of the 
+   KDC reply. 
+    
+   If the KDC resolves the service principal name into a principal in 
+   the realm specified by the service realm name, it will return a 
+   normal ticket. When using canonicalization, the client can omit the 
+   service realm name. If it is supplied, it is used as a hint by the 
+   KDC, but the service principal lookup is not constrained to locating 
+   the service principal name in that specified realm. If the 
+   "canonicalize" flag in the KDC options is not set, then the KDC MUST 
+   only look up the name as a normal principal name in the specified 
+   service realm.  
+    
+   If the "canonicalize" flag in the KDC options is set and the KDC 
+   doesn't find the principal locally, the KDC can return a cross-realm 
+   ticket granting ticket to the next hop on the trust path towards a 
+   realm that may be able to resolve the principal name. 
+    
+   If the KDC can determine the service principal's realm, it SHOULD 
+   return the service realm as KDC supplied pre-authentication data 
+   element. The preauth data MUST be encrypted using the sub-session 
+   key from the authenticator if present or the session key from the 
+   ticket. 
+    
+   The data itself is an ASN.1 encoded structure containing the 
+   server's realm, and if known, the real principal name.  
+    
+                PA-SERVER-REFERRAL-INFO        25 
+                 
+                PA-SERVER-REFERRAL :: = KERB-ENCRYPTED-DATA  
+                                           -- PA-SERVER-REFERRAL-DATA 
+                 
+                PA-SERVER-REFERRAL-DATA ::= SEQUENCE { 
+                        referred-server-realm[0]  KERB-REALM 
+                        referred-name[1]         PrincipalName OPTIONAL 
+                        ... 
+  
+Jaganathan            Category - Standards Track                     6 
+                            KDC Referrals                 August 2004 
+ 
+ 
+                } 
+    
+    
+   If applicable to the encryption type, the key derivation value will 
+   for the PA-SERVER-REFERRAL is 22. 
+    
+   If the referred-name field is present, the client MUST use that name 
+   in a subsequent TGS request to the service realm when following the 
+   referral. 
+    
+   The client will use this information to request a chain of cross-
+   realm ticket granting tickets until it reaches the realm of the 
+   service, and can then expect to receive a valid service ticket.  
+    
+   However an implementation should limit the number of referrals that 
+   it processes to avoid infinite referral loops. A suggested limit is 
+   5 referrals before giving up. 
+    
+   This is an example of a client requesting a service ticket for a 
+   service in realm NT.MS.COM where the client is in OFFICE.MS.COM. 
+    
+        +NC = Canonicalize KDCOption set 
+        +PA-REFERRAL = returned PA-SERVER-REFERRAL-INFO 
+         
+        C: TGS-REQ sname=server/foo.nt.ms.com srealm=NULL +NC to 
+        OFFICE.MS.COM 
+        S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 
+        containing NT.MS.COM 
+        C: TGS-REQ sname=krbtgt/NT.MS.COM@MS.COM +NC to MS.COM 
+        S: TGS-REP sname=krbtgt/NT.MS.COM@MS.COM 
+        C: TGS-REQ sname=server/foo.nt.ms.com srealm=NT.MS.COM +NC to 
+        NT.MS.COM 
+        S: TGS-REP sname=server/foo.nt.ms.com@NT.MS.COM 
+    
+   Notice that the client only specifies the service name in the 
+   initial and final TGS request. 
+    
+7. Cross Realm Routing 
+    
+   The current Kerberos protocol requires the client to explicitly 
+   request a cross-realm TGT for each pair of realms on a referral 
+   chain. As a result, the client need to be aware of the trust 
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts). Instead, the client should be able to request a TGT 
+   to the target realm from each realm on the route. The KDC will 
+   determine the best path for the client and return a cross-realm TGT. 
+   The client has to be aware that a request for a cross-realm TGT may 
+   return a TGT for a realm different from the one requested. 
+    
+   For compatibility, the client MUST use the "canonicalize" KDC option 
+   if it is able to use cross-realm routing from the KDC. 
+    
+8. Compatibility with earlier implementations of name canonicalization 
+  
+Jaganathan            Category - Standards Track                     7 
+                            KDC Referrals                 August 2004 
+ 
+ 
+    
+   The Microsoft Windows 2000 release included an earlier form of name-
+   canonicalization [4]. It has these differences: 
+    
+   1) The TGS referral data was returned inside of the KDC message as 
+      "encrypted pre auth data". 
+    
+                KERB-ENCRYPTED-KDC-REPLY ::=  SEQUENCE { 
+                        session-key[0]   KERB-ENCRYPTION-KEY, 
+                        last-request[1]  PKERB-LAST-REQUEST, 
+                        nonce[2]         INTEGER, 
+                        key-expiration[3] KERB-TIME OPTIONAL, 
+                        flags[4]         KERB-TICKET-FLAGS, 
+                        authtime[5]      KERB-TIME, 
+                        starttime[6]     KERB-TIME OPTIONAL, 
+                        endtime[7]       KERB-TIME, 
+                        renew-until[8]   KERB-TIME OPTIONAL, 
+                        server-realm[9]  KERB-REALM, 
+                        server-name[10]  KERB-PRINCIPAL-NAME, 
+                        client-addresses[11] PKERB-HOST-ADDRESSES 
+                OPTIONAL, 
+                        encrypted-pa-data[12] SEQUENCE OF KERB-PA-DATA 
+                OPTIONAL 
+                } 
+    
+   2) The preauth data type definition in the encrypted preauth data is 
+      as follows: 
+    
+                PA-SVR-REFERRAL-INFO        20 
+                 
+                PA-SVR-REFERRAL-DATA ::= SEQUENCE { 
+                        referred-server-name[1]  PrincipalName OPTIONAL 
+                        referred-server-realm[0] KERB-REALM 
+                } 
+    
+     
+9. Security Considerations 
+ 
+   In the case of TGS requests the client may be vulnerable to a denial 
+   of service attack by an attacker that replays replies from previous 
+   requests. The client can verify that the request was one of its own 
+   by checking the client-address field or authtime field, though, so 
+   the damage is limited and detectable. Clients MUST NOT process cross 
+   realm referral TGTs if the KDC reply does not include the encrypted 
+   PA-SERVER-REFERRAL-INFO.  
+    
+   For the AS exchange case, it is important that the logon mechanism 
+   not trust a name that has not been used to authenticate the user. 
+   For example, the name that the user enters as part of a logon 
+   exchange may not be the name that the user authenticates as, given 
+   that the KDC_ERR_WRONG_REALM error may have been returned. The 
+   relevant Kerberos naming information for logon (if any), is the 
+
+  
+Jaganathan            Category - Standards Track                     8 
+                            KDC Referrals                 August 2004 
+ 
+ 
+   client name and client realm in the service ticket targeted at the 
+   workstation that was obtained using the user's initial TGT. 
+    
+   How the client name and client realm is mapped into a local account 
+   for logon is a local matter, but the client logon mechanism MUST use 
+   additional information such as the client realm and/or authorization 
+   attributes from the service ticket presented to the workstation by 
+   the user, when mapping the logon credentials to a local account on 
+   the workstation. 
+ 
+10. Acknowledgements 
+   The authors wish to thank Ken Raeburn for his comments and 
+   suggestions.  
+ 
+11.1 Normative 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  Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 
+      Raeburn, "The Kerberos Network Authentication Service (V5)", 
+      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 
+      2002.  Work in progress. 
+ 
+11.2 Informative References 
+    
+    
+   4  J. Trostle, I. Kosinovsky, and M. Swift,"Implementation of 
+      Crossrealm Referral Handling in the MIT Kerberos Client", In 
+      Network and Distributed System Security Symposium, February 2001. 
+    
+    
+12. Author's Addresses 
+    
+   Karthik Jaganathan 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: karthikj@Microsoft.com 
+    
+   Larry Zhu 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: lzhu@Microsoft.com 
+    
+   Michael Swift 
+   University of Washington 
+  
+Jaganathan            Category - Standards Track                     9 
+                            KDC Referrals                 August 2004 
+ 
+ 
+   Seattle, Washington 
+   Email: mikesw@cs.washington.edu 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@Microsoft.com 
+    
+   Jonathan Trostle 
+   Cisco Systems 
+   170 W. Tasman Dr. 
+   San Jose, CA 95134 
+   Email: jtrostle@cisco.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Jaganathan            Category - Standards Track                    10 
+                            KDC Referrals                 August 2004 
+ 
+ 
+   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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Jaganathan            Category - Standards Track                    11 
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt
new file mode 100644
index 00000000000..98d97a377af
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt
@@ -0,0 +1,767 @@
+Kerberos Working Group                               Karthik Jaganathan
+Internet Draft                                                Larry Zhu
+Document: draft-ietf-krb-wg-kerberos-referrals-04.txt       John Brezak
+Category: Standards Track                                     Microsoft
+                                                             Mike Swift
+                                               University of Washington
+                                                       Jonathan Trostle
+                                                          Cisco Systems
+                                                  Expires: January 2005
+
+
+           Generating KDC Referrals to locate Kerberos realms
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC-2026 [1].
+
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
+   Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+
+   The draft documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services. The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path. The clients will use this
+   referral information to reach the realm of the target principal and
+   then receive the ticket.
+
+
+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].
+
+
+1. Introduction
+
+
+
+
+Jaganathan                                                      [Page 1]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [3], use principal names constructed from a known user or
+   service name and realm. A service name is typically constructed from
+   a name of the service and the DNS host name of the computer that is
+   providing the service. Many existing deployments of Kerberos use a
+   single Kerberos realm where all users and services would be using the
+   same realm.  However in an environment where there are multiple
+   trusted Kerberos realms, the client needs to be able to determine
+   what realm a particular user or service is in before making an AS or
+   TGS request. Traditionally this requires client configuration to make
+   this possible.
+
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request. However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name. A good example of this
+   is an RFC-821 style email name [4]. This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name. In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC. The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm. Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm. To do this requires that the client be
+   able to determine what realm the target service principal is in
+   before making the TGS request. Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  In order for this to work on the client, each
+   application canonicalizes the host name of the service, for example
+   by doing a DNS lookup followed by a reverse lookup using the returned
+   IP address. The returned primary host name is then used in the
+   construction of the principal name for the target service. In order
+   for the correct realm to be added for the target host, the mapping
+   table [domain_to_realm] is consulted for the realm corresponding to
+   the DNS host name. The corresponding realm is then used to complete
+   the target service principal name.
+
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms. Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+   the environment.
+
+
+
+
+
+Jaganathan                                                      [Page 2]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+   organization (remote server). The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization. Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name. This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name. You could give that remote server an identity in the local
+   realm and then have that remote server maintain a separate secret for
+   each alias it is known as. Alternatively you could arrange to have
+   the local realm issue a referral to the remote realm and notify the
+   requesting client of the server's remote name that should be used in
+   order to request a ticket.
+
+
+   This draft proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos. Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and provide a mechanism for
+   the KDC to determine the trusted realm authentication path by being
+   able to generate referrals to other realms in order to locate
+   principals.
+
+
+   To rectify these problems, this draft introduces three new kinds of
+   KDC referrals:
+
+
+   1. AS ticket referrals, in which the client doesn't know which realm
+   contains a user account.
+   2. TGS ticket referrals, in which the client doesn't know which realm
+   contains a server account.
+   3. Cross realm shortcut referrals, in which the KDC chooses the next
+   path on a referral chain
+
+
+2. Requesting a referral
+
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [3] for the AS-REQ or TGS-REQ. This flag indicates to the
+   KDC that the client is prepared to receive a reply that contains a
+   principal name other than the one requested.
+
+
+       KDCOptions ::= KerberosFlags
+                -- canonicalize (15)
+                -- other KDCOptions values omitted
+
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+
+
+
+
+Jaganathan                                                      [Page 3]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   name in the request. A referral ticket is a cross realm TGT that is
+   returned when the sname of the ticket is not the sname in the request
+   [3].
+
+
+3. Realm Organization Model
+
+
+   This draft assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world. A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship. The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm. This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+
+
+                     MS.COM
+                   /        \
+                  /          \
+           OFFICE.MS.COM  NTDEV.MS.COM
+
+
+
+   In this configuration, all users in the MS.COM enterprise could have
+   a principal name such as alice@MS.COM, with the same realm portion.
+   In addition, servers at MS.COM should be able to have DNS host names
+   from any DNS domain independent of what Kerberos realm their
+   principals reside in.
+
+
+4. Client Name Canonicalization
+
+
+   A client account may have multiple principal names. More useful,
+   though, is a globally unique name that allows unification of email
+   and security principal names. For example, all users at MS may have a
+   client principal name of the form "joe@MS.COM" even though the
+   principals are contained in multiple realms. This global name is
+   again an alias for the true client principal name, which indicates
+   what realm contains the principal. Thus, accounts "alice" in the
+   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
+   "alice@MS.COM" and "bob@MS.COM".
+
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+   name doesn't correspond to any Kerberos realm. Thus, the entire name
+   "alice@MS.COM" is transmitted as a single component in the client
+   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
+   [3]. The KDC will recognize this name type and then transform the
+
+
+
+
+Jaganathan                                                      [Page 4]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   requested name into the true principal name.  The true principal name
+   can be using a name type different from the requested name type.
+   Typically the true principal name will be a NT-PRINCIPAL [3].
+
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request. For example the
+   AS request may specify a client name of "bob@MS.COM" as an NT-
+   PRINCIPAL with the "canonicalize" KDC option set and the KDC will
+   return with a client name of "104567" as a NT-UID.
+
+
+5. Client Referrals
+
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ. In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine. In the case of the name alice@MS.COM, the client
+   MAY optimistically choose to send the request to MS.COM. The realm in
+   the AS-REQ is always the name of the realm that the request is for as
+   specified in [3].
+
+
+   The KDC will try to lookup the name in its local account database. If
+   the account is present in the realm of the request, it SHOULD return
+   a KDC reply structure with the appropriate ticket.
+
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@MS.COM, using a name service. If this lookup
+   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
+   [3].  If the lookup is successful, it MUST return an error
+   KDC_ERR_WRONG_REALM [3] and in the error message the crealm field
+   will contain either the true realm of the client or another realm
+   that MAY have better information about the client's true realm. The
+   client MUST NOT use a cname returned from a referral.
+
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message from the first request. The client SHOULD
+   repeat these steps until it finds the true realm of the client. To
+   avoid infinite referral loops, an implementation should limit the
+   number of referrals.  A suggested limit is 5 referrals before giving
+   up. In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.
+
+
+6. Service Referrals
+
+
+
+
+Jaganathan                                                      [Page 5]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   The primary problem in service referrals is that the KDC must return
+   a referral ticket rather than an error message as is done in AS
+   ticket referrals. There needs to be a place to include in the TGS-REP
+   information about what realm contains the service. This is done by
+   returning information about the service name in the pre-
+   authentication data field of the KDC reply [3].
+
+
+   If the KDC resolves the service principal name into a principal in
+   the realm specified by the service realm name, it will return a
+   normal ticket.
+
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified service realm. If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.
+
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response. The pre-authentication data MUST be
+   encrypted using the sub-session key from the authenticator if present
+   or the session key from the ticket. The pre-authentication data
+   contains the referred realm, and if known, the real principal name.
+
+
+       PA-SERVER-REFERRAL      25
+
+
+       PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                             -- ServerReferalData --
+
+
+       ServerReferralData ::= SEQUENCE {
+              referred-realm         [0] Realm,
+                             -- target realm of the referral TGT
+              referred-name          [1] PrincipalName OPTIONAL,
+                             -- service principal name, MAY differ
+                             -- from the server name in the request
+              ...
+       }
+
+
+   Clients MUST NOT process referral tickets if the KDC response does
+   not contain the PA-SERVER-REFERRAL.
+
+
+   If applicable to the encryption type, the key usage value for the
+   encryption key used by PA-SERVER-REFERRAL is 26 if the session key
+   from the ticket is used or 27 if a sub-session key is used.
+
+
+   If the referred-name field is present, the client MUST use that name
+
+
+
+
+Jaganathan                                                      [Page 6]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   in a subsequent TGS request to the service realm when following the
+   referral.
+
+
+   The client will use this information to request a chain of cross-
+   realm ticket granting tickets until it reaches the realm of the
+   service, and can then expect to receive a valid service ticket.
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops. A suggested limit is 5
+   referrals before giving up.
+
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+
+
+       +NC = Canonicalize KDCOption set
+       +PA-REFERRAL = returned PA-SERVER-REFERRAL
+       C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to OFFICE.MS.COM
+       S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
+          containing MS.COM as the referred realm with no referred name
+       C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to MS.COM
+       S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
+          containing NTDEV.MS.COM as the referred realm with no referred
+          name
+       C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to NTDEV.MS.COM
+       S: TGS-REP sname=server/foo.ntdev.ms.com@NTDEV.MS.COM
+
+
+7. Cross Realm Routing
+
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain. As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+
+   Instead, using this referral routing mechanism, The KDC will
+   determine the best path for the client and return a cross-realm TGT
+   as the referral TGT, and the target realm for this TGT in the PA-
+   SERVER-REFERRAL of the KDC reply.
+
+
+   If the "canonicalize" KDC option is not set, the KDC MUST NOT return
+   a referral ticket. Clients MUST NOT process referral tickets if the
+   KDC response does not contain the PA-SERVER-REFERRAL.
+
+
+8. Compatibility with earlier implementations of name canonicalization
+
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [5]. Here are the differences:
+
+
+   1) The TGS referral data is returned inside of the KDC message as
+
+
+
+
+Jaganathan                                                      [Page 7]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   "encrypted pre-authentication data".
+
+
+       EncKDCRepPart   ::= SEQUENCE {
+              key                [0] EncryptionKey,
+              last-req           [1] LastReq,
+              nonce              [2] UInt32,
+              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,
+              encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+      }
+
+
+   2) The preauth data type definition in the encrypted preauth data is
+   as follows:
+
+
+       PA-SVR-REFERRAL-INFO       20
+
+
+       PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+              referred-name   [1] PrincipalName OPTIONAL,
+              referred-realm  [0] Realm
+       }
+
+
+9. Security Considerations
+
+
+   In the case of TGS requests the client may be vulnerable to a denial
+   of service attack by an attacker that replays replies from previous
+   requests. The client can verify that the request was one of its own
+   by checking the client-address field or authtime field, though, so
+   the damage is limited and detectable.
+
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned. The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+
+
+
+
+Jaganathan                                                      [Page 8]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+
+10. Acknowledgements
+
+
+   The authors wish to thank Ken Raeburn for his comments and
+   suggestions.
+
+
+11. References
+
+
+11.1 Normative 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] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
+   Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos-
+   clarifications. Work in progress.
+
+
+   [4] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
+   1982.
+
+
+11.2 Informative References
+
+
+   [5] Trostle, J., Kosinovsky, I., and Swift, M., "Implementation of
+   Crossrealm Referral Handling in the MIT Kerberos Client", In Network
+   and Distributed System Security Symposium, February 2001.
+
+
+12. Author's Addresses
+
+
+   Karthik Jaganathan
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington
+   Email: karthikj@Microsoft.com
+
+
+   Larry Zhu
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington
+   Email: lzhu@Microsoft.com
+
+
+   Michael Swift
+   University of Washington
+
+
+
+
+Jaganathan                                                      [Page 9]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+   Seattle, Washington
+   Email: mikesw@cs.washington.edu
+
+
+   John Brezak
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington
+   Email: jbrezak@Microsoft.com
+
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+   Email: jtrostle@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan                                                     [Page 10]
+
+
+
+
+
+
+                              KDC Referrals                 January 2005
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan                                                     [Page 11]
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
new file mode 100644
index 00000000000..9b41e043045
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
@@ -0,0 +1,961 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Obsoletes: 2478 (if approved)                      Microsoft Corporation
+Expires: April 25, 2005                                 October 25, 2004
+
+
+           Generating KDC Referrals to locate Kerberos realms
+                  draft-ietf-krb-wg-kerberos-referrals-05
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on April 25, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+   referral information to reach the realm of the target principal and
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 1]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+   then receive the ticket.
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . .   5
+   3.   Requesting a Referral  . . . . . . . . . . . . . . . . . . .   6
+   4.   Realm Organization Model . . . . . . . . . . . . . . . . . .   7
+   5.   Client Name Canonicalization . . . . . . . . . . . . . . . .   8
+   6.   Client Referrals . . . . . . . . . . . . . . . . . . . . . .   9
+   7.   Server Referrals . . . . . . . . . . . . . . . . . . . . . .  10
+   8.   Cross Realm Routing  . . . . . . . . . . . . . . . . . . . .  12
+   9.   Compatibility with Earlier Implementations of Name
+        Canonicalization . . . . . . . . . . . . . . . . . . . . . .  13
+   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
+   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  15
+   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
+   12.1   Normative References . . . . . . . . . . . . . . . . . . .  16
+   12.2   Informative References . . . . . . . . . . . . . . . . . .  16
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  16
+        Intellectual Property and Copyright Statements . . . . . . .  17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 2]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [KRBCLR], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name [RFC822].  This document
+   describes a mechanism that would allow a user to specify a user
+   principal name that is an alias for the user's Kerberos principal
+   name.  In practice this would be the name that the user specifies to
+   obtain a TGT from a Kerberos KDC.  The user principal name no longer
+   has a direct relationship with the Kerberos principal or realm.  Thus
+   the administrator is able to move the user's principal to other
+   realms without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  In order for this to work on the client, each
+   application canonicalizes the host name of the service, for example
+   by doing a DNS lookup followed by a reverse lookup using the returned
+   IP address.  The returned primary host name is then used in the
+   construction of the principal name for the target service.  In order
+   for the correct realm to be added for the target host, the mapping
+   table [domain_to_realm] is consulted for the realm corresponding to
+   the DNS host name.  The corresponding realm is then used to complete
+   the target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 3]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  You could give that remote server an identity in the local
+   realm and then have that remote server maintain a separate secret for
+   each alias it is known as.  Alternatively you could arrange to have
+   the local realm issue a referral to the remote realm and notify the
+   requesting client of the server's remote name that should be used in
+   order to request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and provide a mechanism for
+   the KDC to determine the trusted realm authentication path by being
+   able to generate referrals to other realms in order to locate
+   principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1.  Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2.  Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 4]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 5]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+3.  Requesting a Referral
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [KRBCLR] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [KRBCLR].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 6]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                        MS.COM
+                      /        \
+                     /          \
+              OFFICE.MS.COM  NTDEV.MS.COM
+
+   In this configuration, all users in the MS.COM enterprise could have
+   a principal name such as alice@MS.COM, with the same realm portion.
+   In addition, servers at MS.COM should be able to have DNS host names
+   from any DNS domain independent of what Kerberos realm their
+   principals reside in.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 7]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+5.  Client Name Canonicalization
+
+   A client account may have multiple principal names.  More useful,
+   though, is a globally unique name that allows unification of email
+   and security principal names.  For example, all users at MS may have
+   a client principal name of the form "joe@MS.COM" even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
+   "alice@MS.COM" and "bob@MS.COM".
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+   name doesn't correspond to any Kerberos realm.  Thus, the entire name
+   "alice@MS.COM" is transmitted as a single component in the client
+   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
+   [KRBCLR].  The KDC will recognize this name type and then transform
+   the requested name into the true principal name.  The true principal
+   name can be using a name type different from the requested name type.
+   Typically the true principal name will be a NT-PRINCIPAL [KRBCLR].
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request.  For example
+   the AS request may specify a client name of "bob@MS.COM" as an
+   NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC
+   will return with a client name of "104567" as a NT-UID.
+
+   It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 8]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+6.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@MS.COM, the client
+   MAY optimistically choose to send the request to MS.COM.  The realm
+   in the AS-REQ is always the name of the realm that the request is for
+   as specified in [KRBCLR].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@MS.COM, using a name service.  If this lookup
+   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
+   [KRBCLR].  If the lookup is successful, it MUST return an error
+   KDC_ERR_WRONG_REALM [KRBCLR] and in the error message the crealm
+   field will contain either the true realm of the client or another
+   realm that MAY have better information about the client's true realm.
+   The client SHALL NOT use a cname returned from a referral until that
+   name is validated.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message from the first request.  The client SHOULD
+   repeat these steps until it finds the true realm of the client.  To
+   avoid infinite referral loops, an implementation should limit the
+   number of referrals.  A suggested limit is 5 referrals before giving
+   up.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitional direct rusts between them.
+
+   The true principal name of the client, carried via the KRB_ERROR
+   message, can be validated in a subsequent TGS message exchange where
+   its value is communicated back to the KDC via the authenticator in
+   the PA-TGS-REQ padata [KRBCLR].
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                 [Page 9]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+7.  Server Referrals
+
+   The primary difference in server referrals is that the KDC MUST
+   return a referral TGT rather than an error message as is done in the
+   client referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server.  This is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [KRBCLR], as specified later in this
+   section.
+
+   If the KDC resolves the server principal name into a principal in the
+   realm specified by the service realm name, it will return a normal
+   ticket.
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified server realm.  If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.  The true principal name of the server SHALL be
+   returned in the padata of the reply if it is different from what is
+   specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in
+   pre-authentication data MUST be encrypted using the session key from
+   the reply ticket.  The key usage value for the encryption operation
+   used by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+          PA-SERVER-REFERRAL      25
+
+          PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                                -- ServerReferralData --
+
+          ServerReferralData ::= SEQUENCE {
+                 referred-realm         [0] Realm, OPTIONAL
+                                -- target realm of the referral TGT
+                 true-principal-name    [1] PrincipalName OPTIONAL,
+                                -- true server principal name
+                 ...
+          }
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 10]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+   Clients SHALL NOT accept a reply ticket, whose the server principal
+   name is different from that of the request,  if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the
+   PA-SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+
+          +NC = Canonicalize KDCOption set
+          +PA-REFERRAL = returned PA-SERVER-REFERRAL
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
+          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
+             containing MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
+          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
+             containing NTDEV.MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
+          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 11]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+8.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 7, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 12]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+9.  Compatibility with Earlier Implementations of Name Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 13]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+10.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 14]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+11.  Acknowledgments
+
+   The authors wish to thank Ken Raeburn for his comments and
+   suggestions.
+
+   Sam Hartman, Ken Raeburn, and authors came up with the idea of using
+   the ticket key to encrypt the referral data, which prevents cut and
+   paste attack using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 15]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+12.  References
+
+12.1  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [KRBCLR]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 
+              Kerberos Network Authentication Service (V5)", 
+              draft-ietf-krb-wg-kerberos-clarifications. Work in 
+              progress.
+              
+   [RFC822]   Crocker, D., "Standard for the Format of ARPA Internet 
+              Text Messages", RFC 822, August 1982.
+
+12.2  Informative References
+
+   [XPR]      Trostle, J., Kosinovsky, I., and Swift, M., 
+              "Implementation of Crossrealm Referral Handling in the 
+              MIT Kerberos Client", In Network and Distributed System 
+              Security Symposium, February 2001.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 16]
+
+Internet-Draft               KDC Referrals                  October 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Jaganathan         Expires April 25, 2005                [Page 17]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-06.txt
new file mode 100644
index 00000000000..238baaea8a3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-06.txt
@@ -0,0 +1,733 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Updates: 4120 (if approved)                        Microsoft Corporation
+Expires: January 20, 2006                                  July 19, 2005
+
+
+           Generating KDC Referrals to locate Kerberos realms
+                draft-ietf-krb-wg-kerberos-referrals-06
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 20, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+   referral information to reach the realm of the target principal and
+   then receive the ticket.
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 1]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
+   3.   Requesting a Referral  . . . . . . . . . . . . . . . . . . .   4
+   4.   Realm Organization Model . . . . . . . . . . . . . . . . . .   5
+   5.   Client Name Canonicalization . . . . . . . . . . . . . . . .   5
+   6.   Client Referrals . . . . . . . . . . . . . . . . . . . . . .   6
+   7.   Server Referrals . . . . . . . . . . . . . . . . . . . . . .   7
+   8.   Cross Realm Routing  . . . . . . . . . . . . . . . . . . . .   9
+   9.   Compatibility with Earlier Implementations of Name
+        Canonicalization . . . . . . . . . . . . . . . . . . . . . .   9
+   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
+   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11
+   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     12.1   Normative References . . . . . . . . . . . . . . . . . .  11
+     12.2   Informative References . . . . . . . . . . . . . . . . .  11
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  12
+        Intellectual Property and Copyright Statements . . . . . . .  13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 2]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [RFC4120], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name.  This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name.  In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC.  The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm.  Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  In order for this to work on the client, each
+   application canonicalizes the host name of the service, for example
+   by doing a DNS lookup followed by a reverse lookup using the returned
+   IP address.  The returned primary host name is then used in the
+   construction of the principal name for the target service.  In order
+   for the correct realm to be added for the target host, the mapping
+   table [domain_to_realm] is consulted for the realm corresponding to
+   the DNS host name.  The corresponding realm is then used to complete
+   the target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 3]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  You could give that remote server an identity in the local
+   realm and then have that remote server maintain a separate secret for
+   each alias it is known as.  Alternatively you could arrange to have
+   the local realm issue a referral to the remote realm and notify the
+   requesting client of the server's remote name that should be used in
+   order to request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and provide a mechanism for
+   the KDC to determine the trusted realm authentication path by being
+   able to generate referrals to other realms in order to locate
+   principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+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 [RFC2119].
+
+3.  Requesting a Referral
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 4]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                        MS.COM
+                      /        \
+                     /          \
+              OFFICE.MS.COM  NTDEV.MS.COM
+
+   In this configuration, all users in the MS.COM enterprise could have
+   a principal name such as alice@MS.COM, with the same realm portion.
+   In addition, servers at MS.COM should be able to have DNS host names
+   from any DNS domain independent of what Kerberos realm their
+   principals reside in.
+
+5.  Client Name Canonicalization
+
+   A client account may have multiple principal names.  More useful,
+   though, is a globally unique name that allows unification of email
+   and security principal names.  For example, all users at MS may have
+   a client principal name of the form "joe@MS.COM" even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as "alice@
+   MS.COM" and "bob@MS.COM".
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 5]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+   name doesn't correspond to any Kerberos realm.  Thus, the entire name
+   "alice@MS.COM" is transmitted as a single component in the client
+   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
+   [RFC4120].  The KDC will recognize this name type and then transform
+   the requested name into the true principal name.  The true principal
+   name can be using a name type different from the requested name type.
+   Typically the true principal name will be a NT-PRINCIPAL [RFC4120].
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request.  For example
+   the AS request may specify a client name of "bob@MS.COM" as an NT-
+   ENTERPRISE name with the "canonicalize" KDC option set and the KDC
+   will return with a client name of "104567" as a NT-UID.
+
+   It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.
+
+6.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@MS.COM, the client
+   MAY optimistically choose to send the request to MS.COM.  The realm
+   in the AS-REQ is always the name of the realm that the request is for
+   as specified in [RFC4120].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@MS.COM, using a name service.  If this lookup
+   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
+   [RFC4120].  If the lookup is successful, it MUST return an error
+   KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm
+   field will contain either the true realm of the client or another
+   realm that MAY have better information about the client's true realm.
+   The client SHALL NOT use a cname returned from a referral until that
+   name is validated.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message from the first request.  The client SHOULD
+   repeat these steps until it finds the true realm of the client.  To
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 6]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+   avoid infinite referral loops, an implementation should limit the
+   number of referrals.  A suggested limit is 5 referrals before giving
+   up.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct rusts between them.
+
+   The true principal name of the client, returned in AS-REQ, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].
+
+7.  Server Referrals
+
+   The primary difference in server referrals is that the KDC MUST
+   return a referral TGT rather than an error message as is done in the
+   client referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server.  This is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [RFC4120], as specified later in this
+   section.
+
+   If the KDC resolves the server principal name into a principal in the
+   realm specified by the service realm name, it will return a normal
+   ticket.
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified server realm.  If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.  The true principal name of the server SHALL be
+   returned in the padata of the reply if it is different from what is
+   specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in pre-
+   authentication data MUST be encrypted using the session key from the
+   reply ticket.  The key usage value for the encryption operation used
+   by PA-SERVER-REFERRAL is 26.
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 7]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+          PA-SERVER-REFERRAL      25
+
+          PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                                -- ServerReferralData --
+
+          ServerReferralData ::= SEQUENCE {
+                 referred-realm         [0] Realm OPTIONAL,
+                                -- target realm of the referral TGT
+                 true-principal-name    [1] PrincipalName OPTIONAL,
+                                -- true server principal name
+                 ...
+          }
+
+   Clients SHALL NOT accept a reply ticket, whose the server principal
+   name is different from that of the request, if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the PA-
+   SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+
+
+
+
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 8]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+          +NC = Canonicalize KDCOption set
+          +PA-REFERRAL = returned PA-SERVER-REFERRAL
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
+          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
+             containing MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
+          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
+             containing NTDEV.MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
+          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
+
+
+8.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 7, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+9.  Compatibility with Earlier Implementations of Name Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006                [Page 9]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+   3) When [PKINIT] is used, the NT-ENTERPRISE client name is encoded as
+      a Subject Alternative Name (SAN) extension [RFC3280] in the
+      client's X.509 certificate.  The type of the otherName field for
+      this SAN extension is AnotherName [RFC3280].  The type-id field of
+      the type AnotherName is id-ms-sc-logon-upn
+      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+10.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006               [Page 10]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+11.  Acknowledgments
+
+   The authors wish to thank Ken Raeburn for his comments and
+   suggestions.
+
+   Sam Hartman, Ken Raeburn, and authors came up with the idea of using
+   the ticket key to encrypt the referral data, which prevents cut and
+   paste attack using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+12.  References
+
+12.1  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+                            
+   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              cat-kerberos-pk-init.  Work in Progress. 
+
+12.2  Informative References
+
+   [XPR]      Trostle, J., Kosinovsky, I., and Swift, M., 
+              "Implementation of Crossrealm Referral Handling in the 
+              MIT Kerberos Client", In Network and Distributed System 
+              Security Symposium, February 2001.
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006               [Page 11]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006               [Page 12]
+
+Internet-Draft                KDC Referrals                    July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu & Jaganathan        Expires January 20, 2006               [Page 13]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-08.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-08.txt
new file mode 100644
index 00000000000..37061a2e132
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-08.txt
@@ -0,0 +1,896 @@
+
+
+
+NETWORK WORKING GROUP                                         K. Raeburn
+Internet-Draft                                                       MIT
+Updates: 4120 (if approved)                                       L. Zhu
+Expires: December 27, 2006                                 K. Jaganathan
+                                                   Microsoft Corporation
+                                                           June 25, 2006
+
+
+           Generating KDC Referrals to Locate Kerberos Realms
+                draft-ietf-krb-wg-kerberos-referrals-08
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on December 27, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 1]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   referral information to reach the realm of the target principal and
+   then receive the ticket.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+   5.  Client Name Canonicalization . . . . . . . . . . . . . . . . .  5
+   6.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
+   7.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Server Name Canonicalization (Informative) . . . . . . . . . . 10
+   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 10
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
+   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 12
+     14.2.  Informative References  . . . . . . . . . . . . . . . . . 12
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 13
+   Appendix B.  Document history  . . . . . . . . . . . . . . . . . . 14
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
+   Intellectual Property and Copyright Statements . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 2]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [RFC4120], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name.  This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name.  In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC.  The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm.  Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  In order for this to work on the client, each
+   application canonicalizes the host name of the service, for example
+   by doing a DNS lookup followed by a reverse lookup using the returned
+   IP address.  The returned primary host name is then used in the
+   construction of the principal name for the target service.  In order
+   for the correct realm to be added for the target host, the mapping
+   table [domain_to_realm] is consulted for the realm corresponding to
+   the DNS host name.  The corresponding realm is then used to complete
+   the target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 3]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  You could give that remote server an identity in the local
+   realm and then have that remote server maintain a separate secret for
+   each alias it is known as.  Alternatively you could arrange to have
+   the local realm issue a referral to the remote realm and notify the
+   requesting client of the server's remote name that should be used in
+   order to request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and provide a mechanism for
+   the KDC to determine the trusted realm authentication path by being
+   able to generate referrals to other realms in order to locate
+   principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+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 [RFC2119].
+
+
+3.  Requesting a Referral
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 4]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                        MS.COM
+                      /        \
+                     /          \
+              OFFICE.MS.COM  NTDEV.MS.COM
+
+   In this configuration, all users in the MS.COM enterprise could have
+   a principal name such as alice@MS.COM, with the same realm portion.
+   In addition, servers at MS.COM should be able to have DNS host names
+   from any DNS domain independent of what Kerberos realm their
+   principals reside in.
+
+
+5.  Client Name Canonicalization
+
+   A client account may have multiple principal names.  More useful,
+   though, is a globally unique name that allows unification of email
+   and security principal names.  For example, all users at MS may have
+   a client principal name of the form "joe@MS.COM" even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may log on as "alice@
+   MS.COM" and "bob@MS.COM".
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 5]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+   name doesn't correspond to any Kerberos realm.  Thus, the entire name
+   "alice@MS.COM" is transmitted as a single component in the client
+   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
+   [RFC4120] (and the local realm name).  The KDC will recognize this
+   name type and then transform the requested name into the true
+   principal name.  The true principal name can be using a name type
+   different from the requested name type.  Typically the true principal
+   name will be a NT-PRINCIPAL [RFC4120].
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request, and include a
+   mandatory PA-DATA object authenticating the client name mapping:
+
+   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
+     names          [0] SEQUENCE {
+       requested-name [0] PrincipalName,
+       real-name      [1] PrincipalName
+     },
+     canon-checksum [1] Checksum
+   }
+
+   The canon-checksum field is computed over the DER encoding of the
+   names sequences, using the returned session key and a key usage value
+   of (TBD).
+
+   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
+   not included.  If the client name is changed, and the PA-CLIENT-
+   CANONICALIZED field does not exist, or the checksum cannot be
+   verified, or the requested-name field doesn't match the originally-
+   transmitted request, the client should discard the response.
+
+   For example the AS request may specify a client name of "bob@MS.COM"
+   as an NT-ENTERPRISE name with the "canonicalize" KDC option set and
+   the KDC will return with a client name of "104567" as a NT-UID, and a
+   PA-CLIENT-CANONICALIZED field listing the NT-ENTERPRISE "bob@MS.COM"
+   principal as the requested-name and the NT-UID "104567" principal as
+   the real-name.
+
+   It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.
+
+   In order to enable one party in a user-to-user exchange to confirm
+   the identity of another when only the alias is known, the KDC MAY
+   include the following authorization data element, wrapped in AD-IF-
+   RELEVANT, in the initial credentials and copy it from a ticket-
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 6]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   granting ticket into additional credentials:
+
+   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
+     login-alias  [0] PrincipalName,
+     checksum     [1] Checksum
+   }
+
+   (Q: Wrapped inside KDCIssued too?  Use SEQUENCE OF PrincipalName?)
+
+   The checksum is computed over the DER encoding of the login-alias
+   field using (WHICH KEY?  If recipient can forge it, the KDC can't
+   trust it when returned, and would have to verify that the alias is
+   valid before copying it to additional credentials) and a key usage
+   number of (TBD).
+
+   The recipient of this authenticator must check the AD-LOGIN-ALIAS
+   name, if present, in addition to the normal client name field,
+   against the identity of the party with which it wishes to
+   authenticate; either should be allowed to match.  (Note that this is
+   not backwards compatible with [RFC4120]; if the server side of the
+   user-to-user exchange does not support this extension, and does not
+   know the true principal name, authentication may fail if the alias is
+   sought in the client name field.)
+
+
+6.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@MS.COM, the client
+   MAY optimistically choose to send the request to MS.COM.  The realm
+   in the AS-REQ is always the name of the realm that the request is for
+   as specified in [RFC4120].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@MS.COM, using a name service.  If this lookup
+   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
+   [RFC4120].  If the lookup is successful, it MUST return an error
+   KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm
+   field will contain either the true realm of the client or another
+   realm that MAY have better information about the client's true realm.
+   The client SHALL NOT use a cname returned from a referral until that
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 7]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   name is validated.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message from the first request.  (The client realm
+   name will be updated in the new request to refer to this new realm.)
+   The client SHOULD repeat these steps until it finds the true realm of
+   the client.  To avoid infinite referral loops, an implementation
+   should limit the number of referrals.  A suggested limit is 5
+   referrals before giving up.
+
+   Since the same client name is sent to the referring and referred-to
+   realms, both realms must recognize the same client names.  In
+   particular, the referring realm cannot (usefully) define principal
+   name aliases that the referred-to realm will not know.
+
+   The true principal name of the client, returned in AS-REQ, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].
+
+
+7.  Server Referrals
+
+   The primary difference in server referrals is that the KDC MUST
+   return a referral TGT rather than an error message as is done in the
+   client referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server.  This is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [RFC4120], as specified later in this
+   section.
+
+   If the KDC resolves the server principal name into a principal in the
+   realm specified by the service realm name, it will return a normal
+   ticket.
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified server realm.  If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.  The true principal name of the server SHALL be
+   returned in the padata of the reply if it is different from what is
+   specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 8]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in pre-
+   authentication data MUST be encrypted using the session key from the
+   reply ticket.  The key usage value for the encryption operation used
+   by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+          PA-SERVER-REFERRAL      25
+
+          PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                                -- ServerReferralData --
+
+          ServerReferralData ::= SEQUENCE {
+                 referred-realm           [0] Realm OPTIONAL,
+                                -- target realm of the referral TGT
+                 true-principal-name      [1] PrincipalName OPTIONAL,
+                                -- true server principal name
+                 requested-principal-name [2] PrincipalName OPTIONAL,
+                                -- requested server name
+                 ...
+          }
+
+   Clients SHALL NOT accept a reply ticket, whose the server principal
+   name is different from that of the request, if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The requested-principal-name MUST be included by the KDC, and MUST be
+   verified by the client, if the client sent an AS-REQ, as protection
+   against a man-in-the-middle modification to the AS-REQ message.
+
+   (Note that with the forthcoming rfc1510ter, the AS-REP may include an
+   option checksum of the AS-REQ, in which case this check would no
+   longer be necessary.)
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the PA-
+   SERVER-REFERRAL data.
+
+
+
+Raeburn, et al.         Expires December 27, 2006               [Page 9]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
+
+          +NC = Canonicalize KDCOption set
+          +PA-REFERRAL = returned PA-SERVER-REFERRAL
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
+          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
+             containing MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
+          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
+             containing NTDEV.MS.COM as the referred realm with no
+             true-principal-name
+          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
+          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
+
+   Note that any referral or alias processing of the server name in
+   user-to-user authentication should use the same data as client name
+   canonicalization or referral.  Otherwise, the name used by one user
+   to log in may not be useable by another for user-to-user
+   authentication to the first.
+
+
+8.  Server Name Canonicalization (Informative)
+
+   No attempt is being made in this document to provide a means for
+   dealing with local-realm server principal name canonicalization or
+   aliasing.  The most obvious use case for this would be a hostname-
+   based service principal name ("host/foobar.example.com"), with a DNS
+   alias ("foo") for the server host which is used by the client.  There
+   are other ways this can be handled, currently, though they may
+   require additional configuration on the application server or KDC or
+   both.
+
+
+9.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 10]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 7, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+10.  Caching Information
+
+   It is possible that the client may wish to get additional credentials
+   for the same service principal, perhaps with different authorization-
+   data restrictions or other changed attributes.  The return of a
+   server referral from a KDC can be taken as an indication that the
+   requested principal does not currently exist in the local realm.
+   Clearly, it would reduce network traffic if the clientn could cache
+   that information and use it when acquiring the second set of
+   credentials for a service, rather than always having to re-check with
+   the local KDC to see if the name has been created locally.
+
+   Rather than introduce a new timeout field for this cached
+   information, we can use the lifetime of the returned TGT in this
+   case.  When the TGT expires, the previously returned referral from
+   the local KDC should be considered invalid, and the local KDC must be
+   asked again for information for the desired service principal name.
+   If the client is still in contact with the service and needs to
+   reauthenticate to the same service regardless of local service
+   principal name assignments, it should use the referred-realm and
+   true-principal-name values when requesting new credentials.
+
+   Accordingly, KDC authors and maintainers should consider what factors
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+
+11.  Open Issues
+
+   When should client name aliases be included in credentials?
+
+   Should all known client name aliases be included, or only the one
+   used at initial ticket acquisition?
+
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 11]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+12.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+
+13.  Acknowledgments
+
+   Sam Hartman and authors came up with the idea of using the ticket key
+   to encrypt the referral data, which prevents cut and paste attack
+   using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+14.2.  Informative References
+
+   [I-D.ietf-cat-kerberos-pk-init]
+              Tung, B. and L. Zhu, "Public Key Cryptography for Initial
+              Authentication in Kerberos",
+              draft-ietf-cat-kerberos-pk-init-34 (work in progress),
+              February 2006.
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 12]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
+              of Crossrealm Referral Handling in the MIT Kerberos
+              Client",  Network and Distributed System Security
+              Symposium, February 2001.
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+
+
+
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 13]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+   3) When [I-D.ietf-cat-kerberos-pk-init] is used, the NT-ENTERPRISE
+      client name is encoded as a Subject Alternative Name (SAN)
+      extension [RFC3280] in the client's X.509 certificate.  The type
+      of the otherName field for this SAN extension is AnotherName
+      [RFC3280].  The type-id field of the type AnotherName is id-ms-sc-
+      logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct rusts between them.
+
+   While we might want to permit multiple aliases to exist and even be
+   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
+   one alias to exist, so this question had not previously arisen.
+
+
+Appendix B.  Document history
+
+   08 Moved Microsoft implementation info to appendix.  Clarify lack of
+      local server name canonicalization.  Added optional authz-data for
+      login alias, to support user-to-user case.  Added requested-
+      principal-name to ServerReferralData.  Added discussion of caching
+      information, and referral TGT lifetime.
+   07 Re-issued with new editor.  Fixed up some references.  Started
+      history.
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 14]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+Authors' Addresses
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   Email: raeburn@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 15]
+
+Internet-Draft                KDC Referrals                    June 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Raeburn, et al.         Expires December 27, 2006              [Page 16]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt
new file mode 100644
index 00000000000..24e3ace21d4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt
@@ -0,0 +1,896 @@
+
+
+
+NETWORK WORKING GROUP                                         K. Raeburn
+Internet-Draft                                                       MIT
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: September 6, 2007                                 March 5, 2007
+
+
+           Generating KDC Referrals to Locate Kerberos Realms
+                draft-ietf-krb-wg-kerberos-referrals-09
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on September 6, 2007.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+   referral information to reach the realm of the target principal and
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 1]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   then receive the ticket.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+   5.  Client Name Canonicalization . . . . . . . . . . . . . . . . .  5
+   6.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
+   7.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Server Name Canonicalization (Informative) . . . . . . . . . . 10
+   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 10
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
+   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 12
+     14.2.  Informative References  . . . . . . . . . . . . . . . . . 12
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 13
+   Appendix B.  Document history  . . . . . . . . . . . . . . . . . . 14
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
+   Intellectual Property and Copyright Statements . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 2]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [RFC4120], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name.  This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name.  In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC.  The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm.  Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  The user-supplied host name or its domain component
+   is looked up in this table (often using the result of some form of
+   host name lookup performed with insecure DNS queries, in violation of
+   [RFC4120]).  The corresponding realm is then used to complete the
+   target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 3]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  The administrator in the local realm could give that
+   remote server an identity in the local realm and then have that
+   remote server maintain a separate secret for each alias it is known
+   as.  Alternatively the administrator could arrange to have the local
+   realm issue a referral to the remote realm and notify the requesting
+   client of the server's remote name that should be used in order to
+   request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and allow the KDC to
+   determine the trusted realm authentication path by being able to
+   generate referrals to other realms in order to locate principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+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 [RFC2119].
+
+
+3.  Requesting a Referral
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 4]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                      EXAMPLE.COM
+                      /        \
+                     /          \
+          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
+
+   In this configuration, all users in the EXAMPLE.COM enterprise could
+   have principal names such as alice@EXAMPLE.COM, with the same realm
+   portion.  In addition, servers at EXAMPLE.COM should be able to have
+   DNS host names from any DNS domain independent of what Kerberos realm
+   their principals reside in.
+
+
+5.  Client Name Canonicalization
+
+   A client account may have multiple principal names.  More useful,
+   though, is a globally unique name that allows unification of email
+   and security principal names.  For example, all users at EXAMPLE.COM
+   may have a client principal name of the form "joe@EXAMPLE.COM" even
+   though the principals are contained in multiple realms.  This global
+   name is again an alias for the true client principal name, which
+   indicates what realm contains the principal.  Thus, accounts "alice"
+   in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log
+   on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 5]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   name corresponds to the Kerberos realm with which the request is
+   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
+   single component in the client name field of the AS-REQ message, with
+   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
+   The KDC will recognize this name type and then transform the
+   requested name into the true principal name if the client account
+   resides in the local realm.  The true principal name can have a name
+   type different from the requested name type.  Typically the true
+   principal name will be a NT-PRINCIPAL [RFC4120].
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request, and include a
+   mandatory PA-DATA object authenticating the client name mapping:
+
+   ReferralInfo ::= SEQUENCE {
+     requested-name  [0] PrincipalName,
+     mapped-name     [1] PrincipalName,
+     ...
+   }
+   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
+     names          [0] ReferralInfo,
+     canon-checksum [1] Checksum
+   }
+
+   The canon-checksum field is computed over the DER encoding of the
+   names sequences, using the AS reply key and a key usage value of
+   (TBD).
+
+   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
+   not included.  If the client name is changed, and the PA-CLIENT-
+   CANONICALIZED field does not exist, or the checksum cannot be
+   verified, or the requested-name field doesn't match the client name
+   in the originally-transmitted request, the client should discard the
+   response.
+
+   For example the AS request may specify a client name of "bob@
+   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
+   option set and the KDC will return with a client name of "104567" as
+   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
+   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
+   NT-UID "104567" principal as the mapped-name.
+
+   (It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.)
+
+   In order to enable one party in a user-to-user exchange to confirm
+   the identity of another when only the alias is known, the KDC MAY
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 6]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   include the following authorization data element, wrapped in AD-KDC-
+   ISSUED, in the initial credentials and copy it from a ticket-granting
+   ticket into additional credentials:
+
+   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
+     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
+   }
+
+   The login-aliases field lists one or more of the aliases the
+   principal may have used in the initial ticket request.
+
+   The recipient of this authenticator must check the AD-LOGIN-ALIAS
+   names, if present, in addition to the normal client name field,
+   against the identity of the party with which it wishes to
+   authenticate; either should be allowed to match.  (Note that this is
+   not backwards compatible with [RFC4120]; if the server side of the
+   user-to-user exchange does not support this extension, and does not
+   know the true principal name, authentication may fail if the alias is
+   sought in the client name field.)
+
+
+6.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@EXAMPLE.COM, the
+   client MAY optimistically choose to send the request to EXAMPLE.COM.
+   The realm in the AS-REQ is always the name of the realm that the
+   request is for as specified in [RFC4120].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@EXAMPLE.COM, using a name service.  If this
+   lookup is unsuccessful, it MUST return the error
+   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
+   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
+   error message the crealm field will contain either the true realm of
+   the client or another realm that MAY have better information about
+   the client's true realm.  The client SHALL NOT use a cname returned
+   from a Kerberos error until that name is validated.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 7]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message corresponding to the first request.  (The
+   client realm name will be updated in the new request to refer to this
+   new realm.)  The client SHOULD repeat these steps until it finds the
+   true realm of the client.  To avoid infinite referral loops, an
+   implementation should limit the number of referrals.  A suggested
+   limit is 5 referrals before giving up.
+
+   Since the same client name is sent to the referring and referred-to
+   realms, both realms must recognize the same client names.  In
+   particular, the referring realm cannot (usefully) define principal
+   name aliases that the referred-to realm will not know.
+
+   The true principal name of the client, returned in AS-REQ, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].
+
+
+7.  Server Referrals
+
+   The primary difference in server referrals is that the KDC MUST
+   return a referral TGT rather than an error message as is done in the
+   client referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server.  This is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [RFC4120], as specified later in this
+   section.
+
+   If the KDC resolves the server principal name into a principal in the
+   realm specified by the service realm name, it will return a normal
+   ticket.
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified server realm.  If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.  The true principal name of the server SHALL be
+   returned in the padata of the reply if it is different from what is
+   specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in pre-
+   authentication data MUST be encrypted using the session key from the
+   reply ticket.  The key usage value for the encryption operation used
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 8]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+          PA-SERVER-REFERRAL      25
+
+          PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                                -- ServerReferralData --
+
+          ServerReferralData ::= SEQUENCE {
+                 referred-realm           [0] Realm OPTIONAL,
+                                -- target realm of the referral TGT
+                 true-principal-name      [1] PrincipalName OPTIONAL,
+                                -- true server principal name
+                 requested-principal-name [2] PrincipalName OPTIONAL,
+                                -- requested server name
+                 ...
+          }
+
+   Clients SHALL NOT accept a reply ticket, whose the server principal
+   name is different from that of the request, if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The requested-principal-name MUST be included by the KDC, and MUST be
+   verified by the client, if the client sent an AS-REQ, as protection
+   against a man-in-the-middle modification to the AS-REQ message.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the PA-
+   SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+
+
+Raeburn & Zhu           Expires September 6, 2007               [Page 9]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm DEV.EXAMPLE.COM where the client is in
+   ADMIN.EXAMPLE.COM.
+
+      +NC = Canonicalize KDCOption set
+      +PA-REFERRAL = returned PA-SERVER-REFERRAL
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
+         containing EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
+         containing DEV.EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
+      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
+
+   Note that any referral or alias processing of the server name in
+   user-to-user authentication should use the same data as client name
+   canonicalization or referral.  Otherwise, the name used by one user
+   to log in may not be useable by another for user-to-user
+   authentication to the first.
+
+
+8.  Server Name Canonicalization (Informative)
+
+   No attempt is being made in this document to provide a means for
+   dealing with local-realm server principal name canonicalization or
+   aliasing.  The most obvious use case for this would be a hostname-
+   based service principal name ("host/foobar.example.com"), with a DNS
+   alias ("foo") for the server host which is used by the client.  There
+   are other ways this can be handled, currently, though they may
+   require additional configuration on the application server or KDC or
+   both.
+
+
+9.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 7, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 10]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+10.  Caching Information
+
+   It is possible that the client may wish to get additional credentials
+   for the same service principal, perhaps with different authorization-
+   data restrictions or other changed attributes.  The return of a
+   server referral from a KDC can be taken as an indication that the
+   requested principal does not currently exist in the local realm.
+   Clearly, it would reduce network traffic if the clients could cache
+   that information and use it when acquiring the second set of
+   credentials for a service, rather than always having to re-check with
+   the local KDC to see if the name has been created locally.
+
+   Rather than introduce a new timeout field for this cached
+   information, we can use the lifetime of the returned TGT in this
+   case.  When the TGT expires, the previously returned referral from
+   the local KDC should be considered invalid, and the local KDC must be
+   asked again for information for the desired service principal name.
+   (Note that the client may get back multiple referral TGTs from the
+   local KDC to the same remote realm, with different lifetimes.  The
+   lifetime information must be properly associated with the requested
+   service principal names.  Simply having another TGT for the same
+   remote realm does not extend the validity of previously acquired
+   information about one service principal name.)  If the client is
+   still in contact with the service and needs to reauthenticate to the
+   same service regardless of local service principal name assignments,
+   it should use the referred-realm and true-principal-name values when
+   requesting new credentials.
+
+   Accordingly, KDC authors and maintainers should consider what factors
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+
+11.  Open Issues
+
+   When should client name aliases be included in credentials?
+
+   Should all known client name aliases be included, or only the one
+   used at initial ticket acquisition?
+
+   We still don't discuss what "validation" of the returned information
+   means.
+
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 11]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+12.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+
+13.  Acknowledgments
+
+   Sam Hartman and authors came up with the idea of using the ticket key
+   to encrypt the referral data, which prevents cut and paste attack
+   using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+   Karthik Jaganathan contributed to earlier versions.
+
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+14.2.  Informative References
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 12]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
+              of Crossrealm Referral Handling in the MIT Kerberos
+              Client",  Network and Distributed System Security
+              Symposium, February 2001.
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   (Remove this section when Microsoft publishes this information in a
+   separate document.)
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 13]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
+      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
+      the client's X.509 certificate.  The type of the otherName field
+      for this SAN extension is AnotherName [RFC3280].  The type-id
+      field of the type AnotherName is id-ms-sc-logon-upn
+      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct rusts between them.
+
+   While we might want to permit multiple aliases to exist and even be
+   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
+   one NT-ENTERPRISE alias to exist, so this question had not previously
+   arisen.
+
+
+Appendix B.  Document history
+
+   [REMOVE BEFORE PUBLICATION.]
+
+   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
+      Rewrote description of existing practice.  (Don't name the lookup
+      table consulted.  Mention that DNS "canonicalization" is contrary
+      to [RFC4120].)  Noted Microsoft behavior should be moved out into
+      a separate document.  Changed some second-person references in the
+      introduction to identify the proper parties.  Changed PA-CLIENT-
+      CANONICALIZED to use a separate type for the actual referral data,
+      add an extension marker to that type, and change the checksum key
+      from the "returned session key" to the "AS reply key".  Changed
+      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
+      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
+      needed separate checksum.  Attempt to clarify the cache lifetime
+      of referral information.
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 14]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+   08 Moved Microsoft implementation info to appendix.  Clarify lack of
+      local server name canonicalization.  Added optional authz-data for
+      login alias, to support user-to-user case.  Added requested-
+      principal-name to ServerReferralData.  Added discussion of caching
+      information, and referral TGT lifetime.
+   07 Re-issued with new editor.  Fixed up some references.  Started
+      history.
+
+
+Authors' Addresses
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   Email: raeburn@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 15]
+
+Internet-Draft                KDC Referrals                   March 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Raeburn & Zhu           Expires September 6, 2007              [Page 16]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-10.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-10.txt
new file mode 100644
index 00000000000..b7e1beb5948
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-10.txt
@@ -0,0 +1,1008 @@
+
+
+
+Kerberos Working Group                                        K. Raeburn
+Internet-Draft                                                       MIT
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: August 28, 2008                               February 25, 2008
+
+
+           Generating KDC Referrals to Locate Kerberos Realms
+                draft-ietf-krb-wg-kerberos-referrals-10
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on August 28, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+   referral information to reach the realm of the target principal and
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 1]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   then receive the ticket.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  5
+   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  5
+   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
+   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 11
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
+   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 12
+   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+     13.1.  Shared-password case  . . . . . . . . . . . . . . . . . . 13
+   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
+   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     15.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
+     15.2.  Informative References  . . . . . . . . . . . . . . . . . 14
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 14
+   Appendix B.  Document history [REMOVE BEFORE PUBLICATION]  . . . . 16
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
+   Intellectual Property and Copyright Statements . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 2]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [RFC4120], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name.  This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name.  In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC.  The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm.  Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  The user-supplied host name or its domain component
+   is looked up in this table (often using the result of some form of
+   host name lookup performed with insecure DNS queries, in violation of
+   [RFC4120]).  The corresponding realm is then used to complete the
+   target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 3]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  The administrator in the local realm could give that
+   remote server an identity in the local realm and then have that
+   remote server maintain a separate secret for each alias it is known
+   as.  Alternatively the administrator could arrange to have the local
+   realm issue a referral to the remote realm and notify the requesting
+   client of the server's remote name that should be used in order to
+   request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and allow the KDC to
+   determine the trusted realm authentication path by being able to
+   generate referrals to other realms in order to locate principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+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 [RFC2119].
+
+
+3.  Requesting a Referral
+
+   In order to request referrals defined in section 5, 6, and 7, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 4]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                      EXAMPLE.COM
+                      /        \
+                     /          \
+          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
+
+   In this configuration, all users in the EXAMPLE.COM enterprise could
+   have principal names such as alice@EXAMPLE.COM, with the same realm
+   portion.  In addition, servers at EXAMPLE.COM should be able to have
+   DNS host names from any DNS domain independent of what Kerberos realm
+   their principals reside in.
+
+
+5.  Enterprise Principal Name Type
+
+   The NT-ENTERPRISE type principal name contains one component, a
+   string of realm-defined content, which is intended to be used as an
+   alias for another principal name in some realm in the enterprise.  It
+   is used for conveying the alias name, not for the real principal
+   names within the realms, and thus is only useful when name
+   canonicalization is requested.
+
+
+6.  Name Canonicalization
+
+   A service or account may have multiple principal names.  More useful,
+   though, is a globally unique name that allows unification of email
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 5]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   and security principal names.  For example, all users at EXAMPLE.COM
+   may have a client principal name of the form "joe@EXAMPLE.COM" even
+   though the principals are contained in multiple realms.  This global
+   name is again an alias for the true client principal name, which
+   indicates what realm contains the principal.  Thus, accounts "alice"
+   in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log
+   on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
+
+   This utilizes a new client principal name type, as the AS-REQ message
+   only contains a single realm field, and the realm portion of this
+   name corresponds to the Kerberos realm with which the request is
+   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
+   single component in the client name field of the AS-REQ message, with
+   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
+   The KDC will recognize this name type and then transform the
+   requested name into the true principal name if the client account
+   resides in the local realm.  The true principal name can have a name
+   type different from the requested name type.  Typically the true
+   principal name will be a NT-PRINCIPAL [RFC4120].
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client principal name and type in the AS response and ticket returned
+   from the name type of the client name in the request, and include a
+   mandatory PA-DATA object authenticating the client name mapping:
+
+   ReferralInfo ::= SEQUENCE {
+     requested-name  [0] PrincipalName,
+     mapped-name     [1] PrincipalName,
+     ...
+   }
+   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
+     names          [0] ReferralInfo,
+     canon-checksum [1] Checksum
+   }
+
+   The canon-checksum field is computed over the DER encoding of the
+   names sequences, using the AS reply key and a key usage value of
+   (TBD).
+
+   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
+   not included.  If the client name is changed, and the PA-CLIENT-
+   CANONICALIZED field does not exist, or the checksum cannot be
+   verified, or the requested-name field doesn't match the client name
+   in the originally-transmitted request, the client should discard the
+   response.
+
+   For example the AS request may specify a client name of "bob@
+   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 6]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   option set and the KDC will return with a client name of "104567" as
+   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
+   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
+   NT-UID "104567" principal as the mapped-name.
+
+   (It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.)
+
+   In order to enable one party in a user-to-user exchange to confirm
+   the identity of another when only the alias is known, the KDC MAY
+   include the following authorization data element, wrapped in AD-KDC-
+   ISSUED, in the initial credentials and copy it from a ticket-granting
+   ticket into additional credentials:
+
+   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
+     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
+   }
+
+   The login-aliases field lists one or more of the aliases the
+   principal may have used in the initial ticket request.
+
+   The recipient of this authenticator must check the AD-LOGIN-ALIAS
+   names, if present, in addition to the normal client name field,
+   against the identity of the party with which it wishes to
+   authenticate; either should be allowed to match.  (Note that this is
+   not backwards compatible with [RFC4120]; if the server side of the
+   user-to-user exchange does not support this extension, and does not
+   know the true principal name, authentication may fail if the alias is
+   sought in the client name field.)
+
+   The use of AD-KDC-ISSUED authorization data elements in cross-realm
+   cases has not been well explored at this writing; hence we will only
+   specify the inclusion of this data in the one-realm case.  The alias
+   information should be dropped in the general cross-realm case.
+   However, a realm may implement a policy of accepting and re-signing
+   (wrapping in a new AD-KDC-ISSUED element) alias information provided
+   by certain other realms in the cross-realm ticket-granting service.
+
+
+7.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@EXAMPLE.COM, the
+   client MAY optimistically choose to send the request to EXAMPLE.COM.
+   The realm in the AS-REQ is always the name of the realm that the
+   request is for as specified in [RFC4120].
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 7]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC will try to lookup
+   the entire name, alice@EXAMPLE.COM, using a name service.  If this
+   lookup is unsuccessful, it MUST return the error
+   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
+   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
+   error message the crealm field will contain either the true realm of
+   the client or another realm that MAY have better information about
+   the client's true realm.  The client SHALL NOT use a cname returned
+   from a Kerberos error until that name is validated.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message corresponding to the first request.  (The
+   client realm name will be updated in the new request to refer to this
+   new realm.)  The client SHOULD repeat these steps until it finds the
+   true realm of the client.  To avoid infinite referral loops, an
+   implementation should limit the number of referrals.  A suggested
+   limit is 5 referrals before giving up.
+
+   Since the same client name is sent to the referring and referred-to
+   realms, both realms must recognize the same client names.  In
+   particular, the referring realm cannot (usefully) define principal
+   name aliases that the referred-to realm will not know.
+
+   The true principal name of the client, returned in AS-REQ, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].  However, this requires trusting the referred-to
+   realm's KDCs.  Clients should limit the referral mappings they will
+   accept to realms trusted via some local policy.  Some possible
+   factors that might be taken into consideration for such a policy
+   might include:
+
+   o  Any realm indicated by the local KDC, if the returned KRB-ERROR
+      message is protected, for example using a public key known to be
+      associated with the KDC
+   o  A list of realms configured by an administrator
+   o  Any realm accepted by the user when explicitly prompted
+
+
+
+
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 8]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+8.  Server Referrals
+
+   The primary difference in server referrals is that the KDC MUST
+   return a referral TGT rather than an error message as is done in the
+   client referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server.  This is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [RFC4120], as specified later in this
+   section.
+
+   If the KDC resolves the server principal name into a principal in the
+   realm specified by the service realm name, it will return a normal
+   ticket.
+
+   If the "canonicalize" flag in the KDC options is not set, the KDC
+   MUST only look up the name as a normal principal name in the
+   specified server realm.  If the "canonicalize" flag in the KDC
+   options is set and the KDC doesn't find the principal locally, the
+   KDC MAY return a cross-realm ticket granting ticket to the next hop
+   on the trust path towards a realm that may be able to resolve the
+   principal name.  The true principal name of the server SHALL be
+   returned in the padata of the reply if it is different from what is
+   specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in pre-
+   authentication data MUST be encrypted using the session key from the
+   reply ticket.  The key usage value for the encryption operation used
+   by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu            Expires August 28, 2008                [Page 9]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+          PA-SERVER-REFERRAL      25
+
+          PA-SERVER-REFERRAL-DATA ::= EncryptedData
+                                -- ServerReferralData --
+
+          ServerReferralData ::= SEQUENCE {
+                 referred-realm           [0] Realm OPTIONAL,
+                                -- target realm of the referral TGT
+                 true-principal-name      [1] PrincipalName OPTIONAL,
+                                -- true server principal name
+                 requested-principal-name [2] PrincipalName OPTIONAL,
+                                -- requested server name
+                 referral-valid-until     [3] KerberosTime OPTIONAL,
+                 ...
+          }
+
+   Clients SHALL NOT accept a reply ticket in which the server principal
+   name is different from that of the request, if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The requested-principal-name MUST be included by the KDC, and MUST be
+   verified by the client, if the client sent an AS-REQ, as protection
+   against a man-in-the-middle modification to the AS-REQ message.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the PA-
+   SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   The client may cache the mapping of the requested name to the name of
+   the next realm to use and the principal name to ask for.  (See
+   Section 10.)  The referral-valid-until field, if present, conveys how
+   long this information is valid for.
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 10]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm DEV.EXAMPLE.COM where the client is in
+   ADMIN.EXAMPLE.COM.
+
+      +NC = Canonicalize KDCOption set
+      +PA-REFERRAL = returned PA-SERVER-REFERRAL
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
+         containing EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
+         containing DEV.EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
+      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
+
+   Note that any referral or alias processing of the server name in
+   user-to-user authentication should use the same data as client name
+   canonicalization or referral.  Otherwise, the name used by one user
+   to log in may not be useable by another for user-to-user
+   authentication to the first.
+
+
+9.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 8, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+10.  Caching Information
+
+   It is possible that the client may wish to get additional credentials
+   for the same service principal, perhaps with different authorization-
+   data restrictions or other changed attributes.  The return of a
+   server referral from a KDC can be taken as an indication that the
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 11]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   requested principal does not currently exist in the local realm.
+   Clearly, it would reduce network traffic if the clients could cache
+   that information and use it when acquiring the second set of
+   credentials for a service, rather than always having to re-check with
+   the local KDC to see if the name has been created locally.
+
+   If the referral-valid-until field is provided in the PA-SERVER-
+   REFERRAL-DATA message, it indicates the expiration time of this data;
+   if it is not included, the expiration time of the TGT is used.  When
+   the TGT expires, the previously returned referral from the local KDC
+   should be considered invalid, and the local KDC must be asked again
+   for information for the desired service principal name.  (Note that
+   the client may get back multiple referral TGTs from the local KDC to
+   the same remote realm, with different lifetimes.  The lifetime
+   information must be properly associated with the requested service
+   principal names.  Simply having another TGT for the same remote realm
+   does not extend the validity of previously acquired information about
+   one service principal name.)  If the client is still in contact with
+   the service and needs to reauthenticate to the same service
+   regardless of local service principal name assignments, it should use
+   the referred-realm and true-principal-name values when requesting new
+   credentials.
+
+   Accordingly, KDC authors and maintainers should consider what factors
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+
+11.  Open Issues
+
+   Client referral info validation
+
+   When should client name aliases be included in credentials?  Should
+   all known client name aliases be included, or only the one used at
+   initial ticket acquisition?
+
+   Should list the policies that need to be defined.
+
+   More examples: u2u, policy checks, maybe cross-realm.
+
+   Restore server name canonicalization from early drafts.
+
+
+12.  Number Assignments
+
+   Most number registries in the Kerberos protocol have not been turned
+   over to IANA for management at the time of this writing, hence this
+   is not an "IANA Considerations" section.
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 12]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   Various values do need assigning for this draft:
+      AD-LOGIN-ALIAS
+      PA-CLIENT-CANONICALIZED
+      key usage value for PA-CLIENT-CANONICALIZED field canon-checksum
+
+
+13.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+13.1.  Shared-password case
+
+   A special case to examine is when the user is known (or correctly
+   suspected) to use the same password for multiple accounts.  A man-in-
+   the-middle attacker can either alter the request on its way to the
+   KDC, changing the client principal name, or reply to the client with
+   a response previously send by the KDC in response to a request from
+   the attacker.  The response received by the client can then be
+   decrypted by the user, though if the default "salt" generated from
+   the principal name is used to produce the user's key, a PA-ETYPE-INFO
+   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
+   the attacker to cause the client software to generate the key needed
+   for the message it will receive.  None of this requires the attacker
+   to know the user's password, and without further checking, could
+   cause the user to unknowingly use the wrong credentials.
+
+   In normal [RFC4120] operation, a generated AP-REQ message includes in
+   the Authenticator field a copy of the client's idea of its own
+   principal name.  If this differs from the name in the KDC-generated
+   Ticket, the application server will reject the message.
+
+   With client name canonicalization as described in this document, the
+   client may get its principal name from the response from the KDC.
+   Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 13]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   check that the requested name was not altered in transit.  If the PA-
+   CLIENT-CANONICALIZED data is absent, the client can use the principal
+   name it requested.
+
+
+14.  Acknowledgments
+
+   Sam Hartman and authors came up with the idea of using the ticket key
+   to encrypt the referral data, which prevents cut and paste attack
+   using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+   Karthik Jaganathan contributed to earlier versions.
+
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+15.2.  Informative References
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
+              of Crossrealm Referral Handling in the MIT Kerberos
+              Client",  Network and Distributed System Security
+              Symposium, February 2001.
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 14]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
+      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
+      the client's X.509 certificate.  The type of the otherName field
+      for this SAN extension is AnotherName [RFC3280].  The type-id
+      field of the type AnotherName is id-ms-sc-logon-upn
+      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 15]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct rusts between them.
+
+   While we might want to permit multiple aliases to exist and even be
+   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
+   one NT-ENTERPRISE alias to exist, so this question had not previously
+   arisen.
+
+
+Appendix B.  Document history [REMOVE BEFORE PUBLICATION]
+
+   10 TBD
+   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
+      Rewrote description of existing practice.  (Don't name the lookup
+      table consulted.  Mention that DNS "canonicalization" is contrary
+      to [RFC4120].)  Noted Microsoft behavior should be moved out into
+      a separate document.  Changed some second-person references in the
+      introduction to identify the proper parties.  Changed PA-CLIENT-
+      CANONICALIZED to use a separate type for the actual referral data,
+      add an extension marker to that type, and change the checksum key
+      from the "returned session key" to the "AS reply key".  Changed
+      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
+      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
+      needed separate checksum.  Attempt to clarify the cache lifetime
+      of referral information.
+   08 Moved Microsoft implementation info to appendix.  Clarify lack of
+      local server name canonicalization.  Added optional authz-data for
+      login alias, to support user-to-user case.  Added requested-
+      principal-name to ServerReferralData.  Added discussion of caching
+      information, and referral TGT lifetime.
+   07 Re-issued with new editor.  Fixed up some references.  Started
+      history.
+
+
+Authors' Addresses
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   Email: raeburn@mit.edu
+
+
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 16]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 17]
+
+Internet-Draft                KDC Referrals                February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Raeburn & Zhu            Expires August 28, 2008               [Page 18]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt
new file mode 100644
index 00000000000..7c4c5a36522
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt
@@ -0,0 +1,1064 @@
+
+
+
+NETWORK WORKING GROUP                                         K. Raeburn
+Internet-Draft                                                       MIT
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: January 15, 2009                                  July 14, 2008
+
+
+ Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm
+                               Referrals
+                draft-ietf-krb-wg-kerberos-referrals-11
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 15, 2009.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+   The memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   TGT to another realm on the referral path.  The clients will use this
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 1]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   referral information to reach the realm of the target principal and
+   then receive the ticket.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  5
+   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  6
+   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 12
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 12
+   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13
+   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+     14.1.  Shared-password case  . . . . . . . . . . . . . . . . . . 14
+     14.2.  Preauthentication data  . . . . . . . . . . . . . . . . . 14
+   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     16.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
+     16.2.  Informative References  . . . . . . . . . . . . . . . . . 15
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 15
+   Appendix B.  Document history [REMOVE BEFORE PUBLICATION]  . . . . 17
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
+   Intellectual Property and Copyright Statements . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 2]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos AS and TGS protocols, as
+   defined in [RFC4120], use principal names constructed from a known
+   user or service name and realm.  A service name is typically
+   constructed from a name of the service and the DNS host name of the
+   computer that is providing the service.  Many existing deployments of
+   Kerberos use a single Kerberos realm where all users and services
+   would be using the same realm.  However in an environment where there
+   are multiple trusted Kerberos realms, the client needs to be able to
+   determine what realm a particular user or service is in before making
+   an AS or TGS request.  Traditionally this requires client
+   configuration to make this possible.
+
+   When having to deal with multiple trusted realms, users are forced to
+   know what realm they are in before they can obtain a ticket granting
+   ticket (TGT) with an AS request.  However, in many cases the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an RFC 822 style email name.  This document describes a
+   mechanism that would allow a user to specify a user principal name
+   that is an alias for the user's Kerberos principal name.  In practice
+   this would be the name that the user specifies to obtain a TGT from a
+   Kerberos KDC.  The user principal name no longer has a direct
+   relationship with the Kerberos principal or realm.  Thus the
+   administrator is able to move the user's principal to other realms
+   without the user having to know that it happened.
+
+   Once a user has a TGT, they would like to be able to access services
+   in any trusted Kerberos realm.  To do this requires that the client
+   be able to determine what realm the target service principal is in
+   before making the TGS request.  Current implementations of Kerberos
+   typically have a table that maps DNS host names to corresponding
+   Kerberos realms.  The user-supplied host name or its domain component
+   is looked up in this table (often using the result of some form of
+   host name lookup performed with insecure DNS queries, in violation of
+   [RFC4120]).  The corresponding realm is then used to complete the
+   target service principal name.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client side
+   configuration information can be very costly from an administration
+   point of view - especially if there are many realms and computers in
+   the environment.
+
+   There are also cases where specific DNS aliases (local names) have
+   been setup in an organization to refer to a server in another
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 3]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   organization (remote server).  The server has different DNS names in
+   each organization and each organization has a Kerberos realm that is
+   configured to service DNS names within that organization.  Ideally
+   users are able to authenticate to the server in the other
+   organization using the local server name.  This would mean that the
+   local realm be able to produce a ticket to the remote server under
+   its name.  The administrator in the local realm could give that
+   remote server an identity in the local realm and then have that
+   remote server maintain a separate secret for each alias it is known
+   as.  Alternatively the administrator could arrange to have the local
+   realm issue a referral to the remote realm and notify the requesting
+   client of the server's remote name that should be used in order to
+   request a ticket.
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services and allow the KDC to
+   determine the trusted realm authentication path by being able to
+   generate referrals to other realms in order to locate principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+
+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 [RFC2119].
+
+
+3.  Requesting a Referral
+
+   In order to request referrals as defined in later sections, the
+   Kerberos client MUST explicitly request the canonicalize KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 4]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+                   -- other KDCOptions values omitted
+
+   The client should expect, when sending names with the "canonicalize"
+   KDC option, that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct trust relationship.  The KDC
+   also has access to a trusted name service that can resolve any name
+   from within its enterprise into a realm.  This trusted name service
+   removes the need to use an un-trusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate trust relationships:
+
+                      EXAMPLE.COM
+                      /        \
+                     /          \
+          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
+
+   In this configuration, all users in the EXAMPLE.COM enterprise could
+   have principal names such as alice@EXAMPLE.COM, with the same realm
+   portion.  In addition, servers at EXAMPLE.COM should be able to have
+   DNS host names from any DNS domain independent of what Kerberos realm
+   their principals reside in.
+
+
+5.  Enterprise Principal Name Type
+
+   The NT-ENTERPRISE type principal name contains one component, a
+   string of realm-defined content, which is intended to be used as an
+   alias for another principal name in some realm in the enterprise.  It
+   is used for conveying the alias name, not for the real principal
+   names within the realms, and thus is only useful when name
+   canonicalization is requested.
+
+   The intent is to allow unification of email and security principal
+   names.  For example, all users at EXAMPLE.COM may have a client
+   principal name of the form "joe@EXAMPLE.COM" even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 5]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as
+   "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
+
+   This utilizes a new principal name type, as the KDC-REQ message only
+   contains a single client realm field, and the realm portion of this
+   name corresponds to the Kerberos realm with which the request is
+   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
+   single component in the client name field of the AS-REQ message, with
+   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
+   The KDC will recognize this name type and then transform the
+   requested name into the true principal name if the client account
+   resides in the local realm.  The true principal name can have a name
+   type different from the requested name type.  Typically the true
+   principal name will be a NT-PRINCIPAL [RFC4120].
+
+
+6.  Name Canonicalization
+
+   A service or account may have multiple principal names.  For example,
+   if a host is known by multiple names, host-based services on it may
+   be known by multiple names in order to prevent the client from
+   needing a secure directory service to determine the correct hostname
+   to use.  In order that the host should not need to be updated
+   whenever a new alias is created, the KDC may provide the mapping
+   information to the client in the credential acquisition process.
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client and server principal names and types in the AS response and
+   ticket returned from the name type of the client name in the request.
+   In a TGS exchange, the server principal name and type may be changed.
+
+   If the client principal name is changed in an AS exchange, the KDC
+   must include a mandatory PA-DATA object authenticating the client
+   name mapping:
+
+   ClientReferralInfo ::= SEQUENCE {
+     requested-name  [0] PrincipalName,
+     mapped-name     [1] PrincipalName,
+     ...
+   }
+   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
+     names          [0] ClientReferralInfo,
+     canon-checksum [1] Checksum
+   }
+
+   The canon-checksum field is computed over the DER encoding of the
+   names sequences, using the AS reply key and a key usage value of
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 6]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   (TBD).
+
+   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
+   not included.  If the client name is changed, and the PA-CLIENT-
+   CANONICALIZED field does not exist, or the checksum cannot be
+   verified, or the requested-name field doesn't match the client name
+   in the originally-transmitted request, the client should discard the
+   response.
+
+   For example the AS request may specify a client name of "bob@
+   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
+   option set and the KDC will return with a client name of "104567" as
+   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
+   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
+   NT-UID "104567" principal as the mapped-name.
+
+   (It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out of band mechanisms.)
+
+   If the server name is changed, a PA-SERVER-REFERRAL preauth data
+   entry MUST be supplied by the KDC and validated by the client.
+
+   In order to enable one party in a user-to-user exchange to confirm
+   the identity of another when only the alias is known, the KDC MAY
+   include the following authorization data element, wrapped in AD-KDC-
+   ISSUED, in the initial credentials and copy it from a ticket-granting
+   ticket into additional credentials:
+
+   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
+     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
+   }
+
+   The login-aliases field lists one or more of the aliases the
+   principal may have.
+
+   The recipient of this authenticator must check the AD-LOGIN-ALIAS
+   names, if present, in addition to the normal client name field,
+   against the identity of the party with which it wishes to
+   authenticate; either should be allowed to match.  (Note that this is
+   not backwards compatible with [RFC4120]; if the server side of the
+   user-to-user exchange does not support this extension, and does not
+   know the true principal name, authentication may fail if the alias is
+   sought in the client name field.)
+
+   The use of AD-KDC-ISSUED authorization data elements in cross-realm
+   cases has not been well explored at this writing; hence we will only
+   specify the inclusion of this data in the one-realm case.  The alias
+   information SHOULD be dropped in the general cross-realm case.
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 7]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   However, a realm MAY implement a policy of accepting and re-signing
+   (wrapping in a new AD-KDC-ISSUED element) alias information provided
+   by certain trusted realms, in the cross-realm ticket-granting
+   service.
+
+   The canonical principal name for an alias may not be in the form of a
+   ticket-granting service name, as (in a case of server name
+   canonicalization) that would be construed as a case of cross-realm
+   referral, described below.
+
+
+7.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient trusted realm, for example the realm of
+   the client machine.  In the case of the name alice@EXAMPLE.COM, the
+   client MAY optimistically choose to send the request to EXAMPLE.COM.
+   The realm in the AS-REQ is always the name of the realm that the
+   request is for as specified in [RFC4120].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply structure with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC may look up the
+   client principal name using some kind of name service or directory
+   service.  If this lookup is unsuccessful, it MUST return the error
+   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
+   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
+   error message the crealm field will contain either the true realm of
+   the client or another realm that MAY have better information about
+   the client's true realm.  The client SHALL NOT use the cname returned
+   in this error message.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first referral to the realm specified by the realm field of the
+   Kerberos error message corresponding to the first request.  (The
+   client realm name will be updated in the new request to refer to this
+   new realm.)  The client SHOULD repeat these steps until it finds the
+   true realm of the client.  To avoid infinite referral loops, an
+   implementation should limit the number of referrals.  A suggested
+   limit is 5 referrals before giving up.
+
+   Since the same client name is sent to the referring and referred-to
+   realms, both realms must recognize the same client names.  In
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 8]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   particular, the referring realm cannot (usefully) define principal
+   name aliases that the referred-to realm will not know.
+
+   The true principal name of the client, returned in AS-REQ, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].  However, this requires trusting the referred-to
+   realm's KDCs.  Clients should limit the referral mappings they will
+   accept to realms trusted via some local policy.  Some possible
+   factors that might be taken into consideration for such a policy
+   might include:
+
+   o  Any realm indicated by the local KDC, if the returned KRB-ERROR
+      message is protected by some additional means, for example using a
+      preauthentication scheme using a public key known to be associated
+      with the KDC, or an IPsec tunnel known to have the desired KDC as
+      the remote endpoint
+   o  A list of realms configured by an administrator
+   o  Any realm accepted by the user when explicitly prompted
+
+   There is currently no provision for changing the client name in a
+   client referral response, because there is no method for verifying
+   that a man-in-the-middle attack did not change the requested name in
+   the request on the way to the KDC.
+
+
+8.  Server Referrals
+
+   The primary difference in server referrals is that the KDC returns a
+   referral TGT rather than an error message as is done in the client
+   referrals.  There needs to be a place to include in the reply
+   information about what realm contains the server; this is done by
+   returning information about the server name in the pre-authentication
+   data field of the KDC reply [RFC4120], as specified later in this
+   section.
+
+   If the "canonicalize" flag in the KDC options is set and the KDC
+   doesn't find the principal locally, either as a regular principal or
+   as an alias for another local principal, the KDC MAY return a cross-
+   realm ticket granting ticket to the next hop on the trust path
+   towards a realm that may be able to resolve the principal name.  The
+   true principal name of the server SHALL be returned in the padata of
+   the reply if it is different from what is specified the request.
+
+   When a referral TGT is returned, the KDC MUST return the target realm
+   for the referral TGT as an KDC supplied pre-authentication data
+   element in the response.  This referral information in pre-
+   authentication data MUST be encrypted using the session key from the
+
+
+
+Raeburn & Zhu           Expires January 15, 2009                [Page 9]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   reply ticket.  The key usage value for the encryption operation used
+   by PA-SERVER-REFERRAL is 26.
+
+   The pre-authentication data returned by the KDC, which contains the
+   referred realm and the true principal name of server, is encoded in
+   DER as follows.
+
+
+         PA-SERVER-REFERRAL      25
+
+         SERVER-REFERRAL-DATA ::= EncryptedData
+                               -- ServerReferralData
+                               -- returned session key, ku=26
+
+         ServerReferralData ::= SEQUENCE {
+                referred-realm           [0] Realm OPTIONAL,
+                               -- target realm of the referral TGT
+                true-principal-name      [1] PrincipalName OPTIONAL,
+                               -- true server principal name
+                requested-principal-name [2] PrincipalName OPTIONAL,
+                               -- requested server name
+                referral-valid-until     [3] KerberosTime OPTIONAL,
+                rep-cksum                [4] Checksum,
+                               -- associated {AS,TGS}-REP with no padata
+                               -- reply key, ku=[TBD]
+                ...
+         }
+
+   The rep-cksum field is a checksum computed over the DER encoding of
+   the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is
+   included, but with the padata field omitted.  It SHOULD be computed
+   using the mandatory-to-implement checksum type associated with the
+   encryption type of the reply key.  (Encrypting the referral data in
+   with the reply key but without the checksum only proves that it was
+   generated by one of the parties with access to the reply key; it is
+   not proof against cut-and-paste attacks combining parts of different
+   KDC replies using the same reply key.)
+
+   Clients SHALL NOT accept a reply ticket in which the server principal
+   name is different from that of the request, if the KDC response does
+   not contain a PA-SERVER-REFERRAL padata entry.
+
+   The requested-principal-name MUST be included by the KDC, and MUST be
+   verified by the client, if the client sent an AS-REQ, as protection
+   against a man-in-the-middle modification to the AS-REQ message.
+
+   The referred-realm field is present if and only if the returned
+   ticket is a referral TGT, not a service ticket for the requested
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 10]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   server principal.
+
+   When a referral TGT is returned and the true-principal-name field is
+   present, the client MUST use that name in the subsequent requests to
+   the server realm when following the referral.
+
+   Client SHALL NOT accept a true server principal name for a service
+   ticket if the true-principal-name field is not present in the PA-
+   SERVER-REFERRAL data.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   The client may cache the mapping of the requested name to the name of
+   the next realm to use and the principal name to ask for.  (See
+   Section 10.)  The referral-valid-until field, if present, conveys how
+   long this information is valid for.
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm DEV.EXAMPLE.COM where the client is in
+   ADMIN.EXAMPLE.COM.
+
+      +NC = Canonicalize KDCOption set
+      +PA-REFERRAL = returned PA-SERVER-REFERRAL
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
+         containing EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
+         containing DEV.EXAMPLE.COM as the referred realm with no
+         true-principal-name
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
+      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
+
+   Note that any referral or alias processing of the server name in
+   user-to-user authentication should use the same data as client name
+   canonicalization or referral.  Otherwise, the name used by one user
+   to log in may not be useable by another for user-to-user
+   authentication to the first.
+
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 11]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+9.  Cross Realm Routing
+
+   The current Kerberos protocol requires the client to explicitly
+   request a cross-realm TGT for each pair of realms on a referral
+   chain.  As a result, the client need to be aware of the trust
+   hierarchy and of any short-cut trusts (those that aren't parent-
+   child trusts).
+
+   Instead, using the server referral routing mechanism as defined in
+   Section 8, The KDC will determine the best path for the client and
+   return a cross-realm TGT as the referral TGT, and the target realm
+   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
+
+   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
+   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
+   response does not contain the PA-SERVER-REFERRAL padata.
+
+
+10.  Caching Information
+
+   It is possible that the client may wish to get additional credentials
+   for the same service principal, perhaps with different authorization-
+   data restrictions or other changed attributes.  The return of a
+   server referral from a KDC can be taken as an indication that the
+   requested principal does not currently exist in the local realm.
+   Clearly, it would reduce network traffic if the clients could cache
+   that information and use it when acquiring the second set of
+   credentials for a service, rather than always having to re-check with
+   the local KDC to see if the name has been created locally.
+
+   If the referral-valid-until field is provided in the PA-SERVER-
+   REFERRAL-DATA message, it indicates the expiration time of this data;
+   if it is not included, the expiration time of the TGT is used.  When
+   the TGT expires, the previously returned referral from the local KDC
+   should be considered invalid, and the local KDC must be asked again
+   for information for the desired service principal name.  (Note that
+   the client may get back multiple referral TGTs from the local KDC to
+   the same remote realm, with different lifetimes.  The lifetime
+   information must be properly associated with the requested service
+   principal names.  Simply having another TGT for the same remote realm
+   does not extend the validity of previously acquired information about
+   one service principal name.)  If the client is still in contact with
+   the service and needs to reauthenticate to the same service
+   regardless of local service principal name assignments, it should use
+   the referred-realm and true-principal-name values when requesting new
+   credentials.
+
+   Accordingly, KDC authors and maintainers should consider what factors
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 12]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+
+11.  Open Issues
+
+   Client referral info validation
+
+   When should client name aliases be included in credentials?  Should
+   all known client name aliases be included, or only the one used at
+   initial ticket acquisition?
+
+   Should list the policies that need to be defined.
+
+   More examples: u2u, policy checks, maybe cross-realm.
+
+   Possibly generalize the integrity/privacy protection on
+   ServerReferralData into a general padata wrapper?
+
+   Is PA-SERVER-REFERRAL needed in a TGS exchange?
+
+   Do we need to send requested-name fields, or can we just include them
+   in checksums?
+
+
+12.  Number Assignments
+
+   Most number registries in the Kerberos protocol have not been turned
+   over to IANA for management at the time of this writing, hence this
+   is not an "IANA Considerations" section.
+
+   Various values do need assigning for this draft:
+      AD-LOGIN-ALIAS
+      PA-CLIENT-CANONICALIZED
+      key usage value for PA-CLIENT-CANONICALIZED field canon-checksum
+
+
+13.  IANA Considerations
+
+   None at present.
+
+
+14.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 13]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any), is the
+   client name and client realm in the service ticket targeted at the
+   workstation that was obtained using the user's initial TGT.
+
+   How the client name and client realm is mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user, when mapping the logon credentials to a local account on
+   the workstation.
+
+14.1.  Shared-password case
+
+   A special case to examine is when the user is known (or correctly
+   suspected) to use the same password for multiple accounts.  A man-in-
+   the-middle attacker can either alter the request on its way to the
+   KDC, changing the client principal name, or reply to the client with
+   a response previously send by the KDC in response to a request from
+   the attacker.  The response received by the client can then be
+   decrypted by the user, though if the default "salt" generated from
+   the principal name is used to produce the user's key, a PA-ETYPE-INFO
+   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
+   the attacker to cause the client software to generate the key needed
+   for the message it will receive.  None of this requires the attacker
+   to know the user's password, and without further checking, could
+   cause the user to unknowingly use the wrong credentials.
+
+   In normal [RFC4120] operation, a generated AP-REQ message includes in
+   the Authenticator field a copy of the client's idea of its own
+   principal name.  If this differs from the name in the KDC-generated
+   Ticket, the application server will reject the message.
+
+   With client name canonicalization as described in this document, the
+   client may get its principal name from the response from the KDC.
+   Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
+   check that the requested name was not altered in transit.  If the PA-
+   CLIENT-CANONICALIZED data is absent, the client can use the principal
+   name it requested.
+
+14.2.  Preauthentication data
+
+   In cases of credential renewal, forwarding, or validation, if
+   credentials are sent to the KDC that are not an initial ticket-
+   granting ticket for the client's home realm, the encryption key used
+   to protect the TGS exchange is one known to a third party (namely,
+   the service for which the credential was issued).  Consequently, in
+   such an exchange, the protection described earlier for the
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 14]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   preauthentication data cannot be assumed to provide a secure channel
+   between the KDC and the client, and such preauth data MUST NOT be
+   trusted for any information that needs to come from the KDC.
+
+
+15.  Acknowledgments
+
+   Sam Hartman and authors came up with the idea of using the ticket key
+   to encrypt the referral data, which prevents cut and paste attack
+   using the referral data and referral TGTs.
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+   Karthik Jaganathan contributed to earlier versions.
+
+
+16.  References
+
+16.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+16.2.  Informative References
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
+              of Crossrealm Referral Handling in the MIT Kerberos
+              Client",  Network and Distributed System Security
+              Symposium, February 2001.
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 15]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) The TGS referral data is returned inside of the KDC message as
+      "encrypted pre-authentication data".
+
+
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   2) The preauth data type definition in the encrypted preauth data is
+      as follows:
+
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
+      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
+      the client's X.509 certificate.  The type of the otherName field
+      for this SAN extension is AnotherName [RFC3280].  The type-id
+      field of the type AnotherName is id-ms-sc-logon-upn
+      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+   In Microsoft's current implementation through the use of global
+   catalogs any domain in one forest is reachable from any other domain
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 16]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct rusts between them.
+
+   While we might want to permit multiple aliases to exist and even be
+   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
+   one NT-ENTERPRISE alias to exist, so this question had not previously
+   arisen.
+
+
+Appendix B.  Document history [REMOVE BEFORE PUBLICATION]
+
+   11 Changed title.  Better protection on server referral preauth data.
+      Support server name canonicalization.  Rename ReferralInfo to
+      ClientReferralInfo.  Disallow alias mapping to a TGT principal.
+      Explain why no name change in client referrals.  Add empty IANA
+      Considerations.  Add some notes on preauth data protection during
+      renewal etc.
+   10 Separate enterprise principal names into a separate section.  Add
+      a little wording to suggest server principal name canonicalization
+      might be allowed; not fleshed out.  Advise against AD-KDC-ISSUED
+      in cronn-realm cases.  Advise policy checks on returned client
+      referral info, since there's no security.  List number
+      assignments.  Add security analysis of shared-password case.  No
+      longer plan to remove Microsoft appendix.  Add referral-valid-
+      until field.
+   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
+      Rewrote description of existing practice.  (Don't name the lookup
+      table consulted.  Mention that DNS "canonicalization" is contrary
+      to [RFC4120].)  Noted Microsoft behavior should be moved out into
+      a separate document.  Changed some second-person references in the
+      introduction to identify the proper parties.  Changed PA-CLIENT-
+      CANONICALIZED to use a separate type for the actual referral data,
+      add an extension marker to that type, and change the checksum key
+      from the "returned session key" to the "AS reply key".  Changed
+      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
+      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
+      needed separate checksum.  Attempt to clarify the cache lifetime
+      of referral information.
+   08 Moved Microsoft implementation info to appendix.  Clarify lack of
+      local server name canonicalization.  Added optional authz-data for
+      login alias, to support user-to-user case.  Added requested-
+      principal-name to ServerReferralData.  Added discussion of caching
+      information, and referral TGT lifetime.
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 17]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+   07 Re-issued with new editor.  Fixed up some references.  Started
+      history.
+
+
+Authors' Addresses
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA  02139
+   US
+
+   Email: raeburn@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 18]
+
+Internet-Draft                KDC Referrals                    July 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Raeburn & Zhu           Expires January 15, 2009               [Page 19]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-sam-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-sam-02.txt
new file mode 100644
index 00000000000..ca2ae64f4d3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-sam-02.txt
@@ -0,0 +1,1049 @@
+INTERNET-DRAFT                                           Ken Hornstein
+<draft-ietf-krb-wg-kerberos-sam-02.txt>      Naval Research Laboratory
+Updates: RFC 1510                                           Ken Renard
+October 27, 2003                                           WareOnEarth
+                                                       Clifford Newman
+                                                                   ISI
+                                                             Glen Zorn
+                                                         Cisco Systems
+
+
+
+      Integrating Single-use Authentication Mechanisms with Kerberos
+
+
+0. Status Of this Memo
+   This document is an Internet-Draft and is subject to 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 docu-
+   ments at any time.  It is inappropriate to use  Internet-Drafts  as
+   reference  material  or  to  cite them other than as ``work in pro-
+   gress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
+   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
+   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   The distribution of  this  memo  is  unlimited.   It  is  filed  as
+   <draft-ietf-krb-wg-kerberos-sam-02.txt>,   and  expires  April  27,
+   2004.  Please send comments to the authors.
+
+
+1. Abstract
+   This document defines extensions to the Kerberos protocol  specifi-
+   cation  [RFC1510]  which  provide  a  method  by which a variety of
+   single-use authentication mechanisms may be  supported  within  the
+   protocol.  The method defined specifies a standard fashion in which
+   the preauthentication data and error data fields in  Kerberos  mes-
+   sages may be used to support single-use authentication mechanisms.
+
+
+2. Terminology
+   To simplify the following discussion, we will  define  those  terms
+   which  may be unfamiliar to the audience or specific to the discus-
+   sion itself.
+
+   Single-use Preauthentication Data (SPD):  Data sent in the  padata-
+   value  field  of  a  Kerberos  V5 message proving that knowledge of
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 1]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   certain unique information is held by a principal.   This  informa-
+   tion  may  or may not be identical to the single-use authentication
+   data input to the client.  For example, in the case of  S/Key,  the
+   principal  might  input  a  one-time  password  (in  any of several
+   forms); the knowledge of this one-time password is taken  to  indi-
+   cate  knowledge  of  the principal's secret passphrase.  Similarly,
+   the SPD may or may not contain the provided single-use  authentica-
+   tion  data.   For  instance,  if  a given single-use authentication
+   mechanism includes a token which generates an encryption key for  a
+   supported  cryptosystem, that key could be used to encrypt portions
+   of the SPD before transmission.  As long as the  verification  pro-
+   cess  of  the mechanism was capable of independently generating the
+   same key, the  successful  decryption  of  the  SPD  would  provide
+   assurance  that  the originator of the message was in possession of
+   the token, as well as whatever information the  token  required  to
+   generate the encryption key.
+
+   Single-use Authentication Mechanism (SAM):  A system for generating
+   and verifying authentication data which is usable only once.
+
+   Single-use Authentication Data (SAD):  SAM-specific  data  provided
+   by  a principal as input to client software to be used in the crea-
+   tion of SPD.
+
+
+3. Motivation and Scope
+   Several  single-use  authentication  mechanisms  are  currently  in
+   widespread  use, including hardware-based schemes from vendors such
+   as Enigma Logic, CRYPTOCard, and Security  Dynamics  and  software-
+   based  methods  like  S/Key  [RFC1760].  The hardware-based schemes
+   typically require that  the  authenticating  user  carry  a  small,
+   credit-card-sized  electronic device (called a token) which is used
+   to generate unique authentication data.  Some  tokens  require  the
+   user  to  enter data into the device.  This input may take the form
+   of a Personal Identification Number (PIN), a server-generated chal-
+   lenge string or both.  Other tokens do not use a challenge-response
+   technique, instead spontaneously generating new and unique  authen-
+   tication  data  every  few seconds.  These tokens are usually time-
+   synchronized with a server.  The  use  of  one-time  passwords  and
+   token  cards  as an authentication mechanism has steadily increased
+   over the past few years; in  addition,  the  Internet  Architecture
+   Board  has  encouraged the use of SAMs to improve Internet security
+   [RFC1636].
+
+   The widespread acceptance of Kerberos within the Internet community
+   has  produced  considerable demand for the integration of SAM tech-
+   nology with the authentication protocol.  Several currently  avail-
+   able  implementations of Kerberos include support for some types of
+   token cards, but the implementations are either not  interoperable,
+   or  would require the release of source code (not always an option)
+   to make them interoperate.  This memo attempts to remedy that prob-
+   lem  by specifying a method in which SAM data may be securely tran-
+   sported in Kerberos V5 messages in a standard, extensible  fashion.
+   This  document  does  not,  however,  attempt  to precisely specify
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 2]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   either the generation or verification of SAM data,  since  this  is
+   likely to be SAM-specific; nor does it dictate the conditions under
+   which SAM data must be included in Kerberos messages, since we con-
+   sider this to be a matter of local policy.
+
+   A primary reason for using a SAM with Kerberos  is  to  reduce  the
+   threat  from  common  attacks  on Kerberos passwords (poorly chosen
+   passwords, password guessing, etc).  If passwords are used in  com-
+   bination  with  SAM authentication data, users must still adhere to
+   sensible password policies and safe practices regarding the  selec-
+   tion,  secrecy,  and  maintenance of their passwords.  Depending on
+   the specific mechanism used, the purpose of the SAD is  to  augment
+   (or sometimes replace) the use of a password as a secret key.
+
+
+4. Generic Approach - Two Models
+   As outlined above, there are essentially two  types  of  single-use
+   authentication  mechanisms:  challenge/response and time-based.  In
+   order to support challenge/response mechanisms,  the  Kerberos  Key
+   Distribution  Center  (KDC)  must communicate the appropriate chal-
+   lenge string to the user, via the  client  software.   Furthermore,
+   some  challenge/response  mechanisms  require tight synchronization
+   between all instances of the KDC and the client.   One  example  is
+   S/Key  and  its variants.  If the KDC and client do not perform the
+   same number of message digest iterations, the protocol  will  fail;
+   worse,  it  might be possible for an eavesdropping attacker to cap-
+   ture a valid S/Key passcode and replay it to a  KDC  replica  which
+   had an outdated iteration number.  In the time-based case, no chal-
+   lenge is required.  This naturally  gives  rise  to  two  modes  of
+   client behavior, described below.
+
+
+4.1 Challenge/Response Model
+   The client begins with an initial KRB_AS_REQ message  to  the  KDC,
+   possibly using existing preauthentication methods (PA-ENC-TIMESTAMP
+   (encrypted  timestamp),  PA-OSF-DCE  (DCE),  etc.).   Depending  on
+   whether  preauthentication  is  used,  the  user  may or may not be
+   prompted at this time for a Kerberos password.   If  (for  example)
+   encrypted  timestamp  preauthentication is used, then the user will
+   be prompted; on the other hand, if no preauthentication is  in  use
+   the  prompt  for  the  password may be deferred (possibly forever).
+   Note that the use of preauthentication here may  allow  an  offline
+   guessing  attack  against  the  Kerberos password separate from the
+   SPD.  However, if the use of a SAM is required, then  the  password
+   by itself is not sufficient for authentication.  (Specify character
+   strings as UTF-8)
+
+   The KDC will determine in an implementation-  and  policy-dependent
+   fashion if the client is required to utilize a single-use authenti-
+   cation mechanism.  For  example,  the  implementation  may  use  IP
+   address screening to require principals authenticating from outside
+   a firewall to use a SAM, while principals on the inside  need  not.
+   If  SAM  usage  is  required,  then  the  KDC  will  respond with a
+   KRB_ERROR   message,   with   the   error-code   field    set    to
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 3]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   KDC_ERR_PREAUTH_REQUIRED  and the e-data field containing the ASN.1
+   structure that is a sequence of PA-DATA fields.
+
+   If the type of one of the PA-DATA fields  is  PA-SAM-REDIRECT,  the
+   client  should  re-execute  the  authentication  protocol  from the
+   beginning, directing messages to another of the KDCs for the realm.
+   This  is done to allow some methods to require that a single KDC be
+   used for SAM authentication when tight  synchronization  is  needed
+   between all replicas and the KDC database propagation code does not
+   provide such synchronization.  The corresponding padata-value  will
+   contain an encoded sequence of host addresses [RFC1510], from which
+   the client must choose the KDC to be contacted next.   The  PA-SAM-
+   REDIRECT is defined as:
+
+
+   PA-SAM-REDIRECT ::=    HostAddresses
+
+
+   Client implementations SHOULD check the addresses  in  the  PA-SAM-
+   REDIRECT  and  verify  that  they are a subset of the KDC addresses
+   that they have been configured for that realm.
+
+   If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then
+   if  one  of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the
+   exchange will continue as described in section 5, below.
+
+   Note that some Kerberos implementations support an older preauthen-
+   tication  mechanism  with the padata types PA-SAM-CHALLENGE and PA-
+   SAM-RESPONSE.  That protocol is depreciated and not defined here.
+
+
+4.2 Time-based Model
+   For mechanisms where no challenge is required,  the  user  (or  the
+   client  software  being  utilized)  may  or  may  not know a priori
+   whether SAM usage is required.  If it does not know, then the  ini-
+   tial exchange may proceed as above.  If it is known that a use of a
+   single-use authentication mechanism  is  required  then  the  first
+   exchange  can  be  skipped  and the authentication will continue as
+   follows.
+
+
+5. SAM Preauthentication
+
+   An optional SAM-CHALLENGE-2 may be sent from the KDC to the  client
+   and  the  client  will  send a SAM-RESPONSE-2 as pre-authentication
+   data in the KRB-AS-REQ.  The details of the messages follow.
+
+5.1 SAM-CHALLENGE-2
+
+   Prior to performing preauthentication using a single-use  authenti-
+   cation  mechanism,  the  client  must  know  whether a challenge is
+   required (if the client doesn't have this information prior to  its
+   sending  the  first  KRB_AS_REQ message, it will be informed of the
+   requirement by the KDC, as described in section  4.1).  The  client
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 4]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   does  NOT need to know the specific type of SAM in use.  If a chal-
+   lenge is required the client will be sent the challenge by the KDC.
+   This  means that a client supporting SAMs will be able to work with
+   new methods without modification.  The challenge, as  well  as  all
+   other prompts mentioned herein, can be internationalized by the KDC
+   on a per-principal basis.
+
+   If a KRB_ERROR message is received from the KDC indicating that SAM
+   usage  is required, that message will include in its e-data field a
+   PA-DATA structure that encodes information  about  the  SAM  to  be
+   used.   This  includes  whether a challenge is required, and if so,
+   the challenge itself; and informational data about the type of  SAM
+   that  is  in  use,  and how to prompt for the SAD.  The SAM type is
+   informational only and does not affect the behavior of the  client.
+   The  prompt  is also informational and may be presented to the user
+   by the client, or it may be safely ignored.
+
+   The ASN.1 definition for the SAM challenge is:
+
+          PA-SAM-CHALLENGE-2 ::= SEQUENCE {
+              sam-body[0]                 PA-SAM-CHALLENGE-2-BODY,
+              sam-cksum[1]                SEQUENCE (1..MAX) OF Checksum,
+              ...
+          }
+
+          PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE {
+              sam-type[0]                 INTEGER (0..4294967295),
+              sam-flags[1]                SAMFlags,
+              sam-type-name[2]            GeneralString OPTIONAL,
+              sam-track-id[3]             GeneralString OPTIONAL,
+                                            -- Key usage of 26
+              sam-challenge-label[4]      GeneralString OPTIONAL,
+              sam-challenge[5]            GeneralString OPTIONAL,
+              sam-response-prompt[6]      GeneralString OPTIONAL,
+              sam-pk-for-sad[7]           OCTET STRING OPTIONAL,
+              sam-nonce[8]                INTEGER (0..4294967295),
+              sam-etype[9]                INTEGER (0..4294967295),
+              ...
+          }
+
+          SAMFlags ::= BIT STRING (SIZE (32..MAX))
+              -- use-sad-as-key(0)
+              -- send-encrypted-sad(1)
+              -- must-pk-encrypt-sad(2)
+
+5.1.1  SAM-TYPE and SAM-TYPE-NAME Fields
+
+   The sam-type field is informational only, but it must be  specified
+   and sam-type values must be registered with the IANA.
+
+   Initially defined values of the sam-type codes are:
+
+       PA_SAM_TYPE_ENIGMA     1   -- Enigma Logic
+       PA_SAM_TYPE_DIGI_PATH  2   -- Digital Pathways
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 5]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+       PA_SAM_TYPE_SKEY_K0    3   -- S/key where  KDC has key 0
+       PA_SAM_TYPE_SKEY       4   -- Traditional S/Key
+       PA_SAM_TYPE_SECURID    5   -- Security Dynamics
+       PA_SAM_TYPE_CRYPTOCARD 6   -- CRYPTOCard
+
+   PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and
+   PA_SAM_TYPE_CRYPTOCARD     represent     popular    token    cards.
+   PA_SAM_TYPE_SKEY is the traditional S/Key protocol,  in  which  the
+   SAD  verifier  does  not  have  knowledge  of the principal's S/Key
+   secret.  PA_SAM_TYPE_SKEY_K0 is a variant of S/Key  that  uses  the
+   same  SAD  and PC software or hardware device, but where the zeroth
+   key (the S/Key secret) is actually stored on, and can be  used  by,
+   the  SAD verifier to independently generate the correct authentica-
+   tion data.
+
+   Note that using  PA_SAM_TYPE_SKEY_K0  gives  up  one  advantage  of
+   S/Key, viz., that the information required to generate the SAD need
+   not be stored on the host; but since the SAD verifier (which may be
+   the  KDC) is assumed to be more secure than other hosts on the net-
+   work, it may be acceptable to give up this advantage in some situa-
+   tions.  The advantage of using this S/Key variant is that the secu-
+   rity of the network protocol is strengthened since the SAD need not
+   be  sent  from the client to the KDC.  Thus, the SAD can be used as
+   part of the key used to encrypt the encrypted parts of both the SPD
+   and the KRB_AS_REP message, rather than being sent protected by the
+   principal's Kerberos secret key  which  may  have  been  previously
+   exposed  to an attacker (see section 6, below).  In any case, there
+   is a definite advantage to being interoperable with the S/Key algo-
+   rithm.
+
+   Due to the volatility of, and rapid developments in,  the  area  of
+   single-use   authentication   mechanisms  (both  software-only  and
+   hardware supported), any subsequently defined sam-type  codes  will
+   be maintained by the IANA.
+
+   The optional sam-type-name field is a UTF-8  character  string  for
+   informational  use only.  It may be used by the client to display a
+   short description of the type of single-use authentication  mechan-
+   ism to be used.
+
+5.1.2  SAM-FLAGS Field
+
+   The sam-flags field indicates whether the SAD is known by  the  KDC
+   (in which case it can be used as part of the encryption key for the
+   ensuing KRB_AS_REP message), or if it must be provided to  the  KDC
+   in a recoverable manner.  If it is known to the KDC, use-sad-as-key
+   indicates that the SAD alone will be used to generate  the  encryp-
+   tion  key  for  the forthcoming KRB_AS_REQ and KRB_AS_REP messages,
+   and that the user will not need  to  also  enter  a  password.   We
+   recommend  that this option only be used if the SAD will be used to
+   generate adequate keying material (sufficient length, secrecy, ran-
+   domness)  for  the cryptographic algorithm used.  If the single-use
+   authentication data is  not  known  (and  cannot  be  generated  or
+   discovered)  by  the KDC, then send-encrypted-sad flag will be set,
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 6]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   indicating that the SAD must be sent to the KDC encrypted under the
+   principal's  secret  key.   If  neither  use-sad-as-key  nor  send-
+   encrypted-sad are set, the client may assume that the KDC knows the
+   SAD,  but  the  Kerberos  password  should  be  used along with the
+   passcode in the derivation of the encryption key (see  below).   No
+   more  than  one  of the send-encrypted-sad and use-sad-as-key flags
+   should be in a SAM-CHALLENGE-2.
+
+   The must-pk-encrypt-sad flag is reserved for future use.   If  this
+   flag  is  set and a client does not support the must-pk-encrypt-sad
+   option (to be defined in a separate document), the client will  not
+   be able to complete the authentication and must notify the user.
+
+5.1.3  SAM-CHECKSUM Field
+
+   The sam-cksum field contains a sequence of  at  least  one  crypto-
+   graphic  checksum  of  encoding of the PA-SAM-CHALLENGE-2 sequence.
+   If the send-encrypted-sad flag is set, the key to be used for  this
+   checksum  is  the client's long-term secret.  If the use-sad-as-key
+   flag is set, then the SAD alone will be used as the key.   If  nei-
+   ther  flag  is  set, then the key used for this checksum is derived
+   from the SAD and the user's password (see section 5.2).
+
+   The checksum algorithm to be used for this is the mandatory  check-
+   sum  associated with the encryption algorithm specified in the sam-
+   etype field, with a key usage of 25.
+
+   In some cases there may be more than one valid SAD; some preauthen-
+   tication  mechanisms  may have a range of valid responses.  In that
+   case, the KDC may elect to return multiple checksums, one for  each
+   possible  SAD response.  The number of possible responses of course
+   depends on the mechanism and site policy.  In the case where multi-
+   ple  checksums  are  returned, the client MUST try each checksum in
+   turn until one of the checksums  is  verified  successfully.   Note
+   that in the non-send-encrypted-sad case the checksum cannot be ver-
+   ified until the user enters in the SAD, but if no checksum  can  be
+   verified, the client MUST not send a response but instead return an
+   error to the user.
+
+   The sam-cksum field  is  generated  by  calculating  the  specified
+   checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence.
+
+   If no checksum is included, or is of the wrong type,  or  none  are
+   found  which  are  correct, the client MUST abort the dialogue with
+   the   KDC   and    issue,    respectively,    KRB5_SAM_NO_CHECKSUM,
+   KRB5_SAM_BAD_CHECKSUM_TYPE,  or  KRB5_SAM_BAD_CHECKSUM  error  mes-
+   sages.
+
+5.1.4  SAM-TRACK-ID Field
+
+   The optional sam-track-id field may be returned by the KDC  in  the
+   KRB_ERROR  message.   If  present,  the client MUST copy this field
+   into the corresponding field of the SAM response sent in the subse-
+   quent  KRB_AS_REQ  message.   This  field may be used by the KDC to
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 7]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   match challenges and responses.  It might  be  a  suitably  encoded
+   integer,  or  even  be encrypted data with the KDC state encoded so
+   that the KDC doesn't have to maintain the state  internally.   Note
+   that  when  a  KDC  supplies  a sam-track-id, it MUST link the sam-
+   track-id with the sam-nonce field to prevent spoofing of  the  sam-
+   track-id field.
+
+   The key usage type 26 is reserved  for  use  to  encrypt  the  sam-
+   track-id  data.   The  key  used  to  encrypt  the  sam-track-id is
+   mechanism-dependent.
+
+5.1.5  SAM-CHALLENGE-LABEL Field
+
+   The sam-challenge-label field is informational and optional.  If it
+   is  included, is will be an UTF-8 encoded character.  If present, a
+   client may choose to precede the presentation of the challenge with
+   this  string.   For  example,  if  the  challenge is 135773 and the
+   string in the sam-challenge-label field  is  "Enter  the  following
+   number on your card", the client may choose to display to the user:
+
+          Enter the following number on your card: 135773
+
+   If no challenge label was presented, or if the  client  chooses  to
+   ignore it, the client might display instead:
+
+          Challenge from authentication server: 135773
+
+   Internationalization is supported by allowing customization of  the
+   challenge  label  and other strings on a per-principal basis.  Note
+   that this character string should be encoded using UTF-8.
+
+5.1.6  SAM-CHALLENGE Field
+
+   The optional sam-challenge field contains a  string  that  will  be
+   needed  by  the  user to generate a suitable response.  If the sam-
+   challenge field is left out, it indicates that the SAM in use  does
+   not  require  a  challenge,  and that the authorized user should be
+   able to produce the correct SAD without one.  If the  sam-challenge
+   field  is present, it is the data that is used by the SAD generator
+   to create the SAD to be used in the production of  the  SPD  to  be
+   included in the response.
+
+5.1.7  SAM-RESPONSE-PROMPT Field
+
+   The sam-response-prompt field is informational  and  optional.   If
+   present, a client may choose to precede the prompt for the response
+   with the specified string.
+
+          Passcode:
+
+5.1.8  SAM-PK-FOR-SAD Field
+
+   sam-pk-for-sad is  an  optional  field.   It  is  included  in  the
+   interest  of  future  extensability  of  the protocol to the use of
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 8]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   public-key cryptography.
+
+5.1.9  SAM-NONCE Field
+
+   The sam-nonce is a KDC-supplied nonce and  should  conform  to  the
+   specification   of   the  nonce  field  in  a  KRB_KDC_REQ  message
+   [RFC1510].
+
+   Challenge/Response mechanisms MUST link the nonce  field  with  the
+   sam-track-id  (if  one  is  included) to prevent replay of the sam-
+   track-id field.
+
+5.1.10  SAM-ETYPE Field
+
+   The sam-etype field contains the encryption type to be used by  the
+   client  for  all encrypted fields in the PA-SAM-RESPONSE-2 message.
+   The KDC should pick an appropriate encryption  algorithm  based  on
+   the   encryption   algorithms   listed   in  the  client's  initial
+   KRB_AS_REQ.
+
+5.2  Obtaining SAM Authentication Data
+
+   If the client is performing SAM preauthentication  in  the  initial
+   message,  without  receipt  of  a  PA-SAM-CHALLENGE-2 (i.e. without
+   waiting for the KRB_ERROR message), and the SAM  in  use  does  not
+   require  a  challenge,  the  client  will  prompt for the SAD in an
+   application-specific manner.
+
+   Once the user has been prompted for and entered the SAD (and possi-
+   bly the Kerberos password), the client will derive a key to be used
+   to encrypt the preauthentication data  for  a  KRB_AS_REQ  message.
+   This key will be determined as follows:
+
+          By default, the key is derived from the password and the SAD
+          by running each through the string_to_key function [RFC1510]
+          separately; i.e., K1  =  string_to_key(password)  and  K2  =
+          string_to_key(SAD).   When  the  keys  are both DES or 3DES,
+          keys  K1  and  K2  will  be  combined  using  the  algorithm
+          described  in  Appendix  B, ``DES/3DES Key Combination Algo-
+          rithm''.  For all other encryption algorithms, the algorithm
+          described in Appendix A, ``Key Combination Algorithm'' shall
+          be used.  Note that this algorithm is  not  commutative;  an
+          implementation  MUST insure that K1 is the key corresponding
+          to the user's long-term password, and K2 is the output  from
+          the SAD.  In either case, the salt used by the string_to_key
+          algorithm for the SAD shall be the same salt as used for the
+          user's password.
+
+          If the send-encrypted-sad flag  is  set,  the  key  will  be
+          derived   by   running  the  Kerberos  password  though  the
+          string_to_key function in the normal fashion.
+
+          If the use-sad-as-key flag is set and the integrity  of  the
+          PA-SAM-CHALLENGE-2  PADATA  field  can be verified using the
+
+
+
+Hornstein, Renard, Newman, Zorn                               [Page 9]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+          sam-cksum  field,  then  the  SAD   is   run   through   the
+          string_to_key function and the result is used as the encryp-
+          tion key for the request.  WARNING: the  use  of  single-use
+          authentication data in this manner is NOT recommended unless
+          the range of the SAD is large enough to make  an  exhaustive
+          off-line  search  impractical  and the risks involved in the
+          use of SAD alone are  fully  considered.   Also,  note  that
+          without  the availability to the KDC of a relatively static,
+          unique secret key shared with the user, the only  mechanisms
+          that  can  be  used  to protect the integrity of the PA-SAM-
+          CHALLENGE-2 PADATA field are  based  on  either  public  key
+          cryptography  or  the  KDC's  a  priori knowledge of the SAD
+          itself.  In the latter case, the client must obtain the  SAD
+          from  the  user  and  use  it to verify the integrity of the
+          challenge before the new KRB_AS_REQ message is sent.
+
+          The sam-pk-for-sad field is reserved  for  future  use.   If
+          this  field is not empty and the client does not support the
+          use of public-key encryption for SAD (to  be  defined  in  a
+          separate  document), the client will not be able to complete
+          the authentication and must notify the user.
+
+5.3  SAM-RESPONSE PA-DATA
+
+   The client will then send another KRB_AS_REQ message  to  the  KDC,
+   but with a padata field with padata-type equal to PA-SAM-RESPONSE-2
+   and padata-value defined as follows:
+
+          PA-SAM-RESPONSE-2 ::= SEQUENCE {
+              sam-type[0]                 INTEGER (0..4294967295),
+              sam-flags[1]                SAMFlags,
+              sam-track-id[2]             GeneralString OPTIONAL,
+              sam-enc-nonce-or-sad[3]     EncryptedData,
+                                             -- PA-ENC-SAM-RESPONSE-ENC
+                                             -- Key usage of 27
+              sam-nonce[4]                INTEGER (0..4294967295),
+              ...
+          }
+
+          PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
+               sam-nonce[0]               INTEGER (0..4294967295),
+               sam-sad[1]                 GeneralString OPTIONAL,
+               ...
+          }
+
+   The source of the data included in the PA-SAM-RESPONSE-2  structure
+   depends upon whether or not a KRB_ERROR message was received by the
+   client from the KDC.
+
+5.3.1  SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields
+
+   If an error reply was received, the sam-type, sam-flags,  and  sam-
+   nonce  fields will contain copies of the same fields from the error
+   message.
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 10]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   If no error reply was received  (i.e.,  the  client  knows  that  a
+   single-use  authentication  mechanism  is to be used), the sam-type
+   field must be set to a value chosen from  the  list  of  registered
+   sam-type codes.
+
+   The value of the sam-flags field may vary depending upon  the  type
+   of  SAM  in use, but in all cases the must-pk-encrypt-sad flag must
+   be zero.  If the send-encrypted-sad flag is set, the sam-sad  field
+   must  contain  the entered single-use authentication data (see Sec-
+   tion 5.3.3).
+
+5.3.2  SAM-TRACK-ID Field
+
+   Note that if there is no sam-track-id in the request,  it  MUST  be
+   omitted  in the response.  Otherwise, the sam-track-id data MUST be
+   copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2.
+
+5.3.3  SAM-ENC-NONCE-OR-SAD
+
+   The sam-enc-nonce-or-sad field represends the results of the preau-
+   thentication  process.   It  contains  the  encrypted SAD or a SAD-
+   encrypted nonce.  The PA-ENC-SAM-RESPONSE-ENC message is  encrypted
+   with  the SAD, password + SAD, or password (based on the sam-flags)
+   with key usage 27.  The fields of the  PA-ENC-SAM-REPONSE-ENC  mes-
+   sage are populated as follows:
+
+   The sam-nonce contains the nonce from the SAM-CHALLENGE-2.  This is
+   the same as the unencrypted sam-nonce described in section 5.2.2.
+
+   The sam-sad field contains the SAD if send-encrypted-sad is set  in
+   the sam-flags.  Otherwise, it is omitted.
+
+5.4  Verification of the SAM-RESPONSE-2
+
+   Upon receipt the KDC validates this PADATA in  much  the  same  way
+   that  it  validates  the  PA-ENC-TS preauthentication method except
+   that it uses the SAD (if available,  and  possibly  in  conjunction
+   with  saved  state information or portions of the preauthentication
+   data) to determine  the  correct  key(s)  required  to  verify  the
+   encrypted  data.   Note that if the KDC uses the sam-track-id field
+   to encode its state, the SAM-verification routine   is  responsible
+   for  including  information in that field to detect modification or
+   replay by an attacker.
+
+5.5  KRB5-AS-REP
+
+   The rest of the processing of the request proceeds normally, except
+   that  instead  of  being  encrypted  in  the user's secret key, the
+   KRB_AS_REP message is encrypted in the key obtained  above.   Note,
+   however, that some single-use authentication mechanisms may require
+   further KRB_AS_REQ/KRB_ERROR exchanges to complete  authentication;
+   for example, in order to allow the server to resynchronize with the
+   drifting clock on a time-based token card.  In these cases the  KDC
+   may  respond  with another KRB_ERROR message containing a different
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 11]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   sam-type value, along with appropriate prompts  and/or  challenges.
+   This  sequence  of  exchanges  will  continue  until authentication
+   either succeeds or fails.
+
+6.  Requirements for Single-use Authentication Mechanisms
+
+   Single-Use Authentication Mechanisms vary  in  their  capabilities.
+   To  aid  implementers,  we summarize here how various types of SAMs
+   would operate using this protocool.
+
+   If a SAM system can provide a SAD or a sequence of  valid  SADs  to
+   the   KDC,  then  the  implementation  SHOULD  NOT  set  the  send-
+   encrypted-sad flag.  This SAM system should provide the SAD to  the
+   KDC, which will combine it with the user's long-term key (password)
+   to generate the key used to generate the  checksum  placed  in  the
+   sam-cksum  field  in the PA-SAM-CHALLENGE-2 message.  This combined
+   key will also be used by the KDC to verify  PA-SAM-RESPONSE-2  mes-
+   sage  by  using it to decrypt the sam-enc-nonce-or-sad field and as
+   the key to encrypt the KRB-AS-REP.  If a SAM system returns a range
+   of  valid  responses, each response can be used to generate a valid
+   checksum which can be placed in the sam-cksum sequence.
+
+   If a SAM system can generate enough entropy, it can  set  the  use-
+   sad-as-key  field  to use the SAD solely as keying material, but it
+   should be noted that most SAM systems  that  require  the  user  to
+   enter  in  a  response  do  not  have enough entropy to replace the
+   user's long-term key.  The most likely consumer  of  use-sad-as-key
+   is a hardware token which communicates a key directly with Kerberos
+   client software.  With or without the use of  use-sad-as-key,  this
+   is  the  preferred method as it protects against offline dictionary
+   attacks against the user's password.
+
+   If a SAM system cannot provide a SAD or a sequence of SADs  to  the
+   KDC,  then  the send-encrypted-sad flag must be set.  In this case,
+   the SAD will be encrypted using the user's  long-term  key  in  the
+   PA-SAM-RESPONSE-2  message.   It  should  be  noted  that this is a
+   weaker solution, as it does not protect the user's password against
+   offline  dictionary attacks, and any additional entropy provided by
+   the SAM system cannot be used.
+
+7. Security considerations
+
+   Single-use authentication  mechanisms  requiring  the  use  of  the
+   send-encrypted-sad  option are discouraged as their use on the net-
+   work is less secure than the case where a combination of the  users
+   password  and  SAD  is  used as the encryption key.  In particular,
+   when  the  send-encrypted-sad  option  is  used,  an  attacker  who
+   observes the response and is in possession of the users' secret key
+   (which doesn't change from login to  login)  can  use  the  key  to
+   decrypt the response and obtain the single-use authentication data.
+   This is dependent on the SAM technology used.
+
+   If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field
+   but  the  client  software  being  used does not support public-key
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 12]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   cryptography, it is possible that legitimate users  may  be  denied
+   service.
+
+   An attacker in possession of the users encryption key (again, which
+   doesn't   change   from   login   to   login)   might  be  able  to
+   generate/modify a SAM challenge and attach the  appropriate  check-
+   sum.   This  affects  the  security  of both the send-encrypted-sad
+   option and the must-pk-encrypt-sad option.
+
+
+8. Expiration
+   This Internet-Draft expires on April 27, 2004.
+
+
+9. References
+
+   [RFC1510]
+        The Kerberos Network Authentication System; Kohl  and  Neuman;
+        September 1993.
+
+   [RFC1760]
+        The S/Key One-Time Password System; Haller; February 1995
+
+   [RFC1636]
+        Report of IAB Workshop on Security in the  Internet  Architec-
+        ture; Braden, Clark, Crocker and Huitema; June 1994
+
+   [KCRYPTO]
+        Encryption and Checksum Specifications for  Kerberos  5;  Rae-
+        burn; May 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 13]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+10. Authors' Addresses
+   Ken Hornstein
+   Naval Research Laboratory
+   4555 Overlook Avenue
+   Washington, DC 20375
+
+   Phone: 202-404-4765
+   EMail: kenh@cmf.nrl.navy.mil
+
+
+   Ken Renard
+   WareOnEarth
+   6849 Old Dominion Dr, Suite 365
+   Annandale, VA 22003
+
+   Phone: 703-622-3469
+   EMail: kdrenard@wareonearth.com
+
+
+   B. Clifford Neuman
+   USC/Information Sciences Institute
+   4676 Admiralty Way #1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: bcn@isi.edu
+
+
+   Glen Zorn
+   Cisco Systems
+   500 108th Ave NE
+   Suite 500
+   Bellevue, WA  98004
+
+   Phone: 425-344-8113
+   EMail: gwz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 14]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+Appendix A - Key combination algorithm
+
+   Definitions:
+
+   prf - Pseudo-random function that outputs an octet string based  on
+   an input key and a input octet string (defined in [KCRYPTO])
+
+   ^   - Exclusive-OR operation
+
+   random-to-key - Generates  an  encryption  key  from  random  input
+   (defined in [KCRYPTO])
+
+   Given two input keys, K1 and K2,  where  K1  is  derived  from  the
+   user's  long-term  password, and K2 is derived from the SAD, output
+   key (K3) is derived as follows:
+
+   Two sequence of octets, R1 and R2, shall be produced for  each  key
+   K1  and K2.  R1 and R2 will be generated by iterating over calls to
+   prf() until enough bits are generated as needed by  the  random-to-
+   key function for the encryption type specified for K3.
+
+   The octet-string parameter to the prf() function shall be the ASCII
+   string  "CombineA"  for  K1, and "CombineB" for K2.  These have the
+   following byte values:
+               { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 }
+               { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 }
+
+   Furthermore,  on  each  iteration  both  octet-strings  will   have
+   appended  to them the iteration count in the form of an ASCII, base
+   10, numeral.  The iteration count shall start at zero.  The  format
+   of  the iteration count is equivalant to the C language "%d" format
+   to the printf() function call.  Pseudo code implementing this  fol-
+   lows:
+
+   count = 0;
+   while ( bits < required_bits) {
+       sprintf(A1, "CombineA%d", count);
+       sprintf(A2, "CombineB%d", count);
+       R1 += prf(K1, A1);
+       R2 += prf(K2, A2);
+       count++;
+   }
+
+   When R1 and R2 have been generated, they are truncated if the  they
+   are  longer  than the length required by random-to-key.  The key is
+   then generated as follows:
+
+       K3 = random-to-key(R1 ^ R2)
+
+
+
+
+
+
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 15]
+
+
+
+
+
+INTERNET-DRAFT                                        October 27, 2003
+
+
+   Appendix B - DES/3DES Key combination algorithm
+
+      Definitions:
+
+      DR - generate "random" data from an encryption key  (defined  in
+      [KCRYPTO])
+
+      n-fold - "stretches" or "shrinks" a sequence bits to a specified
+      size (defined in [KCRYPTO])
+
+      random-to-key - Generates an encryption key  from  random  input
+      (defined in [KCRYPTO])
+
+      DK - Derive-Key, defined in [KCRYPTO])
+
+      CombineConstant - The ASCII encoding of  the  string  "combine",
+      which is defined as the following byte string:
+
+                   { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 }
+
+      Note: | means "concatenate"
+
+      Given two input keys, K1 and K2, the Combine-Key function is  as
+      follows:
+
+      R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1))
+
+      rnd = n-fold(R1 | R2)
+
+      tkey = random-to-key(rnd)
+
+      Combine-Key(K1, K2) = DK(tkey, CombineConstant)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornstein, Renard, Newman, Zorn                              [Page 16]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt
new file mode 100644
index 00000000000..da5dd0daca2
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt
@@ -0,0 +1,1352 @@
+
+Kerberos Working Group                                  Jonathan Trostle
+INTERNET-DRAFT                                             Cisco Systems
+Category: Standards Track                                     Mike Swift
+                                                        University of WA
+                                                             John Brezak
+                                                               Microsoft
+                                                            Bill Gossman
+                                                           Cisco Systems
+                                                        Nicolas Williams
+                                                        Sun Microsystems
+
+
+
+                Kerberos Set/Change Password: Version 2
+              <draft-ietf-krb-wg-kerberos-set-passwd-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 [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 December 31st, 2001. Please send comments to
+   the authors.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This proposal specifies an extensible protocol for setting keys and
+   changing the passwords of Kerberos [RFC1510] principals.
+
+   The protocol support a single operation per-session when run over UDP, or
+
+Trostle et. al.							[Page 1]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   multiple operations per-session when run over TCP.  Clients can
+   change their own principal's password or keys or they can change
+   other principals', provided that they are properly authorized to do
+   so.
+
+   Additional related features include the ability to determine the
+   known aliases of Kerberos principals.  This feature will facilitate
+   the implementation of aliasing of target principal names in KDC
+   requests by allowing principals to know which names are aliases of
+   their canonical principal names.  Principal aliasing is needed to
+   properly support the use of aliases and short-form names by users
+   without requiring that clients canonicalize principal names, possibly
+   using insecure name services in the process.
+
+   This protocol uses IETF language tags [RFC3066] to negotiate proper
+   localization of help messages intended for users.  UTF-8 is used
+   throughout for strings, suitably constrained, where necessary, by the
+   minor version of Kerberos V in use by clients and servers.
+
+1. Introduction
+
+   Kerberos lacks a single, standard protocol for changing passwords and
+   keys.  While several vendor-specific protocols exist for changing
+   Kerberos passwords/keys, none are properly internationalized.
+
+   This document defines a protocol that is somewhat backward-compatible
+   with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative
+   defined in [RFC3244] that uses more or less the same protocol framing.
+
+   This new protocol is designed to be extensible and properly
+   internationalized.
+
+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 [RFC2119].
+
+3. Table of Contents
+
+   1. Introduction
+   2. Conventions used in this document
+   3. Table of Contents
+   4. The Protocol
+   4.1 Transports
+   4.2 Protocol Framing
+   4.2.1 The protocol over UDP
+   4.2.2 The protocol over TCP
+   4.3 Protocol version negotiation
+   4.3.1 Protocol major version negotiation
+   4.3.2 Protocol minor version negotiation
+   4.4 Use of Kerberos V
+   4.4.1 Use of KRB-ERROR
+
+Trostle et. al.							[Page 2]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   4.5 Use of ASN.1
+   4.6 Protocol internationalization
+   4.6.1 Normalization forms for UTF-8 strings
+   4.6.2 Language negotiation
+   4.7 Protocol Extensibility
+   4.8 Protocol Subsets
+   5  Protocol Operations
+   5.1 PDUs
+   6  ASN1 Module
+   7 Descriptions of each protocol requests and responses
+   7.1 Null Request
+   7.2 Change Password
+   7.3 Set Keys Requests
+   7.5 The Get Policy Request
+   7.6 The Get Aliases Request
+   7.7 The Get Supported Enctypes Request
+   8 IANA Considerations
+   9 Security Considerations
+   10 Description of TLV Encoding of Sample Subsets of the Protocol
+   10.1 TLV encoding of the Null request and response
+   10.2 TLV encoding of Error-Response
+   10.3 TLV encoding of the change password requests and responses
+   10.4 TLV encoding of Change Keys requests and responses
+   11 Acknowledgements
+   12 References
+   13 Expiration Date
+   14 Authors' Addresses
+   15 Notes to the RFC Editor
+
+4. The Protocol
+
+   The structure of the protocol is quite similar to that of typical RPC
+   protocols.  Each operation has a structure for each client request and
+   a structure for each server response.  Each transaction consists of a
+   single operation; the abstract syntax for the protocol implies the
+   use, on the wire, of an operation identifier associated with an
+   opaque blob representing the request of response.  The protocol data
+   is wrapped in a KRB-PRIV and framed in a header that is backwards
+   compatible with version 1 of this protocol.
+
+4.1 Transports 
+
+   The service SHOULD accept requests on UDP port 464 and TCP port 464.
+   This is the same port used by version 1 [KPASSWDv1] of this protocol,
+   but version 2 is a completely different protocol sharing with version
+   1 only the outer framing.
+
+4.2 Protocol Framing
+
+   For compatibility with the original Kerberos password changing
+   protocol developed at MIT, the first 4 bytes of the message consist
+   of a 2-byte network byte order message length, followed by a 2 byte
+   network byte order protocol version number, followed by a 2 byte
+
+Trostle et. al.							[Page 3]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   network byte order length for an optional AP-REQ, AP-REP or
+   KRB-ERROR, followed by the same, if present, followed by a KRB-PRIV
+   (optional in TCP) containing the actual protocol message encoded in
+   DER [X690].
+
+   In the case of TCP there is an additional 4 byte network byte order
+   length prepended to the frame described above.
+   
+   The protocol version number MUST be set to 2 for this protocol.
+
+   Bytes on the wire description of the framing:
+
+       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 (0 if absent)   | AP-REQ data (if present)      /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                   KRB-PRIV message                            /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The same framing applies equally to requests and responses, but 
+   responses use AP-REP and/or KRB-ERROR instead of AP-REQ:
+
+       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 (0 if absent)   | AP-REP data (if present)      /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                   KRB-PRIV 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    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present)   /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included.
+
+   Note that this framing is used by version 1 [KPASSWDv1] and version
+   0xff80 [RFC3244], though the latter does not use the framing when
+   responding with KRB-ERROR messages.
+
+   Servers MAY respond to version 0xff80 requests with an un-framed
+   KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients
+   and server MUST always use this framing.  See section 4.3.
+
+
+Trostle et. al.							[Page 4]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+4.2.1 The protocol over UDP
+
+   In the UDP case there is a single message from the client and a
+   single response from the server with no state kept between requests,
+   and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and
+   each response MUST carry an AP-REP, or KRB-ERROR and a KDB-PRIV.
+   Both the client and server MUST destroy the authentication context
+   after each operation.
+
+   UDP clients MUST not request the use of sequence numbers, otherwise
+   it cannot generate the KRB-PRIV prior to receiving the AP-REP.
+   Clients MAY refuse to operate version 2 of the protocol over UDP; it
+   is RECOMMENDED that servers reject version 2 UDP requests.
+
+4.2.2 The protocol over TCP
+
+   When used with the TCP transport, there is a 4 octet header in
+   network byte order that precedes the message and specifies the length
+   of the message.
+
+   The initial message from the client MUST carry an AP-REQ and the
+   response to any request bearing an AP-REQ MUST carry an AP-REP.
+
+   Subsequent messages MAY involve Kerberos V AP exchanges, but
+   generally the client SHOULD NOT initiate a new AP exchange except
+   when it desires to authenticate as a different principal, when
+   its current authentication context is about to expire or when the
+   server responds with an error indicating that the client must
+   re-initialize the authentication context (possibly due to the
+   previous context expiring).
+
+   The server MUST NOT process any requests that do not contain an
+   AP-REQ unless a non-expired authentication context is currently
+   established with the client on the same TCP connection.
+
+   Servers MAY close open sessions at any time.
+
+4.3 Protocol version negotiation
+
+   There are several major versions of this protocol.  Version 2 also
+   introduces a notion of protocol minor versions for use in negotiating
+   protocol extensions.  As of this time only one minor version is
+   defined for major version 2: minor version 0.
+
+4.3.1 Protocol major version negotiation
+
+   Version 2 clients that also support other versions, such as
+   [KPASSWDv1] or [rfc3244] SHOULD attempt to use version 2 of the
+   protocol first and then try other versions if the server
+   responds with either a message framed as described in section 4.2 but
+   with a protocol version number other than 2 (in the case of
+   [KPASSWDv1], or a KRB-ERRROR with an error code of
+   KRB5_KPASSWD_BAD_VERSION in the e-data field [RFC3244].
+
+Trostle et. al.							[Page 5]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+   Note that some version 1 servers return a KRB-ERROR indicating that
+   versions other than 1 of the change password protocol are not
+   supported rather than an AP-REP and a KRB-PRIV containing the error
+   data.  Therefore change password protocol negotiation is subject to
+   downgrade attacks where version 2 clients support version 1 of this
+   protocol.
+
+   Also note that some [RFC3244] implementations do not return any
+   responses to requests for protocol versions other than 0xff80, and in
+   the TCP case close the TCP connection.
+
+   Version 2 servers MAY support other versions of the Kerberos password
+   change protocol.
+
+   Version 2 servers SHOULD respond to non-v2 requests using whatever
+   response is appropriate for the versions used by the clients, but if
+   a server does not do this or know how to do this then it MUST respond
+   with an error framed as in section 4.2, using an AP-REP and KRB-PRIV
+   if the client's AP-REQ can be accepted, or a KRB-ERROR (framed)
+   otherwise and using a ProtocolErrorCode value of
+   unsupported-major-version.
+
+4.3.2 Protocol minor version negotiation
+
+   Version 2 clients are free to use whatever protocol minor version and
+   message extensions are available to them in their initial messages to
+   version 2 servers, provided that the minor versions (other than 0)
+   have been defined through IETF documents and registered with the
+   IANA.
+
+   Version 2 clients and servers MUST support all protocol minor
+   versions between 0 to the highest version supported by the client and
+   server.  That is, a client or server that supports minor version 4
+   MUST also support minor versions 0, 1, 2 and 3.
+
+   Version 2 servers MUST answer with the highest protocol minor version
+   number supported by the server and the client.
+
+   Version 2 clients MUST use the protocol minor version used in a
+   server's reply for any subsequent messages in the same session
+   (currently this only applies to TCP sessions).
+
+   See section 4.7 for further description of the protocol's
+   extensibility and its relation to protocol minor versions and the
+   negotiation thereof.
+
+4.4 Use of Kerberos V
+
+   This protocol makes use of messages defined in [RFC1510] and
+   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
+   KRB-PRIV.  Because of the proposed extensions to Kerberos V which
+   will require a new ASN.1 module, and because of the ways that the
+
+Trostle et. al.							[Page 6]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   Kerberos V ASN.1 types will change, this protocol cannot safely
+   import any types from the Kerberos V module, therefore the Kerberos
+   PDUs are encoded as OCTET STRINGs herein.
+
+   All operations are to be performed by the server on behalf of the
+   client principal.
+
+   The client SHOULD use "kadmin/changepw" as the server principal name
+   for this protocol.  The server MUST have a principal name of
+   "kadmin/changepw" and MAY have a principal name of "kadmin/setpw."
+
+   The client MUST request mutual authentication and the client MUST NOT
+   request the use of sequence numbers when using the protocol over
+   UDP, but it MUST request the use of sequence numbers when running
+   over TCP.
+
+   The server MUST reject requests that operate on the same principal as
+   the client's if the client's principal is not in the same realm as
+   the server's principal name or if the client's ticket is not INITIAL.
+
+   The server MAY reject all requests from clients operating on
+   principals not in the client's realm.  The server MAY reject all
+   requests operating on principals other than the client's.
+
+4.4.1 Use of KRB-ERROR
+
+   When an error arises during the AP exchange for which
+   [clarifications] does not provide an appropriate error code then the
+   server MUST use KRB_ERR_GENERIC as the error, a localized (if
+   possible [er, is that ok, pre-extensions? probably not]) error string
+   for the e-text field of KRB-ERROR and the encoding of an
+   Error-Response PDU (see section 6) as e-data.
+
+4.5 Use of ASN.1
+
+   This protocol's messages are defined in ASN.1, using only features
+   from [X680].  All ASN.1 types defined herein are to be encoded in
+   DER [X690].  A complete ASN.1 module is given in section 6.  The
+   ASN.1 tagging environment for this module is EXPLICIT.
+
+   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
+   KRB-PRIV as described above.
+
+4.6 Protocol internationalization
+
+   Protocol requests have an optional field indicationg the languages
+   spoken by the client user; the client SHOULD send its list of spoken
+   languages to the server (once per-TCP session), but if future
+   extensions to the Kerberos protocol should add similar functionality
+   then the client SHOULD NOT use this field when using the extended
+   Kerberos protocol.  All strings in the protocol are UTF-8 strings.
+   The server SHOULD localize all strings intended for users to a
+   language in common with the languages spoken by the client user.
+
+Trostle et. al.							[Page 7]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+   For TCP sessions servers MUST cache the optional language tag lists
+   from prior requests for use with requests that exclude the language
+   tag list.  Clients MAY expect such server behaviour and send the
+   language tag lists only when they change or even just once per-TCP
+   session.  Clients SHOULD send the server the language tag list at
+   least once, with or before any actual operation.
+
+   Kerberos principal and realm names used in this protocol MUST be
+   constrained as per the specification of the version of Kerberos V
+   used by the client.
+
+4.6.1 Normalization forms for UTF-8 strings
+
+   No normalization form is required for string types other than
+   for PrincipalName and Realm, which two types are constrained by the
+   specification of the version of Kerberos V used by the client, and
+   the password fields in the change password operation, which MUST be
+   normalized according to [k5stringprep].
+
+4.6.2 Language negotiation
+
+   The server MUST pick a language from the client's input list or
+   the default language tag (see [RFC3066]) for text in its responses
+   which is meant for the user to read.
+
+   The server SHOULD use a language selection algorithm such that
+   consideration is first given to exact matches between the client's
+   spoken languages and the server's available locales, followed by
+   "fuzzy" matches where only the first sub-tags of the client's
+   language tag list are used for matching against the servers available
+   locales.
+
+   When the server has a message catalog for one of the client's spoken
+   languages the server SHOULD localize any text strings intended for
+   users to read.
+
+4.7 Protocol Extensibility
+
+   The protocol is defined in ASN.1 and uses extensibility markers
+   throughout.  As such, the module presented herein can be extended
+   within the framework of [X680].
+
+   Typed holes are not used in this protocol as it is very simple and
+   does not require the ability to deal with abstract data types defined
+   in different layers.  For this reason, the only way to extend this
+   protocol is by extending the ASN.1 module within the framework of the
+   IETF; all future extensions to this protocol have to be defined in
+   IETF documents unless otherwise specified in a future IETF revision
+   of this protocol.
+
+   A protocol minor version number is used to negotiate use of
+   extensions.  See section 4.3.2 for the minor version negotiation.
+
+Trostle et. al.							[Page 8]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+   Message extensions are to be closely tied to protocol minor numbers.
+   Clients MAY use any protocol minor version that they support in
+   initial requests, and MUST use the protocol minor version indicated
+   in the server's initial reply in any subsequent requests in the same
+   session (this only applies in the TCP case).  Clients MAY cache the
+   minor version number supported by any given server for a reasonably
+   short and finite amount of time - 24 hours is the maximum RECOMMENDED
+   time for caching server minor version information.
+
+   Servers SHOULD ignore protocol extensions and minor versions that they
+   do not understand in initial requests, except for extensions to the
+   "Op-req" type, which MUST result in an error; servers MAY respond
+   with an error (ProtocolErrorCode value of unsupported-minor-version)
+   to clients that use minor versions unsupported by the server in their
+   initial requests.
+
+   Servers MUST select the highest minor version in common with their
+   clients for use in replies.
+
+   Servers MAY support a subset of the operations defined in this
+   protocol but MUST support all the PDUs.
+
+4.8 Protocol Subsets
+
+   The structure of the protocol is such that the ASN.1 syntaxes for the
+   various operations supported by the protocol are independent of the
+   each other.  Clients and servers MAY implement subsets of the overall
+   protocol.
+
+   The structure of this protocol and the properties of the
+   tag-length-value (TLV) DER encoding of ASN.1 make it possible to
+   describe the encoding of individual operations' messages very simply.
+
+   In the interest of facilitating ease of implementation for trivial
+   subsets of this protocol, without the need for ASN.1 compilers,
+   section 10 describes examples of TLV layouts of some individual
+   protocol operations (but the DER encodings of tags, lengths and
+   UNIVERSAL values is not described).
+
+
+5  Protocol Operations
+
+   The protocol as defined herein supports the following operations
+   relating to the management of Kerberos principal's passwords or keys:
+
+     - change password
+     - set key
+     - get password policy name and/or description of principal
+     - list aliases of a principal
+     - list enctypes supported by realm
+
+   These operations are needed to support Kerberos V interoperability
+
+Trostle et. al.							[Page 9]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   between clients and KDCs of different implementation origins.
+
+   The operation for retrieving a list of aliases of a principal is
+   needed where KDCs implement aliasing of principal names and allows
+   clients to properly setup their "keytabs" when principal aliasing is
+   in use.
+
+   Operations such as creation or deletion of principals are outside the
+   scope of this document, and should be performed via directories or
+   other Kerberos administration protocols.  However, it is conceivable
+   that such operations could be added to this protocol at a later
+   point.
+
+   Operations can be added to the protocol only via future IETF RFCs.
+
+   The individual operations are described in section 7.
+
+5.1 PDUs
+
+   The types "Request," "Response" and "Error-Response" are the ASN.1
+   module's PDUs.
+
+   The "Request" and "Response" PDUs are always to be sent wrapped in
+   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
+   sent as KRB-ERROR e-data (see section 4.4.1) when AP exchanges fail,
+   otherwise it MUST be sent wrapped in a KRB-PRIV.
+
+   The PDUs are described in section 6.
+
+
+6  ASN1 Module
+
+DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+-- Unsafe: IMPORT AP-REQ, AP-REP, KRB-ERROR, KRB-PRIV, PrincipalName,
+--			    Realm, KerberosString, FROM KerberosV5Spec2
+
+-- From [clarifications]
+PrincipalName	    ::= SEQUENCE {
+	name-type   [0] Int32,
+	name-string [1] SEQUENCE OF UTF8String
+}
+Realm		    ::= UTF8String
+-- NOTE WELL: Principal and realm names MUST be constrained by the
+--            specification of the version of Kerberos V used by the
+--            client.
+-- 
+-- [Perhaps PrincipalName should be a SEQUENCE of an optional name type
+-- and a UTF8String, for simplicity.]
+
+-- From [clarifications]
+Int32	    ::= INTEGER (-2147483648..2147483647)
+UInt32	    ::= INTEGER (0..4294967295)
+
+Trostle et. al.							[Page 10]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+-- Based on EncryptionKey type from [clarifications]
+Key	    ::= SEQUENCE {
+	enc-type	[0] Int32,	-- from Kerberos
+	key		[1] OCTET STRING,
+	...
+}
+
+Etype	    ::= Int32	-- as in [clarifications]
+-- Perhaps we should use an extensible CHOICE of Int32?
+
+Language-Tag	    ::= UTF8String -- Constrained by [RFC3066]
+
+-- Use LangTaggedText instead of UTF8String for *-text fields and remove
+-- "language" field?
+--
+-- LangTaggedText should be used as e-text for KRB-ERROR, at least in
+-- extensions, perhaps in [clarifications]
+LangTaggedText	    ::= SEQUENCE {
+	language	[0] Language-Tag OPTIONAL,
+	text		[1] UTF8String,
+	...
+}
+
+Request		::= [APPLICATION 0] SEQUENCE {
+	pvno-major	[0] INTEGER DEFAULT 2,
+	pvno-minor	[1] INTEGER DEFAULT 0,
+	languages	[2] SEQUENCE OF Language-Tag OPTIONAL,
+	targ-name	[3] PrincipalName OPTIONAL,
+	targ-realm	[4] Realm OPTIONAL,
+		-- If targ-name/realm are missing then the request
+		-- applies to the principal of the client
+	operation	[5] Op-req,
+	...
+}
+
+Response	::= [APPLICATION 1] SEQUENCE {
+	pvno-major	[0] INTEGER DEFAULT 2,
+	pvno-minor	[1] INTEGER DEFAULT 0,
+	language	[2] Language-Tag DEFAULT "i-default",
+	result		[3] Op-rep OPTIONAL,
+	...
+}
+
+Error-Response	::= [APPLICATION 2] SEQUENCE {
+	pvno-major	[0] INTEGER DEFAULT 2,
+	pvno-minor	[1] INTEGER DEFAULT 0,
+	language	[2] Language-Tag DEFAULT "i-default",
+	error-code	[3] ProtocolErrorCode,
+	help-text	[4] UTF8String OPTIONAL,
+	op-error	[5] Op-error OPTIONAL,
+	...
+}
+
+Trostle et. al.							[Page 11]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+Op-req		::= CHOICE {
+	null			[0] Req-null,
+	change-pw		[1] Req-change-pw,
+	set-keys		[2] Req-set-keys,
+	get-pw-policy		[3] Req-get-pw-policy,
+	get-princ-aliases	[4] Req-get-princ-aliases,
+	get-supported-etypes	[5] Req-get-supported-etypes,
+	...
+}
+
+Op-rep		::= CHOICE {
+	null			[0] Rep-null,
+	change-pw		[1] Rep-change-pw,
+	set-keys		[2] Rep-set-keys,
+	get-pw-policy		[3] Rep-get-pw-policy,
+	get-princ-aliases	[4] Rep-get-princ-aliases,
+	get-supported-etypes	[5] Rep-get-supported-etypes,
+	...
+}
+
+Op-error	::= CHOICE {
+	null			[0] Err-null,
+	change-pw		[1] Err-change-pw,
+	set-keys		[2] Err-set-keys,
+	get-pw-policy		[3] Err-get-pw-policy,
+	get-princ-aliases	[4] Err-get-princ-aliases,
+	get-supported-etypes	[5] Err-get-supported-etypes,
+	...
+}
+
+ProtocolErrorCode	    ::= ENUM {
+	-- Remember, ASN.1 enums are zero-based
+	generic-error,
+	unsupported-major-version,
+	unsupported-minor-version,
+	unsupported-operation,
+	authorization-failed,
+	initial-ticket-required,
+	target-principal-unknown,
+	...
+}
+
+--
+-- Requests and responses
+--
+
+-- NULL request, much like ONC RPC's NULL procedure
+Req-null    ::= NULL
+
+Rep-null    ::= NULL
+
+Err-null    ::= NULL
+
+Trostle et. al.							[Page 12]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+-- Change password
+Req-change-pw	::= SEQUENCE {
+	old-pw		[0] UTF8String,
+	new-pw		[1] UTF8String OPTIONAL,
+	etypes		[2] SEQUENCE (1..) OF Etype OPTIONAL,
+	...
+}
+
+Rep-change-pw	::= SEQUENCE {
+	info-text	[0] UTF8String OPTIONAL,
+	new-pw		[1] UTF8String OPTIONAL,
+				-- generated by the server if present
+				-- (and requested by the client)
+	etypes		[2] SEQUENCE (1..) OF Etype OPTIONAL,
+	...
+}
+
+Err-change-pw	::= SEQUENCE {
+	help-text		[0] UTF8String OPTIONAL,
+	code			[1] ENUM {
+		generic,
+		wont-generate-new-pw,
+		old-pw-incorrect,
+		new-pw-rejected-generic,
+		pw-change-too-soon,
+		...
+	},
+	suggested-new-pw	[2] UTF8String OPTIONAL,
+	...
+}
+
+-- Change/Set keys
+
+Req-set-keys	::= SEQUENCE {
+	etypes		[0] SEQUENCE (1..) OF Etype,
+	entropy		[1] OCTET STRING OPTIONAL,
+				-- The client can provide entropy for
+				-- the server's use while generating
+				-- keys.
+	...
+}
+
+Rep-set-keys	::= SEQUENCE {
+	info-text	[0] UTF8String OPTIONAL,
+	kvno		[1] UInt32,
+	keys		[2] SEQUENCE (1..) OF Key,
+				-- The server always makes the keys.
+	aliases		[3] SEQUENCE OF SEQUENCE {
+		name	    [0] PrincipalName,
+		realm	    [1] Realm OPTIONAL,
+		...
+	} OPTIONAL,
+
+Trostle et. al.							[Page 13]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+	...
+}
+
+Err-set-keys	::= SEQUENCE {
+	help-text	[0] UTF8String OPTIONAL, -- Reason for rejection
+	enctypes	[1] SEQUENCE of Etype OPTIONAL, -- supported enctypes
+	code		[2] ENUM {
+		etype-no-support,
+		...
+	}
+}
+
+-- Get password policy
+Req-get-pw-policy   ::= NULL
+
+Rep-get-pw-policy   ::= SEQUENCE {
+	help-text	[0] UTF8String OPTIONAL,
+	policy-name	[1] UTF8String OPTIONAL,
+	description	[2] UTF8String OPTIONAL,
+	...
+}
+
+Err-get-pw-policy   ::= NULL
+
+-- Get principal aliases
+Req-get-princ-aliases	::= NULL
+
+Rep-get-princ-aliases	::= SEQUENCE {
+	help-text	[0] UTF8String OPTIONAL,
+	aliases		[1] SEQUENCE OF SEQUENCE {
+		name	    [0] PrincipalName,
+		realm	    [1] Realm OPTIONAL,
+		...
+	} OPTIONAL,
+	...
+}
+
+Err-get-princ-aliases	::= NULL
+
+-- Get list of enctypes supported by KDC for new keys
+Req-get-supported-etypes    ::=	NULL
+
+Rep-get-supported-etypes    ::= SEQUENCE OF Etype
+
+Err-get-supported-etypes    ::= NULL
+
+END
+
+7 Descriptions of each protocol requests and responses
+
+   This section describes the semantics of each operation request and
+   response defined in the ASN.1 module in section 6.
+
+
+Trostle et. al.							[Page 14]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   Requests and responses consist of an outer structure ("Request," 
+   "Response" and "Error-Response") containing fields common to all
+   requests/responses, and an inner structure for fields that are
+   specific to each operation's requests/responses.
+
+   Specifically, the outer Request structure has a field for passing a
+   client's spoken (read) languages to the server.  It also has two
+   optional fields for identifying the operation's target principal's
+   name and realm (if not sent then the server MUST use the client
+   principal name and realm from the AP exchange as the target).
+
+   The Response and Error PDU' outer structures include a field
+   indicating the language that the server has chosen for localization
+   of text intended to be displayed to users.
+
+   All three PDUs, "Request," "Response," and "Error-Response" include a
+   protocol version number and the two responses include an optional
+   field through which the server can indicate which language, from the
+   client's list, the server can "speak."
+
+7.1 Null Request
+
+   The null request is intended for use with TCP; its purpose is similar
+   to RPC null procedures and is akin to a "ping" operation.
+
+7.2 Change Password
+
+   The change password request has two fields: old-pw (old password -
+   required) and new-pw (new password - optional).  The server MUST
+   validate the old password and MUST check the quality of the new
+   password, if sent, according to the password policy associated with
+   the client's principal before accepting the request.  If the client
+   does not specify a new password the server MUST either generate one
+   and return it in the response or reject the request with
+   wont-generate-new-pw as the Err-change-pw message's error code.
+
+   If the server rejects a client's proposed new password it SHOULD
+   include a description of the password quality policy in effect for
+   the target principal and/or an explanation of what was wrong with the
+   proposed password in the help-text field of the Err-change-pw
+   message.  Additionally, servers MAY include a randomly generated, but
+   preferably user-friendly password in the suggested-new-pw field of
+   Err-change-pw messages when the client's proposed new password
+   violates the target principal's password quality policy; of course,
+   any such suggested new password MUST pass the target principal's
+   password quality policy.
+
+   Clients MAY specify key enctypes to set with new passwords, but
+   generally SHOULD NOT do so.  If a client requests specific enctypes
+   then the server MUST NOT create keys from the new password of any
+   enctype other than those requested by the client.
+
+   Servers MAY indicate the enctypes of the keys created with new
+
+Trostle et. al.							[Page 15]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   passwords, but SHOULD NOT do so unless the client requested specific
+   enctypes - in which case the server MUST include the new key enctypes
+   in the change password response.
+
+7.3 Set Keys Requests
+
+   The set keys request consists of a sequence of key enctypes and an
+   optional OCTET STRING of client-provided entropy.
+
+   The server generates keys of the requested enctypes and returns them.
+   The server MAY utilize some, all or none of the client-provided
+   entropy, if any, to generate the keys, but the server SHOULD input
+   some entropy in the process.
+
+   The server SHOULD also include a list of the target principal's
+   aliases, if there are any.
+
+7.5 The Get Policy Request
+   
+   It is common for sites to set policies with respect to password
+   quality.  It is beyond the scope of this document to describe such
+   policies.  However, it is reasonable for password policies to have
+   names and as such for this protocol to associate named password
+   quality policies with principals.  It may also be reasonable for
+   users to learn of their password quality policies.
+
+   The protocol therefore provides an operation for retrieving the name
+   and/or description of the password policy that applies to the target
+   principal name.
+
+   Management of password quality policies' actual content is beyond the
+   scope of this protocol.
+
+7.6 The Get Aliases Request
+   
+   This request allows a client to obtain a list of aliases associated
+   with a principal so that the client can properly configure the
+   principal's "keytab."
+
+   Principal aliases are principal names for which the KDC will issue
+   tickets (with the alias being either the client or target principal
+   name of such tickets) using the same key as the "canonical" principal
+   name, but without canonicalizing the aliased names in KDC exchanges.
+
+7.7 The Get Supported Enctypes Request
+
+   This request allows a client to learn of the target principal's
+   realm's supported enctypes.
+
+
+8 IANA Considerations
+
+   ...
+
+Trostle et. al.							[Page 16]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+
+9 Security Considerations
+   
+   Implementors and site administrators should note that the redundancy
+   of UTF-8 encodings varies by Unicode codepoint used.  Password
+   quality policies should, therefore, take this into account when
+   estimating the amount of redundancy and entropy in a proposed new
+   password.  [?? It's late at night - I think this is correct.]
+
+   Kerberos set/change password/key protocol major version negotiation
+   cannot be done securely.  A downgrade attack is possible against
+   clients that attempt to negotiate the protocol major version to use
+   with a server.  It is not clear at this time that the attacker would
+   gain much from such a downgrade attack other than denial of service
+   (DoS) by forcing the client to use a protocol version which does not
+   support some feature needed by the client (Kerberos V in general is
+   subject to a variety of DoS attacks anyways [RFC1510]).
+
+   [More text needed]
+
+10 Description of TLV Encoding of Sample Subsets of the Protocol
+
+  This section provides example descriptions of the TLV DER encodings of
+  some requests and responses.  This section is not intended to be
+  authoritative and implementors are encouraged to base their
+  implementations on the ASN.1 syntax given in section 6.  These TLV
+  descriptions are given here in the interest of promoting
+  implementation of this protocol even by implementors who do not have
+  access to ASN.1 development tools.
+
+  Tags are described as T(<tag>) where <tag> is a letter denoting the
+  tag type (u for UNIVERSAL, a for APPLICATION, c for CONTEXT and p for
+  PRIVATE) and a number or universal type name.
+
+  Lengths and values are described as L{<value>}, where <value> is a
+  description of the encoding of the value, except for scalar UNIVERSAL
+  types, where <value> shall be '<' description of value '>'.
+
+  Optional fields are enclosed in square brackets ('[' and ']').
+
+  Repetition is denoted by ellipsis ("...").
+
+  Extensibility is denoted by "[...]".
+
+  Comments are introduced by "--" as in ASN.1
+
+10.1 TLV encoding of the Null request and response
+
+   -- Null Request
+   -- Outer application tag
+   T(a0)L{T(uSEQUENCE)L{
+     -- "preamble"
+     -- pvno-major == 2 so it is left out
+
+Trostle et. al.							[Page 17]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+     -- pvno-minor == 0 so it is left out
+     -- optional languages list
+     [T(c2)L{
+       T(uSEQUENCE)L{
+         T(uUTF8String)L{<language tag>}
+         ...
+       }
+     }]
+     -- optional targ-name
+     [T(c3)L{
+       Tc(uSEQUENCE)L{
+	 -- name-type
+         T(c0)L{T(uINTEGER)L{<name-type>}}
+	 -- name-string
+	 T(c1)L{
+	   T(uSEQUENCE)L{
+	     [T(uUTF8String)L{<component name>}]
+	     ...
+	   }
+	 }
+       }
+     }]
+     -- optional targ-realm
+     [T(c4)L{T(uUTF8String)L{<realm name>}}]
+     -- end of preamble
+
+     -- operation choice tag
+     T(c5)L{
+       -- null CHOICE (this tag indicates the CHOICE taken; replace this
+       -- TLV with the TLV for any operation to get the Request encoding
+       -- of that operation)
+       T(c0)L{
+	 -- Req-null (this is the encoding of the value of the CHOICE
+	 -- taken); NULL has no LV part.
+	 T(uNULL)
+       }
+     }
+     -- extensions
+     [...]
+   }}
+
+   -- Null Response
+   -- Outer application tag
+   T(a1)L{T(uSEQUENCE)L{
+     -- "preamble"
+     -- pvno-major == 2 so it is left out
+     -- pvno-minor == 0 so it is left out
+     -- optional language
+     [T(c1)L{T(uUTF8String)L{<language tag>}}]
+     -- end preamble
+     -- operation choice tag
+     T(c2)L{
+       -- null CHOICE
+
+Trostle et. al.							[Page 18]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+       T(c0)L{
+         T(uNULL)
+       }
+     }
+   }}
+
+10.2 TLV encoding of Error-Response
+
+   -- Error Response
+   -- Outer application tag
+   T(a1)L{T(uSEQUENCE)L{
+     -- "preamble"
+     -- pvno-major == 2 so it is left out
+     -- pvno-minor == 0 so it is left out
+     -- optional language
+     [T(c2)L{T(uUTF8String)L{<language tag>}}]
+     -- end preamble
+     -- error code
+     T(c3)L{T(uENUM)L{<error code}}
+     T(c4)L{T(uUTF8String)L{<error text}}
+     -- optional CHOICE
+     T(c5)L{
+       -- CHOICE TLV goes here
+       T(c<choice taken>)L{<value of CHOICE taken>}
+     }
+     -- extensions
+     [...]
+   }}
+
+10.3 TLV encoding of the change password requests and responses
+
+   -- Req-change-pw
+     -- choice tag
+     T(c1)L{
+       T(uSEQUENCE)L{
+	 -- old password
+	 T(c0)L{T(uUTF8String)L{<password string>}}
+	 -- new password (optional; if missing server must generate it)
+	 [T(c1)L{T(uUTF8String)L{<password string>}}]
+	 -- extensions
+	 [...]
+       }
+     }
+
+   -- Rep-change-pw
+     -- choice tag
+     T(c1)L{
+       T(uSEQUENCE)L{
+	 -- optional informational text
+	 [T(c0)L{T(uUTF8String)L{<text>}}]
+	 -- new password (optional; see section 6)
+	 [T(c1)L{T(uUTF8String)L{<new password>}}]
+	 -- extensions
+
+Trostle et. al.							[Page 19]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+	 [...]
+       }
+     }
+
+   -- Err-change-pw
+     -- choice tag
+     T(c1)L{
+       T(uSEQUENCE)L{
+	 -- optional help text
+	 [T(c0)L{T(uUTF8String)L{<text>}}]
+	 -- error code
+	 T(c1)L{T(uENUM)L{<error code>}}]
+	 -- extensions
+	 [...]
+       }
+     }
+
+10.4 TLV encoding of Change Keys requests and responses
+
+   -- Req-set-keys
+     -- choice tag
+     T(c1)L{
+       T(uSEQUENCE)L{
+	 -- new key enctypes
+	 T(c0)L{T(uSEQUENCE)L{
+	   T(uINTEGER)L{<etype integer>},
+	   ...
+	 }}
+	 -- optional entropy
+	 [T(c1)L{T(uOCTET STRING)L{<entropy>}}]
+	 -- extensions
+	 [...]
+       }
+     }
+
+   -- Rep-set-keys
+     -- choice tag
+     T(c1)L{
+       T(uSEQUENCE)L{
+	 -- optional informational text
+	 [T(c0)L{T(uUTF8String)L{<text>}}]
+	 -- new kvno
+	 T(c1)L{T(uINTEGER)L{<new kvno>}}
+	 -- new keys
+	 T(c2)L{T(uSEQUENCE)L{
+	   -- first key
+	   T(uSEQUENCE)L{
+	     T(uINTEGER)L{<etype>}
+	     T(uOCTET STRING)L{<key>}
+	     -- extensions to Key
+	     [...]
+	   }
+	   -- additional keys, if any
+
+Trostle et. al.							[Page 20]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+	   ...
+	 }}
+	 -- optional aliases
+	 [T(c3)L{T(uSEQUENCE)L{
+	   -- first alias
+	   T(uSEQUENCE)L{
+	     -- principal name
+	     T(uSEQUENCE)L{
+	       T(uUTF8String)L{<component1>},
+	       -- components 2..N, if any
+	       ...
+	     }
+	     T(uUTF8String)L{<realm name>}
+	     -- extensions
+	     [...]
+	   }
+	   -- additional aliases, if any
+	   ...
+	 }}]
+	 -- extensions
+	 [...]
+       }
+     }
+
+   -- Err-set-keys
+     -- choice tag
+     T(c1)L{
+       T(uSEQUENCE)L{
+	 -- optional help text
+	 [T(c0)L{T(uUTF8String)L{<text>}}]
+	 -- KDC supported enctypes
+	 [T(c1)L{T(uSEQUENCE)L{
+	   T(uINTEGER)L{<etype integer>},
+	   ...
+	 }}]
+	 -- error code
+	 T(c2)L{T(uENUM)L{<error code>}}]
+	 -- extensions
+	 [...]
+       }
+     }
+
+11 Acknowledgements
+   
+   The authors would like to thank Sam Hartman, Paul W. Nelson and
+   Marcus Watts for their assistance.
+
+   The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
+   Andrea, Paul W. Nelson, Marcus Watts and other participants from the
+   IETF Kerberos Working Group for their input to the document.
+
+12 References
+
+
+Trostle et. al.							[Page 21]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+12.1 Normative References
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2119]
+      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
+      Indicate Requirement Levels," March 1997, Status: Best Current
+      Practice.
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
+
+   [RFC1510]
+      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
+      Authentication Service (v5)," September 1993, Status: Proposed
+      Standard.
+
+   [clarifications]
+      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
+      kerberos-clarifications.
+
+   [k5stringprep]
+      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
+      utf8-profile.
+
+   [RFC3066]
+      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
+      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
+      Practice.
+
+   [KPASSWDv1]
+      (Reference needed!)
+
+12.1 Informative References
+
+   [RFC3244]
+      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
+      Kerberos Change Password and Set Password Protocols," February
+      2002, Status: Informational.
+
+
+Trostle et. al.							[Page 22]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+13 Authors' Addresses
+
+      Jonathan Trostle
+      Cisco Systems
+      170 W. Tasman Dr.
+      San Jose, CA 95134
+      Email: jtrostle@cisco.com
+
+      Mike Swift
+      University of Washington
+      Seattle, WA
+      Email: mikesw@cs.washington.edu
+
+      John Brezak
+      Microsoft
+      1 Microsoft Way
+      Redmond, WA 98052
+      Email: jbrezak@microsoft.com
+
+      Bill Gossman
+      Cisco Systems
+      500 108th Ave. NE, Suite 500
+      Bellevue, WA 98004
+      Email: bgossman@cisco.com
+
+      Nicolas Williams
+      Sun Microsystems
+      5300 Riata Trace Ct
+      Austin, TX 78727
+      Email: nicolas.williams@sun.com
+
+14 Notes to the RFC Editor
+
+   This document has two KRB WG drafts as normative references and
+   cannot progress until those drafts progress, but no other draft
+   depends on this one.
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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
+
+Trostle et. al.							[Page 23]
+
+DRAFT		Kerberos Set/Change Password v2		Expires November 2003
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt
new file mode 100644
index 00000000000..a25d8096ca4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt
@@ -0,0 +1,1793 @@
+
+Kerberos Working Group                                  Nicolas Williams
+INTERNET-DRAFT                                          Sun Microsystems
+Category: Standards Track                               Jonathan Trostle
+                                                           Cisco Systems
+
+
+
+                Kerberos Set/Change Password: Version 2
+              <draft-ietf-krb-wg-kerberos-set-passwd-02.txt>
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on January 12, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document specifies an extensible protocol for setting keys and
+   changing the passwords of Kerberos V principals.
+
+Table of Contents
+
+   1  Introduction
+   2  The Protocol
+   2.1  Transports 
+   2.2  Protocol Framing
+   2.3  Protocol version negotiation
+   2.3.1  Protocol Major Version Negotiation
+   2.3.2  Protocol Minor Version Negotiation
+   2.4  Use of Kerberos V
+
+N. Williams et. al.						[Page 1]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   2.5  Use of ASN.1
+   2.6  Internationalization
+   2.6.1  Normalization Forms for UTF-8 Strings
+   2.6.2  Language Negotiation
+   2.7  Protocol Extensibility
+   2.8  Protocol Subsets
+   3  Protocol Elements
+   3.1  PDUs
+   3.2  Operations
+   3.2.1  Null
+   3.2.2  Change Kerberos Password
+   3.2.3  Set Kerberos Password
+   3.2.4  Set Kerberos Keys
+   3.2.5  Generate Kerberos Keys
+   3.2.6  Get New Keys
+   3.2.7  Commit New Keys
+   3.2.8  Get Password Quality Policy
+   3.2.9  Get Principal Aliases
+   3.2.10  Get Realm's Supported Kerberos V Version and Features
+   4  ASN.1 Module
+   6  IANA Considerations
+   7  Security Considerations
+   8  Acknowledgements
+   9  References
+   9.1  Normative References
+   9.2  Informative References
+   10  Authors' Addresses
+   11  Notes to the RFC Editor
+
+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 [RFC2119].
+
+1  Introduction
+
+   Up to this point Kerberos V has lacked a single, standard protocol
+   for changing passwords and keys.  While several vendor-specific
+   protocols exist for changing Kerberos passwords/keys, none are
+   properly internationalized and all are incomplete in one respect or
+   another and none are sufficiently extensible to cope with new
+   features that may be added to Kerberos V at some future time.
+
+   This document defines a protocol that is somewhat backward-compatible
+   with the "kpasswd" protocol defined in [RFC3244] that uses more or
+   less the same protocol framing.
+
+   This new protocol is designed to be extensible and properly
+   internationalized.
+
+2  The Protocol
+
+
+N. Williams et. al.						[Page 2]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   The structure of the protocol is quite similar to that of typical RPC
+   protocols.  Each transaction consists of a data structure specific to
+   an operation which is then wrapped in a data structure which is
+   general to all operations of the protocol.  These data structures are
+   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
+   are encoded using the Distinguished Encoding Rules (DER) [X690].
+
+   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
+   KRB-ERROR, and framed in a header that is backwards compatible with
+   [RFC3244].
+
+2.1  Transports 
+
+   The service supports only connection-oriented transports,
+   specifically TCP, and MUST accept requests on TCP port 464, the same
+   as in [RFC3244].
+
+2.2  Protocol Framing
+
+   Requests and responses are exchanged using the same framing as in
+   [RFC3244], but with the following differences:
+
+    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
+
+    - the 'AP-REQ length' field of the request can be set to 0x0, in
+      which case the 'AP-REQ' field of the request is excluded
+
+    - the 'KRB-PRIV' field of the request and reply is mutually
+      exclusive with the 'AP-REQ' field of the request
+
+    - the 'AP-REP length' field of the reply can be set to 0x0, in
+      which case the 'AP-REP' field of the reply is excluded
+
+    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
+      be or has been accepted by the server
+
+    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
+      of the reply
+
+   The initial message from the client MUST carry an AP-REQ and the
+   response to any request bearing an AP-REQ MUST carry an AP-REP or
+   MUST be a KRB-ERROR.
+
+   Subsequent messages exchanged on the same TCP connection MAY involve
+   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
+   a new AP exchange except when it desires to authenticate as a
+   different principal, when the ticket last used for authentication
+   expires or when the server responds with an error indicating that the
+   client must re-authenticate.
+
+2.3  Protocol Version Negotiation
+
+   There are several major versions of this protocol.  Version 2 also
+
+N. Williams et. al.						[Page 3]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   introduces a notion of protocol minor versions for use in negotiating
+   protocol extensions.  As of this time only one minor version is
+   defined for major version 2: minor version 0, defined herein.
+
+2.3.1  Protocol Major Version Negotiation
+
+   Version 2 clients that also support other versions, such as 0xff80,
+   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
+   first.
+
+   Servers which do not support version 2 of this protocol typically
+   include their preferred version number in the reply and/or may
+   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
+   status code of KRB5_KPASSWD_MALFORMED.
+
+   Note that some [RFC3244] server implementations close the TCP
+   connection without returning any other response.  Note also that
+   there is no integrity protection for the major version number in the
+   protocol framing or for any data in a KRB-ERROR.
+
+   As a result change password protocol major version negotiation is
+   subject to downgrade attacks.  Therefore major version negotiation is
+   NOT RECOMMENDED.
+
+   Where the server indicates that it does not support version 2, the
+   client MAY, but SHOULD NOT, unless configured to do so, fall back on
+   another major version of this protocol.
+
+   Version 2 servers MAY respond to non-v2 requests using whatever
+   response is appropriate for the versions used by the clients, but if
+   a server does not do this or know how to do this then it MUST respond
+   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
+   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
+   using a ProtocolErrorCode value of unsupported-major-version.
+
+   It is expected that implementations of as yet unspecified future
+   major versions of this protocol will be required to support version 2
+   integrity protected error replies for properly indicating no support
+   for version 2 of the protocl.  We also hope that no further major
+   versions of this protocol will be needed.
+
+2.3.2  Protocol Minor Version Negotiation
+
+   Version 2 clients are free to use whatever protocol minor version and
+   message extensions are available to them in their initial messages to
+   version 2 servers, provided that the minor versions (other than 0)
+   have been defined through IETF documents.
+
+   Version 2 servers MUST answer with the highest protocol minor version
+   number supported by the server and the client.
+
+   Version 2 clients MUST use the protocol minor version used in a
+   server's reply for any subsequent messages in the same TCP session.
+
+N. Williams et. al.						[Page 4]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+   See section 2.7 for further description of the protocol's
+   extensibility and its relation to protocol minor versions and the
+   negotiation thereof.
+
+2.4  Use of Kerberos V and Key Exchange
+
+   This protocol makes use of messages defined in [RFC1510] and
+   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
+   KRB-PRIV.
+
+   All operations are to be performed by the server on behalf of the
+   client principal.
+
+   Clients SHOULD use "kadmin/setpw" as the principal name of the server
+   for all requests except when changing the client principal's own
+   expired password, for which they should use "kadmin/changepw".  The 
+   "kadmin/changepw" service exists to allow KDCs to limit principals
+   with expired passwords to getting initial tickets to the password
+   changing service only and only for changing expired passwords.
+
+   Servers MUST limit clients that used the "kadmin/changepw" service
+   principal name to changing the password of the client principal.
+
+   The client MUST request mutual authentication and the client MUST
+   MUST request the use of sequence numbers.
+
+   Clients SHOULD use INITIAL tickets for requests whose target
+   principal is the client's principal.  Servers SHOULD force the use of
+   INITIAL tickets for such requests and MAY force the use of INITIAL
+   for all others - see section 3.2.
+
+   Servers MUST specify a sub-session key.
+
+   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
+   sub-session key and key usage 20 (client->server) or 21
+   (server->client).
+
+   After each new AP exchange the client and server MUST destroy the
+   session keys, if any, resulting from the previous AP exchange.
+
+2.5  Use of ASN.1
+
+   This protocol's messages are defined in ASN.1, using only features
+   from [X680].  All ASN.1 types defined herein are to be encoded in
+   DER [X690].  A complete ASN.1 module is given in section 4.
+
+   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
+   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
+
+2.6  Internationalization
+
+   This protocol's request PDU carries an optional field indicating the
+
+N. Williams et. al.						[Page 5]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   languages spoken by the client user; the client SHOULD send its list
+   of spoken languages to the server (once per-TCP session).
+
+   The server SHOULD localize all strings intended for display to users
+   to a language in common with the languages spoken by the client user.
+
+   Strings for Kerberos principal and realm names used in this protocol
+   are be constrained as per [clarifications].
+
+2.6.1  Normalization Forms for UTF-8 Strings
+
+   Because Kerberos V [clarifications] restricts principal names, realm
+   names and passwords to IA5String, this protocol uses UTF8String with
+   an extensible constraint to IA5String.
+
+   Future versions of Kerberos may relax this constraint; if so then a
+   minor version of this protocol should relax this constraint
+   accordingly.
+
+2.6.2  Language Negotiation
+
+   The server MUST pick a language from the client's input list or
+   the default language tag (see [RFC3066]) for text in its responses
+   which is meant for the user to read.
+
+   The server SHOULD use a language selection algorithm such that
+   consideration is first given to exact matches between the client's
+   spoken languages and the server's available locales, followed by
+   "fuzzy" matches where only the first sub-tags of the client's
+   language tag list are used for matching against the servers available
+   locales.
+
+   Servers MUST cache the optional language tag lists from prior
+   requests for use with subsequent requests that exclude the language
+   tag list.  Clients MAY expect such server behaviour and send the
+   language tag lists only once per-TCP session.  Clients SHOULD send
+   the server the language tag list at least once.
+
+   When the server has a message catalog for one of the client's spoken
+   languages the server SHOULD localize any text strings intended for
+   display to users.
+
+2.7  Protocol Extensibility
+
+   The protocol is defined in ASN.1 and uses extensibility markers
+   throughout.  As such, the module presented herein can be extended
+   within the framework of [X680].
+
+   Typed holes are not used in this protocol as it is very simple and
+   does not require the ability to deal with abstract data types defined
+   in different layers.  For this reason, the only way to extend this
+   protocol is by extending the ASN.1 module within the framework of the
+   IETF; all future extensions to this protocol have to be defined in
+
+N. Williams et. al.						[Page 6]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   IETF documents unless otherwise specified in a future IETF revision
+   of this protocol.
+
+   A protocol minor version number is used to negotiate use of
+   extensions.  See section 2.3.2 for the minor version negotiation.
+
+   Servers SHOULD ignore unknown additions to the ASN.1 types, in
+   initial requests, where the syntax allows them, except for extensions
+   to the "Op-req" type, which MUST result in an error.
+
+   Servers MUST respond with an error (ProtocolErrorCode value of
+   unsupported-minor-version) to clients that use operations unknown to
+   the server.
+
+2.8  Protocol Subsets
+
+   The structure of the protocol is such that the ASN.1 syntaxes for the
+   various operations supported by the protocol are independent of the
+   each other.  Client and server implementations MAY implement subsets
+   of the overall protocol by removing some alternatives to the Op-req,
+   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
+   
+   For example, it should be possible to have a password-change only
+   client that cannot set principal's keys - and vice versa.
+
+3  Protocol Elements
+
+   The protocol as defined herein supports the following operations
+   relating to the management of Kerberos principal's passwords or keys:
+
+     [NOTE:  New since last version of this I-D.]
+     - get principal's current and preferred string-to-key parameters
+
+     - change password (or enctypes and string-to-key parameters)
+     - set password (administrative)
+     - set new keys
+     - generate new keys
+     - get new, un-committed keys
+     - commit new keys
+     - get password policy name and/or description of principal
+     - list aliases of a principal
+     - list enctypes and version of Kerberos V supported by realm
+
+   The operation for retrieving a list of aliases of a principal is
+   needed where KDCs implement aliasing of principal names and allows
+   clients to properly setup their key databases when principal aliasing
+   is in use.
+
+   Operations such as creation or deletion of principals are outside the
+   scope of this document, and should be performed via other means, such
+   as through directories or other Kerberos administration protocols.
+
+   The individual operations are described in section 3.2.
+
+N. Williams et. al.						[Page 7]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+3.1  PDUs
+
+   The types "Request," "Response" and "Error-Response" are the ASN.1
+   module's PDUs.
+
+   The "Request" and "Response" PDUs are always to be sent wrapped in
+   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
+   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
+   otherwise it MUST be sent wrapped in a KRB-PRIV.
+
+   The ASN.1 syntax for the PDUs is given in section 4.
+
+   Note that the first field of each PDU is the major version of the
+   protocol, defaulted to 2, meaning that it is never included in
+   version 2 exchanges.  Similarly, the second field of each PDU is the
+   minor version, defaulted to 0.
+
+   The request, responses and error PDUs consist of an outer structure
+   ("Request," "Response" and "Error-Response") containing fields common
+   to all requests, responses and errors, respectively, and an inner
+   structure for fields that are specific to each operation's
+   requests/responses.  The inner structure is optional in the case of
+   the Error-Response PDU and need not be included when generic errors
+   occur for which there is a suitable ProtocolErrorCode.
+
+   Specifically, the outer Request structure has a field for passing a
+   client user's spoken (read) languages to the server.  It also has two
+   optional fields for identifying the requested operation's target
+   principal's name and realm (if not sent then the server MUST use the
+   client's principal name and realm as the target).  A boolean field
+   for indicating whether or not the request should be dry-run is also
+   included; dry-runs can be used to test server policies, and servers
+   MUST NOT modify any principals when processing dry-run requests.
+
+   The Response and Error PDUs' outer structures include a field
+   indicating the language that the server has chosen for localization
+   of text intended to be displayed to users; this field is defaulted to
+   "i-default".  This language tag applies to all UTF8 strings in the
+   inner structure (Op-rep and Op-err) that are meant to be displayed to
+   users.
+
+   The protocol error codes are:
+
+      - proto-generic-error
+
+        An operation-specific error ocurred, see the inner Op-error.
+
+      - proto-format-error
+      - proto-unsupported-major-version
+      - proto-unsupported-minor-version
+      - proto-unsupported-operation
+
+
+N. Williams et. al.						[Page 8]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      - proto-wrong-service-principal
+
+        Use kadmin/setpw for the server's principal name.
+
+      - proto-re-authentication-required
+
+        The server demands that the client re-authenticate through a new
+        AP exchange.
+
+      - proto-initial-ticket-required
+
+        Use of an INITIAL ticket is required for the requested
+        operation.
+
+      - proto-client-and-target-realm-mismatch
+
+        The server requires that the client's principal name and the
+        target principal of the operation share the same realm name.
+
+      - proto-target-principal-unknown
+      - proto-authorization-failed
+
+3.2  Operations
+
+   This section describes the semantics of each operation request and
+   response defined in the ASN.1 module in section 4.
+      
+3.2.1  Null
+
+   NAME
+
+      null - Null or "ping" operation
+
+   DESCRIPTION
+
+      The null request is intended for use with TCP; its purpose is
+      similar to RPC null procedures and is akin to a "ping" operation.
+
+   ERRORS
+
+      None.
+
+3.2.2  Change Kerberos Password
+
+   NAME
+
+      change-pw - Change password operation
+
+   SYNOPSIS
+
+      Req-change-pw(old-pw, [languages], [new-pw],
+                    [commit], [etypes]) ->
+         Rep-change-pw([info-text], [new-pw], [etypes]) |
+
+N. Williams et. al.						[Page 9]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+         Err-change-pw([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      Change a principal's password.
+
+      The change password request has one required, three optional and
+      one defaulted arguments: "old-pw" (required), "languages,"
+      "new-pw", "commit" (defaults to "TRUE") and "etypes",
+      corresponding to the target principal's old password, its
+      preferred languages, its new password, a boolean indicating
+      whether or not to make the new long-term key available for
+      immediate use, and the desired enctypes for the new long-term
+      keys.
+
+      The server MUST validate the old password and MUST check the
+      quality of the new password, if sent, according the password
+      quality policy associated with the target principal.
+
+      If the old and new passwords in the request are the same strings,
+      and the principal is not currently required to change its
+      password, then the server MAY permit the password change as way to
+      change a principal's enctypes and string-to-key parameters.  This
+      feature provides a way to, for example, add enctypes to a
+      principals' password-derived long-term keys without forcing a
+      password change following an upgrade to the KDC that adds support
+      for new enctypes.
+
+      A client MAY request that the server generate a new password by
+      excluding the new password from its request, in which case the
+      server MUST either generate a new password or respond with an
+      error indicating that it does not support this feature.
+
+      Server-generated passwords MUST meet the target principal's
+      password quality policy.  It is RECOMMENDED that server-generated
+      passwords be user-friendly, that is, memorable and that the target
+      principal's preferred languages be taken into account by the
+      password generation alogrithm used by the server.
+
+      Uncommitted password changes are commited using the commit-keys
+      operation.
+
+   RETURN
+
+      Upon successful password changes the server responds with a
+      Rep-change-pw.  The fields of Rep-change-pw are all optional and
+      include:
+
+         - 'info-text' which the server can use to send a message to the
+           user such as "Your new password will expire in 90 days," for
+           example.
+
+         - 'new-pw' which the server MUST include if the client
+
+N. Williams et. al.						[Page 10]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+           requested that the server generate a new password; generated
+           passwords MUST pass the target principal's password quality
+           policy.
+
+         - 'etypes' which the server MAY include to indicate which types
+           of long-term keys it created for the target principal and
+           which the server MUST include if the client specified a set
+           of enctypes in its request.
+
+   ERRORS
+
+      The server may respond to change password requests with protocol
+      or operation errors.  See section 3.1 for a description of
+      protocol error codes.
+
+      All operation errors include an optional 'help-text' field by
+      which the server can describe the error in a human-readable,
+      localizaed string.
+
+      Change password error codes include:
+
+         - generic-error
+
+         - old-pw-incorrect
+
+         - wont-generate-new-pw
+
+           The server will not generate a new password for this
+           principal or does not support password generation in general.
+
+         - new-pw-rejected-generic
+
+           The client's proposed new password failed the target
+           principal's password quality policy.
+
+           The server MUST include a description of the password quality
+           policy or aspect of it that the client's proposed new
+           password failed to meet.
+
+           The server MAY generate and send a new password that the
+           client can then use as a new password and which is guaranteed
+           to pass the target principal's current password quality
+           policy.
+
+           The server MAY include a set of policy error code hints.
+
+         - etype-not-supported
+
+           The client requested an enctype that the KDC does not
+           support.
+
+3.2.3  Set Kerberos Password
+
+
+N. Williams et. al.						[Page 11]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   NAME
+
+      set-pw - Set password operation
+
+   SYNOPSIS
+
+      Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
+         Rep-set-pw([info-text], [new-pw], [etypes]) |
+         Err-set-pw([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      Administratively set a principal's password.
+
+      The set password request has three optional and one defaulted
+      arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
+      and "etypes", corresponding to the target principal's preferred
+      languages, new password, a boolean indicating whether or not to
+      make the new long-term key available for immediate use, and the
+      desired enctypes for the new long-term keys.
+
+      The server MUST check the quality of the new password, if sent,
+      according the password quality policy associated with the target
+      principal.
+
+      The server SHOULD require that the client use the change-pw
+      operation instead of set-pw when the client principal and the
+      target principal are the same.
+
+      A client MAY request that the server generate a new password by
+      excluding the new password from its request, in which case the
+      server MUST either generate a new password or respond with an
+      error indicating that it does not support this feature.
+
+      Server-generated passwords MUST meet the target principal's
+      password quality policy.  It is RECOMMENDED that server-generated
+      passwords be user-friendly, that is, memorable and that the target
+      principal's preferred languages be taken into account by the
+      password generation alogrithm used by the server.
+
+   RETURN
+
+      Upon successfully setting a password the server responds with a
+      Rep-set-pw.  The fields of Rep-set-pw are all optional and
+      include:
+
+         - 'info-text' which the server can use to send a message to the
+           user such as "Your new password will expire in 90 days," for
+           example.
+
+         - 'new-pw' which the server MUST include if the client
+           requested that the server generate a new password; generated
+           passwords MUST pass the target principal's password quality
+
+N. Williams et. al.						[Page 12]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+           policy.
+
+         - 'etypes' which the server MAY include to indicate which types
+           of long-term keys it created for the target principal and
+           which the server MUST include if the client specified a set
+           of enctypes in its request.
+
+   ERRORS
+
+      The server may respond to set password requests with protocol or
+      operation errors.  See section XYZ for a description of protocol
+      error codes.
+
+      All operation errors include an optional 'help-text' field by
+      which the server can describe the error in a human-readable,
+      localizaed string.
+
+      Set password error codes include:
+
+         - generic-error
+
+         - use-change-pw
+
+           The server demands that the client use the change-pw
+           operation for the target principal of the set-pw request.
+
+         - wont-generate-new-pw
+
+           The server will not generate a new password for this
+           principal or does not support password generation in general.
+
+         - new-pw-rejected-generic
+
+           The client's proposed new password failed the target
+           principal's password quality policy.
+
+           The server MUST include a description of the password quality
+           policy or aspect of it that the client's proposed new
+           password failed to meet.
+
+           The server MAY generate and send a new password that the
+           client can then use as a new password and which is guaranteed
+           to pass the target principal's current password quality
+           policy.
+
+           The server MAY include a set of policy error code hints.
+
+         - etype-not-supported
+
+           The client requested an enctype that the KDC does not
+           support.
+
+3.2.4  Set Kerberos Keys
+
+N. Williams et. al.						[Page 13]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+   NAME
+
+      set-keys
+
+   SYNOPSIS
+
+      Req-set-keys(new-keys, commit?, [isupport]) ->
+         Rep-set-keys([info-text], kvno, aliases, [isupport])
+
+   DESCRIPTION
+
+      The set-keys request consists of two required fields and one
+      optional field: "new-keys", "commit" (a boolean field - see below)
+      and "isupport", an optional field for indicating to the KDC what
+      Kerberos V features are supported by the target principal.
+
+      When "commit" is true the KDC makes the new keys available for
+      issueing tickets encrypted in them immediately.  Otherwise the
+      client MUST follow up with a commit-keys request to make the keys
+      available.  This feature is useful for changing keys shared by
+      multiple hosts, in clustered services, for example, in an atomic
+      manner; see section 3.2.6 and 3.2.7.
+
+      If a principal has keys are awaiting commitment when a new
+      set-keys request for that principal s made then the KDC MUST
+      overwrite the deferred keys.
+
+   RETURN
+
+      For successful set-keys operations the server returns:
+
+         - Informational text, optional.
+
+         - The new kvno for the target principal.
+
+         - A list of aliases of the target principal known to the KDC
+           (optional).
+
+         - The set of Kerberos V features supported by the KDC
+           (optional).
+
+   ERRORS
+
+      The server may respond with the following errors:
+
+         - generic
+         - deferred-commit-no-support
+         - etype-no-support
+
+3.2.5  Generate Kerberos Keys
+
+   NAME
+
+N. Williams et. al.						[Page 14]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+      gen-keys
+
+   SYNOPSIS
+
+      Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
+         Rep-set-keys([info-text], key, kvno, aliases, [isupport])
+
+   DESCRIPTION
+
+      The gen-keys is similar to the set-keys request (see section
+      3.2.4) but differs in that the server generates keys of
+      client-requested enctypes, rather than the client providing
+      specific keys.
+
+      The gen-keys request consists of two required fields and two
+      optional fields: "etypes" (the enctypes of the new keys),
+      "entropy", "commit" and "isupport" (see section 3.2.4).
+
+      If a principal has keys are awaiting commitment when a new
+      set-keys request for that principal s made then the KDC MUST
+      overwrite the deferred keys.
+
+   RETURN
+
+      For successful set-keys operations the server returns:
+
+         - Informational text, optional.
+
+         - The new kvno for the target principal.
+
+         - The new key (only one is needed).
+
+         - A list of aliases of the target principal known to the KDC
+           (optional).
+
+         - The set of Kerberos V features supported by the KDC
+           (optional).
+
+   ERRORS
+
+      The server may respond with the following errors:
+
+         - generic
+         - deferred-commit-no-support
+         - etype-no-support
+
+3.2.6  Get New Keys
+
+   NAME
+
+      get-keys
+
+
+N. Williams et. al.						[Page 15]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   SYNOPSIS
+
+      Req-get-keys(kvno) ->
+         Rep-get-keys([info-text], keys, aliases, [isupport]) |
+         Err-get-keys([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      This request allows a client to get the keys set or generated in a
+      previous set-keys or gen-keys request with deferred commitment..
+
+   RETURN
+
+      If the target principal and kvno correspond to uncommitted keys
+      the server MUST respond with the actual keys that would be set by
+      a subsequent commit-keys request.  Otherwise the server MUST
+      respond with an error (meaning that this operation cannot be used
+      to extract keys from the KDC that may be in use).
+
+   ERRORS
+
+         - generic
+         - kvno-committed
+         - no-such-kvno
+
+3.2.7  Commit New Keys
+
+   NAME
+
+      commit-keys
+
+   SYNOPSIS
+
+      Req-commit-keys(kvno) ->
+         Rep-commit-keys() |
+         Err-commit-keys([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      The commit-keys operation allows a client to bring a principal's
+      new keys into use at the KDC.
+
+      Clients should make a commit-keys request corresponding to a
+      deferred commitment set-keys/gen-keys operation as soon as the
+      local key database for the target principal is updated.
+
+      The target principal name and the kvno MUST match those from a
+      prior set-keys or gen-keys operation.
+
+      Servers MAY expire delayed key commitments at will.  Servers
+      SHOULD expire uncommitted new keys after a reasonable amount of
+      time (600 seconds is RECOMMENDED).
+
+
+N. Williams et. al.						[Page 16]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      Servers MUST respond to new set-keys requests for principals with
+      pending, uncommitted new keys by expiring the uncommitted new keys
+      and proceeding as if there had been no expired new keys.
+
+   ERRORS
+
+      - generic
+      - op-kvno-expired
+      - op-kvno-unknown
+      - new-keys-conflict (A set-keys or gen-keys request succeeded
+                           subsequent to the request that matches this
+                           {principal, kvno} tuple.)
+
+3.2.8  Get Password Quality Policy
+   
+   NAME
+
+      get-pw-policy
+
+   SYNOPSIS
+
+      Req-get-pw-policy() ->
+         Rep-get-pw-policy([policy name], [policy description])
+
+   DESCRIPTION
+
+      Returns a description of the target principal's associated
+      password quality policy, if any, as a list of localized
+      UTF8String values.
+
+      Clients can use this operation in conjunction with the change-pw
+      operation to obtain text that can be displayed to the user before
+      the user actually enters a new password.
+
+      It is common for sites to set policies with respect to password
+      quality.  It is beyond the scope of this document to describe such
+      policies.  Management of password quality policies' actual content
+      is also beyond the scope of this protocol.
+
+   ERRORS
+
+      No operation errors are defined.
+
+
+3.2.9  Get Principal Aliases
+   
+   NAME
+
+      get-print-aliases
+
+   SYNOPSIS
+
+      Req-get-princ-aliases() ->
+
+N. Williams et. al.						[Page 17]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+         Rep-get-princ-aliases(aliases)
+
+   DESCRIPTION
+
+      Returns a list of aliases of the target principal.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.2.10  Get Realm's Supported Kerberos V Version and Features
+   
+   NAME
+
+      get-realm-krb5-support
+
+   SYNOPSIS
+
+      Req-get-realm-krb5-support() ->
+         Rep-get-realm-krb5-support(isupport)
+
+   DESCRIPTION
+
+      Returns set of Kerberos V features support by the target
+      principal's realm's KDCs.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.2.11  Retrieve Principal's S2K Params and Preferred Params
+   
+   NAME
+
+      get-s2kparams
+
+   SYNOPSIS
+
+      Req-get-s2kparams() ->
+         Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
+
+   DESCRIPTION
+
+      Returns the string2key parameters for the principal's current
+      password-derived long-term keys, if any, and the parameters that
+      the realm would prefer, if they differ from the former.
+
+      This operation is intended for use with the change-pw() operation.
+      When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
+      the principal's long-term secret keys' string2key parameters (and
+      enctype list) should be changed and, if so, change them.
+
+      If the 'princ-s2kparams' return value is missing then the
+
+N. Williams et. al.						[Page 18]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      principal does not have a password-derived long-term key.
+
+      The 'preferred-s2kparams' MUST be excluded if the principal's
+      string2key parameters satisfy the realm's policy.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.3  Principal Aliases
+
+   Applications that use Kerberos often have to derive acceptor
+   principal names from hostnames entered by users.  Such hostnames may
+   be aliases, they may be fully qualified, partially qualified or not
+   qualified at all.  Some implementations have resorted to deriving
+   principal names from such hostnames by utilizing the names services
+   to canonicalize the hostname first; such practices are not secure
+   unless the name service are secure, which often aren't.
+
+   One method for securely deriving principal names from hostnames is to
+   alias principals at the KDC such that the KDC will issue tickets for
+   principal names which are aliases of others.  It is helpful for
+   principals to know what are their aliases as known by the KDCs.
+
+   Note that changing a principal's aliases is out of scope for this
+   protocol.
+
+3.4  Kerberos V Feature Negotiation
+
+   Principals and realms' KDCs may need to know about additional
+   Kerberos V features and extensions that they each support.  Several
+   operations (see above) provide a way for clients and servers to
+   exchange such infomration, in the form of lists of types supported
+   for the various typed holes used in Kerberos V.
+
+4  ASN.1 Module
+
+   DEFINITIONS EXPLICIT TAGS ::= BEGIN
+   -- 
+   -- Note:  EXPLICIT tagging is in use by default throughout this
+   --        module.
+
+   -- From [clarifications] with modifications
+   PrincipalName            ::= SEQUENCE {
+        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
+   }
+   Realm                    ::= UTF8String (IA5String, ...)
+   Salt                     ::= UTF8String (IA5String, ...)
+   Password                 ::= UTF8String (IA5String, ...)
+
+   -- NOTE WELL: Principal and realm names MUST be constrained by the
+   --            specification of the version of Kerberos V used by the
+   --            client.
+
+N. Williams et. al.						[Page 19]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   -- 
+   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
+   --  type and a UTF8String, for simplicity.]
+
+   -- From [clarifications]
+   Int32            ::= INTEGER (-2147483648..2147483647)
+   UInt32           ::= INTEGER (0..4294967295)
+
+   -- Based on [clarifications]
+   Etype            ::= Int32
+   Etype-Info-Entry ::= SEQUENCE {
+        etype           [0] Etype,
+        salt            [1] Salt OPTIONAL,
+        s2kparams       [2] OCTET STRING OPTIONAL,
+        ...
+   }
+   Key              ::= SEQUENCE {
+        enc-type        [0] Etype,        -- from Kerberos
+        key             [1] OCTET STRING,
+        ...
+   }
+
+   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
+
+   -- Empty, extensible SEQUENCEs are legal ASN.1
+   Extensible-NULL  ::= SEQUENCE {
+        ...
+   }
+
+   -- Kerberos clients negotiate some parameters relating to their peers
+   -- indirectly through the KDC.  Today this is true of ticket session
+   -- key enctypes, but in the future this indirect negotiation may also
+   -- occur with respect to the minor version of Kerberos V to be used
+   -- between clients and servers.  Additionally, KDCs may need to know
+   -- what authorization-data types are supported by service principals,
+   -- both, for compatibility with legacy software and for optimization.
+   --
+   -- Thesefore it is important for KDCs to know what features of
+   -- Kerberos V each service principal supports.
+   --
+   -- In version 2.0 of this protocol the clients and servers may notify
+   -- each other of their support for:
+   --
+   --  - enctypes
+   --  - authorization data types
+   --  - transited encoding data types
+   --
+   -- All authorization-data types defined in [clarifications] are
+   -- assumed to be supported if the minor version is 1 and do not need
+   -- to be included in the ad-type list.
+   --
+   -- Int32 is used for enctype and transited encoding data type
+   -- identifiers.
+
+N. Williams et. al.						[Page 20]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   --
+   -- An extensible CHOICE of Int32 is used for authorization data
+   -- types.
+
+   KerberosV-TR-ID             ::= Int32
+
+   KerberosV-AD-ID             ::= CHOICE {
+        ad-int                [0] Int32,
+        ...
+   }
+
+   KerberosVSupportNego        ::= SEQUENCE {
+        enc-types       [0] SEQUENCE OF Etype,
+        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
+                                    -- authorization data types
+        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
+                                    -- transited encoding types
+        ...
+   }
+
+   Request                     ::= [APPLICATION 0] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
+                -- Should be defaulted to the SEQUENCE of "i-default"
+        targ-name       [2] PrincipalName OPTIONAL,
+        targ-realm      [3] Realm OPTIONAL,
+                -- If targ-name/realm are missing then the request
+                -- applies to the principal of the client
+        dry-run         [4] BOOLEAN DEFAULT FALSE,
+        operation       [5] Op-req,
+        ...
+   }
+
+   Response                    ::= [APPLICATION 1] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        language        [1] Language-Tag DEFAULT "i-default",
+        result          [2] Op-rep,
+        ...
+   }
+
+   Error-Response              ::= [APPLICATION 2] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        language        [1] Language-Tag DEFAULT "i-default",
+        error-code      [2] ProtocolErrorCode,
+        help-text       [3] UTF8String OPTIONAL,
+        op-error        [4] Op-err OPTIONAL,
+        ...
+   }
+
+   Op-req                      ::= CHOICE {
+        null                     [0] Req-null,
+        change-pw                [1] Req-change-pw,
+        set-pw                   [2] Req-set-pw,
+
+N. Williams et. al.						[Page 21]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+        set-keys                 [3] Req-set-keys,
+        gen-keys                 [4] Req-gen-keys,
+        get-keys                 [5] Req-get-keys,
+        commit-keys              [6] Req-commit-keys,
+        get-pw-policy            [7] Req-get-pw-policy,
+        get-princ-aliases        [8] Req-get-princ-aliases,
+        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
+        get-s2kparams            [10] Req-get-s2kparams,
+        ...
+   }
+
+   Op-rep                     ::= CHOICE {
+        null                    [0] Rep-null,
+        change-pw               [1] Rep-change-pw,
+        set-pw                  [2] Rep-set-pw,
+        set-keys                [3] Rep-set-keys,
+        gen-keys                [4] Req-gen-keys,
+        get-keys                [5] Req-get-keys,
+        commit-keys             [6] Rep-commit-keys,
+        get-pw-policy           [7] Rep-get-pw-policy,
+        get-princ-aliases       [8] Rep-get-princ-aliases,
+        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
+        get-s2kparams           [10] Rep-get-s2kparams,
+        ...
+   }
+
+   Op-err        ::= CHOICE {
+        null                    [0] Err-null,
+        change-pw               [1] Err-change-pw,
+        set-pw                  [2] Err-set-pw,
+        set-keys                [3] Err-set-keys,
+        gen-keys                [4] Err-gen-keys,
+        get-keys                [5] Err-get-keys,
+        commit-keys             [6] Err-commit-keys,
+        get-pw-policy           [7] Err-get-pw-policy,
+        get-princ-aliases       [8] Err-get-princ-aliases,
+        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
+        get-s2kparams           [10] Err-get-s2kparams,
+        ...
+   }
+
+   ProtocolErrorCode           ::= ENUM {
+        proto-format-error,
+        proto-unsupported-major-version,
+        proto-unsupported-minor-version,
+        proto-unsupported-operation,      -- Request CHOICE tag unknown
+        proto-generic-see-op-error,       -- See Op-error
+        proto-wrong-service-principal,    -- Use kadmin/setpw
+        proto-re-authentication-required,
+        proto-initial-ticket-required,
+        proto-client-and-target-realm-mismatch,
+        proto-target-principal-unknown,
+        proto-authorization-failed,
+
+N. Williams et. al.						[Page 22]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+        proto-dry-run-not-permitted,
+        ...
+   }
+
+   -- These codes are hints for clients, primarily for when they are
+   -- used for changing the passwords of automated principals; error
+   -- replies carry password quality policy help text that is more
+   -- appropriate for clients to display to users.
+   PW-Quality-Codes        ::= ENUM {
+        pwq-generic,
+        pwq-too-soon,
+        pwq-repeated,
+        pwq-too-short,
+        pwq-dictionary-words,
+        pwq-prohibited-codepoints,
+        pwq-need-more-char-classes,
+        ...
+   }
+
+   --
+   -- Requests and responses
+   --
+
+   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
+   Req-null    ::= NULL
+
+   Rep-null    ::= NULL
+
+   Err-null    ::= NULL
+
+   -- Change password
+   Req-change-pw        ::= SEQUENCE {
+        old-pw            [0] Password,
+        new-pw            [1] Password OPTIONAL,
+        commit            [2] BOOLEAN DEFAULT TRUE,
+        etypes            [3] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Rep-change-pw        ::= SEQUENCE {
+        info-text         [0] UTF8String OPTIONAL,
+        new-pw            [1] Password OPTIONAL,
+                            -- generated by the server if present
+                            -- (and requested by the client)
+        etypes            [2] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Err-change-pw        ::= SEQUENCE {
+        help-text         [0] UTF8String OPTIONAL,
+        error             [1] CHOICE {
+            op-generic-error           [0] Extensible-NULL,
+            op-old-pw-incorrect        [1] Extensible-NULL,
+
+N. Williams et. al.						[Page 23]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+            op-wont-generate-new-pw    [2] Extensible-NULL,
+            op-new-pw-rejected-generic [3] SEQUENCE {
+                    policy                  [1] SEQUENCE OF UTF8String,
+                    suggested-pw            [2] Password OPTIONAL,
+                    policy-codes            [3] SET OF PW-Quality-Codes
+                                                    OPTIONAL,
+                    ...
+            }
+            op-etype-not-supported     [4] SEQUENCE {
+                    supported-etypes   [1] SEQUENCE OF Etype,
+                    ...
+            },
+            ...
+        },
+        ...
+   }
+
+   -- Set password
+   Req-set-pw        ::= SEQUENCE {
+        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
+        new-pw                [1] Password OPTIONAL,
+        commit                [2] BOOLEAN DEFAULT TRUE,
+        etypes                [3] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Rep-set-pw        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        new-pw                [1] Password OPTIONAL,
+                                -- generated by the server if present
+                                -- (and requested by the client)
+        etypes                [2] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Err-set-pw        ::= Err-change-pw
+
+   -- Set keys
+   Req-set-keys      ::= SEQUENCE {
+        keys            [0] SEQUENCE OF Key,
+        commit          [1] BOOLEAN DEFAULT TRUE,
+                                -- TRUE  -> install keys now
+                                -- 
+                                -- FALSE -> require set-keys-commit
+                                --          before issuing tickets
+                                --          encrypted with these keys.
+                                -- 
+                                -- See commit-keys op
+        isupport        [2] KerberosVSupportNego OPTIONAL,
+                                -- For future Kerberos V extensions KDCs
+                                -- may need to know what krb5 version is
+                                -- supported by individual service
+                                -- principals.  This field provides a
+
+N. Williams et. al.						[Page 24]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+                                -- way to tell the KDC what version of
+                                -- Kerberos V the target principal
+                                -- supports.
+        ...
+   }
+
+   Rep-set-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        kvno             [1] UInt32,
+        aliases          [2] SEQUENCE OF SEQUENCE {
+                name     [0] PrincipalName,
+                realm    [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-set-keys        ::= SEQUENCE {
+        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
+        error         [1] CHOICE {
+                op-generic                    [0] Extensible-NULL,
+                op-deferred-commit-no-support [1] Extensible-NULL,
+                op-etype-no-support           [2] SEQUENCE OF {
+                        supported-etypes      [1] SEQUENCE OF Etype,
+                        ...
+                }
+                ...
+        }
+   }
+
+   -- Generate keys
+   Req-gen-keys        ::= SEQUENCE {
+        etypes           [0] SEQUENCE (1..) OF Etype,
+        entropy          [1] OCTET STRING OPTIONAL,
+        commit           [2] BOOLEAN DEFAULT TRUE,
+                                -- TRUE  -> install keys now
+                                -- 
+                                -- FALSE -> require set-keys-commit
+                                --          before issuing tickets
+                                --          encrypted with these keys.
+                                -- 
+                                -- See commit-keys op
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+                                -- For future Kerberos V extensions KDCs
+                                -- may need to know what krb5 version is
+                                -- supported by individual service
+                                -- principals.  This field provides a
+                                -- way to tell the KDC what version of
+                                -- Kerberos V the target principal
+                                -- supports.
+        ...
+
+N. Williams et. al.						[Page 25]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   }
+
+   Rep-gen-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        kvno             [1] UInt32,
+        key              [2] Key,
+        aliases          [3] SEQUENCE OF SEQUENCE {
+                name          [0] PrincipalName,
+                realm         [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [4] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-gen-keys        ::= Err-set-keys
+
+   -- Get un-committed key request
+   Req-get-keys        ::= SEQUENCE {
+        kvno             [0] UInt32,
+        ...
+   }
+
+   Rep-get-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        keys             [1] SEQUENCE OF Key,
+        aliases          [2] SEQUENCE OF SEQUENCE {
+                name          [0] PrincipalName,
+                realm         [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-get-keys      ::= SEQUENCE {
+        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
+        error          [1] CHOICE {
+                op-generic         [0] Extensible-NULL,
+                op-kvno-committed  [1] Extensible-NULL,
+                op-no-such-kvno    [1] Extensible-NULL,
+                ...
+        }
+   }
+
+   -- Commit a set keys request
+   Req-commit-keys ::= SEQUENCE {
+        kvno         [0] UInt32,
+        ...
+   }
+
+
+N. Williams et. al.						[Page 26]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   Rep-commit-keys ::= Extensible-NULL
+
+   Err-commit-keys ::= SEQUENCE {
+        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
+        error        [1] CHOICE {
+                op-generic           [0] Extensible-NULL,
+                op-kvno-expired      [1] Extensible-NULL,
+                    -- The client took too long to respond.
+                op-kvno-unknown      [2] Extensible-NULL,
+                    -- The targ princ/kvno is invalid or unknown to the
+                    -- server (perhaps it lost track of state)
+                op-new-keys-conflict [3] Extensible-NULL,
+                    -- A new-keys/commit-keys request subsequent to the
+                    -- new-keys that produced the kvno has completed
+                    -- and incremented the principal's kvno
+                ...
+        }
+        ...
+   }
+
+   -- Get password policy
+   Req-get-pw-policy   ::= Extensible-NULL
+
+   Rep-get-pw-policy   ::= SEQUENCE {
+        policy-name      [0] UTF8String OPTIONAL,
+        description      [1] SEQUENCE OF UTF8String OPTIONAL,
+        ...
+   }
+
+   Err-get-pw-policy   ::= Extensible-NULL
+
+   -- Get principal aliases
+   Req-get-princ-aliases        ::= Extensible-NULL
+
+   Rep-get-princ-aliases        ::= SEQUENCE {
+        help-text    [0] UTF8String OPTIONAL,
+        aliases      [1] SEQUENCE OF SEQUENCE {
+                name      [0] PrincipalName,
+                realm     [1] Realm OPTIONAL,
+                ...
+        },
+        ...
+   }
+
+   Err-get-princ-aliases        ::= Extensible-NULL
+
+   -- Get list of enctypes supported by KDC for new keys
+   Req-get-realm-krb5-support   ::= Extensible-NULL
+
+   Rep-get-realm-krb5-support   ::= SEQUENCE {
+        isupport        [0] KerberosVSupportNego,
+                                -- Version of Kerberos V supported by
+                                -- the target realm.
+
+N. Williams et. al.						[Page 27]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+        ...
+   }
+
+   Err-get-realm-krb5-support   ::= Extensible-NULL
+
+   -- Get s2kparams
+   Req-get-s2kparams            ::= Extensible-NULL
+
+   Rep-get-s2kparams            ::= SEQUENCE {
+        help-text       [0] UTF8String OPTIONAL,
+        s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
+        ...
+   }
+
+   Err-get-s2kparams            ::= Extensible-NULL
+
+   END
+
+
+6  IANA Considerations
+
+   There are no IANA considerations for this document.
+
+7  Security Considerations
+   
+   Implementors and site administrators should note that the redundancy
+   of UTF-8 encodings of passwords varies by language.  Password quality
+   policies SHOULD, therefore, take this into account when estimating
+   the amount of redundancy and entropy in a proposed new password.  [??
+   It's late at night - I think this is correct.]
+
+   Kerberos set/change password/key protocol major version negotiation
+   cannot be done securely; a downgrade attack is possible against
+   clients that attempt to negotiate the protocol major version to use
+   with a server.  It is not clear at this time that the attacker would
+   gain much from such a downgrade attack other than denial of service
+   (DoS) by forcing the client to use a protocol version which does not
+   support some feature needed by the client (Kerberos V in general is
+   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
+   SHOULD NOT negotiate support for legacy major versions of this
+   protocol unless configured otherwise.
+
+   This protocol does not have Perfect Forward Security (PFS).  As a
+   result, any passive network snooper watching password/key changing
+   operations who has stolen a principal's password or long-term keys
+   can find out what the new ones are.
+
+   [More text needed?]
+
+8  Acknowledgements
+   
+   The authors would like to thank Bill GossmanMike Swift, John Brezak,
+   Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
+
+N. Williams et. al.						[Page 28]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
+   other participants from the IETF Kerberos Working Group for their
+   assistance.
+
+9  References
+
+9.1  Normative References
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2119]
+      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
+      Indicate Requirement Levels," March 1997, Status: Best Current
+      Practice.
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
+
+   [clarifications]
+      RFC-Editor: To be replaced by RFC number for
+      draft-ietf-krb-wg-kerberos-clarifications.
+
+   [RFC3066]
+      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
+      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
+      Practice.
+
+9.2  Informative References
+
+   [RFC3244]
+      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
+      Kerberos Change Password and Set Password Protocols," February
+      2002, Status: Informational.
+
+10  Authors' Addresses
+
+      Nicolas Williams
+      Sun Microsystems
+      5300 Riata Trace Ct
+      Austin, TX 78727
+
+N. Williams et. al.						[Page 29]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      Email: nicolas.williams@sun.com
+
+      Jonathan Trostle
+      Cisco Systems
+      170 W. Tasman Dr.
+      San Jose, CA 95134
+      Email: jtrostle@cisco.com
+
+11  Notes to the RFC Editor
+
+   This document has two KRB WG drafts as normative references and
+   cannot progress until those drafts progress, but no other draft
+   depends on this one.
+
+12  Change History
+
+    -01 -> -02
+
+     - Removed Bill Gossman, Mike Swift and John Brezak as authors.
+
+     - Removed UDP as a transport for this protocol.
+
+     - Replaced redundant copies of framing ASCII art with reference to
+       RFC3244.
+
+     - Made all name/password strings UTF8String with an extensible
+       constraint to IA5String.
+
+     - Added a method for doing dry runs of operations.  This is helpful
+       in testing passwords against password quality policies.
+
+     - Added an operation for retrieving a principal's current and
+       preferred string-to-key parameters, and a way to change them
+       without changing the principal's password.
+
+     - Added password quality codes as hints for smart clients, but
+       these are optional and not to be used instead of messages to be
+       displayed to useds.
+
+     - Added a 'commit' option to change-pw and set-pw (as requested by
+       Larry).
+
+     - Removed "version" field of the Kerberos V feature negotiation
+       struture.
+
+
+
+N. Williams et. al.						[Page 30]
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+N. Williams et. al.						[Page 31]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt
new file mode 100644
index 00000000000..3a923d00d40
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt
@@ -0,0 +1,1816 @@
+
+Kerberos Working Group                                  Nicolas Williams
+INTERNET-DRAFT                                          Sun Microsystems
+Expires: August 22, 2005                               February 21, 2005
+
+
+
+
+                Kerberos Set/Change Password: Version 2
+              <draft-ietf-krb-wg-kerberos-set-passwd-03.txt>
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 22, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document specifies an extensible protocol for setting keys and
+   changing the passwords of Kerberos V principals.
+
+Table of Contents
+
+   1  Introduction
+   2  The Protocol
+   2.1  Transports 
+   2.2  Protocol Framing
+   2.3  Protocol version negotiation
+   2.3.1  Protocol Major Version Negotiation
+   2.3.2  Protocol Minor Version Negotiation
+   2.4  Use of Kerberos V
+
+N. Williams        						[Page 1]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   2.5  Use of ASN.1
+   2.6  Internationalization
+   2.6.1  Normalization Forms for UTF-8 Strings
+   2.6.2  Language Negotiation
+   2.7  Protocol Extensibility
+   2.8  Protocol Subsets
+   3  Protocol Elements
+   3.1  PDUs
+   3.2  Operations
+   3.2.1  Null
+   3.2.2  Change Kerberos Password
+   3.2.3  Set Kerberos Password
+   3.2.4  Set Kerberos Keys
+   3.2.5  Generate Kerberos Keys
+   3.2.6  Get New Keys
+   3.2.7  Commit New Keys
+   3.2.8  Get Password Quality Policy
+   3.2.9  Get Principal Aliases
+   3.2.10  Get Realm's Supported Kerberos V Version and Features
+   4  ASN.1 Module
+   6  IANA Considerations
+   7  Security Considerations
+   8  Acknowledgements
+   9  References
+   9.1  Normative References
+   9.2  Informative References
+   10  Authors' Addresses
+   11  Notes to the RFC Editor
+
+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 [RFC2119].
+
+1  Introduction
+
+   Up to this point Kerberos V has lacked a single, standard protocol
+   for changing passwords and keys.  While several vendor-specific
+   protocols exist for changing Kerberos passwords/keys, none are
+   properly internationalized and all are incomplete in one respect or
+   another and none are sufficiently extensible to cope with new
+   features that may be added to Kerberos V at some future time.
+
+   This document defines a protocol that is somewhat backward-compatible
+   with the "kpasswd" protocol defined in [RFC3244] that uses more or
+   less the same protocol framing.
+
+   This new protocol is designed to be extensible and properly
+   internationalized.
+
+2  The Protocol
+
+
+N. Williams        						[Page 2]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   The structure of the protocol is quite similar to that of typical RPC
+   protocols.  Each transaction consists of a data structure specific to
+   an operation which is then wrapped in a data structure which is
+   general to all operations of the protocol.  These data structures are
+   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
+   are encoded using the Distinguished Encoding Rules (DER) [X690].
+
+   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
+   KRB-ERROR, and framed in a header that is backwards compatible with
+   [RFC3244].
+
+2.1  Transports 
+
+   The service supports only connection-oriented transports,
+   specifically TCP, and MUST accept requests on TCP port 464, the same
+   as in [RFC3244].
+
+2.2  Protocol Framing
+
+   Requests and responses are exchanged using the same framing as in
+   [RFC3244], but with the following differences:
+
+    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
+
+    - the 'AP-REQ length' field of the request can be set to 0x0, in
+      which case the 'AP-REQ' field of the request is excluded
+
+    - the 'KRB-PRIV' field of the request and reply is mutually
+      exclusive with the 'AP-REQ' field of the request
+
+    - the 'AP-REP length' field of the reply can be set to 0x0, in
+      which case the 'AP-REP' field of the reply is excluded
+
+    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
+      be or has been accepted by the server
+
+    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
+      of the reply
+
+   The initial message from the client MUST carry an AP-REQ and the
+   response to any request bearing an AP-REQ MUST carry an AP-REP or
+   MUST be a KRB-ERROR.
+
+   Subsequent messages exchanged on the same TCP connection MAY involve
+   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
+   a new AP exchange except when it desires to authenticate as a
+   different principal, when the ticket last used for authentication
+   expires or when the server responds with an error indicating that the
+   client must re-authenticate.
+
+2.3  Protocol Version Negotiation
+
+   There are several major versions of this protocol.  Version 2 also
+
+N. Williams        						[Page 3]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   introduces a notion of protocol minor versions for use in negotiating
+   protocol extensions.  As of this time only one minor version is
+   defined for major version 2: minor version 0, defined herein.
+
+2.3.1  Protocol Major Version Negotiation
+
+   Version 2 clients that also support other versions, such as 0xff80,
+   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
+   first.
+
+   Servers which do not support version 2 of this protocol typically
+   include their preferred version number in the reply and/or may
+   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
+   status code of KRB5_KPASSWD_MALFORMED.
+
+   Note that some [RFC3244] server implementations close the TCP
+   connection without returning any other response.  Note also that
+   there is no integrity protection for the major version number in the
+   protocol framing or for any data in a KRB-ERROR.
+
+   As a result change password protocol major version negotiation is
+   subject to downgrade attacks.  Therefore major version negotiation is
+   NOT RECOMMENDED.
+
+   Where the server indicates that it does not support version 2, the
+   client MAY, but SHOULD NOT, unless configured to do so, fall back on
+   another major version of this protocol.
+
+   Version 2 servers MAY respond to non-v2 requests using whatever
+   response is appropriate for the versions used by the clients, but if
+   a server does not do this or know how to do this then it MUST respond
+   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
+   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
+   using a ProtocolErrorCode value of unsupported-major-version.
+
+   It is expected that implementations of as yet unspecified future
+   major versions of this protocol will be required to support version 2
+   integrity protected error replies for properly indicating no support
+   for version 2 of the protocl.  We also hope that no further major
+   versions of this protocol will be needed.
+
+2.3.2  Protocol Minor Version Negotiation
+
+   Version 2 clients are free to use whatever protocol minor version and
+   message extensions are available to them in their initial messages to
+   version 2 servers, provided that the minor versions (other than 0)
+   have been defined through IETF documents.
+
+   Version 2 servers MUST answer with the highest protocol minor version
+   number supported by the server and the client.
+
+   Version 2 clients MUST use the protocol minor version used in a
+   server's reply for any subsequent messages in the same TCP session.
+
+N. Williams        						[Page 4]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+   See section 2.7 for further description of the protocol's
+   extensibility and its relation to protocol minor versions and the
+   negotiation thereof.
+
+2.4  Use of Kerberos V and Key Exchange
+
+   This protocol makes use of messages defined in [RFC1510] and
+   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
+   KRB-PRIV.
+
+   All operations are to be performed by the server on behalf of the
+   client principal.
+
+   Clients SHOULD use "kadmin/setpw" as the principal name of the server
+   for all requests except when changing the client principal's own
+   expired password, for which they should use "kadmin/changepw".  The 
+   "kadmin/changepw" service exists to allow KDCs to limit principals
+   with expired passwords to getting initial tickets to the password
+   changing service only and only for changing expired passwords.
+
+   Servers MUST limit clients that used the "kadmin/changepw" service
+   principal name to changing the password of the client principal.
+
+   The client MUST request mutual authentication and the client MUST
+   MUST request the use of sequence numbers.
+
+   Clients SHOULD use INITIAL tickets for requests whose target
+   principal is the client's principal.  Servers SHOULD force the use of
+   INITIAL tickets for such requests and MAY force the use of INITIAL
+   for all others - see section 3.2.
+
+   Servers MUST specify a sub-session key.
+
+   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
+   sub-session key and key usage 20 (client->server) or 21
+   (server->client).
+
+   After each new AP exchange the client and server MUST destroy the
+   session keys, if any, resulting from the previous AP exchange.
+
+2.5  Use of ASN.1
+
+   This protocol's messages are defined in ASN.1, using only features
+   from [X680].  All ASN.1 types defined herein are to be encoded in
+   DER [X690].  A complete ASN.1 module is given in section 4.
+
+   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
+   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
+
+2.6  Internationalization
+
+   This protocol's request PDU carries an optional field indicating the
+
+N. Williams        						[Page 5]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   languages spoken by the client user; the client SHOULD send its list
+   of spoken languages to the server (once per-TCP session).
+
+   The server SHOULD localize all strings intended for display to users
+   to a language in common with the languages spoken by the client user.
+
+   Strings for Kerberos principal and realm names used in this protocol
+   are be constrained as per [clarifications].
+
+2.6.1  Normalization Forms for UTF-8 Strings
+
+   Because Kerberos V [clarifications] restricts principal names, realm
+   names and passwords to IA5String, this protocol uses UTF8String with
+   an extensible constraint to IA5String.
+
+   Future versions of Kerberos may relax this constraint; if so then a
+   minor version of this protocol should relax this constraint
+   accordingly.
+
+2.6.2  Language Negotiation
+
+   The server MUST pick a language from the client's input list or
+   the default language tag (see [RFC3066]) for text in its responses
+   which is meant for the user to read.
+
+   The server SHOULD use a language selection algorithm such that
+   consideration is first given to exact matches between the client's
+   spoken languages and the server's available locales, followed by
+   "fuzzy" matches where only the first sub-tags of the client's
+   language tag list are used for matching against the servers available
+   locales.
+
+   Servers MUST cache the optional language tag lists from prior
+   requests for use with subsequent requests that exclude the language
+   tag list.  Clients MAY expect such server behaviour and send the
+   language tag lists only once per-TCP session.  Clients SHOULD send
+   the server the language tag list at least once.
+
+   When the server has a message catalog for one of the client's spoken
+   languages the server SHOULD localize any text strings intended for
+   display to users.
+
+2.7  Protocol Extensibility
+
+   The protocol is defined in ASN.1 and uses extensibility markers
+   throughout.  As such, the module presented herein can be extended
+   within the framework of [X680].
+
+   Typed holes are not used in this protocol as it is very simple and
+   does not require the ability to deal with abstract data types defined
+   in different layers.  For this reason, the only way to extend this
+   protocol is by extending the ASN.1 module within the framework of the
+   IETF; all future extensions to this protocol have to be defined in
+
+N. Williams        						[Page 6]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   IETF documents unless otherwise specified in a future IETF revision
+   of this protocol.
+
+   A protocol minor version number is used to negotiate use of
+   extensions.  See section 2.3.2 for the minor version negotiation.
+
+   Servers SHOULD ignore unknown additions to the ASN.1 types, in
+   initial requests, where the syntax allows them, except for extensions
+   to the "Op-req" type, which MUST result in an error.
+
+   Servers MUST respond with an error (ProtocolErrorCode value of
+   unsupported-minor-version) to clients that use operations unknown to
+   the server.
+
+2.8  Protocol Subsets
+
+   The structure of the protocol is such that the ASN.1 syntaxes for the
+   various operations supported by the protocol are independent of the
+   each other.  Client and server implementations MAY implement subsets
+   of the overall protocol by removing some alternatives to the Op-req,
+   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
+   
+   For example, it should be possible to have a password-change only
+   client that cannot set principal's keys - and vice versa.
+
+3  Protocol Elements
+
+   The protocol as defined herein supports the following operations
+   relating to the management of Kerberos principal's passwords or keys:
+
+     [NOTE:  New since last version of this I-D.]
+     - get principal's current and preferred string-to-key parameters
+
+     - change password (or enctypes and string-to-key parameters)
+     - set password (administrative)
+     - set new keys
+     - generate new keys
+     - get new, un-committed keys
+     - commit new keys
+     - get password policy name and/or description of principal
+     - list aliases of a principal
+     - list enctypes and version of Kerberos V supported by realm
+
+   The operation for retrieving a list of aliases of a principal is
+   needed where KDCs implement aliasing of principal names and allows
+   clients to properly setup their key databases when principal aliasing
+   is in use.
+
+   Operations such as creation or deletion of principals are outside the
+   scope of this document, and should be performed via other means, such
+   as through directories or other Kerberos administration protocols.
+
+   The individual operations are described in section 3.2.
+
+N. Williams        						[Page 7]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+3.1  PDUs
+
+   The types "Request," "Response" and "Error-Response" are the ASN.1
+   module's PDUs.
+
+   The "Request" and "Response" PDUs are always to be sent wrapped in
+   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
+   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
+   otherwise it MUST be sent wrapped in a KRB-PRIV.
+
+   The ASN.1 syntax for the PDUs is given in section 4.
+
+   Note that the first field of each PDU is the major version of the
+   protocol, defaulted to 2, meaning that it is never included in
+   version 2 exchanges.  Similarly, the second field of each PDU is the
+   minor version, defaulted to 0.
+
+   The request, responses and error PDUs consist of an outer structure
+   ("Request," "Response" and "Error-Response") containing fields common
+   to all requests, responses and errors, respectively, and an inner
+   structure for fields that are specific to each operation's
+   requests/responses.  The inner structure is optional in the case of
+   the Error-Response PDU and need not be included when generic errors
+   occur for which there is a suitable ProtocolErrorCode.
+
+   Specifically, the outer Request structure has a field for passing a
+   client user's spoken (read) languages to the server.  It also has two
+   optional fields for identifying the requested operation's target
+   principal's name and realm (if not sent then the server MUST use the
+   client's principal name and realm as the target).  A boolean field
+   for indicating whether or not the request should be dry-run is also
+   included; dry-runs can be used to test server policies, and servers
+   MUST NOT modify any principals when processing dry-run requests.
+
+   The Response and Error PDUs' outer structures include a field
+   indicating the language that the server has chosen for localization
+   of text intended to be displayed to users; this field is defaulted to
+   "i-default".  This language tag applies to all UTF8 strings in the
+   inner structure (Op-rep and Op-err) that are meant to be displayed to
+   users.
+
+   The protocol error codes are:
+
+      - proto-generic-error
+
+        An operation-specific error ocurred, see the inner Op-error.
+
+      - proto-format-error
+      - proto-unsupported-major-version
+      - proto-unsupported-minor-version
+      - proto-unsupported-operation
+
+
+N. Williams        						[Page 8]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      - proto-wrong-service-principal
+
+        Use kadmin/setpw for the server's principal name.
+
+      - proto-re-authentication-required
+
+        The server demands that the client re-authenticate through a new
+        AP exchange.
+
+      - proto-initial-ticket-required
+
+        Use of an INITIAL ticket is required for the requested
+        operation.
+
+      - proto-client-and-target-realm-mismatch
+
+        The server requires that the client's principal name and the
+        target principal of the operation share the same realm name.
+
+      - proto-target-principal-unknown
+      - proto-authorization-failed
+
+3.2  Operations
+
+   This section describes the semantics of each operation request and
+   response defined in the ASN.1 module in section 4.
+      
+3.2.1  Null
+
+   NAME
+
+      null - Null or "ping" operation
+
+   DESCRIPTION
+
+      The null request is intended for use with TCP; its purpose is
+      similar to RPC null procedures and is akin to a "ping" operation.
+
+   ERRORS
+
+      None.
+
+3.2.2  Change Kerberos Password
+
+   NAME
+
+      change-pw - Change password operation
+
+   SYNOPSIS
+
+      Req-change-pw(old-pw, [languages], [new-pw],
+                    [commit], [etypes]) ->
+         Rep-change-pw([info-text], [new-pw], [etypes]) |
+
+N. Williams        						[Page 9]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+         Err-change-pw([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      Change a principal's password.
+
+      The change password request has one required, three optional and
+      one defaulted arguments: "old-pw" (required), "languages,"
+      "new-pw", "commit" (defaults to "TRUE") and "etypes",
+      corresponding to the target principal's old password, its
+      preferred languages, its new password, a boolean indicating
+      whether or not to make the new long-term key available for
+      immediate use, and the desired enctypes for the new long-term
+      keys.
+
+      The server MUST validate the old password and MUST check the
+      quality of the new password, if sent, according the password
+      quality policy associated with the target principal.
+
+      If the old and new passwords in the request are the same strings,
+      and the principal is not currently required to change its
+      password, then the server MAY permit the password change as way to
+      change a principal's enctypes and string-to-key parameters.  This
+      feature provides a way to, for example, add enctypes to a
+      principals' password-derived long-term keys without forcing a
+      password change following an upgrade to the KDC that adds support
+      for new enctypes.
+
+      A client MAY request that the server generate a new password by
+      excluding the new password from its request, in which case the
+      server MUST either generate a new password or respond with an
+      error indicating that it does not support this feature.
+
+      Server-generated passwords MUST meet the target principal's
+      password quality policy.  It is RECOMMENDED that server-generated
+      passwords be user-friendly, that is, memorable and that the target
+      principal's preferred languages be taken into account by the
+      password generation alogrithm used by the server.
+
+      Uncommitted password changes are commited using the commit-keys
+      operation.
+
+   RETURN
+
+      Upon successful password changes the server responds with a
+      Rep-change-pw.  The fields of Rep-change-pw are all optional and
+      include:
+
+         - 'info-text' which the server can use to send a message to the
+           user such as "Your new password will expire in 90 days," for
+           example.
+
+         - 'new-pw' which the server MUST include if the client
+
+N. Williams        						[Page 10]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+           requested that the server generate a new password; generated
+           passwords MUST pass the target principal's password quality
+           policy.
+
+         - 'etypes' which the server MAY include to indicate which types
+           of long-term keys it created for the target principal and
+           which the server MUST include if the client specified a set
+           of enctypes in its request.
+
+   ERRORS
+
+      The server may respond to change password requests with protocol
+      or operation errors.  See section 3.1 for a description of
+      protocol error codes.
+
+      All operation errors include an optional 'help-text' field by
+      which the server can describe the error in a human-readable,
+      localizaed string.
+
+      Change password error codes include:
+
+         - generic-error
+
+         - old-pw-incorrect
+
+         - wont-generate-new-pw
+
+           The server will not generate a new password for this
+           principal or does not support password generation in general.
+
+         - new-pw-rejected-generic
+
+           The client's proposed new password failed the target
+           principal's password quality policy.
+
+           The server MUST include a description of the password quality
+           policy or aspect of it that the client's proposed new
+           password failed to meet.
+
+           The server MAY generate and send a new password that the
+           client can then use as a new password and which is guaranteed
+           to pass the target principal's current password quality
+           policy.
+
+           The server MAY include a set of policy error code hints.
+
+         - etype-not-supported
+
+           The client requested an enctype that the KDC does not
+           support.
+
+3.2.3  Set Kerberos Password
+
+
+N. Williams        						[Page 11]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   NAME
+
+      set-pw - Set password operation
+
+   SYNOPSIS
+
+      Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
+         Rep-set-pw([info-text], [new-pw], [etypes]) |
+         Err-set-pw([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      Administratively set a principal's password.
+
+      The set password request has three optional and one defaulted
+      arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
+      and "etypes", corresponding to the target principal's preferred
+      languages, new password, a boolean indicating whether or not to
+      make the new long-term key available for immediate use, and the
+      desired enctypes for the new long-term keys.
+
+      The server MUST check the quality of the new password, if sent,
+      according the password quality policy associated with the target
+      principal.
+
+      The server SHOULD require that the client use the change-pw
+      operation instead of set-pw when the client principal and the
+      target principal are the same.
+
+      A client MAY request that the server generate a new password by
+      excluding the new password from its request, in which case the
+      server MUST either generate a new password or respond with an
+      error indicating that it does not support this feature.
+
+      Server-generated passwords MUST meet the target principal's
+      password quality policy.  It is RECOMMENDED that server-generated
+      passwords be user-friendly, that is, memorable and that the target
+      principal's preferred languages be taken into account by the
+      password generation alogrithm used by the server.
+
+   RETURN
+
+      Upon successfully setting a password the server responds with a
+      Rep-set-pw.  The fields of Rep-set-pw are all optional and
+      include:
+
+         - 'info-text' which the server can use to send a message to the
+           user such as "Your new password will expire in 90 days," for
+           example.
+
+         - 'new-pw' which the server MUST include if the client
+           requested that the server generate a new password; generated
+           passwords MUST pass the target principal's password quality
+
+N. Williams        						[Page 12]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+           policy.
+
+         - 'etypes' which the server MAY include to indicate which types
+           of long-term keys it created for the target principal and
+           which the server MUST include if the client specified a set
+           of enctypes in its request.
+
+   ERRORS
+
+      The server may respond to set password requests with protocol or
+      operation errors.  See section XYZ for a description of protocol
+      error codes.
+
+      All operation errors include an optional 'help-text' field by
+      which the server can describe the error in a human-readable,
+      localizaed string.
+
+      Set password error codes include:
+
+         - generic-error
+
+         - use-change-pw
+
+           The server demands that the client use the change-pw
+           operation for the target principal of the set-pw request.
+
+         - wont-generate-new-pw
+
+           The server will not generate a new password for this
+           principal or does not support password generation in general.
+
+         - new-pw-rejected-generic
+
+           The client's proposed new password failed the target
+           principal's password quality policy.
+
+           The server MUST include a description of the password quality
+           policy or aspect of it that the client's proposed new
+           password failed to meet.
+
+           The server MAY generate and send a new password that the
+           client can then use as a new password and which is guaranteed
+           to pass the target principal's current password quality
+           policy.
+
+           The server MAY include a set of policy error code hints.
+
+         - etype-not-supported
+
+           The client requested an enctype that the KDC does not
+           support.
+
+3.2.4  Set Kerberos Keys
+
+N. Williams        						[Page 13]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+   NAME
+
+      set-keys
+
+   SYNOPSIS
+
+      Req-set-keys(new-keys, commit?, [isupport]) ->
+         Rep-set-keys([info-text], kvno, aliases, [isupport])
+
+   DESCRIPTION
+
+      The set-keys request consists of two required fields and one
+      optional field: "new-keys", "commit" (a boolean field - see below)
+      and "isupport", an optional field for indicating to the KDC what
+      Kerberos V features are supported by the target principal.
+
+      When "commit" is true the KDC makes the new keys available for
+      issueing tickets encrypted in them immediately.  Otherwise the
+      client MUST follow up with a commit-keys request to make the keys
+      available.  This feature is useful for changing keys shared by
+      multiple hosts, in clustered services, for example, in an atomic
+      manner; see section 3.2.6 and 3.2.7.
+
+      If a principal has keys are awaiting commitment when a new
+      set-keys request for that principal s made then the KDC MUST
+      overwrite the deferred keys.
+
+   RETURN
+
+      For successful set-keys operations the server returns:
+
+         - Informational text, optional.
+
+         - The new kvno for the target principal.
+
+         - A list of aliases of the target principal known to the KDC
+           (optional).
+
+         - The set of Kerberos V features supported by the KDC
+           (optional).
+
+   ERRORS
+
+      The server may respond with the following errors:
+
+         - generic
+         - deferred-commit-no-support
+         - etype-no-support
+
+3.2.5  Generate Kerberos Keys
+
+   NAME
+
+N. Williams        						[Page 14]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+      gen-keys
+
+   SYNOPSIS
+
+      Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
+         Rep-set-keys([info-text], key, kvno, aliases, [isupport])
+
+   DESCRIPTION
+
+      The gen-keys is similar to the set-keys request (see section
+      3.2.4) but differs in that the server generates keys of
+      client-requested enctypes, rather than the client providing
+      specific keys.
+
+      The gen-keys request consists of two required fields and two
+      optional fields: "etypes" (the enctypes of the new keys),
+      "entropy", "commit" and "isupport" (see section 3.2.4).
+
+      If a principal has keys are awaiting commitment when a new
+      set-keys request for that principal s made then the KDC MUST
+      overwrite the deferred keys.
+
+   RETURN
+
+      For successful set-keys operations the server returns:
+
+         - Informational text, optional.
+
+         - The new kvno for the target principal.
+
+         - The new key (only one is needed).
+
+         - A list of aliases of the target principal known to the KDC
+           (optional).
+
+         - The set of Kerberos V features supported by the KDC
+           (optional).
+
+   ERRORS
+
+      The server may respond with the following errors:
+
+         - generic
+         - deferred-commit-no-support
+         - etype-no-support
+
+3.2.6  Get New Keys
+
+   NAME
+
+      get-keys
+
+
+N. Williams        						[Page 15]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   SYNOPSIS
+
+      Req-get-keys(kvno) ->
+         Rep-get-keys([info-text], keys, aliases, [isupport]) |
+         Err-get-keys([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      This request allows a client to get the keys set or generated in a
+      previous set-keys or gen-keys request with deferred commitment..
+
+   RETURN
+
+      If the target principal and kvno correspond to uncommitted keys
+      the server MUST respond with the actual keys that would be set by
+      a subsequent commit-keys request.  Otherwise the server MUST
+      respond with an error (meaning that this operation cannot be used
+      to extract keys from the KDC that may be in use).
+
+   ERRORS
+
+         - generic
+         - kvno-committed
+         - no-such-kvno
+
+3.2.7  Commit New Keys
+
+   NAME
+
+      commit-keys
+
+   SYNOPSIS
+
+      Req-commit-keys(kvno) ->
+         Rep-commit-keys() |
+         Err-commit-keys([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      The commit-keys operation allows a client to bring a principal's
+      new keys into use at the KDC.
+
+      Clients should make a commit-keys request corresponding to a
+      deferred commitment set-keys/gen-keys operation as soon as the
+      local key database for the target principal is updated.
+
+      The target principal name and the kvno MUST match those from a
+      prior set-keys or gen-keys operation.
+
+      Servers MAY expire delayed key commitments at will.  Servers
+      SHOULD expire uncommitted new keys after a reasonable amount of
+      time (600 seconds is RECOMMENDED).
+
+
+N. Williams        						[Page 16]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      Servers MUST respond to new set-keys requests for principals with
+      pending, uncommitted new keys by expiring the uncommitted new keys
+      and proceeding as if there had been no expired new keys.
+
+   ERRORS
+
+      - generic
+      - op-kvno-expired
+      - op-kvno-unknown
+      - new-keys-conflict (A set-keys or gen-keys request succeeded
+                           subsequent to the request that matches this
+                           {principal, kvno} tuple.)
+
+3.2.8  Get Password Quality Policy
+   
+   NAME
+
+      get-pw-policy
+
+   SYNOPSIS
+
+      Req-get-pw-policy() ->
+         Rep-get-pw-policy([policy name], [policy description])
+
+   DESCRIPTION
+
+      Returns a description of the target principal's associated
+      password quality policy, if any, as a list of localized
+      UTF8String values.
+
+      Clients can use this operation in conjunction with the change-pw
+      operation to obtain text that can be displayed to the user before
+      the user actually enters a new password.
+
+      It is common for sites to set policies with respect to password
+      quality.  It is beyond the scope of this document to describe such
+      policies.  Management of password quality policies' actual content
+      is also beyond the scope of this protocol.
+
+   ERRORS
+
+      No operation errors are defined.
+
+
+3.2.9  Get Principal Aliases
+   
+   NAME
+
+      get-print-aliases
+
+   SYNOPSIS
+
+      Req-get-princ-aliases() ->
+
+N. Williams        						[Page 17]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+         Rep-get-princ-aliases(aliases)
+
+   DESCRIPTION
+
+      Returns a list of aliases of the target principal.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.2.10  Get Realm's Supported Kerberos V Version and Features
+   
+   NAME
+
+      get-realm-krb5-support
+
+   SYNOPSIS
+
+      Req-get-realm-krb5-support() ->
+         Rep-get-realm-krb5-support(isupport)
+
+   DESCRIPTION
+
+      Returns set of Kerberos V features support by the target
+      principal's realm's KDCs.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.2.11  Retrieve Principal's S2K Params and Preferred Params
+   
+   NAME
+
+      get-s2kparams
+
+   SYNOPSIS
+
+      Req-get-s2kparams() ->
+         Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
+
+   DESCRIPTION
+
+      Returns the string2key parameters for the principal's current
+      password-derived long-term keys, if any, and the parameters that
+      the realm would prefer, if they differ from the former.
+
+      This operation is intended for use with the change-pw() operation.
+      When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
+      the principal's long-term secret keys' string2key parameters (and
+      enctype list) should be changed and, if so, change them.
+
+      If the 'princ-s2kparams' return value is missing then the
+
+N. Williams        						[Page 18]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      principal does not have a password-derived long-term key.
+
+      The 'preferred-s2kparams' MUST be excluded if the principal's
+      string2key parameters satisfy the realm's policy.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.3  Principal Aliases
+
+   Applications that use Kerberos often have to derive acceptor
+   principal names from hostnames entered by users.  Such hostnames may
+   be aliases, they may be fully qualified, partially qualified or not
+   qualified at all.  Some implementations have resorted to deriving
+   principal names from such hostnames by utilizing the names services
+   to canonicalize the hostname first; such practices are not secure
+   unless the name service are secure, which often aren't.
+
+   One method for securely deriving principal names from hostnames is to
+   alias principals at the KDC such that the KDC will issue tickets for
+   principal names which are aliases of others.  It is helpful for
+   principals to know what are their aliases as known by the KDCs.
+
+   Note that changing a principal's aliases is out of scope for this
+   protocol.
+
+3.4  Kerberos V Feature Negotiation
+
+   Principals and realms' KDCs may need to know about additional
+   Kerberos V features and extensions that they each support.  Several
+   operations (see above) provide a way for clients and servers to
+   exchange such infomration, in the form of lists of types supported
+   for the various typed holes used in Kerberos V.
+
+4  ASN.1 Module
+
+   DEFINITIONS EXPLICIT TAGS ::= BEGIN
+   -- 
+   -- Note:  EXPLICIT tagging is in use by default throughout this
+   --        module.
+
+   -- From [clarifications] with modifications
+   PrincipalName            ::= SEQUENCE {
+        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
+   }
+   Realm                    ::= UTF8String (IA5String, ...)
+   Salt                     ::= UTF8String (IA5String, ...)
+   Password                 ::= UTF8String (IA5String, ...)
+
+   -- NOTE WELL: Principal and realm names MUST be constrained by the
+   --            specification of the version of Kerberos V used by the
+   --            client.
+
+N. Williams        						[Page 19]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   -- 
+   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
+   --  type and a UTF8String, for simplicity.]
+
+   -- From [clarifications]
+   Int32            ::= INTEGER (-2147483648..2147483647)
+   UInt32           ::= INTEGER (0..4294967295)
+
+   -- Based on [clarifications]
+   Etype            ::= Int32
+   Etype-Info-Entry ::= SEQUENCE {
+        etype           [0] Etype,
+        salt            [1] Salt OPTIONAL,
+        s2kparams       [2] OCTET STRING OPTIONAL,
+        ...
+   }
+   Key              ::= SEQUENCE {
+        enc-type        [0] Etype,        -- from Kerberos
+        key             [1] OCTET STRING,
+        ...
+   }
+
+   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
+
+   -- Empty, extensible SEQUENCEs are legal ASN.1
+   Extensible-NULL  ::= SEQUENCE {
+        ...
+   }
+
+   -- Kerberos clients negotiate some parameters relating to their peers
+   -- indirectly through the KDC.  Today this is true of ticket session
+   -- key enctypes, but in the future this indirect negotiation may also
+   -- occur with respect to the minor version of Kerberos V to be used
+   -- between clients and servers.  Additionally, KDCs may need to know
+   -- what authorization-data types are supported by service principals,
+   -- both, for compatibility with legacy software and for optimization.
+   --
+   -- Thesefore it is important for KDCs to know what features of
+   -- Kerberos V each service principal supports.
+   --
+   -- In version 2.0 of this protocol the clients and servers may notify
+   -- each other of their support for:
+   --
+   --  - enctypes
+   --  - authorization data types
+   --  - transited encoding data types
+   --
+   -- All authorization-data types defined in [clarifications] are
+   -- assumed to be supported if the minor version is 1 and do not need
+   -- to be included in the ad-type list.
+   --
+   -- Int32 is used for enctype and transited encoding data type
+   -- identifiers.
+
+N. Williams        						[Page 20]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   --
+   -- An extensible CHOICE of Int32 is used for authorization data
+   -- types.
+
+   KerberosV-TR-ID             ::= Int32
+
+   KerberosV-AD-ID             ::= CHOICE {
+        ad-int                [0] Int32,
+        ...
+   }
+
+   KerberosVSupportNego        ::= SEQUENCE {
+        enc-types       [0] SEQUENCE OF Etype,
+        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
+                                    -- authorization data types
+        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
+                                    -- transited encoding types
+        ...
+   }
+
+   Request                     ::= [APPLICATION 0] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
+                -- Should be defaulted to the SEQUENCE of "i-default"
+        targ-name       [2] PrincipalName OPTIONAL,
+        targ-realm      [3] Realm OPTIONAL,
+                -- If targ-name/realm are missing then the request
+                -- applies to the principal of the client
+        dry-run         [4] BOOLEAN DEFAULT FALSE,
+        operation       [5] Op-req,
+        ...
+   }
+
+   Response                    ::= [APPLICATION 1] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        language        [1] Language-Tag DEFAULT "i-default",
+        result          [2] Op-rep,
+        ...
+   }
+
+   Error-Response              ::= [APPLICATION 2] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        language        [1] Language-Tag DEFAULT "i-default",
+        error-code      [2] ProtocolErrorCode,
+        help-text       [3] UTF8String OPTIONAL,
+        op-error        [4] Op-err OPTIONAL,
+        ...
+   }
+
+   Op-req                      ::= CHOICE {
+        null                     [0] Req-null,
+        change-pw                [1] Req-change-pw,
+        set-pw                   [2] Req-set-pw,
+
+N. Williams        						[Page 21]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+        set-keys                 [3] Req-set-keys,
+        gen-keys                 [4] Req-gen-keys,
+        get-keys                 [5] Req-get-keys,
+        commit-keys              [6] Req-commit-keys,
+        get-pw-policy            [7] Req-get-pw-policy,
+        get-princ-aliases        [8] Req-get-princ-aliases,
+        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
+        get-s2kparams            [10] Req-get-s2kparams,
+        ...
+   }
+
+   Op-rep                     ::= CHOICE {
+        null                    [0] Rep-null,
+        change-pw               [1] Rep-change-pw,
+        set-pw                  [2] Rep-set-pw,
+        set-keys                [3] Rep-set-keys,
+        gen-keys                [4] Req-gen-keys,
+        get-keys                [5] Req-get-keys,
+        commit-keys             [6] Rep-commit-keys,
+        get-pw-policy           [7] Rep-get-pw-policy,
+        get-princ-aliases       [8] Rep-get-princ-aliases,
+        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
+        get-s2kparams           [10] Rep-get-s2kparams,
+        ...
+   }
+
+   Op-err        ::= CHOICE {
+        null                    [0] Err-null,
+        change-pw               [1] Err-change-pw,
+        set-pw                  [2] Err-set-pw,
+        set-keys                [3] Err-set-keys,
+        gen-keys                [4] Err-gen-keys,
+        get-keys                [5] Err-get-keys,
+        commit-keys             [6] Err-commit-keys,
+        get-pw-policy           [7] Err-get-pw-policy,
+        get-princ-aliases       [8] Err-get-princ-aliases,
+        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
+        get-s2kparams           [10] Err-get-s2kparams,
+        ...
+   }
+
+   ProtocolErrorCode           ::= ENUM {
+        proto-format-error,
+        proto-unsupported-major-version,
+        proto-unsupported-minor-version,
+        proto-unsupported-operation,      -- Request CHOICE tag unknown
+        proto-generic-see-op-error,       -- See Op-error
+        proto-wrong-service-principal,    -- Use kadmin/setpw
+        proto-re-authentication-required,
+        proto-initial-ticket-required,
+        proto-client-and-target-realm-mismatch,
+        proto-target-principal-unknown,
+        proto-authorization-failed,
+
+N. Williams        						[Page 22]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+        proto-dry-run-not-permitted,
+        ...
+   }
+
+   -- These codes are hints for clients, primarily for when they are
+   -- used for changing the passwords of automated principals; error
+   -- replies carry password quality policy help text that is more
+   -- appropriate for clients to display to users.
+   PW-Quality-Codes        ::= ENUM {
+        pwq-generic,
+        pwq-too-soon,
+        pwq-repeated,
+        pwq-too-short,
+        pwq-dictionary-words,
+        pwq-prohibited-codepoints,
+        pwq-need-more-char-classes,
+        ...
+   }
+
+   --
+   -- Requests and responses
+   --
+
+   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
+   Req-null    ::= NULL
+
+   Rep-null    ::= NULL
+
+   Err-null    ::= NULL
+
+   -- Change password
+   Req-change-pw        ::= SEQUENCE {
+        old-pw            [0] Password,
+        new-pw            [1] Password OPTIONAL,
+        commit            [2] BOOLEAN DEFAULT TRUE,
+        etypes            [3] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Rep-change-pw        ::= SEQUENCE {
+        info-text         [0] UTF8String OPTIONAL,
+        new-pw            [1] Password OPTIONAL,
+                            -- generated by the server if present
+                            -- (and requested by the client)
+        etypes            [2] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Err-change-pw        ::= SEQUENCE {
+        help-text         [0] UTF8String OPTIONAL,
+        error             [1] CHOICE {
+            op-generic-error           [0] Extensible-NULL,
+            op-old-pw-incorrect        [1] Extensible-NULL,
+
+N. Williams        						[Page 23]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+            op-wont-generate-new-pw    [2] Extensible-NULL,
+            op-new-pw-rejected-generic [3] SEQUENCE {
+                    policy                  [1] SEQUENCE OF UTF8String,
+                    suggested-pw            [2] Password OPTIONAL,
+                    policy-codes            [3] SET OF PW-Quality-Codes
+                                                    OPTIONAL,
+                    ...
+            }
+            op-etype-not-supported     [4] SEQUENCE {
+                    supported-etypes   [1] SEQUENCE OF Etype,
+                    ...
+            },
+            ...
+        },
+        ...
+   }
+
+   -- Set password
+   Req-set-pw        ::= SEQUENCE {
+        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
+        new-pw                [1] Password OPTIONAL,
+        commit                [2] BOOLEAN DEFAULT TRUE,
+        etypes                [3] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Rep-set-pw        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        new-pw                [1] Password OPTIONAL,
+                                -- generated by the server if present
+                                -- (and requested by the client)
+        etypes                [2] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Err-set-pw        ::= Err-change-pw
+
+   -- Set keys
+   Req-set-keys      ::= SEQUENCE {
+        keys            [0] SEQUENCE OF Key,
+        commit          [1] BOOLEAN DEFAULT TRUE,
+                                -- TRUE  -> install keys now
+                                -- 
+                                -- FALSE -> require set-keys-commit
+                                --          before issuing tickets
+                                --          encrypted with these keys.
+                                -- 
+                                -- See commit-keys op
+        isupport        [2] KerberosVSupportNego OPTIONAL,
+                                -- For future Kerberos V extensions KDCs
+                                -- may need to know what krb5 version is
+                                -- supported by individual service
+                                -- principals.  This field provides a
+
+N. Williams        						[Page 24]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+                                -- way to tell the KDC what version of
+                                -- Kerberos V the target principal
+                                -- supports.
+        ...
+   }
+
+   Rep-set-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        kvno             [1] UInt32,
+        aliases          [2] SEQUENCE OF SEQUENCE {
+                name     [0] PrincipalName,
+                realm    [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-set-keys        ::= SEQUENCE {
+        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
+        error         [1] CHOICE {
+                op-generic                    [0] Extensible-NULL,
+                op-deferred-commit-no-support [1] Extensible-NULL,
+                op-etype-no-support           [2] SEQUENCE OF {
+                        supported-etypes      [1] SEQUENCE OF Etype,
+                        ...
+                }
+                ...
+        }
+   }
+
+   -- Generate keys
+   Req-gen-keys        ::= SEQUENCE {
+        etypes           [0] SEQUENCE (1..) OF Etype,
+        entropy          [1] OCTET STRING OPTIONAL,
+        commit           [2] BOOLEAN DEFAULT TRUE,
+                                -- TRUE  -> install keys now
+                                -- 
+                                -- FALSE -> require set-keys-commit
+                                --          before issuing tickets
+                                --          encrypted with these keys.
+                                -- 
+                                -- See commit-keys op
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+                                -- For future Kerberos V extensions KDCs
+                                -- may need to know what krb5 version is
+                                -- supported by individual service
+                                -- principals.  This field provides a
+                                -- way to tell the KDC what version of
+                                -- Kerberos V the target principal
+                                -- supports.
+        ...
+
+N. Williams        						[Page 25]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   }
+
+   Rep-gen-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        kvno             [1] UInt32,
+        key              [2] Key,
+        aliases          [3] SEQUENCE OF SEQUENCE {
+                name          [0] PrincipalName,
+                realm         [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [4] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-gen-keys        ::= Err-set-keys
+
+   -- Get un-committed key request
+   Req-get-keys        ::= SEQUENCE {
+        kvno             [0] UInt32,
+        ...
+   }
+
+   Rep-get-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        keys             [1] SEQUENCE OF Key,
+        aliases          [2] SEQUENCE OF SEQUENCE {
+                name          [0] PrincipalName,
+                realm         [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-get-keys      ::= SEQUENCE {
+        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
+        error          [1] CHOICE {
+                op-generic         [0] Extensible-NULL,
+                op-kvno-committed  [1] Extensible-NULL,
+                op-no-such-kvno    [1] Extensible-NULL,
+                ...
+        }
+   }
+
+   -- Commit a set keys request
+   Req-commit-keys ::= SEQUENCE {
+        kvno         [0] UInt32,
+        ...
+   }
+
+
+N. Williams        						[Page 26]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   Rep-commit-keys ::= Extensible-NULL
+
+   Err-commit-keys ::= SEQUENCE {
+        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
+        error        [1] CHOICE {
+                op-generic           [0] Extensible-NULL,
+                op-kvno-expired      [1] Extensible-NULL,
+                    -- The client took too long to respond.
+                op-kvno-unknown      [2] Extensible-NULL,
+                    -- The targ princ/kvno is invalid or unknown to the
+                    -- server (perhaps it lost track of state)
+                op-new-keys-conflict [3] Extensible-NULL,
+                    -- A new-keys/commit-keys request subsequent to the
+                    -- new-keys that produced the kvno has completed
+                    -- and incremented the principal's kvno
+                ...
+        }
+        ...
+   }
+
+   -- Get password policy
+   Req-get-pw-policy   ::= Extensible-NULL
+
+   Rep-get-pw-policy   ::= SEQUENCE {
+        policy-name      [0] UTF8String OPTIONAL,
+        description      [1] SEQUENCE OF UTF8String OPTIONAL,
+        ...
+   }
+
+   Err-get-pw-policy   ::= Extensible-NULL
+
+   -- Get principal aliases
+   Req-get-princ-aliases        ::= Extensible-NULL
+
+   Rep-get-princ-aliases        ::= SEQUENCE {
+        help-text    [0] UTF8String OPTIONAL,
+        aliases      [1] SEQUENCE OF SEQUENCE {
+                name      [0] PrincipalName,
+                realm     [1] Realm OPTIONAL,
+                ...
+        },
+        ...
+   }
+
+   Err-get-princ-aliases        ::= Extensible-NULL
+
+   -- Get list of enctypes supported by KDC for new keys
+   Req-get-realm-krb5-support   ::= Extensible-NULL
+
+   Rep-get-realm-krb5-support   ::= SEQUENCE {
+        isupport        [0] KerberosVSupportNego,
+                                -- Version of Kerberos V supported by
+                                -- the target realm.
+
+N. Williams        						[Page 27]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+        ...
+   }
+
+   Err-get-realm-krb5-support   ::= Extensible-NULL
+
+   -- Get s2kparams
+   Req-get-s2kparams            ::= Extensible-NULL
+
+   Rep-get-s2kparams            ::= SEQUENCE {
+        help-text       [0] UTF8String OPTIONAL,
+        s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
+        ...
+   }
+
+   Err-get-s2kparams            ::= Extensible-NULL
+
+   END
+
+
+6  IANA Considerations
+
+   There are no IANA considerations for this document.
+
+7  Security Considerations
+   
+   Implementors and site administrators should note that the redundancy
+   of UTF-8 encodings of passwords varies by language.  Password quality
+   policies SHOULD, therefore, take this into account when estimating
+   the amount of redundancy and entropy in a proposed new password.  [??
+   It's late at night - I think this is correct.]
+
+   Kerberos set/change password/key protocol major version negotiation
+   cannot be done securely; a downgrade attack is possible against
+   clients that attempt to negotiate the protocol major version to use
+   with a server.  It is not clear at this time that the attacker would
+   gain much from such a downgrade attack other than denial of service
+   (DoS) by forcing the client to use a protocol version which does not
+   support some feature needed by the client (Kerberos V in general is
+   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
+   SHOULD NOT negotiate support for legacy major versions of this
+   protocol unless configured otherwise.
+
+   This protocol does not have Perfect Forward Security (PFS).  As a
+   result, any passive network snooper watching password/key changing
+   operations who has stolen a principal's password or long-term keys
+   can find out what the new ones are.
+
+   [More text needed?]
+
+8  Acknowledgements
+   
+   The authors would like to thank Bill GossmanMike Swift, John Brezak,
+   Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
+
+N. Williams        						[Page 28]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
+   other participants from the IETF Kerberos Working Group for their
+   assistance.
+
+9  References
+
+9.1  Normative References
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2119]
+      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
+      Indicate Requirement Levels," March 1997, Status: Best Current
+      Practice.
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
+
+   [clarifications]
+      RFC-Editor: To be replaced by RFC number for
+      draft-ietf-krb-wg-kerberos-clarifications.
+
+   [RFC3066]
+      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
+      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
+      Practice.
+
+9.2  Informative References
+
+   [RFC3244]
+      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
+      Kerberos Change Password and Set Password Protocols," February
+      2002, Status: Informational.
+
+10  Authors' Addresses
+
+      Nicolas Williams
+      Sun Microsystems
+      5300 Riata Trace Ct
+      Austin, TX 78727
+
+N. Williams        						[Page 29]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+      Email: nicolas.williams@sun.com
+
+
+11  Notes to the RFC Editor
+
+   This document has two KRB WG drafts as normative references and
+   cannot progress until those drafts progress, but no other draft
+   depends on this one.
+
+12  Change History
+
+    -01 -> -02
+
+     - Removed Bill Gossman, Mike Swift and John Brezak as authors.
+
+     - Removed UDP as a transport for this protocol.
+
+     - Replaced redundant copies of framing ASCII art with reference to
+       RFC3244.
+
+     - Made all name/password strings UTF8String with an extensible
+       constraint to IA5String.
+
+     - Added a method for doing dry runs of operations.  This is helpful
+       in testing passwords against password quality policies.
+
+     - Added an operation for retrieving a principal's current and
+       preferred string-to-key parameters, and a way to change them
+       without changing the principal's password.
+
+     - Added password quality codes as hints for smart clients, but
+       these are optional and not to be used instead of messages to be
+       displayed to useds.
+
+     - Added a 'commit' option to change-pw and set-pw (as requested by
+       Larry).
+
+     - Removed "version" field of the Kerberos V feature negotiation
+       struture.
+
+
+
+N. Williams        						[Page 30]
+
+
+DRAFT		Kerberos Set/Change Password v2		Expires January 2005
+
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires August 22, 2005                [Page 31]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-04.txt
new file mode 100644
index 00000000000..b8547195e4a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-04.txt
@@ -0,0 +1,1787 @@
+
+Kerberos Working Group                                  Nicolas Williams
+INTERNET-DRAFT                                          Sun Microsystems
+Expires: August 22, 2005                                    October 2005
+
+
+
+
+                Kerberos Set/Change Password: Version 2
+              <draft-ietf-krb-wg-kerberos-set-passwd-04.txt>
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 17, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies an extensible protocol for setting keys and
+   changing the passwords of Kerberos V principals.
+
+Table of Contents
+
+   1  Introduction
+   2  The Protocol
+   2.1  Transports 
+   2.2  Protocol Framing
+   2.3  Protocol version negotiation
+   2.3.1  Protocol Major Version Negotiation
+   2.3.2  Protocol Minor Version Negotiation
+   2.4  Use of Kerberos V
+
+N. Williams        						[Page 1]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   2.5  Use of ASN.1
+   2.6  Internationalization
+   2.6.1  Normalization Forms for UTF-8 Strings
+   2.6.2  Language Negotiation
+   2.7  Protocol Extensibility
+   2.8  Protocol Subsets
+   3  Protocol Elements
+   3.1  PDUs
+   3.2  Operations
+   3.2.1  Null
+   3.2.2  Change Kerberos Password
+   3.2.3  Set Kerberos Password
+   3.2.4  Set Kerberos Keys
+   3.2.5  Generate Kerberos Keys
+   3.2.6  Get New Keys
+   3.2.7  Commit New Keys
+   3.2.8  Get Password Quality Policy
+   3.2.9  Get Principal Aliases
+   3.2.10  Get Realm's Supported Kerberos V Version and Features
+   4  ASN.1 Module
+   6  IANA Considerations
+   7  Security Considerations
+   8  Acknowledgements
+   9  References
+   9.1  Normative References
+   9.2  Informative References
+   10  Authors' Addresses
+   11  Notes to the RFC Editor
+
+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 [RFC2119].
+
+1  Introduction
+
+   Up to this point Kerberos V has lacked a single, standard protocol
+   for changing passwords and keys.  While several vendor-specific
+   protocols exist for changing Kerberos passwords/keys, none are
+   properly internationalized and all are incomplete in one respect or
+   another and none are sufficiently extensible to cope with new
+   features that may be added to Kerberos V at some future time.
+
+   This document defines a protocol that is somewhat backward-compatible
+   with the "kpasswd" protocol defined in [RFC3244] that uses more or
+   less the same protocol framing.
+
+   This new protocol is designed to be extensible and properly
+   internationalized.
+
+2  The Protocol
+
+
+N. Williams        						[Page 2]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   The structure of the protocol is quite similar to that of typical RPC
+   protocols.  Each transaction consists of a data structure specific to
+   an operation which is then wrapped in a data structure which is
+   general to all operations of the protocol.  These data structures are
+   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
+   are encoded using the Distinguished Encoding Rules (DER) [X690].
+
+   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
+   KRB-ERROR, and framed in a header that is backwards compatible with
+   [RFC3244].
+
+2.1  Transports 
+
+   The service supports only connection-oriented transports,
+   specifically TCP, and MUST accept requests on TCP port 464, the same
+   as in [RFC3244].
+
+2.2  Protocol Framing
+
+   Requests and responses are exchanged using the same framing as in
+   [RFC3244], but with the following differences:
+
+    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
+
+    - the 'AP-REQ length' field of the request can be set to 0x0, in
+      which case the 'AP-REQ' field of the request is excluded
+
+    - the 'KRB-PRIV' field of the request and reply is mutually
+      exclusive with the 'AP-REQ' field of the request
+
+    - the 'AP-REP length' field of the reply can be set to 0x0, in
+      which case the 'AP-REP' field of the reply is excluded
+
+    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
+      be or has been accepted by the server
+
+    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
+      of the reply
+
+   The initial message from the client MUST carry an AP-REQ and the
+   response to any request bearing an AP-REQ MUST carry an AP-REP or
+   MUST be a KRB-ERROR.
+
+   Subsequent messages exchanged on the same TCP connection MAY involve
+   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
+   a new AP exchange except when it desires to authenticate as a
+   different principal, when the ticket last used for authentication
+   expires or when the server responds with an error indicating that the
+   client must re-authenticate.
+
+2.3  Protocol Version Negotiation
+
+   There are several major versions of this protocol.  Version 2 also
+
+N. Williams        						[Page 3]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   introduces a notion of protocol minor versions for use in negotiating
+   protocol extensions.  As of this time only one minor version is
+   defined for major version 2: minor version 0, defined herein.
+
+2.3.1  Protocol Major Version Negotiation
+
+   Version 2 clients that also support other versions, such as 0xff80,
+   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
+   first.
+
+   Servers which do not support version 2 of this protocol typically
+   include their preferred version number in the reply and/or may
+   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
+   status code of KRB5_KPASSWD_MALFORMED.
+
+   Note that some [RFC3244] server implementations close the TCP
+   connection without returning any other response.  Note also that
+   there is no integrity protection for the major version number in the
+   protocol framing or for any data in a KRB-ERROR.
+
+   As a result change password protocol major version negotiation is
+   subject to downgrade attacks.  Therefore major version negotiation is
+   NOT RECOMMENDED.
+
+   Where the server indicates that it does not support version 2, the
+   client MAY, but SHOULD NOT, unless configured to do so, fall back on
+   another major version of this protocol.
+
+   Version 2 servers MAY respond to non-v2 requests using whatever
+   response is appropriate for the versions used by the clients, but if
+   a server does not do this or know how to do this then it MUST respond
+   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
+   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
+   using a ProtocolErrorCode value of unsupported-major-version.
+
+   It is expected that implementations of as yet unspecified future
+   major versions of this protocol will be required to support version 2
+   integrity protected error replies for properly indicating no support
+   for version 2 of the protocl.  We also hope that no further major
+   versions of this protocol will be needed.
+
+2.3.2  Protocol Minor Version Negotiation
+
+   Version 2 clients are free to use whatever protocol minor version and
+   message extensions are available to them in their initial messages to
+   version 2 servers, provided that the minor versions (other than 0)
+   have been defined through IETF documents.
+
+   Version 2 servers MUST answer with the highest protocol minor version
+   number supported by the server and the client.
+
+   Version 2 clients MUST use the protocol minor version used in a
+   server's reply for any subsequent messages in the same TCP session.
+
+N. Williams        						[Page 4]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+
+   See section 2.7 for further description of the protocol's
+   extensibility and its relation to protocol minor versions and the
+   negotiation thereof.
+
+2.4  Use of Kerberos V and Key Exchange
+
+   This protocol makes use of messages defined in [RFC1510] and
+   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
+   KRB-PRIV.
+
+   All operations are to be performed by the server on behalf of the
+   client principal.
+
+   Clients SHOULD use "kadmin/setpw" as the principal name of the server
+   for all requests except when changing the client principal's own
+   expired password, for which they should use "kadmin/changepw".  The 
+   "kadmin/changepw" service exists to allow KDCs to limit principals
+   with expired passwords to getting initial tickets to the password
+   changing service only and only for changing expired passwords.
+
+   Servers MUST limit clients that used the "kadmin/changepw" service
+   principal name to changing the password of the client principal.
+
+   The client MUST request mutual authentication and the client MUST
+   MUST request the use of sequence numbers.
+
+   Clients SHOULD use INITIAL tickets for requests whose target
+   principal is the client's principal.  Servers SHOULD force the use of
+   INITIAL tickets for such requests and MAY force the use of INITIAL
+   for all others - see section 3.2.
+
+   Servers MUST specify a sub-session key.
+
+   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
+   sub-session key and key usage 20 (client->server) or 21
+   (server->client).
+
+   After each new AP exchange the client and server MUST destroy the
+   session keys, if any, resulting from the previous AP exchange.
+
+2.5  Use of ASN.1
+
+   This protocol's messages are defined in ASN.1, using only features
+   from [X680].  All ASN.1 types defined herein are to be encoded in
+   DER [X690].  A complete ASN.1 module is given in section 4.
+
+   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
+   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
+
+2.6  Internationalization
+
+   This protocol's request PDU carries an optional field indicating the
+
+N. Williams        						[Page 5]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   languages spoken by the client user; the client SHOULD send its list
+   of spoken languages to the server (once per-TCP session).
+
+   The server SHOULD localize all strings intended for display to users
+   to a language in common with the languages spoken by the client user.
+
+   Strings for Kerberos principal and realm names used in this protocol
+   are be constrained as per [clarifications].
+
+2.6.1  Normalization Forms for UTF-8 Strings
+
+   Because Kerberos V [clarifications] restricts principal names, realm
+   names and passwords to IA5String, this protocol uses UTF8String with
+   an extensible constraint to IA5String.
+
+   Future versions of Kerberos may relax this constraint; if so then a
+   minor version of this protocol should relax this constraint
+   accordingly.
+
+2.6.2  Language Negotiation
+
+   The server MUST pick a language from the client's input list or
+   the default language tag (see [RFC3066]) for text in its responses
+   which is meant for the user to read.
+
+   The server SHOULD use a language selection algorithm such that
+   consideration is first given to exact matches between the client's
+   spoken languages and the server's available locales, followed by
+   "fuzzy" matches where only the first sub-tags of the client's
+   language tag list are used for matching against the servers available
+   locales.
+
+   Servers MUST cache the optional language tag lists from prior
+   requests for use with subsequent requests that exclude the language
+   tag list.  Clients MAY expect such server behaviour and send the
+   language tag lists only once per-TCP session.  Clients SHOULD send
+   the server the language tag list at least once.
+
+   When the server has a message catalog for one of the client's spoken
+   languages the server SHOULD localize any text strings intended for
+   display to users.
+
+2.7  Protocol Extensibility
+
+   The protocol is defined in ASN.1 and uses extensibility markers
+   throughout.  As such, the module presented herein can be extended
+   within the framework of [X680].
+
+   Typed holes are not used in this protocol as it is very simple and
+   does not require the ability to deal with abstract data types defined
+   in different layers.  For this reason, the only way to extend this
+   protocol is by extending the ASN.1 module within the framework of the
+   IETF; all future extensions to this protocol have to be defined in
+
+N. Williams        						[Page 6]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   IETF documents unless otherwise specified in a future IETF revision
+   of this protocol.
+
+   A protocol minor version number is used to negotiate use of
+   extensions.  See section 2.3.2 for the minor version negotiation.
+
+   Servers SHOULD ignore unknown additions to the ASN.1 types, in
+   initial requests, where the syntax allows them, except for extensions
+   to the "Op-req" type, which MUST result in an error.
+
+   Servers MUST respond with an error (ProtocolErrorCode value of
+   unsupported-minor-version) to clients that use operations unknown to
+   the server.
+
+2.8  Protocol Subsets
+
+   The structure of the protocol is such that the ASN.1 syntaxes for the
+   various operations supported by the protocol are independent of the
+   each other.  Client and server implementations MAY implement subsets
+   of the overall protocol by removing some alternatives to the Op-req,
+   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
+   
+   For example, it should be possible to have a password-change only
+   client that cannot set principal's keys - and vice versa.
+
+3  Protocol Elements
+
+   The protocol as defined herein supports the following operations
+   relating to the management of Kerberos principal's passwords or keys:
+
+     [NOTE:  New since last version of this I-D.]
+     - get principal's current and preferred string-to-key parameters
+
+     - change password (or enctypes and string-to-key parameters)
+     - set password (administrative)
+     - set new keys
+     - generate new keys
+     - get new, un-committed keys
+     - commit new keys
+     - get password policy name and/or description of principal
+     - list aliases of a principal
+     - list enctypes and version of Kerberos V supported by realm
+
+   The operation for retrieving a list of aliases of a principal is
+   needed where KDCs implement aliasing of principal names and allows
+   clients to properly setup their key databases when principal aliasing
+   is in use.
+
+   Operations such as creation or deletion of principals are outside the
+   scope of this document, and should be performed via other means, such
+   as through directories or other Kerberos administration protocols.
+
+   The individual operations are described in section 3.2.
+
+N. Williams        						[Page 7]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+
+3.1  PDUs
+
+   The types "Request," "Response" and "Error-Response" are the ASN.1
+   module's PDUs.
+
+   The "Request" and "Response" PDUs are always to be sent wrapped in
+   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
+   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
+   otherwise it MUST be sent wrapped in a KRB-PRIV.
+
+   The ASN.1 syntax for the PDUs is given in section 4.
+
+   Note that the first field of each PDU is the major version of the
+   protocol, defaulted to 2, meaning that it is never included in
+   version 2 exchanges.  Similarly, the second field of each PDU is the
+   minor version, defaulted to 0.
+
+   The request, responses and error PDUs consist of an outer structure
+   ("Request," "Response" and "Error-Response") containing fields common
+   to all requests, responses and errors, respectively, and an inner
+   structure for fields that are specific to each operation's
+   requests/responses.  The inner structure is optional in the case of
+   the Error-Response PDU and need not be included when generic errors
+   occur for which there is a suitable ProtocolErrorCode.
+
+   Specifically, the outer Request structure has a field for passing a
+   client user's spoken (read) languages to the server.  It also has two
+   optional fields for identifying the requested operation's target
+   principal's name and realm (if not sent then the server MUST use the
+   client's principal name and realm as the target).  A boolean field
+   for indicating whether or not the request should be dry-run is also
+   included; dry-runs can be used to test server policies, and servers
+   MUST NOT modify any principals when processing dry-run requests.
+
+   The Response and Error PDUs' outer structures include a field
+   indicating the language that the server has chosen for localization
+   of text intended to be displayed to users; this field is defaulted to
+   "i-default".  This language tag applies to all UTF8 strings in the
+   inner structure (Op-rep and Op-err) that are meant to be displayed to
+   users.
+
+   The protocol error codes are:
+
+      - proto-generic-error
+
+        An operation-specific error ocurred, see the inner Op-error.
+
+      - proto-format-error
+      - proto-unsupported-major-version
+      - proto-unsupported-minor-version
+      - proto-unsupported-operation
+
+
+N. Williams        						[Page 8]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+      - proto-wrong-service-principal
+
+        Use kadmin/setpw for the server's principal name.
+
+      - proto-re-authentication-required
+
+        The server demands that the client re-authenticate through a new
+        AP exchange.
+
+      - proto-initial-ticket-required
+
+        Use of an INITIAL ticket is required for the requested
+        operation.
+
+      - proto-client-and-target-realm-mismatch
+
+        The server requires that the client's principal name and the
+        target principal of the operation share the same realm name.
+
+      - proto-target-principal-unknown
+      - proto-authorization-failed
+
+3.2  Operations
+
+   This section describes the semantics of each operation request and
+   response defined in the ASN.1 module in section 4.
+      
+3.2.1  Null
+
+   NAME
+
+      null - Null or "ping" operation
+
+   DESCRIPTION
+
+      The null request is intended for use with TCP; its purpose is
+      similar to RPC null procedures and is akin to a "ping" operation.
+
+   ERRORS
+
+      None.
+
+3.2.2  Change Kerberos Password
+
+   NAME
+
+      change-pw - Change password operation
+
+   SYNOPSIS
+
+      Req-change-pw(old-pw, [languages], [new-pw],
+                    [commit], [etypes]) ->
+         Rep-change-pw([info-text], [new-pw], [etypes]) |
+
+N. Williams        						[Page 9]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+         Err-change-pw([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      Change a principal's password.
+
+      The change password request has one required, three optional and
+      one defaulted arguments: "old-pw" (required), "languages,"
+      "new-pw", "commit" (defaults to "TRUE") and "etypes",
+      corresponding to the target principal's old password, its
+      preferred languages, its new password, a boolean indicating
+      whether or not to make the new long-term key available for
+      immediate use, and the desired enctypes for the new long-term
+      keys.
+
+      The server MUST validate the old password and MUST check the
+      quality of the new password, if sent, according the password
+      quality policy associated with the target principal.
+
+      If the old and new passwords in the request are the same strings,
+      and the principal is not currently required to change its
+      password, then the server MAY permit the password change as way to
+      change a principal's enctypes and string-to-key parameters.  This
+      feature provides a way to, for example, add enctypes to a
+      principals' password-derived long-term keys without forcing a
+      password change following an upgrade to the KDC that adds support
+      for new enctypes.
+
+      A client MAY request that the server generate a new password by
+      excluding the new password from its request, in which case the
+      server MUST either generate a new password or respond with an
+      error indicating that it does not support this feature.
+
+      Server-generated passwords MUST meet the target principal's
+      password quality policy.  It is RECOMMENDED that server-generated
+      passwords be user-friendly, that is, memorable and that the target
+      principal's preferred languages be taken into account by the
+      password generation alogrithm used by the server.
+
+      Uncommitted password changes are commited using the commit-keys
+      operation.
+
+   RETURN
+
+      Upon successful password changes the server responds with a
+      Rep-change-pw.  The fields of Rep-change-pw are all optional and
+      include:
+
+         - 'info-text' which the server can use to send a message to the
+           user such as "Your new password will expire in 90 days," for
+           example.
+
+         - 'new-pw' which the server MUST include if the client
+
+N. Williams        						[Page 10]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+           requested that the server generate a new password; generated
+           passwords MUST pass the target principal's password quality
+           policy.
+
+         - 'etypes' which the server MAY include to indicate which types
+           of long-term keys it created for the target principal and
+           which the server MUST include if the client specified a set
+           of enctypes in its request.
+
+   ERRORS
+
+      The server may respond to change password requests with protocol
+      or operation errors.  See section 3.1 for a description of
+      protocol error codes.
+
+      All operation errors include an optional 'help-text' field by
+      which the server can describe the error in a human-readable,
+      localizaed string.
+
+      Change password error codes include:
+
+         - generic-error
+
+         - old-pw-incorrect
+
+         - wont-generate-new-pw
+
+           The server will not generate a new password for this
+           principal or does not support password generation in general.
+
+         - new-pw-rejected-generic
+
+           The client's proposed new password failed the target
+           principal's password quality policy.
+
+           The server MUST include a description of the password quality
+           policy or aspect of it that the client's proposed new
+           password failed to meet.
+
+           The server MAY generate and send a new password that the
+           client can then use as a new password and which is guaranteed
+           to pass the target principal's current password quality
+           policy.
+
+           The server MAY include a set of policy error code hints.
+
+         - etype-not-supported
+
+           The client requested an enctype that the KDC does not
+           support.
+
+3.2.3  Set Kerberos Password
+
+
+N. Williams        						[Page 11]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   NAME
+
+      set-pw - Set password operation
+
+   SYNOPSIS
+
+      Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
+         Rep-set-pw([info-text], [new-pw], [etypes]) |
+         Err-set-pw([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      Administratively set a principal's password.
+
+      The set password request has three optional and one defaulted
+      arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
+      and "etypes", corresponding to the target principal's preferred
+      languages, new password, a boolean indicating whether or not to
+      make the new long-term key available for immediate use, and the
+      desired enctypes for the new long-term keys.
+
+      The server MUST check the quality of the new password, if sent,
+      according the password quality policy associated with the target
+      principal.
+
+      The server SHOULD require that the client use the change-pw
+      operation instead of set-pw when the client principal and the
+      target principal are the same.
+
+      A client MAY request that the server generate a new password by
+      excluding the new password from its request, in which case the
+      server MUST either generate a new password or respond with an
+      error indicating that it does not support this feature.
+
+      Server-generated passwords MUST meet the target principal's
+      password quality policy.  It is RECOMMENDED that server-generated
+      passwords be user-friendly, that is, memorable and that the target
+      principal's preferred languages be taken into account by the
+      password generation alogrithm used by the server.
+
+   RETURN
+
+      Upon successfully setting a password the server responds with a
+      Rep-set-pw.  The fields of Rep-set-pw are all optional and
+      include:
+
+         - 'info-text' which the server can use to send a message to the
+           user such as "Your new password will expire in 90 days," for
+           example.
+
+         - 'new-pw' which the server MUST include if the client
+           requested that the server generate a new password; generated
+           passwords MUST pass the target principal's password quality
+
+N. Williams        						[Page 12]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+           policy.
+
+         - 'etypes' which the server MAY include to indicate which types
+           of long-term keys it created for the target principal and
+           which the server MUST include if the client specified a set
+           of enctypes in its request.
+
+   ERRORS
+
+      The server may respond to set password requests with protocol or
+      operation errors.  See section XYZ for a description of protocol
+      error codes.
+
+      All operation errors include an optional 'help-text' field by
+      which the server can describe the error in a human-readable,
+      localizaed string.
+
+      Set password error codes include:
+
+         - generic-error
+
+         - use-change-pw
+
+           The server demands that the client use the change-pw
+           operation for the target principal of the set-pw request.
+
+         - wont-generate-new-pw
+
+           The server will not generate a new password for this
+           principal or does not support password generation in general.
+
+         - new-pw-rejected-generic
+
+           The client's proposed new password failed the target
+           principal's password quality policy.
+
+           The server MUST include a description of the password quality
+           policy or aspect of it that the client's proposed new
+           password failed to meet.
+
+           The server MAY generate and send a new password that the
+           client can then use as a new password and which is guaranteed
+           to pass the target principal's current password quality
+           policy.
+
+           The server MAY include a set of policy error code hints.
+
+         - etype-not-supported
+
+           The client requested an enctype that the KDC does not
+           support.
+
+3.2.4  Set Kerberos Keys
+
+N. Williams        						[Page 13]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+
+   NAME
+
+      set-keys
+
+   SYNOPSIS
+
+      Req-set-keys(new-keys, commit?, [isupport]) ->
+         Rep-set-keys([info-text], kvno, aliases, [isupport])
+
+   DESCRIPTION
+
+      The set-keys request consists of two required fields and one
+      optional field: "new-keys", "commit" (a boolean field - see below)
+      and "isupport", an optional field for indicating to the KDC what
+      Kerberos V features are supported by the target principal.
+
+      When "commit" is true the KDC makes the new keys available for
+      issueing tickets encrypted in them immediately.  Otherwise the
+      client MUST follow up with a commit-keys request to make the keys
+      available.  This feature is useful for changing keys shared by
+      multiple hosts, in clustered services, for example, in an atomic
+      manner; see section 3.2.6 and 3.2.7.
+
+      If a principal has keys are awaiting commitment when a new
+      set-keys request for that principal s made then the KDC MUST
+      overwrite the deferred keys.
+
+   RETURN
+
+      For successful set-keys operations the server returns:
+
+         - Informational text, optional.
+
+         - The new kvno for the target principal.
+
+         - A list of aliases of the target principal known to the KDC
+           (optional).
+
+         - The set of Kerberos V features supported by the KDC
+           (optional).
+
+   ERRORS
+
+      The server may respond with the following errors:
+
+         - generic
+         - deferred-commit-no-support
+         - etype-no-support
+
+3.2.5  Generate Kerberos Keys
+
+   NAME
+
+N. Williams        						[Page 14]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+
+      gen-keys
+
+   SYNOPSIS
+
+      Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
+         Rep-set-keys([info-text], key, kvno, aliases, [isupport])
+
+   DESCRIPTION
+
+      The gen-keys is similar to the set-keys request (see section
+      3.2.4) but differs in that the server generates keys of
+      client-requested enctypes, rather than the client providing
+      specific keys.
+
+      The gen-keys request consists of two required fields and two
+      optional fields: "etypes" (the enctypes of the new keys),
+      "entropy", "commit" and "isupport" (see section 3.2.4).
+
+      If a principal has keys are awaiting commitment when a new
+      set-keys request for that principal s made then the KDC MUST
+      overwrite the deferred keys.
+
+   RETURN
+
+      For successful set-keys operations the server returns:
+
+         - Informational text, optional.
+
+         - The new kvno for the target principal.
+
+         - The new key (only one is needed).
+
+         - A list of aliases of the target principal known to the KDC
+           (optional).
+
+         - The set of Kerberos V features supported by the KDC
+           (optional).
+
+   ERRORS
+
+      The server may respond with the following errors:
+
+         - generic
+         - deferred-commit-no-support
+         - etype-no-support
+
+3.2.6  Get New Keys
+
+   NAME
+
+      get-keys
+
+
+N. Williams        						[Page 15]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   SYNOPSIS
+
+      Req-get-keys(kvno) ->
+         Rep-get-keys([info-text], keys, aliases, [isupport]) |
+         Err-get-keys([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      This request allows a client to get the keys set or generated in a
+      previous set-keys or gen-keys request with deferred commitment..
+
+   RETURN
+
+      If the target principal and kvno correspond to uncommitted keys
+      the server MUST respond with the actual keys that would be set by
+      a subsequent commit-keys request.  Otherwise the server MUST
+      respond with an error (meaning that this operation cannot be used
+      to extract keys from the KDC that may be in use).
+
+   ERRORS
+
+         - generic
+         - kvno-committed
+         - no-such-kvno
+
+3.2.7  Commit New Keys
+
+   NAME
+
+      commit-keys
+
+   SYNOPSIS
+
+      Req-commit-keys(kvno) ->
+         Rep-commit-keys() |
+         Err-commit-keys([help-text], error code, [error info])
+
+   DESCRIPTION
+
+      The commit-keys operation allows a client to bring a principal's
+      new keys into use at the KDC.
+
+      Clients should make a commit-keys request corresponding to a
+      deferred commitment set-keys/gen-keys operation as soon as the
+      local key database for the target principal is updated.
+
+      The target principal name and the kvno MUST match those from a
+      prior set-keys or gen-keys operation.
+
+      Servers MAY expire delayed key commitments at will.  Servers
+      SHOULD expire uncommitted new keys after a reasonable amount of
+      time (600 seconds is RECOMMENDED).
+
+
+N. Williams        						[Page 16]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+      Servers MUST respond to new set-keys requests for principals with
+      pending, uncommitted new keys by expiring the uncommitted new keys
+      and proceeding as if there had been no expired new keys.
+
+   ERRORS
+
+      - generic
+      - op-kvno-expired
+      - op-kvno-unknown
+      - new-keys-conflict (A set-keys or gen-keys request succeeded
+                           subsequent to the request that matches this
+                           {principal, kvno} tuple.)
+
+3.2.8  Get Password Quality Policy
+   
+   NAME
+
+      get-pw-policy
+
+   SYNOPSIS
+
+      Req-get-pw-policy() ->
+         Rep-get-pw-policy([policy name], [policy description])
+
+   DESCRIPTION
+
+      Returns a description of the target principal's associated
+      password quality policy, if any, as a list of localized
+      UTF8String values.
+
+      Clients can use this operation in conjunction with the change-pw
+      operation to obtain text that can be displayed to the user before
+      the user actually enters a new password.
+
+      It is common for sites to set policies with respect to password
+      quality.  It is beyond the scope of this document to describe such
+      policies.  Management of password quality policies' actual content
+      is also beyond the scope of this protocol.
+
+   ERRORS
+
+      No operation errors are defined.
+
+
+3.2.9  Get Principal Aliases
+   
+   NAME
+
+      get-print-aliases
+
+   SYNOPSIS
+
+      Req-get-princ-aliases() ->
+
+N. Williams        						[Page 17]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+         Rep-get-princ-aliases(aliases)
+
+   DESCRIPTION
+
+      Returns a list of aliases of the target principal.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.2.10  Get Realm's Supported Kerberos V Version and Features
+   
+   NAME
+
+      get-realm-krb5-support
+
+   SYNOPSIS
+
+      Req-get-realm-krb5-support() ->
+         Rep-get-realm-krb5-support(isupport)
+
+   DESCRIPTION
+
+      Returns set of Kerberos V features support by the target
+      principal's realm's KDCs.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.2.11  Retrieve Principal's S2K Params and Preferred Params
+   
+   NAME
+
+      get-s2kparams
+
+   SYNOPSIS
+
+      Req-get-s2kparams() ->
+         Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
+
+   DESCRIPTION
+
+      Returns the string2key parameters for the principal's current
+      password-derived long-term keys, if any, and the parameters that
+      the realm would prefer, if they differ from the former.
+
+      This operation is intended for use with the change-pw() operation.
+      When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
+      the principal's long-term secret keys' string2key parameters (and
+      enctype list) should be changed and, if so, change them.
+
+      If the 'princ-s2kparams' return value is missing then the
+
+N. Williams        						[Page 18]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+      principal does not have a password-derived long-term key.
+
+      The 'preferred-s2kparams' MUST be excluded if the principal's
+      string2key parameters satisfy the realm's policy.
+
+   ERRORS
+
+      No operation-specific errors.
+
+3.3  Principal Aliases
+
+   Applications that use Kerberos often have to derive acceptor
+   principal names from hostnames entered by users.  Such hostnames may
+   be aliases, they may be fully qualified, partially qualified or not
+   qualified at all.  Some implementations have resorted to deriving
+   principal names from such hostnames by utilizing the names services
+   to canonicalize the hostname first; such practices are not secure
+   unless the name service are secure, which often aren't.
+
+   One method for securely deriving principal names from hostnames is to
+   alias principals at the KDC such that the KDC will issue tickets for
+   principal names which are aliases of others.  It is helpful for
+   principals to know what are their aliases as known by the KDCs.
+
+   Note that changing a principal's aliases is out of scope for this
+   protocol.
+
+3.4  Kerberos V Feature Negotiation
+
+   Principals and realms' KDCs may need to know about additional
+   Kerberos V features and extensions that they each support.  Several
+   operations (see above) provide a way for clients and servers to
+   exchange such infomration, in the form of lists of types supported
+   for the various typed holes used in Kerberos V.
+
+4  ASN.1 Module
+
+   DEFINITIONS EXPLICIT TAGS ::= BEGIN
+   -- 
+   -- Note:  EXPLICIT tagging is in use by default throughout this
+   --        module.
+
+   -- From [clarifications] with modifications
+   PrincipalName            ::= SEQUENCE {
+        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
+   }
+   Realm                    ::= UTF8String (IA5String, ...)
+   Salt                     ::= UTF8String (IA5String, ...)
+   Password                 ::= UTF8String (IA5String, ...)
+
+   -- NOTE WELL: Principal and realm names MUST be constrained by the
+   --            specification of the version of Kerberos V used by the
+   --            client.
+
+N. Williams        						[Page 19]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   -- 
+   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
+   --  type and a UTF8String, for simplicity.]
+
+   -- From [clarifications]
+   Int32            ::= INTEGER (-2147483648..2147483647)
+   UInt32           ::= INTEGER (0..4294967295)
+
+   -- Based on [clarifications]
+   Etype            ::= Int32
+   Etype-Info-Entry ::= SEQUENCE {
+        etype           [0] Etype,
+        salt            [1] Salt OPTIONAL,
+        s2kparams       [2] OCTET STRING OPTIONAL,
+        ...
+   }
+   Key              ::= SEQUENCE {
+        enc-type        [0] Etype,        -- from Kerberos
+        key             [1] OCTET STRING,
+        ...
+   }
+
+   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
+
+   -- Empty, extensible SEQUENCEs are legal ASN.1
+   Extensible-NULL  ::= SEQUENCE {
+        ...
+   }
+
+   -- Kerberos clients negotiate some parameters relating to their peers
+   -- indirectly through the KDC.  Today this is true of ticket session
+   -- key enctypes, but in the future this indirect negotiation may also
+   -- occur with respect to the minor version of Kerberos V to be used
+   -- between clients and servers.  Additionally, KDCs may need to know
+   -- what authorization-data types are supported by service principals,
+   -- both, for compatibility with legacy software and for optimization.
+   --
+   -- Thesefore it is important for KDCs to know what features of
+   -- Kerberos V each service principal supports.
+   --
+   -- In version 2.0 of this protocol the clients and servers may notify
+   -- each other of their support for:
+   --
+   --  - enctypes
+   --  - authorization data types
+   --  - transited encoding data types
+   --
+   -- All authorization-data types defined in [clarifications] are
+   -- assumed to be supported if the minor version is 1 and do not need
+   -- to be included in the ad-type list.
+   --
+   -- Int32 is used for enctype and transited encoding data type
+   -- identifiers.
+
+N. Williams        						[Page 20]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   --
+   -- An extensible CHOICE of Int32 is used for authorization data
+   -- types.
+
+   KerberosV-TR-ID             ::= Int32
+
+   KerberosV-AD-ID             ::= CHOICE {
+        ad-int                [0] Int32,
+        ...
+   }
+
+   KerberosVSupportNego        ::= SEQUENCE {
+        enc-types       [0] SEQUENCE OF Etype,
+        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
+                                    -- authorization data types
+        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
+                                    -- transited encoding types
+        ...
+   }
+
+   Request                     ::= [APPLICATION 0] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
+                -- Should be defaulted to the SEQUENCE of "i-default"
+        targ-name       [2] PrincipalName OPTIONAL,
+        targ-realm      [3] Realm OPTIONAL,
+                -- If targ-name/realm are missing then the request
+                -- applies to the principal of the client
+        dry-run         [4] BOOLEAN DEFAULT FALSE,
+        operation       [5] Op-req,
+        ...
+   }
+
+   Response                    ::= [APPLICATION 1] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        language        [1] Language-Tag DEFAULT "i-default",
+        result          [2] Op-rep,
+        ...
+   }
+
+   Error-Response              ::= [APPLICATION 2] SEQUENCE {
+        pvno-minor      [0] INTEGER DEFAULT 0,
+        language        [1] Language-Tag DEFAULT "i-default",
+        error-code      [2] ProtocolErrorCode,
+        help-text       [3] UTF8String OPTIONAL,
+        op-error        [4] Op-err OPTIONAL,
+        ...
+   }
+
+   Op-req                      ::= CHOICE {
+        null                     [0] Req-null,
+        change-pw                [1] Req-change-pw,
+        set-pw                   [2] Req-set-pw,
+
+N. Williams        						[Page 21]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+        set-keys                 [3] Req-set-keys,
+        gen-keys                 [4] Req-gen-keys,
+        get-keys                 [5] Req-get-keys,
+        commit-keys              [6] Req-commit-keys,
+        get-pw-policy            [7] Req-get-pw-policy,
+        get-princ-aliases        [8] Req-get-princ-aliases,
+        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
+        get-s2kparams            [10] Req-get-s2kparams,
+        ...
+   }
+
+   Op-rep                     ::= CHOICE {
+        null                    [0] Rep-null,
+        change-pw               [1] Rep-change-pw,
+        set-pw                  [2] Rep-set-pw,
+        set-keys                [3] Rep-set-keys,
+        gen-keys                [4] Req-gen-keys,
+        get-keys                [5] Req-get-keys,
+        commit-keys             [6] Rep-commit-keys,
+        get-pw-policy           [7] Rep-get-pw-policy,
+        get-princ-aliases       [8] Rep-get-princ-aliases,
+        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
+        get-s2kparams           [10] Rep-get-s2kparams,
+        ...
+   }
+
+   Op-err        ::= CHOICE {
+        null                    [0] Err-null,
+        change-pw               [1] Err-change-pw,
+        set-pw                  [2] Err-set-pw,
+        set-keys                [3] Err-set-keys,
+        gen-keys                [4] Err-gen-keys,
+        get-keys                [5] Err-get-keys,
+        commit-keys             [6] Err-commit-keys,
+        get-pw-policy           [7] Err-get-pw-policy,
+        get-princ-aliases       [8] Err-get-princ-aliases,
+        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
+        get-s2kparams           [10] Err-get-s2kparams,
+        ...
+   }
+
+   ProtocolErrorCode           ::= ENUM {
+        proto-format-error,
+        proto-unsupported-major-version,
+        proto-unsupported-minor-version,
+        proto-unsupported-operation,      -- Request CHOICE tag unknown
+        proto-generic-see-op-error,       -- See Op-error
+        proto-wrong-service-principal,    -- Use kadmin/setpw
+        proto-re-authentication-required,
+        proto-initial-ticket-required,
+        proto-client-and-target-realm-mismatch,
+        proto-target-principal-unknown,
+        proto-authorization-failed,
+
+N. Williams        						[Page 22]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+        proto-dry-run-not-permitted,
+        ...
+   }
+
+   -- These codes are hints for clients, primarily for when they are
+   -- used for changing the passwords of automated principals; error
+   -- replies carry password quality policy help text that is more
+   -- appropriate for clients to display to users.
+   PW-Quality-Codes        ::= ENUM {
+        pwq-generic,
+        pwq-too-soon,
+        pwq-repeated,
+        pwq-too-short,
+        pwq-dictionary-words,
+        pwq-prohibited-codepoints,
+        pwq-need-more-char-classes,
+        ...
+   }
+
+   --
+   -- Requests and responses
+   --
+
+   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
+   Req-null    ::= NULL
+
+   Rep-null    ::= NULL
+
+   Err-null    ::= NULL
+
+   -- Change password
+   Req-change-pw        ::= SEQUENCE {
+        old-pw            [0] Password,
+        new-pw            [1] Password OPTIONAL,
+        commit            [2] BOOLEAN DEFAULT TRUE,
+        etypes            [3] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Rep-change-pw        ::= SEQUENCE {
+        info-text         [0] UTF8String OPTIONAL,
+        new-pw            [1] Password OPTIONAL,
+                            -- generated by the server if present
+                            -- (and requested by the client)
+        etypes            [2] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Err-change-pw        ::= SEQUENCE {
+        help-text         [0] UTF8String OPTIONAL,
+        error             [1] CHOICE {
+            op-generic-error           [0] Extensible-NULL,
+            op-old-pw-incorrect        [1] Extensible-NULL,
+
+N. Williams        						[Page 23]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+            op-wont-generate-new-pw    [2] Extensible-NULL,
+            op-new-pw-rejected-generic [3] SEQUENCE {
+                    policy                  [1] SEQUENCE OF UTF8String,
+                    suggested-pw            [2] Password OPTIONAL,
+                    policy-codes            [3] SET OF PW-Quality-Codes
+                                                    OPTIONAL,
+                    ...
+            }
+            op-etype-not-supported     [4] SEQUENCE {
+                    supported-etypes   [1] SEQUENCE OF Etype,
+                    ...
+            },
+            ...
+        },
+        ...
+   }
+
+   -- Set password
+   Req-set-pw        ::= SEQUENCE {
+        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
+        new-pw                [1] Password OPTIONAL,
+        commit                [2] BOOLEAN DEFAULT TRUE,
+        etypes                [3] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Rep-set-pw        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        new-pw                [1] Password OPTIONAL,
+                                -- generated by the server if present
+                                -- (and requested by the client)
+        etypes                [2] SEQUENCE (1..) OF Etype OPTIONAL,
+        ...
+   }
+
+   Err-set-pw        ::= Err-change-pw
+
+   -- Set keys
+   Req-set-keys      ::= SEQUENCE {
+        keys            [0] SEQUENCE OF Key,
+        commit          [1] BOOLEAN DEFAULT TRUE,
+                                -- TRUE  -> install keys now
+                                -- 
+                                -- FALSE -> require set-keys-commit
+                                --          before issuing tickets
+                                --          encrypted with these keys.
+                                -- 
+                                -- See commit-keys op
+        isupport        [2] KerberosVSupportNego OPTIONAL,
+                                -- For future Kerberos V extensions KDCs
+                                -- may need to know what krb5 version is
+                                -- supported by individual service
+                                -- principals.  This field provides a
+
+N. Williams        						[Page 24]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+                                -- way to tell the KDC what version of
+                                -- Kerberos V the target principal
+                                -- supports.
+        ...
+   }
+
+   Rep-set-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        kvno             [1] UInt32,
+        aliases          [2] SEQUENCE OF SEQUENCE {
+                name     [0] PrincipalName,
+                realm    [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-set-keys        ::= SEQUENCE {
+        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
+        error         [1] CHOICE {
+                op-generic                    [0] Extensible-NULL,
+                op-deferred-commit-no-support [1] Extensible-NULL,
+                op-etype-no-support           [2] SEQUENCE OF {
+                        supported-etypes      [1] SEQUENCE OF Etype,
+                        ...
+                }
+                ...
+        }
+   }
+
+   -- Generate keys
+   Req-gen-keys        ::= SEQUENCE {
+        etypes           [0] SEQUENCE (1..) OF Etype,
+        entropy          [1] OCTET STRING OPTIONAL,
+        commit           [2] BOOLEAN DEFAULT TRUE,
+                                -- TRUE  -> install keys now
+                                -- 
+                                -- FALSE -> require set-keys-commit
+                                --          before issuing tickets
+                                --          encrypted with these keys.
+                                -- 
+                                -- See commit-keys op
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+                                -- For future Kerberos V extensions KDCs
+                                -- may need to know what krb5 version is
+                                -- supported by individual service
+                                -- principals.  This field provides a
+                                -- way to tell the KDC what version of
+                                -- Kerberos V the target principal
+                                -- supports.
+        ...
+
+N. Williams        						[Page 25]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   }
+
+   Rep-gen-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        kvno             [1] UInt32,
+        key              [2] Key,
+        aliases          [3] SEQUENCE OF SEQUENCE {
+                name          [0] PrincipalName,
+                realm         [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [4] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-gen-keys        ::= Err-set-keys
+
+   -- Get un-committed key request
+   Req-get-keys        ::= SEQUENCE {
+        kvno             [0] UInt32,
+        ...
+   }
+
+   Rep-get-keys        ::= SEQUENCE {
+        info-text        [0] UTF8String OPTIONAL,
+        keys             [1] SEQUENCE OF Key,
+        aliases          [2] SEQUENCE OF SEQUENCE {
+                name          [0] PrincipalName,
+                realm         [1] Realm OPTIONAL,
+                ...
+        },
+        isupport         [3] KerberosVSupportNego OPTIONAL,
+        ...
+        -- Should there be ETYPE-INFO2 stuff here?
+   }
+
+   Err-get-keys      ::= SEQUENCE {
+        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
+        error          [1] CHOICE {
+                op-generic         [0] Extensible-NULL,
+                op-kvno-committed  [1] Extensible-NULL,
+                op-no-such-kvno    [1] Extensible-NULL,
+                ...
+        }
+   }
+
+   -- Commit a set keys request
+   Req-commit-keys ::= SEQUENCE {
+        kvno         [0] UInt32,
+        ...
+   }
+
+
+N. Williams        						[Page 26]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   Rep-commit-keys ::= Extensible-NULL
+
+   Err-commit-keys ::= SEQUENCE {
+        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
+        error        [1] CHOICE {
+                op-generic           [0] Extensible-NULL,
+                op-kvno-expired      [1] Extensible-NULL,
+                    -- The client took too long to respond.
+                op-kvno-unknown      [2] Extensible-NULL,
+                    -- The targ princ/kvno is invalid or unknown to the
+                    -- server (perhaps it lost track of state)
+                op-new-keys-conflict [3] Extensible-NULL,
+                    -- A new-keys/commit-keys request subsequent to the
+                    -- new-keys that produced the kvno has completed
+                    -- and incremented the principal's kvno
+                ...
+        }
+        ...
+   }
+
+   -- Get password policy
+   Req-get-pw-policy   ::= Extensible-NULL
+
+   Rep-get-pw-policy   ::= SEQUENCE {
+        policy-name      [0] UTF8String OPTIONAL,
+        description      [1] SEQUENCE OF UTF8String OPTIONAL,
+        ...
+   }
+
+   Err-get-pw-policy   ::= Extensible-NULL
+
+   -- Get principal aliases
+   Req-get-princ-aliases        ::= Extensible-NULL
+
+   Rep-get-princ-aliases        ::= SEQUENCE {
+        help-text    [0] UTF8String OPTIONAL,
+        aliases      [1] SEQUENCE OF SEQUENCE {
+                name      [0] PrincipalName,
+                realm     [1] Realm OPTIONAL,
+                ...
+        },
+        ...
+   }
+
+   Err-get-princ-aliases        ::= Extensible-NULL
+
+   -- Get list of enctypes supported by KDC for new keys
+   Req-get-realm-krb5-support   ::= Extensible-NULL
+
+   Rep-get-realm-krb5-support   ::= SEQUENCE {
+        isupport        [0] KerberosVSupportNego,
+                                -- Version of Kerberos V supported by
+                                -- the target realm.
+
+N. Williams        						[Page 27]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+        ...
+   }
+
+   Err-get-realm-krb5-support   ::= Extensible-NULL
+
+   -- Get s2kparams
+   Req-get-s2kparams            ::= Extensible-NULL
+
+   Rep-get-s2kparams            ::= SEQUENCE {
+        help-text       [0] UTF8String OPTIONAL,
+        s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
+        ...
+   }
+
+   Err-get-s2kparams            ::= Extensible-NULL
+
+   END
+
+
+6  IANA Considerations
+
+   There are no IANA considerations for this document.
+
+7  Security Considerations
+   
+   Implementors and site administrators should note that the redundancy
+   of UTF-8 encodings of passwords varies by language.  Password quality
+   policies SHOULD, therefore, take this into account when estimating
+   the amount of redundancy and entropy in a proposed new password.  [??
+   It's late at night - I think this is correct.]
+
+   Kerberos set/change password/key protocol major version negotiation
+   cannot be done securely; a downgrade attack is possible against
+   clients that attempt to negotiate the protocol major version to use
+   with a server.  It is not clear at this time that the attacker would
+   gain much from such a downgrade attack other than denial of service
+   (DoS) by forcing the client to use a protocol version which does not
+   support some feature needed by the client (Kerberos V in general is
+   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
+   SHOULD NOT negotiate support for legacy major versions of this
+   protocol unless configured otherwise.
+
+   This protocol does not have Perfect Forward Security (PFS).  As a
+   result, any passive network snooper watching password/key changing
+   operations who has stolen a principal's password or long-term keys
+   can find out what the new ones are.
+
+   [More text needed?]
+
+8  Acknowledgements
+   
+   The authors would like to thank original editors/authors Jonathan
+   Trostle, Bill Gossman, Mike Swift, John Brezak, as well as Ken
+   Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
+
+N. Williams        						[Page 28]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
+   other participants from the IETF Kerberos Working Group for their
+   assistance.
+
+9  References
+
+9.1  Normative References
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2119]
+      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
+      Indicate Requirement Levels," March 1997, Status: Best Current
+      Practice.
+
+   [X680]
+      Abstract Syntax Notation One (ASN.1): Specification of Basic
+      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
+      International Standard 8824-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
+
+   [X690]
+      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
+      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
+      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
+      Standard 8825-1:1998.
+      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
+
+   [clarifications]
+      RFC-Editor: To be replaced by RFC number for
+      draft-ietf-krb-wg-kerberos-clarifications.
+
+   [RFC3066]
+      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
+      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
+      Practice.
+
+9.2  Informative References
+
+   [RFC3244]
+      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
+      Kerberos Change Password and Set Password Protocols," February
+      2002, Status: Informational.
+
+10  Authors' Addresses
+
+      Nicolas Williams
+      Sun Microsystems
+      5300 Riata Trace Ct
+      Austin, TX 78727
+
+N. Williams        						[Page 29]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+      Email: nicolas.williams@sun.com
+
+
+11  Notes to the RFC Editor
+
+   This document has two KRB WG drafts as normative references and
+   cannot progress until those drafts progress, but no other draft
+   depends on this one.
+
+12  Change History
+
+    -01 -> -02
+
+     - Removed Bill Gossman, Mike Swift and John Brezak as authors.
+
+     - Removed UDP as a transport for this protocol.
+
+     - Replaced redundant copies of framing ASCII art with reference to
+       RFC3244.
+
+     - Made all name/password strings UTF8String with an extensible
+       constraint to IA5String.
+
+     - Added a method for doing dry runs of operations.  This is helpful
+       in testing passwords against password quality policies.
+
+     - Added an operation for retrieving a principal's current and
+       preferred string-to-key parameters, and a way to change them
+       without changing the principal's password.
+
+     - Added password quality codes as hints for smart clients, but
+       these are optional and not to be used instead of messages to be
+       displayed to useds.
+
+     - Added a 'commit' option to change-pw and set-pw (as requested by
+       Larry).
+
+     - Removed "version" field of the Kerberos V feature negotiation
+       struture.
+
+
+
+N. Williams        						[Page 30]
+
+DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
+
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams                Expires August 22, 2005                [Page 31]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
new file mode 100644
index 00000000000..a6dec9d1e07
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                             Ken Hornstein
+<draft-ietf-krb-wg-krb-dns-locate-02.txt>                            NRL
+February 28, 2001                                         Jeffrey Altman
+Expires: August 28, 2001                             Columbia University
+
+
+
+          Distributing Kerberos KDC and Realm Information with DNS
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Distribution of this memo is unlimited.  It is filed as <draft-ietf-
+   krb-wg-krb-dns-locate-02.txt>, and expires on August 28, 2001.
+   Please send comments to the authors.
+
+Abstract
+
+   Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
+   col [RFC????] describe any mechanism for clients to learn critical
+   configuration information necessary for proper operation of the pro-
+   tocol.  Such information includes the location of Kerberos key dis-
+   tribution centers or a mapping between DNS domains and Kerberos
+   realms.
+
+   Current Kerberos implementations generally store such configuration
+   information in a file on each client machine.  Experience has shown
+   this method of storing configuration information presents problems
+   with out-of-date information and scaling problems, especially when
+
+
+
+Hornstein, Altman                                               [Page 1]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   using cross-realm authentication.
+
+   This memo describes a method for using the Domain Name System
+   [RFC1035] for storing such configuration information.  Specifically,
+   methods for storing KDC location and hostname/domain name to realm
+   mapping information are discussed.
+
+DNS vs. Kerberos - Case Sensitivity of Realm Names
+
+   In Kerberos, realm names are case sensitive.  While it is strongly
+   encouraged that all realm names be all upper case this recommendation
+   has not been adopted by all sites.  Some sites use all lower case
+   names and other use mixed case.  DNS on the other hand is case insen-
+   sitive for queries but is case preserving for responses to TXT
+   queries.  Since "MYREALM", "myrealm", and "MyRealm" are all different
+   it is necessary that only one of the possible combinations of upper
+   and lower case characters be used.  This restriction may be lifted in
+   the future as the DNS naming scheme is expanded to support non-ASCII
+   names.
+
+Overview - KDC location information
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2052].  The format of this RR is as follows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for Kerberos is always "_kerberos".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_udp" record MUST be included.  If the Kerberos implementa-
+   tion supports TCP transport, a "_tcp" record SHOULD be included.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
+   ing as defined in RFC 2052.
+
+   As per RFC 2052 the Port number should be the value assigned to "ker-
+   beros" by the Internet Assigned Number Authority (88).
+
+Example - KDC location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
+   beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
+   directed to kdc1.asdf.com first as per the specified priority.
+   Weights are not used in these records.
+
+
+
+
+Hornstein, Altman                                               [Page 2]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
+   _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
+
+Overview - Kerberos password changing server location information
+
+   Kerberos password changing server [KERB-CHG] location is to be stored
+   using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
+   lows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for the password server is always "_kpasswd".
+
+   The Proto MUST be "_udp".
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
+   ing as defined in RFC 2052.
+
+   As per RFC 2052 the Port number should be the value assigned to
+   "kpasswd" by the Internet Assigned Number Authority (464).
+
+Overview - Kerberos admin server location information
+
+   Kerberos admin location information is to be stored using the DNS SRV
+   RR [RFC 2052].  The format of this RR is as follows:
+
+   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+
+   The Service name for the admin server is always "_kerberos-adm".
+
+   The Proto can be either "_udp" or "_tcp".  If these records are to be
+   used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
+   mentation supports UDP transport, a "_udp" record SHOULD be included.
+
+   The Realm is the Kerberos realm that this record corresponds to.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
+   ing as defined in RFC 2052.
+
+   As per RFC 2052 the Port number should be the value assigned to
+   "kerberos-adm" by the Internet Assigned Number Authority (749).
+
+   Note that there is no formal definition of a Kerberos admin protocol,
+   so the use of this record is optional and implementation-dependent.
+
+
+
+
+
+Hornstein, Altman                                               [Page 3]
+
+RFC DRAFT                                              February 28, 2001
+
+
+Example - Kerberos administrative server location information
+
+   These are DNS records for a Kerberos realm ASDF.COM.  It has one
+   administrative server, kdc1.asdf.com.
+
+   _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 749 kdc1.asdf.com.
+
+Overview - Hostname/domain name to Kerberos realm mapping
+
+   Information on the mapping of DNS hostnames and domain names to Ker-
+   beros realms is stored using DNS TXT records [RFC 1035].  These
+   records have the following format.
+
+   Service.Name TTL Class TXT Realm
+
+   The Service field is always "_kerberos", and prefixes all entries of
+   this type.
+
+   The Name is a DNS hostname or domain name.  This is explained in
+   greater detail below.
+
+   TTL, Class, and TXT have the standard DNS meaning as defined in RFC
+   1035.
+
+   The Realm is the data for the TXT RR, and consists simply of the Ker-
+   beros realm that corresponds to the Name specified.
+
+   When a Kerberos client wishes to utilize a host-specific service, it
+   will perform a DNS TXT query, using the hostname in the Name field of
+   the DNS query.  If the record is not found, the first label of the
+   name is stripped and the query is retried.
+
+   Compliant implementations MUST query the full hostname and the most
+   specific domain name (the hostname with the first label removed).
+   Compliant implementations SHOULD try stripping all subsequent labels
+   until a match is found or the Name field is empty.
+
+Example - Hostname/domain name to Kerberos realm mapping
+
+   For the previously mentioned ASDF.COM realm and domain, some sample
+   records might be as follows:
+
+   _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
+   _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
+   _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
+
+   Let us suppose that in this case, a Kerberos client wishes to use a
+   Kerberized service on the host foo.asdf.com.  It would first query:
+
+
+
+Hornstein, Altman                                               [Page 4]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   _kerberos.foo.asdf.com. IN TXT
+
+   Finding no match, it would then query:
+
+   _kerberos.asdf.com. IN TXT
+
+   And find an answer of ASDF.COM.  This would be the realm that
+   foo.asdf.com resides in.
+
+   If another Kerberos client wishes to use a Kerberized service on the
+   host salesserver.asdf.com, it would query:
+
+   _kerberos.salesserver.asdf.com IN TXT
+
+   And find an answer of SALES.ASDF.COM.
+
+Security considerations
+
+   As DNS is deployed today, it is an unsecure service.  Thus the infor-
+   mation returned by it cannot be trusted.
+
+   Current practice for REALM to KDC mapping is to use hostnames to
+   indicate KDC hosts (stored in some implementation-dependent location,
+   but generally a local config file).  These hostnames are vulnerable
+   to the standard set of DNS attacks (denial of service, spoofed
+   entries, etc).  The design of the Kerberos protocol limits attacks of
+   this sort to denial of service.  However, the use of SRV records does
+   not change this attack in any way.  They have the same vulnerabili-
+   ties that already exist in the common practice of using hostnames for
+   KDC locations.
+
+   Current practice for HOSTNAME to REALM mapping is to provide a local
+   configuration of mappings of hostname or domain name to realm which
+   are then mapped to KDCs.  But this again is vulnerable to spoofing
+   via CNAME records that point to hosts in other domains.  This has the
+   same effect as when a TXT record is spoofed.  In a realm with no
+   cross-realm trusts this is a DoS attack.  However, when cross-realm
+   trusts are used it is possible to redirect a client to use a comprom-
+   ised realm.
+
+   This is not an exploit of the Kerberos protocol but of the Kerberos
+   trust model.  The same can be done to any application that must
+   resolve the hostname in order to determine which domain a non-FQDN
+   belongs to.
+
+   Implementations SHOULD provide a way of specifying this information
+   locally without the use of DNS.  However, to make this feature
+   worthwhile a lack of any configuration information on a client should
+
+
+
+Hornstein, Altman                                               [Page 5]
+
+RFC DRAFT                                              February 28, 2001
+
+
+   be interpretted as permission to use DNS.
+
+Expiration
+
+   This Internet-Draft expires on August 28, 2001.
+
+References
+
+
+   [RFC1510]
+        The Kerberos Network Authentication System; Kohl, Newman; Sep-
+        tember 1993.
+
+   [RFC1035]
+        Domain Names - Implementation and Specification; Mockapetris;
+        November 1987
+
+   [RFC2782]
+        A DNS RR for specifying the location of services (DNS SRV); Gul-
+        brandsen, Vixie; Feburary 2000
+
+   [KERB-CHG]
+        Kerberos Change Password Protocol; Horowitz;
+        ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
+        password-02.txt
+
+Authors' Addresses
+
+   Ken Hornstein
+   US Naval Research Laboratory
+   Bldg A-49, Room 2
+   4555 Overlook Avenue
+   Washington DC  20375 USA
+
+   Phone: +1 (202) 404-4765
+   EMail: kenh@cmf.nrl.navy.mil
+
+   Jeffrey Altman
+   The Kermit Project
+   Columbia University
+   612 West 115th Street #716
+   New York NY 10025-7799 USA
+
+   Phone: +1 (212) 854-1344
+   EMail: jaltman@columbia.edu
+
+
+
+
+
+
+Hornstein, Altman                                               [Page 6]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt
new file mode 100644
index 00000000000..66e5521ed58
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt
@@ -0,0 +1,505 @@
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: February 8, 2005                          Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                         August 10, 2004
+
+
+                        OCSP Support for PKINIT
+                    draft-ietf-krb-wg-ocsp-for-pkinit-00
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on February 8, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   OCSP responses.  These responses are used to verify the validity of
+   the certificates used in PKINIT - the Kerberos Version 5 extension
+   that provides for the use of public key cryptography.
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 1]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 4
+   3.   Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
+   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
+   6.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+        Intellectual Property and Copyright Statements . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 2]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of KDC certificates in order to avoid transmission of large
+   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
+   constrained networks.
+
+   This document defines a pre-authentication type [CLARIFICATIONS],
+   where the client and the KDC MAY piggyback OCSP responses for
+   certificates used in authentication exchanges, as defined in
+   [PKINIT].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 3]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 4]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              16
+
+   The corresponding pre-authentication field contains OCSP data as
+   follows:
+
+          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
+
+          OcspResponse ::= OCTET STRING
+                         -- contains a complete OCSP response,
+                         -- defined in [RFC2560]
+
+   The client MAY send OCSP responses for certificates used in
+   PA-PK-AS-REQ via a PA-PK-OCSP-RESPONSE.
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
+   PA-PK-OCSP-RESPONSE in response.  The client can request a
+   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers MAY need to be done.
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 5]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, and MUST be used in conjunction with
+   PKINIT.
+
+   There is a downgrade attack against clients which want OCSP responses
+   from the KDC for the KDC's certificates.  The clients, however, can
+   treat the absence of valid OCSP responses as an error, based on their
+   local configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 6]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+5.  IANA Considerations
+
+   This document defines a new pre-authentication type for use with
+   PKINIT to encode OCSP responses.  The official value for this padata
+   identifier need to be acquired from IANA.
+
+6  References
+
+   [CLARIFICATIONS]
+              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", 
+              draft-ietf-krb-wg-kerberos-clarifications, Work in 
+              progress.
+
+   [PKINIT]   Tung, B. and B. Neuman, "Public Key Cryptography for
+              Initial Authentication in Kerberos", 
+              draft-ietf-cat-kerberos-pk-init, Work in progress.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 7]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 8]
+
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   This document was based on conversations among the authors, Jeffrey 
+   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 
+   working group.
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 9]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-01.txt
new file mode 100644
index 00000000000..a4927feee70
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-01.txt
@@ -0,0 +1,566 @@
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: February 8, 2005                          Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                         August 10, 2004
+
+
+
+                        OCSP Support for PKINIT
+                   draft-ietf-krb-wg-ocsp-for-pkinit-01
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on February 8, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+   This document defines a mechanism to enable in-band transmission of
+   OCSP responses.  These responses are used to verify the validity of
+   the certificates used in PKINIT - the Kerberos Version 5 extension
+   that provides for the use of public key cryptography.
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 1]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+Table of Contents
+
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 4
+   3.   Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
+   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
+   6.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+        Intellectual Property and Copyright Statements . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 2]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+1.  Introduction
+
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of KDC certificates in order to avoid transmission of large
+   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
+   constrained networks.
+
+
+   This document defines a pre-authentication type [CLARIFICATIONS],
+   where the client and the KDC MAY piggyback OCSP responses for
+   certificates used in authentication exchanges, as defined in
+   [PKINIT].
+
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 3]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 4]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+3.  Message Definition
+
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+
+              PA-PK-OCSP-RESPONSE              16
+
+
+   The corresponding pre-authentication field contains OCSP data as
+   follows:
+
+
+          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
+
+
+          OcspResponse ::= OCTET STRING
+                         -- contains a complete OCSP response,
+                         -- defined in [RFC2560]
+
+
+   The client MAY send OCSP responses for certificates used in
+   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
+
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
+   PA-PK-OCSP-RESPONSE in response.  The client can request a
+   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
+
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [PKINIT].
+
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers MAY need to be done.
+
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 5]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+4.  Security Considerations
+
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, and MUST be used in conjunction with
+   PKINIT.
+
+
+   There is a downgrade attack against clients which want OCSP responses
+   from the KDC for the KDC's certificates.  The clients, however, can
+   treat the absence of valid OCSP responses as an error, based on their
+   local configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 6]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+5.  IANA Considerations
+
+
+   This document defines a new pre-authentication type for use with
+   PKINIT to encode OCSP responses.  The official value for this padata
+   identifier need to be acquired from IANA.
+
+
+6  References
+
+
+   [CLARIFICATIONS]
+              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", 
+              draft-ietf-krb-wg-kerberos-clarifications, Work in 
+              progress.
+
+
+   [PKINIT]   Tung, B. and B. Neuman, "Public Key Cryptography for
+              Initial Authentication in Kerberos", 
+              draft-ietf-cat-kerberos-pk-init, Work in progress.
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+
+
+Authors' Addresses
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+
+   EMail: lzhu@microsoft.com
+
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 7]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 8]
+Internet-Draft          OCSP Support for PKINIT              August 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   This document was based on conversations among the authors, Jeffrey 
+   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 
+   working group.
+
+
+
+
+
+Zhu, et al.             Expires February 8, 2005                [Page 9]
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt
new file mode 100644
index 00000000000..55cdf4c7674
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt
@@ -0,0 +1,562 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: May 21, 2005                              Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                       November 20, 2004
+
+
+                        OCSP Support for PKINIT
+                 draft-ietf-krb-wg-ocsp-for-pkinit-02
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on May 21, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   OCSP responses.  These responses are used to verify the validity of
+   the certificates used in PKINIT - the Kerberos Version 5 extension
+   that provides for the use of public key cryptography.
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 1]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
+   3.   Message Definition . . . . . . . . . . . . . . . . . . . . .   5
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
+   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
+   6.   Acknowledgement  . . . . . . . . . . . . . . . . . . . . . .   8
+   7.   References . . . . . . . . . . . . . . . . . . . . . . . . .   8
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   8
+        Intellectual Property and Copyright Statements . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 2]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of KDC certificates in order to avoid transmission of large
+   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
+   constrained networks [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [CLARIFICATIONS],
+   where the client and the KDC MAY piggyback OCSP responses for
+   certificates used in authentication exchanges, as defined in
+   [PKINIT].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 3]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 4]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              16
+
+   The corresponding pre-authentication field contains OCSP data as
+   follows:
+
+          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
+
+          OcspResponse ::= OCTET STRING
+                         -- contains a complete OCSP response,
+                         -- defined in [RFC2560]
+
+   The client MAY send OCSP responses for certificates used in
+   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
+   PA-PK-OCSP-RESPONSE in response.  The client can request a
+   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [PKINIT].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers MAY need to be done.
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 5]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, and MUST be used in conjunction with
+   PKINIT.
+
+   There is a downgrade attack against clients which want OCSP responses
+   from the KDC for the KDC's certificates.  The clients, however, can
+   treat the absence of valid OCSP responses as an error, based on their
+   local configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 6]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+5.  IANA Considerations
+
+   This document defines a new pre-authentication type for use with
+   PKINIT to encode OCSP responses.  The official value for this padata
+   identifier need to be acquired from IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 7]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+6.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
+   working group.
+
+7  References
+
+   [CLARIFICATIONS]
+              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", 
+              draft-ietf-krb-wg-kerberos-clarifications, Work in 
+              progress.
+
+   [OCSP-PROFILE]
+              Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
+              High Volume Environments", 
+              draft-ietf-pkix-lightweight-ocsp-profile, Work in
+              progress.
+
+   [PKINIT]   Tung, B., Neuman, B. and S. Medvinsky, "Public Key
+              Cryptography for Initial Authentication in Kerberos",
+              draft-ietf-cat-kerberos-pk-init, Work in progress.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 8]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                  [Page 9]
+
+Internet-Draft          OCSP Support for PKINIT            November 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires May 21, 2005                 [Page 10]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt
new file mode 100644
index 00000000000..319f161599a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt
@@ -0,0 +1,394 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: August 4, 2005                            Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                        January 31, 2005
+
+
+                        OCSP Support for PKINIT
+                   draft-ietf-krb-wg-ocsp-for-pkinit-04
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on August 4, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   Online Certificate Status Protocol (OCSP) responses in the Kerberos
+   network authentication protocol.  These responses are used to verify
+   the validity of the certificates used in PKINIT - the Kerberos
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 1]
+
+Internet-Draft           OCSP Support for PKINIT            January 2005
+
+
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
+     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
+       Intellectual Property and Copyright Statements . . . . . . . .  7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 2]
+
+Internet-Draft           OCSP Support for PKINIT            January 2005
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of the certificates for Kerberos Key Distribution Center
+   (KDC) in order to avoid transmission of large Certificate Revocation
+   Lists (CRLs) and therefore save bandwidth on constrained networks
+   [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [CLARIFICATIONS],
+   where the client and the KDC MAY piggyback OCSP responses for
+   certificates used in authentication exchanges, as defined in
+   [PKINIT].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+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 [RFC2119].
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              16
+
+   The corresponding padata-value field [CLARIFICATIONS] contains the
+   DER [X60] encoding of the following ASN.1 type:
+
+          PKOcspData ::= SEQUENCE OF OcspResponse
+
+          OcspResponse ::= OCTET STRING
+                         -- contains a complete OCSP response,
+                         -- defined in [RFC2560]
+
+   The client MAY send OCSP responses for certificates used in
+   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a
+   PA-PK-OCSP-RESPONSE containing OCSP responses for certificates used
+   in the KDC's PA-PK-AS-REP.  The client can request a
+   PA-PK-OCSP-RESPONSE by using a PKOcspData containing an empty
+   sequence.
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 3]
+
+Internet-Draft           OCSP Support for PKINIT            January 2005
+
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [PKINIT].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers may be needed
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, but is designed to be used in
+   conjunction with PKINIT.
+
+   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
+   data and PKINIT pre-authentication data other than a given OCSP
+   response corresponding to a certificate used in a PKINIT
+   pre-authentication data element.  Attacks involving removal or
+   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
+   are, at worst, downgrade attacks, where a PKINIT client or KDC would
+   proceed without use of CRLs or OCSP for certificate validation, or
+   denial of service attacks, where a PKINIT client or KDC that cannot
+   validate the other's certificate without an accompanying OCSP
+   response might reject the AS exchange or where they might have to
+   download very large CRLs in order to continue.  Kerberos V does not
+   protect against denial-of-service attacks, therefore the
+   denial-of-service aspect of these attacks are acceptable.
+
+   If a PKINIT client or KDC cannot validate certificates without the
+   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
+   exchange, possibly according to local configuration.
+
+
+
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 4]
+
+Internet-Draft           OCSP Support for PKINIT            January 2005
+
+
+5.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+6.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
+   working group.
+
+7.  References
+
+7.1  Normative References
+
+   [CLARIFICATIONS]
+              RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+
+   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              cat-kerberos-pk-init.  Work in Progress. 
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
+              Rules (BER), Canonical Encoding Rules (CER) and 
+              Distinguished Encoding Rules (DER), ITU-T Recommendation 
+              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
+
+7.2  Informative References
+
+   [OCSP-PROFILE]
+              RFC-Editor: To be replaced by RFC number for draft-deacon-
+              lightweight-ocsp-profile.  Work in Progress.  
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 5]
+
+Internet-Draft           OCSP Support for PKINIT            January 2005
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 6]
+
+Internet-Draft           OCSP Support for PKINIT            January 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.              Expires August 4, 2005                 [Page 7]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-05.txt
new file mode 100644
index 00000000000..e777e327291
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-05.txt
@@ -0,0 +1,399 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: November 21, 2005                         Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                            May 20, 2005
+
+
+                        OCSP Support for PKINIT
+                   draft-ietf-krb-wg-ocsp-for-pkinit-05
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667. 
+   
+   By submitting this Internet-Draft, each author represents
+   that any applicable patent or other IPR claims of which he
+   or she is aware have been or will be disclosed, and any of
+   which he or she becomes aware will be disclosed, in
+   accordance with Section 6 of BCP 79.
+   
+   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 Internet-Draft will expire on November 21, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   Online Certificate Status Protocol (OCSP) responses in the Kerberos
+   network authentication protocol.  These responses are used to verify
+   the validity of the certificates used in PKINIT - the Kerberos
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 1]
+
+Internet-Draft           OCSP Support for PKINIT                May 2005
+
+
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
+     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
+       Intellectual Property and Copyright Statements . . . . . . . .  7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 2]
+
+Internet-Draft           OCSP Support for PKINIT                May 2005
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of the certificates for Kerberos Key Distribution Center
+   (KDC) in order to avoid transmission of large Certificate Revocation
+   Lists (CRLs) and therefore save bandwidth on constrained networks
+   [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [CLARIFICATIONS],
+   where the client and the KDC MAY piggyback OCSP responses for
+   certificates used in authentication exchanges, as defined in
+   [PKINIT].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+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 [RFC2119].
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              18
+
+   The corresponding padata-value field [CLARIFICATIONS] contains the
+   DER [X60] encoding of the following ASN.1 type:
+
+          PKOcspData ::= SEQUENCE OF OcspResponse
+                         -- If more than one OcspResponse is
+                         -- included, the first OcspResponse
+                         -- MUST contain the OCSP response
+                         -- for the signer's certificate.
+
+          OcspResponse ::= OCTET STRING
+                         -- Contains a complete OCSP response,
+                         -- as defined in [RFC2560].
+
+   The client MAY send OCSP responses for certificates used in PA-PK-AS-
+   REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 3]
+
+Internet-Draft           OCSP Support for PKINIT                May 2005
+
+
+   OCSP-RESPONSE containing OCSP responses for certificates used in the
+   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
+   using a PKOcspData containing an empty sequence.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
+   PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [PKINIT].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers may be needed
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, but is designed to be used in
+   conjunction with PKINIT.
+
+   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
+   data and PKINIT pre-authentication data other than a given OCSP
+   response corresponding to a certificate used in a PKINIT pre-
+   authentication data element.  Attacks involving removal or
+   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
+   are, at worst, downgrade attacks, where a PKINIT client or KDC would
+   proceed without use of CRLs or OCSP for certificate validation, or
+   denial of service attacks, where a PKINIT client or KDC that cannot
+   validate the other's certificate without an accompanying OCSP
+   response might reject the AS exchange or where they might have to
+   download very large CRLs in order to continue.  Kerberos V does not
+   protect against denial-of-service attacks, therefore the denial-of-
+   service aspect of these attacks are acceptable.
+
+   If a PKINIT client or KDC cannot validate certificates without the
+   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 4]
+
+Internet-Draft           OCSP Support for PKINIT                May 2005
+
+
+   exchange, possibly according to local configuration.
+
+5.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+6.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
+   working group.
+
+7.  References
+
+7.1  Normative References
+
+   [CLARIFICATIONS]
+              RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+
+   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              cat-kerberos-pk-init.  Work in Progress. 
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
+              Rules (BER), Canonical Encoding Rules (CER) and 
+              Distinguished Encoding Rules (DER), ITU-T Recommendation 
+              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
+
+7.2  Informative References
+
+   [OCSP-PROFILE]
+              RFC-Editor: To be replaced by RFC number for draft-deacon-
+              lightweight-ocsp-profile.  Work in Progress.  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 5]
+
+Internet-Draft           OCSP Support for PKINIT                May 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 6]
+
+Internet-Draft           OCSP Support for PKINIT                May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.             Expires November 21, 2005               [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
new file mode 100644
index 00000000000..f6679d0cd76
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
@@ -0,0 +1,397 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: January 20, 2006                          Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                           July 19, 2005
+
+
+                        OCSP Support for PKINIT
+                  draft-ietf-krb-wg-ocsp-for-pkinit-06
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 20, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   Online Certificate Status Protocol (OCSP) responses in the Kerberos
+   network authentication protocol.  These responses are used to verify
+   the validity of the certificates used in PKINIT - the Kerberos
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 1]
+
+Internet-Draft           OCSP Support for PKINIT               July 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
+     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
+       Intellectual Property and Copyright Statements . . . . . . . .  7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 2]
+
+Internet-Draft           OCSP Support for PKINIT               July 2005
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well-bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of the certificates for Kerberos Key Distribution Center
+   (KDC) in order to avoid transmission of large Certificate Revocation
+   Lists (CRLs) and therefore save bandwidth on constrained networks
+   [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [RFC4120], where the
+   client and the KDC MAY piggyback OCSP responses for certificates used
+   in authentication exchanges, as defined in [PKINIT].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+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 [RFC2119].
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              18
+
+   The corresponding padata-value field [RFC4120] contains the DER [X60]
+   encoding of the following ASN.1 type:
+
+          PKOcspData ::= SEQUENCE OF OcspResponse
+                         -- If more than one OcspResponse is
+                         -- included, the first OcspResponse
+                         -- MUST contain the OCSP response
+                         -- for the signer's certificate.
+                         -- The signer refers to the client for
+                         -- AS-REQ, and the KDC for the AS-REP,
+                         -- respectively.
+
+          OcspResponse ::= OCTET STRING
+                         -- Contains a complete OCSP response,
+                         -- as defined in [RFC2560].
+
+   The client MAY send OCSP responses for certificates used in PA-PK-AS-
+   REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 3]
+
+Internet-Draft           OCSP Support for PKINIT               July 2005
+
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
+   OCSP-RESPONSE containing OCSP responses for certificates used in the
+   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
+   using a PKOcspData containing an empty sequence.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
+   PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [PKINIT].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers may be needed
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform their own revocation status verification independently.
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, but is designed to be used in
+   conjunction with PKINIT.
+
+   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
+   data and PKINIT pre-authentication data other than a given OCSP
+   response corresponding to a certificate used in a PKINIT pre-
+   authentication data element.  Attacks involving removal or
+   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
+   are, at worst, downgrade attacks, where a PKINIT client or KDC would
+   proceed without use of CRLs or OCSP for certificate validation, or
+   denial of service attacks, where a PKINIT client or KDC that cannot
+   validate the other's certificate without an accompanying OCSP
+   response might reject the AS exchange or where they might have to
+   download very large CRLs in order to continue.  Kerberos V does not
+   protect against denial-of-service attacks, therefore the denial-of-
+   service aspect of these attacks are acceptable.
+
+   If a PKINIT client or KDC cannot validate certificates without the
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 4]
+
+Internet-Draft           OCSP Support for PKINIT               July 2005
+
+
+   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
+   exchange, possibly according to local configuration.
+
+5.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+6.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
+   working group.
+
+7.  References
+
+7.1  Normative References
+
+   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              cat-kerberos-pk-init.  Work in Progress. 
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
+              Rules (BER), Canonical Encoding Rules (CER) and 
+              Distinguished Encoding Rules (DER), ITU-T Recommendation 
+              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
+
+7.2  Informative References
+
+   [OCSP-PROFILE]
+              RFC-Editor: To be replaced by RFC number for draft-deacon-
+              lightweight-ocsp-profile.  Work in Progress.  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 5]
+
+Internet-Draft           OCSP Support for PKINIT               July 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 6]
+
+Internet-Draft           OCSP Support for PKINIT               July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt
new file mode 100644
index 00000000000..c40b8345958
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt
@@ -0,0 +1,1848 @@
+

+

+

+Network Working Group                                        G. Richards

+Internet-Draft                         RSA, The Security Division of EMC

+Intended status: Standards Track                           July 14, 2008

+Expires: January 15, 2009

+

+

+                         OTP Pre-authentication

+                    draft-ietf-krb-wg-otp-preauth-05

+

+Status of this Memo

+

+   By submitting this Internet-Draft, each author represents that any

+   applicable patent or other IPR claims of which he or she is aware

+   have been or will be disclosed, and any of which he or she becomes

+   aware will be disclosed, in accordance with Section 6 of BCP 79.

+

+   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 Internet-Draft will expire on January 15, 2009.

+

+Abstract

+

+   The Kerberos protocol provides a framework authenticating a client

+   using the exchange of pre-authentication data.  This document

+   describes the use of this framework to carry out One Time Password

+   (OTP) authentication.

+

+

+

+

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009                [Page 1]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+Table of Contents

+

+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

+     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3

+     1.2.  Overall Design . . . . . . . . . . . . . . . . . . . . . .  3

+     1.3.  Conventions Used in this Document  . . . . . . . . . . . .  4

+   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  4

+     2.1.  OTP Mechanism Support  . . . . . . . . . . . . . . . . . .  4

+     2.2.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  4

+     2.3.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  5

+     2.4.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  6

+   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  6

+     3.1.  Initial Client Request . . . . . . . . . . . . . . . . . .  6

+     3.2.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  6

+     3.3.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7

+     3.4.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  9

+     3.5.  Confirming the Reply Key Change  . . . . . . . . . . . . . 10

+     3.6.  Reply Key Generation . . . . . . . . . . . . . . . . . . . 11

+   4.  OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 13

+     4.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 13

+     4.2.  PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 15

+     4.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 18

+     4.4.  PA-OTP-PIN-CHANGE  . . . . . . . . . . . . . . . . . . . . 19

+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19

+     6.1.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . . . 19

+     6.2.  Reflection . . . . . . . . . . . . . . . . . . . . . . . . 20

+     6.3.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 20

+     6.4.  Brute Force Attack . . . . . . . . . . . . . . . . . . . . 20

+     6.5.  FAST Facilities  . . . . . . . . . . . . . . . . . . . . . 20

+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21

+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21

+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21

+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21

+   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 22

+   Appendix B.  Examples of OTP Pre-Authentication Exchanges  . . . . 24

+     B.1.  Four Pass Authentication . . . . . . . . . . . . . . . . . 24

+     B.2.  Two Pass Authentication  . . . . . . . . . . . . . . . . . 27

+     B.3.  Pin Change . . . . . . . . . . . . . . . . . . . . . . . . 29

+     B.4.  Resynchronization  . . . . . . . . . . . . . . . . . . . . 30

+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32

+   Intellectual Property and Copyright Statements . . . . . . . . . . 33

+

+

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009                [Page 2]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+1.  Introduction

+

+1.1.  Scope

+

+   This document describes a FAST [ZhHa07] factor that allows One-Time

+   Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-

+   authentication in a manner that does not require use of the user's

+   Kerberos password.  The system is designed to work with different

+   types of OTP algorithms such as time-based OTPs [RFC2808], counter-

+   based tokens [RFC4226], challenge-response and [RFC2289] type

+   systems.  It is also designed to work with tokens that are

+   electronically connected to the user's computer via means such as a

+   USB interface.

+

+   This FAST factor provides the following facilities (as defined in

+   [ZhHa07]): client-authentication, replacing-reply-key and KDC-

+   authentication.  It does not provide the strengthening-reply-key

+   facility.

+

+   This proposal is partially based upon previous work on integrating

+   single-use authentication mechanisms into Kerberos [HoReNeZo04] and

+   allows for the use of the existing password-change extensions to

+   handle PIN change as described in [RFC3244].

+

+1.2.  Overall Design

+

+   This proposal supports 4-pass and 2-pass variants.  In the 4-pass

+   system, the client sends the KDC an initial AS-REQ and the KDC

+   responds with a KRB-ERROR containing padata that includes a random

+   nonce.  The client then encrypts the nonce and returns it along with

+   its own random value to the KDC in a second AS-REQ.  Finally, the KDC

+   returns the client's random value encrypted within the padata of the

+   AS-REP.  In the 2-pass variant, the client encrypts a timestamp

+   rather than a nonce from the KDC and the encrypted data is sent to

+   the KDC in the initial AS-REQ.  This variant can be used in cases

+   where the client can determine in advance that OTP pre-authentication

+   is supported by the KDC and which OTP key should be used.

+

+   In both systems, in order to create the message sent to the KDC, the

+   client must generate the OTP value and three keys: the standard Reply

+   Key, a key to encrypt the data sent to the KDC and a final key to

+   decrypt the KDC's reply.  In most cases, the OTP value will be used

+   in the key generation but in order to support algorithms where the

+   KDC cannot obtain the value (e.g.  [RFC2289]), the system also

+   supports the option of including the OTP value in the request along

+   with the encrypted nonce.  In addition, in order to support

+   situations where the KDC is unable to obtain the plaintext OTP value,

+   the system also supports the use of hashed OTP values in the key

+

+

+

+Richards                Expires January 15, 2009                [Page 3]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   derivation.

+

+   The message from the client to the KDC is sent within the encrypted

+   data provided by the FAST padata type of the AS-REQ.  The KDC then

+   obtains the OTP value, generates the same keys and verifies the pre-

+   authentication data by decrypting the nonce.  If the verification

+   succeeds then it confirms knowledge of the Reply Key by returning the

+   client's nonce encrypted under one of the generated keys within the

+   encrypted part of the FAST padata of the AS-REP.

+

+1.3.  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 [RFC2119].

+

+   This document assumes familiarity with the Kerberos preauthentication

+   framework [ZhHa07] and so freely uses terminology and notation from

+   this document.

+

+   The word padata is used as shorthand for pre-authentication data.

+

+

+2.  Usage Overview

+

+2.1.  OTP Mechanism Support

+

+   As described above, this document describes a generic system for

+   supporting different OTP mechanisms in Kerberos pre-authentication.

+   However, to ensure interoperability, all implementations of this

+   specification SHOULD provide a mechanism for OTP mechanism support to

+   be added or removed.

+

+2.2.  Pre-Authentication

+

+   The approach uses pre-authentication data in AS-REQ, AS-REP and KRB-

+   ERROR messages.

+

+   In the 4-pass system, the client begins by sending an initial AS-REQ

+   to the KDC that may contain pre-authentication data such as the

+   standard Kerberos password data.  The KDC will then determine, in an

+   implementation dependent fashion, whether OTP authentication is

+   required and if it is, it will respond with a KRB-ERROR message

+   containing a PA-OTP-CHALLENGE in the PA-DATA.

+

+   The PA-OTP-CHALLENGE will contain a KDC generated nonce, an

+   encryption type, an optional list of hash algorithm identifiers, an

+   optional iteration count and optional information on how the OTP

+

+

+

+Richards                Expires January 15, 2009                [Page 4]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   should be generated by the client.  The client will then generate the

+   OTP value, its own nonce and two keys: a Client Key to encrypt the

+   KDC's nonce and a Reply Key used to decrypt the KDC's reply.

+

+   As described in Section 3.6, these keys will be generated from the

+   Armor Key (defined in [ZhHa07]) and the OTP value unless the OTP

+   algorithm does not allow the KDC to obtain the OTP value.  If hash

+   algorithm identifiers were included in the PA-OTP-CHALLENGE then the

+   client will use the hash of the OTP value rather than the plaintext

+   value in the key generation.

+

+   The generated Client Key will be used to encrypt the nonce received

+   from the KDC using the specified encryption type.  The encrypted

+   value, a random nonce generated by the client along with optional

+   information on how the OTP was generated are then sent to the KDC in

+   a PA-OTP-REQUEST element encrypted within the armored-data of a PA-

+   FX-FAST-REQUEST PA-DATA element of a second AS-REQ.

+

+   In the 2-pass system, the client sends the PA-OTP-REQUEST in the

+   initial AS-REQ instead of sending it in response to a PA-OTP-

+   CHALLENGE returned by the KDC.  Since no challenge is received from

+   the KDC, the client includes an encrypted timestamp in the request

+   rather than the encrypted KDC nonce.

+

+   In both cases, on receipt of a PA-OTP-REQUEST, the KDC generate the

+   same keys as the client, and use the generated Client Key to verify

+   the pre-authentication by decrypting the encrypted data sent by the

+   client (either nonce or timestamp).  If the validation succeeds then

+   the KDC will authenticate itself to the client and confirm that the

+   Reply Key has been updated by encrypting the client's nonce under the

+   Reply Key and returning the encrypted value in the encData of a PA-

+   OTP-CONFIRM.  The PA-OTP-CONFIRM is encrypted within the armored-data

+   of a PA-FX-FAST-REPLY PA-DATA element of the AS-REP as described in

+   [ZhHa07].

+

+2.3.  PIN Change

+

+   If, following successful validation of a PA-OTP-REQUEST in a AS-REQ,

+   the KDC requires that the user changes their PIN then it will include

+   a PA-OTP-PIN-CHANGE element in the armored data of the PA-FX-FAST-

+   REPLY PA-DATA element of the AS-REP.  This data can be used to return

+   a new PIN to the user if the KDC has updated the PIN or to indicate

+   to the user that they must change their PIN.

+

+   In the latter case, it is recommended that user PIN change be handled

+   by a PIN change service supporting the ChangePasswdData in a AP-REQ

+   as described in [RFC3244].  If a user PIN for OTP is required to

+   change and such a service is used then the KDC MUST NOT return a TGT

+

+

+

+Richards                Expires January 15, 2009                [Page 5]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   when the user is authenticated using this PIN.  The KDC SHOULD return

+   a service ticket to the PIN change service when the existing PIN is

+   required to change, in order for the client to compute an AP-REQ

+   according to [RFC3244].  In order to complicate stealing service

+   tickets intended for the PIN change service (and the corresponding

+   session keys), the lifetime of the PIN-change service tickets should

+   be just long enough to complete the PIN change, regardless whether

+   the exiting PIN needs to be changed or not.  A 1-minute lifetime is

+   RECOMMENED.  This way the PIN change service can effectively force

+   the user to present the existing PIN in order to change to use a new

+   PIN.

+

+2.4.  Re-Synchronization

+

+   It is possible with time and event-based tokens that the OTP server

+   will lose synchronization with the current token state.  If, when

+   processing a PA-OTP-REQUEST, the pre-authentication validation fails

+   for this reason then the KDC SHALL return a KRB-ERROR message

+   containing a PA-OTP-CHALLENGE in the PA-DATA with the "nextOTP" flag

+   set.  If this flag is set then the client MUST re-try the

+   authentication using the OTP for the token "state" after that used in

+   the failed authentication attempt.

+

+

+3.  Pre-Authentication Protocol Details

+

+3.1.  Initial Client Request

+

+   In the 4-pass mode, the client begins by sending an initial AS-REQ

+   possibly containing other pre-authentication data.  If the KDC

+   determines that OTP-based pre-authentication is required and the

+   request does not contain a PA-OTP-REQUEST then it will respond as

+   described in Section 3.2.

+

+   If the client has all the necessary information, it MAY use the

+   2-pass system by constructing a PA-OTP-REQUEST as described in

+   Section 3.3 and including it in the initial request.

+

+3.2.  KDC Challenge

+

+   If the user is required to authenticate using an OTP then the KDC

+   SHALL respond to the initial AS-REQ with a KRB-ERROR containing:

+

+   o  An error code of KDC_ERR_PREAUTH_REQUIRED

+

+   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.

+

+   The PA-OTP-CHALLENGE SHALL contain a random nonce value to be

+

+

+

+Richards                Expires January 15, 2009                [Page 6]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   returned encrypted in the client response and the encryption type to

+   be used by the client.

+

+   If the OTP is to be generated using an server generated challenge

+   then the value of the challenge SHALL be included in the otp-

+   challenge field.  If the OTP is to be generated by combining the

+   challenge with the token's current state (e.g. time) then the

+   "combine" flag SHALL be set.

+

+   The KDC MAY use the otp-service to identify the service provided by

+   the KDC in order to assist the client in locating the OTP token to be

+   used.  For example, this field could be used when a client has

+   multiple OTP tokens from different servers to identify the KDC.

+   Similarly, if the KDC can determine which OTP token key is the be

+   used, then the otp-keyID field MAY be used to pass that value to the

+   client.

+

+   The otp-algID field MAY be used to identify the algorithm that should

+   be used in the OTP calculation.  For example, it could be used when a

+   user has been issued with multiple tokens of different types.

+

+   In order to support connected tokens that can generate OTP values of

+   varying length, the KDC MAY include the desired length of the OTP in

+   the otp-length field.

+

+   In order to support cases where the KDC cannot obtain plaintext

+   values for the OTPs, the challenge MAY also contain a sequence of one

+   way hash function algorithm identifiers and a minimum value of the

+   iteration count to be used by the client when hashing the OTP value.

+

+3.3.  Client Response

+

+   The client response SHALL be sent to the KDC as a PA-OTP-REQUEST

+   included within the enc-fast-req of a PA-FX-FAST-REQUEST encrypted

+   under the current Armor Key as described in [ZhHa07].

+

+   In order to generate its response, the client must generate an OTP

+   value.  The OTP value MUST be based on the parameters in the KDC

+   challenge if present and the response SHOULD include any information

+   on the generated OTP value reported by the OTP token

+

+   If the "nextOTP" flag is set in the PA-OTP-CHALLENGE, then the client

+   MUST generate the OTP value in the next token state that that used in

+   the previous PA-OTP-REQUEST.  The "nextOTP" flag must also be set in

+   the PA-OTP-REQUEST.

+

+   The otp-time and otp-counter fields MAY be used to return the time

+   and counter values used by the token.  The otp-format field MAY be

+

+

+

+Richards                Expires January 15, 2009                [Page 7]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   used to report the format of the generated OTP.  This field SHOULD be

+   used if a token can generate OTP values in multiple formats.  The

+   otp-algID field MAY be used by the client to report the algorithm

+   used in the OTP calculation and the otp-keyID MAY be used to report

+   the identifier of the OTP token key used.

+

+   If an otp-challenge is present in the PA-OTP-CHALLENGE then the OTP

+   value MUST be generated based on a challenge if the token is capable

+   of accepting a challenge.  The client MAY ignore the provided

+   challenge if and only if the token is not capable of including a

+   challenge in the OTP calculation.  If the "combine" flag is not set

+   in the PA-OTP-CHALLENGE then the OTP SHALL be calculated based only

+   the challenge and not the internal state (e.g. time or counter) of

+   the token.  If the "combine" flag is set then the OTP SHALL be

+   calculated using both the internal state and the provided challenge.

+   If the flag is set but otp-challenge is not present then the client

+   SHALL regard the request as invalid.

+

+   If the OTP value was generated by a challenge not sent by the KDC

+   then the challenge SHALL be included in the otp-challenge of the PA-

+   OTP-RESPONSE.  If the OTP was generated by combining a challenge

+   (either received from the KDC or generated by the client) with the

+   token state then the "combine" flag SHALL be set in the PA-OTP-

+   RESPONSE.

+

+   The client MUST derive the Client Key and Reply Key as described in

+   Section 3.6.  In order to support OTP algorithms where the KDC cannot

+   obtain the OTP value, the client MAY include the generated value in

+   the otp-value field of the response.  However, the client MUST NOT

+   include the OTP value in the response unless it is allowed by the

+   algorithm profile.  If it is included then the OTP value MUST NOT be

+   used in the key derivation.

+

+   If the client used hashed OTP values in the key derivation process

+   then it MUST include the hash algorithm and iteration count used in

+   the hashAlg and iterationCount fields of the PA-OTP-REQUEST.  These

+   fields MUST NOT be included if hashed OTP values were not used.  It

+   is RECOMMENDED that the iteration count used by the client be chosen

+   in such a way that it is computationally infeasible/unattractive for

+   an attacker to brute-force search for the given OTP within the

+   lifetime of that OTP.

+

+   If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE

+   that contained hash algorithm identifiers and the OTP value is to be

+   used in the key derivation then the client MUST use hashed OTP values

+   and MUST select the first algorithm from the list that it supports.

+   However, if the algorithm identifiers do not conform to local policy

+   restrictions then the authentication attempt MUST NOT proceed.  If

+

+

+

+Richards                Expires January 15, 2009                [Page 8]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   the iteration count specified in the PA-OTP-CHALLENGE does not

+   conform to local policy then the client MAY use a higher value but

+   MUST NOT use a lower value.  That is, the value in the KDC challenge

+   is a minimum value.

+

+   The generated Client Key is used by the client to encrypt data to be

+   included in the encData of the response to allow the KDC to

+   authenticate the user.  The key usage for this encryption is

+   KEY_USAGE_OTP_REQUEST.

+

+   o  If the response is being generated in response to a KDC challenge

+      then client encrypts a PA-OTP-ENC-REQUEST containing the value of

+      nonce from the corresponding challenge using the encryption type

+      specified in the challenge.

+

+   o  If the response is not in response to a KDC challenge then the

+      client encrypts a PA-ENC-TS-ENC containing the current time as in

+      the encrypted timestamp pre-authentication mechanism [RFC4120].

+

+   If the client is working in 2-pass mode and so is not responding to

+   an initial KDC challenge then the values of the iteration count, hash

+   algorithms and encryption type cannot be obtained from that

+   challenge.  The client SHOULD use any values obtained from a previous

+   PA-OTP-CHALLENGE or, if no values are available, it MAY use initial

+   configured values.

+

+   Finally, the client generates a random value to include in the nonce

+   of the response.  This value will then be returned encrypted by the

+   KDC.

+

+3.4.  Verifying the pre-auth Data

+

+   The KDC validates the pre-authentication data by generating the same

+   keys as the client and using the generated Client Key to decrypt the

+   value of encData from the PA-OTP-REQUEST.

+

+   If the otp-value field is included in the PA-OTP-REQUEST then the KDC

+   MUST use that value in the key generation.  Otherwise, the KDC will

+   need to generate or obtain the value.

+

+   If the otp-challenge field is present, then the OTP was calculated

+   using that challenge.  If the "combine" flag is also set, then the

+   OTP was calculated using the challenge and the token's current state.

+

+   It is RECOMMENDED that the KDC acts upon the values of otp-time, otp-

+   counter, otp-format, otp-algID and otp-keyID if they are present in

+   the PA-OTP-REQUEST.  If the KDC receives a request containing these

+   values but cannot act upon theme then they MAY be ignored.

+

+

+

+Richards                Expires January 15, 2009                [Page 9]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   The KDC generates the Client Key and Reply Key as described in

+   Section 3.6 from the OTP value using the hash algorithm and iteration

+   count if present in the PA-OTP-REQUEST.  However, the client

+   authentication MUST fail if the KDC requires hashed OTP values and

+   the hashAlg field was not present in the PA-OTP-REQUEST, if the hash

+   algorithm identifier or the value of iterationCount included in the

+   PA-OTP-REQUEST do not conform to local KDC policy or if the value of

+   the iterationCount is less than that specified in the PA-OTP-

+   CHALLENGE.

+

+   The generated Client Key is then used to decrypt the encData from the

+   PA-OTP-REQUEST.  If the client response was sent as a result of a PA-

+   OTP-CHALLENGE then decrypted data will be a PA-OTP-ENC-REQUEST and

+   the client authentication MUST fail if the nonce value from the PA-

+   OTP-ENC-REQUEST is not the same as the nonce value sent in the PA-

+   OTP-CHALLENGE.  If the response was not sent as a result of a PA-OTP-

+   CHALLENGE then the decrypted value will be a PA-ENC-TS-ENC and the

+   authentication process will be the same as with standard encrypted

+   timestamp pre-authentication [RFC4120]

+

+   The authentication MUST fail if the encryption type used by the

+   client in the encData does not conform to policy.

+

+   If authentication fails due to the hash algorithm, iteration count or

+   encryption type used by the client then the KDC SHOULD return a PA-

+   OTP-CHALLENGE with the required values in the error response.  If the

+   authentication fails due to the token state on the server no longer

+   being synchronized with the token used then the KDC SHALL return a

+   PA-OTP-CHALLENGE with the "nextOTP" flag set as described in

+   Section 2.4.

+

+   If during the authentication process, the KDC determines that the

+   user's PIN has expired then it MAY include a PA-OTP-PIN-CHANGE in the

+   response as described in Section 2.3

+

+3.5.  Confirming the Reply Key Change

+

+   If the pre-authentication data was successfully verified, then, in

+   order to support mutual authentication, the KDC SHALL respond to the

+   client's PA-OTP-REQUEST by including in the AS-REP, a PA-OTP-CONFIRM

+   containing the client's nonce from PA-OTP-REQUEST encrypted under the

+   generated Reply Key.

+

+   The nonce SHALL be returned within a PA-OTP-ENC-CONFIRM encrypted

+   within the encData of the PA-OTP-CONFIRM.  The key usage SHALL be

+   KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as

+   used by the client in the encData of the PA-OTP-REQUEST.

+

+

+

+

+Richards                Expires January 15, 2009               [Page 10]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   The PA-OTP-CONFIRM SHALL be sent to the client within the enc-fast-

+   rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key.

+

+   The client then uses its generated Reply Key to decrypt the PA-OTP-

+   ENC-CONFIRM from the encData of the PA-OTP-CONFIRM.  The client MUST

+   fail the authentication process if the nonce value in the PA-OTP-ENC-

+   CONFIRM is not the same as the nonce value sent in the PA-OTP-

+   REQUEST.

+

+3.6.  Reply Key Generation

+

+   In order to authenticate the user, the client and KDC need to

+   generate two encryption keys:

+

+   o  The Client Key to be used by the client to encrypt and by the KDC

+      to decrypt the encData in the PA-OTP-REQUEST.

+

+   o  The Reply Key to be used in the standard manner by the KDC to

+      encrypt data in the AS-REP but also to be used by the KDC to

+      encrypt and by the client to decrypt the encData value in the PA-

+      OTP-CONFIRM.

+

+   The method used to generate the three keys will depend on the OTP

+   algorithm.

+

+   o  If the OTP value is included in the otp-value of the PA-OTP-

+      REQUEST then all three keys SHALL be the same as the Armor Key

+      (defined in [ZhHa07]).

+

+   o  If the OTP value is not included in the otp-value of the PA-OTP-

+      REQUEST then the three keys SHALL be derived from the Armor Key

+      and the OTP value as described below.

+

+   If the OTP value is not included in the PA-OTP-REQUEST, then the

+   Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from

+   [ZhHa07]

+

+             Client Key = KRB_FX_CF2(K1, K2, O1, O2)

+             Reply Key = KRB_FX_CF2(K1, K2, O3, O4)

+

+   The first input keys, K1, shall be the Armor Key. The second input

+   key, K2, shall be derived from the OTP value using string-to-key

+   (defined in [RFC3961]).

+

+   The octet string parameters, O1, O2, O3 and O4, shall be the ASCII

+   string "Combine1", "Combine2", "Combine3" and "Combine4" as shown

+   below:

+

+

+

+

+Richards                Expires January 15, 2009               [Page 11]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31}

+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32}

+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x33}

+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x34}

+

+   If the hash of the OTP value is to be used then K2 SHALL be derived

+   as follows:

+

+   o  An initial hash value, H, is generated:

+

+             H = hash(sname|nonce|OTP)

+

+      Where:

+      *  "|" denotes concatenation

+      *  hash is the hash algorithm selected by the client.

+      *  sname is the UTF-8 encoding of the KDC's fully qualified domain

+         name.  If the domain name is an Internationalized Domain Name

+         then the value shall be the output of nameprep [RFC3491] as

+         described in [RFC3490]

+      *  nonce is the random nonce value generated by the client to be

+         included in the PA-OTP-REQUEST.

+      *  OTP is the OTP value.

+

+   o  The initial hash value is then hashed iterationCount-1 times to

+      produce a final hash value, H'.  (Where iterationCount is the

+      value from the PA-OTP-REQUEST.)

+

+             H' = hash(hash(...(iterationCount-1 times)...(H)))

+

+   o  The value of K2 is then derived from the base64 [RFC2045] encoding

+      of this final hash value.

+

+             K2 = string-to-key(Base64(H')||"Krb-preAuth")

+

+   If the OTP value is binary and the hash value is not used, then K2

+   SHALL be derived from the base64 encoding of the OTP value.

+

+             K2 = string-to-key(Base64(OTP)||"Krb-preAuth")

+

+   If the OTP value is not binary and the hash value is not used, then

+   K2 SHALL be derived by running the OTP value once through string-to-

+   key.

+

+             K2 = string-to-key(OTP||"Krb-preAuth")

+

+   The salt and any additional parameters for string-to-key will be

+   derived as described in section 3.1.3 of [RFC4120] using preauth data

+   or default values defined for the particular enctype.  The symbol

+

+

+

+Richards                Expires January 15, 2009               [Page 12]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   "||" denotes string concatenation.

+

+

+4.  OTP Kerberos Message Types

+

+4.1.  PA-OTP-CHALLENGE

+

+   The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in

+   the PA-DATA of a KRB-ERROR when pre-authentication using an OTP value

+   is required.  The corresponding padata-value field contains the DER

+   encoding of a PA-OTP-CHALLENGE containing a server generated nonce

+   and information for the client on how to generate the OTP.

+

+             PA_OTP_CHALLENGE     << TBA >>

+

+             PA-OTP-CHALLENGE ::= SEQUENCE {

+               flags              OTPFlags,

+               nonce              UInt32,

+               etype              Int32,

+               supportedHashAlg   SEQUENCE OF AlgorithmIdentifier

+                                                  OPTIONAL,

+               iterationCount     INTEGER         OPTIONAL,

+               otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,

+               otp-length     [0] Int32           OPTIONAL,

+               otp-service        UTF8String      OPTIONAL,

+               otp-keyID      [1] OCTET STRING    OPTIONAL,

+               otp-algID          AnyURI          OPTIONAL,

+               ...

+             }

+

+             OTPFlags ::= KerberosFlags

+             -- nextOTP (0)

+             -- combine (1)

+

+   flags

+      If the "nextOTP" flag is set then the OTP SHALL be based on the

+      next token "state" rather than the current one.  As an example,

+      for a time-based token, this means the next time slot and for an

+      event-based token, this could mean the next counter value.

+

+      The "combine flag controls how the challenge included in otp-

+      challenge shall be used.  If the flag is set then OTP SHALL be

+      calculated using the challenge from otp-challenge and the internal

+      token state (e.g. time or counter).  If the "combine" flag is not

+      set then the OTP SHALL be calculated based only on the challenge.

+      If the flag is set and otp-challenge is not present then the

+      request SHALL be regarded as invalid.

+

+

+

+

+Richards                Expires January 15, 2009               [Page 13]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   nonce

+      A KDC-supplied nonce value to be encrypted by the client in the

+      PA-OTP-REQUEST.

+

+   etype

+      The encryption type to be used by the client to encrypt the nonce

+      in the PA-OTP-REQUEST.

+

+   supportedHashAlg

+      If present then a hash of the OTP value MUST be used in the key

+      derivation rather than the plain text value.  Each

+      AlgorithmIdentifier identifies a hash algorithm that is supported

+      by the KDC in decreasing order of preference.  The client MUST

+      select the first algorithm from the list that it supports.

+      Support for SHA1 by both the client and KDC is REQUIRED.  The

+      AlgorithmIdentifer selected by the client MUST be placed in the

+      hashAlg element of the PA-OTP-REQUEST.

+

+   iterationCount

+      The minimum value of the iteration count to be used by the client

+      when hashing the OTP value.  This value MUST be present if and

+      only if supportedHashAlg is present.  If the value of this element

+      does not conform to local policy on the client then the client MAY

+      use a larger value but MUST NOT use a lower value.  The value of

+      the iteration count used by the client MUST be returned in the PA-

+      OTP-REQUEST sent to the KDC.

+

+   otp-challenge

+      The otp-challenge is used by the KDC to send a challenge value for

+      use in the OTP calculation.  The challenge is an optional octet

+      string that SHOULD be uniquely generated for each request it is

+      present in, and SHOULD be eight octets or longer when present.

+      When the challenge is not present, the OTP will be calculated on

+      the current token state only.  The client MAY ignore a provided

+      challenge if and only if the OTP token the client is interacting

+      with is not capable of including a challenge in the OTP

+      calculation.  In this case, KDC policies will determine whether to

+      accept a provided OTP value or not.

+

+   otp-length

+      Use of this field is OPTIONAL, but MAY be used by the KDC to

+      specify the desired length of the generated OTP in octets.  For

+      example, this field could be used when a token is capable of

+      producing OTP values of different lengths.

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 14]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   otp-service

+      Use of this field is OPTIONAL, but MAY be used by the KDC to

+      identify the appropriate OTP tokens to be used.  For example, this

+      field could be used when a client has multiple OTP tokens from

+      different servers.

+

+   otp-keyID

+      Use of this field is OPTIONAL, but MAY be used by the KDC to

+      identify which token key should be used for the authentication.

+      For example, this field could be used when a user has been issued

+      multiple token keys by the same server.

+

+   otp-algID

+      use of this field is OPTIONAL, but MAY be used by the KDC to

+      identify the algorithm to use when generating the OTP.

+

+4.2.  PA-OTP-REQUEST

+

+   The padata-type PA_OTP_REQUEST is sent by the client to the KDC in

+   the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the

+   PA-DATA of an AS-REQ.  The corresponding padata-value field contains

+   the DER encoding of a PA-OTP-REQUEST.

+

+   The message contains pre-authentication data encrypted by the client

+   using the generated Client Key and optional information on how the

+   OTP was generated.  It may also, optionally, contain the generated

+   OTP value.

+

+             PA_OTP_REQUEST     << TBA >>

+

+             PA-OTP-REQUEST ::= SEQUENCE {

+               flags             OTPFlags,

+               nonce             UInt32,

+               encData           EncryptedData,

+                                 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC

+                                 -- Key usage of KEY_USAGE_OTP_REQUEST

+               hashAlg           AlgorithmIdentifier OPTIONAL,

+               iterationCount    INTEGER         OPTIONAL,

+               otp-value         OCTET STRING    OPTIONAL,

+               otp-challenge [0] OCTET STRING    OPTIONAL,

+               otp-time          KerberosTime    OPTIONAL,

+               otp-counter   [1] OCTET STRING    OPTIONAL,

+               otp-format    [2] OTPFormat       OPTIONAL,

+               otp-keyID     [3] OCTET STRING    OPTIONAL,

+               otp-algID         AnyURI          OPTIONAL,

+               ...

+             }

+

+

+

+

+Richards                Expires January 15, 2009               [Page 15]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+             KEY_USAGE_OTP_REQUEST  << TBA >>

+

+

+             PA-OTP-ENC-REQUEST ::= SEQUENCE {

+               nonce     UInt32,

+               ...

+             }

+

+

+             OTPFormat ::= INTEGER {

+               decimal(0),

+               hexadecimal(1),

+               alphanumeric(2),

+               binary(3)

+             }

+

+   flags

+      If the "nextOTP" flag is set then the OTP was calculated based on

+      the next token "state" rather than the current one.  This flag

+      MUST be set if and only if it was set in a corresponding PA-OTP-

+      CHALLENGE.

+

+      If the "combine" flag is set then the OTP was calculated based on

+      a challenge and the token state.

+

+   nonce

+      A random nonce value generated by the client to be returned

+      encrypted by the KDC in the PA-OTP-CONFIRM.

+

+   encData

+      This field contains the pre-authentication data encrypted under

+      the Client Key with a key usage of KEY_USAGE_OTP_REQUEST.  If the

+      PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE then this

+      MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-

+      CHALLENGE.  If no challenge was received then this MUST contain a

+      PA-ENC-TS-ENC.

+

+   hashAlg

+      This field MUST be present if and only if a hash of the OTP value

+      was used as input to string-to-key (see Section 3.6) and MUST

+      contain the AlgorithmIdentifier of the hash algorithm used.  If

+      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then

+      the AlgorithmIdentifer MUST be the first one supported by the

+      client from the supportedHashAlg of the PA-OTP-CHALLENGE.

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 16]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   iterationCount

+      This field MUST be present if and only if a hash of the OTP value

+      was used as input to string-to-key (see Section 3.6) and MUST

+      contain the iteration count used when hashing the OTP value.  If

+      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then

+      the value MUST NOT be less that that specified in the PA-OTP-

+      CHALLENGE.

+

+   otp-value

+      The generated OTP value.  This value MUST NOT be present unless

+      allowed by the OTP algorithm profile.

+

+   otp-challenge

+      Value used by the client in the OTP calculation.  It MUST be sent

+      to the KDC if and only if the value would otherwise be unknown to

+      the KDC.  For example, the token or client modified or generated

+      challenge.

+

+   otp-time

+      This field MAY be included by the client to carry the time value

+      as reported by the OTP token.  Use of this element is OPTIONAL but

+      it MAY be used by a client to simplify the OTP calculations of the

+      KDC.  It is RECOMMENDED that the KDC act upon this value if it is

+      present in the request and it is capable of using it in the

+      generation of the OTP value.

+

+   otp-counter

+      This field MAY be included by the client to carry the token

+      counter value, as reported by the OTP token.  Use of this element

+      is OPTIONAL but it MAY be used by a client to simplify the OTP

+      calculations of the KDC.  It is RECOMMENDED that the KDC act upon

+      this value if it is present in the request and it is capable of

+      using it in the generation of the OTP value.

+

+   otp-format

+      This field MAY be used by the client to send the format of the

+      generated OTP as reported by the OTP token.  Use of this element

+      is OPTIONAL but it MAY be used by the client to simplify the OTP

+      calculation.  It is RECOMMENDED that the KDC act upon this value

+      if it is present in the request and it is capable of using it in

+      the generation of the OTP value.

+

+   otp-keyID

+      This field MAY be used by the client to send the identifier of the

+      token key used, as reported by the OTP token.  Use of this field

+      is OPTIONAL but MAY be used by the client to simplify the

+      authentication process by identifying a particular token key

+      associated with the user.  It is RECOMMENDED that the KDC act upon

+

+

+

+Richards                Expires January 15, 2009               [Page 17]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+      this value if it is present in the request and it is capable of

+      using it in the generation of the OTP value.

+

+   otp-algID

+      This field MAY be used by the client to send the identifier of the

+      OTP algorithm used, as reported by the OTP token.  Use of this

+      element is OPTIONAL but it MAY be used by the client to simplify

+      the OTP calculation.  It is RECOMMENDED that the KDC act upon this

+      value if it is present in the request and it is capable of using

+      it in the generation of the OTP value.

+

+4.3.  PA-OTP-CONFIRM

+

+   The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc-

+   fast-rep of a PA-FX-FAST-REPLY in the AS-REP of the KDC.  It is used

+   to return the client's nonce encrypted under the new Reply Key in

+   order to authenticate the KDC and confirm the Reply Key change.

+

+   The corresponding padata-value field contains the DER encoding of a

+   PA-OTP-CONFIRM.

+

+             PA_OTP_CONFIRM     << TBA >>

+

+             PA-OTP-CONFIRM ::= SEQUENCE {

+               encData        EncryptedData,

+                                   -- PA-OTP-ENC-CONFIRM

+                                   -- Key usage of KEY_USAGE_OTP_CONFIRM

+               ...

+             }

+

+             KEY_USAGE_OTP_CONFIRM  << TBA >>

+

+

+             PA-OTP-ENC-CONFIRM ::= SEQUENCE {

+               nonce     UInt32,

+               ...

+             }

+

+   encData

+      An EncryptedData containing a PA-OTP-ENC-CONFIRM containing the

+      value of the nonce from the corresponding PA-OTP-REQUEST encrypted

+      under the current Reply Key. The key usage SHALL be

+      KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same

+      as that used by the client in the PA-OTP-REQUEST.

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 18]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+4.4.  PA-OTP-PIN-CHANGE

+

+   The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the enc-

+   fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change

+   their PIN or if the user's PIN has been changed.

+

+   The corresponding padata-value field contains the DER encoding of a

+   PA-OTP-PIN-CHANGE.

+

+             PA_OTP_PIN_CHANGE     << TBA >>

+

+             PA-OTP-PIN-CHANGE ::= SEQUENCE {

+               flags         PinFlags,

+               pin           UTF8String OPTIONAL,

+               minLength     INTEGER    OPTIONAL,

+               maxLength [1] INTEGER    OPTIONAL,

+               ...

+             }

+

+             PinFlags ::= KerberosFlags

+               -- systemSetPin (0)

+

+   If the "systemSetPin" flag is set then the user's PIN has been

+   changed and the new PIN value is contained in the pin field.  The pin

+   field MUST therefore be present.

+

+   If the "systemSetPin" flag is not set then the user's PIN has not

+   been changed by the server but it MUST instead be changed by the

+   user.  Restrictions on the size of the PIN MAY be given by the

+   minLength and maxLength fields.  If the pin field is present then it

+   contains a PIN value that MAY be used by the user when changing the

+   PIN.

+

+

+5.  IANA Considerations

+

+   A registry may be required for the otp-algID values as introduced in

+   Section 4.1.  No other IANA actions are anticipated.

+

+

+6.  Security Considerations

+

+6.1.  Man-in-the-Middle

+

+   In the system described in this document, the OTP pre-authentication

+   protocol is tunnelled within the FAST Armor channel provided by the

+   pre-authentication framework.  As described in [AsNiNy02], tunneled

+   protocols are potentially vulnerable to man-in-the-middle attacks if

+

+

+

+Richards                Expires January 15, 2009               [Page 19]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   the outer tunnel is compromised and it is generally considered good

+   practice in such cases to bind the inner encryption to the outer

+   tunnel.

+

+   Even though no such attacks are known at this point, the proposed

+   system uses the outer Armor Key in the derivation of the inner Client

+   and Reply keys and so achieve crypto-binding to the outer channel.

+

+6.2.  Reflection

+

+   The 4-pass system described above is a challenge-response protocol

+   and such protocols are potentially vulnerable to reflection attacks.

+   No such attacks are known at this point but to help mitigate against

+   such attacks, the system uses different keys to encrypt the client

+   and server nonces.

+

+6.3.  Replay

+

+   The 2-pass version of the protocol does not involve a server nonce

+   and so the client instead encrypts a timestamp.  To reduce the chance

+   of replay attacks, the KDC must check that the client time used in

+   such a request is later than that used in previous requests.

+

+6.4.  Brute Force Attack

+

+   A compromised or hostile KDC may be able to obtain the OTP value used

+   by the client via a brute force attack.  If the OTP value is short

+   then the KDC could iterate over the possible OTP values until a

+   Client Key is generated that can decrypt the encData sent in the PA-

+   OTP-REQUEST.

+

+   As described in Section 3.6, an iteration count can be used in the

+   generation of the Client Key and the value of the iteration count can

+   be controlled by local client policy.  Use of this iteration count

+   can make it computationally infeasible/unattractive for an attacker

+   to brute-force search for the given OTP within the lifetime of that

+   OTP.

+

+6.5.  FAST Facilities

+

+   The secret used to generate the OTP is known only to the client and

+   the KDC and so successful decryption of the encrypted nonce by the

+   KDC authenticates the user.  Similarly, successful decryption of the

+   encrypted nonce by the client proves that the expected KDC replied.

+   The Reply Key is replaced by a key generated from the OTP and Armor

+   Key. This FAST factor therefore provides the following facilities:

+   client-authentication, replacing-reply-key and KDC-authentication.

+

+

+

+

+Richards                Expires January 15, 2009               [Page 20]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+7.  Acknowledgments

+

+   Many significant contributions were made to this document by RSA

+   employees but special thanks go to Magnus Nystrom, John Linn, Robert

+   Polansky and Boris Khoutorski.

+

+   Many valuable suggestions were also made by members of the Kerberos

+   Working group but special thanks go to Larry Zhu, Jeffrey Hutzelman,

+   Tim Alsop, Henry Hotz and Nicolas Williams.

+

+

+8.  References

+

+8.1.  Normative References

+

+   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail

+              Extensions (MIME) Part One: Format of Internet Message

+              Bodies", RFC 2045, November 1996.

+

+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

+              Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,

+              "Internationalizing Domain Names in Applications (IDNA)",

+              RFC 3490, March 2003.

+

+   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep

+              Profile for Internationalized Domain Names (IDN)",

+              RFC 3491, March 2003.

+

+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

+              Kerberos 5", RFC 3961, February 2005.

+

+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

+              Kerberos Network Authentication Service (V5)", RFC 4120,

+              July 2005.

+

+   [ZhHa07]   Znu, L. and S. Hartman, "A generalized Framework for

+              Kerberos Pre-Authentication",

+              draft-ietf-krb-wg-preauth-framework-08 (work in progress),

+              July 2008.

+

+8.2.  Informative References

+

+   [AsNiNy02]

+              Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle

+              in Tunneled Authentication Protocols", Cryptology ePrint

+              Archive Report 2002/163, November 2002.

+

+

+

+Richards                Expires January 15, 2009               [Page 21]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   [HoReNeZo04]

+              Horstein, K., Renard, K., Neuman, C., and G. Zorn,

+              "Integrating Single-use Authentication Mechanisms with

+              Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in

+              progress), July 2004.

+

+   [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-

+              Time Password System", RFC 2289, February 1998.

+

+   [RFC2808]  Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,

+              April 2000.

+

+   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows

+              2000 Kerberos Change Password and Set Password Protocols",

+              RFC 3244, February 2002.

+

+   [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and

+              O. Ranen, "HOTP: An HMAC-Based One-Time Password

+              Algorithm", RFC 4226, December 2005.

+

+

+Appendix A.  ASN.1 Module

+

+   OTPKerberos

+   DEFINITIONS IMPLICIT TAGS ::=

+   BEGIN

+

+   IMPORTS

+       AnyURI

+       FROM XSD {joint-iso-itu-t asn1(1) specification(0)

+                 modules(0) xsd-module(1)};

+

+       KerberosTime, KerberosFlags, EncryptionKey, UInt32,

+       Int32, EncryptedData

+       FROM KerberosV5Spec2 {iso(1) identified-organization(3)

+                             dod(6) internet(1) security(5)

+                             kerberosV5(2) modules(4) krb5spec2(2)}

+                             -- as defined in RFC 4120.

+       AlgorithmIdentifier

+       FROM PKIX1Explicit88 { iso (1) identified-organization (3)

+                              dod (6) internet (1)

+                              security (5) mechanisms (5) pkix (7)

+                              id-mod (0) id-pkix1-explicit (18) };

+                              -- As defined in RFC 3280.

+

+       PA-OTP-CHALLENGE ::= SEQUENCE {

+         flags              OTPFlags,

+         nonce              UInt32,

+

+

+

+Richards                Expires January 15, 2009               [Page 22]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+         etype              Int32,

+         supportedHashAlg   SEQUENCE OF AlgorithmIdentifier

+                                            OPTIONAL,

+         iterationCount     INTEGER         OPTIONAL,

+         otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,

+         otp-length     [0] Int32           OPTIONAL,

+         otp-service        UTF8String      OPTIONAL,

+         otp-keyID      [1] OCTET STRING    OPTIONAL,

+         otp-algID          AnyURI          OPTIONAL,

+         ...

+       }

+

+       OTPFlags ::= KerberosFlags

+       -- nextOTP (0)

+       -- combine (1)

+

+       PA-OTP-REQUEST ::= SEQUENCE {

+         flags             OTPFlags,

+         nonce             UInt32,

+         encData           EncryptedData,

+                           -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC

+                           -- Key usage of KEY_USAGE_OTP_REQUEST

+         hashAlg           AlgorithmIdentifier OPTIONAL,

+         iterationCount    INTEGER         OPTIONAL,

+         otp-value         OCTET STRING    OPTIONAL,

+         otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL,

+         otp-time          KerberosTime    OPTIONAL,

+         otp-counter   [1] OCTET STRING    OPTIONAL,

+         otp-format    [2] OTPFormat       OPTIONAL,

+         otp-keyID     [3] OCTET STRING    OPTIONAL,

+         otp-algID         AnyURI          OPTIONAL,

+         ...

+       }

+

+       PA-OTP-ENC-REQUEST ::= SEQUENCE {

+         nonce     UInt32,

+         ...

+       }

+

+       OTPFormat ::= INTEGER {

+         decimal(0),

+         hexadecimal(1),

+         alphanumeric(2),

+         binary(3)

+       }

+

+       PA-OTP-CONFIRM ::= SEQUENCE {

+         encData        EncryptedData,

+

+

+

+Richards                Expires January 15, 2009               [Page 23]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+                        -- PA-OTP-ENC-CONFIRM

+                        -- Key usage of KEY_USAGE_OTP_CONFIRM

+         ...

+       }

+

+       PA-OTP-ENC-CONFIRM ::= SEQUENCE {

+         nonce     UInt32,

+         ...

+       }

+

+       PA-OTP-PIN-CHANGE ::= SEQUENCE {

+         flags         PinFlags,

+         pin           UTF8String OPTIONAL,

+         minLength     INTEGER    OPTIONAL,

+         maxLength [0] INTEGER    OPTIONAL,

+         ...

+       }

+

+       PinFlags ::= KerberosFlags

+       -- systemSetPin (0)

+

+   END

+

+

+Appendix B.  Examples of OTP Pre-Authentication Exchanges

+

+   This section is non-normative.

+

+B.1.  Four Pass Authentication

+

+   In this mode, the client sends an initial AS-REQ to the KDC that does

+   not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR

+   containing a PA-OTP-CHALLENGE.

+

+   In this example, the user has been issued with a connected, time-

+   based token and the KDC requires hashed OTP values in the key

+   generation with SHA-384 as the preferred hash algorithm and a minimum

+   of 1024 iterations.  It also requires that 256-bit AES be used to

+   encrypt the nonce.  The local policy on the client supports SHA-256

+   and requires 100,000 iterations of the OTP value.

+

+   The basic sequence of steps involved is as follows:

+

+   1.   The client obtains the user name of the user.

+

+   2.   The client sends an initial AS-REQ to the KDC that does not

+        contain a PA-OTP-REQUEST.

+

+

+

+

+Richards                Expires January 15, 2009               [Page 24]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   3.   The KDC determines that the user identified by the AS-REQ

+        requires OTP authentication.

+

+   4.   The KDC constructs a PA-OTP-CHALLENGE as follows:

+

+        flags

+           0

+

+        nonce

+           A randomly generated value.

+

+        etype

+           aes256-cts-hmac-sha1-96

+

+        supportedHashAlg

+           AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1

+

+        iterationCount

+           1024

+

+        otp-service

+           A string that can be used by the client to assist the user in

+           locating the correct token.

+

+   5.   The KDC returns a KRB-ERROR with an error code of

+        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.

+

+   6.   The client displays the value of otp-service and prompts the

+        user to connect the token.

+

+   7.   The client obtains the current OTP value from the token and

+        records the time as reported by the token.

+

+   8.   The client generates Client Key and Reply Key as described in

+        Section 3.6 using SHA-256 from the list of algorithms sent by

+        the KDC and the iteration count of 100,000 as required by local

+        policy.

+

+   9.   The client constructs a PA-OTP-REQUEST as follows:

+

+        flags

+           0

+

+        nonce

+           A randomly generated value.

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 25]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+        encData

+           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted

+           under the Client Key with a key usage of

+           KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-

+           hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from

+           the PA-OTP-CHALLENGE.

+

+        hashAlg

+           SHA-256

+

+        iterationCount

+           100,000

+

+        otp-time

+           The time used in the OTP calculation as reported by the OTP

+           token.

+

+   10.  The client encrypts the PA-OTP-REQUEST within the enc-fast-req

+        of a PA-FX-FAST-REQUEST.

+

+   11.  The client sends an AS-REQ to the KDC containing the PA-FX-FAST-

+        REQUEST within the padata.

+

+   12.  The KDC validates the pre-authentication data in the PA-OTP-

+        REQUEST:

+

+        *  Generates the Client Key and Reply Key from the OTP value for

+           the user identified in the AS-REQ, using an iteration count

+           of 100,000 and hash algorithm of SHA-256 as specified in the

+           PA-OTP-REQUEST.

+

+        *  Uses the generated Client Key to decrypt the PA-OTP-ENC-

+           REQUEST in the encData of the PA-OTP-REQUEST.

+

+        *  Authenticates the user by comparing the nonce value from the

+           decrypted PA-OTP-ENC-REQUEST to that sent in the

+           corresponding PA-OTP-CHALLENGE.

+

+   13.  The KDC constructs a TGT for the user.

+

+   14.  The KDC constructs a PA-OTP-CONFIRM as follows:

+

+        encData

+           An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted

+           under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM

+           and an encryption type of aes256-cts-hmac-sha1-96 (the

+           encryption type used by the client in the PA-OTP-REQUEST).

+           The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-

+

+

+

+Richards                Expires January 15, 2009               [Page 26]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+           REQUEST.

+

+   15.  The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a

+        PA-FX-FAST-REPLY.

+

+   16.  The KDC returns an AS-REP to the client, encrypted using the

+        Reply Key, containing the TGT and padata with the PA-FX-FAST-

+        REPLY.

+

+   17.  The client authenticates the KDC and verifies the Reply Key

+        change.

+

+        *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-

+           CONFIRM in the encData of the PA-OTP-CONFIRM.

+

+        *  Authenticates the KDC by comparing the nonce value from the

+           decrypted PA-OTP-ENC-CONFIRM to that sent in the

+           corresponding PA-OTP-REQUEST.

+

+B.2.  Two Pass Authentication

+

+   In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-

+   FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC.

+

+   In this example, the user has been issued with a hand-held token and

+   so none of the OTP generation parameters (otp-length etc) are

+   included in the PA-OTP-RESPONSE.  The KDC does not require hashed OTP

+   values in the key generation.

+

+   It is assumed that the client has been configured with the following

+   information or has obtained it from a previous PA-OTP-CHALLENGE.

+   o  The encryption type of aes128-cts-hmac-sha1-96 to use to encrypt

+      the encData.

+   o  The fact that hashed OTP values are not required.

+

+   The basic sequence of steps involved is as follows:

+

+   1.   The client obtains the user name and OTP value from the user.

+

+   2.   The client generates Client Key and Reply Key using unhashed OTP

+        values as described in Section 3.6.

+

+   3.   The client constructs a PA-OTP-REQUEST as follows:

+

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 27]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+        flags

+           0

+

+        nonce

+           A randomly generated value.

+

+        encData

+           An EncryptedData containing a PA-ENC-TS-ENC encrypted under

+           the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and

+           an encryption type of aes128-cts-hmac-sha1-96.  The PA-ENC-

+           TS-ENC contains the current client time.

+

+   4.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req

+        of a PA-FX-FAST-REQUEST.

+

+   5.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-

+        REQUEST within the padata.

+

+   6.   The KDC validates the pre-authentication data:

+

+        *  Generates the Client Key and Reply Key from the unhashed OTP

+           value for the user identified in the AS-REQ.

+

+        *  Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in

+           the encData of the PA-OTP-REQUEST.

+

+        *  Authenticates the user using the timestamp in the standard

+           manner.

+

+   7.   The KDC constructs a TGT for the user.

+

+   8.   The KDC constructs a PA-OTP-CONFIRM as follows:

+

+        encData

+           An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted

+           under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM

+           and an encryption type of aes128-cts-hmac-sha1-96 (the

+           encryption type used by the client in the PA-OTP-REQUEST).

+           The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-

+           REQUEST.

+

+   9.   The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a

+        PA-FX-FAST-REPLY.

+

+   10.  The KDC returns an AS-REP to the client, encrypted using the

+        Reply Key, containing the TGT and padata with the PA-FX-FAST-

+        REPLY.

+

+

+

+

+Richards                Expires January 15, 2009               [Page 28]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+   11.  The client authenticates the KDC and verifies the key change.

+

+        *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-

+           CONFIRM in the encData of the PA-OTP-CONFIRM.

+

+        *  Authenticates the KDC by comparing the nonce value from the

+           decrypted PA-OTP-ENC-CONFIRM to that sent in the

+           corresponding PA-OTP-REQUEST.

+

+B.3.  Pin Change

+

+   This exchange follows from the point where the KDC receives the PA-

+   OTP-REQUEST from the client in the examples in Appendix B.1 and

+   Appendix B.2.  During the validation of the pre-authentication data

+   (whether encrypted nonce or encrypted timestamp), the KDC determines

+   that the user's PIN has expired and so must be changed.  The KDC

+   therefore includes a PA-OTP-PIN-CHANGE along with the PA-OTP-CONFIRM

+   in the AS-REP.

+

+   In this example, the KDC does not generate PIN values for the user

+   but requires that the user generate a new PIN that is between 4 and 8

+   characters in length.  The actual PIN change is handled by a PIN

+   change service that requires the "initial" bit to be set in the

+   service ticket.

+

+   The basic sequence of steps involved is as follows:

+

+   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as

+        described in the previous examples.

+

+   2.   The KDC validates the pre-authentication data and authenticates

+        the user as in the previous examples but determines that the

+        user's PIN has expired.

+

+   3.   KDC constructs a ticket for a PIN change service with the

+        "initial" flag set.

+

+   4.   KDC constructs a PA-OTP-CONFIRM as in the previous examples.

+

+   5.   KDC constructs a PA-OTP-PIN-CHANGE as follows:

+

+        flags

+           0

+

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 29]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+        minLength

+           4

+

+        maxLength

+           8

+

+   6.   KDC encrypts the PA-OTP-PIN-CHANGE and PA-OTP-CONFIRM within the

+        enc-fast-rep of a PA-FX-FAST-REPLY.

+

+   7.   KDC returns an AS-REP to the client containing the ticket to the

+        PIN change service and padata containing the PA-FX-FAST-REPLY.

+

+   8.   The client authenticates the KDC as in the previous examples.

+

+   9.   The client uses the ticket in the AS-REP to call the PIN change

+        service and change the user's PIN.

+

+   10.  The client sends a second AS-REQ to the KDC containing a PA-OTP-

+        REQUEST constructed using the new PIN.

+

+   11.  The KDC responds with an AS-REP containing a TGT and a PA-OTP-

+        CONFRIM.

+

+

+B.4.  Resynchronization

+

+   This exchange follows from the point where the KDC receives the PA-

+   OTP-REQUEST from the client.  During the validation of the pre-

+   authentication data (whether encrypted nonce or encrypted timestamp),

+   the KDC determines that the local record of the token's state needs

+   to be re-synchronized with the token.  The KDC therefore includes a

+   KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.

+

+   The sequence of steps below follows is a variation of the four pass

+   examples shown in Appendix B.1 but the same process would also work

+   in the two-pass case.

+

+   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as

+        described in the previous examples.

+

+   2.   The KDC validates the pre-authentication data and authenticates

+        the user as in the previous examples but determines that user's

+        token requires re-synchronizing.

+

+   3.   KDC constructs a PA-OTP-CHALLENGE as follows:

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 30]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+        flags

+           nextOTP bit set

+

+        nonce

+           A randomly generated value.

+

+        etype

+           aes256-cts-hmac-sha1-96

+

+        supportedHashAlg

+           AlgorithmIdentifiers for SHA-256 and SHA-1

+

+        iterationCount

+           1024

+

+        otp-service

+           Set to a string that can be used by the client to assist the

+           user in locating the correct token.

+

+   4.   KDC returns a KRB-ERROR with an error code of

+        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.

+

+   5.   The client obtains the next OTP value from the token and records

+        the time as reported by the token.

+

+   6.   The client generates Client Key Reply Key as described in

+        Section 3.6 using SHA-256 from the list of algorithms sent by

+        the KDC and the iteration count of 100,000 as required by local

+        policy.

+

+   7.   The client constructs a PA-OTP-REQUEST as follows:

+

+        flags

+           nextOTP bit set

+

+        nonce

+           A randomly generated value.

+

+        encData

+           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted

+           under the Client Key with a key usage of

+           KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-

+           hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from

+           the PA-OTP-CHALLENGE.

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 31]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+        hashAlg

+           SHA-256

+

+        iterationCount

+           100,000

+

+        otp-time

+           The time used in the OTP calculation as reported by the OTP

+           token.

+

+   8.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req

+        of a PA-FX-FAST-REQUEST.

+

+   9.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-

+        REQUEST within the padata.

+

+   10.  Authentication process now proceeds as with the standard

+        sequence.

+

+

+Author's Address

+

+   Gareth Richards

+   RSA, The Security Division of EMC

+   RSA House

+   Western Road

+   Bracknell, Berkshire  RG12 1RT

+   UK

+

+   Email: gareth.richards@rsa.com

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 32]

+

+Internet-Draft           OTP Pre-authentication                July 2008

+

+

+Full Copyright Statement

+

+   Copyright (C) The IETF Trust (2008).

+

+   This document is subject to the rights, licenses and restrictions

+   contained in BCP 78, and except as set forth therein, the authors

+   retain all their rights.

+

+   This document and the information contained herein are provided on an

+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

+

+

+Intellectual Property

+

+   The IETF takes no position regarding the validity or scope of any

+   Intellectual Property Rights 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; nor does it represent that it has

+   made any independent effort to identify any such rights.  Information

+   on the procedures with respect to rights in RFC documents can be

+   found in BCP 78 and BCP 79.

+

+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at

+   http://www.ietf.org/ipr.

+

+   The IETF invites any interested party to bring to its attention any

+   copyrights, patents or patent applications, or other proprietary

+   rights that may cover technology that may be required to implement

+   this standard.  Please address the information to the IETF at

+   ietf-ipr@ietf.org.

+

+

+

+

+

+

+

+

+

+

+

+Richards                Expires January 15, 2009               [Page 33]

+

diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt
new file mode 100644
index 00000000000..bf2dd5f2d2f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                               L. Hornquist Astrand
+Internet-Draft                                      Stockholm University
+Expires: September 2, 2006                                        L. Zhu
+                                                   Microsoft Corporation
+                                                              March 2006
+
+
+                       PK-INIT algorithm agility
+                draft-ietf-krb-wg-pkinit-alg-agility-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on September 2, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The PK-INIT protocol have in several places hard coded crypto
+   algorithms.  The protocol specification needs to be updated so it can
+   support negotiation to upgrading to newer versions of crypto
+   algorithms.  This document addresses this issue.
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 1]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
+   3.  paChecksum agility . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  CMS Digest Algorithm agility . . . . . . . . . . . . . . . . .  6
+   5.  Certificate Signer Algorithm Identifier agility  . . . . . . .  7
+   6.  octetstring2key function agility . . . . . . . . . . . . . . .  8
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 2]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+1.  Introduction
+
+   The Kerberos PK-INIT document contains several hardcoded algorithms
+   that was know designed at design time that they had to be replaced by
+   something else at a later time, this document described how to use
+   other algorithms other then those that are hard-coded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 3]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+2.  Requirements notation
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 4]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+3.  paChecksum agility
+
+   The paChecksum binds the PK-INIT part of the request to main body of
+   the Kerberos request (KDC-REQ-BODY).  This is to makes sure an
+   attacker can not change the request from the client to the server.
+   The problem is that paChecksum is hardcoded to use SHA1-1, however,
+   there is a mechaism to provide algorithm agility for the paChecksum
+   within the PK-INIT prototcol.  Newer clients can choose not send the
+   paChecksum field, but rather add some new fields after the existing
+   fields, older KDC will send back know failure-code so that newer
+   clients can fall back to the old protocol if local policy allows
+   that.
+
+   If the attacker can preserve the checksum in paChecksum, an attacker
+   can, for example, change the KDC-REQ-BODY is to downgrade the
+   encryption types used, expend the expiration time, etc, and then try
+   to brute-force the request.
+
+   In the Public Key Encryption case of PK-INIT the reply contains a
+   checksum over the whole request in the asChecksum field, in this case
+   the client will detect any modifications to the request.  Since the
+   asChecksum is using the associated checksum of the session key
+   encryption type, asChecksum field is algorithm agile.
+
+   One way to solve this problem is to add the asChecksum to the Diffie-
+   Hellman case reply too, and just ignore the paCheckSum field.  The
+   KDC should still not issue tickets that are too weak, since that
+   exposes the problem.  This is regardless of the using PK-INIT or not.
+
+   Questions for wg: Wait for Kerberos Extensions that will solve this
+   problem (ignore the problem for how), or use add asChecksum to DH
+   case.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 5]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+4.  CMS Digest Algorithm agility
+
+   The client can tell KDC what the supported CMS types are in the
+   requset packet, but there are no equivalent for KDC to the the client
+   what the digest algorithm are support in an reply.
+
+   Have KDC send the CMS list of supported encryption types in the
+   e-data field of KRB-ERROR when returning the
+   KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error.
+
+   DER encoded TS-SD-PARAMETERS specifies supported digest algorithms.
+   The list is in decreasing preference order.
+
+
+
+   TD-SD-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 6]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+5.  Certificate Signer Algorithm Identifier agility
+
+   The KDC can reject a certificate based on the signers hash algorithm
+   with the error KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED, but doesn't tell
+   the client what algorithm are supported.
+
+   DER encoded TS-DC-PARAMETERS specifies supported certificate digest
+   algorithms.  The AllowedAlgorithms is in decreasing preference order.
+   RejectedAlgorithm may be include my the KDC to tell what algorithm
+   was rejected in case the rejected certificate was part of a computed
+   chain.
+
+
+
+   TD-DC-PARAMETERS ::= SEQUENCE {
+       AllowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
+       RejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 7]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+6.  octetstring2key function agility
+
+   The PK-INIT standard uses a home-grown string 2 key function in the
+   DH case.  The function uses SHA-1 to mix and stretch the DH shared
+   key.
+
+   Describe how the client announces that is supports the new String to
+   key function.  Probably by stuffing it into the supportCMSTypes field
+   in the request.
+
+   Use NIST SP 800 56B when its published.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 8]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+7.  Security Considerations
+
+   This document describes negotiation of checksum types and other
+   cryptographic functions.  Most of this negotiation is done
+   unauthenticated with no way to very
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 9]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+8.  IANA Considerations
+
+   No IANA considerations.
+
+9.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006             [Page 10]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+Authors' Addresses
+
+   Love Hornquist Astrand
+   Stockholm University
+   SE-106 91  STOCKHOLM
+   SWEDEN
+
+   Email: lha@it.su.se
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006             [Page 11]
+
+Internet-Draft          PK-INIT algorithm agility             March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hornquist Astrand & Zhu  Expires September 2, 2006             [Page 12]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt
new file mode 100644
index 00000000000..bd6dbfe32e9
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt
@@ -0,0 +1,1175 @@
+
+
+Network Working Group                               L. Hornquist Astrand
+Internet-Draft                                      Stockholm University
+Intended status: Standards Track                                  L. Zhu
+Expires: January 10, 2008                          Microsoft Corporation
+                                                            July 9, 2007
+
+
+                       PK-INIT algorithm agility
+                draft-ietf-krb-wg-pkinit-alg-agility-03
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 10, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 1]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+Abstract
+
+   The PK-INIT defined in RFC 4556 is examined and updated to remove
+   protocol structures tied to specific cryptographic algorithms.  The
+   affinity to SHA-1 as the checksum algorithm in the authentication
+   request is analyzed.  The PK-INIT key derivation function is made
+   negotiable, the digest algorithms for signing the pre-authentication
+   data and the client's X.509 certificates are made discoverable.
+
+   These changes provide protection preemptively against vulnerabilities
+   discovered in the future against any specific cryptographic
+   algorithm, and allow incremental deployment of newer algorithms.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
+   3.  paChecksum Agility . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . .  7
+   5.  X.509 Certificate Signer Algorithm Agility . . . . . . . . . .  8
+   6.  KDF agility  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 16
+     10.2.  Informative References  . . . . . . . . . . . . . . . . . 17
+   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 18
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
+   Intellectual Property and Copyright Statements . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 2]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+1.  Introduction
+
+   In August 2004, Xiaoyun Wang's research group reported MD4 [RFC1320]
+   collisions generated using hand calculation [WANG04] alongside
+   attacks on later hash function designs in the MD4, MD5 [RFC1321] and
+   SHA [RFC4634] family.  Implementations based on Wang's algorithm can
+   find collisions in real time.  These discoveries challenged the
+   security for protocols relying on the collision resistance properties
+   of these hashes, for example one can forge a digital signature when
+   SHA-1 [RFC4634] is the digest algorithm.  A more far reaching side
+   effect of these recent events, however, is that it is now generally
+   considered flawed or distasteful at least if protocols are designed
+   to use only specific algorithms.
+
+   The Internet Engineer Task Force (IETF) called for actions to update
+   existing protocols to provide crypto algorithm agility in order to
+   untie protocols with specific algorithms.  The idea is that if the
+   protocol has crypto algorithm agility, and when a new vulnerability
+   specific to an algorithm is discovered, this algorithm can be
+   disabled via protocol negotiation quickly, thus we can avoid the wait
+   for the multi-year standardization and implementation efforts to
+   update the protocols.  In additon, crypto agility allows deployment
+   of new crypto algorithms to be done incrementally, rather than
+   requring a "flag day" on which the change must be deployed everywhere
+   at the same time in order to maintain interoperability.
+
+   This document is to update PK-INIT [RFC4556] to provide crypto
+   algorithm agility.  Several protocol structures used in the [RFC4556]
+   protocol are either tied to SHA-1, or require the algorithms not
+   negotiated but rather based on local policy.  The following concerns
+   have been addressed:
+
+   o  The checksum algorithm in the authentication request is hardwired
+      to use SHA-1 [RFC4634].
+
+   o  The acceptable digest algorithms for signing the authentication
+      data are not discoverable.
+
+   o  The key derivation function in Section 3.2.3 of [RFC4556] is
+      hardwired to use SHA-1.
+
+   o  The acceptable digest algorithms for signing the client X.509
+      certificates are not discoverable.
+
+   To accomplish these, new key derivation functions (KDFs) identifiable
+   by object identifiers are defined.  The PKINIT client provides a list
+   of KDFs in the request and the KDC picks one in the response, thus a
+   mutually-supported KDF is negotiated.
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 3]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+   Furthermore, structures are defined to allow the client discover the
+   Cryptographic Message Syntax (CMS) [RFC3852] digest algorithms
+   supported by the KDC for signing the pre-authentication data and
+   signing the client X.509 certificate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 4]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+2.  Requirements Notation
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 5]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+3.  paChecksum Agility
+
+   The paChecksum defined in Section 3.2.1 of [RFC4556] provides a
+   cryptographic binding between the client's pre-authentication data
+   and the corresponding Kerberos request body.  This also prevents the
+   KDC body from being tempered with.  SHA-1 is the only allowed
+   checksum algorithm defined in [RFC4556].  This facility relies the
+   collision resistance properties of the SHA-1 checksum [RFC4634].
+
+   When the reply key delivery mechanism is based on public key
+   encryption as described in Section 3.2.3. of [RFC4556], the
+   asChecksum in the KDC reply provides the binding between the pre-
+   authentication and the ticket request and response messages, and
+   integrity protection for the unauthenticated clear text in these
+   messages.  However, if the reply key delivery mechanism is based on
+   the Diffie-Hellman key agreement as described in Section 3.2.3.1 of
+   [RFC4556], the security provided by using SHA-1 in the paChecksum is
+   weak.  In this case, the new KDF selected by the KDC as described in
+   Section 6 provides the cryptographic binding and integrity
+   protection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 6]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+4.  CMS Digest Algorithm Agility
+
+   When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
+   as described In section 3.2.2 of [RFC4556], implementations
+   comforming to this specification can OPTIONALLY send back a list of
+   supported CMS types signifying the digest algorithms supported by the
+   KDC, in the decreasing preference order.  This is accomplished by
+   including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the
+   error data.
+
+
+
+   TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
+
+
+   The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
+   the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded
+   TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:
+
+
+
+   TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
+       AlgorithmIdentifier
+           -- Contains the list of CMS algorithm [RFC3852]
+           -- identifiers that identify the digest algorithms
+           -- acceptable by the KDC for signing CMS data in
+           -- the order of decreasing preference.
+
+
+   The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
+   digest algorithms supported by the KDC.
+
+   This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
+   can facilitate trouble-shooting when none of the digest algorithms
+   supported by the client is supported by the KDC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 7]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+5.  X.509 Certificate Signer Algorithm Agility
+
+   When the client's X.509 certificate is rejected and the
+   KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
+   described in section 3.2.2 of [RFC4556], conforming implementations
+   can OPTIONALLY send a list of digest algorithms acceptable by the KDC
+   for use by the CA in signing the client's X.509 certificate, in the
+   decreasing preference order.  This is accomplished by including a
+   TD_CERT_DIGEST_ALGORITHMS typed data element in the error data.  The
+   corresponding data contains the ASN.1 DER encoding of the structure
+   TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows:
+
+
+   TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112
+
+   TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
+           allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
+                      -- Contains the list of CMS algorithm [RFC3852]
+                      -- identifiers that identify the digest algorithms
+                      -- that are used by the CA to sign the client's
+                      -- X.509 certificate and acceptable by the KDC in
+                      -- the process of validating the client's X.509
+                      -- certificate, in the order of decreasing
+                      -- preference.
+           rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
+                      -- This identifies the digest algorithm that was
+                      -- used to sign the client's X.509 certificate and
+                      -- has been rejected by the KDC in the process of
+                      -- validating the client's X.509 certificate
+                      -- [RFC3280].
+           ...
+   }
+
+
+   The KDC fills in allowedAlgorithm field with the list of algorithm
+   [RFC3852] identifiers that identify digest algorithms that are used
+   by the CA to sign the client's X.509 certificate and acceptable by
+   the KDC in the process of validating the client's X.509 certificate,
+   in the order of decreasing preference.  The rejectedAlgorithm field
+   identifies the signing algorithm for use in signing the client's
+   X.509 certificate that has been rejected by the KDC in the process of
+   validating the client's certificate [RFC3280].
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 8]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+6.  KDF agility
+
+   Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines
+   a Key Derivation Function (KDF) that derives a Kerberos protocol key
+   based on the secret value generated by the Diffie-Hellman key
+   exchange.  This KDF requires the use of SHA-1 [RFC4634].
+
+   New KDFs defined in this document based on [SP80056A] can be used in
+   conjunction with any hash functions.  A new KDF is identified by an
+   object identifier.  The following KDF object identifiers are defined:
+
+
+
+   id-pkinit-kdf OBJECT IDENTIFIER           ::= { id-pkinit 6 }
+       -- PKINIT KDFs
+   id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER   ::= { id-pkinit-kdf 1 }
+       -- SP800 56A ASN.1 structured hash based KDF using SHA-1
+   id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 }
+       -- SP800 56A ASN.1 structured hash based KDF using SHA-256
+   id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 }
+       -- SP800 56A ASN.1 structured hash based KDF using SHA-512
+
+
+   Where id-pkinit is defined in [RFC4556].  The id-pkinit-kdf-ah-sha1
+   KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that
+   uses SHA-1 [RFC4634] as the hash function.  Similarly id-pkinit-kdf-
+   ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF
+   using SHA-256 [RFC4634] and SHA-512 [RFC4634] respectively.  The
+   common input parameters for these KDFs are provided as follows:
+
+   o  The secret value is the shared secret value generated by the
+      Diffie-Hellman exchange.  The Diffie-Hellman shared value is first
+      padded with leading zeros such that the size of the secret value
+      in octets is the same as that of the modulus, then represented as
+      a string of octets in big-endian order.
+
+   o  The key data length is K. K is the key-generation seed length in
+      bits [RFC3961] for the Authentication Service (AS) reply key.  The
+      enctype of the AS reply key is selected according to [RFC4120].
+
+   o  The algorithm identifier input parameter is the identifier of the
+      respective KDF.  For example, this is id-pkinit-kdf-ah-sha1 if the
+      KDF is the [SP80056A] ASN.1 structured HKDF using SHA-1 as the
+      hash.
+
+   o  The initiator identifier is an OCTET STRING that contains the
+      ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that
+      identifies the client as specified in the AS-REQ [RFC4120] in the
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 9]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+      request.
+
+   o  The recipient identifier is an OCTET STRING that contains the
+      ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that
+      identifies the TGS as specified in the AS-REQ [RFC4120] in the
+      request.
+
+   o  The supplemental private information is absent (not used).
+
+   o  The supplemental public information is an OCTET STRING that
+      contains the ASN.1 DER encoding of the structure PkinitSuppPubInfo
+      as defined later in this section.
+
+   o  The hash length is 128 for id-pkinit-kdf-ah-sha1, 256 for id-
+      pkinit-kdf-ah-sha256, and 512 for id-pkinit-kdf-ah-sha512.
+
+   o  The maximum hash input length is 2^64 in bits.
+
+   The structure PkinitSuppPubInfo is defined as follows:
+
+
+   PkinitSuppPubInfo ::= SEQUENCE {
+          enctype           [0] Int32,
+              -- The enctype of the AS reply key.
+          as-REQ            [1] OCTET STRING,
+              -- This contains the AS-REQ in the request.
+          pk-as-rep         [2] OCTET STRING,
+              -- Contains the DER encoding of the type
+              -- PA-PK-AS-REP [RFC4556] in the KDC reply.
+          ticket            [3] Ticket,
+              -- This is the ticket in the KDC reply.
+          ...
+   }
+
+
+   The PkinitSuppPubInfo structure contains mutually-known public
+   information specific to the authentication exchange.  The enctype
+   field is the enctype of the AS reply key as selected according to
+   [RFC4120].  The as-REQ field contains the DER encoding of the type
+   AS-REQ [RFC4120] in the request sent from the client to the KDC.
+   Note that the as-REQ field does not include the wrapping 4 octet
+   length field when TCP is used.  The pk-as-rep field contains the DER
+   encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply.  The
+   ticket field is filled with the ticket in the KDC reply.  The
+   PkinitSuppPubInfo provides a cryptographic bindings between the pre-
+   authentication data and the corresponding ticket request and
+   response, thus addressing the concerns described in Section 3.
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 10]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+   The above ASN.1 structured [SP80056A] HKDF produces a bit string of
+   length K in bits as the keying material, and then the AS reply key is
+   the output of random-to-key() [RFC3961] using that returned keying
+   material as the input.
+
+   The KDF is negotiated between the client and the KDC.  The client
+   sends an unordered set of supported KDFs in the request, and the KDC
+   picks one from the set in the reply.
+
+   To acomplish this, the AuthPack structure in [RFC4556] is extended as
+   follows:
+
+
+   AuthPack ::= SEQUENCE {
+          pkAuthenticator   [0] PKAuthenticator,
+          clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
+          supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
+                   OPTIONAL,
+          clientDHNonce     [3] DHNonce OPTIONAL,
+          ...,
+          supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
+              -- Contains an unordered set of KDFs supported by the
+              -- client.
+          ...
+   }
+
+   KDFAlgorithmId ::= SEQUENCE {
+          kdf-id            [0] OBJECT IDENTIFIER,
+              -- The object identifier of the KDF
+          ...
+   }
+
+
+   The new field supportedKDFs contains an unordered set of KDFs
+   supported by the client.
+
+   The KDFAlgorithmId structure contains an object identifier that
+   identifies a KDF.  The algorithm of the KDF and its parameters are
+   defined by the corresponding specification of that KDF.
+
+   The DHRepInfo structure in [RFC4556] is extended as follows:
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 11]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+   DHRepInfo ::= SEQUENCE {
+           dhSignedData         [0] IMPLICIT OCTET STRING,
+           serverDHNonce        [1] DHNonce OPTIONAL,
+           ...,
+           kdf                  [2] KDFAlgorithmId OPTIONAL,
+               -- The KDF picked by the KDC.
+           ...
+   }
+
+
+   The new field kdf in the extended DHRepInfo structure identifies the
+   KDF picked by the KDC.  This kdf field MUST be filled by the
+   comforming KDC if the supportedKDFs field is present in the request,
+   and it MUST be one of the KDFs supported by the client as indicated
+   in the request.  Which KDF is chosen is a matter of the local policy
+   on the KDC.
+
+   If the supportedKDFs field is not present in the request, the kdf
+   field in the reply MUST be absent.
+
+   If the client fills the supportedKDFs field in the request, but the
+   kdf field in the reply is not present, the client can deduce that the
+   KDC is not updated to conform with this specification.  In that case,
+   it is a matter of local policy on the client whether to reject the
+   reply when the kdf field is absent in the reply.
+
+   Implementations comforming to this specification MUST support id-
+   pkinit-kdf-ah-sha256.
+
+   If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF
+   (82).
+
+   PKINIT introduces the following new error code:
+
+   o  KDC_ERR_NO_ACCEPTABLE_KDF 82
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 12]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+7.  Security Considerations
+
+   This document describes negotiation of checksum types, key derivation
+   functions and other cryptographic functions.  If negotiation is done
+   unauthenticated, care MUST be taken to accept only acceptable values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 13]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+8.  Acknowledgements
+
+   Jeffery Hutzelman and Shawn Emery reviewed the document and provided
+   suggestions for improvements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 14]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+9.  IANA Considerations
+
+   No IANA considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 15]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and HMAC-SHA)", July 2006.
+
+   [SP80056A]
+              Barker, E., Don, D., and M. Smid, "Recommendation for
+              Pair-Wise Key Establishment Schemes Using Discrete
+              Logarithm Cryptography", March 2006.
+
+   [X680]     ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
+              1:2002, Information technology - Abstract Syntax Notation
+              One (ASN.1): Specification of basic notation".
+
+   [X690]     ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
+              1:2002, Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)".
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 16]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+10.2.  Informative References
+
+   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
+              April 1992.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [WANG04]   Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,
+              "Cryptanalysis of Hash functions MD4 and RIPEMD",
+              August 2004.
+
+   [X9.42]    ANSI, "Public Key Cryptography for the Financial Services
+              Industry: Agreement of Symmetric Keys Using Discrete
+              Logarithm Cryptography", 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 17]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+
+
+   KerberosV5-PK-INIT-Agility-SPEC {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   IMPORTS
+      AlgorithmIdentifier, SubjectPublicKeyInfo
+          FROM PKIX1Explicit88 { iso (1)
+            identified-organization (3) dod (6) internet (1)
+            security (5) mechanisms (5) pkix (7) id-mod (0)
+            id-pkix1-explicit (18) }
+            -- As defined in RFC 3280.
+
+      Ticket, Int32, Realm, EncryptionKey, Checksum
+          FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+            dod(6) internet(1) security(5) kerberosV5(2)
+            modules(4) krb5spec2(2) }
+            -- as defined in RFC 4120.
+
+      PKAuthenticator, DHNonce
+          FROM KerberosV5-PK-INIT-SPEC {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) pkinit(5) };
+            -- as defined in RFC 4556.
+
+   TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
+       AlgorithmIdentifier
+           -- Contains the list of CMS algorithm [RFC3852]
+           -- identifiers that identify the digest algorithms
+           -- acceptable by the KDC for signing CMS data in
+           -- the order of decreasing preference.
+
+   TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
+          allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
+              -- Contains the list of CMS algorithm [RFC3852]
+              -- identifiers that identify the digest algorithms
+              -- that are used by the CA to sign the client's
+              -- X.509 certificate and acceptable by the KDC in
+              -- the process of validating the client's X.509
+              -- certificate, in the order of decreasing
+              -- preference.
+          rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
+              -- This identifies the digest algorithm that was
+              -- used to sign the client's X.509 certificate and
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 18]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+              -- has been rejected by the KDC in the process of
+              -- validating the client's X.509 certificate
+              -- [RFC3280].
+          ...
+   }
+
+   PkinitSuppPubInfo ::= SEQUENCE {
+          enctype           [0] Int32,
+              -- The enctype of the AS reply key.
+          as-REQ            [1] OCTET STRING,
+              -- This contains the AS-REQ in the request.
+          pk-as-rep         [2] OCTET STRING,
+              -- Contains the DER encoding of the type
+              -- PA-PK-AS-REP [RFC4556] in the KDC reply.
+          ticket            [3] Ticket,
+              -- This is the ticket in the KDC reply.
+          ...
+   }
+
+   AuthPack ::= SEQUENCE {
+          pkAuthenticator   [0] PKAuthenticator,
+          clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
+          supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
+                   OPTIONAL,
+          clientDHNonce     [3] DHNonce OPTIONAL,
+          ...,
+          supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
+              -- Contains an unordered set of KDFs supported by the
+              -- client.
+          ...
+   }
+
+   KDFAlgorithmId ::= SEQUENCE {
+          kdf-id            [0] OBJECT IDENTIFIER,
+              -- The object identifier of the KDF
+          ...
+   }
+
+   DHRepInfo ::= SEQUENCE {
+          dhSignedData      [0] IMPLICIT OCTET STRING,
+          serverDHNonce     [1] DHNonce OPTIONAL,
+          ...,
+          kdf               [2] KDFAlgorithmId OPTIONAL,
+              -- The KDF picked by the KDC.
+          ...
+   }
+   END
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 19]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+Authors' Addresses
+
+   Love Hornquist Astrand
+   Stockholm University
+   SE-106 91 Stockholm
+   Sweden
+
+   Email: lha@it.su.se
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 20]
+
+Internet-Draft          PK-INIT algorithm agility              July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 21]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-00.txt
new file mode 100644
index 00000000000..56d43df3a8b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-00.txt
@@ -0,0 +1,1177 @@
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                                       MIT
+Expires: August 9, 2004                                 February 9, 2004
+
+
+         A Generalized Framework for Kerberos Preauthentication
+                 draft-ietf-krb-wg-preauth-framework-00
+
+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 Internet-Draft will expire on August 9, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called preauthentication
+   for proving the identity  of a principal and for better protecting
+   the long-term secret of the principal.
+
+   This document describes a model for Kerberos preauthentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   preauthentication mechanism is likely to change. It also describes
+   how multiple preauthentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 1]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   preauthentication mechanisms.
+
+   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 [1].
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Model for Preauthentication  . . . . . . . . . . . . . . . . .  4
+   2.1 Information Managed by Model . . . . . . . . . . . . . . . . .  5
+   2.2 The Preauth_Required Error . . . . . . . . . . . . . . . . . .  6
+   2.3 Client to KDC  . . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.4 KDC to Client  . . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.  Preauthentication Facilities . . . . . . . . . . . . . . . . .  9
+   3.1 Client Authentication  . . . . . . . . . . . . . . . . . . . . 10
+   3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . . . 10
+   3.3 Replace Reply Key  . . . . . . . . . . . . . . . . . . . . . . 11
+   3.4 Verify Response  . . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Requirements for Preauthentication Mechanisms  . . . . . . . . 12
+   5.  Tools for Use in Preauthentication Mechanisms  . . . . . . . . 13
+   5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . . . 13
+   5.3 Managing State for the KDC . . . . . . . . . . . . . . . . . . 13
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
+       Normative References . . . . . . . . . . . . . . . . . . . . . 17
+       Informative References . . . . . . . . . . . . . . . . . . . . 18
+   A.  Todo List  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       Intellectual Property and Copyright Statements . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 2]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+1. Introduction
+
+   The core Kerberos specification treats preauthentication data as an
+   opaque typed hole in the messages to the KDC that may influence the
+   reply key used to encrypt the KDC response.  This generality has been
+   useful: preauthentication data is used for a variety of extensions to
+   the protocol, many outside the expectations of the initial designers.
+   However, this generality makes designing the more common types of
+   preauthentication mechanisms difficult. Each mechanism needs to
+   specify how it interacts with other mechanisms.  Also, problems like
+   combining a key with the long-term secret or proving the identity of
+   the user are common to multiple mechanisms.  Where there are
+   generally well-accepted solutions to these problems, it is desirable
+   to standardize one of these solutions so mechanisms  can avoid
+   duplication of work.  In other cases, a modular approach to these
+   problems is appropriate.  The modular approach will allow new  and
+   better solutions to common preauth problems to be used by existing
+   mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos preauthentication
+   mechanisms.  IT defines the common set of functions preauthentication
+   mechanisms perform as well as how these functions affect the state of
+   the request and response.  In addition several common tools needed by
+   preauthentication mechanisms are provided.  Unlike [3], this
+   framework is not complete--it does not describe all the inputs and
+   outputs for the preauthentication mechanisms.  Mechanism designers
+   should try to be consistent with this framework because doing so will
+   make their mechanisms easier to implement.  Kerberos implementations
+   are likely to have plugin architectures  for preauthentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [3] and the core
+   Kerberos protocol [2].  This document freely uses terminology and
+   notation from these documents without reference or further
+   explanation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 3]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+2. Model for Preauthentication
+
+   when a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial AS request.  If
+   preauthentication is being used, then the KDC will respond with a
+   KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
+   what preauthentication to use, it MAY optimize a round-trip and send
+   an initial request with padata included.  If the client includes the
+   wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  For
+   interoperability reasons, clients that include optimistic preauth
+   MUST retry with no padata and examine the KDC_ERR_PREAUTH_REQUIRED if
+   they receive a KDC_ERR_PREAUTH_FAILED in response to their initial
+   optimistic request.
+
+   The KDC maintains no state between two requests; subsequent requests
+   may even be processed by a different KDC. On the other hand, the
+   client treats a series of exchanges with KDCs as a single
+   authentication session.  Each exchange accumulates state and
+   hopefully brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict. For many
+   of the simpler preauthentication scenarios,  the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient preauthentication for the KDC to be
+   able to return a successful response.  For these simple scenarios,
+   the client only sends one request with preauthentication data and so
+   the authentication session is trivial.  For more complex
+   authentication sessions, the KDC needs to provide the client with a
+   cookie to include in future requests to capture the current state of
+   the authentication session.  Handling of multiple round-trip
+   mechanisms is discussed in Section 5.3.
+
+   This framework specifies the behavior of Kerberos preauthentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC response.  The padata typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  These extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process preauthentication.  It also specifies how Kerberos
+   implementations process the preauthentication data at each step of
+   the AS request process.
+
+
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 4]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+2.1 Information Managed by Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC response
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this authentication session
+
+   o  Whether the contents of the KDC response can be  verified by the
+      client principal
+
+   o  Whether the contents of the KDC response can be  verified by the
+      client machine
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in section 5.2.7.5 of the
+   Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
+   client  what types of keys are available.  Thus in full generality,
+   the reply key in the preauth model is actually a set of keys.  At the
+   beginning of a request, it is initialized to the set of long-term
+   keys advertised in the PA-ETYPE-INFO2 element on the KDC.  If
+   multiple reply keys are available, the client chooses which one to
+   use.  Thus the client does not need to treat the reply key as a set.
+   At the beginning of a handling a request, the client picks a reply
+   key to use.
+
+   KDC implementations MAY choose to offer only one key in the
+   PA-ETYPE-INFO2 element.  Since the KDC already knows the client's
+   list of supported enctypes from the  request, no interoperability
+   problems are created by choosing a single possible reply key.  This
+   way, the KDC implementation avoids the complexity of treating the
+   reply key as a set.
+
+   At the beginning of handling a message on both the client and KDC,
+   the client's identity is not authenticated.  A mechanism may indicate
+   that it has successfully authenticated the client's identity.  This
+   information is useful to keep track of on the client  in order to
+   know what preauthentication mechanisms should be used.  The KDC needs
+   to keep track of whether the client is authenticated because the
+   primary purpose of preauthentication is to authenticate the client
+   identity before issuing a ticket.  Implementations that have
+   preauthentication mechanisms offering significantly different
+   strengths of client authentication MAY choose to keep track of the
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 5]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   strength of the authentication used as an input into policy
+   decisions.  For example, some principals might require strong
+   preauthentication, while less sensitive principals can use relatively
+   weak forms of preauthentication like encrypted timestamp.
+
+   Initially the reply key has not been used.  A preauthentication
+   mechanism that uses the reply key either directly to encrypt or
+   cheksum some data or indirectly in the generation of new keys MUST
+   indicate that the reply key is used.  This state is maintained by the
+   client and KDC to enforce the security requirement stated in Section
+   3.3 that the reply key cannot be replaced after it is used.
+
+   Without preauthentication, the client knows that the KDC request is
+   authentic and has not been modified because it is encrypted in the
+   long-term key of the client.  Only the KDC and client know that key.
+   So at the start of handling any message the KDC request is presumed
+   to be verified to the client principal.  Any preauthentication
+   mechanism that sets a new reply key not based on the principal's
+   long-term secret MUST either verify the KDC response some other way
+   or indicate that the response is not verified.  If a mechanism
+   indicates that the response is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the response.  The KDC needs to track this state so it can
+   avoid generating a response that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC. Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC response that will decrypt
+   properly.  So, if the client machine needs to authenticate that the
+   user is in fact the named principal, then the client machine needs to
+   do a TGS request for itself as a service.  Some preauthentication
+   mechanisms may provide  a way for the client to authenticate the KDC.
+   Examples of this include signing the response with a well-known
+   public key or providing a ticket for the client machine as a service
+   in addition to the requested ticket.
+
+2.2 The Preauth_Required Error
+
+   Typically a client starts an authentication session by sending  an
+   initial request with no preauthentication.  If the KDC requires
+   preauthentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
+   message.  This message MAY also be returned for preauthentication
+   configurations that use multi-round-trip mechanisms.  This error
+   contains a sequence of padata.  Typically the padata contains the
+   preauth type IDs of all the available preauthentication mechanisms.
+   IN the initial error response, most mechanisms do not contain data.
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 6]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   If a mechanism requires multiple round trips or starts with a
+   challenge from the KDC to the client, then it will likely contain
+   data in the initial error response.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without preauthentication.  There
+   are few situations where preauthentication is desirable and where the
+   KDC needs to expose ciphertext encrypted in a weak key before the
+   client has proven knowledge of that key.
+
+   In order to generate the error response, the KDC first starts by
+   initializing the preauthentication state.  Then it processes any
+   padata in the client's request in the order provided by the client.
+   Mechanisms that are not understood by the KDC are ignored.
+   Mechanisms that are inappropriate for the client principal or request
+   SHOULD also be ignored.  Next, it generates padata for the error
+   response, modifying the preauthentication state appropriately as each
+   mechanism is processed.  The KDC chooses the order in which it will
+   generated padata (and thus the order of padata in the response), but
+   it needs to modify the preauthentication state consistently with the
+   choice of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the mechanisms subsequent in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.
+
+2.3 Client to KDC
+
+   This description assumes a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic preauthentication then the client needs to optimisticly
+   choose the information it would normally receive from that error
+   response.
+
+   The client starts by initializing the preauthentication state as
+   specified.  It then processes the pdata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   After processing the pdata in the KDC error, the client generates a
+   new request.  It processes the preauthentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate. When the request is complete it is sent.
+
+2.4 KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or  a AS reply.
+   There are many causes for an error to be generated that have nothing
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 7]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   to do with preauthentication; they are discussed in the Kerberos
+   specification.
+
+   From the standpoint of evaluating the preauthentication, the KDC
+   first starts by initializing the preauthentication state.  IT then
+   processes the padata in the request.  AS mentioned in Section 2.2,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.
+
+   At this point the KDC decides whether it will issue a
+   preauthentication required error or a reply.  Typically a KDC will
+   issue a reply if the client's identity has been authenticated to a
+   sufficient degree.  The processing of the preauthentication required
+   error is described in Section 2.2.
+
+   The KDC generates the pdata modifying the preauthentication state as
+   necessary.  Then it generates the final response, encrypting it in
+   the current preauthentication reply key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 8]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+3. Preauthentication Facilities
+
+   Preauthentication mechanisms can be thought of as conceptually
+   providing various facilities.  This serves two useful purposes.
+   First, mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the  abstract services that a mechanism provides
+   yields a minimum set of security requirements that all mechanisms
+   providing that facility must meet. These security requirements are
+   not complete; mechanisms will have additional security requirements
+   based on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many preauthentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than  by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.
+
+   According to Kerberos extensibility rules (section 1.4.2 of the
+   Kerberos specification [2]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular preauth mechanism when it sends an initial request, a
+   preauth mechanism MUST NOT change the semantics of the request in a
+   way that will break a KDC that does not understand that mechanism.
+   Similarly, KDCs MUST not send messages to clients that affect the
+   core semantics unless the clients have indicated support for the
+   message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect. Section
+   3.2 discusses how to design mechanisms that modify the reply key to
+   be split into a proposal and acceptance without requiring additional
+   round trips to use the new reply key in subsiquent preauthentication.
+   Other changes in the state described in Section 2.1 can safely be
+   ignored by a KDC that does not understand a mechanism.  Mechanisms
+
+
+
+Hartman                  Expires August 9, 2004                 [Page 9]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   that modify the behavior of the request outside the scope of this
+   framework need to carefully consider the Kerberos extensibility rules
+   to avoid similar problems.
+
+3.1 Client Authentication
+
+      Binding to reply key
+
+      Consider Secure ID case where you don't have anything to bind to
+
+
+3.2 Strengthen Reply Key
+
+   Particularly, when dealing with keys based on passwords it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [5].  Typically these additional secrets are
+   converted into a Kerberos protocol key.  Then they are combined with
+   the existing reply key as discussed in Section 5.1.
+
+   If a mechanism implementing this facility wishes to modify the reply
+   key before knowing that the other party in the exchange supports the
+   mechanism, it proposes modifying the reply key.  The other party then
+   includes a message indicating that the proposal is accepted if it is
+   understood and meets policy.  In many cases it is desirable to use
+   the new reply key for client authentication and for other facilities.
+   Waiting for the other party to accept the proposal and actually
+   modify the reply key state would add an additional round trip to the
+   exchange.  Instead, mechanism designers  are encouraged to include a
+   typed hole for additional padata in the message that proposes the
+   reply key change.  The padata included in the typed hole are
+   generated assuming the new reply key. If the other party accepts the
+   proposal, then these padata are interpreted as if they were included
+   immediately following the proposal.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are  are included is a matter for the mechanism specification.
+   Similarly, the format of the message accepting the proposal is
+   mechanism-specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  Typically the reply key is used to protect the
+   padata.  XXX If you are only minimally increasing the strength of the
+   reply key, this may give the attacker access to something too close
+
+
+
+Hartman                  Expires August 9, 2004                [Page 10]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   to the original reply key.  However, binding the padata to the new
+   reply key  seems potentially important from a security standpoint.
+   There may also be objections to this from a double encryption
+   standpoint because we also recommend client authentication facilities
+   be tied to the reply key.
+
+3.3 Replace Reply Key
+
+      Containers to handle reply key when not sure whether other side
+      supports mech
+
+      Make sure reply key is not used previously
+
+      Interactions with client authentication
+
+      Reference to container argument
+
+
+3.4 Verify Response
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 11]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+4. Requirements for Preauthentication Mechanisms
+
+      State management for multi-round-trip mechs
+
+      Security interactions with other mechs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 12]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+5. Tools for Use in Preauthentication Mechanisms
+
+5.1 Combine Keys
+
+5.2 Signing Requests/Responses
+
+5.3 Managing State for the KDC
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 13]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+6. IANA Considerations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 14]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+7. Security Considerations
+
+      Very little of the AS request is authenticated.  Same for padata
+      in the reply or error.  Discuss implications
+
+      Table of security requirements stated elsewhere in the document
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 15]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+8. Acknowledgements
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 16]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, BCP 14, March 1997.
+
+   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-04.txt (work in
+        progress), June 2003.
+
+   [3]  Raeburn, K., "Encryption and Checksum Specifications for
+        Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
+
+   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 17]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+Informative References
+
+   [5]  Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
+        Single-use Authentication Mechanisms with Kerberos",
+        draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
+        October 2003.
+
+
+Author's Address
+
+   Sam hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 18]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+Appendix A. Todo List
+
+      Flesh out sections that are still outlines
+
+      Discuss cookies and multiple-round-trip mechanisms.
+
+      Talk about checksum contributions from each mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 19]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+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 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.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004). 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 assignees.
+
+   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
+
+
+
+Hartman                  Expires August 9, 2004                [Page 20]
+
+Internet-Draft        Kerberos Preauth Framework           February 2004
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires August 9, 2004                [Page 21]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt
new file mode 100644
index 00000000000..a98e7e6588d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt
@@ -0,0 +1,1165 @@
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                                       MIT
+Expires: January 17, 2005                                  July 19, 2004
+
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-01
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on January 17, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+
+Abstract
+
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity  of a principal and for better protecting
+   the long-term secret of the principal.
+
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change. It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 1]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+   This document also provides common tools needed by multiple
+   pre-authentication mechanisms.
+
+
+   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 [1].
+
+
+Table of Contents
+
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  4
+     2.1   Information Managed by Model . . . . . . . . . . . . . . .  5
+     2.2   The Preauth_Required Error . . . . . . . . . . . . . . . .  7
+     2.3   Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  7
+     2.4   KDC to Client  . . . . . . . . . . . . . . . . . . . . . .  8
+   3.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . .  9
+     3.1   Client Authentication  . . . . . . . . . . . . . . . . . . 10
+     3.2   Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 10
+     3.3   Replace Reply Key  . . . . . . . . . . . . . . . . . . . . 11
+     3.4   Verify Response  . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 12
+   5.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 13
+     5.1   Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.2   Signing Requests/Responses . . . . . . . . . . . . . . . . 13
+     5.3   Managing State for the KDC . . . . . . . . . . . . . . . . 13
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 17
+   9.2   Informative References . . . . . . . . . . . . . . . . . . . 17
+   A.  Todo List  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+       Intellectual Property and Copyright Statements . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 2]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+1.  Introduction
+
+
+   The core Kerberos specification treats pre-authentication data as an
+   opaque typed hole in the messages to the KDC that may influence the
+   reply key used to encrypt the KDC response.  This generality has been
+   useful: pre-authentication data is used for a variety of extensions
+   to the protocol, many outside the expectations of the initial
+   designers.  However, this generality makes designing the more common
+   types of pre-authentication mechanisms difficult. Each mechanism
+   needs to specify how it interacts with other mechanisms.  Also,
+   problems like combining a key with the long-term secret or proving
+   the identity of the user are common to multiple mechanisms.  Where
+   there are generally well-accepted solutions to these problems, it is
+   desirable to standardize one of these solutions so mechanisms  can
+   avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  IT defines the common set of functions
+   pre-authentication mechanisms perform as well as how these functions
+   affect the state of the request and response.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [3], this framework is not complete--it does not describe all
+   the inputs and outputs for the pre-authentication mechanisms.
+   Mechanism designers should try to be consistent with this framework
+   because doing so will make their mechanisms easier to implement.
+   Kerberos implementations are likely to have plugin architectures  for
+   pre-authentication; such architectures are likely to support
+   mechanisms that follow this framework plus commonly used extensions.
+
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [3] and the core
+   Kerberos protocol [2].  This document freely uses terminology and
+   notation from these documents without reference or further
+   explanation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 3]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+2.  Model for Pre-Authentication
+
+
+   when a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial AS request.  If
+   pre-authentication is being used, then the KDC will respond with a
+   KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
+   what pre-authentication to use, it MAY optimize a round-trip and send
+   an initial request with padata included.  If the client includes the
+   wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  For
+   interoperability reasons, clients that include optimistic
+   pre-authentication MUST retry with no padata and examine the
+   KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
+   response to their initial optimistic request.
+
+
+   The KDC maintains no state between two requests; subsequent requests
+   may even be processed by a different KDC. On the other hand, the
+   client treats a series of exchanges with KDCs as a single
+   authentication session.  Each exchange accumulates state and
+   hopefully brings the client closer to a successful authentication.
+
+
+   These models for state management are in apparent conflict. For many
+   of the simpler pre-authentication scenarios,  the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful response.  For these simple scenarios,
+   the client only sends one request with pre-authentication data and so
+   the authentication session is trivial.  For more complex
+   authentication sessions, the KDC needs to provide the client with a
+   cookie to include in future requests to capture the current state of
+   the authentication session.  Handling of multiple round-trip
+   mechanisms is discussed in Section 5.3.
+
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC response.  The padata typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  These extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the pre-authentication data at each step of
+   the AS request process.
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 4]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+2.1  Information Managed by Model
+
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+   o  The reply key used to encrypt the KDC response
+   o  How strongly the identity of the client has been authenticated
+   o  Whether the reply key has been used in this authentication session
+   o  Whether the reply key has been replaced in this authentication
+      session
+   o  Whether the contents of the KDC response can be  verified by the
+      client principal
+   o  Whether the contents of the KDC response can be  verified by the
+      client machine
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in section 5.2.7.5 of the
+   Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
+   client  what types of keys are available.  Thus in full generality,
+   the reply key in the pre-authentication model is actually a set of
+   keys.  At the beginning of a request, it is initialized to the set of
+   long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC.
+   If multiple reply keys are available, the client chooses which one to
+   use.  Thus the client does not need to treat the reply key as a set.
+   At the beginning of a handling a request, the client picks a reply
+   key to use.
+
+
+   KDC implementations MAY choose to offer only one key in the
+   PA-ETYPE-INFO2 element.  Since the KDC already knows the client's
+   list of supported enctypes from the  request, no interoperability
+   problems are created by choosing a single possible reply key.  This
+   way, the KDC implementation avoids the complexity of treating the
+   reply key as a set.
+
+
+   At the beginning of handling a message on both the client and KDC,
+   the client's identity is not authenticated.  A mechanism may indicate
+   that it has successfully authenticated the client's identity.  This
+   information is useful to keep track of on the client  in order to
+   know what pre-authentication mechanisms should be used.  The KDC
+   needs to keep track of whether the client is authenticated because
+   the primary purpose of pre-authentication is to authenticate the
+   client identity before issuing a ticket.  Implementations that have
+   pre-authentication mechanisms offering significantly different
+   strengths of client authentication MAY choose to keep track of the
+   strength of the authentication used as an input into policy
+   decisions.  For example, some principals might require strong
+   pre-authentication, while less sensitive principals can use
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 5]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key either directly to encrypt or
+   checksum some data or indirectly in the generation of new keys MUST
+   indicate that the reply key is used.  This state is maintained by the
+   client and KDC to enforce the security requirement stated in Section
+   3.3 that the reply key cannot be replaced after it is used.
+
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 3.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced. Once the reply key has been replaced, knowledge of the
+   reply key is insufficient to authenticate the client. The reply key
+   is marked replaced in exactly the same situations as the KDC reply
+   is marked as not being verified to the client principal.  However,
+   while mechanisms can verify the KDC request to the client, once the
+   reply key is replaced, then the reply key remains replaced for the
+   remainder of the authentication session.
+
+
+   Without pre-authentication, the client knows that the KDC request is
+   authentic and has not been modified because it is encrypted in the
+   long-term key of the client.  Only the KDC and client know that key.
+   So at the start of handling any message the KDC request is presumed
+   to be verified to the client principal.  Any pre-authentication
+   mechanism that sets a new reply key not based on the principal's
+   long-term secret MUST either verify the KDC response some other way
+   or indicate that the response is not verified.  If a mechanism
+   indicates that the response is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the response.  The KDC needs to track this state so it can
+   avoid generating a response that is not verified.
+
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC. Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC response that will decrypt
+   properly.  So, if the client machine needs to authenticate that the
+   user is in fact the named principal, then the client machine needs to
+   do a TGS request for itself as a service.  Some pre-authentication
+   mechanisms may provide  a way for the client to authenticate the KDC.
+   Examples of this include signing the response with a well-known
+   public key or providing a ticket for the client machine as a service
+   in addition to the requested ticket.
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 6]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+2.2  The Preauth_Required Error
+
+
+   Typically a client starts an authentication session by sending  an
+   initial request with no pre-authentication.  If the KDC requires
+   pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
+   message.  This message MAY also be returned for pre-authentication
+   configurations that use multi-round-trip mechanisms.  This error
+   contains a sequence of padata.  Typically the padata contains the
+   pre-authentication type IDs of all the available pre-authentication
+   mechanisms.  IN the initial error response, most mechanisms do not
+   contain data.  If a mechanism requires multiple round trips or starts
+   with a challenge from the KDC to the client, then it will likely
+   contain data in the initial error response.
+
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where pre-authentication is desirable and where
+   the KDC needs to expose ciphertext encrypted in a weak key before the
+   client has proven knowledge of that key.
+
+
+   In order to generate the error response, the KDC first starts by
+   initializing the pre-authentication state.  Then it processes any
+   padata in the client's request in the order provided by the client.
+   Mechanisms that are not understood by the KDC are ignored.
+   Mechanisms that are inappropriate for the client principal or request
+   SHOULD also be ignored.  Next, it generates padata for the error
+   response, modifying the pre-authentication state appropriately as
+   each mechanism is processed.  The KDC chooses the order in which it
+   will generated padata (and thus the order of padata in the response),
+   but it needs to modify the pre-authentication state consistently with
+   the choice of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the mechanisms subsequent in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.
+
+
+2.3  Client to KDC
+
+
+   This description assumes a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to optimisticly
+   choose the information it would normally receive from that error
+   response.
+
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the pdata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 7]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+   After processing the pdata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate. When the request is complete it is sent.
+
+
+2.4  KDC to Client
+
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or  a AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the Kerberos
+   specification.
+
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  IT then
+   processes the padata in the request.  AS mentioned in Section 2.2,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.
+
+
+   At this point the KDC decides whether it will issue a
+   pre-authentication required error or a reply.  Typically a KDC will
+   issue a reply if the client's identity has been authenticated to a
+   sufficient degree.  The processing of the pre-authentication required
+   error is described in Section 2.2.
+
+
+   The KDC generates the pdata modifying the pre-authentication state as
+   necessary.  Then it generates the final response, encrypting it in
+   the current pre-authentication reply key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 8]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+3.  Pre-Authentication Facilities
+
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the  abstract services that a 2mechanism provides
+   yields a minimum set of security requirements that all mechanisms
+   providing that facility must meet. These security requirements are
+   not complete; mechanisms will have additional security requirements
+   based on the specific protocol they employ.
+
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than  by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.
+
+
+   According to Kerberos extensibility rules (section 1.4.2 of the
+   Kerberos specification [2]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a preauth mechanism MUST NOT change the semantics of the
+   request in a way that will break a KDC that does not understand that
+   mechanism.  Similarly, KDCs MUST not send messages to clients that
+   affect the core semantics unless the clients have indicated support
+   for the message.
+
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect. Section
+   3.2 discusses how to design mechanisms that modify the reply key to
+   be split into a proposal and acceptance without requiring additional
+   round trips to use the new reply key in subsequent
+   pre-authentication. Other changes in the state described in Section
+   2.1 can safely be ignored by a KDC that does not understand a
+
+
+
+
+Hartman                 Expires January 17, 2005                [Page 9]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+   mechanism.  Mechanisms that modify the behavior of the request
+   outside the scope of this framework need to carefully consider the
+   Kerberos extensibility rules to avoid similar problems.
+
+
+3.1  Client Authentication
+
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [2] and the
+   single-use mechanism defined in [5]. Mechanisms that provide this
+   facility are expected to mark the client  as authenticated.
+
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge  of the reply key before transmitting a successful
+   KDC reply.  Otherwise, an attacker can intercept the
+   pre-authentication exchange and get a reply to attack.  One way of
+   proving the client knows the reply key is to implement the Replace
+   Reply Key facility along with this facility.  The Pkinit mechanism
+   [6] implements Client Authentication along side Replace Reply Key.
+
+
+   If the reply key has been replaced, then mechanisms such as encrypted
+   timestamp that rely on knowledge of the reply key to authenticate the
+   client MUST NOT be used.
+
+
+3.2  Strengthen Reply Key
+
+
+   Particularly, when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [5].  Typically these additional secrets are
+   converted into a Kerberos protocol key.  Then they are combined with
+   the existing reply key as discussed in Section 5.1.
+
+
+   If a mechanism implementing this facility wishes to modify the reply
+   key before knowing that the other party in the exchange supports the
+   mechanism, it proposes modifying the reply key.  The other party then
+   includes a message indicating that the proposal is accepted if it is
+   understood and meets policy.  In many cases it is desirable to use
+   the new reply key for client authentication and for other facilities.
+   Waiting for the other party to accept the proposal and actually
+   modify the reply key state would add an additional round trip to the
+   exchange.  Instead, mechanism designers  are encouraged to include a
+   typed hole for additional padata in the message that proposes the
+   reply key change.  The padata included in the typed hole are
+   generated assuming the new reply key. If the other party accepts the
+   proposal, then these padata are interpreted as if they were included
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 10]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+   immediately following the proposal.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+
+   The specific formats of the proposal message, including where padata
+   are  are included is a matter for the mechanism specification.
+   Similarly, the format of the message accepting the proposal is
+   mechanism-specific.
+
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  Typically the reply key is used to protect the
+   padata.  XXX If you are only minimally increasing the strength of the
+   reply key, this may give the attacker access to something too close
+   to the original reply key.  However, binding the padata to the new
+   reply key  seems potentially important from a security standpoint.
+   There may also be objections to this from a double encryption
+   standpoint because we also recommend client authentication facilities
+   be tied to the reply key.
+
+
+3.3  Replace Reply Key
+
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.    This facility can only be used in
+   cases where knowledge of the reply key is not used to authenticate
+   the client.  The new reply key MUST be communicated to the client and
+   KDC in a secure manner.    Mechanisms implementing this facility MUST
+   mark the reply key as replaced in the pre-authentication state.
+   Mechanisms implementing this facility MUST either provide a mechanism
+   to verify the KDC reply to the client or mark the reply as unverified
+   in the pre-authentication state. Mechanisms implementing this
+   facility SHOULD NOT be used if a previous mechanism has used the
+   reply key.
+
+
+   As with the Strengthen Reply Key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be more common for both sides to know that the
+   facility is available by the time that the new key is available to be
+   used.  However, mechanism designers can use a container for padata in
+   a proposal message as discussed in Section 3.2 if appropriate.
+
+
+3.4  Verify Response
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 11]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+4.  Requirements for Pre-Authentication Mechanisms
+
+
+      State management for multi-round-trip mechs
+      Security interactions with other mechs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 12]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+5.  Tools for Use in Pre-Authentication Mechanisms
+
+
+5.1  Combine Keys
+
+
+5.2  Signing Requests/Responses
+
+
+5.3  Managing State for the KDC
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 13]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+6.  IANA Considerations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 14]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+7.  Security Considerations
+
+
+      Very little of the AS request is authenticated.  Same for padata
+      in the reply or error.  Discuss implications
+      Table of security requirements stated elsewhere in the document
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 15]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+8.  Acknowledgements
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 16]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+9.  References
+
+
+9.1  Normative References
+
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, BCP 14, March 1997.
+
+
+   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
+        progress), June 2004.
+
+
+   [3]  Raeburn, K., "Encryption and Checksum Specifications for
+        Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
+
+
+   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+
+9.2  Informative References
+
+
+   [5]  Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
+        Single-use Authentication Mechanisms with Kerberos",
+        draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
+        October 2003.
+
+
+   [6]  Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky,
+        "Public Key Cryptography for Initial Authentication in
+        Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in
+        progress), April 2004.
+
+
+
+Author's Address
+
+
+   Sam hartman
+   MIT
+
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 17]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+Appendix A.  Todo List
+
+
+      Flesh out sections that are still outlines
+      Discuss cookies and multiple-round-trip mechanisms.
+      Talk about checksum contributions from each mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 18]
+Internet-Draft        Kerberos Preauth Framework               July 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights. Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard. Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004). This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                 Expires January 17, 2005               [Page 19] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
new file mode 100644
index 00000000000..e3f81542dbb
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
@@ -0,0 +1,1178 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                                       MIT
+Expires: April 24, 2005                                 October 24, 2004
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-02
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on April 24, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity  of a principal and for better protecting
+   the long-term secret of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 1]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple
+   pre-authentication mechanisms.
+
+   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 [1].
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  4
+     2.1   Information Managed by Model . . . . . . . . . . . . . . .  5
+     2.2   The Initial Preauth_Required Error . . . . . . . . . . . .  7
+     2.3   Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  8
+     2.4   KDC to Client  . . . . . . . . . . . . . . . . . . . . . .  8
+   3.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
+     3.1   Client Authentication  . . . . . . . . . . . . . . . . . . 11
+     3.2   Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 11
+     3.3   Replace Reply Key  . . . . . . . . . . . . . . . . . . . . 12
+     3.4   Verify Response  . . . . . . . . . . . . . . . . . . . . . 12
+   4.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
+   5.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
+     5.1   Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 15
+     5.2   Signing Requests/Responses . . . . . . . . . . . . . . . . 15
+     5.3   Managing State for the KDC . . . . . . . . . . . . . . . . 15
+     5.4   PA-AUTHENTICATION-SET  . . . . . . . . . . . . . . . . . . 15
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 19
+   9.2   Informative References . . . . . . . . . . . . . . . . . . . 19
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
+   A.  Todo List  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+       Intellectual Property and Copyright Statements . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 2]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+1.  Introduction
+
+   The core Kerberos specification treats pre-authentication data as an
+   opaque typed hole in the messages to the KDC that may influence the
+   reply key used to encrypt the KDC response.  This generality has been
+   useful: pre-authentication data is used for a variety of extensions
+   to the protocol, many outside the expectations of the initial
+   designers.  However, this generality makes designing the more common
+   types of pre-authentication mechanisms difficult.  Each mechanism
+   needs to specify how it interacts with other mechanisms.  Also,
+   problems like combining a key with the long-term secret or proving
+   the identity of the user are common to multiple mechanisms.  Where
+   there are generally well-accepted solutions to these problems, it is
+   desirable to standardize one of these solutions so mechanisms  can
+   avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  IT defines the common set of functions
+   pre-authentication mechanisms perform as well as how these functions
+   affect the state of the request and response.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [3], this framework is not complete--it does not describe all
+   the inputs and outputs for the pre-authentication mechanisms.
+   Mechanism designers should try to be consistent with this framework
+   because doing so will make their mechanisms easier to implement.
+   Kerberos implementations are likely to have plugin architectures  for
+   pre-authentication; such architectures are likely to support
+   mechanisms that follow this framework plus commonly used extensions.
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [3] and the core
+   Kerberos protocol [2].  This document freely uses terminology and
+   notation from these documents without reference or further
+   explanation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 3]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+2.  Model for Pre-Authentication
+
+   when a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial AS request.  If
+   pre-authentication is being used, then the KDC will respond with a
+   KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
+   what pre-authentication to use, it MAY optimize a round-trip and send
+   an initial request with padata included.  If the client includes the
+   wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  For
+   interoperability reasons, clients that include optimistic
+   pre-authentication MUST retry with no padata and examine the
+   KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
+   response to their initial optimistic request.
+
+   The KDC maintains no state between two requests; subsequent requests
+   may even be processed by a different KDC.  On the other hand, the
+   client treats a series of exchanges with KDCs as a single
+   authentication session.  Each exchange accumulates state and
+   hopefully brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios,  the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful response.  For these simple scenarios,
+   the client only sends one request with pre-authentication data and so
+   the authentication session is trivial.  For more complex
+   authentication sessions, the KDC needs to provide the client with a
+   cookie to include in future requests to capture the current state of
+   the authentication session.  Handling of multiple round-trip
+   mechanisms is discussed in Section 5.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC response.  The padata typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  These extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the pre-authentication data at each step of
+   the AS request process.
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 4]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+2.1  Information Managed by Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+   o  The reply key used to encrypt the KDC response
+   o  How strongly the identity of the client has been authenticated
+   o  Whether the reply key has been used in this authentication session
+   o  Whether the reply key has been replaced in this authentication
+      session
+   o  Whether the contents of the KDC response can be  verified by the
+      client principal
+   o  Whether the contents of the KDC response can be  verified by the
+      client machine
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in section 5.2.7.5 of the
+   Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
+   client  what types of keys are available.  Thus in full generality,
+   the reply key in the pre-authentication model is actually a set of
+   keys.  At the beginning of a request, it is initialized to the set of
+   long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC.
+   If multiple reply keys are available, the client chooses which one to
+   use.  Thus the client does not need to treat the reply key as a set.
+   At the beginning of a handling a request, the client picks a reply
+   key to use.
+
+   KDC implementations MAY choose to offer only one key in the
+   PA-ETYPE-INFO2 element.  Since the KDC already knows the client's
+   list of supported enctypes from the  request, no interoperability
+   problems are created by choosing a single possible reply key.  This
+   way, the KDC implementation avoids the complexity of treating the
+   reply key as a set.
+
+   At the beginning of handling a message on both the client and KDC,
+   the client's identity is not authenticated.  A mechanism may indicate
+   that it has successfully authenticated the client's identity.  This
+   information is useful to keep track of on the client  in order to
+   know what pre-authentication mechanisms should be used.  The KDC
+   needs to keep track of whether the client is authenticated because
+   the primary purpose of pre-authentication is to authenticate the
+   client identity before issuing a ticket.  Implementations that have
+   pre-authentication mechanisms offering significantly different
+   strengths of client authentication MAY choose to keep track of the
+   strength of the authentication used as an input into policy
+   decisions.  For example, some principals might require strong
+   pre-authentication, while less sensitive principals can use
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 5]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key either directly to encrypt or
+   checksum some data or indirectly in the generation of new keys MUST
+   indicate that the reply key is used.  This state is maintained by the
+   client and KDC to enforce the security requirement stated in Section
+   3.3 that the reply key cannot be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 3.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply  is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC request to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the authentication session.
+
+   Without pre-authentication, the client knows that the KDC request is
+   authentic and has not been modified because it is encrypted in the
+   long-term key of the client.  Only the KDC and client know that key.
+   So at the start of handling any message the KDC request is presumed
+   to be verified to the client principal.  Any pre-authentication
+   mechanism that sets a new reply key not based on the principal's
+   long-term secret MUST either verify the KDC response some other way
+   or indicate that the response is not verified.  If a mechanism
+   indicates that the response is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the response.  The KDC needs to track this state so it can
+   avoid generating a response that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC response that will decrypt
+   properly.  So, if the client machine needs to authenticate that the
+   user is in fact the named principal, then the client machine needs to
+   do a TGS request for itself as a service.  Some pre-authentication
+   mechanisms may provide  a way for the client to authenticate the KDC.
+   Examples of this include signing the response with a well-known
+   public key or providing a ticket for the client machine as a service
+   in addition to the requested ticket.
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 6]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+2.2  The Initial Preauth_Required Error
+
+   Typically a client starts an authentication session by sending  an
+   initial request with no pre-authentication.  If the KDC requires
+   pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
+   message.  This message MAY also be returned for pre-authentication
+   configurations that use multi-round-trip mechanisms; see Section 2.4
+   for details of that case.  This
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C.  A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.  The KDC MAY include any initial
+   data for the mechanisms.
+
+   The KDC includes a a PA-AUTHENTICATION-SET padata element for each
+   authentication set; this element is defined in Section 5.4.  This
+   element includes the pa-type and pa-value for the first mechanism in
+   the authentication set.  It also includes the  pa-type for each of
+   the other mechanisms.  Associated with the second and following
+   pa-type is a pa-hint, which is an octet-string specified by the
+   pre-authentication mechanism.  This hint may provide information for
+   the client which helps it determine whether the mechanism can be
+   used.  For example a public-key mechanism might include the
+   certificate authorities it trusts in the hint info.  Most mechanisms
+   today do not  specify hint info; if a mechanism does not specify hint
+   info the KDC MUST not send a hint for that mechanism.  To allow
+   future revisions of mechanism specifications to add hint info,
+   clients MUST ignore hint info received for mechanisms that the client
+   believes do not support hint info.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where pre-authentication is desirable and where
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 7]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   the KDC needs to expose ciphertext encrypted in a weak key before the
+   client has proven knowledge of that key.
+
+2.3  Client to KDC
+
+   This description assumes a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to optimisticly
+   choose the information it would normally receive from that error
+   response.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the first KDC_ERR_PREAUTH_REQUIRED,
+   the client MAY ignore any padata it chooses unless doing so violates
+   a specification to which the client conforms.  Clients MUST NOT
+   ignore the padata defined in Section 5.3.  Clients SHOULD  process
+   padata unrelated to this framework or other means of authenticating
+   the user.  Clients SHOULD choose one authentication set or mechanism
+   that could lead to authenticating the user and ignore the rest.
+   Since the set of mechanisms offered by the KDC is ordered, clients
+   typically choose the first mechanism that the client can usefully
+   perform.  If a client chooses to ignore a padata it MUST NOT process
+   the padata, allow the padata to affect the pre-authentication state,
+   nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  When the request is complete it is sent.
+
+2.4  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or  a AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the Kerberos
+   specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  IT then
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 8]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   processes the padata in the request.  AS mentioned in Section 2.2,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.
+
+   At this point the KDC decides whether it will issue a
+   pre-authentication required error or a reply.  Typically a KDC will
+   issue a reply if the client's identity has been authenticated to a
+   sufficient degree.
+
+   In the case of a PREAUTH_REQUIRED error, the KDC first starts by
+   initializing the pre-authentication state.  Then it processes any
+   padata in the client's request in the order provided by the client.
+   Mechanisms that are not understood by the KDC are ignored.
+   Mechanisms that are inappropriate for the client principal or request
+   SHOULD also be ignored.  Next, it generates padata for the error
+   response, modifying the pre-authentication state appropriately as
+   each mechanism is processed.  The KDC chooses the order in which it
+   will generated padata (and thus the order of padata in the response),
+   but it needs to modify the pre-authentication state consistently with
+   the choice of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the mechanisms subsequent in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the second and
+   following PREAUTH_REQUIRED errors in an authentication session will
+   include KDC state as discussed in Section 5.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                 [Page 9]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+3.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the  abstract services that a 2mechanism provides
+   yields a minimum set of security requirements that all mechanisms
+   providing that facility must meet.  These security requirements are
+   not complete; mechanisms will have additional security requirements
+   based on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than  by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.
+
+   According to Kerberos extensibility rules (section 1.4.2 of the
+   Kerberos specification [2]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a preauth mechanism MUST NOT change the semantics of the
+   request in a way that will break a KDC that does not understand that
+   mechanism.  Similarly, KDCs MUST not send messages to clients that
+   affect the core semantics unless the clients have indicated support
+   for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 3.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent
+   pre-authentication.  Other changes in the state described in Section
+   2.1 can safely be ignored by a KDC that does not understand a
+
+
+
+Hartman                  Expires April 24, 2005                [Page 10]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   mechanism.  Mechanisms that modify the behavior of the request
+   outside the scope of this framework need to carefully consider the
+   Kerberos extensibility rules to avoid similar problems.
+
+3.1  Client Authentication
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [2] and the
+   single-use mechanism defined in [5].  Mechanisms that provide this
+   facility are expected to mark the client  as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge  of the reply key before transmitting a successful
+   KDC reply.  Otherwise, an attacker can intercept the
+   pre-authentication exchange and get a reply to attack.  One way of
+   proving the client knows the reply key is to implement the Replace
+   Reply Key facility along with this facility.  The Pkinit mechanism
+   [6] implements Client Authentication along side Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as encrypted
+   timestamp that rely on knowledge of the reply key to authenticate the
+   client MUST NOT be used.
+
+3.2  Strengthen Reply Key
+
+   Particularly, when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [5].  Typically these additional secrets are
+   converted into a Kerberos protocol key.  Then they are combined with
+   the existing reply key as discussed in Section 5.1.
+
+   If a mechanism implementing this facility wishes to modify the reply
+   key before knowing that the other party in the exchange supports the
+   mechanism, it proposes modifying the reply key.  The other party then
+   includes a message indicating that the proposal is accepted if it is
+   understood and meets policy.  In many cases it is desirable to use
+   the new reply key for client authentication and for other facilities.
+   Waiting for the other party to accept the proposal and actually
+   modify the reply key state would add an additional round trip to the
+   exchange.  Instead, mechanism designers  are encouraged to include a
+   typed hole for additional padata in the message that proposes the
+   reply key change.  The padata included in the typed hole are
+   generated assuming the new reply key.  If the other party accepts the
+   proposal, then these padata are interpreted as if they were included
+
+
+
+Hartman                  Expires April 24, 2005                [Page 11]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   immediately following the proposal.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are  are included is a matter for the mechanism specification.
+   Similarly, the format of the message accepting the proposal is
+   mechanism-specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  Typically the reply key is used to protect the
+   padata.  XXX If you are only minimally increasing the strength of the
+   reply key, this may give the attacker access to something too close
+   to the original reply key.  However, binding the padata to the new
+   reply key  seems potentially important from a security standpoint.
+   There may also be objections to this from a double encryption
+   standpoint because we also recommend client authentication facilities
+   be tied to the reply key.
+
+3.3  Replace Reply Key
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and KDC
+   in a secure manner.  Mechanisms implementing this facility MUST mark
+   the reply key as replaced in the pre-authentication state.
+   Mechanisms implementing this facility MUST either provide a mechanism
+   to verify the KDC reply to the client or mark the reply as unverified
+   in the pre-authentication state.  Mechanisms implementing this
+   facility SHOULD NOT be used if a previous mechanism has used the
+   reply key.
+
+   As with the Strengthen Reply Key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be more common for both sides to know that the
+   facility is available by the time that the new key is available to be
+   used.  However, mechanism designers can use a container for padata in
+   a proposal message as discussed in Section 3.2 if appropriate.
+
+3.4  Verify Response
+
+   This facility verifies that the response comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the ticket can be decrypted then the client knows that a trusted KDC
+   responded.  Note that the client machine cannot trust the client
+
+
+
+Hartman                  Expires April 24, 2005                [Page 12]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+   unless the machine retrieves a service ticket for itself.  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Mechanisms providing this facility provide such a
+   mechanism.  They mark the pre-authentication state as having been
+   verified; they may also mark it as verified to the client host.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 13]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+4.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of
+   pre-authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes  the pa-type value to be used and the
+   contents of the message.  The processing  of the message my the
+   sender and recipient is also specified.  This specification needs to
+   include all modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent as part of the
+   first KDC_ERR_PREAUTH_REQUIRED or as part of an authentication set.
+   If the client will need information such as available certificate
+   authorities in order to determine if it can use the mechanism, then
+   this information should be in that first message.  IN addition, such
+   mechanisms should also define a pa-hint to be included in
+   authentication sets when the mechanism is not the first mechanism in
+   the authentication set.  Often, the same information included in the
+   first pa-value is appropriate to include in the pa-hint.
+
+   In order to ease in security analysis the mechanism specification
+   should describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security considerations section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 14]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+5.  Tools for Use in Pre-Authentication Mechanisms
+
+5.1  Combine Keys
+
+5.2  Signing Requests/Responses
+
+5.3  Managing State for the KDC
+
+5.4  PA-AUTHENTICATION-SET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 15]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+6.  IANA Considerations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 16]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+7.  Security Considerations
+
+      Very little of the AS request is authenticated.  Same for padata
+      in the reply or error.  Discuss implications
+      Table of security requirements stated elsewhere in the document
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 17]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+8.  Acknowledgements
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 18]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, BCP 14, March 1997.
+
+   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
+        progress), June 2004.
+
+   [3]  Raeburn, K., "Encryption and Checksum Specifications for
+        Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
+
+   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+9.2  Informative References
+
+   [5]  Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
+        Single-use Authentication Mechanisms with Kerberos",
+        draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
+        October 2003.
+
+   [6]  Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky,
+        "Public Key Cryptography for Initial Authentication in
+        Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in
+        progress), April 2004.
+
+
+Author's Address
+
+   Sam hartman
+   MIT
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 19]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+Appendix A.  Todo List
+
+      Flesh out sections that are still outlines
+      Discuss cookies and multiple-round-trip mechanisms.
+      Talk about checksum contributions from each mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 20]
+
+Internet-Draft        Kerberos Preauth Framework            October 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hartman                  Expires April 24, 2005                [Page 21]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt
new file mode 100644
index 00000000000..2354a5926a4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt
@@ -0,0 +1,1830 @@
+
+
+Kerberos Working Group                                            L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                                   S. Hartman
+Intended status: Standards Track                                     MIT
+Expires: April 28, 2007                                 October 25, 2006
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-04
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 28, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secret of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of such tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism,
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is straightforward to chain multiple authentication factors
+   or add a plugin to, for example, utilize a different key management
+   system, or support a new key agreement algorithm.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
+     3.1.  Information Managed by the Pre-authentication Model  . . .  6
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 11
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 17
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 18
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 19
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 20
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 21
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 24
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 27
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 28
+   Appendix A.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 28
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   Intellectual Property and Copyright Statements . . . . . . . . . . 32
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secret or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriated.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata.  FAST provides a protected channel between
+   the client and the KDC, and it also delivers a reply key within the
+   protected channel.  Based on FAST, pre-authentication mechanisms can
+   extend Kerberos with ease, to support, for example, password
+   authenticated key exchange (PAKE) protocols with zero knowledge
+   password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication
+   mechanism can be encapsulated in the padata field Section 6.5 of
+   FAST.  A pre-authentication type thus carried within FAST is called a
+   FAST factor.  A FAST factor MUST NOT be used outside of FAST unless
+   its specification explicitly allows so.  Note that FAST without a
+   FAST factor for authentication does NOT by itself authenticate the
+   client or the KDC.
+
+   New pre-authentication mechanisms SHOULD design FAST factors, instead
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   of full-blown pre-authentication mechanisms.
+
+   A conversation consists of all messages that are necessary to
+   complete the mutual authentication between the client and the KDC.  A
+   conversation is the smallest logic unit for messages exchanged
+   between the client and the KDC.  The KDC need to manage mulitple
+   authentication sets frequently need to keep track of KDC states
+   during a convesation, standard solutions are provided for these
+   common problems.
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document freely uses terminology
+   and notation from these documents without reference or further
+   explanation.
+
+
+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 [RFC2119].
+
+   The word padata is used as the shorthand of pre-authentication data.
+   A conversation is used to refer to all authentication messages
+   exchanged between the client and the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data as
+   that of the KDC_ERR_PREAUTH_REQUIRED error, and then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   single authentication session.  Each exchange accumulates state and
+   hopefully brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   authentication session is trivial.  For more complex authentication
+   sessions, the KDC needs to provide the client with a cookie to
+   include in future requests to capture the current state of the
+   authentication session.  Handling of multiple round-trip mechanisms
+   is discussed in Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this authentication session
+
+   o  Whether the reply key has been replaced in this authentication
+      session
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client machine
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a handling a request, the client
+   picks a reply key to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key either directly to encrypt or
+   checksum some data or indirectly in the generation of new keys MUST
+   indicate that the reply key is used.  This state is maintained by the
+   client and the KDC to enforce the security requirement stated in
+   Section 4.3 that the reply key cannot be used after it is replaced.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the authentication session.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of handling any message the KDC reply is
+   presumed to be verified using the client principal's long-term key.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client to authenticate the KDC.  Examples
+   of this include signing the reply with a well-known public key or
+   providing a ticket for the client machine as a service in addition to
+   the requested ticket.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts an authentication session by sending an
+   initial request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED for
+   pre-authentication configurations that use multi-round-trip
+   mechanisms; see Section 3.4 for details of that case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where pre-authentication is desirable and where
+   the KDC needs to expose cipher text encrypted in a weak key before
+   the client has proven knowledge of that key.
+
+3.3.  Client to KDC
+
+   This description assumes a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to optimistically
+   choose the information it would normally receive from that error
+   response.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients MUST NOT ignore
+   the padata defined in Section 6.3.  Clients SHOULD process padata
+   unrelated to this framework or other means of authenticating the
+   user.  Clients SHOULD choose one authentication set or mechanism that
+   could lead to authenticating the user and ignore the rest.  Since the
+   list of mechanisms offered by the KDC is in the decreasing preference
+   order, clients typically choose the first mechanism that the client
+   can usefully perform.  If a client chooses to ignore a padata it MUST
+   NOT process the padata, allow the padata to affect the pre-
+   authentication state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+
+
+
+Zhu & Hartman            Expires April 28, 2007                 [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or a AS reply.  There
+   are many causes for an error to be generated that have nothing to do
+   with pre-authentication; they are discussed in the core Kerberos
+   specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  It then
+   processes the padata in the request.  As mentioned in Section 3.3,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.
+
+   At this point the KDC decides whether it will issue a pre-
+   authentication required error or a reply.  Typically a KDC will issue
+   a reply if the client's identity has been authenticated to a
+   sufficient degree.
+
+   In the case of a KDC_ERR_PREAUTH_REQUIRED error, the KDC first starts
+   by initializing the pre-authentication state.  Then it processes any
+   padata in the client's request in the order provided by the client.
+   Mechanisms that are not understood by the KDC are ignored.
+   Mechanisms that are inappropriate for the client principal or the
+   request SHOULD also be ignored.  Next, it generates padata for the
+   error response, modifying the pre-authentication state appropriately
+   as each mechanism is processed.  The KDC chooses the order in which
+   it will generate padata (and thus the order of padata in the
+   response), but it needs to modify the pre-authentication state
+   consistently with the choice of order.  For example, if some
+   mechanism establishes an authenticated client identity, then the
+   subsequent mechanisms in the generated response receive this state as
+   input.  After the padata is generated, the error response is sent.
+   Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   in a converstation will include KDC state as discussed in
+   Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST not send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly, when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [RFC4556].  Typically these additional secrets can be
+   first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   If a mechanism implementing this facility wishes to modify the reply
+   key before knowing that the other party in the exchange supports the
+   mechanism, it proposes modifying the reply key.  The other party then
+   includes a message indicating that the proposal is accepted if it is
+   understood and meets policy.  In many cases it is desirable to use
+   the new reply key for client authentication and for other facilities.
+   Waiting for the other party to accept the proposal and actually
+   modify the reply key state would add an additional round trip to the
+   exchange.  Instead, mechanism designers are encouraged to include a
+   typed hole for additional padata in the message that proposes the
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   reply key change.  The padata included in the typed hole are
+   generated assuming the new reply key.  If the other party accepts the
+   proposal, then these padata are interpreted as if they were included
+   immediately following the proposal.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are are included is a matter for the mechanism specification.
+   Similarly, the format of the message accepting the proposal is
+   mechanism-specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  Typically the reply key is used to protect the
+   padata.  If you are only minimally increasing the strength of the
+   reply key, this may give the attacker access to something too close
+   to the original reply key.  However, binding the padata to the new
+   reply key seems potentially important from a security standpoint.
+   There may also be objections to this from a double encryption
+   standpoint because we also recommend client authentication facilities
+   be tied to the reply key.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  Mechanisms implementing this facility MUST
+   mark the reply key as replaced in the pre-authentication state.
+   Mechanisms implementing this facility MUST either provide a mechanism
+   to verify the KDC reply to the client or mark the reply as unverified
+   in the pre-authentication state.  Mechanisms implementing this
+   facility SHOULD NOT be used if a previous mechanism has used the
+   reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be more common for both sides to know that the
+   facility is available by the time that the new key is available to be
+   used.  However, mechanism designers can use a container for padata in
+   a proposal message as discussed in Section 4.2 if appropriate.
+
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client need information such as, for
+   example, trusted certificate authorities in order to determine if it
+   can use the mechanism, then this information should be in that
+   message.  In addition, such mechanisms should also define a pa-hint
+   to be included in authentication sets.  Often, the same information
+   included in the padata-value is appropriate to include in the pa-
+   hint.
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that is used in FAST to provide
+   authentication information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key need to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets
+   to it.  Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+    KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+    KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   The function KRB-FX-CF2() produces a new key based on two existing
+   keys of the same enctype and it is base on a secure hash function and
+   the primitives encrypt(), random-to-key() and K-truncate() described
+   in [RFC3961].
+
+    KRB-FX-CF2(protocol key, protocol key, octet string) ->
+                  (resulting key)
+
+   The KRB-FX-CF2() function takes two protocol keys and an octet string
+   as input, and output a new key of the same enctype.
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+    encrypt(B, initial-cipher-state, pepper) -> (state-1, cipher-text-1)
+
+    encrypt(A, initial-cipher-state, pepper) -> (state-2, cipher-text-2)
+
+    PRF+(H, cipher-text-1 | cipher-text-2) -> bitstring-1
+
+    K-truncate(cipher-text-1) -> bitstring-2
+
+    random-to-key(bitstring-2) -> final-key
+
+    KRB-FX-CF2(A, B, pepper) -> final-key
+
+   Where initial-cipher-state is defined in [RFC3961] and the key-
+   generation seed length K is specified by the enctype profile
+   [RFC3961].  The value of the parameter pepper is RECOMMENDED to be in
+   the form of contextID || SharedInfo per guidelines in [HKDF].  If the
+   value of pepper is too short for the encrypt() primitive, it MUST
+   first be padded with all zeroes to the next shortest length that
+   encryt() can operate on.  PRF+() produces a bit-string of at least K
+   bits in length.
+
+   H is the secure hash function associated with the enctype.  An
+   example of a secure hash function is SHA-256 [SHA2].
+
+   This document updates [RFC3961] to associate a secure hash function
+   with every enctype.  Unless otherwise specified by the enctype
+   specification, the associated hash function is SHA-256.  The
+   associated hash function for hmac-sha1-96-aes256 is SHA-512 [SHA2].
+
+        encryption type       etype       associated hash function
+      --------------------------------------------------------------
+      hmac-sha1-96-aes256      16             SHA-512 [SHA2]
+
+   PRF+ is defined as follows:
+
+     PRF+(secure hash function, octet string) -> (octet string)
+
+     PRF+(H, shared-info) -> H( 1 || shared-info ) ||
+        H( 2 || shared-info ) H ( 3 || shared-info ) || ...
+
+   Where the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.
+
+   Mechanism designers MUST specify the pepper value when combining two
+   keys using KRB-FX-CF2().
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD provide integrity protection of the
+   messages in a conversation whenever feasible
+
+   Sensitive data MUST be encrypted when sent over the wire.  Non-
+   sensitive data that have privacy implications are encouraged to be
+   encrypted as well.
+
+   If there are more than one roundtrip for an authentication exchange,
+   mechanism designers SHOULD allow either the client or the KDC provide
+   a checksum of all the messages exchanged on the wire, that is then
+   verified by the receiver.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   have the benefit of crypto-agility provided by [RFC3961].  The
+   advantage afforded by crypto-agility is the ability to avoid a multi-
+   year standardization and deployment cycle to fix a problem specific
+   to a particular algorithm, when real attacks do arise against that
+   algorithm.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+6.3.  Managing States for the KDC
+
+   For any conversation that consists of more than two messages, the KDC
+   likely need to keep track of KDC states for incomplete authentication
+   exchanges and destroy the states of a conversation when the
+   authentication completes successful or fails, or the KDC times out.
+   When the KDC times out, the KDC returns an error message with the
+   code KDC_ERR_PREAUTH_TIMED_OUT.
+
+       KDC_ERR_PREAUTH_TIMED_OUT           TBA
+
+   Upnon receipt of this error, the client MUST abort the existing
+   conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC need to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE pdata type is defined in this section to facilitate
+   state management.
+
+       PA_FX_COOKIE                        TBA
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   The corresponding padata-value field [RFC4120] contains the
+   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
+   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
+
+     PA-FX-COOKIE ::= SEQUENCE {
+         Cookie          [1] OCTET STRING,
+             -- Opaque data, for use to associate all the messages in a
+             -- single conversation between the client and the KDC.
+             -- This can be generated by either the client or the KDC.
+             -- The receiver MUST copy the exact Cookie encapsulated in
+             -- a PA_FX_COOKIE data element into the next message of the
+             -- same conversation.
+         ...
+     }
+
+   The PA-FX-COOKIE structure contains an opaque cookie that is a logic
+   identifier of all the messages in a conversation.
+
+   The PA_FX_COOKIE can be initially sent by the client or the KDC, the
+   receiver MUST copy the Cookie into a PA_FX_COOKIE padata and include
+   it in the next message, if any, in the same conversation.
+
+   The content of the PA_FX_COOKIE padata is a local matter of the
+   sender.  Implementations MUST NOT include any sensitive or private
+   data in the PA-FX-COOKIE structure.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
+   identify the conversation with the client.
+
+       KDC_ERR_MORE_PREAUTH_DATA_NEEDED    TBA
+
+   If a PA_FX_COOKIE is included in the client request, the KDC then
+   MUST copy the exact cookie into the response.
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the
+   PA_AUTHENTICATION_SET padata element.  A PA_AUTHENTICATION_SET padata
+   element contains the ASN.1 DER encoding of the PA-AUTHENTICATION-SET
+   structure:
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+       PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+       PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+           pa-type         [1] Int32,
+               -- same as padata-type.
+           pa-hint         [2] OCTET STRING,
+               -- hint data.
+           ...
+       }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.
+
+   When indicating which sets of padata are supported, the KDC includes
+   a PA-AUTHENTICATION-SET padata element for each authentication set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA_FX_COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC along with the first
+   message that contains a PA-AUTHENTICATION-SET, in order to keep track
+   of KDC states.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   The cipher text exposure of encrypted timestamp pre-authentication
+   data is a security concern for Kerberos.  Attackers can lauch offline
+   dictionary attack using the cipher text.  The FAST pre-authentication
+   padata is a tool to mitigate this threat.  FAST also provides
+   solutions to common problems for pre-authentication mechanisms such
+   as binding of the request and the reply, freshness guarantee of the
+   authentication.  FAST itself, however, does not authenticate the
+   client or the KDC, instead, it provides a typed hole to allow pre-
+   authentication data be tunneled using FAST messages.  A pre-
+   authentication data element used within FAST is called a FAST factor.
+   A FAST factor capatures the minimal work required for extending
+   Kerberos to support a new authentication scheme.  A FAST factor MUST
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   NOT be used outside of FAST unless its specification explicitly
+   allows so.  The typed holes in FAST messages can also be used as
+   generic ones that are not intended to prove the client's identity, or
+   establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   A FAST mechanism factor when used within FAST to authenticate the
+   client or the KDC is a pre-authentication mechanism, as such the
+   specification of such a FAST factor SHOULD specify which facilities
+   it provides per Section 5.
+
+   Implementations of the pre-authentication framework SHOULD use
+   encrypted timestamp pre-authentication, if that is the mechanism to
+   authenticate the client, as a FAST factor to avoid security exposure.
+
+   The encrypted timestamp FAST factor MUST fill out the encrypted rep-
+   key-package field as described in Section 6.5.3.  It provides the
+   following facilities: client-authentication, replacing-reply-key,
+   KDC-authentication.  It does not provide the strengthening-reply-key
+   facility.  The security considerations section of this document
+   provides an explaination why the security requirements are met.
+
+   FAST employs an armoring scheme.  The armor can be a host Ticket
+   Granting Ticket (TGT), or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a
+   host key.  The rest of this section describes the types of armors and
+   the messages used by FAST.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The ArmorData structure is used to
+   identify the armor key.  It contains the following two fields: the
+   armor-type identifies the type of armor data, and the armor-value as
+   an OCTET STRING contains the data.
+
+       KrbFastArmor ::= SEQUENCE {
+           armor-type     [1] Int32,
+               -- Type of the armor.
+           armor-value    [2] OCTET STRING,
+               -- Value of the armor.
+           ...
+       }
+
+   The value of the armor key is a matter of the armor type
+   specification.  The following types of armors are currently defined:
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+       FX_FAST_ARMOR_AP_REQUEST  1
+       FX_FAST_ARMOR_KEY_ID      2
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+6.5.1.1.  Ticket-based Armors
+
+   The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT.
+   The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains
+   an AP-REQ encoded in DER.  The subkey field in the AP-REQ MUST be
+   present.  And the armor key is the subkey in the AP-REQ
+   authenticator.
+
+   If the client has a TGT for the expected KDC, it can use that ticket
+   to construct the AP-REQ.  If not, the client can use anonymous PKINIT
+   as described in [KRB-ANON] to obtain a TGT anonymously and use that
+   to construct an FX_FAST_ARMOR_AP_REQUEST armor.
+
+6.5.1.2.  Key-based Armors
+
+   The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of
+   a key that is shared between the client host and the KDC.  The
+   content and the encoding of the armor-data field of this armor type
+   is a local matter of the communicating client and the expected KDC.
+   The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the
+   KDC does have a shared key and it is beneficial to minimize the
+   number of messages exchanged between the client and the KDC, namely
+   by eliminating the messages for obtaining a host ticket based on the
+   host key.
+
+6.5.2.  FAST Request
+
+   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+    PA-FX-FAST-REQUEST ::= CHOICE {
+        armored-data    [1] KrbFastAmoredReq,
+        ...
+    }
+
+    KrbFastAmoredReq ::= SEQUENCE {
+        armor           [1] KrbFastArmor OPTIONAL,
+            -- Contains the armor that determines the armor key.
+            -- MUST be present in the initial AS-REQ in a converstation,
+            -- MUST be absent in any subsequent AS-REQ.
+            -- MUST be absent in TGS-REQ.
+        req-checksum    [2] Checksum,
+            -- Checksum performed over the type KDC-REQ-BODY.
+            -- The checksum key is the armor key, and the checksum
+            -- type is the required checksum type for the enctype of
+            -- the armor key.
+        enc-fast-req    [3] EncryptedData, -- KrbFastReq --
+            -- The encryption key is the armor key, and the key usage
+            -- number is TBA.
+        ...
+    }
+
+   The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure.  The
+   KrbFastAmoredReq encapsulates the encrypted padata.
+
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is TBA.  The armor field in the
+   KrbFastAmoredReq structure is filled to identify the armor key.
+
+   When a KrbFastAmoredReq is included in an AS request, the armor field
+   MUST be present in the initial AS-REQ in a converstation, specifying
+   the armor key being used.  The armor field MUST be absent in any
+   subsequent AS-REQ of the same converstation.  Thus the armor key is
+   specified explicitly in the initial AS-REQ in a converstation, and
+   implicitly thereafter.
+
+   When a KrbFastAmoredReq is included in a TGS request, the armor field
+   MUST be absent.  In which case, the subkey in the AP-REQ
+   authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the
+   armor key is implicitly that subkey.
+
+   The req-checksum field contains a checksum that is performed over the
+   type KDC-REQ-BODY of the containing message.  The checksum key is the
+   armor key, and the checksum type is the required checksum type for
+   the enctype of the armor key.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The KrbFastReq structure contains the following information:
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+       KrbFastReq ::= SEQUENCE {
+           fast-options    [0] FastOptions,
+               -- Additional options.
+           padata          [1] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           timestamp       [2] KerberosTime,
+           usec            [3] Microseconds,
+               -- timestamp and usec represent the time of the client
+               -- host.
+           req-nonce       [4] OCTET STRING,
+               -- At least 128 octets in length, randomly filled using
+               -- a PRNG by the client for each message request.
+           ...
+       }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The meanings of the options are as follows:
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- anonymous(1),
+          -- kdc-referrals(16)
+
+
+      Bits    Name          Description
+     -----------------------------------------------------------------
+      0     RESERVED        Reserved for future expansion of this field.
+      1     anonymous       Requesting the KDC to hide client names in
+                            the KDC response, as described next in this
+                            section.
+      16    kdc-referrals   Requesting the KDC to follow referrals, as
+                            described next in this section.
+
+   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
+   options.  If the KDC does not understand a critical option, it MUST
+   fail the request.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  The KDC conforming to this specification ignores
+   unknown non-critical options.
+
+   The anonymous Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The anonymous option is designed to complicate
+      traffic analysis performed over the client-KDC messages.  If the
+      anonymous option is set, the KDC implementing PA_FX_FAST MUST
+      identify the client as the anonymous principal in the KDC reply
+      and the error response.  Thus this option is set by the client if
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+      it wishes to hide the client identity in the KDC response.
+
+   The kdc-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] need to contain the AS specified in the error
+      response in order to complete client referrals.  In many cases, it
+      is desirable to keep the client's involvement minimal.  For
+      example, the client may contact the KDC via a satellite link that
+      has high latency, or the client has limited computational
+      capabilities.  The kdc-referrals option is designed to minimize
+      the number of KDC response messages that the client need to
+      process.  If the kdc-referrals option is set, the KDC that honors
+      this option acts as the client to follow AS referrals and TGS
+      referrals [REFERRALS], and return the ticket thus-obtained using
+      the reply key expected by the client.  The kdc-referrals option
+      can be implemented when the KDC knows the reply key.  KDC can
+      igore kdc-referrals option when it does not understand it or it
+      does not allow it based on local policy.  The client MUST be able
+      to process the KDC responses when this option is not honored by
+      the KDC, unless otherwise specified.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 in [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.
+
+   The timestamp and usec fields represent the time of the client host,
+   these fields have the same semantics as the corresponding-
+   identically-named fields in Section 5.6.1 of [RFC4120].
+
+   The req-nonce field is randomly filled using a PRNG by the client for
+   each message request.  It MUST have at least 128 octets in length.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
+   padata element in the KDC reply and/or the error response, when the
+   client and the KDC agreed upon the armor key.  The corresponding
+   padata-value field [RFC4120] in the KDC response is the DER encoding
+   of the ASN.1 type PA-FX-FAST-REPLY.
+
+
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data    [1] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep    [1] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is TBA.
+          ...
+      }
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is TBA.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST reject the reply based on local policy.  The
+   Kerberos client MAY process an error message without a PA-FX-FAST-
+   REPLY, if that is only intended to return better error information to
+   the application, typically for trouble-shooing purposes.
+
+   The KrbFastResponse structure contains the following information:
+
+      KrbFastResponse ::= SEQUENCE {
+          padata          [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          finish          [2] KrbFastFinish OPTIONAL,
+              -- MUST be present if the client is authenticated,
+              -- absent otherwise.
+              -- Typically this is present if and only if the containing
+              -- message is the last one in a conversation.
+          rep-nonce       [3] OCTET STRING,
+              -- At least 128 octets in length, randomly filled using
+              -- a PRNG by the KDC for each KDC response.
+          ...
+      }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data completing the exchange for
+   the FAST factors.  They can also be used as generic typed-holes for
+   protocol extensibility.
+
+   The finish field contains a KrbFastFinish structure.  It is filled by
+   the KDC when the client has been authenticated (the client
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   authenticated state is marked), it MUST be absent otherwise.
+   Consequently this field can only be present in an AS-REP or a TGS-REP
+   when a ticket is returned.  And typically the containing message with
+   the finish field present is the last one in a conversation.
+
+   The KrbFastFinish structure contains the following information:
+
+    KrbFastFinish ::= SEQUENCE {
+        authtime        [1] KerberosTime,
+        usec            [2] Microseconds,
+            -- timestamp and usec represent the time on the KDC when
+            -- the reply was generated.
+        rep-key-package [3]  EncryptedData OPTIONAL, -- EncryptionKey --
+            -- This, if present, replaces the reply key for AS and TGS.
+            -- The encryption key is the client key, unless otherwise
+            -- specified. The key usage number is TBA.
+        crealm          [4] Realm,
+        cname           [5] PrincipalName,
+            -- Contains the client realm and the client name.
+        checksum        [6] Checksum,
+            -- Checksum performed over all the messages in the
+            -- conversation, except the containing message.
+            -- The checksum key is the ticket session key of the reply
+            -- ticket, and the checksum type is the required checksum
+            -- type of that key.
+        ...
+    }
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply was generated, these fields have the same semantics as the
+   corresponding-identically-named fields in Section 5.6.1 of [RFC4120].
+   The client MUST use the KDC's time in these fields thereafter when
+   using the returned ticket.  Note that the KDC's time in AS-REP may
+   not match the authtime in the reply ticket if the kdc-referrals
+   option is requested and honored by the KDC.
+
+   The rep-key-package field, if present, contains the reply key
+   encrypted using the client key unless otherwise specified.  The key
+   usage number is TBA.
+
+   When the encrypted timestamp FAST factor is used in the request, the
+   rep-key-package field MUST be present and the client key is used to
+   encrypt the reply key enclosed in the KrbFastArmoredRep.
+
+   The cname and crealm fields identifies the authenticated client.
+
+   The checksum field contains a checksum of all the messages in the
+   conversation excluding and prior to the containing message.  The
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   checksum key is the ticket session key of the reply ticket, and the
+   checksum type is the required checksum type of the enctype of that
+   key.
+
+   The rep-nonce field is randomly filled using a PRNG by the KDC for
+   each KDC response, and it MUST have at least 128 octets in length.
+
+   The client MUST include a PA_FX_COOKIE as defined in Section 6.3, if
+   it includes a PA_FX_FAST in the request.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+          AD-authentication-strength      TBA
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  IANA Considerations
+
+   This document defines FAST factors, these are mini- and light-
+   weighted- pre-authentication mechanisms.  A new IANA registry should
+   be setup for registering FAST factor IDs.
+
+
+8.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   for any given client principal.
+
+   Because the client secrets are known only to the client and the KDC,
+   the verification of the encrypted timestamp proves the client's
+   identity, the verification of the encrypted rep-key-package in the
+   KDC reply proves that the expected KDC responded.  The encrypted
+   reply key is contained in the rep-key-package in the PA-FX-FAST-
+   REPLY.  Therefore, the encrypted timestamp FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication, replacing-reply-key, KDC-authentication.  There is no
+   un-authenticated cleartext introduced by the encrypted timestamp FAST
+   factor.
+
+
+9.  Acknowledgements
+
+   Serveral suggestions from Jeffery Hutzman based on early revisions of
+   this documents led to significant improvements of this document.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
+              Support", draft-ietf-krb-wg-anon, work in progress.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate 
+              Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals, 
+              work in progress.
+
+Zhu & Hartman            Expires April 27, 2007                [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   [SHA2]     National Institute of Standards and Technology, "Secure 
+              Hash Standard (SHS)", Federal Information Processing 
+              Standards Publication 180-2, August 2002.  
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation.
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+   
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).
+
+10.2.  Informative References
+
+   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 
+              Encrypted Key Exchange: A Password-Based Protocol Secure 
+              Against Dictionary Attacks and Password File Compromise". 
+              Proceedings of the 1st ACM Conference on Computer and 
+              Communications Security, ACM Press, November 1993.
+   
+   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 
+              progress.
+
+   [IEEE1363.2] 
+              IEEE P1363.2: Password-Based Public-Key Cryptography, 
+              2004.
+           
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+Appendix A.  ASN.1 module
+
+    KerberosPreauthFramework {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) preauth-framework(3)
+    } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+    IMPORTS
+
+          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+          Int32, EncryptedData, PA-DATA
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) };
+                 -- as defined in RFC 4120.
+
+    PA-FX-COOKIE ::= SEQUENCE {
+        Cookie          [1] OCTET STRING,
+            -- Opaque data, for use to associate all the messages in a
+            -- single conversation between the client and the KDC.
+            -- This can be generated by either the client or the KDC.
+            -- The receiver MUST copy the exact Cookie encapsulated in
+            -- a PA_FX_COOKIE data element into the next message of the
+            -- same conversation.
+        ...
+    }
+
+    PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+    PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+        pa-type         [1] Int32,
+            -- same as padata-type.
+        pa-hint         [2] OCTET STRING,
+            -- hint data.
+        ...
+    }
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+
+    PA-FX-FAST-REQUEST ::= CHOICE {
+        armored-data    [1] KrbFastAmoredReq,
+        ...
+    }
+
+    KrbFastAmoredReq ::= SEQUENCE {
+        armor           [1] KrbFastArmor OPTIONAL,
+            -- Contains the armor that determines the armor key.
+            -- MUST be present in AS-REQ.
+            -- MUST be absent in TGS-REQ.
+        req-checksum    [2] Checksum,
+            -- Checksum performed over the type KDC-REQ-BODY.
+            -- The checksum key is the armor key, and the checksum
+            -- type is the required checksum type for the enctype of
+            -- the armor key.
+        enc-fast-req    [3] EncryptedData, -- KrbFastReq --
+            -- The encryption key is the armor key, and the key usage
+            -- number is TBA.
+        ...
+    }
+
+    KrbFastArmor ::= SEQUENCE {
+        armor-type     [1] Int32,
+            -- Type of the armor.
+        armor-value    [2] OCTET STRING,
+            -- Value of the armor.
+        ...
+    }
+
+    KrbFastReq ::= SEQUENCE {
+        fast-options    [0] FastOptions,
+            -- Additional options.
+        padata          [1] SEQUENCE OF PA-DATA,
+            -- padata typed holes.
+        timestamp       [2] KerberosTime,
+        usec            [3] Microseconds,
+            -- timestamp and usec represent the time of the client
+            -- host.
+        req-nonce       [4] OCTET STRING,
+            -- At least 128 octets in length, randomly filled using
+            -- a PRNG by the client for each message request.
+        ...
+    }
+
+    FastOptions ::= KerberosFlags
+        -- reserved(0),
+        -- anonymous(1),
+        -- kdc-referrals(16)
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+
+    PA-FX-FAST-REPLY ::= CHOICE {
+        armored-data    [1] KrbFastArmoredRep,
+        ...
+    }
+
+    KrbFastArmoredRep ::= SEQUENCE {
+        enc-fast-rep    [1] EncryptedData, -- KrbFastResponse --
+            -- The encryption key is the armor key in the request, and
+            -- the key usage number is TBA.
+        ...
+    }
+
+    KrbFastResponse ::= SEQUENCE {
+        padata          [1] SEQUENCE OF PA-DATA,
+            -- padata typed holes.
+        finish          [2] KrbFastFinish OPTIONAL,
+            -- MUST be present if the client is authenticated,
+            -- absent otherwise.
+            -- Typically this is present if and only if the containing
+            -- message is the last one in a conversation.
+        rep-nonce       [3] OCTET STRING,
+            -- At least 128 octets in length, randomly filled using
+            -- a PRNG by the KDC for each KDC response.
+        ...
+    }
+
+    KrbFastFinish ::= SEQUENCE {
+        timestamp       [1] KerberosTime,
+        usec            [2] Microseconds,
+            -- timestamp and usec represent the time on the KDC when
+            -- the reply was generated.
+        rep-key-package [3]  EncryptedData OPTIONAL, -- EncryptionKey --
+            -- This, if present, replaces the reply key for AS and TGS.
+            -- The encryption key is the client key, unless otherwise
+            -- specified. The key usage number is TBA.
+        crealm          [4] Realm,
+        cname           [5] PrincipalName,
+            -- Contains the client realm and the client name.
+        checksum        [6] Checksum,
+            -- Checksum performed over all the messages in the
+            -- conversation, except the containing message.
+            -- The checksum key is the ticket session key of the reply
+            -- ticket, and the checksum type is the required checksum
+            -- type of that key.
+        ...
+    }
+
+    END
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Sam hartman
+   MIT
+
+   Email: hartmans@mit.edu
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework           October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu & Hartman            Expires April 28, 2007                [Page 32]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-05.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-05.txt
new file mode 100644
index 00000000000..dc17ceb52e1
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-05.txt
@@ -0,0 +1,1938 @@
+
+
+Kerberos Working Group                                            L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                                   S. Hartman
+Intended status: Standards Track                                     MIT
+Expires: September 6, 2007                                 March 5, 2007
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-05
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on September 6, 2007.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secret of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is straightforward to chain multiple authentication
+   mechanisms, utilize a different key management system, or support a
+   new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Conventions and Terminologies Used in This Document  . . . . .  5
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
+     3.1.  Information Managed by the Pre-authentication Model  . . .  6
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 20
+       6.5.1.  FAST and Encrypted Time Stamp  . . . . . . . . . . . . 21
+       6.5.2.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 21
+       6.5.3.  FAST Request . . . . . . . . . . . . . . . . . . . . . 22
+       6.5.4.  FAST Response  . . . . . . . . . . . . . . . . . . . . 26
+       6.5.5.  Error Messages used with Kerberos FAST . . . . . . . . 28
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 28
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 30
+   Appendix A.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 30
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
+   Intellectual Property and Copyright Statements . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secret or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata.  FAST provides a protected channel between
+   the client and the KDC, and it also delivers a reply key within the
+   protected channel.  Based on FAST, pre-authentication mechanisms can
+   extend Kerberos with ease, to support, for example, password
+   authenticated key exchange (PAKE) protocols with zero knowledge
+   password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication
+   mechanism can be encapsulated in the FAST messages as defined in
+   Section 6.5.  A pre-authentication type carried within FAST is called
+   a FAST factor.  Creating a FAST factor is the easiest path to create
+   a new pre-authentication mechanism.  FAST factors are significantly
+   easier to analyze from a security standpoint than other pre-
+   authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   authentication mechanisms outside of FAST.
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document freely uses terminology
+   and notation from these documents without reference or further
+   explanation.
+
+
+2.  Conventions and Terminologies 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 [RFC2119].
+
+   The word padata is used as the shorthand of pre-authentication data.
+
+   A conversation is used to refer to all authentication messages
+   exchanged between the client and the KDCs in order to authenticate
+   the client principal.  A conversation as defined here consists of all
+   messages that are necessary to complete the authentication between
+   the client and the KDC.  It is the smallest logic unit for messages
+   exchanged between the client and the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a
+   reply key to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key cannot
+   be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of handling any message the KDC reply is
+   presumed to be verified using the client principal's long-term key.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client to authenticate the KDC.  Examples
+   of this include signing the reply that can be verified using a well-
+   known public key or providing a ticket for the client machine as a
+   service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case. [[anchor3: Is it desirable to define a new error code for this?
+   Probably but we need to call out to the WG.]]
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where pre-authentication is desirable and where
+   the KDC needs to expose cipher text encrypted in a weak key before
+   the client has proven knowledge of that key.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to optimistically
+   choose the information it would normally receive from that error
+   response.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+
+
+
+Zhu & Hartman           Expires September 6, 2007               [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  It then
+   processes the padata in the request.  As mentioned in Section 3.3,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.
+
+   At this point the KDC decides whether it will issue a pre-
+   authentication required error or a reply.  Typically a KDC will issue
+   a reply if the client's identity has been authenticated to a
+   sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Mechanisms that are inappropriate for the client principal
+   or the request SHOULD also be ignored.  Next, it generates padata for
+   the error response, modifying the pre-authentication state
+   appropriately as each mechanism is processed.  The KDC chooses the
+   order in which it will generate padata (and thus the order of padata
+   in the response), but it needs to modify the pre-authentication state
+   consistently with the choice of order.  For example, if some
+   mechanism establishes an authenticated client identity, then the
+   subsequent mechanisms in the generated response receive this state as
+   input.  After the padata is generated, the error response is sent.
+   Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   in a converstation will include KDC state as discussed in
+   Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly, when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   If a mechanism implementing this facility wishes to modify the reply
+   key before knowing that the other party in the exchange supports the
+   mechanism, it proposes modifying the reply key.  The other party then
+   includes a message indicating that the proposal is accepted if it is
+   understood and meets policy.  In many cases it is desirable to use
+   the new reply key for client authentication and for other facilities.
+   Waiting for the other party to accept the proposal and actually
+   modify the reply key state would add an additional round trip to the
+   exchange.  Instead, mechanism designers are encouraged to include a
+   typed hole for additional padata in the message that proposes the
+   reply key change.  The padata included in the typed hole are
+   generated assuming the new reply key.  If the other party accepts the
+   proposal, then these padata are considered as an inner level.  As
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   with the outer level, one authentication set or mechanism is
+   typically chosen for client authentication, along with auxiliary
+   mechanisms such as KDC cookies, and other mechanisms are ignored.
+   [[anchor6: Containers like this need more thought.  For example if
+   you are constructing an authentication set do you expect to use a
+   strengthen reply key mechanism in conjunction with something else, do
+   you include the something else in the hint of the strengthen
+   mechanism or as its own entry.  It's easier to configure and express
+   the authentication set as its own entry.  However if you do that' the
+   composition of the mechanisms looks in practice than it appears in
+   the authentication set.]]  The party generating the proposal can
+   determine whether the padata were processed based on whether the
+   proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata. [[anchor7: Why?  I suspect there's an obvious
+   attack here but I need to work through it and add detail.  In
+   particular, it seems that a checksum at the end should be
+   sufficient.]]Typically the reply key is used to protect the padata.
+   If you are only minimally increasing the strength of the reply key,
+   this may give the attacker access to something too close to the
+   original reply key.  However, binding the padata to the new reply key
+   seems potentially important from a security standpoint.  There may
+   also be objections to this from a double encryption standpoint
+   because we also recommend client authentication facilities be tied to
+   the reply key.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  Mechanisms implementing this facility MUST
+   mark the reply key as replaced in the pre-authentication state.
+   Mechanisms implementing this facility MUST either provide a mechanism
+   to verify the KDC reply to the client or mark the reply as unverified
+   in the pre-authentication state.  Mechanisms implementing this
+   facility SHOULD NOT be used if a previous mechanism has used the
+   reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be more common for both sides to know that the
+   facility is available by the time that the new key is available to be
+   used.  However, mechanism designers can use a container for padata in
+   a proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key need to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.
+
+   Mechanism designers MUST specify the pepper values when combining two
+   keys using KRB-FX-CF2().  The pepper1 and pepper2 MUST be distinct so
+   that if the two keys being combined are the same, the resulting key
+   is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there are more than one roundtrip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   have the benefit of crypto-agility provided by [RFC3961].
+
+   The advantage afforded by crypto-agility is the ability to avoid a
+   multi-year standardization and deployment cycle to fix a problem that
+   is specific to a particular algorithm, when real attacks do arise
+   against that algorithm.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) are
+   encrypted in a protected channel, in most cases, therefore no un-
+   authenticated-text issue is associated with these mechanisms.
+   However mechanism designers MUST consider the case carefully when the
+   KDC authentication is not provided by Kerberos FAST.
+
+6.3.  Managing States for the KDC
+
+   [[anchor11: Kerberos is stateless today.  We can either maintain that
+   and store all the state in a cookie or change that and require
+   clients go to the same KDC for future requests.  Consider how this
+   interacts with proxies.  The rest of this section assumes we maintain
+   the current model.]]  Kerberos KDCs are stateless.  There is no
+   requirement that clients will choose the same KDC for the second
+   request in a conversation.  Proxies or other intermediate nodes may
+   also influence KDC selection.  So, each request from a client to a
+   KDC must include sufficient information that the KDC can regenerate
+   any needed state.  This is accomplished by giving the client a
+   potentially long opaque cookie in responses to include in future
+   requests in the same conversation.  The KDC MAY respond that a
+   conversation is too old and needs to restart by responding with a
+   KDC_ERR_PREAUTH_EXPIRED error.
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+       KDC_ERR_PREAUTH_EXPIRED            TBA
+
+   When a client receives this error, the client MUST abort the existing
+   conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE pdata type is defined in this section to facilitate
+   state management.  This padata is sent by the KDC when the KDC
+   requires state for a future transaction.  The client includes this
+   opaque token in the next message in the conversation.  The token may
+   be relatively large; clients MUST be prepared for tokens somewhat
+   larger than the size of all messages in a conversation.
+
+       PA_FX_COOKIE                       TBA
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains the
+   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
+   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
+
+     PA-FX-COOKIE ::= SEQUENCE {
+         Cookie            [1] OCTET STRING,
+             -- Opaque data, for use to associate all the messages in a
+             -- single conversation between the client and the KDC.
+             -- This can be generated by either the client or the KDC.
+             -- The receiver MUST copy the exact Cookie encapsulated in
+             -- a PA_FX_COOKIE data element into the next message of the
+             -- same conversation.
+         ...
+     }
+
+   The content of the PA_FX_COOKIE padata is a local matter of the KDC.
+   However the KDC MUST construct the token in such a manner that a
+   malicious client cannot subvert the authentication process by
+   manipulating the token.  The KDC implementation needs to consider
+   expiration of tokens, key rollover and other security issues in token
+   design.  The content of the Cookie field is likely specific to the
+   pre-authentication mechanisms used to authenticate the client.  In
+   order to compute the finished field in the KrbFastRespons structure
+   as defined in Section 6.5.4, all the previous messages in the
+   conversation MUST be included in the Cookie.  If a client
+   authentication response can be replayed to multiple KDCs via the
+   PA_FX_COOKIE mechanism, an expiration in the Cookie is RECOMMENDED to
+   prevent the response being presented indefinitely.
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
+   identify the conversation with the client.
+
+       KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the
+   PA_AUTHENTICATION_SET padata element.
+
+   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+       PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+       PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+           pa-type           [1] Int32,
+               -- same as padata-type.
+           pa-hint           [2] OCTET STRING,
+               -- hint data.
+           ...
+       }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info. [[anchor12: What if you
+   have a padata type as the first member of a set that requires a
+   challenge.  For example SAM assumes that the KDC sends a challenge to
+   the client initially.  That's not a pa-hint; that's a pa-value.  How
+   do you convey that data with this?]] [[anchor13: The PA-SET appears
+   only in the first message from the KDC to the client?  In particular,
+   the client should not be prepared for the future authentication
+   mechanisms to change as the conversation progresses.  I think this is
+   correct; we should discuss and if the WG agrees the text should
+   reflect this.]]
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   When indicating which sets of padata are supported, the KDC includes
+   a PA-AUTHENTICATION-SET padata element for each authentication set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA_FX_COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC along with the first
+   message that contains a PA-AUTHENTICATION-SET, in order to keep track
+   of KDC states.
+
+   [[anchor14: It's much easier to design UIs if you can determine ahead
+   of time what all the elements of your dialogue will need to be.  If
+   we mandate that the pa-hints need to be sufficient that you can
+   determine what information you will require from a user ahead of time
+   we can simplify the UI for login.  I propose that we make this
+   requirement.  WG agreement required.]]
+
+6.5.  Definition of Kerberos FAST Padata
+
+   The cipher text exposure when using the encrypted timestamp pre-
+   authentication data is a security concern for Kerberos.  Attackers
+   can launch offline dictionary attack using the cipher text.  The FAST
+   pre-authentication padata is a tool to mitigate this threat.  FAST
+   also provides solutions to common problems for pre-authentication
+   mechanisms such as binding of the request and the reply, freshness
+   guarantee of the authentication.  FAST itself, however, does not
+   authenticate the client or the KDC, instead, it provides a typed hole
+   to allow pre-authentication data be tunneled.  A pre-authentication
+   data element used within FAST is called a FAST factor.  A FAST factor
+   captures the minimal work required for extending Kerberos to support
+   a new authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a host Ticket
+   Granting Ticket (TGT), or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a
+   host key.  The armoring TGT can be a cross-realm TGT.  The rest of
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   this section describes the types of armors and the messages used by
+   FAST.
+
+6.5.1.  FAST and Encrypted Time Stamp
+
+   FAST provides new behavior for encrypted time stamp [RFC4120].  When
+   used as a FAST factor, this mechanism provides stronger security
+   guarantees.
+
+   Implementations of the pre-authentication framework SHOULD use
+   encrypted timestamp pre-authentication, if that is the mechanism to
+   authenticate the client, as a FAST factor to avoid security exposure.
+
+   The encrypted timestamp FAST factor MUST fill out the encrypted rep-
+   key-package field as described in Section 6.5.4.  It provides the
+   following facilities: client-authentication, replacing-reply-key,
+   KDC-authentication.  It does not provide the strengthening-reply-key
+   facility.  The security considerations section of this document
+   provides an explanation why the security requirements are met.
+
+6.5.2.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The ArmorData structure is used to
+   identify the armor key.  It contains the following two fields: the
+   armor-type identifies the type of armor data, and the armor-value as
+   an OCTET STRING contains the data.
+
+       KrbFastArmor ::= SEQUENCE {
+           armor-type        [1] Int32,
+               -- Type of the armor.
+           armor-value       [2] OCTET STRING,
+               -- Value of the armor.
+           ...
+       }
+
+   The value of the armor key is a matter of the armor type
+   specification.  The following armor types are currently defined :
+
+
+       FX_FAST_ARMOR_AP_REQUEST  1
+       FX_FAST_ARMOR_KEY_ID      2
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+6.5.2.1.  Ticket-based Armors
+
+   The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT.
+   The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains
+   an AP-REQ encoded in DER.  The subkey field in the AP-REQ MUST be
+   present.  The armor key is the subkey in the AP-REQ authenticator.
+
+   The ticket in the AP-REQ MUST be for the TGT service of the target
+   KDC.  Here are 3 ways in the decreasing preference order how an armor
+   TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has a trust path to the client's realm, the host
+       machine obtains a TGT to the client's realm, and this ticket is
+       the armor ticket.
+
+   2.  Otherwise, the client's host machine cannot obtain a host ticket
+       strictly based on RFC4120, but the KDC has a signing asymmetric
+       key that the client can verify its binding with the expected KDC,
+       the client then can use anonymous PKINIT to obtain a anonymous
+       TGT, and use that TGT to as the armor ticket.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication.  Note that this mode of operation
+       is vulnerable to man-in-the-middle attacks at the time of
+       obtaining the initial anonymous TGT.
+
+   Because the KDC does not know if the client is able to trust the
+   ticket it has, the KDC and client MUST initialize the pre-
+   authentication state to an unverified KDC.
+
+6.5.2.2.  Key-based Armors
+
+   The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of
+   a key that is shared between the client host and the KDC.  The
+   content and the encoding of the armor-data field of this armor type
+   is a local matter of the communicating client and the expected KDC.
+   The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the
+   KDC does have a shared key and it is beneficial to minimize the
+   number of messages exchanged between the client and the KDC, namely
+   by eliminating the messages for obtaining a host ticket based on the
+   host key. [[anchor19: Do we believe this has sufficient value to
+   specify or do we want to assume all armor comes from tickets?]]
+
+6.5.3.  FAST Request
+
+   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.
+
+       PA_FX_FAST                         TBA
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data      [1] KrbFastAmoredReq,
+           ...
+       }
+
+       KrbFastAmoredReq ::= SEQUENCE {
+           armor             [1] KrbFastArmor OPTIONAL,
+               -- Contains the armor that determines the armor key.
+               -- MUST be present in AS-REQ.
+               -- MUST be absent in TGS-REQ.
+           req-checksum      [2] Checksum,
+               -- Checksum performed over the type KDC-REQ-BODY.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REA_CHKSUM.
+           enc-fast-req      [3] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REA_CHKSUM          TBA
+       KEY_USAGE_FAST_ENC                 TBA
+
+   The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure.  The
+   KrbFastAmoredReq encapsulates the encrypted padata.
+
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.
+
+       KEY_USAGE_FAST_ARMOR               TBA
+
+   The armor key is identified as follows:
+
+   o  When a KrbFastAmoredReq is included in an AS request, the armor
+      field MUST be present in the initial AS-REQ in a conversation,
+      specifying the armor key being used.  The armor field MUST be
+      absent in any subsequent AS-REQ of the same conversation.  In
+      other words, the armor key is specified explicitly in the initial
+      AS-REQ in a conversation, and implicitly thereafter.
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   o  When a KrbFastAmoredReq is included in a TGS request, the armor
+      field MUST be absent.  In which case, the subkey in the AP-REQ
+      authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the
+      armor key is implicitly that subkey.
+
+   The req-checksum field contains a checksum that is performed over the
+   type KDC-REQ-BODY of the containing message.  The checksum key is the
+   armor key, and the checksum type is the required checksum type for
+   the enctype of the armor key.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The KrbFastReq structure contains the following information:
+
+       KrbFastReq ::= SEQUENCE {
+           fast-options      [0] FastOptions,
+               -- Additional options.
+           padata            [1] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           crealm            [2] Realm OPTIONAL,
+           cname             [3] PrincipalName OPTIONAL,
+               -- Contains the client realm and the client name.
+               -- If present, the client name and realm in the
+               -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored.
+           ...
+       }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The meanings of the options are as follows:
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- anonymous(1),
+          -- kdc-referrals(16)
+
+
+      Bits    Name          Description
+     -----------------------------------------------------------------
+      0     RESERVED        Reserved for future expansion of this field.
+      1     anonymous       Requesting the KDC to hide client names in
+                            the KDC response, as described next in this
+                            section.
+      16    kdc-referrals   Requesting the KDC to follow referrals, as
+                            described next in this section.
+
+   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
+   options.  If the KDC does not understand a critical option, it MUST
+   fail the request.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignores
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   unknown non-critical options.
+
+   The anonymous Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The anonymous option is designed to complicate
+      traffic analysis performed over the messages exchanged between the
+      client and the KDC.  If the anonymous option is set, the KDC
+      implementing PA_FX_FAST MUST identify the client as the anonymous
+      principal in the KDC reply and the error response.  Hence this
+      option is set by the client if it wishes to conceal the client
+      identity in the KDC response.
+
+   The kdc-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] need to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-referrals
+      option is designed to minimize the number of messages that need to
+      be processed by the client.  This option is useful when, for
+      example, the client may contact the KDC via a satellite link that
+      has high latency, or the client has limited computational
+      capabilities.  If the kdc-referrals option is set, the KDC that
+      honors this option acts as the client to follow AS referrals and
+      TGS referrals [REFERRALS], and return the ticket thus-obtained
+      using the reply key expected by the client.  The kdc-referrals
+      option can be implemented when the KDC knows the reply key.  The
+      KDC can ignore kdc-referrals option when it does not understand it
+      or it does not allow this option based on local policy.  The
+      client MUST be able to process the KDC responses when this option
+      is not honored by the KDC, unless otherwise specified.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.
+
+   The crealm field and the cname field identify the client principal in
+   the ticket request.  If either the crealm field or the cname field is
+   present, the corresponding crealm or cname field in the KDC-REQ-BODY
+   [RFC4120] of an AS-REQ MUST be ignored.  The client can fill in these
+   fields in the KrbFastReq structure and leaves the cname field and the
+   crealm field KDC-REQ-BODY absent, thus conceals its identity in the
+   AS-REQ.
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+6.5.4.  FAST Response
+
+   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
+   padata element in the KDC reply and/or the error response, when the
+   client and the KDC agreed upon the armor key.  The corresponding
+   padata-value field [RFC4120] in the KDC response is the DER encoding
+   of the ASN.1 type PA-FX-FAST-REPLY.
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data      [1] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [1] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 TBA
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the request.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.  The Kerberos client MAY process an error
+   message without a PA-FX-FAST-REPLY, if that is only intended to
+   return better error information to the application, typically for
+   trouble-shooing purposes.
+
+   The KrbFastResponse structure contains the following information:
+
+      KrbFastResponse ::= SEQUENCE {
+          padata            [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          finished          [2] KrbFastFinished OPTIONAL,
+              -- MUST be present if the client is authenticated,
+              -- absent otherwise.
+              -- Typically this is present if and only if the containing
+              -- message is the last one in a conversation.
+          ...
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+      }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation; it MUST
+   be absent otherwise.  Consequently this field can only be present in
+   an AS-REP or a TGS-REP when a ticket is returned.
+
+   The KrbFastFinished structure contains the following information:
+
+     KrbFastFinished ::= SEQUENCE {
+         timestamp         [1] KerberosTime,
+         usec              [2] Microseconds,
+             -- timestamp and usec represent the time on the KDC when
+             -- the reply was generated.
+         rep-key-package   [3]  EncryptedData OPTIONAL,
+                       -- EncryptionKey --
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- The encryption key is the client key, unless otherwise
+             -- specified. The key usage number is
+             -- KEY_USAGE_FAST_FINISHED.
+         crealm            [4] Realm,
+         cname             [5] PrincipalName,
+             -- Contains the client realm and the client name.
+         checksum          [6] Checksum,
+             -- Checksum performed over all the messages in the
+             -- conversation, except the containing message.
+             -- The checksum key is the ticket session key of the reply
+             -- ticket, and the checksum type is the required checksum
+             -- type of that key.
+         ...
+     }
+     KEY_USAGE_FAST_REP_KEY             TBA
+     KEY_USAGE_FAST_FINISHED            TBA
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   referrals option is requested and honored by the KDC.
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   The rep-key-package field, if present, contains the reply key
+   encrypted using the client key unless otherwise specified.  The key
+   usage number is KEY_USAGE_FAST_REP_KEY.
+
+   When the encrypted timestamp FAST factor is used in the request, the
+   rep-key-package field MUST be present and the client key is used to
+   encrypt the reply key enclosed in the KrbFastArmoredRep.
+
+   The cname and crealm fields identify the authenticated client.
+
+   The checksum field contains a checksum of all the messages in the
+   conversation prior to the containing message (the containing message
+   is excluded).  The checksum key is the ticket session key of the
+   reply ticket, the checksum type is the required checksum type of the
+   enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED.
+
+6.5.5.  Error Messages used with Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120], where a PA_FX_FAST padata element is included and it
+   contains the DER encoding of the type PA-FX-FAST-REPLY.  If the
+   e-data field of the KRB-ERROR message contains the DER encoding of a
+   TYPED-DATA, a typed data element TD_FX_FAST SHOULD be included in the
+   e-data if the Kerberos FAST padata is included in the request, and
+   the corresponding data-value field [RFC4120] contains the ASN.1 DER
+   encoding of the type PA-FX-FAST-REPLY.  In other words, the typed
+   data element type TD_FX_FAST is allocated to encapsulate the FAST
+   reply message in the error responses.  If a PA-FX-FAST-REPLY is not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection. [[anchor21: Why do we want padata in arbitrary
+   error responses?  What if the KDC cannot generate a fast reply
+   because for example no armor nor state cookie was included in a
+   request?  Also, we need to confirm that the WG is OK with a pre-
+   authentication specification changing error returns for unrelated
+   errors.]]
+
+       TD_FX_FAST                         TBA
+           -- Typed data element type for Kerberos FAST
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+       AD-authentication-strength         TBA
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  IANA Considerations
+
+   This document defines FAST factors, these are mini- and light-
+   weighted- pre-authentication mechanisms.  A new IANA registry should
+   be setup for registering FAST factor IDs.  The evaluation policy is
+   "Specification Required".
+
+
+8.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   Because the client secrets are known only to the client and the KDC,
+   the verification of the encrypted timestamp proves the client's
+   identity, the verification of the encrypted rep-key-package in the
+   KDC reply proves that the expected KDC responded.  The encrypted
+   reply key is contained in the rep-key-package in the PA-FX-FAST-
+   REPLY.  Therefore, the encrypted timestamp FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication, replacing-reply-key, KDC-authentication.  There is no
+   un-authenticated clear text introduced by the encrypted timestamp
+   FAST factor.
+
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+9.  Acknowledgements
+
+   Several suggestions from Jeffery Hutzman based on early revisions of
+   this documents led to significant improvements of this document.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
+              Support", draft-ietf-krb-wg-anon, work in progress.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate 
+              Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals, 
+              work in progress.
+
+   [SHA2]     National Institute of Standards and Technology, "Secure 
+              Hash Standard (SHS)", Federal Information Processing 
+              Standards Publication 180-2, August 2002.  
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation.
+   
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).
+
+10.2.  Informative References
+
+   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 
+              Encrypted Key Exchange: A Password-Based Protocol Secure 
+              Against Dictionary Attacks and Password File Compromise". 
+              Proceedings of the 1st ACM Conference on Computer and 
+              Communications Security, ACM Press, November 1993.
+   
+   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 
+              progress.
+
+   [IEEE1363.2] 
+              IEEE P1363.2: Password-Based Public-Key Cryptography, 
+              2004.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+Appendix A.  ASN.1 module
+
+     KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+     IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-DATA
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+                  -- as defined in RFC 4120.
+
+     PA-FX-COOKIE ::= SEQUENCE {
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+         Cookie            [1] OCTET STRING,
+             -- Opaque data, for use to associate all the messages in a
+             -- single conversation between the client and the KDC.
+             -- This can be generated by either the client or the KDC.
+             -- The receiver MUST copy the exact Cookie encapsulated in
+             -- a PA_FX_COOKIE data element into the next message of the
+             -- same conversation.
+         ...
+     }
+
+     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+         pa-type           [1] Int32,
+             -- same as padata-type.
+         pa-hint           [2] OCTET STRING,
+             -- hint data.
+         ...
+     }
+
+     PA-FX-FAST-REQUEST ::= CHOICE {
+         armored-data      [1] KrbFastAmoredReq,
+         ...
+     }
+
+     KrbFastAmoredReq ::= SEQUENCE {
+         armor             [1] KrbFastArmor OPTIONAL,
+             -- Contains the armor that determines the armor key.
+             -- MUST be present in AS-REQ.
+             -- MUST be absent in TGS-REQ.
+         req-checksum      [2] Checksum,
+             -- Checksum performed over the type KDC-REQ-BODY.
+             -- The checksum key is the armor key, the checksum
+             -- type is the required checksum type for the enctype of
+             -- the armor key, and the key usage number is
+             -- KEY_USAGE_FAST_REA_CHKSUM.
+         enc-fast-req      [3] EncryptedData, -- KrbFastReq --
+             -- The encryption key is the armor key, and the key usage
+             -- number is KEY_USAGE_FAST_ENC.
+         ...
+     }
+
+     KrbFastArmor ::= SEQUENCE {
+         armor-type        [1] Int32,
+             -- Type of the armor.
+         armor-value       [2] OCTET STRING,
+             -- Value of the armor.
+         ...
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+     }
+
+     KrbFastReq ::= SEQUENCE {
+         fast-options      [0] FastOptions,
+             -- Additional options.
+         padata            [1] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         crealm            [2] Realm OPTIONAL,
+         cname             [3] PrincipalName OPTIONAL,
+             -- Contains the client realm and the client name.
+             -- If present, the client name and realm in the
+             -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored.
+         ...
+     }
+
+     FastOptions ::= KerberosFlags
+         -- reserved(0),
+         -- anonymous(1),
+         -- kdc-referrals(16)
+
+     PA-FX-FAST-REPLY ::= CHOICE {
+         armored-data      [1] KrbFastArmoredRep,
+         ...
+     }
+
+     KrbFastArmoredRep ::= SEQUENCE {
+         enc-fast-rep      [1] EncryptedData, -- KrbFastResponse --
+             -- The encryption key is the armor key in the request, and
+             -- the key usage number is KEY_USAGE_FAST_REP.
+         ...
+     }
+
+     KrbFastResponse ::= SEQUENCE {
+         padata            [1] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         finished          [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+     KrbFastFinished ::= SEQUENCE {
+         timestamp         [1] KerberosTime,
+         usec              [2] Microseconds,
+             -- timestamp and usec represent the time on the KDC when
+             -- the reply was generated.
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+         rep-key-package   [3]  EncryptedData OPTIONAL,
+                       -- EncryptionKey --
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- The encryption key is the client key, unless otherwise
+             -- specified. The key usage number is
+             -- KEY_USAGE_FAST_FINISHED.
+         crealm            [4] Realm,
+         cname             [5] PrincipalName,
+             -- Contains the client realm and the client name.
+         checksum          [6] Checksum,
+             -- Checksum performed over all the messages in the
+             -- conversation, except the containing message.
+             -- The checksum key is the ticket session key of the reply
+             -- ticket, and the checksum type is the required checksum
+             -- type of that key.
+         ...
+     }
+     END
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Sam hartman
+   MIT
+
+   Email: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework             March 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu & Hartman           Expires September 6, 2007              [Page 34]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-06.txt
new file mode 100644
index 00000000000..7df5301bd1d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-06.txt
@@ -0,0 +1,2184 @@
+
+
+
+Kerberos Working Group                                            L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                                   S. Hartman
+Intended status: Standards Track                                     MIT
+Expires: January 9, 2008                                    July 8, 2007
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-06
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 9, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secret of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Conventions and Terminology Used in This Document  . . . . . .  5
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
+     3.1.  Information Managed by the Pre-authentication Model  . . .  6
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 21
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 22
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 23
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 27
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 29
+       6.5.5.  The Authenticated Timestamp FAST Factor  . . . . . . . 30
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 32
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 34
+   Appendix A.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 35
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
+   Intellectual Property and Copyright Statements . . . . . . . . . . 39
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secret or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver a reply
+   key within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password authenticated key exchange (PAKE) protocols with zero
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 6.5.  A pre-authentication type carried within
+   FAST is called a FAST factor.  Creating a FAST factor is the easiest
+   path to create a new pre-authentication mechanism.  FAST factors are
+   significantly easier to analyze from a security standpoint than other
+   pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the KDCs in order to authenticate the client
+   principal.  A conversation as defined here consists of all messages
+   that are necessary to complete the authentication between the client
+   and the KDC.
+
+   Lastly, this document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a
+   reply key to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key cannot
+   be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of handling any message the KDC reply is
+   presumed to be verified using the client principal's long-term key.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client to authenticate the KDC.  Examples
+   of this include signing the reply that can be verified using a well-
+   known public key or providing a ticket for the client machine as a
+   service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where pre-authentication is desirable and where
+   the KDC needs to expose cipher text encrypted in a weak key before
+   the client has proven knowledge of that key.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to optimistically
+   guess values for the information it would normally receive from that
+   error response.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+
+
+
+Zhu & Hartman            Expires January 9, 2008                [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  It then
+   processes the padata in the request.  As mentioned in Section 3.3,
+   the KDC MAY ignore padata that is inappropriate for the configuration
+   and MUST ignore padata of an unknown type.
+
+   At this point the KDC decides whether it will issue a pre-
+   authentication required error or a reply.  Typically a KDC will issue
+   a reply if the client's identity has been authenticated to a
+   sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Mechanisms that are inappropriate for the client principal
+   or the request SHOULD also be ignored.  Next, it generates padata for
+   the error response, modifying the pre-authentication state
+   appropriately as each mechanism is processed.  The KDC chooses the
+   order in which it will generate padata (and thus the order of padata
+   in the response), but it needs to modify the pre-authentication state
+   consistently with the choice of order.  For example, if some
+   mechanism establishes an authenticated client identity, then the
+   subsequent mechanisms in the generated response receive this state as
+   input.  After the padata is generated, the error response is sent.
+   Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   in a converstation will include KDC state as discussed in
+   Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly, when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   If a mechanism implementing this facility wishes to modify the reply
+   key before knowing that the other party in the exchange supports the
+   mechanism, it proposes modifying the reply key.  The other party then
+   includes a message indicating that the proposal is accepted if it is
+   understood and meets policy.  In many cases it is desirable to use
+   the new reply key for client authentication and for other facilities.
+   Waiting for the other party to accept the proposal and actually
+   modify the reply key state would add an additional round trip to the
+   exchange.  Instead, mechanism designers are encouraged to include a
+   typed hole for additional padata in the message that proposes the
+   reply key change.  The padata included in the typed hole are
+   generated assuming the new reply key.  If the other party accepts the
+   proposal, then these padata are considered as an inner level.  As
+   with the outer level, one authentication set or mechanism is
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   typically chosen for client authentication, along with auxiliary
+   mechanisms such as KDC cookies, and other mechanisms are ignored.
+   [[anchor5: Containers like this need more thought.  For example if
+   you are constructing an authentication set do you expect to use a
+   strengthen reply key mechanism in conjunction with something else, do
+   you include the something else in the hint of the strengthen
+   mechanism or as its own entry.  It's easier to configure and express
+   the authentication set as its own entry.  However if you do that' the
+   composition of the mechanisms looks in practice than it appears in
+   the authentication set.]]  The party generating the proposal can
+   determine whether the padata were processed based on whether the
+   proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  Mechanisms implementing this facility MUST
+   mark the reply key as replaced in the pre-authentication state.
+   Mechanisms implementing this facility MUST either provide a mechanism
+   to verify the KDC reply to the client or mark the reply as unverified
+   in the pre-authentication state.  Mechanisms implementing this
+   facility SHOULD NOT be used if a previous mechanism has used the
+   reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be more common for both sides to know that the
+   facility is available by the time that the new key is available to be
+   used.  However, mechanism designers can use a container for padata in
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   a proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one roundtrip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to avoid a multi-year standardization and deployment cycle to fix a
+   problem that is specific to a particular algorithm, when real attacks
+   do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless.  There is no requirement that clients
+   will choose the same KDC for the second request in a conversation.
+   Proxies or other intermediate nodes may also influence KDC selection.
+   So, each request from a client to a KDC must include sufficient
+   information that the KDC can regenerate any needed state.  This is
+   accomplished by giving the client a potentially long opaque cookie in
+   responses to include in future requests in the same conversation.
+   The KDC MAY respond that a conversation is too old and needs to
+   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            TBA
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE pdata type is defined in this section to facilitate
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   state management.  This padata is sent by the KDC when the KDC
+   requires state for a future transaction.  The client includes this
+   opaque token in the next message in the conversation.  The token may
+   be relatively large; clients MUST be prepared for tokens somewhat
+   larger than the size of all messages in a conversation.
+
+       PA_FX_COOKIE                       TBA
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains the
+   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
+   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
+
+      PA-FX-COOKIE ::= SEQUENCE {
+          conversationId  [0] OCTET STRING,
+             -- Contains the identifier of this conversation. This field
+             -- must contain the same value for all the messages
+             -- within the same conversation.
+          enc-binding-key [1] EncryptedData OPTIONAL,
+                          -- EncryptionKey --
+             -- This field is present when and only when a FAST
+             -- padata as defined in Section 6.5 is included.
+             -- The encrypted data, when decrypted, contains an
+             -- EncryptionKey structure.
+             -- This encryption key is encrypted using the armor key
+             -- (defined in Section 6.5.1), and the key usage for the
+             -- encryption is KEY_USAGE_FAST_BINDING_KEY.
+             -- Present only once in a converstation.
+          cookie          [2] OCTET STRING OPTIONAL,
+             -- Opaque data, for use to associate all the messages in
+             -- a single conversation between the client and the KDC.
+             -- This is generated by the KDC and the client MUST copy
+             -- the exact cookie encapsulated in a PA_FX_COOKIE data
+             -- element into the next message of the same conversation.
+          ...
+      }
+      KEY_USAGE_FAST_BINDING_KEY         TBA
+
+   The conversationId field contains a sufficiently-long rand number
+   that uniquely identifies the conversation.  If a PA_FX_COOKIE padata
+   is present in one message, a PA_FX_COOKIE structure MUST be present
+   in all subsequent messages of the same converstation between the
+   client and the KDC, with the same conversationId value.
+
+   The enc-binding-key field is present when and only when a FAST padata
+   (defined in Section 6.5) is included.  The enc-binding-key field is
+   present only once in a conversation.  It MUST be ignored if it is
+   present in a subsequent message of the same conversation.  The
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   encrypted data, when decrypted, contains an EncryptionKey structure
+   that is called the binding key.  The binding key is encrypted using
+   the armor key (defined in Section 6.5.1), and the key usage for the
+   encryption is KEY_USAGE_FAST_BINDING_KEY.
+
+   If a Kerberos FAST padata as defined in Section 6.5 is included in
+   one message, it MUST be included in all subsequent messages of the
+   same conversation.
+
+   When FAST padata as defined Section 6.5 is included, the PA-FX-COOKIE
+   padata MUST be included.
+
+   The cookie token is generated by the KDC and the client MUST copy the
+   exact cookie encapsulated in a PA_FX_COOKIE data element into the
+   next message of the same conversation.  The content of the cookie
+   field is a local matter of the KDC.  However the KDC MUST construct
+   the cookie token in such a manner that a malicious client cannot
+   subvert the authentication process by manipulating the token.  The
+   KDC implementation needs to consider expiration of tokens, key
+   rollover and other security issues in token design.  The content of
+   the cookie field is likely specific to the pre-authentication
+   mechanisms used to authenticate the client.  If a client
+   authentication response can be replayed to multiple KDCs via the
+   PA_FX_COOKIE mechanism, an expiration in the cookie is RECOMMENDED to
+   prevent the response being presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
+   identify the conversation with the client according to Section 6.5.4.
+
+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the
+   PA_AUTHENTICATION_SET padata element.
+
+   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING,
+                -- hint data.
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  If a member of the pre-
+   authentication mechanism set that requires a challenge, a separate
+   padata that carries the challenge SHOULD be included along with the
+   pre-authentication set padata.
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client should not be prepared
+   for the future authentication mechanisms to change as the
+   conversation progresses. [[anchor9: I think this is correct; we
+   should discuss and if the WG agrees the text should reflect this.]]
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA_FX_COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC along with the first
+   message that contains a PA-AUTHENTICATION-SET, in order to keep track
+   of KDC states.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If one mechanism completes on the client side, and the client expects
+   the KDC to send the next padata for the next pre-authentication
+   mechanism before the authentication succeeds, the client sends an
+   AS_REQ with a padata of type PA_FX_HEARTBEAT.
+
+        PA_FX_HEARTBEAT                    TBA
+
+   The padata-value for the PA_FX_HEARTBEAT is empty.
+
+   If one mechanism completes on the KDC side, and the KDC expects the
+   client to send the next padata for the next pre-authentication
+   mechanism before the authentication succeeds, the KDC sends a KRB-
+   ERROR message with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED and
+   includes a padata of type PA_FX_HEARTBEAT.
+
+   [[anchor10: It's much easier to design UIs if you can determine ahead
+   of time what all the elements of your dialogue will need to be.  If
+   we mandate that the pa-hints need to be sufficient that you can
+   determine what information you will require from a user ahead of time
+   we can simplify the UI for login.  I propose that we make this
+   requirement.  WG agreement required.]]
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the entrypted timestap pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted timestamp, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value as an OCTET STRING contains the description of the armor scheme
+   and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           TBA
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is the subkey in the AP-REQ authenticator.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three ways in the decreasing preference
+   order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has a trust path to the client's realm, the host
+       machine obtains a TGT by pre-authenticating intitialy the realm
+       of the host machine using the host keys.  If the client's realm
+       is different than the realm of the local host, the machine then
+       obtains a cross-realm TGT to the client's realm as the armor
+       ticket.  Otherwise, the host's primary TGT is the armor ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key that
+       the client can verify the binding between the public key of the
+       signing key and the expected KDC, the client can use anonymous
+       PKINIT [KRB-ANON] [RFC4556] to authenticate the KDC and obtain an
+       anonymous TGT as the armor ticket.  The armor key can be a cross-
+       team TGT obtained based on the initial primary TGT obtained using
+       anonymous PKINIT with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.  The armor key can be a cross-team TGT obtained based
+       on the initial primary TGT obtained using anonymous PKINIT
+       without KDC authentication.
+
+   Because the KDC does not know if the client is able to trust the
+   ticket it has, the KDC MUST initialize the pre-authentication state
+   to an unverified KDC.
+
+6.5.2.  FAST Request
+
+   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+       PA_FX_FAST                         TBA
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+               -- MUST be absent in TGS-REQ.
+           req-checksum [1] Checksum,
+               -- Checksum performed over the type KDC-REQ-BODY for
+               -- the req-body field of the KDC-REQ structure defined in
+               -- [RFC4120]
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REA_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REA_CHKSUM          TBA
+       KEY_USAGE_FAST_ENC                 TBA
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.
+
+        KEY_USAGE_FAST_ARMOR               TBA
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  In a TGS request, the armor field in the KrbFastArmoredReq
+      structure MUST NOT be present and the subkey in the AP-REQ
+      authenticator in the PA-TGS-REQ PA-DATA MUST be present.  In this
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+      case, the armor key is that subkey in the AP-REQ authenticator.
+
+   The req-checksum field contains a checksum that is performed over the
+   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]
+   structure of the containing message.  The checksum key is the armor
+   key, and the checksum type is the required checksum type for the
+   enctype of the armor key per [RFC3961]. [[anchor12: Is this checksum
+   still needed if we include a full kdc-req-body]]
+
+   The KrbFastReq structure contains the following information:
+
+       KrbFastReq ::= SEQUENCE {
+           fast-options [0] FastOptions,
+               -- Additional options.
+           padata       [1] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           req-body     [2] KDC-REQ-BODY,
+               -- Contains the KDC request body as defined in Section
+               -- 5.4.1 of [RFC4120].  The req-body field in the KDC-REQ
+               -- structure [RFC4120] MUST be ignored.
+               -- The client name and realm in the KDC-REQ [RFC4120]
+               -- MUST NOT be present for AS-REQ and TGS-REQ when
+               -- Kerberos FAST padata is included in the request.
+           ...
+       }
+
+   [[anchor13: See mailing list discussion about whether client name
+   absent is correct.]]
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- anonymous(1),
+            -- kdc-referrals(16)
+
+
+      Bits    Name          Description
+     -----------------------------------------------------------------
+      0     RESERVED        Reserved for future expansion of this field.
+      1     anonymous       Requesting the KDC to hide client names in
+                            the KDC response, as described next in this
+                            section.
+      16    kdc-referrals   Requesting the KDC to follow referrals, as
+                            described next in this section.
+
+   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   options.  If the KDC does not support a critical option, it MUST fail
+   the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS (there is no
+   accompanying e-data defined in this document for this error code).
+   Bit 16 and onward (with bit 16 included) are non-critical options.
+   KDCs conforming to this specification ignores unknown non-critical
+   options.
+
+        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA
+
+   The anonymous Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The anonymous option is designed to complicate
+      traffic analysis.  If the anonymous option is set, the KDC
+      implementing PA_FX_FAST MUST identify the client as the anonymous
+      principal in the KDC reply and the error response.  Hence this
+      option is set by the client if it wishes to conceal the client
+      identity in the KDC response.
+
+   The kdc-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] need to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-referrals
+      option is designed to minimize the number of messages that need to
+      be processed by the client.  This option is useful when, for
+      example, the client may contact the KDC via a satellite link that
+      has high network latency, or the client has limited computational
+      capabilities.  If the kdc-referrals option is set, the KDC that
+      honors this option acts as the client to follow AS referrals and
+      TGS referrals [REFERRALS], and return the service ticket to the
+      named server principal in the client request using the reply key
+      expected by the client.  The kdc-referrals option can be
+      implemented when the KDC knows the reply key.  The KDC can ignore
+      kdc-referrals option when it does not understand it or it does not
+      allow this option based on local policy.  The client SHOULD be
+      able to process the KDC responses when this option is not honored
+      by the KDC.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  This outer
+   structure SHOULD be filled in for backwards compatibility with KDCs
+   that do not support FAST.  The client MAY fill in the cname and
+   crealm fields in the kdc-req-body in the KrbFastReq structure and
+   leave the cname field and the crealm field in KDC-REQ absent, in
+   order to conceal the client's identity in the AS-REQ.[[anchor14:
+   Absent is probably wrong.  Presumably we want a name similar to the
+   anonymous principal name.]]
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
+   padata element in the KDC reply.  In the case of an error, the
+   PA_FX_FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA_FX_FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 TBA
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+     KrbFastResponse ::= SEQUENCE {
+         padata      [0] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         rep-key     [1] EncryptionKey OPTIONAL,
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- MUST be absent in KRB-ERROR.
+         finished    [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.
+
+   The rep-key field, if present, contains the reply key that is used to
+   encrypted the KDC reply.  The rep-key field MUST be absent in the
+   case where an error occurs.  The enctype of the rep-key is the
+   strongest mutually supported by the KDC and the client.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation; it MUST
+   be absent otherwise.  In other words, this field can only be present
+   in an AS-REP or a TGS-REP when a ticket is returned.
+
+   The KrbFastFinished structure contains the following information:
+
+        KrbFastFinished ::= SEQUENCE {
+            timestamp   [0] KerberosTime,
+            usec        [1] Microseconds,
+                -- timestamp and usec represent the time on the KDC when
+                -- the reply was generated.
+            crealm      [2] Realm,
+            cname       [3] PrincipalName,
+                -- Contains the client realm and the client name.
+            checksum    [4] Checksum,
+                -- Checksum performed over all the messages in the
+                -- conversation, except the containing message.
+                -- The checksum key is the binding key as defined in
+                -- Section 6.3, and the checksum type is the required
+                -- checksum type of the binding key.
+            ...
+        }
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+        KEY_USAGE_FAST_FINISHED            TBA
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   referrals option is requested and honored by the KDC.
+
+   The cname and crealm fields identify the authenticated client.
+
+   The checksum field contains a checksum of all the messages in the
+   conversation prior to the containing message (the containing message
+   is excluded).  The checksum key is the binding key as defined in
+   Section 6.3, and the checksum type is the required checksum type of
+   the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED. [[anchor15: Examples would be good here;
+   what all goes into the checksum?]]
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST also be included if the KDC expects at least one
+   more message from the client in order to complete the authentication.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA_FX_FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elments that indicate acceptable pre-authentication mechanisms
+   [RFC4120] and in the KrbFastResponse structure.
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The Kerberos client MAY process an error
+   message without a PA-FX-FAST-REPLY, if that is only intended to
+   return better error information to the application, typically for
+   trouble-shooting purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, the
+   PA_FX_TYPED_DATA padata is included in the KrbFastResponse structure
+   to encapsulate the TYPED-DATA [RFC4120] elements.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   [RFC4556].
+
+        PA_FX_TYPED_DATA                   TBA
+            -- This is the padata element that encapsulates a TYPED-DATA
+            -- structure.
+
+   The corresponding padata-value for the PA_FX_TYPED_DATA padata type
+   contains the DER encoding of the ASN.1 type TYPED-DATA [RFC4120].
+
+6.5.5.  The Authenticated Timestamp FAST Factor
+
+   The encrypted time stamp [RFC4120] padata can be used as a FAST
+   factor to authenticate the client and it does not expose the cipher
+   text derived using the client's long term keys.  However this FAST
+   factor is not risk-free from current intellectual property claims as
+   of the time of this writing.  To provide a clearn replacement FAST
+   factor that closely matches the encrypted timestamp FAST factor, the
+   authenticated timestamp pre-authentication is introduced in this
+   section.
+
+   The authenticated timestamp FAST factor authenticates a client by
+   means of computing a checksum over a time-stamped structure using the
+   client's long term keys.  The padata-type is
+   PA_AUTHENTICATED_TIMESTAMP and the corresponding padata-value
+   contains the DER encoding of ASN.1 type AuthenticatedTimestamp.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+        AuthenticatedTimestampToBeSigned ::= SEQUENCE {
+            timestamp   [0] PA-ENC-TS-ENC,
+                -- Contains the timestamp field of the corresponding
+                -- AuthenticatedTimestamp structure.
+            req-body    [1] KDC-REQ-BODY OPTIONAL,
+                -- MUST contain the req-body field of the KDC-REQ
+                -- structure in the containing AS-REQ for the client
+                -- request.
+                -- MUST be Absent for the KDC reply.
+            ...
+        }
+
+        AuthenticatedTimestamp ::= SEQUENCE {
+            timestamp   [0] PA-ENC-TS-ENC,
+                -- Filled out according to Section 5.2.7.2 of [RFC4120].
+                -- Contains the client's current time for the client,
+                -- and the KDC's current time for the KDC.
+            checksum    [1] CheckSum,
+                -- The checksum is performed over the type
+                -- AuthenticatedTimestampToBeSigned and the key usage is
+                -- KEY_USAGE_AUTHENTICATED_TS_CLIENT for the client and
+                _ KEY_USAGE_AUTHENTICATED_TS_KDC for the KDC
+            ...
+        }
+
+        KEY_USAGE_AUTHENTICATED_TS_CLIENT  TBA
+        KEY_USAGE_AUTHENTICATED_TS_KDC     TBA
+
+   The client fills out the AuthenticatedTimestamp structure as follows:
+
+   o  The timestamp field in the AuthenticatedTimestamp structure is
+      filled out with the client's current time according to Section
+      5.2.7.2 of [RFC4120].
+
+   o  The checksum field in the AuthenticatedTimestamp structure is
+      performed over the type AuthenticatedTimestampToBeSigned.  The
+      checksum key is one of the client's long term keys.  The key usage
+      for the checksum operation is KEY_USAGE_AUTHENTICATED_TS_CLIENT.
+      The checksum type is the required checksum type for the strongest
+      enctype mutually supported by the client and the KDC.
+
+   o  Within the AuthenticatedTimestampToBeSigned structure, the
+      timestamp field contains the timestamp field of the corresponding
+      AuthenticatedTimestamp structure, and the req-body field MUST
+      contain the req-body field of the KDC-REQ structure in the
+      containing AS-REQ.
+
+   Upon receipt of the PA_AUTHENTICATED_TIMESTAMP FAST factor, the KDC
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   MUST process the padata in a way similar to that of the encrypted
+   timestamp padata.  The KDC MUST verify the checksum in the
+   AuthenticatedTimestamp structure and the timestamp is within the
+   window of acceptable clock skew for the KDC.
+
+   When the authenticated timestamp FAST factor is accepted by the KDC,
+   the KDC MUST include a PA_AUTHENTICATED_TIMESTAMP as a FAST factor in
+   in a successful KDC reply and it MUST include the rep-key field as
+   defined in Section 6.5.3.
+
+   The KDC fills out the AuthenticatedTimestamp structure as follows:
+
+   o  The timestamp field in the AuthenticatedTimestamp structure is
+      filled out with the KDC's current time according to Section
+      5.2.7.2 of [RFC4120].
+
+   o  The checksum field in the AuthenticatedTimestamp structure is
+      performed over the type AuthenticatedTimestampToBeSigned.  The
+      checksum key is the reply key picked from the client's long term
+      keys according to [RFC4120].  The key usage for the checksum
+      operation is KEY_USAGE_AUTHENTICATED_TS_KDC.  The checksum type is
+      the required checksum type for the checksum key.
+
+   o  Within the AuthenticatedTimestampToBeSigned structure, the
+      timestamp field contains the timestamp field of the corresponding
+      AuthenticatedTimestamp structure, and the req-body field MUST be
+      absent.
+
+   Upon receipt of the PA_AUTHENTICATED_TIMESTAMP FAST factor in the KDC
+   reply, the client MUST verify the checksum in the
+   AuthenticatedTimestamp structure and the timestamp is within the
+   window of acceptable clock skew for the client.  The successful
+   verificaiton of the PA_AUTHENTICATED_TIMESTAMP padata authenticates
+   the KDC.
+
+   The authenticated timestamp FAST factor provides the following
+   facilities: client-authentication, replacing-reply-key, KDC-
+   authentication.  It does not provide the strengthening-reply-key
+   facility.  The security considerations section of this document
+   provides an explanation why the security requirements are met.
+
+   Conforming implementations MUST support the authenticated timestamp
+   FAST factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         TBA
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  IANA Considerations
+
+   This document defines several new pa-data types, key usages and error
+   codes.  In addition it would be good to track which pa-data items are
+   only to be used as FAST factors.
+
+
+8.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   Because the client secrets are known only to the client and the KDC,
+   the verification of the authenticated timestamp proves the client's
+   identity, the verification of the authenticated timestamp in the KDC
+   reply proves that the expected KDC responded.  The encrypted reply
+   key is contained in the rep-key in the PA-FX-FAST-REPLY.  Therefore,
+   the authenticated timestamp FAST factor as a pre-authentication
+   mechanism offers the following facilities: client-authentication,
+   replacing-reply-key, KDC-authentication.  There is no un-
+   authenticated clear text introduced by the authenticated timestamp
+   FAST factor.
+
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+9.  Acknowledgements
+
+   Several suggestions from Jeffery Hutzman based on early revisions of
+   this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+10.2.  Informative References
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [KRB-WG.SAM]
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+
+Appendix A.  ASN.1 module
+
+     KerberosPreauthFramework {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) preauth-framework(3)
+     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+     IMPORTS
+          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) };
+                 -- as defined in RFC 4120.
+
+     PA-FX-COOKIE ::= SEQUENCE {
+         conversationId  [0] OCTET STRING,
+            -- Contains the identifier of this conversation. This field
+            -- must contain the same value for all the messages
+            -- within the same conversation.
+         enc-binding-key [1] EncryptedData OPTIONAL,
+                         -- EncryptionKey --
+            -- This field is present when and only when a FAST
+            -- padata as defined in Section 6.5 is included.
+            -- The encrypted data, when decrypted, contains an
+            -- EncryptionKey structure.
+            -- This encryption key is encrypted using the armor key
+            -- (defined in Section 6.5.1), and the key usage for the
+            -- encryption is KEY_USAGE_FAST_BINDING_KEY.
+         cookie          [2] OCTET STRING OPTIONAL,
+            -- Opaque data, for use to associate all the messages in
+            -- a single conversation between the client and the KDC.
+            -- This is generated by the KDC and the client MUST copy
+            -- the exact cookie encapsulated in a PA_FX_COOKIE data
+            -- element into the next message of the same conversation.
+         ...
+     }
+
+     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+         pa-type      [0] Int32,
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+             -- same as padata-type.
+         pa-hint      [1] OCTET STRING,
+             -- hint data.
+         ...
+     }
+
+     KrbFastArmor ::= SEQUENCE {
+         armor-type   [0] Int32,
+             -- Type of the armor.
+         armor-value  [1] OCTET STRING,
+             -- Value of the armor.
+         ...
+     }
+
+     PA-FX-FAST-REQUEST ::= CHOICE {
+         armored-data [0] KrbFastArmoredReq,
+         ...
+     }
+
+     KrbFastArmoredReq ::= SEQUENCE {
+         armor        [0] KrbFastArmor OPTIONAL,
+             -- Contains the armor that identifies the armor key.
+             -- MUST be present in AS-REQ.
+             -- MUST be absent in TGS-REQ.
+         req-checksum [1] Checksum,
+             -- Checksum performed over the type KDC-REQ-BODY for
+             -- the req-body field of the KDC-REQ structure defined in
+             -- [RFC4120]
+             -- The checksum key is the armor key, the checksum
+             -- type is the required checksum type for the enctype of
+             -- the armor key, and the key usage number is
+             -- KEY_USAGE_FAST_REA_CHKSUM.
+         enc-fast-req [2] EncryptedData, -- KrbFastReq --
+             -- The encryption key is the armor key, and the key usage
+             -- number is KEY_USAGE_FAST_ENC.
+         ...
+     }
+
+     KrbFastReq ::= SEQUENCE {
+         fast-options [0] FastOptions,
+             -- Additional options.
+         padata       [1] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         req-body     [2] KDC-REQ-BODY,
+             -- Contains the KDC request body as defined in Section
+             -- 5.4.1 of [RFC4120].  The req-body field in the KDC-REQ
+             -- structure [RFC4120] MUST be ignored.
+             -- The client name and realm in the KDC-REQ [RFC4120]
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+             -- MUST NOT be present for AS-REQ and TGS-REQ when
+             -- Kerberos FAST padata is included in the request.
+         ...
+     }
+
+     FastOptions ::= KerberosFlags
+         -- reserved(0),
+         -- anonymous(1),
+         -- kdc-referrals(16)
+
+     PA-FX-FAST-REPLY ::= CHOICE {
+         armored-data [0] KrbFastArmoredRep,
+         ...
+     }
+
+     KrbFastArmoredRep ::= SEQUENCE {
+         enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
+             -- The encryption key is the armor key in the request, and
+             -- the key usage number is KEY_USAGE_FAST_REP.
+         ...
+     }
+
+     KrbFastResponse ::= SEQUENCE {
+         padata      [0] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         rep-key     [1] EncryptionKey OPTIONAL,
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- MUST be absent in KRB-ERROR.
+         finished    [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+     KrbFastFinished ::= SEQUENCE {
+         timestamp   [0] KerberosTime,
+         usec        [1] Microseconds,
+             -- timestamp and usec represent the time on the KDC when
+             -- the reply was generated.
+         crealm      [2] Realm,
+         cname       [3] PrincipalName,
+             -- Contains the client realm and the client name.
+         checksum    [4] Checksum,
+             -- Checksum performed over all the messages in the
+             -- conversation, except the containing message.
+             -- The checksum key is the binding key as defined in
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+             -- Section 6.3, and the checksum type is the required
+             -- checksum type of the binding key.
+         ...
+     }
+
+     AuthenticatedTimestampToBeSigned ::= SEQUENCE {
+         timestamp   [0] PA-ENC-TS-ENC,
+             -- Contains the timestamp field of the corresponding
+             -- AuthenticatedTimestamp structure.
+         req-body    [1] KDC-REQ-BODY OPTIONAL,
+             -- MUST contain the req-body field of the KDC-REQ
+             -- structure in the containing AS-REQ for the client
+             -- request.
+             -- MUST be Absent for the KDC reply.
+         ...
+     }
+
+     AuthenticatedTimestamp ::= SEQUENCE {
+         timestamp   [0] PA-ENC-TS-ENC,
+             -- Filled out according to Section 5.2.7.2 of [RFC4120].
+             -- Contains the client's current time for the client,
+             -- and the KDC's current time for the KDC.
+         checksum    [1] CheckSum,
+             -- The checksum is performed over the type
+             -- AuthenticatedTimestampToBeSigned and the key usage is
+             -- KEY_USAGE_AUTHENTICATED_TS_CLIENT for the client and
+             _ KEY_USAGE_AUTHENTICATED_TS_KDC for the KDC
+         ...
+     }
+     END
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Sam hartman
+   MIT
+
+   Email: hartmans@mit.edu
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework              July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu & Hartman            Expires January 9, 2008               [Page 39]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt
new file mode 100644
index 00000000000..96f996350fa
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt
@@ -0,0 +1,2266 @@
+

+

+Kerberos Working Group                                            L. Zhu

+Internet-Draft                                     Microsoft Corporation

+Updates: 4120 (if approved)                                   S. Hartman

+Intended status: Standards Track                       Painless Security

+Expires: January 15, 2009                                  July 14, 2008

+

+

+        A Generalized Framework for Kerberos Pre-Authentication

+                 draft-ietf-krb-wg-preauth-framework-08

+

+Status of this Memo

+

+   By submitting this Internet-Draft, each author represents that any

+   applicable patent or other IPR claims of which he or she is aware

+   have been or will be disclosed, and any of which he or she becomes

+   aware will be disclosed, in accordance with Section 6 of BCP 79.

+

+   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 Internet-Draft will expire on January 15, 2009.

+

+Abstract

+

+   Kerberos is a protocol for verifying the identity of principals

+   (e.g., a workstation user or a network server) on an open network.

+   The Kerberos protocol provides a mechanism called pre-authentication

+   for proving the identity of a principal and for better protecting the

+   long-term secret of the principal.

+

+   This document describes a model for Kerberos pre-authentication

+   mechanisms.  The model describes what state in the Kerberos request a

+   pre-authentication mechanism is likely to change.  It also describes

+   how multiple pre-authentication mechanisms used in the same request

+   will interact.

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 1]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   This document also provides common tools needed by multiple pre-

+   authentication mechanisms.  One of these tools is a secure channel

+   between the client and the KDC with a reply key delivery mechanism;

+   this secure channel can be used to protect the authentication

+   exchange thus eliminate offline dictionary attacks.  With these

+   tools, it is relatively straightforward to chain multiple

+   authentication mechanisms, utilize a different key management system,

+   or support a new key agreement algorithm.

+

+

+Table of Contents

+

+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

+   2.  Conventions and Terminology Used in This Document  . . . . . .  5

+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5

+     3.1.  Information Managed by the Pre-authentication Model  . . .  6

+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8

+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9

+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10

+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10

+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12

+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12

+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13

+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14

+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14

+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15

+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15

+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16

+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17

+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19

+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 22

+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 23

+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 24

+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 28

+       6.5.4.  Authenticated Kerberos Error Messages using

+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 30

+       6.5.5.  The Encrypted Challenge FAST Factor  . . . . . . . . . 31

+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 32

+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33

+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33

+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34

+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34

+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 34

+     10.2. Informative References . . . . . . . . . . . . . . . . . . 34

+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 35

+     A.1.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 35

+     A.2.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 35

+   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 35

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 2]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39

+   Intellectual Property and Copyright Statements . . . . . . . . . . 40

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 3]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+1.  Introduction

+

+   The core Kerberos specification [RFC4120] treats pre-authentication

+   data as an opaque typed hole in the messages to the KDC that may

+   influence the reply key used to encrypt the KDC reply.  This

+   generality has been useful: pre-authentication data is used for a

+   variety of extensions to the protocol, many outside the expectations

+   of the initial designers.  However, this generality makes designing

+   more common types of pre-authentication mechanisms difficult.  Each

+   mechanism needs to specify how it interacts with other mechanisms.

+   Also, problems like combining a key with the long-term secret or

+   proving the identity of the user are common to multiple mechanisms.

+   Where there are generally well-accepted solutions to these problems,

+   it is desirable to standardize one of these solutions so mechanisms

+   can avoid duplication of work.  In other cases, a modular approach to

+   these problems is appropriate.  The modular approach will allow new

+   and better solutions to common pre-authentication problems to be used

+   by existing mechanisms as they are developed.

+

+   This document specifies a framework for Kerberos pre-authentication

+   mechanisms.  It defines the common set of functions that pre-

+   authentication mechanisms perform as well as how these functions

+   affect the state of the request and reply.  In addition several

+   common tools needed by pre-authentication mechanisms are provided.

+   Unlike [RFC3961], this framework is not complete--it does not

+   describe all the inputs and outputs for the pre-authentication

+   mechanisms.  Pre-Authentication mechanism designers should try to be

+   consistent with this framework because doing so will make their

+   mechanisms easier to implement.  Kerberos implementations are likely

+   to have plugin architectures for pre-authentication; such

+   architectures are likely to support mechanisms that follow this

+   framework plus commonly used extensions.

+

+   One of these common tools is the flexible authentication secure

+   tunneling (FAST) padata type.  FAST provides a protected channel

+   between the client and the KDC, and it can optionally deliver a reply

+   key within the protected channel.  Based on FAST, pre-authentication

+   mechanisms can extend Kerberos with ease, to support, for example,

+   password authenticated key exchange (PAKE) protocols with zero

+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-

+   authentication mechanism can be encapsulated in the FAST messages as

+   defined in Section 6.5.  A pre-authentication type carried within

+   FAST is called a FAST factor.  Creating a FAST factor is the easiest

+   path to create a new pre-authentication mechanism.  FAST factors are

+   significantly easier to analyze from a security standpoint than other

+   pre-authentication mechanisms.

+

+   Mechanism designers should design FAST factors, instead of new pre-

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 4]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   authentication mechanisms outside of FAST.

+

+

+2.  Conventions and Terminology 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 [RFC2119].

+

+   The word padata is used as a shorthand for pre-authentication data.

+

+   A conversation is the set of all authentication messages exchanged

+   between the client and the KDCs in order to authenticate the client

+   principal.  A conversation as defined here consists of all messages

+   that are necessary to complete the authentication between the client

+   and the KDC.

+

+   Lastly, this document should be read only after reading the documents

+   describing the Kerberos cryptography framework [RFC3961] and the core

+   Kerberos protocol [RFC4120].  This document may freely use

+   terminology and notation from these documents without reference or

+   further explanation.

+

+

+3.  Model for Pre-Authentication

+

+   When a Kerberos client wishes to obtain a ticket using the

+   authentication server, it sends an initial Authentication Service

+   (AS) request.  If pre-authentication is required but not being used,

+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.

+   Alternatively, if the client knows what pre-authentication to use, it

+   MAY optimize away a round-trip and send an initial request with

+   padata included in the initial request.  If the client includes the

+   padata computed using the wrong pre-authentication mechanism or

+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no

+   indication of what padata should have been included.  In that case,

+   the client MUST retry with no padata and examine the error data of

+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-

+   authentication information in the accompanying error data of

+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and

+   then retry.

+

+   The conventional KDC maintains no state between two requests;

+   subsequent requests may even be processed by a different KDC.  On the

+   other hand, the client treats a series of exchanges with KDCs as a

+   single conversation.  Each exchange accumulates state and hopefully

+   brings the client closer to a successful authentication.

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 5]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   These models for state management are in apparent conflict.  For many

+   of the simpler pre-authentication scenarios, the client uses one

+   round trip to find out what mechanisms the KDC supports.  Then the

+   next request contains sufficient pre-authentication for the KDC to be

+   able to return a successful reply.  For these simple scenarios, the

+   client only sends one request with pre-authentication data and so the

+   conversation is trivial.  For more complex conversations, the KDC

+   needs to provide the client with a cookie to include in future

+   requests to capture the current state of the authentication session.

+   Handling of multiple round-trip mechanisms is discussed in

+   Section 6.3.

+

+   This framework specifies the behavior of Kerberos pre-authentication

+   mechanisms used to identify users or to modify the reply key used to

+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry

+   extensions to Kerberos that have nothing to do with proving the

+   identity of the user or establishing a reply key.  Such extensions

+   are outside the scope of this framework.  However mechanisms that do

+   accomplish these goals should follow this framework.

+

+   This framework specifies the minimum state that a Kerberos

+   implementation needs to maintain while handling a request in order to

+   process pre-authentication.  It also specifies how Kerberos

+   implementations process the padata at each step of the AS request

+   process.

+

+3.1.  Information Managed by the Pre-authentication Model

+

+   The following information is maintained by the client and KDC as each

+   request is being processed:

+

+   o  The reply key used to encrypt the KDC reply

+

+   o  How strongly the identity of the client has been authenticated

+

+   o  Whether the reply key has been used in this conversation

+

+   o  Whether the reply key has been replaced in this conversation

+

+   o  Whether the contents of the KDC reply can be verified by the

+      client principal

+

+

+   Conceptually, the reply key is initially the long-term key of the

+   principal.  However, principals can have multiple long-term keys

+   because of support for multiple encryption types, salts and

+   string2key parameters.  As described in Section 5.2.7.5 of the

+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 6]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   the client what types of keys are available.  Thus in full

+   generality, the reply key in the pre-authentication model is actually

+   a set of keys.  At the beginning of a request, it is initialized to

+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on

+   the KDC.  If multiple reply keys are available, the client chooses

+   which one to use.  Thus the client does not need to treat the reply

+   key as a set.  At the beginning of a request, the client picks a

+   reply key to use.

+

+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-

+   INFO2 element.  Since the KDC already knows the client's list of

+   supported enctypes from the request, no interoperability problems are

+   created by choosing a single possible reply key.  This way, the KDC

+   implementation avoids the complexity of treating the reply key as a

+   set.

+

+   When the padata in the request is verified by the KDC, then the

+   client is known to have that key, therefore the KDC SHOULD pick the

+   same key as the reply key.

+

+   At the beginning of handling a message on both the client and the

+   KDC, the client's identity is not authenticated.  A mechanism may

+   indicate that it has successfully authenticated the client's

+   identity.  This information is useful to keep track of on the client

+   in order to know what pre-authentication mechanisms should be used.

+   The KDC needs to keep track of whether the client is authenticated

+   because the primary purpose of pre-authentication is to authenticate

+   the client identity before issuing a ticket.  The handling of

+   authentication strength using various authentication mechanisms is

+   discussed in Section 6.6.

+

+   Initially the reply key has not been used.  A pre-authentication

+   mechanism that uses the reply key to encrypt or checksum some data in

+   the generation of new keys MUST indicate that the reply key is used.

+   This state is maintained by the client and the KDC to enforce the

+   security requirement stated in Section 4.3 that the reply key cannot

+   be replaced after it is used.

+

+   Initially the reply key has not been replaced.  If a mechanism

+   implements the Replace Reply Key facility discussed in Section 4.3,

+   then the state MUST be updated to indicate that the reply key has

+   been replaced.  Once the reply key has been replaced, knowledge of

+   the reply key is insufficient to authenticate the client.  The reply

+   key is marked replaced in exactly the same situations as the KDC

+   reply is marked as not being verified to the client principal.

+   However, while mechanisms can verify the KDC reply to the client,

+   once the reply key is replaced, then the reply key remains replaced

+   for the remainder of the conversation.

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 7]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   Without pre-authentication, the client knows that the KDC reply is

+   authentic and has not been modified because it is encrypted in a

+   long-term key of the client.  Only the KDC and the client know that

+   key.  So at the start of a conversation, the KDC reply is presumed to

+   be verified using the client principal's long-term key.  Any pre-

+   authentication mechanism that sets a new reply key not based on the

+   principal's long-term secret MUST either verify the KDC reply some

+   other way or indicate that the reply is not verified.  If a mechanism

+   indicates that the reply is not verified then the client

+   implementation MUST return an error unless a subsequent mechanism

+   verifies the reply.  The KDC needs to track this state so it can

+   avoid generating a reply that is not verified.

+

+   The typical Kerberos request does not provide a way for the client

+   machine to know that it is talking to the correct KDC.  Someone who

+   can inject packets into the network between the client machine and

+   the KDC and who knows the password that the user will give to the

+   client machine can generate a KDC reply that will decrypt properly.

+   So, if the client machine needs to authenticate that the user is in

+   fact the named principal, then the client machine needs to do a TGS

+   request for itself as a service.  Some pre-authentication mechanisms

+   may provide a way for the client to authenticate the KDC.  Examples

+   of this include signing the reply that can be verified using a well-

+   known public key or providing a ticket for the client machine as a

+   service.

+

+3.2.  Initial Pre-authentication Required Error

+

+   Typically a client starts a conversation by sending an initial

+   request with no pre-authentication.  If the KDC requires pre-

+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.

+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,

+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED

+   (defined in Section 6.3) for pre-authentication configurations that

+   use multi-round-trip mechanisms; see Section 3.4 for details of that

+   case.

+

+   The KDC needs to choose which mechanisms to offer the client.  The

+   client needs to be able to choose what mechanisms to use from the

+   first message.  For example consider the KDC that will accept

+   mechanism A followed by mechanism B or alternatively the single

+   mechanism C. A client that supports A and C needs to know that it

+   should not bother trying A.

+

+   Mechanisms can either be sufficient on their own or can be part of an

+   authentication set--a group of mechanisms that all need to

+   successfully complete in order to authenticate a client.  Some

+   mechanisms may only be useful in authentication sets; others may be

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 8]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   useful alone or in authentication sets.  For the second group of

+   mechanisms, KDC policy dictates whether the mechanism will be part of

+   an authentication set or offered alone.  For each mechanism that is

+   offered alone, the KDC includes the pre-authentication type ID of the

+   mechanism in the padata sequence returned in the

+   KDC_ERR_PREAUTH_REQUIRED error.

+

+   The KDC SHOULD NOT send data that is encrypted in the long-term

+   password-based key of the principal.  Doing so has the same security

+   exposures as the Kerberos protocol without pre-authentication.  There

+   are few situations where pre-authentication is desirable and where

+   the KDC needs to expose cipher text encrypted in a weak key before

+   the client has proven knowledge of that key.

+

+3.3.  Client to KDC

+

+   This description assumes that a client has already received a

+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs

+   optimistic pre-authentication then the client needs to optimistically

+   guess values for the information it would normally receive from that

+   error response.

+

+   The client starts by initializing the pre-authentication state as

+   specified.  It then processes the padata in the

+   KDC_ERR_PREAUTH_REQUIRED.

+

+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the

+   client MAY ignore any padata it chooses unless doing so violates a

+   specification to which the client conforms.  Clients conforming to

+   this specification MUST NOT ignore the padata defined in Section 6.3.

+   Clients SHOULD process padata unrelated to this framework or other

+   means of authenticating the user.  Clients SHOULD choose one

+   authentication set or mechanism that could lead to authenticating the

+   user and ignore the rest.  Since the list of mechanisms offered by

+   the KDC is in the decreasing preference order, clients typically

+   choose the first mechanism or authentication set that the client can

+   usefully perform.  If a client chooses to ignore a padata it MUST NOT

+   process the padata, allow the padata to affect the pre-authentication

+   state, nor respond to the padata.

+

+   For each padata the client chooses to process, the client processes

+   the padata and modifies the pre-authentication state as required by

+   that mechanism.  Padata are processed in the order received from the

+   KDC.

+

+   After processing the padata in the KDC error, the client generates a

+   new request.  It processes the pre-authentication mechanisms in the

+   order in which they will appear in the next request, updating the

+

+

+

+Zhu & Hartman           Expires January 15, 2009                [Page 9]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   state as appropriate.  The request is sent when it is complete.

+

+3.4.  KDC to Client

+

+   When a KDC receives an AS request from a client, it needs to

+   determine whether it will respond with an error or an AS reply.

+   There are many causes for an error to be generated that have nothing

+   to do with pre-authentication; they are discussed in the core

+   Kerberos specification.

+

+   From the standpoint of evaluating the pre-authentication, the KDC

+   first starts by initializing the pre-authentication state.  It then

+   processes the padata in the request.  As mentioned in Section 3.3,

+   the KDC MAY ignore padata that is inappropriate for the configuration

+   and MUST ignore padata of an unknown type.  The KDC MUST NOT ignore

+   padata of types used in previous messages.  For example, if a KDC

+   issues a KDC_ERR_PREAUTH_REQUIRED error including padata of type x,

+   then the KDC cannot ignore padata of type x received in an AS-REQ

+   message from the client.

+

+   At this point the KDC decides whether it will issue an error or a

+   reply.  Typically a KDC will issue a reply if the client's identity

+   has been authenticated to a sufficient degree.

+

+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC

+   first starts by initializing the pre-authentication state.  Then it

+   processes any padata in the client's request in the order provided by

+   the client.  Mechanisms that are not understood by the KDC are

+   ignored.  Next, it generates padata for the error response, modifying

+   the pre-authentication state appropriately as each mechanism is

+   processed.  The KDC chooses the order in which it will generate

+   padata (and thus the order of padata in the response), but it needs

+   to modify the pre-authentication state consistently with the choice

+   of order.  For example, if some mechanism establishes an

+   authenticated client identity, then the subsequent mechanisms in the

+   generated response receive this state as input.  After the padata is

+   generated, the error response is sent.  Typically the errors with the

+   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a converstation will include

+   KDC state as discussed in Section 6.3.

+

+   To generate a final reply, the KDC generates the padata modifying the

+   pre-authentication state as necessary.  Then it generates the final

+   response, encrypting it in the current pre-authentication reply key.

+

+

+4.  Pre-Authentication Facilities

+

+   Pre-Authentication mechanisms can be thought of as providing various

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 10]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   conceptual facilities.  This serves two useful purposes.  First,

+   mechanism authors can choose only to solve one specific small

+   problem.  It is often useful for a mechanism designed to offer key

+   management not to directly provide client authentication but instead

+   to allow one or more other mechanisms to handle this need.  Secondly,

+   thinking about the abstract services that a mechanism provides yields

+   a minimum set of security requirements that all mechanisms providing

+   that facility must meet.  These security requirements are not

+   complete; mechanisms will have additional security requirements based

+   on the specific protocol they employ.

+

+   A mechanism is not constrained to only offering one of these

+   facilities.  While such mechanisms can be designed and are sometimes

+   useful, many pre-authentication mechanisms implement several

+   facilities.  By combining multiple facilities in a single mechanism,

+   it is often easier to construct a secure, simple solution than by

+   solving the problem in full generality.  Even when mechanisms provide

+   multiple facilities, they need to meet the security requirements for

+   all the facilities they provide.  If the FAST factor approach is

+   used, it is likely that one or a small number of facilities can be

+   provided by a single mechanism without complicating the security

+   analysis.

+

+   According to Kerberos extensibility rules (Section 1.5 of the

+   Kerberos specification [RFC4120]), an extension MUST NOT change the

+   semantics of a message unless a recipient is known to understand that

+   extension.  Because a client does not know that the KDC supports a

+   particular pre-authentication mechanism when it sends an initial

+   request, a pre-authentication mechanism MUST NOT change the semantics

+   of the request in a way that will break a KDC that does not

+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to

+   clients that affect the core semantics unless the client has

+   indicated support for the message.

+

+   The only state in this model that would break the interpretation of a

+   message is changing the expected reply key.  If one mechanism changed

+   the reply key and a later mechanism used that reply key, then a KDC

+   that interpreted the second mechanism but not the first would fail to

+   interpret the request correctly.  In order to avoid this problem,

+   extensions that change core semantics are typically divided into two

+   parts.  The first part proposes a change to the core semantic--for

+   example proposes a new reply key.  The second part acknowledges that

+   the extension is understood and that the change takes effect.

+   Section 4.2 discusses how to design mechanisms that modify the reply

+   key to be split into a proposal and acceptance without requiring

+   additional round trips to use the new reply key in subsequent pre-

+   authentication.  Other changes in the state described in Section 3.1

+   can safely be ignored by a KDC that does not understand a mechanism.

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 11]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   Mechanisms that modify the behavior of the request outside the scope

+   of this framework need to carefully consider the Kerberos

+   extensibility rules to avoid similar problems.

+

+4.1.  Client-authentication Facility

+

+   The client authentication facility proves the identity of a user to

+   the KDC before a ticket is issued.  Examples of mechanisms

+   implementing this facility include the encrypted timestamp facility

+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].

+   Mechanisms that provide this facility are expected to mark the client

+   as authenticated.

+

+   Mechanisms implementing this facility SHOULD require the client to

+   prove knowledge of the reply key before transmitting a successful KDC

+   reply.  Otherwise, an attacker can intercept the pre-authentication

+   exchange and get a reply to attack.  One way of proving the client

+   knows the reply key is to implement the Replace Reply Key facility

+   along with this facility.  The PKINIT mechanism [RFC4556] implements

+   Client Authentication alongside Replace Reply Key.

+

+   If the reply key has been replaced, then mechanisms such as

+   encrypted-timestamp that rely on knowledge of the reply key to

+   authenticate the client MUST NOT be used.

+

+4.2.  Strengthening-reply-key Facility

+

+   Particularly, when dealing with keys based on passwords, it is

+   desirable to increase the strength of the key by adding additional

+   secrets to it.  Examples of sources of additional secrets include the

+   results of a Diffie-Hellman key exchange or key bits from the output

+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can

+   be first combined with the existing reply key and then converted to a

+   protocol key using tools defined in Section 6.1.

+

+   Typically a mechanism implementing this facility will know that the

+   other side of the exchange supports the facility before the reply key

+   is changed.  For example, a mechanism might need to learn the

+   certificate for a KDC before encrypting a new key in the public key

+   belonging to that certificate.  However, if a mechanism implementing

+   this facility wishes to modify the reply key before knowing that the

+   other party in the exchange supports the mechanism, it proposes

+   modifying the reply key.  The other party then includes a message

+   indicating that the proposal is accepted if it is understood and

+   meets policy.  In many cases it is desirable to use the new reply key

+   for client authentication and for other facilities.  Waiting for the

+   other party to accept the proposal and actually modify the reply key

+   state would add an additional round trip to the exchange.  Instead,

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 12]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   mechanism designers are encouraged to include a typed hole for

+   additional padata in the message that proposes the reply key change.

+   The padata included in the typed hole are generated assuming the new

+   reply key.  If the other party accepts the proposal, then these

+   padata are considered as an inner level.  As with the outer level,

+   one authentication set or mechanism is typically chosen for client

+   authentication, along with auxiliary mechanisms such as KDC cookies,

+   and other mechanisms are ignored.  When mechanisms include such a

+   container, the hint provided for use in authentication sets MUST

+   contain a sequence of inner mechanisms along with hints for those

+   mechanisms.  The party generating the proposal can determine whether

+   the padata were processed based on whether the proposal for the reply

+   key is accepted.

+

+   The specific formats of the proposal message, including where padata

+   are included is a matter for the mechanism specification.  Similarly,

+   the format of the message accepting the proposal is mechanism-

+   specific.

+

+   Mechanisms implementing this facility and including a typed hole for

+   additional padata MUST checksum that padata using a keyed checksum or

+   encrypt the padata.  This requirement protects against modification

+   of the contents of the typed hole.  By modifying these contents an

+   attacker might be able to choose which mechanism is used to

+   authenticate the client, or to convince a party to provide text

+   encrypted in a key that the attacker had manipulated.  It is

+   important that mechanisms strengthen the reply key enough that using

+   it to checksum padata is appropriate.

+

+4.3.  Replacing-reply-key Facility

+

+   The Replace Reply Key facility replaces the key in which a successful

+   AS reply will be encrypted.  This facility can only be used in cases

+   where knowledge of the reply key is not used to authenticate the

+   client.  The new reply key MUST be communicated to the client and the

+   KDC in a secure manner.  Mechanisms implementing this facility MUST

+   mark the reply key as replaced in the pre-authentication state.

+   Mechanisms implementing this facility MUST either provide a mechanism

+   to verify the KDC reply to the client or mark the reply as unverified

+   in the pre-authentication state.  Mechanisms implementing this

+   facility SHOULD NOT be used if a previous mechanism has used the

+   reply key.

+

+   As with the strengthening-reply-key facility, Kerberos extensibility

+   rules require that the reply key not be changed unless both sides of

+   the exchange understand the extension.  In the case of this facility

+   it will likely be the case for both sides to know that the facility

+   is available by the time that the new key is available to be used.

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 13]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   However, mechanism designers can use a container for padata in a

+   proposal message as discussed in Section 4.2 if appropriate.

+

+4.4.  KDC-authentication Facility

+

+   This facility verifies that the reply comes from the expected KDC.

+   In traditional Kerberos, the KDC and the client share a key, so if

+   the KDC reply can be decrypted then the client knows that a trusted

+   KDC responded.  Note that the client machine cannot trust the client

+   unless the machine is presented with a service ticket for it

+   (typically the machine can retrieve this ticket by itself).  However,

+   if the reply key is replaced, some mechanism is required to verify

+   the KDC.  Pre-authentication mechanisms providing this facility allow

+   a client to determine that the expected KDC has responded even after

+   the reply key is replaced.  They mark the pre-authentication state as

+   having been verified.

+

+

+5.  Requirements for Pre-Authentication Mechanisms

+

+   This section lists requirements for specifications of pre-

+   authentication mechanisms.

+

+   For each message in the pre-authentication mechanism, the

+   specification describes the pa-type value to be used and the contents

+   of the message.  The processing of the message by the sender and

+   recipient is also specified.  This specification needs to include all

+   modifications to the pre-authentication state.

+

+   Generally mechanisms have a message that can be sent in the error

+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an

+   authentication set.  If the client needs information such as trusted

+   certificate authorities in order to determine if it can use the

+   mechanism, then this information should be in that message.  In

+   addition, such mechanisms should also define a pa-hint to be included

+   in authentication sets.  Often, the same information included in the

+   padata-value is appropriate to include in the pa-hint (as defined in

+   Section 6.4).

+

+   In order to ease security analysis the mechanism specification should

+   describe what facilities from this document are offered by the

+   mechanism.  For each facility, the security consideration section of

+   the mechanism specification should show that the security

+   requirements of that facility are met.  This requirement is

+   applicable to any FAST factor that provides authentication

+   information.

+

+   Significant problems have resulted in the specification of Kerberos

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 14]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   protocols because much of the KDC exchange is not protected against

+   authentication.  The security considerations section should discuss

+   unauthenticated plaintext attacks.  It should either show that

+   plaintext is protected or discuss what harm an attacker could do by

+   modifying the plaintext.  It is generally acceptable for an attacker

+   to be able to cause the protocol negotiation to fail by modifying

+   plaintext.  More significant attacks should be evaluated carefully.

+

+   As discussed in Section 6.3, there is no guarantee that a client will

+   use the same KDCs for all messages in a conversation.  The mechanism

+   specification needs to show why the mechanism is secure in this

+   situation.  The hardest problem to deal with, especially for

+   challenge/response mechanisms is to make sure that the same response

+   cannot be replayed against two KDCs while allowing the client to talk

+   to any KDC.

+

+

+6.  Tools for Use in Pre-Authentication Mechanisms

+

+   This section describes common tools needed by multiple pre-

+   authentication mechanisms.  By using these tools mechanism designers

+   can use a modular approach to specify mechanism details and ease

+   security analysis.

+

+6.1.  Combining Keys

+

+   Frequently a weak key needs to be combined with a stronger key before

+   use.  For example, passwords are typically limited in size and

+   insufficiently random, therefore it is desirable to increase the

+   strength of the keys based on passwords by adding additional secrets.

+   Additional source of secrecy may come from hardware tokens.

+

+   This section provides standard ways to combine two keys into one.

+

+   KRB-FX-CF1() is defined to combine two pass-phrases.

+

+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)

+       KRB-FX-CF1(x, y) -> x || y

+

+   Where || denotes concatenation.  The strength of the final key is

+   roughly the total strength of the individual keys being combined

+   assuming that the string_to_key() function [RFC3961] uses all its

+   input evenly.

+

+   An example usage of KRB-FX-CF1() is when a device provides random but

+   short passwords, the password is often combined with a personal

+   identification number (PIN).  The password and the PIN can be

+   combined using KRB-FX-CF1().

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 15]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()

+   function defined in [RFC3961].

+

+   Given two input keys, K1 and K2, where K1 and K2 can be of two

+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as

+   follows:

+

+       KRB-FX-CF2(protocol key, protocol key, octet string,

+                 octet string)  ->  (protocol key)

+

+       PRF+(K1, pepper1) -> octet-string-1

+       PRF+(K2, pepper2) -> octet-string-2

+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->

+              random-to-key(octet-string-1 ^ octet-string-2)

+

+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as

+   follows:

+

+    PRF+(protocol key, octet string) -> (octet string)

+

+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||

+                  pseudo-random( key, 2 || shared-info ) ||

+                  pseudo-random( key, 3 || shared-info ) || ...

+

+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet

+   integer.  The pseudo-random() operation is specified by the enctype

+   of the protocol key.  PRF+() uses the counter to generate enough bits

+   as needed by the random-to-key() [RFC3961] function for the

+   encryption type specified for the resulting key; unneeded bits are

+   removed from the tail.

+

+   Mechanism designers MUST specify the values for the input parameter

+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The

+   pepper1 and pepper2 MUST be distinct so that if the two keys being

+   combined are the same, the resulting key is not a trivial key.

+

+6.2.  Protecting Requests/Responses

+

+   Mechanism designers SHOULD protect clear text portions of pre-

+   authentication data.  Various denial of service attacks and downgrade

+   attacks against Kerberos are possible unless plaintexts are somehow

+   protected against modification.  An early design goal of Kerberos

+   Version 5 [RFC4120] was to avoid encrypting more of the

+   authentication exchange that was required.  (Version 4 doubly-

+   encrypted the encrypted part of a ticket in a KDC reply, for

+   example.)  This minimization of encryption reduces the load on the

+   KDC and busy servers.  Also, during the initial design of Version 5,

+   the existence of legal restrictions on the export of cryptography

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 16]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   made it desirable to minimize of the number of uses of encryption in

+   the protocol.  Unfortunately, performing this minimization created

+   numerous instances of unauthenticated security-relevant plaintext

+   fields.

+

+   If there is more than one roundtrip for an authentication exchange,

+   mechanism designers need to allow either the client or the KDC to

+   provide a checksum of all the messages exchanged on the wire in the

+   conversation, and the checksum is then verified by the receiver.

+

+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.

+

+   Primitives defined in [RFC3961] are RECOMMENDED for integrity

+   protection and confidentiality.  Mechanisms based on these primitives

+   are crypto-agile as the result of using [RFC3961] along with

+   [RFC4120].  The advantage afforded by crypto-agility is the ability

+   to avoid a multi-year standardization and deployment cycle to fix a

+   problem that is specific to a particular algorithm, when real attacks

+   do arise against that algorithm.

+

+   Note that data used by FAST factors (defined in Section 6.5) is

+   encrypted in a protected channel, thus they do not share the un-

+   authenticated-text issues with mechanisms designed as full-blown pre-

+   authentication mechanisms.

+

+6.3.  Managing States for the KDC

+

+   Kerberos KDCs are stateless.  There is no requirement that clients

+   will choose the same KDC for the second request in a conversation.

+   Proxies or other intermediate nodes may also influence KDC selection.

+   So, each request from a client to a KDC must include sufficient

+   information that the KDC can regenerate any needed state.  This is

+   accomplished by giving the client a potentially long opaque cookie in

+   responses to include in future requests in the same conversation.

+   The KDC MAY respond that a conversation is too old and needs to

+   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.

+

+       KDC_ERR_PREAUTH_EXPIRED            TBA

+

+   When a client receives this error, the client SHOULD abort the

+   existing conversation, and restart a new one.

+

+   An example, where more than one message from the client is needed, is

+   when the client is authenticated based on a challenge-response

+   scheme.  In that case, the KDC needs to keep track of the challenge

+   issued for a client authentication request.

+

+   The PA-FX-COOKIE pdata type is defined in this section to facilitate

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 17]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   state management.  This padata is sent by the KDC when the KDC

+   requires state for a future transaction.  The client includes this

+   opaque token in the next message in the conversation.  The token may

+   be relatively large; clients MUST be prepared for tokens somewhat

+   larger than the size of all messages in a conversation.

+

+       PA_FX_COOKIE                       TBA

+           -- Stateless cookie that is not tied to a specific KDC.

+

+   The corresponding padata-value field [RFC4120] contains the

+   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the

+   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:

+

+      PA-FX-COOKIE ::= SEQUENCE {

+          conversationId  [0] OCTET STRING,

+             -- Contains the identifier of this conversation. This field

+             -- must contain the same value for all the messages

+             -- within the same conversation.

+          enc-binding-key [1] EncryptedData OPTIONAL,

+                          -- EncryptionKey --

+             -- This field is present when and only when a FAST

+             -- padata as defined in Section 6.5 is included.

+             -- The encrypted data, when decrypted, contains an

+             -- EncryptionKey structure.

+             -- This encryption key is encrypted using the armor key

+             -- (defined in Section 6.5.1), and the key usage for the

+             -- encryption is KEY_USAGE_FAST_BINDING_KEY.

+             -- Present only once in a converstation.

+          cookie          [2] OCTET STRING OPTIONAL,

+             -- Opaque data, for use to associate all the messages in

+             -- a single conversation between the client and the KDC.

+             -- This is generated by the KDC and the client MUST copy

+             -- the exact cookie encapsulated in a PA_FX_COOKIE data

+             -- element into the next message of the same conversation.

+          ...

+      }

+      KEY_USAGE_FAST_BINDING_KEY         TBA

+

+   The conversationId field contains a sufficiently-long rand number

+   that uniquely identifies the conversation.  If a PA_FX_COOKIE padata

+   is present in one message, a PA_FX_COOKIE structure MUST be present

+   in all subsequent messages of the same converstation between the

+   client and the KDC, with the same conversationId value.

+

+   The enc-binding-key field is present when and only when a FAST padata

+   (defined in Section 6.5) is included.  The enc-binding-key field is

+   present only once in a conversation.  It MUST be ignored if it is

+   present in a subsequent message of the same conversation.  The

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 18]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   encrypted data, when decrypted, contains an EncryptionKey structure

+   that is called the binding key.  The binding key is encrypted using

+   the armor key (defined in Section 6.5.1), and the key usage for the

+   encryption is KEY_USAGE_FAST_BINDING_KEY.

+

+   If a Kerberos FAST padata as defined in Section 6.5 is included in

+   one message, it MUST be included in all subsequent messages of the

+   same conversation.

+

+   When FAST padata as defined Section 6.5 is included, the PA-FX-COOKIE

+   padata MUST be included.

+

+   The cookie token is generated by the KDC and the client MUST copy the

+   exact cookie encapsulated in a PA_FX_COOKIE data element into the

+   next message of the same conversation.  The content of the cookie

+   field is a local matter of the KDC.  However the KDC MUST construct

+   the cookie token in such a manner that a malicious client cannot

+   subvert the authentication process by manipulating the token.  The

+   KDC implementation needs to consider expiration of tokens, key

+   rollover and other security issues in token design.  The content of

+   the cookie field is likely specific to the pre-authentication

+   mechanisms used to authenticate the client.  If a client

+   authentication response can be replayed to multiple KDCs via the

+   PA_FX_COOKIE mechanism, an expiration in the cookie is RECOMMENDED to

+   prevent the response being presented indefinitely.

+

+   If at least one more message for a mechanism or a mechanism set is

+   expected by the KDC, the KDC returns a

+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to

+   identify the conversation with the client according to Section 6.5.4.

+

+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA

+

+6.4.  Pre-authentication Set

+

+   If all mechanisms in a group need to successfully complete in order

+   to authenticate a client, the client and the KDC SHOULD use the

+   PA_AUTHENTICATION_SET padata element.

+

+   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER

+   encoding of the PA-AUTHENTICATION-SET structure:

+

+

+

+

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 19]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM

+

+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {

+            pa-type      [0] Int32,

+                -- same as padata-type.

+            pa-hint      [1] OCTET STRING OPTIONAL,

+            pa-value  [2] OCTET STRING OPTIONAL,

+            ...

+        }

+

+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure

+   contains the corresponding value of padata-type in PA-DATA [RFC4120].

+   Associated with the pa-type is a pa-hint, which is an octet-string

+   specified by the pre-authentication mechanism.  This hint may provide

+   information for the client which helps it determine whether the

+   mechanism can be used.  For example a public-key mechanism might

+   include the certificate authorities it trusts in the hint info.  Most

+   mechanisms today do not specify hint info; if a mechanism does not

+   specify hint info the KDC MUST NOT send a hint for that mechanism.

+   To allow future revisions of mechanism specifications to add hint

+   info, clients MUST ignore hint info received for mechanisms that the

+   client believes do not support hint info.  The pa-value element of

+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the

+   first padata-value from the KDC to the client.  If the client chooses

+   this authentication set then the client MUST process this pa-value.

+   The pa-value element MUST be absent for all but the first entry in

+   the authentication set.  Clients MUST ignore pa-value for the second

+   and following entries in the authentication set.

+

+   If the client chooses an authentication set, then its AS-REQ message

+   MUST contain a PA_AUTHENTICATION_SET_SELECTED padata element.  This

+   element contains the encoding of the PA-AUTHENTICATION-SET sequence

+   received from the KDC corresponding to the authentication set that is

+   chosen.  The client MUST use the same octet values received from the

+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-

+   wise comparison to identify the selected authentication set.  The

+   PA_AUTHENTICATION_SET_SELECTED padata element MUST come before any

+   padata elements from the authentication set in the padata sequence in

+   the AS-REQ message.  The client MAY cache authentication sets from

+   prior messages and use them to construct an optimistic initial AS-

+   REQ.  If the KDC receives a PA_AUTHENTICATION_SET_SELECTED padata

+   element that does not correspond to an authentication set that it

+   would offer, then the KDC returns the

+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The edata in this

+   error contains a sequence of padata just as for the

+   KDC_ERR_PREAUTH_REQUIRED error.

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 20]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+      PA_AUTHENTICATION_SET_SELECTED         TBA

+      KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA

+

+   The PA-AUTHENTICATION-SET appears only in the first message from the

+   KDC to the client.  In particular, the client MAY fail if the

+   authentication mechanism sets change as the conversation progresses.

+   Clients MAY assume that the hints provided in the authentication set

+   contain enough information that the client knows what user interface

+   elements need to be displayed during the entire authentication

+   conversation.  Exceptional circumstances such as expired passwords or

+   expired accounts may require that additional user interface be

+   displayed.  Mechanism designers need to carefully consider the design

+   of their hints so that the client has this information.  This way,

+   clients can construct necessary dialogue boxes or wizards based on

+   the authentication set and can present a coherent user interface.

+   Current standards for user interface do not provide an acceptable

+   experience when the client has to ask additional questions later in

+   the conversation.

+

+   When indicating which sets of pre-authentication mechanisms are

+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element

+   for each pre-authentication mechanism set.

+

+   The client sends the padata-value for the first mechanism it picks in

+   the pre-authentication set, when the first mechanism completes, the

+   client and the KDC will proceed with the second mechanism, and so on

+   until all mechanisms complete successfully.  The PA_FX_COOKIE as

+   defined in Section 6.3 MUST be sent by the KDC along with the first

+   message that contains a PA-AUTHENTICATION-SET, in order to keep track

+   of KDC states.

+

+   Before the authentication succeeds and a ticket is returned, the

+   message that the client sends is an AS_REQ and the message that the

+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR

+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined

+   in Section 6.3 and the accompanying e-data contains the DER encoding

+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in

+   the METHOD-DATA.  If there is no padata, the e-data field is absent

+   in the KRB-ERROR message.

+

+   If the client sends the last message for a given mechanism, then the

+   KDC sends the first message for the next mechanism.  If the next

+   mechanism does not start with a KDC-side challenge, then the KDC

+   includes a padata item with the appropriate pa-type and an empty pa-

+   data.

+

+   If the KDC sends the last message for a particular mechanism, the KDC

+   also includes the first padata for the next mechanism.

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 21]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+6.5.  Definition of Kerberos FAST Padata

+

+   As described in [RFC4120], Kerberos is vulnerable to offline

+   dictionary attacks.  An attacker can request an AS-REP and try

+   various passwords to see if they can decrypt the resulting ticket.

+   RFC 4120 provides the entrypted timestap pre-authentication method

+   that ameliorates the situation somewhat by requiring that an attacker

+   observe a successful authentication.  However stronger security is

+   desired in many environments.  The Kerberos FAST pre-authentication

+   padata defined in this section provides a tool to significantly

+   reduce vulnerability to offline dictionary attack.  When combined

+   with encrypted timestamp, FAST requires an attacker to mount a

+   successful man-in-the-middle attack to observe ciphertext.  When

+   combined with host keys, FAST can even protect against active

+   attacks.  FAST also provides solutions to common problems for pre-

+   authentication mechanisms such as binding of the request and the

+   reply, freshness guarantee of the authentication.  FAST itself,

+   however, does not authenticate the client or the KDC, instead, it

+   provides a typed hole to allow pre-authentication data be tunneled.

+   A pre-authentication data element used within FAST is called a FAST

+   factor.  A FAST factor captures the minimal work required for

+   extending Kerberos to support a new pre-authentication scheme.

+

+   A FAST factor MUST NOT be used outside of FAST unless its

+   specification explicitly allows so.  The typed holes in FAST messages

+   can also be used as generic holes for other padata that are not

+   intended to prove the client's identity, or establish the reply key.

+

+   New pre-authentication mechanisms SHOULD be designed as FAST factors,

+   instead of full-blown pre-authentication mechanisms.

+

+   FAST factors that are pre-authentication mechanisms MUST meet the

+   requirements in Section 5.

+

+   FAST employs an armoring scheme.  The armor can be a Ticket Granting

+   Ticket (TGT) obtained by the client's machine using the host keys to

+   pre-authenticate with the KDC, or an anonymous TGT obtained based on

+   anonymous PKINIT [KRB-ANON] [RFC4556].

+

+   The rest of this section describes the types of armors and the syntax

+   of the messages used by FAST.  Conforming implementations MUST

+   support Kerberos FAST padata.

+

+   Any FAST armor scheme MUST provide a fresh armor key for each

+   conversation.  Clients and KDCs can assume that if a message is

+   encrypted and integrity protected with a given armor key then it is

+   part of the conversation using that armor key.

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 22]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+6.5.1.  FAST Armors

+

+   An armor key is used to encrypt pre-authentication data in the FAST

+   request and the response.  The KrbFastArmor structure is defined to

+   identify the armor key.  This structure contains the following two

+   fields: the armor-type identifies the type of armors, and the armor-

+   value as an OCTET STRING contains the description of the armor scheme

+   and the armor key.

+

+        KrbFastArmor ::= SEQUENCE {

+            armor-type   [0] Int32,

+                -- Type of the armor.

+            armor-value  [1] OCTET STRING,

+                -- Value of the armor.

+            ...

+        }

+

+   The value of the armor key is a matter of the armor type

+   specification.  Only one armor type is defined in this document.

+

+        FX_FAST_ARMOR_AP_REQUEST           TBA

+

+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.

+

+   Conforming implementations MUST implement the

+   FX_FAST_ARMOR_AP_REQUEST armor type.

+

+6.5.1.1.  Ticket-based Armors

+

+   This is a ticket-based armoring scheme.  The armor-type is

+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER

+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket

+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.

+   The armor key is the subkey in the AP-REQ authenticator.

+

+   The server name field of the armor ticket MUST identify the TGS of

+   the target realm.  Here are three ways in the decreasing preference

+   order how an armor TGT SHOULD be obtained:

+

+   1.  If the client is authenticating from a host machine whose

+       Kerberos realm has a trust path to the client's realm, the host

+       machine obtains a TGT by pre-authenticating intitialy the realm

+       of the host machine using the host keys.  If the client's realm

+       is different than the realm of the local host, the machine then

+       obtains a cross-realm TGT to the client's realm as the armor

+       ticket.  Otherwise, the host's primary TGT is the armor ticket.

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 23]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   2.  If the client's host machine cannot obtain a host ticket strictly

+       based on RFC4120, but the KDC has an asymmetric signing key that

+       the client can verify the binding between the public key of the

+       signing key and the expected KDC, the client can use anonymous

+       PKINIT [KRB-ANON] [RFC4556] to authenticate the KDC and obtain an

+       anonymous TGT as the armor ticket.  The armor key can be a cross-

+       team TGT obtained based on the initial primary TGT obtained using

+       anonymous PKINIT with KDC authentication.

+

+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous

+       TGT without KDC authentication and that TGT is the armor ticket.

+       Note that this mode of operation is vulnerable to man-in-the-

+       middle attacks at the time of obtaining the initial anonymous

+       armor TGT.  The armor key can be a cross-team TGT obtained based

+       on the initial primary TGT obtained using anonymous PKINIT

+       without KDC authentication.

+

+   Because the KDC does not know if the client is able to trust the

+   ticket it has, the KDC MUST initialize the pre-authentication state

+   to an unverified KDC.

+

+6.5.2.  FAST Request

+

+   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-

+   authentication padata.  The corresponding padata-value field

+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-

+   REQUEST.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 24]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+       PA_FX_FAST                         TBA

+           -- Padata type for Kerberos FAST

+

+       PA-FX-FAST-REQUEST ::= CHOICE {

+           armored-data [0] KrbFastArmoredReq,

+           ...

+       }

+

+       KrbFastArmoredReq ::= SEQUENCE {

+           armor        [0] KrbFastArmor OPTIONAL,

+               -- Contains the armor that identifies the armor key.

+               -- MUST be present in AS-REQ.

+               -- MUST be absent in TGS-REQ.

+           req-checksum [1] Checksum,

+               -- Checksum performed over the type KDC-REQ-BODY for

+               -- the req-body field of the KDC-REQ structure defined in

+               -- [RFC4120]

+               -- The checksum key is the armor key, the checksum

+               -- type is the required checksum type for the enctype of

+               -- the armor key, and the key usage number is

+               -- KEY_USAGE_FAST_REA_CHKSUM.

+           enc-fast-req [2] EncryptedData, -- KrbFastReq --

+               -- The encryption key is the armor key, and the key usage

+               -- number is KEY_USAGE_FAST_ENC.

+           ...

+       }

+

+       KEY_USAGE_FAST_REA_CHKSUM          TBA

+       KEY_USAGE_FAST_ENC                 TBA

+

+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.

+   The KrbFastArmoredReq encapsulates the encrypted padata.

+

+   The enc-fast-req field contains an encrypted KrbFastReq structure.

+   The armor key is used to encrypt the KrbFastReq structure, and the

+   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.

+

+        KEY_USAGE_FAST_ARMOR               TBA

+

+   The armor key is selected as follows:

+

+   o  In an AS request, the armor field in the KrbFastArmoredReq

+      structure MUST be present and the armor key is identified

+      according to the specification of the armor type.

+

+   o  In a TGS request, the armor field in the KrbFastArmoredReq

+      structure MUST NOT be present and the subkey in the AP-REQ

+      authenticator in the PA-TGS-REQ PA-DATA MUST be present.  In this

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 25]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+      case, the armor key is that subkey in the AP-REQ authenticator.

+

+   The req-checksum field contains a checksum that is performed over the

+   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]

+   structure of the containing message.  The checksum key is the armor

+   key, and the checksum type is the required checksum type for the

+   enctype of the armor key per [RFC3961].  This checksum is included in

+   order to bind the FAST data to the outer request.  A KDC that

+   implements FAST will ignore the outer request, but including a

+   checksum is relatively cheap and may prevent confusing behavior.

+

+   The KrbFastReq structure contains the following information:

+

+        KrbFastReq ::= SEQUENCE {

+            fast-options [0] FastOptions,

+                -- Additional options.

+            padata       [1] SEQUENCE OF PA-DATA,

+                -- padata typed holes.

+            req-body     [2] KDC-REQ-BODY,

+                -- Contains the KDC request body as defined in Section

+                -- 5.4.1 of [RFC4120].

+                -- This req-body field is preferred over the outer field

+                -- in the KDC request.

+             ...

+        }

+

+   The fast-options field indicates various options that are to modify

+   the behavior of the KDC.  The following options are defined:

+

+        FastOptions ::= KerberosFlags

+            -- reserved(0),

+            -- anonymous(1),

+            -- kdc-referrals(16)

+

+

+      Bits    Name          Description

+     -----------------------------------------------------------------

+      0     RESERVED        Reserved for future expansion of this field.

+      1     anonymous       Requesting the KDC to hide client names in

+                            the KDC response, as described next in this

+                            section.

+      16    kdc-referrals   Requesting the KDC to follow referrals, as

+                            described next in this section.

+

+   Bits 1 through 15 (with bit 2 and bit 15 included) are critical

+   options.  If the KDC does not support a critical option, it MUST fail

+   the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS (there is no

+   accompanying e-data defined in this document for this error code).

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 26]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   Bit 16 and onward (with bit 16 included) are non-critical options.

+   KDCs conforming to this specification ignores unknown non-critical

+   options.

+

+        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA

+

+   The anonymous Option

+

+      The Kerberos response defined in [RFC4120] contains the client

+      identity in clear text, This makes traffic analysis

+      straightforward.  The anonymous option is designed to complicate

+      traffic analysis.  If the anonymous option is set, the KDC

+      implementing PA_FX_FAST MUST identify the client as the anonymous

+      principal [KRB-ANON] in the KDC reply and the error response.

+      Hence this option is set by the client if it wishes to conceal the

+      client identity in the KDC response.  A conforming KD ignores the

+      client principal name in the outer KDC-REQ-BODY field, and

+      identifies the client using the cname and crealm fields in the

+      req-body field of the KrbFastReq structure.

+

+   The kdc-referrals Option

+

+      The Kerberos client described in [RFC4120] has to request referral

+      TGTs along the authentication path in order to get a service

+      ticket for the target service.  The Kerberos client described in

+      the [REFERRALS] need to contact the AS specified in the error

+      response in order to complete client referrals.  The kdc-referrals

+      option is designed to minimize the number of messages that need to

+      be processed by the client.  This option is useful when, for

+      example, the client may contact the KDC via a satellite link that

+      has high network latency, or the client has limited computational

+      capabilities.  If the kdc-referrals option is set, the KDC that

+      honors this option acts as the client to follow AS referrals and

+      TGS referrals [REFERRALS], and return the service ticket to the

+      named server principal in the client request using the reply key

+      expected by the client.  The kdc-referrals option can be

+      implemented when the KDC knows the reply key.  The KDC can ignore

+      kdc-referrals option when it does not understand it or it does not

+      allow this option based on local policy.  The client SHOULD be

+      able to process the KDC responses when this option is not honored

+      by the KDC.

+

+   The padata field contains a list of PA-DATA structures as described

+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain

+   FAST factors.  They can also be used as generic typed-holes to

+   contain data not intended for proving the client's identity or

+   establishing a reply key, but for protocol extensibility.

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 27]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   The KDC-REQ-BODY in the FAST structure is used in preference to the

+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-

+   REQ-BODY structure SHOULD be filled in for backwards compatibility

+   with KDCs that do not support FAST.  A conforming KDC ignores the

+   outer KDC-REQ-BODY field in the KDC request.

+

+6.5.3.  FAST Response

+

+   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST

+   padata element in the KDC reply.  In the case of an error, the

+   PA_FX_FAST padata is included in the KDC responses according to

+   Section 6.5.4.

+

+   The corresponding padata-value field [RFC4120] for the PA_FX_FAST in

+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-

+   FAST-REPLY.

+

+      PA-FX-FAST-REPLY ::= CHOICE {

+          armored-data [0] KrbFastArmoredRep,

+          ...

+      }

+

+      KrbFastArmoredRep ::= SEQUENCE {

+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --

+              -- The encryption key is the armor key in the request, and

+              -- the key usage number is KEY_USAGE_FAST_REP.

+          ...

+      }

+      KEY_USAGE_FAST_REP                 TBA

+

+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep

+   structure.  The KrbFastArmoredRep structure encapsulates the padata

+   in the KDC reply in the encrypted form.  The KrbFastResponse is

+   encrypted with the armor key used in the corresponding request, and

+   the key usage number is KEY_USAGE_FAST_REP.

+

+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the

+   KDC response MUST support a local policy that rejects the response.

+   Clients MAY also support policies that fall back to other mechanisms

+   or that do not use pre-authentication when FAST is unavailable.  It

+   is important to consider the potential downgrade attacks when

+   deploying such a policy.

+

+   The KrbFastResponse structure contains the following information:

+

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 28]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+     KrbFastResponse ::= SEQUENCE {

+         padata      [0] SEQUENCE OF PA-DATA,

+             -- padata typed holes.

+         rep-key     [1] EncryptionKey OPTIONAL,

+             -- This, if present, replaces the reply key for AS and TGS.

+             -- MUST be absent in KRB-ERROR.

+         finished    [2] KrbFastFinished OPTIONAL,

+             -- MUST be present if the client is authenticated,

+             -- absent otherwise.

+             -- Typically this is present if and only if the containing

+             -- message is the last one in a conversation.

+         ...

+     }

+

+   The padata field in the KrbFastResponse structure contains a list of

+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These

+   PA-DATA structures are used to carry data advancing the exchange

+   specific for the FAST factors.  They can also be used as generic

+   typed-holes for protocol extensibility.

+

+   The rep-key field, if present, contains the reply key that is used to

+   encrypted the KDC reply.  The rep-key field MUST be absent in the

+   case where an error occurs.  The enctype of the rep-key is the

+   strongest mutually supported by the KDC and the client.

+

+   The finished field contains a KrbFastFinished structure.  It is

+   filled by the KDC in the final message in the conversation; it MUST

+   be absent otherwise.  In other words, this field can only be present

+   in an AS-REP or a TGS-REP when a ticket is returned.

+

+   The KrbFastFinished structure contains the following information:

+

+        KrbFastFinished ::= SEQUENCE {

+            timestamp   [0] KerberosTime,

+            usec        [1] Microseconds,

+                -- timestamp and usec represent the time on the KDC when

+                -- the reply was generated.

+            crealm      [2] Realm,

+            cname       [3] PrincipalName,

+                -- Contains the client realm and the client name.

+            checksum    [4] Checksum,

+                -- Checksum performed over all the messages in the

+                -- conversation, except the containing message.

+                -- The checksum key is the binding key as defined in

+                -- Section 6.3, and the checksum type is the required

+                -- checksum type of the binding key.

+            ...

+        }

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 29]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+        KEY_USAGE_FAST_FINISHED            TBA

+

+   The timestamp and usec fields represent the time on the KDC when the

+   reply ticket was generated, these fields have the same semantics as

+   the corresponding-identically-named fields in Section 5.6.1 of

+   [RFC4120].  The client MUST use the KDC's time in these fields

+   thereafter when using the returned ticket.  Note that the KDC's time

+   in AS-REP may not match the authtime in the reply ticket if the kdc-

+   referrals option is requested and honored by the KDC.

+

+   The cname and crealm fields identify the authenticated client.

+

+   The checksum field contains a checksum of all the messages in the

+   conversation prior to the containing message (the containing message

+   is excluded).  The checksum key is the binding key as defined in

+   Section 6.3, and the checksum type is the required checksum type of

+   the enctype of that key, and the key usage number is

+   KEY_USAGE_FAST_FINISHED. [[anchor9: Examples would be good here; what

+   all goes into the checksum?]]

+

+   When FAST padata is included, the PA-FX-COOKIE padata as defined in

+   Section 6.3 MUST also be included if the KDC expects at least one

+   more message from the client in order to complete the authentication.

+

+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST

+

+   If the Kerberos FAST padata was included in the request, unless

+   otherwise specified, the e-data field of the KRB-ERROR message

+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA

+   [RFC4120] and a PA_FX_FAST is included in the METHOD-DATA.  The KDC

+   MUST include all the padata elements such as PA-ETYPE-INFO2 and

+   padata elments that indicate acceptable pre-authentication mechanisms

+   [RFC4120] and in the KrbFastResponse structure.

+

+   If the Kerberos FAST padata is included in the request but not

+   included in the error reply, it is a matter of the local policy on

+   the client to accept the information in the error message without

+   integrity protection.  The Kerberos client MAY process an error

+   message without a PA-FX-FAST-REPLY, if that is only intended to

+   return better error information to the application, typically for

+   trouble-shooting purposes.

+

+   In the cases where the e-data field of the KRB-ERROR message is

+   expected to carry a TYPED-DATA [RFC4120] element, the

+   PA_FX_TYPED_DATA padata is included in the KrbFastResponse structure

+   to encapsulate the TYPED-DATA [RFC4120] elements.  For example, the

+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR

+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 30]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   [RFC4556].

+

+        PA_FX_TYPED_DATA                   TBA

+            -- This is the padata element that encapsulates a TYPED-DATA

+            -- structure.

+

+   The corresponding padata-value for the PA_FX_TYPED_DATA padata type

+   contains the DER encoding of the ASN.1 type TYPED-DATA [RFC4120].

+

+6.5.5.  The Encrypted Challenge FAST Factor

+

+   The encrypted challenge FAST factor authenticates a client using the

+   client's long-term key.  This factor works similarly to the encrypted

+   time stamp pre-authentication option described in [RFC4120].  The

+   client encrypts a structure containing a timestamp in the challenge

+   key.  The challenge key is KRB-FX-CF2(long_term_key, armor_key,

+   "challengelongterm", "challengearmor").  Because the armor key is

+   fresh and random, the challenge key is fresh and random.  The only

+   purpose of the timestamp is to limit the validity of the

+   authentication so that a request cannot be replayed.  A client MAY

+   base the timestamp based on the KDC time in a KDC error and need not

+   maintain accurate time synchronization itself.  If a client bases its

+   time on an untrusted source, an attacker may trick the client into

+   producing an authentication request that is valid at some future

+   time.  The attacker may be able to use this authentication request to

+   make it appear that a client has authenticated at that future time.

+   If ticket-based armor is used, then the lifetime of the ticket will

+   limit the window in which an attacker can make the client appear to

+   have authenticated.  For many situations, the ability of an attacker

+   to cause a client to appear to have authenticated is not a

+   significant concern; the ability to avoid requiring time

+   synchronization on clients is more valuable.

+

+   The client sends a padata of type PA_ENCRYPTED_CHALLENGE the

+   corresponding padata-value contains the DER encoding of ASN.1 type

+   EncryptedChallenge.

+

+      EncryptedChallenge ::= EncryptedData

+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key

+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the

+              --  client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.

+

+      PA_ENCRYPTED_CHALLENGE          TBA

+      KEY_USAGE_ENC_CHALLENGE_CLIENT  TBA

+      KEY_USAGE_ENC_CHALLENGE_KDC     TBA

+

+   The client includes some time stamp reasonably close to the KDC's

+   current time and encrypts it in the challenge key.  Clients MAY use

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 31]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   the current time; doing so prevents the exposure where an attacker

+   can cause a client to appear to authenticate in the future.  The

+   client sends the request including this factor.

+

+   On receiving an AS-REQ containing the PA_ENCRYPTED_CHALLENGE fast

+   factor, the KDC decrypts the timestamp.  If the decryption fails the

+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including etype-info2 in

+   the error [[anchor11: Or should this be KRB_APP_ERR_MODIFIED?]].  The

+   KDC confirms that the timestamp falls within its current clock skew

+   returning KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see

+   if the encrypted challenge is a replay.  The KDC MUST NOT consider

+   two encrypted challenges replays simply because the time stamps are

+   the same; to be a replay, the ciphertext MUST be identical.  It is

+   not clear that RFC 3961 prevents encryption systems for which an

+   attacker can transform one ciphertext into a different ciphertext

+   yielding an identical plaintext.  So, it may not be safe to base

+   replay detection on the ciphertext in the general case.  However the

+   FAST tunnel provides integrity protection so requiring ciphertext be

+   identical is secure in this instance.  Allowing clients to re-use

+   time stamps avoids requiring that clients maintain state about which

+   time stamps have been used.

+

+   If the KDC accepts the encrypted challenge, it MUST include a padata

+   element of type PA_ENCRYPTED_CHALLENGE.  The KDC encrypts its current

+   time in the challenge key.  The KDC MUST replace the reply key before

+   issuing a ticket. [[anchor12: I'd like to say that the KDC replaces

+   its reply key by this point.  However we need to decide at what

+   points the FAST mechanism for replacing the reply key can be used and

+   how that interacts with this.]]The client MUST check that the

+   timestamp decrypts properly.  The client MAY check that the timestamp

+   is in some reasonable skew of the current time.  The client MUST NOT

+   require that the timestamp be identical to the timestamp in the

+   issued credentials or the returned message.

+

+   The encrypted challenge FAST factor provides the following

+   facilities: client-authentication, KDC authentication.  It does not

+   provide the strengthening-reply-key facility.  The security

+   considerations section of this document provides an explanation why

+   the security requirements are met.

+

+   Conforming implementations MUST support the encrypted challenge FAST

+   factor.

+

+6.6.  Authentication Strength Indication

+

+   Implementations that have pre-authentication mechanisms offering

+   significantly different strengths of client authentication MAY choose

+   to keep track of the strength of the authentication used as an input

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 32]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   into policy decisions.  For example, some principals might require

+   strong pre-authentication, while less sensitive principals can use

+   relatively weak forms of pre-authentication like encrypted timestamp.

+

+   An AuthorizationData data type AD-Authentication-Strength is defined

+   for this purpose.

+

+        AD-authentication-strength         TBA

+

+   The corresponding ad-data field contains the DER encoding of the pre-

+   authentication data set as defined in Section 6.4.  This set contains

+   all the pre-authentication mechanisms that were used to authenticate

+   the client.  If only one pre-authentication mechanism was used to

+   authenticate the client, the pre-authentication set contains one

+   element.

+

+   The AD-authentication-strength element MUST be included in the AD-IF-

+   RELEVANT, thus it can be ignored if it is unknown to the receiver.

+

+

+7.  IANA Considerations

+

+   This document defines several new pa-data types, key usages and error

+   codes.  In addition it would be good to track which pa-data items are

+   only to be used as FAST factors.

+

+

+8.  Security Considerations

+

+   The kdc-referrals option in the Kerberos FAST padata requests the KDC

+   to act as the client to follow referrals.  This can overload the KDC.

+   To limit the damages of denied of service using this option, KDCs MAY

+   restrict the number of simultaneous active requests with this option

+   for any given client principal.

+

+   Because the client secrets are known only to the client and the KDC,

+   the verification of the authenticated timestamp proves the client's

+   identity, the verification of the authenticated timestamp in the KDC

+   reply proves that the expected KDC responded.  The encrypted reply

+   key is contained in the rep-key in the PA-FX-FAST-REPLY.  Therefore,

+   the authenticated timestamp FAST factor as a pre-authentication

+   mechanism offers the following facilities: client-authentication,

+   replacing-reply-key, KDC-authentication.  There is no un-

+   authenticated clear text introduced by the authenticated timestamp

+   FAST factor.

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 33]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+9.  Acknowledgements

+

+   Sam Hartman would like to thank the MIT Kerberos Consortium for its

+   funding of his time on this project prior to April 2008.

+

+   Several suggestions from Jeffery Hutzman based on early revisions of

+   this documents led to significant improvements of this document.

+

+   The proposal to ask one KDC to chase down the referrals and return

+   the final ticket is based on requirements in [ID.CROSS].

+

+   Joel Webber had a proposal for a mechanism similar to FAST that

+   created a protected tunnel for Kerberos pre-authentication.

+

+

+10.  References

+

+10.1.  Normative References

+

+   [KRB-ANON]

+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",

+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.

+

+   [REFERRALS]

+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to

+              Locate Kerberos Realms",

+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in

+              progress), 2007.

+

+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

+              Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

+              Kerberos 5", RFC 3961, February 2005.

+

+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

+              Kerberos Network Authentication Service (V5)", RFC 4120,

+              July 2005.

+

+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 34]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+   [SHA2]     National Institute of Standards and Technology, "Secure 

+              Hash Standard (SHS)", Federal Information Processing 

+              Standards Publication 180-2, August 2002.  

+

+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,

+              Information technology - Abstract Syntax Notation One

+              (ASN.1): Specification of basic notation.

+   

+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,

+              Information technology - ASN.1 encoding Rules:

+              Specification of Basic Encoding Rules (BER), Canonical

+              Encoding Rules (CER) and Distinguished Encoding Rules

+              (DER).              

+

+10.2.  Informative References

+

+   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 

+              Encrypted Key Exchange: A Password-Based Protocol Secure 

+              Against Dictionary Attacks and Password File Compromise". 

+              Proceedings of the 1st ACM Conference on Computer and 

+              Communications Security, ACM Press, November 1993.

+   

+   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 

+              progress.

+

+   [IEEE1363.2] 

+              IEEE P1363.2: Password-Based Public-Key Cryptography, 

+              2004.

+

+   [ID.CROSS]

+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem

+              Statement on the Operation of Kerberos in a Specific

+              System", draft-sakane-krb-cross-problem-statement-02.txt

+              (work in progress), April 2007.

+

+   [KRB-WG.SAM]

+

+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,

+              "Integrating Single-use Authentication Mechanisms with

+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in

+              progress), October 2003.

+

+

+Appendix A.  Change History

+

+   RFC editor, please remove this section before publication.

+

+A.1.  Changes since 07

+

+      Propose replacement of authenticated timestamp with encrypted

+      challenge.  The desire to avoid clients needing time

+      synchronization and to simply the factor.

+      Add a requirement that any FAST armor scheme must provide a fresh

+      key for each conversation.  This allows us to assume that anything

+      encrypted/integrity protected in the right key is fresh and not

+      subject to cross-conversation cut&paste.

+      Removed heartbeat padata.  The KDC will double up messages if it

+      needs to; the client simply sends its message and waits for the

+      next response.

+      Define PA_AUTHENTICATION_SET_SELECTED

+      Clarify a KDC cannot ignore padata is has clamed to support

+

+A.2.  Changes since 06

+

+      Note that even for replace reply key it is likely that the side

+      using the mechanism will know that the other side supports it.

+      Since it is reasonablly unlikely we'll need a container mechanism

+      other than FAST itself, we don't need to optimize for that case.

+      So, we want to optimize for implementation simplicity.  Thus if

+      you do have such a container mechanism interacting with

+      authentication sets we'll assume that the hint need to describe

+      hints for all contained mechanisms.  This closes out a long-

+      standing issue.

+      Write up what Sam believes is the consensus on UI and prompts in

+      the authentication set: clients MAY assume that they have all the

+      UI information they need.

+

+

+Appendix B.  ASN.1 module

+

+     KerberosPreauthFramework {

+           iso(1) identified-organization(3) dod(6) internet(1)

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 35]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+           security(5) kerberosV5(2) modules(4) preauth-framework(3)

+     } DEFINITIONS EXPLICIT TAGS ::= BEGIN

+

+     IMPORTS

+          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,

+          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,

+          Microseconds, KerberosFlags

+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)

+                 dod(6) internet(1) security(5) kerberosV5(2)

+                 modules(4) krb5spec2(2) };

+                 -- as defined in RFC 4120.

+

+     PA-FX-COOKIE ::= SEQUENCE {

+         conversationId  [0] OCTET STRING,

+            -- Contains the identifier of this conversation. This field

+            -- must contain the same value for all the messages

+            -- within the same conversation.

+         enc-binding-key [1] EncryptedData OPTIONAL,

+                         -- EncryptionKey --

+            -- This field is present when and only when a FAST

+            -- padata as defined in Section 6.5 is included.

+            -- The encrypted data, when decrypted, contains an

+            -- EncryptionKey structure.

+            -- This encryption key is encrypted using the armor key

+            -- (defined in Section 6.5.1), and the key usage for the

+            -- encryption is KEY_USAGE_FAST_BINDING_KEY.

+            -- Present only once in a converstation.

+         cookie          [2] OCTET STRING OPTIONAL,

+            -- Opaque data, for use to associate all the messages in

+            -- a single conversation between the client and the KDC.

+            -- This is generated by the KDC and the client MUST copy

+            -- the exact cookie encapsulated in a PA_FX_COOKIE data

+            -- element into the next message of the same conversation.

+         ...

+     }

+

+     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM

+

+     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {

+         pa-type      [0] Int32,

+             -- same as padata-type.

+         pa-hint      [1] OCTET STRING OPTIONAL,

+         pa-value  [2] OCTET STRING OPTIONAL,

+         ...

+     }

+

+     KrbFastArmor ::= SEQUENCE {

+         armor-type   [0] Int32,

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 36]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+             -- Type of the armor.

+         armor-value  [1] OCTET STRING,

+             -- Value of the armor.

+         ...

+     }

+

+     PA-FX-FAST-REQUEST ::= CHOICE {

+         armored-data [0] KrbFastArmoredReq,

+         ...

+     }

+

+     KrbFastArmoredReq ::= SEQUENCE {

+         armor        [0] KrbFastArmor OPTIONAL,

+             -- Contains the armor that identifies the armor key.

+             -- MUST be present in AS-REQ.

+             -- MUST be absent in TGS-REQ.

+         req-checksum [1] Checksum,

+             -- Checksum performed over the type KDC-REQ-BODY for

+             -- the req-body field of the KDC-REQ structure defined in

+             -- [RFC4120]

+             -- The checksum key is the armor key, the checksum

+             -- type is the required checksum type for the enctype of

+             -- the armor key, and the key usage number is

+             -- KEY_USAGE_FAST_REA_CHKSUM.

+         enc-fast-req [2] EncryptedData, -- KrbFastReq --

+             -- The encryption key is the armor key, and the key usage

+             -- number is KEY_USAGE_FAST_ENC.

+         ...

+     }

+

+     KrbFastReq ::= SEQUENCE {

+         fast-options [0] FastOptions,

+             -- Additional options.

+         padata       [1] SEQUENCE OF PA-DATA,

+             -- padata typed holes.

+         req-body     [2] KDC-REQ-BODY,

+             -- Contains the KDC request body as defined in Section

+             -- 5.4.1 of [RFC4120].

+             -- This req-body field is preferred over the outer field

+             -- in the KDC request.

+          ...

+     }

+

+     FastOptions ::= KerberosFlags

+         -- reserved(0),

+         -- anonymous(1),

+         -- kdc-referrals(16)

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 37]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+     PA-FX-FAST-REPLY ::= CHOICE {

+         armored-data [0] KrbFastArmoredRep,

+         ...

+     }

+

+     KrbFastArmoredRep ::= SEQUENCE {

+         enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --

+             -- The encryption key is the armor key in the request, and

+             -- the key usage number is KEY_USAGE_FAST_REP.

+         ...

+     }

+

+     KrbFastResponse ::= SEQUENCE {

+         padata      [0] SEQUENCE OF PA-DATA,

+             -- padata typed holes.

+         rep-key     [1] EncryptionKey OPTIONAL,

+             -- This, if present, replaces the reply key for AS and TGS.

+             -- MUST be absent in KRB-ERROR.

+         finished    [2] KrbFastFinished OPTIONAL,

+             -- MUST be present if the client is authenticated,

+             -- absent otherwise.

+             -- Typically this is present if and only if the containing

+             -- message is the last one in a conversation.

+         ...

+     }

+

+     KrbFastFinished ::= SEQUENCE {

+         timestamp   [0] KerberosTime,

+         usec        [1] Microseconds,

+             -- timestamp and usec represent the time on the KDC when

+             -- the reply was generated.

+         crealm      [2] Realm,

+         cname       [3] PrincipalName,

+             -- Contains the client realm and the client name.

+         checksum    [4] Checksum,

+             -- Checksum performed over all the messages in the

+             -- conversation, except the containing message.

+             -- The checksum key is the binding key as defined in

+             -- Section 6.3, and the checksum type is the required

+             -- checksum type of the binding key.

+         ...

+     }

+

+     EncryptedChallenge ::= EncryptedData

+             -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key

+             -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the

+             --  client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.

+     END

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 38]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+Authors' Addresses

+

+   Larry Zhu

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: lzhu@microsoft.com

+

+

+   Sam hartman

+   Painless Security

+

+   Email: hartmans-ietf@mit.edu

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 39]

+

+Internet-Draft         Kerberos Preauth Framework              July 2008

+

+

+Full Copyright Statement

+

+   Copyright (C) The IETF Trust (2008).

+

+   This document is subject to the rights, licenses and restrictions

+   contained in BCP 78, and except as set forth therein, the authors

+   retain all their rights.

+

+   This document and the information contained herein are provided on an

+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

+

+

+Intellectual Property

+

+   The IETF takes no position regarding the validity or scope of any

+   Intellectual Property Rights 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; nor does it represent that it has

+   made any independent effort to identify any such rights.  Information

+   on the procedures with respect to rights in RFC documents can be

+   found in BCP 78 and BCP 79.

+

+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at

+   http://www.ietf.org/ipr.

+

+   The IETF invites any interested party to bring to its attention any

+   copyrights, patents or patent applications, or other proprietary

+   rights that may cover technology that may be required to implement

+   this standard.  Please address the information to the IETF at

+   ietf-ipr@ietf.org.

+

+

+

+

+

+

+

+

+

+

+

+Zhu & Hartman           Expires January 15, 2009               [Page 40]

+

+

diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-09.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-09.txt
new file mode 100644
index 00000000000..9a4d76ad941
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-09.txt
@@ -0,0 +1,2521 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                         Painless Security
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: August 15, 2009                               February 11, 2009
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-09
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on August 15, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secrets of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Conventions and Terminology Used in This Document  . . . . . .  6
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
+     3.1.  Information Managed by the Pre-authentication Model  . . .  7
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 13
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 14
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 16
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 18
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 22
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 23
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 25
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 29
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 32
+       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 33
+       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 33
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 35
+   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 35
+     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 36
+     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 36
+     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 36
+     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 36
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
+     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 36
+     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 38
+     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 39
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 39
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 40
+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 41
+     A.1.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 41
+     A.2.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 42
+     A.3.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 42
+   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 42
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secrets or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver a reply
+   key within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password authenticated key exchange (PAKE) protocols with zero
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 6.5.  A pre-authentication type carried within
+   FAST is called a FAST factor.  Creating a FAST factor is the easiest
+   path to create a new pre-authentication mechanism.  FAST factors are
+   significantly easier to analyze from a security standpoint than other
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's KDCs in order to authenticate the
+   client principal.  A conversation as defined here consists of all
+   messages that are necessary to complete the authentication between
+   the client and the client's KDCs.
+
+   If the KDC reply in an Authentication Service (AS) exchange is
+   verified, the KDC is authenticated by the client.  In this document,
+   verification of the KDC reply is used as a synonym of authentication
+   of the KDC.
+
+   Lastly, this document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client principal's long-term key.  It should be
+   noted that in this document, verifying the KDC reply means
+   authenticating the KDC, and these phrases are used interchangeably.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client machine to authenticate the KDC.
+   Examples of this include signing the reply that can be verified using
+   a well-known public key or providing a ticket for the client machine
+   as a service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+
+
+Hartman & Zhu            Expires August 15, 2009                [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and pre-authentication is desirable.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to guess values
+   for the information it would normally receive from that error
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 6.3 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 3.3, the KDC MAY
+   ignore padata that is inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
+   KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets (as
+   defined in Section 6.4) MUST contain a sequence of inner mechanisms
+   along with hints for those mechanisms.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.
+
+   Mechanism designers MUST specify the values for the input parameter
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one round trip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless.  There is no requirement that clients
+   will choose the same KDC for the second request in a conversation.
+   Proxies or other intermediate nodes may also influence KDC selection.
+   So, each request from a client to a KDC must include sufficient
+   information that the KDC can regenerate any needed state.  This is
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   accomplished by giving the client a potentially long opaque cookie in
+   responses to include in future requests in the same conversation.
+   The KDC MAY respond that a conversation is too old and needs to
+   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            TBA
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management.  This padata is sent by the KDC when the KDC
+   requires state for a future transaction.  The client includes this
+   opaque token in the next message in the conversation.  The token may
+   be relatively large; clients MUST be prepared for tokens somewhat
+   larger than the size of all messages in a conversation.
+
+       PA-FX-COOKIE                       TBA
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However the KDC MUST construct the cookie
+   token in such a manner that a malicious client cannot subvert the
+   authentication process by manipulating the token.  The KDC
+   implementation needs to consider expiration of tokens, key rollover
+   and other security issues in token design.  The content of the cookie
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
+   identify the conversation with the client according to Section 3.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              TBA
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value  [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   message MUST contain a PA-AUTHENTICATION-SET-SELECTED padata element.
+   This element contains the encoding of the PA-AUTHENTICATION-SET
+   sequence received from the KDC corresponding to the authentication
+   set that is chosen.  The client MUST use the same octet values
+   received from the KDC; it cannot re-encode the sequence.  This allows
+   KDCs to use bit-wise comparison to identify the selected
+   authentication set.  The PA-AUTHENTICATION-SET-SELECTED padata
+   element MUST come before any padata elements from the authentication
+   set in the padata sequence in the AS-REQ message.  The client MAY
+   cache authentication sets from prior messages and use them to
+   construct an optimistic initial AS-REQ.  If the KDC receives a PA-
+   AUTHENTICATION-SET-SELECTED padata element that does not correspond
+   to an authentication set that it would offer, then the KDC returns
+   the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data in this
+   error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+         PA-AUTHENTICATION-SET-SELECTED         TBA
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers need to carefully consider the design
+   of their hints so that the client has this information.  This way,
+   clients can construct necessary dialogue boxes or wizards based on
+   the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC so that the
+   conversation can continue if the conversation involves multiple KDCs.
+   The cookie may not be needed in the first message containing the PA-
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   AUTHENTICATION-SET sequence as the KDC may be able to reconstruct the
+   state from the PA-AUTHENTICATION-SET-SELECTED padata.  KDCs MUST
+   support clients that do not include a cookie because they
+   optimistically choose an authentication set, although they MAY always
+   return KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in
+   that message.  Clients that support PA-AUTHENTICATION-SET MUST
+   support PA-FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a fast factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+                   "subkeyarmor", "ticketarmor" )
+
+   The `ticket_key' is the session key from the ticket in the ap-req.
+   The `subkey' is the ap-req subkey.  This construction guarantees that
+   both the KDC (through the session key) and the client (through the
+   subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key whose
+       binding with the expected KDC can be verified by the client, the
+       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
+       authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+   If anonymous PKINIT is used, The KDC cannot know whether its signing
+   key can be verified by the client, hence the KDC MUST be marked as
+   unverified from the KDC's point of view while the client could be
+   able to authenticate the KDC by verifying the KDC's signing key is
+   bound with the expected KDC.  The client needs to carefully consider
+   the risk and benefit tradeoffs associated with active attacks before
+   exposing cipher text encrypted using the user's long-term secrets
+   when the armor does not authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+   armor authorization data element.  These tickets and authenticators
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e. the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   As discussed previously, the server of an armor ticket MUST be the
+   TGS of the realm from whom service is requested.  As a result, if
+   this armor type is used when a ticket is being validated, proxied, or
+   in other cases where a ticket other than a TGT is presented to the
+   TGS, a TGT will be used as an armor ticket, while another ticket will
+   be used in the pa-tgs-req authenticator.
+
+6.5.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST with an empty pa-value in a PREAUTH_REQUIRED
+   error.  Clients MUST ignore the pa-value of PA-FX-FAST in an initial
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   PREAUTH_REQUIRED error.  FAST is not expected to be used in an
+   authentication set: clients will typically use FAST padata if
+   available and this decision should not depend on what other pre-
+   authentication methods are available.  As such, no pa-hint is defined
+   for FAST at this time.
+
+       PA-FX-FAST                         TBA
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- Checksum performed over the type KDC-REQ-BODY for
+               -- the req-body field of the KDC-REQ structure defined in
+               -- [RFC4120]
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          TBA
+       KEY_USAGE_FAST_ENC                 TBA
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD not include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
+      being presented to the TGS, a client SHOULD use some form of FAST
+      armor such as a ticket-based armor with a TGT as an armor ticket.
+      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
+      omit the armor field, in which case the armor key is the same that
+      would be computed if the authenticator were used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
+      ticket other than a TGT can be used to establish an armor key;
+      even though the armor key is computed the same as a
+      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
+      ticket in FX_FAST_ARMOR_AP_REQUEST.
+
+   The req-checksum field contains a checksum that is performed over the
+   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]
+   structure of the containing message.  The checksum key is the armor
+   key, and the checksum type is the required checksum type for the
+   enctype of the armor key per [RFC3961].  This checksum is included in
+   order to bind the FAST padata to the outer request.  A KDC that
+   implements FAST will ignore the outer request, but including a
+   checksum is relatively cheap and may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+            -- kdcfollow--referrals(16)
+
+
+     Bits    Name                    Description
+    -----------------------------------------------------------------
+     0     RESERVED              Reserved for future expansion of this
+                                 field.
+     1     hide-client-names     Requesting the KDC to hide client
+                                 names in the KDC response, as
+                                 described next in this section.
+     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [KRB-ANON] in the KDC reply and the error
+      response.  Hence this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] needs to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-follow-
+      referrals option is designed to minimize the number of messages
+      that need to be processed by the client.  This option is useful
+      when, for example, the client may contact the KDC via a satellite
+      link that has high network latency, or the client has limited
+      computational capabilities.  If the kdc-follow-referrals option is
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+      set, the KDC MAY act as the client to follow TGS referrals
+      [REFERRALS], and return the service ticket to the named server
+      principal in the client request using the reply key expected by
+      the client.  That is, rather than returning a referral, the KDC
+      follows that referral by contacting a remote KDC and processing
+      the referral.  The kdc-referrals option can be implemented when
+      the KDC knows the reply key.  The KDC can ignore kdc-referrals
+      option when it does not understand it or it does not allow this
+      option based on local policy.  The client SHOULD be capable of
+      processing the KDC responses when this option is not honored by
+      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
+      is going to be used to avoid problems when the client's UDP
+      retransmit algorithm has timeouts insufficient to allow the KDC to
+      interact with remote KDCs.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  However pre-
+   authentication data methods such as [RFC4556] that include a checksum
+   of the KDC-REQ-BODY should checksum the outer KDC-REQ-BODY.  These
+   methods will already be bound to the inner body through the integrity
+   protection in the FAST request.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 TBA
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+     KrbFastResponse ::= SEQUENCE {
+         padata      [0] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         rep-key     [1] EncryptionKey OPTIONAL,
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- MUST be absent in KRB-ERROR.
+         finished    [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata otherwise in the outer KDC reply into
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   this field.  The padata field in the KDC reply structure outside of
+   the PA-FX-FAST-REPLY structure typically includes only the PA-FX-
+   FAST-REPLY padata and optionally the PA-FX-COOKIE padata.
+
+   The rep-key field, if present, contains the reply key that is used to
+   encrypted the KDC reply.  The rep-key field MUST be absent in the
+   case where an error occurs.  The enctype of the rep-key is the
+   strongest mutually supported by the KDC and the client.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation; it MUST
+   be absent otherwise.  In other words, this field can only be present
+   in an AS-REP or a TGS-REP when a ticket is returned.
+
+   The KrbFastFinished structure contains the following information:
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp   [0] KerberosTime,
+          usec        [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm      [2] Realm,
+          cname       [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          checksum    [4] Checksum,
+              -- Checksum performed over all the messages in the
+              -- conversation, except the containing message.
+              -- The checksum key is the armor key as defined in
+              -- Section 6.5.1, and the checksum type is the required
+              -- checksum type of the armor key.
+          ticket-checksum [5] Checksum,
+              -- checksum  of the ticket in the KDC-REP  using the armor
+              -- and  the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+      KEY_USAGE_FAST_FINISHED            TBA
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   follow-referrals option is requested and honored by the KDC.  The
+   client need not confirm that the timestamp returned is within
+   allowable clock skew: the armor key guarantees that the reply is
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   fresh.  The client MAY trust the time stamp returned.
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The checksum field contains a checksum of all the messages in the
+   conversation prior to the containing message (the containing message
+   is excluded).  The checksum key is the armor key, and the checksum
+   type is the required checksum type of the enctype of that key, and
+   the key usage number is KEY_USAGE_FAST_FINISHED.  The ticket-checksum
+   is a checksum of the issued ticket using the same key and key usage.
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST also be included if the KDC expects at least one
+   more message from the client in order to complete the authentication.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        TBA
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The Kerberos client MAY process an error
+   message without a PA-FX-FAST-REPLY, if that is only intended to
+   return better error information to the application, typically for
+   trouble-shooting purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, then that
+   information should be transmitted in a pa-data element within the
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   KRBFastResponse structure.  The padata-type is the same as the data-
+   type would be in the typed data element and the padata-value is the
+   same as the data-value.  As discussed in Section 8, data-types and
+   padata-types are drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+6.5.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes two pa-data items: PA-FX-FAST and PA-FX-
+   COOKIE.  The client MAY include additional pa-data, but the KDC MUST
+   ignore the outer request body and any padata besides PA-FX-FAST and
+   PA-FX-COOKIE if PA-FX-FAST is processed.  In the case of the TGS
+   request, the outer request should include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST and
+   PA-FX-COOKIE should be included in PA-FX-FAST.  The client MUST
+   ignore other padata outside of PA-FX-FAST.
+
+6.5.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   client encrypts a structure containing a timestamp in the challenge
+   key.  The challenge key used by the client to send a message to the
+   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          TBA
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  TBA
+      KEY_USAGE_ENC_CHALLENGE_KDC     TBA
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the time stamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to re-use time stamps avoids requiring that clients maintain
+   state about which time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST replace the reply key before
+   issuing a ticket.  The client MUST check that the timestamp decrypts
+   properly.  The client MAY check that the timestamp is winthin the
+   window of acceptable clock skew for the client.  The client MUST NOT
+   require that the timestamp be identical to the timestamp in the
+   issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication and KDC authentication.  This FAST
+   factor also takes advantage of the FAST facility to replace the reply
+   key.  It does not provide the strengthening-reply-key facility.  The
+   security considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   authentication set.  No pa-hint is defined because the only
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         TBA
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 8 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+7.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                TBA
+           KDC_ERR_MORE_PREAUTH_DATA_NEEDED       TBA
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA
+           KDC_ERR_UNKNOWN_FAST_OPTIONS           TBA
+
+7.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM          TBA
+           KEY_USAGE_FAST_ENC                 TBA
+           KEY_USAGE_FAST_REP                 TBA
+           KEY_USAGE_FAST_FINISHED            TBA
+           KEY_USAGE_ENC_CHALLENGE_CLIENT     TBA
+           KEY_USAGE_ENC_CHALLENGE_KDC        TBA
+
+7.3.  Authorization Data Elements
+
+           AD-authentication-strength         TBA
+           AD-fx-fast-armor                   TBA
+
+7.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                       TBA
+           PA-AUTHENTICATION-SET              TBA
+           PA-AUTHENTICATION-SET-SELECTED     TBA
+           PA-FX-FAST                         TBA
+           PA-FX-ERROR                        TBA
+           PA-ENCRYPTED-CHALLENGE             TBA
+
+
+8.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   should all be located under
+   http://www.iana.org/assignments/kerberos-parameters.
+
+8.1.  Pre-authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registration
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   standards track RFCs.  A concern that a particular method needs to be
+   a standards track RFC may be raised as an objection during IETF
+   review.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+                              Type Value                       Reference
+   PA-TGS-REQ                 1    RFC 4120
+   PA-ENC-TIMESTAMP           2    RFC 4120
+   PA-PW-SALT                 3    RFC 4120
+   [reserved]                 4
+   PA-ENC-UNIX-TIME           5    (deprecated)
+   PA-SANDIA-SECUREID         6
+   PA-SESAME                  7
+   PA-OSF-DCE                 8
+   PA-CYBERSAFE-SECUREID      9
+   PA-AFS3-SALT               10
+   PA-ETYPE-INFO              11   RFC 4120
+   PA-SAM-CHALLENGE           12   (sam/otp)
+   PA-SAM-RESPONSE            13   (sam/otp)
+   PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
+   PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
+   PA-PK-AS-REQ               16   RFC 4556
+   PA-PK-AS-REP               17   RFC 4556
+   PA-ETYPE-INFO2             19   RFC 4120
+   PA-USE-SPECIFIED-KVNO      20
+   PA-SAM-REDIRECT            21   (sam/otp)
+   PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
+   TD-PADATA                  22   (embeds padata)
+   PA-SAM-ETYPE-INFO          23   (sam/otp)
+   PA-ALT-PRINC               24   (crawdad@fnal.gov)
+   PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
+   PA-SAM-RESPONSE2           31   (kenh@pobox.com)
+   PA-EXTRA-TGT               41   Reserved extra TGT
+   TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+   TD-KRB-PRINCIPAL           102  PrincipalName
+   TD-KRB-REALM               103  Realm
+   TD-TRUSTED-CERTIFIERS      104  from PKINIT
+   TD-CERTIFICATE-INDEX       105  from PKINIT
+   TD-APP-DEFINED-ERROR       106  application specific
+   TD-REQ-NONCE               107  INTEGER
+   TD-REQ-SEQ                 108  INTEGER
+   PA-PAC-REQUEST             128  MS-KILE
+
+
+8.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+8.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in  the KDC response
+      16    kdc-follow-referrals   Requesting the KDC to follow
+                                   referrals
+
+
+9.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   With regarding to the facilities provided by the Encrypted Challenge
+   FAST factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication and KDC-authentication.  There is no un-authenticated
+   clear text introduced by the Encrypted Challenge FAST factor.
+
+
+10.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+11.2.  Informative References
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 40]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+Appendix A.  Change History
+
+   RFC editor, please remove this section before publication.
+
+A.1.  Changes since 08
+
+      Fix a number of typos
+      Rename anonymous flag to hide-client-name; rename kdc-referals to
+      kdc-follow-referrals
+      Clarify how anonymous pkinit interacts with KDC verified.
+      Introduce AD-fx-fast-armor authorization data to deal with
+      unprivileged processes constructing KDC requests.  Note that a TGT
+      is always used for armor tickets if the armor field is present; if
+      you proxy or validate you'll end up with a TGT armor ticket and
+      another ticket in the pa-tgs-req.  Alternatively you can simply
+      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
+      All KDCs in a realm MUST support FAST if it is to be offered.
+      The cookie message is always generated by the KDC.
+      Note that the client can trust and need not verify the time stamp
+      in the finish message.  This can seed the client's idea of KDC
+      time.
+      Note that the client name in the finish message may differ from
+      the name in the request if referrals are used.
+      Note that KDCs should advertize fast in preauth_required errors.
+      Armor key is constructed using KRB-FX-CF2.  This is true even in
+      the TGS case; there is no security reason to do this.  Using the
+      subkey as done in draft 08 would be fine, but the current text
+      uses the same procedure both in the TGS and AS case.
+      Use a different challenge key in each direction in the encrypted
+      challenge option.
+      Note that the KDC should process PA-FX-COOKIE before other padata.
+      KRB-FX-CF2 uses k1's enctype for the result; change around calling
+      order so we pass in subkeys and armor keys as k1 in preference to
+      long-term keys or ticket session keys.
+      Clarify the relationship between authentication sets and cookies.
+      A cookie may not be needed in the first message.  Clarify how this
+      interacts with optimistic clients.
+      Remove text raising a concern that RFC 3961 may permit ciphertext
+      transformations that do not change plaintext: discussion on the
+      list came to the conclusion that RFC 3961 does not permit this.
+      Remove binding key concept; use the armor key instead.  The cookie
+      becomes just an octet string.
+      Include PA-FX-ERROR to protect the error information per Dublin.
+      Returning preauth_failed in the failed to decrypt encrypted
+      challenge seems fine; remove the issue marker
+      Add a section describing what goes in the inner and outer request.
+      I believe it is redundant but found it useful while putting
+      together an implementation proposal.
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 41]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+      Use hyphen rather than underscore in the constants for pre-
+      authentication data to be consistent with RFC 4120.
+      Add a ticket-checksum to the finished message
+      Remove redundant KEY_USAGE_FAST_ARMOR.
+      Add protocol constants section for non-IANA registrations and
+      flesh out IANA section.
+      Clarify that kdc-req-body checksums should always use the outer
+      body even for mechanisms like PKINIT that include their own (now
+      redundant) checksum.
+      Remove mechanism for encapsulating typed data in padata; just
+      reflect the value.
+
+A.2.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut and paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA-AUTHENTICATION-SET-SELECTED
+      Clarify a KDC cannot ignore padata is has claimed to support
+
+A.3.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonably unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix B.  ASN.1 module
+
+     KerberosPreauthFramework {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) preauth-framework(3)
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 42]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+     IMPORTS
+          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+          Microseconds, KerberosFlags
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) };
+                 -- as defined in RFC 4120.
+
+
+     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+         pa-type      [0] Int32,
+             -- same as padata-type.
+         pa-hint      [1] OCTET STRING OPTIONAL,
+         pa-value  [2] OCTET STRING OPTIONAL,
+         ...
+     }
+
+     KrbFastArmor ::= SEQUENCE {
+         armor-type   [0] Int32,
+             -- Type of the armor.
+         armor-value  [1] OCTET STRING,
+             -- Value of the armor.
+         ...
+     }
+
+     PA-FX-FAST-REQUEST ::= CHOICE {
+         armored-data [0] KrbFastArmoredReq,
+         ...
+     }
+
+     KrbFastArmoredReq ::= SEQUENCE {
+         armor        [0] KrbFastArmor OPTIONAL,
+             -- Contains the armor that identifies the armor key.
+             -- MUST be present in AS-REQ.
+         req-checksum [1] Checksum,
+             -- Checksum performed over the type KDC-REQ-BODY for
+             -- the req-body field of the KDC-REQ structure defined in
+             -- [RFC4120]
+             -- The checksum key is the armor key, the checksum
+             -- type is the required checksum type for the enctype of
+             -- the armor key, and the key usage number is
+             -- KEY_USAGE_FAST_REQ_CHKSUM.
+         enc-fast-req [2] EncryptedData, -- KrbFastReq --
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 43]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+             -- The encryption key is the armor key, and the key usage
+             -- number is KEY_USAGE_FAST_ENC.
+         ...
+     }
+
+     KrbFastReq ::= SEQUENCE {
+         fast-options [0] FastOptions,
+             -- Additional options.
+         padata       [1] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         req-body     [2] KDC-REQ-BODY,
+             -- Contains the KDC request body as defined in Section
+             -- 5.4.1 of [RFC4120].
+             -- This req-body field is preferred over the outer field
+             -- in the KDC request.
+          ...
+     }
+
+     FastOptions ::= KerberosFlags
+         -- reserved(0),
+         -- anonymous(1),
+         -- kdc-referrals(16)
+
+     PA-FX-FAST-REPLY ::= CHOICE {
+         armored-data [0] KrbFastArmoredRep,
+         ...
+     }
+
+     KrbFastArmoredRep ::= SEQUENCE {
+         enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+             -- The encryption key is the armor key in the request, and
+             -- the key usage number is KEY_USAGE_FAST_REP.
+         ...
+     }
+
+     KrbFastResponse ::= SEQUENCE {
+         padata      [0] SEQUENCE OF PA-DATA,
+             -- padata typed holes.
+         rep-key     [1] EncryptionKey OPTIONAL,
+             -- This, if present, replaces the reply key for AS and TGS.
+             -- MUST be absent in KRB-ERROR.
+         finished    [2] KrbFastFinished OPTIONAL,
+             -- MUST be present if the client is authenticated,
+             -- absent otherwise.
+             -- Typically this is present if and only if the containing
+             -- message is the last one in a conversation.
+         ...
+     }
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 44]
+
+Internet-Draft         Kerberos Preauth Framework          February 2009
+
+
+     KrbFastFinished ::= SEQUENCE {
+         timestamp   [0] KerberosTime,
+         usec        [1] Microseconds,
+             -- timestamp and usec represent the time on the KDC when
+             -- the reply was generated.
+         crealm      [2] Realm,
+         cname       [3] PrincipalName,
+             -- Contains the client realm and the client name.
+         checksum    [4] Checksum,
+             -- Checksum performed over all the messages in the
+             -- conversation, except the containing message.
+             -- The checksum key is the armor key as defined in
+             -- Section 6.5.1, and the checksum type is the required
+             -- checksum type of the armor key.
+         ticket-checksum [5] Checksum,
+             -- checksum  of the ticket in the KDC-REP  using the armor
+             -- and  the key usage is KEY_USAGE_FAST_FINISH.
+             -- The checksum type is the required checksum type
+             -- of the armor key.
+         ...
+     }
+
+     EncryptedChallenge ::= EncryptedData
+             -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+             -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+             -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+     END
+
+
+Authors' Addresses
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+Hartman & Zhu            Expires August 15, 2009               [Page 45]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-10.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-10.txt
new file mode 100644
index 00000000000..db244176b59
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-10.txt
@@ -0,0 +1,2633 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                         Painless Security
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: September 10, 2009                                March 9, 2009
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-10
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on September 10, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secrets of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Conventions and Terminology Used in This Document  . . . . . .  6
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
+     3.1.  Information Managed by the Pre-authentication Model  . . .  7
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
+       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
+       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
+   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 36
+     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
+     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
+     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
+     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 37
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
+     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 37
+     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 39
+     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 41
+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 42
+     A.1.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 42
+     A.2.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 42
+     A.3.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 43
+     A.4.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 43
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 44
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secrets or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver a reply
+   key within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password authenticated key exchange (PAKE) protocols with zero
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 6.5.  A pre-authentication type carried within
+   FAST is called a FAST factor.  Creating a FAST factor is the easiest
+   path to create a new pre-authentication mechanism.  FAST factors are
+   significantly easier to analyze from a security standpoint than other
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's Authentication Service (AS) in
+   order to authenticate the client principal.  A conversation as
+   defined here consists of all messages that are necessary to complete
+   the authentication between the client and the client's AS.  In the
+   Ticket Exchange Service (TGS) exchange, a conversation consists of
+   the request message and the reply message.  The term conversation is
+   defined here for both AS and TGS for convenience of discussion.  See
+   Section 6.3 for specific rules on the extent of a conversation in the
+   AS-REQ case.  Prior to this framework, implementations needed to use
+   implementation-specific heuristics to determine the extent of a
+   conversation.
+
+   If the KDC reply in an AS exchange is verified, the KDC is
+   authenticated by the client.  In this document, verification of the
+   KDC reply is used as a synonym of authentication of the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client principal's long-term key.  It should be
+   noted that in this document, verifying the KDC reply means
+   authenticating the KDC, and these phrases are used interchangeably.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client machine to authenticate the KDC.
+   Examples of this include signing the reply that can be verified using
+   a well-known public key or providing a ticket for the client machine
+   as a service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+
+
+
+Hartman & Zhu          Expires September 10, 2009               [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set or offered alone.  For each mechanism that is
+   offered alone, the KDC includes the pre-authentication type ID of the
+   mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and pre-authentication is desirable.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to guess values
+   for the information it would normally receive from that error
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 6.3 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 3.3, the KDC MAY
+   ignore padata that is inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
+   KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets (as
+   defined in Section 6.4) MUST contain a sequence of inner mechanisms
+   along with hints for those mechanisms.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one round trip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless.  There is no requirement that clients
+   will choose the same KDC for the second request in a conversation.
+   Proxies or other intermediate nodes may also influence KDC selection.
+   So, each request from a client to a KDC must include sufficient
+   information that the KDC can regenerate any needed state.  This is
+   accomplished by giving the client a potentially long opaque cookie in
+   responses to include in future requests in the same conversation.
+   The KDC MAY respond that a conversation is too old and needs to
+   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            90
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management in the AS exchange.  This padata is sent by the KDC
+   when the KDC requires state for a future transaction.  The client
+   includes this opaque token in the next message in the conversation.
+   The token may be relatively large; clients MUST be prepared for
+   tokens somewhat larger than the size of all messages in a
+   conversation.
+
+       PA-FX-COOKIE                       133
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However the KDC MUST construct the cookie
+   token in such a manner that a malicious client cannot subvert the
+   authentication process by manipulating the token.  The KDC
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   implementation needs to consider expiration of tokens, key rollover
+   and other security issues in token design.  The content of the cookie
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
+   identify the conversation with the client according to Section 3.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   91
+
+   A client MAY throw away the state associated with a conversation and
+   begin a new conversation by discarding its state and not including a
+   cooking in the first message of a conversation.  KDCs that comply
+   with this specification MUST include a cookie in a response when the
+   client can continue the conversation.  In particular, a KDC MUST
+   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED.  KDCs SHOULD include a cookie in
+   errors containing additional information allowing a client to retry.
+   One reasonable strategy for meeting these requirements is to always
+   include a cookie in KDC errors.
+
+   A KDC MAY indicate that it is terminating a conversation by not
+   including a cookie in a response.  When FAST is used, clients can
+   assume that the absence of a cookie means that the KDC is ending the
+   conversation.  Clients also need to deal with KDCs prior to this
+   specification that do not include cookies; if cookies nor FAST are
+   used in a conversation, the absence of a cookie is not a strong
+   indication that the KDC is terminating the conversation.
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              134
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value  [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.  The PA-
+   AUTH-SET-SELECTED padata element MUST come before any padata elements
+   from the authentication set in the padata sequence in the AS-REQ
+   message.  The client MAY cache authentication sets from prior
+   messages and use them to construct an optimistic initial AS-REQ.  If
+   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
+   correspond to an authentication set that it would offer, then the KDC
+   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
+   in this error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+         PA-AUTH-SET-SELECTED                   135
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers needs to carefully consider the
+   design of their hints so that the client has this information.  This
+   way, clients can construct necessary dialogue boxes or wizards based
+   on the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC so that the
+   conversation can continue if the conversation involves multiple KDCs.
+   The cookie may not be needed in the first message containing the PA-
+   AUTHENTICATION-SET sequence as the KDC may be able to reconstruct the
+   state from the PA-AUTHENTICATION-SET-SELECTED padata.  KDCs MUST
+   support clients that do not include a cookie because they
+   optimistically choose an authentication set, although they MAY always
+   return KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in
+   that message.  Clients that support PA-AUTHENTICATION-SET MUST
+   support PA-FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   support Kerberos FAST padata.
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a fast factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+                   "subkeyarmor", "ticketarmor" )
+
+   The `ticket_key' is the session key from the ticket in the ap-req.
+   The `subkey' is the ap-req subkey.  This construction guarantees that
+   both the KDC (through the session key) and the client (through the
+   subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key whose
+       binding with the expected KDC can be verified by the client, the
+       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
+       authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+   If anonymous PKINIT is used to obtain the armor ticket, the KDC
+   cannot know whether its signing key can be verified by the client,
+   hence the KDC MUST be marked as unverified from the KDC's point of
+   view while the client could be able to authenticate the KDC by
+   verifying the KDC's signing key is bound with the expected KDC.  The
+   client needs to carefully consider the risk and benefit tradeoffs
+   associated with active attacks before exposing cipher text encrypted
+   using the user's long-term secrets when the armor does not
+   authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   armor authorization data element.  These tickets and authenticators
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e. the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   As discussed previously, the server of an armor ticket MUST be the
+   TGS of the realm from whom service is requested.  As a result, if
+   this armor type is used when a ticket is being validated, proxied, or
+   in other cases where a ticket other than a TGT is presented to the
+   TGS, a TGT will be used as an armor ticket, while another ticket will
+   be used in the pa-tgs-req authenticator.
+
+6.5.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST with an empty pa-value in a PREAUTH_REQUIRED
+   error.  Clients MUST ignore the pa-value of PA-FX-FAST in an initial
+   PREAUTH_REQUIRED error.  FAST is not expected to be used in an
+   authentication set: clients will typically use FAST padata if
+   available and this decision should not depend on what other pre-
+   authentication methods are available.  As such, no pa-hint is defined
+   for FAST at this time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+       PA-FX-FAST                         136
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- For AS, contains the checksum performed over the type
+               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+               -- structure;
+               -- For TGS, contains the checksum performed over the type
+               -- AP-REQ in the PA-TGS-REQ padata.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          50
+       KEY_USAGE_FAST_ENC                 51
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD not include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
+      being presented to the TGS, a client SHOULD use some form of FAST
+      armor such as a ticket-based armor with a TGT as an armor ticket.
+      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
+      omit the armor field, in which case the armor key is the same that
+      would be computed if the authenticator were used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
+      ticket other than a TGT can be used to establish an armor key;
+      even though the armor key is computed the same as a
+      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
+      ticket in FX_FAST_ARMOR_AP_REQUEST.
+
+   The req-checksum field contains a checksum computed differently for
+   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
+   BODY for the req-body field of the KDC-REQ structure of the
+   containing message; for an TGS-REQ, it is performed over the type AP-
+   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
+   the armor key, and the checksum type is the required checksum type
+   for the enctype of the armor key per [RFC3961].  This checksum is
+   included in order to bind the FAST padata to the outer request.  A
+   KDC that implements FAST will ignore the outer request, but including
+   a checksum is relatively cheap and may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+            -- kdcfollow--referrals(16)
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+     Bits    Name                    Description
+    -----------------------------------------------------------------
+     0     RESERVED              Reserved for future expansion of this
+                                 field.
+     1     hide-client-names     Requesting the KDC to hide client
+                                 names in the KDC response, as
+                                 described next in this section.
+     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS       93
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [KRB-ANON] in the KDC reply and the error
+      response.  Hence this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] needs to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-follow-
+      referrals option is designed to minimize the number of messages
+      that need to be processed by the client.  This option is useful
+      when, for example, the client may contact the KDC via a satellite
+      link that has high network latency, or the client has limited
+      computational capabilities.  If the kdc-follow-referrals option is
+      set, the KDC MAY act as the client to follow TGS referrals
+      [REFERRALS], and return the service ticket to the named server
+      principal in the client request using the reply key expected by
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+      the client.  That is, rather than returning a referral, the KDC
+      follows that referral by contacting a remote KDC and processing
+      the referral.  The kdc-referrals option can be implemented when
+      the KDC knows the reply key.  The KDC can ignore kdc-referrals
+      option when it does not understand it or it does not allow this
+      option based on local policy.  The client SHOULD be capable of
+      processing the KDC responses when this option is not honored by
+      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
+      is going to be used to avoid problems when the client's UDP
+      retransmit algorithm has timeouts insufficient to allow the KDC to
+      interact with remote KDCs.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.  If the KDC
+   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+   the client MUST place any padata that is otherwise in the outer KDC
+   request body into this field.  In a TGS request, PA-TGS-REQ padata is
+   not included in this field and it is present in the outer KDC request
+   body.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  However pre-
+   authentication data methods such as [RFC4556] that include a checksum
+   of the KDC-REQ-BODY should checksum the outer KDC-REQ-BODY.  These
+   methods will already be bound to the inner body through the integrity
+   protection in the FAST request.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 52
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+        KrbFastResponse ::= SEQUENCE {
+            padata      [0] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            rep-key     [1] EncryptionKey OPTIONAL,
+                -- This, if present, replaces the reply key for AS and
+                -- TGS.
+                -- MUST be absent in KRB-ERROR.
+            finished    [2] KrbFastFinished OPTIONAL,
+                -- Present in AS or TGS reply; absent otherwise.
+            ...
+        }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata that is otherwise in the outer KDC-
+   REP structure into this field.  The padata field in the KDC reply
+   structure outside of the PA-FX-FAST-REPLY structure typically
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   includes only the PA-FX- FAST-REPLY padata and optionally the PA-FX-
+   COOKIE padata.
+
+   The rep-key field, if present, contains the reply key that is used to
+   encrypted the KDC reply.  The rep-key field MUST be absent in the
+   case where an error occurs.  The enctype of the rep-key is the
+   strongest mutually supported by the KDC and the client.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation.  This
+   field is present in an AS-REP or a TGS-REP when a ticket is returned,
+   and it is not present in an error reply.
+
+   The KrbFastFinished structure contains the following information:
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp   [0] KerberosTime,
+          usec        [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm      [2] Realm,
+          cname       [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          checksum    [4] Checksum,
+              -- Checksum performed over all the messages in the
+              -- conversation, except the containing message.
+              -- The checksum key is the armor key as defined in
+              -- Section 6.5.1, and the checksum type is the required
+              -- checksum type of the armor key.
+          ticket-checksum [5] Checksum,
+              -- checksum  of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+      KEY_USAGE_FAST_FINISHED            53
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   follow-referrals option is requested and honored by the KDC.  The
+   client need not confirm that the timestamp returned is within
+   allowable clock skew: the armor key guarantees that the reply is
+   fresh.  The client MAY trust the time stamp returned.
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The checksum field contains a checksum of all the messages in the
+   conversation prior to the containing message (the containing message
+   is excluded).  The checksum key is the armor key, and the checksum
+   type is the required checksum type of the enctype of that key, and
+   the key usage number is KEY_USAGE_FAST_FINISHED.  The ticket-checksum
+   is a checksum of the issued ticket using the same key and key usage.
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST also be included if the KDC expects at least one
+   more message from the client in order to complete the authentication.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        137
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The Kerberos client MAY process an error
+   message without a PA-FX-FAST-REPLY, if that is only intended to
+   return better error information to the application, typically for
+   trouble-shooting purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, then that
+   information should be transmitted in a pa-data element within the
+   KRBFastResponse structure.  The padata-type is the same as the data-
+   type would be in the typed data element and the padata-value is the
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   same as the data-value.  As discussed in Section 8, data-types and
+   padata-types are drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+6.5.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes two pa-data items: PA-FX-FAST and PA-FX-
+   COOKIE.  The client MAY include additional pa-data, but the KDC MUST
+   ignore the outer request body and any padata besides PA-FX-FAST and
+   PA-FX-COOKIE if PA-FX-FAST is processed.  In the case of the TGS
+   request, the outer request should include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST and
+   PA-FX-COOKIE should be included in PA-FX-FAST.  The client MUST
+   ignore other padata outside of PA-FX-FAST.
+
+6.5.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   client encrypts a structure containing a timestamp in the challenge
+   key.  The challenge key used by the client to send a message to the
+   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          138
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
+      KEY_USAGE_ENC_CHALLENGE_KDC     55
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the time stamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to re-use time stamps avoids requiring that clients maintain
+   state about which time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST replace the reply key before
+   issuing a ticket.  The client MUST check that the timestamp decrypts
+   properly.  The client MAY check that the timestamp is winthin the
+   window of acceptable clock skew for the client.  The client MUST NOT
+   require that the timestamp be identical to the timestamp in the
+   issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication and KDC authentication.  This FAST
+   factor also takes advantage of the FAST facility to replace the reply
+   key.  It does not provide the strengthening-reply-key facility.  The
+   security considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+   authentication set.  No pa-hint is defined because the only
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         70
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 8 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+7.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                 90
+           KDC_ERR_MORE_PREAUTH_DATA_NEEDED        91
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
+           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS            93
+
+7.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM               50
+           KEY_USAGE_FAST_ENC                      51
+           KEY_USAGE_FAST_REP                      52
+           KEY_USAGE_FAST_FINISHED                 53
+           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
+           KEY_USAGE_ENC_CHALLENGE_KDC             55
+
+7.3.  Authorization Data Elements
+
+           AD-authentication-strength              70
+           AD-fx-fast-armor                        71
+
+7.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                            133
+           PA-AUTHENTICATION-SET                   134
+           PA-AUTH-SET-SELECTED                    135
+           PA-FX-FAST                              136
+           PA-FX-ERROR                             137
+           PA-ENCRYPTED-CHALLENGE                  138
+
+
+8.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   should all be located under
+   http://www.iana.org/assignments/kerberos-parameters.
+
+8.1.  Pre-authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registration
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   standards track RFCs.  A concern that a particular method needs to be
+   a standards track RFC may be raised as an objection during IETF
+   review.
+
+      Type                Value    Reference
+  ----------------------------------------------------------------------
+  PA-TGS-REQ                 1    RFC 4120
+  PA-ENC-TIMESTAMP           2    RFC 4120
+  PA-PW-SALT                 3    RFC 4120
+  [reserved]                 4
+  PA-ENC-UNIX-TIME           5    (deprecated)
+  PA-SANDIA-SECUREID         6
+  PA-SESAME                  7
+  PA-OSF-DCE                 8
+  PA-CYBERSAFE-SECUREID      9
+  PA-AFS3-SALT               10
+  PA-ETYPE-INFO              11   RFC 4120
+  PA-SAM-CHALLENGE           12   (sam/otp)
+  PA-SAM-RESPONSE            13   (sam/otp)
+  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+  PA-PK-AS-REQ               16   RFC 4556
+  PA-PK-AS-REP               17   RFC 4556
+  PA-ETYPE-INFO2             19   RFC 4120
+  PA-USE-SPECIFIED-KVNO      20
+  PA-SAM-REDIRECT            21   (sam/otp)
+  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
+  TD-PADATA                  22   (embeds padata)
+  PA-SAM-ETYPE-INFO          23   (sam/otp)
+  PA-ALT-PRINC               24   (crawdad@fnal.gov)
+  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
+  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
+  PA-EXTRA-TGT               41   Reserved extra TGT
+  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+  TD-KRB-PRINCIPAL           102  PrincipalName
+  TD-KRB-REALM               103  Realm
+  TD-TRUSTED-CERTIFIERS      104  PKINIT
+  TD-CERTIFICATE-INDEX       105  PKINIT
+  TD-APP-DEFINED-ERROR       106  Application specific
+  TD-REQ-NONCE               107  INTEGER
+  TD-REQ-SEQ                 108  INTEGER
+  PA-PAC-REQUEST             128  MS-KILE
+  PA-FOR_USER                129  MS-KILE
+  PA-FOR-X509-USER           130  MS-KILE
+  PA-FOR-CHECK_DUPS          131  MS-KILE
+  PA-AS-CHECKSUM             132  MS-KILE
+  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
+  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
+  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
+  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
+  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
+  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
+  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
+  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
+  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
+  PA-SUPPORTED-ETYPES        165  MS-KILE
+
+8.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+8.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in  the KDC response
+      16    kdc-follow-referrals   Requesting the KDC to follow
+                                   referrals
+
+
+9.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   With regarding to the facilities provided by the Encrypted Challenge
+   FAST factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication and KDC-authentication.  There is no un-authenticated
+   clear text introduced by the Encrypted Challenge FAST factor.
+
+
+10.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 40]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+11.2.  Informative References
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 41]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+Appendix A.  Change History
+
+   RFC editor, please remove this section before publication.
+
+A.1.  Changes since 09
+
+      Clarify conversations by defining for TGS and by describing how
+      cookies form conversation boundaries.
+      Simplify text surrounding when finish is included: always for AS
+      and TGS reply, never for error.
+      Fill in IANA and constants
+
+A.2.  Changes since 08
+
+      Fix a number of typos
+      Rename anonymous flag to hide-client-name; rename kdc-referals to
+      kdc-follow-referrals
+      Clarify how anonymous pkinit interacts with KDC verified.
+      Introduce AD-fx-fast-armor authorization data to deal with
+      unprivileged processes constructing KDC requests.  Note that a TGT
+      is always used for armor tickets if the armor field is present; if
+      you proxy or validate you'll end up with a TGT armor ticket and
+      another ticket in the pa-tgs-req.  Alternatively you can simply
+      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
+      All KDCs in a realm MUST support FAST if it is to be offered.
+      The cookie message is always generated by the KDC.
+      Note that the client can trust and need not verify the time stamp
+      in the finish message.  This can seed the client's idea of KDC
+      time.
+      Note that the client name in the finish message may differ from
+      the name in the request if referrals are used.
+      Note that KDCs should advertize fast in preauth_required errors.
+      Armor key is constructed using KRB-FX-CF2.  This is true even in
+      the TGS case; there is no security reason to do this.  Using the
+      subkey as done in draft 08 would be fine, but the current text
+      uses the same procedure both in the TGS and AS case.
+      Use a different challenge key in each direction in the encrypted
+      challenge option.
+      Note that the KDC should process PA-FX-COOKIE before other padata.
+      KRB-FX-CF2 uses k1's enctype for the result; change around calling
+      order so we pass in subkeys and armor keys as k1 in preference to
+      long-term keys or ticket session keys.
+      Clarify the relationship between authentication sets and cookies.
+      A cookie may not be needed in the first message.  Clarify how this
+      interacts with optimistic clients.
+      Remove text raising a concern that RFC 3961 may permit ciphertext
+      transformations that do not change plaintext: discussion on the
+      list came to the conclusion that RFC 3961 does not permit this.
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 42]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+      Remove binding key concept; use the armor key instead.  The cookie
+      becomes just an octet string.
+      Include PA-FX-ERROR to protect the error information per Dublin.
+      Returning preauth_failed in the failed to decrypt encrypted
+      challenge seems fine; remove the issue marker
+      Add a section describing what goes in the inner and outer request.
+      I believe it is redundant but found it useful while putting
+      together an implementation proposal.
+      Use hyphen rather than underscore in the constants for pre-
+      authentication data to be consistent with RFC 4120.
+      Add a ticket-checksum to the finished message
+      Remove redundant KEY_USAGE_FAST_ARMOR.
+      Add protocol constants section for non-IANA registrations and
+      flesh out IANA section.
+      Clarify that kdc-req-body checksums should always use the outer
+      body even for mechanisms like PKINIT that include their own (now
+      redundant) checksum.
+      Remove mechanism for encapsulating typed data in padata; just
+      reflect the value.
+
+A.3.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut and paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA-AUTH-SET-SELECTED
+      Clarify a KDC cannot ignore padata is has claimed to support
+
+A.4.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonably unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 43]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix B.  ASN.1 module
+
+      KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+           Microseconds, KerberosFlags
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+                  -- as defined in RFC 4120.
+
+
+      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+          pa-type      [0] Int32,
+              -- same as padata-type.
+          pa-hint      [1] OCTET STRING OPTIONAL,
+          pa-value  [2] OCTET STRING OPTIONAL,
+          ...
+      }
+
+      KrbFastArmor ::= SEQUENCE {
+          armor-type   [0] Int32,
+              -- Type of the armor.
+          armor-value  [1] OCTET STRING,
+              -- Value of the armor.
+          ...
+      }
+
+      PA-FX-FAST-REQUEST ::= CHOICE {
+          armored-data [0] KrbFastArmoredReq,
+          ...
+      }
+
+      KrbFastArmoredReq ::= SEQUENCE {
+          armor        [0] KrbFastArmor OPTIONAL,
+              -- Contains the armor that identifies the armor key.
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 44]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+              -- MUST be present in AS-REQ.
+          req-checksum [1] Checksum,
+              -- For AS, contains the checksum performed over the type
+              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+              -- structure;
+              -- For TGS, contains the checksum performed over the type
+              -- AP-REQ in the PA-TGS-REQ padata.
+              -- The checksum key is the armor key, the checksum
+              -- type is the required checksum type for the enctype of
+              -- the armor key, and the key usage number is
+              -- KEY_USAGE_FAST_REQ_CHKSUM.
+          enc-fast-req [2] EncryptedData, -- KrbFastReq --
+              -- The encryption key is the armor key, and the key usage
+              -- number is KEY_USAGE_FAST_ENC.
+          ...
+      }
+
+      KrbFastReq ::= SEQUENCE {
+          fast-options [0] FastOptions,
+              -- Additional options.
+          padata       [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          req-body     [2] KDC-REQ-BODY,
+              -- Contains the KDC request body as defined in Section
+              -- 5.4.1 of [RFC4120].
+              -- This req-body field is preferred over the outer field
+              -- in the KDC request.
+           ...
+      }
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- anonymous(1),
+          -- kdc-referrals(16)
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+
+      KrbFastResponse ::= SEQUENCE {
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 45]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+          padata      [0] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          rep-key     [1] EncryptionKey OPTIONAL,
+              -- This, if present, replaces the reply key for AS and
+              -- TGS.
+              -- MUST be absent in KRB-ERROR.
+          finished    [2] KrbFastFinished OPTIONAL,
+              -- Present in AS or TGS reply; absent otherwise.
+          ...
+      }
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp   [0] KerberosTime,
+          usec        [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm      [2] Realm,
+          cname       [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          checksum    [4] Checksum,
+              -- Checksum performed over all the messages in the
+              -- conversation, except the containing message.
+              -- The checksum key is the armor key as defined in
+              -- Section 6.5.1, and the checksum type is the required
+              -- checksum type of the armor key.
+          ticket-checksum [5] Checksum,
+              -- checksum  of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+      END
+
+
+Authors' Addresses
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 46]
+
+Internet-Draft         Kerberos Preauth Framework             March 2009
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu          Expires September 10, 2009              [Page 47]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-11.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-11.txt
new file mode 100644
index 00000000000..e314f231c27
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-11.txt
@@ -0,0 +1,2689 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                         Painless Security
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: November 21, 2009                                  May 20, 2009
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-11
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on November 21, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secrets of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Conventions and Terminology Used in This Document  . . . . . .  6
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
+     3.1.  Information Managed by the Pre-authentication Model  . . .  7
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
+       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
+       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
+   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
+     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
+     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
+     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
+     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 37
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
+     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
+     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
+     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 42
+   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 42
+   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 43
+     B.1.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 43
+     B.2.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 43
+     B.3.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 43
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+     B.4.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 45
+     B.5.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 45
+   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 45
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secrets or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver a reply
+   key within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password authenticated key exchange (PAKE) protocols with zero
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 6.5.  A pre-authentication type carried within
+   FAST is called a FAST factor.  Creating a FAST factor is the easiest
+   path to create a new pre-authentication mechanism.  FAST factors are
+   significantly easier to analyze from a security standpoint than other
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's Authentication Service (AS) in
+   order to authenticate the client principal.  A conversation as
+   defined here consists of all messages that are necessary to complete
+   the authentication between the client and the client's AS.  In the
+   Ticket Exchange Service (TGS) exchange, a conversation consists of
+   the request message and the reply message.  The term conversation is
+   defined here for both AS and TGS for convenience of discussion.  See
+   Section 6.3 for specific rules on the extent of a conversation in the
+   AS-REQ case.  Prior to this framework, implementations needed to use
+   implementation-specific heuristics to determine the extent of a
+   conversation.
+
+   If the KDC reply in an AS exchange is verified, the KDC is
+   authenticated by the client.  In this document, verification of the
+   KDC reply is used as a synonym of authentication of the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client principal's long-term key.  It should be
+   noted that in this document, verifying the KDC reply means
+   authenticating the KDC, and these phrases are used interchangeably.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client machine to authenticate the KDC.
+   Examples of this include signing the reply that can be verified using
+   a well-known public key or providing a ticket for the client machine
+   as a service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+
+
+
+Hartman & Zhu           Expires November 21, 2009               [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set, offered alone, or both.  For each mechanism
+   that is offered alone (even if it is also offered in an
+   authentication set), the KDC includes the pre-authentication type ID
+   of the mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
+   part of an authentication set are not directly represented in the
+   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
+   although they are represented in the PA-AUTHENTICATION-SET sequence.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and pre-authentication is desirable.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to guess values
+   for the information it would normally receive from that error
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 6.3 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 3.3, the KDC MAY
+   ignore padata that is inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
+   KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets (as
+   defined in Section 6.4) MUST contain a sequence of inner mechanisms
+   along with hints for those mechanisms.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one round trip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless in that there is no requirement that
+   clients will choose the same KDC for the second request in a
+   conversation.  Proxies or other intermediate nodes may also influence
+   KDC selection.  So, each request from a client to a KDC must include
+   sufficient information that the KDC can regenerate any needed state.
+   This is accomplished by giving the client a potentially long opaque
+   cookie in responses to include in future requests in the same
+   conversation.  The KDC MAY respond that a conversation is too old and
+   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            90
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management in the AS exchange.  This padata is sent by the KDC
+   when the KDC requires state for a future transaction.  The client
+   includes this opaque token in the next message in the conversation.
+   The token may be relatively large; clients MUST be prepared for
+   tokens somewhat larger than the size of all messages in a
+   conversation.
+
+       PA-FX-COOKIE                       133
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However the KDC MUST construct the cookie
+   token in such a manner that a malicious client cannot subvert the
+   authentication process by manipulating the token.  The KDC
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   implementation needs to consider expiration of tokens, key rollover
+   and other security issues in token design.  The content of the cookie
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
+   identify the conversation with the client according to Section 3.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   91
+
+   A client MAY throw away the state associated with a conversation and
+   begin a new conversation by discarding its state and not including a
+   cooking in the first message of a conversation.  KDCs that comply
+   with this specification MUST include a cookie in a response when the
+   client can continue the conversation.  In particular, a KDC MUST
+   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED.  KDCs SHOULD include a cookie in
+   errors containing additional information allowing a client to retry.
+   One reasonable strategy for meeting these requirements is to always
+   include a cookie in KDC errors.
+
+   A KDC MAY indicate that it is terminating a conversation by not
+   including a cookie in a response.  When FAST is used, clients can
+   assume that the absence of a cookie means that the KDC is ending the
+   conversation.  Clients also need to deal with KDCs prior to this
+   specification that do not include cookies; if cookies nor FAST are
+   used in a conversation, the absence of a cookie is not a strong
+   indication that the KDC is terminating the conversation.
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              134
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value     [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.  The PA-
+   AUTH-SET-SELECTED padata element MUST come before any padata elements
+   from the authentication set in the padata sequence in the AS-REQ
+   message.  The client MAY cache authentication sets from prior
+   messages and use them to construct an optimistic initial AS-REQ.  If
+   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
+   correspond to an authentication set that it would offer, then the KDC
+   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
+   in this error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+         PA-AUTH-SET-SELECTED                   135
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers needs to carefully consider the
+   design of their hints so that the client has this information.  This
+   way, clients can construct necessary dialogue boxes or wizards based
+   on the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
+   requirement is so that the conversation can continue if the
+   conversation involves multiple KDCs.  KDCs MUST support clients that
+   do not include a cookie because they optimistically choose an
+   authentication set, although they MAY always return
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
+   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
+   FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a fast factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+                   "subkeyarmor", "ticketarmor" )
+
+   The `ticket_session_key' is the session key from the ticket in the
+   ap-req.  The `subkey' is the ap-req subkey.  This construction
+   guarantees that both the KDC (through the session key) and the client
+   (through the subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key whose
+       binding with the expected KDC can be verified by the client, the
+       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
+       authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+   If anonymous PKINIT is used to obtain the armor ticket, the KDC
+   cannot know whether its signing key can be verified by the client,
+   hence the KDC MUST be marked as unverified from the KDC's point of
+   view while the client could be able to authenticate the KDC by
+   verifying the KDC's signing key is bound with the expected KDC.  The
+   client needs to carefully consider the risk and benefit tradeoffs
+   associated with active attacks before exposing cipher text encrypted
+   using the user's long-term secrets when the armor does not
+   authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+   armor authorization data element.  These tickets and authenticators
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e. the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   As discussed previously, the server of an armor ticket MUST be the
+   TGS of the realm from whom service is requested.  As a result, if
+   this armor type is used when a ticket is being validated, proxied, or
+   in other cases where a ticket other than a TGT is presented to the
+   TGS, a TGT will be used as an armor ticket, while another ticket will
+   be used in the pa-tgs-req authenticator.
+
+6.5.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
+   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
+   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
+   error.  FAST is not expected to be used in an authentication set:
+   clients will typically use FAST padata if available and this decision
+   should not depend on what other pre-authentication methods are
+   available.  As such, no pa-hint is defined for FAST at this time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+       PA-FX-FAST                         136
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- For AS, contains the checksum performed over the type
+               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+               -- structure;
+               -- For TGS, contains the checksum performed over the type
+               -- AP-REQ in the PA-TGS-REQ padata.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          50
+       KEY_USAGE_FAST_ENC                 51
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD not include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
+      being presented to the TGS, a client SHOULD use some form of FAST
+      armor such as a ticket-based armor with a TGT as an armor ticket.
+      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
+      omit the armor field, in which case the armor key is the same that
+      would be computed if the authenticator were used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
+      ticket other than a TGT can be used to establish an armor key;
+      even though the armor key is computed the same as a
+      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
+      ticket in FX_FAST_ARMOR_AP_REQUEST.
+
+   The req-checksum field contains a checksum computed differently for
+   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
+   BODY for the req-body field of the KDC-REQ structure of the
+   containing message; for an TGS-REQ, it is performed over the type AP-
+   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
+   the armor key, and the checksum type is the required checksum type
+   for the enctype of the armor key per [RFC3961].  This checksum MUST
+   be a keyed checksume and it is included in order to bind the FAST
+   padata to the outer request.  A KDC that implements FAST will ignore
+   the outer request, but including a checksum is relatively cheap and
+   may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+            -- kdc-follow-referrals(16)
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+     Bits    Name                    Description
+    -----------------------------------------------------------------
+     0     RESERVED              Reserved for future expansion of this
+                                 field.
+     1     hide-client-names     Requesting the KDC to hide client
+                                 names in the KDC response, as
+                                 described next in this section.
+     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [KRB-ANON] in the KDC reply and the error
+      response.  Hence this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] needs to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-follow-
+      referrals option is designed to minimize the number of messages
+      that need to be processed by the client.  This option is useful
+      when, for example, the client may contact the KDC via a satellite
+      link that has high network latency, or the client has limited
+      computational capabilities.  If the kdc-follow-referrals option is
+      set, the KDC MAY act as the client to follow TGS referrals
+      [REFERRALS], and return the service ticket to the named server
+      principal in the client request using the reply key expected by
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+      the client.  That is, rather than returning a referral, the KDC
+      follows that referral by contacting a remote KDC and processing
+      the referral.  The kdc-referrals option can be implemented when
+      the KDC knows the reply key.  The KDC can ignore kdc-referrals
+      option when it does not understand it or it does not allow this
+      option based on local policy.  The client SHOULD be capable of
+      processing the KDC responses when this option is not honored by
+      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
+      is going to be used to avoid problems when the client's UDP
+      retransmit algorithm has timeouts insufficient to allow the KDC to
+      interact with remote KDCs.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.  If the KDC
+   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+   the client MUST place any padata that is otherwise in the outer KDC
+   request body into this field.  In a TGS request, PA-TGS-REQ padata is
+   not included in this field and it is present in the outer KDC request
+   body.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  However pre-
+   authentication data methods such as [RFC4556] that include a checksum
+   of the KDC-REQ-BODY should checksum the outer KDC-REQ-BODY.  These
+   methods will already be bound to the inner body through the integrity
+   protection in the FAST request.
+
+   In a TGS request, a client MAY include the AD-fx-fast-used authdata
+   either in the pa-tgs-req authenticator or in the authorization data
+   in the pa-tgs-req ticket.  If the KDC receives this authorization
+   data but does not find a FAST padata then it MUST return
+   KRB_APP_ERR_MODIFIED.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   FAST-REPLY.
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 52
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+       KrbFastResponse ::= SEQUENCE {
+           padata         [0] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           strengthen-key [1] EncryptionKey OPTIONAL,
+               -- This, if present, strengthens the reply key for AS and
+               -- TGS.
+               -- MUST be absent in KRB-ERROR.
+           finished       [2] KrbFastFinished OPTIONAL,
+               -- Present in AS or TGS reply; absent otherwise.
+           nonce          [3] UInt32,
+               -- Nonce from the client request.
+           ...
+  }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata that is otherwise in the outer KDC-
+   REP structure into this field.  The padata field in the KDC reply
+   structure outside of the PA-FX-FAST-REPLY structure typically
+   includes only the PA-FX- FAST-REPLY padata.
+
+   The strengthen-key field provides a mechanism for the KDC to
+   strengthen the reply key.  If set, the reply key is strengthened
+   after all padata items are processed.  Let padata-reply-key be the
+   reply key after padata processing.
+
+   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
+                         "strengthenkey", "replykey")
+
+   The strengthen-key field MAY be set in an AS or TGS reply; it must be
+   absent in an error reply.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation.  This
+   field is present in an AS-REP or a TGS-REP when a ticket is returned,
+   and it is not present in an error reply.
+
+   The KrbFastFinished structure contains the following information:
+
+       KrbFastFinished ::= SEQUENCE {
+           timestamp       [0] KerberosTime,
+           usec            [1] Microseconds,
+               -- timestamp and usec represent the time on the KDC when
+               -- the reply was generated.
+           crealm          [2] Realm,
+           cname           [3] PrincipalName,
+               -- Contains the client realm and the client name.
+           ticket-checksum [4] Checksum,
+               -- checksum of the ticket in the KDC-REP  using the armor
+               -- and the key usage is KEY_USAGE_FAST_FINISH.
+               -- The checksum type is the required checksum type
+               -- of the armor key.
+           ...
+       }
+       KEY_USAGE_FAST_FINISHED            53
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   follow-referrals option is requested and honored by the KDC.  The
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   client need not confirm that the timestamp returned is within
+   allowable clock skew: the armor key guarantees that the reply is
+   fresh.  The client MAY trust the time stamp returned.
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The ticket-checksum is a checksum of the issued ticket.  The checksum
+   key is the armor key, and the checksum type is the required checksum
+   type of the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED.
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST be included in the padata sequence in the
+   KrbFastResponse sequence if the KDC expects at least one more message
+   from the client in order to complete the authentication.
+
+   The nonce field in the KrbFastResponse contains the value of the
+   nonce field in the KDC-REQ of the corresponding client request and it
+   binds the KDC response with the client request.  The client MUST
+   verify that this nonce value in the reply matches with that of the
+   request and reject the KDC reply otherwise.  To prevent the response
+   from one message in a conversation from being replayed to a request
+   in another message, clients SHOULD use a new nonce for each message
+   in a conversation.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        137
+
+   If the Kerberos FAST padata is included in the request but not
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The client SHOULD however process the KDC
+   errors as the result of the KDC's inability to accept the AP_REQ
+   armor and potentially retry another request with a different armor
+   when applicable.  The Kerberos client MAY process an error message
+   without a PA-FX-FAST-REPLY, if that is only intended to return better
+   error information to the application, typically for trouble-shooting
+   purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, then that
+   information should be transmitted in a pa-data element within the
+   KRBFastResponse structure.  The padata-type is the same as the data-
+   type would be in the typed data element and the padata-value is the
+   same as the data-value.  As discussed in Section 8, data-types and
+   padata-types are drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+6.5.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
+   include additional pa-data, but the KDC MUST ignore the outer request
+   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
+   processed.  In the case of the TGS request, the outer request should
+   include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST should
+   be included in PA-FX-FAST.  The client MUST ignore other padata
+   outside of PA-FX-FAST.
+
+6.5.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   client encrypts a structure containing a timestamp in the challenge
+   key.  The challenge key used by the client to send a message to the
+   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          138
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
+      KEY_USAGE_ENC_CHALLENGE_KDC     55
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the time stamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to re-use time stamps avoids requiring that clients maintain
+   state about which time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST strengthen the reply key
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   before issuing a ticket.  The client MUST check that the timestamp
+   decrypts properly.  The client MAY check that the timestamp is
+   winthin the window of acceptable clock skew for the client.  The
+   client MUST NOT require that the timestamp be identical to the
+   timestamp in the issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication and KDC authentication.  This FAST
+   factor also takes advantage of the FAST facility to strengthen the
+   reply key.  It does not provide the replacing-reply-key facility.
+   The security considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+   authentication set.  No pa-hint is defined because the only
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         70
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+7.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 8 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+7.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                 90
+           KDC_ERR_MORE_PREAUTH_DATA_NEEDED        91
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
+           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+7.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM               50
+           KEY_USAGE_FAST_ENC                      51
+           KEY_USAGE_FAST_REP                      52
+           KEY_USAGE_FAST_FINISHED                 53
+           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
+           KEY_USAGE_ENC_CHALLENGE_KDC             55
+
+7.3.  Authorization Data Elements
+
+           AD-authentication-strength              70
+           AD-fx-fast-armor                        71
+           AD-fx-fast-used                         72
+
+7.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                            133
+           PA-AUTHENTICATION-SET                   134
+           PA-AUTH-SET-SELECTED                    135
+           PA-FX-FAST                              136
+           PA-FX-ERROR                             137
+           PA-ENCRYPTED-CHALLENGE                  138
+
+
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+8.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   should all be located under
+   http://www.iana.org/assignments/kerberos-parameters.
+
+8.1.  Pre-authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registration
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   standards track RFCs.  A concern that a particular method needs to be
+   a standards track RFC may be raised as an objection during IETF
+   review.
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+      Type                Value    Reference
+  ----------------------------------------------------------------------
+  PA-TGS-REQ                 1    RFC 4120
+  PA-ENC-TIMESTAMP           2    RFC 4120
+  PA-PW-SALT                 3    RFC 4120
+  [reserved]                 4
+  PA-ENC-UNIX-TIME           5    (deprecated)
+  PA-SANDIA-SECUREID         6
+  PA-SESAME                  7
+  PA-OSF-DCE                 8
+  PA-CYBERSAFE-SECUREID      9
+  PA-AFS3-SALT               10
+  PA-ETYPE-INFO              11   RFC 4120
+  PA-SAM-CHALLENGE           12   (sam/otp)
+  PA-SAM-RESPONSE            13   (sam/otp)
+  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REQ               16   RFC 4556
+  PA-PK-AS-REP               17   RFC 4556
+  PA-PK-OCSP-RESPONSE        18   RFC 4557
+  PA-ETYPE-INFO2             19   RFC 4120
+  PA-USE-SPECIFIED-KVNO      20
+  PA-SVR-REFERRAL-INFO       20   (referrals)
+  PA-SAM-REDIRECT            21   (sam/otp)
+  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
+  TD-PADATA                  22   (embeds padata)
+  PA-SAM-ETYPE-INFO          23   (sam/otp)
+  PA-ALT-PRINC               24   (crawdad@fnal.gov)
+  PA-SERVER-REFERRAL         25   (referrals)
+  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
+  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
+  PA-EXTRA-TGT               41   Reserved extra TGT
+  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+  TD-KRB-PRINCIPAL           102  PrincipalName
+  TD-KRB-REALM               103  Realm
+  TD-TRUSTED-CERTIFIERS      104  PKINIT
+  TD-CERTIFICATE-INDEX       105  PKINIT
+  TD-APP-DEFINED-ERROR       106  Application specific
+  TD-REQ-NONCE               107  INTEGER
+  TD-REQ-SEQ                 108  INTEGER
+  PA-PAC-REQUEST             128  MS-KILE
+  PA-FOR_USER                129  MS-KILE
+  PA-FOR-X509-USER           130  MS-KILE
+  PA-FOR-CHECK_DUPS          131  MS-KILE
+  PA-AS-CHECKSUM             132  MS-KILE
+  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
+  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
+  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
+  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
+  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
+  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
+  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
+  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
+  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
+  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
+  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
+  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
+  PA_PKU2U_NAME              148  draft-zhu-pku2u
+  PA-SUPPORTED-ETYPES        165  MS-KILE
+  PA-EXTENDED_ERROR          166  MS-KILE
+
+8.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+8.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in  the KDC response
+      16    kdc-follow-referrals   Requesting the KDC to follow
+                                   referrals
+
+
+9.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denied of service using this option, KDCs MAY
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 40]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   With regarding to the facilities provided by the Encrypted Challenge
+   FAST factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication and KDC-authentication.  There is no un-authenticated
+   clear text introduced by the Encrypted Challenge FAST factor.
+
+
+10.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+   Srinivas Cheruku and Greg Hudson provided valuable review comments.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 41]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+11.2.  Informative References
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+
+Appendix A.  Test Vectors for KRB-FX-CF2
+
+   This informative appendix presents test vectors for the KRB-FX-CF2
+   function.  Test vectors are presented for several encryption types.
+   In all cases the first key (k1) is the result of string-to-
+   key("key1", "key1", default_parameters) and the second key (k2) is
+   the result of string-to-key("key2", "key2", default_parameters).
+   Both keys are of the same enctype.  The presented test vector is the
+   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
+   "b").  The peppers are one-octet ASCII strings.
+
+   In performing interoperability testing, there was significant
+   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
+   vectors assume that the AES pseudo-random operation is aes-
+   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
+   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
+   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
+   assumed to be des-cbc(md5(input).  As specified in RFC 4757, the RC4
+   pseudo-random operation is hmac-sha1(input).
+
+   These test vectors were produced with revision 22359 of the MIT
+   Kerberos sources.  The AES 256 and AES 128 test vectors have been
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 42]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+   confirmed by another implementer.  The RC4 implementation of KRB-FX-
+   CF2 from that revision of MIT Kerberos worked against another
+   implementation during an interoperability event, although these
+   specific test vectors have not been confirmed.  The DES and triple
+   DES test vectors have not been confirmed.
+
+
+   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
+   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
+                        b9617ae3a96868c337cb93b5e72b1c7b
+   DES (enctype 1): 43bae3738c9467e6
+   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
+   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
+
+
+Appendix B.  Change History
+
+   RFC editor, please remove this section before publication.
+
+B.1.  Changes since 10
+
+      The checksum member of the KrbFastFinished sequence has been
+      removed.  A nonce field has been added to KrbFastResponse.
+      The cookie no longer needs to be outside of FAST.  In fact, some
+      security guarantees depend on the cookie being inside FAST now
+      that the finish checksum has been removed.  Affected that change.
+      Replace the rep-key field in KrbFastResponse with the strengthen-
+      key field.  Per mailing list discussion, there are security
+      advantages to strengthening the reply key.
+      Clarify handling of authentication sets.
+      Include the AD-fx-fast-used authorization data type.
+      Include note about random nonces.
+
+B.2.  Changes since 09
+
+      Clarify conversations by defining for TGS and by describing how
+      cookies form conversation boundaries.
+      Simplify text surrounding when finish is included: always for AS
+      and TGS reply, never for error.
+      Fill in IANA and constants
+
+B.3.  Changes since 08
+
+      Fix a number of typos
+      Rename anonymous flag to hide-client-name; rename kdc-referals to
+      kdc-follow-referrals
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 43]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+      Clarify how anonymous pkinit interacts with KDC verified.
+      Introduce AD-fx-fast-armor authorization data to deal with
+      unprivileged processes constructing KDC requests.  Note that a TGT
+      is always used for armor tickets if the armor field is present; if
+      you proxy or validate you'll end up with a TGT armor ticket and
+      another ticket in the pa-tgs-req.  Alternatively you can simply
+      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
+      All KDCs in a realm MUST support FAST if it is to be offered.
+      The cookie message is always generated by the KDC.
+      Note that the client can trust and need not verify the time stamp
+      in the finish message.  This can seed the client's idea of KDC
+      time.
+      Note that the client name in the finish message may differ from
+      the name in the request if referrals are used.
+      Note that KDCs should advertize fast in preauth_required errors.
+      Armor key is constructed using KRB-FX-CF2.  This is true even in
+      the TGS case; there is no security reason to do this.  Using the
+      subkey as done in draft 08 would be fine, but the current text
+      uses the same procedure both in the TGS and AS case.
+      Use a different challenge key in each direction in the encrypted
+      challenge option.
+      Note that the KDC should process PA-FX-COOKIE before other padata.
+      KRB-FX-CF2 uses k1's enctype for the result; change around calling
+      order so we pass in subkeys and armor keys as k1 in preference to
+      long-term keys or ticket session keys.
+      Clarify the relationship between authentication sets and cookies.
+      A cookie may not be needed in the first message.  Clarify how this
+      interacts with optimistic clients.
+      Remove text raising a concern that RFC 3961 may permit ciphertext
+      transformations that do not change plaintext: discussion on the
+      list came to the conclusion that RFC 3961 does not permit this.
+      Remove binding key concept; use the armor key instead.  The cookie
+      becomes just an octet string.
+      Include PA-FX-ERROR to protect the error information per Dublin.
+      Returning preauth_failed in the failed to decrypt encrypted
+      challenge seems fine; remove the issue marker
+      Add a section describing what goes in the inner and outer request.
+      I believe it is redundant but found it useful while putting
+      together an implementation proposal.
+      Use hyphen rather than underscore in the constants for pre-
+      authentication data to be consistent with RFC 4120.
+      Add a ticket-checksum to the finished message
+      Remove redundant KEY_USAGE_FAST_ARMOR.
+      Add protocol constants section for non-IANA registrations and
+      flesh out IANA section.
+      Clarify that kdc-req-body checksums should always use the outer
+      body even for mechanisms like PKINIT that include their own (now
+      redundant) checksum.
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 44]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+      Remove mechanism for encapsulating typed data in padata; just
+      reflect the value.
+
+B.4.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut and paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA-AUTH-SET-SELECTED
+      Clarify a KDC cannot ignore padata is has claimed to support
+
+B.5.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonably unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix C.  ASN.1 module
+
+      KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+           Microseconds, KerberosFlags
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 45]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+                  -- as defined in RFC 4120.
+
+
+      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+          pa-type      [0] Int32,
+              -- same as padata-type.
+          pa-hint      [1] OCTET STRING OPTIONAL,
+          pa-value     [2] OCTET STRING OPTIONAL,
+          ...
+      }
+
+      KrbFastArmor ::= SEQUENCE {
+          armor-type   [0] Int32,
+              -- Type of the armor.
+          armor-value  [1] OCTET STRING,
+              -- Value of the armor.
+          ...
+      }
+
+      PA-FX-FAST-REQUEST ::= CHOICE {
+          armored-data [0] KrbFastArmoredReq,
+          ...
+      }
+
+      KrbFastArmoredReq ::= SEQUENCE {
+          armor        [0] KrbFastArmor OPTIONAL,
+              -- Contains the armor that identifies the armor key.
+              -- MUST be present in AS-REQ.
+          req-checksum [1] Checksum,
+              -- For AS, contains the checksum performed over the type
+              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+              -- structure;
+              -- For TGS, contains the checksum performed over the type
+              -- AP-REQ in the PA-TGS-REQ padata.
+              -- The checksum key is the armor key, the checksum
+              -- type is the required checksum type for the enctype of
+              -- the armor key, and the key usage number is
+              -- KEY_USAGE_FAST_REQ_CHKSUM.
+          enc-fast-req [2] EncryptedData, -- KrbFastReq --
+              -- The encryption key is the armor key, and the key usage
+              -- number is KEY_USAGE_FAST_ENC.
+          ...
+      }
+
+      KrbFastReq ::= SEQUENCE {
+          fast-options [0] FastOptions,
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 46]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+              -- Additional options.
+          padata       [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          req-body     [2] KDC-REQ-BODY,
+              -- Contains the KDC request body as defined in Section
+              -- 5.4.1 of [RFC4120].
+              -- This req-body field is preferred over the outer field
+              -- in the KDC request.
+           ...
+      }
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- hide-client-names(1),
+          -- kdc-follow-referrals(16)
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+
+      KrbFastResponse ::= SEQUENCE {
+          padata         [0] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          strengthen-key [1] EncryptionKey OPTIONAL,
+              -- This, if present, strengthens the reply key for AS and
+              -- TGS.
+              -- MUST be absent in KRB-ERROR.
+          finished       [2] KrbFastFinished OPTIONAL,
+              -- Present in AS or TGS reply; absent otherwise.
+          nonce          [3] UInt32,
+              -- Nonce from the client request.
+          ...
+      }
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp       [0] KerberosTime,
+          usec            [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm          [2] Realm,
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 47]
+
+Internet-Draft         Kerberos Preauth Framework               May 2009
+
+
+          cname           [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          ticket-checksum [4] Checksum,
+              -- checksum of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+      END
+
+
+Authors' Addresses
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires November 21, 2009              [Page 48]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-12.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-12.txt
new file mode 100644
index 00000000000..3b5cbd6be32
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-12.txt
@@ -0,0 +1,2745 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                         Painless Security
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: December 6, 2009                                   June 4, 2009
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-12
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on December 6, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secrets of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key delivery mechanism;
+   this secure channel can be used to protect the authentication
+   exchange thus eliminate offline dictionary attacks.  With these
+   tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Conventions and Terminology Used in This Document  . . . . . .  6
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
+     3.1.  Information Managed by the Pre-authentication Model  . . .  7
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
+       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
+       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
+   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
+     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
+     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
+     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
+     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 37
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
+     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
+     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
+     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 42
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 42
+   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 43
+   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 44
+     B.1.  Changes since 11 . . . . . . . . . . . . . . . . . . . . . 44
+     B.2.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 44
+     B.3.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 44
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+     B.4.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 44
+     B.5.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 46
+     B.6.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 46
+   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 46
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secrets or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver a reply
+   key within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password authenticated key exchange (PAKE) protocols with zero
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 6.5.  A pre-authentication type carried within
+   FAST is called a FAST factor.  Creating a FAST factor is the easiest
+   path to create a new pre-authentication mechanism.  FAST factors are
+   significantly easier to analyze from a security standpoint than other
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's Authentication Service (AS) in
+   order to authenticate the client principal.  A conversation as
+   defined here consists of all messages that are necessary to complete
+   the authentication between the client and the client's AS.  In the
+   Ticket Exchange Service (TGS) exchange, a conversation consists of
+   the request message and the reply message.  The term conversation is
+   defined here for both AS and TGS for convenience of discussion.  See
+   Section 6.3 for specific rules on the extent of a conversation in the
+   AS-REQ case.  Prior to this framework, implementations needed to use
+   implementation-specific heuristics to determine the extent of a
+   conversation.
+
+   If the KDC reply in an AS exchange is verified, the KDC is
+   authenticated by the client.  In this document, verification of the
+   KDC reply is used as a synonym of authentication of the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the contents of the KDC reply can be verified by the
+      client principal
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client principal's long-term key.  It should be
+   noted that in this document, verifying the KDC reply means
+   authenticating the KDC, and these phrases are used interchangeably.
+   Any pre-authentication mechanism that sets a new reply key not based
+   on the principal's long-term secret MUST either verify the KDC reply
+   some other way or indicate that the reply is not verified.  If a
+   mechanism indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   The typical Kerberos request does not provide a way for the client
+   machine to know that it is talking to the correct KDC.  Someone who
+   can inject packets into the network between the client machine and
+   the KDC and who knows the password that the user will give to the
+   client machine can generate a KDC reply that will decrypt properly.
+   So, if the client machine needs to authenticate that the user is in
+   fact the named principal, then the client machine needs to do a TGS
+   request for itself as a service.  Some pre-authentication mechanisms
+   may provide a way for the client machine to authenticate the KDC.
+   Examples of this include signing the reply that can be verified using
+   a well-known public key or providing a ticket for the client machine
+   as a service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+
+
+
+Hartman & Zhu           Expires December 6, 2009                [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set, offered alone, or both.  For each mechanism
+   that is offered alone (even if it is also offered in an
+   authentication set), the KDC includes the pre-authentication type ID
+   of the mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
+   part of an authentication set are not directly represented in the
+   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
+   although they are represented in the PA-AUTHENTICATION-SET sequence.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and pre-authentication is desirable.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to guess values
+   for the information it would normally receive from that error
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 6.3 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 3.3, the KDC MAY
+   ignore padata that is inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
+   KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets (as
+   defined in Section 6.4) MUST contain a sequence of inner mechanisms
+   along with hints for those mechanisms.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   authentication.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) -> x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one round trip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless in that there is no requirement that
+   clients will choose the same KDC for the second request in a
+   conversation.  Proxies or other intermediate nodes may also influence
+   KDC selection.  So, each request from a client to a KDC must include
+   sufficient information that the KDC can regenerate any needed state.
+   This is accomplished by giving the client a potentially long opaque
+   cookie in responses to include in future requests in the same
+   conversation.  The KDC MAY respond that a conversation is too old and
+   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            90
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management in the AS exchange.  This padata is sent by the KDC
+   when the KDC requires state for a future transaction.  The client
+   includes this opaque token in the next message in the conversation.
+   The token may be relatively large; clients MUST be prepared for
+   tokens somewhat larger than the size of all messages in a
+   conversation.
+
+       PA-FX-COOKIE                       133
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However the KDC MUST construct the cookie
+   token in such a manner that a malicious client cannot subvert the
+   authentication process by manipulating the token.  The KDC
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   implementation needs to consider expiration of tokens, key rollover
+   and other security issues in token design.  The content of the cookie
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
+   identify the conversation with the client according to Section 3.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   91
+
+   A client MAY throw away the state associated with a conversation and
+   begin a new conversation by discarding its state and not including a
+   cooking in the first message of a conversation.  KDCs that comply
+   with this specification MUST include a cookie in a response when the
+   client can continue the conversation.  In particular, a KDC MUST
+   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+   KDC_ERR_MORE_PREAUTH_DATA_NEEDED.  KDCs SHOULD include a cookie in
+   errors containing additional information allowing a client to retry.
+   One reasonable strategy for meeting these requirements is to always
+   include a cookie in KDC errors.
+
+   A KDC MAY indicate that it is terminating a conversation by not
+   including a cookie in a response.  When FAST is used, clients can
+   assume that the absence of a cookie means that the KDC is ending the
+   conversation.  Clients also need to deal with KDCs prior to this
+   specification that do not include cookies; if cookies nor FAST are
+   used in a conversation, the absence of a cookie is not a strong
+   indication that the KDC is terminating the conversation.
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              134
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value     [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.  The PA-
+   AUTH-SET-SELECTED padata element MUST come before any padata elements
+   from the authentication set in the padata sequence in the AS-REQ
+   message.  The client MAY cache authentication sets from prior
+   messages and use them to construct an optimistic initial AS-REQ.  If
+   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
+   correspond to an authentication set that it would offer, then the KDC
+   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
+   in this error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+         PA-AUTH-SET-SELECTED                   135
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers needs to carefully consider the
+   design of their hints so that the client has this information.  This
+   way, clients can construct necessary dialogue boxes or wizards based
+   on the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
+   requirement is so that the conversation can continue if the
+   conversation involves multiple KDCs.  KDCs MUST support clients that
+   do not include a cookie because they optimistically choose an
+   authentication set, although they MAY always return
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
+   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
+   FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a fast factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+                   "subkeyarmor", "ticketarmor" )
+
+   The `ticket_session_key' is the session key from the ticket in the
+   ap-req.  The `subkey' is the ap-req subkey.  This construction
+   guarantees that both the KDC (through the session key) and the client
+   (through the subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key whose
+       binding with the expected KDC can be verified by the client, the
+       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
+       authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+   If anonymous PKINIT is used to obtain the armor ticket, the KDC
+   cannot know whether its signing key can be verified by the client,
+   hence the KDC MUST be marked as unverified from the KDC's point of
+   view while the client could be able to authenticate the KDC by
+   verifying the KDC's signing key is bound with the expected KDC.  The
+   client needs to carefully consider the risk and benefit tradeoffs
+   associated with active attacks before exposing cipher text encrypted
+   using the user's long-term secrets when the armor does not
+   authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+   armor authorization data element.  These tickets and authenticators
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e. the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   As discussed previously, the server of an armor ticket MUST be the
+   TGS of the realm from whom service is requested.  As a result, if
+   this armor type is used when a ticket is being validated, proxied, or
+   in other cases where a ticket other than a TGT is presented to the
+   TGS, a TGT will be used as an armor ticket, while another ticket will
+   be used in the pa-tgs-req authenticator.
+
+6.5.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
+   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
+   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
+   error.  FAST is not expected to be used in an authentication set:
+   clients will typically use FAST padata if available and this decision
+   should not depend on what other pre-authentication methods are
+   available.  As such, no pa-hint is defined for FAST at this time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+       PA-FX-FAST                         136
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- For AS, contains the checksum performed over the type
+               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+               -- structure;
+               -- For TGS, contains the checksum performed over the type
+               -- AP-REQ in the PA-TGS-REQ padata.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          50
+       KEY_USAGE_FAST_ENC                 51
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD not include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
+      being presented to the TGS, a client SHOULD use some form of FAST
+      armor such as a ticket-based armor with a TGT as an armor ticket.
+      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
+      omit the armor field, in which case the armor key is the same that
+      would be computed if the authenticator were used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
+      ticket other than a TGT can be used to establish an armor key;
+      even though the armor key is computed the same as a
+      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
+      ticket in FX_FAST_ARMOR_AP_REQUEST.
+
+   The req-checksum field contains a checksum computed differently for
+   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
+   BODY for the req-body field of the KDC-REQ structure of the
+   containing message; for an TGS-REQ, it is performed over the type AP-
+   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
+   the armor key, and the checksum type is the required checksum type
+   for the enctype of the armor key per [RFC3961].  This checksum MUST
+   be a keyed checksume and it is included in order to bind the FAST
+   padata to the outer request.  A KDC that implements FAST will ignore
+   the outer request, but including a checksum is relatively cheap and
+   may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+            -- kdc-follow-referrals(16)
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+     Bits    Name                    Description
+    -----------------------------------------------------------------
+     0     RESERVED              Reserved for future expansion of this
+                                 field.
+     1     hide-client-names     Requesting the KDC to hide client
+                                 names in the KDC response, as
+                                 described next in this section.
+     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [KRB-ANON] in the KDC reply and the error
+      response.  Hence this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] needs to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-follow-
+      referrals option is designed to minimize the number of messages
+      that need to be processed by the client.  This option is useful
+      when, for example, the client may contact the KDC via a satellite
+      link that has high network latency, or the client has limited
+      computational capabilities.  If the kdc-follow-referrals option is
+      set, the KDC MAY act as the client to follow TGS referrals
+      [REFERRALS], and return the service ticket to the named server
+      principal in the client request using the reply key expected by
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+      the client.  That is, rather than returning a referral, the KDC
+      follows that referral by contacting a remote KDC and processing
+      the referral.  The kdc-referrals option can be implemented when
+      the KDC knows the reply key.  The KDC can ignore kdc-referrals
+      option when it does not understand it or it does not allow this
+      option based on local policy.  The client SHOULD be capable of
+      processing the KDC responses when this option is not honored by
+      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
+      is going to be used to avoid problems when the client's UDP
+      retransmit algorithm has timeouts insufficient to allow the KDC to
+      interact with remote KDCs.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.  If the KDC
+   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+   the client MUST place any padata that is otherwise in the outer KDC
+   request body into this field.  In a TGS request, PA-TGS-REQ padata is
+   not included in this field and it is present in the outer KDC request
+   body.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
+   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
+   should checksum the KDC-REQ-BODY.
+
+   In a TGS request, a client MAY include the AD-fx-fast-used authdata
+   either in the pa-tgs-req authenticator or in the authorization data
+   in the pa-tgs-req ticket.  If the KDC receives this authorization
+   data but does not find a FAST padata then it MUST return
+   KRB_APP_ERR_MODIFIED.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 52
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+       KrbFastResponse ::= SEQUENCE {
+           padata         [0] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           strengthen-key [1] EncryptionKey OPTIONAL,
+               -- This, if present, strengthens the reply key for AS and
+               -- TGS.
+               -- MUST be absent in KRB-ERROR.
+           finished       [2] KrbFastFinished OPTIONAL,
+               -- Present in AS or TGS reply; absent otherwise.
+           nonce          [3] UInt32,
+               -- Nonce from the client request.
+           ...
+  }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata that is otherwise in the outer KDC-
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   REP structure into this field.  The padata field in the KDC reply
+   structure outside of the PA-FX-FAST-REPLY structure typically
+   includes only the PA-FX- FAST-REPLY padata.
+
+   The strengthen-key field provides a mechanism for the KDC to
+   strengthen the reply key.  If set, the reply key is strengthened
+   after all padata items are processed.  Let padata-reply-key be the
+   reply key after padata processing.
+
+   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
+                         "strengthenkey", "replykey")
+
+   The strengthen-key field MAY be set in an AS or TGS reply; it must be
+   absent in an error reply.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation.  This
+   field is present in an AS-REP or a TGS-REP when a ticket is returned,
+   and it is not present in an error reply.
+
+   The KrbFastFinished structure contains the following information:
+
+       KrbFastFinished ::= SEQUENCE {
+           timestamp       [0] KerberosTime,
+           usec            [1] Microseconds,
+               -- timestamp and usec represent the time on the KDC when
+               -- the reply was generated.
+           crealm          [2] Realm,
+           cname           [3] PrincipalName,
+               -- Contains the client realm and the client name.
+           ticket-checksum [4] Checksum,
+               -- checksum of the ticket in the KDC-REP  using the armor
+               -- and the key usage is KEY_USAGE_FAST_FINISH.
+               -- The checksum type is the required checksum type
+               -- of the armor key.
+           ...
+       }
+       KEY_USAGE_FAST_FINISHED            53
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+   follow-referrals option is requested and honored by the KDC.  The
+   client need not confirm that the timestamp returned is within
+   allowable clock skew: the armor key guarantees that the reply is
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   fresh.  The client MAY trust the time stamp returned.
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The ticket-checksum is a checksum of the issued ticket.  The checksum
+   key is the armor key, and the checksum type is the required checksum
+   type of the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED.
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST be included in the padata sequence in the
+   KrbFastResponse sequence if the KDC expects at least one more message
+   from the client in order to complete the authentication.
+
+   The nonce field in the KrbFastResponse contains the value of the
+   nonce field in the KDC-REQ of the corresponding client request and it
+   binds the KDC response with the client request.  The client MUST
+   verify that this nonce value in the reply matches with that of the
+   request and reject the KDC reply otherwise.  To prevent the response
+   from one message in a conversation from being replayed to a request
+   in another message, clients SHOULD use a new nonce for each message
+   in a conversation.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        137
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   integrity protection.  The client SHOULD however process the KDC
+   errors as the result of the KDC's inability to accept the AP_REQ
+   armor and potentially retry another request with a different armor
+   when applicable.  The Kerberos client MAY process an error message
+   without a PA-FX-FAST-REPLY, if that is only intended to return better
+   error information to the application, typically for trouble-shooting
+   purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, then that
+   information should be transmitted in a pa-data element within the
+   KRBFastResponse structure.  The padata-type is the same as the data-
+   type would be in the typed data element and the padata-value is the
+   same as the data-value.  As discussed in Section 8, data-types and
+   padata-types are drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+6.5.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
+   include additional pa-data, but the KDC MUST ignore the outer request
+   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
+   processed.  In the case of the TGS request, the outer request should
+   include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST should
+   be included in PA-FX-FAST.  The client MUST ignore other padata
+   outside of PA-FX-FAST.
+
+6.5.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   client encrypts a structure containing a timestamp in the challenge
+   key.  The challenge key used by the client to send a message to the
+   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          138
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
+      KEY_USAGE_ENC_CHALLENGE_KDC     55
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the time stamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to re-use time stamps avoids requiring that clients maintain
+   state about which time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST strengthen the reply key
+   before issuing a ticket.  The client MUST check that the timestamp
+   decrypts properly.  The client MAY check that the timestamp is
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   winthin the window of acceptable clock skew for the client.  The
+   client MUST NOT require that the timestamp be identical to the
+   timestamp in the issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication and KDC authentication.  This FAST
+   factor also takes advantage of the FAST facility to strengthen the
+   reply key.  It does not provide the replacing-reply-key facility.
+   The security considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+   authentication set.  No pa-hint is defined because the only
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         70
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+7.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 8 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+7.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                 90
+           KDC_ERR_MORE_PREAUTH_DATA_NEEDED        91
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
+           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+7.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM               50
+           KEY_USAGE_FAST_ENC                      51
+           KEY_USAGE_FAST_REP                      52
+           KEY_USAGE_FAST_FINISHED                 53
+           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
+           KEY_USAGE_ENC_CHALLENGE_KDC             55
+
+7.3.  Authorization Data Elements
+
+           AD-authentication-strength              70
+           AD-fx-fast-armor                        71
+           AD-fx-fast-used                         72
+
+7.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                            133
+           PA-AUTHENTICATION-SET                   134
+           PA-AUTH-SET-SELECTED                    135
+           PA-FX-FAST                              136
+           PA-FX-ERROR                             137
+           PA-ENCRYPTED-CHALLENGE                  138
+
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+8.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   should all be located under
+   http://www.iana.org/assignments/kerberos-parameters.
+
+8.1.  Pre-authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registration
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   standards track RFCs.  A concern that a particular method needs to be
+   a standards track RFC may be raised as an objection during IETF
+   review.
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+      Type                Value    Reference
+  ----------------------------------------------------------------------
+  PA-TGS-REQ                 1    RFC 4120
+  PA-ENC-TIMESTAMP           2    RFC 4120
+  PA-PW-SALT                 3    RFC 4120
+  [reserved]                 4
+  PA-ENC-UNIX-TIME           5    (deprecated)
+  PA-SANDIA-SECUREID         6
+  PA-SESAME                  7
+  PA-OSF-DCE                 8
+  PA-CYBERSAFE-SECUREID      9
+  PA-AFS3-SALT               10
+  PA-ETYPE-INFO              11   RFC 4120
+  PA-SAM-CHALLENGE           12   (sam/otp)
+  PA-SAM-RESPONSE            13   (sam/otp)
+  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REQ               16   RFC 4556
+  PA-PK-AS-REP               17   RFC 4556
+  PA-PK-OCSP-RESPONSE        18   RFC 4557
+  PA-ETYPE-INFO2             19   RFC 4120
+  PA-USE-SPECIFIED-KVNO      20
+  PA-SVR-REFERRAL-INFO       20   (referrals)
+  PA-SAM-REDIRECT            21   (sam/otp)
+  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
+  TD-PADATA                  22   (embeds padata)
+  PA-SAM-ETYPE-INFO          23   (sam/otp)
+  PA-ALT-PRINC               24   (crawdad@fnal.gov)
+  PA-SERVER-REFERRAL         25   (referrals)
+  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
+  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
+  PA-EXTRA-TGT               41   Reserved extra TGT
+  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+  TD-KRB-PRINCIPAL           102  PrincipalName
+  TD-KRB-REALM               103  Realm
+  TD-TRUSTED-CERTIFIERS      104  PKINIT
+  TD-CERTIFICATE-INDEX       105  PKINIT
+  TD-APP-DEFINED-ERROR       106  Application specific
+  TD-REQ-NONCE               107  INTEGER
+  TD-REQ-SEQ                 108  INTEGER
+  PA-PAC-REQUEST             128  MS-KILE
+  PA-FOR_USER                129  MS-KILE
+  PA-FOR-X509-USER           130  MS-KILE
+  PA-FOR-CHECK_DUPS          131  MS-KILE
+  PA-AS-CHECKSUM             132  MS-KILE
+  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
+  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
+  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
+  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
+  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
+  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
+  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
+  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
+  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
+  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
+  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
+  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
+  PA_PKU2U_NAME              148  draft-zhu-pku2u
+  PA-SUPPORTED-ETYPES        165  MS-KILE
+  PA-EXTENDED_ERROR          166  MS-KILE
+
+8.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+8.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in  the KDC response
+      16    kdc-follow-referrals   Requesting the KDC to follow
+                                   referrals
+
+
+9.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denial of service using this option, KDCs MAY
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 40]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   With regarding to the facilities provided by the Encrypted Challenge
+   FAST factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication and KDC-authentication.  There is no un-authenticated
+   clear text introduced by the Encrypted Challenge FAST factor.
+
+   FAST provides an encrypted tunnel over which pre-authentication
+   conversations can take place.  In addition, FAST optionally
+   authenticates the KDC to the client.  It is the responsibility of
+   FAST factors to authenticate the client to the KDC.  Care MUST be
+   taken to design FAST factors such that they are bound to the
+   conversation.  If this is not done, a man-in-the-middle may be able
+   to cut&paste a fast factor from one conversation to another.  The
+   easiest way to do this is to bind each fast factor to the armor key
+   which is guaranteed to be unique for each conversation.
+
+   The anonymous pkinit mode for obtaining an armor ticket does not
+   always authenticate the KDC to the client before the conversation
+   begins.  Tracking the KDC verified state guarantees that by the end
+   of the conversation, the client has authenticated the KDC.  However
+   fast factor designers need to consider the implications of using
+   their factor when the KDC has not yet been authenticated.  If this
+   proves problematic in an environment, then the particular fast factor
+   should not be used with anonymous PKINIT.
+
+   Existing pre-authentication mechanisms are believed to be at least as
+   secure when used with FAST as they are when used outside of FAST.
+   One part of this security is making sure that when pre-authentication
+   methods checksum the request, they checksum the inner request rather
+   than the outer request.  If the mechanism checksummed the outer
+   request, a man-in-the-middle could observe it outside a FAST tunnel
+   and then cut&paste it into a FAST exchange where the inner rather
+   than outer request would be used to select attributes of the issued
+   ticket.  Such attacks would typically invalidate auditing information
+   or create a situation where the client and KDC disagree about what
+   ticket is issued.  However, such attacks are unlikely to allow an
+   attacker who would not be able to authenticate as a principal to do
+   so.  Even so, FAST is believed to defend against these attacks in
+   existing legacy mechanism.  However since there is no standard for
+   how legacy mechanisms bind the request to the pre-authentication or
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 41]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   provide integrity protection, security analysis can be difficult.  In
+   some cases FAST may significantly improve the integrity protection of
+   legacy mechanisms.
+
+
+10.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+   Srinivas Cheruku and Greg Hudson provided valuable review comments.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+11.2.  Informative References
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 42]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+
+Appendix A.  Test Vectors for KRB-FX-CF2
+
+   This informative appendix presents test vectors for the KRB-FX-CF2
+   function.  Test vectors are presented for several encryption types.
+   In all cases the first key (k1) is the result of string-to-
+   key("key1", "key1", default_parameters) and the second key (k2) is
+   the result of string-to-key("key2", "key2", default_parameters).
+   Both keys are of the same enctype.  The presented test vector is the
+   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
+   "b").  The peppers are one-octet ASCII strings.
+
+   In performing interoperability testing, there was significant
+   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
+   vectors assume that the AES pseudo-random operation is aes-
+   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
+   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
+   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
+   assumed to be des-cbc(md5(input).  As specified in RFC 4757, the RC4
+   pseudo-random operation is hmac-sha1(input).
+
+   These test vectors were produced with revision 22359 of the MIT
+   Kerberos sources.  The AES 256 and AES 128 test vectors have been
+   confirmed by another implementer.  The RC4 implementation of KRB-FX-
+   CF2 from that revision of MIT Kerberos worked against another
+   implementation during an interoperability event, although these
+   specific test vectors have not been confirmed.  The DES and triple
+   DES test vectors have not been confirmed.
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 43]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
+   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
+                        b9617ae3a96868c337cb93b5e72b1c7b
+   DES (enctype 1): 43bae3738c9467e6
+   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
+   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
+
+
+Appendix B.  Change History
+
+   RFC editor, please remove this section before publication.
+
+B.1.  Changes since 11
+
+      Checksum the inner request body in methods like PKINIT, not the
+      outer request body.  Per mailing list discussion, this change
+      addresses a potential security weakness.
+      Add additional security considerations text
+
+B.2.  Changes since 10
+
+      The checksum member of the KrbFastFinished sequence has been
+      removed.  A nonce field has been added to KrbFastResponse.
+      The cookie no longer needs to be outside of FAST.  In fact, some
+      security guarantees depend on the cookie being inside FAST now
+      that the finish checksum has been removed.  Affected that change.
+      Replace the rep-key field in KrbFastResponse with the strengthen-
+      key field.  Per mailing list discussion, there are security
+      advantages to strengthening the reply key.
+      Clarify handling of authentication sets.
+      Include the AD-fx-fast-used authorization data type.
+      Include note about random nonces.
+
+B.3.  Changes since 09
+
+      Clarify conversations by defining for TGS and by describing how
+      cookies form conversation boundaries.
+      Simplify text surrounding when finish is included: always for AS
+      and TGS reply, never for error.
+      Fill in IANA and constants
+
+B.4.  Changes since 08
+
+      Fix a number of typos
+      Rename anonymous flag to hide-client-name; rename kdc-referals to
+      kdc-follow-referrals
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 44]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+      Clarify how anonymous pkinit interacts with KDC verified.
+      Introduce AD-fx-fast-armor authorization data to deal with
+      unprivileged processes constructing KDC requests.  Note that a TGT
+      is always used for armor tickets if the armor field is present; if
+      you proxy or validate you'll end up with a TGT armor ticket and
+      another ticket in the pa-tgs-req.  Alternatively you can simply
+      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
+      All KDCs in a realm MUST support FAST if it is to be offered.
+      The cookie message is always generated by the KDC.
+      Note that the client can trust and need not verify the time stamp
+      in the finish message.  This can seed the client's idea of KDC
+      time.
+      Note that the client name in the finish message may differ from
+      the name in the request if referrals are used.
+      Note that KDCs should advertize fast in preauth_required errors.
+      Armor key is constructed using KRB-FX-CF2.  This is true even in
+      the TGS case; there is no security reason to do this.  Using the
+      subkey as done in draft 08 would be fine, but the current text
+      uses the same procedure both in the TGS and AS case.
+      Use a different challenge key in each direction in the encrypted
+      challenge option.
+      Note that the KDC should process PA-FX-COOKIE before other padata.
+      KRB-FX-CF2 uses k1's enctype for the result; change around calling
+      order so we pass in subkeys and armor keys as k1 in preference to
+      long-term keys or ticket session keys.
+      Clarify the relationship between authentication sets and cookies.
+      A cookie may not be needed in the first message.  Clarify how this
+      interacts with optimistic clients.
+      Remove text raising a concern that RFC 3961 may permit ciphertext
+      transformations that do not change plaintext: discussion on the
+      list came to the conclusion that RFC 3961 does not permit this.
+      Remove binding key concept; use the armor key instead.  The cookie
+      becomes just an octet string.
+      Include PA-FX-ERROR to protect the error information per Dublin.
+      Returning preauth_failed in the failed to decrypt encrypted
+      challenge seems fine; remove the issue marker
+      Add a section describing what goes in the inner and outer request.
+      I believe it is redundant but found it useful while putting
+      together an implementation proposal.
+      Use hyphen rather than underscore in the constants for pre-
+      authentication data to be consistent with RFC 4120.
+      Add a ticket-checksum to the finished message
+      Remove redundant KEY_USAGE_FAST_ARMOR.
+      Add protocol constants section for non-IANA registrations and
+      flesh out IANA section.
+      Clarify that kdc-req-body checksums should always use the outer
+      body even for mechanisms like PKINIT that include their own (now
+      redundant) checksum.
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 45]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+      Remove mechanism for encapsulating typed data in padata; just
+      reflect the value.
+
+B.5.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut and paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA-AUTH-SET-SELECTED
+      Clarify a KDC cannot ignore padata is has claimed to support
+
+B.6.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonably unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix C.  ASN.1 module
+
+      KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+           Microseconds, KerberosFlags
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 46]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+                  -- as defined in RFC 4120.
+
+
+      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+          pa-type      [0] Int32,
+              -- same as padata-type.
+          pa-hint      [1] OCTET STRING OPTIONAL,
+          pa-value     [2] OCTET STRING OPTIONAL,
+          ...
+      }
+
+      KrbFastArmor ::= SEQUENCE {
+          armor-type   [0] Int32,
+              -- Type of the armor.
+          armor-value  [1] OCTET STRING,
+              -- Value of the armor.
+          ...
+      }
+
+      PA-FX-FAST-REQUEST ::= CHOICE {
+          armored-data [0] KrbFastArmoredReq,
+          ...
+      }
+
+      KrbFastArmoredReq ::= SEQUENCE {
+          armor        [0] KrbFastArmor OPTIONAL,
+              -- Contains the armor that identifies the armor key.
+              -- MUST be present in AS-REQ.
+          req-checksum [1] Checksum,
+              -- For AS, contains the checksum performed over the type
+              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+              -- structure;
+              -- For TGS, contains the checksum performed over the type
+              -- AP-REQ in the PA-TGS-REQ padata.
+              -- The checksum key is the armor key, the checksum
+              -- type is the required checksum type for the enctype of
+              -- the armor key, and the key usage number is
+              -- KEY_USAGE_FAST_REQ_CHKSUM.
+          enc-fast-req [2] EncryptedData, -- KrbFastReq --
+              -- The encryption key is the armor key, and the key usage
+              -- number is KEY_USAGE_FAST_ENC.
+          ...
+      }
+
+      KrbFastReq ::= SEQUENCE {
+          fast-options [0] FastOptions,
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 47]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+              -- Additional options.
+          padata       [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          req-body     [2] KDC-REQ-BODY,
+              -- Contains the KDC request body as defined in Section
+              -- 5.4.1 of [RFC4120].
+              -- This req-body field is preferred over the outer field
+              -- in the KDC request.
+           ...
+      }
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- hide-client-names(1),
+          -- kdc-follow-referrals(16)
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+
+      KrbFastResponse ::= SEQUENCE {
+          padata         [0] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          strengthen-key [1] EncryptionKey OPTIONAL,
+              -- This, if present, strengthens the reply key for AS and
+              -- TGS.
+              -- MUST be absent in KRB-ERROR.
+          finished       [2] KrbFastFinished OPTIONAL,
+              -- Present in AS or TGS reply; absent otherwise.
+          nonce          [3] UInt32,
+              -- Nonce from the client request.
+          ...
+      }
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp       [0] KerberosTime,
+          usec            [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm          [2] Realm,
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 48]
+
+Internet-Draft         Kerberos Preauth Framework              June 2009
+
+
+          cname           [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          ticket-checksum [4] Checksum,
+              -- checksum of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+      END
+
+
+Authors' Addresses
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires December 6, 2009               [Page 49]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-13.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-13.txt
new file mode 100644
index 00000000000..b045c97c0df
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-13.txt
@@ -0,0 +1,2803 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                         Painless Security
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: January 30, 2010                                  July 29, 2009
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-13
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on January 30, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secrets of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key strengthening
+   mechanism; this secure channel can be used to protect the
+   authentication exchange thus eliminate offline dictionary attacks.
+   With these tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Conventions and Terminology Used in This Document  . . . . . .  6
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
+     3.1.  Information Managed by the Pre-authentication Model  . . .  7
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . . 10
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 16
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 17
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
+       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
+       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
+   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
+     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
+     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
+     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
+     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 38
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
+     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
+     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
+     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 43
+   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 44
+   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 44
+     B.1.  Changes since 12 . . . . . . . . . . . . . . . . . . . . . 45
+     B.2.  Changes since 11 . . . . . . . . . . . . . . . . . . . . . 45
+     B.3.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 45
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+     B.4.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 45
+     B.5.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 45
+     B.6.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 47
+     B.7.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 47
+   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 47
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secrets or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver key
+   material used to strengthen the reply key within the protected
+   channel.  Based on FAST, pre-authentication mechanisms can extend
+   Kerberos with ease, to support, for example, password authenticated
+   key exchange (PAKE) protocols with zero knowledge password proof
+   (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication mechanism can be
+   encapsulated in the FAST messages as defined in Section 6.5.  A pre-
+   authentication type carried within FAST is called a FAST factor.
+   Creating a FAST factor is the easiest path to create a new pre-
+   authentication mechanism.  FAST factors are significantly easier to
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   analyze from a security standpoint than other pre-authentication
+   mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's Authentication Service (AS) in
+   order to authenticate the client principal.  A conversation as
+   defined here consists of all messages that are necessary to complete
+   the authentication between the client and the client's AS.  In the
+   Ticket Exchange Service (TGS) exchange, a conversation consists of
+   the request message and the reply message.  The term conversation is
+   defined here for both AS and TGS for convenience of discussion.  See
+   Section 6.3 for specific rules on the extent of a conversation in the
+   AS-REQ case.  Prior to this framework, implementations needed to use
+   implementation-specific heuristics to determine the extent of a
+   conversation.
+
+   If the KDC reply in an AS exchange is verified, the KDC is
+   authenticated by the client.  In this document, verification of the
+   KDC reply is used as a synonym of authentication of the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   padata computed using the wrong pre-authentication mechanism or
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the origin of the KDC reply can be verified by the client
+      (i.e. whether the KDC is authenticated to the client)
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client's long-term key.  It should be noted
+   that in this document, verifying the KDC reply means authenticating
+   the KDC, and these phrases are used interchangeably.  Any pre-
+   authentication mechanism that sets a new reply key not based on the
+   principal's long-term secret MUST either verify the KDC reply some
+   other way or indicate that the reply is not verified.  If a mechanism
+   indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   In this specification, KDC verification/authentication refers to the
+   level of authentication of the KDC to the client provided by RFC
+   4120.  There is a stronger form of KDC verification that, while
+   sometimes important in Kerberos deployments is not addressed in this
+   specification: the typical Kerberos request does not provide a way
+   for the client machine to know that it is talking to the correct KDC.
+   Someone who can inject packets into the network between the client
+   machine and the KDC and who knows the password that the user will
+   give to the client machine can generate a KDC reply that will decrypt
+   properly.  So, if the client machine needs to authenticate that the
+   user is in fact the named principal, then the client machine needs to
+   do a TGS request for itself as a service.  Some pre-authentication
+   mechanisms may provide a way for the client machine to authenticate
+   the KDC.  Examples of this include signing the reply that can be
+   verified using a well-known public key or providing a ticket for the
+
+
+
+Hartman & Zhu           Expires January 30, 2010                [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   client machine as a service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set, offered alone, or both.  For each mechanism
+   that is offered alone (even if it is also offered in an
+   authentication set), the KDC includes the pre-authentication type ID
+   of the mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
+   part of an authentication set are not directly represented in the
+   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
+   although they are represented in the PA-AUTHENTICATION-SET sequence.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and pre-authentication is desirable.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to guess values
+   for the information it would normally receive from that error
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 6.3 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 3.3, the KDC MAY
+   ignore padata that is inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will
+   include KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets (as
+   defined in Section 6.4) MUST contain a sequence of inner mechanisms
+   along with hints for those mechanisms.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   alteration.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) := x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) := pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one round trip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless in that there is no requirement that
+   clients will choose the same KDC for the second request in a
+   conversation.  Proxies or other intermediate nodes may also influence
+   KDC selection.  So, each request from a client to a KDC must include
+   sufficient information that the KDC can regenerate any needed state.
+   This is accomplished by giving the client a potentially long opaque
+   cookie in responses to include in future requests in the same
+   conversation.  The KDC MAY respond that a conversation is too old and
+   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            90
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management in the AS exchange.  This padata is sent by the KDC
+   when the KDC requires state for a future transaction.  The client
+   includes this opaque token in the next message in the conversation.
+   The token may be relatively large; clients MUST be prepared for
+   tokens somewhat larger than the size of all messages in a
+   conversation.
+
+       PA-FX-COOKIE                       133
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However the KDC MUST construct the cookie
+   token in such a manner that a malicious client cannot subvert the
+   authentication process by manipulating the token.  The KDC
+   implementation needs to consider expiration of tokens, key rollover
+   and other security issues in token design.  The content of the cookie
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to
+   identify the conversation with the client according to Section 3.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED   91
+
+   A client MAY throw away the state associated with a conversation and
+   begin a new conversation by discarding its state and not including a
+   cookie in the first message of a conversation.  KDCs that comply with
+   this specification MUST include a cookie in a response when the
+   client can continue the conversation.  In particular, a KDC MUST
+   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.  KDCs SHOULD include a cookie in
+   errors containing additional information allowing a client to retry.
+   One reasonable strategy for meeting these requirements is to always
+   include a cookie in KDC errors.
+
+   A KDC MAY indicate that it is terminating a conversation by not
+   including a cookie in a response.  When FAST is used, clients can
+   assume that the absence of a cookie means that the KDC is ending the
+   conversation.  Clients also need to deal with KDCs prior to this
+   specification that do not include cookies; if cookies nor FAST are
+   used in a conversation, the absence of a cookie is not a strong
+   indication that the KDC is terminating the conversation.
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              134
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value     [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.  The PA-
+   AUTH-SET-SELECTED padata element MUST come before any padata elements
+   from the authentication set in the padata sequence in the AS-REQ
+   message.  The client MAY cache authentication sets from prior
+   messages and use them to construct an optimistic initial AS-REQ.  If
+   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   correspond to an authentication set that it would offer, then the KDC
+   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
+   in this error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+         PA-AUTH-SET-SELECTED                   135
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers needs to carefully consider the
+   design of their hints so that the client has this information.  This
+   way, clients can construct necessary dialogue boxes or wizards based
+   on the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
+   requirement is so that the conversation can continue if the
+   conversation involves multiple KDCs.  KDCs MUST support clients that
+   do not include a cookie because they optimistically choose an
+   authentication set, although they MAY always return
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
+   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
+   FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.  If a FAST KDC receives an
+   unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
+
+   An armor type may be appropriate for use in armoring AS requests,
+   armoring TGS requests or both.  TGS armor types MUST authenticate the
+   client to to the KDC, typically by binding the TGT subsession key to
+   the armor key.  As discussed below, it is desirable for AS armor
+   types to authenticate the KDC to the client, but this is not
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   required.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a fast factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+                   "subkeyarmor", "ticketarmor" )
+
+   The `ticket_session_key' is the session key from the ticket in the
+   ap-req.  The `subkey' is the ap-req subkey.  This construction
+   guarantees that both the KDC (through the session key) and the client
+   (through the subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key whose
+       binding with the expected KDC can be verified by the client, the
+       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
+       authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   If anonymous PKINIT is used to obtain the armor ticket, the KDC
+   cannot know whether its signing key can be verified by the client,
+   hence the KDC MUST be marked as unverified from the KDC's point of
+   view while the client could be able to authenticate the KDC by
+   verifying the KDC's signing key is bound with the expected KDC.  The
+   client needs to carefully consider the risk and benefit tradeoffs
+   associated with active attacks before exposing cipher text encrypted
+   using the user's long-term secrets when the armor does not
+   authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+   armor authorization data element.  These tickets and authenticators
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e. the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   Only implicit armors are allowed in the TGS.
+
+6.5.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
+   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
+   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
+   error.  FAST is not expected to be used in an authentication set:
+   clients will typically use FAST padata if available and this decision
+   should not depend on what other pre-authentication methods are
+   available.  As such, no pa-hint is defined for FAST at this time.
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+       PA-FX-FAST                         136
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- For AS, contains the checksum performed over the type
+               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+               -- structure;
+               -- For TGS, contains the checksum performed over the type
+               -- AP-REQ in the PA-TGS-REQ padata.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          50
+       KEY_USAGE_FAST_ENC                 51
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD NOT include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  Clients MAY present a non-TGT in
+      the PA-TGS-REQ authenticator and omit the armor field, in which
+      case the armor key is the same that would be computed if the
+      authenticator were used in a FX_FAST_ARMOR_AP_REQUEST armor.  This
+      is the only case where a ticket other than a TGT can be used to
+      establish an armor key; even though the armor key is computed the
+      same as a FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an
+      armor ticket in FX_FAST_ARMOR_AP_REQUEST.  Alternatively, a client
+      MAY use an armor type defined in the future for use with the TGS
+      request.
+
+   The req-checksum field contains a checksum computed differently for
+   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
+   BODY for the req-body field of the KDC-REQ structure of the
+   containing message; for an TGS-REQ, it is performed over the type AP-
+   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
+   the armor key, and the checksum type is the required checksum type
+   for the enctype of the armor key per [RFC3961].  This checksum MUST
+   be a keyed checksume and it is included in order to bind the FAST
+   padata to the outer request.  A KDC that implements FAST will ignore
+   the outer request, but including a checksum is relatively cheap and
+   may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+            -- kdc-follow-referrals(16)
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+     Bits    Name                    Description
+    -----------------------------------------------------------------
+     0     RESERVED              Reserved for future expansion of this
+                                 field.
+     1     hide-client-names     Requesting the KDC to hide client
+                                 names in the KDC response, as
+                                 described next in this section.
+     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [KRB-ANON] in the KDC reply and the error
+      response.  Hence this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] needs to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-follow-
+      referrals option is designed to minimize the number of messages
+      that need to be processed by the client.  This option is useful
+      when, for example, the client may contact the KDC via a satellite
+      link that has high network latency, or the client has limited
+      computational capabilities.  If the kdc-follow-referrals option is
+      set, the KDC MAY act as the client to follow TGS referrals
+      [REFERRALS], and return the service ticket to the named server
+      principal in the client request using the reply key expected by
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+      the client.  That is, rather than returning a referral, the KDC
+      follows that referral by contacting a remote KDC and processing
+      the referral.  The kdc-referrals option can be implemented when
+      the KDC knows the reply key.  The KDC can ignore kdc-referrals
+      option when it does not understand it or it does not allow this
+      option based on local policy.  The client SHOULD be capable of
+      processing the KDC responses when this option is not honored by
+      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
+      is going to be used to avoid problems when the client's UDP
+      retransmit algorithm has timeouts insufficient to allow the KDC to
+      interact with remote KDCs.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.  If the KDC
+   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+   the client MUST place any padata that is otherwise in the outer KDC
+   request body into this field.  In a TGS request, PA-TGS-REQ padata is
+   not included in this field and it is present in the outer KDC request
+   body.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
+   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
+   should checksum the KDC-REQ-BODY in the FAST structure.
+
+   In a TGS request, a client MAY include the AD-fx-fast-used authdata
+   either in the pa-tgs-req authenticator or in the authorization data
+   in the pa-tgs-req ticket.  If the KDC receives this authorization
+   data but does not find a FAST padata then it MUST return
+   KRB_APP_ERR_MODIFIED.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 52
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+       KrbFastResponse ::= SEQUENCE {
+           padata         [0] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           strengthen-key [1] EncryptionKey OPTIONAL,
+               -- This, if present, strengthens the reply key for AS and
+               -- TGS. MUST be present for TGS.
+               -- MUST be absent in KRB-ERROR.
+           finished       [2] KrbFastFinished OPTIONAL,
+               -- Present in AS or TGS reply; absent otherwise.
+           nonce          [3] UInt32,
+               -- Nonce from the client request.
+           ...
+  }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata that is otherwise in the outer KDC-
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   REP structure into this field.  The padata field in the KDC reply
+   structure outside of the PA-FX-FAST-REPLY structure typically
+   includes only the PA-FX- FAST-REPLY padata.
+
+   The strengthen-key field provides a mechanism for the KDC to
+   strengthen the reply key.  If set, the reply key is strengthened
+   after all padata items are processed.  Let padata-reply-key be the
+   reply key after padata processing.
+
+   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
+                         "strengthenkey", "replykey")
+
+   The strengthen-key field MAY be set in an AS reply; it MUST be set in
+   a TGS reply; it must be absent in an error reply.  The strengthen key
+   is required in a TGS reply so that an attacker cannot remove the FAST
+   PADATA from a TGS reply, causing the KDC to appear not to support
+   FAST.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation.  This
+   field is present in an AS-REP or a TGS-REP when a ticket is returned,
+   and it is not present in an error reply.
+
+   The KrbFastFinished structure contains the following information:
+
+       KrbFastFinished ::= SEQUENCE {
+           timestamp       [0] KerberosTime,
+           usec            [1] Microseconds,
+               -- timestamp and usec represent the time on the KDC when
+               -- the reply was generated.
+           crealm          [2] Realm,
+           cname           [3] PrincipalName,
+               -- Contains the client realm and the client name.
+           ticket-checksum [4] Checksum,
+               -- checksum of the ticket in the KDC-REP  using the armor
+               -- and the key usage is KEY_USAGE_FAST_FINISH.
+               -- The checksum type is the required checksum type
+               -- of the armor key.
+           ...
+       }
+       KEY_USAGE_FAST_FINISHED            53
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   follow-referrals option is requested and honored by the KDC.  The
+   client need not confirm that the timestamp returned is within
+   allowable clock skew: the armor key guarantees that the reply is
+   fresh.  The client MAY trust the time stamp returned.
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The ticket-checksum is a checksum of the issued ticket.  The checksum
+   key is the armor key, and the checksum type is the required checksum
+   type of the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED.
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST be included in the padata sequence in the
+   KrbFastResponse sequence if the KDC expects at least one more message
+   from the client in order to complete the authentication.
+
+   The nonce field in the KrbFastResponse contains the value of the
+   nonce field in the KDC-REQ of the corresponding client request and it
+   binds the KDC response with the client request.  The client MUST
+   verify that this nonce value in the reply matches with that of the
+   request and reject the KDC reply otherwise.  To prevent the response
+   from one message in a conversation from being replayed to a request
+   in another message, clients SHOULD use a new nonce for each message
+   in a conversation.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        137
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The client SHOULD however process the KDC
+   errors as the result of the KDC's inability to accept the AP_REQ
+   armor and potentially retry another request with a different armor
+   when applicable.  The Kerberos client MAY process an error message
+   without a PA-FX-FAST-REPLY, if that is only intended to return better
+   error information to the application, typically for trouble-shooting
+   purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, then that
+   information should be transmitted in a pa-data element within the
+   KRBFastResponse structure.  The padata-type is the same as the data-
+   type would be in the typed data element and the padata-value is the
+   same as the data-value.  As discussed in Section 8, data-types and
+   padata-types are drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+6.5.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
+   include additional pa-data, but the KDC MUST ignore the outer request
+   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
+   processed.  In the case of the TGS request, the outer request should
+   include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST should
+   be included in PA-FX-FAST.  The client MUST ignore other padata
+   outside of PA-FX-FAST.
+
+6.5.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   word challenge is used instead of timestamp because while the
+   timestamp is used as an initial challenge, if the KDC and client do
+   not have synchronized time, then the KDC can provide updated time to
+   the client to use as a challenge.  The client encrypts a structure
+   containing a timestamp in the challenge key.  The challenge key used
+   by the client to send a message to the KDC is KRB-FX-
+   CF2(armor_key,long_term_key, "clientchallengearmor",
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE.  The
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          138
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
+      KEY_USAGE_ENC_CHALLENGE_KDC     55
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the time stamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to re-use time stamps avoids requiring that clients maintain
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   state about which time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST strengthen the reply key
+   before issuing a ticket.  The client MUST check that the timestamp
+   decrypts properly.  The client MAY check that the timestamp is within
+   the window of acceptable clock skew for the client.  The client MUST
+   NOT require that the timestamp be identical to the timestamp in the
+   issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication and KDC authentication.  This FAST
+   factor also takes advantage of the FAST facility to strengthen the
+   reply key.  It does not provide the replacing-reply-key facility.
+   The security considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+   authentication set.  No pa-hint is defined because the only
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         70
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 8 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+7.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                 90
+           KDC_ERR_MORE_PREAUTH_DATA_REQUIRED      91
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
+           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+7.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM               50
+           KEY_USAGE_FAST_ENC                      51
+           KEY_USAGE_FAST_REP                      52
+           KEY_USAGE_FAST_FINISHED                 53
+           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
+           KEY_USAGE_ENC_CHALLENGE_KDC             55
+
+7.3.  Authorization Data Elements
+
+           AD-authentication-strength              70
+           AD-fx-fast-armor                        71
+           AD-fx-fast-used                         72
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+7.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                            133
+           PA-AUTHENTICATION-SET                   134
+           PA-AUTH-SET-SELECTED                    135
+           PA-FX-FAST                              136
+           PA-FX-ERROR                             137
+           PA-ENCRYPTED-CHALLENGE                  138
+
+
+8.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   should all be located under
+   http://www.iana.org/assignments/kerberos-parameters.
+
+8.1.  Pre-authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registration
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   standards track RFCs.  A concern that a particular method needs to be
+   a standards track RFC may be raised as an objection during IETF
+   review.
+
+      Type                Value    Reference
+  ----------------------------------------------------------------------
+  PA-TGS-REQ                 1    RFC 4120
+  PA-ENC-TIMESTAMP           2    RFC 4120
+  PA-PW-SALT                 3    RFC 4120
+  [reserved]                 4
+  PA-ENC-UNIX-TIME           5    (deprecated)
+  PA-SANDIA-SECUREID         6
+  PA-SESAME                  7
+  PA-OSF-DCE                 8
+  PA-CYBERSAFE-SECUREID      9
+  PA-AFS3-SALT               10
+  PA-ETYPE-INFO              11   RFC 4120
+  PA-SAM-CHALLENGE           12   (sam/otp)
+  PA-SAM-RESPONSE            13   (sam/otp)
+  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REQ               16   RFC 4556
+  PA-PK-AS-REP               17   RFC 4556
+  PA-PK-OCSP-RESPONSE        18   RFC 4557
+  PA-ETYPE-INFO2             19   RFC 4120
+  PA-USE-SPECIFIED-KVNO      20
+  PA-SVR-REFERRAL-INFO       20   (referrals)
+  PA-SAM-REDIRECT            21   (sam/otp)
+  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
+  TD-PADATA                  22   (embeds padata)
+  PA-SAM-ETYPE-INFO          23   (sam/otp)
+  PA-ALT-PRINC               24   (crawdad@fnal.gov)
+  PA-SERVER-REFERRAL         25   (referrals)
+  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
+  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
+  PA-EXTRA-TGT               41   Reserved extra TGT
+  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+  TD-KRB-PRINCIPAL           102  PrincipalName
+  TD-KRB-REALM               103  Realm
+  TD-TRUSTED-CERTIFIERS      104  PKINIT
+  TD-CERTIFICATE-INDEX       105  PKINIT
+  TD-APP-DEFINED-ERROR       106  Application specific
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+  TD-REQ-NONCE               107  INTEGER
+  TD-REQ-SEQ                 108  INTEGER
+  PA-PAC-REQUEST             128  MS-KILE
+  PA-FOR_USER                129  MS-KILE
+  PA-FOR-X509-USER           130  MS-KILE
+  PA-FOR-CHECK_DUPS          131  MS-KILE
+  PA-AS-CHECKSUM             132  MS-KILE
+  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
+  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
+  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
+  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
+  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
+  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
+  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
+  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
+  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
+  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
+  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
+  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
+  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
+  PA_PKU2U_NAME              148  draft-zhu-pku2u
+  PA-SUPPORTED-ETYPES        165  MS-KILE
+  PA-EXTENDED_ERROR          166  MS-KILE
+
+8.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+8.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 40]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in the KDC response
+      16    kdc-follow-referrals   Requesting the KDC to follow
+                                   referrals
+
+
+9.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denial of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   Regarding to the facilities provided by the Encrypted Challenge FAST
+   factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication and KDC-authentication.  There is no un-authenticated
+   clear text introduced by the Encrypted Challenge FAST factor.
+
+   FAST provides an encrypted tunnel over which pre-authentication
+   conversations can take place.  In addition, FAST optionally
+   authenticates the KDC to the client.  It is the responsibility of
+   FAST factors to authenticate the client to the KDC.  Care MUST be
+   taken to design FAST factors such that they are bound to the
+   conversation.  If this is not done, a man-in-the-middle may be able
+   to cut&paste a fast factor from one conversation to another.  The
+   easiest way to do this is to bind each fast factor to the armor key
+   which is guaranteed to be unique for each conversation.
+
+   The anonymous pkinit mode for obtaining an armor ticket does not
+   always authenticate the KDC to the client before the conversation
+   begins.  Tracking the KDC verified state guarantees that by the end
+   of the conversation, the client has authenticated the KDC.  However
+   fast factor designers need to consider the implications of using
+   their factor when the KDC has not yet been authenticated.  If this
+   proves problematic in an environment, then the particular fast factor
+   should not be used with anonymous PKINIT.
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 41]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   Existing pre-authentication mechanisms are believed to be at least as
+   secure when used with FAST as they are when used outside of FAST.
+   One part of this security is making sure that when pre-authentication
+   methods checksum the request, they checksum the inner request rather
+   than the outer request.  If the mechanism checksummed the outer
+   request, a man-in-the-middle could observe it outside a FAST tunnel
+   and then cut&paste it into a FAST exchange where the inner rather
+   than outer request would be used to select attributes of the issued
+   ticket.  Such attacks would typically invalidate auditing information
+   or create a situation where the client and KDC disagree about what
+   ticket is issued.  However, such attacks are unlikely to allow an
+   attacker who would not be able to authenticate as a principal to do
+   so.  Even so, FAST is believed to defend against these attacks in
+   existing legacy mechanism.  However since there is no standard for
+   how legacy mechanisms bind the request to the pre-authentication or
+   provide integrity protection, security analysis can be difficult.  In
+   some cases FAST may significantly improve the integrity protection of
+   legacy mechanisms.
+
+   The security of the TGS exchange depends on authenticating the client
+   to the KDC.  In the AS exchange, this is done using pre-
+   authentication data or FAST factors.  In the TGS exchange, this is
+   done by presenting a TGT and by using the session (or sub-session)
+   key in constructing the request.  Because FAST uses a request body in
+   the inner request, encrypted in the armor key, rather than the
+   request body in the outer request, it is critical that establishing
+   the armor key be tied to the authentication of the client to the KDC.
+   If this is not done, an attacker could manipulate the options
+   requested in the TGS request, for example requesting a ticket with
+   different validity or addresses.  The easiest way to bind the armor
+   key to the authentication of the client to the KDC is for the armor
+   key to depend on the sub-session key of the TGT.  This is done with
+   the implicit TGS armor supported by this specification.  Future armor
+   types designed for use with the TGS MUST either bind their armor keys
+   to the TGT or provide another mechanism to authenticate the client to
+   the KDC.
+
+
+10.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 42]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+   Srinivas Cheruku and Greg Hudson provided valuable review comments.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+11.2.  Informative References
+
+   [EKE]      Bellovin, S. and M. Merritt, "Augmented Encrypted Key
+              Exchange: A Password-Based Protocol Secure Against
+              Dictionary Attacks and Password File Compromise,
+              Proceedings of the 1st ACM Conference on Computer and
+              Communications Security, ACM Press.", November 1993.
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [IEEE1363.2]
+              IEEE, "IEEE P1363.2: Password-Based Public-Key
+              Cryptography", 2004.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 43]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+
+Appendix A.  Test Vectors for KRB-FX-CF2
+
+   This informative appendix presents test vectors for the KRB-FX-CF2
+   function.  Test vectors are presented for several encryption types.
+   In all cases the first key (k1) is the result of string-to-
+   key("key1", "key1", default_parameters) and the second key (k2) is
+   the result of string-to-key("key2", "key2", default_parameters).
+   Both keys are of the same enctype.  The presented test vector is the
+   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
+   "b").  The peppers are one-octet ASCII strings.
+
+   In performing interoperability testing, there was significant
+   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
+   vectors assume that the AES pseudo-random operation is aes-
+   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
+   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
+   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
+   assumed to be des-cbc(md5(input)).  As specified in RFC 4757, the RC4
+   pseudo-random operation is hmac-sha1(input).
+
+   These test vectors were produced with revision 22359 of the MIT
+   Kerberos sources.  The AES 256 and AES 128 test vectors have been
+   confirmed by multiple other implementors.  The RC4 test vectors have
+   been confirmed by one other implementor.  The triple DES test vectors
+   have also been confirmed.
+
+
+   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
+   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
+                        b9617ae3a96868c337cb93b5e72b1c7b
+   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
+   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
+
+
+Appendix B.  Change History
+
+   RFC editor, please remove this section before publication.
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 44]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+B.1.  Changes since 12
+
+      Per comment from Greg Hudson, KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
+      instead of KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+      Use pa-authentication-set-selected not pa-auth-set-selected
+      Update discussion of KDC verification (Love)
+      Remove explicit TGS armor, note that TGS armor must authenticate
+      the client to the KDC, describe in security considerations.
+
+B.2.  Changes since 11
+
+      Checksum the inner request body in methods like PKINIT, not the
+      outer request body.  Per mailing list discussion, this change
+      addresses a potential security weakness.
+      Add additional security considerations text
+
+B.3.  Changes since 10
+
+      The checksum member of the KrbFastFinished sequence has been
+      removed.  A nonce field has been added to KrbFastResponse.
+      The cookie no longer needs to be outside of FAST.  In fact, some
+      security guarantees depend on the cookie being inside FAST now
+      that the finish checksum has been removed.  Affected that change.
+      Replace the rep-key field in KrbFastResponse with the strengthen-
+      key field.  Per mailing list discussion, there are security
+      advantages to strengthening the reply key.
+      Clarify handling of authentication sets.
+      Include the AD-fx-fast-used authorization data type.
+      Include note about random nonces.
+
+B.4.  Changes since 09
+
+      Clarify conversations by defining for TGS and by describing how
+      cookies form conversation boundaries.
+      Simplify text surrounding when finish is included: always for AS
+      and TGS reply, never for error.
+      Fill in IANA and constants
+
+B.5.  Changes since 08
+
+      Fix a number of typos
+      Rename anonymous flag to hide-client-name; rename kdc-referals to
+      kdc-follow-referrals
+      Clarify how anonymous pkinit interacts with KDC verified.
+      Introduce AD-fx-fast-armor authorization data to deal with
+      unprivileged processes constructing KDC requests.  Note that a TGT
+      is always used for armor tickets if the armor field is present; if
+      you proxy or validate you'll end up with a TGT armor ticket and
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 45]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+      another ticket in the pa-tgs-req.  Alternatively you can simply
+      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
+      All KDCs in a realm MUST support FAST if it is to be offered.
+      The cookie message is always generated by the KDC.
+      Note that the client can trust and need not verify the time stamp
+      in the finish message.  This can seed the client's idea of KDC
+      time.
+      Note that the client name in the finish message may differ from
+      the name in the request if referrals are used.
+      Note that KDCs should advertize fast in preauth_required errors.
+      Armor key is constructed using KRB-FX-CF2.  This is true even in
+      the TGS case; there is no security reason to do this.  Using the
+      subkey as done in draft 08 would be fine, but the current text
+      uses the same procedure both in the TGS and AS case.
+      Use a different challenge key in each direction in the encrypted
+      challenge option.
+      Note that the KDC should process PA-FX-COOKIE before other padata.
+      KRB-FX-CF2 uses k1's enctype for the result; change around calling
+      order so we pass in subkeys and armor keys as k1 in preference to
+      long-term keys or ticket session keys.
+      Clarify the relationship between authentication sets and cookies.
+      A cookie may not be needed in the first message.  Clarify how this
+      interacts with optimistic clients.
+      Remove text raising a concern that RFC 3961 may permit ciphertext
+      transformations that do not change plaintext: discussion on the
+      list came to the conclusion that RFC 3961 does not permit this.
+      Remove binding key concept; use the armor key instead.  The cookie
+      becomes just an octet string.
+      Include PA-FX-ERROR to protect the error information per Dublin.
+      Returning preauth_failed in the failed to decrypt encrypted
+      challenge seems fine; remove the issue marker
+      Add a section describing what goes in the inner and outer request.
+      I believe it is redundant but found it useful while putting
+      together an implementation proposal.
+      Use hyphen rather than underscore in the constants for pre-
+      authentication data to be consistent with RFC 4120.
+      Add a ticket-checksum to the finished message
+      Remove redundant KEY_USAGE_FAST_ARMOR.
+      Add protocol constants section for non-IANA registrations and
+      flesh out IANA section.
+      Clarify that kdc-req-body checksums should always use the outer
+      body even for mechanisms like PKINIT that include their own (now
+      redundant) checksum.
+      Remove mechanism for encapsulating typed data in padata; just
+      reflect the value.
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 46]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+B.6.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut and paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA-auth-SET-SELECTED
+      Clarify a KDC cannot ignore padata is has claimed to support
+
+B.7.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonably unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix C.  ASN.1 module
+
+      KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+           Microseconds, KerberosFlags
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+                  -- as defined in RFC 4120.
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 47]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+          pa-type      [0] Int32,
+              -- same as padata-type.
+          pa-hint      [1] OCTET STRING OPTIONAL,
+          pa-value     [2] OCTET STRING OPTIONAL,
+          ...
+      }
+
+      KrbFastArmor ::= SEQUENCE {
+          armor-type   [0] Int32,
+              -- Type of the armor.
+          armor-value  [1] OCTET STRING,
+              -- Value of the armor.
+          ...
+      }
+
+      PA-FX-FAST-REQUEST ::= CHOICE {
+          armored-data [0] KrbFastArmoredReq,
+          ...
+      }
+
+      KrbFastArmoredReq ::= SEQUENCE {
+          armor        [0] KrbFastArmor OPTIONAL,
+              -- Contains the armor that identifies the armor key.
+              -- MUST be present in AS-REQ.
+          req-checksum [1] Checksum,
+              -- For AS, contains the checksum performed over the type
+              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+              -- structure;
+              -- For TGS, contains the checksum performed over the type
+              -- AP-REQ in the PA-TGS-REQ padata.
+              -- The checksum key is the armor key, the checksum
+              -- type is the required checksum type for the enctype of
+              -- the armor key, and the key usage number is
+              -- KEY_USAGE_FAST_REQ_CHKSUM.
+          enc-fast-req [2] EncryptedData, -- KrbFastReq --
+              -- The encryption key is the armor key, and the key usage
+              -- number is KEY_USAGE_FAST_ENC.
+          ...
+      }
+
+      KrbFastReq ::= SEQUENCE {
+          fast-options [0] FastOptions,
+              -- Additional options.
+          padata       [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 48]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+          req-body     [2] KDC-REQ-BODY,
+              -- Contains the KDC request body as defined in Section
+              -- 5.4.1 of [RFC4120].
+              -- This req-body field is preferred over the outer field
+              -- in the KDC request.
+           ...
+      }
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- hide-client-names(1),
+          -- kdc-follow-referrals(16)
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+
+      KrbFastResponse ::= SEQUENCE {
+          padata         [0] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          strengthen-key [1] EncryptionKey OPTIONAL,
+              -- This, if present, strengthens the reply key for AS and
+              -- TGS.  MUST be present for TGS
+              -- MUST be absent in KRB-ERROR.
+          finished       [2] KrbFastFinished OPTIONAL,
+              -- Present in AS or TGS reply; absent otherwise.
+          nonce          [3] UInt32,
+              -- Nonce from the client request.
+          ...
+      }
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp       [0] KerberosTime,
+          usec            [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm          [2] Realm,
+          cname           [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          ticket-checksum [4] Checksum,
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 49]
+
+Internet-Draft         Kerberos Preauth Framework              July 2009
+
+
+              -- checksum of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+      END
+
+
+Authors' Addresses
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires January 30, 2010               [Page 50]
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-14.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-14.txt
new file mode 100644
index 00000000000..588b87adb76
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-preauth-framework-14.txt
@@ -0,0 +1,2801 @@
+
+
+
+Kerberos Working Group                                        S. Hartman
+Internet-Draft                                         Painless Security
+Updates: 4120 (if approved)                                       L. Zhu
+Intended status: Standards Track                   Microsoft Corporation
+Expires: February 13, 2010                               August 12, 2009
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+                 draft-ietf-krb-wg-preauth-framework-14
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on February 13, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 1]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   The Kerberos protocol provides a mechanism called pre-authentication
+   for proving the identity of a principal and for better protecting the
+   long-term secrets of the principal.
+
+   This document describes a model for Kerberos pre-authentication
+   mechanisms.  The model describes what state in the Kerberos request a
+   pre-authentication mechanism is likely to change.  It also describes
+   how multiple pre-authentication mechanisms used in the same request
+   will interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the KDC with a reply key strengthening
+   mechanism; this secure channel can be used to protect the
+   authentication exchange thus eliminate offline dictionary attacks.
+   With these tools, it is relatively straightforward to chain multiple
+   authentication mechanisms, utilize a different key management system,
+   or support a new key agreement algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 2]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Conventions and Terminology Used in This Document  . . . . . .  6
+   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
+     3.1.  Information Managed by the Pre-authentication Model  . . .  7
+     3.2.  Initial Pre-authentication Required Error  . . . . . . . . 10
+     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
+     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
+   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
+     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
+     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
+     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
+     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
+   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 16
+   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 17
+     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
+     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
+     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
+     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
+     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
+       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
+       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
+       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
+       6.5.4.  Authenticated Kerberos Error Messages using
+               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
+       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
+       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
+     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
+   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
+     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
+     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
+     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
+     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 38
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
+     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
+     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
+     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 43
+   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 44
+   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 45
+     B.1.  Changes since 13 . . . . . . . . . . . . . . . . . . . . . 45
+     B.2.  Changes since 12 . . . . . . . . . . . . . . . . . . . . . 45
+     B.3.  Changes since 11 . . . . . . . . . . . . . . . . . . . . . 45
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 3]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+     B.4.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 45
+     B.5.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 45
+     B.6.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 46
+     B.7.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 47
+     B.8.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 47
+   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 47
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 4]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data as an opaque typed hole in the messages to the KDC that may
+   influence the reply key used to encrypt the KDC reply.  This
+   generality has been useful: pre-authentication data is used for a
+   variety of extensions to the protocol, many outside the expectations
+   of the initial designers.  However, this generality makes designing
+   more common types of pre-authentication mechanisms difficult.  Each
+   mechanism needs to specify how it interacts with other mechanisms.
+   Also, problems like combining a key with the long-term secrets or
+   proving the identity of the user are common to multiple mechanisms.
+   Where there are generally well-accepted solutions to these problems,
+   it is desirable to standardize one of these solutions so mechanisms
+   can avoid duplication of work.  In other cases, a modular approach to
+   these problems is appropriate.  The modular approach will allow new
+   and better solutions to common pre-authentication problems to be used
+   by existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete--it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-Authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plugin architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the KDC, and it can optionally deliver key
+   material used to strengthen the reply key within the protected
+   channel.  Based on FAST, pre-authentication mechanisms can extend
+   Kerberos with ease, to support, for example, password authenticated
+   key exchange (PAKE) protocols with zero knowledge password proof
+   (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication mechanism can be
+   encapsulated in the FAST messages as defined in Section 6.5.  A pre-
+   authentication type carried within FAST is called a FAST factor.
+   Creating a FAST factor is the easiest path to create a new pre-
+   authentication mechanism.  FAST factors are significantly easier to
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 5]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   analyze from a security standpoint than other pre-authentication
+   mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+
+2.  Conventions and Terminology 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 [RFC2119].
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's Authentication Service (AS) in
+   order to authenticate the client principal.  A conversation as
+   defined here consists of all messages that are necessary to complete
+   the authentication between the client and the client's AS.  In the
+   Ticket Exchange Service (TGS) exchange, a conversation consists of
+   the request message and the reply message.  The term conversation is
+   defined here for both AS and TGS for convenience of discussion.  See
+   Section 6.3 for specific rules on the extent of a conversation in the
+   AS-REQ case.  Prior to this framework, implementations needed to use
+   implementation-specific heuristics to determine the extent of a
+   conversation.
+
+   If the KDC reply in an AS exchange is verified, the KDC is
+   authenticated by the client.  In this document, verification of the
+   KDC reply is used as a synonym of authentication of the KDC.
+
+
+3.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket using the
+   authentication server, it sends an initial Authentication Service
+   (AS) request.  If pre-authentication is required but not being used,
+   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round-trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 6]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   padata computed using the wrong pre-authentication mechanism or
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 6.3.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+3.1.  Information Managed by the Pre-authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 7]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the origin of the KDC reply can be verified by the client
+      (i.e. whether the KDC is authenticated to the client)
+
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request is verified by the KDC, then the
+   client is known to have that key, therefore the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  This information is useful to keep track of on the client
+   in order to know what pre-authentication mechanisms should be used.
+   The KDC needs to keep track of whether the client is authenticated
+   because the primary purpose of pre-authentication is to authenticate
+   the client identity before issuing a ticket.  The handling of
+   authentication strength using various authentication mechanisms is
+   discussed in Section 6.6.
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 8]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   Initially the reply key has not been used.  A pre-authentication
+   mechanism that uses the reply key to encrypt or checksum some data in
+   the generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 4.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially the reply key has not been replaced.  If a mechanism
+   implements the Replace Reply Key facility discussed in Section 4.3,
+   then the state MUST be updated to indicate that the reply key has
+   been replaced.  Once the reply key has been replaced, knowledge of
+   the reply key is insufficient to authenticate the client.  The reply
+   key is marked replaced in exactly the same situations as the KDC
+   reply is marked as not being verified to the client principal.
+   However, while mechanisms can verify the KDC reply to the client,
+   once the reply key is replaced, then the reply key remains replaced
+   for the remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So at the start of a conversation, the KDC reply is presumed to
+   be verified using the client's long-term key.  It should be noted
+   that in this document, verifying the KDC reply means authenticating
+   the KDC, and these phrases are used interchangeably.  Any pre-
+   authentication mechanism that sets a new reply key not based on the
+   principal's long-term secret MUST either verify the KDC reply some
+   other way or indicate that the reply is not verified.  If a mechanism
+   indicates that the reply is not verified then the client
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   In this specification, KDC verification/authentication refers to the
+   level of authentication of the KDC to the client provided by RFC
+   4120.  There is a stronger form of KDC verification that, while
+   sometimes important in Kerberos deployments is not addressed in this
+   specification: the typical Kerberos request does not provide a way
+   for the client machine to know that it is talking to the correct KDC.
+   Someone who can inject packets into the network between the client
+   machine and the KDC and who knows the password that the user will
+   give to the client machine can generate a KDC reply that will decrypt
+   properly.  So, if the client machine needs to authenticate that the
+   user is in fact the named principal, then the client machine needs to
+   do a TGS request for itself as a service.  Some pre-authentication
+   mechanisms may provide a way for the client machine to authenticate
+   the KDC.  Examples of this include signing the reply that can be
+   verified using a well-known public key or providing a ticket for the
+
+
+
+Hartman & Zhu           Expires February 13, 2010               [Page 9]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   client machine as a service.
+
+3.2.  Initial Pre-authentication Required Error
+
+   Typically a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
+   (defined in Section 6.3) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 3.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C. A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set--a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set, offered alone, or both.  For each mechanism
+   that is offered alone (even if it is also offered in an
+   authentication set), the KDC includes the pre-authentication type ID
+   of the mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
+   part of an authentication set are not directly represented in the
+   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
+   although they are represented in the PA-AUTHENTICATION-SET sequence.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and pre-authentication is desirable.
+
+3.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication then the client needs to guess values
+   for the information it would normally receive from that error
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 10]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 6.3.
+   Clients SHOULD process padata unrelated to this framework or other
+   means of authenticating the user.  Clients SHOULD choose one
+   authentication set or mechanism that could lead to authenticating the
+   user and ignore the rest.  Since the list of mechanisms offered by
+   the KDC is in the decreasing preference order, clients typically
+   choose the first mechanism or authentication set that the client can
+   usefully perform.  If a client chooses to ignore a padata it MUST NOT
+   process the padata, allow the padata to affect the pre-authentication
+   state, nor respond to the padata.
+
+   For each padata the client chooses to process, the client processes
+   the padata and modifies the pre-authentication state as required by
+   that mechanism.  Padata are processed in the order received from the
+   KDC.
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+3.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 6.3 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 3.3, the KDC MAY
+   ignore padata that is inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 11]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point the KDC decides whether it will issue an error or a
+   reply.  Typically a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC
+   first starts by initializing the pre-authentication state.  Then it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata is
+   generated, the error response is sent.  Typically the errors with the
+   code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will
+   include KDC state as discussed in Section 6.3.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+4.  Pre-Authentication Facilities
+
+   Pre-Authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  By combining multiple facilities in a single mechanism,
+   it is often easier to construct a secure, simple solution than by
+   solving the problem in full generality.  Even when mechanisms provide
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 12]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   multiple facilities, they need to meet the security requirements for
+   all the facilities they provide.  If the FAST factor approach is
+   used, it is likely that one or a small number of facilities can be
+   provided by a single mechanism without complicating the security
+   analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic--for
+   example proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 4.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 3.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+4.1.  Client-authentication Facility
+
+   The client authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 13]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The PKINIT mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+4.2.  Strengthening-reply-key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
+   be first combined with the existing reply key and then converted to a
+   protocol key using tools defined in Section 6.1.
+
+   Typically a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+   meets policy.  In many cases it is desirable to use the new reply key
+   for client authentication and for other facilities.  Waiting for the
+   other party to accept the proposal and actually modify the reply key
+   state would add an additional round trip to the exchange.  Instead,
+   mechanism designers are encouraged to include a typed hole for
+   additional padata in the message that proposes the reply key change.
+   The padata included in the typed hole are generated assuming the new
+   reply key.  If the other party accepts the proposal, then these
+   padata are considered as an inner level.  As with the outer level,
+   one authentication set or mechanism is typically chosen for client
+   authentication, along with auxiliary mechanisms such as KDC cookies,
+   and other mechanisms are ignored.  When mechanisms include such a
+   container, the hint provided for use in authentication sets (as
+   defined in Section 6.4) MUST contain a sequence of inner mechanisms
+   along with hints for those mechanisms.  The party generating the
+   proposal can determine whether the padata were processed based on
+   whether the proposal for the reply key is accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included is a matter for the mechanism specification.  Similarly,
+   the format of the message accepting the proposal is mechanism-
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 14]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+4.3.  Replacing-reply-key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+   As with the strengthening-reply-key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message as discussed in Section 4.2 if appropriate.
+
+4.4.  KDC-authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically the machine can retrieve this ticket by itself).  However,
+   if the reply key is replaced, some mechanism is required to verify
+   the KDC.  Pre-authentication mechanisms providing this facility allow
+   a client to determine that the expected KDC has responded even after
+   the reply key is replaced.  They mark the pre-authentication state as
+   having been verified.
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 15]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+5.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information such as trusted
+   certificate authorities in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 6.4).
+
+   In order to ease security analysis the mechanism specification should
+   describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security consideration section of
+   the mechanism specification should show that the security
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   alteration.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 6.3, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 16]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+6.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+6.1.  Combining Keys
+
+   Frequently a weak key needs to be combined with a stronger key before
+   use.  For example, passwords are typically limited in size and
+   insufficiently random, therefore it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   Additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two pass-phrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) := x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 17]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) := pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+6.2.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect clear text portions of pre-
+   authentication data.  Various denial of service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange that was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example.)  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   If there is more than one round trip for an authentication exchange,
+   mechanism designers need to allow either the client or the KDC to
+   provide a checksum of all the messages exchanged on the wire in the
+   conversation, and the checksum is then verified by the receiver.
+
+   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 18]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 6.5) is
+   encrypted in a protected channel, thus they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+   authentication mechanisms.
+
+6.3.  Managing States for the KDC
+
+   Kerberos KDCs are stateless in that there is no requirement that
+   clients will choose the same KDC for the second request in a
+   conversation.  Proxies or other intermediate nodes may also influence
+   KDC selection.  So, each request from a client to a KDC must include
+   sufficient information that the KDC can regenerate any needed state.
+   This is accomplished by giving the client a potentially long opaque
+   cookie in responses to include in future requests in the same
+   conversation.  The KDC MAY respond that a conversation is too old and
+   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            90
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge-response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management in the AS exchange.  This padata is sent by the KDC
+   when the KDC requires state for a future transaction.  The client
+   includes this opaque token in the next message in the conversation.
+   The token may be relatively large; clients MUST be prepared for
+   tokens somewhat larger than the size of all messages in a
+   conversation.
+
+       PA-FX-COOKIE                       133
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 19]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However the KDC MUST construct the cookie
+   token in such a manner that a malicious client cannot subvert the
+   authentication process by manipulating the token.  The KDC
+   implementation needs to consider expiration of tokens, key rollover
+   and other security issues in token design.  The content of the cookie
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to
+   identify the conversation with the client according to Section 3.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED   91
+
+   A client MAY throw away the state associated with a conversation and
+   begin a new conversation by discarding its state and not including a
+   cookie in the first message of a conversation.  KDCs that comply with
+   this specification MUST include a cookie in a response when the
+   client can continue the conversation.  In particular, a KDC MUST
+   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.  KDCs SHOULD include a cookie in
+   errors containing additional information allowing a client to retry.
+   One reasonable strategy for meeting these requirements is to always
+   include a cookie in KDC errors.
+
+   A KDC MAY indicate that it is terminating a conversation by not
+   including a cookie in a response.  When FAST is used, clients can
+   assume that the absence of a cookie means that the KDC is ending the
+   conversation.  Clients also need to deal with KDCs prior to this
+   specification that do not include cookies; if cookies nor FAST are
+   used in a conversation, the absence of a cookie is not a strong
+   indication that the KDC is terminating the conversation.
+
+6.4.  Pre-authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 20]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              134
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value     [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet-string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client which helps it determine whether the
+   mechanism can be used.  For example a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore pa-value for the second
+   and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.  The PA-
+   AUTH-SET-SELECTED padata element MUST come before any padata elements
+   from the authentication set in the padata sequence in the AS-REQ
+   message.  The client MAY cache authentication sets from prior
+   messages and use them to construct an optimistic initial AS-REQ.  If
+   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 21]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   correspond to an authentication set that it would offer, then the KDC
+   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
+   in this error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+
+         PA-AUTH-SET-SELECTED                   135
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances such as expired passwords or
+   expired accounts may require that additional user interface be
+   displayed.  Mechanism designers needs to carefully consider the
+   design of their hints so that the client has this information.  This
+   way, clients can construct necessary dialogue boxes or wizards based
+   on the authentication set and can present a coherent user interface.
+   Current standards for user interface do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE as
+   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
+   requirement is so that the conversation can continue if the
+   conversation involves multiple KDCs.  KDCs MUST support clients that
+   do not include a cookie because they optimistically choose an
+   authentication set, although they MAY always return
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
+   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
+   FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS_REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
+   in Section 6.3 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 22]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   the METHOD-DATA.  If there is no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+6.5.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attack.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply, freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC, instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a FAST
+   factor.  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 5.
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 23]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [KRB-ANON] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+6.5.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors, and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.  If a FAST KDC receives an
+   unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
+
+   An armor type may be appropriate for use in armoring AS requests,
+   armoring TGS requests or both.  TGS armor types MUST authenticate the
+   client to to the KDC, typically by binding the TGT subsession key to
+   the armor key.  As discussed below, it is desirable for AS armor
+   types to authenticate the KDC to the client, but this is not
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 24]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   required.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a fast factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+6.5.1.1.  Ticket-based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+                   "subkeyarmor", "ticketarmor" )
+
+   The `ticket_session_key' is the session key from the ticket in the
+   ap-req.  The `subkey' is the ap-req subkey.  This construction
+   guarantees that both the KDC (through the session key) and the client
+   (through the subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC4120, but the KDC has an asymmetric signing key whose
+       binding with the expected KDC can be verified by the client, the
+       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
+       authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 25]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   If anonymous PKINIT is used to obtain the armor ticket, the KDC
+   cannot know whether its signing key can be verified by the client,
+   hence the KDC MUST be marked as unverified from the KDC's point of
+   view while the client could be able to authenticate the KDC by
+   verifying the KDC's signing key is bound with the expected KDC.  The
+   client needs to carefully consider the risk and benefit tradeoffs
+   associated with active attacks before exposing cipher text encrypted
+   using the user's long-term secrets when the armor does not
+   authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+   armor authorization data element.  These tickets and authenticators
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e. the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   Only implicit armors are allowed in the TGS at this time.
+
+6.5.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
+   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
+   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
+   error.  FAST is not expected to be used in an authentication set:
+   clients will typically use FAST padata if available and this decision
+   should not depend on what other pre-authentication methods are
+   available.  As such, no pa-hint is defined for FAST at this time.
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 26]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+       PA-FX-FAST                         136
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- For AS, contains the checksum performed over the type
+               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+               -- structure;
+               -- For TGS, contains the checksum performed over the type
+               -- AP-REQ in the PA-TGS-REQ padata.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          50
+       KEY_USAGE_FAST_ENC                 51
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD NOT include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 27]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in a
+      FX_FAST_ARMOR_AP_REQUEST armor.  Clients MAY present a non-TGT in
+      the PA-TGS-REQ authenticator and omit the armor field, in which
+      case the armor key is the same that would be computed if the
+      authenticator were used in a FX_FAST_ARMOR_AP_REQUEST armor.  This
+      is the only case where a ticket other than a TGT can be used to
+      establish an armor key; even though the armor key is computed the
+      same as a FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an
+      armor ticket in FX_FAST_ARMOR_AP_REQUEST.  Alternatively, a client
+      MAY use an armor type defined in the future for use with the TGS
+      request.
+
+   The req-checksum field contains a checksum computed differently for
+   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
+   BODY for the req-body field of the KDC-REQ structure of the
+   containing message; for an TGS-REQ, it is performed over the type AP-
+   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
+   the armor key, and the checksum type is the required checksum type
+   for the enctype of the armor key per [RFC3961].  This checksum MUST
+   be a keyed checksume and it is included in order to bind the FAST
+   padata to the outer request.  A KDC that implements FAST will ignore
+   the outer request, but including a checksum is relatively cheap and
+   may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+            -- kdc-follow-referrals(16)
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 28]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+     Bits    Name                    Description
+    -----------------------------------------------------------------
+     0     RESERVED              Reserved for future expansion of this
+                                 field.
+     1     hide-client-names     Requesting the KDC to hide client
+                                 names in the KDC response, as
+                                 described next in this section.
+     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in clear text, This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [KRB-ANON] in the KDC reply and the error
+      response.  Hence this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      The Kerberos client described in [RFC4120] has to request referral
+      TGTs along the authentication path in order to get a service
+      ticket for the target service.  The Kerberos client described in
+      the [REFERRALS] needs to contact the AS specified in the error
+      response in order to complete client referrals.  The kdc-follow-
+      referrals option is designed to minimize the number of messages
+      that need to be processed by the client.  This option is useful
+      when, for example, the client may contact the KDC via a satellite
+      link that has high network latency, or the client has limited
+      computational capabilities.  If the kdc-follow-referrals option is
+      set, the KDC MAY act as the client to follow TGS referrals
+      [REFERRALS], and return the service ticket to the named server
+      principal in the client request using the reply key expected by
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 29]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      the client.  That is, rather than returning a referral, the KDC
+      follows that referral by contacting a remote KDC and processing
+      the referral.  The kdc-referrals option can be implemented when
+      the KDC knows the reply key.  The KDC can ignore kdc-referrals
+      option when it does not understand it or it does not allow this
+      option based on local policy.  The client SHOULD be capable of
+      processing the KDC responses when this option is not honored by
+      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
+      is going to be used to avoid problems when the client's UDP
+      retransmit algorithm has timeouts insufficient to allow the KDC to
+      interact with remote KDCs.
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.  If the KDC
+   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+   the client MUST place any padata that is otherwise in the outer KDC
+   request body into this field.  In a TGS request, PA-TGS-REQ padata is
+   not included in this field and it is present in the outer KDC request
+   body.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
+   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
+   should checksum the KDC-REQ-BODY in the FAST structure.
+
+   In a TGS request, a client MAY include the AD-fx-fast-used authdata
+   either in the pa-tgs-req authenticator or in the authorization data
+   in the pa-tgs-req ticket.  If the KDC receives this authorization
+   data but does not find a FAST padata then it MUST return
+   KRB_APP_ERR_MODIFIED.
+
+6.5.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 6.5.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 30]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 52
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
+   KDC response MUST support a local policy that rejects the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+       KrbFastResponse ::= SEQUENCE {
+           padata         [0] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           strengthen-key [1] EncryptionKey OPTIONAL,
+               -- This, if present, strengthens the reply key for AS and
+               -- TGS. MUST be present for TGS.
+               -- MUST be absent in KRB-ERROR.
+           finished       [2] KrbFastFinished OPTIONAL,
+               -- Present in AS or TGS reply; absent otherwise.
+           nonce          [3] UInt32,
+               -- Nonce from the client request.
+           ...
+  }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata that is otherwise in the outer KDC-
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 31]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   REP structure into this field.  The padata field in the KDC reply
+   structure outside of the PA-FX-FAST-REPLY structure typically
+   includes only the PA-FX- FAST-REPLY padata.
+
+   The strengthen-key field provides a mechanism for the KDC to
+   strengthen the reply key.  If set, the reply key is strengthened
+   after all padata items are processed.  Let padata-reply-key be the
+   reply key after padata processing.
+
+   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
+                         "strengthenkey", "replykey")
+
+   The strengthen-key field MAY be set in an AS reply; it MUST be set in
+   a TGS reply; it must be absent in an error reply.  The strengthen key
+   is required in a TGS reply so that an attacker cannot remove the FAST
+   PADATA from a TGS reply, causing the KDC to appear not to support
+   FAST.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation.  This
+   field is present in an AS-REP or a TGS-REP when a ticket is returned,
+   and it is not present in an error reply.
+
+   The KrbFastFinished structure contains the following information:
+
+       KrbFastFinished ::= SEQUENCE {
+           timestamp       [0] KerberosTime,
+           usec            [1] Microseconds,
+               -- timestamp and usec represent the time on the KDC when
+               -- the reply was generated.
+           crealm          [2] Realm,
+           cname           [3] PrincipalName,
+               -- Contains the client realm and the client name.
+           ticket-checksum [4] Checksum,
+               -- checksum of the ticket in the KDC-REP  using the armor
+               -- and the key usage is KEY_USAGE_FAST_FINISH.
+               -- The checksum type is the required checksum type
+               -- of the armor key.
+           ...
+       }
+       KEY_USAGE_FAST_FINISHED            53
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding-identically-named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  Note that the KDC's time
+   in AS-REP may not match the authtime in the reply ticket if the kdc-
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 32]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   follow-referrals option is requested and honored by the KDC.  The
+   client need not confirm that the timestamp returned is within
+   allowable clock skew: the armor key guarantees that the reply is
+   fresh.  The client MAY trust the time stamp returned.
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The ticket-checksum is a checksum of the issued ticket.  The checksum
+   key is the armor key, and the checksum type is the required checksum
+   type of the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED.
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 6.3 MUST be included in the padata sequence in the
+   KrbFastResponse sequence if the KDC expects at least one more message
+   from the client in order to complete the authentication.
+
+   The nonce field in the KrbFastResponse contains the value of the
+   nonce field in the KDC-REQ of the corresponding client request and it
+   binds the KDC response with the client request.  The client MUST
+   verify that this nonce value in the reply matches with that of the
+   request and reject the KDC reply otherwise.  To prevent the response
+   from one message in a conversation from being replayed to a request
+   in another message, clients SHOULD use a new nonce for each message
+   in a conversation.
+
+6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        137
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 33]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  The client SHOULD however process the KDC
+   errors as the result of the KDC's inability to accept the AP_REQ
+   armor and potentially retry another request with a different armor
+   when applicable.  The Kerberos client MAY process an error message
+   without a PA-FX-FAST-REPLY, if that is only intended to return better
+   error information to the application, typically for trouble-shooting
+   purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, then that
+   information should be transmitted in a pa-data element within the
+   KRBFastResponse structure.  The padata-type is the same as the data-
+   type would be in the typed data element and the padata-value is the
+   same as the data-value.  As discussed in Section 8, data-types and
+   padata-types are drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+6.5.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
+   include additional pa-data, but the KDC MUST ignore the outer request
+   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
+   processed.  In the case of the TGS request, the outer request should
+   include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST should
+   be included in PA-FX-FAST.  The client MUST ignore other padata
+   outside of PA-FX-FAST.
+
+6.5.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   time stamp pre-authentication option described in [RFC4120].  The
+   word challenge is used instead of timestamp because while the
+   timestamp is used as an initial challenge, if the KDC and client do
+   not have synchronized time, then the KDC can provide updated time to
+   the client to use as a challenge.  The client encrypts a structure
+   containing a timestamp in the challenge key.  The challenge key used
+   by the client to send a message to the KDC is KRB-FX-
+   CF2(armor_key,long_term_key, "clientchallengearmor",
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 34]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE.  The
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          138
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
+      KEY_USAGE_ENC_CHALLENGE_KDC     55
+
+   The client includes some time stamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key.  Clients MAY use
+   the current time; doing so prevents the exposure where an attacker
+   can cause a client to appear to authenticate in the future.  The
+   client sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the time stamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to re-use time stamps avoids requiring that clients maintain
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 35]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   state about which time stamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST strengthen the reply key
+   before issuing a ticket.  The client MUST check that the timestamp
+   decrypts properly.  The client MAY check that the timestamp is within
+   the window of acceptable clock skew for the client.  The client MUST
+   NOT require that the timestamp be identical to the timestamp in the
+   issued credentials or the returned message.
+
+   The encrypted challenge FAST factor provides the following
+   facilities: client-authentication and KDC authentication.  This FAST
+   factor also takes advantage of the FAST facility to strengthen the
+   reply key.  It does not provide the replacing-reply-key facility.
+   The security considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+   authentication set.  No pa-hint is defined because the only
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+6.6.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         70
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 6.4.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 36]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   element.
+
+   The AD-authentication-strength element MUST be included in the AD-IF-
+   RELEVANT, thus it can be ignored if it is unknown to the receiver.
+
+
+7.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 8 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+7.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                 90
+           KDC_ERR_MORE_PREAUTH_DATA_REQUIRED      91
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
+           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+7.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM               50
+           KEY_USAGE_FAST_ENC                      51
+           KEY_USAGE_FAST_REP                      52
+           KEY_USAGE_FAST_FINISHED                 53
+           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
+           KEY_USAGE_ENC_CHALLENGE_KDC             55
+
+7.3.  Authorization Data Elements
+
+           AD-authentication-strength              70
+           AD-fx-fast-armor                        71
+           AD-fx-fast-used                         72
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 37]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+7.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                            133
+           PA-AUTHENTICATION-SET                   134
+           PA-AUTH-SET-SELECTED                    135
+           PA-FX-FAST                              136
+           PA-FX-ERROR                             137
+           PA-ENCRYPTED-CHALLENGE                  138
+
+
+8.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   should all be located under
+   http://www.iana.org/assignments/kerberos-parameters.
+
+8.1.  Pre-authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registration
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 38]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   standards track RFCs.  A concern that a particular method needs to be
+   a standards track RFC may be raised as an objection during IETF
+   review.
+
+      Type                Value    Reference
+  ----------------------------------------------------------------------
+  PA-TGS-REQ                 1    RFC 4120
+  PA-ENC-TIMESTAMP           2    RFC 4120
+  PA-PW-SALT                 3    RFC 4120
+  [reserved]                 4
+  PA-ENC-UNIX-TIME           5    (deprecated)
+  PA-SANDIA-SECUREID         6
+  PA-SESAME                  7
+  PA-OSF-DCE                 8
+  PA-CYBERSAFE-SECUREID      9
+  PA-AFS3-SALT               10
+  PA-ETYPE-INFO              11   RFC 4120
+  PA-SAM-CHALLENGE           12   (sam/otp)
+  PA-SAM-RESPONSE            13   (sam/otp)
+  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
+  PA-PK-AS-REQ               16   RFC 4556
+  PA-PK-AS-REP               17   RFC 4556
+  PA-PK-OCSP-RESPONSE        18   RFC 4557
+  PA-ETYPE-INFO2             19   RFC 4120
+  PA-USE-SPECIFIED-KVNO      20
+  PA-SVR-REFERRAL-INFO       20   (referrals)
+  PA-SAM-REDIRECT            21   (sam/otp)
+  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
+  TD-PADATA                  22   (embeds padata)
+  PA-SAM-ETYPE-INFO          23   (sam/otp)
+  PA-ALT-PRINC               24   (crawdad@fnal.gov)
+  PA-SERVER-REFERRAL         25   (referrals)
+  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
+  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
+  PA-EXTRA-TGT               41   Reserved extra TGT
+  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+  TD-KRB-PRINCIPAL           102  PrincipalName
+  TD-KRB-REALM               103  Realm
+  TD-TRUSTED-CERTIFIERS      104  PKINIT
+  TD-CERTIFICATE-INDEX       105  PKINIT
+  TD-APP-DEFINED-ERROR       106  Application specific
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 39]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+  TD-REQ-NONCE               107  INTEGER
+  TD-REQ-SEQ                 108  INTEGER
+  PA-PAC-REQUEST             128  MS-KILE
+  PA-FOR_USER                129  MS-KILE
+  PA-FOR-X509-USER           130  MS-KILE
+  PA-FOR-CHECK_DUPS          131  MS-KILE
+  PA-AS-CHECKSUM             132  MS-KILE
+  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
+  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
+  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
+  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
+  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
+  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
+  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
+  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
+  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
+  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
+  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
+  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
+  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
+  PA_PKU2U_NAME              148  draft-zhu-pku2u
+  PA-SUPPORTED-ETYPES        165  MS-KILE
+  PA-EXTENDED_ERROR          166  MS-KILE
+
+8.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+8.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 40]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in the KDC response
+      16    kdc-follow-referrals   Requesting the KDC to follow
+                                   referrals
+
+
+9.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denial of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   Regarding to the facilities provided by the Encrypted Challenge FAST
+   factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: client-
+   authentication and KDC-authentication.  There is no un-authenticated
+   clear text introduced by the Encrypted Challenge FAST factor.
+
+   FAST provides an encrypted tunnel over which pre-authentication
+   conversations can take place.  In addition, FAST optionally
+   authenticates the KDC to the client.  It is the responsibility of
+   FAST factors to authenticate the client to the KDC.  Care MUST be
+   taken to design FAST factors such that they are bound to the
+   conversation.  If this is not done, a man-in-the-middle may be able
+   to cut&paste a fast factor from one conversation to another.  The
+   easiest way to do this is to bind each fast factor to the armor key
+   which is guaranteed to be unique for each conversation.
+
+   The anonymous pkinit mode for obtaining an armor ticket does not
+   always authenticate the KDC to the client before the conversation
+   begins.  Tracking the KDC verified state guarantees that by the end
+   of the conversation, the client has authenticated the KDC.  However
+   fast factor designers need to consider the implications of using
+   their factor when the KDC has not yet been authenticated.  If this
+   proves problematic in an environment, then the particular fast factor
+   should not be used with anonymous PKINIT.
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 41]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   Existing pre-authentication mechanisms are believed to be at least as
+   secure when used with FAST as they are when used outside of FAST.
+   One part of this security is making sure that when pre-authentication
+   methods checksum the request, they checksum the inner request rather
+   than the outer request.  If the mechanism checksummed the outer
+   request, a man-in-the-middle could observe it outside a FAST tunnel
+   and then cut&paste it into a FAST exchange where the inner rather
+   than outer request would be used to select attributes of the issued
+   ticket.  Such attacks would typically invalidate auditing information
+   or create a situation where the client and KDC disagree about what
+   ticket is issued.  However, such attacks are unlikely to allow an
+   attacker who would not be able to authenticate as a principal to do
+   so.  Even so, FAST is believed to defend against these attacks in
+   existing legacy mechanism.  However since there is no standard for
+   how legacy mechanisms bind the request to the pre-authentication or
+   provide integrity protection, security analysis can be difficult.  In
+   some cases FAST may significantly improve the integrity protection of
+   legacy mechanisms.
+
+   The security of the TGS exchange depends on authenticating the client
+   to the KDC.  In the AS exchange, this is done using pre-
+   authentication data or FAST factors.  In the TGS exchange, this is
+   done by presenting a TGT and by using the session (or sub-session)
+   key in constructing the request.  Because FAST uses a request body in
+   the inner request, encrypted in the armor key, rather than the
+   request body in the outer request, it is critical that establishing
+   the armor key be tied to the authentication of the client to the KDC.
+   If this is not done, an attacker could manipulate the options
+   requested in the TGS request, for example requesting a ticket with
+   different validity or addresses.  The easiest way to bind the armor
+   key to the authentication of the client to the KDC is for the armor
+   key to depend on the sub-session key of the TGT.  This is done with
+   the implicit TGS armor supported by this specification.  Future armor
+   types designed for use with the TGS MUST either bind their armor keys
+   to the TGT or provide another mechanism to authenticate the client to
+   the KDC.
+
+
+10.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [ID.CROSS].
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 42]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+   Joel Webber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+   Srinivas Cheruku and Greg Hudson provided valuable review comments.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+11.2.  Informative References
+
+   [EKE]      Bellovin, S. and M. Merritt, "Augmented Encrypted Key
+              Exchange: A Password-Based Protocol Secure Against
+              Dictionary Attacks and Password File Compromise,
+              Proceedings of the 1st ACM Conference on Computer and
+              Communications Security, ACM Press.", November 1993.
+
+   [ID.CROSS]
+              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+              Statement on the Operation of Kerberos in a Specific
+              System", draft-sakane-krb-cross-problem-statement-02.txt
+              (work in progress), April 2007.
+
+   [IEEE1363.2]
+              IEEE, "IEEE P1363.2: Password-Based Public-Key
+              Cryptography", 2004.
+
+   [KRB-WG.SAM]
+              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 43]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
+              progress), October 2003.
+
+   [REFERRALS]
+              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
+              Locate Kerberos Realms",
+              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
+              progress), 2007.
+
+
+Appendix A.  Test Vectors for KRB-FX-CF2
+
+   This informative appendix presents test vectors for the KRB-FX-CF2
+   function.  Test vectors are presented for several encryption types.
+   In all cases the first key (k1) is the result of string-to-
+   key("key1", "key1", default_parameters) and the second key (k2) is
+   the result of string-to-key("key2", "key2", default_parameters).
+   Both keys are of the same enctype.  The presented test vector is the
+   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
+   "b").  The peppers are one-octet ASCII strings.
+
+   In performing interoperability testing, there was significant
+   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
+   vectors assume that the AES pseudo-random operation is aes-
+   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
+   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
+   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
+   assumed to be des-cbc(md5(input)).  As specified in RFC 4757, the RC4
+   pseudo-random operation is hmac-sha1(input).
+
+   Interoperability testing also demonstrated ambiguity surrounding the
+   DES random-to-key operation.  The random-to-key operation is assumed
+   to be distribute 56 bits into high-7-bits of 8 octets and generate
+   parity.
+
+   These test vectors were produced with revision 22359 of the MIT
+   Kerberos sources.  The AES 256 and AES 128 test vectors have been
+   confirmed by multiple other implementors.  The RC4 test vectors have
+   been confirmed by one other implementor.  The DES and triple DES test
+   vectors have not been confirmed.
+
+
+   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
+   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
+                        b9617ae3a96868c337cb93b5e72b1c7b
+   DES (enctype 1): 43bae3738c9467e6
+   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
+   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 44]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+Appendix B.  Change History
+
+   RFC editor, please remove this section before publication.
+
+B.1.  Changes since 13
+
+      Restore DES test vectors; their removal was not mentioned in 13.
+      Clarify that only implicit TGS armor is defined at this time.  In
+      the future we may define explicit TGS armor.
+
+B.2.  Changes since 12
+
+      Per comment from Greg Hudson, KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
+      instead of KDC_ERR_MORE_PREAUTH_DATA_NEEDED
+      Use pa-authentication-set-selected not pa-auth-set-selected
+      Update discussion of KDC verification (Love)
+      Remove explicit TGS armor, note that TGS armor must authenticate
+      the client to the KDC, describe in security considerations.
+
+B.3.  Changes since 11
+
+      Checksum the inner request body in methods like PKINIT, not the
+      outer request body.  Per mailing list discussion, this change
+      addresses a potential security weakness.
+      Add additional security considerations text
+
+B.4.  Changes since 10
+
+      The checksum member of the KrbFastFinished sequence has been
+      removed.  A nonce field has been added to KrbFastResponse.
+      The cookie no longer needs to be outside of FAST.  In fact, some
+      security guarantees depend on the cookie being inside FAST now
+      that the finish checksum has been removed.  Affected that change.
+      Replace the rep-key field in KrbFastResponse with the strengthen-
+      key field.  Per mailing list discussion, there are security
+      advantages to strengthening the reply key.
+      Clarify handling of authentication sets.
+      Include the AD-fx-fast-used authorization data type.
+      Include note about random nonces.
+
+B.5.  Changes since 09
+
+      Clarify conversations by defining for TGS and by describing how
+      cookies form conversation boundaries.
+      Simplify text surrounding when finish is included: always for AS
+      and TGS reply, never for error.
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 45]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      Fill in IANA and constants
+
+B.6.  Changes since 08
+
+      Fix a number of typos
+      Rename anonymous flag to hide-client-name; rename kdc-referals to
+      kdc-follow-referrals
+      Clarify how anonymous pkinit interacts with KDC verified.
+      Introduce AD-fx-fast-armor authorization data to deal with
+      unprivileged processes constructing KDC requests.  Note that a TGT
+      is always used for armor tickets if the armor field is present; if
+      you proxy or validate you'll end up with a TGT armor ticket and
+      another ticket in the pa-tgs-req.  Alternatively you can simply
+      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
+      All KDCs in a realm MUST support FAST if it is to be offered.
+      The cookie message is always generated by the KDC.
+      Note that the client can trust and need not verify the time stamp
+      in the finish message.  This can seed the client's idea of KDC
+      time.
+      Note that the client name in the finish message may differ from
+      the name in the request if referrals are used.
+      Note that KDCs should advertize fast in preauth_required errors.
+      Armor key is constructed using KRB-FX-CF2.  This is true even in
+      the TGS case; there is no security reason to do this.  Using the
+      subkey as done in draft 08 would be fine, but the current text
+      uses the same procedure both in the TGS and AS case.
+      Use a different challenge key in each direction in the encrypted
+      challenge option.
+      Note that the KDC should process PA-FX-COOKIE before other padata.
+      KRB-FX-CF2 uses k1's enctype for the result; change around calling
+      order so we pass in subkeys and armor keys as k1 in preference to
+      long-term keys or ticket session keys.
+      Clarify the relationship between authentication sets and cookies.
+      A cookie may not be needed in the first message.  Clarify how this
+      interacts with optimistic clients.
+      Remove text raising a concern that RFC 3961 may permit ciphertext
+      transformations that do not change plaintext: discussion on the
+      list came to the conclusion that RFC 3961 does not permit this.
+      Remove binding key concept; use the armor key instead.  The cookie
+      becomes just an octet string.
+      Include PA-FX-ERROR to protect the error information per Dublin.
+      Returning preauth_failed in the failed to decrypt encrypted
+      challenge seems fine; remove the issue marker
+      Add a section describing what goes in the inner and outer request.
+      I believe it is redundant but found it useful while putting
+      together an implementation proposal.
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 46]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      Use hyphen rather than underscore in the constants for pre-
+      authentication data to be consistent with RFC 4120.
+      Add a ticket-checksum to the finished message
+      Remove redundant KEY_USAGE_FAST_ARMOR.
+      Add protocol constants section for non-IANA registrations and
+      flesh out IANA section.
+      Clarify that kdc-req-body checksums should always use the outer
+      body even for mechanisms like PKINIT that include their own (now
+      redundant) checksum.
+      Remove mechanism for encapsulating typed data in padata; just
+      reflect the value.
+
+B.7.  Changes since 07
+
+      Propose replacement of authenticated timestamp with encrypted
+      challenge.  The desire to avoid clients needing time
+      synchronization and to simply the factor.
+      Add a requirement that any FAST armor scheme must provide a fresh
+      key for each conversation.  This allows us to assume that anything
+      encrypted/integrity protected in the right key is fresh and not
+      subject to cross-conversation cut and paste.
+      Removed heartbeat padata.  The KDC will double up messages if it
+      needs to; the client simply sends its message and waits for the
+      next response.
+      Define PA-auth-SET-SELECTED
+      Clarify a KDC cannot ignore padata is has claimed to support
+
+B.8.  Changes since 06
+
+      Note that even for replace reply key it is likely that the side
+      using the mechanism will know that the other side supports it.
+      Since it is reasonably unlikely we'll need a container mechanism
+      other than FAST itself, we don't need to optimize for that case.
+      So, we want to optimize for implementation simplicity.  Thus if
+      you do have such a container mechanism interacting with
+      authentication sets we'll assume that the hint need to describe
+      hints for all contained mechanisms.  This closes out a long-
+      standing issue.
+      Write up what Sam believes is the consensus on UI and prompts in
+      the authentication set: clients MAY assume that they have all the
+      UI information they need.
+
+
+Appendix C.  ASN.1 module
+
+      KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 47]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+           Microseconds, KerberosFlags
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+                  -- as defined in RFC 4120.
+
+
+      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+          pa-type      [0] Int32,
+              -- same as padata-type.
+          pa-hint      [1] OCTET STRING OPTIONAL,
+          pa-value     [2] OCTET STRING OPTIONAL,
+          ...
+      }
+
+      KrbFastArmor ::= SEQUENCE {
+          armor-type   [0] Int32,
+              -- Type of the armor.
+          armor-value  [1] OCTET STRING,
+              -- Value of the armor.
+          ...
+      }
+
+      PA-FX-FAST-REQUEST ::= CHOICE {
+          armored-data [0] KrbFastArmoredReq,
+          ...
+      }
+
+      KrbFastArmoredReq ::= SEQUENCE {
+          armor        [0] KrbFastArmor OPTIONAL,
+              -- Contains the armor that identifies the armor key.
+              -- MUST be present in AS-REQ.
+          req-checksum [1] Checksum,
+              -- For AS, contains the checksum performed over the type
+              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+              -- structure;
+              -- For TGS, contains the checksum performed over the type
+              -- AP-REQ in the PA-TGS-REQ padata.
+              -- The checksum key is the armor key, the checksum
+              -- type is the required checksum type for the enctype of
+              -- the armor key, and the key usage number is
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 48]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+              -- KEY_USAGE_FAST_REQ_CHKSUM.
+          enc-fast-req [2] EncryptedData, -- KrbFastReq --
+              -- The encryption key is the armor key, and the key usage
+              -- number is KEY_USAGE_FAST_ENC.
+          ...
+      }
+
+      KrbFastReq ::= SEQUENCE {
+          fast-options [0] FastOptions,
+              -- Additional options.
+          padata       [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          req-body     [2] KDC-REQ-BODY,
+              -- Contains the KDC request body as defined in Section
+              -- 5.4.1 of [RFC4120].
+              -- This req-body field is preferred over the outer field
+              -- in the KDC request.
+           ...
+      }
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- hide-client-names(1),
+          -- kdc-follow-referrals(16)
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+
+      KrbFastResponse ::= SEQUENCE {
+          padata         [0] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          strengthen-key [1] EncryptionKey OPTIONAL,
+              -- This, if present, strengthens the reply key for AS and
+              -- TGS.  MUST be present for TGS
+              -- MUST be absent in KRB-ERROR.
+          finished       [2] KrbFastFinished OPTIONAL,
+              -- Present in AS or TGS reply; absent otherwise.
+          nonce          [3] UInt32,
+              -- Nonce from the client request.
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 49]
+
+Internet-Draft         Kerberos Preauth Framework            August 2009
+
+
+          ...
+      }
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp       [0] KerberosTime,
+          usec            [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm          [2] Realm,
+          cname           [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          ticket-checksum [4] Checksum,
+              -- checksum of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+      END
+
+
+Authors' Addresses
+
+   Sam hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu           Expires February 13, 2010              [Page 50]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt
new file mode 100644
index 00000000000..036c6750607
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt
@@ -0,0 +1,6049 @@
+
+
+INTERNET-DRAFT                                                    Tom Yu
+draft-ietf-krb-wg-rfc1510ter-00.txt                                  MIT
+Expires: 25 July 2005                                    21 January 2005
+
+        The Kerberos Network Authentication Service (Version 5)
+
+Status of This Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   or will be disclosed, and any of which I become aware will be
+   disclosed, in accordance with RFC 3668.
+
+   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
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes version 5 of the Kerberos network
+   authentication protocol.  It describes a framework to allow for
+   extensions to be made to the protocol without creating
+   interoperability problems.
+
+Key Words for Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in RFC 2119.
+
+
+
+
+Yu                         Expires: Jul 2005                    [Page 1]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+Table of Contents
+
+   Status of This Memo ..............................................  1
+   Copyright Notice .................................................  1
+   Abstract .........................................................  1
+   Key Words for Requirements .......................................  1
+   Table of Contents ................................................  2
+   1.  Introduction .................................................  5
+   1.1.  Kerberos Protocol Overview .................................  5
+   1.2.  Document Organization ......................................  6
+   2.  Compatibility Considerations .................................  6
+   2.1.  Extensibility ..............................................  7
+   2.2.  Compatibility with RFC 1510 ................................  7
+   2.3.  Backwards Compatibility ....................................  7
+   2.4.  1.4.2. Sending Extensible Messages .........................  8
+   2.5.  Criticality ................................................  8
+   2.6.  Authenticating Cleartext Portions of Messages ..............  9
+   2.7.  Capability Negotiation ..................................... 10
+   3.  Use of ASN.1 in Kerberos ..................................... 10
+   3.1.  Module Header .............................................. 11
+   3.2.  Top-Level Type ............................................. 11
+   3.3.  Previously Unused ASN.1 Notation (informative) ............. 12
+   3.3.1.  Parameterized Types ...................................... 12
+   3.3.2.  COMPONENTS OF Notation ................................... 12
+   3.3.3.  Constraints .............................................. 12
+   3.4.  New Types .................................................. 13
+   4.  Basic Types .................................................. 14
+   4.1.  Constrained Integer Types .................................. 14
+   4.2.  KerberosTime ............................................... 15
+   4.3.  KerberosString ............................................. 15
+   4.4.  Language Tags .............................................. 16
+   4.5.  KerberosFlags .............................................. 16
+   4.6.  Typed Holes ................................................ 16
+   4.7.  HostAddress and HostAddresses .............................. 17
+   4.7.1.  Internet (IPv4) Addresses ................................ 17
+   4.7.2.  Internet (IPv6) Addresses ................................ 17
+   4.7.3.  DECnet Phase IV addresses ................................ 18
+   4.7.4.  Netbios addresses ........................................ 18
+   4.7.5.  Directional Addresses .................................... 18
+   5.  Principals ................................................... 19
+   5.1.  Name Types ................................................. 19
+   5.2.  Principal Type Definition .................................. 19
+   5.3.  Principal Name Reuse ....................................... 20
+   5.4.  Realm Names ................................................ 20
+   5.5.  Printable Representations of Principal Names ............... 21
+   5.6.  Ticket-Granting Service Principal .......................... 21
+   5.6.1.  Cross-Realm TGS Principals ............................... 21
+   6.  Types Relating to Encryption ................................. 21
+   6.1.  Assigned Numbers for Encryption ............................ 22
+   6.1.1.  EType .................................................... 22
+   6.1.2.  Key Usages ............................................... 22
+
+Yu                         Expires: Jul 2005                    [Page 2]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   6.2.  Which Key to Use ........................................... 23
+   6.3.  EncryptionKey .............................................. 24
+   6.4.  EncryptedData .............................................. 24
+   6.5.  Checksums .................................................. 25
+   6.5.1.  ChecksumOf ............................................... 26
+   6.5.2.  Signed ................................................... 27
+   7.  Tickets ...................................................... 27
+   7.1.  Timestamps ................................................. 28
+   7.2.  Ticket Flags ............................................... 28
+   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 29
+   7.2.2.  Invalid Tickets .......................................... 29
+   7.2.3.  OK as Delegate ........................................... 30
+   7.2.4.  Renewable Tickets ........................................ 30
+   7.2.5.  Postdated Tickets ........................................ 31
+   7.2.6.  Proxiable and Proxy Tickets .............................. 32
+   7.2.7.  Forwarded and Forwardable Tickets ........................ 33
+   7.3.  Transited Realms ........................................... 34
+   7.4.  Authorization Data ......................................... 34
+   7.4.1.  AD-IF-RELEVANT ........................................... 35
+   7.4.2.  AD-KDCIssued ............................................. 35
+   7.4.3.  AD-AND-OR ................................................ 37
+   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 37
+   7.5.  Encrypted Part of Ticket ................................... 37
+   7.6.  Cleartext Part of Ticket ................................... 38
+   8.  Credential Acquisition ....................................... 40
+   8.1.  KDC-REQ .................................................... 40
+   8.2.  PA-DATA .................................................... 46
+   8.3.  KDC-REQ Processing ......................................... 46
+   8.3.1.  Handling Replays ......................................... 46
+   8.3.2.  Request Validation ....................................... 47
+   8.3.2.1.  AS-REQ Authentication .................................. 47
+   8.3.2.2.  TGS-REQ Authentication ................................. 47
+   8.3.2.3.  Principal Validation ................................... 47
+   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 48
+   8.3.3.  Timestamp Handling ....................................... 48
+   8.3.3.1.  AS-REQ Timestamp Processing ............................ 49
+   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 49
+   8.3.4.  Handling Transited Realms ................................ 50
+   8.3.5.  Address Processing ....................................... 50
+   8.3.6.  Ticket Flag Processing ................................... 51
+   8.3.7.  Key Selection ............................................ 52
+   8.3.7.1.  Reply Key and Session Key Selection .................... 52
+   8.3.7.2.  Ticket Key Selection ................................... 52
+   8.4.  KDC-REP .................................................... 52
+   8.5.  Reply Validation ........................................... 55
+   8.6.  IP Transports .............................................. 55
+   8.6.1.  UDP/IP transport ......................................... 55
+   8.6.2.  TCP/IP transport ......................................... 56
+   8.6.3.  KDC Discovery on IP Networks ............................. 57
+   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
+   8.6.3.2.  DNS SRV records for KDC location ....................... 58
+
+Yu                         Expires: Jul 2005                    [Page 3]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
+                Networks ............................................ 58
+   9.  Errors ....................................................... 58
+   10.  Session Key Exchange ........................................ 61
+   10.1.  AP-REQ .................................................... 61
+   10.2.  AP-REP .................................................... 63
+   11.  Session Key Use ............................................. 65
+   11.1.  KRB-SAFE .................................................. 65
+   11.2.  KRB-PRIV .................................................. 65
+   11.3.  KRB-CRED .................................................. 66
+   12.  Security Considerations ..................................... 67
+   12.1.  Time Synchronization ...................................... 67
+   12.2.  Replays ................................................... 67
+   12.3.  Principal Name Reuse ...................................... 67
+   12.4.  Password Guessing ......................................... 67
+   12.5.  Forward Secrecy ........................................... 67
+   12.6.  Authorization ............................................. 68
+   12.7.  Login Authentication ...................................... 68
+   13.  IANA Considerations ......................................... 68
+   14.  Acknowledgments ............................................. 69
+   Appendices ....................................................... 69
+   A.  ASN.1 Module (Normative) ..................................... 69
+   B.  Kerberos and Character Encodings (Informative) ...............103
+   C.  Kerberos History (Informative) ...............................104
+   D.  Notational Differences from [KCLAR] ..........................105
+   Normative References .............................................106
+   Informative References ...........................................106
+   Author's Address .................................................108
+   Full Copyright Statement .........................................108
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                    [Page 4]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+1.  Introduction
+
+   The Kerberos network authentication protocol is a trusted-third-party
+   protocol utilizing symmetric-key cryptography.  It assumes that all
+   communications between parties in the protocol may be arbitrarily
+   tampered with or monitored, and that the security of the overall
+   system depends only on the effectiveness of the cryptographic
+   techniques and the secrecy of the cryptographic keys used.  The
+   Kerberos protocol authenticates an application client's identity to
+   an application server, and likewise authenticates the application
+   server's identity to the application client.  These assurances are
+   made possible by the client and the server sharing secrets with the
+   trusted third party: the Kerberos server, also known as the Key
+   Distribution Center (KDC).  In addition, the protocol establishes an
+   ephemeral shared secret (the session key) between the client and the
+   server, allowing the protection of further communications between
+   them.
+
+   The Kerberos protocol, as originally specified, provides insufficient
+   means for extending the protocol in a backwards-compatible way.  This
+   deficiency has caused problems for interoperability.  This document
+   describes a framework which enables backwards-compatible extensions
+   to the Kerberos protocol.
+
+1.1.  Kerberos Protocol Overview
+
+   Kerberos comprises three main sub-protocols: credentials acquisition,
+   session key exchange, and session key usage.  A client acquires
+   credentials by asking the KDC for a credential for a service; the KDC
+   issues the credential, which contains a ticket and a session key.
+   The ticket, containing the client's identity, timestamps, expiration
+   time, and a session key, is a encrypted in a key known to the
+   application server.  The KDC encrypts the credential using a key
+   known to the client, and transmits the credential to the client.
+
+   There are two means of requesting credentials: the Authentication
+   Service (AS) exchange, and the Ticket-Granting Service (TGS)
+   exchange.  In the typical AS exchange, a client uses a password-
+   derived key to decrypt the response.  In the TGS exchange, the KDC
+   behaves as an application server; the client authenticates to the TGS
+   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
+   the TGT by using the AS exchange.
+
+   Session key exchange consists of the client transmitting the ticket
+   to the application server, accompanied by an authenticator.  The
+   authenticator contains a timestamp and additional data encrypted
+   using the ticket's session key.  The application server decrypts the
+   ticket, extracting the session key.  The application server then uses
+   the session key to decrypt the authenticator.  Upon successful
+   decryption of the authenticator, the application server knows that
+   the data in the authenticator were sent by the client named in the
+
+Yu                         Expires: Jul 2005                    [Page 5]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   associated ticket.  Additionally, since authenticators expire more
+   quickly than tickets, the application server has some assurance that
+   the transaction is not a replay.  The application server may send an
+   encrypted acknowledgment to the client, verifying its identity to the
+   client.
+
+   Once session key exchange has occurred, the client and server may use
+   the established session key to protect further traffic.  This
+   protection may consist of protection of integrity only, or of
+   protection of confidentiality and integrity.  Additional measures
+   exist for a client to securely forward credentials to a server.
+
+   The entire scheme depends on loosely synchronized clocks.
+   Synchronization of the clock on the KDC with the application server
+   clock allows the application server to accurately determine whether a
+   credential is expired.  Likewise, synchronization of the clock on the
+   client with the application server clock prevents replay attacks
+   utilizing the same credential.  Careful design of the application
+   protocol may allow replay prevention without requiring client-server
+   clock synchronization.
+
+   After establishing a session key, application client and the
+   application server can exchange Kerberos protocol messages that use
+   the session key to protect the integrity or confidentiality of
+   communications between the client and the server.  Additionally, the
+   client may forward credentials to the application server.
+
+   The credentials acquisition protocol takes place over specific,
+   defined transports (UDP and TCP).  Application protocols define which
+   transport to use for the session key establishment protocol and for
+   messages using the session key; the application may choose to perform
+   its own encapsulation of the Kerberos messages, for example.
+
+1.2.  Document Organization
+
+   The remainder of this document begins by describing the general
+   frameworks for protocol extensibility, including whether to interpret
+   unknown extensions as critical.  It then defines the protocol
+   messages and exchanges.
+
+   The definition of the Kerberos protocol uses Abstract Syntax Notation
+   One (ASN.1) [X680], which specifies notation for describing the
+   abstract content of protocol messages.  This document defines a
+   number of base types using ASN.1; these base types subsequently
+   appear in multiple types which define actual protocol messages.
+   Definitions of principal names and of tickets, which are central to
+   the protocol, also appear preceding the protocol message definitions.
+
+
+
+
+
+Yu                         Expires: Jul 2005                    [Page 6]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+2.  Compatibility Considerations
+
+2.1.  Extensibility
+
+   In the past, significant interoperability problems have resulted from
+   conflicting assumptions about how the Kerberos protocol can be
+   extended.  As the deployed base of Kerberos grows, the ability to
+   extend the Kerberos protocol becomes more important.  In order to
+   ensure that vendors and the IETF can extend the protocol while
+   maintaining backwards compatibility, this document outlines a
+   framework for extending Kerberos.
+
+   Kerberos provides two general mechanisms for protocol extensibility.
+   Many protocol messages, including some defined in RFC 1510, contain
+   typed holes--sub-messages containing an octet string along with an
+   integer that identifies how to interpret the octet string.  The
+   integer identifiers are registered centrally, but can be used both
+   for vendor extensions and for extensions standardized in the IETF.
+   This document adds typed holes to a number of messages which
+   previously lacked typed holes.
+
+   Many new messages defined in this document also contain ASN.1
+   extension markers.  These markers allow future revisions of this
+   document to add additional elements to messages, for cases where
+   typed holes are inadequate for some reason.  Because tag numbers and
+   position in a sequence need to be coordinated in order to maintain
+   interoperability, implementations MUST NOT include ASN.1 extensions
+   except when those extensions are specified by IETF standards-track
+   documents.
+
+2.2.  Compatibility with RFC 1510
+
+   Implementations of RFC 1510 did not use extensible ASN.1 types.
+   Sending additional fields not in RFC 1510 to these implementations
+   results in undefined behavior.  Examples of this behavior are known
+   to include discarding messages with no error indications.
+
+   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
+   are used; one alternative of the CHOICE provides a message which is
+   wire-encoding compatible with RFC 1510, and the other alternative
+   provides the new, extensible message.
+
+   Implementations sending new messages MUST ensure that the recipient
+   supports these new messages.  Along with each extensible message is a
+   guideline for when that message MAY be used.  IF that guideline is
+   followed, then the recipient is guaranteed to understand the message.
+
+2.3.  Backwards Compatibility
+
+   This document describes two sets (for the most part) of ASN.1 types.
+   The first set of types is wire-encoding compatible with RFC 1510 and
+
+Yu                         Expires: Jul 2005                    [Page 7]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   [KCLAR].  The second set of types is the set of types enabling
+   extensibility.  This second set may be referred to as
+   "extensibility-enabled types". [ need to make this consistent
+   throughout? ]
+
+   A major difference between the new extensibility-enabled types and
+   the types for RFC 1510 compatibility is that the extensibility-
+   enabled types allow for the use of UTF-8 encodings in various
+   character strings in the protocol.  Each party in the protocol must
+   have some knowledge of the capabilities of the other parties in the
+   protocol.  There are methods for establishing this knowledge without
+   necessarily requiring explicit configuration.
+
+   An extensibility-enabled client can detect whether a KDC supports the
+   extensibility-enabled types by requesting an extensibility-enabled
+   reply.  If the KDC replies with an extensibility-enabled reply, the
+   client knows that the KDC supports extensibility.  If the KDC issues
+   an extensibility-enabled ticket, the client knows that the service
+   named in the ticket is extensibility-enabled.
+
+2.4.  1.4.2. Sending Extensible Messages
+
+   Care must be taken to make sure that old implementations can
+   understand messages sent to them even if they do not understand an
+   extension that is used.  Unless the sender knows the extension is
+   supported, the extension cannot change the semantics of the core
+   message or previously defined extensions.
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence.  The KDC should
+   only use the extension if this padata element is present in the AS-
+   REQ.  Even if policy requires the use of the extension, it is better
+   to return an error indicating that the extension is required than to
+   use the extension when the recipient may not support it; debugging
+   why implementations do not interoperate is easier when errors are
+   returned.
+
+2.5.  Criticality
+
+   Recipients of unknown message extensions (including typed holes, new
+   flags, and ASN.1 extension elements) should preserve the encoding of
+   the extension but otherwise ignore the presence of the extension;
+   i.e., unknown extensions SHOULD be treated as non-critical.  If a
+   copy of the message is used later--for example, when a Ticket
+   received in a KDC-REP is later used in an AP-REQ--then the unknown
+
+Yu                         Expires: Jul 2005                    [Page 8]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   extensions MUST be included.
+
+   An implementation SHOULD NOT reject a request merely because it does
+   not understand some element of the request.  As a related
+   consequence, implementations SHOULD handle communicating with other
+   implementations which do not implement some requested options.  This
+   may require designers of options to provide means to determine
+   whether an option has been rejected, not understood, or (perhaps
+   maliciously) deleted or modified in transit.
+
+   There is one exception to non-criticality described above: if an
+   unknown authorization data element is received by a server either in
+   an AP-REQ or in a Ticket contained in an AP-REQ, then the
+   authentication SHOULD fail.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether the restriction applies to that service then a security
+   weakness may result if authentication succeeds.  Authorization
+   elements meant to be truly optional can be enclosed in the AD-IF-
+   RELEVANT element.
+
+   Many RFC 1510 implementations ignore unknown authorization data
+   elements.  Depending on these implementations to honor authorization
+   data restrictions may create a security weakness.
+
+2.6.  Authenticating Cleartext Portions of Messages
+
+   Various denial of service attacks and downgrade attacks against
+   Kerberos are possible unless plaintexts are somehow protected against
+   modification.  An early design goal of Kerberos Version 5 was to
+   avoid encrypting more of the authentication exchange that was
+   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
+   in a KDC reply, for example.)  This minimization of encryption
+   reduces the load on the KDC and busy servers.  Also, during the
+   initial design of Version 5, the existence of legal restrictions on
+   the export of cryptography made it desirable to minimize of the
+   number of uses of encryption in the protocol.  Unfortunately,
+   performing this minimization created numerous instances of
+   unauthenticated security-relevant plaintext fields.
+
+   The extensible variants of the messages described in this document
+   wrap the actual message in an ASN.1 sequence containing a keyed
+   checksum of the contents of the message.  Guidelines in [XXX] section
+   3 specify when the checksum MUST be included and what key MUST be
+   used.  Guidelines on when to include a checksum are never ambiguous:
+   a particular PDU is never correct both with and without a checksum.
+   With the exception of the KRB-ERROR message, receiving
+   implementations MUST reject messages where a checksum is included and
+   not expected or where a checksum is expected but not included.  The
+   receiving implementation does not always have sufficient information
+   to know whether a KRB-ERROR should contain a checksum.  Even so,
+   KRB-ERROR messages with invalid checksums MUST be rejected and
+
+Yu                         Expires: Jul 2005                    [Page 9]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   implementations MAY consider the presence or absence of a checksum
+   when evaluating whether to trust the error.
+
+   This authenticated cleartext protection is provided only in the
+   extensible variants of the messages; it is never used when
+   communicating with an RFC 1510 implementation.
+
+2.7.  Capability Negotiation
+
+   Kerberos is a three-party protocol.  Each of the three parties
+   involved needs a means of detecting the capabilities supported by the
+   others.  Two of the parties, the KDC and the application server, do
+   not communicate directly in the Kerberos protocol.  Communicating
+   capabilities from the KDC to the application server requires using a
+   ticket as an intermediary.
+
+   The main capability requiring negotiation is the support of the
+   extensibility framework described in this document.  Negotiation of
+   this capability while remaining compatible with RFC 1510
+   implementations is possible.  The main complication is that the
+   client needs to know whether the application server supports the
+   extensibility framework prior to sending any message to the
+   application server.  This can be accomplished if the KDC has
+   knowledge of whether an application server supports the extensibility
+   framework.
+
+   Client software advertizes its capabilities when requesting
+   credentials from the KDC.  If the KDC recognizes the capabilities, it
+   acknowledges this fact to the client in its reply.  In addition, if
+   the KDC has knowledge that the application server supports certain
+   capabilities, it also communicates this knowledge to the client in
+   its reply.  The KDC can encode its own capabilities in the ticket so
+   that the application server may discover these capabilities.  The
+   client advertizes its capabilities to the application server when it
+   initiates authentication to the application server.
+
+3.  Use of ASN.1 in Kerberos
+
+   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
+   Even though ASN.1 theoretically allows the description of protocol
+   messages to be independent of the encoding rules used to encode the
+   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
+   the semantics of the notation, such as whether tags carry any
+   semantic content to the application, may cause the use of other ASN.1
+   encoding rules to be problematic.
+
+   Implementors not using existing ASN.1 tools (e.g., compilers or
+   support libraries) are cautioned to thoroughly read and understand
+   the actual ASN.1 specification to ensure correct implementation
+   behavior.  There is more complexity in the notation than is
+   immediately obvious, and some tutorials and guides to ASN.1 are
+
+Yu                         Expires: Jul 2005                   [Page 10]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   misleading or erroneous.  Recommended tutorials and guides include
+   [Dub00], [Lar99], though there is still no substitute for reading the
+   actual ASN.1 specification.
+
+3.1.  Module Header
+
+   The type definitions in this document assume an ASN.1 module
+   definition of the following form:
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- Rest of definitions here
+
+      END
+
+   This specifies that the tagging context for the module will be
+   explicit and that automatic tagging is not done.
+
+   Some other publications [RFC1510] [RFC1964] erroneously specify an
+   object identifier (OID) having an incorrect value of "5" for the
+   "dod" component of the OID.  In the case of RFC 1964, use of the
+   "correct" OID value would result in a change in the wire protocol;
+   therefore, the RFC 1964 OID remains unchanged for now.
+
+3.2.  Top-Level Type
+
+   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
+   Data Units or PDUs) which an application may directly reference.
+   Applications SHOULD NOT transmit any types other than those which are
+   alternatives of the KRB-PDU CHOICE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 11]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+3.3.  Previously Unused ASN.1 Notation (informative)
+
+   Some aspects of ASN.1 notation used in this document were not used in
+   [KCLAR], and may be unfamiliar to some readers.  This subsection is
+   informative; for normative definitions of the notation, see the
+   actual ASN.1 specifications [X680], [X682], [X683].
+
+3.3.1.  Parameterized Types
+
+   This document uses ASN.1 parameterized types [X683] to make
+   definitions of types more readable.  For some types, some or all of
+   the parameters are advisory, i.e., they are not encoded in any form
+   for transmission in a protocol message.  These advisory parameters
+   can describe implementation behavior associated with the type.
+
+3.3.2.  COMPONENTS OF Notation
+
+   The "COMPONENTS OF" notation, used to define the RFC 1510
+   compatibility types, extracts all of the component types of an ASN.1
+   SEQUENCE type.  The extension marker (the "..." notation) and any
+   extension components are not extracted by "COMPONENTS OF".  The
+   "COMPONENTS OF" notation permits concise definition of multiple types
+   which have many components in common with each other.
+
+3.3.3.  Constraints
+
+   This document uses ASN.1 constraints, including the
+   "UserDefinedConstraint" notation [X682].  Some constraints can be
+   handled automatically by tools that can parse them.  Uses of the
+
+Yu                         Expires: Jul 2005                   [Page 12]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
+   typically need to have behavior manually coded; the notation provides
+   a formalized way of conveying intended implementation behavior.
+
+   The "WITH COMPONENTS" constraint notation allows constraints to apply
+   to component types of a SEQUENCE type.  This constraint notation
+   effectively allows constraints to "reach into" a type to constrain
+   its component types.
+
+3.4.  New Types
+
+   This document defines a number of ASN.1 types which are new since
+   [KCLAR].  The names of these types will typically have a suffix like
+   "Ext", indicating that the types are intended to support
+   extensibility.  Types original to RFC 1510 and [KCLAR] have been
+   renamed to have a suffix like "1510".  The "Ext" and "1510" types
+   often contain a number of common elements; these common elements have
+   a suffix like "Common".  The "1510" types have various ASN.1
+   constraints applied to them; the constraints limit the possible
+   values of the "1510" types to those permitted by RFC 1510 or by
+   [KCLAR].  The "Ext" types may have different constraints, typically
+   to force string values to be sent as UTF-8.
+
+   For example, consider
+
+      -- example "common" type
+      Foo-Common      ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING,
+          ...,
+          c           [2] INTEGER,
+          ...
+      }
+
+      -- example "RFC 1510 compatibility" type
+      Foo-1510        ::= SEQUENCE {
+          -- the COMPONENTS OF notation drops the extension marker
+          -- and all extension additions.
+          COMPONENTS OF Foo-Common
+      }
+
+      -- example "extensibility-enabled" type
+      Foo-Ext         ::= Foo-Common
+
+   where "Foo-Common" is a common type used to define both the "1510"
+   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
+   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
+   not contain the extension marker, nor does it contain the extension
+   component "c".  The type "Foo-1510" is equivalent to "Foo-1510-
+   Equiv", shown below.
+
+
+Yu                         Expires: Jul 2005                   [Page 13]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- example type equivalent to Foo-1510
+      Foo-1510-Equiv  ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING
+      }
+
+
+4.  Basic Types
+
+   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
+   types.
+
+4.1.  Constrained Integer Types
+
+   In RFC 1510, many types contained references to the unconstrained
+   INTEGER type.  Since an unconstrained INTEGER can contain almost any
+   possible abstract integer value, most of the unconstrained references
+   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
+   [KCLAR].
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+   The "Int32" type often contains an assigned number identifying the
+   contents of a typed hole.  Unless otherwise stated, non-negative
+   values are registered, and negative values are available for local
+   use.
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+   The "UInt32" type is used in some places where an unsigned 32-bit
+   integer is needed.
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+   The "UInt64" type is used in places where 32 bits of precision may
+   provide inadequate security.
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+   Sequence numbers were constrained to 32 bits in [KCLAR], but this
+   document allows for 64-bit sequence numbers.
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+Yu                         Expires: Jul 2005                   [Page 14]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
+   to 64 bits here.
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+   The "microseconds" type is intended to carry the microseconds part of
+   a time value.
+
+4.2.  KerberosTime
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
+   KerberosTime value MUST NOT include any fractional portions of the
+   seconds.  As required by the DER, it further MUST NOT include any
+   separators, and it specifies the UTC time zone (Z).  Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is "19851106210627Z".
+
+4.3.  KerberosString
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+   The KerberosString type is used for character strings in various
+   places in the Kerberos protocol.  For compatibility with RFC 1510,
+   GeneralString values constrained to IA5String (US-ASCII) are
+   permitted in messages exchanged with RFC 1510 implementations.  The
+   new protocol messages contain strings encoded as UTF-8, and these
+   strings MUST be normalized using [SASLPREP].  KerberosString values
+   are present in principal names and in error messages.  Control
+   characters SHOULD NOT be used in principal names, and used with
+   caution in error messages.
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+   KerberosStringIA5 requires the use of the "ia5" alternative, while
+
+Yu                         Expires: Jul 2005                   [Page 15]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   KerberosStringExt forbids it.  These types appear in ASN.1
+   constraints on messages.
+
+   For detailed background regarding the history of character string use
+   in Kerberos, as well as discussion of some compatibility issues, see
+   Appendix B.
+
+4.4.  Language Tags
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+   The "LangTag" type is used to specify language tags for localization
+   purposes, using the [RFC3066] format.
+
+4.5.  KerberosFlags
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+      })
+
+
+   The actual bit string type encoded in Kerberos messages does not use
+   named bits.  The advisory parameter of the KerberosFlags type names a
+   bit string type defined using named bits, whose value is encoded as
+   if it were a bit string with unnamed bits.  This practice is
+   necessary because the DER require trailing zero bits to be removed
+   when encoding bit strings defined using named bits.  Existing
+   implementations of Kerberos send exactly 32 bits rather than
+   truncating, so the size constraint requires the transmission of at
+   least 32 bits.  Trailing zero bits beyond the first 32 bits are
+   truncated.
+
+4.6.  Typed Holes
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+Yu                         Expires: Jul 2005                   [Page 16]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   The "TH-id" type is a generalized means to identify the contents of a
+   typed hole.  The "int32" alternative may be used for simple integer
+   assignments, in the same manner as "Int32", while the "rel-oid"
+   alternative may be used for hierarchical delegation.
+
+4.7.  HostAddress and HostAddresses
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+   addr-type
+        This field specifies the type of address that follows.
+
+   address
+        This field encodes a single address of the type identified by
+        "addr-type".
+
+   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.
+
+
+      addr-type |     meaning
+      __________|______________
+              2 |   IPv4
+              3 |   directional
+             12 |   DECnet
+             20 |   NetBIOS
+             24 |   IPv6
+
+
+
+4.7.1.  Internet (IPv4) Addresses
+
+   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
+   MSB order (most significant byte first). The IPv4 loopback address
+   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
+   two (2).
+
+
+Yu                         Expires: Jul 2005                   [Page 17]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+4.7.2.  Internet (IPv6) Addresses
+
+   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
+   in MSB order (most significant byte first). The type of IPv6
+   addresses is twenty-four (24). The following addresses MUST NOT
+   appear in any Kerberos PDU:
+
+      * the Unspecified Address
+
+      * the Loopback Address
+
+      * Link-Local addresses
+
+   This restriction applies to the inclusion in the address fields of
+   Kerberos PDUs, but not to the address fields of packets that might
+   carry such PDUs.  The restriction is necessary because the use of an
+   address with non-global scope could allow the acceptance of a message
+   sent from a node that may have the same address, but which is not the
+   host intended by the entity that added the restriction.  If the
+   link-local address type needs to be used for communication, then the
+   address restriction in tickets must not be used (i.e. addressless
+   tickets must be used).
+
+   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
+   2.
+
+4.7.3.  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).
+
+4.7.4.  Netbios addresses
+
+   Netbios addresses are 16-octet addresses typically composed of 1 to
+   15 alphanumeric characters and padded with the US-ASCII SPC character
+   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
+   0).  The type of Netbios addresses is twenty (20).
+
+4.7.5.  Directional Addresses
+
+   In many environments, including the sender address in KRB-SAFE and
+   KRB-PRIV messages is undesirable because the addresses may be changed
+   in transport by network address translators. However, if these
+   addresses are removed, the messages may be subject to a reflection
+   attack in which a message is reflected back to its originator. The
+   directional address type provides a way to avoid transport addresses
+   and reflection attacks.  Directional addresses are encoded as four
+   byte unsigned integers in network byte order.  If the message is
+   originated by the party sending the original AP-REQ message, then an
+   address of 0 SHOULD be used. If the message is originated by the
+   party to whom that AP-REQ was sent, then the address 1 SHOULD be
+
+Yu                         Expires: Jul 2005                   [Page 18]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   used.  Applications involving multiple parties can specify the use of
+   other addresses.
+
+   Directional addresses MUST only be used for the sender address field
+   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
+   ticket address or in a AP-REQ message.  This address type SHOULD only
+   be used in situations where the sending party knows that the
+   receiving party supports the address type.  This generally means that
+   directional addresses may only be used when the application protocol
+   requires their support.  Directional addresses are type (3).
+
+5.  Principals
+
+   Principals are participants in the Kerberos protocol.  A "realm"
+   consists of principals in one administrative domain, served by one
+   KDC (or one replicated set of KDCs).  Each principal name has an
+   arbitrary number of components, though typical principal names will
+   only have one or two components.  A principal name is meant to be
+   readable by and meaningful to humans, especially in a realm lacking a
+   centrally adminstered authorization infrastructure.
+
+5.1.  Name Types
+
+   Each PrincipalName has NameType indicating what sort of name it is.
+   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).
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+
+Yu                         Expires: Jul 2005                   [Page 19]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+5.2.  Principal Type Definition
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+   name-type
+        hint of the type of name that follows
+
+   name-string
+        The "name-string" encodes a sequence of components that form a
+        name, each component encoded as a KerberosString.  Taken
+        together, a PrincipalName and a Realm form a principal
+        identifier.  Most PrincipalNames will have only a few components
+        (typically one or two).
+
+5.3.  Principal Name Reuse
+
+   Realm administrators SHOULD use extreme caution when considering
+   reusing a principal name.  A service administrator might explicitly
+   enter principal names into a local access control list (ACL) for the
+   service.  If such local ACLs exist independently of a centrally
+   administered authorization infrastructure, realm administrators
+   SHOULD NOT reuse principal names until confirming that all extant ACL
+   entries referencing that principal name have been updated.  Failure
+   to perform this check can result in a security vulnerability, as a
+   new principal can inadvertently inherit unauthorized privileges upon
+   receiving a reused principal name.  An organization whose Kerberos-
+   authenticated services all use a centrally-adminstered authorization
+   infrastructure may not need to take these precautions regarding
+   principal name reuse.
+
+5.4.  Realm Names
+
+      Realm           ::= KerberosString
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
+   character with the code 0 (the US-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
+
+Yu                         Expires: Jul 2005                   [Page 20]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   the style of X.500 names.
+
+5.5.  Printable Representations of Principal Names
+
+   [ perhaps non-normative? ]
+
+   The printable form of a principal name consists of the concatenation
+   of components of the PrincipalName value using the slash character
+   (/), followed by an at-sign (@), followed by the realm name.  Any
+   occurrence of a backslash (\), slash (/) or at-sign (@) in the
+   PrincipalName value is quoted by a backslash.
+
+5.6.  Ticket-Granting Service Principal
+
+   The PrincipalName value corresponding to a ticket-granting service
+   has two components: the first component is the string "krbtgt", and
+   the second component is the realm name of the TGS which will accept a
+   ticket-granting ticket having this service principal name.  The realm
+   name of service always indicates which realm issued the ticket.  A
+   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
+   obtaining tickets in the same realm would have the following ASN.1
+   values for its "realm" and "sname" components, respectively:
+
+      -- Example Realm and PrincipalName for a TGS
+
+      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
+
+      tgtPrinc1       PrincipalName ::= {
+          name-type nt-srv-inst,
+          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
+      }
+
+   Its printable representation would be written as
+   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
+
+5.6.1.  Cross-Realm TGS Principals
+
+   It is possible for a principal in one realm to authenticate to a
+   service in another realm.  A KDC can issue a cross-realm ticket-
+   granting ticket to allow one of its principals to authenticate to a
+   service in a foreign realm.  For example, the TGS principal
+   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
+   client principal in the realm A.EXAMPLE.COM to authenticate to a
+   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
+   issues a ticket to a client originating in A.EXAMPLE.COM, the
+   client's realm name remains "A.EXAMPLE.COM", even though the service
+   principal will have the realm "B.EXAMPLE.COM".
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 21]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+6.  Types Relating to Encryption
+
+   Many Kerberos protocol messages contain encrypted encodings of
+   various data types.  Some Kerberos protocol messages also contain
+   checksums (signatures) of encodings of various types.
+
+6.1.  Assigned Numbers for Encryption
+
+   Encryption algorithm identifiers and key usages both have assigned
+   numbers, described in [KCRYPTO].
+
+6.1.1.  EType
+
+   EType is the integer type for assigned numbers for encryption
+   algorithms.  Defined in [KCRYPTO].
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+6.1.2.  Key Usages
+
+   KeyUsage is the integer type for assigned numbers for key usages.
+   Key usage values are inputs to the encryption and decryption
+
+Yu                         Expires: Jul 2005                   [Page 22]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   functions described in [KCRYPTO].
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+6.2.  Which Key to Use
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 23]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+6.3.  EncryptionKey
+
+   The "EncryptionKey" type holds an encryption key.
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+   keytype
+        This "EType" identifies the encryption algorithm, described in
+        [KCRYPTO].
+
+   keyvalue
+        Contains the actual key.
+
+6.4.  EncryptedData
+
+   The "EncryptedData" type contains the encryption of another data
+   type.  The recipient uses fields within EncryptedData to determine
+   which key to use for decryption.
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 24]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+   KeyUsages
+        Advisory parameter indicating which key usage to use when
+        encrypting the ciphertext.  If "KeyUsages" indicate multiple
+        "KeyUsage" values, the detailed description of the containing
+        message will indicate which key to use under which conditions.
+
+   Type
+        Advisory parameter indicating the ASN.1 type whose DER encoding
+        is the plaintext encrypted into the EncryptedData.
+
+   Keys
+        Advisory parameter indicating which key to use to perform the
+        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
+        detailed description of the containing message will indicate
+        which key to use under which conditions.
+
+   KeyUsages
+        Advisory parameter indicating which "KeyUsage" value is used to
+        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
+        the detailed description of the containing message will indicate
+        which key usage to use under which conditions.
+
+6.5.  Checksums
+
+   Several types contain checksums (actually signatures) of data.
+
+
+Yu                         Expires: Jul 2005                   [Page 25]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+   CksumType
+        Integer type for assigned numbers for signature algorithms.
+        Defined in [KCRYPTO]
+
+   Keys
+        As in EncryptedData
+
+   KeyUsages
+        As in EncryptedData
+
+   cksumtype
+        Signature algorithm used to produce the signature.
+
+   checksum
+        The actual checksum.
+
+6.5.1.  ChecksumOf
+
+   ChecksumOf is similar to "Checksum", but specifies which type is
+   signed.
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+Yu                         Expires: Jul 2005                   [Page 26]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   Type
+        Indicates the ASN.1 type whose DER encoding is signed.
+
+6.5.2.  Signed
+
+   Signed is similar to "ChecksumOf", but contains an actual instance of
+   the type being signed in addition to the signature.
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+7.  Tickets
+
+   [ A large number of items described here are duplicated in the
+   sections describing KDC-REQ processing.  Should find a way to avoid
+   this duplication. ]
+
+   A ticket binds a principal name to a session key.  The important
+   fields of a ticket are in the encrypted part.  The components in
+   common between the RFC 1510 and the extensible versions are
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+   crealm
+        This field contains the client's realm.
+
+   cname
+        This field contains the client's name.
+
+Yu                         Expires: Jul 2005                   [Page 27]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   caddr
+        This field lists the network addresses (if absent, all addresses
+        are permitted) from which the ticket is valid.
+
+   Descriptions of the other fields appear in the following sections.
+
+7.1.  Timestamps
+
+   Three of the ticket timestamps may be requested from the KDC.  The
+   timestamps may differ from those requested, depending on site policy.
+
+   authtime
+        The time at which the client authenticated, as recorded by the
+        KDC.
+
+   starttime
+        The earliest time when the ticket is valid.  If not present, the
+        ticket is valid starting at the authtime.  This is requested as
+        the "from" field of KDC-REQ-BODY-COMMON.
+
+   endtime
+        This time is requested in the "till" field of KDC-REQ-BODY-
+        COMMON.  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 time is requested in the "rtime" field of KDC-REQ-BODY-
+        COMMON.  It 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.
+
+7.2.  Ticket Flags
+
+   A number of flags may be set in the ticket, further defining some of
+   its capabilities.  Some of these flags map to flags in a KDC request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 28]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+7.2.1.  Flags Relating to Initial Ticket Acquisition
+
+   [ adapted KCLAR 2.1. ]
+
+   Several flags indicate the details of how the initial ticket was
+   acquired.
+
+   initial
+        The "initial" flag indicates that a ticket was issued using the
+        AS protocol, rather than issued based on a ticket-granting
+        ticket.  Application servers (e.g., a password-changing program)
+        requiring a client's definite knowledge of its secret key can
+        insist that this flag be set in any tickets they accept, thus
+        being assured that the client's key was recently presented to
+        the application client.
+
+   pre-authent
+        The "pre-authent" flag indicates that some sort of pre-
+        authentication was used during the AS exchange.
+
+   hw-authent
+        The "hw-authent" flag indicates that some sort of hardware-based
+        pre-authentication occurred during the AS exchange.
+
+   Both the "pre-authent" and the "hw-authent" flags may be present with
+   or without the "initial" flag; such tickets with the "initial" flag
+   clear are ones which are derived from initial tickets with the "pre-
+   authent" or "hw-authent" flags set.
+
+
+Yu                         Expires: Jul 2005                   [Page 29]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+7.2.2.  Invalid Tickets
+
+   [ KCLAR 2.2. ]
+
+   The "invalid" flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets which have this flag set.  A postdated
+   ticket will 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 8.3.2.4).
+
+7.2.3.  OK as Delegate
+
+   [ KCLAR 2.8. ]
+
+   The "ok-as-delegate" flag provides a way for a KDC to communicate
+   local realm policy to a client regarding whether the service for
+   which the ticket is issued is trusted to accept delegated
+   credentials.  For some applications, a client may need to delegate
+   credentials to a service to act on its behalf in contacting other
+   services.  The ability of a client to obtain a service ticket for a
+   service conveys no information to the client about whether the
+   service should be trusted to accept delegated credentials.
+
+   The copy of the ticket flags visible to the client may have the "ok-
+   as-delegate" flag set to indicate to the client that the service
+   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 service.  It is acceptable 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.
+
+7.2.4.  Renewable Tickets
+
+   [ adapted KCLAR 2.3. ]
+
+   The "renewable" flag indicates whether the ticket may be renewed.
+
+   Renewable tickets can be used to mitigate the consequences of ticket
+   theft.  Applications may desire to hold credentials which can be
+   valid for long periods of time.  However, this can expose the
+   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
+
+Yu                         Expires: Jul 2005                   [Page 30]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   periodically would require the application to have long-term access
+   to the client's secret key, which is an even greater risk.
+
+   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 present an unexpired renewable ticket to the
+   KDC, setting the "renew" option 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.  It can usually be ignored by application
+   servers.  However, some particularly careful application servers MAY
+   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 clear by default,
+   but a client can request it be set by setting the "renewable" option
+   in the 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.
+
+7.2.5.  Postdated Tickets
+
+   postdated
+        indicates a ticket which has been postdated
+
+   may-postdate
+        indicates that postdated tickets may be issued based on this
+        ticket
+
+   [ KCLAR 2.4. ]
+
+   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.
+
+
+
+Yu                         Expires: Jul 2005                   [Page 31]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   The "may-postdate" flag in a ticket is normally only interpreted by
+   the TGS.  It can be ignored by application servers.  This flag MUST
+   be set in a ticket-granting ticket in order for the KDC 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 AS-REQ [?also TGS-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 AS-REQ message.  The life (endtime minus
+   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 minus 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 for
+   validation before use.
+
+7.2.6.  Proxiable and Proxy Tickets
+
+   proxy
+        indicates a proxy ticket
+
+   proxiable
+        indicates that proxy tickets may be issued based on this ticket
+
+   [ KCLAR 2.5. ]
+
+   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, users wishing to delegate their
+   identity in a form usable for all purposes 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
+
+Yu                         Expires: Jul 2005                   [Page 32]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   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 may contain a set of network addresses from which they are
+   valid.  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.
+
+7.2.7.  Forwarded and Forwardable Tickets
+
+   forwarded
+        indicates a forwarded ticket
+
+   forwardable
+        indicates that forwarded tickets may be issued based on this
+        ticket
+
+   [ KCLAR 2.6. ]
+
+   Authentication forwarding is an instance of a proxy where the service
+   that is granted is 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
+
+Yu                         Expires: Jul 2005                   [Page 33]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   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.
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+7.3.  Transited Realms
+
+   [ KCLAR 2.7., plus new stuff ]
+
+7.4.  Authorization Data
+
+   [ KCLAR 5.2.6. ]
+
+      ADType          ::= TH-id
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+   ad-type
+        This field identifies the contents of the ad-data.  All negative
+        values are reserved for local use.  Non-negative values are
+        reserved for registered use.
+
+   ad-data
+        This field contains authorization data to be interpreted
+        according to the value of the corresponding ad-type field.
+
+   Each sequence of ADType and OCTET STRING is referred 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
+   AuthorizationData, and the interpretation of the encapsulating
+   element determines which enclosed elements must be interpreted, and
+   which may be ignored.
+
+   Depending on the meaning of the encapsulating element, the
+   encapsulated AuthorizationData may be ignored, interpreted as issued
+   directly by the KDC, or be stored in a separate plaintext part of the
+   ticket.  The types of the encapsulating elements are specified as
+
+Yu                         Expires: Jul 2005                   [Page 34]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   part of the Kerberos protocol because behavior based on these
+   container elements should be understood across implementations, while
+   other elements need only be understood by the applications which they
+   affect.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator.  Unless encapsulated in a known
+   authorization data element modifying the criticality of the elements
+   it contains, an application server MUST reject the authentication of
+   a client whose AP-REQ or ticket contains an unrecognized
+   authorization data element.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether it is the target of a restriction, a security weakness may
+   exist if the ticket can be used for that service.  Authorization
+   elements that are truly optional can be enclosed in AD-IF-RELEVANT
+   element.
+
+
+      ad-type |           contents of ad-data
+      ________|_______________________________________
+            1 |   DER encoding of AD-IF-RELEVANT
+            4 |   DER encoding of AD-KDCIssued
+            5 |   DER encoding of AD-AND-OR
+            8 |   DER encoding of AD-MANDATORY-FOR-KDC
+
+
+
+7.4.1.  AD-IF-RELEVANT
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      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.  The ad-type for AD-IF-RELEVANT is (1).
+
+7.4.2.  AD-KDCIssued
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 35]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+   ad-checksum
+        A cryptographic checksum computed over the DER encoding of the
+        AuthorizationData in the "elements" field, keyed with the
+        session key.  Its checksumtype is the mandatory checksum type
+        for the encryption type of the session key, and its key usage
+        value is 19.
+
+   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
+        AuthorizationData issued by the KDC.
+
+   The KDC-issued ad-data field is intended to provide a means for
+   Kerberos credentials to embed within themselves privilege attributes
+   and other mechanisms for positive authorization, amplifying the
+   privileges of the principal beyond what it would have if using
+   credentials without such an authorization-data element.
+
+   This amplification of privileges cannot 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).  AuthorizationData encapsulated with in the
+   AD-KDCIssued element MUST be ignored by the application server if
+   this "signature" is not present.  Further, AuthorizationData
+   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
+
+Yu                         Expires: Jul 2005                   [Page 36]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   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 encapsulates MAY be safely ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+7.4.3.  AD-AND-OR
+
+      ad-and-or               ADType ::= int32 : 5
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisfied.  Therefore, 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.
+
+   The ad-type for AD-AND-OR is (5).
+
+7.4.4.  AD-MANDATORY-FOR-KDC
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+   be interpreted by the KDC.  KDCs that do not understand the type of
+   an element embedded within the mandatory-for-kdc element MUST reject
+   the request.
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+7.5.  Encrypted Part of Ticket
+
+   The complete definition of the encrypted part is
+
+
+Yu                         Expires: Jul 2005                   [Page 37]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+   with the common portion being
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+   The encrypted part of the backwards-compatibility form of a ticket
+   is:
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+   The encrypted part of the extensible form of a ticket is:
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 38]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+7.6.  Cleartext Part of Ticket
+
+   The complete definition of Ticket is:
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+   with the common portion being:
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+   The "sname" field provides the name of the target service principal
+   in cleartext, as a hint to aid the server in choosing the correct
+   decryption key.
+
+   The backwards-compatibility form of Ticket is:
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+   The extensible form of Ticket is:
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 39]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+   TicketExtensions, which may only be present in the extensible form of
+   Ticket, are a cleartext typed hole for extension use.
+   AuthorizationData already provides an encrypted typed hole.
+
+      TEType                  ::= TH-id
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+   A client will only receive an extensible Ticket if the application
+   server supports extensibility.
+
+8.  Credential Acquisition
+
+   There are two exchanges that can be used for acquiring credentials:
+   the AS exchange and the TGS exchange.  These exchanges have many
+   similarities, and this document describes them in parallel, noting
+   which behaviors are specific to one type of exchange.  The AS request
+   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
+   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
+   are forms of KDC replies (KDC-REP).
+
+   The credentials acquisition protocol operates over specific
+   transports.  Additionally, specific methods exist to permit a client
+   to discover the KDC host with which to communicate.
+
+8.1.  KDC-REQ
+
+   The KDC-REQ has a large number of fields in common between the RFC
+   1510 and the extensible versions.  The KDC-REQ type itself is never
+   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 40]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
+   an EncTicketPartCommon.  The KDC copies most of them unchanged,
+   provided that the requested values meet site policy.
+
+Yu                         Expires: Jul 2005                   [Page 41]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   kdc-options
+        These flags do not correspond directly to "flags" in
+        EncTicketPartCommon.
+
+   cname
+        This field is copied to the "cname" field in
+        EncTicketPartCommon.  The "cname" field is required in an AS-
+        REQ; the client places its own name here.  In a TGS-REQ, the
+        "cname" in the ticket in the AP-REQ takes precedence.
+
+   realm
+        This field is the server's realm, and also holds the client's
+        realm in an AS-REQ.
+
+   sname
+        The "sname" field indicates the server's name.  It may be absent
+        in a TGS-REQ which requests user-to-user authentication, in
+        which case the "sname" of the issued ticket will be taken from
+        the included additional ticket.
+
+   The "from", "till", and "rtime" fields correspond to the "starttime",
+   "endtime", and "renew-till" fields of EncTicketPartCommon.
+
+   addresses
+        This field corresponds to the "caddr" field of
+        EncTicketPartCommon.
+
+   enc-authorization-data
+        For TGS-REQ, this field contains authorization data encrypted
+        using either the TGT session key or the AP-REQ subsession key;
+        the KDC may copy these into the "authorization-data" field of
+        EncTicketPartCommon if policy permits.
+
+   lang-tags
+        Only present in the extensible messages.  Specifies the set of
+        languages which the client is willing to accept in error
+        messages.
+
+   KDC options used in a KDC-REQ are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 42]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+   Different options apply to different phases of KDC-REQ processing.
+
+   The backwards-compatibility form of a KDC-REQ is:
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+   The extensible form of a KDC-REQ is:
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+   The backwards-compatibility form of a KDC-REQ-BODY is:
+
+Yu                         Expires: Jul 2005                   [Page 43]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+   The extensible form of a KDC-REQ-BODY is:
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+   The AS-REQ is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 44]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
+   if the client does not know that the KDC supports the extensibility
+   framework.  A client SHOULD send the extensible AS-REQ alternative in
+   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
+   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
+   what if their contents conflict? ]
+
+   The TGS-REQ is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 45]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+8.2.  PA-DATA
+
+   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
+   authenticate an AS-REQ; they may also modify several of the
+   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
+   to the client about which long-term key (usually password-derived) to
+   use.  PA-DATA may also include "hints" about which pre-authentication
+   mechanisms to use, or include data for input into a pre-
+   authentication mechanism.
+
+   [ XXX enumerate standard padata here ]
+
+8.3.  KDC-REQ Processing
+
+   Processing of a KDC-REQ proceeds through several steps.  An
+   implementation need not perform these steps exactly as described, as
+   long as it behaves as if the steps were performed as described.  The
+   KDC performs replay handling upon receiving the request; it then
+   validates the request, adjusts timestamps, and selects the keys used
+   in the reply.  It copies data from the request into the issued
+   ticket, adjusting the values to conform with its policies.  The KDC
+   then transmits the reply to the client.
+
+8.3.1.  Handling Replays
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+
+Yu                         Expires: Jul 2005                   [Page 46]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   successfully processed, the KDC MUST respond with a KDC-REP message
+   rather than a replay error.  In order to reduce the amount of
+   ciphertext given to a potential attacker, KDCs MAY send the same
+   response generated when the request was first handled.  KDCs MUST
+   obey this replay behavior even if the actual transport in use is
+   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
+   and the entire request is not identical to a recently successfully
+   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
+   appropriate for AP-REQ processing.
+
+8.3.2.  Request Validation
+
+8.3.2.1.  AS-REQ Authentication
+
+   Site policy determines whether a given client principal is required
+   to provide some pre-authentication prior to receiving an AS-REP.
+   Since the default reply key is typically the client's long-term
+   password-based key, an attacker may easily request known plaintext
+   (in the form of an AS-REP) upon which to mount a dictionary attack.
+   Pre-authentication can limit the possibility of such an attack.
+
+   If site policy requires pre-authentication for a client principal,
+   and no pre-authentication is provided, the KDC returns the error
+   "kdc-err-preauth-required".  Accompanying this error are "e-data"
+   which include hints telling the client which pre-authentication
+   mechanisms to use, or data for input to pre-authentication mechanisms
+   (e.g., input to challenge-response systems).  If pre-authentication
+   fails, the KDC returns the error "kdc-err-preauth-failed".
+
+   [ may need additional changes based on Sam's preauth draft ]
+
+8.3.2.2.  TGS-REQ Authentication
+
+   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
+   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
+   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
+   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
+   request.  [ padata not signed by authenticator! ] Any error from the
+   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
+   The service principal in the ticket of the AP-REQ may be a ticket-
+   granting service principal, or a normal application service
+   principal.  A ticket which is not a ticket-granting ticket MUST NOT
+   be used to issue a ticket for any service other than the one named in
+   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
+   forwarded?]  option must be set in the request.
+
+8.3.2.3.  Principal Validation
+
+   If the client principal in an AS-REQ is unknown, the KDC returns the
+   error "kdc-err-c-principal-unknown".  If the server principal in a
+   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
+
+Yu                         Expires: Jul 2005                   [Page 47]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   unknown".
+
+8.3.2.4.  Checking For Revoked or Invalid Tickets
+
+   [ KCLAR 3.3.3.1 ]
+
+   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 to the KDC for the realm in which
+   the server resides.  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.  If TGTs have been issued for cross-realm authentication, use
+   of the cross-realm TGT will not be affected unless the hot-list is
+   propagated to the KDCs for the realms for which such cross-realm
+   tickets were issued.
+
+   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
+   issue any ticket unless the TGS-REQ requests the "validate" option.
+
+8.3.3.  Timestamp Handling
+
+   [ some aspects of timestamp handling, especially regarding postdating
+   and renewal, are difficult to read in KCLAR... needs closer
+   examination here ]
+
+   Processing of "starttime" (requested in the "from" field) differs
+   depending on whether the "postdated" option is set in the request.
+   If the "postdated" option is not set, and the requested "starttime"
+   is in the future beyond the window of acceptable clock skew, the KDC
+   returns the error "kdc-err-cannot-postdate".  If the "postdated"
+   option is not set, and the requested "starttime" is absent or does
+   not indicate a time in the future beyond the acceptable clock skew,
+   the KDC sets the "starttime" to the KDC's current time.  The
+   "postdated" option MUST NOT be honored if the ticket is being
+   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
+   Otherwise, if the "postdated" option is set, and site policy permits,
+   the KDC sets the "starttime" as requested, and sets the "invalid"
+   flag in the new ticket.
+
+   The "till" field is required in the RFC 1510 version of the KDC-REQ.
+   If the "till" field is equal to "19700101000000Z" (midnight, January
+   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
+
+   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
+   "renew-till" time is later than the "renew-till" time of the ticket
+
+Yu                         Expires: Jul 2005                   [Page 48]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   from which it is derived.
+
+8.3.3.1.  AS-REQ Timestamp Processing
+
+   In the AS exchange, the "authtime" of a ticket is set to the local
+   time at the KDC.
+
+   The "endtime" of the ticket will be set to the earlier of the
+   requested "till" time and a time determined by local policy, possibly
+   determined using factors specific to the realm or principal.  For
+   example, the expiration time MAY be set to the earliest of the
+   following:
+
+      * the expiration time ("till" value) requested
+
+      * the ticket's start time plus the maximum allowable lifetime
+        associated with the client principal from the authentication
+        server's database
+
+      * 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.
+
+   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 MAY be set to the earliest 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
+
+8.3.3.2.  TGS-REQ Timestamp Processing
+
+   In the TGS exchange, the KDC sets the "authtime" to that of the
+   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
+   server can print a ticket for itself with a spoofed authtime.
+
+Yu                         Expires: Jul 2005                   [Page 49]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   security issues for hot-list?] [ MIT implementation may change
+   authtime of renewed tickets; needs check... ]
+
+   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
+   requests an "endtime" (in the "till" field), then the "endtime" of
+   the new ticket is set to the minimum of
+
+      * the requested "endtime" value,
+
+      * the "endtime" in the TGT, and
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+   If the new ticket is a renewal, the "endtime" of the new ticket is
+   bounded by the minimum of
+
+      * the requested "endtime" value,
+
+      * the value of the "renew-till" value of the old,
+
+      * the "starttime" of the new ticket plus the lifetime (endtime
+        minus starttime) of the old ticket, i.e., the lifetime of the
+        new ticket may not exceed that of the ticket being renewed [
+        adapted from KCLAR 3.3.3. ], and
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
+   a "starttime", "endtime", or "renew-till" time later than the
+   "renew-till" time of the TGT.
+
+8.3.4.  Handling Transited Realms
+
+   The KDC checks the ticket in a TGS-REQ against site policy, unless
+   the "disable-transited-check" option is set in the TGS-REQ.  If site
+   policy permits the transit path in the TGS-REQ ticket, the KDC sets
+   the "transited-policy-checked" flag in the issued ticket.  If the
+   "disable-transited-check" option is set, the issued ticket will have
+   the "transited-policy-checked" flag cleared.
+
+8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
+   copied into the issued ticket.  If the "addresses" field is absent or
+   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
+   TGS-REQ into the issued ticket, unless the either "forwarded" or
+   "proxy" option is set.  If the "forwarded" option is set, and the
+   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
+   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
+   issued ticket.  The KDC behaves similarly if the "proxy" option is
+   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
+   The "proxy" option will not be honored on requests for additional
+   ticket-granting tickets.
+
+Yu                         Expires: Jul 2005                   [Page 50]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+8.3.6.  Ticket Flag Processing
+
+   Many kdc-options request that the KDC set a corresponding flag in the
+   issued ticket.  kdc-options marked with an asterisk (*) in the
+   following table do not directly request the corresponding ticket flag
+   and therefore require special handling.
+
+
+             kdc-option       |    ticket flag affected
+      ________________________|__________________________
+      forwardable             |  forwardable
+      forwarded               |  forwarded
+      proxiable               |  proxiable
+      proxy                   |  proxy
+      allow-postdate          |  may-postdate
+      postdated               |  postdated
+      renewable               |  renewable
+      requestanonymous        |  anonymous
+      canonicalize            |  -
+      disable-transited-check*|  transited-policy-checked
+      renewable-ok*           |  renewable
+      enc-tkt-in-skey         |  -
+      renew                   |  -
+      validate*               |  invalid
+
+
+
+   forwarded
+        The KDC sets the "forwarded" flag in the issued ticket if the
+        "forwarded" option is set in the TGS-REQ and the "forwardable"
+        flag is set in the TGS-REQ ticket.
+
+   proxy
+        The KDC sets the "proxy" flag in the issued ticket if the
+        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
+        set in the TGS-REQ ticket.
+
+   disable-transited-check
+        The handling of the "disable-transited-check" kdc-option is
+        described in Section 8.3.4.
+
+   renewable-ok
+        The handling of the "renewable-ok" kdc-option is described in
+        Section 8.3.3.1.
+
+   enc-tkt-in-skey
+        This flag modifies ticket key selection to use the session key
+        of an additional ticket included in the TGS-REQ, for the purpose
+        of user-to-user authentication.
+
+
+
+Yu                         Expires: Jul 2005                   [Page 51]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   validate
+        If the "validate" kdc-option is set in a TGS-REQ, and the
+        "starttime" has passed, the KDC will clear the "invalid" bit on
+        the ticket before re-issuing it.
+
+8.3.7.  Key Selection
+
+   Three keys are involved in creating a KDC-REP.  The reply key
+   encrypts the encrypted part of the KDC-REP.  The session key is
+   stored in the encrypted part of the ticket, and is also present in
+   the encrypted part of the KDC-REP so that the client can retrieve it.
+   The ticket key is used to encrypt the ticket.  These keys all have
+   initial values for a given exchange; pre-authentication and other
+   extension mechanisms may change the value used for any of these keys.
+
+   [ again, may need changes based on Sam's preauth draft ]
+
+8.3.7.1.  Reply Key and Session Key Selection
+
+   The set of encryption types which the client will understand appears
+   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
+   of possible reply keys and the set of session key encryption types
+   based on the "etype" field.
+
+   For the AS exchange, the reply key is initially a long-term key of
+   the client, limited to those encryption types listed in the "etype"
+   field.  The KDC SHOULD use the first valid strong "etype" for which
+   an encryption key is available.  For the TGS exchange, the reply key
+   is initially the subsession key of the Authenticator.  If the
+   Authenticator subsesion key is absent, the reply key is initially the
+   session key of the ticket used to authenticate the TGS-REQ.
+
+   The session key is initially randomly generated, and has an
+   encryption type which both the client and the server will understand.
+   Typically, the KDC has prior knowledge of which encryption types the
+   server will understand.  It selects the first valid strong "etype"
+   listed the request which the server also will understand.
+
+8.3.7.2.  Ticket Key Selection
+
+   The ticket key is initially the long-term key of the service.  The
+   "enc-tkt-in-skey" option requests user-to-user authentication, where
+   the ticket encryption key of the issued ticket is set equal to the
+   session key of the additional ticket in the request.
+
+8.4.  KDC-REP
+
+   The important parts of the KDC-REP are encrypted.
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 52]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+   Most of the fields of EncKDCRepPartCom are duplicates of the
+   corresponding fields in the returned ticket.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 53]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 54]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+   req-cksum
+        Signature of the original request using the reply key, to avoid
+        replay attacks against the client, among other things.  Only
+        present in the extensible version of KDC-REP.
+
+           AS-REP          ::= CHOICE {
+               rfc1510     [APPLICATION 11] KDC-REP-1510 {
+                   EncASRepPart1510
+               } (WITH COMPONENTS { ..., msg-type (11) }),
+               ext         [APPLICATION  7]  Signed {
+                   [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+                   { key-reply }, { ku-ASRep-cksum }
+               } (WITH COMPONENTS { ..., msg-type (7) })
+           }
+
+
+           TGS-REP         ::= CHOICE {
+               rfc1510     [APPLICATION 13] KDC-REP-1510 {
+                   EncTGSRepPart1510
+               } (WITH COMPONENTS { ..., msg-type (13) }),
+               ext         [APPLICATION  9]  Signed {
+                   [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+                   { key-reply }, { ku-TGSRep-cksum }
+               } (WITH COMPONENTS { ..., msg-type (9) })
+           }
+
+
+   The extensible versions of AS-REQ and TGS-REQ are signed with the
+   reply key, to prevent an attacker from performing a delayed denial-
+   of-service attack by substituting the ticket.
+
+8.5.  Reply Validation
+
+   [ signature verification ]
+
+8.6.  IP Transports
+
+   [ KCLAR 7.2 ]
+
+   Kerberos defines two IP transport mechanisms for the credentials
+   acquisition protocol: UDP/IP and TCP/IP.
+
+
+Yu                         Expires: Jul 2005                   [Page 55]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+8.6.1.  UDP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
+   identify the IP address and port to which they will send their
+   request.
+
+   When contacting a 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 the KDC. The KDC will respond with a reply
+   datagram containing only an encoding of the reply message (either a
+   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
+   address. The response to a request made through UDP/IP transport MUST
+   also use UDP/IP transport. If the response can not be handled using
+   UDP (for example because it is too large), the KDC MUST return "krb-
+   err-response-too-big", forcing the client to retry the request using
+   the TCP transport.
+
+8.6.2.  TCP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   initially try a request using the UDP transport. Clients SHOULD use
+   KDC discovery (Section 8.6.3) to identify the IP address and port to
+   which they will send their request.
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+   When the KDC-REQ message is sent to the KDC over a TCP stream, the
+   response (KDC-REP or KRB-ERROR message) MUST be returned to the
+   client on the same TCP stream that was established for the request.
+   The KDC MAY close the TCP stream after sending a response, but MAY
+   leave the stream open for a reasonable period of time if it expects a
+   followup. Care must be taken in managing TCP/IP connections on the
+   KDC to prevent denial of service attacks based on the number of open
+   TCP/IP connections.
+
+
+Yu                         Expires: Jul 2005                   [Page 56]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   anytime after the receipt of a response.  A stream closure SHOULD NOT
+   be treated as a fatal error.  Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication) the client may
+   need to establish a new connection when it is ready to send
+   subsequent messages.  A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   followup messages.
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
+   the TCP stream is preceded by the length of the request as 4 octets
+   in network byte order. The high bit of the length is reserved for
+   future expansion and MUST currently be set to zero.  If a KDC that
+   does not understand how to interpret a set high bit of the length
+   encoding receives a request with the high order bit of the length
+   set, it MUST return a KRB-ERROR message with the error "krb-err-
+   field-toolong" and MUST close the TCP stream.
+
+   If multiple requests are sent over a single TCP connection, and the
+   KDC sends multiple responses, the KDC is not required to send the
+   responses in the order of the corresponding requests.  This may
+   permit some implementations to send each response as soon as it is
+   ready even if earlier requests are still being processed (for
+   example, waiting for a response from an external device or database).
+
+8.6.3.  KDC Discovery on IP Networks
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored 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 using cross-realm authentication. This section
+   describes a method for using the Domain Name System [RFC 1035] for
+   storing KDC location information.
+
+8.6.3.1.  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
+   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
+   and "MyRealm" are all different, but resolve the same in the domain
+   name system, it is necessary that only one of the possible
+   combinations of upper and lower case characters be used in realm
+
+Yu                         Expires: Jul 2005                   [Page 57]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   names.
+
+8.6.3.2.  DNS SRV records for KDC location
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2782].  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 one of "udp", "tcp". If these SRV records are to be
+   used, both "udp" and "tcp" records MUST be specified for all KDC
+   deployments.
+
+   The Realm is the Kerberos realm that this record corresponds to.  The
+   realm MUST be a domain style realm name.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2782.
+
+   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal) unless the KDC is configured
+   to listen on an alternate TCP port.
+
+   Implementation note: Many existing client implementations do not
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority.  Weights are not used in these sample records.
+
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+
+
+9.  Errors
+
+   The KRB-ERROR message is returned by the KDC if an error occurs
+   during credentials acquisition.  It may also be returned by an
+   application server if an error occurs during authentication.
+
+
+
+Yu                         Expires: Jul 2005                   [Page 58]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+   The extensible KRB-ERROR is only signed if there has been a key
+   negotiated with its recipient.  KRB-ERROR messages sent in response
+   to AS-REQ messages will probably not be signed unless a
+   preauthentication mechanism has negotiated a key.  (Signing using a
+   client's long-term key can expose ciphertext to dictionary attacks.)
+
+   The parts of a KRB-ERROR common to both the backwards-compatibility
+   and the extensibile messages are
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+Yu                         Expires: Jul 2005                   [Page 59]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   ctime, cusec
+        Client's time, if known from a KDC-REQ or AP-REQ.
+
+   stime, susec
+        KDC or application server's current time.
+
+   error-code
+        Numeric error code designating the error.
+
+   crealm, cname
+        Client's realm and name, if known.
+
+   realm, sname
+        server's realm and name. [ XXX what if these aren't known? ]
+
+   e-text
+        Human-readable text providing additional details for the error.
+
+   e-data
+        This field contains additional data about the error for use by
+        the client to help it recover from or handle the error. If the
+        "error-code" is "kdc-err-preauth-required", then the e-data
+        field will contain an encoding of a sequence of padata fields,
+        each corresponding to an acceptable pre-authentication method
+        and optionally containing data for the method:
+
+           METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+        For error codes defined in this document other than "kdc-err-
+        preauth-required", the format and contents of the e-data field
+        are implementation-defined.  Similarly, for future error codes,
+        the format and contents of the e-data field are implementation-
+        defined unless specified.
+
+   lang-tag
+        Indicates the language of the message in the "e-text" field.  It
+        is only present in the extensible KRB-ERROR.
+
+   nonce
+        is the nonce from a KDC-REQ.  It is only present in the
+        extensible KRB-ERROR.
+
+   typed-data
+        TYPED-DATA is a typed hole allowing for additional data to be
+        returned in error conditions, since "e-data" is insufficiently
+        flexible for some purposes.  TYPED-DATA is only present in the
+        extensible KRB-ERROR.
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 60]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+           TDType ::= TH-id
+
+           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+               data-type   [0] TDType,
+               data-value  [1] OCTET STRING OPTIONAL
+           }
+
+
+10.  Session Key Exchange
+
+   Session key exchange consists of the AP-REQ and AP-REP messages.  The
+   client sends the AP-REQ message, and the service responds with an
+   AP-REP message if mutual authentication is desired.  Following
+   session key exchange, the client and service share a secret session
+   key, or possibly a subsesion key, which can be used to protect
+   further communications.  Additionally, the session key exchange
+   process can establish initial sequence numbers which the client and
+   service can use to detect replayed messages.
+
+10.1.  AP-REQ
+
+   An AP-REQ message contains a ticket and a authenticator.  The
+   authenticator is ciphertext encrypted with the session key contained
+   in the ticket.  The plaintext contents of the authenticator are:
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+   The common parts between the RFC 1510 and the extensible versions of
+   the AP-REQ are:
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 61]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+   The complete definition of AP-REQ is:
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 62]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+10.2.  AP-REP
+
+   An AP-REP message provides mutual authentication of the service to
+   the client.
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+Yu                         Expires: Jul 2005                   [Page 63]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+
+Yu                         Expires: Jul 2005                   [Page 64]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+11.  Session Key Use
+
+   Once a session key has been established, the client and server can
+   use several kinds of messages to securely transmit data.  KRB-SAFE
+   provides integrity protection for application data, while KRB-PRIV
+   provides confidentiality along with integrity protection.  The KRB-
+   CRED message provides a means of securely forwarding credentials from
+   the client host to the server host.
+
+11.1.  KRB-SAFE
+
+   The KRB-SAFE message provides integrity protection for an included
+   cleartext message.
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+11.2.  KRB-PRIV
+
+   The KRB-PRIV message provides confidentiality and integrity
+   protection.
+
+
+Yu                         Expires: Jul 2005                   [Page 65]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+11.3.  KRB-CRED
+
+   The KRB-CRED message provides a means of securely transferring
+   credentials from the client to the service.
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+
+Yu                         Expires: Jul 2005                   [Page 66]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+12.  Security Considerations
+
+12.1.  Time Synchronization
+
+   Time synchronization between the KDC and application servers is
+   necessary to prevent acceptance of expired tickets.
+
+   Time synchronization is needed between application servers and
+   clients to prevent replay attacks if a replay cache is being used.
+   If negotiated subsession keys are used to encrypt application data,
+   replay caches may not be necessary.
+
+12.2.  Replays
+
+12.3.  Principal Name Reuse
+
+   See Section 5.3.
+
+12.4.  Password Guessing
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 67]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+12.5.  Forward Secrecy
+
+   [from KCLAR 10.; needs some rewriting]
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB-PRIV message,
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the TGS-REP
+   message.  The session key from the ticket-granting ticket was sent to
+   the user in the AS-REP message encrypted in the user's secret key,
+   and embedded in the ticket-granting ticket, which was encrypted in
+   the key of the KDC.  Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+12.6.  Authorization
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  Kerberos does not, by
+   itself, provide authorization.  Applications SHOULD NOT accept the
+   mere issuance of a service ticket by the Kerberos server as granting
+   authority to use the service.
+
+12.7.  Login Authentication
+
+   Some applications, particularly those which provide login access when
+   provided with a password, SHOULD NOT treat successful acquisition of
+   credentials as sufficient proof of the user's identity.  An attacker
+   posing as a user could generate an illegitimate KDC-REP message which
+   decrypts properly.  To authenticate a user logging on to a local
+   system, the credentials obtained SHOULD be used in a TGS exchange to
+   obtain credentials for a local service.  Successful use of those
+   credentials to authenticate to the local service assures that the
+   initially obtained credentials are from a valid KDC.
+
+13.  IANA Considerations
+
+   [ needs more work ]
+
+   Each use of Int32 in this document defines a number space.  [ XXX
+   enumerate these ] Negative numbers are reserved for private use;
+   local and experimental extensions should use these values.  Zero is
+   reserved and may not be assigned.
+
+
+Yu                         Expires: Jul 2005                   [Page 68]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   Typed hole contents may be identified by either Int32 values or by
+   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
+   namespace, assignments to the top level of the RELATIVE-OID space may
+   be made on a first-come, first-served basis.
+
+14.  Acknowledgments
+
+   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
+   clarifications-07.  The description of the general form of the
+   extensibility framework was derived from text by Sam Hartman.
+
+Appendices
+
+A.  ASN.1 Module (Normative)
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related
+      -- OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
+      -- OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2)
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 69]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+      --
+      -- *** basic types
+      --
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+Yu                         Expires: Jul 2005                   [Page 70]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 71]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+      -- IA5 only
+      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringIA5))
+      })
+
+      -- IA5 excluded
+      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringExt))
+      })
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 72]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      Realm           ::= KerberosString
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+      })
+
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+      --
+      -- *** crypto-related types and assignments
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 73]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 74]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 75]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 76]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 77]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+      --
+      -- *** Tickets
+      --
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+Yu                         Expires: Jul 2005                   [Page 78]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 79]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+      --
+      -- *** Authorization Data
+      --
+
+
+      ADType          ::= TH-id
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      AD-IF-RELEVANT          ::= AuthorizationData
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 80]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+      ad-and-or               ADType ::= int32 : 5
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+
+      TrType                  ::= TH-id -- must be registered
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+          tr-type     [0] TrType,
+          contents    [1] OCTET STRING
+      }
+
+
+      TEType                  ::= TH-id
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 81]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+      --
+      -- *** KDC protocol
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 82]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 83]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 84]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 85]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 86]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AS-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 11] KDC-REP-1510 {
+              EncASRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (11) }),
+          ext         [APPLICATION  7]  Signed {
+              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+              { key-reply }, { ku-ASRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (7) })
+      }
+
+
+      TGS-REP         ::= CHOICE {
+          rfc1510     [APPLICATION 13] KDC-REP-1510 {
+              EncTGSRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (13) }),
+          ext         [APPLICATION  9]  Signed {
+              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+              { key-reply }, { ku-TGSRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (9) })
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 87]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 88]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 89]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      LRType          ::=     TH-id
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+          lr-type     [0] LRType,
+          lr-value    [1] KerberosTime
+      }
+
+
+      --
+      -- *** preauth
+      --
+
+
+      PaDataType      ::= TH-id
+      PaDataOID       ::= RELATIVE-OID
+
+      PA-DATA ::= SEQUENCE {
+          -- NOTE: first tag is [1], not [0]
+          padata-type         [1] PaDataType,
+          padata-value        [2] OCTET STRING
+      }
+
+
+      -- AP-REQ authenticating a TGS-REQ
+      pa-tgs-req              PaDataType ::= int32 : 1
+      PA-TGS-REQ              ::= AP-REQ
+
+
+      -- Encrypted timestamp preauth
+      -- Encryption key used is client's long-term key.
+      pa-enc-timestamp        PaDataType ::= int32 : 2
+
+      PA-ENC-TIMESTAMP ::= EncryptedData {
+          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
+      }
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 90]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Hints returned in AS-REP or KRB-ERROR to help client
+      -- choose a password-derived key, either for preauthentication
+      -- or for decryption of the reply.
+      pa-etype-info           PaDataType ::= int32 : 11
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+
+      -- Similar to etype-info, but with parameters provided for
+      -- the string-to-key function.
+      pa-etype-info2          PaDataType ::= int32 : 19
+
+      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
+                                      OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+
+      -- Obsolescent.  Salt for client's long-term key.
+      -- Its character encoding is unspecified.
+      pa-pw-salt              PaDataType ::= int32 : 3
+      -- The "padata-value" does not encode an ASN.1 type.
+      -- Instead, "padata-value" must consist of the salt string to
+      -- be used by the client, in an unspecified character
+      -- encoding.
+
+
+      -- An extensible AS-REQ may be sent as a padata in a
+      -- non-extensible AS-REQ to allow for backwards compatibility.
+      pa-as-req               PaDataType ::= int32 : 42 -- provisional
+      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
+
+
+      --
+      -- *** Session key exchange
+      --
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 91]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 92]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      ApReqExtType    ::= TH-id
+
+      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apReqExt-Type       [0] ApReqExtType,
+          apReqExt-Data       [1] OCTET STRING
+      }
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 93]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+      ApRepExtType    ::= TH-id
+
+      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apRepExt-Type       [0] ApRepExtType,
+          apRepExt-Data       [1] OCTET STRING
+      }
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 94]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Application messages
+      --
+
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 95]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 96]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 97]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
+          pvno            [0] INTEGER (5),
+          msg-type        [1] INTEGER (16),
+          sname           [2] PrincipalName OPTIONAL,
+          srealm          [3] Realm OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Error messages
+      --
+
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 98]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+      TDType ::= TH-id
+
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+          data-type   [0] TDType,
+          data-value  [1] OCTET STRING OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                   [Page 99]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      --
+      -- *** Error codes
+      --
+
+      -- No error
+      kdc-err-none                          ErrCode ::= 0
+      -- Client's entry in database has expired
+      kdc-err-name-exp                      ErrCode ::= 1
+      -- Server's entry in database has expired
+      kdc-err-service-exp                   ErrCode ::= 2
+      -- Requested protocol version number not supported
+      kdc-err-bad-pvno                      ErrCode ::= 3
+      -- Client's key encrypted in old master key
+      kdc-err-c-old-mast-kvno               ErrCode ::= 4
+      -- Server's key encrypted in old master key
+      kdc-err-s-old-mast-kvno               ErrCode ::= 5
+      -- Client not found in Kerberos database
+      kdc-err-c-principal-unknown           ErrCode ::= 6
+      -- Server not found in Kerberos database
+      kdc-err-s-principal-unknown           ErrCode ::= 7
+      -- Multiple principal entries in database
+      kdc-err-principal-not-unique          ErrCode ::= 8
+      -- The client or server has a null key
+      kdc-err-null-key                      ErrCode ::= 9
+      -- Ticket not eligible for postdating
+      kdc-err-cannot-postdate               ErrCode ::= 10
+      -- Requested start time is later than end time
+      kdc-err-never-valid                   ErrCode ::= 11
+      -- KDC policy rejects request
+      kdc-err-policy                        ErrCode ::= 12
+      -- KDC cannot accommodate requested option
+      kdc-err-badoption                     ErrCode ::= 13
+      -- KDC has no support for encryption type
+      kdc-err-etype-nosupp                  ErrCode ::= 14
+      -- KDC has no support for checksum type
+      kdc-err-sumtype-nosupp                ErrCode ::= 15
+      -- KDC has no support for padata type
+      kdc-err-padata-type-nosupp            ErrCode ::= 16
+      -- KDC has no support for transited type
+      kdc-err-trtype-nosupp                 ErrCode ::= 17
+      -- Clients credentials have been revoked
+      kdc-err-client-revoked                ErrCode ::= 18
+      -- Credentials for server have been revoked
+      kdc-err-service-revoked               ErrCode ::= 19
+      -- TGT has been revoked
+      kdc-err-tgt-revoked                   ErrCode ::= 20
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                  [Page 100]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Client not yet valid - try again later
+      kdc-err-client-notyet                 ErrCode ::= 21
+      -- Server not yet valid - try again later
+      kdc-err-service-notyet                ErrCode ::= 22
+      -- Password has expired - change password to reset
+      kdc-err-key-expired                   ErrCode ::= 23
+      -- Pre-authentication information was invalid
+      kdc-err-preauth-failed                ErrCode ::= 24
+      -- Additional pre-authenticationrequired
+      kdc-err-preauth-required              ErrCode ::= 25
+      -- Requested server and ticket don't match
+      kdc-err-server-nomatch                ErrCode ::= 26
+      -- Server principal valid for user2user only
+      kdc-err-must-use-user2user            ErrCode ::= 27
+      -- KDC Policy rejects transited path
+      kdc-err-path-not-accpeted             ErrCode ::= 28
+      -- A service is not available
+      kdc-err-svc-unavailable               ErrCode ::= 29
+      -- Integrity check on decrypted field failed
+      krb-ap-err-bad-integrity              ErrCode ::= 31
+      -- Ticket expired
+      krb-ap-err-tkt-expired                ErrCode ::= 32
+      -- Ticket not yet valid
+      krb-ap-err-tkt-nyv                    ErrCode ::= 33
+      -- Request is a replay
+      krb-ap-err-repeat                     ErrCode ::= 34
+      -- The ticket isn't for us
+      krb-ap-err-not-us                     ErrCode ::= 35
+      -- Ticket and authenticator don't match
+      krb-ap-err-badmatch                   ErrCode ::= 36
+      -- Clock skew too great
+      krb-ap-err-skew                       ErrCode ::= 37
+      -- Incorrect net address
+      krb-ap-err-badaddr                    ErrCode ::= 38
+      -- Protocol version mismatch
+      krb-ap-err-badversion                 ErrCode ::= 39
+      -- Invalid msg type
+      krb-ap-err-msg-type                   ErrCode ::= 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                  [Page 101]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Message stream modified
+      krb-ap-err-modified                   ErrCode ::= 41
+      -- Message out of order
+      krb-ap-err-badorder                   ErrCode ::= 42
+      -- Specified version of key is not available
+      krb-ap-err-badkeyver                  ErrCode ::= 44
+      -- Service key not available
+      krb-ap-err-nokey                      ErrCode ::= 45
+      -- Mutual authentication failed
+      krb-ap-err-mut-fail                   ErrCode ::= 46
+      -- Incorrect message direction
+      krb-ap-err-baddirection               ErrCode ::= 47
+      -- Alternative authentication method required
+      krb-ap-err-method                     ErrCode ::= 48
+      -- Incorrect sequence number in message
+      krb-ap-err-badseq                     ErrCode ::= 49
+      -- Inappropriate type of checksum in message
+      krb-ap-err-inapp-cksum                ErrCode ::= 50
+      -- Policy rejects transited path
+      krb-ap-path-not-accepted              ErrCode ::= 51
+      -- Response too big for UDP, retry with TCP
+      krb-err-response-too-big              ErrCode ::= 52
+      -- Generic error (description in e-text)
+      krb-err-generic                       ErrCode ::= 60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                  [Page 102]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+      -- Field is too long for this implementation
+      krb-err-field-toolong                 ErrCode ::= 61
+      -- Reserved for PKINIT
+      kdc-error-client-not-trusted          ErrCode ::= 62
+      -- Reserved for PKINIT
+      kdc-error-kdc-not-trusted             ErrCode ::= 63
+      -- Reserved for PKINIT
+      kdc-error-invalid-sig                 ErrCode ::= 64
+      -- Reserved for PKINIT
+      kdc-err-key-too-weak                  ErrCode ::= 65
+      -- Reserved for PKINIT
+      kdc-err-certificate-mismatch          ErrCode ::= 66
+      -- No TGT available to validate USER-TO-USER
+      krb-ap-err-no-tgt                     ErrCode ::= 67
+      -- USER-TO-USER TGT issued different KDC
+      kdc-err-wrong-realm                   ErrCode ::= 68
+      -- Ticket must be for USER-TO-USER
+      krb-ap-err-user-to-user-required      ErrCode ::= 69
+      -- Reserved for PKINIT
+      kdc-err-cant-verify-certificate       ErrCode ::= 70
+      -- Reserved for PKINIT
+      kdc-err-invalid-certificate           ErrCode ::= 71
+      -- Reserved for PKINIT
+      kdc-err-revoked-certificate           ErrCode ::= 72
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unknown     ErrCode ::= 73
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unavailable ErrCode ::= 74
+
+
+      END
+
+
+B.  Kerberos and Character Encodings (Informative)
+
+   [adapted from KCLAR 5.2.1]
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO 2022 | ECMA-35
+   [ISO2022] to switch character sets, and the default character set
+   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
+   International Reference Version (IRV) (aka U.S. ASCII), which mostly
+   works.
+
+   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER previously
+   [X690-1997] prohibited the designation of character sets as any but
+   the G0 and C0 sets.  This had the side effect of prohibiting the use
+
+Yu                         Expires: Jul 2005                  [Page 103]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
+   other character-sets that utilize a 96-character set, since it is
+   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
+   element.  Recent revisions to the ASN.1 standards resolve this
+   contradiction.
+
+   In practice, many implementations treat RFC 1510 GeneralStrings as if
+   they were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to conform to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   [the following should probably be rewritten and moved into the
+   principal name section]
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way.  Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters.  This is a violation of the ASN.1
+   standard.  Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard.  As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+
+Yu                         Expires: Jul 2005                  [Page 104]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+C.  Kerberos History (Informative)
+
+   [Adapted from KCLAR "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 Ts'o, 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 [KNT94].
+
+D.  Notational Differences from [KCLAR]
+
+   [ possible point for discussion ]
+
+   [KCLAR] uses notational conventions slightly different from this
+   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
+   language style identifier names for defined values.  In ASN.1
+   notation, identifiers referencing defined values must begin with a
+   lowercase letter and contain hyphen (-) characters rather than
+   underscore (_) characters, while identifiers referencing types begin
+   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
+   identifiers with underscores to identify defined values.  This has
+   the potential to create confusion, but neither document defines
+   values using actual ASN.1 value-assignment notation.
+
+   It is debatable whether it is advantageous to write all identifier
+   names (regardless of their ASN.1 token type) in all-uppercase letters
+   for the purpose of emphasis in running text.  The alternative is to
+
+Yu                         Expires: Jul 2005                  [Page 105]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   use double-quote characters (") when ambiguity is possible.
+
+Normative References
+
+   [ISO646]
+        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
+
+   [ISO2022]
+        "Information technology -- Character code structure and
+        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
+
+   [KCRYPTO]
+        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
+        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
+
+   [RFC2119]
+        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+        Requirement Levels", March 1997.
+
+   [RFC3660]
+        H. Alvestrand, "Tags for the Identification of Languages",
+        RFC 3660, January 2001.
+
+   [SASLPREP]
+        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
+        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
+        progress.
+
+   [X680]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Specification of basic notation", ITU-T Recommendation X.680
+        (2002) | ISO/IEC 8824-1:2002.
+
+   [X682]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Constraint specification", ITU-T Recommendation X.682 (2002) |
+        ISO/IEC 8824-3:2002.
+
+   [X683]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Parameterization of ASN.1 specifications", ITU-T Recommendation
+        X.683 (2002) | ISO/IEC 8824-4:2002.
+
+   [X690]
+        "Information technology -- ASN.1 encoding Rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+
+
+
+Yu                         Expires: Jul 2005                  [Page 106]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+Informative References
+
+   [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).
+
+   [Dub00]
+        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
+        Systems", Elsevier-Morgan Kaufmann, 2000.
+        <http://www.oss.com/asn1/dubuisson.html>
+
+   [ISO8859-1]
+        "Information technology -- 8-bit single-byte coded graphic
+        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
+        1:1998.
+
+   [KCLAR]
+        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
+        Network Authentication Service (V5)", draft-ietf-krb-wg-
+        kerberos-clarifications-07.txt, work in progress.
+
+   [KNT94]
+        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+        Evolution of the Kerberos Authentication System".  In
+        Distributed Open Systems, pages 78-94.  IEEE Computer Society
+        Press, 1994.
+
+   [Lar96]
+        John Larmouth, "Understanding OSI", International Thomson
+        Computer Press, 1996.
+        <http://www.isi.salford.ac.uk/books/osi.html>
+
+   [Lar99]
+        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
+        1999.  <http://www.oss.com/asn1/larmouth.html>
+
+   [NS78]
+        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+        Authentication in Large Networks of Computers", Communications
+        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+   [RFC1510]
+        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
+        Service (v5)", RFC1510, September 1993, Status: Proposed
+        Standard.
+
+   [RFC1964]
+        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
+        June 1996, Status: Proposed Standard.
+
+
+Yu                         Expires: Jul 2005                  [Page 107]
+
+Internet-Draft               rfc1510ter-00                   21 Jan 2005
+
+   [X690-2002]
+        "Information technology -- ASN.1 encoding rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+Author's Address
+
+   Tom Yu
+   77 Massachusetts Ave
+   Cambridge, MA 02139
+   USA
+   tlyu@mit.edu
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Jul 2005                  [Page 108]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt
new file mode 100644
index 00000000000..5728927e468
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt
@@ -0,0 +1,6049 @@
+
+
+INTERNET-DRAFT                                                    Tom Yu
+draft-ietf-krb-wg-rfc1510ter-01.txt                                  MIT
+Expires: 19 March 2005                                 15 September 2005
+
+        The Kerberos Network Authentication Service (Version 5)
+
+Status of This Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes version 5 of the Kerberos network
+   authentication protocol.  It describes a framework to allow for
+   extensions to be made to the protocol without creating
+   interoperability problems.
+
+Key Words for Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in RFC 2119.
+
+
+
+
+Yu                         Expires: Mar 2005                    [Page 1]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+Table of Contents
+
+   Status of This Memo ..............................................  1
+   Copyright Notice .................................................  1
+   Abstract .........................................................  1
+   Key Words for Requirements .......................................  1
+   Table of Contents ................................................  2
+   1.  Introduction .................................................  5
+   1.1.  Kerberos Protocol Overview .................................  5
+   1.2.  Document Organization ......................................  6
+   2.  Compatibility Considerations .................................  6
+   2.1.  Extensibility ..............................................  7
+   2.2.  Compatibility with RFC 1510 ................................  7
+   2.3.  Backwards Compatibility ....................................  7
+   2.4.  1.4.2. Sending Extensible Messages .........................  8
+   2.5.  Criticality ................................................  8
+   2.6.  Authenticating Cleartext Portions of Messages ..............  9
+   2.7.  Capability Negotiation ..................................... 10
+   3.  Use of ASN.1 in Kerberos ..................................... 10
+   3.1.  Module Header .............................................. 11
+   3.2.  Top-Level Type ............................................. 11
+   3.3.  Previously Unused ASN.1 Notation (informative) ............. 12
+   3.3.1.  Parameterized Types ...................................... 12
+   3.3.2.  COMPONENTS OF Notation ................................... 12
+   3.3.3.  Constraints .............................................. 12
+   3.4.  New Types .................................................. 13
+   4.  Basic Types .................................................. 14
+   4.1.  Constrained Integer Types .................................. 14
+   4.2.  KerberosTime ............................................... 15
+   4.3.  KerberosString ............................................. 15
+   4.4.  Language Tags .............................................. 16
+   4.5.  KerberosFlags .............................................. 16
+   4.6.  Typed Holes ................................................ 16
+   4.7.  HostAddress and HostAddresses .............................. 17
+   4.7.1.  Internet (IPv4) Addresses ................................ 17
+   4.7.2.  Internet (IPv6) Addresses ................................ 17
+   4.7.3.  DECnet Phase IV addresses ................................ 18
+   4.7.4.  Netbios addresses ........................................ 18
+   4.7.5.  Directional Addresses .................................... 18
+   5.  Principals ................................................... 19
+   5.1.  Name Types ................................................. 19
+   5.2.  Principal Type Definition .................................. 19
+   5.3.  Principal Name Reuse ....................................... 20
+   5.4.  Realm Names ................................................ 20
+   5.5.  Printable Representations of Principal Names ............... 21
+   5.6.  Ticket-Granting Service Principal .......................... 21
+   5.6.1.  Cross-Realm TGS Principals ............................... 21
+   6.  Types Relating to Encryption ................................. 21
+   6.1.  Assigned Numbers for Encryption ............................ 22
+   6.1.1.  EType .................................................... 22
+   6.1.2.  Key Usages ............................................... 22
+
+Yu                         Expires: Mar 2005                    [Page 2]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   6.2.  Which Key to Use ........................................... 23
+   6.3.  EncryptionKey .............................................. 24
+   6.4.  EncryptedData .............................................. 24
+   6.5.  Checksums .................................................. 25
+   6.5.1.  ChecksumOf ............................................... 26
+   6.5.2.  Signed ................................................... 27
+   7.  Tickets ...................................................... 27
+   7.1.  Timestamps ................................................. 28
+   7.2.  Ticket Flags ............................................... 28
+   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 29
+   7.2.2.  Invalid Tickets .......................................... 29
+   7.2.3.  OK as Delegate ........................................... 30
+   7.2.4.  Renewable Tickets ........................................ 30
+   7.2.5.  Postdated Tickets ........................................ 31
+   7.2.6.  Proxiable and Proxy Tickets .............................. 32
+   7.2.7.  Forwarded and Forwardable Tickets ........................ 33
+   7.3.  Transited Realms ........................................... 34
+   7.4.  Authorization Data ......................................... 34
+   7.4.1.  AD-IF-RELEVANT ........................................... 35
+   7.4.2.  AD-KDCIssued ............................................. 35
+   7.4.3.  AD-AND-OR ................................................ 37
+   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 37
+   7.5.  Encrypted Part of Ticket ................................... 37
+   7.6.  Cleartext Part of Ticket ................................... 38
+   8.  Credential Acquisition ....................................... 40
+   8.1.  KDC-REQ .................................................... 40
+   8.2.  PA-DATA .................................................... 46
+   8.3.  KDC-REQ Processing ......................................... 46
+   8.3.1.  Handling Replays ......................................... 46
+   8.3.2.  Request Validation ....................................... 47
+   8.3.2.1.  AS-REQ Authentication .................................. 47
+   8.3.2.2.  TGS-REQ Authentication ................................. 47
+   8.3.2.3.  Principal Validation ................................... 47
+   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 48
+   8.3.3.  Timestamp Handling ....................................... 48
+   8.3.3.1.  AS-REQ Timestamp Processing ............................ 49
+   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 49
+   8.3.4.  Handling Transited Realms ................................ 50
+   8.3.5.  Address Processing ....................................... 50
+   8.3.6.  Ticket Flag Processing ................................... 51
+   8.3.7.  Key Selection ............................................ 52
+   8.3.7.1.  Reply Key and Session Key Selection .................... 52
+   8.3.7.2.  Ticket Key Selection ................................... 52
+   8.4.  KDC-REP .................................................... 52
+   8.5.  Reply Validation ........................................... 55
+   8.6.  IP Transports .............................................. 55
+   8.6.1.  UDP/IP transport ......................................... 55
+   8.6.2.  TCP/IP transport ......................................... 56
+   8.6.3.  KDC Discovery on IP Networks ............................. 57
+   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
+   8.6.3.2.  DNS SRV records for KDC location ....................... 58
+
+Yu                         Expires: Mar 2005                    [Page 3]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
+                Networks ............................................ 58
+   9.  Errors ....................................................... 58
+   10.  Session Key Exchange ........................................ 61
+   10.1.  AP-REQ .................................................... 61
+   10.2.  AP-REP .................................................... 63
+   11.  Session Key Use ............................................. 65
+   11.1.  KRB-SAFE .................................................. 65
+   11.2.  KRB-PRIV .................................................. 65
+   11.3.  KRB-CRED .................................................. 66
+   12.  Security Considerations ..................................... 67
+   12.1.  Time Synchronization ...................................... 67
+   12.2.  Replays ................................................... 67
+   12.3.  Principal Name Reuse ...................................... 67
+   12.4.  Password Guessing ......................................... 67
+   12.5.  Forward Secrecy ........................................... 67
+   12.6.  Authorization ............................................. 68
+   12.7.  Login Authentication ...................................... 68
+   13.  IANA Considerations ......................................... 68
+   14.  Acknowledgments ............................................. 69
+   Appendices ....................................................... 69
+   A.  ASN.1 Module (Normative) ..................................... 69
+   B.  Kerberos and Character Encodings (Informative) ...............103
+   C.  Kerberos History (Informative) ...............................104
+   D.  Notational Differences from [KCLAR] ..........................105
+   Normative References .............................................106
+   Informative References ...........................................106
+   Author's Address .................................................108
+   Copyright Statement ..............................................108
+   Intellectual Property Statement ..................................108
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                    [Page 4]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+1.  Introduction
+
+   The Kerberos network authentication protocol is a trusted-third-party
+   protocol utilizing symmetric-key cryptography.  It assumes that all
+   communications between parties in the protocol may be arbitrarily
+   tampered with or monitored, and that the security of the overall
+   system depends only on the effectiveness of the cryptographic
+   techniques and the secrecy of the cryptographic keys used.  The
+   Kerberos protocol authenticates an application client's identity to
+   an application server, and likewise authenticates the application
+   server's identity to the application client.  These assurances are
+   made possible by the client and the server sharing secrets with the
+   trusted third party: the Kerberos server, also known as the Key
+   Distribution Center (KDC).  In addition, the protocol establishes an
+   ephemeral shared secret (the session key) between the client and the
+   server, allowing the protection of further communications between
+   them.
+
+   The Kerberos protocol, as originally specified, provides insufficient
+   means for extending the protocol in a backwards-compatible way.  This
+   deficiency has caused problems for interoperability.  This document
+   describes a framework which enables backwards-compatible extensions
+   to the Kerberos protocol.
+
+1.1.  Kerberos Protocol Overview
+
+   Kerberos comprises three main sub-protocols: credentials acquisition,
+   session key exchange, and session key usage.  A client acquires
+   credentials by asking the KDC for a credential for a service; the KDC
+   issues the credential, which contains a ticket and a session key.
+   The ticket, containing the client's identity, timestamps, expiration
+   time, and a session key, is a encrypted in a key known to the
+   application server.  The KDC encrypts the credential using a key
+   known to the client, and transmits the credential to the client.
+
+   There are two means of requesting credentials: the Authentication
+   Service (AS) exchange, and the Ticket-Granting Service (TGS)
+   exchange.  In the typical AS exchange, a client uses a password-
+   derived key to decrypt the response.  In the TGS exchange, the KDC
+   behaves as an application server; the client authenticates to the TGS
+   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
+   the TGT by using the AS exchange.
+
+   Session key exchange consists of the client transmitting the ticket
+   to the application server, accompanied by an authenticator.  The
+   authenticator contains a timestamp and additional data encrypted
+   using the ticket's session key.  The application server decrypts the
+   ticket, extracting the session key.  The application server then uses
+   the session key to decrypt the authenticator.  Upon successful
+   decryption of the authenticator, the application server knows that
+   the data in the authenticator were sent by the client named in the
+
+Yu                         Expires: Mar 2005                    [Page 5]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   associated ticket.  Additionally, since authenticators expire more
+   quickly than tickets, the application server has some assurance that
+   the transaction is not a replay.  The application server may send an
+   encrypted acknowledgment to the client, verifying its identity to the
+   client.
+
+   Once session key exchange has occurred, the client and server may use
+   the established session key to protect further traffic.  This
+   protection may consist of protection of integrity only, or of
+   protection of confidentiality and integrity.  Additional measures
+   exist for a client to securely forward credentials to a server.
+
+   The entire scheme depends on loosely synchronized clocks.
+   Synchronization of the clock on the KDC with the application server
+   clock allows the application server to accurately determine whether a
+   credential is expired.  Likewise, synchronization of the clock on the
+   client with the application server clock prevents replay attacks
+   utilizing the same credential.  Careful design of the application
+   protocol may allow replay prevention without requiring client-server
+   clock synchronization.
+
+   After establishing a session key, application client and the
+   application server can exchange Kerberos protocol messages that use
+   the session key to protect the integrity or confidentiality of
+   communications between the client and the server.  Additionally, the
+   client may forward credentials to the application server.
+
+   The credentials acquisition protocol takes place over specific,
+   defined transports (UDP and TCP).  Application protocols define which
+   transport to use for the session key establishment protocol and for
+   messages using the session key; the application may choose to perform
+   its own encapsulation of the Kerberos messages, for example.
+
+1.2.  Document Organization
+
+   The remainder of this document begins by describing the general
+   frameworks for protocol extensibility, including whether to interpret
+   unknown extensions as critical.  It then defines the protocol
+   messages and exchanges.
+
+   The definition of the Kerberos protocol uses Abstract Syntax Notation
+   One (ASN.1) [X680], which specifies notation for describing the
+   abstract content of protocol messages.  This document defines a
+   number of base types using ASN.1; these base types subsequently
+   appear in multiple types which define actual protocol messages.
+   Definitions of principal names and of tickets, which are central to
+   the protocol, also appear preceding the protocol message definitions.
+
+
+
+
+
+Yu                         Expires: Mar 2005                    [Page 6]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+2.  Compatibility Considerations
+
+2.1.  Extensibility
+
+   In the past, significant interoperability problems have resulted from
+   conflicting assumptions about how the Kerberos protocol can be
+   extended.  As the deployed base of Kerberos grows, the ability to
+   extend the Kerberos protocol becomes more important.  In order to
+   ensure that vendors and the IETF can extend the protocol while
+   maintaining backwards compatibility, this document outlines a
+   framework for extending Kerberos.
+
+   Kerberos provides two general mechanisms for protocol extensibility.
+   Many protocol messages, including some defined in RFC 1510, contain
+   typed holes--sub-messages containing an octet string along with an
+   integer that identifies how to interpret the octet string.  The
+   integer identifiers are registered centrally, but can be used both
+   for vendor extensions and for extensions standardized in the IETF.
+   This document adds typed holes to a number of messages which
+   previously lacked typed holes.
+
+   Many new messages defined in this document also contain ASN.1
+   extension markers.  These markers allow future revisions of this
+   document to add additional elements to messages, for cases where
+   typed holes are inadequate for some reason.  Because tag numbers and
+   position in a sequence need to be coordinated in order to maintain
+   interoperability, implementations MUST NOT include ASN.1 extensions
+   except when those extensions are specified by IETF standards-track
+   documents.
+
+2.2.  Compatibility with RFC 1510
+
+   Implementations of RFC 1510 did not use extensible ASN.1 types.
+   Sending additional fields not in RFC 1510 to these implementations
+   results in undefined behavior.  Examples of this behavior are known
+   to include discarding messages with no error indications.
+
+   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
+   are used; one alternative of the CHOICE provides a message which is
+   wire-encoding compatible with RFC 1510, and the other alternative
+   provides the new, extensible message.
+
+   Implementations sending new messages MUST ensure that the recipient
+   supports these new messages.  Along with each extensible message is a
+   guideline for when that message MAY be used.  IF that guideline is
+   followed, then the recipient is guaranteed to understand the message.
+
+2.3.  Backwards Compatibility
+
+   This document describes two sets (for the most part) of ASN.1 types.
+   The first set of types is wire-encoding compatible with RFC 1510 and
+
+Yu                         Expires: Mar 2005                    [Page 7]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   [KCLAR].  The second set of types is the set of types enabling
+   extensibility.  This second set may be referred to as
+   "extensibility-enabled types". [ need to make this consistent
+   throughout? ]
+
+   A major difference between the new extensibility-enabled types and
+   the types for RFC 1510 compatibility is that the extensibility-
+   enabled types allow for the use of UTF-8 encodings in various
+   character strings in the protocol.  Each party in the protocol must
+   have some knowledge of the capabilities of the other parties in the
+   protocol.  There are methods for establishing this knowledge without
+   necessarily requiring explicit configuration.
+
+   An extensibility-enabled client can detect whether a KDC supports the
+   extensibility-enabled types by requesting an extensibility-enabled
+   reply.  If the KDC replies with an extensibility-enabled reply, the
+   client knows that the KDC supports extensibility.  If the KDC issues
+   an extensibility-enabled ticket, the client knows that the service
+   named in the ticket is extensibility-enabled.
+
+2.4.  1.4.2. Sending Extensible Messages
+
+   Care must be taken to make sure that old implementations can
+   understand messages sent to them even if they do not understand an
+   extension that is used.  Unless the sender knows the extension is
+   supported, the extension cannot change the semantics of the core
+   message or previously defined extensions.
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence.  The KDC should
+   only use the extension if this padata element is present in the AS-
+   REQ.  Even if policy requires the use of the extension, it is better
+   to return an error indicating that the extension is required than to
+   use the extension when the recipient may not support it; debugging
+   why implementations do not interoperate is easier when errors are
+   returned.
+
+2.5.  Criticality
+
+   Recipients of unknown message extensions (including typed holes, new
+   flags, and ASN.1 extension elements) should preserve the encoding of
+   the extension but otherwise ignore the presence of the extension;
+   i.e., unknown extensions SHOULD be treated as non-critical.  If a
+   copy of the message is used later--for example, when a Ticket
+   received in a KDC-REP is later used in an AP-REQ--then the unknown
+
+Yu                         Expires: Mar 2005                    [Page 8]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   extensions MUST be included.
+
+   An implementation SHOULD NOT reject a request merely because it does
+   not understand some element of the request.  As a related
+   consequence, implementations SHOULD handle communicating with other
+   implementations which do not implement some requested options.  This
+   may require designers of options to provide means to determine
+   whether an option has been rejected, not understood, or (perhaps
+   maliciously) deleted or modified in transit.
+
+   There is one exception to non-criticality described above: if an
+   unknown authorization data element is received by a server either in
+   an AP-REQ or in a Ticket contained in an AP-REQ, then the
+   authentication SHOULD fail.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether the restriction applies to that service then a security
+   weakness may result if authentication succeeds.  Authorization
+   elements meant to be truly optional can be enclosed in the AD-IF-
+   RELEVANT element.
+
+   Many RFC 1510 implementations ignore unknown authorization data
+   elements.  Depending on these implementations to honor authorization
+   data restrictions may create a security weakness.
+
+2.6.  Authenticating Cleartext Portions of Messages
+
+   Various denial of service attacks and downgrade attacks against
+   Kerberos are possible unless plaintexts are somehow protected against
+   modification.  An early design goal of Kerberos Version 5 was to
+   avoid encrypting more of the authentication exchange that was
+   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
+   in a KDC reply, for example.)  This minimization of encryption
+   reduces the load on the KDC and busy servers.  Also, during the
+   initial design of Version 5, the existence of legal restrictions on
+   the export of cryptography made it desirable to minimize of the
+   number of uses of encryption in the protocol.  Unfortunately,
+   performing this minimization created numerous instances of
+   unauthenticated security-relevant plaintext fields.
+
+   The extensible variants of the messages described in this document
+   wrap the actual message in an ASN.1 sequence containing a keyed
+   checksum of the contents of the message.  Guidelines in [XXX] section
+   3 specify when the checksum MUST be included and what key MUST be
+   used.  Guidelines on when to include a checksum are never ambiguous:
+   a particular PDU is never correct both with and without a checksum.
+   With the exception of the KRB-ERROR message, receiving
+   implementations MUST reject messages where a checksum is included and
+   not expected or where a checksum is expected but not included.  The
+   receiving implementation does not always have sufficient information
+   to know whether a KRB-ERROR should contain a checksum.  Even so,
+   KRB-ERROR messages with invalid checksums MUST be rejected and
+
+Yu                         Expires: Mar 2005                    [Page 9]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   implementations MAY consider the presence or absence of a checksum
+   when evaluating whether to trust the error.
+
+   This authenticated cleartext protection is provided only in the
+   extensible variants of the messages; it is never used when
+   communicating with an RFC 1510 implementation.
+
+2.7.  Capability Negotiation
+
+   Kerberos is a three-party protocol.  Each of the three parties
+   involved needs a means of detecting the capabilities supported by the
+   others.  Two of the parties, the KDC and the application server, do
+   not communicate directly in the Kerberos protocol.  Communicating
+   capabilities from the KDC to the application server requires using a
+   ticket as an intermediary.
+
+   The main capability requiring negotiation is the support of the
+   extensibility framework described in this document.  Negotiation of
+   this capability while remaining compatible with RFC 1510
+   implementations is possible.  The main complication is that the
+   client needs to know whether the application server supports the
+   extensibility framework prior to sending any message to the
+   application server.  This can be accomplished if the KDC has
+   knowledge of whether an application server supports the extensibility
+   framework.
+
+   Client software advertizes its capabilities when requesting
+   credentials from the KDC.  If the KDC recognizes the capabilities, it
+   acknowledges this fact to the client in its reply.  In addition, if
+   the KDC has knowledge that the application server supports certain
+   capabilities, it also communicates this knowledge to the client in
+   its reply.  The KDC can encode its own capabilities in the ticket so
+   that the application server may discover these capabilities.  The
+   client advertizes its capabilities to the application server when it
+   initiates authentication to the application server.
+
+3.  Use of ASN.1 in Kerberos
+
+   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
+   Even though ASN.1 theoretically allows the description of protocol
+   messages to be independent of the encoding rules used to encode the
+   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
+   the semantics of the notation, such as whether tags carry any
+   semantic content to the application, may cause the use of other ASN.1
+   encoding rules to be problematic.
+
+   Implementors not using existing ASN.1 tools (e.g., compilers or
+   support libraries) are cautioned to thoroughly read and understand
+   the actual ASN.1 specification to ensure correct implementation
+   behavior.  There is more complexity in the notation than is
+   immediately obvious, and some tutorials and guides to ASN.1 are
+
+Yu                         Expires: Mar 2005                   [Page 10]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   misleading or erroneous.  Recommended tutorials and guides include
+   [Dub00], [Lar99], though there is still no substitute for reading the
+   actual ASN.1 specification.
+
+3.1.  Module Header
+
+   The type definitions in this document assume an ASN.1 module
+   definition of the following form:
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- Rest of definitions here
+
+      END
+
+   This specifies that the tagging context for the module will be
+   explicit and that automatic tagging is not done.
+
+   Some other publications [RFC1510] [RFC1964] erroneously specify an
+   object identifier (OID) having an incorrect value of "5" for the
+   "dod" component of the OID.  In the case of RFC 1964, use of the
+   "correct" OID value would result in a change in the wire protocol;
+   therefore, the RFC 1964 OID remains unchanged for now.
+
+3.2.  Top-Level Type
+
+   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
+   Data Units or PDUs) which an application may directly reference.
+   Applications SHOULD NOT transmit any types other than those which are
+   alternatives of the KRB-PDU CHOICE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 11]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+3.3.  Previously Unused ASN.1 Notation (informative)
+
+   Some aspects of ASN.1 notation used in this document were not used in
+   [KCLAR], and may be unfamiliar to some readers.  This subsection is
+   informative; for normative definitions of the notation, see the
+   actual ASN.1 specifications [X680], [X682], [X683].
+
+3.3.1.  Parameterized Types
+
+   This document uses ASN.1 parameterized types [X683] to make
+   definitions of types more readable.  For some types, some or all of
+   the parameters are advisory, i.e., they are not encoded in any form
+   for transmission in a protocol message.  These advisory parameters
+   can describe implementation behavior associated with the type.
+
+3.3.2.  COMPONENTS OF Notation
+
+   The "COMPONENTS OF" notation, used to define the RFC 1510
+   compatibility types, extracts all of the component types of an ASN.1
+   SEQUENCE type.  The extension marker (the "..." notation) and any
+   extension components are not extracted by "COMPONENTS OF".  The
+   "COMPONENTS OF" notation permits concise definition of multiple types
+   which have many components in common with each other.
+
+3.3.3.  Constraints
+
+   This document uses ASN.1 constraints, including the
+   "UserDefinedConstraint" notation [X682].  Some constraints can be
+   handled automatically by tools that can parse them.  Uses of the
+
+Yu                         Expires: Mar 2005                   [Page 12]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
+   typically need to have behavior manually coded; the notation provides
+   a formalized way of conveying intended implementation behavior.
+
+   The "WITH COMPONENTS" constraint notation allows constraints to apply
+   to component types of a SEQUENCE type.  This constraint notation
+   effectively allows constraints to "reach into" a type to constrain
+   its component types.
+
+3.4.  New Types
+
+   This document defines a number of ASN.1 types which are new since
+   [KCLAR].  The names of these types will typically have a suffix like
+   "Ext", indicating that the types are intended to support
+   extensibility.  Types original to RFC 1510 and [KCLAR] have been
+   renamed to have a suffix like "1510".  The "Ext" and "1510" types
+   often contain a number of common elements; these common elements have
+   a suffix like "Common".  The "1510" types have various ASN.1
+   constraints applied to them; the constraints limit the possible
+   values of the "1510" types to those permitted by RFC 1510 or by
+   [KCLAR].  The "Ext" types may have different constraints, typically
+   to force string values to be sent as UTF-8.
+
+   For example, consider
+
+      -- example "common" type
+      Foo-Common      ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING,
+          ...,
+          c           [2] INTEGER,
+          ...
+      }
+
+      -- example "RFC 1510 compatibility" type
+      Foo-1510        ::= SEQUENCE {
+          -- the COMPONENTS OF notation drops the extension marker
+          -- and all extension additions.
+          COMPONENTS OF Foo-Common
+      }
+
+      -- example "extensibility-enabled" type
+      Foo-Ext         ::= Foo-Common
+
+   where "Foo-Common" is a common type used to define both the "1510"
+   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
+   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
+   not contain the extension marker, nor does it contain the extension
+   component "c".  The type "Foo-1510" is equivalent to "Foo-1510-
+   Equiv", shown below.
+
+
+Yu                         Expires: Mar 2005                   [Page 13]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- example type equivalent to Foo-1510
+      Foo-1510-Equiv  ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING
+      }
+
+
+4.  Basic Types
+
+   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
+   types.
+
+4.1.  Constrained Integer Types
+
+   In RFC 1510, many types contained references to the unconstrained
+   INTEGER type.  Since an unconstrained INTEGER can contain almost any
+   possible abstract integer value, most of the unconstrained references
+   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
+   [KCLAR].
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+   The "Int32" type often contains an assigned number identifying the
+   contents of a typed hole.  Unless otherwise stated, non-negative
+   values are registered, and negative values are available for local
+   use.
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+   The "UInt32" type is used in some places where an unsigned 32-bit
+   integer is needed.
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+   The "UInt64" type is used in places where 32 bits of precision may
+   provide inadequate security.
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+   Sequence numbers were constrained to 32 bits in [KCLAR], but this
+   document allows for 64-bit sequence numbers.
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+Yu                         Expires: Mar 2005                   [Page 14]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
+   to 64 bits here.
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+   The "microseconds" type is intended to carry the microseconds part of
+   a time value.
+
+4.2.  KerberosTime
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
+   KerberosTime value MUST NOT include any fractional portions of the
+   seconds.  As required by the DER, it further MUST NOT include any
+   separators, and it specifies the UTC time zone (Z).  Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is "19851106210627Z".
+
+4.3.  KerberosString
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+   The KerberosString type is used for character strings in various
+   places in the Kerberos protocol.  For compatibility with RFC 1510,
+   GeneralString values constrained to IA5String (US-ASCII) are
+   permitted in messages exchanged with RFC 1510 implementations.  The
+   new protocol messages contain strings encoded as UTF-8, and these
+   strings MUST be normalized using [SASLPREP].  KerberosString values
+   are present in principal names and in error messages.  Control
+   characters SHOULD NOT be used in principal names, and used with
+   caution in error messages.
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+   KerberosStringIA5 requires the use of the "ia5" alternative, while
+
+Yu                         Expires: Mar 2005                   [Page 15]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   KerberosStringExt forbids it.  These types appear in ASN.1
+   constraints on messages.
+
+   For detailed background regarding the history of character string use
+   in Kerberos, as well as discussion of some compatibility issues, see
+   Appendix B.
+
+4.4.  Language Tags
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+   The "LangTag" type is used to specify language tags for localization
+   purposes, using the [RFC3066] format.
+
+4.5.  KerberosFlags
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+      })
+
+
+   The actual bit string type encoded in Kerberos messages does not use
+   named bits.  The advisory parameter of the KerberosFlags type names a
+   bit string type defined using named bits, whose value is encoded as
+   if it were a bit string with unnamed bits.  This practice is
+   necessary because the DER require trailing zero bits to be removed
+   when encoding bit strings defined using named bits.  Existing
+   implementations of Kerberos send exactly 32 bits rather than
+   truncating, so the size constraint requires the transmission of at
+   least 32 bits.  Trailing zero bits beyond the first 32 bits are
+   truncated.
+
+4.6.  Typed Holes
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+Yu                         Expires: Mar 2005                   [Page 16]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   The "TH-id" type is a generalized means to identify the contents of a
+   typed hole.  The "int32" alternative may be used for simple integer
+   assignments, in the same manner as "Int32", while the "rel-oid"
+   alternative may be used for hierarchical delegation.
+
+4.7.  HostAddress and HostAddresses
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+   addr-type
+        This field specifies the type of address that follows.
+
+   address
+        This field encodes a single address of the type identified by
+        "addr-type".
+
+   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.
+
+
+      addr-type |     meaning
+      __________|______________
+              2 |   IPv4
+              3 |   directional
+             12 |   DECnet
+             20 |   NetBIOS
+             24 |   IPv6
+
+
+
+4.7.1.  Internet (IPv4) Addresses
+
+   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
+   MSB order (most significant byte first). The IPv4 loopback address
+   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
+   two (2).
+
+
+Yu                         Expires: Mar 2005                   [Page 17]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+4.7.2.  Internet (IPv6) Addresses
+
+   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
+   in MSB order (most significant byte first). The type of IPv6
+   addresses is twenty-four (24). The following addresses MUST NOT
+   appear in any Kerberos PDU:
+
+      * the Unspecified Address
+
+      * the Loopback Address
+
+      * Link-Local addresses
+
+   This restriction applies to the inclusion in the address fields of
+   Kerberos PDUs, but not to the address fields of packets that might
+   carry such PDUs.  The restriction is necessary because the use of an
+   address with non-global scope could allow the acceptance of a message
+   sent from a node that may have the same address, but which is not the
+   host intended by the entity that added the restriction.  If the
+   link-local address type needs to be used for communication, then the
+   address restriction in tickets must not be used (i.e. addressless
+   tickets must be used).
+
+   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
+   2.
+
+4.7.3.  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).
+
+4.7.4.  Netbios addresses
+
+   Netbios addresses are 16-octet addresses typically composed of 1 to
+   15 alphanumeric characters and padded with the US-ASCII SPC character
+   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
+   0).  The type of Netbios addresses is twenty (20).
+
+4.7.5.  Directional Addresses
+
+   In many environments, including the sender address in KRB-SAFE and
+   KRB-PRIV messages is undesirable because the addresses may be changed
+   in transport by network address translators. However, if these
+   addresses are removed, the messages may be subject to a reflection
+   attack in which a message is reflected back to its originator. The
+   directional address type provides a way to avoid transport addresses
+   and reflection attacks.  Directional addresses are encoded as four
+   byte unsigned integers in network byte order.  If the message is
+   originated by the party sending the original AP-REQ message, then an
+   address of 0 SHOULD be used. If the message is originated by the
+   party to whom that AP-REQ was sent, then the address 1 SHOULD be
+
+Yu                         Expires: Mar 2005                   [Page 18]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   used.  Applications involving multiple parties can specify the use of
+   other addresses.
+
+   Directional addresses MUST only be used for the sender address field
+   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
+   ticket address or in a AP-REQ message.  This address type SHOULD only
+   be used in situations where the sending party knows that the
+   receiving party supports the address type.  This generally means that
+   directional addresses may only be used when the application protocol
+   requires their support.  Directional addresses are type (3).
+
+5.  Principals
+
+   Principals are participants in the Kerberos protocol.  A "realm"
+   consists of principals in one administrative domain, served by one
+   KDC (or one replicated set of KDCs).  Each principal name has an
+   arbitrary number of components, though typical principal names will
+   only have one or two components.  A principal name is meant to be
+   readable by and meaningful to humans, especially in a realm lacking a
+   centrally adminstered authorization infrastructure.
+
+5.1.  Name Types
+
+   Each PrincipalName has NameType indicating what sort of name it is.
+   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).
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+
+Yu                         Expires: Mar 2005                   [Page 19]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+5.2.  Principal Type Definition
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+   name-type
+        hint of the type of name that follows
+
+   name-string
+        The "name-string" encodes a sequence of components that form a
+        name, each component encoded as a KerberosString.  Taken
+        together, a PrincipalName and a Realm form a principal
+        identifier.  Most PrincipalNames will have only a few components
+        (typically one or two).
+
+5.3.  Principal Name Reuse
+
+   Realm administrators SHOULD use extreme caution when considering
+   reusing a principal name.  A service administrator might explicitly
+   enter principal names into a local access control list (ACL) for the
+   service.  If such local ACLs exist independently of a centrally
+   administered authorization infrastructure, realm administrators
+   SHOULD NOT reuse principal names until confirming that all extant ACL
+   entries referencing that principal name have been updated.  Failure
+   to perform this check can result in a security vulnerability, as a
+   new principal can inadvertently inherit unauthorized privileges upon
+   receiving a reused principal name.  An organization whose Kerberos-
+   authenticated services all use a centrally-adminstered authorization
+   infrastructure may not need to take these precautions regarding
+   principal name reuse.
+
+5.4.  Realm Names
+
+      Realm           ::= KerberosString
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
+   character with the code 0 (the US-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
+
+Yu                         Expires: Mar 2005                   [Page 20]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   the style of X.500 names.
+
+5.5.  Printable Representations of Principal Names
+
+   [ perhaps non-normative? ]
+
+   The printable form of a principal name consists of the concatenation
+   of components of the PrincipalName value using the slash character
+   (/), followed by an at-sign (@), followed by the realm name.  Any
+   occurrence of a backslash (\), slash (/) or at-sign (@) in the
+   PrincipalName value is quoted by a backslash.
+
+5.6.  Ticket-Granting Service Principal
+
+   The PrincipalName value corresponding to a ticket-granting service
+   has two components: the first component is the string "krbtgt", and
+   the second component is the realm name of the TGS which will accept a
+   ticket-granting ticket having this service principal name.  The realm
+   name of service always indicates which realm issued the ticket.  A
+   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
+   obtaining tickets in the same realm would have the following ASN.1
+   values for its "realm" and "sname" components, respectively:
+
+      -- Example Realm and PrincipalName for a TGS
+
+      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
+
+      tgtPrinc1       PrincipalName ::= {
+          name-type nt-srv-inst,
+          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
+      }
+
+   Its printable representation would be written as
+   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
+
+5.6.1.  Cross-Realm TGS Principals
+
+   It is possible for a principal in one realm to authenticate to a
+   service in another realm.  A KDC can issue a cross-realm ticket-
+   granting ticket to allow one of its principals to authenticate to a
+   service in a foreign realm.  For example, the TGS principal
+   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
+   client principal in the realm A.EXAMPLE.COM to authenticate to a
+   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
+   issues a ticket to a client originating in A.EXAMPLE.COM, the
+   client's realm name remains "A.EXAMPLE.COM", even though the service
+   principal will have the realm "B.EXAMPLE.COM".
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 21]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+6.  Types Relating to Encryption
+
+   Many Kerberos protocol messages contain encrypted encodings of
+   various data types.  Some Kerberos protocol messages also contain
+   checksums (signatures) of encodings of various types.
+
+6.1.  Assigned Numbers for Encryption
+
+   Encryption algorithm identifiers and key usages both have assigned
+   numbers, described in [KCRYPTO].
+
+6.1.1.  EType
+
+   EType is the integer type for assigned numbers for encryption
+   algorithms.  Defined in [KCRYPTO].
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+6.1.2.  Key Usages
+
+   KeyUsage is the integer type for assigned numbers for key usages.
+   Key usage values are inputs to the encryption and decryption
+
+Yu                         Expires: Mar 2005                   [Page 22]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   functions described in [KCRYPTO].
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+6.2.  Which Key to Use
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 23]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+6.3.  EncryptionKey
+
+   The "EncryptionKey" type holds an encryption key.
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+   keytype
+        This "EType" identifies the encryption algorithm, described in
+        [KCRYPTO].
+
+   keyvalue
+        Contains the actual key.
+
+6.4.  EncryptedData
+
+   The "EncryptedData" type contains the encryption of another data
+   type.  The recipient uses fields within EncryptedData to determine
+   which key to use for decryption.
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 24]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+   KeyUsages
+        Advisory parameter indicating which key usage to use when
+        encrypting the ciphertext.  If "KeyUsages" indicate multiple
+        "KeyUsage" values, the detailed description of the containing
+        message will indicate which key to use under which conditions.
+
+   Type
+        Advisory parameter indicating the ASN.1 type whose DER encoding
+        is the plaintext encrypted into the EncryptedData.
+
+   Keys
+        Advisory parameter indicating which key to use to perform the
+        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
+        detailed description of the containing message will indicate
+        which key to use under which conditions.
+
+   KeyUsages
+        Advisory parameter indicating which "KeyUsage" value is used to
+        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
+        the detailed description of the containing message will indicate
+        which key usage to use under which conditions.
+
+6.5.  Checksums
+
+   Several types contain checksums (actually signatures) of data.
+
+
+Yu                         Expires: Mar 2005                   [Page 25]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+   CksumType
+        Integer type for assigned numbers for signature algorithms.
+        Defined in [KCRYPTO]
+
+   Keys
+        As in EncryptedData
+
+   KeyUsages
+        As in EncryptedData
+
+   cksumtype
+        Signature algorithm used to produce the signature.
+
+   checksum
+        The actual checksum.
+
+6.5.1.  ChecksumOf
+
+   ChecksumOf is similar to "Checksum", but specifies which type is
+   signed.
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+Yu                         Expires: Mar 2005                   [Page 26]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   Type
+        Indicates the ASN.1 type whose DER encoding is signed.
+
+6.5.2.  Signed
+
+   Signed is similar to "ChecksumOf", but contains an actual instance of
+   the type being signed in addition to the signature.
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+7.  Tickets
+
+   [ A large number of items described here are duplicated in the
+   sections describing KDC-REQ processing.  Should find a way to avoid
+   this duplication. ]
+
+   A ticket binds a principal name to a session key.  The important
+   fields of a ticket are in the encrypted part.  The components in
+   common between the RFC 1510 and the extensible versions are
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+   crealm
+        This field contains the client's realm.
+
+   cname
+        This field contains the client's name.
+
+Yu                         Expires: Mar 2005                   [Page 27]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   caddr
+        This field lists the network addresses (if absent, all addresses
+        are permitted) from which the ticket is valid.
+
+   Descriptions of the other fields appear in the following sections.
+
+7.1.  Timestamps
+
+   Three of the ticket timestamps may be requested from the KDC.  The
+   timestamps may differ from those requested, depending on site policy.
+
+   authtime
+        The time at which the client authenticated, as recorded by the
+        KDC.
+
+   starttime
+        The earliest time when the ticket is valid.  If not present, the
+        ticket is valid starting at the authtime.  This is requested as
+        the "from" field of KDC-REQ-BODY-COMMON.
+
+   endtime
+        This time is requested in the "till" field of KDC-REQ-BODY-
+        COMMON.  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 time is requested in the "rtime" field of KDC-REQ-BODY-
+        COMMON.  It 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.
+
+7.2.  Ticket Flags
+
+   A number of flags may be set in the ticket, further defining some of
+   its capabilities.  Some of these flags map to flags in a KDC request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 28]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+7.2.1.  Flags Relating to Initial Ticket Acquisition
+
+   [ adapted KCLAR 2.1. ]
+
+   Several flags indicate the details of how the initial ticket was
+   acquired.
+
+   initial
+        The "initial" flag indicates that a ticket was issued using the
+        AS protocol, rather than issued based on a ticket-granting
+        ticket.  Application servers (e.g., a password-changing program)
+        requiring a client's definite knowledge of its secret key can
+        insist that this flag be set in any tickets they accept, thus
+        being assured that the client's key was recently presented to
+        the application client.
+
+   pre-authent
+        The "pre-authent" flag indicates that some sort of pre-
+        authentication was used during the AS exchange.
+
+   hw-authent
+        The "hw-authent" flag indicates that some sort of hardware-based
+        pre-authentication occurred during the AS exchange.
+
+   Both the "pre-authent" and the "hw-authent" flags may be present with
+   or without the "initial" flag; such tickets with the "initial" flag
+   clear are ones which are derived from initial tickets with the "pre-
+   authent" or "hw-authent" flags set.
+
+
+Yu                         Expires: Mar 2005                   [Page 29]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+7.2.2.  Invalid Tickets
+
+   [ KCLAR 2.2. ]
+
+   The "invalid" flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets which have this flag set.  A postdated
+   ticket will 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 8.3.2.4).
+
+7.2.3.  OK as Delegate
+
+   [ KCLAR 2.8. ]
+
+   The "ok-as-delegate" flag provides a way for a KDC to communicate
+   local realm policy to a client regarding whether the service for
+   which the ticket is issued is trusted to accept delegated
+   credentials.  For some applications, a client may need to delegate
+   credentials to a service to act on its behalf in contacting other
+   services.  The ability of a client to obtain a service ticket for a
+   service conveys no information to the client about whether the
+   service should be trusted to accept delegated credentials.
+
+   The copy of the ticket flags visible to the client may have the "ok-
+   as-delegate" flag set to indicate to the client that the service
+   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 service.  It is acceptable 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.
+
+7.2.4.  Renewable Tickets
+
+   [ adapted KCLAR 2.3. ]
+
+   The "renewable" flag indicates whether the ticket may be renewed.
+
+   Renewable tickets can be used to mitigate the consequences of ticket
+   theft.  Applications may desire to hold credentials which can be
+   valid for long periods of time.  However, this can expose the
+   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
+
+Yu                         Expires: Mar 2005                   [Page 30]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   periodically would require the application to have long-term access
+   to the client's secret key, which is an even greater risk.
+
+   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 present an unexpired renewable ticket to the
+   KDC, setting the "renew" option 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.  It can usually be ignored by application
+   servers.  However, some particularly careful application servers MAY
+   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 clear by default,
+   but a client can request it be set by setting the "renewable" option
+   in the 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.
+
+7.2.5.  Postdated Tickets
+
+   postdated
+        indicates a ticket which has been postdated
+
+   may-postdate
+        indicates that postdated tickets may be issued based on this
+        ticket
+
+   [ KCLAR 2.4. ]
+
+   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.
+
+
+
+Yu                         Expires: Mar 2005                   [Page 31]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   The "may-postdate" flag in a ticket is normally only interpreted by
+   the TGS.  It can be ignored by application servers.  This flag MUST
+   be set in a ticket-granting ticket in order for the KDC 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 AS-REQ [?also TGS-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 AS-REQ message.  The life (endtime minus
+   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 minus 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 for
+   validation before use.
+
+7.2.6.  Proxiable and Proxy Tickets
+
+   proxy
+        indicates a proxy ticket
+
+   proxiable
+        indicates that proxy tickets may be issued based on this ticket
+
+   [ KCLAR 2.5. ]
+
+   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, users wishing to delegate their
+   identity in a form usable for all purposes 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
+
+Yu                         Expires: Mar 2005                   [Page 32]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   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 may contain a set of network addresses from which they are
+   valid.  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.
+
+7.2.7.  Forwarded and Forwardable Tickets
+
+   forwarded
+        indicates a forwarded ticket
+
+   forwardable
+        indicates that forwarded tickets may be issued based on this
+        ticket
+
+   [ KCLAR 2.6. ]
+
+   Authentication forwarding is an instance of a proxy where the service
+   that is granted is 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
+
+Yu                         Expires: Mar 2005                   [Page 33]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   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.
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+7.3.  Transited Realms
+
+   [ KCLAR 2.7., plus new stuff ]
+
+7.4.  Authorization Data
+
+   [ KCLAR 5.2.6. ]
+
+      ADType          ::= TH-id
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+   ad-type
+        This field identifies the contents of the ad-data.  All negative
+        values are reserved for local use.  Non-negative values are
+        reserved for registered use.
+
+   ad-data
+        This field contains authorization data to be interpreted
+        according to the value of the corresponding ad-type field.
+
+   Each sequence of ADType and OCTET STRING is referred 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
+   AuthorizationData, and the interpretation of the encapsulating
+   element determines which enclosed elements must be interpreted, and
+   which may be ignored.
+
+   Depending on the meaning of the encapsulating element, the
+   encapsulated AuthorizationData may be ignored, interpreted as issued
+   directly by the KDC, or be stored in a separate plaintext part of the
+   ticket.  The types of the encapsulating elements are specified as
+
+Yu                         Expires: Mar 2005                   [Page 34]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   part of the Kerberos protocol because behavior based on these
+   container elements should be understood across implementations, while
+   other elements need only be understood by the applications which they
+   affect.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator.  Unless encapsulated in a known
+   authorization data element modifying the criticality of the elements
+   it contains, an application server MUST reject the authentication of
+   a client whose AP-REQ or ticket contains an unrecognized
+   authorization data element.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether it is the target of a restriction, a security weakness may
+   exist if the ticket can be used for that service.  Authorization
+   elements that are truly optional can be enclosed in AD-IF-RELEVANT
+   element.
+
+
+      ad-type |           contents of ad-data
+      ________|_______________________________________
+            1 |   DER encoding of AD-IF-RELEVANT
+            4 |   DER encoding of AD-KDCIssued
+            5 |   DER encoding of AD-AND-OR
+            8 |   DER encoding of AD-MANDATORY-FOR-KDC
+
+
+
+7.4.1.  AD-IF-RELEVANT
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      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.  The ad-type for AD-IF-RELEVANT is (1).
+
+7.4.2.  AD-KDCIssued
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 35]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+   ad-checksum
+        A cryptographic checksum computed over the DER encoding of the
+        AuthorizationData in the "elements" field, keyed with the
+        session key.  Its checksumtype is the mandatory checksum type
+        for the encryption type of the session key, and its key usage
+        value is 19.
+
+   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
+        AuthorizationData issued by the KDC.
+
+   The KDC-issued ad-data field is intended to provide a means for
+   Kerberos credentials to embed within themselves privilege attributes
+   and other mechanisms for positive authorization, amplifying the
+   privileges of the principal beyond what it would have if using
+   credentials without such an authorization-data element.
+
+   This amplification of privileges cannot 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).  AuthorizationData encapsulated with in the
+   AD-KDCIssued element MUST be ignored by the application server if
+   this "signature" is not present.  Further, AuthorizationData
+   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
+
+Yu                         Expires: Mar 2005                   [Page 36]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   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 encapsulates MAY be safely ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+7.4.3.  AD-AND-OR
+
+      ad-and-or               ADType ::= int32 : 5
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisfied.  Therefore, 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.
+
+   The ad-type for AD-AND-OR is (5).
+
+7.4.4.  AD-MANDATORY-FOR-KDC
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+   be interpreted by the KDC.  KDCs that do not understand the type of
+   an element embedded within the mandatory-for-kdc element MUST reject
+   the request.
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+7.5.  Encrypted Part of Ticket
+
+   The complete definition of the encrypted part is
+
+
+Yu                         Expires: Mar 2005                   [Page 37]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+   with the common portion being
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+   The encrypted part of the backwards-compatibility form of a ticket
+   is:
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+   The encrypted part of the extensible form of a ticket is:
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 38]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+7.6.  Cleartext Part of Ticket
+
+   The complete definition of Ticket is:
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+   with the common portion being:
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+   The "sname" field provides the name of the target service principal
+   in cleartext, as a hint to aid the server in choosing the correct
+   decryption key.
+
+   The backwards-compatibility form of Ticket is:
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+   The extensible form of Ticket is:
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 39]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+   TicketExtensions, which may only be present in the extensible form of
+   Ticket, are a cleartext typed hole for extension use.
+   AuthorizationData already provides an encrypted typed hole.
+
+      TEType                  ::= TH-id
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+   A client will only receive an extensible Ticket if the application
+   server supports extensibility.
+
+8.  Credential Acquisition
+
+   There are two exchanges that can be used for acquiring credentials:
+   the AS exchange and the TGS exchange.  These exchanges have many
+   similarities, and this document describes them in parallel, noting
+   which behaviors are specific to one type of exchange.  The AS request
+   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
+   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
+   are forms of KDC replies (KDC-REP).
+
+   The credentials acquisition protocol operates over specific
+   transports.  Additionally, specific methods exist to permit a client
+   to discover the KDC host with which to communicate.
+
+8.1.  KDC-REQ
+
+   The KDC-REQ has a large number of fields in common between the RFC
+   1510 and the extensible versions.  The KDC-REQ type itself is never
+   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 40]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
+   an EncTicketPartCommon.  The KDC copies most of them unchanged,
+   provided that the requested values meet site policy.
+
+Yu                         Expires: Mar 2005                   [Page 41]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   kdc-options
+        These flags do not correspond directly to "flags" in
+        EncTicketPartCommon.
+
+   cname
+        This field is copied to the "cname" field in
+        EncTicketPartCommon.  The "cname" field is required in an AS-
+        REQ; the client places its own name here.  In a TGS-REQ, the
+        "cname" in the ticket in the AP-REQ takes precedence.
+
+   realm
+        This field is the server's realm, and also holds the client's
+        realm in an AS-REQ.
+
+   sname
+        The "sname" field indicates the server's name.  It may be absent
+        in a TGS-REQ which requests user-to-user authentication, in
+        which case the "sname" of the issued ticket will be taken from
+        the included additional ticket.
+
+   The "from", "till", and "rtime" fields correspond to the "starttime",
+   "endtime", and "renew-till" fields of EncTicketPartCommon.
+
+   addresses
+        This field corresponds to the "caddr" field of
+        EncTicketPartCommon.
+
+   enc-authorization-data
+        For TGS-REQ, this field contains authorization data encrypted
+        using either the TGT session key or the AP-REQ subsession key;
+        the KDC may copy these into the "authorization-data" field of
+        EncTicketPartCommon if policy permits.
+
+   lang-tags
+        Only present in the extensible messages.  Specifies the set of
+        languages which the client is willing to accept in error
+        messages.
+
+   KDC options used in a KDC-REQ are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 42]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+   Different options apply to different phases of KDC-REQ processing.
+
+   The backwards-compatibility form of a KDC-REQ is:
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+   The extensible form of a KDC-REQ is:
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+   The backwards-compatibility form of a KDC-REQ-BODY is:
+
+Yu                         Expires: Mar 2005                   [Page 43]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+   The extensible form of a KDC-REQ-BODY is:
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+   The AS-REQ is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 44]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
+   if the client does not know that the KDC supports the extensibility
+   framework.  A client SHOULD send the extensible AS-REQ alternative in
+   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
+   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
+   what if their contents conflict? ]
+
+   The TGS-REQ is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 45]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+8.2.  PA-DATA
+
+   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
+   authenticate an AS-REQ; they may also modify several of the
+   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
+   to the client about which long-term key (usually password-derived) to
+   use.  PA-DATA may also include "hints" about which pre-authentication
+   mechanisms to use, or include data for input into a pre-
+   authentication mechanism.
+
+   [ XXX enumerate standard padata here ]
+
+8.3.  KDC-REQ Processing
+
+   Processing of a KDC-REQ proceeds through several steps.  An
+   implementation need not perform these steps exactly as described, as
+   long as it behaves as if the steps were performed as described.  The
+   KDC performs replay handling upon receiving the request; it then
+   validates the request, adjusts timestamps, and selects the keys used
+   in the reply.  It copies data from the request into the issued
+   ticket, adjusting the values to conform with its policies.  The KDC
+   then transmits the reply to the client.
+
+8.3.1.  Handling Replays
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+
+Yu                         Expires: Mar 2005                   [Page 46]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   successfully processed, the KDC MUST respond with a KDC-REP message
+   rather than a replay error.  In order to reduce the amount of
+   ciphertext given to a potential attacker, KDCs MAY send the same
+   response generated when the request was first handled.  KDCs MUST
+   obey this replay behavior even if the actual transport in use is
+   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
+   and the entire request is not identical to a recently successfully
+   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
+   appropriate for AP-REQ processing.
+
+8.3.2.  Request Validation
+
+8.3.2.1.  AS-REQ Authentication
+
+   Site policy determines whether a given client principal is required
+   to provide some pre-authentication prior to receiving an AS-REP.
+   Since the default reply key is typically the client's long-term
+   password-based key, an attacker may easily request known plaintext
+   (in the form of an AS-REP) upon which to mount a dictionary attack.
+   Pre-authentication can limit the possibility of such an attack.
+
+   If site policy requires pre-authentication for a client principal,
+   and no pre-authentication is provided, the KDC returns the error
+   "kdc-err-preauth-required".  Accompanying this error are "e-data"
+   which include hints telling the client which pre-authentication
+   mechanisms to use, or data for input to pre-authentication mechanisms
+   (e.g., input to challenge-response systems).  If pre-authentication
+   fails, the KDC returns the error "kdc-err-preauth-failed".
+
+   [ may need additional changes based on Sam's preauth draft ]
+
+8.3.2.2.  TGS-REQ Authentication
+
+   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
+   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
+   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
+   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
+   request.  [ padata not signed by authenticator! ] Any error from the
+   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
+   The service principal in the ticket of the AP-REQ may be a ticket-
+   granting service principal, or a normal application service
+   principal.  A ticket which is not a ticket-granting ticket MUST NOT
+   be used to issue a ticket for any service other than the one named in
+   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
+   forwarded?]  option must be set in the request.
+
+8.3.2.3.  Principal Validation
+
+   If the client principal in an AS-REQ is unknown, the KDC returns the
+   error "kdc-err-c-principal-unknown".  If the server principal in a
+   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
+
+Yu                         Expires: Mar 2005                   [Page 47]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   unknown".
+
+8.3.2.4.  Checking For Revoked or Invalid Tickets
+
+   [ KCLAR 3.3.3.1 ]
+
+   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 to the KDC for the realm in which
+   the server resides.  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.  If TGTs have been issued for cross-realm authentication, use
+   of the cross-realm TGT will not be affected unless the hot-list is
+   propagated to the KDCs for the realms for which such cross-realm
+   tickets were issued.
+
+   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
+   issue any ticket unless the TGS-REQ requests the "validate" option.
+
+8.3.3.  Timestamp Handling
+
+   [ some aspects of timestamp handling, especially regarding postdating
+   and renewal, are difficult to read in KCLAR... needs closer
+   examination here ]
+
+   Processing of "starttime" (requested in the "from" field) differs
+   depending on whether the "postdated" option is set in the request.
+   If the "postdated" option is not set, and the requested "starttime"
+   is in the future beyond the window of acceptable clock skew, the KDC
+   returns the error "kdc-err-cannot-postdate".  If the "postdated"
+   option is not set, and the requested "starttime" is absent or does
+   not indicate a time in the future beyond the acceptable clock skew,
+   the KDC sets the "starttime" to the KDC's current time.  The
+   "postdated" option MUST NOT be honored if the ticket is being
+   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
+   Otherwise, if the "postdated" option is set, and site policy permits,
+   the KDC sets the "starttime" as requested, and sets the "invalid"
+   flag in the new ticket.
+
+   The "till" field is required in the RFC 1510 version of the KDC-REQ.
+   If the "till" field is equal to "19700101000000Z" (midnight, January
+   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
+
+   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
+   "renew-till" time is later than the "renew-till" time of the ticket
+
+Yu                         Expires: Mar 2005                   [Page 48]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   from which it is derived.
+
+8.3.3.1.  AS-REQ Timestamp Processing
+
+   In the AS exchange, the "authtime" of a ticket is set to the local
+   time at the KDC.
+
+   The "endtime" of the ticket will be set to the earlier of the
+   requested "till" time and a time determined by local policy, possibly
+   determined using factors specific to the realm or principal.  For
+   example, the expiration time MAY be set to the earliest of the
+   following:
+
+      * the expiration time ("till" value) requested
+
+      * the ticket's start time plus the maximum allowable lifetime
+        associated with the client principal from the authentication
+        server's database
+
+      * 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.
+
+   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 MAY be set to the earliest 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
+
+8.3.3.2.  TGS-REQ Timestamp Processing
+
+   In the TGS exchange, the KDC sets the "authtime" to that of the
+   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
+   server can print a ticket for itself with a spoofed authtime.
+
+Yu                         Expires: Mar 2005                   [Page 49]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   security issues for hot-list?] [ MIT implementation may change
+   authtime of renewed tickets; needs check... ]
+
+   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
+   requests an "endtime" (in the "till" field), then the "endtime" of
+   the new ticket is set to the minimum of
+
+      * the requested "endtime" value,
+
+      * the "endtime" in the TGT, and
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+   If the new ticket is a renewal, the "endtime" of the new ticket is
+   bounded by the minimum of
+
+      * the requested "endtime" value,
+
+      * the value of the "renew-till" value of the old,
+
+      * the "starttime" of the new ticket plus the lifetime (endtime
+        minus starttime) of the old ticket, i.e., the lifetime of the
+        new ticket may not exceed that of the ticket being renewed [
+        adapted from KCLAR 3.3.3. ], and
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
+   a "starttime", "endtime", or "renew-till" time later than the
+   "renew-till" time of the TGT.
+
+8.3.4.  Handling Transited Realms
+
+   The KDC checks the ticket in a TGS-REQ against site policy, unless
+   the "disable-transited-check" option is set in the TGS-REQ.  If site
+   policy permits the transit path in the TGS-REQ ticket, the KDC sets
+   the "transited-policy-checked" flag in the issued ticket.  If the
+   "disable-transited-check" option is set, the issued ticket will have
+   the "transited-policy-checked" flag cleared.
+
+8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
+   copied into the issued ticket.  If the "addresses" field is absent or
+   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
+   TGS-REQ into the issued ticket, unless the either "forwarded" or
+   "proxy" option is set.  If the "forwarded" option is set, and the
+   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
+   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
+   issued ticket.  The KDC behaves similarly if the "proxy" option is
+   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
+   The "proxy" option will not be honored on requests for additional
+   ticket-granting tickets.
+
+Yu                         Expires: Mar 2005                   [Page 50]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+8.3.6.  Ticket Flag Processing
+
+   Many kdc-options request that the KDC set a corresponding flag in the
+   issued ticket.  kdc-options marked with an asterisk (*) in the
+   following table do not directly request the corresponding ticket flag
+   and therefore require special handling.
+
+
+             kdc-option       |    ticket flag affected
+      ________________________|__________________________
+      forwardable             |  forwardable
+      forwarded               |  forwarded
+      proxiable               |  proxiable
+      proxy                   |  proxy
+      allow-postdate          |  may-postdate
+      postdated               |  postdated
+      renewable               |  renewable
+      requestanonymous        |  anonymous
+      canonicalize            |  -
+      disable-transited-check*|  transited-policy-checked
+      renewable-ok*           |  renewable
+      enc-tkt-in-skey         |  -
+      renew                   |  -
+      validate*               |  invalid
+
+
+
+   forwarded
+        The KDC sets the "forwarded" flag in the issued ticket if the
+        "forwarded" option is set in the TGS-REQ and the "forwardable"
+        flag is set in the TGS-REQ ticket.
+
+   proxy
+        The KDC sets the "proxy" flag in the issued ticket if the
+        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
+        set in the TGS-REQ ticket.
+
+   disable-transited-check
+        The handling of the "disable-transited-check" kdc-option is
+        described in Section 8.3.4.
+
+   renewable-ok
+        The handling of the "renewable-ok" kdc-option is described in
+        Section 8.3.3.1.
+
+   enc-tkt-in-skey
+        This flag modifies ticket key selection to use the session key
+        of an additional ticket included in the TGS-REQ, for the purpose
+        of user-to-user authentication.
+
+
+
+Yu                         Expires: Mar 2005                   [Page 51]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   validate
+        If the "validate" kdc-option is set in a TGS-REQ, and the
+        "starttime" has passed, the KDC will clear the "invalid" bit on
+        the ticket before re-issuing it.
+
+8.3.7.  Key Selection
+
+   Three keys are involved in creating a KDC-REP.  The reply key
+   encrypts the encrypted part of the KDC-REP.  The session key is
+   stored in the encrypted part of the ticket, and is also present in
+   the encrypted part of the KDC-REP so that the client can retrieve it.
+   The ticket key is used to encrypt the ticket.  These keys all have
+   initial values for a given exchange; pre-authentication and other
+   extension mechanisms may change the value used for any of these keys.
+
+   [ again, may need changes based on Sam's preauth draft ]
+
+8.3.7.1.  Reply Key and Session Key Selection
+
+   The set of encryption types which the client will understand appears
+   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
+   of possible reply keys and the set of session key encryption types
+   based on the "etype" field.
+
+   For the AS exchange, the reply key is initially a long-term key of
+   the client, limited to those encryption types listed in the "etype"
+   field.  The KDC SHOULD use the first valid strong "etype" for which
+   an encryption key is available.  For the TGS exchange, the reply key
+   is initially the subsession key of the Authenticator.  If the
+   Authenticator subsesion key is absent, the reply key is initially the
+   session key of the ticket used to authenticate the TGS-REQ.
+
+   The session key is initially randomly generated, and has an
+   encryption type which both the client and the server will understand.
+   Typically, the KDC has prior knowledge of which encryption types the
+   server will understand.  It selects the first valid strong "etype"
+   listed the request which the server also will understand.
+
+8.3.7.2.  Ticket Key Selection
+
+   The ticket key is initially the long-term key of the service.  The
+   "enc-tkt-in-skey" option requests user-to-user authentication, where
+   the ticket encryption key of the issued ticket is set equal to the
+   session key of the additional ticket in the request.
+
+8.4.  KDC-REP
+
+   The important parts of the KDC-REP are encrypted.
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 52]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+   Most of the fields of EncKDCRepPartCom are duplicates of the
+   corresponding fields in the returned ticket.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 53]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 54]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+   req-cksum
+        Signature of the original request using the reply key, to avoid
+        replay attacks against the client, among other things.  Only
+        present in the extensible version of KDC-REP.
+
+           AS-REP          ::= CHOICE {
+               rfc1510     [APPLICATION 11] KDC-REP-1510 {
+                   EncASRepPart1510
+               } (WITH COMPONENTS { ..., msg-type (11) }),
+               ext         [APPLICATION  7]  Signed {
+                   [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+                   { key-reply }, { ku-ASRep-cksum }
+               } (WITH COMPONENTS { ..., msg-type (7) })
+           }
+
+
+           TGS-REP         ::= CHOICE {
+               rfc1510     [APPLICATION 13] KDC-REP-1510 {
+                   EncTGSRepPart1510
+               } (WITH COMPONENTS { ..., msg-type (13) }),
+               ext         [APPLICATION  9]  Signed {
+                   [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+                   { key-reply }, { ku-TGSRep-cksum }
+               } (WITH COMPONENTS { ..., msg-type (9) })
+           }
+
+
+   The extensible versions of AS-REQ and TGS-REQ are signed with the
+   reply key, to prevent an attacker from performing a delayed denial-
+   of-service attack by substituting the ticket.
+
+8.5.  Reply Validation
+
+   [ signature verification ]
+
+8.6.  IP Transports
+
+   [ KCLAR 7.2 ]
+
+   Kerberos defines two IP transport mechanisms for the credentials
+   acquisition protocol: UDP/IP and TCP/IP.
+
+
+Yu                         Expires: Mar 2005                   [Page 55]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+8.6.1.  UDP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
+   identify the IP address and port to which they will send their
+   request.
+
+   When contacting a 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 the KDC. The KDC will respond with a reply
+   datagram containing only an encoding of the reply message (either a
+   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
+   address. The response to a request made through UDP/IP transport MUST
+   also use UDP/IP transport. If the response can not be handled using
+   UDP (for example because it is too large), the KDC MUST return "krb-
+   err-response-too-big", forcing the client to retry the request using
+   the TCP transport.
+
+8.6.2.  TCP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   initially try a request using the UDP transport. Clients SHOULD use
+   KDC discovery (Section 8.6.3) to identify the IP address and port to
+   which they will send their request.
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+   When the KDC-REQ message is sent to the KDC over a TCP stream, the
+   response (KDC-REP or KRB-ERROR message) MUST be returned to the
+   client on the same TCP stream that was established for the request.
+   The KDC MAY close the TCP stream after sending a response, but MAY
+   leave the stream open for a reasonable period of time if it expects a
+   followup. Care must be taken in managing TCP/IP connections on the
+   KDC to prevent denial of service attacks based on the number of open
+   TCP/IP connections.
+
+
+Yu                         Expires: Mar 2005                   [Page 56]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   anytime after the receipt of a response.  A stream closure SHOULD NOT
+   be treated as a fatal error.  Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication) the client may
+   need to establish a new connection when it is ready to send
+   subsequent messages.  A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   followup messages.
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
+   the TCP stream is preceded by the length of the request as 4 octets
+   in network byte order. The high bit of the length is reserved for
+   future expansion and MUST currently be set to zero.  If a KDC that
+   does not understand how to interpret a set high bit of the length
+   encoding receives a request with the high order bit of the length
+   set, it MUST return a KRB-ERROR message with the error "krb-err-
+   field-toolong" and MUST close the TCP stream.
+
+   If multiple requests are sent over a single TCP connection, and the
+   KDC sends multiple responses, the KDC is not required to send the
+   responses in the order of the corresponding requests.  This may
+   permit some implementations to send each response as soon as it is
+   ready even if earlier requests are still being processed (for
+   example, waiting for a response from an external device or database).
+
+8.6.3.  KDC Discovery on IP Networks
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored 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 using cross-realm authentication. This section
+   describes a method for using the Domain Name System [RFC 1035] for
+   storing KDC location information.
+
+8.6.3.1.  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
+   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
+   and "MyRealm" are all different, but resolve the same in the domain
+   name system, it is necessary that only one of the possible
+   combinations of upper and lower case characters be used in realm
+
+Yu                         Expires: Mar 2005                   [Page 57]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   names.
+
+8.6.3.2.  DNS SRV records for KDC location
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2782].  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 one of "udp", "tcp". If these SRV records are to be
+   used, both "udp" and "tcp" records MUST be specified for all KDC
+   deployments.
+
+   The Realm is the Kerberos realm that this record corresponds to.  The
+   realm MUST be a domain style realm name.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2782.
+
+   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal) unless the KDC is configured
+   to listen on an alternate TCP port.
+
+   Implementation note: Many existing client implementations do not
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority.  Weights are not used in these sample records.
+
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+
+
+9.  Errors
+
+   The KRB-ERROR message is returned by the KDC if an error occurs
+   during credentials acquisition.  It may also be returned by an
+   application server if an error occurs during authentication.
+
+
+
+Yu                         Expires: Mar 2005                   [Page 58]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+   The extensible KRB-ERROR is only signed if there has been a key
+   negotiated with its recipient.  KRB-ERROR messages sent in response
+   to AS-REQ messages will probably not be signed unless a
+   preauthentication mechanism has negotiated a key.  (Signing using a
+   client's long-term key can expose ciphertext to dictionary attacks.)
+
+   The parts of a KRB-ERROR common to both the backwards-compatibility
+   and the extensibile messages are
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+Yu                         Expires: Mar 2005                   [Page 59]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   ctime, cusec
+        Client's time, if known from a KDC-REQ or AP-REQ.
+
+   stime, susec
+        KDC or application server's current time.
+
+   error-code
+        Numeric error code designating the error.
+
+   crealm, cname
+        Client's realm and name, if known.
+
+   realm, sname
+        server's realm and name. [ XXX what if these aren't known? ]
+
+   e-text
+        Human-readable text providing additional details for the error.
+
+   e-data
+        This field contains additional data about the error for use by
+        the client to help it recover from or handle the error. If the
+        "error-code" is "kdc-err-preauth-required", then the e-data
+        field will contain an encoding of a sequence of padata fields,
+        each corresponding to an acceptable pre-authentication method
+        and optionally containing data for the method:
+
+           METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+        For error codes defined in this document other than "kdc-err-
+        preauth-required", the format and contents of the e-data field
+        are implementation-defined.  Similarly, for future error codes,
+        the format and contents of the e-data field are implementation-
+        defined unless specified.
+
+   lang-tag
+        Indicates the language of the message in the "e-text" field.  It
+        is only present in the extensible KRB-ERROR.
+
+   nonce
+        is the nonce from a KDC-REQ.  It is only present in the
+        extensible KRB-ERROR.
+
+   typed-data
+        TYPED-DATA is a typed hole allowing for additional data to be
+        returned in error conditions, since "e-data" is insufficiently
+        flexible for some purposes.  TYPED-DATA is only present in the
+        extensible KRB-ERROR.
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 60]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+           TDType ::= TH-id
+
+           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+               data-type   [0] TDType,
+               data-value  [1] OCTET STRING OPTIONAL
+           }
+
+
+10.  Session Key Exchange
+
+   Session key exchange consists of the AP-REQ and AP-REP messages.  The
+   client sends the AP-REQ message, and the service responds with an
+   AP-REP message if mutual authentication is desired.  Following
+   session key exchange, the client and service share a secret session
+   key, or possibly a subsesion key, which can be used to protect
+   further communications.  Additionally, the session key exchange
+   process can establish initial sequence numbers which the client and
+   service can use to detect replayed messages.
+
+10.1.  AP-REQ
+
+   An AP-REQ message contains a ticket and a authenticator.  The
+   authenticator is ciphertext encrypted with the session key contained
+   in the ticket.  The plaintext contents of the authenticator are:
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+   The common parts between the RFC 1510 and the extensible versions of
+   the AP-REQ are:
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 61]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+   The complete definition of AP-REQ is:
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 62]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+10.2.  AP-REP
+
+   An AP-REP message provides mutual authentication of the service to
+   the client.
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+Yu                         Expires: Mar 2005                   [Page 63]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+
+Yu                         Expires: Mar 2005                   [Page 64]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+11.  Session Key Use
+
+   Once a session key has been established, the client and server can
+   use several kinds of messages to securely transmit data.  KRB-SAFE
+   provides integrity protection for application data, while KRB-PRIV
+   provides confidentiality along with integrity protection.  The KRB-
+   CRED message provides a means of securely forwarding credentials from
+   the client host to the server host.
+
+11.1.  KRB-SAFE
+
+   The KRB-SAFE message provides integrity protection for an included
+   cleartext message.
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+11.2.  KRB-PRIV
+
+   The KRB-PRIV message provides confidentiality and integrity
+   protection.
+
+
+Yu                         Expires: Mar 2005                   [Page 65]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+11.3.  KRB-CRED
+
+   The KRB-CRED message provides a means of securely transferring
+   credentials from the client to the service.
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+
+Yu                         Expires: Mar 2005                   [Page 66]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+12.  Security Considerations
+
+12.1.  Time Synchronization
+
+   Time synchronization between the KDC and application servers is
+   necessary to prevent acceptance of expired tickets.
+
+   Time synchronization is needed between application servers and
+   clients to prevent replay attacks if a replay cache is being used.
+   If negotiated subsession keys are used to encrypt application data,
+   replay caches may not be necessary.
+
+12.2.  Replays
+
+12.3.  Principal Name Reuse
+
+   See Section 5.3.
+
+12.4.  Password Guessing
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 67]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+12.5.  Forward Secrecy
+
+   [from KCLAR 10.; needs some rewriting]
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB-PRIV message,
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the TGS-REP
+   message.  The session key from the ticket-granting ticket was sent to
+   the user in the AS-REP message encrypted in the user's secret key,
+   and embedded in the ticket-granting ticket, which was encrypted in
+   the key of the KDC.  Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+12.6.  Authorization
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  Kerberos does not, by
+   itself, provide authorization.  Applications SHOULD NOT accept the
+   mere issuance of a service ticket by the Kerberos server as granting
+   authority to use the service.
+
+12.7.  Login Authentication
+
+   Some applications, particularly those which provide login access when
+   provided with a password, SHOULD NOT treat successful acquisition of
+   credentials as sufficient proof of the user's identity.  An attacker
+   posing as a user could generate an illegitimate KDC-REP message which
+   decrypts properly.  To authenticate a user logging on to a local
+   system, the credentials obtained SHOULD be used in a TGS exchange to
+   obtain credentials for a local service.  Successful use of those
+   credentials to authenticate to the local service assures that the
+   initially obtained credentials are from a valid KDC.
+
+13.  IANA Considerations
+
+   [ needs more work ]
+
+   Each use of Int32 in this document defines a number space.  [ XXX
+   enumerate these ] Negative numbers are reserved for private use;
+   local and experimental extensions should use these values.  Zero is
+   reserved and may not be assigned.
+
+
+Yu                         Expires: Mar 2005                   [Page 68]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   Typed hole contents may be identified by either Int32 values or by
+   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
+   namespace, assignments to the top level of the RELATIVE-OID space may
+   be made on a first-come, first-served basis.
+
+14.  Acknowledgments
+
+   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
+   clarifications-07.  The description of the general form of the
+   extensibility framework was derived from text by Sam Hartman.
+
+Appendices
+
+A.  ASN.1 Module (Normative)
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related
+      -- OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
+      -- OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2)
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 69]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+      --
+      -- *** basic types
+      --
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+Yu                         Expires: Mar 2005                   [Page 70]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 71]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+      -- IA5 only
+      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringIA5))
+      })
+
+      -- IA5 excluded
+      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringExt))
+      })
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 72]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      Realm           ::= KerberosString
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+      })
+
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+      --
+      -- *** crypto-related types and assignments
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 73]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 74]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 75]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 76]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 77]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+      --
+      -- *** Tickets
+      --
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+Yu                         Expires: Mar 2005                   [Page 78]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 79]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+      --
+      -- *** Authorization Data
+      --
+
+
+      ADType          ::= TH-id
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      AD-IF-RELEVANT          ::= AuthorizationData
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 80]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+      ad-and-or               ADType ::= int32 : 5
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+
+      TrType                  ::= TH-id -- must be registered
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+          tr-type     [0] TrType,
+          contents    [1] OCTET STRING
+      }
+
+
+      TEType                  ::= TH-id
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 81]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+      --
+      -- *** KDC protocol
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 82]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 83]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 84]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 85]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 86]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AS-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 11] KDC-REP-1510 {
+              EncASRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (11) }),
+          ext         [APPLICATION  7]  Signed {
+              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+              { key-reply }, { ku-ASRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (7) })
+      }
+
+
+      TGS-REP         ::= CHOICE {
+          rfc1510     [APPLICATION 13] KDC-REP-1510 {
+              EncTGSRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (13) }),
+          ext         [APPLICATION  9]  Signed {
+              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+              { key-reply }, { ku-TGSRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (9) })
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 87]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 88]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 89]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      LRType          ::=     TH-id
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+          lr-type     [0] LRType,
+          lr-value    [1] KerberosTime
+      }
+
+
+      --
+      -- *** preauth
+      --
+
+
+      PaDataType      ::= TH-id
+      PaDataOID       ::= RELATIVE-OID
+
+      PA-DATA ::= SEQUENCE {
+          -- NOTE: first tag is [1], not [0]
+          padata-type         [1] PaDataType,
+          padata-value        [2] OCTET STRING
+      }
+
+
+      -- AP-REQ authenticating a TGS-REQ
+      pa-tgs-req              PaDataType ::= int32 : 1
+      PA-TGS-REQ              ::= AP-REQ
+
+
+      -- Encrypted timestamp preauth
+      -- Encryption key used is client's long-term key.
+      pa-enc-timestamp        PaDataType ::= int32 : 2
+
+      PA-ENC-TIMESTAMP ::= EncryptedData {
+          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
+      }
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 90]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Hints returned in AS-REP or KRB-ERROR to help client
+      -- choose a password-derived key, either for preauthentication
+      -- or for decryption of the reply.
+      pa-etype-info           PaDataType ::= int32 : 11
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+
+      -- Similar to etype-info, but with parameters provided for
+      -- the string-to-key function.
+      pa-etype-info2          PaDataType ::= int32 : 19
+
+      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
+                                      OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+
+      -- Obsolescent.  Salt for client's long-term key.
+      -- Its character encoding is unspecified.
+      pa-pw-salt              PaDataType ::= int32 : 3
+      -- The "padata-value" does not encode an ASN.1 type.
+      -- Instead, "padata-value" must consist of the salt string to
+      -- be used by the client, in an unspecified character
+      -- encoding.
+
+
+      -- An extensible AS-REQ may be sent as a padata in a
+      -- non-extensible AS-REQ to allow for backwards compatibility.
+      pa-as-req               PaDataType ::= int32 : 42 -- provisional
+      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
+
+
+      --
+      -- *** Session key exchange
+      --
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 91]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 92]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      ApReqExtType    ::= TH-id
+
+      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apReqExt-Type       [0] ApReqExtType,
+          apReqExt-Data       [1] OCTET STRING
+      }
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 93]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+      ApRepExtType    ::= TH-id
+
+      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apRepExt-Type       [0] ApRepExtType,
+          apRepExt-Data       [1] OCTET STRING
+      }
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 94]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Application messages
+      --
+
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 95]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 96]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 97]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
+          pvno            [0] INTEGER (5),
+          msg-type        [1] INTEGER (16),
+          sname           [2] PrincipalName OPTIONAL,
+          srealm          [3] Realm OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Error messages
+      --
+
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 98]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+      TDType ::= TH-id
+
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+          data-type   [0] TDType,
+          data-value  [1] OCTET STRING OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                   [Page 99]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      --
+      -- *** Error codes
+      --
+
+      -- No error
+      kdc-err-none                          ErrCode ::= 0
+      -- Client's entry in database has expired
+      kdc-err-name-exp                      ErrCode ::= 1
+      -- Server's entry in database has expired
+      kdc-err-service-exp                   ErrCode ::= 2
+      -- Requested protocol version number not supported
+      kdc-err-bad-pvno                      ErrCode ::= 3
+      -- Client's key encrypted in old master key
+      kdc-err-c-old-mast-kvno               ErrCode ::= 4
+      -- Server's key encrypted in old master key
+      kdc-err-s-old-mast-kvno               ErrCode ::= 5
+      -- Client not found in Kerberos database
+      kdc-err-c-principal-unknown           ErrCode ::= 6
+      -- Server not found in Kerberos database
+      kdc-err-s-principal-unknown           ErrCode ::= 7
+      -- Multiple principal entries in database
+      kdc-err-principal-not-unique          ErrCode ::= 8
+      -- The client or server has a null key
+      kdc-err-null-key                      ErrCode ::= 9
+      -- Ticket not eligible for postdating
+      kdc-err-cannot-postdate               ErrCode ::= 10
+      -- Requested start time is later than end time
+      kdc-err-never-valid                   ErrCode ::= 11
+      -- KDC policy rejects request
+      kdc-err-policy                        ErrCode ::= 12
+      -- KDC cannot accommodate requested option
+      kdc-err-badoption                     ErrCode ::= 13
+      -- KDC has no support for encryption type
+      kdc-err-etype-nosupp                  ErrCode ::= 14
+      -- KDC has no support for checksum type
+      kdc-err-sumtype-nosupp                ErrCode ::= 15
+      -- KDC has no support for padata type
+      kdc-err-padata-type-nosupp            ErrCode ::= 16
+      -- KDC has no support for transited type
+      kdc-err-trtype-nosupp                 ErrCode ::= 17
+      -- Clients credentials have been revoked
+      kdc-err-client-revoked                ErrCode ::= 18
+      -- Credentials for server have been revoked
+      kdc-err-service-revoked               ErrCode ::= 19
+      -- TGT has been revoked
+      kdc-err-tgt-revoked                   ErrCode ::= 20
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                  [Page 100]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Client not yet valid - try again later
+      kdc-err-client-notyet                 ErrCode ::= 21
+      -- Server not yet valid - try again later
+      kdc-err-service-notyet                ErrCode ::= 22
+      -- Password has expired - change password to reset
+      kdc-err-key-expired                   ErrCode ::= 23
+      -- Pre-authentication information was invalid
+      kdc-err-preauth-failed                ErrCode ::= 24
+      -- Additional pre-authenticationrequired
+      kdc-err-preauth-required              ErrCode ::= 25
+      -- Requested server and ticket don't match
+      kdc-err-server-nomatch                ErrCode ::= 26
+      -- Server principal valid for user2user only
+      kdc-err-must-use-user2user            ErrCode ::= 27
+      -- KDC Policy rejects transited path
+      kdc-err-path-not-accpeted             ErrCode ::= 28
+      -- A service is not available
+      kdc-err-svc-unavailable               ErrCode ::= 29
+      -- Integrity check on decrypted field failed
+      krb-ap-err-bad-integrity              ErrCode ::= 31
+      -- Ticket expired
+      krb-ap-err-tkt-expired                ErrCode ::= 32
+      -- Ticket not yet valid
+      krb-ap-err-tkt-nyv                    ErrCode ::= 33
+      -- Request is a replay
+      krb-ap-err-repeat                     ErrCode ::= 34
+      -- The ticket isn't for us
+      krb-ap-err-not-us                     ErrCode ::= 35
+      -- Ticket and authenticator don't match
+      krb-ap-err-badmatch                   ErrCode ::= 36
+      -- Clock skew too great
+      krb-ap-err-skew                       ErrCode ::= 37
+      -- Incorrect net address
+      krb-ap-err-badaddr                    ErrCode ::= 38
+      -- Protocol version mismatch
+      krb-ap-err-badversion                 ErrCode ::= 39
+      -- Invalid msg type
+      krb-ap-err-msg-type                   ErrCode ::= 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                  [Page 101]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Message stream modified
+      krb-ap-err-modified                   ErrCode ::= 41
+      -- Message out of order
+      krb-ap-err-badorder                   ErrCode ::= 42
+      -- Specified version of key is not available
+      krb-ap-err-badkeyver                  ErrCode ::= 44
+      -- Service key not available
+      krb-ap-err-nokey                      ErrCode ::= 45
+      -- Mutual authentication failed
+      krb-ap-err-mut-fail                   ErrCode ::= 46
+      -- Incorrect message direction
+      krb-ap-err-baddirection               ErrCode ::= 47
+      -- Alternative authentication method required
+      krb-ap-err-method                     ErrCode ::= 48
+      -- Incorrect sequence number in message
+      krb-ap-err-badseq                     ErrCode ::= 49
+      -- Inappropriate type of checksum in message
+      krb-ap-err-inapp-cksum                ErrCode ::= 50
+      -- Policy rejects transited path
+      krb-ap-path-not-accepted              ErrCode ::= 51
+      -- Response too big for UDP, retry with TCP
+      krb-err-response-too-big              ErrCode ::= 52
+      -- Generic error (description in e-text)
+      krb-err-generic                       ErrCode ::= 60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Mar 2005                  [Page 102]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+      -- Field is too long for this implementation
+      krb-err-field-toolong                 ErrCode ::= 61
+      -- Reserved for PKINIT
+      kdc-error-client-not-trusted          ErrCode ::= 62
+      -- Reserved for PKINIT
+      kdc-error-kdc-not-trusted             ErrCode ::= 63
+      -- Reserved for PKINIT
+      kdc-error-invalid-sig                 ErrCode ::= 64
+      -- Reserved for PKINIT
+      kdc-err-key-too-weak                  ErrCode ::= 65
+      -- Reserved for PKINIT
+      kdc-err-certificate-mismatch          ErrCode ::= 66
+      -- No TGT available to validate USER-TO-USER
+      krb-ap-err-no-tgt                     ErrCode ::= 67
+      -- USER-TO-USER TGT issued different KDC
+      kdc-err-wrong-realm                   ErrCode ::= 68
+      -- Ticket must be for USER-TO-USER
+      krb-ap-err-user-to-user-required      ErrCode ::= 69
+      -- Reserved for PKINIT
+      kdc-err-cant-verify-certificate       ErrCode ::= 70
+      -- Reserved for PKINIT
+      kdc-err-invalid-certificate           ErrCode ::= 71
+      -- Reserved for PKINIT
+      kdc-err-revoked-certificate           ErrCode ::= 72
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unknown     ErrCode ::= 73
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unavailable ErrCode ::= 74
+
+
+      END
+
+
+B.  Kerberos and Character Encodings (Informative)
+
+   [adapted from KCLAR 5.2.1]
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO 2022 | ECMA-35
+   [ISO2022] to switch character sets, and the default character set
+   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
+   International Reference Version (IRV) (aka U.S. ASCII), which mostly
+   works.
+
+   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER previously
+   [X690-1997] prohibited the designation of character sets as any but
+   the G0 and C0 sets.  This had the side effect of prohibiting the use
+
+Yu                         Expires: Mar 2005                  [Page 103]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
+   other character-sets that utilize a 96-character set, since it is
+   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
+   element.  Recent revisions to the ASN.1 standards resolve this
+   contradiction.
+
+   In practice, many implementations treat RFC 1510 GeneralStrings as if
+   they were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to conform to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   [the following should probably be rewritten and moved into the
+   principal name section]
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way.  Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters.  This is a violation of the ASN.1
+   standard.  Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard.  As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+
+Yu                         Expires: Mar 2005                  [Page 104]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+C.  Kerberos History (Informative)
+
+   [Adapted from KCLAR "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 Ts'o, 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 [KNT94].
+
+D.  Notational Differences from [KCLAR]
+
+   [ possible point for discussion ]
+
+   [KCLAR] uses notational conventions slightly different from this
+   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
+   language style identifier names for defined values.  In ASN.1
+   notation, identifiers referencing defined values must begin with a
+   lowercase letter and contain hyphen (-) characters rather than
+   underscore (_) characters, while identifiers referencing types begin
+   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
+   identifiers with underscores to identify defined values.  This has
+   the potential to create confusion, but neither document defines
+   values using actual ASN.1 value-assignment notation.
+
+   It is debatable whether it is advantageous to write all identifier
+   names (regardless of their ASN.1 token type) in all-uppercase letters
+   for the purpose of emphasis in running text.  The alternative is to
+
+Yu                         Expires: Mar 2005                  [Page 105]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   use double-quote characters (") when ambiguity is possible.
+
+Normative References
+
+   [ISO646]
+        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
+
+   [ISO2022]
+        "Information technology -- Character code structure and
+        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
+
+   [KCRYPTO]
+        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
+        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
+
+   [RFC2119]
+        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+        Requirement Levels", March 1997.
+
+   [RFC3660]
+        H. Alvestrand, "Tags for the Identification of Languages",
+        RFC 3660, January 2001.
+
+   [SASLPREP]
+        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
+        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
+        progress.
+
+   [X680]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Specification of basic notation", ITU-T Recommendation X.680
+        (2002) | ISO/IEC 8824-1:2002.
+
+   [X682]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Constraint specification", ITU-T Recommendation X.682 (2002) |
+        ISO/IEC 8824-3:2002.
+
+   [X683]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Parameterization of ASN.1 specifications", ITU-T Recommendation
+        X.683 (2002) | ISO/IEC 8824-4:2002.
+
+   [X690]
+        "Information technology -- ASN.1 encoding Rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+
+
+
+Yu                         Expires: Mar 2005                  [Page 106]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+Informative References
+
+   [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).
+
+   [Dub00]
+        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
+        Systems", Elsevier-Morgan Kaufmann, 2000.
+        <http://www.oss.com/asn1/dubuisson.html>
+
+   [ISO8859-1]
+        "Information technology -- 8-bit single-byte coded graphic
+        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
+        1:1998.
+
+   [KCLAR]
+        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
+        Network Authentication Service (V5)", draft-ietf-krb-wg-
+        kerberos-clarifications-07.txt, work in progress.
+
+   [KNT94]
+        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+        Evolution of the Kerberos Authentication System".  In
+        Distributed Open Systems, pages 78-94.  IEEE Computer Society
+        Press, 1994.
+
+   [Lar96]
+        John Larmouth, "Understanding OSI", International Thomson
+        Computer Press, 1996.
+        <http://www.isi.salford.ac.uk/books/osi.html>
+
+   [Lar99]
+        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
+        1999.  <http://www.oss.com/asn1/larmouth.html>
+
+   [NS78]
+        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+        Authentication in Large Networks of Computers", Communications
+        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+   [RFC1510]
+        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
+        Service (v5)", RFC1510, September 1993, Status: Proposed
+        Standard.
+
+   [RFC1964]
+        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
+        June 1996, Status: Proposed Standard.
+
+
+Yu                         Expires: Mar 2005                  [Page 107]
+
+Internet-Draft               rfc1510ter-01                   15 Sep 2005
+
+   [X690-2002]
+        "Information technology -- ASN.1 encoding rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+Author's Address
+
+   Tom Yu
+   77 Massachusetts Ave
+   Cambridge, MA 02139
+   USA
+   tlyu@mit.edu
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Yu                         Expires: Mar 2005                  [Page 108]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt
new file mode 100644
index 00000000000..009e8bd2bb5
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt
@@ -0,0 +1,6217 @@
+
+
+INTERNET-DRAFT                                                    Tom Yu
+draft-ietf-krb-wg-rfc1510ter-03.txt                                  MIT
+Expires: 26 Apr 2006                                     23 October 2006
+
+        The Kerberos Network Authentication Service (Version 5)
+
+Status of This Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).  All Rights Reserved.
+
+Abstract
+
+   This document describes version 5 of the Kerberos network
+   authentication protocol.  It describes a framework to allow for
+   extensions to be made to the protocol without creating
+   interoperability problems.
+
+Key Words for Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in RFC 2119.
+
+
+
+
+Yu                         Expires: Apr 2007                    [Page 1]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+Table of Contents
+
+   Status of This Memo ..............................................  1
+   Copyright Notice .................................................  1
+   Abstract .........................................................  1
+   Key Words for Requirements .......................................  1
+   Table of Contents ................................................  2
+   1.  Introduction .................................................  5
+   1.1.  Kerberos Protocol Overview .................................  5
+   1.2.  Document Organization ......................................  6
+   2.  Compatibility Considerations .................................  6
+   2.1.  Extensibility ..............................................  7
+   2.2.  Compatibility with RFC 1510 ................................  7
+   2.3.  Backwards Compatibility ....................................  7
+   2.4.  Sending Extensible Messages ................................  8
+   2.5.  Criticality ................................................  8
+   2.6.  Authenticating Cleartext Portions of Messages ..............  9
+   2.7.  Capability Negotiation ..................................... 10
+   2.7.1.  KDC protocol ............................................. 10
+   2.7.2.  Application protocol ..................................... 11
+   2.8.  Strings .................................................... 11
+   3.  Use of ASN.1 in Kerberos ..................................... 11
+   3.1.  Module Header .............................................. 12
+   3.2.  Top-Level Type ............................................. 12
+   3.3.  Previously Unused ASN.1 Notation (informative) ............. 13
+   3.3.1.  Parameterized Types ...................................... 13
+   3.3.2.  Constraints .............................................. 13
+   3.4.  New Types .................................................. 13
+   4.  Basic Types .................................................. 14
+   4.1.  Constrained Integer Types .................................. 14
+   4.2.  KerberosTime ............................................... 15
+   4.3.  KerberosString ............................................. 15
+   4.4.  Language Tags .............................................. 16
+   4.5.  KerberosFlags .............................................. 16
+   4.6.  Typed Holes ................................................ 17
+   4.7.  HostAddress and HostAddresses .............................. 17
+   4.7.1.  Internet (IPv4) Addresses ................................ 18
+   4.7.2.  Internet (IPv6) Addresses ................................ 18
+   4.7.3.  DECnet Phase IV addresses ................................ 18
+   4.7.4.  Netbios addresses ........................................ 18
+   4.7.5.  Directional Addresses .................................... 18
+   5.  Principals ................................................... 19
+   5.1.  Name Types ................................................. 19
+   5.2.  Principal Type Definition .................................. 20
+   5.3.  Principal Name Reuse ....................................... 21
+   5.4.  Best Common Practice Recommendations for the Processing
+            of Principal Names Consisting of Internationalized
+            Domain Names:  .......................................... 21
+   5.5.  Realm Names ................................................ 22
+   5.6.  Best Common Practice Recommendations for the Processing
+            of Internationalized Domain-Style Realm Names:  ......... 22
+
+Yu                         Expires: Apr 2007                    [Page 2]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   5.7.  Printable Representations of Principal Names ............... 23
+   5.8.  Ticket-Granting Service Principal .......................... 23
+   5.8.1.  Cross-Realm TGS Principals ............................... 24
+   6.  Types Relating to Encryption ................................. 24
+   6.1.  Assigned Numbers for Encryption ............................ 24
+   6.1.1.  EType .................................................... 24
+   6.1.2.  Key Usages ............................................... 25
+   6.2.  Which Key to Use ........................................... 26
+   6.3.  EncryptionKey .............................................. 27
+   6.4.  EncryptedData .............................................. 27
+   6.5.  Checksums .................................................. 28
+   6.5.1.  ChecksumOf ............................................... 29
+   6.5.2.  Signed ................................................... 30
+   7.  Tickets ...................................................... 30
+   7.1.  Timestamps ................................................. 31
+   7.2.  Ticket Flags ............................................... 32
+   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 32
+   7.2.2.  Invalid Tickets .......................................... 33
+   7.2.3.  OK as Delegate ........................................... 33
+   7.2.4.  Renewable Tickets ........................................ 34
+   7.2.5.  Postdated Tickets ........................................ 34
+   7.2.6.  Proxiable and Proxy Tickets .............................. 35
+   7.2.7.  Forwarded and Forwardable Tickets ........................ 36
+   7.3.  Transited Realms ........................................... 37
+   7.4.  Authorization Data ......................................... 37
+   7.4.1.  AD-IF-RELEVANT ........................................... 38
+   7.4.2.  AD-KDCIssued ............................................. 39
+   7.4.3.  AD-AND-OR ................................................ 40
+   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 40
+   7.5.  Encrypted Part of Ticket ................................... 41
+   7.6.  Cleartext Part of Ticket ................................... 41
+   8.  Credential Acquisition ....................................... 43
+   8.1.  KDC-REQ .................................................... 43
+   8.2.  PA-DATA .................................................... 50
+   8.3.  KDC-REQ Processing ......................................... 50
+   8.3.1.  Handling Replays ......................................... 50
+   8.3.2.  Request Validation ....................................... 51
+   8.3.2.1.  AS-REQ Authentication .................................. 51
+   8.3.2.2.  TGS-REQ Authentication ................................. 51
+   8.3.2.3.  Principal Validation ................................... 51
+   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 51
+   8.3.3.  Timestamp Handling ....................................... 52
+   8.3.3.1.  AS-REQ Timestamp Processing ............................ 52
+   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 53
+   8.3.4.  Handling Transited Realms ................................ 54
+   8.3.5.  Address Processing ....................................... 54
+   8.3.6.  Ticket Flag Processing ................................... 54
+   8.3.7.  Key Selection ............................................ 56
+   8.3.7.1.  Reply Key and Session Key Selection .................... 56
+   8.3.7.2.  Ticket Key Selection ................................... 56
+   8.4.  KDC-REP .................................................... 56
+
+Yu                         Expires: Apr 2007                    [Page 3]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   8.5.  Reply Validation ........................................... 60
+   8.6.  IP Transports .............................................. 60
+   8.6.1.  UDP/IP transport ......................................... 60
+   8.6.2.  TCP/IP transport ......................................... 60
+   8.6.3.  KDC Discovery on IP Networks ............................. 62
+   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 62
+   8.6.3.2.  DNS SRV records for KDC location ....................... 62
+   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
+                Networks ............................................ 63
+   9.  Errors ....................................................... 63
+   10.  Session Key Exchange ........................................ 65
+   10.1.  AP-REQ .................................................... 66
+   10.2.  AP-REP .................................................... 67
+   11.  Session Key Use ............................................. 69
+   11.1.  KRB-SAFE .................................................. 69
+   11.2.  KRB-PRIV .................................................. 69
+   11.3.  KRB-CRED .................................................. 70
+   12.  Security Considerations ..................................... 71
+   12.1.  Time Synchronization ...................................... 71
+   12.2.  Replays ................................................... 71
+   12.3.  Principal Name Reuse ...................................... 72
+   12.4.  Password Guessing ......................................... 72
+   12.5.  Forward Secrecy ........................................... 72
+   12.6.  Authorization ............................................. 72
+   12.7.  Login Authentication ...................................... 72
+   13.  IANA Considerations ......................................... 72
+   14.  Acknowledgments ............................................. 73
+   Appendices ....................................................... 73
+   A.  ASN.1 Module (Normative) ..................................... 73
+   B.  Kerberos and Character Encodings (Informative) ...............105
+   C.  Kerberos History (Informative) ...............................107
+   D.  Notational Differences from [KCLAR] ..........................107
+   Normative References .............................................108
+   Informative References ...........................................109
+   Author's Address .................................................110
+   Copyright Statement ..............................................110
+   Intellectual Property Statement ..................................110
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                    [Page 4]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+1.  Introduction
+
+   The Kerberos network authentication protocol is a trusted-third-party
+   protocol utilizing symmetric-key cryptography.  It assumes that all
+   communications between parties in the protocol may be arbitrarily
+   tampered with or monitored, and that the security of the overall
+   system depends only on the effectiveness of the cryptographic
+   techniques and the secrecy of the cryptographic keys used.  The
+   Kerberos protocol authenticates an application client's identity to
+   an application server, and likewise authenticates the application
+   server's identity to the application client.  These assurances are
+   made possible by the client and the server sharing secrets with the
+   trusted third party: the Kerberos server, also known as the Key
+   Distribution Center (KDC).  In addition, the protocol establishes an
+   ephemeral shared secret (the session key) between the client and the
+   server, allowing the protection of further communications between
+   them.
+
+   The Kerberos protocol, as originally specified, provides insufficient
+   means for extending the protocol in a backwards-compatible way.  This
+   deficiency has caused problems for interoperability.  This document
+   describes a framework which enables backwards-compatible extensions
+   to the Kerberos protocol.
+
+1.1.  Kerberos Protocol Overview
+
+   Kerberos comprises three main sub-protocols: credentials acquisition,
+   session key exchange, and session key usage.  A client acquires
+   credentials by asking the KDC for a credential for a service; the KDC
+   issues the credential, which contains a ticket and a session key.
+   The ticket, containing the client's identity, timestamps, expiration
+   time, and a session key, is a encrypted in a key known to the
+   application server.  The KDC encrypts the credential using a key
+   known to the client, and transmits the credential to the client.
+
+   There are two means of requesting credentials: the Authentication
+   Service (AS) exchange, and the Ticket-Granting Service (TGS)
+   exchange.  In the typical AS exchange, a client uses a password-
+   derived key to decrypt the response.  In the TGS exchange, the KDC
+   behaves as an application server; the client authenticates to the TGS
+   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
+   the TGT by using the AS exchange.
+
+   Session key exchange consists of the client transmitting the ticket
+   to the application server, accompanied by an authenticator.  The
+   authenticator contains a timestamp and additional data encrypted
+   using the ticket's session key.  The application server decrypts the
+   ticket, extracting the session key.  The application server then uses
+   the session key to decrypt the authenticator.  Upon successful
+   decryption of the authenticator, the application server knows that
+   the data in the authenticator were sent by the client named in the
+
+Yu                         Expires: Apr 2007                    [Page 5]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   associated ticket.  Additionally, since authenticators expire more
+   quickly than tickets, the application server has some assurance that
+   the transaction is not a replay.  The application server may send an
+   encrypted acknowledgment to the client, verifying its identity to the
+   client.
+
+   Once session key exchange has occurred, the client and server may use
+   the established session key to protect further traffic.  This
+   protection may consist of protection of integrity only, or of
+   protection of confidentiality and integrity.  Additional measures
+   exist for a client to securely forward credentials to a server.
+
+   The entire scheme depends on loosely synchronized clocks.
+   Synchronization of the clock on the KDC with the application server
+   clock allows the application server to accurately determine whether a
+   credential is expired.  Likewise, synchronization of the clock on the
+   client with the application server clock prevents replay attacks
+   utilizing the same credential.  Careful design of the application
+   protocol may allow replay prevention without requiring client-server
+   clock synchronization.
+
+   After establishing a session key, application client and the
+   application server can exchange Kerberos protocol messages that use
+   the session key to protect the integrity or confidentiality of
+   communications between the client and the server.  Additionally, the
+   client may forward credentials to the application server.
+
+   The credentials acquisition protocol takes place over specific,
+   defined transports (UDP and TCP).  Application protocols define which
+   transport to use for the session key establishment protocol and for
+   messages using the session key; the application may choose to perform
+   its own encapsulation of the Kerberos messages, for example.
+
+1.2.  Document Organization
+
+   The remainder of this document begins by describing the general
+   frameworks for protocol extensibility, including whether to interpret
+   unknown extensions as critical.  It then defines the protocol
+   messages and exchanges.
+
+   The definition of the Kerberos protocol uses Abstract Syntax Notation
+   One (ASN.1) [X680], which specifies notation for describing the
+   abstract content of protocol messages.  This document defines a
+   number of base types using ASN.1; these base types subsequently
+   appear in multiple types which define actual protocol messages.
+   Definitions of principal names and of tickets, which are central to
+   the protocol, also appear preceding the protocol message definitions.
+
+
+
+
+
+Yu                         Expires: Apr 2007                    [Page 6]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+2.  Compatibility Considerations
+
+2.1.  Extensibility
+
+   In the past, significant interoperability problems have resulted from
+   conflicting assumptions about how the Kerberos protocol can be
+   extended.  As the deployed base of Kerberos grows, the ability to
+   extend the Kerberos protocol becomes more important.  In order to
+   ensure that vendors and the IETF can extend the protocol while
+   maintaining backwards compatibility, this document outlines a
+   framework for extending Kerberos.
+
+   Kerberos provides two general mechanisms for protocol extensibility.
+   Many protocol messages, including some defined in RFC 1510, contain
+   typed holes--sub-messages containing an octet string along with an
+   integer that identifies how to interpret the octet string.  The
+   integer identifiers are registered centrally, but can be used both
+   for vendor extensions and for extensions standardized in the IETF.
+   This document adds typed holes to a number of messages which
+   previously lacked typed holes.
+
+   Many new messages defined in this document also contain ASN.1
+   extension markers.  These markers allow future revisions of this
+   document to add additional elements to messages, for cases where
+   typed holes are inadequate for some reason.  Because tag numbers and
+   position in a sequence need to be coordinated in order to maintain
+   interoperability, implementations MUST NOT include ASN.1 extensions
+   except when those extensions are specified by IETF standards-track
+   documents.
+
+2.2.  Compatibility with RFC 1510
+
+   Implementations of RFC 1510 did not use extensible ASN.1 types.
+   Sending additional fields not in RFC 1510 to these implementations
+   results in undefined behavior.  Examples of this behavior are known
+   to include discarding messages with no error indications.
+
+   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
+   are used; one alternative of the CHOICE provides a message which is
+   wire-encoding compatible with RFC 1510, and the other alternative
+   provides the new, extensible message.
+
+   Implementations sending new messages MUST ensure that the recipient
+   supports these new messages.  Along with each extensible message is a
+   guideline for when that message MAY be used.  If that guideline is
+   followed, then the recipient is guaranteed to understand the message.
+
+2.3.  Backwards Compatibility
+
+   This document describes two sets (for the most part) of ASN.1 types.
+   The first set of types is wire-encoding compatible with RFC 1510 and
+
+Yu                         Expires: Apr 2007                    [Page 7]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   [KCLAR].  The second set of types is the set of types enabling
+   extensibility.  This second set may be referred to as
+   "extensibility-enabled types". [ need to make this consistent
+   throughout? ]
+
+   A major difference between the new extensibility-enabled types and
+   the types for RFC 1510 compatibility is that the extensibility-
+   enabled types allow for the use of UTF-8 encodings in various
+   character strings in the protocol.  Each party in the protocol must
+   have some knowledge of the capabilities of the other parties in the
+   protocol.  There are methods for establishing this knowledge without
+   necessarily requiring explicit configuration.
+
+   An extensibility-enabled client can detect whether a KDC supports the
+   extensibility-enabled types by requesting an extensibility-enabled
+   reply.  If the KDC replies with an extensibility-enabled reply, the
+   client knows that the KDC supports extensibility.  If the KDC issues
+   an extensibility-enabled ticket, the client knows that the service
+   named in the ticket is extensibility-enabled.
+
+2.4.  Sending Extensible Messages
+
+   Care must be taken to make sure that old implementations can
+   understand messages sent to them even if they do not understand an
+   extension that is used.  Unless the sender knows the extension is
+   supported, the extension cannot change the semantics of the core
+   message or previously defined extensions.
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence.  The KDC should
+   only use the extension if this padata element is present in the AS-
+   REQ.  Even if policy requires the use of the extension, it is better
+   to return an error indicating that the extension is required than to
+   use the extension when the recipient may not support it; debugging
+   why implementations do not interoperate is easier when errors are
+   returned.
+
+2.5.  Criticality
+
+   Recipients of unknown message extensions (including typed holes, new
+   flags, and ASN.1 extension elements) should preserve the encoding of
+   the extension but otherwise ignore the presence of the extension;
+   i.e., unknown extensions SHOULD be treated as non-critical.  If a
+   copy of the message is used later--for example, when a Ticket
+   received in a KDC-REP is later used in an AP-REQ--then the unknown
+
+Yu                         Expires: Apr 2007                    [Page 8]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   extensions MUST be included.
+
+   An implementation SHOULD NOT reject a request merely because it does
+   not understand some element of the request.  As a related
+   consequence, implementations SHOULD handle communicating with other
+   implementations which do not implement some requested options.  This
+   may require designers of options to provide means to determine
+   whether an option has been rejected, not understood, or (perhaps
+   maliciously) deleted or modified in transit.
+
+   There is one exception to non-criticality described above: if an
+   unknown authorization data element is received by a server either in
+   an AP-REQ or in a Ticket contained in an AP-REQ, then the
+   authentication SHOULD fail.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether the restriction applies to that service then a security
+   weakness may result if authentication succeeds.  Authorization
+   elements meant to be truly optional can be enclosed in the AD-IF-
+   RELEVANT element.
+
+   Many RFC 1510 implementations ignore unknown authorization data
+   elements.  Depending on these implementations to honor authorization
+   data restrictions may create a security weakness.
+
+2.6.  Authenticating Cleartext Portions of Messages
+
+   Various denial of service attacks and downgrade attacks against
+   Kerberos are possible unless plaintexts are somehow protected against
+   modification.  An early design goal of Kerberos Version 5 was to
+   avoid encrypting more of the authentication exchange that was
+   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
+   in a KDC reply, for example.)  This minimization of encryption
+   reduces the load on the KDC and busy servers.  Also, during the
+   initial design of Version 5, the existence of legal restrictions on
+   the export of cryptography made it desirable to minimize of the
+   number of uses of encryption in the protocol.  Unfortunately,
+   performing this minimization created numerous instances of
+   unauthenticated security-relevant plaintext fields.
+
+   The extensible variants of the messages described in this document
+   wrap the actual message in an ASN.1 sequence containing a keyed
+   checksum of the contents of the message.  Guidelines in [XXX] section
+   3 specify when the checksum MUST be included and what key MUST be
+   used.  Guidelines on when to include a checksum are never ambiguous:
+   a particular PDU is never correct both with and without a checksum.
+   With the exception of the KRB-ERROR message, receiving
+   implementations MUST reject messages where a checksum is included and
+   not expected or where a checksum is expected but not included.  The
+   receiving implementation does not always have sufficient information
+   to know whether a KRB-ERROR should contain a checksum.  Even so,
+   KRB-ERROR messages with invalid checksums MUST be rejected and
+
+Yu                         Expires: Apr 2007                    [Page 9]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   implementations MAY consider the presence or absence of a checksum
+   when evaluating whether to trust the error.
+
+   This authenticated cleartext protection is provided only in the
+   extensible variants of the messages; it is never used when
+   communicating with an RFC 1510 implementation.
+
+2.7.  Capability Negotiation
+
+   Kerberos is a three-party protocol.  Each of the three parties
+   involved needs a means of detecting the capabilities supported by the
+   others.  Two of the parties, the KDC and the application server, do
+   not communicate directly in the Kerberos protocol.  Communicating
+   capabilities from the KDC to the application server requires using a
+   ticket as an intermediary.
+
+   The main capability requiring negotiation is the support of the
+   extensibility framework described in this document.  Negotiation of
+   this capability while remaining compatible with RFC 1510
+   implementations is possible.  The main complication is that the
+   client needs to know whether the application server supports the
+   extensibility framework prior to sending any message to the
+   application server.  This can be accomplished if the KDC has
+   knowledge of whether an application server supports the extensibility
+   framework.
+
+   Client software advertizes its capabilities when requesting
+   credentials from the KDC.  If the KDC recognizes the capabilities, it
+   acknowledges this fact to the client in its reply.  In addition, if
+   the KDC has knowledge that the application server supports certain
+   capabilities, it also communicates this knowledge to the client in
+   its reply.  The KDC can encode its own capabilities in the ticket so
+   that the application server may discover these capabilities.  The
+   client advertizes its capabilities to the application server when it
+   initiates authentication to the application server.
+
+2.7.1.  KDC protocol
+
+   A client may send an AS-REQ-EXT if it has prior knowledge that the
+   KDC in question will accept it.  (possibly via a TCP extension?)
+   Otherwise, the client will send an AS-REQ-1510 with the AS-REQ-EXT
+   inside preauthentication data.  The client will always know whether
+   to send TGS-REQ-EXT because (as in the application protocol) it knows
+   the type of the associated Ticket.  (Note: could be a problem with
+   non-TGT tickets)
+
+   The KDC will send AS-REP-EXT or TGS-REP-EXT if the client's message
+   is extensible; otherwise, it will send AS-REP-1510 or TGS-REP-1510.
+   The Ticket contained within the AS-REP-EXT or TGS-REP-EXT will be a
+   TicketExt if the application server supports it; otherwise, it will
+   be a Ticket1510.  AS-REP-1510 and TGS-REP-1510 always contain a
+
+Yu                         Expires: Apr 2007                   [Page 10]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   Ticket1510.  The EncTicketPart will depend on the server's
+   capability; the client cannot distinguish EncTicketPart1510 from
+   EncTicketPartExt.
+
+   KDCs within a realm should be uniform in advertized capability for
+   extensible messages.  A KDC SHOULD only issue a TicketExt TGT if all
+   KDCs support it.  Similarly, a client receiving a TicketExt knows
+   that all instances of the application service will accept extensible
+   messages.
+
+2.7.2.  Application protocol
+
+   The client knows whether the application server supports AP-REQ-EXT
+   because it can distinguish Ticket1510 from TicketExt.  The server
+   knows the client's capability due to the format of the AP-REQ.
+
+2.8.  Strings
+
+   Some implementations of RFC 1510 do not limit princpal names and
+   realm names to ASCII characters.  As a result, migration difficulties
+   resulting from legacy non-ASCII principal and realm names can arise.
+   Is it reasonable to assume that any legacy non-ASCII character can be
+   uniquely represented in Unicode?
+
+   This may result in a situation where various parties of the protocol
+   need to know alternate, possibly multiple, legacy non-ASCII names for
+   principals and also to know how they map into Unicode.  An
+   application server needs to know all possible legacy encodings of its
+   name if it receives a "mixed" ticket. (Ticket1510 containing
+   EncTicketPartExt) It also needs to be able to compare a legacy
+   encoding of a client principal against the normalized UTF-8 encoding
+   when checking the client's principal name in the Authenticator
+   against the one contained in the EncTicketPart.  This check can be
+   avoided if the application protocol does not require a replay cache.
+
+3.  Use of ASN.1 in Kerberos
+
+   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
+   Even though ASN.1 theoretically allows the description of protocol
+   messages to be independent of the encoding rules used to encode the
+   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
+   the semantics of the notation, such as whether tags carry any
+   semantic content to the application, may cause the use of other ASN.1
+   encoding rules to be problematic.
+
+   Implementors not using existing ASN.1 tools (e.g., compilers or
+   support libraries) are cautioned to thoroughly read and understand
+   the actual ASN.1 specification to ensure correct implementation
+   behavior.  There is more complexity in the notation than is
+   immediately obvious, and some tutorials and guides to ASN.1 are
+   misleading or erroneous.  Recommended tutorials and guides include
+
+Yu                         Expires: Apr 2007                   [Page 11]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   [Dub00], [Lar99], though there is still no substitute for reading the
+   actual ASN.1 specification.
+
+3.1.  Module Header
+
+   The type definitions in this document assume an ASN.1 module
+   definition of the following form:
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- Rest of definitions here
+
+      END
+
+   This specifies that the tagging context for the module will be
+   explicit and that automatic tagging is not done.
+
+   Some other publications [RFC1510] [RFC1964] erroneously specify an
+   object identifier (OID) having an incorrect value of "5" for the
+   "dod" component of the OID.  In the case of RFC 1964, use of the
+   "correct" OID value would result in a change in the wire protocol;
+   therefore, the RFC 1964 OID remains unchanged for now.
+
+3.2.  Top-Level Type
+
+   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
+   Data Units or PDUs) which an application may directly reference.
+   Applications SHOULD NOT transmit any types other than those which are
+   alternatives of the KRB-PDU CHOICE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 12]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+3.3.  Previously Unused ASN.1 Notation (informative)
+
+   Some aspects of ASN.1 notation used in this document were not used in
+   [KCLAR], and may be unfamiliar to some readers.  This subsection is
+   informative; for normative definitions of the notation, see the
+   actual ASN.1 specifications [X680], [X682], [X683].
+
+3.3.1.  Parameterized Types
+
+   This document uses ASN.1 parameterized types [X683] to make
+   definitions of types more readable.  For some types, some or all of
+   the parameters are advisory, i.e., they are not encoded in any form
+   for transmission in a protocol message.  These advisory parameters
+   can describe implementation behavior associated with the type.
+
+3.3.2.  Constraints
+
+   This document uses ASN.1 constraints, including the
+   "UserDefinedConstraint" notation [X682].  Some constraints can be
+   handled automatically by tools that can parse them.  Uses of the
+   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
+   typically need to have behavior manually coded; the notation provides
+   a formalized way of conveying intended implementation behavior.
+
+   The "WITH COMPONENTS" constraint notation allows constraints to apply
+   to component types of a SEQUENCE type.  This constraint notation
+   effectively allows constraints to "reach into" a type to constrain
+   its component types.
+
+
+Yu                         Expires: Apr 2007                   [Page 13]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+3.4.  New Types
+
+   This document defines a number of ASN.1 types which are new since
+   [KCLAR].  The names of these types will typically have a suffix like
+   "Ext", indicating that the types are intended to support
+   extensibility.  Types original to RFC 1510 and [KCLAR] have been
+   renamed to have a suffix like "1510".  The "Ext" and "1510" types
+   often contain a number of common elements, but differ primarily in
+   the way strings are encoded.
+
+4.  Basic Types
+
+   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
+   types.
+
+4.1.  Constrained Integer Types
+
+   In RFC 1510, many types contained references to the unconstrained
+   INTEGER type.  Since an unconstrained INTEGER can contain almost any
+   possible abstract integer value, most of the unconstrained references
+   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
+   [KCLAR].
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+   The "Int32" type often contains an assigned number identifying the
+   contents of a typed hole.  Unless otherwise stated, non-negative
+   values are registered, and negative values are available for local
+   use.
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+   The "UInt32" type is used in some places where an unsigned 32-bit
+   integer is needed.
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+   The "UInt64" type is used in places where 32 bits of precision may
+   provide inadequate security.
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+   Sequence numbers were constrained to 32 bits in [KCLAR], but this
+   document allows for 64-bit sequence numbers.
+
+
+Yu                         Expires: Apr 2007                   [Page 14]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- nonces
+      Nonce           ::= UInt64
+
+   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
+   to 64 bits here.
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+   The "microseconds" type is intended to carry the microseconds part of
+   a time value.
+
+4.2.  KerberosTime
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
+   KerberosTime value MUST NOT include any fractional portions of the
+   seconds.  As required by the DER, it further MUST NOT include any
+   separators, and it specifies the UTC time zone (Z).  Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is "19851106210627Z".
+
+4.3.  KerberosString
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+   The KerberosString type is used for character strings in various
+   places in the Kerberos protocol.  For compatibility with RFC 1510,
+   GeneralString values constrained to IA5String (US-ASCII) are
+   permitted in messages exchanged with RFC 1510 implementations.  The
+   new protocol messages contain strings encoded as UTF-8, and these
+   strings MUST be normalized using [SASLPREP].  KerberosString values
+   are present in principal names and in error messages.  Control
+   characters SHOULD NOT be used in principal names, and used with
+   caution in error messages.
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 15]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+   KerberosStringIA5 requires the use of the "ia5" alternative, while
+   KerberosStringExt forbids it.  These types appear in ASN.1
+   constraints on messages.
+
+   For detailed background regarding the history of character string use
+   in Kerberos, as well as discussion of some compatibility issues, see
+   Appendix B.
+
+4.4.  Language Tags
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+   The "LangTag" type is used to specify language tags for localization
+   purposes, using the [RFC3066] format.
+
+4.5.  KerberosFlags
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+      })
+
+
+   The actual bit string type encoded in Kerberos messages does not use
+   named bits.  The advisory parameter of the KerberosFlags type names a
+   bit string type defined using named bits, whose value is encoded as
+   if it were a bit string with unnamed bits.  This practice is
+   necessary because the DER require trailing zero bits to be removed
+   when encoding bit strings defined using named bits.  Existing
+   implementations of Kerberos send exactly 32 bits rather than
+   truncating, so the size constraint requires the transmission of at
+   least 32 bits.  Trailing zero bits beyond the first 32 bits are
+   truncated.
+
+Yu                         Expires: Apr 2007                   [Page 16]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+4.6.  Typed Holes
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+   The "TH-id" type is a generalized means to identify the contents of a
+   typed hole.  The "int32" alternative may be used for simple integer
+   assignments, in the same manner as "Int32", while the "rel-oid"
+   alternative may be used for hierarchical delegation.
+
+4.7.  HostAddress and HostAddresses
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+   addr-type
+        This field specifies the type of address that follows.
+
+   address
+        This field encodes a single address of the type identified by
+        "addr-type".
+
+   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.
+
+
+      addr-type |     meaning
+      __________|______________
+              2 |   IPv4
+              3 |   directional
+             12 |   DECnet
+             20 |   NetBIOS
+             24 |   IPv6
+
+
+
+Yu                         Expires: Apr 2007                   [Page 17]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+4.7.1.  Internet (IPv4) Addresses
+
+   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
+   MSB order (most significant byte first). The IPv4 loopback address
+   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
+   two (2).
+
+4.7.2.  Internet (IPv6) Addresses
+
+   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
+   in MSB order (most significant byte first). The type of IPv6
+   addresses is twenty-four (24). The following addresses MUST NOT
+   appear in any Kerberos PDU:
+
+      * the Unspecified Address
+
+      * the Loopback Address
+
+      * Link-Local addresses
+
+   This restriction applies to the inclusion in the address fields of
+   Kerberos PDUs, but not to the address fields of packets that might
+   carry such PDUs.  The restriction is necessary because the use of an
+   address with non-global scope could allow the acceptance of a message
+   sent from a node that may have the same address, but which is not the
+   host intended by the entity that added the restriction.  If the
+   link-local address type needs to be used for communication, then the
+   address restriction in tickets must not be used (i.e. addressless
+   tickets must be used).
+
+   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
+   2.
+
+4.7.3.  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).
+
+4.7.4.  Netbios addresses
+
+   Netbios addresses are 16-octet addresses typically composed of 1 to
+   15 alphanumeric characters and padded with the US-ASCII SPC character
+   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
+   0).  The type of Netbios addresses is twenty (20).
+
+4.7.5.  Directional Addresses
+
+   In many environments, including the sender address in KRB-SAFE and
+   KRB-PRIV messages is undesirable because the addresses may be changed
+   in transport by network address translators. However, if these
+   addresses are removed, the messages may be subject to a reflection
+
+Yu                         Expires: Apr 2007                   [Page 18]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   attack in which a message is reflected back to its originator. The
+   directional address type provides a way to avoid transport addresses
+   and reflection attacks.  Directional addresses are encoded as four
+   byte unsigned integers in network byte order.  If the message is
+   originated by the party sending the original AP-REQ message, then an
+   address of 0 SHOULD be used. If the message is originated by the
+   party to whom that AP-REQ was sent, then the address 1 SHOULD be
+   used.  Applications involving multiple parties can specify the use of
+   other addresses.
+
+   Directional addresses MUST only be used for the sender address field
+   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
+   ticket address or in a AP-REQ message.  This address type SHOULD only
+   be used in situations where the sending party knows that the
+   receiving party supports the address type.  This generally means that
+   directional addresses may only be used when the application protocol
+   requires their support.  Directional addresses are type (3).
+
+5.  Principals
+
+   Principals are participants in the Kerberos protocol.  A "realm"
+   consists of principals in one administrative domain, served by one
+   KDC (or one replicated set of KDCs).  Each principal name has an
+   arbitrary number of components, though typical principal names will
+   only have one or two components.  A principal name is meant to be
+   readable by and meaningful to humans, especially in a realm lacking a
+   centrally adminstered authorization infrastructure.
+
+5.1.  Name Types
+
+   Each PrincipalName has NameType indicating what sort of name it is.
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 19]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+5.2.  Principal Type Definition
+
+   The "PrincipalName" type takes a parameter to constrain which string
+   type it contains.
+
+      PrincipalName { StrType }       ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString (StrType)
+      }
+
+
+   The constrained types have their own names.
+
+      -- IA5 only
+      PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
+      -- IA5 excluded
+      PrincipalNameExt ::= PrincipalName { KerberosStringExt }
+      -- Either one?
+      PrincipalNameEither ::= PrincipalName { KerberosString }
+
+
+   name-type
+        hint of the type of name that follows
+
+   name-string
+        The "name-string" encodes a sequence of components that form a
+
+Yu                         Expires: Apr 2007                   [Page 20]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+        name, each component encoded as a KerberosString.  Taken
+        together, a PrincipalName and a Realm form a principal
+        identifier.  Most PrincipalNames will have only a few components
+        (typically one or two).
+
+5.3.  Principal Name Reuse
+
+   Realm administrators SHOULD use extreme caution when considering
+   reusing a principal name.  A service administrator might explicitly
+   enter principal names into a local access control list (ACL) for the
+   service.  If such local ACLs exist independently of a centrally
+   administered authorization infrastructure, realm administrators
+   SHOULD NOT reuse principal names until confirming that all extant ACL
+   entries referencing that principal name have been updated.  Failure
+   to perform this check can result in a security vulnerability, as a
+   new principal can inadvertently inherit unauthorized privileges upon
+   receiving a reused principal name.  An organization whose Kerberos-
+   authenticated services all use a centrally-adminstered authorization
+   infrastructure may not need to take these precautions regarding
+   principal name reuse.
+
+5.4.  Best Common Practice Recommendations for the Processing of
+   Principal Names Consisting of Internationalized Domain Names:
+
+   Kerberos principals are often created for the purpose of
+   authenticating a service located on a machine identified by an domain
+   name.  Unfortunately, once a principal name is created it is
+   impossible to know the source from which the resulting KerberosString
+   was derived.  It is therefore required that principal names
+   containing internationalized domain names be processed via the
+   following procedure:
+
+   *  ensure that the IDN component must be a valid domain name as per
+      the rules of IDNA [RFC3490]
+
+   *  separate the IDN component into labels separated by any of the
+      Full Stop characters
+
+   *  fold all Full Stop characters to Full Stop (0x002E)
+
+   *  for each label (perform all steps):
+
+      o  if the label begins with an ACE prefix as registered with IANA,
+         the prefix will be removed and the rest of the label will be
+         converted from the ACE representation to Unicode [need
+         reference]
+
+      o  if the label consists of one or more internationalized
+         characters separately apply the NamePrep and then the SASLprep
+         string preparation methods.
+
+
+Yu                         Expires: Apr 2007                   [Page 21]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      o  if the label consists of zero internalizationalized characters,
+         the label is to be lower-cased
+
+      o  if the output of the two methods match, continue on to the next
+         label; otherwise reject the principal name as invalid
+
+   *  the result of a valid principal name component derived from an IDN
+      is the joining of the individual string prepared labels separated
+      by the Full Stop (0x002E)
+
+5.5.  Realm Names
+
+         Realm { StrType }       ::= KerberosString (StrType)
+
+         -- IA5 only
+         RealmIA5                ::= Realm { KerberosStringIA5 }
+
+         -- IA5 excluded
+         RealmExt                ::= Realm { KerberosStringExt }
+
+         -- Either
+         RealmEither             ::= Realm { KerberosString }
+
+
+
+   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
+   character with the code 0 (the US-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.
+
+5.6.  Best Common Practice Recommendations for the Processing of
+   Internationalized Domain-Style Realm Names:
+
+   Domain Style Realm names are defined as all realm names whose
+   components are separated by Full Stop (0x002E) (aka periods, '.') and
+   contain neither colons, name containing one or more internationalized
+   characters (not included in US-ASCII), this procedure must be used:
+
+   *  the realm name must be a valid domain name as per the rules of
+      IDNA [RFC3490]
+
+   *  the following string preparation routine must be followed:
+
+      -  separate the string into components separated by any of the
+         Full Stop characters
+
+      -  fold all Full Stop characters to Full Stop (0x002E)
+
+      -  for each component (perform all steps):
+
+
+Yu                         Expires: Apr 2007                   [Page 22]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+         o  if the component begins with an ACE prefix as registered
+            with IANA, the prefix will be removed and the rest of the
+            component will be converted from the ACE representation to
+            Unicode [need reference]
+
+         o  if the component consists of one or more internationalized
+            characters separately apply the NamePrep and SASLprep string
+            preparation methods.
+
+            if the output of the two methods match, continue on to the
+            next component; otherwise reject the realm name as invalid
+
+      -  the result of a valid realm name is the joining of the
+         individual string prepared components separated by the Full
+         Stop (0x002E)
+
+   In [KCLAR], the recommendation is that all domain style realm names
+   be represented in uppercase.  This recommendation is modified in the
+   following manner.  All components of domain style realm names not
+   including internationalized characters should be upper-cased.  All
+   components of domain style realm names including internationalized
+   characters must be lower-cased.  (The lower case representation of
+   internationalized components is enforced by the requirement that the
+   output of NamePrep and StringPrep string preparation must be
+   equivalent.)
+
+5.7.  Printable Representations of Principal Names
+
+   [ perhaps non-normative? ]
+
+   The printable form of a principal name consists of the concatenation
+   of components of the PrincipalName value using the slash character
+   (/), followed by an at-sign (@), followed by the realm name.  Any
+   occurrence of a backslash (\), slash (/) or at-sign (@) in the
+   PrincipalName value is quoted by a backslash.
+
+5.8.  Ticket-Granting Service Principal
+
+   The PrincipalName value corresponding to a ticket-granting service
+   has two components: the first component is the string "krbtgt", and
+   the second component is the realm name of the TGS which will accept a
+   ticket-granting ticket having this service principal name.  The realm
+   name of service always indicates which realm issued the ticket.  A
+   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
+   obtaining tickets in the same realm would have the following ASN.1
+   values for its "realm" and "sname" components, respectively:
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 23]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Example Realm and PrincipalName for a TGS
+
+      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
+
+      tgtPrinc1       PrincipalName ::= {
+          name-type nt-srv-inst,
+          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
+      }
+
+   Its printable representation would be written as
+   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
+
+5.8.1.  Cross-Realm TGS Principals
+
+   It is possible for a principal in one realm to authenticate to a
+   service in another realm.  A KDC can issue a cross-realm ticket-
+   granting ticket to allow one of its principals to authenticate to a
+   service in a foreign realm.  For example, the TGS principal
+   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
+   client principal in the realm A.EXAMPLE.COM to authenticate to a
+   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
+   issues a ticket to a client originating in A.EXAMPLE.COM, the
+   client's realm name remains "A.EXAMPLE.COM", even though the service
+   principal will have the realm "B.EXAMPLE.COM".
+
+6.  Types Relating to Encryption
+
+   Many Kerberos protocol messages contain encrypted encodings of
+   various data types.  Some Kerberos protocol messages also contain
+   checksums (signatures) of encodings of various types.
+
+6.1.  Assigned Numbers for Encryption
+
+   Encryption algorithm identifiers and key usages both have assigned
+   numbers, described in [KCRYPTO].
+
+6.1.1.  EType
+
+   EType is the integer type for assigned numbers for encryption
+   algorithms.  Defined in [KCRYPTO].
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 24]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+6.1.2.  Key Usages
+
+   KeyUsage is the integer type for assigned numbers for key usages.
+   Key usage values are inputs to the encryption and decryption
+   functions described in [KCRYPTO].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 25]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 29
+      ku-ASReq-cksum                  KeyUsage ::= 30
+      ku-TGSReq-cksum                 KeyUsage ::= 31
+      ku-ASRep-cksum                  KeyUsage ::= 32
+      ku-TGSRep-cksum                 KeyUsage ::= 33
+      ku-APReq-cksum                  KeyUsage ::= 34
+      ku-APRep-cksum                  KeyUsage ::= 35
+      ku-KrbCred-cksum                KeyUsage ::= 36
+      ku-KrbError-cksum               KeyUsage ::= 37
+      ku-KDCRep-cksum                 KeyUsage ::= 38
+
+      ku-kg-acceptor-seal             KeyUsage ::= 22
+      ku-kg-acceptor-sign             KeyUsage ::= 23
+      ku-kg-intiator-seal             KeyUsage ::= 24
+      ku-kg-intiator-sign             KeyUsage ::= 25
+
+      -- KeyUsage values 25..27 used by hardware preauth?
+
+      -- for KINK
+      ku-kink-encrypt                 KeyUsage ::= 39
+      ku-kink-cksum                   KeyUsage ::= 40
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 26]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+6.2.  Which Key to Use
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+6.3.  EncryptionKey
+
+   The "EncryptionKey" type holds an encryption key.
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+   keytype
+        This "EType" identifies the encryption algorithm, described in
+        [KCRYPTO].
+
+   keyvalue
+        Contains the actual key.
+
+6.4.  EncryptedData
+
+   The "EncryptedData" type contains the encryption of another data
+   type.  The recipient uses fields within EncryptedData to determine
+   which key to use for decryption.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 27]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+   KeyUsages
+        Advisory parameter indicating which key usage to use when
+        encrypting the ciphertext.  If "KeyUsages" indicate multiple
+        "KeyUsage" values, the detailed description of the containing
+        message will indicate which key to use under which conditions.
+
+   Type
+        Advisory parameter indicating the ASN.1 type whose DER encoding
+        is the plaintext encrypted into the EncryptedData.
+
+   Keys
+        Advisory parameter indicating which key to use to perform the
+        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
+        detailed description of the containing message will indicate
+        which key to use under which conditions.
+
+   KeyUsages
+        Advisory parameter indicating which "KeyUsage" value is used to
+        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
+        the detailed description of the containing message will indicate
+        which key usage to use under which conditions.
+
+6.5.  Checksums
+
+   Several types contain checksums (actually signatures) of data.
+
+
+Yu                         Expires: Apr 2007                   [Page 28]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+   CksumType
+        Integer type for assigned numbers for signature algorithms.
+        Defined in [KCRYPTO]
+
+   Keys
+        As in EncryptedData
+
+   KeyUsages
+        As in EncryptedData
+
+   cksumtype
+        Signature algorithm used to produce the signature.
+
+   checksum
+        The actual checksum.
+
+6.5.1.  ChecksumOf
+
+   ChecksumOf is similar to "Checksum", but specifies which type is
+   signed.
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+Yu                         Expires: Apr 2007                   [Page 29]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   Type
+        Indicates the ASN.1 type whose DER encoding is signed.
+
+6.5.2.  Signed
+
+   Signed is similar to "ChecksumOf", but contains an actual instance of
+   the type being signed in addition to the signature.
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+7.  Tickets
+
+   [ A large number of items described here are duplicated in the
+   sections describing KDC-REQ processing.  Should find a way to avoid
+   this duplication. ]
+
+   A ticket binds a principal name to a session key.  The important
+   fields of a ticket are in the encrypted part.
+
+      -- Encrypted part of ticket
+      EncTicketPart   ::= CHOICE {
+          rfc1510     EncTicketPart1510,
+          ext         EncTicketPartExt
+      }
+
+
+      EncTicketPart1510       ::= [APPLICATION 3] SEQUENCE {
+          flags               [0] TicketFlags,
+          key                 [1] EncryptionKey,
+          crealm              [2] RealmIA5,
+          cname               [3] PrincipalNameIA5,
+          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
+      }
+
+
+
+Yu                         Expires: Apr 2007                   [Page 30]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      EncTicketPartExt        ::= [APPLICATION 5] SEQUENCE {
+          flags               [0] TicketFlags,
+          key                 [1] EncryptionKey,
+          crealm              [2] RealmExt,
+          cname               [3] PrincipalNameExt,
+          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,
+          ...,
+      }
+
+
+   crealm
+        This field contains the client's realm.
+
+   cname
+        This field contains the client's name.
+
+   caddr
+        This field lists the network addresses (if absent, all addresses
+        are permitted) from which the ticket is valid.
+
+   Descriptions of the other fields appear in the following sections.
+
+7.1.  Timestamps
+
+   Three of the ticket timestamps may be requested from the KDC.  The
+   timestamps may differ from those requested, depending on site policy.
+
+   authtime
+        The time at which the client authenticated, as recorded by the
+        KDC.
+
+   starttime
+        The earliest time when the ticket is valid.  If not present, the
+        ticket is valid starting at the authtime.  This is requested as
+        the "from" field of KDC-REQ-BODY.
+
+   endtime
+        This time is requested in the "till" field of KDC-REQ-BODY.
+        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.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 31]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   renew-till
+        This time is requested in the "rtime" field of KDC-REQ-BODY.  It
+        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.
+
+7.2.  Ticket Flags
+
+   A number of flags may be set in the ticket, further defining some of
+   its capabilities.  Some of these flags map to flags in a KDC request.
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+7.2.1.  Flags Relating to Initial Ticket Acquisition
+
+   [ adapted KCLAR 2.1. ]
+
+   Several flags indicate the details of how the initial ticket was
+   acquired.
+
+   initial
+        The "initial" flag indicates that a ticket was issued using the
+        AS protocol, rather than issued based on a ticket-granting
+        ticket.  Application servers (e.g., a password-changing program)
+        requiring a client's definite knowledge of its secret key can
+        insist that this flag be set in any tickets they accept, thus
+        being assured that the client's key was recently presented to
+        the application client.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 32]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   pre-authent
+        The "pre-authent" flag indicates that some sort of pre-
+        authentication was used during the AS exchange.
+
+   hw-authent
+        The "hw-authent" flag indicates that some sort of hardware-based
+        pre-authentication occurred during the AS exchange.
+
+   Both the "pre-authent" and the "hw-authent" flags may be present with
+   or without the "initial" flag; such tickets with the "initial" flag
+   clear are ones which are derived from initial tickets with the "pre-
+   authent" or "hw-authent" flags set.
+
+7.2.2.  Invalid Tickets
+
+   [ KCLAR 2.2. ]
+
+   The "invalid" flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets which have this flag set.  A postdated
+   ticket will 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 8.3.2.4).
+
+7.2.3.  OK as Delegate
+
+   [ KCLAR 2.8. ]
+
+   The "ok-as-delegate" flag provides a way for a KDC to communicate
+   local realm policy to a client regarding whether the service for
+   which the ticket is issued is trusted to accept delegated
+   credentials.  For some applications, a client may need to delegate
+   credentials to a service to act on its behalf in contacting other
+   services.  The ability of a client to obtain a service ticket for a
+   service conveys no information to the client about whether the
+   service should be trusted to accept delegated credentials.
+
+   The copy of the ticket flags visible to the client may have the "ok-
+   as-delegate" flag set to indicate to the client that the service
+   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 service.  It is acceptable 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.
+
+Yu                         Expires: Apr 2007                   [Page 33]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+7.2.4.  Renewable Tickets
+
+   [ adapted KCLAR 2.3. ]
+
+   The "renewable" flag indicates whether the ticket may be renewed.
+
+   Renewable tickets can be used to mitigate the consequences of ticket
+   theft.  Applications may desire to hold credentials which can be
+   valid for long periods of time.  However, this can expose the
+   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 application to have long-term access
+   to the client's secret key, which is an even greater risk.
+
+   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 present an unexpired renewable ticket to the
+   KDC, setting the "renew" option 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.  It can usually be ignored by application
+   servers.  However, some particularly careful application servers MAY
+   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 clear by default,
+   but a client can request it be set by setting the "renewable" option
+   in the 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.
+
+7.2.5.  Postdated Tickets
+
+   postdated
+        indicates a ticket which has been postdated
+
+   may-postdate
+        indicates that postdated tickets may be issued based on this
+        ticket
+
+   [ KCLAR 2.4. ]
+
+
+Yu                         Expires: Apr 2007                   [Page 34]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   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 TGS.  It can be ignored by application servers.  This flag MUST
+   be set in a ticket-granting ticket in order for the KDC 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 AS-REQ [?also TGS-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 AS-REQ message.  The life (endtime minus
+   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 minus 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 for
+   validation before use.
+
+7.2.6.  Proxiable and Proxy Tickets
+
+   proxy
+        indicates a proxy ticket
+
+   proxiable
+        indicates that proxy tickets may be issued based on this ticket
+
+   [ KCLAR 2.5. ]
+
+   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.
+
+
+Yu                         Expires: Apr 2007                   [Page 35]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   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, users wishing to delegate their
+   identity in a form usable for all purposes 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 may contain a set of network addresses from which they are
+   valid.  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.
+
+7.2.7.  Forwarded and Forwardable Tickets
+
+   forwarded
+        indicates a forwarded ticket
+
+   forwardable
+        indicates that forwarded tickets may be issued based on this
+        ticket
+
+   [ KCLAR 2.6. ]
+
+   Authentication forwarding is an instance of a proxy where the service
+   that is granted is 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
+
+Yu                         Expires: Apr 2007                   [Page 36]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   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.
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+7.3.  Transited Realms
+
+   [ KCLAR 2.7., plus new stuff ]
+
+7.4.  Authorization Data
+
+   [ KCLAR 5.2.6. ]
+
+      ADType          ::= TH-id
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+   ad-type
+        This field identifies the contents of the ad-data.  All negative
+        values are reserved for local use.  Non-negative values are
+        reserved for registered use.
+
+   ad-data
+        This field contains authorization data to be interpreted
+        according to the value of the corresponding ad-type field.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 37]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   Each sequence of ADType and OCTET STRING is referred 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
+   AuthorizationData, and the interpretation of the encapsulating
+   element determines which enclosed elements must be interpreted, and
+   which may be ignored.
+
+   Depending on the meaning of the encapsulating element, the
+   encapsulated AuthorizationData may be ignored, interpreted as issued
+   directly by the KDC, or be stored in a separate plaintext part of the
+   ticket.  The types of the encapsulating elements are specified as
+   part of the Kerberos protocol because behavior based on these
+   container elements should be understood across implementations, while
+   other elements need only be understood by the applications which they
+   affect.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator.  Unless encapsulated in a known
+   authorization data element modifying the criticality of the elements
+   it contains, an application server MUST reject the authentication of
+   a client whose AP-REQ or ticket contains an unrecognized
+   authorization data element.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether it is the target of a restriction, a security weakness may
+   exist if the ticket can be used for that service.  Authorization
+   elements that are truly optional can be enclosed in AD-IF-RELEVANT
+   element.
+
+
+      ad-type |           contents of ad-data
+      ________|_______________________________________
+            1 |   DER encoding of AD-IF-RELEVANT
+            4 |   DER encoding of AD-KDCIssued
+            5 |   DER encoding of AD-AND-OR
+            8 |   DER encoding of AD-MANDATORY-FOR-KDC
+
+
+
+7.4.1.  AD-IF-RELEVANT
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      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
+
+Yu                         Expires: Apr 2007                   [Page 38]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   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.  The ad-type for AD-IF-RELEVANT is (1).
+
+7.4.2.  AD-KDCIssued
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+   ad-checksum
+        A cryptographic checksum computed over the DER encoding of the
+        AuthorizationData in the "elements" field, keyed with the
+        session key.  Its checksumtype is the mandatory checksum type
+        for the encryption type of the session key, and its key usage
+        value is 19.
+
+   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
+        AuthorizationData issued by the KDC.
+
+   The KDC-issued ad-data field is intended to provide a means for
+   Kerberos credentials to embed within themselves privilege attributes
+   and other mechanisms for positive authorization, amplifying the
+   privileges of the principal beyond what it would have if using
+   credentials without such an authorization-data element.
+
+   This amplification of privileges cannot 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
+
+Yu                         Expires: Apr 2007                   [Page 39]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   server's key (the same key used to encrypt the ticket -- or a key
+   derived from that key).  AuthorizationData encapsulated with in the
+   AD-KDCIssued element MUST be ignored by the application server if
+   this "signature" is not present.  Further, AuthorizationData
+   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 encapsulates MAY be safely ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+7.4.3.  AD-AND-OR
+
+      ad-and-or               ADType ::= int32 : 5
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] Int32,
+          elements            [1] AuthorizationData
+      }
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisfied.  Therefore, 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.
+
+   The ad-type for AD-AND-OR is (5).
+
+7.4.4.  AD-MANDATORY-FOR-KDC
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+   be interpreted by the KDC.  KDCs that do not understand the type of
+   an element embedded within the mandatory-for-kdc element MUST reject
+   the request.
+
+Yu                         Expires: Apr 2007                   [Page 40]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+7.5.  Encrypted Part of Ticket
+
+   The complete definition of the encrypted part is
+
+      -- Encrypted part of ticket
+      EncTicketPart   ::= CHOICE {
+          rfc1510     EncTicketPart1510,
+          ext         EncTicketPartExt
+      }
+
+
+   The encrypted part of the backwards-compatibility form of a ticket
+   is:
+
+      EncTicketPart1510       ::= [APPLICATION 3] SEQUENCE {
+          flags               [0] TicketFlags,
+          key                 [1] EncryptionKey,
+          crealm              [2] RealmIA5,
+          cname               [3] PrincipalNameIA5,
+          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
+      }
+
+   The encrypted part of the extensible form of a ticket is:
+
+      EncTicketPartExt        ::= [APPLICATION 5] SEQUENCE {
+          flags               [0] TicketFlags,
+          key                 [1] EncryptionKey,
+          crealm              [2] RealmExt,
+          cname               [3] PrincipalNameExt,
+          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,
+          ...,
+      }
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 41]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+7.6.  Cleartext Part of Ticket
+
+   The complete definition of Ticket is:
+
+      Ticket          ::= CHOICE {
+          rfc1510     Ticket1510,
+          ext         TicketExt
+      }
+
+
+   The "sname" field provides the name of the target service principal
+   in cleartext, as a hint to aid the server in choosing the correct
+   decryption key.
+
+   The backwards-compatibility form of Ticket is:
+
+      Ticket1510      ::= [APPLICATION 1] SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] RealmIA5,
+          sname       [2] PrincipalNameIA5,
+          enc-part    [3] EncryptedData {
+              EncTicketPart1510, { key-server }, { ku-Ticket }
+          }
+      }
+
+   The extensible form of Ticket is:
+
+      TicketExt       ::= [APPLICATION 4] Signed {
+          [APPLICATION 4] SEQUENCE {
+              tkt-vno     [0] INTEGER (5),
+              realm       [1] RealmExt,
+              sname       [2] PrincipalNameExt,
+              enc-part    [3] EncryptedData {
+                  EncTicketPartExt, { key-server }, { ku-Ticket }
+              },
+              ...,
+              extensions          [4] TicketExtensions OPTIONAL,
+              ...
+          },
+          { key-ticket }, { ku-Ticket-cksum }
+      }
+
+
+   TicketExtensions, which may only be present in the extensible form of
+   Ticket, are a cleartext typed hole for extension use.
+   AuthorizationData already provides an encrypted typed hole.
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 42]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      TEType                  ::= TH-id
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+   A client will only receive an extensible Ticket if the application
+   server supports extensibility.
+
+8.  Credential Acquisition
+
+   There are two exchanges that can be used for acquiring credentials:
+   the AS exchange and the TGS exchange.  These exchanges have many
+   similarities, and this document describes them in parallel, noting
+   which behaviors are specific to one type of exchange.  The AS request
+   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
+   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
+   are forms of KDC replies (KDC-REP).
+
+   The credentials acquisition protocol operates over specific
+   transports.  Additionally, specific methods exist to permit a client
+   to discover the KDC host with which to communicate.
+
+8.1.  KDC-REQ
+
+   The KDC-REQ has a large number of fields in common between the RFC
+   1510 and the extensible versions.  The KDC-REQ type itself is never
+   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
+
+      KDC-REQ-1510    ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (  10 -- AS-REQ --
+                                   | 12 -- TGS-REQ -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL,
+          req-body    [4] KDC-REQ-BODY-1510
+      }
+
+
+      KDC-REQ-EXT     ::= SEQUENCE {
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (  6 -- AS-REQ --
+                                   | 8 -- TGS-REQ -- ),
+          padata      [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      }
+
+
+Yu                         Expires: Apr 2007                   [Page 43]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REQ-BODY-1510       ::= SEQUENCE {
+          kdc-options         [0] KDCOptions,
+          cname               [1] PrincipalNameIA5 OPTIONAL
+          -- Used only in AS-REQ --,
+
+          realm               [2] RealmIA5
+          -- Server's realm; also client's in AS-REQ --,
+
+          sname               [3] PrincipalNameIA5 OPTIONAL,
+          from                [4] KerberosTime OPTIONAL,
+          till                [5] KerberosTime,
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce32,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 44]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REQ-BODY-EXT        ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+   Many fields of KDC-REQ-BODY correspond directly to fields of an
+   EncTicketPart.  The KDC copies most of them unchanged, provided that
+   the requested values meet site policy.
+
+   kdc-options
+        These flags do not correspond directly to "flags" in
+        EncTicketPart.
+
+   cname
+        This field is copied to the "cname" field in EncTicketPart.  The
+        "cname" field is required in an AS-REQ; the client places its
+        own name here.  In a TGS-REQ, the "cname" in the ticket in the
+        AP-REQ takes precedence.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 45]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   realm
+        This field is the server's realm, and also holds the client's
+        realm in an AS-REQ.
+
+   sname
+        The "sname" field indicates the server's name.  It may be absent
+        in a TGS-REQ which requests user-to-user authentication, in
+        which case the "sname" of the issued ticket will be taken from
+        the included additional ticket.
+
+   The "from", "till", and "rtime" fields correspond to the "starttime",
+   "endtime", and "renew-till" fields of EncTicketPart.
+
+   addresses
+        This field corresponds to the "caddr" field of EncTicketPart.
+
+   enc-authorization-data
+        For TGS-REQ, this field contains authorization data encrypted
+        using either the TGT session key or the AP-REQ subsession key;
+        the KDC may copy these into the "authorization-data" field of
+        EncTicketPart if policy permits.
+
+   lang-tags
+        Only present in the extensible messages.  Specifies the set of
+        languages which the client is willing to accept in error
+        messages.
+
+   KDC options used in a KDC-REQ are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 46]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+   Different options apply to different phases of KDC-REQ processing.
+
+   The backwards-compatibility form of a KDC-REQ is:
+
+      KDC-REQ-1510    ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (  10 -- AS-REQ --
+                                   | 12 -- TGS-REQ -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL,
+          req-body    [4] KDC-REQ-BODY-1510
+      }
+
+   The extensible form of a KDC-REQ is:
+
+      KDC-REQ-EXT     ::= SEQUENCE {
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (  6 -- AS-REQ --
+                                   | 8 -- TGS-REQ -- ),
+          padata      [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      }
+
+
+Yu                         Expires: Apr 2007                   [Page 47]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   The backwards-compatibility form of a KDC-REQ-BODY is:
+
+      KDC-REQ-BODY-1510       ::= SEQUENCE {
+          kdc-options         [0] KDCOptions,
+          cname               [1] PrincipalNameIA5 OPTIONAL
+          -- Used only in AS-REQ --,
+
+          realm               [2] RealmIA5
+          -- Server's realm; also client's in AS-REQ --,
+
+          sname               [3] PrincipalNameIA5 OPTIONAL,
+          from                [4] KerberosTime OPTIONAL,
+          till                [5] KerberosTime,
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce32,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --
+      }
+
+   The extensible form of a KDC-REQ-BODY is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 48]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REQ-BODY-EXT        ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+   The AS-REQ is:
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     AS-REQ-1510,
+          ext         AS-REQ-EXT
+      }
+      AS-REQ-1510     ::= [APPLICATION 10] KDC-REQ-1510
+          -- AS-REQ must include client name
+
+      AS-REQ-EXT      ::= [APPLICATION 6] Signed {
+          [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum }
+      }
+      -- AS-REQ must include client name
+
+   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
+   if the client does not know that the KDC supports the extensibility
+
+Yu                         Expires: Apr 2007                   [Page 49]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   framework.  A client SHOULD send the extensible AS-REQ alternative in
+   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
+   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
+   what if their contents conflict? ]
+
+   The TGS-REQ is:
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     TGS-REQ-1510,
+          ext         TGS-REQ-EXT
+      }
+
+      TGS-REQ-1510    ::= [APPLICATION 12] KDC-REQ-1510
+
+      TGS-REQ-EXT     ::= [APPLICATION 8] Signed {
+          [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum }
+      }
+
+
+8.2.  PA-DATA
+
+   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
+   authenticate an AS-REQ; they may also modify several of the
+   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
+   to the client about which long-term key (usually password-derived) to
+   use.  PA-DATA may also include "hints" about which pre-authentication
+   mechanisms to use, or include data for input into a pre-
+   authentication mechanism.
+
+   [ XXX enumerate standard padata here ]
+
+8.3.  KDC-REQ Processing
+
+   Processing of a KDC-REQ proceeds through several steps.  An
+   implementation need not perform these steps exactly as described, as
+   long as it behaves as if the steps were performed as described.  The
+   KDC performs replay handling upon receiving the request; it then
+   validates the request, adjusts timestamps, and selects the keys used
+   in the reply.  It copies data from the request into the issued
+   ticket, adjusting the values to conform with its policies.  The KDC
+   then transmits the reply to the client.
+
+8.3.1.  Handling Replays
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+   successfully processed, the KDC MUST respond with a KDC-REP message
+   rather than a replay error.  In order to reduce the amount of
+   ciphertext given to a potential attacker, KDCs MAY send the same
+   response generated when the request was first handled.  KDCs MUST
+
+Yu                         Expires: Apr 2007                   [Page 50]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   obey this replay behavior even if the actual transport in use is
+   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
+   and the entire request is not identical to a recently successfully
+   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
+   appropriate for AP-REQ processing.
+
+8.3.2.  Request Validation
+
+8.3.2.1.  AS-REQ Authentication
+
+   Site policy determines whether a given client principal is required
+   to provide some pre-authentication prior to receiving an AS-REP.
+   Since the default reply key is typically the client's long-term
+   password-based key, an attacker may easily request known plaintext
+   (in the form of an AS-REP) upon which to mount a dictionary attack.
+   Pre-authentication can limit the possibility of such an attack.
+
+   If site policy requires pre-authentication for a client principal,
+   and no pre-authentication is provided, the KDC returns the error
+   "kdc-err-preauth-required".  Accompanying this error are "e-data"
+   which include hints telling the client which pre-authentication
+   mechanisms to use, or data for input to pre-authentication mechanisms
+   (e.g., input to challenge-response systems).  If pre-authentication
+   fails, the KDC returns the error "kdc-err-preauth-failed".
+
+   [ may need additional changes based on Sam's preauth draft ]
+
+8.3.2.2.  TGS-REQ Authentication
+
+   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
+   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
+   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
+   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
+   request.  [ padata not signed by authenticator! ] Any error from the
+   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
+   The service principal in the ticket of the AP-REQ may be a ticket-
+   granting service principal, or a normal application service
+   principal.  A ticket which is not a ticket-granting ticket MUST NOT
+   be used to issue a ticket for any service other than the one named in
+   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
+   forwarded?]  option must be set in the request.
+
+8.3.2.3.  Principal Validation
+
+   If the client principal in an AS-REQ is unknown, the KDC returns the
+   error "kdc-err-c-principal-unknown".  If the server principal in a
+   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
+   unknown".
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 51]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+8.3.2.4.  Checking For Revoked or Invalid Tickets
+
+   [ KCLAR 3.3.3.1 ]
+
+   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 to the KDC for the realm in which
+   the server resides.  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.  If TGTs have been issued for cross-realm authentication, use
+   of the cross-realm TGT will not be affected unless the hot-list is
+   propagated to the KDCs for the realms for which such cross-realm
+   tickets were issued.
+
+   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
+   issue any ticket unless the TGS-REQ requests the "validate" option.
+
+8.3.3.  Timestamp Handling
+
+   [ some aspects of timestamp handling, especially regarding postdating
+   and renewal, are difficult to read in KCLAR... needs closer
+   examination here ]
+
+   Processing of "starttime" (requested in the "from" field) differs
+   depending on whether the "postdated" option is set in the request.
+   If the "postdated" option is not set, and the requested "starttime"
+   is in the future beyond the window of acceptable clock skew, the KDC
+   returns the error "kdc-err-cannot-postdate".  If the "postdated"
+   option is not set, and the requested "starttime" is absent or does
+   not indicate a time in the future beyond the acceptable clock skew,
+   the KDC sets the "starttime" to the KDC's current time.  The
+   "postdated" option MUST NOT be honored if the ticket is being
+   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
+   Otherwise, if the "postdated" option is set, and site policy permits,
+   the KDC sets the "starttime" as requested, and sets the "invalid"
+   flag in the new ticket.
+
+   The "till" field is required in the RFC 1510 version of the KDC-REQ.
+   If the "till" field is equal to "19700101000000Z" (midnight, January
+   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
+
+   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
+   "renew-till" time is later than the "renew-till" time of the ticket
+   from which it is derived.
+
+
+Yu                         Expires: Apr 2007                   [Page 52]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+8.3.3.1.  AS-REQ Timestamp Processing
+
+   In the AS exchange, the "authtime" of a ticket is set to the local
+   time at the KDC.
+
+   The "endtime" of the ticket will be set to the earlier of the
+   requested "till" time and a time determined by local policy, possibly
+   determined using factors specific to the realm or principal.  For
+   example, the expiration time MAY be set to the earliest of the
+   following:
+
+      * the expiration time ("till" value) requested
+
+      * the ticket's start time plus the maximum allowable lifetime
+        associated with the client principal from the authentication
+        server's database
+
+      * 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.
+
+   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 MAY be set to the earliest 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
+
+8.3.3.2.  TGS-REQ Timestamp Processing
+
+   In the TGS exchange, the KDC sets the "authtime" to that of the
+   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
+   server can print a ticket for itself with a spoofed authtime.
+   security issues for hot-list?] [ MIT implementation may change
+   authtime of renewed tickets; needs check... ]
+
+Yu                         Expires: Apr 2007                   [Page 53]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
+   requests an "endtime" (in the "till" field), then the "endtime" of
+   the new ticket is set to the minimum of
+
+      * the requested "endtime" value,
+
+      * the "endtime" in the TGT, and
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+   If the new ticket is a renewal, the "endtime" of the new ticket is
+   bounded by the minimum of
+
+      * the requested "endtime" value,
+
+      * the value of the "renew-till" value of the old,
+
+      * the "starttime" of the new ticket plus the lifetime (endtime
+        minus starttime) of the old ticket, i.e., the lifetime of the
+        new ticket may not exceed that of the ticket being renewed [
+        adapted from KCLAR 3.3.3. ], and
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
+   a "starttime", "endtime", or "renew-till" time later than the
+   "renew-till" time of the TGT.
+
+8.3.4.  Handling Transited Realms
+
+   The KDC checks the ticket in a TGS-REQ against site policy, unless
+   the "disable-transited-check" option is set in the TGS-REQ.  If site
+   policy permits the transit path in the TGS-REQ ticket, the KDC sets
+   the "transited-policy-checked" flag in the issued ticket.  If the
+   "disable-transited-check" option is set, the issued ticket will have
+   the "transited-policy-checked" flag cleared.
+
+8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
+   copied into the issued ticket.  If the "addresses" field is absent or
+   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
+   TGS-REQ into the issued ticket, unless the either "forwarded" or
+   "proxy" option is set.  If the "forwarded" option is set, and the
+   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
+   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
+   issued ticket.  The KDC behaves similarly if the "proxy" option is
+   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
+   The "proxy" option will not be honored on requests for additional
+   ticket-granting tickets.
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 54]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+8.3.6.  Ticket Flag Processing
+
+   Many kdc-options request that the KDC set a corresponding flag in the
+   issued ticket.  kdc-options marked with an asterisk (*) in the
+   following table do not directly request the corresponding ticket flag
+   and therefore require special handling.
+
+
+             kdc-option       |    ticket flag affected
+      ________________________|__________________________
+      forwardable             |  forwardable
+      forwarded               |  forwarded
+      proxiable               |  proxiable
+      proxy                   |  proxy
+      allow-postdate          |  may-postdate
+      postdated               |  postdated
+      renewable               |  renewable
+      requestanonymous        |  anonymous
+      canonicalize            |  -
+      disable-transited-check*|  transited-policy-checked
+      renewable-ok*           |  renewable
+      enc-tkt-in-skey         |  -
+      renew                   |  -
+      validate*               |  invalid
+
+
+
+   forwarded
+        The KDC sets the "forwarded" flag in the issued ticket if the
+        "forwarded" option is set in the TGS-REQ and the "forwardable"
+        flag is set in the TGS-REQ ticket.
+
+   proxy
+        The KDC sets the "proxy" flag in the issued ticket if the
+        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
+        set in the TGS-REQ ticket.
+
+   disable-transited-check
+        The handling of the "disable-transited-check" kdc-option is
+        described in Section 8.3.4.
+
+   renewable-ok
+        The handling of the "renewable-ok" kdc-option is described in
+        Section 8.3.3.1.
+
+   enc-tkt-in-skey
+        This flag modifies ticket key selection to use the session key
+        of an additional ticket included in the TGS-REQ, for the purpose
+        of user-to-user authentication.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 55]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   validate
+        If the "validate" kdc-option is set in a TGS-REQ, and the
+        "starttime" has passed, the KDC will clear the "invalid" bit on
+        the ticket before re-issuing it.
+
+8.3.7.  Key Selection
+
+   Three keys are involved in creating a KDC-REP.  The reply key
+   encrypts the encrypted part of the KDC-REP.  The session key is
+   stored in the encrypted part of the ticket, and is also present in
+   the encrypted part of the KDC-REP so that the client can retrieve it.
+   The ticket key is used to encrypt the ticket.  These keys all have
+   initial values for a given exchange; pre-authentication and other
+   extension mechanisms may change the value used for any of these keys.
+
+   [ again, may need changes based on Sam's preauth draft ]
+
+8.3.7.1.  Reply Key and Session Key Selection
+
+   The set of encryption types which the client will understand appears
+   in the "etype" field of KDC-REQ-BODY.  The KDC limits the set of
+   possible reply keys and the set of session key encryption types based
+   on the "etype" field.
+
+   For the AS exchange, the reply key is initially a long-term key of
+   the client, limited to those encryption types listed in the "etype"
+   field.  The KDC SHOULD use the first valid strong "etype" for which
+   an encryption key is available.  For the TGS exchange, the reply key
+   is initially the subsession key of the Authenticator.  If the
+   Authenticator subsesion key is absent, the reply key is initially the
+   session key of the ticket used to authenticate the TGS-REQ.
+
+   The session key is initially randomly generated, and has an
+   encryption type which both the client and the server will understand.
+   Typically, the KDC has prior knowledge of which encryption types the
+   server will understand.  It selects the first valid strong "etype"
+   listed the request which the server also will understand.
+
+8.3.7.2.  Ticket Key Selection
+
+   The ticket key is initially the long-term key of the service.  The
+   "enc-tkt-in-skey" option requests user-to-user authentication, where
+   the ticket encryption key of the issued ticket is set equal to the
+   session key of the additional ticket in the request.
+
+8.4.  KDC-REP
+
+   The important parts of the KDC-REP are encrypted.
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 56]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce32,
+          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] RealmIA5,
+          sname               [10] PrincipalNameIA5,
+          caddr               [11] HostAddresses OPTIONAL
+      }
+
+      EncKDCRepPartExt        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+
+   Most of the fields of EncKDCRepPartCom are duplicates of the
+   corresponding fields in the returned ticket.
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 57]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] RealmIA5,
+          cname       [4] PrincipalNameIA5,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          }
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 58]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REP-EXT { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] RealmExt,
+          cname       [4] PrincipalNameExt,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+   req-cksum
+        Signature of the original request using the reply key, to avoid
+        replay attacks against the client, among other things.  Only
+        present in the extensible version of KDC-REP.
+
+           AS-REP          ::= CHOICE {
+               rfc1510     AS-REP-1510,
+               ext         AS-REP-EXT
+           }
+           AS-REP-1510     ::= [APPLICATION 11] KDC-REP-1510
+           AS-REP-EXT      ::= [APPLICATION 7] Signed {
+               [APPLICATION 7] KDC-REP-EXT,
+               { key-reply }, { ku-ASRep-cksum }
+           }
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 59]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+           TGS-REP         ::= CHOICE {
+               rfc1510     TGS-REP-1510,
+               ext         TGS-REP-EXT
+           }
+           TGS-REP-1510    ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 }
+           TGS-REP-EXT     ::= [APPLICATION 9] Signed {
+               [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+               { key-reply }, { ku-TGSRep-cksum }
+           }
+
+
+   The extensible versions of AS-REQ and TGS-REQ are signed with the
+   reply key, to prevent an attacker from performing a delayed denial-
+   of-service attack by substituting the ticket.
+
+8.5.  Reply Validation
+
+   [ signature verification ]
+
+8.6.  IP Transports
+
+   [ KCLAR 7.2 ]
+
+   Kerberos defines two IP transport mechanisms for the credentials
+   acquisition protocol: UDP/IP and TCP/IP.
+
+8.6.1.  UDP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
+   identify the IP address and port to which they will send their
+   request.
+
+   When contacting a 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 the KDC. The KDC will respond with a reply
+   datagram containing only an encoding of the reply message (either a
+   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
+   address. The response to a request made through UDP/IP transport MUST
+   also use UDP/IP transport. If the response can not be handled using
+   UDP (for example because it is too large), the KDC MUST return "krb-
+   err-response-too-big", forcing the client to retry the request using
+   the TCP transport.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 60]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+8.6.2.  TCP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   initially try a request using the UDP transport. Clients SHOULD use
+   KDC discovery (Section 8.6.3) to identify the IP address and port to
+   which they will send their request.
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+   When the KDC-REQ message is sent to the KDC over a TCP stream, the
+   response (KDC-REP or KRB-ERROR message) MUST be returned to the
+   client on the same TCP stream that was established for the request.
+   The KDC MAY close the TCP stream after sending a response, but MAY
+   leave the stream open for a reasonable period of time if it expects a
+   followup. Care must be taken in managing TCP/IP connections on the
+   KDC to prevent denial of service attacks based on the number of open
+   TCP/IP connections.
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   anytime after the receipt of a response.  A stream closure SHOULD NOT
+   be treated as a fatal error.  Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication) the client may
+   need to establish a new connection when it is ready to send
+   subsequent messages.  A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   followup messages.
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
+   the TCP stream is preceded by the length of the request as 4 octets
+   in network byte order. The high bit of the length is reserved for
+   future expansion and MUST currently be set to zero.  If a KDC that
+   does not understand how to interpret a set high bit of the length
+   encoding receives a request with the high order bit of the length
+   set, it MUST return a KRB-ERROR message with the error "krb-err-
+   field-toolong" and MUST close the TCP stream.
+
+   If multiple requests are sent over a single TCP connection, and the
+   KDC sends multiple responses, the KDC is not required to send the
+
+Yu                         Expires: Apr 2007                   [Page 61]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   responses in the order of the corresponding requests.  This may
+   permit some implementations to send each response as soon as it is
+   ready even if earlier requests are still being processed (for
+   example, waiting for a response from an external device or database).
+
+8.6.3.  KDC Discovery on IP Networks
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored 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 using cross-realm authentication. This section
+   describes a method for using the Domain Name System [RFC 1035] for
+   storing KDC location information.
+
+8.6.3.1.  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
+   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
+   and "MyRealm" are all different, but resolve the same in the domain
+   name system, it is necessary that only one of the possible
+   combinations of upper and lower case characters be used in realm
+   names.
+
+8.6.3.2.  DNS SRV records for KDC location
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2782].  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 one of "udp", "tcp". If these SRV records are to be
+   used, both "udp" and "tcp" records MUST be specified for all KDC
+   deployments.
+
+   The Realm is the Kerberos realm that this record corresponds to.  The
+   realm MUST be a domain style realm name.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2782.
+
+   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal) unless the KDC is configured
+
+Yu                         Expires: Apr 2007                   [Page 62]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   to listen on an alternate TCP port.
+
+   Implementation note: Many existing client implementations do not
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority.  Weights are not used in these sample records.
+
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+
+
+9.  Errors
+
+   The KRB-ERROR message is returned by the KDC if an error occurs
+   during credentials acquisition.  It may also be returned by an
+   application server if an error occurs during authentication.
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     KRB-ERROR-1510,
+          ext         KRB-ERROR-EXT
+      }
+
+
+   The extensible KRB-ERROR is only signed if there has been a key
+   negotiated with its recipient.  KRB-ERROR messages sent in response
+   to AS-REQ messages will probably not be signed unless a
+   preauthentication mechanism has negotiated a key.  (Signing using a
+   client's long-term key can expose ciphertext to dictionary attacks.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 63]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] RealmIA5 OPTIONAL,
+          cname       [8] PrincipalNameIA5 OPTIONAL,
+          realm       [9] RealmIA5 -- Correct realm --,
+          sname       [10] PrincipalNameIA5 -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL
+      }
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
+          [APPLICATION 23] SEQUENCE{
+              pvno        [0] INTEGER (5),
+              msg-type    [1] INTEGER (23),
+              ctime       [2] KerberosTime OPTIONAL,
+              cusec       [3] Microseconds OPTIONAL,
+              stime       [4] KerberosTime,
+              susec       [5] Microseconds,
+              error-code  [6] ErrCode,
+              crealm      [7] Realm OPTIONAL,
+              cname       [8] PrincipalName OPTIONAL,
+              realm       [9] Realm -- Correct realm --,
+              sname       [10] PrincipalName -- Correct name --,
+              e-text      [11] KerberosString OPTIONAL,
+              e-data      [12] OCTET STRING OPTIONAL,
+              ...,
+              typed-data          [13] TYPED-DATA OPTIONAL,
+              nonce               [14] Nonce OPTIONAL,
+              lang-tag            [15] LangTag OPTIONAL,
+              ...
+          }, { }, { ku-KrbError-cksum }
+      }
+
+
+   ctime, cusec
+        Client's time, if known from a KDC-REQ or AP-REQ.
+
+   stime, susec
+        KDC or application server's current time.
+
+   error-code
+        Numeric error code designating the error.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 64]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   crealm, cname
+        Client's realm and name, if known.
+
+   realm, sname
+        server's realm and name. [ XXX what if these aren't known? ]
+
+   e-text
+        Human-readable text providing additional details for the error.
+
+   e-data
+        This field contains additional data about the error for use by
+        the client to help it recover from or handle the error. If the
+        "error-code" is "kdc-err-preauth-required", then the e-data
+        field will contain an encoding of a sequence of padata fields,
+        each corresponding to an acceptable pre-authentication method
+        and optionally containing data for the method:
+
+           METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+        For error codes defined in this document other than "kdc-err-
+        preauth-required", the format and contents of the e-data field
+        are implementation-defined.  Similarly, for future error codes,
+        the format and contents of the e-data field are implementation-
+        defined unless specified.
+
+   lang-tag
+        Indicates the language of the message in the "e-text" field.  It
+        is only present in the extensible KRB-ERROR.
+
+   nonce
+        is the nonce from a KDC-REQ.  It is only present in the
+        extensible KRB-ERROR.
+
+   typed-data
+        TYPED-DATA is a typed hole allowing for additional data to be
+        returned in error conditions, since "e-data" is insufficiently
+        flexible for some purposes.  TYPED-DATA is only present in the
+        extensible KRB-ERROR.
+
+           TDType ::= TH-id
+
+           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+               data-type   [0] TDType,
+               data-value  [1] OCTET STRING OPTIONAL
+           }
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 65]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+10.  Session Key Exchange
+
+   Session key exchange consists of the AP-REQ and AP-REP messages.  The
+   client sends the AP-REQ message, and the service responds with an
+   AP-REP message if mutual authentication is desired.  Following
+   session key exchange, the client and service share a secret session
+   key, or possibly a subsesion key, which can be used to protect
+   further communications.  Additionally, the session key exchange
+   process can establish initial sequence numbers which the client and
+   service can use to detect replayed messages.
+
+10.1.  AP-REQ
+
+   An AP-REQ message contains a ticket and a authenticator.  The
+   authenticator is ciphertext encrypted with the session key contained
+   in the ticket.  The plaintext contents of the authenticator are:
+
+      -- plaintext of authenticator
+      Authenticator1510       ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] RealmIA5,
+          cname               [2] PrincipalNameIA5,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum32 OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+      AuthenticatorExt        ::= [APPLICATION 35] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] RealmExt,
+          cname               [2] PrincipalNameExt,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL,
+          ...
+      }
+
+   The complete definition of AP-REQ is:
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 66]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     AP-REQ-1510,
+          ext         AP-REQ-EXT
+      }
+
+
+      AP-REQ-1510      ::= [APPLICATION 14] SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket1510,
+          authenticator       [4] EncryptedData {
+              Authenticator1510,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          }
+      }
+
+
+      AP-REQ-EXT      ::= [APPLICATION 18] Signed {
+          [APPLICATION 18] SEQUENCE {
+              pvno                [0] INTEGER (5),
+              msg-type            [1] INTEGER (18),
+              ap-options          [2] APOptions,
+              ticket              [3] Ticket,
+              authenticator       [4] EncryptedData {
+                  AuthenticatorExt,
+                  { key-session },
+                  { ku-APReq-authenticator |
+                    ku-pa-TGSReq-authenticator }
+              },
+              ...,
+              extensions          [5] ApReqExtensions OPTIONAL,
+              lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+              ...
+          }, { key-session }, { ku-APReq-cksum }
+      }
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 67]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+10.2.  AP-REP
+
+   An AP-REP message provides mutual authentication of the service to
+   the client.
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     EncAPRepPart1510,
+          ext         EncAPRepPartExt
+      }
+
+
+      EncAPRepPart1510        ::= [APPLICATION 27] SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum32 OPTIONAL
+      }
+
+
+      EncAPRepPartExt         ::= [APPLICATION 31] SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     AP-REP-1510,
+          ext         AP-REP-EXT
+      }
+
+
+      AP-REP-1510     ::= [APPLICATION 15] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15),
+          enc-part    [2] EncryptedData {
+              EncApRepPart1510,
+              { key-session | key-subsession }, { ku-EncAPRepPart }}
+      }
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 68]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      AP-REP-EXT      ::= [APPLICATION 19] Signed {
+          [APPLICATION 19] SEQUENCE {
+              pvno        [0] INTEGER (5),
+              msg-type    [1] INTEGER (19),
+              enc-part    [2] EncryptedData {
+                  EncAPRepPartExt,
+                  { key-session | key-subsession }, { ku-EncAPRepPart }},
+              ...,
+              extensions          [3] ApRepExtensions OPTIONAL,
+              ...
+          }, { key-session | key-subsession }, { ku-APRep-cksum }
+      }
+
+
+11.  Session Key Use
+
+   Once a session key has been established, the client and server can
+   use several kinds of messages to securely transmit data.  KRB-SAFE
+   provides integrity protection for application data, while KRB-PRIV
+   provides confidentiality along with integrity protection.  The KRB-
+   CRED message provides a means of securely forwarding credentials from
+   the client host to the server host.
+
+11.1.  KRB-SAFE
+
+   The KRB-SAFE message provides integrity protection for an included
+   cleartext message.
+
+      KRB-SAFE        ::= CHOICE {
+          rfc1510     KRB-SAFE-1510,
+          ext         KRB-SAFE-EXT
+      }
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+11.2.  KRB-PRIV
+
+   The KRB-PRIV message provides confidentiality and integrity
+   protection.
+
+
+Yu                         Expires: Apr 2007                   [Page 69]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+11.3.  KRB-CRED
+
+   The KRB-CRED message provides a means of securely transferring
+   credentials from the client to the service.
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     KRB-CRED-1510,
+          ext         KRB-CRED-EXT
+
+      }
+
+
+      KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }}
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 70]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] Signed {
+          [APPLICATION 24] SEQUENCE {
+              pvno        [0] INTEGER (5),
+              msg-type    [1] INTEGER (24),
+              tickets     [2] SEQUENCE OF Ticket,
+              enc-part    [3] EncryptedData {
+                  EncKrbCredPart,
+                  { key-session | key-subsession }, { ku-EncKrbCredPart }},
+              ...
+          }, { key-session | key-subsession }, { ku-KrbCred-cksum }
+      }
+
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+12.  Security Considerations
+
+12.1.  Time Synchronization
+
+   Time synchronization between the KDC and application servers is
+   necessary to prevent acceptance of expired tickets.
+
+   Time synchronization is needed between application servers and
+   clients to prevent replay attacks if a replay cache is being used.
+   If negotiated subsession keys are used to encrypt application data,
+   replay caches may not be necessary.
+
+
+Yu                         Expires: Apr 2007                   [Page 71]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+12.2.  Replays
+
+12.3.  Principal Name Reuse
+
+   See Section 5.3.
+
+12.4.  Password Guessing
+
+12.5.  Forward Secrecy
+
+   [from KCLAR 10.; needs some rewriting]
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB-PRIV message,
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the TGS-REP
+   message.  The session key from the ticket-granting ticket was sent to
+   the user in the AS-REP message encrypted in the user's secret key,
+   and embedded in the ticket-granting ticket, which was encrypted in
+   the key of the KDC.  Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+12.6.  Authorization
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  Kerberos does not, by
+   itself, provide authorization.  Applications SHOULD NOT accept the
+   mere issuance of a service ticket by the Kerberos server as granting
+   authority to use the service.
+
+12.7.  Login Authentication
+
+   Some applications, particularly those which provide login access when
+   provided with a password, SHOULD NOT treat successful acquisition of
+   credentials as sufficient proof of the user's identity.  An attacker
+   posing as a user could generate an illegitimate KDC-REP message which
+   decrypts properly.  To authenticate a user logging on to a local
+   system, the credentials obtained SHOULD be used in a TGS exchange to
+   obtain credentials for a local service.  Successful use of those
+   credentials to authenticate to the local service assures that the
+   initially obtained credentials are from a valid KDC.
+
+
+
+Yu                         Expires: Apr 2007                   [Page 72]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+13.  IANA Considerations
+
+   [ needs more work ]
+
+   Each use of Int32 in this document defines a number space.  [ XXX
+   enumerate these ] Negative numbers are reserved for private use;
+   local and experimental extensions should use these values.  Zero is
+   reserved and may not be assigned.
+
+   Typed hole contents may be identified by either Int32 values or by
+   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
+   namespace, assignments to the top level of the RELATIVE-OID space may
+   be made on a first-come, first-served basis.
+
+14.  Acknowledgments
+
+   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
+   clarifications-07.  The description of the general form of the
+   extensibility framework was derived from text by Sam Hartman.  Some
+   text concerning internationalization of internationalized domain
+   names in principal names and realm names was contributed by Jeffrey
+   Altman and Jeffrey Hutzelman.
+
+Appendices
+
+A.  ASN.1 Module (Normative)
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related
+      -- OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
+      -- OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2)
+      }
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 73]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+      --
+      -- *** basic types
+      --
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+Yu                         Expires: Apr 2007                   [Page 74]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 75]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+      PrincipalName { StrType }       ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString (StrType)
+      }
+
+
+      -- IA5 only
+      PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
+      -- IA5 excluded
+      PrincipalNameExt ::= PrincipalName { KerberosStringExt }
+      -- Either one?
+      PrincipalNameEither ::= PrincipalName { KerberosString }
+
+
+      Realm { StrType }       ::= KerberosString (StrType)
+
+      -- IA5 only
+      RealmIA5                ::= Realm { KerberosStringIA5 }
+
+      -- IA5 excluded
+      RealmExt                ::= Realm { KerberosStringExt }
+
+      -- Either
+      RealmEither             ::= Realm { KerberosString }
+
+
+
+Yu                         Expires: Apr 2007                   [Page 76]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+      })
+
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+      --
+      -- *** crypto-related types and assignments
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 77]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 78]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 29
+      ku-ASReq-cksum                  KeyUsage ::= 30
+      ku-TGSReq-cksum                 KeyUsage ::= 31
+      ku-ASRep-cksum                  KeyUsage ::= 32
+      ku-TGSRep-cksum                 KeyUsage ::= 33
+      ku-APReq-cksum                  KeyUsage ::= 34
+      ku-APRep-cksum                  KeyUsage ::= 35
+      ku-KrbCred-cksum                KeyUsage ::= 36
+      ku-KrbError-cksum               KeyUsage ::= 37
+      ku-KDCRep-cksum                 KeyUsage ::= 38
+
+      ku-kg-acceptor-seal             KeyUsage ::= 22
+      ku-kg-acceptor-sign             KeyUsage ::= 23
+      ku-kg-intiator-seal             KeyUsage ::= 24
+      ku-kg-intiator-sign             KeyUsage ::= 25
+
+      -- KeyUsage values 25..27 used by hardware preauth?
+
+      -- for KINK
+      ku-kink-encrypt                 KeyUsage ::= 39
+      ku-kink-cksum                   KeyUsage ::= 40
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 79]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 80]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 81]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+      --
+      -- *** Tickets
+      --
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     Ticket1510,
+          ext         TicketExt
+      }
+
+
+      Ticket1510      ::= [APPLICATION 1] SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] RealmIA5,
+          sname       [2] PrincipalNameIA5,
+          enc-part    [3] EncryptedData {
+              EncTicketPart1510, { key-server }, { ku-Ticket }
+          }
+      }
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 82]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      TicketExt       ::= [APPLICATION 4] Signed {
+          [APPLICATION 4] SEQUENCE {
+              tkt-vno     [0] INTEGER (5),
+              realm       [1] RealmExt,
+              sname       [2] PrincipalNameExt,
+              enc-part    [3] EncryptedData {
+                  EncTicketPartExt, { key-server }, { ku-Ticket }
+              },
+              ...,
+              extensions          [4] TicketExtensions OPTIONAL,
+              ...
+          },
+          { key-ticket }, { ku-Ticket-cksum }
+      }
+
+
+      -- Encrypted part of ticket
+      EncTicketPart   ::= CHOICE {
+          rfc1510     EncTicketPart1510,
+          ext         EncTicketPartExt
+      }
+
+
+      EncTicketPart1510       ::= [APPLICATION 3] SEQUENCE {
+          flags               [0] TicketFlags,
+          key                 [1] EncryptionKey,
+          crealm              [2] RealmIA5,
+          cname               [3] PrincipalNameIA5,
+          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
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 83]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      EncTicketPartExt        ::= [APPLICATION 5] SEQUENCE {
+          flags               [0] TicketFlags,
+          key                 [1] EncryptionKey,
+          crealm              [2] RealmExt,
+          cname               [3] PrincipalNameExt,
+          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,
+          ...,
+      }
+
+
+      --
+      -- *** Authorization Data
+      --
+
+
+      ADType          ::= TH-id
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      AD-IF-RELEVANT          ::= AuthorizationData
+
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 84]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      ad-and-or               ADType ::= int32 : 5
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] Int32,
+          elements            [1] AuthorizationData
+      }
+
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+
+      ad-initial-verified-cas         ADType ::= int32 : 9
+
+
+      TrType                  ::= TH-id -- must be registered
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+          tr-type     [0] TrType,
+          contents    [1] OCTET STRING
+      }
+
+
+      TEType                  ::= TH-id
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 85]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+      --
+      -- *** KDC protocol
+      --
+
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     AS-REQ-1510,
+          ext         AS-REQ-EXT
+      }
+      AS-REQ-1510     ::= [APPLICATION 10] KDC-REQ-1510
+          -- AS-REQ must include client name
+
+      AS-REQ-EXT      ::= [APPLICATION 6] Signed {
+          [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum }
+      }
+      -- AS-REQ must include client name
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     TGS-REQ-1510,
+          ext         TGS-REQ-EXT
+      }
+
+      TGS-REQ-1510    ::= [APPLICATION 12] KDC-REQ-1510
+
+      TGS-REQ-EXT     ::= [APPLICATION 8] Signed {
+          [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum }
+      }
+
+
+Yu                         Expires: Apr 2007                   [Page 86]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REQ-1510    ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (  10 -- AS-REQ --
+                                   | 12 -- TGS-REQ -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL,
+          req-body    [4] KDC-REQ-BODY-1510
+      }
+
+
+      KDC-REQ-EXT     ::= SEQUENCE {
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (  6 -- AS-REQ --
+                                   | 8 -- TGS-REQ -- ),
+          padata      [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      }
+
+
+      KDC-REQ-BODY-1510       ::= SEQUENCE {
+          kdc-options         [0] KDCOptions,
+          cname               [1] PrincipalNameIA5 OPTIONAL
+          -- Used only in AS-REQ --,
+
+          realm               [2] RealmIA5
+          -- Server's realm; also client's in AS-REQ --,
+
+          sname               [3] PrincipalNameIA5 OPTIONAL,
+          from                [4] KerberosTime OPTIONAL,
+          till                [5] KerberosTime,
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce32,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --
+      }
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 87]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REQ-BODY-EXT        ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 88]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+      AS-REP          ::= CHOICE {
+          rfc1510     AS-REP-1510,
+          ext         AS-REP-EXT
+      }
+      AS-REP-1510     ::= [APPLICATION 11] KDC-REP-1510
+      AS-REP-EXT      ::= [APPLICATION 7] Signed {
+          [APPLICATION 7] KDC-REP-EXT,
+          { key-reply }, { ku-ASRep-cksum }
+      }
+
+
+      TGS-REP         ::= CHOICE {
+          rfc1510     TGS-REP-1510,
+          ext         TGS-REP-EXT
+      }
+      TGS-REP-1510    ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 }
+      TGS-REP-EXT     ::= [APPLICATION 9] Signed {
+          [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+          { key-reply }, { ku-TGSRep-cksum }
+      }
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 89]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] RealmIA5,
+          cname       [4] PrincipalNameIA5,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          }
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 90]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KDC-REP-EXT { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] RealmExt,
+          cname       [4] PrincipalNameExt,
+          ticket      [5] Ticket,
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 91]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce32,
+          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] RealmIA5,
+          sname               [10] PrincipalNameIA5,
+          caddr               [11] HostAddresses OPTIONAL
+      }
+
+      EncKDCRepPartExt        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+
+      LRType          ::=     TH-id
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+          lr-type     [0] LRType,
+          lr-value    [1] KerberosTime
+      }
+
+
+      --
+      -- *** preauth
+      --
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 92]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      PaDataType      ::= TH-id
+      PaDataOID       ::= RELATIVE-OID
+
+      PA-DATA ::= SEQUENCE {
+          -- NOTE: first tag is [1], not [0]
+          padata-type         [1] PaDataType,
+          padata-value        [2] OCTET STRING
+      }
+
+
+      -- AP-REQ authenticating a TGS-REQ
+      pa-tgs-req              PaDataType ::= int32 : 1
+      PA-TGS-REQ              ::= AP-REQ
+
+
+      -- Encrypted timestamp preauth
+      -- Encryption key used is client's long-term key.
+      pa-enc-timestamp        PaDataType ::= int32 : 2
+
+      PA-ENC-TIMESTAMP ::= EncryptedData {
+          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
+      }
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+      -- Hints returned in AS-REP or KRB-ERROR to help client
+      -- choose a password-derived key, either for preauthentication
+      -- or for decryption of the reply.
+      pa-etype-info           PaDataType ::= int32 : 11
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 93]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Similar to etype-info, but with parameters provided for
+      -- the string-to-key function.
+      pa-etype-info2          PaDataType ::= int32 : 19
+
+      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
+                                      OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+
+      -- Obsolescent.  Salt for client long-term key
+      -- Its character encoding is unspecified.
+      pa-pw-salt              PaDataType ::= int32 : 3
+
+      -- The "padata-value" does not encode an ASN.1 type.
+      -- Instead, "padata-value" must consist of the salt string to
+      -- be used by the client, in an unspecified character
+      -- encoding.
+
+
+      -- An extensible AS-REQ may be sent as a padata in a
+      -- non-extensible AS-REQ to allow for backwards compatibility.
+      pa-as-req               PaDataType ::= int32 : 42 -- provisional
+      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
+
+
+      --
+      -- *** Session key exchange
+      --
+
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     AP-REQ-1510,
+          ext         AP-REQ-EXT
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 94]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      AP-REQ-1510      ::= [APPLICATION 14] SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket1510,
+          authenticator       [4] EncryptedData {
+              Authenticator1510,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          }
+      }
+
+
+      AP-REQ-EXT      ::= [APPLICATION 18] Signed {
+          [APPLICATION 18] SEQUENCE {
+              pvno                [0] INTEGER (5),
+              msg-type            [1] INTEGER (18),
+              ap-options          [2] APOptions,
+              ticket              [3] Ticket,
+              authenticator       [4] EncryptedData {
+                  AuthenticatorExt,
+                  { key-session },
+                  { ku-APReq-authenticator |
+                    ku-pa-TGSReq-authenticator }
+              },
+              ...,
+              extensions          [5] ApReqExtensions OPTIONAL,
+              lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+              ...
+          }, { key-session }, { ku-APReq-cksum }
+      }
+
+
+      ApReqExtType    ::= TH-id
+
+      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apReqExt-Type       [0] ApReqExtType,
+          apReqExt-Data       [1] OCTET STRING
+      }
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+Yu                         Expires: Apr 2007                   [Page 95]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- plaintext of authenticator
+      Authenticator1510       ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] RealmIA5,
+          cname               [2] PrincipalNameIA5,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum32 OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+      AuthenticatorExt        ::= [APPLICATION 35] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] RealmExt,
+          cname               [2] PrincipalNameExt,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     AP-REP-1510,
+          ext         AP-REP-EXT
+      }
+
+
+      AP-REP-1510     ::= [APPLICATION 15] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15),
+          enc-part    [2] EncryptedData {
+              EncApRepPart1510,
+              { key-session | key-subsession }, { ku-EncAPRepPart }}
+      }
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 96]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      AP-REP-EXT      ::= [APPLICATION 19] Signed {
+          [APPLICATION 19] SEQUENCE {
+              pvno        [0] INTEGER (5),
+              msg-type    [1] INTEGER (19),
+              enc-part    [2] EncryptedData {
+                  EncAPRepPartExt,
+                  { key-session | key-subsession }, { ku-EncAPRepPart }},
+              ...,
+              extensions          [3] ApRepExtensions OPTIONAL,
+              ...
+          }, { key-session | key-subsession }, { ku-APRep-cksum }
+      }
+
+
+      ApRepExtType    ::= TH-id
+
+      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apRepExt-Type       [0] ApRepExtType,
+          apRepExt-Data       [1] OCTET STRING
+      }
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     EncAPRepPart1510,
+          ext         EncAPRepPartExt
+      }
+
+
+      EncAPRepPart1510        ::= [APPLICATION 27] SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum32 OPTIONAL
+      }
+
+
+      EncAPRepPartExt         ::= [APPLICATION 31] SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Application messages
+      --
+
+
+Yu                         Expires: Apr 2007                   [Page 97]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KRB-SAFE        ::= CHOICE {
+          rfc1510     KRB-SAFE-1510,
+          ext         KRB-SAFE-EXT
+      }
+
+
+      KRB-SAFE-1510   ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }}
+      }
+
+
+      -- Has safe-body optional to allow for GSS-MIC type functionality
+      KRB-SAFE-EXT    ::= [APPLICATION 34] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY OPTIONAL,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...
+      }
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 98]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     KRB-CRED-1510,
+          ext         KRB-CRED-EXT
+
+      }
+
+
+      KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }}
+      }
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] Signed {
+          [APPLICATION 24] SEQUENCE {
+              pvno        [0] INTEGER (5),
+              msg-type    [1] INTEGER (24),
+              tickets     [2] SEQUENCE OF Ticket,
+              enc-part    [3] EncryptedData {
+                  EncKrbCredPart,
+                  { key-session | key-subsession }, { ku-EncKrbCredPart }},
+              ...
+          }, { key-session | key-subsession }, { ku-KrbCred-cksum }
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                   [Page 99]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
+          pvno            [0] INTEGER (5),
+          msg-type        [1] INTEGER (16),
+          sname           [2] PrincipalName OPTIONAL,
+          srealm          [3] Realm OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Error messages
+      --
+
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     KRB-ERROR-1510,
+          ext         KRB-ERROR-EXT
+      }
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                  [Page 100]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] RealmIA5 OPTIONAL,
+          cname       [8] PrincipalNameIA5 OPTIONAL,
+          realm       [9] RealmIA5 -- Correct realm --,
+          sname       [10] PrincipalNameIA5 -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL
+      }
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
+          [APPLICATION 23] SEQUENCE{
+              pvno        [0] INTEGER (5),
+              msg-type    [1] INTEGER (23),
+              ctime       [2] KerberosTime OPTIONAL,
+              cusec       [3] Microseconds OPTIONAL,
+              stime       [4] KerberosTime,
+              susec       [5] Microseconds,
+              error-code  [6] ErrCode,
+              crealm      [7] Realm OPTIONAL,
+              cname       [8] PrincipalName OPTIONAL,
+              realm       [9] Realm -- Correct realm --,
+              sname       [10] PrincipalName -- Correct name --,
+              e-text      [11] KerberosString OPTIONAL,
+              e-data      [12] OCTET STRING OPTIONAL,
+              ...,
+              typed-data          [13] TYPED-DATA OPTIONAL,
+              nonce               [14] Nonce OPTIONAL,
+              lang-tag            [15] LangTag OPTIONAL,
+              ...
+          }, { }, { ku-KrbError-cksum }
+      }
+
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+      TDType ::= TH-id
+
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+          data-type   [0] TDType,
+          data-value  [1] OCTET STRING OPTIONAL
+      }
+
+
+Yu                         Expires: Apr 2007                  [Page 101]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      td-dh-parameters        TDType ::= int32 : 109
+
+
+      --
+      -- *** Error codes
+      --
+
+      -- No error
+      kdc-err-none                          ErrCode ::= 0
+      -- Client's entry in database has expired
+      kdc-err-name-exp                      ErrCode ::= 1
+      -- Server's entry in database has expired
+      kdc-err-service-exp                   ErrCode ::= 2
+      -- Requested protocol version number not supported
+      kdc-err-bad-pvno                      ErrCode ::= 3
+      -- Client's key encrypted in old master key
+      kdc-err-c-old-mast-kvno               ErrCode ::= 4
+      -- Server's key encrypted in old master key
+      kdc-err-s-old-mast-kvno               ErrCode ::= 5
+      -- Client not found in Kerberos database
+      kdc-err-c-principal-unknown           ErrCode ::= 6
+      -- Server not found in Kerberos database
+      kdc-err-s-principal-unknown           ErrCode ::= 7
+      -- Multiple principal entries in database
+      kdc-err-principal-not-unique          ErrCode ::= 8
+      -- The client or server has a null key
+      kdc-err-null-key                      ErrCode ::= 9
+      -- Ticket not eligible for postdating
+      kdc-err-cannot-postdate               ErrCode ::= 10
+      -- Requested start time is later than end time
+      kdc-err-never-valid                   ErrCode ::= 11
+      -- KDC policy rejects request
+      kdc-err-policy                        ErrCode ::= 12
+      -- KDC cannot accommodate requested option
+      kdc-err-badoption                     ErrCode ::= 13
+      -- KDC has no support for encryption type
+      kdc-err-etype-nosupp                  ErrCode ::= 14
+      -- KDC has no support for checksum type
+      kdc-err-sumtype-nosupp                ErrCode ::= 15
+      -- KDC has no support for padata type
+      kdc-err-padata-type-nosupp            ErrCode ::= 16
+      -- KDC has no support for transited type
+      kdc-err-trtype-nosupp                 ErrCode ::= 17
+      -- Clients credentials have been revoked
+      kdc-err-client-revoked                ErrCode ::= 18
+      -- Credentials for server have been revoked
+      kdc-err-service-revoked               ErrCode ::= 19
+      -- TGT has been revoked
+      kdc-err-tgt-revoked                   ErrCode ::= 20
+
+
+
+Yu                         Expires: Apr 2007                  [Page 102]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Client not yet valid - try again later
+      kdc-err-client-notyet                 ErrCode ::= 21
+      -- Server not yet valid - try again later
+      kdc-err-service-notyet                ErrCode ::= 22
+      -- Password has expired - change password to reset
+      kdc-err-key-expired                   ErrCode ::= 23
+      -- Pre-authentication information was invalid
+      kdc-err-preauth-failed                ErrCode ::= 24
+      -- Additional pre-authenticationrequired
+      kdc-err-preauth-required              ErrCode ::= 25
+      -- Requested server and ticket don't match
+      kdc-err-server-nomatch                ErrCode ::= 26
+      -- Server principal valid for user2user only
+      kdc-err-must-use-user2user            ErrCode ::= 27
+      -- KDC Policy rejects transited path
+      kdc-err-path-not-accpeted             ErrCode ::= 28
+      -- A service is not available
+      kdc-err-svc-unavailable               ErrCode ::= 29
+      -- Integrity check on decrypted field failed
+      krb-ap-err-bad-integrity              ErrCode ::= 31
+      -- Ticket expired
+      krb-ap-err-tkt-expired                ErrCode ::= 32
+      -- Ticket not yet valid
+      krb-ap-err-tkt-nyv                    ErrCode ::= 33
+      -- Request is a replay
+      krb-ap-err-repeat                     ErrCode ::= 34
+      -- The ticket isn't for us
+      krb-ap-err-not-us                     ErrCode ::= 35
+      -- Ticket and authenticator don't match
+      krb-ap-err-badmatch                   ErrCode ::= 36
+      -- Clock skew too great
+      krb-ap-err-skew                       ErrCode ::= 37
+      -- Incorrect net address
+      krb-ap-err-badaddr                    ErrCode ::= 38
+      -- Protocol version mismatch
+      krb-ap-err-badversion                 ErrCode ::= 39
+      -- Invalid msg type
+      krb-ap-err-msg-type                   ErrCode ::= 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                  [Page 103]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Message stream modified
+      krb-ap-err-modified                   ErrCode ::= 41
+      -- Message out of order
+      krb-ap-err-badorder                   ErrCode ::= 42
+      -- Specified version of key is not available
+      krb-ap-err-badkeyver                  ErrCode ::= 44
+      -- Service key not available
+      krb-ap-err-nokey                      ErrCode ::= 45
+      -- Mutual authentication failed
+      krb-ap-err-mut-fail                   ErrCode ::= 46
+      -- Incorrect message direction
+      krb-ap-err-baddirection               ErrCode ::= 47
+      -- Alternative authentication method required
+      krb-ap-err-method                     ErrCode ::= 48
+      -- Incorrect sequence number in message
+      krb-ap-err-badseq                     ErrCode ::= 49
+      -- Inappropriate type of checksum in message
+      krb-ap-err-inapp-cksum                ErrCode ::= 50
+      -- Policy rejects transited path
+      krb-ap-path-not-accepted              ErrCode ::= 51
+      -- Response too big for UDP, retry with TCP
+      krb-err-response-too-big              ErrCode ::= 52
+      -- Generic error (description in e-text)
+      krb-err-generic                       ErrCode ::= 60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                  [Page 104]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+      -- Field is too long for this implementation
+      krb-err-field-toolong                 ErrCode ::= 61
+      -- Reserved for PKINIT
+      kdc-error-client-not-trusted          ErrCode ::= 62
+      -- Reserved for PKINIT
+      kdc-error-kdc-not-trusted             ErrCode ::= 63
+      -- Reserved for PKINIT
+      kdc-error-invalid-sig                 ErrCode ::= 64
+      -- Reserved for PKINIT
+      kdc-err-key-too-weak                  ErrCode ::= 65
+      -- Reserved for PKINIT
+      kdc-err-certificate-mismatch          ErrCode ::= 66
+      -- No TGT available to validate USER-TO-USER
+      krb-ap-err-no-tgt                     ErrCode ::= 67
+      -- USER-TO-USER TGT issued different KDC
+      kdc-err-wrong-realm                   ErrCode ::= 68
+      -- Ticket must be for USER-TO-USER
+      krb-ap-err-user-to-user-required      ErrCode ::= 69
+      -- Reserved for PKINIT
+      kdc-err-cant-verify-certificate       ErrCode ::= 70
+      -- Reserved for PKINIT
+      kdc-err-invalid-certificate           ErrCode ::= 71
+      -- Reserved for PKINIT
+      kdc-err-revoked-certificate           ErrCode ::= 72
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unknown     ErrCode ::= 73
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unavailable ErrCode ::= 74
+      -- Reserved for PKINIT
+      kdc-err-client-name-mismatch          ErrCode ::= 75
+      --  Reserved for PKINIT
+      kdc-err-kdc-name-mismatch             ErrCode ::= 76
+      --  Reserved for PKINIT
+      kdc-err-inconsistent-key-purpose      ErrCode ::= 77
+      --  Reserved for PKINIT
+      kdc-err-digest-in-cert-not-accepted   ErrCode ::= 78
+      --  Reserved for PKINIT
+      kdc-err-pa-checksum-must-be-included  ErrCode ::= 79
+      --  Reserved for PKINIT
+      kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80
+      --  Reserved for PKINIT
+      kdc-err-public-key-encryption-not-supported ErrCode ::= 81
+
+
+      END
+
+
+B.  Kerberos and Character Encodings (Informative)
+
+   [adapted from KCLAR 5.2.1]
+
+
+Yu                         Expires: Apr 2007                  [Page 105]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO 2022 | ECMA-35
+   [ISO2022] to switch character sets, and the default character set
+   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
+   International Reference Version (IRV) (aka U.S. ASCII), which mostly
+   works.
+
+   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER previously
+   [X690-1997] prohibited the designation of character sets as any but
+   the G0 and C0 sets.  This had the side effect of prohibiting the use
+   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
+   other character-sets that utilize a 96-character set, since it is
+   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
+   element.  Recent revisions to the ASN.1 standards resolve this
+   contradiction.
+
+   In practice, many implementations treat RFC 1510 GeneralStrings as if
+   they were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to conform to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   [the following should probably be rewritten and moved into the
+   principal name section]
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way.  Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters.  This is a violation of the ASN.1
+   standard.  Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+
+Yu                         Expires: Apr 2007                  [Page 106]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   ASN.1 standard is not violated in this regard.  As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+C.  Kerberos History (Informative)
+
+   [Adapted from KCLAR "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 Ts'o, 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 [KNT94].
+
+D.  Notational Differences from [KCLAR]
+
+   [ possible point for discussion ]
+
+
+Yu                         Expires: Apr 2007                  [Page 107]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   [KCLAR] uses notational conventions slightly different from this
+   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
+   language style identifier names for defined values.  In ASN.1
+   notation, identifiers referencing defined values must begin with a
+   lowercase letter and contain hyphen (-) characters rather than
+   underscore (_) characters, while identifiers referencing types begin
+   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
+   identifiers with underscores to identify defined values.  This has
+   the potential to create confusion, but neither document defines
+   values using actual ASN.1 value-assignment notation.
+
+   It is debatable whether it is advantageous to write all identifier
+   names (regardless of their ASN.1 token type) in all-uppercase letters
+   for the purpose of emphasis in running text.  The alternative is to
+   use double-quote characters (") when ambiguity is possible.
+
+Normative References
+
+   [ISO646]
+        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
+
+   [ISO2022]
+        "Information technology -- Character code structure and
+        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
+
+   [KCRYPTO]
+        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
+        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
+
+   [RFC2119]
+        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+        Requirement Levels", March 1997.
+
+   [RFC3660]
+        H. Alvestrand, "Tags for the Identification of Languages",
+        RFC 3660, January 2001.
+
+   [SASLPREP]
+        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
+        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
+        progress.
+
+   [X680]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Specification of basic notation", ITU-T Recommendation X.680
+        (2002) | ISO/IEC 8824-1:2002.
+
+   [X682]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Constraint specification", ITU-T Recommendation X.682 (2002) |
+        ISO/IEC 8824-3:2002.
+
+Yu                         Expires: Apr 2007                  [Page 108]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   [X683]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Parameterization of ASN.1 specifications", ITU-T Recommendation
+        X.683 (2002) | ISO/IEC 8824-4:2002.
+
+   [X690]
+        "Information technology -- ASN.1 encoding Rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+Informative References
+
+   [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).
+
+   [Dub00]
+        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
+        Systems", Elsevier-Morgan Kaufmann, 2000.
+        <http://www.oss.com/asn1/dubuisson.html>
+
+   [ISO8859-1]
+        "Information technology -- 8-bit single-byte coded graphic
+        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
+        1:1998.
+
+   [KCLAR]
+        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
+        Network Authentication Service (V5)", draft-ietf-krb-wg-
+        kerberos-clarifications-07.txt, work in progress.
+
+   [KNT94]
+        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+        Evolution of the Kerberos Authentication System".  In
+        Distributed Open Systems, pages 78-94.  IEEE Computer Society
+        Press, 1994.
+
+   [Lar96]
+        John Larmouth, "Understanding OSI", International Thomson
+        Computer Press, 1996.
+        <http://www.isi.salford.ac.uk/books/osi.html>
+
+   [Lar99]
+        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
+        1999.  <http://www.oss.com/asn1/larmouth.html>
+
+   [NS78]
+        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+        Authentication in Large Networks of Computers", Communications
+
+Yu                         Expires: Apr 2007                  [Page 109]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+   [RFC1510]
+        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
+        Service (v5)", RFC1510, September 1993, Status: Proposed
+        Standard.
+
+   [RFC1964]
+        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
+        June 1996, Status: Proposed Standard.
+
+   [X690-2002]
+        "Information technology -- ASN.1 encoding rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+Author's Address
+
+   Tom Yu
+   77 Massachusetts Ave
+   Cambridge, MA 02139
+   USA
+   tlyu@mit.edu
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+
+Yu                         Expires: Apr 2007                  [Page 110]
+
+Internet-Draft               rfc1510ter-03                   23 Oct 2006
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2007                  [Page 111]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt
new file mode 100644
index 00000000000..abb6787b250
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt
@@ -0,0 +1,392 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                                       SJD
+Updates: 4120 (if approved)                                 May 10, 2006
+Expires: November 11, 2006
+
+
+Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
+                                  TCP
+                   draft-ietf-krb-wg-tcp-expansion-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on November 11, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes an extensibility mechanism for the Kerberos
+   v5 protocol when used over TCP transports.
+
+
+
+
+
+
+
+
+Josefsson               Expires November 11, 2006               [Page 1]
+
+Internet-Draft          Kerberos V5 TCP extension               May 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
+   3.  Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
+   4.  Interoperability Consideration  . . . . . . . . . . . . . . . . 4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+   Appendix A.  Copying conditions . . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires November 11, 2006               [Page 2]
+
+Internet-Draft          Kerberos V5 TCP extension               May 2006
+
+
+1.  Introduction
+
+   The Kerberos 5 [3] specification, in section 7.2.2, reserve the high
+   order bit in the initial length field for TCP transport for future
+   expansion.  This document update [3] to describe the behaviour when
+   that bit is set.  This mechanism is intended for extensions that are
+   specific for the TCP transport.
+
+
+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 [1].
+
+
+3.  Extension Mechanism for TCP transport
+
+   The reserved high bit of the request length field is used to signal
+   the use of this extension mechanism.  When the reserved high bit is
+   set, the remaining 31 bits of the initial 4 octets are interpreted as
+   a bitmap.  Each bit in the bitmask can be used to request a
+   particular extension.  The 31 bits form the "extension bitmask".  It
+   is expected that other documents will describe the details associated
+   with particular bits.
+
+   A 4-octet value with only the high bit set, and thus the extension
+   bitmask all zeros, is called a PROBE.  A client may send a probe to
+   find out which extensions a KDC support.  A client may also set
+   particular bits in the extension bitmask directly, if it does not
+   need to query the KDC for available extensions before deciding which
+   extension to request.
+
+   If a KDC receive a PROBE, or if a KDC does not support all extensions
+   corresponding to set bits in the extension bitmask, the KDC MUST
+   return 4 octets with the high bit set, and with the remaining bitmask
+   indicate which extensions it supports.  The KDC SHOULD NOT close the
+   connection, and SHOULD wait for the client to then send a second
+   4-octet value, with the high bit set and the remaining bits as the
+   bitmask, to request a particular extension.  If the second 4-octet
+   value is a PROBE or an unsupported extension, the KDC MUST close the
+   connection.  This is used by the client to shutdown a session when
+   the KDC did not support a, by the client, required extension.
+
+   Resource avaibility considerations may influence whether, and for how
+   long, the KDC will wait for the client to send requests.
+
+   The behaviour when more than one non-high bit is set depends on the
+
+
+
+Josefsson               Expires November 11, 2006               [Page 3]
+
+Internet-Draft          Kerberos V5 TCP extension               May 2006
+
+
+   particular extension mechanisms.  If a requested extension (bit X)
+   does not specify how it interact with another requested extensions
+   (bit Y), the KDC MUST treat the request as a PROBE or unsupported
+   extension, and proceed as above.
+
+   Each extension MUST describe the structure of protocol data beyond
+   the length field, and the behaviour of the client and KDC.  If an
+   extension mechanism reserve multiple bits, it MUST describe how they
+   interact.
+
+
+4.  Interoperability Consideration
+
+   Implementations with support for TCP that do not claim to conform to
+   RFC 4120 may not handle the high bit correctly.  Behaviour may
+   include closing the TCP connection without any response, and logging
+   an error message in the KDC log.  When this was written, this problem
+   existed in modern versions of popular implementations.
+   Implementations experiencing trouble getting the expected responses
+   from a server SHOULD assume that it does not support this extension
+   mechanism.  Clients MAY remember this semi-permanently, to avoid
+   excessive logging in the server.  Care should be taken to avoid
+   unexpected behaviour for the user when the KDC is eventually
+   upgraded.  Implementations MAY also provide a way to enable and
+   disable this extension on a per-realm basis.  How to handle these
+   backwards compatibility quirks are in general left unspecified.
+
+
+5.  Security Considerations
+
+   Because the initial length field is not protected, it is possible for
+   an active attacker (i.e., one that is able to modify traffic between
+   the client and the KDC) to make it appear to the client that the
+   server does not support this extension mechanism.  Client and KDC
+   policies can be used to reject connections that does not use any
+   expansion.
+
+
+6.  IANA Considerations
+
+   IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
+   The initial contents of this registry should be:
+
+   [[RFC Editor: Replace xxxx below with the number of this RFC.]]
+
+   Bit #         Meaning                             Reference
+   -----         -------                             ---------
+   0..29         AVAILABLE for registration.
+
+
+
+Josefsson               Expires November 11, 2006               [Page 4]
+
+Internet-Draft          Kerberos V5 TCP extension               May 2006
+
+
+   30            RESERVED.                           RFC XXXX
+
+   IANA will register values 0 to 29 after IESG Approval, as defined in
+   BCP 64 [2].  Assigning value 30 requires a Standards Action that
+   update or obsolete this document.
+
+
+7.  Acknowledgements
+
+   Thanks to Andrew Bartlett who pointed out that some implementations
+   (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
+   regards to the high bit, which resulted in an Interoperability
+   Consideration.
+
+   Nicolas Williams and Jeffrey Hutzelman provided comments that
+   improved the document.
+
+8.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)", RFC 4120, July 2005.
+
+
+Appendix A.  Copying conditions
+
+   Copyright (C) 2005, 2006 Simon Josefsson
+
+   Regarding this entire document or any portion of it, the author makes
+   no guarantees and is not responsible for any damage resulting from
+   its use.  The author grants irrevocable permission to anyone to use,
+   modify, and distribute it in any way that does not diminish the
+   rights of anyone else to use, modify, and distribute it, provided
+   that redistributed derivative works do not contain misleading author
+   or version information.  Derivative works need not be licensed under
+   similar terms.
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires November 11, 2006               [Page 5]
+
+Internet-Draft          Kerberos V5 TCP extension               May 2006
+
+
+Author's Address
+
+   Simon Josefsson
+   SJD
+
+   Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires November 11, 2006               [Page 6]
+
+Internet-Draft          Kerberos V5 TCP extension               May 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Josefsson               Expires November 11, 2006               [Page 7]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-sasl-gs2-11.txt b/third_party/heimdal/doc/standardisation/draft-ietf-sasl-gs2-11.txt
new file mode 100644
index 00000000000..f9316e6c447
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-sasl-gs2-11.txt
@@ -0,0 +1,1232 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                                    SJD AB
+Intended status: Standards Track                             N. Williams
+Expires: September 24, 2009                             Sun Microsystems
+                                                          March 23, 2009
+
+
+       Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
+                         draft-ietf-sasl-gs2-11
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.  This document may contain material
+   from IETF Documents or IETF Contributions published or made publicly
+   available before November 10, 2008.  The person(s) controlling the
+   copyright in some of this material may not have granted the IETF
+   Trust the right to allow modifications of such material outside the
+   IETF Standards Process.  Without obtaining an adequate license from
+   the person(s) controlling the copyright in such materials, this
+   document may not be modified outside the IETF Standards Process, and
+   derivative works of it may not be created outside the IETF Standards
+   Process, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+   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 Internet-Draft will expire on September 24, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 1]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document describes how to use a Generic Security Service
+   Application Program Interface (GSS-API) mechanism in the the Simple
+   Authentication and Security Layer (SASL) framework.  This is done by
+   defining a new SASL mechanism family, called GS2.  This mechanism
+   family offers a number of improvements over the previous "SASL/
+   GSSAPI" mechanism: it is more general, uses fewer messages for the
+   authentication phase in some cases, and supports negotiable use of
+   channel binding.  Only GSS-API mechanisms that support channel
+   binding are supported.
+
+   See <http://josefsson.org/sasl-gs2-*/> for more information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 2]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
+   3.  Mechanism name . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Generating SASL mechanism names from GSS-API OIDs  . . . .  5
+     3.2.  Computing mechanism names manually . . . . . . . . . . . .  5
+     3.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  SASL Authentication Exchange Message Format  . . . . . . . . .  7
+     4.1.  SASL Messages  . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Authentication Conditions  . . . . . . . . . . . . . . . . . . 11
+   8.  GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   10. GSS_Mechanism_SASLname call  . . . . . . . . . . . . . . . . . 11
+     10.1. gss_mechanism_saslname . . . . . . . . . . . . . . . . . . 13
+   11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13
+     11.1. gss_inquire_mech_for_saslname  . . . . . . . . . . . . . . 15
+   12. Security Layers  . . . . . . . . . . . . . . . . . . . . . . . 15
+   13. Interoperability with the SASL "GSSAPI" mechanism  . . . . . . 16
+     13.1. The interoperability problem . . . . . . . . . . . . . . . 16
+     13.2. Resolving the problem  . . . . . . . . . . . . . . . . . . 16
+     13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16
+   14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17
+     14.1. The interoperability problem . . . . . . . . . . . . . . . 17
+     14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17
+     14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17
+   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
+   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+     18.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+     18.2. Informative References . . . . . . . . . . . . . . . . . . 20
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 3]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+1.  Introduction
+
+   Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743] is a framework that provides security services to
+   applications using a variety of authentication "mechanisms".  Simple
+   Authentication and Security Layer (SASL) [RFC4422] is a framework to
+   provide authentication and "security layers" for connection based
+   protocols, also using a variety of mechanisms.  This document
+   describes how to use a GSS-API mechanism as though it were a SASL
+   mechanism.  This facility is called "GS2" -- a moniker that indicates
+   that this is the second GSS-API->SASL mechanism bridge.  The original
+   GSS-API->SASL mechanism bridge was specified by [RFC2222], now
+   [RFC4752]; we shall sometimes refer to the original bridge as "GS1"
+   in this document.
+
+   All GSS-API mechanisms are implicitly registered for use within SASL
+   by this specification.  The SASL mechanisms defined in this document
+   are known as the "GS2 family of mechanisms".
+
+   The GS1 bridge failed to gain wide deployment for any GSS-API
+   mechanism other than The "Kerberos V GSS-API mechanism" [RFC1964]
+   [RFC4121], and has a number of problems that lead us to desire a new
+   bridge.  Specifically: a) GS1 was not round-trip optimized, b) GS1
+   did not support channel binding [RFC5056].  These problems and the
+   opportunity to create the next SASL password-based mechanism, SCRAM
+   [I-D.newman-auth-scram], as a GSS-API mechanism used by SASL
+   applications via GS2, provide the motivation for GS2.
+
+   In particular, the current consensus of the SASL community appears to
+   be that SASL "security layers" (i.e., confidentiality and integrity
+   protection of application data after authentication) are too complex
+   and, since SASL applications tend to have an option to run over a
+   Transport Layer Security (TLS) [RFC5246] channel, redundant and best
+   replaced with channel binding.
+
+   GS2 is designed to be as simple as possible.  It adds to GSS-API
+   security context token exchanges only the bare minimum to support
+   SASL semantics and negotiation of use of channel binding.
+   Specifically, GS2 adds a small header (2 bytes or 4 bytes plus the
+   length of the client requested SASL authorization ID (authzid)) to
+   the initial context token and to the application channel binding
+   data, and it uses SASL mechanism negotiation to implement channel
+   binding negotiation.  All GS2 plaintext is protected via the use of
+   GSS-API channel binding.  Additionally, to simplify the
+   implementation of GS2 mechanisms for implementors who will not
+   implement a GSS-API framework, we compress the initial security
+   context token header required by [RFC2743] (see section 3.1).
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 4]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+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 [RFC2119].
+
+
+3.  Mechanism name
+
+3.1.  Generating SASL mechanism names from GSS-API OIDs
+
+   There are two SASL mechanism names for any GSS-API mechanism used
+   through this facility.  One denotes that the server supports channel
+   binding.  The other denotes that it does not.
+
+   The SASL mechanism name for a GSS-API mechanism is that which is
+   provided by that mechanism when it was specified, if one was
+   specified.  This name denotes that the server does not support
+   channel binding.  Add the suffix "-PLUS" and the resulting name
+   denotes that the server does support channel binding.  SASL
+   implementations can use the GSS_Mechanism_Name call (see below) to
+   query for the SASL mechanism name of a GSS-API mechanism.
+
+   For GSS-API mechanisms whose SASL names are not defined together with
+   the GSS-API mechanism or in this document, the SASL mechanism name is
+   concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
+   (with an upper case alphabet) of the first 55 bits of the binary
+   SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER
+   encoding [CCITT.X690.2002], including the tag and length octets, of
+   the GSS-API mechanism's Object Identifier.  The Base32 rules on
+   padding characters and characters outside of the base32 alphabet are
+   not relevant to this use of Base32.  If any padding or non-alphabet
+   characters are encountered, the name is not a GS2 family mechanism
+   name.  This name denotes that the server does not support channel
+   binding.  Add the suffix "-PLUS" and the resulting name denotes that
+   the server does support channel binding.
+
+3.2.  Computing mechanism names manually
+
+   The hash-derived GS2 SASL mechanism name may be computed manually.
+   This is useful when the set of supported GSS-API mechanisms is known
+   in advance.  It also obliterate the need to implement Base32, SHA-1
+   and DER in the SASL mechanism.  The computed mechanism name can be
+   used directly in the implementation, and the implementation need not
+   concern itself with that the mechanism is part of a mechanism family.
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 5]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+3.3.  Examples
+
+   The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1.  The
+   ASN.1 DER encoding of the OID, including the tag and length, is (in
+   hex) 06 07 2b 06 01 05 05 01 01.  The SHA-1 hash of the ASN.1 DER
+   encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
+   27 86 61 ad.  Convert the first 7 octets to binary, drop the last
+   bit, and re-group them in groups of 5, and convert them back to
+   decimal, which results in these computations:
+
+   hex:
+   1c f8 f4 2b 5a 9f 80
+
+   binary:
+   00011100 11111000 11110100 00101011 01011010
+   10011111 1000000
+
+   binary in groups of 5:
+   00011 10011 11100 01111 01000 01010 11010 11010
+   10011 11110 00000
+
+   decimal of each group:
+   3 19 28 15 8 10 26 26 19 30 0
+
+   base32 encoding:
+   D T 4 P I K 2 2 T 6 A
+
+   The last step translate each decimal value using table 3 in Base32
+   [RFC4648].  Thus the SASL mechanism name for the SPKM-1 GSSAPI
+   mechanism is "GS2-DT4PIK22T6A".
+
+   The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
+   1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
+   86 F7 12 01 02 02.  The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
+   93 25 51 6a fc ff 04 b0 43 60.  Convert the first ten octets to
+   binary, and re-group them in groups of 5, and convert them back to
+   decimal, which results in these computations:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 6]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   hex:
+   82 d2 73 25 76 6b d6
+
+   binary:
+   10000010 11010010 01110011 00100101 01110110
+   01101011 1101011
+
+   binary in groups of 5:
+   10000 01011 01001 00111 00110 01001 01011 10110
+   01101 01111 01011
+
+   decimal of each group:
+   16 11 9 7 6 9 11 22 13 15 11
+
+   base32 encoding:
+   Q L J H G J L W N P L
+
+   The last step translate each decimal value using table 3 in Base32
+   [RFC4648].  Thus the SASL mechanism name for the Kerberos V5 GSSAPI
+   mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
+   supports channel binding) "GS2-QLJHGJLWNPL-PLUS".  But instead, we
+   assign the Kerberos V mechanism a non-hash-derived mechanism name:
+   "KerberosV-GS2" and "KerberosV-GS2-PLUS" (see Section 15).
+
+
+4.  SASL Authentication Exchange Message Format
+
+4.1.  SASL Messages
+
+   During the SASL authentication exchange for GS2, a number of messages
+   following the following format is sent between the client and server.
+   This number is the same as the number of context tokens that the GSS-
+   API mechanism would normally require in order to establish a security
+   context (or to fail to do so).
+
+   Note that when using a GS2 mechanism the SASL client is always a GSS-
+   API initiator and the SASL server is always a GSS-API acceptor.  Thus
+   the SASL client calls GSS_Init_sec_context() and the server calls
+   GSS_Accept_sec_context().
+
+   All the SASL authentication messages exchanged are exactly the same
+   as the security context tokens of the GSS-API mechanism, except for
+   the initial security context token.
+
+   Also, the server SHOULD refrain from sending GSS-API error tokens
+   (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
+   along with a major status code other than GSS_S_COMPLETE or
+   GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 7]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   The initial security context token is modified as follows:
+   o  The [RFC2743] section 3.1 initial context token header MUST be
+      removed if present, and its presence is noted (see below).  On the
+      server side this header MUST be recomputed and restored prior to
+      passing the token to GSS_Accept_sec_context().
+   o  A GS2 header MUST be prefixed to the resulting initial context
+      token.  This header has the form given below in ABNF [RFC5234].
+
+      UTF8-1-safe    = %x01-2B / %x2D-3C / %x3E-7F
+                       ;; As UTF8-1 in RFC 3629 except
+                       ;; NUL, "=", and ",".
+      UTF8-2         = <as defined in RFC 3629 (STD 63)>
+      UTF8-3         = <as defined in RFC 3629 (STD 63)>
+      UTF8-4         = <as defined in RFC 3629 (STD 63)>
+      UTF8-char-safe = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
+
+      saslname     = 1*(UTF8-char-safe / "=2C" / "=3D")
+      gs2-authzid  = "a=" saslname
+                        ;; GS2 has to transport an authzid since
+                        ;; the GSS-API has no equivalent
+      gs2-std-mech = "F"
+                        ;; "F" means the mechanism is NOT is a
+                        ;; standard GSS-API mechanism in that the
+                        ;; RFC2743 section 3.1 header was missing
+      gs2-cb-flag  = "n" / "y" / "p"
+                        ;; GS2 channel binding (CB) flag
+                        ;; "n" -> client does not support CB
+                        ;; "y" -> client supports CB, thinks the server
+                        ;;           does not
+                        ;; "p" -> client supports and used CB
+      gs2-header   = [gs2-std-mech] gs2-cb-flag [gs2-authzid] ","
+                        ;; The GS2 header is gs2-header.
+                        ;; gs2-std-mech is present if the GSS-API
+                        ;; mechanism's initial context token did not
+                        ;; have the standard header defined in
+                        ;; [RFC2743] section 3.1.
+
+   The GS2 header is also prepended to the application's channel binding
+   data.  If the application did not provide channel binding data then
+   the GS2 header is used as though it were application-provided channel
+   binding data.
+
+   The "gs2-authzid" holds the SASL authorization identity.  It is
+   encoded using UTF-8 [RFC3629] with three exceptions:
+   o  The NUL characters is forbidden as required by section 3.4.1 of
+      [RFC4422].
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 8]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   o  The server MUST replace any occurance of "," (comma) in the string
+      with "=2C".
+   o  The server MUST replace any occurance of "=" (comma) in the string
+      with "=3D".
+
+   If a server sends a string that does not conform to this syntax, the
+   client MUST reject authentication.
+
+
+5.  Channel Bindings
+
+   If the server supports channel binding then it must list both forms
+   of the SASL mechanism name for each GSS-API mechanism supported via
+   GS2 (i.e., GSS-API mechanisms that support channel binding).
+
+   If the client supports channel binding and the server does not (i.e.,
+   the server did not advertise the -PLUS names) then the client MUST
+   either fail authentication or it MUST set the channel binding flag in
+   the GS2 initial security context token to "y" and MUST NOT include
+   application channel binding data in the GSS-API channel binding input
+   to GSS_Init_sec_context().
+
+   If the client supports channel binding and the server also does then
+   the client MUST set the channel binding flag in the GS2 initial
+   security context token to "p" and MUST include application channel
+   binding data in the GSS-API channel binding input to
+   GSS_Init_sec_context().
+
+   If the client does not support channel binding then it MUST set the
+   channel binding flag in the GS2 initial security context token to "n"
+   and MUST NOT include application channel binding data in the GSS-API
+   channel binding input to GSS_Init_sec_context().
+
+   Upon receipt of the initial authentication message the server checks
+   the channel binding flag in the GS2 header and constructs a channel
+   binding data input for GSS_Accept_sec_context() accordingly.  If the
+   client channel binding flag was "n" then the server MUST NOT include
+   application channel binding data in the GSS-API channel binding input
+   to GSS_Accept_sec_context().  If the client channel binding flag was
+   "y" and the server does support channel binding then the server MUST
+   fail authentication.  If the client channel binding flag was "p" the
+   server MUST include application channel binding data in the GSS-API
+   channel binding input to GSS_Accept_sec_context().
+
+   For more discussions of channel bindings, and the syntax of the
+   channel binding data for various security protocols, see [RFC5056].
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009               [Page 9]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+6.  Examples
+
+   Example #1: a one round-trip GSS-API context token exchange, no
+   channel binding, optional authzid given.
+
+         C: Request authentication exchange
+         S: Empty Challenge
+         C: nauthzid=someuser, <initial context token with standard
+                                header removed>
+         S: Send reply context token as is
+         C: Empty message
+         S: Outcome of authentication exchange
+
+   Example #2: a one and one half round-trip GSS-API context token
+   exchange.
+
+         C: Request authentication exchange
+         S: Empty Challenge
+         C: nauthzid=someuser, <initial context token with standard
+                                header removed>
+         S: Send reply context token as is
+         C: Send reply context token as is
+         S: Outcome of authentication exchange
+
+   Example #3: a two round-trip GSS-API context token exchange.
+
+         C: Request authentication exchange
+         S: Empty Challenge
+         C: nauthzid=someuser, <initial context token with standard
+                                header removed>
+         S: Send reply context token as is
+         C: Send reply context token as is
+         S: Send reply context token as is
+         C: Empty message
+         S: Outcome of authentication exchange
+
+   Example #4: using channel binding.
+
+         C: Request authentication exchange
+         S: Empty Challenge
+         C: yauthzid=someuser, <initial context token with standard
+                                header removed>
+         S: Send reply context token as is
+         ...
+
+   GSS-API authentication is always initiated by the client.  The SASL
+   framework allows either the client and server to initiate
+   authentication.  In GS2 the server will send an initial empty
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 10]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   challenge (zero byte string) if it has not yet received a token from
+   the client.  See section 3 of [RFC4422].
+
+
+7.  Authentication Conditions
+
+   Authentication MUST NOT succeed if any one of the following
+   conditions are true:
+
+   o  GSS_Init/Accept_sec_context() return anything other than
+      GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
+   o  If the client's GS2 channel binding flag was "y" and the server
+      supports channel binding.
+   o  If the client requires use of channel binding and the server did
+      not advertise support for channel binding.
+   o  Authorization of client principal (i.e., src_name in
+      GSS_Accept_sec_context()) to requested authzid failed.
+   o  If the client is not authorized to the requested authzid or an
+      authzid could not be derived from the client's initiator principal
+      name.
+
+
+8.  GSS-API Parameters
+
+   GS2 does not use any GSS-API per-message tokens.  Therefore the
+   setting of req_flags related to per-message tokens is irrelevant.
+
+
+9.  Naming
+
+   There's no requirement that any particular GSS-API name-types be
+   used.  However, typically SASL servers will have host-based acceptor
+   principal names (see [RFC2743] section 4.1) and clients will
+   typically have username initiator principal names (see [RFC2743]
+   section 4.2).
+
+
+10.  GSS_Mechanism_SASLname call
+
+   To allow SASL implementations to query for the SASL mechanism name of
+   a GSS-API mechanism, we specify a new GSS-API function for this
+   purpose.
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 11]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+      Inputs:
+
+      o desired_mech OBJECT IDENTIFIER
+
+      Outputs:
+
+      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
+        (really, ASCII)
+
+      o mech_name UTF-8 STRING -- name of this mechanism, possibly
+        localized
+
+      o mech_description UTF-8 STRING -- possibly localized
+        description of this mechanism.
+
+      Return major_status codes:
+
+      o  GSS_S_COMPLETE indicates successful completion, and that output
+         parameters holds correct information.
+
+      o  GSS_S_BAD_MECH indicates that a disred_mech was unsupported by
+         the GSS-API implementation.
+
+      The GSS_Mechanism_SASLname call is used to get the SASL mechanism
+      name for a GSS-API mechanism.  It also returns a name and
+      description of the mechanism in a human readable form.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 12]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+10.1.  gss_mechanism_saslname
+
+   The C binding for the GSS_Mechanism_SASLname call is as follows.
+
+     OM_uint32 gss_mechanism_saslname(
+       OM_uint32     *minor_status,
+       const gss_OID  desired_mech,
+       gss_buffer_t   sasl_mech_name,
+       gss_buffer_t   mech_name,
+       gss_buffer_t   mech_description,
+     );
+
+     Purpose:
+
+     Output the SASL mechanism name of a GSS-API mechanism.  Also output
+     a name and description of the mechanism in a human readable form.
+
+     Parameters:
+
+     minor_status      Integer, modify
+                       Mechanism specific status code.
+
+     Function value:   GSS status code
+
+     GSS_S_COMPLETE    Successful completion
+
+     GSS_S_BAD_MECH    The desired_mech OID is unsupported
+
+
+11.  GSS_Inquire_mech_for_SASLname call
+
+   To allow SASL clients to more efficiently identify which GSS-API
+   mechanism a particular SASL mechanism name refers to we specify a new
+   GSS-API utility function for this purpose.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 13]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+      Inputs:
+
+      o sasl_mech_name OCTET STRING -- SASL name of mechanism
+        (really, ASCII)
+
+      Outputs:
+
+      o  mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
+         and not "default" specifier
+
+      Return major_status codes:
+
+      o  GSS_S_COMPLETE indicates successful completion, and that output
+         parameters holds correct information.
+
+      o  GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
+         had the indicated sasl_mech_name.
+
+      The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
+      mechanism OID associated with a SASL mechanism name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 14]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+11.1.  gss_inquire_mech_for_saslname
+
+   The C binding for the GSS_Inquire_mech_for_SASLname call is as
+   follows.
+
+      OM_uint32 gss_inquire_mech_for_saslname(
+        OM_uint32           *minor_status,
+        const gss_buffer_t   sasl_mech_name,
+        gss_OID             *mech_type
+      );
+
+      Purpose:
+
+      Output GSS-API mechanism OID of mechanism associated with given
+      sasl_mech_name.
+
+      Parameters:
+
+      minor_status      Integer, modify
+                        Mechanism specific status code.
+
+      Function value:   GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_MECH    The desired_mech OID is unsupported
+
+
+12.  Security Layers
+
+   GS2 does not currently support SASL security layers.  Applications
+   that need integrity protection or confidentiality and integrity
+   protection MUST use either channel binding to a secure external
+   channel or a SASL mechanism that does provide security layers.
+
+   NOTE WELL: the GS2 client's first authentication message MUST always
+   start with "F", "n", "y" or "p", otherwise the server MUST fail
+   authentication.  This will allow us to add support for security
+   layers in the future if it were to become necessary.  Note that
+   adding security layer support to GS2 must not break existing SASL/GS2
+   applications, which can be accomplished by making security layers
+   optional.
+
+   [A sketch of how to add sec layer support...  Add a way for the
+   client to: a) make an offer of sec layers and max buffer, b) make an
+   opportunistic selection of sec layer and buffer size, both in the
+   first client authentication message, and starting with a character
+   other than "F", "n", "y" or "p".  The server could accept the
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 15]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   opportunistic proposal (reply token prefixed with a byte indicating
+   acceptance) or reject it along with an indication of the server's
+   acceptable sec layers and max buffer size.  In the latter case the
+   GSS-API security context token exchange must be abandoned and
+   recommenced, although this would be a detail of the GS2 bridge not
+   exposed to the SASL application.  The negotiation would be protected
+   via GSS channel binding, as with the rest of GS2.]
+
+
+13.  Interoperability with the SASL "GSSAPI" mechanism
+
+   The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
+   under the name "GSSAPI", see GSSAPI mechanism [RFC4752].  The
+   Kerberos V5 mechanism may also be used with the GS2 family.  This
+   causes an interopability problem, which is discussed and resolved
+   below.
+
+13.1.  The interoperability problem
+
+   The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos
+   V GSS-API mechanism used as a SASL GS2 mechanism.
+
+   If a client (or server) only support Kerberos V5 under the "GSSAPI"
+   name and the server (or client) only support Kerberos V5 under the
+   GS2 family, the mechanism negotiation will fail.
+
+13.2.  Resolving the problem
+
+   If the Kerberos V5 mechanism is supported under GS2 in a server, the
+   server SHOULD also support Kerberos V5 through the "GSSAPI"
+   mechanism, to avoid interoperability problems with older clients.
+
+   Reasons for violating this recommendation may include security
+   considerations regarding the absent features in the GS2 mechanism.
+   The SASL "GSSAPI" mechanism lacks support for channel bindings, which
+   means that using an external secure channel may not be sufficient
+   protection against active attackers (see [RFC5056], [mitm]).
+
+13.3.  Additional Recommendations
+
+   If the application requires security layers then it MUST prefer the
+   SASL "GSSAPI" mechanism over "KerberosV-GS2".
+
+   If the application can use channel binding to an external channel
+   then it is RECOMMENDED that it select Kerberos V5 through the GS2
+   mechanism rather than the "GSSAPI" mechanism.
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 16]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+14.  Mechanisms that negotiate other mechanisms
+
+   A GSS-API mechanism that negotiate other mechanisms interact badly
+   with the SASL mechanism negotiation.  There are two problems.  The
+   first is an interoperability problem and the second is a security
+   concern.  The problems are described and resolved below.
+
+14.1.  The interoperability problem
+
+   If a client implement GSS-API mechanism X, potentially negotiated
+   through a GSS-API mechanism Y, and the server also implement GSS-API
+   mechanism X negotiated through a GSS-API mechanism Z, the
+   authentication negotiation will fail.
+
+14.2.  Security problem
+
+   If a client's policy is to first prefer GSSAPI mechanism X, then non-
+   GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
+   mechanisms Y and Z but not X, then if the client attempts to
+   negotiate mechanism X by using a GSS-API mechanism that negotiate
+   other mechanisms (such as SPNEGO), it may end up using mechanism Z
+   when it ideally should have used mechanism Y. For this reason, the
+   use of GSS-API mechanisms that negotiate other mechanisms are
+   disallowed under GS2.
+
+14.3.  Resolving the problems
+
+   GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
+   with the GS2 SASL mechanism.  Specifically SPNEGO [RFC4178] MUST NOT
+   be used as a GS2 mechanism.  To make this easier for SASL
+   implementations we assign a symbolic SASL mechanism name to the
+   SPNEGO GSS-API mechanism: "SPNEGO".  SASL client implementations MUST
+   NOT choose the SPNEGO mechanism under any circumstances.  [What about
+   SASL apps that don't do mechanism negotiation?  Probably none exist.
+   But if any did then presumably it would OK to use the SPNEGO
+   mechanism, no? -Nico]
+
+   The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech()
+   [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
+   mechanisms.
+
+
+15.  IANA Considerations
+
+   The SASL names for the Kerberos V GSS-API mechanism [RFC4121]
+   [RFC1964] used via GS2 SHALL be "KerberosV-GS2" and "KerberosV-GS2-
+   PLUS".
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 17]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be
+   "SPNEGO" and "SPNEGO-PLUS".  As described in Section 14 the SASL
+   "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used.  These names are
+   provided as a convienience for SASL library implementors.
+
+   The IANA is advised that SASL mechanism names starting with "GS2-"
+   are reserved for SASL mechanisms which conform to this document.  The
+   IANA is directed to place a statement to that effect in the sasl-
+   mechanisms registry.
+
+   The IANA is further advised that SASL mechanisms MUST NOT end in
+   "-PLUS" except as a version of another mechanism name simply suffixed
+   with "-PLUS".
+
+     Subject: Registration of SASL mechanism GS2-*
+     SASL mechanism prefix: GS2-
+     Security considerations: RFC [THIS-DOC]
+     Published specification: RFC [THIS-DOC]
+     Person & email address to contact for further information:
+       Simon Josefsson <simon@josefsson.org>
+     Intended usage: COMMON
+     Owner/Change controller: iesg@ietf.org
+     Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
+
+
+16.  Security Considerations
+
+   Security issues are also discussed throughout this memo.
+
+   The security provided by a GS2 mechanism depends on the security of
+   the GSS-API mechanism.  The GS2 mechanism family depends on channel
+   binding support, so GSS-API mechanisms that do not support channel
+   binding cannot be successfully used as SASL mechanisms via the GS2
+   bridge.
+
+   Because GS2 does not support security layers it is strongly
+   RECOMMENDED that channel binding to a secure external channel be
+   used.  Successful channel binding eliminates the possibility of man-
+   in-the-middle (MITM) attacks, provided that the external channel and
+   its channel binding data are secure and provided that the GSS-API
+   mechanism used is secure.  Authentication failure because of channel
+   binding failure may indicate that an MITM attack was attempted, but
+   note that a real MITM attacker would likely attempt to close the
+   connection to the client or simulate network partition , thus MITM
+   attack detection is heuristic.
+
+   Use of channel binding will also protect the SASL mechanism
+   negotiation -- if there is no MITM then the external secure channel
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 18]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   will have protected the SASL mechanism negotiation.
+
+   The channel binding data MAY be sent (byt the actual GSS-API
+   mechanism used) without confidentiality protection and knowledge of
+   it is assumed to provide no advantage to an MITM (who can, in any
+   case, compute the channel binding data independently).  If the
+   external channel does not provide confidentiality protection and the
+   GSS-API mechanism does not provide confidentiality protection for the
+   channel binding data, then passive attackers (eavesdroppers) can
+   recover the channel binding data.  See [RFC5056].
+
+   When constructing the input_name_string for GSS_Import_name() with
+   the GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT
+   canonicalize the server's fully qualified domain name using an
+   insecure or untrusted directory service, such as the Domain Name
+   System [RFC1034] without DNSSEC [RFC4033].
+
+   GS2 does not directly use any cryptographic algorithms, therefore it
+   is automatically "algorithm agile", or, as agile as the GSS-API
+   mechanisms that are available for use in SASL apoplications via GS2.
+
+   The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
+   channel binding [RFC5056], any external channels (such as TLS,
+   [RFC5246], channel binding types (see the IANA channel binding type
+   registry), and GSS-API mechanisms (such as the Kerberos V mechanism
+   [RFC4121] [RFC1964]), may also apply.
+
+
+17.  Acknowledgements
+
+   The history of GS2 can be traced to the "GSSAPI" mechanism originally
+   specified by RFC2222.  This document was derived from
+   draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
+   significant contributions from John G. Myers, although the majority
+   of this document has been rewritten by the current authors.
+
+   Contributions of many members of the SASL mailing list are gratefully
+   acknowledged.  In particular, ideas and feedback from Sam Hartman,
+   Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document
+   and the protocol.
+
+
+18.  References
+
+18.1.  Normative References
+
+   [FIPS.180-1.1995]
+              National Institute of Standards and Technology, "Secure
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 19]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+              Hash Standard", FIPS PUB 180-1, April 1995,
+              <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
+              Security Layer (SASL)", RFC 4422, June 2006.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [CCITT.X690.2002]
+              International International Telephone and Telegraph
+              Consultative Committee, "ASN.1 encoding rules:
+              Specification of basic encoding Rules (BER), Canonical
+              encoding rules (CER) and Distinguished encoding rules
+              (DER)", CCITT Recommendation X.690, July 2002.
+
+18.2.  Informative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
+              (SASL)", RFC 2222, October 1997.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 20]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+   [RFC4752]  Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
+              Authentication and Security Layer (SASL) Mechanism",
+              RFC 4752, November 2006.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [I-D.newman-auth-scram]
+              Menon-Sen, A., Melnikov, A., and C. Newman, "Salted
+              Challenge Response (SCRAM) SASL Mechanism",
+              draft-newman-auth-scram-10 (work in progress),
+              February 2009.
+
+   [I-D.ietf-kitten-extended-mech-inquiry]
+              Williams, N., "Extended Generic Security Service Mechanism
+              Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-04
+              (work in progress), March 2008.
+
+   [mitm]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
+              in Tunneled Authentication",
+              WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
+
+
+Authors' Addresses
+
+   Simon Josefsson
+   SJD AB
+   Hagagatan 24
+   Stockholm  113 47
+   SE
+
+   Email: simon@josefsson.org
+   URI:   http://josefsson.org/
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 21]
+
+Internet-Draft                 SASL GS2-*                     March 2009
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   USA
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams   Expires September 24, 2009              [Page 22]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-sasl-scram-04.txt b/third_party/heimdal/doc/standardisation/draft-ietf-sasl-scram-04.txt
new file mode 100644
index 00000000000..b6245b6a5be
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ietf-sasl-scram-04.txt
@@ -0,0 +1,1905 @@
+
+
+
+NETWORK WORKING GROUP                                       A. Menon-Sen
+Internet-Draft                                    Oryx Mail Systems GmbH
+Intended status: Standards Track                             A. Melnikov
+Expires: February 1, 2010                                      Isode Ltd
+                                                               C. Newman
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                           July 31, 2009
+
+
+            Salted Challenge Response (SCRAM) SASL Mechanism
+                      draft-ietf-sasl-scram-04.txt
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on February 1, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 1]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+Abstract
+
+   The secure authentication mechanism most widely deployed and used by
+   Internet application protocols is the transmission of clear-text
+   passwords over a channel protected by Transport Layer Security (TLS).
+   There are some significant security concerns with that mechanism,
+   which could be addressed by the use of a challenge response
+   authentication mechanism protected by TLS.  Unfortunately, the
+   challenge response mechanisms presently on the standards track all
+   fail to meet requirements necessary for widespread deployment, and
+   have had success only in limited use.
+
+   This specification describes a family of Simple Authentication and
+   Security Layer (SASL, RFC 4422) authentication mechanisms called the
+   Salted Challenge Response Authentication Mechanism (SCRAM), which
+   addresses the security concerns and meets the deployability
+   requirements.  When used in combination with TLS or an equivalent
+   security layer, a mechanism from this family could improve the
+   status-quo for application protocol authentication and provide a
+   suitable choice for a mandatory-to-implement mechanism for future
+   application protocol standards.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 2]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+Table of Contents
+
+   1.          Conventions Used in This Document  . . . . . . . . . .  4
+   1.1.        Terminology  . . . . . . . . . . . . . . . . . . . . .  4
+   1.2.        Notation . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.          Introduction . . . . . . . . . . . . . . . . . . . . .  7
+   3.          SCRAM Algorithm Overview . . . . . . . . . . . . . . .  9
+   4.          SCRAM Mechanism Names  . . . . . . . . . . . . . . . . 10
+   5.          SCRAM Authentication Exchange  . . . . . . . . . . . . 11
+   5.1.        SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
+   6.          Channel Binding  . . . . . . . . . . . . . . . . . . . 15
+   6.1.        Default Channel Binding  . . . . . . . . . . . . . . . 16
+   7.          Formal Syntax  . . . . . . . . . . . . . . . . . . . . 17
+   8.          SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
+   8.1.        GSS-API Principal Name Types for SCRAM . . . . . . . . 20
+   8.2.        GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
+   8.3.        GSS_Pseudo_random() for SCRAM  . . . . . . . . . . . . 21
+   9.          Security Considerations  . . . . . . . . . . . . . . . 22
+   10.         IANA Considerations  . . . . . . . . . . . . . . . . . 24
+   11.         Acknowledgements . . . . . . . . . . . . . . . . . . . 26
+   Appendix A. Other Authentication Mechanisms  . . . . . . . . . . . 27
+   Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 28
+   Appendix C. Internet-Draft Change History  . . . . . . . . . . . . 29
+   12.         References . . . . . . . . . . . . . . . . . . . . . . 31
+   12.1.       Normative References . . . . . . . . . . . . . . . . . 31
+   12.2.       Normative References for GSS-API implementors  . . . . 31
+   12.3.       Informative References . . . . . . . . . . . . . . . . 32
+               Authors' Addresses . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 3]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+1.  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 [RFC2119].
+
+   Formal syntax is defined by [RFC5234] including the core rules
+   defined in Appendix B of [RFC5234].
+
+   Example lines prefaced by "C:" are sent by the client and ones
+   prefaced by "S:" by the server.  If a single "C:" or "S:" label
+   applies to multiple lines, then the line breaks between those lines
+   are for editorial clarity only, and are not part of the actual
+   protocol exchange.
+
+1.1.  Terminology
+
+   This document uses several terms defined in [RFC4949] ("Internet
+   Security Glossary") including the following: authentication,
+   authentication exchange, authentication information, brute force,
+   challenge-response, cryptographic hash function, dictionary attack,
+   eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
+   one-way encryption function, password, replay attack and salt.
+   Readers not familiar with these terms should use that glossary as a
+   reference.
+
+   Some clarifications and additional definitions follow:
+
+   o  Authentication information: Information used to verify an identity
+      claimed by a SCRAM client.  The authentication information for a
+      SCRAM identity consists of salt, iteration count, the "StoredKey"
+      and "ServerKey" (as defined in the algorithm overview) for each
+      supported cryptographic hash function.
+
+   o  Authentication database: The database used to look up the
+      authentication information associated with a particular identity.
+      For application protocols, LDAPv3 (see [RFC4510]) is frequently
+      used as the authentication database.  For network-level protocols
+      such as PPP or 802.11x, the use of RADIUS is more common.
+
+   o  Base64: An encoding mechanism defined in [RFC4648] which converts
+      an octet string input to a textual output string which can be
+      easily displayed to a human.  The use of base64 in SCRAM is
+      restricted to the canonical form with no whitespace.
+
+   o  Octet: An 8-bit byte.
+
+   o  Octet string: A sequence of 8-bit bytes.
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 4]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   o  Salt: A random octet string that is combined with a password
+      before applying a one-way encryption function.  This value is used
+      to protect passwords that are stored in an authentication
+      database.
+
+1.2.  Notation
+
+   The pseudocode description of the algorithm uses the following
+   notations:
+
+   o  ":=": The variable on the left hand side represents the octet
+      string resulting from the expression on the right hand side.
+
+   o  "+": Octet string concatenation.
+
+   o  "[ ]": A portion of an expression enclosed in "[" and "]" may not
+      be included in the result under some circumstances.  See the
+      associated text for a description of those circumstances.
+
+   o  HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
+      [RFC2104]) using the octet string represented by "key" as the key
+      and the octet string "str" as the input string.  The size of the
+      result is the hash result size for the hash function in use.  For
+      example, it is 20 octets for SHA-1 (see [RFC3174]).
+
+   o  H(str): Apply the cryptographic hash function to the octet string
+      "str", producing an octet string as a result.  The size of the
+      result depends on the hash result size for the hash function in
+      use.
+
+   o  XOR: Apply the exclusive-or operation to combine the octet string
+      on the left of this operator with the octet string on the right of
+      this operator.  The length of the output and each of the two
+      inputs will be the same for this use.
+
+   o  Hi(str, salt):
+
+
+
+      U0   := HMAC(str, salt + INT(1))
+      U1   := HMAC(str, U0)
+      U2   := HMAC(str, U1)
+      ...
+      Ui-1 := HMAC(str, Ui-2)
+      Ui   := HMAC(str, Ui-1)
+
+      Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 5]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+      where "i" is the iteration count, "+" is the string concatenation
+      operator and INT(g) is a four-octet encoding of the integer g,
+      most significant octet first.
+
+   o  This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
+      with dkLen == output length of HMAC() == output length of H().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 6]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+2.  Introduction
+
+   This specification describes a family of authentication mechanisms
+   called the Salted Challenge Response Authentication Mechanism (SCRAM)
+   which addresses the requirements necessary to deploy a challenge-
+   response mechanism more widely than past attempts.  When used in
+   combination with Transport Layer Security (TLS, see [RFC5246]) or an
+   equivalent security layer, a mechanism from this family could improve
+   the status-quo for application protocol authentication and provide a
+   suitable choice for a mandatory-to-implement mechanism for future
+   application protocol standards.
+
+   For simplicity, this family of mechanisms does not presently include
+   negotiation of a security layer [RFC4422].  It is intended to be used
+   with an external security layer such as that provided by TLS or SSH,
+   with optional channel binding [RFC5056] to the external security
+   layer.
+
+   SCRAM is specified herein as a pure Simple Authentication and
+   Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
+   bridge between SASL and the Generic Security Services Application
+   Programming Interface (GSS-API) called "GS2" [I-D.ietf-sasl-gs2].
+   This means that this document defines both, a SASL mechanism and a
+   GSS-API mechanism.
+
+   SCRAM provides the following protocol features:
+
+   o  The authentication information stored in the authentication
+      database is not sufficient by itself to impersonate the client.
+      The information is salted to prevent a pre-stored dictionary
+      attack if the database is stolen.
+
+   o  The server does not gain the ability to impersonate the client to
+      other servers (with an exception for server-authorized proxies).
+
+   o  The mechanism permits the use of a server-authorized proxy without
+      requiring that proxy to have super-user rights with the back-end
+      server.
+
+   o  Mutual authentication is supported, but only the client is named
+      (i.e., the server has no name).
+
+   A separate document defines a standard LDAPv3 [RFC4510] attribute
+   that enables storage of the SCRAM authentication information in LDAP.
+   See [I-D.melnikov-sasl-scram-ldap].
+
+   For an in-depth discussion of why other challenge response mechanisms
+   are not considered sufficient, see appendix A.  For more information
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 7]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   about the motivations behind the design of this mechanism, see
+   appendix B.
+
+   Comments regarding this draft may be sent either to the
+   ietf-sasl@imc.org mailing list or to the authors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 8]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+3.  SCRAM Algorithm Overview
+
+   Note that this section omits some details, such as client and server
+   nonces.  See Section 5 for more details.
+
+   To begin with, the SCRAM client is in possession of a username and
+   password.  It sends the username to the server, which retrieves the
+   corresponding authentication information, i.e. a salt, StoredKey,
+   ServerKey and the iteration count i.  (Note that a server
+   implementation may chose to use the same iteration count for all
+   accounts.)  The server sends the salt and the iteration count to the
+   client, which then computes the following values and sends a
+   ClientProof to the server:
+
+
+      SaltedPassword  := Hi(password, salt)
+      ClientKey       := HMAC(SaltedPassword, "Client Key")
+      StoredKey       := H(ClientKey)
+      AuthMessage     := client-first-message-bare + "," +
+                         server-first-message + "," +
+                         client-final-message-without-proof
+      ClientSignature := HMAC(StoredKey, AuthMessage)
+      ClientProof     := ClientKey XOR ClientSignature
+      ServerKey       := HMAC(SaltedPassword, "Server Key")
+      ServerSignature := HMAC(ServerKey, AuthMessage)
+
+
+   The server authenticates the client by computing the ClientSignature,
+   exclusive-ORing that with the ClientProof to recover the ClientKey
+   and verifying the correctness of the ClientKey by applying the hash
+   function and comparing the result to the StoredKey.  If the ClientKey
+   is correct, this proves that the client has access to the user's
+   password.
+
+   Similarly, the client authenticates the server by computing the
+   ServerSignature and comparing it to the value sent by the server.  If
+   the two are equal, it proves that the server had access to the user's
+   ServerKey.
+
+   The AuthMessage is computed by concatenating messages from the
+   authentication exchange.  The format of these messages is defined in
+   Section 7.
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010                [Page 9]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+4.  SCRAM Mechanism Names
+
+   A SCRAM mechanism name is a string "SCRAM-" followed by the
+   uppercased name of the underlying hash function taken from the IANA
+   "Hash Function Textual Names" registry (see http://www.iana.org),
+   optionally followed by the suffix "-PLUS" (see below).  Note that
+   SASL mechanism names are limited to 20 characters, which means that
+   only hash function names with lengths shorter or equal to 9
+   characters (20-length("SCRAM-")-length("-PLUS") can be used.  For
+   cases when the underlying hash function name is longer than 9
+   characters, an alternative 9 character (or shorter) name can be used
+   to construct the corresponding SCRAM mechanism name, as long as this
+   alternative name doesn't conflict with any other hash function name
+   from the IANA "Hash Function Textual Names" registry.
+
+   For interoperability, all SCRAM clients and servers MUST implement
+   the SCRAM-SHA-1 authentication mechanism, i.e. an authentication
+   mechanism from the SCRAM family that uses the SHA-1 hash function as
+   defined in [RFC3174].
+
+   The "-PLUS" suffix is used only when the server supports channel
+   binding to the external channel.  If the server supports channel
+   binding, it will advertise both the "bare" and "plus" versions of
+   whatever mechanisms it supports (e.g., if the server supports only
+   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
+   and SCRAM-SHA-1-PLUS); if the server does not support channel
+   binding, then it will advertise only the "bare" version of the
+   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
+   negotiation of the use of channel binding.  See Section 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 10]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+5.  SCRAM Authentication Exchange
+
+   SCRAM is a SASL mechanism whose client response and server challenge
+   messages are text-based messages containing one or more attribute-
+   value pairs separated by commas.  Each attribute has a one-letter
+   name.  The messages and their attributes are described in
+   Section 5.1, and defined in Section 7.
+
+   This is a simple example of a SCRAM-SHA-1 authentication exchange
+   when the client doesn't support channel bindings:
+
+
+      C: n,,n=Chris Newman,r=ClientNonce
+      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
+      C: c=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
+      S: v=WxPv/siO5l+qxN4
+
+
+   [[anchor5: Note that the all hashes above are fake and will be fixed
+   during AUTH48.]]
+
+   With channel-binding data sent by the client this might look like
+   this (see [tls-server-end-point] for the definition of tls-server-
+   end-point TLS channel binding):
+
+
+      C: p=tls-server-end-point,,n=Chris Newman,r=ClientNonce
+      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
+      C: c=cD10bHMtc2VydmVyLWVuZC1wb2ludCwsy1hFtXOnZ+ySrQM6srFp
+         l/77uqvtxrg7nBY1BetEr/g=,r=ClientNonceServerNonce,p=Wx
+         Pv/siO5l+qxN4
+      S: v=WxPv/siO5l+qxN4
+
+
+   [[anchor6: Note that all hashes above are fake and will be fixed
+   during AUTH48.]]
+
+   First, the client sends a message containing:
+
+   o  a GS2 header consisting of a flag indicating whether channel
+      binding is supported-but-not-used, not supported, or used, and an
+      optional SASL authorization identity;
+
+   o  SCRAM username and a random, unique nonce attributes.
+
+   Note that the client's first message will always start with "n", "y"
+   or "p", otherwise the message is invalid and authentication MUST
+   fail.  This is important, as it allows for GS2 extensibility (e.g.,
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 11]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   to add support for security layers).
+
+   In response, the server sends the user's iteration count i, the
+   user's salt, and appends its own nonce to the client-specified one.
+   The client then responds with the same nonce and a ClientProof
+   computed using the selected hash function as explained earlier.  The
+   server verifies the nonce and the proof, verifies that the
+   authorization identity (if supplied by the client in the first
+   message) is authorized to act as the authentication identity, and,
+   finally, it responds with a ServerSignature, concluding the
+   authentication exchange.  The client then authenticates the server by
+   computing the ServerSignature and comparing it to the value sent by
+   the server.  If the two are different, the client MUST consider the
+   authentication exchange to be unsuccessful and it might have to drop
+   the connection.
+
+5.1.  SCRAM Attributes
+
+   This section describes the permissible attributes, their use, and the
+   format of their values.  All attribute names are single US-ASCII
+   letters and are case-sensitive.
+
+   Note that the order of attributes in client or server messages is
+   fixed, with the exception of extension attributes (described by the
+   "extensions" ABNF production), which can appear in any order in the
+   designated positions.  See the ABNF section for authoritative
+   reference.
+
+   o  a: This is an optional attribute, and is part of the GS2
+      [I-D.ietf-sasl-gs2] bridge between the GSS-API and SASL.  This
+      attribute specifies an authorization identity.  A client may
+      include it in its first message to the server if it wants to
+      authenticate as one user, but subsequently act as a different
+      user.  This is typically used by an administrator to perform some
+      management task on behalf of another user, or by a proxy in some
+      situations.
+
+         Upon the receipt of this value the server verifies its
+         correctness according to the used SASL protocol profile.
+         Failed verification results in failed authentication exchange.
+
+         If this attribute is omitted (as it normally would be), the
+         authorization identity is assumed to be derived from the
+         username specified with the (required) "n" attribute.
+
+         The server always authenticates the user specified by the "n"
+         attribute.  If the "a" attribute specifies a different user,
+         the server associates that identity with the connection after
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 12]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+         successful authentication and authorization checks.
+
+         The syntax of this field is the same as that of the "n" field
+         with respect to quoting of '=' and ','.
+
+   o  n: This attribute specifies the name of the user whose password is
+      used for authentication (a.k.a. "authentication identity"
+      [RFC4422]).  A client MUST include it in its first message to the
+      server.  If the "a" attribute is not specified (which would
+      normally be the case), this username is also the identity which
+      will be associated with the connection subsequent to
+      authentication and authorization.
+
+         Before sending the username to the server, the client MUST
+         prepare the username using the "SASLPrep" profile [RFC4013] of
+         the "stringprep" algorithm [RFC3454].  If the preparation of
+         the username fails or results in an empty string, the client
+         SHOULD abort the authentication exchange (*).
+
+         (*) An interactive client can request a repeated entry of the
+         username value.
+
+         Upon receipt of the username by the server, the server SHOULD
+         prepare it using the "SASLPrep" profile [RFC4013] of the
+         "stringprep" algorithm [RFC3454].  If the preparation of the
+         username fails or results in an empty string, the server SHOULD
+         abort the authentication exchange.
+
+         The characters ',' or '=' in usernames are sent as '=2C' and
+         '=3D' respectively.  If the server receives a username which
+         contains '=' not followed by either '2C' or '3D', then the
+         server MUST fail the authentication.
+
+   o  m: This attribute is reserved for future extensibility.  In this
+      version of SCRAM, its presence in a client or a server message
+      MUST cause authentication failure when the attribute is parsed by
+      the other end.
+
+   o  r: This attribute specifies a sequence of random printable
+      characters excluding ',' which forms the nonce used as input to
+      the hash function.  No quoting is applied to this string.  As
+      described earlier, the client supplies an initial value in its
+      first message, and the server augments that value with its own
+      nonce in its first response.  It is important that this value be
+      different for each authentication.  The client MUST verify that
+      the initial part of the nonce used in subsequent messages is the
+      same as the nonce it initially specified.  The server MUST verify
+      that the nonce sent by the client in the second message is the
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 13]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+      same as the one sent by the server in its first message.
+
+   o  c: This REQUIRED attribute specifies base64-encoded of a header
+      and the channel-binding data.  It is sent by the client in its
+      second authentication message.  The header consist of:
+
+      *  the GS2 header from the client's first message (recall: a
+         channel binding flag and an optional authzid).  This header is
+         going to include channel binding type prefix (see [RFC5056]),
+         if and only if the client is using channel binding;
+
+      *  followed by the external channel's channel binding data, if and
+         only if the client is using channel binding.
+
+   o  s: This attribute specifies the base64-encoded salt used by the
+      server for this user.  It is sent by the server in its first
+      message to the client.
+
+   o  i: This attribute specifies an iteration count for the selected
+      hash function and user, and MUST be sent by the server along with
+      the user's salt.
+
+         For SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism servers SHOULD
+         announce a hash iteration-count of at least 4096.  Note that a
+         client implementation MAY cache SaltedPassword/ClientKey for
+         later reauthentication to the same service, as it is likely
+         that the server is going to advertise the same salt value upon
+         reauthentication.  This might be useful for mobile clients
+         where CPU usage is a concern.
+
+   o  p: This attribute specifies a base64-encoded ClientProof.  The
+      client computes this value as described in the overview and sends
+      it to the server.
+
+   o  v: This attribute specifies a base64-encoded ServerSignature.  It
+      is sent by the server in its final message, and is used by the
+      client to verify that the server has access to the user's
+      authentication information.  This value is computed as explained
+      in the overview.
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 14]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+6.  Channel Binding
+
+   SCRAM supports channel binding to external secure channels, such as
+   TLS.  Clients and servers may or may not support channel binding,
+   therefore the use of channel binding is negotiable.  SCRAM does not
+   provide security layers, however, therefore it is imperative that
+   SCRAM provide integrity protection for the negotiation of channel
+   binding.
+
+   Use of channel binding is negotiated as follows:
+
+   o  Servers SHOULD advertise both non-PLUS (SCRAM-<hash-function>) and
+      the PLUS-variant (SCRAM-<hash-function>-PLUS) SASL mechanism
+      names.  If the server cannot support channel binding, it MAY
+      advertise only the non-PLUS variant.  If the server would never
+      succeed authentication of the non-PLUS variant due to policy
+      reasons, it MAY advertise only the PLUS-variant.
+
+   o  If the client negotiates mechanisms then the client MUST select
+      SCRAM-<hash-function>-PLUS if offered by the server and the client
+      wants to select SCRAM with the given hash function.  Otherwise
+      (the client does not negotiate mechanisms), if the client has no
+      prior knowledge about mechanisms supported by the server and
+      wasn't explicitly configured to use a particular variant of the
+      SCRAM mechanism, then it MUST select only SCRAM-<hash-function>
+      (not suffixed with "-PLUS").
+
+   o  If the client supports channel binding and the server appears to
+      support it (i.e., the client sees SCRAM-<hash-function>-PLUS), or
+      if the client wishes to use channel binding but the client does
+      not negotiate mechanisms, then the client MUST set the GS2 channel
+      binding flag to "p" in order to indicate the channel binding type
+      it is using and it MUST include the channel binding data for the
+      external channel in the computation of the "c=" attribute (see
+      Section 5.1).
+
+   o  If the client supports channel binding but the server does not
+      appear to (i.e., the client did not see SCRAM-<hash-function>-
+      PLUS) then the client MUST either fail authentication or it MUST
+      choose the non-PLUS mechanism and set the GS2 channel binding flag
+      to "y" and MUST NOT include channel binding data for the external
+      channel in the computation of the "c=" attribute (see
+      Section 5.1).
+
+   o  If the client does not support channel binding then the client
+      MUST set the GS2 channel binding flag to "n" and MUST NOT include
+      channel binding data for the external channel in the computation
+      of the "c=" attribute (see Section 5.1).
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 15]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   o  Upon receipt of the client first message the server checks the GS2
+      channel binding flag (gs2-cb-flag).
+
+      *  If the flag is set to "y" and the server supports channel
+         binding the server MUST fail authentication.  This is because
+         if the client sets the GS2 channel binding flag set to "y" then
+         the client must have believed that the server did not support
+         channel binding -- if the server did in fact support channel
+         binding then this is an indication that there has been a
+         downgrade attack (e.g., an attacker changed the server's
+         mechanism list to exclude the -PLUS suffixed SCRAM mechanism
+         name(s)).
+
+      *  If the channel binding flag was "p" and the server does not
+         support the indicated channel binding type then the server MUST
+         fail authentication.
+
+   The server MUST always validate the client's "c=" field.  The server
+   does this by constructing the value of the "c=" attribute and then
+   checking that it matches the client's c= attribute value.
+
+   For more discussions of channel bindings, and the syntax of the
+   channel binding data for various security protocols, see [RFC5056].
+
+6.1.  Default Channel Binding
+
+   A default channel binding type agreement process for all SASL
+   application protocols that do not provide their own channel binding
+   type agreement is provided as follows.
+
+   'tls-unique' is the default channel binding type for any application
+   that doesn't specify one.
+
+   Servers MUST implement the "tls-unique" [tls-unique]
+   [I-D.altman-tls-channel-bindings] channel binding type, if they
+   implement any channel binding.  Clients SHOULD implement the "tls-
+   unique" [tls-unique] [I-D.altman-tls-channel-bindings] channel
+   binding type, if they implement any channel binding.  Clients and
+   servers SHOULD choose the highest- layer/innermost end-to-end TLS
+   channel as the channel to bind to.
+
+   Servers MUST choose the channel binding type indicated by the client,
+   or fail authentication if they don't support it.
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 16]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+7.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"
+   and "UTF8-4" non-terminal are defined in [RFC3629].
+
+
+     ALPHA = <as defined in RFC 5234 appendix B.1>
+     DIGIT = <as defined in RFC 5234 appendix B.1>
+     UTF8-2 = <as defined in RFC 3629 (STD 63)>
+     UTF8-3 = <as defined in RFC 3629 (STD 63)>
+     UTF8-4 = <as defined in RFC 3629 (STD 63)>
+
+     attr-val        = ALPHA "=" value
+                       ;; Generic syntax of any attribute sent
+                       ;; by server or client
+
+     value           = 1*value-char
+
+     value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
+                       UTF8-2 / UTF8-3 / UTF8-4
+                       ;; UTF8-char except NUL, "=", and ",".
+
+     value-char      = value-safe-char / "="
+
+     base64-char     = ALPHA / DIGIT / "/" / "+"
+
+     base64-4        = 4base64-char
+
+     base64-3        = 3base64-char "="
+
+     base64-2        = 2base64-char "=="
+
+     base64          = *base64-4 [base64-3 / base64-2]
+
+     posit-number = %x31-39 *DIGIT
+                       ;; A positive number
+
+     saslname        = 1*(value-safe-char / "=2C" / "=3D")
+                       ;; Conforms to <value>
+
+     authzid         = "a=" saslname
+                       ;; Protocol specific.
+
+     cb-name         = 1*(ALPHA / DIGIT / "." / "-")
+                        ;; See RFC 5056 section 7.
+                        ;; E.g. "tls-server-end-point" or
+                        ;; "tls-unique"
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 17]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+     gs2-cbind-flag  = "p=" cb-name / "n" / "y"
+                       ;; "n" -> client doesn't support channel binding
+                       ;; "y" -> client does support channel binding
+                       ;;        but thinks the server does not.
+                       ;; "p" -> client requires channel binding.
+                       ;; The selected channel binding follows "p=".
+
+     gs2-header      = gs2-cbind-flag "," [ authzid ] ","
+                       ;; GS2 header for SCRAM
+                       ;; (the actual GS2 header includes an optional
+                       ;; flag to indicate that the GSS mechanism is not
+                       ;; "standard" but since SCRAM is "standard" we
+                       ;; don't include that flag).
+
+     username        = "n=" saslname
+                       ;; Usernames are prepared using SASLPrep.
+
+     reserved-mext  = "m=" 1*(value-char)
+                       ;; Reserved for signalling mandatory extensions.
+                       ;; The exact syntax will be defined in
+                       ;; the future.
+
+     channel-binding = "c=" base64
+                       ;; base64 encoding of cbind-input
+
+     proof           = "p=" base64
+
+     nonce           = "r=" c-nonce [s-nonce]
+                       ;; Second part provided by server.
+
+     c-nonce         = value
+
+     s-nonce         = value
+
+     salt            = "s=" base64
+
+     verifier        = "v=" base64
+                       ;; base-64 encoded ServerSignature.
+
+     iteration-count = "i=" posit-number
+                       ;; A positive number
+
+     client-first-message-bare =
+                       [reserved-mext ","]
+                       username "," nonce ["," extensions]
+
+     client-first-message =
+                       gs2-header client-first-message-bare
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 18]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+     server-first-message =
+                       [reserved-mext ","] nonce "," salt ","
+                       iteration-count ["," extensions]
+
+     client-final-message-without-proof =
+                       channel-binding "," nonce [","
+                       extensions]
+
+     client-final-message =
+                       client-final-message-without-proof "," proof
+
+     gss-server-error = "e=" value
+     server-final-message = gss-server-error /
+                       verifier ["," extensions]
+                       ;; The error message is only for the GSS-API
+                       ;; form of SCRAM, and it is OPTIONAL to
+                       ;; implement it.
+
+     extensions = attr-val *("," attr-val)
+                       ;; All extensions are optional,
+                       ;; i.e. unrecognized attributes
+                       ;; not defined in this document
+                       ;; MUST be ignored.
+
+     cbind-data    = 1*OCTET
+
+     cbind-input   = gs2-header [ cbind-data ]
+                       ;; cbind-data MUST be present for
+                       ;; gs2-cbind-flag of "p" and MUST be absent
+                       ;; for "y" or "n".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 19]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+8.  SCRAM as a GSS-API Mechanism
+
+   This section and its sub-sections and all normative references of it
+   not referenced elsewhere in this document are INFORMATIONAL for SASL
+   implementors, but they are NORMATIVE for GSS-API implementors.
+
+   SCRAM is actually also GSS-API mechanism.  The messages are the same,
+   but a) the GS2 header on the client's first message and channel
+   binding data is excluded when SCRAM is used as a GSS-API mechanism,
+   and b) the RFC2743 section 3.1 initial context token header is
+   prefixed to the client's first authentication message (context
+   token).
+
+   The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10).
+
+8.1.  GSS-API Principal Name Types for SCRAM
+
+   SCRAM does not name acceptors.  Therefore only GSS_C_NO_NAME and
+   names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
+   input of GSS_Init_sec_context() when using a SCRAM mechanism.
+
+   SCRAM supports only a single name type for initiators:
+   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
+   SCRAM.
+
+   There is no name canonicalization procedure for SCRAM beyond applying
+   SASLprep as described in Section 5.1.
+
+   The query, display and exported name syntax for SCRAM principal names
+   is the same: there is no syntax -- SCRAM principal names are free-
+   form.  (The exported name token does, of course, conform to [RFC2743]
+   section 3.2, but the "NAME" part of the token is just a SCRAM user
+   name.)
+
+8.2.  GSS-API Per-Message Tokens for SCRAM
+
+   The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the
+   same as those for the Kerberos V GSS-API mechanism [RFC4121], using
+   the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
+
+   The 128-bit session key SHALL be derived by using the least
+   significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
+   key" || ClientKey || AuthMessage).
+
+   SCRAM does support PROT_READY, and is PROT_READY on the initiator
+   side first upon receipt of the server's reply to the initial security
+   context token.
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 20]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+8.3.  GSS_Pseudo_random() for SCRAM
+
+   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
+   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
+   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
+   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 21]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+9.  Security Considerations
+
+   If the authentication exchange is performed without a strong security
+   layer, then a passive eavesdropper can gain sufficient information to
+   mount an offline dictionary or brute-force attack which can be used
+   to recover the user's password.  The amount of time necessary for
+   this attack depends on the cryptographic hash function selected, the
+   strength of the password and the iteration count supplied by the
+   server.  An external security layer with strong encryption will
+   prevent this attack.
+
+   If the external security layer used to protect the SCRAM exchange
+   uses an anonymous key exchange, then the SCRAM channel binding
+   mechanism can be used to detect a man-in-the-middle attack on the
+   security layer and cause the authentication to fail as a result.
+   However, the man-in-the-middle attacker will have gained sufficient
+   information to mount an offline dictionary or brute-force attack.
+   For this reason, SCRAM includes the ability to increase the iteration
+   count over time.
+
+   If the authentication information is stolen from the authentication
+   database, then an offline dictionary or brute-force attack can be
+   used to recover the user's password.  The use of salt mitigates this
+   attack somewhat by requiring a separate attack on each password.
+   Authentication mechanisms which protect against this attack are
+   available (e.g., the EKE class of mechanisms).  RFC 2945 [RFC2945] is
+   an example of such technology.  There are IPR disclosures at
+   http://datatracker.ietf.org/ipr/ that mention RFC 2945.
+
+   If an attacker obtains the authentication information from the
+   authentication repository and either eavesdrops on one authentication
+   exchange or impersonates a server, the attacker gains the ability to
+   impersonate that user to all servers providing SCRAM access using the
+   same hash function, password, iteration count and salt.  For this
+   reason, it is important to use randomly-generated salt values.
+
+   SCRAM does not negotiate a hash function to use.  Hash function
+   negotiation is left to the SASL mechanism negotiation.  It is
+   important that clients be able to sort a locally available list of
+   mechanisms by preference so that the client may pick the most
+   preferred of a server's advertised mechanism list.  This preference
+   order is not specified here as it is a local matter.  The preference
+   order should include objective and subjective notions of mechanism
+   cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
+   preferred over SCRAM with SHA-1).
+
+   Note that to protect the SASL mechanism negotiation applications
+   normally must list the server mechs twice: once before and once after
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 22]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   authentication, the latter using security layers.  Since SCRAM does
+   not provide security layers the only ways to protect the mechanism
+   negotiation are: a) use channel binding to an external channel, or b)
+   use an external channel that authenticates a user-provided server
+   name.
+
+   SCRAM does not protect against downgrade attacks of channel binding
+   types.  The complexities of negotiation a channel binding type, and
+   handling down-grade attacks in that negotiation, was intentionally
+   left out of scope for this document.
+
+   A hostile server can perform a computational denial-of-service attack
+   on clients by sending a big iteration count value.
+
+   See [RFC4086] for more information about generating randomness.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 23]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+10.  IANA Considerations
+
+   IANA is requested to add the following family of SASL mechanisms to
+   the SASL Mechanism registry established by [RFC4422]:
+
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL family SCRAM
+
+   SASL mechanism name (or prefix for the family): SCRAM-*
+   Security considerations: Section 7 of [RFCXXXX]
+   Published specification (optional, recommended): [RFCXXXX]
+   Person & email address to contact for further information:
+    IETF SASL WG <ietf-sasl@imc.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note: Members of this family must be explicitly registered
+   using the "IETF Consensus" registration procedure.
+   Reviews must be requested on the SASL WG mailing list.
+
+
+   "IETF Consensus" registration procedure MUST be used for registering
+   new mechanisms in this family.  The SASL mailing list
+   <ietf-sasl@imc.org> (or a successor designated by the responsible
+   Security AD) MUST be used for soliciting reviews on such
+   registrations.
+
+   Note to future SCRAM- mechanism designers: each new SCRAM- SASL
+   mechanism MUST be explicitly registered with IANA and MUST comply
+   with SCRAM- mechanism naming convention defined in Section 4 of this
+   document.
+
+   IANA is requested to add the following entries to the SASL Mechanism
+   registry established by [RFC4422]:
+
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL mechanism SCRAM-SHA-1
+
+   SASL mechanism name (or prefix for the family): SCRAM-SHA-1
+   Security considerations: Section 7 of [RFCXXXX]
+   Published specification (optional, recommended): [RFCXXXX]
+   Person & email address to contact for further information:
+    IETF SASL WG <ietf-sasl@imc.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note:
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 24]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS
+
+   SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS
+   Security considerations: Section 7 of [RFCXXXX]
+   Published specification (optional, recommended): [RFCXXXX]
+   Person & email address to contact for further information:
+    IETF SASL WG <ietf-sasl@imc.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note:
+
+
+   This document also requests IANA to assign a GSS-API mechanism OID
+   for SCRAM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 25]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+11.  Acknowledgements
+
+   This document benefited from discussions on the SASL WG mailing list.
+   The authors would like to specially thank Dave Cridland, Simon
+   Josefsson and Jeffrey Hutzelman for their contributions to this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 26]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+Appendix A.  Other Authentication Mechanisms
+
+   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+   proved to be too complex to implement and test, and thus has poor
+   interoperability.  The security layer is often not implemented, and
+   almost never used; everyone uses TLS instead.  For a more complete
+   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+   see [I-D.ietf-sasl-digest-to-historic].
+
+   The CRAM-MD5 SASL mechanism, while widely deployed has also some
+   problems, in particular it is missing some modern SASL features such
+   as support for internationalized usernames and passwords, support for
+   passing of authorization identity, support for channel bindings.  It
+   also doesn't support server authentication.  For a more complete list
+   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
+
+   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+   eavesdropper to impersonate the authenticating user to any other
+   server for which the user has the same password.  It also sends the
+   password in the clear over the network, unless TLS is used.  Server
+   authentication is not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 27]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+Appendix B.  Design Motivations
+
+   The following design goals shaped this document.  Note that some of
+   the goals have changed since the initial version of the document.
+
+   o  The SASL mechanism has all modern SASL features: support for
+      internationalized usernames and passwords, support for passing of
+      authorization identity, support for channel bindings.
+
+   o  The protocol supports mutual authentication.
+
+   o  The authentication information stored in the authentication
+      database is not sufficient by itself to impersonate the client.
+
+   o  The server does not gain the ability to impersonate the client to
+      other servers (with an exception for server-authorized proxies),
+      unless such other servers allow SCRAM authentication and use the
+      same salt and iteration count for the user.
+
+   o  The mechanism is extensible, but [hopefully] not overengineered in
+      this respect.
+
+   o  Easier to implement than DIGEST-MD5 in both clients and servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 28]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+Appendix C.  Internet-Draft Change History
+
+   (RFC Editor: Please delete everything after this point)
+
+   Changes since -10
+
+   o  Converted the source for this I-D to XML.
+
+   o  Added text to make SCRAM compliant with the new GS2 design.
+
+   o  Added text on channel binding negotiation.
+
+   o  Added text on channel binding, including a reference to RFC5056.
+
+   o  Added text on SCRAM as a GSS-API mechanism.  This noted as not
+      relevant to SASL-only implementors -- the normative references for
+      SCRAM as a GSS-API mechanism are segregated as well.
+
+   Changes since -07
+
+   o  Updated References.
+
+   o  Clarified purpose of the m= attribute.
+
+   o  Fixed a problem with authentication/authorization identity's ABNF
+      not allowing for some characters.
+
+   o  Updated ABNF for nonce to show client-generated and server-
+      generated parts.
+
+   o  Only register SCRAM-SHA-1 with IANA and require explicit
+      registrations of all other SCRAM- mechanisms.
+
+   Changes since -06
+
+   o  Removed hash negotiation from SCRAM and turned it into a family of
+      SASL mechanisms.
+
+   o  Start using "Hash Function Textual Names" IANA registry for SCRAM
+      mechanism naming.
+
+   o  Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
+
+   o  Clarified extensibility of SCRAM: added m= attribute (for future
+      mandatory extensions) and specified that all unrecognized
+      attributes must be ignored.
+
+   Changes since -05
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 29]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   o  Changed the mandatory to implement hash algorithm to SHA-1 (as per
+      WG consensus).
+
+   o  Added text about use of SASLPrep for username canonicalization/
+      validation.
+
+   o  Clarified that authorization identity is canonicalized/verified
+      according to SASL protocol profile.
+
+   o  Clarified that iteration count is per-user.
+
+   o  Clarified how clients select the authentication function.
+
+   o  Added IANA registration for the new mechanism.
+
+   o  Added missing normative references (UTF-8, SASLPrep).
+
+   o  Various editorial changes based on comments from Hallvard B
+      Furuseth, Nico William and Simon Josefsson.
+
+   Changes since -04
+
+   o  Update Base64 and Security Glossary references.
+
+   o  Add Formal Syntax section.
+
+   o  Don't bother with "v=".
+
+   o  Make MD5 mandatory to implement.  Suggest i=128.
+
+   Changes since -03
+
+   o  Seven years have passed, in which it became clear that DIGEST-MD5
+      suffered from unacceptably bad interoperability, so SCRAM-MD5 is
+      now back from the dead.
+
+   o  Be hash agnostic, so MD5 can be replaced more easily.
+
+   o  General simplification.
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 30]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, September 2001.
+
+   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
+              Internationalized Strings ("stringprep")", RFC 3454,
+              December 2002.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+              and Passwords", RFC 4013, February 2005.
+
+   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
+              Security Layer (SASL)", RFC 4422, June 2006.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+12.2.  Normative References for GSS-API implementors
+
+   [I-D.ietf-sasl-gs2]
+              Josefsson, S. and N. Williams, "Using GSS-API Mechanisms
+              in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-12
+              (work in progress), April 2009.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 31]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
+
+   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
+              Kerberos V Generic Security Service Application Program
+              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
+
+   [tls-unique]
+              Zhu, L., "Registration of TLS unique channel binding
+              (generic)", IANA http://www.iana.org/assignments/
+              channel-binding-types/tls-unique, July 2008.
+
+12.3.  Informative References
+
+   [I-D.altman-tls-channel-bindings]
+              Altman, J., Williams, N., and L. Zhu, "Channel Bindings
+              for TLS", draft-altman-tls-channel-bindings-05 (work in
+              progress), June 2009.
+
+   [I-D.ietf-sasl-crammd5-to-historic]
+              Zeilenga, K., "CRAM-MD5 to Historic",
+              draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
+              November 2008.
+
+   [I-D.ietf-sasl-digest-to-historic]
+              Melnikov, A., "Moving DIGEST-MD5 to Historic",
+              draft-ietf-sasl-digest-to-historic-00 (work in progress),
+              July 2008.
+
+   [I-D.melnikov-sasl-scram-ldap]
+              Melnikov, A., "LDAP schema for storing SCRAM secrets",
+              draft-melnikov-sasl-scram-ldap-02 (work in progress),
+              July 2009.
+
+   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
+              Specification Version 2.0", RFC 2898, September 2000.
+
+   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
+              RFC 2945, September 2000.
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 32]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510,
+              June 2006.
+
+   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
+              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              RFC 4949, August 2007.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [tls-server-end-point]
+              Zhu, L., "Registration of TLS server end-point channel
+              bindings", IANA http://www.iana.org/assignments/
+              channel-binding-types/tls-server-end-point, July 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 33]
+
+Internet-Draft                    SCRAM                        July 2009
+
+
+Authors' Addresses
+
+   Abhijit Menon-Sen
+   Oryx Mail Systems GmbH
+
+   Email: ams@oryx.com
+
+
+   Alexey Melnikov
+   Isode Ltd
+
+   Email: Alexey.Melnikov@isode.com
+
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive
+   West Covina, CA  91790
+   USA
+
+   Email: chris.newman@sun.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   USA
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.       Expires February 1, 2010               [Page 34]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt b/third_party/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt
new file mode 100644
index 00000000000..8956003025d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt
@@ -0,0 +1,1233 @@
+
+
+
+Internet Engineering Task Force                            K. Jaganathan
+Internet-Draft                                                    L. Zhu
+Expires: January 9, 2006                                       J. Brezak
+                                                   Microsoft Corporation
+                                                            July 8, 2005
+
+
+                 The RC4-HMAC Kerberos encryption type
+                    draft-jaganathan-rc4-hmac-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 9, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Microsoft 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),
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 1]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   and provide exportable (meet United States government export
+   restriction requirements) encryption.  This document describes the
+   implementation of those encryption types.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Key Generation . . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Checksum Types . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Encryption Types . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 12
+   8.  GSSAPI Kerberos V5 Mechanism Type  . . . . . . . . . . . . . . 13
+     8.1   Mechanism Specific Changes . . . . . . . . . . . . . . . . 13
+     8.2   GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 14
+     8.3   GSSAPI WRAP Semantics  . . . . . . . . . . . . . . . . . . 16
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   10.   Normative References . . . . . . . . . . . . . . . . . . . . 20
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+       Intellectual Property and Copyright Statements . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 2]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+1.  Introduction
+
+   The Microsoft 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 Microsoft Windows 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 3]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 4]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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
+   [RFC1320] 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 5]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+4.  Basic Operations
+
+   The MD5 HMAC function is defined in [RFC2104].  It is used in this
+   encryption type for checksum operations.  Refer to [RFC2104] 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 [RFC1321].  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 .  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.  With each message, the
+   message type (T) is used as a component of the keying material.  This
+   table summarizes the different key derivation values used in the
+   various operations.  Note that these differ from the key derivations
+   used in other Kerberos encryption types.  T = the message type,
+   encoded as a little-endian four byte integer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 6]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+          1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
+          the client key (T=1)
+          2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key
+          or application session key), encrypted with the service key
+          (T=2)
+          3.  AS-REP encrypted part (includes TGS session key or
+          application session key), encrypted with the client key (T=8)
+          4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
+          TGS session key (T=4)
+          5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
+          TGS authenticator subkey (T=5)
+          6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
+          keyed with the TGS session key (T=6)
+          7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
+          TGS authenticator subkey), encrypted with the TGS session key
+           T=7)
+          8.  TGS-REP encrypted part (includes application session key),
+          encrypted with the TGS session key (T=8)
+          9.  TGS-REP encrypted part (includes application session key),
+          encrypted with the TGS authenticator subkey (T=8)
+          10.  AP-REQ Authenticator cksum, keyed with the application
+          session key (T=10)
+          11.  AP-REQ Authenticator (includes application authenticator
+          subkey), encrypted with the application session key (T=11)
+          12.  AP-REP encrypted part (includes application session
+          subkey), encrypted with the application session key (T=12)
+          13.  KRB-PRIV encrypted part, encrypted with a key chosen by
+          the application. Also for data encrypted with GSS Wrap (T=13)
+          14.  KRB-CRED encrypted part, encrypted with a key chosen by
+          the application (T=14)
+          15.  KRB-SAFE cksum, keyed with a key chosen by the
+          application. Also for data signed in GSS MIC (T=15)
+
+          Relative to RFC-1964 key uses:
+
+         T = 0 in the generation of sequence number for the MIC 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.
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 7]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 8]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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.
+
+           OCTET L40[14] = "fortybits";
+           OCTET SK = "signaturekey";
+
+      The header field on the encrypted data in KDC messages is:
+
+           typedef struct _RC4_MDx_HEADER {
+               OCTET Checksum[16];
+               OCTET Confounder[8];
+           } RC4_MDx_HEADER, *PRC4_MDx_HEADER;
+
+
+           ENCRYPT (K, export, T, data)
+           {
+               struct EDATA {
+                   struct HEADER {
+                           OCTET Checksum[16];
+                           OCTET Confounder[8];
+                   } Header;
+                   OCTET Data[0];
+               } edata;
+
+               if (export){
+                   *((DWORD *)(L40+10)) = T;
+                   HMAC (K, L40, 10 + 4, K1);
+               }
+               else
+               {
+                   HMAC (K, &T, 4, K1);
+               }
+               memcpy (K2, K1, 16);
+               if (export) memset (K1+7, 0xAB, 9);
+
+               nonce (edata.Confounder, 8);
+               memcpy (edata.Data, data);
+
+               edata.Checksum = HMAC (K2, edata);
+
+
+
+Jaganathan, et al.       Expires January 9, 2006                [Page 9]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+               K3 = HMAC (K1, edata.Checksum);
+
+               RC4 (K3, edata.Confounder);
+               RC4 (K3, data.Data);
+           }
+
+           DECRYPT (K, export, T, edata)
+           {
+               // edata looks like
+               struct EDATA {
+                   struct HEADER {
+                           OCTET Checksum[16];
+                           OCTET Confounder[8];
+                   } Header;
+                   OCTET Data[0];
+               } edata;
+
+               if (export){
+                   *((DWORD *)(L40+10)) = T;
+                   HMAC (K, L40, 14, K1);
+               }
+               else
+               {
+                   HMAC (K, &T, 4, K1);
+               }
+               memcpy (K2, K1, 16);
+               if (export) memset (K1+7, 0xAB, 9);
+
+               K3 = HMAC (K1, edata.Checksum);
+
+               RC4 (K3, edata.Confounder);
+               RC4 (K3, edata.Data);
+
+
+               // verify generated and received checksums
+             checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
+               if (checksum != edata.Checksum)
+                   printf("CHECKSUM ERROR  !!!!!!\n");
+           }
+
+   The KDC message is encrypted using the ENCRYPT function not including
+   the Checksum in the RC4_MDx_HEADER.
+
+   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.
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 10]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   The pseudo-random operation [RFC3961] for both enctypes above is
+   defined as follows:
+
+           pseudo-random(K, S) = HMAC-SHA1(K, S)
+
+   where K is the protocol key and S is the input octet string.  HMAC-
+   SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20-
+   octet digest.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 11]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 12]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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 are adapted to
+   support these new encryption types.  See [RFC1964] Section 1.2.2.
+
+   The only support quality of protection is:
+
+         #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0
+
+   When using this RC4 based encryption type, the sequence number is
+   always 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
+   [RFC1964] 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 per message tokens - they are raw AP messages that do not
+   include object identifiers.
+
+           #define GSS_C_DCE_STYLE                 0x1000
+
+   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
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 13]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   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
+   15 characters, trailing blank (ASCII char 20) filled, with a 16-th
+   octet of 0x0.
+
+8.2   GSSAPI MIC Semantics
+
+   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 [RFC1964] Section 1.2 for
+   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
+
+   The GSS_GetMIC token has the following format:
+
+        Byte no         Name        Description
+        0..1           TOK_ID     Identification field.
+                                  Tokens emitted by GSS_GetMIC() contain
+                                  the hex value 01 01 in this field.
+        2..3           SGN_ALG    Integrity algorithm indicator.
+                                  11 00 - HMAC
+        4..7           Filler     Contains ff ff ff ff
+        8..15          SND_SEQ    Sequence number field.
+        16..23         SGN_CKSUM  Checksum of "to-be-signed data",
+                                  calculated according to algorithm
+                                  specified in SGN_ALG field.
+
+   The MIC mechanism used for GSS MIC based messages is as follow:
+
+           GetMIC(Kss, direction, export, seq_num, data)
+           {
+                   struct Token {
+                          struct Header {
+                                 OCTET TOK_ID[2];
+                                 OCTET SGN_ALG[2];
+                                 OCTET Filler[4];
+                            };
+                          OCTET SND_SEQ[8];
+                          OCTET SGN_CKSUM[8];
+                   } Token;
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 14]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   Token.TOK_ID = 01 01;
+                   Token.SGN_SLG = 11 00;
+                   Token.Filler = ff ff ff ff;
+
+                   // Create the sequence number
+
+                   if (direction == sender_is_initiator)
+                   {
+                           memset(Token.SEND_SEQ+4, 0xff, 4)
+                   }
+                   else if (direction == sender_is_acceptor)
+                   {
+                           memset(Token.SEND_SEQ+4, 0, 4)
+                   }
+                   Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
+                   Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
+                   Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
+                   Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
+
+                   // Derive signing key from session key
+
+                   Ksign = HMAC(Kss, "signaturekey");
+                                     // length includes terminating null
+
+                   // Generate checksum of message - SGN_CKSUM
+                   //   Key derivation salt = 15
+
+                   Sgn_Cksum = MD5((int32)15, Token.Header, data);
+
+                   // Save first 8 octets of HMAC Sgn_Cksum
+
+                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
+                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
+
+                   // Encrypt the sequence number
+
+                   // Derive encryption key for the sequence number
+                   //   Key derivation salt = 0
+
+                   if (exportable)
+                   {
+                           Kseq = HMAC(Kss, "fortybits", (int32)0);
+                                        // len includes terminating null
+                           memset(Kseq+7, 0xab, 7)
+                   }
+                   else
+                   {
+                            Kseq = HMAC(Kss, (int32)0);
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 15]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   }
+                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
+
+                   // Encrypt the sequence number
+
+                   RC4(Kseq, Token.SND_SEQ);
+           }
+
+
+8.3   GSSAPI WRAP Semantics
+
+   There are two encryption keys 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 [RFC1964] Section 1.2.2.3.
+
+   The RC4-HMAC GSS_Wrap() token has the following format:
+
+
+      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.
+                                    11 00 - HMAC
+        4..5           SEAL_ALG     ff ff - none
+                                    00 00 - DES-CBC
+                                    10 00 - RC4
+        6..7           Filler       Contains ff ff
+        8..15          SND_SEQ      Encrypted sequence number field.
+        16..23         SGN_CKSUM    Checksum of plaintext padded data,
+                                    calculated according to algorithm
+                                    specified in SGN_ALG field.
+        24..31         Confounder   Random confounder
+        32..last       Data         encrypted or plaintext padded data
+
+   The encryption mechanism used for GSS wrap based messages is as
+   follow:
+
+
+           WRAP(Kss, encrypt, direction, export, seq_num, data)
+           {
+                   struct Token {          // 32 octets
+                          struct Header {
+                                 OCTET TOK_ID[2];
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 16]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                                 OCTET SGN_ALG[2];
+                                 OCTET SEAL_ALG[2];
+                                 OCTET Filler[2];
+                          };
+                          OCTET SND_SEQ[8];
+                          OCTET SGN_CKSUM[8];
+                            OCTET Confounder[8];
+                   } Token;
+
+
+                   Token.TOK_ID = 02 01;
+                   Token.SGN_SLG = 11 00;
+                   Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
+                   Token.Filler = ff ff;
+
+                   // Create the sequence number
+
+                   if (direction == sender_is_initiator)
+                   {
+                           memset(&Token.SEND_SEQ[4], 0xff, 4)
+                   }
+                   else if (direction == sender_is_acceptor)
+                   {
+                           memset(&Token.SEND_SEQ[4], 0, 4)
+                   }
+                   Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
+                   Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
+                   Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
+                   Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
+
+                   // Generate random confounder
+
+                   nonce(&Token.Confounder, 8);
+
+                   // Derive signing key from session key
+
+                   Ksign = HMAC(Kss, "signaturekey");
+
+                   // Generate checksum of message -
+                   //  SGN_CKSUM + Token.Confounder
+                   //   Key derivation salt = 15
+
+                   Sgn_Cksum = MD5((int32)15, Token.Header,
+                                   Token.Confounder);
+
+                   // Derive encryption key for data
+                   //   Key derivation salt = 0
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 17]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
+                                                           // XOR
+                   if (exportable)
+                   {
+                           Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
+                                       // len includes terminating null
+                           memset(Kcrypt+7, 0xab, 7);
+                   }
+                   else
+                   {
+                           Kcrypt = HMAC(Klocal, (int32)0);
+                     }
+
+                   // new encryption key salted with seq
+
+                   Kcrypt = HMAC(Kcrypt, (int32)seq);
+
+                   // Encrypt confounder (if encrypting)
+
+                   if (encrypt)
+                           RC4(Kcrypt, Token.Confounder);
+
+                   // Sum the data buffer
+
+                   Sgn_Cksum += MD5(data);         // Append to checksum
+
+                   // Encrypt the data (if encrypting)
+
+                   if (encrypt)
+                           RC4(Kcrypt, data);
+
+                   // Save first 8 octets of HMAC Sgn_Cksum
+
+                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
+                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
+
+                   // Derive encryption key for the sequence number
+                   //   Key derivation salt = 0
+
+                   if (exportable)
+                   {
+                           Kseq = HMAC(Kss, "fortybits", (int32)0);
+                                       // len includes terminating null
+                           memset(Kseq+7, 0xab, 7)
+                   }
+                   else
+                   {
+                           Kseq = HMAC(Kss, (int32)0);
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 18]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   }
+                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
+
+                   // Encrypt the sequence number
+
+                   RC4(Kseq, Token.SND_SEQ);
+
+                   // Encrypted message = Token + Data
+           }
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 19]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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.  Normative References
+
+   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
+              April 1992.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510, September 1993.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+
+Authors' Addresses
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 20]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   John Brezak
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: jbrezak@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 21]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Jaganathan, et al.       Expires January 9, 2006               [Page 22]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-01.txt b/third_party/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-01.txt
new file mode 100644
index 00000000000..1550e35deec
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-jaganathan-rc4-hmac-01.txt
@@ -0,0 +1,1177 @@
+
+
+
+Internet Engineering Task Force                            K. Jaganathan
+Internet-Draft                                                    L. Zhu
+Expires: January 19, 2006                                      J. Brezak
+                                                   Microsoft Corporation
+                                                           July 18, 2005
+
+
+                 The RC4-HMAC Kerberos encryption type
+                    draft-jaganathan-rc4-hmac-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Microsoft 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),
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 1]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   and provide exportable (meet United States government export
+   restriction requirements) encryption.  This document describes the
+   implementation of those encryption types
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Key Generation . . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Checksum Types . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Encryption Types . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 11
+   8.  GSSAPI Kerberos V5 Mechanism Type  . . . . . . . . . . . . . . 12
+     8.1   Mechanism Specific Changes . . . . . . . . . . . . . . . . 12
+     8.2   GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 13
+     8.3   GSSAPI WRAP Semantics  . . . . . . . . . . . . . . . . . . 15
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   10.   Normative References . . . . . . . . . . . . . . . . . . . . 19
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
+       Intellectual Property and Copyright Statements . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 2]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+1.  Introduction
+
+   The Microsoft 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 Microsoft Windows 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 3]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 4]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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 4120.  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
+   [RFC1320] 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 5]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+4.  Basic Operations
+
+   The MD5 HMAC function is defined in [RFC2104].  It is used in this
+   encryption type for checksum operations.  Refer to[RFC2104]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 [RFC1321].  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 .  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.  With each message, the
+   message type (T) is used as a component of the keying material.  This
+   table summarizes the different key derivation values used in the
+   various operations.  Note that these differ from the key derivations
+   used in other Kerberos encryption types.  T = the message type,
+   encoded as a little-endian four byte integer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 6]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+          1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
+          the client key (T=1)
+          2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key
+          or application session key), encrypted with the service key
+          (T=2)
+          3.  AS-REP encrypted part (includes TGS session key or
+          application session key), encrypted with the client key (T=8)
+          4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
+          TGS session key (T=4)
+          5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
+          TGS authenticator subkey (T=5)
+          6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
+          keyed with the TGS session key (T=6)
+          7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
+          TGS authenticator subkey), encrypted with the TGS session key
+           T=7)
+          8.  TGS-REP encrypted part (includes application session key),
+          encrypted with the TGS session key (T=8)
+          9.  TGS-REP encrypted part (includes application session key),
+          encrypted with the TGS authenticator subkey (T=8)
+          10.  AP-REQ Authenticator cksum, keyed with the application
+          session key (T=10)
+          11.  AP-REQ Authenticator (includes application authenticator
+          subkey), encrypted with the application session key (T=11)
+          12.  AP-REP encrypted part (includes application session
+          subkey), encrypted with the application session key (T=12)
+          13.  KRB-PRIV encrypted part, encrypted with a key chosen by
+          the application. Also for data encrypted with GSS Wrap (T=13)
+          14.  KRB-CRED encrypted part, encrypted with a key chosen by
+          the application (T=14)
+          15.  KRB-SAFE cksum, keyed with a key chosen by the
+          application. Also for data signed in GSS MIC (T=15)
+
+          Relative to RFC-4121 key uses:
+
+         T = 0 in the generation of sequence number for the MIC 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.
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 7]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 8]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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.
+
+           OCTET L40[14] = "fortybits";
+           OCTET SK = "signaturekey";
+
+      The header field on the encrypted data in KDC messages is:
+
+           typedef struct _RC4_MDx_HEADER {
+               OCTET Checksum[16];
+               OCTET Confounder[8];
+           } RC4_MDx_HEADER, *PRC4_MDx_HEADER;
+
+
+           ENCRYPT (K, export, T, data)
+           {
+               struct EDATA {
+                   struct HEADER {
+                           OCTET Checksum[16];
+                           OCTET Confounder[8];
+                   } Header;
+                   OCTET Data[0];
+               } edata;
+
+               if (export){
+                   *((DWORD *)(L40+10)) = T;
+                   HMAC (K, L40, 10 + 4, K1);
+               }
+               else
+               {
+                   HMAC (K, "&"T, 4, K1);
+               }
+               memcpy (K2, K1, 16);
+               if (export) memset (K1+7, 0xAB, 9);
+
+               nonce (edata.Confounder, 8);
+               memcpy (edata.Data, data);
+
+               edata.Checksum = HMAC (K2, edata);
+
+
+
+Jaganathan, et al.      Expires January 19, 2006                [Page 9]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+               K3 = HMAC (K1, edata.Checksum);
+
+               RC4 (K3, edata.Confounder);
+               RC4 (K3, data.Data);
+           }
+
+           DECRYPT (K, export, T, edata)
+           {
+               // edata looks like
+               struct EDATA {
+                   struct HEADER {
+                           OCTET Checksum[16];
+                           OCTET Confounder[8];
+                   } Header;
+                   OCTET Data[0];
+               } edata;
+
+               if (export){
+                   *((DWORD *)(L40+10)) = T;
+                   HMAC (K, L40, 14, K1);
+               }
+               else
+               {
+                   HMAC (K, "&"T, 4, K1);
+               }
+               memcpy (K2, K1, 16);
+               if (export) memset (K1+7, 0xAB, 9);
+
+               K3 = HMAC (K1, edata.Checksum);
+
+               RC4 (K3, edata.Confounder);
+               RC4 (K3, edata.Data);
+
+
+               // verify generated and received checksums
+             checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
+               if (checksum != edata.Checksum)
+                   printf("CHECKSUM ERROR  !!!!!!\n");
+           }
+
+   The KDC message is encrypted using the ENCRYPT function not including
+   the Checksum in the RC4_MDx_HEADER.
+
+   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.
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 10]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+7.  Key Strength Negotiation
+
+   TA 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 11]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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 are adapted to
+   support these new encryption types .  See [RFC4121] .
+
+   The only support quality of protection is:
+
+         #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0
+
+   When using this RC4 based encryption type, the sequence number is
+   always 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
+   [RFC4121] .
+
+   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 serverAEs
+   AP reply.  In addition, the context negotiation tokens do not have
+   GSSAPI per message tokens - they are raw AP messages that do not
+   include object identifiers.
+
+           #define GSS_C_DCE_STYLE                 0x1000
+
+   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
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 12]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   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
+   15 characters, trailing blank (ASCII char 20) filled, with a 16-th
+   octet of 0x0.
+
+8.2   GSSAPI MIC Semantics
+
+   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 [RFC4121] for GSS_GetMIC()
+   and GSS_Wrap(conf_flag=FALSE).
+
+   The GSS_GetMIC token has the following format:
+
+        Byte no         Name       Description
+        0..1           TOK_ID     Identification field.
+                                  Tokens emitted by GSS_GetMIC() contain
+                                  the hex value 01 01 in this field.
+        2..3           SGN_ALG    Integrity algorithm indicator.
+                                  11 00 - HMAC
+        4..7           Filler     Contains ff ff ff ff
+        8..15          SND_SEQ    Sequence number field.
+        6..23         SGN_CKSUM  Checksum of "to-be-signed data",
+                                 calculated according to algorithm
+                                 specified in SGN_ALG field.
+
+   The MIC mechanism used for GSS MIC based messages is as follow:
+
+           GetMIC(Kss, direction, export, seq_num, data)
+           {
+                   struct Token {
+                          struct Header {
+                                 OCTET TOK_ID[2];
+                                 OCTET SGN_ALG[2];
+                                 OCTET Filler[4];
+                            };
+                          OCTET SND_SEQ[8];
+                          OCTET SGN_CKSUM[8];
+                   } Token;
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 13]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   Token.TOK_ID = 01 01;
+                   Token.SGN_SLG = 11 00;
+                   Token.Filler = ff ff ff ff;
+
+                   // Create the sequence number
+
+                   if (direction == sender_is_initiator)
+                   {
+                           memset(Token.SEND_SEQ+4, 0xff, 4)
+                   }
+                   else if (direction == sender_is_acceptor)
+                   {
+                           memset(Token.SEND_SEQ+4, 0, 4)
+                   }
+                   Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24;
+                   Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16;
+                   Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8;
+                   Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff);
+
+                   // Derive signing key from session key
+
+                   Ksign = HMAC(Kss, "signaturekey");
+                                     // length includes terminating null
+
+                   // Generate checksum of message - SGN_CKSUM
+                   //   Key derivation salt = 15
+
+                   Sgn_Cksum = MD5((int32)15, Token.Header, data);
+
+                   // Save first 8 octets of HMAC Sgn_Cksum
+
+                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
+                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
+
+                   // Encrypt the sequence number
+
+                   // Derive encryption key for the sequence number
+                   //   Key derivation salt = 0
+
+                   if (exportable)
+                   {
+                           Kseq = HMAC(Kss, "fortybits", (int32)0);
+                                        // len includes terminating null
+                           memset(Kseq+7, 0xab, 7)
+                   }
+                   else
+                   {
+                            Kseq = HMAC(Kss, (int32)0);
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 14]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   }
+                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
+
+                   // Encrypt the sequence number
+
+                   RC4(Kseq, Token.SND_SEQ);
+           }
+
+
+8.3   GSSAPI WRAP Semantics
+
+   There are two encryption keys 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 [RFC4121] .
+
+   The RC4-HMAC GSS_Wrap() token has the following format:
+
+
+      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.
+                                    11 00 - HMAC
+        4..5           SEAL_ALG     ff ff - none
+                                    00 00 - DES-CBC
+                                    10 00 - RC4
+        6..7           Filler       Contains ff ff
+        8..15          SND_SEQ      Encrypted sequence number field.
+        16..23         SGN_CKSUM    Checksum of plaintext padded data,
+                                    calculated according to algorithm
+                                    specified in SGN_ALG field.
+        24..31         Confounder   Random confounder
+        32..last       Data         encrypted or plaintext padded data
+
+   The encryption mechanism used for GSS wrap based messages is as
+   follow:
+
+
+           WRAP(Kss, encrypt, direction, export, seq_num, data)
+           {
+                   struct Token {          // 32 octets
+                          struct Header {
+                                 OCTET TOK_ID[2];
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 15]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                                 OCTET SGN_ALG[2];
+                                 OCTET SEAL_ALG[2];
+                                 OCTET Filler[2];
+                          };
+                          OCTET SND_SEQ[8];
+                          OCTET SGN_CKSUM[8];
+                            OCTET Confounder[8];
+                   } Token;
+
+
+                   Token.TOK_ID = 02 01;
+                   Token.SGN_SLG = 11 00;
+                   Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
+                   Token.Filler = ff ff;
+
+                   // Create the sequence number
+
+                   if (direction == sender_is_initiator)
+                   {
+                           memset("&"Token.SEND_SEQ[4], 0xff, 4)
+                   }
+                   else if (direction == sender_is_acceptor)
+                   {
+                           memset("&"Token.SEND_SEQ[4], 0, 4)
+                   }
+                   Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24;
+                   Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16;
+                   Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8;
+                   Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff);
+
+                   // Generate random confounder
+
+                   nonce("&"Token.Confounder, 8);
+
+                   // Derive signing key from session key
+
+                   Ksign = HMAC(Kss, "signaturekey");
+
+                   // Generate checksum of message -
+                   //  SGN_CKSUM + Token.Confounder
+                   //   Key derivation salt = 15
+
+                   Sgn_Cksum = MD5((int32)15, Token.Header,
+                                   Token.Confounder);
+
+                   // Derive encryption key for data
+                   //   Key derivation salt = 0
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 16]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   for (i = 0; i "<" 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
+           // XOR
+                   if (exportable)
+                   {
+                           Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
+                                       // len includes terminating null
+                           memset(Kcrypt+7, 0xab, 7);
+                   }
+                   else
+                   {
+                           Kcrypt = HMAC(Klocal, (int32)0);
+                     }
+
+                   // new encryption key salted with seq
+
+                   Kcrypt = HMAC(Kcrypt, (int32)seq);
+
+                   // Encrypt confounder (if encrypting)
+
+                   if (encrypt)
+                           RC4(Kcrypt, Token.Confounder);
+
+                   // Sum the data buffer
+
+                   Sgn_Cksum += MD5(data);         // Append to checksum
+
+                   // Encrypt the data (if encrypting)
+
+                   if (encrypt)
+                           RC4(Kcrypt, data);
+
+                   // Save first 8 octets of HMAC Sgn_Cksum
+
+                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
+                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
+
+                   // Derive encryption key for the sequence number
+                   //   Key derivation salt = 0
+
+                   if (exportable)
+                   {
+                           Kseq = HMAC(Kss, "fortybits", (int32)0);
+                                       // len includes terminating null
+                           memset(Kseq+7, 0xab, 7)
+                   }
+                   else
+                   {
+                           Kseq = HMAC(Kss, (int32)0);
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 17]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+                   }
+                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
+
+                   // Encrypt the sequence number
+
+                   RC4(Kseq, Token.SND_SEQ);
+
+                   // Encrypted message = Token + Data
+           }
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 18]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+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.  The Windows
+   implementation of Kerberos uses a minimum RC4 key strength of 128
+   bits.  A discussion of the security considerations when using HMACs
+   is present in  [RFC2104] .
+
+10.  Normative References
+
+   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
+              April 1992.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+
+Authors' Addresses
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 19]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   John Brezak
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: jbrezak@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 20]
+
+Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Jaganathan, et al.      Expires January 19, 2006               [Page 21]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt
new file mode 100644
index 00000000000..e5be859aeee
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt
@@ -0,0 +1,447 @@
+Network Working Group                                       S. Josefsson
+Internet-Draft                                         November 13, 2004
+Expires: May 14, 2005
+
+
+          Using Transport Layer Security (TLS) with Kerberos 5
+                 draft-josefsson-kerberos5-starttls-00
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on May 14, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specify how the Transport Layer Security (TLS) protocol
+   is used in conjunction with the Kerberos 5 protocol.
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 1]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+Table of Contents
+
+   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
+   2.  Extension Mechanism for TCP/IP transport . . . . . . . . . . .  4
+   3.  Kerberos 5 STARTTLS Extension  . . . . . . . . . . . . . . . .  4
+     3.1   STARTTLS requested by client (extension 1) . . . . . . . .  4
+     3.2   STARTTLS request accepted by server (extension 2)  . . . .  5
+     3.3   Proceeding after successful TLS negotiation  . . . . . . .  5
+     3.4   Proceeding after failed TLS negotiation  . . . . . . . . .  5
+     3.5   STARTTLS aware KDC Discovery . . . . . . . . . . . . . . .  5
+     3.6   Initial Authentication via TLS . . . . . . . . . . . . . .  5
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.1   Normative References . . . . . . . . . . . . . . . . . . . .  6
+   5.2   Informative References . . . . . . . . . . . . . . . . . . .  6
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
+       Intellectual Property and Copyright Statements . . . . . . . .  8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 2]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+1.  Introduction and Background
+
+   This document describe how Shishi, a Kerberos 5 [1] implementation,
+   upgrade communication between clients and Key Distribution Centers
+   (KDCs) to use the Transport Layer Security (TLS) [2] protocol.
+
+   The TLS protocol offer integrity and privacy protected exchanges that
+   can be authentication using X.509 certificates, OpenPGP keys [6], and
+   user name and passwords via SRP [5].
+
+   An inconclusive list of the motivation for using TLS with Kerberos 5
+   is given below.
+
+   o  Explicit server authentication of the KDC to the client.  In
+      traditional Kerberos 5, authentication of the KDC is proved as a
+      side effect that the KDC knows your encryption key (i.e., your
+      password).
+
+   o  Flexible authentication against KDC.  Kerberos 5 assume the user
+      knows a key (usually in the form of a password).  Sometimes
+      external factors make this hard to fulfill.  In some situations,
+      users are equipped with smart cards with a RSA authentication key.
+      In others, users have a OpenPGP client on their desktop, with a
+      public OpenPGP key known to the server.  In some situations, the
+      policy may be that password authentication may only be done
+      through SRP.
+
+   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
+      packets are transfered without privacy protection (i.e.,
+      encryption).  That part contains information, such as the client
+      principal name, the server principal name, the encryption types
+      supported by the client, the lifetime of tickets, etc.  Revealing
+      such information is, in some threat models, considered a problem.
+
+   o  Prevents downgrade attacks affecting encryption types.  The
+      encryption type of the ticket in KDC-REQ are sent in the clear in
+      Kerberos 5.  This allows an attacker to replace the encryption
+      type with a compromised mechanisms, e.g.  56-bit DES.  Since
+      clients in general cannot know the encryption types other servers
+      support, it is difficult for the client to detect if there was a
+      man-in-the-middle or if the remote server simply did not support a
+      stronger mechanism.  Clients could chose to refuse 56-bit DES
+      altogether, but in some environments this leads to operational
+      difficulties.
+
+   o  The TLS protocol has been studied by many parties.  In some threat
+      models, the designer prefer to reduce the number of protocols that
+      can hurt the overall system security if they are compromised.
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 3]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+   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 [4].
+
+2.  Extension Mechanism for TCP/IP transport
+
+   Kerberos 5 require Key Distribution Centers (KDCs) to accept requests
+   over TCP.  Each request and response is prefixed by 4 octets,
+   encoding an integer in network byte order, that indicate the length
+   of the packet.  The high bit of the 4 octet length field was reserved
+   for future expansion.  Servers that do not understand how to
+   interpret a set high bit are required to return a KRB-ERROR with the
+   KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream.
+
+   We will use the reserved bit to provide an extension mechanism.  When
+   the reserved high bit is set, the remaining 31 bits of the 4 octets
+   are treated as an extensible typed hole, and thus form a 31 bit
+   integer enumerating various extensions.  Each of the values indicate
+   a specific extended operation mode, two of which are used and defined
+   here, and the rest are left for others to use.
+
+   If the KDC do not understand a requested extension, it MUST return a
+   KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
+   length integer, with the high bit clear, as usual) and close the TCP
+   stream.
+
+   The following table specify the meaning of the 31 lower bits in the 4
+   octet field, when the high bit is set:
+
+   0               RESERVED.
+   1               STARTTLS requested by client.
+   2               STARTTLS request accepted by server.
+   3...2147483647  AVAILABLE for registration (via bug-shishi@josefsson.org)
+.
+   2147483648      RESERVED.
+
+
+3.  Kerberos 5 STARTTLS Extension
+
+3.1  STARTTLS requested by client (extension 1)
+
+   When this message is sent by the client, the client is requesting the
+   server to start TLS negotiation on the TCP stream.  The client MUST
+   NOT start TLS negotiation immediately.  Instead, the client wait for
+   either a KRB-ERROR (sent normally, prefixed by a 4 octet length
+   integer) indicating the server do not understand the set high bit, or
+   4 octets which is to be interpreted as an integer in network byte
+   order, where the high bit is set and the remaining 31 bit are
+   interpreted as an integer specifying ``STARTTLS request accepted by
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 4]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+   server'' (extension 2).  In the first case, the client infer that the
+   server do not understand (or wish to support) STARTTLS, and can
+   re-try using normal TCP, if unprotected Kerberos 5 exchanges are
+   acceptable to the client policy.  In the latter case, it should
+   invoke TLS negotiation on the stream.  If any other data is received,
+   the client MUST close the TCP stream.
+
+3.2  STARTTLS request accepted by server (extension 2)
+
+   This message should be sent by the server when it has received the
+   extension 1 message.  The message is an acknowledgment of the
+   client's request to initiate STARTTLS on the channel.  The server
+   MUST then invoke a TLS negotiation.
+
+3.3  Proceeding after successful TLS negotiation
+
+   If the TLS negotiation ended successfully, possibly also considering
+   client or server policies, the exchange within the TLS protected
+   stream is performed like normal UDP Kerberos 5 exchanges, i.e., there
+   is no TCP 4 octet length field before each packet.  Instead each
+   Kerberos packet MUST be sent within one TLS record, so the
+   application can use the TLS record length as the Kerberos 5 packet
+   length.
+
+3.4  Proceeding after failed TLS negotiation
+
+   If the TLS negotiation fails, possibly due to client or server policy
+   (e.g., inadequate support of encryption types in TLS, or lack of
+   client or server authentication) the entity that detect the failure
+   MUST disconnected the connection.  It is expected that any error
+   messages that explain the error condition is transfered by TLS.
+
+3.5  STARTTLS aware KDC Discovery
+
+   Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS)
+   SRV records [3] can be used to find the address of an KDC.  To locate
+   a KDC that support the STARTTLS extension, we use the "_tls" domain.
+   For example:
+
+   _kerberos._tls._tcp.EXAMPLE.COM.   IN      SRV     0 0 88 kdc1.example.com.
+   _kerberos._tls._tcp.EXAMPLE.COM.   IN      SRV     1 0 88 kdc2.example.com.
+
+
+3.6  Initial Authentication via TLS
+
+   The server MAY consider the authentication performed by the TLS
+   exchange as sufficient to issue Kerberos 5 tickets to the client,
+   without requiring, e.g., pre-authentication.  However, it is not an
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 5]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+   error to require or use pre-authentication as well.
+
+   The client may also indicate that it wishes to use TLS both for
+   authentication and data protection by using the NULL encryption type
+   in its request.  The server can decide from its local policy whether
+   or not issuing tickets based solely on TLS authentication, and
+   whether NULL encryption within TLS, is acceptable or not.
+
+4.  Security Considerations
+
+   Because the initial token is not protected, it is possible for an
+   active attacker to make it appear to the client that the server do
+   not support this extension.  It is up to client configuration to
+   disallow non-TLS connections, if that vulnerability is deemed
+   unacceptable.  For interoperability, we suggest the default behaviour
+   should be to allow automatic fall back to TCP or UDP.
+
+   The security considerations of both TLS and Kerberos 5 are inherited.
+   Using TLS for authentication and/or data protection together with
+   Kerberos alter the authentication logic fundamentally.  Thus, it may
+   be that even if the TLS and Kerberos 5 protocols and implementations
+   were secure, the combination of TLS and Kerberos 5 described here
+   could be insecure.
+
+   No channel bindings are provided in the Kerberos messages.  It is an
+   open question whether, and how, this could be solved.  One idea for
+   solving this may be to specify a new encryption algorithm in Kerberos
+   5 that is similar to the NULL encryption algorithm, but also include
+   the TLS session identifier.
+
+5.  References
+
+5.1  Normative References
+
+   [1]  Neuman, C., "The Kerberos Network Authentication Service (V5)",
+        draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress),
+        September 2004.
+
+   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+        2246, January 1999.
+
+   [3]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+5.2  Informative References
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 6]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Taylor, D., "Using SRP for TLS Authentication",
+        draft-ietf-tls-srp-08 (work in progress), August 2004.
+
+   [6]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
+        authentication", draft-ietf-tls-openpgp-keys-05 (work in
+        progress), April 2004.
+
+
+Author's Address
+
+   Simon Josefsson
+
+   EMail: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 7]
+
+Internet-Draft         Using TLS with Kerberos 5           November 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set for
+th therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Josefsson                 Expires May 14, 2005                  [Page 8]
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt
new file mode 100644
index 00000000000..35a790dbb18
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                                       SJD
+Intended status: Standards Track                         October 4, 2006
+Expires: April 7, 2007
+
+
+   Using Kerberos V5 over the Transport Layer Security (TLS) protocol
+                 draft-josefsson-kerberos5-starttls-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 7, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 1]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+Abstract
+
+   This document specify how the Kerberos V5 protocol can be transported
+   over the Transport Layer Security (TLS) protocol, to provide
+   additional security features.
+
+
+Table of Contents
+
+   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
+   2.  Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . .  5
+   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 2]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+1.  Introduction and Background
+
+   This document describe how a Kerberos V5 [2] implementation may
+   upgrade communication between clients and Key Distribution Centers
+   (KDCs) to use the Transport Layer Security (TLS) [4] protocol.
+
+   The TLS protocol offer integrity and privacy protected exchanges that
+   can be authentication using X.509 certificates, OpenPGP keys [7], and
+   user name and passwords via SRP [6].
+
+   There are several reasons to use Kerberos V5 over TLS.
+
+   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
+      packets are transfered without privacy protection (i.e.,
+      encryption).  That part contains information, such as the client
+      principal name, the server principal name, the encryption types
+      supported by the client, the lifetime of tickets, etc.  Revealing
+      such information is, in some threat models, considered a problem.
+
+
+   o  Prevents downgrade attacks affecting encryption types.  The
+      encryption type of the ticket in KDC-REQ are sent in the clear in
+      Kerberos 5.  This allows an attacker to replace the encryption
+      type with a compromised mechanisms, e.g., 56-bit DES.  Since
+      clients in general cannot know the encryption types other servers
+      support, it is difficult for the client to detect if there was a
+      man-in-the-middle or if the remote server simply did not support a
+      stronger mechanism.  Clients could chose to refuse, e.g., 56-bit
+      DES altogether, but in some environments this leads to operational
+      difficulties.
+
+
+   o  Additional authentication against the KDC.  In some situations,
+      users are equipped with smart cards with a RSA authentication key.
+      In others, users have a OpenPGP client on their desktop, with a
+      public OpenPGP key known to the server.  In some situations, the
+      policy may be that password authentication may only be done
+      through SRP.
+
+
+   o  The TLS protocol has been studied by many parties.  In some threat
+      models, the designer prefer to reduce the number of protocols that
+      can hurt the overall system security if they are compromised.
+
+
+   o  Explicit server authentication of the KDC to the client.  In
+      traditional Kerberos 5, authentication of the KDC is proved as a
+      side effect that the KDC knows your encryption key (i.e., your
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 3]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+      password).
+
+   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 [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 4]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+2.  Kerberos V5 STARTTLS Extension
+
+   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
+   [3].  The extension uses bit #TBD in the extension bitmask.
+
+   The protocol is as follows.  After the server has sent the 4-octet
+   value 0x00000000 to indicate support of this extension, the stream
+   will be controlled by the TLS protocol and its framing.  The TLS
+   protocol is initiated by the client.
+
+   Typically, the client initiate the TLS handshake protocol by sending
+   a client hello, and the server responds, and the handshake continues
+   until it either succeed or fails.
+
+   If for any reason the handshake fails, the STARTTLS protocol will
+   also fail, and the TLS error is used as the error indication.
+
+   If the handshake succeeds, the Kerberos V5 authentication protocol is
+   performed within the protected TLS channel, like a normal TCP
+   Kerberos V5 exchange.  In particular, this means that every Kerberos
+   V5 packet will be prefixed by a 4-octet length field, that indicate
+   the length of the Kerberos V5 packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 5]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+3.  Examples
+
+   A complete packet flow for a successful AS-REQ/REP exchange protected
+   by this mechanism will be as follows.  The "STARTTLS-bit" is a
+   4-octet value with only the bit allocated for this extension set.
+
+       Client                                               Server
+
+        [ Kerberos V5 TCP extension mechanism negotiation starts ]
+
+       [0x70000000 & STARTTLS-bit]  -------->
+                                                       [0x00000000]
+                                    <--------
+
+                            [ TLS negotiation starts ]
+
+
+       ClientHello                  -------->
+                                                       ServerHello
+                                                      Certificate*
+                                                ServerKeyExchange*
+                                               CertificateRequest*
+                                    <--------      ServerHelloDone
+       Certificate*
+       ClientKeyExchange
+       CertificateVerify*
+       [ChangeCipherSpec]
+       Finished                     -------->
+                                                [ChangeCipherSpec]
+                                    <--------             Finished
+
+                       [ Kerberos V5 negotiation starts ]
+
+       Kerberos V5 AS-REQ           -------->
+                                                Kerberos V5 AS-REP
+                                    <--------
+
+       * Indicates optional or situation-dependent messages that are not
+         always sent.
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 6]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+4.  STARTTLS aware KDC Discovery
+
+   Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
+   (DNS) SRV records [5] can be used to find the address of an KDC.
+   Using the terminology of Section 7.2.3 of RFC 4120, we define a new
+   Proto of "tls" to indicate that the particular KDC is intended to
+   support this STARTTLS extension.  The Service, Realm, TTL, Class,
+   SRV, Priority, Weight, Port and Target have the same meaning as in
+   RFC 4120.
+
+   For example:
+
+   _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
+   _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 7]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+5.  IANA Considerations
+
+   The IANA is requested to allocate a bit in the "Kerberos TCP
+   Extensions" registry for the extension described in this document, as
+   per [3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 8]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+6.  Security Considerations
+
+   The security considerations in Kerberos V5, TLS, and the extension
+   mechanism framework are inherited.
+
+   To protect against the inherent downgrade attack in the extension
+   framework, it is suggested that implementations offer a policy to
+   require that this extension is successfully negotiated.  For
+   interoperability with implementations that do not support this
+   extension, it is suggested that the policy is disabled by default.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                 [Page 9]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)", RFC 4120, July 2005.
+
+   [3]  Josefsson, S., "Extended Kerberos Version 5 Key Distribution
+        Center (KDC) Exchanges Over  TCP",
+        draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
+        September 2006.
+
+   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+        Protocol Version 1.1", RFC 4346, April 2006.
+
+   [5]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+7.2.  Informative References
+
+   [6]  Taylor, D., "Using SRP for TLS Authentication",
+        draft-ietf-tls-srp-12 (work in progress), June 2006.
+
+   [7]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
+        authentication", draft-ietf-tls-openpgp-keys-10 (work in
+        progress), June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                [Page 10]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+Author's Address
+
+   Simon Josefsson
+   SJD
+
+   Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                [Page 11]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Josefsson                 Expires April 7, 2007                [Page 12]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt
new file mode 100644
index 00000000000..5793b705357
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                                       SJD
+Intended status: Standards Track                        October 21, 2006
+Expires: April 24, 2007
+
+
+   Using Kerberos V5 over the Transport Layer Security (TLS) protocol
+                 draft-josefsson-kerberos5-starttls-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 24, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 1]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+Abstract
+
+   This document specify how the Kerberos V5 protocol can be transported
+   over the Transport Layer Security (TLS) protocol, to provide
+   additional security features.
+
+
+Table of Contents
+
+   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
+   2.  Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . .  5
+   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 2]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+1.  Introduction and Background
+
+   This document describe how a Kerberos V5 [2] implementation may
+   upgrade communication between clients and Key Distribution Centers
+   (KDCs) to use the Transport Layer Security (TLS) [4] protocol.
+
+   The TLS protocol offer integrity and privacy protected exchanges that
+   can be authentication using X.509 certificates, OpenPGP keys [7], and
+   user name and passwords via SRP [6].
+
+   There are several reasons to use Kerberos V5 over TLS.
+
+   o  Prevents downgrade attacks affecting, e.g., encryption types and
+      pre-auth data negotiation.  The encryption type field in KDC-REQ,
+      and the METHOD-DATA field with the requested pre-auth types from
+      the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
+      without integrity or privacy protection in Kerberos 5.  This
+      allows an attacker to replace the encryption type with a
+      compromised encryption type, e.g., 56-bit DES, or request that
+      clients should use a broken pre-auth type.  Since clients in
+      general cannot know the encryption types other servers support, or
+      the pre-auth types servers prefer or require, it is difficult for
+      the client to detect if there was a man-in-the-middle or if the
+      remote server simply did not support a stronger encryption type or
+      preferred another pre-auth type.
+
+
+   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
+      packets are transfered without privacy protection (i.e.,
+      encryption).  That part contains information, such as the client
+      principal name, the server principal name, the encryption types
+      supported by the client, the lifetime of tickets, etc.  Revealing
+      such information is, in some threat models, considered a problem.
+
+
+   o  Additional authentication against the KDC.  In some situations,
+      users are equipped with smart cards with a RSA authentication key.
+      In others, users have a OpenPGP client on their desktop, with a
+      public OpenPGP key known to the server.
+
+   o  The TLS protocol has been studied by many parties.  In some threat
+      models, the designer prefer to reduce the number of protocols that
+      can hurt the overall system security if they are compromised.
+
+
+   o  Explicit server authentication of the KDC to the client.  In
+      traditional Kerberos 5, authentication of the KDC is proved as a
+      side effect that the KDC knows your encryption key (i.e., your
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 3]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+      password).
+
+   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 [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 4]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+2.  Kerberos V5 STARTTLS Extension
+
+   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
+   [3].  The extension uses bit #TBD in the extension bitmask.
+
+   The protocol is as follows.  After the server has sent the 4-octet
+   value 0x00000000 to indicate support of this extension, the stream
+   will be controlled by the TLS protocol and its framing.  The TLS
+   protocol is initiated by the client.
+
+   Typically, the client initiate the TLS handshake protocol by sending
+   a client hello, and the server responds, and the handshake continues
+   until it either succeed or fails.
+
+   If for any reason the handshake fails, the STARTTLS protocol will
+   also fail, and the TLS error is used as the error indication.
+
+   If the handshake succeeds, the Kerberos V5 authentication protocol is
+   performed within the protected TLS channel, like a normal TCP
+   Kerberos V5 exchange.  In particular, this means that every Kerberos
+   V5 packet will be prefixed by a 4-octet length field, that indicate
+   the length of the Kerberos V5 packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 5]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+3.  Examples
+
+   A complete packet flow for a successful AS-REQ/REP exchange protected
+   by this mechanism will be as follows.  The "STARTTLS-bit" is a
+   4-octet value with only the bit allocated for this extension set.
+
+       Client                                               Server
+
+        [ Kerberos V5 TCP extension mechanism negotiation starts ]
+
+       [0x70000000 & STARTTLS-bit]  -------->
+                                                       [0x00000000]
+                                    <--------
+
+                            [ TLS negotiation starts ]
+
+
+       ClientHello                  -------->
+                                                       ServerHello
+                                                      Certificate*
+                                                ServerKeyExchange*
+                                               CertificateRequest*
+                                    <--------      ServerHelloDone
+       Certificate*
+       ClientKeyExchange
+       CertificateVerify*
+       [ChangeCipherSpec]
+       Finished                     -------->
+                                                [ChangeCipherSpec]
+                                    <--------             Finished
+
+                       [ Kerberos V5 negotiation starts ]
+
+       4 octet length field
+       Kerberos V5 AS-REQ           -------->
+                                                4 octet length field
+                                                Kerberos V5 AS-REP
+                                    <--------
+
+       * Indicates optional or situation-dependent messages that are not
+         always sent.
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 6]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+4.  STARTTLS aware KDC Discovery
+
+   Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
+   (DNS) SRV records [5] can be used to find the address of an KDC.
+   Using the terminology of Section 7.2.3 of RFC 4120, we define a new
+   Proto of "tls" to indicate that the particular KDC is intended to
+   support this STARTTLS extension.  The Service, Realm, TTL, Class,
+   SRV, Priority, Weight, Port and Target have the same meaning as in
+   RFC 4120.
+
+   For example:
+
+   _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
+   _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 7]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+5.  IANA Considerations
+
+   The IANA is requested to allocate a bit in the "Kerberos TCP
+   Extensions" registry for the extension described in this document, as
+   per [3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 8]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+6.  Security Considerations
+
+   The security considerations in Kerberos V5, TLS, and the extension
+   mechanism framework are inherited.
+
+   To protect against the inherent downgrade attack in the extension
+   framework, it is suggested that implementations offer a policy to
+   require that this extension is successfully negotiated.  For
+   interoperability with implementations that do not support this
+   extension, it is suggested that the policy is disabled by default.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                 [Page 9]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)", RFC 4120, July 2005.
+
+   [3]  Josefsson, S., "Extended Kerberos Version 5 Key Distribution
+        Center (KDC) Exchanges Over TCP",
+        draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
+        September 2006.
+
+   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+        Protocol Version 1.1", RFC 4346, April 2006.
+
+   [5]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+7.2.  Informative References
+
+   [6]  Taylor, D., "Using SRP for TLS Authentication",
+        draft-ietf-tls-srp-12 (work in progress), June 2006.
+
+   [7]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
+        authentication", draft-ietf-tls-openpgp-keys-10 (work in
+        progress), June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                [Page 10]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+Author's Address
+
+   Simon Josefsson
+   SJD
+
+   Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires April 24, 2007                [Page 11]
+
+Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Josefsson                Expires April 24, 2007                [Page 12]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-07.txt b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-07.txt
new file mode 100644
index 00000000000..e8b2d1788c6
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-josefsson-kerberos5-starttls-07.txt
@@ -0,0 +1,784 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                                    SJD AB
+Intended status: Informational                             July 31, 2009
+Expires: February 1, 2010
+
+
+   Using Kerberos V5 over the Transport Layer Security (TLS) protocol
+                 draft-josefsson-kerberos5-starttls-07
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.  This document may contain material
+   from IETF Documents or IETF Contributions published or made publicly
+   available before November 10, 2008.  The person(s) controlling the
+   copyright in some of this material may not have granted the IETF
+   Trust the right to allow modifications of such material outside the
+   IETF Standards Process.  Without obtaining an adequate license from
+   the person(s) controlling the copyright in such materials, this
+   document may not be modified outside the IETF Standards Process, and
+   derivative works of it may not be created outside the IETF Standards
+   Process, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+   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 Internet-Draft will expire on February 1, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+
+
+
+Josefsson               Expires February 1, 2010                [Page 1]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 2]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+Abstract
+
+   This document specify how the Kerberos V5 protocol can be transported
+   over the Transport Layer Security (TLS) protocol, to provide
+   additional security features.
+
+
+Table of Contents
+
+   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  4
+   2.  Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . .  6
+   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . .  8
+   5.  Server Certificates  . . . . . . . . . . . . . . . . . . . . .  9
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 3]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+1.  Introduction and Background
+
+   This document describe how a Kerberos V5 [RFC4120] implementation may
+   upgrade communication between clients and Key Distribution Centers
+   (KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol.
+
+   The TLS protocol offer integrity and privacy protected exchanges that
+   can be authentication using X.509 certificates, OpenPGP keys
+   [RFC5081], and user name and passwords via SRP [RFC5054].
+
+   There are several reasons to use Kerberos V5 over TLS.
+
+   o  Prevents downgrade attacks affecting, e.g., encryption types and
+      pre-auth data negotiation.  The encryption type field in KDC-REQ,
+      and the METHOD-DATA field with the requested pre-auth types from
+      the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
+      without integrity or privacy protection in Kerberos 5.  This
+      allows an active attacker to replace the encryption type with a
+      compromised encryption type, e.g., 56-bit DES, or request that
+      clients should use a broken pre-auth type.  Since clients in
+      general cannot know the encryption types other servers support, or
+      the pre-auth types servers prefer or require, it is difficult for
+      the client to detect if there was a man-in-the-middle or if the
+      remote server simply did not support a stronger encryption type or
+      preferred another pre-auth type.
+
+   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
+      packets are transferred without privacy protection (i.e.,
+      encryption).  That part contains information, such as the client
+      principal name, the server principal name, the encryption types
+      supported by the client, the lifetime of tickets, etc.  Revealing
+      such information is, in some threat models, considered a problem.
+
+   o  Additional authentication against the KDC.  In some situations,
+      users are equipped with smart cards with a RSA authentication key.
+      In others, users have a OpenPGP client on their desktop, with a
+      public OpenPGP key known to the server.
+
+   o  The TLS protocol has been studied by many parties.  In some threat
+      models, the designer prefer to reduce the number of protocols that
+      can hurt the overall system security if they are compromised.
+
+   o  Explicit server authentication of the KDC to the client.  In
+      traditional Kerberos 5, authentication of the KDC is proved as a
+      side effect that the KDC knows your encryption key (i.e., your
+      password).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+
+
+
+Josefsson               Expires February 1, 2010                [Page 4]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 5]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+2.  Kerberos V5 STARTTLS Extension
+
+   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
+   [RFC5021].  The extension uses bit #TBD in the extension bitmask.
+
+   The protocol is as follows.  After the server has sent the 4-octet
+   value 0x00000000 to indicate support of this extension, the stream
+   will be controlled by the TLS protocol and its framing.  The TLS
+   protocol is initiated by the client.
+
+   Typically, the client initiate the TLS handshake protocol by sending
+   a client hello, and the server responds, and the handshake continues
+   until it either succeed or fails.
+
+   If for any reason the handshake fails, the STARTTLS protocol will
+   also fail, and the TLS error is used as the error indication.  In
+   this case, no further messages can be exchanged over the same TCP
+   session.
+
+   If the handshake succeeds, the Kerberos V5 authentication protocol is
+   performed within the protected TLS channel, like a normal TCP
+   Kerberos V5 exchange.  In particular, this means that every Kerberos
+   V5 packet will be prefixed by a 4-octet length field, that indicate
+   the length of the Kerberos V5 packet.
+
+   When no further Kerberos V5 messages needs to be transferred in the
+   TLS session, the TLS session MUST be shut down properly using the
+   close_notify alert.  When the TLS session is shut down, the TCP
+   connection cannot be re-used to send any further data and MUST be
+   closed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 6]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+3.  Examples
+
+   A complete packet flow for a successful AS-REQ/REP exchange protected
+   by this mechanism will be as follows.  The "STARTTLS-bit" is a
+   4-octet value with only the bit allocated for this extension set.
+
+       Client                                               Server
+
+        [ Kerberos V5 TCP extension mechanism negotiation starts ]
+
+       [0x70000000 & STARTTLS-bit]  -------->
+                                                       [0x00000000]
+                                    <--------
+
+                            [ TLS negotiation starts ]
+
+
+       ClientHello                  -------->
+                                                       ServerHello
+                                                      Certificate*
+                                                ServerKeyExchange*
+                                               CertificateRequest*
+                                    <--------      ServerHelloDone
+       Certificate*
+       ClientKeyExchange
+       CertificateVerify*
+       [ChangeCipherSpec]
+       Finished                     -------->
+                                                [ChangeCipherSpec]
+                                    <--------             Finished
+
+                       [ Kerberos V5 negotiation starts ]
+
+       4 octet length field
+       Kerberos V5 AS-REQ           -------->
+                                                4 octet length field
+                                                Kerberos V5 AS-REP
+                                    <--------
+
+       * Indicates optional or situation-dependent messages that are not
+         always sent.
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 7]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+4.  STARTTLS aware KDC Discovery
+
+   Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name
+   System (DNS) SRV records [RFC2782] can be used to find the address of
+   an KDC.  We define a new Proto of "tls" to indicate that the
+   particular KDC is intended to support this STARTTLS extension.  The
+   Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target
+   have the same meaning as in RFC 4120.
+
+   For example:
+
+   _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
+   _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 8]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+5.  Server Certificates
+
+   The TLS protocol may be used in a mode that provides server
+   authentication using, for example, X.509 and OpenPGP.
+
+   The Kerberos V5 STARTTLS protocol do not require clients to verify
+   the server certificate.  The goal is that support for TLS in Kerberos
+   V5 clients should be as easy to implement and deploy as support for
+   UDP/TCP.  Use of TLS, even without server certificate validation,
+   protects against some attacks that Kerberos V5 over UDP/TCP do not.
+   Requiring server certificates to be used at all times would enable
+   attacks in those situations.
+
+   Many client environments do not have secure long-term storage, which
+   is required to validate certificates.  This makes it impossible to
+   use server certificate validation on a large number of client
+   systems.
+
+   When clients have the ability, they need to be able to validate the
+   server certificate.  For this reason, if a KDC presents a X.509
+   server certificate over TLS, it MUST contain an otherName Subject
+   Alternative Name (SAN) identified using a type-id of id-krb5starttls-
+   san.  The intention is to bind the server certificate to the Kerberos
+   realm for the purpose of using Kerberos V5 STARTTLS.  The value field
+   of the otherName should contain the realm as the "Realm" ASN.1 type.
+
+          id-krb5starttls-san OBJECT IDENTIFIER ::=
+            { iso(1) identified-organization(3) dod(6) internet(1)
+              private(4) enterprise(1) gnu(11591)
+              shishi(6) krb5starttls-san(1) }
+
+   To validate a server certificate, the client MAY use local
+   configuration (e.g., a list that map realm names to a copy of the
+   server's certificate) and compare that with the authentication
+   information provided from the server via TLS.  For illustration, the
+   server certificate could be a X.509 certificate or an OpenPGP key.
+   In this mode, the client need no processing related to id-
+   krb5starttls-san.
+
+   When the server presents a X.509 server certificate, clients MAY use
+   "Certification Path Validation" as described in [RFC5280] to validate
+   the KDC server certificate.  In addition, unless the client can
+   otherwise verify that the server certificate is bound to the KDC of
+   the target realm, the client MUST verify that the server certificate
+   contains the id-krb5starttls-san SAN and that the value is identical
+   to the intended Kerberos realm.
+
+
+
+
+
+Josefsson               Expires February 1, 2010                [Page 9]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+6.  IANA Considerations
+
+   The IANA is requested to allocate a bit in the "Kerberos TCP
+   Extensions" registry for the extension described in this document, as
+   per [RFC5021].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010               [Page 10]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+7.  Acknowledgements
+
+   Jeffrey Hutzelman and Sam Hartman provided comments that improved the
+   protocol and document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010               [Page 11]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+8.  Security Considerations
+
+   The security considerations in Kerberos V5, TLS, and the Kerberos V5
+   TCP extension mechanism are inherited.
+
+   Note that TLS does not protect against Man-In-The-Middle (MITM)
+   attacks unless clients verify the KDC's credentials (X.509
+   certificate, OpenPGP key, etc) correctly.
+
+   If server authentication is used, some information about the server
+   (such as its name) is visible to passive attackers.
+
+   To protect against the inherent downgrade attack in the extension
+   framework, implementations SHOULD offer a policy mode that requires
+   this extension to always be successfully negotiated, for a particular
+   realm, or generally.  For interoperability with implementations that
+   do not support this extension, the policy mode SHOULD be disabled by
+   default.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010               [Page 12]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5021]  Josefsson, S., "Extended Kerberos Version 5 Key
+              Distribution Center (KDC) Exchanges over TCP", RFC 5021,
+              August 2007.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+9.2.  Informative References
+
+   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
+              "Using the Secure Remote Password (SRP) Protocol for TLS
+              Authentication", RFC 5054, November 2007.
+
+   [RFC5081]  Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
+              Layer Security (TLS) Authentication", RFC 5081,
+              November 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010               [Page 13]
+
+Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
+
+
+Author's Address
+
+   Simon Josefsson
+   Simon Josefsson Datakonsult AB
+   Hagagatan 24
+   Stockholm  113 47
+   Sweden
+
+   Email: simon@josefsson.org
+   URI:   http://josefsson.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires February 1, 2010               [Page 14]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt b/third_party/heimdal/doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt
new file mode 100644
index 00000000000..3225b10d937
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt
@@ -0,0 +1,392 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                                       SJD
+Updates: 4120 (if approved)                               April 23, 2006
+Expires: October 25, 2006
+
+
+Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
+                                  TCP
+                  draft-josefsson-krb-tcp-expansion-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on October 25, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes an extensibility mechanism for the Kerberos
+   v5 protocol when used over TCP transports.
+
+
+
+
+
+
+
+
+Josefsson               Expires October 25, 2006                [Page 1]
+
+Internet-Draft          Kerberos V5 TCP extension             April 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
+   3.  Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
+   4.  Interoperability Consideration  . . . . . . . . . . . . . . . . 4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+   Appendix A.  Copying conditions . . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires October 25, 2006                [Page 2]
+
+Internet-Draft          Kerberos V5 TCP extension             April 2006
+
+
+1.  Introduction
+
+   The Kerberos 5 [3] specification, in section 7.2.2, reserve the high
+   order bit in the initial length field for TCP transport for future
+   expansion.  This document update [3] to describe the behaviour when
+   that bit is set.  This mechanism is intended for extensions that are
+   specific for the TCP transport.
+
+
+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 [1].
+
+
+3.  Extension Mechanism for TCP transport
+
+   The reserved high bit of the request length field is used to signal
+   the use of this extension mechanism.  When the reserved high bit is
+   set, the remaining 31 bits of the initial 4 octets are interpreted as
+   a bitmap.  Each bit in the bitmask can be used to request a
+   particular extension.  The 31 bits form the "extension bitmask".  It
+   is expected that other documents will describe the details associated
+   with particular bits.
+
+   A 4-octet value with only the high bit set, and thus the extension
+   bitmask all zeros, is called a PROBE.  A client may send a probe to
+   find out which extensions a KDC support.  A client may also set
+   particular bits in the extension bitmask directly, if it does not
+   need to query the KDC for available extensions before deciding which
+   extension to request.
+
+   If a KDC receive a PROBE, or if a KDC does not support all extensions
+   corresponding to set bits in the extension bitmask, the KDC MUST
+   return 4 octets with the high bit set, and with the remaining bitmask
+   indicate which extensions it supports.  The KDC MUST NOT close the
+   connection, and MUST wait for the client to then send a second
+   4-octet value, with the high bit set and the remaining bits as the
+   bitmask, to request a particular extension.  If the second 4-octet
+   value is a PROBE or an unsupported extension, the KDC MUST close the
+   connection.  This is used by the client to shutdown a session when
+   the KDC did not support a, by the client, required extension.
+
+   The behaviour when more than one non-high bit is set depends on the
+   particular extension mechanisms.  If a requested extension (bit X)
+   does not specify how it interact with another requested extensions
+   (bit Y), the KDC MUST treat the request as a PROBE or unsupported
+
+
+
+Josefsson               Expires October 25, 2006                [Page 3]
+
+Internet-Draft          Kerberos V5 TCP extension             April 2006
+
+
+   extension, and proceed as above.
+
+   Each extension MUST describe the structure of protocol data beyond
+   the length field, and the behaviour of the client and KDC.  If an
+   extension mechanism reserve multiple bits, it MUST describe how they
+   interact.
+
+
+4.  Interoperability Consideration
+
+   Implementations with support for TCP that do not claim to conform to
+   RFC 4120 may not handle the high bit correctly.  Behaviour may
+   include closing the TCP connection without any response, and logging
+   an error message in the KDC log.  When this was written, this problem
+   existed in modern versions of popular implementations.
+   Implementations experiencing trouble getting the expected responses
+   from a server SHOULD assume that it does not support this extension
+   mechanism.  Clients MAY remember this semi-permanently, to avoid
+   excessive logging in the server.  Care should be taken to avoid
+   unexpected behaviour for the user when the KDC is eventually
+   upgraded.  How to handle these backwards compatibility quirks are in
+   general left unspecified.
+
+
+5.  Security Considerations
+
+   Because the initial length field is not protected, it is possible for
+   an active attacker (i.e., one that is able to modify traffic between
+   the client and the KDC) to make it appear to the client that the
+   server does not support this extension mechanism.  Client and KDC
+   policies can be used to reject connections that does not use any
+   expansion.
+
+
+6.  IANA Considerations
+
+   IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
+   The initial contents of this registry should be:
+
+   [[RFC Editor: Replace xxxx below with the number of this RFC.]]
+
+   Bit #         Meaning                             Reference
+   -----         -------                             ---------
+   0..29         AVAILABLE for registration.
+   30            RESERVED.                           RFC XXXX
+
+   IANA will register values 0 to 29 after IESG Approval, as defined in
+   BCP 64 [2].  Assigning value 30 requires a Standards Action.
+
+
+
+Josefsson               Expires October 25, 2006                [Page 4]
+
+Internet-Draft          Kerberos V5 TCP extension             April 2006
+
+
+7.  Acknowledgements
+
+   Thanks to Andrew Bartlett who pointed out that some implementations
+   (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
+   regards to the high bit, which resulted in an Interoperability
+   Consideration.
+
+   Nicolas Williams and Jeffrey Hutzelman provided comments that
+   improved the document.
+
+8.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
+        Network Authentication Service (V5)", RFC 4120, July 2005.
+
+
+Appendix A.  Copying conditions
+
+   Regarding this entire document or any portion of it, the author makes
+   no guarantees and is not responsible for any damage resulting from
+   its use.  The author grants irrevocable permission to anyone to use,
+   modify, and distribute it in any way that does not diminish the
+   rights of anyone else to use, modify, and distribute it, provided
+   that redistributed derivative works do not contain misleading author
+   or version information.  Derivative works need not be licensed under
+   similar terms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires October 25, 2006                [Page 5]
+
+Internet-Draft          Kerberos V5 TCP extension             April 2006
+
+
+Author's Address
+
+   Simon Josefsson
+   SJD
+
+   Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson               Expires October 25, 2006                [Page 6]
+
+Internet-Draft          Kerberos V5 TCP extension             April 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Josefsson               Expires October 25, 2006                [Page 7]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt b/third_party/heimdal/doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt
new file mode 100644
index 00000000000..4f527d61f95
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt
@@ -0,0 +1,1120 @@
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                          February 2, 2003
+Expires: August 3, 2003
+
+
+                      A Kerberos 5 SASL Mechanism
+                   draft-josefsson-sasl-kerberos5-01
+
+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 Internet-Draft will expire on August 3, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document specifies a Simple Authentication and Security Layer
+   (SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1],
+   with optional initial Authentication Service (AS) and/or
+   Ticket-Granting-Service (TGS) exchanges.
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 1]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Document Changes . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Kerberos Version 5 Mechanism . . . . . . . . . . . . . . . . .  3
+   4.  Theory Of Operation  . . . . . . . . . . . . . . . . . . . . .  6
+   4.1 Infrastructure Mode  . . . . . . . . . . . . . . . . . . . . .  6
+   4.2 Proxied Infrastructure Mode  . . . . . . . . . . . . . . . . .  6
+   4.3 Non-Infrastructure Mode  . . . . . . . . . . . . . . . . . . .  7
+   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
+       Normative References . . . . . . . . . . . . . . . . . . . . . 17
+       Informative References . . . . . . . . . . . . . . . . . . . . 17
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
+       Intellectual Property and Copyright Statements . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 2]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+1. Introduction
+
+   Kerberos 5 provides client and optional server authentication,
+   usually employing symmetric encryption and a trusted (symmetric) key
+   distribution center.  Specifying Kerberos 5 authentication for each
+   network protocol where there is a need to use Kerberos 5 is a tedious
+   task.  However, as many protocols already specify support for the
+   SASL framework, by specifying a Kerberos 5 SASL mechanism, support
+   for Kerberos 5 in many protocols is accomplished.  Even for protocols
+   that do not support SASL, specifying SASL support (and thereby
+   implicitly Kerberos 5) is often advantageous over specifying Kerberos
+   5 support directly.  The advantages include better flexibility if or
+   when new Kerberos versions are released, and perhaps more commonly,
+   when circumstances demand that other authentication methods
+   (supported by SASL) should be used.
+
+   It should be mentioned that Kerberos 5 authentication via SASL is
+   already possible, by using the Generic Security Service Application
+   Program Interface [6] framework.  However, GSSAPI adds some amount of
+   overhead, both in terms of code complexity, code size and additional
+   network round trips.  More importantly, GSSAPI do not support the
+   authentication steps (AS and TGS).  These are some of the motivation
+   behind this "slimmer" Kerberos 5 SASL mechanism.
+
+2. Document Changes
+
+   Modification since -00:
+
+   * The way data is encoded in the
+     AP-REQ.Authenticator.authorization-data field is corrected and
+     elaborated.
+
+   * The incorrect sentence about including application data in the
+     AP-REP is removed.
+
+   * The "Theory of operation" section now includes three modes;
+     Infrastructure, Proxied Infrastructure, and Non-Infrastructure
+     modes.
+
+   * The example section now contains a complete dump from an
+     implementation.
+
+
+3. Kerberos Version 5 Mechanism
+
+   The mechanism name associated with Kerberos version 5 is
+   "KERBEROS_V5".  The exchange consists of one initial server packet
+   (containing some parameters and a challenge, described below), and
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 3]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   then an unfixed number of messages containing Kerberos 5 packets,
+   with the last exchange being an AP-REQ, and optional AP-REP, for the
+   desired SASL service on a format described below.
+
+   The normal packet exchange, after the required initial server packet,
+   are one optional AS-REQ and AS-REP exchange, one optional TGS-REQ and
+   TGS-REP exchange and then the AP-REQ packet and optional AP-REP
+   reply.  The only steps that are required by this SASL mechanism is
+   the initial server packet and the final AP-REQ and optional AP-REP
+   exchange.  The AP-REP is sent when and only when mutual
+   authentication is required.  The AP-REQ is for the SASL service that
+   is requested.  The AP-REQ must contain authenticated application data
+   on a format described below.  The AS and TGS exchanges is usually
+   used by clients to acquire the proper tickets required for the AP
+   phase.  It is not expected that any other Kerberos 5 packets will be
+   exchanged, but this mechanism do not disallow such packets in order
+   to make it possible to use this SASL mechanism with future Kerberos
+   extensions.
+
+   As discussed above, the client is allowed to send any valid Kerberos
+   5 message and the server should handle any message, subject to local
+   policy restrictions.  If the server do not understand the meaning of
+   a packet or do not wish to respond to it (e.g., it cannot proxy a
+   TGS-REQ), it SHOULD respond with a empty response and await further
+   packets.  Reasons for aborting the authentication phase instead of
+   sending an empty response includes if the number of received packets
+   exceeds a pre-defined limit.  AS-REQ and TGS-REQ packets destined for
+   non-local Kerberos Key Distribution Centers (KDCs) is proxied to the
+   correct server by the SASL server.  No provisions are made in the
+   protocol to allow the client to specify the addresses of the KDCs,
+   instead the SASL server is required to discover this information
+   (usually by static configuration or by using DNS).  It is legitimate
+   for the SASL server to abort the authentication phase with an error
+   saying that the indicated realm was not found or is restricted by
+   policy (i.e., a policy that only permits local KDC requests is
+   permitted).
+
+   Since it is expected that clients may not yet have IP addresses when
+   they invoke this SASL mechanism (invoking this mechanism may be one
+   step in acquiring an IP address), clients commonly leave the address
+   fields in the AS-REQ empty.
+
+   The initial server packet should contain one octet containing a bit
+   mask of supported security layers, four octets indicating the maximum
+   cipher-text buffer size the server is able to receive (or 0 if no
+   security layers are supported) in network byte order, and then 16
+   octets containing random data (see [4] on how random data might be
+   generated).
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 4]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   The last exchange must be an AP-REQ for the desired SASL service,
+   optionally followed by an AP-REP.  The SASL service is translated
+   into a Kerberos principal and realm as follows: The first element of
+   the principal is the service name specified in the protocol that uses
+   SASL.  The second element is the address of the SASL server, usually
+   expressed as a hostname.  The SASL realm should be the Kerberos realm
+   of the server.  The checksum value in the "cksum" field in the
+   Authenticator in the AP-REQ is computed on a string where the first
+   octet indicate the desired security layer requested by the client (a
+   bitmask with one bit set, which must also be set in the security
+   layer bitmask offered by the server), the next four octets indicate
+   the maximum cipher-text buffer size the client is able to receive in
+   network byte order (or 0 if a security layer is not indicated by the
+   first octet), followed by the entire initial server packet, in turn
+   followed by the desired authorization identity (which can be empty to
+   indicate that the authorization identity should be the same as the
+   authentication identity in the Kerberos ticket stored in the AP-REQ).
+   This same string is also to be included in the authorization-data
+   field of the Authenticator, with an ad-type of -1.
+
+   Upon decrypting and verifying the ticket and authenticator (i.e.,
+   standard AP-REQ processing), the server extracts the
+   authorization-data value from the Authenticator and checks that the
+   checksum in the authenticator is correct.  It then proceeds to check
+   that the server security layer bit mask, server maximum cipher-text
+   buffer size, and the random data equals the data provided in the
+   initial server challenge.  The server verify that the client selected
+   a security layer that was offered, and that the client maximum buffer
+   is 0 if no security layer was chosen.  The server must also verify
+   that the principal identified in the Kerberos ticket is authorized to
+   connect to the service as the authorization identity specified by the
+   client (or, if absent, the username denoted by the ticket principal).
+   Unless the client requested mutual authentication, the authentication
+   process is complete.
+
+   If the client requested mutual authentication, the server constructs
+   an AP-REP according to Kerberos 5.
+
+   The security layers and their corresponding bit-masks are as follows:
+
+         Bit 0 No security layer
+         Bit 1 Integrity (KRB-SAFE) protection
+         Bit 2 Privacy (KRB-PRIV) protection
+         Bit 3 Mutual authentication is required (AP option MUTUAL-
+               REQUIRED must also be present).
+
+   Other bit-masks may be defined in the future; bits which are not
+   understood must be negotiated off.
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 5]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+4. Theory Of Operation
+
+   This section describes, for illustration only, three common scenarios
+   where this mechanism can be used.
+
+4.1 Infrastructure Mode
+
+   Normally a SASL server is an application server such as a mail
+   system.  The server is configured to belong to at least one Kerberos
+   5 realm, and the server shares a symmetric key with the Kerberos 5
+   Key Distribution Center in that realm.  The server cannot perform the
+   initial Kerberos AS and TGS operation itself, but a KDC is needed for
+   that operation.  Once the user acquired credentials the server is
+   able to carry out the AP-REQ/AP-REP phase using its symmetric key.
+   The steps are as follows:
+
+   0) Server sends initial token.
+
+   * Client acquires a ticket for the server using an out-of-band request
+     to the KDC. Client generates the AP-REQ using the ticket for the
+     server.
+
+   1) Client sends AP-REQ to the server.
+
+   * Server parses AP-REQ, and if required the AP-REP is generated.
+
+   2) [Optional] Server sends AP-REP to the client.
+
+   * [Optional] Client parses AP-REP.
+
+   As can be seen, round-trip wise this is optimal, possibly bar the
+   initial token, although in IMAP it does not cause an additional
+   round-trip, and other protocols may be similar.
+
+4.2 Proxied Infrastructure Mode
+
+   If the client for some reason cannot carry out the communication with
+   the KDC itself, or for some other reason the server is in a better
+   position than the client to communicate with the KDC, the server can
+   proxy that part of the exchange via the server using the SASL
+   framework.  The server effectively acts as a proxy.  Note that the
+   packets that are sent are identical to those in the first example,
+   they are only routed differently.  The steps are as follows:
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 6]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   0) Server sends initial token.
+
+   * Client constructs AS-REQ using username and realm supplied by user,
+     in order to acquire a ticket granting ticket.
+
+   1) Client sends AS-REQ to server.
+
+   * Server finds address of KDC and forwards the AS-REQ to and waits for
+     the AS-REP response from the KDC.
+
+   2) Server sends AS-REP to client.
+
+   * Client parses AS-REP and constructs a TGS-REQ using the ticket
+     granting ticket encryption key, in order to acquire a ticket for the
+     server.
+
+   3) Client sends TGS-REQ to server.
+
+   * Server finds address of KDC and forwards the TGS-REQ to and waits
+     for the TGS-REP response from the KDC.
+
+   4) Server sends TGS-REP to client.
+
+   * Client parses TGS-REP and generates the AP-REQ using the session
+     encryption key.
+
+   5) Client sends AP-REQ to server.
+
+   * Server parses AP-REQ and if required the AP-REP is generated.
+
+   6) [Optional] Server sends AP-REP.
+
+   * [Optional] Client parses AP-REP.
+
+   If efficiency as a concern, and the client have no other use of a
+   ticket granting ticket for the realm, step 3 and 4 can be skipped by
+   asking for a ticket for the server directly in the AS-REQ.
+
+   Note that the client in subsequent connections may try to re-use the
+   ticket negotiated if it is still valid.
+
+4.3 Non-Infrastructure Mode
+
+   Kerberos 5 is usually a distributed security system, but we wish to
+   point out that this Kerberos 5 SASL mechanism may be used in a
+   standalone SASL server to provide the security advantages that the
+   Kerberos 5 Authentication Service (AS) provides over other methods.
+
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 7]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   Specifically, the SASL server may use a legacy password database such
+   as a CRAM-MD5 clear text password file to generate Kerberos 5
+   principals "on the fly".  Authentication may thus proceed as follows:
+
+   0) Server sends initial token.
+
+   * Client constructs AS-REQ using username supplied by user, in order
+     to acquire a ticket for the server directly.  The realm can be
+     predetermined by administrators, or simply the hostname of the
+     server.
+
+   1) Client sends AS-REQ to server.
+
+   * Server parses AS-REQ and generates AS-REP based on password in
+     database. The AS-REQ embeds a ticket for the server.
+
+   2) Server sends AS-REP to client.
+
+   * Client parses AS-REP and extracts the ticket and generates an AP-REQ
+     using the session encryption key.
+
+   3) Client sends AP-REQ to server.
+
+   * Server parses AP-REQ and if required, generates the AP-REP.
+
+   4) [Optional] Server sends AP-REP to client.
+
+   * [Optional] Client parses AP-REP.
+
+   This may be extended further, i.e.  by using the password and
+   Kerberos 5 pre-authentication in step 1.
+
+   Note that the client in subsequent connections may try to re-use the
+   ticket negotiated if it is still valid.
+
+5. Example
+
+   The following is one Kerberos version 5 login scenario for the IMAP4
+   protocol, in the non-infrastructure mode.  Note that the line breaks
+   are for editorial clarity.
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 8]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+        S: * OK IMAP4rev1 server
+        C: . AUTHENTICATE KERBEROS_V5
+        S: + CQAAAADp6+ONC2vcprRbmH2J95Gh
+        C: an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzog
+           sbCWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8y
+           MDAzMDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM=
+        S: + a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUb
+           A2phc6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBG
+           ltYXAbCWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3
+           f2w6y+bA56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68
+           TcsiMh8y9KbWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zT
+           L/NbcoIJq2ynCS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/
+           y0TaaBtTCBsqADAgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ7
+           52eFj1tUpU3qT1NGgfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPn
+           MCx2VDGyOu4Uv4PUsw4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnu
+           O7v7gTO+MGxzNvhVgMlujT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJ
+           c=
+        C: boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG
+           9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMC
+           ARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAl
+           UUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJ
+           sGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oG
+           flhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSB
+           qjE+doGGFMaz8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L
+           62PLsanqpow5bxAUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJ
+           OOwKJp/ZftZOkSdTHBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPG
+           Hu126PTyjXs3EziFqf6HT9Da/NJnDClFL8+nnlVFVt
+        S: + b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOW
+           IouXfHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6
+           rFt/ytas4U0g==
+        C:
+        S: . OK AUTHENTICATE KERBEROS_V5 authentication successful
+
+   The service requested is "imap/localhost" in the realm "localhost".
+   The password used was "foo", yielding an aes256-cts-hmac-sha1-96
+   encryption key of
+   0x6aefbaf05423cbc0fb44a41cc221783d7f52b764cca41fe2a05ad6d3bc7a67ea.
+
+   The first packet specify that mutual authentication and no integrity
+   or privacy layer (hence a zero maximum buffer size) and some random
+   data.
+
+   The second packet contains the AS-REQ, expanded as follows:
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                 [Page 9]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   name:KDC-REQ  type:SEQUENCE
+     name:pvno  type:INTEGER  value:0x05
+     name:msg-type  type:INTEGER  value:0x0a
+     name:req-body  type:SEQUENCE
+       name:kdc-options  type:BIT_STR  value(32):00000000
+       name:cname  type:SEQUENCE
+         name:name-type  type:INTEGER  value:0x00
+         name:name-string  type:SEQ_OF
+           name:NULL  type:GENERALSTRING
+           name:?1  type:GENERALSTRING  value:6a6173
+       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
+       name:sname  type:SEQUENCE
+         name:name-type  type:INTEGER  value:0x00
+         name:name-string  type:SEQ_OF
+           name:NULL  type:GENERALSTRING
+           name:?1  type:GENERALSTRING  value:696d6170
+           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
+       name:till  type:TIME  value:20030202164143Z
+       name:nonce  type:INTEGER  value:0x5406d89f
+       name:etype  type:SEQ_OF
+         name:NULL  type:INTEGER
+         name:?1  type:INTEGER  value:0x11
+         name:?2  type:INTEGER  value:0x10
+         name:?3  type:INTEGER  value:0x03
+   -----BEGIN SHISHI KDC-REQ-----
+   an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzogsb
+   CWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8yMDAz
+   MDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM=
+   -----END SHISHI KDC-REQ-----
+
+   The third packet contains the AS-REP, expanded as follows:
+
+   name:KDC-REP  type:SEQUENCE
+     name:pvno  type:INTEGER  value:0x05
+     name:msg-type  type:INTEGER  value:0x0b
+     name:crealm  type:GENERALSTRING  value:6c6f63616c686f7374
+     name:cname  type:SEQUENCE
+       name:name-type  type:INTEGER  value:0x00
+       name:name-string  type:SEQ_OF
+         name:NULL  type:GENERALSTRING
+         name:?1  type:GENERALSTRING  value:6a6173
+     name:ticket  type:SEQUENCE
+       name:tkt-vno  type:INTEGER  value:0x05
+       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
+       name:sname  type:SEQUENCE
+         name:name-type  type:INTEGER  value:0x01
+         name:name-string  type:SEQ_OF
+           name:NULL  type:GENERALSTRING
+
+
+
+Josefsson                Expires August 3, 2003                [Page 10]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+           name:?1  type:GENERALSTRING  value:696d6170
+           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
+       name:enc-part  type:SEQUENCE
+         name:etype  type:INTEGER  value:0x12
+         name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377
+         f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214
+         e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8
+         7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7
+         28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716
+         b0681de8ebe941f054a77fcb44d
+     name:enc-part  type:SEQUENCE
+       name:etype  type:INTEGER  value:0x11
+       name:cipher  type:OCT_STR  value:60fedd9e05c52f6fe151612ce4fc46c25
+       9afa56cc61d6ca1d9027be767858f5b54a54dea4f534681f56ad815555860d2553
+       3b5be00eb90a0920d0c3392ba9fc28661e2deadb79b403e7302c765431b23aee14
+       bf83d4b30e3eb847afaa4411733a42b194fecbba57ec2c561edcad4f7bcb5cd03a
+       b003469ee3bbbfb8133be306c7336f85580c96e8d3d9d91582f0af89580936e55e
+       7f554b54959833fcdce2db8f68f6964e86497
+   -----BEGIN SHISHI KDC-REP-----
+   a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUbA2ph
+   c6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBGltYXAb
+   CWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3f2w6y+bA
+   56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68TcsiMh8y9K
+   bWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zTL/NbcoIJq2yn
+   CS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/y0TaaBtTCBsqAD
+   AgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ752eFj1tUpU3qT1NG
+   gfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPnMCx2VDGyOu4Uv4PUsw
+   4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnuO7v7gTO+MGxzNvhVgMlu
+   jT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJc=
+   -----END SHISHI KDC-REP-----
+
+   After extracting the AS-REP, the EncASRepPart and Ticket are as
+   follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                [Page 11]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   name:EncKDCRepPart  type:SEQUENCE
+     name:key  type:SEQUENCE
+       name:keytype  type:INTEGER  value:0x11
+       name:keyvalue  type:OCT_STR  value:517fe065071c845c425b5b18c4236618
+     name:last-req  type:SEQ_OF
+       name:NULL  type:SEQUENCE
+         name:lr-type  type:INTEGER
+         name:lr-value  type:TIME
+     name:nonce  type:INTEGER  value:0x5406d89f
+     name:flags  type:BIT_STR  value(3):20
+     name:authtime  type:TIME  value:20030202162503Z
+     name:endtime  type:TIME  value:20030202164143Z
+     name:srealm  type:GENERALSTRING  value:6c6f63616c686f7374
+     name:sname  type:SEQUENCE
+       name:name-type  type:INTEGER  value:0x01
+       name:name-string  type:SEQ_OF
+         name:NULL  type:GENERALSTRING
+         name:?1  type:GENERALSTRING  value:696d6170
+         name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
+   -----BEGIN SHISHI EncKDCRepPart-----
+   MIGAoBswGaADAgERoRIEEFF/4GUHHIRcQltbGMQjZhihAjAAogYCBFQG2J+kBAMC
+   BSClERgPMjAwMzAyMDIxNjI1MDNapxEYDzIwMDMwMjAyMTY0MTQzWqkLGwlsb2Nh
+   bGhvc3SqHDAaoAMCAQGhEzARGwRpbWFwGwlsb2NhbGhvc3Q=
+   -----END SHISHI EncKDCRepPart-----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                [Page 12]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   name:Ticket  type:SEQUENCE
+     name:tkt-vno  type:INTEGER  value:0x05
+     name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
+     name:sname  type:SEQUENCE
+       name:name-type  type:INTEGER  value:0x01
+       name:name-string  type:SEQ_OF
+         name:NULL  type:GENERALSTRING
+         name:?1  type:GENERALSTRING  value:696d6170
+         name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
+     name:enc-part  type:SEQUENCE
+       name:etype  type:INTEGER  value:0x12
+       name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377f6
+       c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214e61c
+       37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c87cfd49
+       82c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b728209ab6
+       ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716b0681de8eb
+       e941f054a77fcb44d
+   -----BEGIN SHISHI Ticket-----
+   YYHhMIHeoAMCAQWhCxsJbG9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9j
+   YWxob3N0o4GrMIGooAMCARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/
+   xOiH4DdcW9PDwkWoAlUUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4s
+   ll50JUssh8/UmCxJsGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rk
+   kpZZeXitwFk8oGflhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRN
+   -----END SHISHI Ticket-----
+
+   The third packet contains the AP-REQ, expanded as follows:
+
+   name:AP-REQ  type:SEQUENCE
+     name:pvno  type:INTEGER  value:0x05
+     name:msg-type  type:INTEGER  value:0x0e
+     name:ap-options  type:BIT_STR  value(32):04000000
+     name:ticket  type:SEQUENCE
+       name:tkt-vno  type:INTEGER  value:0x05
+       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
+       name:sname  type:SEQUENCE
+         name:name-type  type:INTEGER  value:0x01
+         name:name-string  type:SEQ_OF
+           name:NULL  type:GENERALSTRING
+           name:?1  type:GENERALSTRING  value:696d6170
+           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
+       name:enc-part  type:SEQUENCE
+         name:etype  type:INTEGER  value:0x12
+         name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377
+         f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214
+         e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8
+         7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7
+         28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716
+         b0681de8ebe941f054a77fcb44d
+
+
+
+Josefsson                Expires August 3, 2003                [Page 13]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+     name:authenticator  type:SEQUENCE
+       name:etype  type:INTEGER  value:0x11
+       name:kvno  type:INTEGER  value:0x01
+       name:cipher  type:OCT_STR  value:313e76818614c6b3f20fa72a5e39a86e4
+       13f1cea9748d723960c4be26a0de34124829ab01d2ff703335cff6df0beb63cbb1
+       a9eaa68c396f1014b65fc373c86abdcd1c07e702d4ff114e06f4ba932acf14eb8a
+       cb5fee0a164614204c938ec0a269fd97ed64e9127531c14192fc4ad62e61effa46
+       42a482791430ad7455279cfd86a61bee6cdfb1afa113c61eed76e8f4f28d7b3713
+       3885a9fe874fd0dafcd2670c29452fcfa79e554556d
+   -----BEGIN SHISHI AP-REQ-----
+   boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG9j
+   YWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMCARKi
+   gaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAlUUYObc
+   wGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJsGRns0sE
+   VgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oGflhShTvV1E
+   rj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSBqjE+doGGFMaz
+   8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L62PLsanqpow5bx
+   AUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJOOwKJp/ZftZOkSdT
+   HBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPGHu126PTyjXs3EziFqf
+   6HT9Da/NJnDClFL8+nnlVFVt
+   -----END SHISHI AP-REQ-----
+
+   After extracting the AP-REP, the Authenticator is as follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                [Page 14]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   name:Authenticator  type:SEQUENCE
+     name:authenticator-vno  type:INTEGER  value:0x05
+     name:crealm  type:GENERALSTRING  value:6c6f63616c686f7374
+     name:cname  type:SEQUENCE
+       name:name-type  type:INTEGER  value:0x01
+       name:name-string  type:SEQ_OF
+         name:NULL  type:GENERALSTRING
+         name:?1  type:GENERALSTRING  value:6a6173
+     name:cksum  type:SEQUENCE
+       name:cksumtype  type:INTEGER  value:0x0a
+       name:checksum  type:OCT_STR  value:15843a44f4f5f71746cc32e8
+     name:cusec  type:INTEGER  value:0x07480d
+     name:ctime  type:TIME  value:20030202162507Z
+     name:authorization-data  type:SEQ_OF
+       name:NULL  type:SEQUENCE
+         name:ad-type  type:INTEGER
+         name:ad-data  type:OCT_STR
+       name:?1  type:SEQUENCE
+         name:ad-type  type:INTEGER  value:0xff
+         name:ad-data  type:OCT_STR  value:09000000000900000000e9ebe38d0b
+         6bdca6b45b987d89f791a1
+   -----BEGIN SHISHI Authenticator-----
+   YoGDMIGAoAMCAQWhCxsJbG9jYWxob3N0ohAwDqADAgEBoQcwBRsDamFzoxcwFaAD
+   AgEKoQ4EDBWEOkT09fcXRswy6KQFAgMHSA2lERgPMjAwMzAyMDIxNjI1MDdaqCcw
+   JTAjoAMCAf+hHAQaCQAAAAAJAAAAAOnr440La9ymtFuYfYn3kaE=
+   -----END SHISHI Authenticator-----
+
+   The fourth packet contains the AP-REP, expanded as follows:
+
+   name:AP-REP  type:SEQUENCE
+     name:pvno  type:INTEGER  value:0x05
+     name:msg-type  type:INTEGER  value:0x0f
+     name:enc-part  type:SEQUENCE
+       name:etype  type:INTEGER  value:0x11
+       name:kvno  type:INTEGER  value:0x00
+       name:cipher  type:OCT_STR  value:930ccd73d8f17971460e066396228b977
+       c75ad4336338f5245b09315fc21cc4e606b25abc89878d1db87fd5b208d3af9893
+       0059e1c7395f49b698faac5b7fcad6ace14d2
+   -----BEGIN SHISHI AP-REP-----
+   b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOWIouX
+   fHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6rFt/yt
+   as4U0g==
+   -----END SHISHI AP-REP-----
+
+   After extracting the AP-REP, the EncAPRepPart is as follows:
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                [Page 15]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   name:EncAPRepPart  type:SEQUENCE
+     name:ctime  type:TIME  value:20030202162507Z
+     name:cusec  type:INTEGER  value:0x07480d
+   -----BEGIN SHISHI EncAPRepPart-----
+   exwwGqARGA8yMDAzMDIwMjE2MjUwN1qhBQIDB0gN
+   -----END SHISHI EncAPRepPart-----
+
+
+6. Security Considerations
+
+   The authentication phase is believed to be no less secure than the
+   Client/Server Authentication exchange described in the Kerberos 5
+   protocol.
+
+   If no security layer is negotiated, the connection is subject to
+   active man-in-the-middle attackers that hijack the connection after
+   authentication has been completed.
+
+   When security layers are used, it is believed that the communication
+   channel negotiated by this specification is no less secure than the
+   KRB_SAFE and KRB_PRIV primitives.  In other words, it is believed
+   that if an attack that breaches integrity or privacy of this
+   mechanism, the same attack also applies to the Kerberos 5
+   specification, and vice versa.
+
+   Server implementations should be aware that the proxy function can be
+   abused, and MAY implement precaution against this if it is considered
+   a threat.  Useful precautions include limiting the size and number of
+   packets forwarded, and to abort the SASL exchange when the limit is
+   reached.
+
+   Server implementations should make sure the method to look up KDC for
+   the client indicated realm does not cause security problems.  In
+   particular, trusting unprotected DNS lookups to find the KDC of a
+   realm may be considered as dangerous by a server.
+
+   The forward-compatibility behavior of returning empty responses to
+   unsupported commands may be abused as a covert channel.
+
+   The reason for the client to send, in the Authenticator checksum
+   field, not only the server random number but the entire initial
+   server packet with the security layer bitmask and maximum cipher-text
+   buffer size accepted by server, is to prevent an attacker from
+   downgrading the security layer and preference for mutual
+   authentication ultimately selected.  The random number ties the
+   client and server to the same network session, prevent
+   man-in-the-middle attacks assuming a Kerberos 5 security layer is
+   chosen and that the Kerberos 5 security layer is secure.
+
+
+
+Josefsson                Expires August 3, 2003                [Page 16]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   Generating AS-REP using a legacy password database requires
+   calculating the string2key operation.  This may be a costly operation
+   (in particular for the recent AES ciphers), so servers should either
+   pre-calculate and store the key once or take precautions against
+   opening itself up to a Denial Of Service attack which exhausts CPU
+   power on the server.
+
+   The security considerations of Kerberos 5 and SASL are inherited.
+   Some immediate consequences of this follows (this is an inconclusive
+   summary):
+
+   Note that some of the Kerberos 5 encryption types are considered
+   weak, implementations must decide which algorithms are trusted.
+
+   Note that the encryption types indicated in AS-REQ/TGS-REQ are not
+   integrity protected, so an attacker may downgrade the encryption keys
+   ultimately used.
+
+   Note that Kerberos 5 do not authorize users, it only authenticate
+   users.  Applications using this mechanism must thus perform checks,
+   not described in detail in this document, to make sure the
+   authenticated user is authorized to the service she is requesting.
+
+   Note that the SASL framework is subject to "downgrade" attacks where
+   an attacker forces a weaker SASL mechanism to be used.  The use of,
+   e.g., TLS [5] can be used to mitigate this.
+
+   Note that clients should use the server name exactly as the user
+   specified, or at least abstain from canonicalizing the server name
+   with insecure mechanisms such as unprotected DNS.
+
+Normative References
+
+   [1]  Kohl, J. and B. Neuman, "The Kerberos Network Authentication
+        Service (V5)", RFC 1510, September 1993.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Myers, J., "Simple Authentication and Security Layer (SASL)",
+        RFC 2222, October 1997.
+
+Informative References
+
+   [4]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+        Recommendations for Security", RFC 1750, December 1994.
+
+   [5]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
+
+
+
+Josefsson                Expires August 3, 2003                [Page 17]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
+        1999.
+
+   [6]  Linn, J., "Generic Security Service Application Program
+        Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+Author's Address
+
+   Simon Josefsson
+   Drottningholmsv. 70
+   Stockholm  112 42
+   Sweden
+
+   EMail: simon@josefsson.org
+
+Acknowledgments
+
+   Text and ideas was borrowed from the Kerberos version 4 SASL
+   mechanism in RFC 2222.  Lawrence Greenfield suggested adding a
+   security consideration about server name canonicalization.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                [Page 18]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+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 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.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 assignees.
+
+   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
+
+
+
+Josefsson                Expires August 3, 2003                [Page 19]
+
+Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                Expires August 3, 2003                [Page 20]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-kamada-krb-client-friendly-cross-02.txt b/third_party/heimdal/doc/standardisation/draft-kamada-krb-client-friendly-cross-02.txt
new file mode 100644
index 00000000000..3bcc4816cb2
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-kamada-krb-client-friendly-cross-02.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                    Ken'ichi Kamada
+INTERNET-DRAFT                                            Shoichi Sakane
+Expires: January 10, 2008                  Yokogawa Electric Corporation
+                                                            July 9, 2007
+
+
+            Client-Friendly Cross-Realm Model for Kerberos 5
+             draft-kamada-krb-client-friendly-cross-02.txt
+
+
+
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft expires on January 10, 2008.
+
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane                                               [Page 1]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+Abstract
+
+   This document proposes a cross-realm traversal model, which is
+   suitable for resource-limited clients, for Kerberos Version 5.  This
+   model provides a way to move the cost of consecutive Ticket-Granting
+   Service (TGS) exchanges from clients to Key Distribution Centers
+   (KDCs) and a way to reduce the traversal cost by generating a direct
+   inter-realm relationship between two realms.  The document describes
+   behavior of clients and KDCs, but does not specify any wire format,
+   which need to be specified separately.
+
+
+Table of Contents
+
+    1. Introduction .................................................  3
+    2. Problems on Client Performance ...............................  3
+       2.1. Long Authentication Path ................................  4
+       2.2. Client-Centric Ticketing ................................  4
+    3. Proposal of Client-Friendly Cross-Realm Model ................  4
+       3.1. Temporary Inter-Realm Relationship Generation Mode ......  5
+       3.2. Attorney Ticketing Mode .................................  6
+       3.3. Combination of the Two Modes ............................  7
+    4. Advantage of The Proposed Model for Deployment ...............  8
+       4.1. Compatibility with Traditional Kerberos Deployment ......  8
+       4.2. Orthogonality of the Two Modes ..........................  8
+    5. Front-End Protocol for Attorney Ticketing Mode ...............  9
+    6. Related Protocols Currently Proposed ......................... 10
+       6.1. PKCROSS ................................................. 10
+       6.2. XTGS .................................................... 10
+    7. Interoperability Considerations .............................. 10
+    8. Security Considerations ...................................... 11
+       8.1. Denial of Service (DoS) ................................. 11
+       8.2. Ticketing Policy ........................................ 11
+    9. IANA Considerations .......................................... 12
+   10. Acknowledgments .............................................. 12
+   11. References ................................................... 12
+       11.1. Normative References ................................... 12
+       11.2. Informative References ................................. 12
+   Authors' Addresses ............................................... 13
+   Full Copyright Statement ......................................... 13
+   Intellectual Property Statement .................................. 13
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane                                               [Page 2]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+1.  Introduction
+
+   Kerberos Version 5 [RFC4120] has a concept of cross-realm
+   authentication so that principals in different realms can
+   authenticate each other.  However in the current cross-realm model,
+   each client has to traverse the authentication path, and the burden
+   of the traversal is not negligible for clients with limited
+   resources, e.g., computational speed or power supply [CRPS].
+
+   In the current cross-realm operation, a client obtains a service
+   ticket for a remote principal in the following steps:
+
+   1)  N TGSes to get cross-realm TGTs in order to traverse the
+       intermediate realms, where N is the number of transit, and
+
+   2)  One TGS to get the final service ticket.
+
+   That is, the client needs to perform N + 1 transactions to obtain a
+   ticket for the remote service.
+
+   This document proposes a new cross-realm model, which consists of
+   "temporary inter-realm relationship generation mode" and "attorney
+   ticketing mode".  The former is intended to reduce transit cost
+   itself, and the latter is to move the cost from clients to KDCs.  The
+   document describes behavior of clients and KDCs, but does not specify
+   any wire format, which need to be specified separately.
+
+   Terms defined in section 1.7 of RFC 4120 are used throughout this
+   document.
+
+
+2.  Problems on Client Performance
+
+   In the current model of cross-realm operation, a client has to
+   transit all realms on the path to the destination realm.  When the
+   source realm and the destination realm have a direct inter-realm
+   relationship, a client is able to obtain a service ticket with two
+   TGS transactions (one for a cross-realm TGT and another for the
+   service ticket).  When the realms have a multi-hop relationship, a
+   client must transit the intermediate realms before it obtains the
+   service ticket.  That is, the client's task increases in proportion
+   to the distance of the relationship.
+
+   Two issues can be observed here behind the client load, which are
+   described in the following subsections.
+
+
+
+
+
+
+Kamada and Sakane                                               [Page 3]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+2.1.  Long Authentication Path
+
+   When a client wants to get a service ticket for a remote realm, it
+   must transit to the remote realm by traversing the intermediate
+   realms on the authentication path to the remote realm.  The result of
+   traversal is cached as a cross-realm TGT, but it is nothing more than
+   a per-client optimization.  Thus all clients accessing a remote realm
+   must pay the cost separately, even if their resources are limited.
+   For a long authentication path, the cost of the whole system becomes
+   large.
+
+2.2.  Client-Centric Ticketing
+
+   In Kerberos, any service tickets or cross-realm TGTs are issued via
+   TGS, where a client present a ticket for the TGS and obtains a next
+   ticket.  Currently, all TGS transactions are initiated by the client
+   and it needs to get all necessary cross-realm TGTs iteratively before
+   the final service ticket.  This process is a burden to a resource-
+   limited client.
+
+
+3.  Proposal of Client-Friendly Cross-Realm Model
+
+   In this section, two modes of operation are introduced, "Temporary
+   Inter-Realm Relationship Generation Mode" and "Attorney Ticketing
+   Mode", to solve the issues described in the previous section.  These
+   two modes are designed to be independent, that is, can be used
+   separately or in combination.
+
+   Temporary Inter-Realm Relationship Generation Mode solves the issue
+   of the long authentication path.  In this mode, if the source realm
+   and the destination realm do not have a direct inter-realm
+   relationship, the source KDC traverses the authentication path by
+   itself, contacts with the remote KDC, and generates a direct inter-
+   realm relationship between them.  After that, the source KDC can
+   issue direct inter-realm TGTs for the destination realm.  The purpose
+   of this mode is to reduce the traversal cost itself by caching the
+   result of traversal.
+
+   Attorney Ticketing Mode solves the issue of the client-centric
+   ticketing.  Consecutive TGS transactions to get cross-realm TGTs
+   and/or a final service ticket are initiated by a client in the
+   traditional Kerberos, whereas a KDC undertake that process in this
+   mode.  The purpose of this mode is to shift the cost of TGSes from a
+   client to a KDC.  This does not reduce the cost itself.
+
+
+
+
+
+
+Kamada and Sakane                                               [Page 4]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+3.1.  Temporary Inter-Realm Relationship Generation Mode
+
+   Temporary inter-realm relationship generation mode enables a KDC to
+   issue an inter-realm TGT directly to a remote KDC with which the KDC
+   doesn't preshare an inter-realm key.  To issue an inter-realm TGT
+   directly, a temporary inter-realm key needs to be provided somehow.
+   To achieve that, the local KDC obtains a special ticket for the
+   remote KDC and uses its session key as an inter-realm key.  This
+   methodology was introduced by PKCROSS [PKCROSS].  In this document,
+   that special ticket is called as an "inter-KDC ticket", and an inter-
+   realm TGT generated from an inter-KDC ticket is called as a "direct
+   inter-realm TGT".
+
+   How does the local KDC reach the remote KDC is out of scope of this
+   model, but we can easily come up with 1) traversing a long
+   authentication path if available or 2) using PKINIT.  In the context
+   of this model, PKCROSS is interpreted as a combination of this mode
+   and PKINIT.
+
+   This document does not standardize a specific protocol, but an inter-
+   KDC ticket will have the following form:
+
+   -  its sname has a special form (PKCROSS proposes
+      "pkcross/realm@REALM", but it would be better to use a more
+      general name than "pkcross"),
+
+   and a direct inter-realm TGT will have the following form:
+
+   -  its TicketExtensions field [KRBEXT] contains the inter-KDC ticket,
+      and
+
+   -  it is protected by the session key (or the sub-session key) of the
+      inter-KDC ticket.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane                                               [Page 5]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+         client C                KDC-L          KDC-I          KDC-R
+         --------                -----          -----          -----
+
+      1.    --------TGS-REQ-------->
+      2.                           [Reach to KDC-R in any way.]
+                                   [Below is an example of PKCROSS.]
+                                   ------------PKINIT------------>
+                                   <----------XTKT(L,R)-----------
+      3.    <--TKT(C,R)w/XTKT(L,R)--
+      4.    ----------------------TGS-REQ------------------------>
+      5.    <---------------------TKT(C,S)------------------------
+
+      [Note: TKT(x,y) means a ticket whose cname is x and sname is y.  ]
+      [      XTKT is an inter-KDC ticket.  See PKCROSS.                ]
+      [      The client C and KDC-L belong to the local realm L.       ]
+      [      The KDC-I is a KDC of an intermediate realm I.            ]
+      [      The KDC-R is a KDC of the remote realm R.                 ]
+
+      1. The client C sends a normal TGS-REQ to KDC-L, requesting
+         a cross-realm TGT to KDC-R.
+      2. KDC-L reaches KDC-R in any way and obtains a XTKT.
+         There is no standardized way to achieve this step yet.
+         PKCROSS is one candidate.  We could also standardize a way
+         in which KDC-L normally transits to KDC-R and obtains an XTKT.
+      3. KDC-L generates a cross-realm TGT that is from C to KDC-R
+         and returns to it to C.
+      4. The same with the traditional cross-realm TGS.
+      5. The same with the traditional cross-realm TGS.
+
+        Figure 1: Message Flow of Temporary Inter-Realm Relationship
+                  Generation
+
+3.2.  Attorney Ticketing Mode
+
+   Traditionally, a Kerberos client repeats TGS transactions until it
+   gets the final ticket.  For example, it has a TGT for its own realm
+   and wants to get a ticket for a service in 3-hop neighbor realm, then
+   it will:
+
+   1)  Present the TGT and get a cross-realm TGT for the next realm,
+
+   2)  Present the 1st cross-realm TGT and get a cross-realm TGT for the
+       2nd next realm,
+
+   3)  Present the 2nd cross-realm TGT and get a cross-realm TGT for the
+       final realm, and
+
+
+
+
+
+Kamada and Sakane                                               [Page 6]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+   4)  Present the final cross-realm TGT and get a service ticket.
+
+   Attorney ticketing mode enables the client to delegate the KDC to
+   perform all transactions listed above on behalf of the client.  An
+   example message flow is shown in Figure 2.  The client entrust the
+   KDC with its TGT (step 1).  The KDC "impersonates" the client and
+   performs all necessary TGS transactions (steps 2 to 4), and returns
+   the final ticket to the client (step 5).
+
+         client C                KDC-L          KDC-I          KDC-R
+         --------                -----          -----          -----
+
+      1.    --------TGS-REQ-------->
+      2.                        TKT(C,I)
+      3.                           ----TGS-REQ---->
+                                   <---TKT(C,R)----
+      4.                           ------------TGS-REQ----------->
+                                   <-----------TKT(C,S)-----------
+      5.    <-------TKT(C,S)--------
+
+      1. The client C sends a special TGS-REQ, which indicates attorney
+         ticketing mode requesting a service ticket for a server S
+         instead of a cross-realm TGT, to KDC-L.
+      2. KDC-L internally generates a cross-realm TGT that is from C
+         to KDC-I, but does not return it to C.
+      3. KDC-L uses the generated cross-realm TGT by itself, and sends
+         a TGS-REQ to KDC-I, which requests a cross-realm TGT from C
+         to KDC-R.
+      4. KDC-L use the obtained cross-realm TGT by itself, and sends
+         a TGS-REQ to KDC-R, which requests a service ticket from C
+         to S.
+      5. KDC-L returns the final service ticket to C.
+
+             Figure 2: Message Flow of Attorney Ticketing Mode
+
+3.3.  Combination of the Two Modes
+
+   Figure 3 shows a typical message flow when the temporary inter-realm
+   relationship generation mode and the attorney ticketing mode are used
+   in combination.  The figure shows the case of the initial contact, so
+   a transaction to obtain an inter-KDC ticket is shown (step 2), but it
+   is infrequently used because the XTKT is cached.  Usually, only two
+   round-trips do all the work.
+
+
+
+
+
+
+
+
+Kamada and Sakane                                               [Page 7]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+         client C                KDC-L          KDC-I          KDC-R
+         --------                -----          -----          -----
+
+      1.    --------TGS-REQ-------->
+      2.                           [Temporary inter-realm relationship
+                                   generation mode runs here.]
+                                   ------------PKINIT------------>
+                                   <----------XTKT(L,R)-----------
+      3.                           [Attorney ticketing mode runs here.]
+                           TKT(C,R)w/XTKT(L,R)
+      4.                           ------------TGS-REQ----------->
+                                   <-----------TKT(C,S)-----------
+      5.    <-------TKT(C,S)--------
+
+       Figure 3: Message Flow When Temporary Inter-Realm Relationship
+                 Generation Mode and Attorney Ticketing Mode
+                 Are Combined
+
+
+4.  Advantage of The Proposed Model for Deployment
+
+4.1.  Compatibility with Traditional Kerberos Deployment
+
+   Temporary inter-realm relationship generation involves only KDCs.
+   From the viewpoint of a client (and a server), it seems that there is
+   a direct inter-realm relationship between two realms.  This means
+   that temporary inter-realm relationship generation mode needs to be
+   deployed only in KDCs.  This property is advantageous, because it
+   does not affect large installed base of clients.  One impeding factor
+   in practice is that some existing implementations cannot handle
+   ticket extensions transparently.  This is further discussed in
+   Interoperability Considerations section.
+
+   Attorney ticketing mode involves only a client and its local KDC.
+   From the viewpoint of the remote KDC, TGS-REQs from a KDC as an
+   attorney cannot be distinguished from those from a "genuine" client
+   (except caddr; see Interoperability Considerations section).
+   Resulting service ticket is identical to the traditional one, so the
+   remote server has nothing to do with this mode.  In short, attorney
+   ticketing mode can be deployed in local realm, independently of the
+   remote deployment.  The merit of this property is large, because
+   remote realms are often in different administration.
+
+4.2.  Orthogonality of the Two Modes
+
+   Temporary inter-realm relationship generation mode and attorney
+   ticketing mode are independent concepts.  Both can be implemented
+   separately or can be used in combination.  When they are combined,
+
+
+
+Kamada and Sakane                                               [Page 8]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+   the load of clients are shifted to KDCs and additional load of KDCs
+   are minimized, thus efficient cross-realm environment is achieved.
+
+
+5.  Front-End Protocol for Attorney Ticketing Mode
+
+   This document does not specify wire-level protocol, which will be
+   done in another document.  This section provides some candidates for
+   the protocol, which is used to request attorney ticketing mode from a
+   KDC (Figure 4).  This protocol can be used for other than attorney
+   ticketing mode, as long as the KDC's behavior for clients is
+   identical to the mode.
+
+     +------+             +-------+
+     |client|------------>|  KDC  |-------------> cross-realm cloud
+     +------+             +-------+  Cross-realm
+        Front-end protocol           traversal by KDC
+        to request a final           (Attorney Ticketing Mode)
+        ticket in one shot
+                                       or
+
+                                   -------------> remote KDC (directly)
+                                     XTGSP
+
+                                       or
+
+                                   ------------->
+                                     Whatever the KDC chooses
+
+          Figure 4: Front-End Protocol for Attorney Ticketing Mode
+
+   Candidate 1: Implicit Signaling
+
+      A client simply requests a final ticket to the local KDC.  If the
+      KDC supports this implicit protocol, it will process the request.
+      If not, KDC_ERR_S_PRINCIPAL_UNKNOWN will be returned.  A possible
+      drawback is that if a requested final ticket is for a TGS, the KDC
+      does not know whether the client expects normal mode or attorney
+      mode.  In addition, implicit signaling can conflict with future
+      extensions.
+
+   Candidate 2: Explicit Signaling
+
+      A flag in KDCOptions or pre-authentication can be used to request
+      attorney mode.
+      [[what happens if not supported?]]
+
+
+
+
+
+Kamada and Sakane                                               [Page 9]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+6.  Related Protocols Currently Proposed
+
+6.1.  PKCROSS
+
+   PKCROSS will be usable as a protocol for temporary inter-realm
+   relationship generation mode.
+
+6.2.  XTGS
+
+   The purpose of XTGS protocol is similar to that of this model, but
+   the behavior is somewhat different [XTGS].  If XTGS is viewed from
+   the perspective of this model, it blends the two modes indivisibly to
+   reduce the number of messages between KDCs as far as possible at the
+   price of the abstraction of cross-realm TGTs and inter-KDC tickets.
+
+   Once a front-end (i.e., between a client and a KDC) protocol to
+   request attorney ticketing mode is standardized, XTGS can be used as
+   an opaque back-end.
+
+
+7.  Interoperability Considerations
+
+   User-to-user mode
+      The protocol for the attorney mode should be able to indicate
+      user-to-user authentication.
+
+   The addresses field in TGS-REQ
+      This field is copied into the caddr field in EncTicketPart, so if
+      this field is used in a TGS-REQ, the resulting ticket can be used
+      only from the specified addresses.  When the local KDC receives a
+      TGS-REQ requesting attorney mode, it should copy the addresses
+      field only into the final TGS-REQ in the attorney process.  It
+      must not copy the field into TGS-REQs to intermediate KDCs,
+      because resulting tickets are to be used by the local KDC instead
+      of the client.
+
+   Opacity of ticket extensions
+      The ticket extensions defined in rfc1510ter [KRBEXT] extends the
+      Ticket ASN.1 type, which is visible to clients.  This is not a
+      problem if a client implementation treats a Ticket as an opaque
+      data, and there are such implementations, but unfortunately the
+      major free implementations do not.  On the other hand, there is a
+      proposal of etype-based ticket extensions [TKTEXTALT].  It
+      encapsulates cleartext bits in the enc-part component of a Ticket.
+      It should not have any problems of opacity.
+
+   [[negotiation of various parameters]]
+
+
+
+
+Kamada and Sakane                                              [Page 10]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+   [[If there are multiple authentication paths and a client has enough
+   knowledge, it could choose which path to take.  With attorney
+   ticketing mode, it cannot because it is up to the KDC to select the
+   path.  Is this a problem?  With temporary inter-realm relationship
+   generation mode, it can as before.]]
+
+   [[co-existence with the plain Kerberos; attorney ticketing mode
+   client vs. non-attorney KDC; inter-realm generating local KDC vs.
+   non-generating remote KDC]]
+
+   [[anything to do with referral?]]
+
+   [[when a KDC in attorney mode receives a KRB-ERROR?]]
+
+
+8.  Security Considerations
+
+8.1.  Denial of Service (DoS)
+
+   A KDC that implements attorney ticketing mode needs to initiate
+   multiple TGS-REQ upon a request from a client.  This means that the
+   KDC will have some states in it and may suffer from DoS attacks.
+
+   Fortunately, attorney ticketing mode can be requested in TGS-REQ,
+   which is only available to authenticated clients, thus, any untrusted
+   party cannot exploit this statefulness.
+
+8.2.  Ticketing Policy
+
+   Attorney ticketing mode changes nothing about the messages sent to
+   the intermediate and remote KDCs.  Those KDCs will not notice the
+   difference and their ticketing process have nothing to be changed.
+
+   Temporary inter-realm relationship generation mode dynamically
+   generates new authentication paths.  This means that KDCs that are
+   involved in the transit of a client are different from those that
+   would be involved if this mode were not used.
+
+   -  Parameters of cross-realm TGTs (lifetime and flags) for a new
+      relationship need to be dynamically transferred (a la PKCROSS).
+
+   -  How to handle the transited fields in inter-KDC tickets, direct
+      inter-realm tickets, and service tickets?
+
+   -  Where the remote KDC adds AuthorizationData and the end-server
+      checks it: there is no problem because it is a local matter of the
+      remote realm.
+
+
+
+
+Kamada and Sakane                                              [Page 11]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+   -  Where an intermediate KDC adds AuthorizationData: traditionally it
+      is added in a cross-realm TGT and propagated to the service
+      ticket; now it will be propagated to the inter-KDC ticket.  Should
+      AuthorizationData in an inter-KDC ticket be copied into a cross-
+      realm TGT or not?  Even if it is copied, AuthorizationData on
+      inter-KDC ticket cannot represent per-client information, so if it
+      is necessary, temporary inter-realm relationship generation mode
+      must not be used.
+
+
+9.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+10.  Acknowledgments
+
+   The authors would like to acknowledge Saber Zrelli, Masahiro
+   Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for
+   contributions to this document.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [KRBEXT]      Yu, T., "The Kerberos Network Authentication Service
+                 (Version 5)", draft-ietf-krb-wg-rfc1510ter-04, Work in
+                 Progress, March 2007.
+
+   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                 Kerberos Network Authentication Service (V5)", RFC
+                 4120, July 2005.
+
+11.2.  Informative References
+
+   [CRPS]        Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement
+                 on the cross-realm operation of Kerberos in a specific
+                 system", draft-sakane-krb-cross-problem-statement-02,
+                 Work in Progress, April 2007.
+
+   [PKCROSS]     Hur, M. et al., "Public Key Cryptography for Cross-
+                 Realm Authentication in Kerberos", draft-ietf-cat-
+                 kerberos-pk-cross-08 (expired), Work in Progress,
+                 November 2001.
+
+   [TKTEXTALT]   Message-ID: <tslfy54akcb.fsf@mit.edu>.
+
+
+
+
+Kamada and Sakane                                              [Page 12]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+   [XTGS]        Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for
+                 cross-realm operations in Kerberos", draft-zrelli-krb-
+                 xtgsp-01, Work in Progress, March 2007.
+
+Authors' Addresses
+
+   Ken'ichi Kamada
+   Shoichi Sakane
+   Yokogawa Electric Corporation
+   2-9-32 Nakacho, Musashino-shi,
+   Tokyo 180-8750 Japan
+   E-mail: Ken-ichi.Kamada@jp.yokogawa.com,
+           Shouichi.Sakane@jp.yokogawa.com
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+
+Kamada and Sakane                                              [Page 13]
+
+Internet-Draft         Client-Friendly Cross-Realm             July 2007
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamada and Sakane                                              [Page 14]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-lha-kitten-deleg-policy-00.txt b/third_party/heimdal/doc/standardisation/draft-lha-kitten-deleg-policy-00.txt
new file mode 100644
index 00000000000..64b0e8d3a74
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-lha-kitten-deleg-policy-00.txt
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                               L. Hornquist Astrand
+Internet-Draft                                               Apple, Inc.
+Intended status: Standards Track                              S. Hartman
+Expires: February 14, 2009                        Painless Security, LLC
+                                                         August 13, 2008
+
+
+                GSS-API: Delegate if approved by policy
+                  draft-lha-gssapi-delegate-policy-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on February 14, 2009.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 1]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+Abstract
+
+   Several GSS-API applications work in a multi-tiered architecture,
+   where the server takes advantage of delegated user credentials to act
+   on behalf of the user and contact additional servers.  In effect, the
+   server acts as an agent on behalf of the user.  Examples include web
+   applications that need to access e-mail or file servers as well as
+   CIFs file servers.  However, delegating the ability to act as a user
+   to a party who is not sufficiently trusted is problematic from a
+   security standpoint.  Kerberos provides a flag called OK-AS-DELEGATE
+   that allows the administrator of a Kerberos realm to communicate that
+   a particular service is trusted for delegation.  This specification
+   adds support for this flag and similar facilities in other
+   authentication mechanisms to GSS-API (RFC 2743).
+
+
+Table of Contents
+
+   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS-API flag, c binding  . . . . . . . . . . . . . . . . . . .  5
+   4.  GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 2]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+1.  Requirements Notation
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 3]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+2.  Introduction
+
+   Several GSS-API applications work in a multi-tiered architecture,
+   where the server takes advantage of delegated user credentials to act
+   on behalf of the user and contact additional servers.  In effect, the
+   server acts as an agent on behalf of the user.  Examples include web
+   applications that need to access e-mail or file servers as well as
+   CIFs file servers.  However, delegating the ability to act as a user
+   to a party who is not sufficiently trusted is problematic from a
+   security standpoint.
+
+   Today, GSS-API [RFC2743] leaves the determination of whether
+   delegation is desired to the client application.  If the client sets
+   the deleg_req_flag to gss_init_sec_context then the application
+   requests delegation.  This requires client applications to know what
+   services should be trusted for delegation.  In some cases, however, a
+   central authority is in a better position to know what services
+   should receive delegation than the client application.  Some
+   mechanisms such as Kerberos [RFC4121] have a facility to allow a
+   realm administrator to communicate that a particular service is a
+   valid target for delegation.  In Kerberos, the KDC can set the OK-AS-
+   DELEGATE flag in issued tickets.  However even in such a case,
+   delegating to services for applications that do not need delegation
+   is problematic.  So, it is desirable for a GSS-API client to be able
+   to request delegation if and only-if central policy reccomends
+   delegation to the given target.
+
+   This specification adds a new input flag to GSS_Init_sec_context to
+   request delegation when approved by central policy.  In addition, a
+   constant value to be used in the GSS-API C bindings [RFC2744] is
+   defined.  Finally, the behavior for the Kerberos mechanism [RFC4121]
+   is specified.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 4]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+3.  GSS-API flag, c binding
+
+   The GSS_Init_sec_context API is extended to gain a new input flag: if
+   the deleg_policy_req flag is set, then delegation should be performed
+   if recommended by central policy.  In addition, the C bindings are
+   extended to define the following constant to represent this new flag.
+
+
+
+   #define GSS_C_DELEG_POLICY_FLAG 32768
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 5]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+4.  GSS-API behavior
+
+   As before, if the GSS_C_DELEG_FLAG is set, the GSS-API mechanism
+   tries to delegate.  Output ret_flags contains the flag
+   GSS_C_DELEG_FLAG if delegation is successful.
+
+   If the GSS_C_DELEG_POLICY_FLAG is set, the code delegates only if the
+   mechanism policy allows delegation.  If delegation is done, the
+   output flag ret_flags contain both GSS_C_DELEG_FLAG and
+   GSS_C_DELEG_POLICY_FLAG on the initator and GSS_C_DELEG_FLAG on the
+   acceptor.
+
+   If both GSS_C_DELEG_FLAG and GSS_C_DELEG_POLICY_FLAG are set, then
+   delegation is attempted.  However GSS_C_DELEG_POLICY_FLAG is only set
+   in ret_flags on the initiator if GSS_C_DELEG_POLICY_FLAG would have
+   been sufficient to request delegation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 6]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+5.  GSS-API behavior
+
+   If the GSS_C_DELEG_POLICY_FLAG is set, the Kerberos GSS-API mechanism
+   will only delegate if ok-as-delegate is set [RFC4120] in the service
+   ticket.  Other policy checks MAY be applied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 7]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+6.  Security Considerations
+
+   Introduce a flag what allows client to get help from the KDC when to
+   delegate to servers, will limit what servers that client delegate
+   too.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 8]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+7.  IANA Considerations
+
+   This section needs to be revised to be consistent with the kitten
+   IANA draft.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 9]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009         [Page 10]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+Authors' Addresses
+
+   Love Hornquist Astrand
+   Apple, Inc.
+
+   Email: lha@apple.com
+
+
+   Sam Hartman
+   Painless Security, LLC
+
+   Email: hartmans-ietf@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009         [Page 11]
+
+Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Hornquist Astrand & Hartman  Expires February 14, 2009         [Page 12]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt b/third_party/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt
new file mode 100644
index 00000000000..e43aadee30e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt
@@ -0,0 +1,728 @@
+
+
+
+Network Working Group                               L. Hornquist Astrand
+Internet-Draft                                                Apple, Inc
+Intended status: Standards Track                         August 13, 2008
+Expires: February 14, 2009
+
+
+                       Kerberos ticket extensions
+                 draft-lha-krb-wg-ticket-extensions-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on February 14, 2009.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2008).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 1]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+Abstract
+
+   The Kerberos protocol does not allow ticket extensions.  This make it
+   harder to deploy features like referrals and PKCROSS.
+
+   Since the Kerberos protocol did not specified extensibility for the
+   Ticket structure and the current implementations are aware of the
+   contents of tickets, the extension protocol cannot simply extend the
+   Ticket ASN.1 structure.  Instead, the extension data needs to be
+   hidden inside the ticket.
+
+
+Table of Contents
+
+   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
+   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  How to request a new assignment for a ticket extension . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+   Appendix A.  Ticket-extensions ASN.1 Module  . . . . . . . . . . . 11
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 2]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+1.  Requirements Notation
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 3]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+2.  Protocol
+
+   The ticket and enc-part as defined by [RFC4120] is defined as follow:
+
+
+   Ticket          ::= [APPLICATION 1] SEQUENCE {
+           tkt-vno         [0] INTEGER (5),
+           realm           [1] Realm,
+           sname           [2] PrincipalName,
+           enc-part        [3] EncryptedData -- EncTicketPart
+   }
+
+   EncryptedData   ::= SEQUENCE {
+           etype   [0] Int32 -- EncryptionType --,
+           kvno    [1] UInt32 OPTIONAL,
+           cipher  [2] OCTET STRING -- ciphertext
+   }
+
+
+
+   This document uses the special encryption type etype-TBETicket to
+   signal that enc-part.cipher contains the DER-encoded TBETicket
+   structure, instead of an encrypted EncTicketPart.
+
+
+
+   etype-TBETicket INTEGER ::= 4711 -- TBA XXX --
+
+   krb5int32  ::= INTEGER (-2147483648..2147483647)
+
+   TBETicket ::= SEQUENCE {
+           etype           [0] krb5int32 -- EncryptionType --,
+           cipher          [1] OCTET STRING
+           extensions      [2] SEQUENCE OF TicketExtension OPTIONAL
+
+   }
+
+   TicketExtension ::= SEQUENCE {
+           te-type [0] krb5int32,
+           te-data [1] OCTET STRING
+           te-csum [2] Checksum OPTIONAL
+   }
+
+
+   The content of cipher data and encryption type fields is moved inside
+   TBETicket.
+
+   Negative ticket extensions types (te-type) is private extensions and
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 4]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+   MUST only be used for experimentation.
+
+   The te-type field is specificing the type of the content in te-data.
+   Unknown te-types MUST be ignored both by the client and the server.
+
+   The te-csum field is optional for the type, when in use by type type
+   specifed in te-type, the key have to be specifed (usually the session
+   key of the ticket) and the key usage number.
+
+   The KDC MUST only return this extension in the AS-REQ if all other
+   KDCs for the same realm also supports this extension.
+
+   The KDC MUST only return this extension in the TGS-REQ to server the
+   KDC knows supports these extension.  This includes both cross realm
+   tickets and service tickets.
+
+   The KDC MAY return extended tickets to servers supporting ticket
+   extensions even if the extended ticket does not contain any
+   extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 5]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+3.  How to request a new assignment for a ticket extension
+
+   When anyone is writing a internet-draft for which a new assignment
+   for te-type is needed/wanted under the ticket extension, then the
+   proper way to do so is as follows:
+
+
+         EXAMPLE-MODULE DEFINITIONS ::= BEGIN
+
+         krb5-ticket-extension-Name ::= INTEGER nnn
+         -- IANA: please assign nnn
+         -- RFC-Editor: replace nnn with IANA-assigned
+         --             number and remove this note
+         END
+
+
+   IANA: Don't do note above, its an example, remove this note RFC-
+   Editor: Don't do note above, its an example, remove this note IANA
+   will assign the number as part of the RFC publication process.
+
+   When reviewing the document, the reviewer should take sure to check
+   that if te-csum is used, the siging key and key usage is specifed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 6]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+4.  Security Considerations
+
+   This document describes how to extend Kerberos tickets to include
+   additional data in the ticket.  This does have a security
+   implications since the extension data in the TBETicket is only
+   optionally signed, not encrypted and is not replay protected.  It is
+   up to the consumers of this interface to make sure its used safely.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 7]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+5.  Acknowledgements
+
+   Thanks to Leif Johansson, and Kamada Ken'ichi for reviewing the
+   document and provided suggestions for improvements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 8]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+6.  IANA Considerations
+
+   There are currently no ticket extensions.  Future ticket extensions
+   will be published at:
+
+
+         http://www.iana.org/assignments/NNNNNNNN
+         -- IANA: please name registry, proposal: krb5-ticket-extensions
+
+
+   IANA is requested to maintain this registry for future assignments.
+   New assignments can only be made via Specification Required as
+   described in [RFC2434].
+
+   IANA will assign the number as part of the RFC publication process.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009               [Page 9]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009              [Page 10]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+Appendix A.  Ticket-extensions ASN.1 Module
+
+
+
+KerberosV5-TicketExtensions {
+       iso(1) identified-organization(3) dod(6) internet(1)
+       security(5) kerberosV5(2) modules(4) ticket-extensions(TBA)
+--- XXX who is the registerar for this number ?
+} DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+IMPORTS
+        -- as defined in RFC 4120
+        Int32, Checksum
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                     dod(6) internet(1) security(5) kerberosV5(2)
+                     modules(4) krb5spec2(2) }
+
+
+etype-TBETicket INTEGER ::= 4711 -- XXX TBA --
+
+TBETicket ::= SEQUENCE {
+        etype           [0] Int32 -- EncryptionType --,
+        cipher          [1] OCTET STRING
+        extensions      [2] SEQUENCE OF TicketExtension OPTIONAL
+}
+
+TicketExtension ::= SEQUENCE {
+        te-type [0] krb5int32,
+        te-data [1] OCTET STRING
+        te-csum [2] Checksum
+}
+
+END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009              [Page 11]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+Author's Address
+
+   Love Hornquist Astrand
+   Apple, Inc
+   Cupertino
+   USA
+
+   Email: lha@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009              [Page 12]
+
+Internet-Draft         Kerberos ticket extensions            August 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Hornquist Astrand       Expires February 14, 2009              [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt b/third_party/heimdal/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt
new file mode 100644
index 00000000000..d65d8fb0890
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt
@@ -0,0 +1,249 @@
+
+
+GSSAPI Java CSharp                                             C. Morris
+INTERNET-DRAFT                                               Novell, Inc.
+draft-morris-java-gssapi-update-for-csharp-00.txt     comorris@novell.com
+Expires 10 March 2004                                           July 2004
+
+
+         Generic Security Service API Version 2 : Java & C# Bindings
+
+Status of this Memo
+
+   Comments should be submitted to comorris@novell.com.
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed, or
+   will be disclosed, and any of which I become aware will be disclosed,
+   in accordance with RFC 3668.
+
+   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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Abstract
+
+   The Generic Security Services Application Program Interface (GSS-API)
+   offers application programmers uniform access to security services
+   atop a variety of underlying cryptographic mechanisms. This document
+   proposes an update to RFC 2853, Generic Security Service API Version 
+   2 : Java Bindings, to include C# bindings.
+
+4.17.  C# Modifications
+
+   This section describes the language dependent modifications necessary
+   to implement the interface in C#. 
+   
+4.17.1   C# Assembly Name
+
+   The C# namespace is org.ietf.gss. See section 4.17.5 for an example.
+   
+4.17.2   C# Class Definitions
+   
+   All class definitions & methods remain the same as specified in the 
+   Java bindings.
+   
+4.17.3   C# Data Types
+
+   All data types remain the same.
+
+4.17.4   C# Exception Handling
+
+   All exception codes remain the same as specified in the Java bindings.
+   However, C# does not have a 'throws' statement. Therefore, method prototypes do
+   not include the exception type. For example,
+   
+   Java method prototype :
+   
+      public abstract GSSName createName(String nameStr, Oid nameType)
+         throws GSSException;
+  
+   Equivalent C# method prototype :
+  
+      public abstract GSSName createName(String nameStr, Oid nameType);
+    
+   C# does implement the throw and catch keywords, for example:
+   
+      public class GSSName createName(String nameStr, Oid nameType)
+      {
+         int majorCode = 0;
+         ...
+         
+         majorCode = validateParms(nameStr, nameType);
+         
+         if (majorCode)
+            throw new GSSException(majorCode);
+            
+         ...
+      }
+
+
+4.17.5   C# Example Code
+
+   Client example : 
+   
+   using ietf.org.gss;
+
+   class GssapiClient
+   {
+      private static TcpClient client;
+      private static NetworkStream stream;
+
+	   static void Main(string[] args)
+	   {
+		   Connect("127.0.0.1", "message from client");
+
+	   try
+	   {
+	      GSSManager manager = GSSManager.getInstance();
+
+	      Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
+	      Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
+
+	      // Optionally Identify who the client wishes to be
+	      // GSSName name = manager.createName("test@gsserver", GSSName.NT_USER_NAME);
+      	
+	      // Obtain default credential
+	      GSSCredential userCreds = manager.createCredential(GSSCredential.INITIATE_ONLY);
+	      GSSName name = userCreds.getName(krb5PrincipalNameType);
+
+	      Console.WriteLine("Just acquired credentials for " + name.toString());
+
+	      int acceptLife = userCreds.getRemainingAcceptLifetime(new Oid("2.3.4"));
+	      int initLife   = userCreds.getRemainingInitLifetime(new Oid("1..3."));
+	      int remLife    = userCreds.getRemainingLifetime();
+	      int usage      = userCreds.getUsage();
+   	   
+	      GSSName namea = userCreds.getName();
+	      Oid[] oa = userCreds.getMechs();
+
+         // Instantiate and initialize a security context that will be
+         // established with the server
+	      GSSContext context = manager.createContext(name,
+						      krb5Mechanism,
+						      userCreds,
+						      GSSContext.DEFAULT_LIFETIME);
+
+	      userCreds.dispose();
+
+	      // Optionally Set Context Options, must be done before iniSecContext call
+	      context.requestMutualAuth(true);
+	      context.requestConf(true);
+	      context.requestInteg(true);
+	      context.requestSequenceDet(true);
+	      context.requestCredDeleg(true);
+
+	      MemoryStream ins = new MemoryStream();
+	      MemoryStream outs = new MemoryStream();
+
+	      // loop until context is setup and no more tokens to receive
+	      while (!context.isEstablished())
+	      {
+   	      outs = new MemoryStream();
+	         context.initSecContext(ins, outs);
+
+	         // send token if present
+	         if (outs.Length > 0)
+	         {
+		         Console.WriteLine("Sending token...");
+		         sendToken(outs);
+	         }
+
+	         // check if we should expect more tokens
+	         if (context.isEstablished())
+		         break;
+
+	         // another token expected from peer
+	         Console.WriteLine("Still expecting another token from server...");
+	         ins = recvToken();
+	      }
+
+	      //
+	      // display context information
+	      //
+
+	      // Did the server authenticate back to client?
+	      Console.WriteLine("\n{0} Mutual Authentication", 
+	      context.getMutualAuthState() ? "Using" : "Not using");
+	      Console.WriteLine("Credentials were delegated = " 
+   	      + context.getCredDelegState());
+	      Console.WriteLine("Remaining lifetime in seconds = " 
+	         + context.getLifetime());
+	      Console.WriteLine("Context mechanism = " + context.getMech());
+	      Console.WriteLine("Initiator = " + context.getSrcName().toString());
+	      Console.WriteLine("Acceptor = " + context.getTargName().toString());
+	      Console.WriteLine("Confidentiality (i.e., privacy) is {0}available", 
+	      context.getConfState() ? "" : "not ");
+	      Console.WriteLine("Integrity is {0}available", 
+	      context.getIntegState() ? "" : "not ");
+	      Console.WriteLine("Is initiator = " + context.isInitiator());
+	      Console.WriteLine("Is transferable = " + context.isTransferable());
+	      Console.WriteLine("Is protReady = " + context.isProtReady());
+	      Console.WriteLine("ReplayDetState = " + 
+	      context.getReplayDetState());
+	      Console.WriteLine("SequenceDetState = " + 
+	      context.getSequenceDetState());
+
+	      // perform wrap on an application supplied message
+	      // using QOP = 0, and requesting privacy service
+
+	      MessageProp msgProp = new MessageProp(0, true);
+	      byte [] message = System.Text.Encoding.ASCII.GetBytes("Hello GSS-API!");
+	      byte [] token = System.Text.Encoding.ASCII.GetBytes("tok");
+
+	      // Byte aray method is equivalent to stream method
+	      //byte []token = context.wrap(message, 0, appMsg.length, msgProp);
+	      //sendToken(token);
+
+	      ins = new MemoryStream();
+	      outs = new MemoryStream();
+	      ins.Write(token, 0, token.Length);
+	      context.getMIC(ins, outs, msgProp);
+	      sendToken(outs);
+
+	      outs = new MemoryStream();
+	      outs.Write(message, 0, message.Length);
+	      sendToken(outs);
+
+	      ins = new MemoryStream();
+	      outs = new MemoryStream();
+	      ins.Write(message, 0, message.Length);
+	      context.wrap(ins, outs, msgProp);
+	      sendToken(outs);
+
+         // Optionally export context to another thead
+	      GSSContext ctx = manager.createContext(context.export());
+	      Console.WriteLine("New context isTransferable = " + ctx.isTransferable());
+	      Console.WriteLine("New context isInitiator = " +ctx.isInitiator());
+	      Console.WriteLine("New context protReady = " +ctx.isProtReady());
+	      Console.WriteLine("New context srcName = " +ctx.getSrcName().toString());
+	      Console.WriteLine("New context targName = " +ctx.getTargName().toString());
+
+	      // release the local-end of the context
+	      ctx.dispose();
+
+	      stream.Close();
+	      Console.WriteLine("Leaving...");
+	   }
+	   catch (GSSException e)
+	   {
+	      Console.WriteLine(e.getMessage());
+	      Console.WriteLine(e.StackTrace);
+	   }
+	}
+
+
+Expires 10 March 2004                                 
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt b/third_party/heimdal/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt
new file mode 100644
index 00000000000..0f959cb8e52
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt
@@ -0,0 +1,461 @@
+
+
+
+<Kerberos Working Group>                                      Larry Zhu 
+Internet Draft                                                Microsoft 
+Updates: 1964                                        Karthik Jaganathan 
+Category: Standards Track                                     Microsoft 
+draft-ietf-krb-wg-gssapi-cfx-00.txt                     August 16, 2003 
+                                             Expires: February 16, 2004 
+ 
+  Crypto Profile Based Support for the Inclusion of New Encryption and 
+        Checksum Algorithms in the Kerberos V5 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 
+    
+   [KCRYPTO] introduced a generic framework for the inclusion of new 
+   encryption and checksum algorithms to be used in the Kerberos V5 
+   protocol.  [AES-KRB5] describes a crypto profile (per [KCRYPTO]) for 
+   AES.  This document introduces a generic method for adding new 
+   crypto-systems to the GSSAPI-KerberosV5 mechanism based on crypto 
+   profiles as defined in [KCRYPTO].  It also describes the use of AES 
+   encryption for GSSAPI as an example of this new method. 
+    
+    
+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. Introduction 
+    
+   [GSSAPI-KRB5] describes the GSSAPI mechanism for Kerberos V5. It 
+   defines the format of context initiation, per-message and context 
+   deletion tokens.  When adding new crypto system support, the 
+
+  
+Zhu              Standards Trace - February 16, 2003                1 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+   approach taken in [GSSAPI-KRB5] is to add algorithm identifiers for 
+   each new cryptosystem.   
+    
+   The approach taken in this document is to use the same encryption 
+   and checksum algorithms specified by the crypto profile for the 
+   session key or subkey that is created during context negotiation.  
+   Message layouts of the per-message and context deletion tokens are 
+   revised to remove algorithm indicators and add extra information to 
+   support the generic crypto framework [KCRYPTO]. 
+    
+   "Newer" encryption and checksum types MUST use the new token formats 
+   defined in this document.  Older encryption and checksum types SHALL 
+   NOT use these new token formats.  The term "newer" is more precisely 
+   defined in [KRBCLAR]. 
+    
+   Note that in this document, "AES" is used for brevity to refer 
+   loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 
+   as defined in [AES-KRB5]. 
+    
+4. Quality of Protection and Algorithm Identifiers 
+ 
+   The GSSAPI specification [GSSAPI] provides for QOP values that can 
+   be used by the application to request a certain type of encryption 
+   or signing.  A zero QOP value is used to indicate the "default" 
+   protection; applications which use the default QOP are not 
+   guaranteed to be portable across implementations or even inter-
+   operate with different deployment configurations of the same 
+   implementation. Using an algorithm that is different from the one 
+   for which the key is defined may not be appropriate. Therefore, when 
+   the new method in this document is used, the QOP value is ignored. 
+    
+   The encryption and checksum algorithms in per-message and context 
+   deletion tokens are now implicitly defined by the algorithms 
+   associated with the session and subkey. Algorithms identifiers are 
+   therefore no longer needed and removed from the token headers. 
+    
+5. Key Derivation 
+    
+   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
+   "entropy-preserving" derived keys, for different purposes or key 
+   usages, from a base key or protocol key.  This document defines four 
+   key usage values below for signing and sealing messages: 
+    
+        Name                       value 
+      ------------------------------------- 
+      KG-USAGE-ACCEPTOR-SIGN         22 
+      KG-USAGE-ACCEPTOR-SEAL         23 
+      KG-USAGE-INITIATOR-SIGN        24 
+      KG-USAGE-INITIATOR-SEAL        25 
+          
+    
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
+   used as the usage number in the key derivation function for deriving 
+   keys to be used in MIC and context deletion tokens, and KG-USAGE-
+Zhu              Standards Track - February 16, 2004                2 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 
+   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 
+   number in the key derivation function for MIC and context deletion 
+   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if 
+   the Wrap token does not provide for confidentiality the same usage 
+   values specified above are used. 
+    
+6. Token Formats and Definitions 
+    
+   The new token formats defined in this document are designed to 
+   accommodate the requirements of newer crypto systems.  Certain 
+   implementations of GSSAPI, such as SSPI, allow for "scatter-gather" 
+   and in-place encryption, mostly by leveraging low level details of 
+   crypto systems.  The token layouts have been designed to satisfy the 
+   above requirements without incurring significant performance 
+   penalties or loosing generality.   
+    
+   The design along with the rationale behind it, is discussed in 
+   detail in the following sections. 
+    
+6.1. Sequence Number and Direction Indicators 
+ 
+   The sequence number for any per-message or context deletion token is 
+   a 64 bit integer (expressed in big endian order). One separate byte 
+   is used as the directional indicator: the hex value FF if the sender 
+   is the context acceptor, 00 otherwise. Both the sequence number and 
+   the directional indicator are protected as specified in section 6.2.  
+ 
+6.2. Encryption and Checksum Operations 
+    
+   The encryption algorithms defined by the crypto profiles provide for 
+   integrity protection. Therefore no separate checksum is needed.  
+    
+   In Wrap tokens that provide for confidentiality, the "header" (the 
+   first 16 bytes of the Wrap token) is appended to the plaintext data 
+   before encryption.  Hence the resulting Wrap token is {"header" | 
+   encrypt(plaintext-data | "header")}, where encrypt() is the 
+   encryption operation defined in the crypto profile. In Wrap tokens 
+   that do not provide for confidentiality, the checksum is calculated 
+   over the plaintext data concatenated with the token header (the 
+   first 16 bytes of the Wrap token).  Hence the resulting Wrap token 
+   is {"header" | plaintext-data | get_mic(plaintext-data | "header")}, 
+   where get_mic() is the checksum operation defined in the crypto 
+   profile. The parameters for the key and the cipher-state in the 
+   encrypt() and get_mic() operations have been omitted for brevity.  
+    
+   The resulting Wrap tokens bind the data to the token header, 
+   including the sequence number, directional indicator, and the 
+   rotation count. 
+ 
+  [With AEAD, Wrap tokens with confidentiality do not need to encrypt 
+  the header and the overhead can be reduced slightly] 
+   
+
+Zhu              Standards Track - February 16, 2004                3 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+  For MIC tokens, the checksum is first calculated over the token 
+  header (the first 16 bytes of the MIC token) and then the to-be-
+  signed plaintext data.   
+   
+  For context deletion tokens, the checksum is calculated over the 
+  token header (the first 16 bytes of the context deletion token). 
+   
+  When AES is used, the checksum algorithm is HMAC_SHA1_96 and the 
+  checksum size is 12 bytes.  Data is pre-pended with a 16 byte 
+  confounder before encryption, and no padding is needed. 
+   
+6.3. RRC Field 
+ 
+   A new field, called "RRC" (Right Rotation Count), is added to allow 
+   the data to be encrypted in place.  The resulting Wrap token in the 
+   previous section, excluding the first 16 bytes of the token header, 
+   is rotated to the right by "RRC" bytes.  The net result is that 
+   "RRC" bytes of trailing octets are moved toward the header.  
+   Consider the following as an example of this rotation operation: 
+   Assume that the RRC value is 3 and the token before the rotation is 
+   {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the token after 
+   rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee 
+   }, where {aa | bb | cc |...| hh} is used to indicate the byte 
+   sequence. 
+  
+   The RRC field is expressed as a two octet integer in big endian 
+   order. 
+    
+   The rotation count value is chosen by the sender based on 
+   implementation details, and the receiver MUST be able to interpret 
+   all possible rotation count values. 
+  
+6.4. EC Field 
+ 
+   The decryption operation in the crypto profile may not always return 
+   the exact length of the plaintext data.  An "EC"(Extra Count) field 
+   is added to the Wrap() token header to indicate the number of bytes 
+   that have been added to the end of the plaintext data before 
+   encryption.  The "EC" field is a two byte integer expressed in big 
+   endian order and it should be 00 00 if confidentiality is not 
+   provided for by the Wrap tokens. 
+    
+6.5. Seal Field 
+ 
+  The Seal field in Wrap tokens is used to indicate whether 
+  confidentiality is provided for.  If confidentiality is provided for 
+  by the Wrap token, this field contains the hex value FF, otherwise it 
+  contains the hex value 00. 
+ 
+6.6. Message Layout for Per-message and Context Deletion Tokens 
+    
+   The new message layouts are as follows. 
+    
+   MIC Token: 
+Zhu              Standards Track - February 16, 2004                4 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+    
+      Byte no           Name             Description 
+       0..1            TOK_ID         Identification field. 
+                                      Tokens emitted by GSS_GetMIC()  
+                                      contain the hex value 04 04 in 
+                                      this field. 
+       2..2            Direction      Hex value FF if the sender is the  
+                                      context acceptor, 00 otherwise.    
+       3..7            Filler         Contains 5 bytes of hex value FF. 
+       8..15           SND_SEQ        Sequence number field in  
+                                      cleartext, in big endian order.  
+       16..            SGN_CKSUM      Checksum of byte 0..15 and the 
+                                      "to-be-signed" data, where the 
+                                      checksum algorithm is defined by      
+                                      the crypto profile for the  
+                                      session key or subkey. 
+ 
+    
+   The Filler field is included in the checksum calculation for 
+   simplicity.  This is common to both MIC and context deletion token 
+   checksum calculations. 
+ 
+   Wrap Token: 
+    
+      Byte no             Name           Description 
+       0..1            TOK_ID       Identification field. 
+                                    Tokens emitted by GSS_Wrap()                     
+                                    contain the hex value 05 04  
+                                    in this field. 
+       2..2            Direction    Hex value FF if the sender is the  
+                                    context acceptor, 00 otherwise.    
+       3..3            Seal         Confidentiality indicator: hex  
+                                    value FF if confidentiality is  
+                                    provided for, 00 otherwise. 
+       4..5            EC           Contains the "extra count" field,   
+                                    in big endian order as described in  
+                                    section 6.4. 
+       6..7            RRC          Contains the "right rotation                      
+                                    count" in big endian order, as  
+                                    described in section 6.3. 
+       8..15           SND_SEQ      Sequence number field in                      
+                                    cleartext, in big endian order. 
+       16..            Data         Encrypted or plaintext data, as  
+                                    described in section 6.2, where  
+                                    the encryption or checksum  
+                                    algorithm is defined by the crypto  
+                                    profile for the session key or  
+                                    subkey. 
+                                    
+                                   
+   Context Deletion Token:       
+    
+      Byte no          Name           Description 
+Zhu              Standards Track - February 16, 2004                5 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+       0..1           TOK_ID        Identification field. 
+                                    Tokens emitted by 
+                                    GSS_Delete_sec_context() contain 
+                                    the hex value 04 05 in this  
+                                    field. 
+       2..2           Direction     Hex value FF if the sender is the  
+                                    context acceptor, 00 otherwise.    
+       3..7           Filler        Contains 5 bytes of hex value FF. 
+       8..15          SND_SEQ       Sequence number field in  
+                                    cleartext, in big endian order.  
+       16..           SGN_CKSUM     Checksum of byte 0..15, where the 
+                                    checksum algorithm is defined by      
+                                    the crypto profile for the  
+                                    session key or subkey. 
+    
+                                   
+7. Backwards compatibility considerations 
+ 
+   The new token formats defined in this document will only be 
+   recognized by new implementations.  A MIC or wrap token generated 
+   with the algorithms defined in this document will not be recognized 
+   by an older implementation that only recognizes the algorithms 
+   defined in [GSSAPI-KRB5].  To address this, implementations can 
+   always use the explicit sign or seal algorithm in [GSSAPI-KRB5] when 
+   the key type corresponds to those algorithms.  An alternative 
+   approach might be to retry sending the message with the sign or seal 
+   algorithm explicitly defined as in [GSSAPI-KRB5]. However this would 
+   require the use of a mechanism such as [SPNEGO] to securely 
+   negotiate the algorithm or the use out of band mechanism to choose 
+   appropriate algorithms.  For this reason, it is RECOMMENDED that the 
+   use of the new token formats defined in this document be confined 
+   only for "newer encryption and checksum" described by a crypto 
+   profile.  
+ 
+8. Security Considerations 
+ 
+   It is possible that the KDC returns a session-key type that is not 
+   supported by the GSSAPI implementation (either on the client and the 
+   server). In this case the implementation MUST not try to use the key 
+   with a supported cryptosystem. This will ensure that no security 
+   weaknesses arise due to the use of an inappropriate key with an 
+   encryption algorithm. 
+    
+   In addition the security problem described in [3DES] arising from 
+   the use of a service implementation with a GSSAPI mechanism 
+   supporting only DES and a Kerberos mechanism supporting both DES and 
+   Triple DES is actually a more generic one.  It arises whenever the 
+   GSSAPI implementation does not support a stronger cryptosystem 
+   supported by the Kerberos mechanism.  KDC administrators desiring to 
+   limit the session key types to support interoperability with such 
+   GSSAPI implementations should carefully weigh the reduction in 
+   protection offered by such mechanisms against the benefits of 
+   interoperability. 
+Zhu              Standards Track - February 16, 2004                6 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+    
+   It is recommended by some cryptographers that the output of a 
+   checksum used with an encryption algorithm should have the same 
+   strength as the key in use.  In this regard standardization work for 
+   SHA-256 and SHA-512 to be used with AES is currently in progress. 
+   This document retains the use of HMAC_SHA1_96 as specified in the 
+   [AES-KRB5] draft.  The use of SHA-256 or SHA-512 with AES will 
+   require new crypto profiles and there should not be any further 
+   changes needed to this document.  
+    
+9. Acknowledgments 
+ 
+   
+  The authors wish to acknowledge the contributions from the following 
+  individuals:  
+ 
+  Ken Raeburn and Nicolas Willams corrected many of our errors in the 
+  use of generic profiles and were instrumental in the creation of this 
+  draft. Sam Hartman and Ken Raeburn suggested the "floating trailer" 
+  idea.   
+   
+  Sam Hartman and Nicolas Williams recommended the replacing our 
+  earlier key derivation function for directional keys with different 
+  key usage numbers for each direction as well as retaining the 
+  directional bit for maximum compatibility.   
+   
+  Paul Leach provided numerous suggestions and comments. Scott Field, 
+  Richard Ward, Dan Simon also provided valuable inputs on this draft. 
+ 
+10. References 
+    
+   [AES] National Institute of Standards and Technology, U.S. 
+   Department of Commerce, "Advanced Encryption Standard", Federal 
+   Information Processing Standards Publication 197, Washington, DC, 
+   November 2001. 
+    
+   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
+   raeburn-krb-rijndael-krb-05.txt, June, 2003. Work in progress. 
+    
+   [DES3] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI    
+   Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT    
+   distribution, June 2000. 
+    
+    
+   [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. 
+    
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
+   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in 
+   progress.  
+
+Zhu              Standards Track - February 16, 2004                7 
+          Crypto Profile Support for Kerberos GSSAPI      August 2003 
+ 
+ 
+    
+   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
+   Raeburn, K., "The Kerveros Network Authentication Service (V5)",    
+   http://www.isi.edu/people/bcn/draft-kerberos-rev.html/krb-
+   clarifications-00-020222.txt, February,2002. Work in progress. 
+    
+   [SPNEGO] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
+   Negotiation Mechanism.", RFC 2478, December 1998. 
+    
+11. Author's Address 
+    
+   Larry Zhu 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: LZhu@microsoft.com 
+ 
+   Karthik Jaganathan 
+   One Microsoft Way 
+   Redmond, WA 98052 - USA 
+   EMail: karthikj@microsoft.com 
+ 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu              Standards Track - February 16, 2004                8 
diff --git a/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-09.txt b/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-09.txt
new file mode 100644
index 00000000000..915b9adea79
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-09.txt
@@ -0,0 +1,1080 @@
+

+

+

+

+

+

+Network Working Group                                  Abhijit Menon-Sen

+Internet-Draft                                    Oryx Mail Systems GmbH

+Intended Status: Proposed Standard                          Chris Newman

+Expires: August 2009                                    Sun Microsystems

+                                                         Alexey Melnikov

+                                                               Isode Ltd

+                                                       February 15, 2009

+

+

+            Salted Challenge Response (SCRAM) SASL Mechanism

+

+                     draft-newman-auth-scram-09.txt

+

+

+Status of this Memo

+

+    This Internet-Draft is submitted to IETF in full conformance with

+    the provisions of BCP 78 and BCP 79.

+

+    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 Internet-Draft expires in July 2009.

+

+

+Copyright Notice

+

+    Copyright (c) 2009 IETF Trust and the persons identified as the

+    document authors.  All rights reserved.

+

+    This document is subject to BCP 78 and the IETF Trust's Legal

+    Provisions Relating to IETF Documents

+    (http://trustee.ietf.org/license-info) in effect on the date of

+    publication of this document.  Please review these documents

+    carefully, as they describe your rights and restrictions with

+    respect to this document.

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 1]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+Abstract

+

+    The secure authentication mechanism most widely deployed and used by

+    Internet application protocols is the transmission of clear-text

+    passwords over a channel protected by Transport Layer Security

+    (TLS).  There are some significant security concerns with that

+    mechanism, which could be addressed by the use of a challenge

+    response authentication mechanism protected by TLS. Unfortunately,

+    the challenge response mechanisms presently on the standards track

+    all fail to meet requirements necessary for widespread deployment,

+    and have had success only in limited use.

+

+    This specification describes a family of authentication mechanisms

+    called the Salted Challenge Response Authentication Mechanism

+    (SCRAM), which addresses the security concerns and meets the

+    deployability requirements. When used in combination with TLS or an

+    equivalent security layer, a mechanism from this family could

+    improve the status-quo for application protocol authentication and

+    provide a suitable choice for a mandatory-to-implement mechanism for

+    future application protocol standards.

+

+

+1. 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 [RFC2119].

+

+    Formal syntax is defined by [RFC5234] including the core rules

+    defined in Appendix B of [RFC5234].

+

+    Example lines prefaced by "C:" are sent by the client and ones

+    prefaced by "S:" by the server. If a single "C:" or "S:" label

+    applies to multiple lines, then the line breaks between those lines

+    are for editorial clarity only, and are not part of the actual

+    protocol exchange.

+

+

+1.1. Terminology

+

+    This document uses several terms defined in [RFC4949] ("Internet

+    Security Glossary") including the following: authentication,

+    authentication exchange, authentication information, brute force,

+    challenge-response, cryptographic hash function, dictionary attack,

+    eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,

+    one-way encryption function, password, replay attack and salt.

+    Readers not familiar with these terms should use that glossary as a

+    reference.

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 2]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    Some clarifications and additional definitions follow:

+

+    - Authentication information: Information used to verify an identity

+      claimed by a SCRAM client. The authentication information for a

+      SCRAM identity consists of salt, iteration count, the "StoredKey"

+      and "ServerKey" (as defined in the algorithm overview) for each

+      supported cryptographic hash function.

+

+    - Authentication database: The database used to look up the

+      authentication information associated with a particular identity.

+      For application protocols, LDAPv3 (see [RFC4510]) is frequently

+      used as the authentication database. For network-level protocols

+      such as PPP or 802.11x, the use of RADIUS is more common.

+

+    - Base64: An encoding mechanism defined in [RFC4648] which converts

+      an octet string input to a textual output string which can be

+      easily displayed to a human. The use of base64 in SCRAM is

+      restricted to the canonical form with no whitespace.

+

+    - Octet: An 8-bit byte.

+

+    - Octet string: A sequence of 8-bit bytes.

+

+    - Salt: A random octet string that is combined with a password

+      before applying a one-way encryption function. This value is used

+      to protect passwords that are stored in an authentication

+      database.

+

+

+1.2. Notation

+

+    The pseudocode description of the algorithm uses the following

+    notations:

+

+    - ":=": The variable on the left hand side represents the octet

+      string resulting from the expression on the right hand side.

+

+    - "+": Octet string concatenation.

+

+    - "[ ]": A portion of an expression enclosed in "[" and "]" may not

+      be included in the result under some circumstances. See the

+      associated text for a description of those circumstances.

+

+    - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in

+      [RFC2104]) using the octet string represented by "key" as the key

+      and the octet string "str" as the input string. The size of the

+      result is the hash result size for the hash function in use. For

+      example, it is 20 octets for SHA-1 (see [RFC3174]).

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 3]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    - H(str): Apply the cryptographic hash function to the octet string

+      "str", producing an octet string as a result. The size of the

+      result depends on the hash result size for the hash function in

+      use.

+

+    - XOR: Apply the exclusive-or operation to combine the octet string

+      on the left of this operator with the octet string on the right of

+      this operator. The length of the output and each of the two inputs

+      will be the same for this use.

+

+    - Hi(str, salt):

+

+         U0   := HMAC(str, salt || INT(1))

+         U1   := HMAC(str, U0)

+         U2   := HMAC(str, U1)

+         ...

+         Ui-1 := HMAC(str, Ui-2)

+         Ui   := HMAC(str, Ui-1)

+

+         Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui

+      where "i" is the iteration count, "||" is the string concatenation

+      operator and INT(g) is a four-octet encoding of the integer g,

+      most significant octet first.

+

+      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and

+      with dkLen == output length of HMAC() == output length of H().

+

+

+

+2. Introduction

+

+    This specification describes a family of authentication mechanisms

+    called the Salted Challenge Response Authentication Mechanism

+    (SCRAM) which addresses the requirements necessary to deploy a

+    challenge-response mechanism more widely than past attempts. When

+    used in combination with Transport Layer Security (TLS, see [TLS])

+    or an equivalent security layer, a mechanism from this family could

+    improve the status-quo for application protocol authentication and

+    provide a suitable choice for a mandatory-to-implement mechanism for

+    future application protocol standards.

+

+    For simplicity, this family of mechanism does not presently include

+    negotiation of a security layer. It is intended to be used with an

+    external security layer such as that provided by TLS or SSH.

+

+    SCRAM provides the following protocol features:

+

+    - The authentication information stored in the authentication

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 4]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      database is not sufficient by itself to impersonate the client.

+      The information is salted to prevent a pre-stored dictionary

+      attack if the database is stolen.

+

+    - The server does not gain the ability to impersonate the client to

+      other servers (with an exception for server-authorized proxies).

+

+    - The mechanism permits the use of a server-authorized proxy without

+      requiring that proxy to have super-user rights with the back-end

+      server.

+

+    - A standard attribute is defined to enable storage of the

+      authentication information in LDAPv3 (see [RFC4510]).

+

+    - Both the client and server can be authenticated by the protocol.

+

+    For an in-depth discussion of why other challenge response

+    mechanisms are not considered sufficient, see appendix A. For more

+    information about the motivations behind the design of this

+    mechanism, see appendix B.

+

+    Comments regarding this draft may be sent either to the ietf-

+    sasl@imc.org mailing list or to the authors.

+

+

+3. SCRAM Algorithm Overview

+

+    Note that this section omits some details, such as client and server

+    nonces.  See Section 5 for more details.

+

+    To begin with, the client is in possession of a username and

+    password.  It sends the username to the server, which retrieves the

+    corresponding authentication information, i.e. a salt, StoredKey,

+    ServerKey and the iteration count i. (Note that a server

+    implementation may chose to use the same iteration count for all

+    account.) The server sends the salt and the iteration count to the

+    client, which then computes the following values and sends a

+    ClientProof to the server:

+

+        SaltedPassword  := Hi(password, salt)

+        ClientKey       := H(SaltedPassword)

+        StoredKey       := H(ClientKey)

+        AuthMessage     := client-first-message + "," +

+                           server-first-message + "," +

+                           final-client-message-without-proof

+        ClientSignature := HMAC(StoredKey, AuthMessage)

+        ClientProof     := ClientKey XOR ClientSignature

+        ServerKey       := HMAC(SaltedPassword, salt)

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 5]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+        ServerSignature := HMAC(ServerKey, AuthMessage)

+

+    The server authenticates the client by computing the

+    ClientSignature, exclusive-ORing that with the ClientProof to

+    recover the ClientKey and verifying the correctness of the ClientKey

+    by applying the hash function and comparing the result to the

+    StoredKey. If the ClientKey is correct, this proves that the client

+    has access to the user's password.

+

+    Similarly, the client authenticates the server by computing the

+    ServerSignature and comparing it to the value sent by the server.

+    If the two are equal, it proves that the server had access to the

+    user's ServerKey.

+

+    The AuthMessage is computed by concatenating messages from the

+    authentication exchange. The format of these messages is defined in

+    the Formal Syntax section.

+

+

+4. SCRAM mechanism names

+

+    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the

+    uppercased name of the underlying hashed function taken from the

+    IANA "Hash Function Textual Names" registry (see

+    http://www.iana.org).

+

+    For interoperability, all SCRAM clients and servers MUST implement

+    the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an

+    authentication mechanism from the SCRAM family that uses the SHA-1

+    hash function as defined in [RFC3174].

+

+

+5. SCRAM Authentication Exchange

+

+    SCRAM is a text protocol where the client and server exchange

+    messages containing one or more attribute-value pairs separated by

+    commas. Each attribute has a one-letter name. The messages and their

+    attributes are described in section 5.1, and defined in the Formal

+    Syntax section.

+

+    This is a simple example of a SCRAM-HMAC-SHA-1 authentication

+    exchange:

+        C: n=Chris Newman,r=ClientNonce

+        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

+        C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

+        S: v=WxPv/siO5l+qxN4

+

+    With channel-binding data sent by the client this might look like this:

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 6]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+        C: n=Chris Newman,r=ClientNonce

+        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

+        C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

+        S: v=WxPv/siO5l+qxN4

+

+    <<Note that the channel-bind data above, as well as all hashes are fake>>

+

+    First, the client sends a message containing the username, and a

+    random, unique nonce. In response, the server sends the user's

+    iteration count i, the user's salt, and appends its own nonce to the

+    client-specified one.  The client then responds with the same nonce

+    and a ClientProof computed using the selected hash function as

+    explained earlier.  In this step the client can also include an

+    optional authorization identity.  The server verifies the nonce and

+    the proof, verifies that the authorization identity (if supplied by

+    the client in the second message) is authorized to act as the

+    authentication identity, and, finally, it responds with a

+    ServerSignature, concluding the authentication exchange. The client

+    then authenticates the server by computing the ServerSignature and

+    comparing it to the value sent by the server.  If the two are

+    different, the client MUST consider the authentication exchange to

+    be unsuccessful and it might have to drop the connection.

+

+

+5.1 SCRAM attributes

+

+    This section describes the permissible attributes, their use, and

+    the format of their values. All attribute names are single US-ASCII

+    letters and are case-sensitive.

+

+    - a: This optional attribute specifies an authorization identity. A

+      client may include it in its second message to the server if it

+      wants to authenticate as one user, but subsequently act as a

+      different user.  This is typically used by an administrator to

+      perform some management task on behalf of another user, or by a

+      proxy in some situations.

+

+      Upon the receipt of this value the server verifies its correctness

+      according to the used SASL protocol profile. Failed verification

+      results in failed authentication exchange.

+

+      If this attribute is omitted (as it normally would be), or

+      specified with an empty value, the authorization identity is

+      assumed to be derived from the username specified with the

+      (required) "n" attribute.

+

+      The server always authenticates the user specified by the "n"

+      attribute.  If the "a" attribute specifies a different user, the

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 7]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      server associates that identity with the connection after

+      successful authentication and authorization checks.

+

+      The syntax of this field is the same as that of the "n" field with

+      respect to quoting of '=' and ','.

+

+    - n: This attribute specifies the name of the user whose password is

+      used for authentication. A client must include it in its first

+      message to the server. If the "a" attribute is not specified

+      (which would normally be the case), this username is also the

+      identity which will be associated with the connection subsequent

+      to authentication and authorization.

+

+      Before sending the username to the server, the client MUST prepare

+      the username using the "SASLPrep" profile [SASLPrep] of the

+      "stringprep" algorithm [RFC3454]. If the preparation of the

+      username fails or results in an empty string, the client SHOULD

+      abort the authentication exchange (*).

+

+      (*) An interactive client can request a repeated entry of the

+      username value.

+

+      Upon receipt of the username by the server, the server SHOULD

+      prepare it using the "SASLPrep" profile [SASLPrep] of the

+      "stringprep" algorithm [RFC3454]. If the preparation of the

+      username fails or results in an empty string, the server SHOULD

+      abort the authentication exchange.

+

+      The characters ',' or '=' in usernames are sent as '=2C' and '=3D'

+      respectively. If the server receives a username which contains '='

+      not followed by either '2C' or '3D', then the server MUST fail the

+      authentication.

+

+    - m: This attribute is reserved for future extensibility.  In this

+      version of SCRAM, its presence in a client or a server message

+      MUST cause authentication failure when the attribute is parsed by

+      the other end.

+

+    - r: This attribute specifies a sequence of random printable

+      characters excluding ',' which forms the nonce used as input to

+      the hash function.  No quoting is applied to this string (unless

+      the binding of SCRAM to a particular protocol states otherwise).

+      As described earlier, the client supplies an initial value in its

+      first message, and the server augments that value with its own

+      nonce in its first response. It is important that this be value

+      different for each authentication. The client MUST verify that the

+      initial part of the nonce used in subsequent messages is the same

+      as the nonce it initially specified. The server MUST verify that

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 8]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      the nonce sent by the client in the second message is the same as

+      the one sent by the server in its first message.

+

+    - c: This optional attribute specifies base64-encoded channel-

+      binding data. It is sent by the client in the second step. If

+      specified by the client, if the server supports the specified

+      channel binding type and if the server can't verify it, then the

+      server MUST fail the authentication exchange.  Whether this

+      attribute is included, and the meaning and contents of the

+      channel-binding data depends on the external security layer in

+      use. This is necessary to detect a man-in-the-middle attack on the

+      security layer.

+

+    - s: This attribute specifies the base64-encoded salt used by the

+      server for this user. It is sent by the server in its first

+      message to the client.

+

+    - i: This attribute specifies an iteration count for the selected

+      hash function and user, and must be sent by the server along with

+      the user's salt.

+

+      For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash

+      iteration-count of at least 128.

+

+    - p: This attribute specifies a base64-encoded ClientProof. The

+      client computes this value as described in the overview and sends

+      it to the server.

+

+    - v: This attribute specifies a base64-encoded ServerSignature. It

+      is sent by the server in its final message, and may be used by the

+      client to verify that the server has access to the user's

+      authentication information. This value is computed as explained in

+      the overview.

+

+

+6. Formal Syntax

+

+    The following syntax specification uses the Augmented Backus-Naur

+    Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"

+    and "UTF8-4" non-terminal are defined in [UTF-8].

+

+      generic-message = attr-val *("," attr-val)

+                        ;; Generic syntax of any server challenge

+                        ;; or client response

+

+      attr-val        = ALPHA "=" value

+

+      value           = *(value-char)

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 9]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      value-safe-char = %01-2B / %2D-3C / %3E-7F /

+                        UTF8-2 / UTF-3 / UTF8-4

+                        ;; UTF8-char except NUL, "=", and ",".

+

+      value-char      = value-safe-char / "="

+

+      base64-char     = ALPHA / DIGIT / "/" / "+"

+

+      base64-4        = 4*4(base64-char)

+

+      base64-3        = 3*3(base64-char) "="

+

+      base64-2        = 2*2(base64-char) "=="

+

+      base64          = *(base64-4) [base64-3 / base64-2]

+

+      posit-number = (%x31-39) *DIGIT

+                        ;; A positive number

+

+      saslname        = 1*(value-safe-char / "=2C" / "=3D")

+                        ;; Conforms to <value>

+

+      authzid         = "a=" saslname

+                        ;; Protocol specific.

+

+      username        = "n=" saslname

+                        ;; Usernames are prepared using SASLPrep.

+

+      reserved-mext  = "m=" 1*(value-char)

+                        ;; Reserved for signalling mandatory extensions.

+                        ;; The exact syntax will be defined in

+                        ;; the future.

+

+      channel-binding = "c=" base64

+

+      proof           = "p=" base64

+

+      nonce           = "r=" c-nonce [s-nonce]

+                        ;; Second part provided by server.

+

+      c-nonce         = value

+

+      s-nonce         = value

+

+      salt            = "s=" base64

+

+      verifier        = "v=" base64

+                        ;; base-64 encoded ServerSignature.

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 10]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      iteration-count = "i=" posit-number

+                        ;; A positive number

+

+      client-first-message =

+                        [reserved-mext ","] username "," nonce [","

+                        extensions]

+

+      server-first-message =

+                        [reserved-mext ","] nonce "," salt ","

+                        iteration-count ["," extensions]

+

+      client-final-message-without-proof =

+                        [authzid ","] [channel-binding ","] nonce [","

+                        extensions]

+

+      client-final-message =

+                        client-final-message-without-proof "," proof

+

+      server-final-message =

+                        verifier ["," extensions]

+

+      extensions = attr-val *("," attr-val)

+                        ;; All extensions are optional,

+                        ;; i.e. unrecognized attributes

+                        ;; not defined in this document

+                        ;; MUST be ignored.

+

+

+7. Security Considerations

+

+    If the authentication exchange is performed without a strong

+    security layer, then a passive eavesdropper can gain sufficient

+    information to mount an offline dictionary or brute-force attack

+    which can be used to recover the user's password. The amount of time

+    necessary for this attack depends on the cryptographic hash function

+    selected, the strength of the password and the iteration count

+    supplied by the server. An external security layer with strong

+    encryption will prevent this attack.

+

+    If the external security layer used to protect the SCRAM exchange

+    uses an anonymous key exchange, then the SCRAM channel binding

+    mechanism can be used to detect a man-in-the-middle attack on the

+    security layer and cause the authentication to fail as a result.

+    However, the man-in-the-middle attacker will have gained sufficient

+    information to mount an offline dictionary or brute-force attack.

+    For this reason, SCRAM includes the ability to increase the

+    iteration count over time.

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 11]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    If the authentication information is stolen from the authentication

+    database, then an offline dictionary or brute-force attack can be

+    used to recover the user's password. The use of salt mitigates this

+    attack somewhat by requiring a separate attack on each password.

+    Authentication mechanisms which protect against this attack are

+    available (e.g., the EKE class of mechanisms), but the patent

+    situation is presently unclear.

+

+    If an attacker obtains the authentication information from the

+    authentication repository and either eavesdrops on one

+    authentication exchange or impersonates a server, the attacker gains

+    the ability to impersonate that user to all servers providing SCRAM

+    access using the same hash function, password, iteration count and

+    salt.  For this reason, it is important to use randomly-generated

+    salt values.

+

+    If the server detects (from the value of the client-specified "h"

+    attribute) that both endpoints support a stronger hash function that

+    the one the client actually chooses to use, then it SHOULD treat

+    this as a downgrade attack and reject the authentication attempt.

+

+    A hostile server can perform a computational denial-of-service

+    attack on clients by sending a big iteration count value.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 12]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+8. IANA considerations

+

+    IANA is requested to add the following entry to the SASL Mechanism

+    registry established by [RFC4422]:

+

+    To: iana@iana.org

+    Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1

+

+    SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1

+    Security considerations: Section 7 of [RFCXXXX]

+    Published specification (optional, recommended): [RFCXXXX]

+    Person & email address to contact for further information:

+     IETF SASL WG <ietf-sasl@imc.org>

+    Intended usage: COMMON

+    Owner/Change controller: IESG <iesg@ietf.org>

+    Note:

+

+    Note that even though this document defines a family of SCRAM-HMAC

+    mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in

+    the SASL Mechanisms registry. IANA is requested to prevent future

+    registrations of SASL mechanisms starting with SCRAM-HMAC- without

+    consulting the SASL mailing list <ietf-sasl@imc.org> first.

+

+    Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC

+    SASL mechanism MUST be explicitly registered with IANA and MUST

+    comply with SCRAM-HMAC mechanism naming convention defined in

+    Section 4 of this document.

+

+

+

+9. Acknowedgements

+

+    The authors would like to thank Dave Cridland for his contributions

+    to this document.

+

+

+10. Normative References

+

+    [RFC4648]  Josefsson, "The Base16, Base32, and Base64 Data

+               Encodings", RFC 4648, SJD, October 2006.

+

+    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO

+               10646", STD 63, RFC 3629, November 2003.

+

+    [RFC2104]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for

+               Message Authentication", IBM, February 1997.

+

+    [RFC2119]  Bradner, "Key words for use in RFCs to Indicate

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 13]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+               Requirement Levels", RFC 2119, Harvard University, March

+               1997.

+

+    [RFC3174]  Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC

+               3174, Motorola, September 2001

+

+    [RFC5234]  Crocker, Overell, "Augmented BNF for Syntax

+               Specifications: ABNF", RFC 5234, January 2008.

+

+    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security

+               Layer (SASL)", RFC 4422, Isode Limited, June 2006.

+

+    [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user

+               names and passwords", RFC 4013, February 2005.

+

+    [RFC3454] Hoffman, P., Blanchet, M., "Preparation of

+               Internationalized Strings ("stringprep")", RFC 3454,

+               December 2002.

+

+

+

+11. Informative References

+

+    [RFC2195]  Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension

+               for Simple Challenge/Response", RFC 2195, MCI, September

+               1997.

+

+    [RFC2202]  Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",

+               RFC 2202, IBM, September 1997

+

+    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography

+               Specification Version 2.0", RFC 2898, September 2000.

+

+    [TLS]  Dierks, Rescorla, "The Transport Layer Security (TLS)

+               Protocol, Version 1.2", RFC 5246, August 2008.

+

+    [RFC4949]  Shirey, "Internet Security Glossary, Version 2", RFC

+               4949, FYI 0036, August 2007.

+

+    [RFC4086]  Eastlake, Schiller, Crocker, "Randomness Requirements for

+               Security", RFC 4086, BCP 0106, Motorola Laboratories,

+               June 2005.

+

+    [RFC4510]  Zeilenga, "Lightweight Directory Access Protocol (LDAP):

+               Technical Specification Road Map", RFC 4510, June 2006.

+

+    [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication

+               as a SASL Mechanism", RFC 2831, May 2000.  <<Also draft-

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 14]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+               ietf-sasl-rfc2831bis-12.txt>>

+

+    [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in

+               progress, draft-ietf-sasl-digest-to-historic-00.txt, July

+               2008

+

+    [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress,

+               draft-ietf-sasl-crammd5-to-historic-00.txt, November

+               2008.

+

+    [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security

+               Layer (SASL) Mechanism" RFC 4616, August 2006.

+

+

+12. Authors' Addresses

+

+    Abhijit Menon-Sen

+    Oryx Mail Systems GmbH

+

+    Email: ams@oryx.com

+

+

+    Alexey Melnikov

+    Isode Ltd

+

+    EMail: Alexey.Melnikov@isode.com

+

+

+    Chris Newman

+    Sun Microsystems

+    1050 Lakes Drive

+    West Covina, CA 91790

+    USA

+

+    Email: chris.newman@sun.com

+

+

+Appendix A: Other Authentication Mechanisms

+

+    The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex

+    to implement and test, and thus has poor interoperability. The

+    security layer is often not implemented, and almost never used;

+    everyone uses TLS instead.  For a more complete list of problems

+    with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST-

+    HISTORIC].

+

+    The CRAM-MD5 SASL mechanism, while widely deployed has also some

+    problems, in particular it is missing some modern SASL features such

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 15]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    as support for internationalized usernames and passwords, support

+    for passing of authorization identity, support for channel bindings.

+    It also doesn't support server authentication.  For a more complete

+    list of problems with CRAM-MD5 see [CRAM-HISTORIC].

+

+    The PLAIN [PLAIN] SASL mechanism allows a malicious server or

+    eavesdropper to impersonate the authenticating user to any other

+    server for which the user has the same password. It also sends the

+    password in the clear over the network, unless TLS is used. Server

+    authentication is not supported.

+

+

+Appendix B: Design Motivations

+

+    The following design goals shaped this document. Note that some of

+    the goals have changed since the initial version of the document.

+

+      The SASL mechanism has all modern SASL features: support for

+      internationalized usernames and passwords, support for passing of

+      authorization identity, support for channel bindings.

+

+      Both the client and server can be authenticated by the protocol.

+

+      The authentication information stored in the authentication

+      database is not sufficient by itself to impersonate the client.

+

+      <<The server does not gain the ability to impersonate the client

+      to other servers (with an exception for server-authorized

+      proxies).>>

+

+      The mechanism is extensible, but [hopefully] not overengineered in

+      this respect.

+

+      Easier to implement than DIGEST-MD5 in both clients and servers.

+

+

+Appendix C: SCRAM Examples

+

+    <<To be written.>>

+

+

+

+

+

+

+

+

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 16]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+        (RFC Editor: Please delete everything after this point)

+

+

+Open Issues

+

+    - The appendices need to be written.

+

+    - Should the server send a base64-encoded ServerSignature for the

+      value of the "v" attribute, or should it compute a ServerProof the

+      way the client computes a ClientProof?

+

+

+Changes since -07

+

+    Updated References.

+

+    Clarified purpose of the m= attribute.

+

+    Fixed a problem with authentication/authorization identity's ABNF

+      not allowing for some characters.

+

+    Updated ABNF for nonce to show client-generated and server-generated

+      parts.

+

+    Only register SCRAM-HMAC-SHA-1 with IANA and require explicit

+      registrations of all other SCRAM-HMAC- mechanisms.

+

+

+

+Changes since -06

+

+    Removed hash negotiation from SCRAM and turned it into a family of

+      SASL mechanisms.

+

+    Start using "Hash Function Textual Names" IANA registry for SCRAM

+      mechanism naming.

+

+    Fixed definition of Hi(str, salt) to be consistent with [RFC2898].

+

+    Clarified extensibility of SCRAM: added m= attribute (for future

+      mandatory extensions) and specified that all unrecognized

+      attributes must be ignored.

+

+

+

+Changes since -05

+

+    Changed the mandatory to implement hash algorithm to SHA-1 (as per

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 17]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      WG consensus).

+

+    Added text about use of SASLPrep for username

+      canonicalization/validation.

+

+    Clarified that authorization identity is canonicalized/verified

+      according to SASL protocol profile.

+

+    Clarified that iteration count is per-user.

+

+    Clarified how clients select the authentication function.

+

+    Added IANA registration for the new mechanism.

+

+    Added missing normative references (UTF-8, SASLPrep).

+

+    Various editorial changes based on comments from Hallvard B

+      Furuseth, Nico William and Simon Josefsson.

+

+

+

+Changes since -04

+

+    - Update Base64 and Security Glossary references.

+

+    - Add Formal Syntax section.

+

+    - Don't bother with "v=".

+

+    - Make MD5 mandatory to implement. Suggest i=128.

+

+

+

+Changes since -03

+

+    - Seven years have passed, in which it became clear that DIGEST-MD5

+      suffered from unacceptably bad interoperability, so SCRAM-MD5 is

+      now back from the dead.

+

+    - Be hash agnostic, so MD5 can be replaced more easily.

+

+    - General simplification.

+

+

+

+

+

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 18]

+

+

diff --git a/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-10.txt b/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-10.txt
new file mode 100644
index 00000000000..640046e3291
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-10.txt
@@ -0,0 +1,1080 @@
+

+

+

+

+

+

+Network Working Group                                  Abhijit Menon-Sen

+Internet-Draft                                    Oryx Mail Systems GmbH

+Intended Status: Proposed Standard                          Chris Newman

+Expires: August 2009                                    Sun Microsystems

+                                                         Alexey Melnikov

+                                                               Isode Ltd

+                                                       February 21, 2009

+

+

+            Salted Challenge Response (SCRAM) SASL Mechanism

+

+                     draft-newman-auth-scram-10.txt

+

+

+Status of this Memo

+

+    This Internet-Draft is submitted to IETF in full conformance with

+    the provisions of BCP 78 and BCP 79.

+

+    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 Internet-Draft expires in July 2009.

+

+

+Copyright Notice

+

+    Copyright (c) 2009 IETF Trust and the persons identified as the

+    document authors.  All rights reserved.

+

+    This document is subject to BCP 78 and the IETF Trust's Legal

+    Provisions Relating to IETF Documents

+    (http://trustee.ietf.org/license-info) in effect on the date of

+    publication of this document.  Please review these documents

+    carefully, as they describe your rights and restrictions with

+    respect to this document.

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 1]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+Abstract

+

+    The secure authentication mechanism most widely deployed and used by

+    Internet application protocols is the transmission of clear-text

+    passwords over a channel protected by Transport Layer Security

+    (TLS).  There are some significant security concerns with that

+    mechanism, which could be addressed by the use of a challenge

+    response authentication mechanism protected by TLS. Unfortunately,

+    the challenge response mechanisms presently on the standards track

+    all fail to meet requirements necessary for widespread deployment,

+    and have had success only in limited use.

+

+    This specification describes a family of authentication mechanisms

+    called the Salted Challenge Response Authentication Mechanism

+    (SCRAM), which addresses the security concerns and meets the

+    deployability requirements. When used in combination with TLS or an

+    equivalent security layer, a mechanism from this family could

+    improve the status-quo for application protocol authentication and

+    provide a suitable choice for a mandatory-to-implement mechanism for

+    future application protocol standards.

+

+

+1. 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 [RFC2119].

+

+    Formal syntax is defined by [RFC5234] including the core rules

+    defined in Appendix B of [RFC5234].

+

+    Example lines prefaced by "C:" are sent by the client and ones

+    prefaced by "S:" by the server. If a single "C:" or "S:" label

+    applies to multiple lines, then the line breaks between those lines

+    are for editorial clarity only, and are not part of the actual

+    protocol exchange.

+

+

+1.1. Terminology

+

+    This document uses several terms defined in [RFC4949] ("Internet

+    Security Glossary") including the following: authentication,

+    authentication exchange, authentication information, brute force,

+    challenge-response, cryptographic hash function, dictionary attack,

+    eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,

+    one-way encryption function, password, replay attack and salt.

+    Readers not familiar with these terms should use that glossary as a

+    reference.

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 2]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    Some clarifications and additional definitions follow:

+

+    - Authentication information: Information used to verify an identity

+      claimed by a SCRAM client. The authentication information for a

+      SCRAM identity consists of salt, iteration count, the "StoredKey"

+      and "ServerKey" (as defined in the algorithm overview) for each

+      supported cryptographic hash function.

+

+    - Authentication database: The database used to look up the

+      authentication information associated with a particular identity.

+      For application protocols, LDAPv3 (see [RFC4510]) is frequently

+      used as the authentication database. For network-level protocols

+      such as PPP or 802.11x, the use of RADIUS is more common.

+

+    - Base64: An encoding mechanism defined in [RFC4648] which converts

+      an octet string input to a textual output string which can be

+      easily displayed to a human. The use of base64 in SCRAM is

+      restricted to the canonical form with no whitespace.

+

+    - Octet: An 8-bit byte.

+

+    - Octet string: A sequence of 8-bit bytes.

+

+    - Salt: A random octet string that is combined with a password

+      before applying a one-way encryption function. This value is used

+      to protect passwords that are stored in an authentication

+      database.

+

+

+1.2. Notation

+

+    The pseudocode description of the algorithm uses the following

+    notations:

+

+    - ":=": The variable on the left hand side represents the octet

+      string resulting from the expression on the right hand side.

+

+    - "+": Octet string concatenation.

+

+    - "[ ]": A portion of an expression enclosed in "[" and "]" may not

+      be included in the result under some circumstances. See the

+      associated text for a description of those circumstances.

+

+    - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in

+      [RFC2104]) using the octet string represented by "key" as the key

+      and the octet string "str" as the input string. The size of the

+      result is the hash result size for the hash function in use. For

+      example, it is 20 octets for SHA-1 (see [RFC3174]).

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 3]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    - H(str): Apply the cryptographic hash function to the octet string

+      "str", producing an octet string as a result. The size of the

+      result depends on the hash result size for the hash function in

+      use.

+

+    - XOR: Apply the exclusive-or operation to combine the octet string

+      on the left of this operator with the octet string on the right of

+      this operator. The length of the output and each of the two inputs

+      will be the same for this use.

+

+    - Hi(str, salt):

+

+         U0   := HMAC(str, salt + INT(1))

+         U1   := HMAC(str, U0)

+         U2   := HMAC(str, U1)

+         ...

+         Ui-1 := HMAC(str, Ui-2)

+         Ui   := HMAC(str, Ui-1)

+

+         Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui

+      where "i" is the iteration count, "+" is the string concatenation

+      operator and INT(g) is a four-octet encoding of the integer g,

+      most significant octet first.

+

+      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and

+      with dkLen == output length of HMAC() == output length of H().

+

+

+

+2. Introduction

+

+    This specification describes a family of authentication mechanisms

+    called the Salted Challenge Response Authentication Mechanism

+    (SCRAM) which addresses the requirements necessary to deploy a

+    challenge-response mechanism more widely than past attempts. When

+    used in combination with Transport Layer Security (TLS, see [TLS])

+    or an equivalent security layer, a mechanism from this family could

+    improve the status-quo for application protocol authentication and

+    provide a suitable choice for a mandatory-to-implement mechanism for

+    future application protocol standards.

+

+    For simplicity, this family of mechanism does not presently include

+    negotiation of a security layer. It is intended to be used with an

+    external security layer such as that provided by TLS or SSH.

+

+    SCRAM provides the following protocol features:

+

+    - The authentication information stored in the authentication

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 4]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      database is not sufficient by itself to impersonate the client.

+      The information is salted to prevent a pre-stored dictionary

+      attack if the database is stolen.

+

+    - The server does not gain the ability to impersonate the client to

+      other servers (with an exception for server-authorized proxies).

+

+    - The mechanism permits the use of a server-authorized proxy without

+      requiring that proxy to have super-user rights with the back-end

+      server.

+

+    - A standard attribute is defined to enable storage of the

+      authentication information in LDAPv3 (see [RFC4510]).

+

+    - Both the client and server can be authenticated by the protocol.

+

+    For an in-depth discussion of why other challenge response

+    mechanisms are not considered sufficient, see appendix A. For more

+    information about the motivations behind the design of this

+    mechanism, see appendix B.

+

+    Comments regarding this draft may be sent either to the ietf-

+    sasl@imc.org mailing list or to the authors.

+

+

+3. SCRAM Algorithm Overview

+

+    Note that this section omits some details, such as client and server

+    nonces.  See Section 5 for more details.

+

+    To begin with, the client is in possession of a username and

+    password.  It sends the username to the server, which retrieves the

+    corresponding authentication information, i.e. a salt, StoredKey,

+    ServerKey and the iteration count i. (Note that a server

+    implementation may chose to use the same iteration count for all

+    account.) The server sends the salt and the iteration count to the

+    client, which then computes the following values and sends a

+    ClientProof to the server:

+

+        SaltedPassword  := Hi(password, salt)

+        ClientKey       := H(SaltedPassword)

+        StoredKey       := H(ClientKey)

+        AuthMessage     := client-first-message + "," +

+                           server-first-message + "," +

+                           client-final-message-without-proof

+        ClientSignature := HMAC(StoredKey, AuthMessage)

+        ClientProof     := ClientKey XOR ClientSignature

+        ServerKey       := HMAC(SaltedPassword, salt)

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 5]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+        ServerSignature := HMAC(ServerKey, AuthMessage)

+

+    The server authenticates the client by computing the

+    ClientSignature, exclusive-ORing that with the ClientProof to

+    recover the ClientKey and verifying the correctness of the ClientKey

+    by applying the hash function and comparing the result to the

+    StoredKey. If the ClientKey is correct, this proves that the client

+    has access to the user's password.

+

+    Similarly, the client authenticates the server by computing the

+    ServerSignature and comparing it to the value sent by the server.

+    If the two are equal, it proves that the server had access to the

+    user's ServerKey.

+

+    The AuthMessage is computed by concatenating messages from the

+    authentication exchange. The format of these messages is defined in

+    the Formal Syntax section.

+

+

+4. SCRAM mechanism names

+

+    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the

+    uppercased name of the underlying hashed function taken from the

+    IANA "Hash Function Textual Names" registry (see

+    http://www.iana.org).

+

+    For interoperability, all SCRAM clients and servers MUST implement

+    the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an

+    authentication mechanism from the SCRAM family that uses the SHA-1

+    hash function as defined in [RFC3174].

+

+

+5. SCRAM Authentication Exchange

+

+    SCRAM is a text protocol where the client and server exchange

+    messages containing one or more attribute-value pairs separated by

+    commas. Each attribute has a one-letter name. The messages and their

+    attributes are described in section 5.1, and defined in the Formal

+    Syntax section.

+

+    This is a simple example of a SCRAM-HMAC-SHA-1 authentication

+    exchange:

+        C: n=Chris Newman,r=ClientNonce

+        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

+        C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

+        S: v=WxPv/siO5l+qxN4

+

+    With channel-binding data sent by the client this might look like this:

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 6]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+        C: n=Chris Newman,r=ClientNonce

+        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

+        C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

+        S: v=WxPv/siO5l+qxN4

+

+    <<Note that the channel-bind data above, as well as all hashes are fake>>

+

+    First, the client sends a message containing the username, and a

+    random, unique nonce. In response, the server sends the user's

+    iteration count i, the user's salt, and appends its own nonce to the

+    client-specified one.  The client then responds with the same nonce

+    and a ClientProof computed using the selected hash function as

+    explained earlier.  In this step the client can also include an

+    optional authorization identity.  The server verifies the nonce and

+    the proof, verifies that the authorization identity (if supplied by

+    the client in the second message) is authorized to act as the

+    authentication identity, and, finally, it responds with a

+    ServerSignature, concluding the authentication exchange. The client

+    then authenticates the server by computing the ServerSignature and

+    comparing it to the value sent by the server.  If the two are

+    different, the client MUST consider the authentication exchange to

+    be unsuccessful and it might have to drop the connection.

+

+

+5.1 SCRAM attributes

+

+    This section describes the permissible attributes, their use, and

+    the format of their values. All attribute names are single US-ASCII

+    letters and are case-sensitive.

+

+    - a: This optional attribute specifies an authorization identity. A

+      client may include it in its second message to the server if it

+      wants to authenticate as one user, but subsequently act as a

+      different user.  This is typically used by an administrator to

+      perform some management task on behalf of another user, or by a

+      proxy in some situations.

+

+      Upon the receipt of this value the server verifies its correctness

+      according to the used SASL protocol profile. Failed verification

+      results in failed authentication exchange.

+

+      If this attribute is omitted (as it normally would be), or

+      specified with an empty value, the authorization identity is

+      assumed to be derived from the username specified with the

+      (required) "n" attribute.

+

+      The server always authenticates the user specified by the "n"

+      attribute.  If the "a" attribute specifies a different user, the

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 7]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      server associates that identity with the connection after

+      successful authentication and authorization checks.

+

+      The syntax of this field is the same as that of the "n" field with

+      respect to quoting of '=' and ','.

+

+    - n: This attribute specifies the name of the user whose password is

+      used for authentication. A client must include it in its first

+      message to the server. If the "a" attribute is not specified

+      (which would normally be the case), this username is also the

+      identity which will be associated with the connection subsequent

+      to authentication and authorization.

+

+      Before sending the username to the server, the client MUST prepare

+      the username using the "SASLPrep" profile [SASLPrep] of the

+      "stringprep" algorithm [RFC3454]. If the preparation of the

+      username fails or results in an empty string, the client SHOULD

+      abort the authentication exchange (*).

+

+      (*) An interactive client can request a repeated entry of the

+      username value.

+

+      Upon receipt of the username by the server, the server SHOULD

+      prepare it using the "SASLPrep" profile [SASLPrep] of the

+      "stringprep" algorithm [RFC3454]. If the preparation of the

+      username fails or results in an empty string, the server SHOULD

+      abort the authentication exchange.

+

+      The characters ',' or '=' in usernames are sent as '=2C' and '=3D'

+      respectively. If the server receives a username which contains '='

+      not followed by either '2C' or '3D', then the server MUST fail the

+      authentication.

+

+    - m: This attribute is reserved for future extensibility.  In this

+      version of SCRAM, its presence in a client or a server message

+      MUST cause authentication failure when the attribute is parsed by

+      the other end.

+

+    - r: This attribute specifies a sequence of random printable

+      characters excluding ',' which forms the nonce used as input to

+      the hash function.  No quoting is applied to this string (<<unless

+      the binding of SCRAM to a particular protocol states otherwise>>).

+      As described earlier, the client supplies an initial value in its

+      first message, and the server augments that value with its own

+      nonce in its first response. It is important that this be value

+      different for each authentication. The client MUST verify that the

+      initial part of the nonce used in subsequent messages is the same

+      as the nonce it initially specified. The server MUST verify that

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 8]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      the nonce sent by the client in the second message is the same as

+      the one sent by the server in its first message.

+

+    - c: This optional attribute specifies base64-encoded channel-

+      binding data. It is sent by the client in the second step. If

+      specified by the client, if the server supports the specified

+      channel binding type and if the server can't verify it, then the

+      server MUST fail the authentication exchange.  Whether this

+      attribute is included, and the meaning and contents of the

+      channel-binding data depends on the external security layer in

+      use. This is necessary to detect a man-in-the-middle attack on the

+      security layer.

+

+    - s: This attribute specifies the base64-encoded salt used by the

+      server for this user. It is sent by the server in its first

+      message to the client.

+

+    - i: This attribute specifies an iteration count for the selected

+      hash function and user, and must be sent by the server along with

+      the user's salt.

+

+      For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash

+      iteration-count of at least 128.

+

+    - p: This attribute specifies a base64-encoded ClientProof. The

+      client computes this value as described in the overview and sends

+      it to the server.

+

+    - v: This attribute specifies a base64-encoded ServerSignature. It

+      is sent by the server in its final message, and may be used by the

+      client to verify that the server has access to the user's

+      authentication information. This value is computed as explained in

+      the overview.

+

+

+6. Formal Syntax

+

+    The following syntax specification uses the Augmented Backus-Naur

+    Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"

+    and "UTF8-4" non-terminal are defined in [UTF-8].

+

+      generic-message = attr-val *("," attr-val)

+                        ;; Generic syntax of any server challenge

+                        ;; or client response

+

+      attr-val        = ALPHA "=" value

+

+      value           = 1*(value-char)

+

+

+

+Menon-Sen & Co             Expires August 2009                FF[Page 9]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      value-safe-char = %01-2B / %2D-3C / %3E-7F /

+                        UTF8-2 / UTF-3 / UTF8-4

+                        ;; UTF8-char except NUL, "=", and ",".

+

+      value-char      = value-safe-char / "="

+

+      base64-char     = ALPHA / DIGIT / "/" / "+"

+

+      base64-4        = 4*4(base64-char)

+

+      base64-3        = 3*3(base64-char) "="

+

+      base64-2        = 2*2(base64-char) "=="

+

+      base64          = *(base64-4) [base64-3 / base64-2]

+

+      posit-number = (%x31-39) *DIGIT

+                        ;; A positive number

+

+      saslname        = 1*(value-safe-char / "=2C" / "=3D")

+                        ;; Conforms to <value>

+

+      authzid         = "a=" saslname

+                        ;; Protocol specific.

+

+      username        = "n=" saslname

+                        ;; Usernames are prepared using SASLPrep.

+

+      reserved-mext  = "m=" 1*(value-char)

+                        ;; Reserved for signalling mandatory extensions.

+                        ;; The exact syntax will be defined in

+                        ;; the future.

+

+      channel-binding = "c=" base64

+

+      proof           = "p=" base64

+

+      nonce           = "r=" c-nonce [s-nonce]

+                        ;; Second part provided by server.

+

+      c-nonce         = value

+

+      s-nonce         = value

+

+      salt            = "s=" base64

+

+      verifier        = "v=" base64

+                        ;; base-64 encoded ServerSignature.

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 10]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      iteration-count = "i=" posit-number

+                        ;; A positive number

+

+      client-first-message =

+                        [reserved-mext ","] username "," nonce [","

+                        extensions]

+

+      server-first-message =

+                        [reserved-mext ","] nonce "," salt ","

+                        iteration-count ["," extensions]

+

+      client-final-message-without-proof =

+                        [authzid ","] [channel-binding ","] nonce [","

+                        extensions]

+

+      client-final-message =

+                        client-final-message-without-proof "," proof

+

+      server-final-message =

+                        verifier ["," extensions]

+

+      extensions = attr-val *("," attr-val)

+                        ;; All extensions are optional,

+                        ;; i.e. unrecognized attributes

+                        ;; not defined in this document

+                        ;; MUST be ignored.

+

+

+7. Security Considerations

+

+    If the authentication exchange is performed without a strong

+    security layer, then a passive eavesdropper can gain sufficient

+    information to mount an offline dictionary or brute-force attack

+    which can be used to recover the user's password. The amount of time

+    necessary for this attack depends on the cryptographic hash function

+    selected, the strength of the password and the iteration count

+    supplied by the server. An external security layer with strong

+    encryption will prevent this attack.

+

+    If the external security layer used to protect the SCRAM exchange

+    uses an anonymous key exchange, then the SCRAM channel binding

+    mechanism can be used to detect a man-in-the-middle attack on the

+    security layer and cause the authentication to fail as a result.

+    However, the man-in-the-middle attacker will have gained sufficient

+    information to mount an offline dictionary or brute-force attack.

+    For this reason, SCRAM includes the ability to increase the

+    iteration count over time.

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 11]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    If the authentication information is stolen from the authentication

+    database, then an offline dictionary or brute-force attack can be

+    used to recover the user's password. The use of salt mitigates this

+    attack somewhat by requiring a separate attack on each password.

+    Authentication mechanisms which protect against this attack are

+    available (e.g., the EKE class of mechanisms), but the patent

+    situation is presently unclear.

+

+    If an attacker obtains the authentication information from the

+    authentication repository and either eavesdrops on one

+    authentication exchange or impersonates a server, the attacker gains

+    the ability to impersonate that user to all servers providing SCRAM

+    access using the same hash function, password, iteration count and

+    salt.  For this reason, it is important to use randomly-generated

+    salt values.

+

+    If the server detects (from the value of the client-specified "h"

+    attribute) that both endpoints support a stronger hash function that

+    the one the client actually chooses to use, then it SHOULD treat

+    this as a downgrade attack and reject the authentication attempt.

+

+    A hostile server can perform a computational denial-of-service

+    attack on clients by sending a big iteration count value.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 12]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+8. IANA considerations

+

+    IANA is requested to add the following entry to the SASL Mechanism

+    registry established by [RFC4422]:

+

+    To: iana@iana.org

+    Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1

+

+    SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1

+    Security considerations: Section 7 of [RFCXXXX]

+    Published specification (optional, recommended): [RFCXXXX]

+    Person & email address to contact for further information:

+     IETF SASL WG <ietf-sasl@imc.org>

+    Intended usage: COMMON

+    Owner/Change controller: IESG <iesg@ietf.org>

+    Note:

+

+    Note that even though this document defines a family of SCRAM-HMAC

+    mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in

+    the SASL Mechanisms registry. IANA is requested to prevent future

+    registrations of SASL mechanisms starting with SCRAM-HMAC- without

+    consulting the SASL mailing list <ietf-sasl@imc.org> first.

+

+    Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC

+    SASL mechanism MUST be explicitly registered with IANA and MUST

+    comply with SCRAM-HMAC mechanism naming convention defined in

+    Section 4 of this document.

+

+

+

+9. Acknowedgements

+

+    The authors would like to thank Dave Cridland for his contributions

+    to this document.

+

+

+10. Normative References

+

+    [RFC4648]  Josefsson, "The Base16, Base32, and Base64 Data

+               Encodings", RFC 4648, SJD, October 2006.

+

+    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO

+               10646", STD 63, RFC 3629, November 2003.

+

+    [RFC2104]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for

+               Message Authentication", IBM, February 1997.

+

+    [RFC2119]  Bradner, "Key words for use in RFCs to Indicate

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 13]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+               Requirement Levels", RFC 2119, Harvard University, March

+               1997.

+

+    [RFC3174]  Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC

+               3174, Motorola, September 2001

+

+    [RFC5234]  Crocker, Overell, "Augmented BNF for Syntax

+               Specifications: ABNF", RFC 5234, January 2008.

+

+    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security

+               Layer (SASL)", RFC 4422, Isode Limited, June 2006.

+

+    [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user

+               names and passwords", RFC 4013, February 2005.

+

+    [RFC3454] Hoffman, P., Blanchet, M., "Preparation of

+               Internationalized Strings ("stringprep")", RFC 3454,

+               December 2002.

+

+

+

+11. Informative References

+

+    [RFC2195]  Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension

+               for Simple Challenge/Response", RFC 2195, MCI, September

+               1997.

+

+    [RFC2202]  Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",

+               RFC 2202, IBM, September 1997

+

+    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography

+               Specification Version 2.0", RFC 2898, September 2000.

+

+    [TLS]  Dierks, Rescorla, "The Transport Layer Security (TLS)

+               Protocol, Version 1.2", RFC 5246, August 2008.

+

+    [RFC4949]  Shirey, "Internet Security Glossary, Version 2", RFC

+               4949, FYI 0036, August 2007.

+

+    [RFC4086]  Eastlake, Schiller, Crocker, "Randomness Requirements for

+               Security", RFC 4086, BCP 0106, Motorola Laboratories,

+               June 2005.

+

+    [RFC4510]  Zeilenga, "Lightweight Directory Access Protocol (LDAP):

+               Technical Specification Road Map", RFC 4510, June 2006.

+

+    [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication

+               as a SASL Mechanism", RFC 2831, May 2000.  <<Also draft-

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 14]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+               ietf-sasl-rfc2831bis-12.txt>>

+

+    [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in

+               progress, draft-ietf-sasl-digest-to-historic-00.txt, July

+               2008

+

+    [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress,

+               draft-ietf-sasl-crammd5-to-historic-00.txt, November

+               2008.

+

+    [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security

+               Layer (SASL) Mechanism" RFC 4616, August 2006.

+

+

+12. Authors' Addresses

+

+    Abhijit Menon-Sen

+    Oryx Mail Systems GmbH

+

+    Email: ams@oryx.com

+

+

+    Alexey Melnikov

+    Isode Ltd

+

+    EMail: Alexey.Melnikov@isode.com

+

+

+    Chris Newman

+    Sun Microsystems

+    1050 Lakes Drive

+    West Covina, CA 91790

+    USA

+

+    Email: chris.newman@sun.com

+

+

+Appendix A: Other Authentication Mechanisms

+

+    The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex

+    to implement and test, and thus has poor interoperability. The

+    security layer is often not implemented, and almost never used;

+    everyone uses TLS instead.  For a more complete list of problems

+    with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST-

+    HISTORIC].

+

+    The CRAM-MD5 SASL mechanism, while widely deployed has also some

+    problems, in particular it is missing some modern SASL features such

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 15]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+    as support for internationalized usernames and passwords, support

+    for passing of authorization identity, support for channel bindings.

+    It also doesn't support server authentication.  For a more complete

+    list of problems with CRAM-MD5 see [CRAM-HISTORIC].

+

+    The PLAIN [PLAIN] SASL mechanism allows a malicious server or

+    eavesdropper to impersonate the authenticating user to any other

+    server for which the user has the same password. It also sends the

+    password in the clear over the network, unless TLS is used. Server

+    authentication is not supported.

+

+

+Appendix B: Design Motivations

+

+    The following design goals shaped this document. Note that some of

+    the goals have changed since the initial version of the document.

+

+      The SASL mechanism has all modern SASL features: support for

+      internationalized usernames and passwords, support for passing of

+      authorization identity, support for channel bindings.

+

+      Both the client and server can be authenticated by the protocol.

+

+      The authentication information stored in the authentication

+      database is not sufficient by itself to impersonate the client.

+

+      <<The server does not gain the ability to impersonate the client

+      to other servers (with an exception for server-authorized

+      proxies).>>

+

+      The mechanism is extensible, but [hopefully] not overengineered in

+      this respect.

+

+      Easier to implement than DIGEST-MD5 in both clients and servers.

+

+

+Appendix C: SCRAM Examples

+

+    <<To be written.>>

+

+

+

+

+

+

+

+

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 16]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+        (RFC Editor: Please delete everything after this point)

+

+

+Open Issues

+

+    - The appendices need to be written.

+

+    - Should the server send a base64-encoded ServerSignature for the

+      value of the "v" attribute, or should it compute a ServerProof the

+      way the client computes a ClientProof?

+

+

+Changes since -07

+

+    Updated References.

+

+    Clarified purpose of the m= attribute.

+

+    Fixed a problem with authentication/authorization identity's ABNF

+      not allowing for some characters.

+

+    Updated ABNF for nonce to show client-generated and server-generated

+      parts.

+

+    Only register SCRAM-HMAC-SHA-1 with IANA and require explicit

+      registrations of all other SCRAM-HMAC- mechanisms.

+

+

+

+Changes since -06

+

+    Removed hash negotiation from SCRAM and turned it into a family of

+      SASL mechanisms.

+

+    Start using "Hash Function Textual Names" IANA registry for SCRAM

+      mechanism naming.

+

+    Fixed definition of Hi(str, salt) to be consistent with [RFC2898].

+

+    Clarified extensibility of SCRAM: added m= attribute (for future

+      mandatory extensions) and specified that all unrecognized

+      attributes must be ignored.

+

+

+

+Changes since -05

+

+    Changed the mandatory to implement hash algorithm to SHA-1 (as per

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 17]

+

+

+

+

+

+Internet-draft                                             February 2009

+

+

+      WG consensus).

+

+    Added text about use of SASLPrep for username

+      canonicalization/validation.

+

+    Clarified that authorization identity is canonicalized/verified

+      according to SASL protocol profile.

+

+    Clarified that iteration count is per-user.

+

+    Clarified how clients select the authentication function.

+

+    Added IANA registration for the new mechanism.

+

+    Added missing normative references (UTF-8, SASLPrep).

+

+    Various editorial changes based on comments from Hallvard B

+      Furuseth, Nico William and Simon Josefsson.

+

+

+

+Changes since -04

+

+    - Update Base64 and Security Glossary references.

+

+    - Add Formal Syntax section.

+

+    - Don't bother with "v=".

+

+    - Make MD5 mandatory to implement. Suggest i=128.

+

+

+

+Changes since -03

+

+    - Seven years have passed, in which it became clear that DIGEST-MD5

+      suffered from unacceptably bad interoperability, so SCRAM-MD5 is

+      now back from the dead.

+

+    - Be hash agnostic, so MD5 can be replaced more easily.

+

+    - General simplification.

+

+

+

+

+

+

+

+

+

+Menon-Sen & Co             Expires August 2009               FF[Page 18]

+

+

diff --git a/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-11.txt b/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-11.txt
new file mode 100644
index 00000000000..4b6abfb02ca
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-newman-auth-scram-11.txt
@@ -0,0 +1,1904 @@
+
+
+
+NETWORK WORKING GROUP                                       A. Menon-Sen
+Internet-Draft                                    Oryx Mail Systems GmbH
+Intended status: Standards Track                             A. Melnikov
+Expires: September 24, 2009                                    Isode Ltd
+                                                               C. Newman
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                          March 23, 2009
+
+
+            Salted Challenge Response (SCRAM) SASL Mechanism
+                     draft-newman-auth-scram-11.txt
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   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 Internet-Draft will expire on September 24, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 1]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+Abstract
+
+   The secure authentication mechanism most widely deployed and used by
+   Internet application protocols is the transmission of clear-text
+   passwords over a channel protected by Transport Layer Security (TLS).
+   There are some significant security concerns with that mechanism,
+   which could be addressed by the use of a challenge response
+   authentication mechanism protected by TLS.  Unfortunately, the
+   challenge response mechanisms presently on the standards track all
+   fail to meet requirements necessary for widespread deployment, and
+   have had success only in limited use.
+
+   This specification describes a family of authentication mechanisms
+   called the Salted Challenge Response Authentication Mechanism
+   (SCRAM), which addresses the security concerns and meets the
+   deployability requirements.  When used in combination with TLS or an
+   equivalent security layer, a mechanism from this family could improve
+   the status-quo for application protocol authentication and provide a
+   suitable choice for a mandatory-to-implement mechanism for future
+   application protocol standards.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 2]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+Table of Contents
+
+   1.          Conventions Used in This Document  . . . . . . . . . .  4
+   1.1.        Terminology  . . . . . . . . . . . . . . . . . . . . .  4
+   1.2.        Notation . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.          Introduction . . . . . . . . . . . . . . . . . . . . .  7
+   3.          SCRAM Algorithm Overview . . . . . . . . . . . . . . .  9
+   4.          SCRAM Mechanism Names  . . . . . . . . . . . . . . . . 10
+   5.          SCRAM Authentication Exchange  . . . . . . . . . . . . 11
+   5.1.        SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
+   6.          Channel Binding  . . . . . . . . . . . . . . . . . . . 15
+   6.1.        Channel Binding to TLS Channels  . . . . . . . . . . . 16
+   7.          Formal Syntax  . . . . . . . . . . . . . . . . . . . . 17
+   8.          SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
+   8.1.        GSS-API Principal Name Types for SCRAM . . . . . . . . 20
+   8.2.        GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
+   8.3.        GSS_Pseudo_random() for SCRAM  . . . . . . . . . . . . 21
+   9.          Security Considerations  . . . . . . . . . . . . . . . 22
+   10.         IANA Considerations  . . . . . . . . . . . . . . . . . 24
+   11.         Acknowledgements . . . . . . . . . . . . . . . . . . . 25
+   Appendix A. Other Authentication Mechanisms  . . . . . . . . . . . 26
+   Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 27
+   Appendix C. SCRAM Examples and Internet-Draft Change History . . . 28
+   12.         References . . . . . . . . . . . . . . . . . . . . . . 31
+   12.1.       Normative References . . . . . . . . . . . . . . . . . 31
+   12.2.       Normative References for GSS-API implementors  . . . . 31
+   12.3.       Informative References . . . . . . . . . . . . . . . . 32
+               Authors' Addresses . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 3]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+1.  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 [RFC2119].
+
+   Formal syntax is defined by [RFC5234] including the core rules
+   defined in Appendix B of [RFC5234].
+
+   Example lines prefaced by "C:" are sent by the client and ones
+   prefaced by "S:" by the server.  If a single "C:" or "S:" label
+   applies to multiple lines, then the line breaks between those lines
+   are for editorial clarity only, and are not part of the actual
+   protocol exchange.
+
+1.1.  Terminology
+
+   This document uses several terms defined in [RFC4949] ("Internet
+   Security Glossary") including the following: authentication,
+   authentication exchange, authentication information, brute force,
+   challenge-response, cryptographic hash function, dictionary attack,
+   eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
+   one-way encryption function, password, replay attack and salt.
+   Readers not familiar with these terms should use that glossary as a
+   reference.
+
+   Some clarifications and additional definitions follow:
+
+   o  Authentication information: Information used to verify an identity
+      claimed by a SCRAM client.  The authentication information for a
+      SCRAM identity consists of salt, iteration count, the "StoredKey"
+      and "ServerKey" (as defined in the algorithm overview) for each
+      supported cryptographic hash function.
+
+   o  Authentication database: The database used to look up the
+      authentication information associated with a particular identity.
+      For application protocols, LDAPv3 (see [RFC4510]) is frequently
+      used as the authentication database.  For network-level protocols
+      such as PPP or 802.11x, the use of RADIUS is more common.
+
+   o  Base64: An encoding mechanism defined in [RFC4648] which converts
+      an octet string input to a textual output string which can be
+      easily displayed to a human.  The use of base64 in SCRAM is
+      restricted to the canonical form with no whitespace.
+
+   o  Octet: An 8-bit byte.
+
+   o  Octet string: A sequence of 8-bit bytes.
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 4]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   o  Salt: A random octet string that is combined with a password
+      before applying a one-way encryption function.  This value is used
+      to protect passwords that are stored in an authentication
+      database.
+
+1.2.  Notation
+
+   The pseudocode description of the algorithm uses the following
+   notations:
+
+   o  ":=": The variable on the left hand side represents the octet
+      string resulting from the expression on the right hand side.
+
+   o  "+": Octet string concatenation.
+
+   o  "[ ]": A portion of an expression enclosed in "[" and "]" may not
+      be included in the result under some circumstances.  See the
+      associated text for a description of those circumstances.
+
+   o  HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
+      [RFC2104]) using the octet string represented by "key" as the key
+      and the octet string "str" as the input string.  The size of the
+      result is the hash result size for the hash function in use.  For
+      example, it is 20 octets for SHA-1 (see [RFC3174]).
+
+   o  H(str): Apply the cryptographic hash function to the octet string
+      "str", producing an octet string as a result.  The size of the
+      result depends on the hash result size for the hash function in
+      use.
+
+   o  XOR: Apply the exclusive-or operation to combine the octet string
+      on the left of this operator with the octet string on the right of
+      this operator.  The length of the output and each of the two
+      inputs will be the same for this use.
+
+   o  Hi(str, salt):
+
+
+
+      U0   := HMAC(str, salt + INT(1))
+      U1   := HMAC(str, U0)
+      U2   := HMAC(str, U1)
+      ...
+      Ui-1 := HMAC(str, Ui-2)
+      Ui   := HMAC(str, Ui-1)
+
+      Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 5]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+      where "i" is the iteration count, "+" is the string concatenation
+      operator and INT(g) is a four-octet encoding of the integer g,
+      most significant octet first.
+
+   o  This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
+      with dkLen == output length of HMAC() == output length of H().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 6]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+2.  Introduction
+
+   This specification describes a family of authentication mechanisms
+   called the Salted Challenge Response Authentication Mechanism (SCRAM)
+   which addresses the requirements necessary to deploy a challenge-
+   response mechanism more widely than past attempts.  When used in
+   combination with Transport Layer Security (TLS, see [RFC5246]) or an
+   equivalent security layer, a mechanism from this family could improve
+   the status-quo for application protocol authentication and provide a
+   suitable choice for a mandatory-to-implement mechanism for future
+   application protocol standards.
+
+   For simplicity, this family of mechanism does not presently include
+   negotiation of a security layer.  It is intended to be used with an
+   external security layer such as that provided by TLS or SSH, with
+   optional channel binding [RFC5056] to the external security layer.
+
+   SCRAM is specified herein as a pure Simple Authentication and
+   Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
+   bridge between SASL and the Generic Security Services Application
+   Programming Interface (GSS-API) called "GS2" [ref-needed].  This
+   means that SCRAM is actually both, a GSS-API and SASL mechanism.
+
+   SCRAM provides the following protocol features:
+
+   o  The authentication information stored in the authentication
+      database is not sufficient by itself to impersonate the client.
+      The information is salted to prevent a pre-stored dictionary
+      attack if the database is stolen.
+
+   o  The server does not gain the ability to impersonate the client to
+      other servers (with an exception for server-authorized proxies).
+
+   o  The mechanism permits the use of a server-authorized proxy without
+      requiring that proxy to have super-user rights with the back-end
+      server.
+
+   o  A standard attribute is defined to enable storage of the
+      authentication information in LDAPv3 (see [RFC4510]).
+
+   o  Mutual authentication is supported, but only the client is named
+      (i.e., the server has no name).
+
+   For an in-depth discussion of why other challenge response mechanisms
+   are not considered sufficient, see appendix A.  For more information
+   about the motivations behind the design of this mechanism, see
+   appendix B.
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 7]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   Comments regarding this draft may be sent either to the
+   ietf-sasl@imc.org mailing list or to the authors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 8]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+3.  SCRAM Algorithm Overview
+
+   Note that this section omits some details, such as client and server
+   nonces.  See Section 5 for more details.
+
+   To begin with, the client is in possession of a username and
+   password.  It sends the username to the server, which retrieves the
+   corresponding authentication information, i.e. a salt, StoredKey,
+   ServerKey and the iteration count i.  (Note that a server
+   implementation may chose to use the same iteration count for all
+   account.)  The server sends the salt and the iteration count to the
+   client, which then computes the following values and sends a
+   ClientProof to the server:
+
+
+      SaltedPassword  := Hi(password, salt)
+      ClientKey       := H(SaltedPassword)
+      StoredKey       := H(ClientKey)
+      AuthMessage     := client-first-message + "," +
+                         server-first-message + "," +
+                         client-final-message-without-proof
+      ClientSignature := HMAC(StoredKey, AuthMessage)
+      ClientProof     := ClientKey XOR ClientSignature
+      ServerKey       := HMAC(SaltedPassword, salt)
+      ServerSignature := HMAC(ServerKey, AuthMessage)
+
+
+   The server authenticates the client by computing the ClientSignature,
+   exclusive-ORing that with the ClientProof to recover the ClientKey
+   and verifying the correctness of the ClientKey by applying the hash
+   function and comparing the result to the StoredKey.  If the ClientKey
+   is correct, this proves that the client has access to the user's
+   password.
+
+   Similarly, the client authenticates the server by computing the
+   ServerSignature and comparing it to the value sent by the server.  If
+   the two are equal, it proves that the server had access to the user's
+   ServerKey.
+
+   The AuthMessage is computed by concatenating messages from the
+   authentication exchange.  The format of these messages is defined in
+   Section 7.
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009               [Page 9]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+4.  SCRAM Mechanism Names
+
+   A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
+   uppercased name of the underlying hashed function taken from the IANA
+   "Hash Function Textual Names" registry (see http://www.iana.org),
+   optionally followed by the suffix "-PLUS" (see below)..
+
+   For interoperability, all SCRAM clients and servers MUST implement
+   the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an authentication
+   mechanism from the SCRAM family that uses the SHA-1 hash function as
+   defined in [RFC3174].
+
+   The "-PLUS" suffix is used only when the server supports channel
+   binding to the external channel.  In this case the server will
+   advertise both, SCRAM-HMAC-SHA-1 and SCRAM-HMAC-SHA-1-PLUS, otherwise
+   the server will advertise only SCRAM-HMAC-SHA-1.  The "-PLUS" exists
+   to allow negotiation of the use of channel binding.  See Section 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 10]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+5.  SCRAM Authentication Exchange
+
+   SCRAM is a text protocol where the client and server exchange
+   messages containing one or more attribute-value pairs separated by
+   commas.  Each attribute has a one-letter name.  The messages and
+   their attributes are described in Section 5.1, and defined in
+   Section 7.
+
+   This is a simple example of a SCRAM-HMAC-SHA-1 authentication
+   exchange:
+
+
+      C: n,n=Chris Newman,r=ClientNonce
+      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
+      C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
+      S: v=WxPv/siO5l+qxN4
+
+
+   With channel-binding data sent by the client this might look like
+   this:
+
+
+      C: p,n=Chris Newman,r=ClientNonce
+      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
+      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
+      S: v=WxPv/siO5l+qxN4
+
+
+   <<Note that the channel-bind data above, as well as all hashes are
+   fake>>
+
+   First, the client sends a message containing:
+
+   o  a GS2 header consisting of a flag indicating whether channel
+      binding is supported-but-not-used, not supported, or used, and the
+      SASL authzid (optional);
+
+   o  SCRAM username and client nonce attributes.
+
+   Note that the client's first message will always start with "n", "y"
+   or "p", otherwise the message is invalid and authentication MUST
+   fail.  This is important, as it allows for GS2 extensibility (e.g.,
+   to add support for security layers).
+
+   In response, the server sends the user's iteration count i, the
+   user's salt, and appends its own nonce to the client-specified one.
+   The client then responds with the same nonce and a ClientProof
+   computed using the selected hash function as explained earlier.  In
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 11]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   this step the client can also include an optional authorization
+   identity.  The server verifies the nonce and the proof, verifies that
+   the authorization identity (if supplied by the client in the second
+   message) is authorized to act as the authentication identity, and,
+   finally, it responds with a ServerSignature, concluding the
+   authentication exchange.  The client then authenticates the server by
+   computing the ServerSignature and comparing it to the value sent by
+   the server.  If the two are different, the client MUST consider the
+   authentication exchange to be unsuccessful and it might have to drop
+   the connection.
+
+5.1.  SCRAM Attributes
+
+   This section describes the permissible attributes, their use, and the
+   format of their values.  All attribute names are single US-ASCII
+   letters and are case-sensitive.
+
+   o  a: This is an optional attribute, and is part of the GS2 [ref-
+      needed] bridge between the GSS-API and SASL.  This attribute
+      specifies an authorization identity.  A client may include it in
+      its second message to the server if it wants to authenticate as
+      one user, but subsequently act as a different user.  This is
+      typically used by an administrator to perform some management task
+      on behalf of another user, or by a proxy in some situations.
+
+         Upon the receipt of this value the server verifies its
+         correctness according to the used SASL protocol profile.
+         Failed verification results in failed authentication exchange.
+
+         If this attribute is omitted (as it normally would be), or
+         specified with an empty value, the authorization identity is
+         assumed to be derived from the username specified with the
+         (required) "n" attribute.
+
+         The server always authenticates the user specified by the "n"
+         attribute.  If the "a" attribute specifies a different user,
+         the server associates that identity with the connection after
+         successful authentication and authorization checks.
+
+         The syntax of this field is the same as that of the "n" field
+         with respect to quoting of '=' and ','.
+
+   o  n: This attribute specifies the name of the user whose password is
+      used for authentication.  A client must include it in its first
+      message to the server.  If the "a" attribute is not specified
+      (which would normally be the case), this username is also the
+      identity which will be associated with the connection subsequent
+      to authentication and authorization.
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 12]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+         Before sending the username to the server, the client MUST
+         prepare the username using the "SASLPrep" profile [RFC4013] of
+         the "stringprep" algorithm [RFC3454].  If the preparation of
+         the username fails or results in an empty string, the client
+         SHOULD abort the authentication exchange (*).
+
+         (*) An interactive client can request a repeated entry of the
+         username value.
+
+         Upon receipt of the username by the server, the server SHOULD
+         prepare it using the "SASLPrep" profile [RFC4013] of the
+         "stringprep" algorithm [RFC3454].  If the preparation of the
+         username fails or results in an empty string, the server SHOULD
+         abort the authentication exchange.
+
+         The characters ',' or '=' in usernames are sent as '=2C' and
+         '=3D' respectively.  If the server receives a username which
+         contains '=' not followed by either '2C' or '3D', then the
+         server MUST fail the authentication.
+
+   o  m: This attribute is reserved for future extensibility.  In this
+      version of SCRAM, its presence in a client or a server message
+      MUST cause authentication failure when the attribute is parsed by
+      the other end.
+
+   o  r: This attribute specifies a sequence of random printable
+      characters excluding ',' which forms the nonce used as input to
+      the hash function.  No quoting is applied to this string (<<unless
+      the binding of SCRAM to a particular protocol states otherwise>>).
+      As described earlier, the client supplies an initial value in its
+      first message, and the server augments that value with its own
+      nonce in its first response.  It is important that this be value
+      different for each authentication.  The client MUST verify that
+      the initial part of the nonce used in subsequent messages is the
+      same as the nonce it initially specified.  The server MUST verify
+      that the nonce sent by the client in the second message is the
+      same as the one sent by the server in its first message.
+
+   o  c: This REQUIRED attribute specifies base64-encoded of a header
+      and the channel-binding data.  It is sent by the client in its
+      second authentication message.  The header consist of:
+
+      *  the GS2 header from the client's first message (recall: a
+         channel binding flag and an optional authzid);
+
+      *  followed by the external channel's channel binding type prefix
+         (see [RFC5056], if and only if the client is using channel
+         binding;
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 13]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+      *  followed by the external channel's channel binding data, if and
+         only if the client is using channel binding.
+
+   o  s: This attribute specifies the base64-encoded salt used by the
+      server for this user.  It is sent by the server in its first
+      message to the client.
+
+   o  i: This attribute specifies an iteration count for the selected
+      hash function and user, and must be sent by the server along with
+      the user's salt.
+
+         For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a
+         hash iteration-count of at least 128.
+
+   o  p: This attribute specifies a base64-encoded ClientProof.  The
+      client computes this value as described in the overview and sends
+      it to the server.
+
+   o  v: This attribute specifies a base64-encoded ServerSignature.  It
+      is sent by the server in its final message, and is used by the
+      client to verify that the server has access to the user's
+      authentication information.  This value is computed as explained
+      in the overview.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 14]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+6.  Channel Binding
+
+   SCRAM supports channel binding to external secure channels, such as
+   TLS.  Clients and servers may or may not support channel binding,
+   therefore the use of channel binding is negotiable.  SCRAM does not
+   provide security layers, however, therefore it is imperative that
+   SCRAM provide integrity protection for the negotiation of channel
+   binding.
+
+   Use of channel binding is negotiated as follows:
+
+   o  The server advertises support for channel binding by advertising
+      both, SCRAM-HMAC-<hash-function> and SCRAM-HMAC-<hash-function>-
+      PLUS.
+
+   o  If the client negotiates mechanisms then client MUST select SCRAM-
+      HMAC-<hash-function>-PLUS if offered by the server.  Otherwise, if
+      the client does not negotiate mechanisms then it MUST select only
+      SCRAM-HMAC-<hash-function> (not suffixed with "-PLUS").
+
+   o  If the client and server both support channel binding, or if the
+      client wishes to use channel binding but the client does not
+      negotiate mechanisms, the client MUST set the GS2 channel binding
+      flag to "p" and MUST include channel binding data for the external
+      channel in the computation of the "c=" attribute (see
+      Section 5.1).
+
+   o  If the client supports channel binding but the server does not
+      then the client MUST set the GS2 channel binding flag to "y" and
+      MUST NOT include channel binding data for the external channel in
+      the computation of the "c=" attribute (see Section 5.1).
+
+   o  If the client does not support channel binding then the client
+      MUST set the GS2 channel binding flag to "n" and MUST NOT include
+      channel binding data for the external channel in the computation
+      of the "c=" attribute (see Section 5.1).
+
+   o  If the server receives a client first message with the GS2 channel
+      binding flag set to "y" and the server supports channel binding
+      the server MUST fail authentication.  This is because if the
+      client sets the GS2 channel binding flag set to "y" then the
+      client must have believed that the server did not support channel
+      binding -- if the server did in fact support channel binding then
+      this is an indication that there has been a downgrade attack
+      (e.g., an attacker changed the server's mechanism list to exclude
+      the -PLUS suffixed SCRAM mechanism name(s)).
+
+   The server MUST always validate the client's "c=" field.  The server
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 15]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   does this by constructing the value of the "c=" attribute and then
+   checking that it matches the client's c= attribute value.
+
+6.1.  Channel Binding to TLS Channels
+
+   If an external TLS channel is to be bound into the SCRAM
+   authentication, and if the channel was established using a server
+   certificate to authenticate the server, then the SCRAM client and
+   server MUST use the 'tls-server-end-point' channel binding type.  See
+   the IANA Channel Binding Types registry.
+
+   If an external TLS channel is to be bound into the SCRAM
+   authentication, and if the channel was established without the use of
+   any server certificate to authenticate the server, then the SCRAM
+   client and server MUST use the 'tls-unique' channel binding type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 16]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+7.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"
+   and "UTF8-4" non-terminal are defined in [RFC3629].
+
+
+     ALPHA = <as defined in RFC 5234 appendix B.1>
+     DIGIT = <as defined in RFC 5234 appendix B.1>
+     UTF8-2 = <as defined in RFC 3629 (STD 63)>
+     UTF8-3 = <as defined in RFC 3629 (STD 63)>
+     UTF8-4 = <as defined in RFC 3629 (STD 63)>
+
+     generic-message = attr-val *("," attr-val)
+                       ;; Generic syntax of any server challenge
+                       ;; or client response
+
+     attr-val        = ALPHA "=" value
+
+     value           = *value-char
+
+     value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
+                       UTF8-2 / UTF8-3 / UTF8-4
+                       ;; UTF8-char except NUL, "=", and ",".
+
+     value-char      = value-safe-char / "="
+
+     base64-char     = ALPHA / DIGIT / "/" / "+"
+
+     base64-4        = 4base64-char
+
+     base64-3        = 3base64-char "="
+
+     base64-2        = 2base64-char "=="
+
+     base64          = *base64-4 [base64-3 / base64-2]
+
+     posit-number = %x31-39 *DIGIT
+                       ;; A positive number
+
+     saslname        = 1*(value-safe-char / "=2C" / "=3D")
+                       ;; Conforms to <value>
+
+     authzid         = "a=" saslname
+                       ;; Protocol specific.
+
+     gs2-cbind-flag  = "n" / "y" / "p"
+                       ;; "n" -> client doesn't support channel binding
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 17]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+                       ;; "y" -> client does support channel binding
+                       ;;        but thinks the server does not.
+                       ;; "p" -> client requires channel binding
+     gs2-header      = gs2-cbind-flag [ authzid ] ","
+                       ;; GS2 header for SCRAM
+                       ;; (the actual GS2 header includes an optional
+                       ;; flag to indicate that the GSS mechanism is not
+                       ;; "standard" but since SCRAM is "standard" we
+                       ;; don't include that flag).
+
+     username        = "n=" saslname
+                       ;; Usernames are prepared using SASLPrep.
+
+     reserved-mext  = "m=" 1*(value-char)
+                       ;; Reserved for signalling mandatory extensions.
+                       ;; The exact syntax will be defined in
+                       ;; the future.
+
+     ;;cbind-type    = value
+     ;;cbind-input   = gs2-header [ value ":" cbind-data ]
+     channel-binding = "c=" base64
+                       ;; base64 encoding of cbind-input
+
+     proof           = "p=" base64
+
+     nonce           = "r=" c-nonce [s-nonce]
+                       ;; Second part provided by server.
+
+     c-nonce         = value
+
+     s-nonce         = value
+
+     salt            = "s=" base64
+
+     verifier        = "v=" base64
+                       ;; base-64 encoded ServerSignature.
+
+     iteration-count = "i=" posit-number
+                       ;; A positive number
+
+     client-first-message =
+                       gs2-header [reserved-mext ","]
+                       username "," nonce ["," extensions]
+
+     server-first-message =
+                       [reserved-mext ","] nonce "," salt ","
+                       iteration-count ["," extensions]
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 18]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+     client-final-message-without-proof =
+                       [channel-binding ","] nonce [","
+                       extensions]
+
+     client-final-message =
+                       client-final-message-without-proof "," proof
+
+     gss-server-error = "e=" value
+     server-final-message = gss-server-error /
+                       verifier ["," extensions]
+                       ;; The error message is only for the GSS-API
+                       ;; form of SCRAM, and it is OPTIONAL to
+                       ;; implement it.
+
+     extensions = attr-val *("," attr-val)
+                       ;; All extensions are optional,
+                       ;; i.e. unrecognized attributes
+                       ;; not defined in this document
+                       ;; MUST be ignored.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 19]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+8.  SCRAM as a GSS-API Mechanism
+
+   This section and its sub-sections and all normative references of it
+   not referenced elsewhere in this document are INFORMATIONAL for SASL
+   implementors, but they are NORMATIVE for GSS-API implementors.
+
+   SCRAM is actually also GSS-API mechanism.  The messages are the same,
+   but a) the GS2 header on the client's first message and channel
+   binding data is excluded when SCRAM is used as a GSS-API mechanism,
+   and b) the RFC2743 section 3.1 initial context token header is
+   prefixed to the client's first authentication message (context
+   token).
+
+   The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10).
+
+8.1.  GSS-API Principal Name Types for SCRAM
+
+   SCRAM does not name acceptors.  Therefore only GSS_C_NO_NAME and
+   names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
+   input of GSS_Init_sec_context() when using a SCRAM mechanism.
+
+   SCRAM supports only a single name type for initiators:
+   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
+   SCRAM.
+
+   There is no name canonicalization procedure for SCRAM beyond applying
+   SASLprep as described in Section 5.1.
+
+   The query, display and exported name syntax for SCRAM principal names
+   is the same: there is no syntax -- SCRAM principal names are free-
+   form.  (The exported name token does, of course, conform to [RFC2743]
+   section 3.2, but the "NAME" part of the token is just a SCRAM user
+   name.)
+
+8.2.  GSS-API Per-Message Tokens for SCRAM
+
+   The per-message tokens for SCRAM as a GSS-API mechanism SHALL BE the
+   same as those for the Kerberos V GSS-API mechanism [RFC4121], using
+   the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
+
+   The 128-bit session key SHALL be derived by using the least
+   significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
+   key" || ClientKey || AuthMessage).
+
+   SCRAM does support PROT_READY, and is PROT_READY on the initiator
+   side first upon receipt of the server's reply to the initial security
+   context token.
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 20]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+8.3.  GSS_Pseudo_random() for SCRAM
+
+   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
+   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
+   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
+   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 21]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+9.  Security Considerations
+
+   If the authentication exchange is performed without a strong security
+   layer, then a passive eavesdropper can gain sufficient information to
+   mount an offline dictionary or brute-force attack which can be used
+   to recover the user's password.  The amount of time necessary for
+   this attack depends on the cryptographic hash function selected, the
+   strength of the password and the iteration count supplied by the
+   server.  An external security layer with strong encryption will
+   prevent this attack.
+
+   If the external security layer used to protect the SCRAM exchange
+   uses an anonymous key exchange, then the SCRAM channel binding
+   mechanism can be used to detect a man-in-the-middle attack on the
+   security layer and cause the authentication to fail as a result.
+   However, the man-in-the-middle attacker will have gained sufficient
+   information to mount an offline dictionary or brute-force attack.
+   For this reason, SCRAM includes the ability to increase the iteration
+   count over time.
+
+   If the authentication information is stolen from the authentication
+   database, then an offline dictionary or brute-force attack can be
+   used to recover the user's password.  The use of salt mitigates this
+   attack somewhat by requiring a separate attack on each password.
+   Authentication mechanisms which protect against this attack are
+   available (e.g., the EKE class of mechanisms), but the patent
+   situation is presently unclear.
+
+   If an attacker obtains the authentication information from the
+   authentication repository and either eavesdrops on one authentication
+   exchange or impersonates a server, the attacker gains the ability to
+   impersonate that user to all servers providing SCRAM access using the
+   same hash function, password, iteration count and salt.  For this
+   reason, it is important to use randomly-generated salt values.
+
+   SCRAM does not negotiate a hash function to use.  Hash function
+   negotiation is left to the SASL mechanism negotiation.  It is
+   important that clients be able to sort a locally available list of
+   mechanisms by preference so that the client may pick the most
+   preferred of a server's advertised mechanism list.  This preference
+   order is not specified here as it is a local matter.  The preference
+   order should include objective and subjective notions of mechanism
+   cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
+   preferred over SCRAM with SHA-1).
+
+   Note that to protect the SASL mechanism negotiation applications
+   normally must list the server mechs twice: once before and once after
+   authentication, the latter using security layers.  Since SCRAM does
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 22]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   not provide security layers the only ways to protect the mechanism
+   negotiation are: a) use channel binding to an external channel, or b)
+   use an external channel that authenticates a user-provided server
+   name.
+
+   A hostile server can perform a computational denial-of-service attack
+   on clients by sending a big iteration count value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 23]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+10.  IANA Considerations
+
+   IANA is requested to add the following entries to the SASL Mechanism
+   registry established by [RFC4422]:
+
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1
+
+   SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1
+   Security considerations: Section 7 of [RFCXXXX]
+   Published specification (optional, recommended): [RFCXXXX]
+   Person & email address to contact for further information:
+    IETF SASL WG <ietf-sasl@imc.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note:
+
+   To: iana@iana.org
+   Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1-PLUS
+
+   SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1-PLUS
+   Security considerations: Section 7 of [RFCXXXX]
+   Published specification (optional, recommended): [RFCXXXX]
+   Person & email address to contact for further information:
+    IETF SASL WG <ietf-sasl@imc.org>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <iesg@ietf.org>
+   Note:
+
+
+   Note that even though this document defines a family of SCRAM-HMAC
+   mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in
+   the SASL Mechanisms registry.  IANA is requested to prevent future
+   registrations of SASL mechanisms starting with SCRAM-HMAC- without
+   consulting the SASL mailing list <ietf-sasl@imc.org> first.
+
+   Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC
+   SASL mechanism MUST be explicitly registered with IANA and MUST
+   comply with SCRAM-HMAC mechanism naming convention defined in
+   Section 4 of this document.
+
+   We hereby request that IANA assign a GSS-API mechanism OID for SCRAM.
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 24]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+11.  Acknowledgements
+
+   The authors would like to thank Dave Cridland for his contributions
+   to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 25]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+Appendix A.  Other Authentication Mechanisms
+
+   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+   proved to be too complex to implement and test, and thus has poor
+   interoperability.  The security layer is often not implemented, and
+   almost never used; everyone uses TLS instead.  For a more complete
+   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+   see [I-D.ietf-sasl-digest-to-historic].
+
+   The CRAM-MD5 SASL mechanism, while widely deployed has also some
+   problems, in particular it is missing some modern SASL features such
+   as support for internationalized usernames and passwords, support for
+   passing of authorization identity, support for channel bindings.  It
+   also doesn't support server authentication.  For a more complete list
+   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
+
+   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+   eavesdropper to impersonate the authenticating user to any other
+   server for which the user has the same password.  It also sends the
+   password in the clear over the network, unless TLS is used.  Server
+   authentication is not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 26]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+Appendix B.  Design Motivations
+
+   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+   proved to be too complex to implement and test, and thus has poor
+   interoperability.  The security layer is often not implemented, and
+   almost never used; everyone uses TLS instead.  For a more complete
+   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+   see [I-D.ietf-sasl-digest-to-historic].
+
+   The CRAM-MD5 SASL mechanism, while widely deployed has also some
+   problems, in particular it is missing some modern SASL features such
+   as support for internationalized usernames and passwords, support for
+   passing of authorization identity, support for channel bindings.  It
+   also doesn't support server authentication.  For a more complete list
+   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
+
+   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+   eavesdropper to impersonate the authenticating user to any other
+   server for which the user has the same password.  It also sends the
+   password in the clear over the network, unless TLS is used.  Server
+   authentication is not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 27]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+Appendix C.  SCRAM Examples and Internet-Draft Change History
+
+   <<To be written.>>
+
+   (RFC Editor: Please delete everything after this point)
+
+   Open Issues
+
+   o  The appendices need to be written.
+
+   o  Should the server send a base64-encoded ServerSignature for the
+      value of the "v" attribute, or should it compute a ServerProof the
+      way the client computes a ClientProof?
+
+   Changes since -10
+
+   o  Converted the source for this I-D to XML.
+
+   o  Added text to make SCRAM compliant with the new GS2 design.
+
+   o  Added text on channel binding negotiation.
+
+   o  Added text on channel binding, including a reference to RFC5056.
+
+   o  Added text on SCRAM as a GSS-API mechanism.  This noted as not
+      relevant to SASL-only implementors -- the normative references for
+      SCRAM as a GSS-API mechanism are segregated as well.
+
+   Changes since -07
+
+   o  Updated References.
+
+   o  Clarified purpose of the m= attribute.
+
+   o  Fixed a problem with authentication/authorization identity's ABNF
+      not allowing for some characters.
+
+   o  Updated ABNF for nonce to show client-generated and server-
+      generated parts.
+
+   o  Only register SCRAM-HMAC-SHA-1 with IANA and require explicit
+      registrations of all other SCRAM-HMAC- mechanisms.
+
+   Changes since -06
+
+   o  Removed hash negotiation from SCRAM and turned it into a family of
+      SASL mechanisms.
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 28]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   o  Start using "Hash Function Textual Names" IANA registry for SCRAM
+      mechanism naming.
+
+   o  Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
+
+   o  Clarified extensibility of SCRAM: added m= attribute (for future
+      mandatory extensions) and specified that all unrecognized
+      attributes must be ignored.
+
+   Changes since -05
+
+   o  Changed the mandatory to implement hash algorithm to SHA-1 (as per
+      WG consensus).
+
+   o  Added text about use of SASLPrep for username canonicalization/
+      validation.
+
+   o  Clarified that authorization identity is canonicalized/verified
+      according to SASL protocol profile.
+
+   o  Clarified that iteration count is per-user.
+
+   o  Clarified how clients select the authentication function.
+
+   o  Added IANA registration for the new mechanism.
+
+   o  Added missing normative references (UTF-8, SASLPrep).
+
+   o  Various editorial changes based on comments from Hallvard B
+      Furuseth, Nico William and Simon Josefsson.
+
+   Changes since -04
+
+   o  Update Base64 and Security Glossary references.
+
+   o  Add Formal Syntax section.
+
+   o  Don't bother with "v=".
+
+   o  Make MD5 mandatory to implement.  Suggest i=128.
+
+   Changes since -03
+
+   o  Seven years have passed, in which it became clear that DIGEST-MD5
+      suffered from unacceptably bad interoperability, so SCRAM-MD5 is
+      now back from the dead.
+
+   o  Be hash agnostic, so MD5 can be replaced more easily.
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 29]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   o  General simplification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 30]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, September 2001.
+
+   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
+              Internationalized Strings ("stringprep")", RFC 3454,
+              December 2002.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+              and Passwords", RFC 4013, February 2005.
+
+   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
+              Security Layer (SASL)", RFC 4422, June 2006.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+12.2.  Normative References for GSS-API implementors
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 31]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
+
+   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
+              Kerberos V Generic Security Service Application Program
+              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
+
+12.3.  Informative References
+
+   [I-D.ietf-sasl-crammd5-to-historic]
+              Zeilenga, K., "CRAM-MD5 to Historic",
+              draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
+              November 2008.
+
+   [I-D.ietf-sasl-digest-to-historic]
+              Melnikov, A., "Moving DIGEST-MD5 to Historic",
+              draft-ietf-sasl-digest-to-historic-00 (work in progress),
+              July 2008.
+
+   [I-D.ietf-sasl-rfc2831bis]
+              Melnikov, A., "Using Digest Authentication as a SASL
+              Mechanism", draft-ietf-sasl-rfc2831bis-12 (work in
+              progress), March 2007.
+
+   [RFC2195]  Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
+              AUTHorize Extension for Simple Challenge/Response",
+              RFC 2195, September 1997.
+
+   [RFC2202]  Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
+              SHA-1", RFC 2202, September 1997.
+
+   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
+              Specification Version 2.0", RFC 2898, September 2000.
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510,
+              June 2006.
+
+   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
+              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              RFC 4949, August 2007.
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 32]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 33]
+
+Internet-Draft                    SCRAM                       March 2009
+
+
+Authors' Addresses
+
+   Abhijit Menon-Sen
+   Oryx Mail Systems GmbH
+
+   Email: ams@oryx.com
+
+
+   Alexey Melnikov
+   Isode Ltd
+
+   Email: Alexey.Melnikov@isode.com
+
+
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive
+   West Covina, CA  91790
+   USA
+
+   Email: chris.newman@sun.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   USA
+
+   Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al.      Expires September 24, 2009              [Page 34]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-02.txt b/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-02.txt
new file mode 100644
index 00000000000..dd88349314e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-02.txt
@@ -0,0 +1,616 @@
+
+
+
+Kerberos Working Group                                   A. Perez-Mendez
+Internet-Draft                                            R. Marin-Lopez
+Intended status: Experimental                       F. Pereniguez-Garcia
+Expires: March 5, 2013                                   G. Lopez-Millan
+                                                    University of Murcia
+                                                                Sep 2012
+
+
+                GSS-API pre-authentication for Kerberos
+                   draft-perez-krb-wg-gss-preauth-02
+
+Abstract
+
+   This document describes a pre-authentication mechanism for Kerberos
+   based on the Generic Security Service Application Program Interface
+   (GSS-API), which allows a Key Distribution Center (KDC) to
+   authenticate clients by using a GSS mechanism.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on March 5, 2013.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 1]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   described in the Simplified BSD License.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Definition of the Kerberos GSS padata  . . . . . . . . . . . .  4
+   4.  GSS Pre-authentication Operation . . . . . . . . . . . . . . .  5
+     4.1.  Generation of GSS preauth requests . . . . . . . . . . . .  5
+     4.2.  Processing of GSS preauth requests . . . . . . . . . . . .  6
+     4.3.  Generation of GSS preauth responses  . . . . . . . . . . .  6
+     4.4.  Processing of GSS preauth responses  . . . . . . . . . . .  7
+   5.  Data in the KDC_ERR_PREAUTH_REQUIRED . . . . . . . . . . . . .  7
+   6.  Derivation of the reply key from the GSS context . . . . . . .  7
+   7.  KDC state management . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Support for federated users  . . . . . . . . . . . . . . . . .  8
+   9.  GSS channel bindings . . . . . . . . . . . . . . . . . . . . .  9
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   13. Normative References . . . . . . . . . . . . . . . . . . . . .  9
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 2]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+1.  Introduction
+
+   The GSS-API (Generic Security Service Application Programming
+   Interface) [RFC2743] provides a generic toolset of functions that
+   allow applications to establish security contexts in order to protect
+   their communications through security services such as
+   authentication, confidentiality and integrity protection.  Thanks to
+   the GSS-API, applications remain independent from the specific
+   underlying mechanism used to establish the context and provide
+   security.
+
+   On the other hand, Kerberos [RFC4120] defines a process called pre-
+   authentication.  This feature is intended to avoid the security risk
+   of providing tickets encrypted with the user's long-term key to
+   attackers, by requiring clients to proof their knowledge over these
+   credentials.  The execution of a pre-authentication mechanism may
+   require the exchange of several KRB_AS_REQ/KRB_ERROR messages before
+   the KDC delivers the TGT requested by the client within a KRB_AS_REP.
+   These messages transport authentication information by means of pre-
+   authentication elements.
+
+   There exists a variety of pre-authentication mechanisms, like PKINIT
+   [RFC4556] and encrypted time-stamp [RFC4120].  Furthermore,
+   [I-D.ietf-krb-wg-preauth-framework] provides a generic framework for
+   Kerberos pre-authentication, which aims to describe the features that
+   a pre-authentication mechanism may provide (e.g. mutual
+   authentication, replace reply key, etc.).  Additionally, in order to
+   simplify the definition of new pre-authentication mechanisms, it
+   defines a mechanism called FAST (Flexible Authentication Secure
+   Tunneling), which provides a generic and secure transport for pre-
+   authentication elements.  More specifically, FAST establishes a
+   secure tunnel providing confidentiality and integrity protection
+   between the client and the KDC prior to the exchange of any specific
+   pre-authentication data.  Within this tunnel, different pre-
+   authentication methods can be executed.  This inner mechanism is
+   called a FAST factor.  It is important to note that FAST factors
+   cannot usually be used outside the FAST pre-authentication method
+   since they assume the underlying security layer provided by FAST.
+
+   The aim of this draft is to define a new pre-authentication
+   mechanism, following the recommendations of
+   [I-D.ietf-krb-wg-preauth-framework], that relies on the GSS-API
+   security services to pre-authenticate clients.  This pre-
+   authentication mechanism will allow the KDC to authenticate clients
+   making use of any current or future GSS mechanism, as long as they
+   satisfy the minimum security requirements described in this
+   specification.  The Kerberos client will play the role of the GSS
+   initiator, while the Authentication Server (AS) in the KDC will play
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 3]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   the role of the GSS acceptor.
+
+1.1.  Requirements Language
+
+   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 [RFC2119].
+
+
+2.  Motivation
+
+   This work is mainly motivated by the necessity of a way to allow the
+   KDC to make use of the technologies defined in the ABFAB WG to
+   perform the access control of federated users.  Specifically, the
+   ABFAB architecture requires relying parties to make use of the GSS-
+   EAP mechanism to perform authentication.
+   [I-D.perez-abfab-eap-gss-preauth] defines how GSS-EAP is transported
+   on top of the GSS pre-authentication mechanism defined in this
+   document.
+
+
+3.  Definition of the Kerberos GSS padata
+
+   To establish the security context, the GSS-API defines the exchange
+   of GSS tokens between the initiator and the acceptor.  These tokens,
+   which contain mechanism-specific information, are completely opaque
+   to the application.  However, how these tokens are transported
+   between the initiator and the responder depends on the specific
+   application.  Since GSS-API is defined as independent of the
+   underlying communications service, its use does not require to
+   implement any specific security feature for the transport.  For
+   instance, tokens could just be sent by means of plain UDP datagrams.
+   For this reason, security and ordered delivery of information must be
+   implemented by each specific GSS mechanism (if required).
+
+   Therefore, GSS tokens are the atomic piece of information from the
+   application point of view when using GSS-API, which require a proper
+   transport between the initiator (Kerberos client) and the acceptor
+   (AS).  In particular, the proposed GSS-based pre-authentication
+   mechanism defines a new pre-authentication element (hereafter padata)
+   called PA-GSS, to transport a generic GSS token from the Kerberos
+   client to the AS and vice-versa.  This padata also transport state
+   information required to maintain the KDC stateless (see section
+   Section 7.
+
+       PA-GSS          To be defined (TBD)
+
+   A PA-GSS padata element contains the ASN.1 DER encoding of the PA-GSS
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 4]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   structure:
+
+       PA-GSS ::= SEQUENCE {
+          sec-ctx-token [0] OCTET STRING,
+          state [1] EncryptedData OPTIONAL -- contains PA-GSS-STATE
+       }
+
+       PA-GSS-STATE ::= SEQUENCE {
+          timestamp [0] KerberosTime,
+          exported-sec-ctx-token [1] OCTET STRING,
+          ...
+       }
+
+   The sec-ctx-token element of the PA-GSS structure contains the
+   output_token token returned by either, the GSS_Init_sec_context and
+   the GSS_Accept_sec_context calls.  The state element of the PA-GSS
+   structure is optional, and will be absent in the first AS_REQ message
+   from the client to the KDC and in the last AS_REP message from the
+   KDC to the client.  It contains a PA-GSS-STATE structure encrypted
+   with the first krbtgt key and a key usage in the 512-1023 range (to
+   be defined TBD).  The state element is generated by the KDC, while
+   the client just copy it from the previously received PA-GSS structure
+   (if present).
+
+   The PA-GSS-STATE contains a timestamp element, meant to detect
+   possible replay situations, and a exported-sec-ctx-token element,
+   representing the whole GSS security context state corresponding to
+   the current authentication process.  This value is generated by the
+   KDC by calling to the GSS_Export_sec_context, when the
+   GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED.
+
+
+4.  GSS Pre-authentication Operation
+
+4.1.  Generation of GSS preauth requests
+
+   The Kerberos client (initiator) starts by calling to the
+   GSS_Init_sec_context function.  In the first call to this function,
+   the client provides GSS_C_NO_CTX as the value of the context_handle
+   and NULL as the input_token, given that no context has been initiated
+   yet.  When using multi round-trip GSS mechanisms, in subsequent calls
+   to this routine the client will use both, the context_handle value
+   obtained after the first call, and the input_token received from the
+   KDC.  The mutual_req_flag, replay_det_req_flag and sequence_req_flag
+   MUST be set, as the GSS token is meant to be tranported over
+   cleartext channels.
+
+   The GSS_Init_sec_context returns a context_handle, an output_token
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 5]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   and a status value.  In this first call, the only acceptable status
+   value is GSS_S_CONTINUE_NEEDED, as the KDC is expected to provide a
+   token in order to continue with the context establishment process.
+   The Kerberos client creates a new PA-GSS padata, with the obtained
+   output_token as the sec-ctx-token element, and with the state element
+   absent.  The PA-GSS padata is sent to the KDC through a KRB_AS_REQ
+   message.
+
+4.2.  Processing of GSS preauth requests
+
+   When the KDC (GSS acceptor) receives a KRB_AS_REQ message containing
+   a PA-GSS padata, but a state element (see Section 7) is not included,
+   the KDC assumes that this is the first message of a context
+   establishment, and thus GSS_C_NO_CTX is used as context_handle to
+   invoke the GSS_Accept_sec_context routine.  Conversely, if a state
+   element is included, the KDC assumes that this message is part an
+   ongoing authentication and the value of the state element is
+   decrypted and used to recover the state of the authentication (see
+   Section 7).  In both cases, after receiving the message, the KDC
+   calls to the GSS_Accept_sec_context function, using the adequate
+   context_handle value and using the received token in the PA-GSS
+   padata as input_token.
+
+   Once the execution of the GSS_Accept_sec_context function is
+   completed, the KDC obtains a context_handle, an output_token that
+   MUST be sent to the initiator in order to continue with the
+   authentication process, and a status value.  If the obtained status
+   is GSS_S_COMPLETE, the client is considered authenticated.  If the
+   status is GSS_S_CONTINUE_NEEDED, further information is required to
+   complete the process.
+
+4.3.  Generation of GSS preauth responses
+
+   Once the KDC has processed the input_token provided by the client (as
+   described in Section 4.2), two main different situations may occur
+   depending on the status value.  If the client is successfully
+   authenticated (GSS_S_COMPLETE), the KDC will reply to the client with
+   a KRB_AS_REP message.  This message will transport the final
+   output_token in a PA-GSS padata type.  This PA-GSS padata will not
+   contain the state element.  The reply key used to encrypt the enc-
+   part field of the KRB_AS_REP message is derived from the GSS security
+   context cryptographic material.  Section 6 provides further details
+   regarding this derivation.  At this moment, the KDC also verifies
+   that the cname provided in the AS_REQ matches the src_name obtained
+   through the final GSS_Accept_sec_ctx call (except when WELLKNOWN/
+   FEDERATED is used as cname Section 8).
+
+   On the contrary, if further data is required to complete the
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 6]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   establishment process (GSS_S_CONTINUE_NEEDED), the KDC will reply to
+   the client with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error message
+   [I-D.ietf-krb-wg-preauth-framework].  In the e-data field of the
+   message, the KDC will include the PA-GSS padata, containing both, the
+   GSS token (sec-ctx-token) and the exported GSS security context
+   (state) (see Section 7).
+
+4.4.  Processing of GSS preauth responses
+
+   When the client receives a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error,
+   it extracts the token from the PA-GSS element and invokes the
+   GSS_Init_sec_context function, as described in section Section 4.1.
+   If present, the state element of the PA-GSS padata is treated as an
+   opaque element, and it is simply copied and included into the
+   generated PA-GSS element without further processing.
+
+   On the other hand, when the client receives a KRB_AS_REP, it knows
+   the context establishment has finalized successfully.  The client
+   invokes the GSS_Init_sec_context function using the transported GSS
+   token.  Note that, to be consistent, this call MUST return
+   GSS_S_COMPLETE and not generate any output_token, since the KDC does
+   not expect further data from the client.
+
+   If the context establishment is completed correctly, the client MUST
+   use the same key derivation process followed by the KDC (Section 4.3)
+   to obtain the reply key to decrypt the enc-part of the KRB_AS_REP.
+
+
+5.  Data in the KDC_ERR_PREAUTH_REQUIRED
+
+   When the KDC sends a KDC_ERR_PREAUTH_REQUIRED error to the client, it
+   includes a sequence of padata, each corresponding to an acceptable
+   pre-authentication method.  Optionally, these padata elements contain
+   data valuable for the client to configure the selected mechanism.
+   The data to be included in the padata for this message is described
+   in this section.
+
+   TBD.  (For example, list of the OIDs of the GSS mechanisms supported
+   by the KDC)
+
+
+6.  Derivation of the reply key from the GSS context
+
+   The GSS pre-authentication mechanism proposed in this draft provides
+   the "Replacing-reply-key" facility
+   [I-D.ietf-krb-wg-preauth-framework].
+
+   After a successful authentication, client and KDC may decide to
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 7]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   completely replace the reply key used to encrypt the KRB_AS_REP by a
+   new one that is cryptographically independent from the client's
+   password stored in client password on the Kerberos users database.
+   This additional keying material can be obtained by means of calls to
+   the GSS_Pseudo_random [RFC4401] function, using "KRB-GSS" as the
+   prf_in parameter.
+
+
+7.  KDC state management
+
+   The Kerberos standard [RFC4120] defines the KDC as a stateless
+   entity.  This means that, if the GSS mechanism requires more than one
+   round-trip, the client MUST provide enough data to the KDC in the
+   following interactions to allow recovering the complete state of the
+   ongoing authentication.  This is specially relevant when the client
+   switches from one KDC to different one (within the same realm) during
+   a pre-authentication process.  This second KDC must be able to
+   continue with the process in a seamless way.
+
+   The GSS-API manages the so-called security contexts.  They represent
+   the whole context of an authentication, including all the state and
+   relevant data of the ongoing security context.  Thus, this
+   information MUST be serialized and sent to the client in order to
+   ensure that the KDC receiving it will be able to reconstruct the
+   associated state.  In order to prevent attacks, this information must
+   be confidentiality and integrity protected using a key shared amongst
+   all the KDCs deployed in the realm, and must be sent along with a
+   timestamp to prevent replay attacks.  How this information is encoded
+   is described in section Section 3.
+
+   To generate the serialized security context information, the
+   GSS_Export_sec_ctx() call is used.  The main drawback of this
+   approach is that the current GSS-API specifications does not allow
+   the exportation of a security context which has not been completely
+   established.  Nevertheless, some GSS mechanisms do allow the
+   exportation of partially established context (e.g.
+   [I-D.ietf-abfab-gss-eap]), and we expect that other GSS mechanisms
+   will do the same in the future.
+
+
+8.  Support for federated users
+
+   This draft supports the authentication of users belonging to a
+   different domain than the authenticating KDC.  This is achieved by
+   letting the GSS-API to provide both, the client name and the reply
+   key to be used.  That means that the requested username may not be
+   present in the KDC's database.  To avoid the generation of an error
+   of type KDC_ERR_C_PRINCIPAL_UNKNOWN, when the Kerberos client knows
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 8]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   it is operating in a federated environment, it MUST set the value of
+   the cname field of the KRB_AS_REQ message to a new wellknown value,
+   WELLKNOWN/FEDERATED, following the model proposed in [RFC6111].  In
+   this way, the KDC will be completely authenticated by the GSS-API
+   calls, and thus no local verification of credentials should be done.
+
+
+9.  GSS channel bindings
+
+   In order to link the GSS authentication with the actual Kerberos
+   exchange transporting GSS tokens, the DER-encoded KDC-REQ-BODY from
+   the AS-REQ is used as channel bindings.
+
+
+10.  Acknowledgements
+
+   This work is supported by the project MULTIGIGABIT EUROPEAN ACADEMIC
+   NETWORK (FP7-INFRASTRUCTURES-2009-1).  It is also funded by a Seneca
+   Foundation grant from the Human Resources Researching Training
+   Program 2007.  Authors finally thank the Funding Program for Research
+   Groups of Excellence with code 04552/GERM/06 granted by the Fundacion
+   Seneca.
+
+
+11.  Security Considerations
+
+   Protection of Request/Responses with FAST, restriction on GSS
+   mechanism, etc.  TBD.
+
+
+12.  IANA Considerations
+
+   This document has no actions for IANA.
+
+
+13.  Normative References
+
+   [I-D.ietf-abfab-gss-eap]
+              Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
+              Extensible Authentication Protocol",
+              draft-ietf-abfab-gss-eap-09 (work in progress),
+              August 2012.
+
+   [I-D.ietf-krb-wg-preauth-framework]
+              Hartman, S. and L. Zhu, "A Generalized Framework for
+              Kerberos Pre-Authentication",
+              draft-ietf-krb-wg-preauth-framework-17 (work in progress),
+              June 2010.
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                 [Page 9]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   [I-D.perez-abfab-eap-gss-preauth]
+              Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., and G.
+              Lopez-Millan, "GSS-EAP pre-authentication for Kerberos",
+              draft-perez-abfab-eap-gss-preauth-01 (work in progress),
+              March 2012.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [RFC6111]  Zhu, L., "Additional Kerberos Naming Constraints",
+              RFC 6111, April 2011.
+
+
+Authors' Addresses
+
+   Alejandro Perez-Mendez (Ed.)
+   University of Murcia
+   Campus de Espinardo S/N, Faculty of Computer Science
+   Murcia,   30100
+   Spain
+
+   Phone: +34 868 88 46 44
+   Email: alex@um.es
+
+
+   Rafa Marin-Lopez
+   University of Murcia
+   Campus de Espinardo S/N, Faculty of Computer Science
+   Murcia,   30100
+   Spain
+
+   Phone: +34 868 88 85 01
+   Email: rafa@um.es
+
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                [Page 10]
+
+Internet-Draft                 GSS preauth                      Sep 2012
+
+
+   Fernando Pereniguez-Garcia
+   University of Murcia
+   Campus de Espinardo S/N, Faculty of Computer Science
+   Murcia,   30100
+   Spain
+
+   Phone: +34 868 88 78 82
+   Email: pereniguez@um.es
+
+
+   Gabriel Lopez-Millan
+   University of Murcia
+   Campus de Espinardo S/N, Faculty of Computer Science
+   Murcia,   30100
+   Spain
+
+   Phone: +34 868 88 85 04
+   Email: gabilm@um.es
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al.      Expires March 5, 2013                [Page 11]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt b/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt
new file mode 100644
index 00000000000..e4c07b1db79
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-03.txt
@@ -0,0 +1,616 @@
+
+
+
+
+Kerberos Working Group                                   A. Perez-Mendez
+Internet-Draft                                                      Jisc
+Intended status: Experimental                             R. Marin-Lopez
+Expires: 27 March 2022                              University of Murcia
+                                                    F. Pereniguez-Garcia
+                                               University Defense Center
+                                                         G. Lopez-Millan
+                                                    University of Murcia
+                                                       L. Howard-Bentata
+                                                   PADL Software Pty Ltd
+                                                          September 2021
+
+
+                GSS-API pre-authentication for Kerberos
+                   draft-perez-krb-wg-gss-preauth-03
+
+Abstract
+
+   This document describes a pre-authentication mechanism for Kerberos
+   based on the Generic Security Service Application Program Interface
+   (GSS-API), which allows a Key Distribution Center (KDC) to
+   authenticate clients by using a GSS mechanism.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at https://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on 5 March 2022.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (https://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 1]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Simplified BSD License text
+   as described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Prerequisites . . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.1.  Cookie Support  . . . . . . . . . . . . . . . . . . . . .   3
+     2.2.  More Pre-Authentication Data Required . . . . . . . . . .   3
+     2.3.  Support for Exporting Partially Established Contexts  . .   4
+     2.4.  Processing of Channel Bindings in Single Round-Trip . . .   4
+   3.  Definition of the GSS padata  . . . . . . . . . . . . . . . .   4
+   4.  GSS-API Pre-authentication Operation  . . . . . . . . . . . .   4
+     4.1.  Kerberos client (GSS-API initiator) . . . . . . . . . . .   4
+     4.2.  KDC (GSS-API acceptor)  . . . . . . . . . . . . . . . . .   5
+   5.  Indication of Supported Mechanisms  . . . . . . . . . . . . .   6
+   6.  Reply Key Derivation  . . . . . . . . . . . . . . . . . . . .   7
+   7.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   8.  Anonymous Authentication  . . . . . . . . . . . . . . . . . .   8
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+   11. Normative References  . . . . . . . . . . . . . . . . . . . .   9
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
+
+1.  Introduction
+
+   The Generic Security Service Application Programming Interface (GSS-
+   API) [RFC2743] provides a framework for authentication and message
+   protection services through a common programming interface, allowing
+   applications to remain agnostic from the selected mechanism.
+
+   Kerberos [RFC4120] is an authentication service based on the Needham-
+   Schroeder symmetric key protocol.  It includes a facility called pre-
+   authentication designed to ensure clients prove knowledge of their
+   long-term key before the Key Distribution Center (KDC) issues a
+   ticket.  Typical pre-authentication mechanisms include encrypted
+   timestamp [RFC4120] and public key certificates [RFC4556].  Pre-
+   authentication data in these messages provides a typed hole for
+   exchanging information used to authenticate the client.
+
+   [RFC6113] specifies a framework for pre-authentication in Kerberos,
+   describing the features such a pre-authentication mechanism may
+   provide such as authenticating the client and/or KDC and
+   strengthening or replacing the reply key in the AS-REP.  FAST
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 2]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   (Flexible Authentication Secure Tunneling) provides a generic and
+   secure transport for pre-authentication elements prior to the
+   exchange of any pre-authentication data.  The inner pre-
+   authentication mechanism is called a FAST factor.  FAST factors can
+   generally not be used outside FAST as they assume the underlying
+   security layer provided by FAST.
+
+   This document defines a new pre-authentication method that relies on
+   GSS-API security services to pre-authenticate Kerberos clients.  This
+   method allows the KDC to authenticate clients using any current or
+   future GSS-API mechanism, as long as they satisfy the minimum
+   security requirements described in this specification.  The Kerberos
+   client assumes the role of the GSS-API initiator, and the
+   Authentication Service (AS) the role of the GSS-API acceptor.  It may
+   be used as a FAST factor or without FAST.
+
+   This work was originally motivated by the desire to allow Kerberos to
+   use the protocols defined in [RFC7055] to authenticate federated
+   users with EAP.
+
+1.1.  Requirements Language
+
+   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 [RFC2119].
+
+2.  Prerequisites
+
+2.1.  Cookie Support
+
+   KDCs which support GSS-API pre-authentication with mechanisms that
+   require more than one round-trip to establish a security context MUST
+   have a secure mechanism for retaining state between AS-REQs.  For
+   stateless KDC implementations, this will typically be a digest of the
+   initial KDC-REQ-BODY concatenated with a GSS_Export_sec_context()
+   token, encrypted in a key known only to the KDC and protected from
+   replay attacks (see Section 5.2 of [RFC6113]).  The format of the PA-
+   FX-COOKIE is implementation defined.
+
+   Clients that support GSS-API pre-authentication with mechanisms that
+   require more than one round-trip MUST echo the received PA-FX-COOKIE
+   in the next AS-REQ (within a given conversation).
+
+2.2.  More Pre-Authentication Data Required
+
+   Both KDCs and clients which implement GSS-API pre-authentication MUST
+   support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as decribed in
+   Section 5.2 of [RFC6113].
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 3]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+2.3.  Support for Exporting Partially Established Contexts
+
+   KDC implementations that use exported context tokens to maintain
+   state will call GSS_Export_sec_context() and GSS_Import_sec_context()
+   on partially established acceptor contexts.  This may require
+   modifications to the mechanism implementation, as [RFC2743] only
+   requires these functions succeed on fully established contexts.
+
+2.4.  Processing of Channel Bindings in Single Round-Trip
+
+   The client's KDC request is bound to the GSS-API context
+   establishment through the use of channel bindings.  GSS-API
+   mechanisms that require more than one round-trip do not expose at
+   which point in the exchange the channel bindings are validated, and
+   assume they are constant for all context establishment calls.  In
+   this specification, the channel bindings contain the encoded client
+   request body, which may vary for each round-trip if a fresh nonce is
+   used on each request.
+
+   To accommodate this, and to avoid re-encoding the request body
+   without the nonce, this specification imposes the additional
+   requirement that the GSS-API mechanism processes channel bindings in
+   a single round-trip within the pre-authentication conversation.
+
+3.  Definition of the GSS padata
+
+   The GSS-API defines an exchange of opaque tokens between the
+   initiator (client) and acceptor (service) in order to authenticate
+   each party.  GSS-API does not define the transport over which these
+   tokens are carried.  This specification defines a Kerberos pre-
+   authentication type, PA-GSS, which carries a GSS-API context token
+   from the Kerberos client to the AS and vice versa.
+
+       PA-GSS          633
+       -- output_token from GSS_Init_sec_context()
+       -- or GSS_Accept_sec_context()
+
+4.  GSS-API Pre-authentication Operation
+
+4.1.  Kerberos client (GSS-API initiator)
+
+   The Kerberos client begins by calling GSS_Init_sec_context() with the
+   desired credential handle and the target name of the TGS, including
+   the instance and realm.  If the underlying mechanism supports
+   Kerberos names, the TGS name MUST be imported as a
+   GSS_KRB5_NT_PRINCIPAL_NAME; otherwise, it SHALL be imported as a
+   GSS_C_NT_HOSTBASED_SERVICE with "krbtgt" as the "service" element and
+   the TGS realm as the "hostname" element (see [RFC2743] Section 4.1).
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 4]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   In the first call to GSS_Init_sec_context(), input_context_handle is
+   GSS_C_NO_CONTEXT and input_token is empty.  In subsequent calls the
+   client uses the context_handle value obtained after the first call,
+   and the input_token received from the KDC.  The mutual_req_flag MUST
+   be set.
+
+   In order to bind the GSS-API and Kerberos message exchanges, the DER-
+   encoded KDC-REQ-BODY from the AS-REQ is passed as channel binding
+   application data.  As the nonce may differ between requests (see
+   [RFC6113] Section 5.4.3), this requires the GSS-API mechanism to
+   process the channel binding information in a single round-trip.  To
+   avoid this potential interoperability issue, clients MAY use a single
+   nonce for all messages in a conversation once GSS-API pre-
+   authentication has commenced.
+
+   If GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED, the
+   output_token is sent to the KDC in the PA-GSS pre-authentication data
+   and the client expects either a KRB-ERROR containing another context
+   token, or an AS-REP optionally containing a final context token.
+
+   Once GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is
+   ready for use.  The AS-REP is decrypted using the reply key (see
+   Section 6) and the Kerberos client name MAY be replaced by the AS-REP
+   cname (see Section 7).  The client MUST fail if the mutual_state flag
+   is not set when fully established, unless the KDC was authenticated
+   by some other means such as a FAST armor.
+
+   The response received from the KDC must agree with the expected
+   status from GSS_Init_sec_context().  It is a state violation to
+   receive an AS-REP from the KDC when the initiator still has
+   additional tokens to send to the KDC (GSS_S_CONTINUE_NEEDED), or
+   conversely to receive KDC_ERR_MORE_PREAUTH_DATA_REQUIRED if the
+   context from the initiator's perspective was already open
+   (GSS_S_COMPLETE).
+
+   When receiving a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error from the
+   KDC, an PA-FX-COOKIE from the KDC MUST be present and copied into the
+   subsequent AS-REQ.
+
+4.2.  KDC (GSS-API acceptor)
+
+   When the KDC receives an AS-REQ message containing PA-GSS pre-
+   authentication data, it first looks for an PA-FX-COOKIE and if
+   present retrieves the context handle associated with the cookie,
+   typically by passing the context token from the decrypted cookie to
+   GSS_Import_sec_context().  The absence of an PA-FX-COOKIE indicates a
+   new conversation and the client sending an initial context token.
+
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 5]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   The KDC SHALL associate the KDC-REQ-BODY of the initial request with
+   the pre-authentication conversation.  On subsequent requests, the KDC
+   MUST abort the conversation and return an error if the KDC-REQ-BODY
+   differs from the initial request.  The nonce is excluded from this
+   comparison.  This extends the protection afforded by the channel
+   binding to all requests in the conversation, not just the request
+   where the mechanism validated the channel bindings.  (No specific
+   implementation is required, but one approach would be for the KDC to
+   include a digest of the KDC-REQ-BODY with the nonce set to zero in
+   the PA-FX-COOKIE contents.)
+
+   If no PA-GSS pre-authentication data is present, the KDC cannot
+   continue with GSS-API pre-authentication and will continue with other
+   pre-authentication methods or return an error as determined by local
+   policy.  If PA-GSS pre-authentication data is present but empty, the
+   KDC SHALL return a KDC_ERR_PREAUTH_FAILED error.  Otherwise,
+   GSS_Accept_sec_context() is called with the acceptor credential
+   handle, the token provided in the PA-GSS pre-authentication data, and
+   channel binding application data containing the DER-encoded KDC-REQ-
+   BODY.
+
+   If GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, the KDC
+   returns a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with the output
+   token included as PA-GSS pre-authentication data.  The acceptor state
+   is encoded, typically by calling GSS_Export_sec_context(), and the
+   encrypted result is placed in an PA-FX-COOKIE.
+
+   If GSS_Accept_sec_context() returns GSS_S_COMPLETE, the context is
+   ready for use and an AS-REP is returned using the reply key specified
+   in Section 6.  Otherwise, an appropriate error such as
+   KDC_ERR_PREAUTH_FAILED is returned to the client and the conversation
+   is aborted.  If the mechanism emitted an error token on failure, it
+   SHOULD be returned to the client.
+
+   If the GSS-API mechanism requires an odd number of messages to
+   establish a security context, the KDC MUST include an empty GSS-PA
+   pre-authentication data in the last message of a successful
+   conversation.
+
+5.  Indication of Supported Mechanisms
+
+   When the KDC sends a KDC_ERR_PREAUTH_REQUIRED error to the client, it
+   MAY include a pre-authentication data element indicating the set of
+   supported mechanisms.  The pre-authentication data comprises of a
+   SPNEGO server initiated initial context token as defined in [MS-SPNG]
+   3.2.5.2, containing the list of mechanisms supported by the acceptor.
+   Context state is discarded and as such the first PA-GSS from the
+   client is always an InitialContextToken ([RFC2743] Section 3.1).
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 6]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+6.  Reply Key Derivation
+
+   The GSS-API pre-authentication mechanism proposed in this draft
+   provides the Replace Reply Key facility [RFC6113].
+
+   After authentication is complete, the client and KDC replace the AS-
+   REP reply key with the output of calling GSS_Pseudo_random()
+   [RFC4401] with the following parameters:
+
+   context       The initiator or acceptor context handle
+
+   prf_key       GSS_C_PRF_KEY_FULL
+
+   prf_in        KRB-GSS || 0x00 || AS-REQ nonce
+
+   desired_output_len  The length in bytes of original reply key
+
+   The nonce is the nonce of the final AS-REQ in the conversation, and
+   is encoded as the little-endian binary representation of 4 bytes.
+   The new reply key has the same key type as the original key.  If FAST
+   is used, the new reply key SHOULD be strengthened by including a
+   strengthen key in the KrbFastResponse.
+
+7.  Naming
+
+   This specification permits Kerberos clients to authenticate without
+   knowing how the KDC will map their GSS-API initiator name to a
+   Kerberos principal.  In such cases the client SHALL set the value of
+   the cname field in the AS-REQ to the well-known [RFC6111] value
+   WELLKNOWN/FEDERATED, replacing it after a successful conversation
+   with the client name returned in the AS-REP.
+
+   When the initiator knows the Kerberos client name it wishes to
+   authenticate as, and the mechanism supports Kerberos names, the name
+   MUST be imported using the GSS_KRB5_NT_PRINCIPAL_NAME name type.
+   Otherwise, GSS_C_NT_USER_NAME SHOULD be used when importing NT-
+   PRINCIPAL names in the local realm, or NT-ENTERPRISE [RFC6806] names.
+   GSS_C_NT_HOSTBASED_SERVICE SHOULD be used when importing NT-SRV-HOST
+   or NT-SRV-INST names with a single instance.
+
+   This specification does not mandate a specific mapping of GSS-API
+   initiator names to Kerberos principal names.  KDCs MAY use the NT-
+   ENTERPRISE principal name type to avoid conflating any domain- or
+   realm-like components of initiator names with Kerberos realms.
+
+   The KDC MAY include an AD-GSS-COMPOSITE-NAME authorization data
+   element, containing name attribute information.  Its value is the
+   exp_composite_name octet string resulting from a successful call to
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 7]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   GSS_Export_name_composite() [RFC6680].  It SHOULD be enclosed in a
+   AD-IF-RELEVANT container.  The format of composite name tokens is
+   implementation dependent; services that cannot parse the name token
+   MUST fail if the authorization data element was not enclosed in AD-
+   IF-RELEVANT.
+
+8.  Anonymous Authentication
+
+   If the client wishes to authenticate anonymously using GSS-API pre-
+   authentication, it MUST specify both the request-anonymous flag in
+   the AS-REQ and anon_req_flag in the call to GSS_Init_sec_context().
+   If GSS_Accept_sec_context() set anon_state and returned an initiator
+   name of type GSS_C_NT_ANONYMOUS, the KDC MUST map the user to the
+   well-known anonymous PKINIT principal and realm defined in [RFC8062].
+
+   If GSS_Accept_sec_context() set anon_state but did not return an
+   initiator name of type GSS_C_NT_ANONYMOUS, then the KDC MUST return
+   the well-known anonymous principal but it MAY include the realm of
+   the initiator.
+
+9.  Security Considerations
+
+   The client SHOULD use FAST armor to protect the pre-authentication
+   conversation.
+
+   The KDC MUST maintain confidentiality and integrity of the PA-FX-
+   COOKIE contents, typically by encrypting it using a key known only to
+   itself.  Cookie values SHOULD be protected from replay attacks by
+   limiting their validity period and binding their contents to the
+   client name in the AS-REQ.
+
+   The establishment of a GSS-API security context is bound to the
+   client's AS-REQ through the inclusion of the encoded KDC-REQ-BODY as
+   channel bindings (see Section 4.1), and the nonce as input to the key
+   derivation function (see Section 6).  By asserting the KDC-REQ-BODY
+   does not change during the conversation (nonce notwithstanding), the
+   channel bindings protect all request bodies in the conversation.
+
+   The KDC MAY wish to restrict the set of GSS-API mechanisms it will
+   accept requests from.  When using SPNEGO [RFC4178] with GSS-API pre-
+   authentication, the client should take care not to select a mechanism
+   with weaker security properties than a different non-GSS-API pre-
+   authentication type that could have been used.
+
+   If mutual_state is false after GSS_Init_sec_context() completes, the
+   client MUST ensure that the KDC was authenticated by some other
+   means.
+
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 8]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+10.  IANA Considerations
+
+   Assign PA-GSS value in Pre-authentication and Typed Data, Kerberos
+   Parameters registry (preference for 633).
+
+   The ad-type number 633 (TBD) is assigned for AD-GSS-COMPOSITE-NAME,
+   updating the table in Section 7.5.4 of [RFC4120].
+
+11.  Normative References
+
+   [MS-SPNG]  "Simple and Protected GSS-API Negotiation Mechanism
+              (SPNEGO) Extension", <https://docs.microsoft.com/en-
+              us/openspecs/windows_protocols/ms-spng/f377a379-c24f-4a0f-
+              a3eb-0d835389e28a>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743,
+              DOI 10.17487/RFC2743, January 2000,
+              <https://www.rfc-editor.org/info/rfc2743>.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              DOI 10.17487/RFC4120, July 2005,
+              <https://www.rfc-editor.org/info/rfc4120>.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, DOI 10.17487/RFC4178, October 2005,
+              <https://www.rfc-editor.org/info/rfc4178>.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401,
+              DOI 10.17487/RFC4401, February 2006,
+              <https://www.rfc-editor.org/info/rfc4401>.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556,
+              DOI 10.17487/RFC4556, June 2006,
+              <https://www.rfc-editor.org/info/rfc4556>.
+
+
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                 [Page 9]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   [RFC6111]  Zhu, L., "Additional Kerberos Naming Constraints",
+              RFC 6111, DOI 10.17487/RFC6111, April 2011,
+              <https://www.rfc-editor.org/info/rfc6111>.
+
+   [RFC6113]  Hartman, S. and L. Zhu, "A Generalized Framework for
+              Kerberos Pre-Authentication", RFC 6113,
+              DOI 10.17487/RFC6113, April 2011,
+              <https://www.rfc-editor.org/info/rfc6113>.
+
+   [RFC6680]  Williams, N., Johansson, L., Hartman, S., and S.
+              Josefsson, "Generic Security Service Application
+              Programming Interface (GSS-API) Naming Extensions",
+              RFC 6680, DOI 10.17487/RFC6680, August 2012,
+              <https://www.rfc-editor.org/info/rfc6680>.
+
+   [RFC6806]  Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
+              Principal Name Canonicalization and Cross-Realm
+              Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012,
+              <https://www.rfc-editor.org/info/rfc6806>.
+
+   [RFC7055]  Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for
+              the Extensible Authentication Protocol", RFC 7055,
+              DOI 10.17487/RFC7055, December 2013,
+              <https://www.rfc-editor.org/info/rfc7055>.
+
+   [RFC8062]  Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
+              "Anonymity Support for Kerberos", RFC 8062,
+              DOI 10.17487/RFC8062, February 2017,
+              <https://www.rfc-editor.org/info/rfc8062>.
+
+Authors' Addresses
+
+   Alejandro Perez-Mendez
+   Jisc
+   4 Portwall Lane
+   Bristol
+   BS1 6NB
+   United Kingdom
+
+   Email: alex.perez-mendez@jisc.ac.uk
+
+
+   Rafa Marin-Lopez
+   University of Murcia
+   Campus de Espinardo S/N, Faculty of Computer Science
+   30100 Murcia Murcia
+   Spain
+
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                [Page 10]
+
+Internet-Draft              GSS-API pre-auth              September 2021
+
+
+   Phone: +34 868 88 85 01
+   Email: rafa@um.es
+
+
+   Fernando Pereniguez-Garcia
+   University Defense Center
+   Spanish Air Force Academy
+   30720 San Javier Murcia
+   Spain
+
+   Phone: +34 968 18 99 46
+   Email: fernando.pereniguez@cud.upct.es
+
+
+   Gabriel Lopez-Millan
+   University of Murcia
+   Campus de Espinardo S/N, Faculty of Computer Science
+   30100 Murcia Murcia
+   Spain
+
+   Phone: +34 868 88 85 04
+   Email: gabilm@um.es
+
+
+   Luke Howard-Bentata
+   PADL Software Pty Ltd
+   PO Box 59
+   Central Park Victoria 3145
+   Australia
+
+   Email: lukeh@padl.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perez-Mendez, et al.      Expires 27 March 2022                [Page 11]
diff --git a/third_party/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/third_party/heimdal/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
new file mode 100644
index 00000000000..24325fdbda7
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
new file mode 100644
index 00000000000..64ca1ac498b
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-02.txt b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-02.txt
new file mode 100644
index 00000000000..6b9989f871a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-02.txt
@@ -0,0 +1,618 @@
+
+
+
+
+
+
+
+
+
+Kerberos Working Group                                        K. Raeburn
+Document: draft-raeburn-krb-rijndael-krb-02.txt                      MIT
+                                                        November 1, 2002
+                                                     expires May 1, 2003
+
+                     AES Encryption for Kerberos 5
+
+Abstract
+
+   Recently the US National Institute of Standards and Technology chose
+   a new Advanced Encryption Standard [AES], which is significantly
+   faster and (it is believed) more secure than the old DES algorithm.
+   This document is a specification for the addition of this algorithm
+   to the Kerberos cryptosystem suite [KCRYPTO].
+
+   Comments should be sent to the author, or to the IETF Kerberos
+   working group (ietf-krb-wg@anl.gov).
+
+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. Introduction
+
+   This document defines encryption key and checksum types for Kerberos
+   5 using the AES algorithm recently chosen by NIST.  These new types
+   support 128-bit block encryption, and key sizes of 128 or 256 bits.
+
+   Using the "simplified profile" of [KCRYPTO], we can define a pair of
+   encryption and checksum schemes.  AES is used with cipher text
+   stealing to avoid message expansion, and SHA-1 [SHA1] is the
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                             November 2002
+
+
+   associated checksum function.
+
+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. Protocol Key Representation
+
+   The profile in [KCRYPTO] treats keys and random octet strings as
+   conceptually different.  But since the AES key space is dense, we can
+   use any bit string as a key.  We use the byte representation for the
+   key described in [AES], where the first bit of the bit string is the
+   high bit of the first byte of the byte string (octet string)
+   representation.
+
+4. Key Generation From Pass Phrases or Random Data
+
+   Given the above format for keys, we can generate keys from the
+   appropriate amounts of random data (128 or 256 bits) by simply
+   copying the input string.
+
+   To generate an encryption key from a pass phrase and salt string, we
+   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
+   indicated below, to generate an intermediate key (of the same length
+   as the desired final key), which is then passed into the DK function
+   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
+   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
+   produces a "random octet string", hence the application of the
+   random-to-key function even though it's effectively a simple identity
+   operation.)  The resulting key is the user's long-term key for use
+   with the encryption algorithm in question.
+
+    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
+    key = DK(tkey, "kerberos")
+
+   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
+   passphrase and salt, as described in Appendix B.1 to PKCS#5.
+
+   The number of iterations is specified by the string-to-key parameters
+   supplied.  The parameter string is four octets indicating an unsigned
+   number in big-endian order.  This is the number of iterations to be
+   performed.  If the value is 00 00 00 00, the number of iterations to
+   be performed is 4294967296 (2**32).  (Thus the minimum expressable
+   iteration count is 1.)
+
+   For environments where slower hardware is the norm, implementations
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                             November 2002
+
+
+   may wish to limit the number of iterations to prevent a spoofed
+   response from consuming lots of client-side CPU time; it is
+   recommended that this bound be no less than 50000.  Even for
+   environments with fast hardware, 4 billion iterations is likely to
+   take a fairly long time; much larger bounds might still be enforced,
+   and it might be wise for implementations to permit interruption of
+   this operation by the user if the environment allows for it.
+
+   If the string-to-key parameters are not supplied, the default value
+   to be used is 00 00 b0 00 (decimal 45056, indicating 45056
+   iterations, which takes slightly under 1 second on a 300MHz Pentium
+   II in tests run by the author).
+
+   Sample test vectors are given in the appendix.
+
+5. Cipher Text Stealing
+
+   Cipher block chaining is used to encrypt messages.  Unlike previous
+   Kerberos cryptosystems, we use cipher text stealing to handle the
+   possibly partial final block of the message.
+
+   Cipher text stealing is described on pages 195-196 of [AC], and
+   section 8 of [RC5]; it has the advantage that no message expansion is
+   done during encryption of messages of arbitrary sizes as is typically
+   done in CBC mode with padding.
+
+   Cipher text stealing, as defined in [RC5], assumes that more than one
+   block of plain text is available.  Since a one-block confounder is
+   added in the simplified profile of [KCRYPTO], and [KCRYPTO] requires
+   that the message to be encrypted cannot be empty, the minimum length
+   to be encrypted is one block plus one byte.  Thus we do not need to
+   do anything special to meet this constraint.
+
+   For consistency, cipher text stealing is always used for the last two
+   blocks of the data to be encrypted, as in [RC5].  If the data length
+   is a multiple of the block size, this is equivalent to plain CBC mode
+   with the last two cipher text blocks swapped.
+
+   A test vector is given in the appendix.
+
+6. Kerberos Algorithm Profile Parameters
+
+   This is a summary of the parameters to be used with the simplified
+   algorithm profile described in [KCRYPTO]:
+
+
+
+
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                             November 2002
+
+
+   +--------------------------------------------------------------------+
+   |               protocol key format       128- or 256-bit string     |
+   |                                                                    |
+   |            string-to-key function       PBKDF2+DK with variable    |
+   |                                         iteration count (see       |
+   |                                         above)                     |
+   |                                                                    |
+   |  default string-to-key parameters       00 09                      |
+   |                                                                    |
+   |        key-generation seed length       key size                   |
+   |                                                                    |
+   |            random-to-key function       identity function          |
+   |                                                                    |
+   |                  hash function, H       SHA-1                      |
+   |                                                                    |
+   |               HMAC output size, h       12 octets (96 bits)        |
+   |                                                                    |
+   |                confounder size, c       16 octets                  |
+   |                                                                    |
+   |             message block size, m       1 octet                    |
+   |                                                                    |
+   |  encryption/decryption functions,       AES in CBC-CTS mode with   |
+   |  E and D                                zero ivec                  |
+   +--------------------------------------------------------------------+
+
+   Using this profile with each key size gives us two each of encryption
+   and checksum algorithm definitions.
+
+7. Assigned Numbers
+
+   The following encryption type numbers are assigned:
+
+   +--------------------------------------------------------------------+
+   |                         encryption types                           |
+   +--------------------------------------------------------------------+
+   |         type name                  etype value          key size   |
+   +--------------------------------------------------------------------+
+   |   aes128-cts-hmac-sha1-96              17                 128      |
+   |   aes256-cts-hmac-sha1-96              18                 256      |
+   +--------------------------------------------------------------------+
+
+   The following checksum type numbers are assigned:
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                             November 2002
+
+
+   +--------------------------------------------------------------------+
+   |                          checksum types                            |
+   +--------------------------------------------------------------------+
+   |        type name                 sumtype value           length    |
+   +--------------------------------------------------------------------+
+   |    hmac-sha1-96-aes128                10                   96      |
+   |    hmac-sha1-96-aes256                11                   96      |
+   +--------------------------------------------------------------------+
+
+   These checksum types will be used with the corresponding encryption
+   types defined above.
+
+8. Recommendations
+
+   Both new cryptosystems are RECOMMENDED.  They should be more secure
+   than DES cryptosystems, and much faster than triple-DES.
+
+9. Security Considerations
+
+   This new algorithm has not been around long enough to receive the
+   decades of intense analysis that DES has received.  It is possible
+   that some weakness exists that has not been found by the
+   cryptographers analyzing these algorithms before and during the AES
+   selection process.
+
+   The use of the HMAC function has drawbacks for certain pass phrase
+   lengths.  For example, a pass phrase longer than the hash function
+   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
+   bytes) before applying the main HMAC algorithm.  However, entropy is
+   generally sparse in pass phrases, especially in long ones, so this
+   may not be a problem in the rare cases of users with long pass
+   phrases.
+
+   Also, generating a 256-bit key from a pass phrase of any length may
+   be deceptive, since the effective entropy in pass-phrase-derived key
+   cannot be nearly that large.
+
+   The iteration count in PBKDF2 appears to be useful primarily as a
+   constant multiplier for the amount of work required for an attacker
+   using brute-force methods.  Unfortunately, it also multiplies, by the
+   same amount, the work needed by a legitimate user with a valid
+   password.  Thus the work factor imposed on an attacker (who may have
+   many powerful workstations at his disposal) must be balanced against
+   the work factor imposed on the legitimate user (who may have a PDA or
+   cell phone); the available computing power on either side increases
+   as time goes on, as well.  A better way to deal with the brute-force
+   attack is through preauthentication mechanisms that provide better
+   protection of, the user's long-term key.  Use of such mechanisms is
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                             November 2002
+
+
+   out of scope for this document.
+
+   Any benefit against other attacks specific to the HMAC or SHA-1
+   algorithms is probably achieved with a fairly small number of
+   iterations.
+
+   Cipher text stealing mode, since it requires no additional padding,
+   will reveal the exact length of each message being encrypted, rather
+   than merely bounding it to a small range of possible lengths as in
+   CBC mode.  Such obfuscation should not be relied upon at higher
+   levels in any case; if the length must be obscured from an outside
+   observer, it should be done by intentionally varying the length of
+   the message to be encrypted.
+
+   The author is not a cryptographer.  Caveat emptor.
+
+10. IANA Considerations
+
+   None.
+
+11. Acknowledgements
+
+   Thanks to John Brezak, Gerardo Diaz Cuellar and Marcus Watts for
+   feedback on earlier versions of this document.
+
+12. Normative References
+
+   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
+   and Sons, New York, 1996.
+
+   [AES] National Institute of Standards and Technology, U.S. Department
+   of Commerce, "Advanced Encryption Standard", Federal Information
+   Processing Standards Publication 197, Washington, DC, November 2001.
+
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
+   progress.
+
+   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
+   Specification Version 2.0", RFC 2898, September 2000.
+
+   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+   RC5-CTS Algorithms", RFC 2040, October 1996.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+   3", RFC 2026, October 1996.
+
+   [SHA1] National Institute of Standards and Technology, U.S.
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                             November 2002
+
+
+   Department of Commerce, "Secure Hash Standard", Federal Information
+   Processing Standards Publication 180-1, Washington, DC, April 1995.
+
+13. Informative References
+
+   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
+   December 2001.
+
+14. Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+15. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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."
+
+A. Sample test vectors
+
+   Sample values for the string-to-key function are included below.
+
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                             November 2002
+
+
+   Iteration count = 1
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+   128-bit AES key:
+       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
+   256-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
+   256-bit AES key:
+       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
+       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
+
+   Iteration count = 2
+   Pass phrase = "password"
+   Salt="ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+   128-bit AES key:
+       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
+   256-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
+   256-bit AES key:
+       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
+       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
+
+   Iteration count = 1200
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+   128-bit AES key:
+       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
+   256-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
+   256-bit AES key:
+       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
+       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                             November 2002
+
+
+   Iteration count = 5
+   Pass phrase = "password"
+   Salt=0x1234567878563412
+   128-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+   128-bit AES key:
+       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
+   256-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
+   256-bit AES key:
+       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
+       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
+   (This test is based on values given in [PECMS].)
+
+   Iteration count = 1200
+   Pass phrase = (64 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt="pass phrase equals block size"
+   128-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+   128-bit AES key:
+       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
+   256-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
+   256-bit AES key:
+       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
+       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
+
+   Iteration count = 1200
+   Pass phrase = (65 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt = "pass phrase exceeds block size"
+   128-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+   128-bit AES key:
+       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
+   256-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
+   256-bit AES key:
+       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
+       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
+
+
+
+
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                             November 2002
+
+
+   Iteration count = 50
+   Pass phrase = g-clef (0xf09d849e)
+   Salt = "EXAMPLE.COMpianist"
+   128-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+   128-bit AES key:
+       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
+   256-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
+   256-bit AES key:
+       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
+       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
+
+   Some test vectors for CBC with cipher text stealing, using an initial
+   vector of all-zero.
+
+   AES 128-bit key:
+       63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20
+   Output:
+       c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+       97
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
+   Output:
+       fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+   Output:
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 10]
+
+INTERNET DRAFT                                             November 2002
+
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+       61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+       48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 11]
diff --git a/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt
new file mode 100644
index 00000000000..70395f2ba8d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt
@@ -0,0 +1,674 @@
+
+
+
+
+
+
+
+
+
+Kerberos Working Group                                        K. Raeburn
+Document: draft-raeburn-krb-rijndael-krb-03.txt                      MIT
+                                                       February 24, 2003
+                                                 expires August 24, 2003
+
+                     AES Encryption for Kerberos 5
+
+Abstract
+
+   Recently the US National Institute of Standards and Technology chose
+   a new Advanced Encryption Standard [AES], which is significantly
+   faster and (it is believed) more secure than the old DES algorithm.
+   This document is a specification for the addition of this algorithm
+   to the Kerberos cryptosystem suite [KCRYPTO].
+
+   Comments should be sent to the author, or to the IETF Kerberos
+   working group (ietf-krb-wg@anl.gov).
+
+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. Introduction
+
+   This document defines encryption key and checksum types for Kerberos
+   5 using the AES algorithm recently chosen by NIST.  These new types
+   support 128-bit block encryption, and key sizes of 128 or 256 bits.
+
+   Using the "simplified profile" of [KCRYPTO], we can define a pair of
+   encryption and checksum schemes.  AES is used with cipher text
+   stealing to avoid message expansion, and SHA-1 [SHA1] is the
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                             February 2003
+
+
+   associated checksum function.
+
+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. Protocol Key Representation
+
+   The profile in [KCRYPTO] treats keys and random octet strings as
+   conceptually different.  But since the AES key space is dense, we can
+   use any bit string of appropriate length as a key.  We use the byte
+   representation for the key described in [AES], where the first bit of
+   the bit string is the high bit of the first byte of the byte string
+   (octet string) representation.
+
+4. Key Generation From Pass Phrases or Random Data
+
+   Given the above format for keys, we can generate keys from the
+   appropriate amounts of random data (128 or 256 bits) by simply
+   copying the input string.
+
+   To generate an encryption key from a pass phrase and salt string, we
+   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
+   indicated below, to generate an intermediate key (of the same length
+   as the desired final key), which is then passed into the DK function
+   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
+   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
+   produces a "random octet string", hence the application of the
+   random-to-key function even though it's effectively a simple identity
+   operation.)  The resulting key is the user's long-term key for use
+   with the encryption algorithm in question.
+
+    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
+    key = DK(tkey, "kerberos")
+
+   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
+   passphrase and salt, as described in Appendix B.1 to PKCS#5.
+
+   The number of iterations is specified by the string-to-key parameters
+   supplied.  The parameter string is four octets indicating an unsigned
+   number in big-endian order.  This is the number of iterations to be
+   performed.  If the value is 00 00 00 00, the number of iterations to
+   be performed is 4294967296 (2**32).  (Thus the minimum expressable
+   iteration count is 1.)
+
+   For environments where slower hardware is the norm, implementations
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                             February 2003
+
+
+   may wish to limit the number of iterations to prevent a spoofed
+   response from consuming lots of client-side CPU time; it is
+   recommended that this bound be no less than 50000.  Even for
+   environments with fast hardware, 4 billion iterations is likely to
+   take a fairly long time; much larger bounds might still be enforced,
+   and it might be wise for implementations to permit interruption of
+   this operation by the user if the environment allows for it.
+
+   If the string-to-key parameters are not supplied, the default value
+   to be used is 00 00 b0 00 (decimal 45056, indicating 45056
+   iterations, which takes slightly under 1 second on a 300MHz Pentium
+   II in tests run by the author).
+
+   Sample test vectors are given in the appendix.
+
+5. Cipher Text Stealing
+
+   Cipher block chaining is used to encrypt messages.  Unlike previous
+   Kerberos cryptosystems, we use cipher text stealing to handle the
+   possibly partial final block of the message.
+
+   Cipher text stealing is described on pages 195-196 of [AC], and
+   section 8 of [RC5]; it has the advantage that no message expansion is
+   done during encryption of messages of arbitrary sizes as is typically
+   done in CBC mode with padding.
+
+   Cipher text stealing, as defined in [RC5], assumes that more than one
+   block of plain text is available.  If exactly one block is to be
+   encrypted, that block is simply encrypted with AES (also known as ECB
+   mode).  Input of less than one block is padded at the end to one
+   block; the values of the padding bits are unspecified.
+   (Implementations may use all-zero padding, but protocols should not
+   rely on the result being deterministic.  Implementations may use
+   random padding, but protocols should not rely on the result not being
+   deterministic.  Note that in most cases, the Kerberos encryption
+   profile will add a random confounder independent of this padding.)
+
+   For consistency, cipher text stealing is always used for the last two
+   blocks of the data to be encrypted, as in [RC5].  If the data length
+   is a multiple of the block size, this is equivalent to plain CBC mode
+   with the last two cipher text blocks swapped.
+
+   A test vector is given in the appendix.
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                             February 2003
+
+
+6. Kerberos Algorithm Profile Parameters
+
+   This is a summary of the parameters to be used with the simplified
+   algorithm profile described in [KCRYPTO]:
+
+   +--------------------------------------------------------------------+
+   |               protocol key format       128- or 256-bit string     |
+   |                                                                    |
+   |            string-to-key function       PBKDF2+DK with variable    |
+   |                                         iteration count (see       |
+   |                                         above)                     |
+   |                                                                    |
+   |  default string-to-key parameters       00 00 b0 00                |
+   |                                                                    |
+   |        key-generation seed length       key size                   |
+   |                                                                    |
+   |            random-to-key function       identity function          |
+   |                                                                    |
+   |                  hash function, H       SHA-1                      |
+   |                                                                    |
+   |               HMAC output size, h       12 octets (96 bits)        |
+   |                                                                    |
+   |             message block size, m       1 octet                    |
+   |                                                                    |
+   |  encryption/decryption functions,       AES in CBC-CTS mode with   |
+   |  E and D                                zero ivec (cipher block    |
+   |                                         size 16 octets)            |
+   +--------------------------------------------------------------------+
+
+   Using this profile with each key size gives us two each of encryption
+   and checksum algorithm definitions.
+
+7. Assigned Numbers
+
+   The following encryption type numbers are assigned:
+
+   +--------------------------------------------------------------------+
+   |                         encryption types                           |
+   +--------------------------------------------------------------------+
+   |         type name                  etype value          key size   |
+   +--------------------------------------------------------------------+
+   |   aes128-cts-hmac-sha1-96              17                 128      |
+   |   aes256-cts-hmac-sha1-96              18                 256      |
+   +--------------------------------------------------------------------+
+
+   The following checksum type numbers are assigned:
+
+
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                             February 2003
+
+
+   +--------------------------------------------------------------------+
+   |                          checksum types                            |
+   +--------------------------------------------------------------------+
+   |        type name                 sumtype value           length    |
+   +--------------------------------------------------------------------+
+   |    hmac-sha1-96-aes128                15                   96      |
+   |    hmac-sha1-96-aes256                16                   96      |
+   +--------------------------------------------------------------------+
+
+   These checksum types will be used with the corresponding encryption
+   types defined above.
+
+8. Security Considerations
+
+   This new algorithm has not been around long enough to receive the
+   decades of intense analysis that DES has received.  It is possible
+   that some weakness exists that has not been found by the
+   cryptographers analyzing these algorithms before and during the AES
+   selection process.
+
+   The use of the HMAC function has drawbacks for certain pass phrase
+   lengths.  For example, a pass phrase longer than the hash function
+   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
+   bytes) before applying the main HMAC algorithm.  However, entropy is
+   generally sparse in pass phrases, especially in long ones, so this
+   may not be a problem in the rare cases of users with long pass
+   phrases.
+
+   Also, generating a 256-bit key from a pass phrase of any length may
+   be deceptive, since the effective entropy in pass-phrase-derived key
+   cannot be nearly that large.
+
+   The iteration count in PBKDF2 appears to be useful primarily as a
+   constant multiplier for the amount of work required for an attacker
+   using brute-force methods.  Unfortunately, it also multiplies, by the
+   same amount, the work needed by a legitimate user with a valid
+   password.  Thus the work factor imposed on an attacker (who may have
+   many powerful workstations at his disposal) must be balanced against
+   the work factor imposed on the legitimate user (who may have a PDA or
+   cell phone); the available computing power on either side increases
+   as time goes on, as well.  A better way to deal with the brute-force
+   attack is through preauthentication mechanisms that provide better
+   protection of, the user's long-term key.  Use of such mechanisms is
+   out of scope for this document.
+
+   If the PBKDF2 iteration count can be spoofed by an intruder on the
+   network, and the limit on the accepted iteration count is very high,
+   the intruder may be able to introduce a form of denial of service
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                             February 2003
+
+
+   attack against the client by sending a very high iteration count,
+   causing the client to spend a great deal of CPU time computing an
+   incorrect key.
+
+   Any benefit against other attacks specific to the HMAC or SHA-1
+   algorithms is probably achieved with a fairly small number of
+   iterations.
+
+   Cipher text stealing mode, since it requires no additional padding in
+   most cases, will reveal the exact length of each message being
+   encrypted, rather than merely bounding it to a small range of
+   possible lengths as in CBC mode.  Such obfuscation should not be
+   relied upon at higher levels in any case; if the length must be
+   obscured from an outside observer, it should be done by intentionally
+   varying the length of the message to be encrypted.
+
+   The author is not a cryptographer.  Caveat emptor.
+
+9. IANA Considerations
+
+   None.
+
+10. Acknowledgements
+
+   Thanks to John Brezak, Gerardo Diaz Cuellar and Marcus Watts for
+   feedback on earlier versions of this document.
+
+11. Normative References
+
+   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
+   and Sons, New York, 1996.
+
+   [AES] National Institute of Standards and Technology, U.S. Department
+   of Commerce, "Advanced Encryption Standard", Federal Information
+   Processing Standards Publication 197, Washington, DC, November 2001.
+
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
+   progress.
+
+   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
+   Specification Version 2.0", RFC 2898, September 2000.
+
+   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+   RC5-CTS Algorithms", RFC 2040, October 1996.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+   3", RFC 2026, October 1996.
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                             February 2003
+
+
+   [SHA1] National Institute of Standards and Technology, U.S.
+   Department of Commerce, "Secure Hash Standard", Federal Information
+   Processing Standards Publication 180-1, Washington, DC, April 1995.
+
+12. Informative References
+
+   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
+   December 2001.
+
+13. Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+14. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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."
+
+A. Sample test vectors
+
+   Sample values for the string-to-key function are included below.
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Iteration count = 1
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+   128-bit AES key:
+       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
+   256-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
+   256-bit AES key:
+       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
+       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
+
+   Iteration count = 2
+   Pass phrase = "password"
+   Salt="ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+   128-bit AES key:
+       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
+   256-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
+   256-bit AES key:
+       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
+       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
+
+   Iteration count = 1200
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+   128-bit AES key:
+       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
+   256-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
+   256-bit AES key:
+       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
+       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Iteration count = 5
+   Pass phrase = "password"
+   Salt=0x1234567878563412
+   128-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+   128-bit AES key:
+       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
+   256-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
+   256-bit AES key:
+       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
+       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
+   (This test is based on values given in [PECMS].)
+
+   Iteration count = 1200
+   Pass phrase = (64 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt="pass phrase equals block size"
+   128-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+   128-bit AES key:
+       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
+   256-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
+   256-bit AES key:
+       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
+       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
+
+   Iteration count = 1200
+   Pass phrase = (65 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt = "pass phrase exceeds block size"
+   128-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+   128-bit AES key:
+       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
+   256-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
+   256-bit AES key:
+       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
+       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
+
+
+
+
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Iteration count = 50
+   Pass phrase = g-clef (0xf09d849e)
+   Salt = "EXAMPLE.COMpianist"
+   128-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+   128-bit AES key:
+       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
+   256-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
+   256-bit AES key:
+       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
+       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
+
+   Some test vectors for CBC with cipher text stealing, using an initial
+   vector of all-zero.
+
+   AES 128-bit key:
+       63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20
+   Output:
+       c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+       97
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
+   Output:
+       fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+   Output:
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 10]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+       61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+       48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+
+Document History (delete before RFC publication)
+
+   Major changes from -02 to -03:
+
+   Describe encryption of data of one block or less.
+
+   Fix default string-to-key parameters in table to agree with text.
+
+   Remove Recommendations section; the Kerberos RFC will cover
+   recommendations and requirements.
+
+   Restore change history, added notes to RFC editor saying to remove
+   it, and update the [KCRYPTO] entry in Normative References.
+
+   Delete confounder size, since it's gone from the simplified profile
+   in crypto-03.
+
+   Change checksum numbers, since Assar Westerlund says 10 is in use.
+
+
+
+
+Raeburn                                                        [Page 11]
+
+INTERNET DRAFT                                             February 2003
+
+
+   Add Security Consideration about denial of service caused by very
+   high spoofed iteration count.
+
+   Major changes from -01 to -02:
+
+   Add test vectors.
+
+   Drop 192/384-bit variants.  Prevailing opinion seems to be that
+   128-bit keys are good for speed, and 256-bit for paranoia, and no one
+   cares about the intermediate sizes.
+
+   Update for new string-to-key params per new Kerberos crypto draft and
+   discussions during the IETF conferences at Salt Lake City, December,
+   2001, and Minneapolis, March, 2002.
+
+   Drop Serpent and Twofish; Rijndael is the only one people care about.
+   Use "AES" in preference to "Rijndael".
+
+   Use cipher text stealing mode intead of plain CBC, and add -cts to
+   the algorithm names.
+
+   Drop SHA-2, stick with SHA-1.  New test cases to exercise boundary
+   conditions in HMAC used in string-to-key.
+
+   Split References into Normative/Informative.
+
+   Major changes from -00:
+
+   Define different types based on key/hash sizes, with hash size always
+   twice key size.  Use simplified profile of revised section 6 of
+   RFC1510bis.  Drop "-kd" from the names.
+
+   Use PKCS#5 instead of simple hash.  Changed string-to-key vector to
+   use some "Appendix Z" cases also submitted for kerberos-revisions.
+
+Notes to RFC Editor
+
+   Assuming this document goes through Last Call along with the Kerberos
+   crypto framework draft, the reference entry for [KCRYPTO] will list
+   the draft name, not the RFC number.  This should be replaced with the
+   RFC info.
+
+   The "Document History" section should be deleted, as should this one.
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 12]
diff --git a/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-05.txt b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-05.txt
new file mode 100644
index 00000000000..38ef593a6c9
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-05.txt
@@ -0,0 +1,730 @@
+
+
+
+
+
+
+
+
+
+Kerberos Working Group                                        K. Raeburn
+Document: draft-raeburn-krb-rijndael-krb-05.txt                      MIT
+                                                           June 20, 2003
+                                               expires December 20, 2003
+
+                     AES Encryption for Kerberos 5
+
+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.
+
+Abstract
+
+   Recently the US National Institute of Standards and Technology chose
+   a new Advanced Encryption Standard, which is significantly faster and
+   (it is believed) more secure than the old DES algorithm.  This
+   document is a specification for the addition of this algorithm to the
+   Kerberos cryptosystem suite.
+
+   Comments should be sent to the author, or to the IETF Kerberos
+   working group (ietf-krb-wg@anl.gov).
+
+1. Introduction
+
+   This document defines encryption key and checksum types for Kerberos
+   5 using the AES algorithm recently chosen by NIST.  These new types
+   support 128-bit block encryption, and key sizes of 128 or 256 bits.
+
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   Using the "simplified profile" of [KCRYPTO], we can define a pair of
+   encryption and checksum schemes.  AES is used with cipher text
+   stealing to avoid message expansion, and SHA-1 [SHA1] is the
+   associated checksum function.
+
+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. Protocol Key Representation
+
+   The profile in [KCRYPTO] treats keys and random octet strings as
+   conceptually different.  But since the AES key space is dense, we can
+   use any bit string of appropriate length as a key.  We use the byte
+   representation for the key described in [AES], where the first bit of
+   the bit string is the high bit of the first byte of the byte string
+   (octet string) representation.
+
+4. Key Generation From Pass Phrases or Random Data
+
+   Given the above format for keys, we can generate keys from the
+   appropriate amounts of random data (128 or 256 bits) by simply
+   copying the input string.
+
+   To generate an encryption key from a pass phrase and salt string, we
+   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
+   indicated below, to generate an intermediate key (of the same length
+   as the desired final key), which is then passed into the DK function
+   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
+   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
+   produces a "random octet string", hence the application of the
+   random-to-key function even though it's effectively a simple identity
+   operation.)  The resulting key is the user's long-term key for use
+   with the encryption algorithm in question.
+
+    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
+    key = DK(tkey, "kerberos")
+
+   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
+   passphrase and salt, as described in Appendix B.1 to PKCS#5.
+
+   The number of iterations is specified by the string-to-key parameters
+   supplied.  The parameter string is four octets indicating an unsigned
+   number in big-endian order.  This is the number of iterations to be
+   performed.  If the value is 00 00 00 00, the number of iterations to
+   be performed is 4294967296 (2**32).  (Thus the minimum expressable
+
+
+
+Raeburn                                                         [Page 2]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   iteration count is 1.)
+
+   For environments where slower hardware is the norm, implementations
+   may wish to limit the number of iterations to prevent a spoofed
+   response from consuming lots of client-side CPU time; it is
+   recommended that this bound be no less than 50000.  Even for
+   environments with fast hardware, 4 billion iterations is likely to
+   take a fairly long time; much larger bounds might still be enforced,
+   and it might be wise for implementations to permit interruption of
+   this operation by the user if the environment allows for it.
+
+   If the string-to-key parameters are not supplied, the value used is
+   00 00 10 00 (decimal 4096, indicating 4096 iterations).
+
+   Note that this is NOT a requirement, nor even a recommendation, for
+   this value to be used in "optimistic preauthentication" (e.g.,
+   attempting timestamp-based preauthentication using the user's long-
+   term key, without having first communicated with the KDC) in the
+   absence of additional information, nor as a default value for sites
+   to use for their principals' long-term keys in their Kerberos
+   database.  It is simply the interpretation of the absence of the
+   string-to-key parameter field when the KDC has had an opportunity to
+   provide it.
+
+   Sample test vectors are given in the appendix.
+
+5. Cipher Text Stealing
+
+   Cipher block chaining is used to encrypt messages.  Unlike previous
+   Kerberos cryptosystems, we use cipher text stealing to handle the
+   possibly partial final block of the message.
+
+   Cipher text stealing is described on pages 195-196 of [AC], and
+   section 8 of [RC5]; it has the advantage that no message expansion is
+   done during encryption of messages of arbitrary sizes as is typically
+   done in CBC mode with padding.
+
+   Cipher text stealing, as defined in [RC5], assumes that more than one
+   block of plain text is available.  If exactly one block is to be
+   encrypted, that block is simply encrypted with AES (also known as ECB
+   mode).  Input of less than one block is padded at the end to one
+   block; the values of the padding bits are unspecified.
+   (Implementations may use all-zero padding, but protocols should not
+   rely on the result being deterministic.  Implementations may use
+   random padding, but protocols should not rely on the result not being
+   deterministic.  Note that in most cases, the Kerberos encryption
+   profile will add a random confounder independent of this padding.)
+
+
+
+
+Raeburn                                                         [Page 3]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   For consistency, cipher text stealing is always used for the last two
+   blocks of the data to be encrypted, as in [RC5].  If the data length
+   is a multiple of the block size, this is equivalent to plain CBC mode
+   with the last two cipher text blocks swapped.
+
+   A test vector is given in the appendix.
+
+6. Kerberos Algorithm Profile Parameters
+
+   This is a summary of the parameters to be used with the simplified
+   algorithm profile described in [KCRYPTO]:
+
+   +--------------------------------------------------------------------+
+   |               protocol key format       128- or 256-bit string     |
+   |                                                                    |
+   |            string-to-key function       PBKDF2+DK with variable    |
+   |                                         iteration count (see       |
+   |                                         above)                     |
+   |                                                                    |
+   |  default string-to-key parameters       00 00 10 00                |
+   |                                                                    |
+   |        key-generation seed length       key size                   |
+   |                                                                    |
+   |            random-to-key function       identity function          |
+   |                                                                    |
+   |                  hash function, H       SHA-1                      |
+   |                                                                    |
+   |               HMAC output size, h       12 octets (96 bits)        |
+   |                                                                    |
+   |             message block size, m       1 octet                    |
+   |                                                                    |
+   |  encryption/decryption functions,       AES in CBC-CTS mode with   |
+   |  E and D                                zero ivec (cipher block    |
+   |                                         size 16 octets)            |
+   +--------------------------------------------------------------------+
+
+   Using this profile with each key size gives us two each of encryption
+   and checksum algorithm definitions.
+
+7. Assigned Numbers
+
+   The following encryption type numbers are assigned:
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 4]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   +--------------------------------------------------------------------+
+   |                         encryption types                           |
+   +--------------------------------------------------------------------+
+   |         type name                  etype value          key size   |
+   +--------------------------------------------------------------------+
+   |   aes128-cts-hmac-sha1-96              17                 128      |
+   |   aes256-cts-hmac-sha1-96              18                 256      |
+   +--------------------------------------------------------------------+
+
+   The following checksum type numbers are assigned:
+
+   +--------------------------------------------------------------------+
+   |                          checksum types                            |
+   +--------------------------------------------------------------------+
+   |        type name                 sumtype value           length    |
+   +--------------------------------------------------------------------+
+   |    hmac-sha1-96-aes128                15                   96      |
+   |    hmac-sha1-96-aes256                16                   96      |
+   +--------------------------------------------------------------------+
+
+   These checksum types will be used with the corresponding encryption
+   types defined above.
+
+8. Security Considerations
+
+   This new algorithm has not been around long enough to receive the
+   decades of intense analysis that DES has received.  It is possible
+   that some weakness exists that has not been found by the
+   cryptographers analyzing these algorithms before and during the AES
+   selection process.
+
+   The use of the HMAC function has drawbacks for certain pass phrase
+   lengths.  For example, a pass phrase longer than the hash function
+   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
+   bytes) before applying the main HMAC algorithm.  However, entropy is
+   generally sparse in pass phrases, especially in long ones, so this
+   may not be a problem in the rare cases of users with long pass
+   phrases.
+
+   Also, generating a 256-bit key from a pass phrase of any length may
+   be deceptive, since the effective entropy in pass-phrase-derived key
+   cannot be nearly that large.
+
+   The iteration count in PBKDF2 appears to be useful primarily as a
+   constant multiplier for the amount of work required for an attacker
+   using brute-force methods.  Unfortunately, it also multiplies, by the
+   same amount, the work needed by a legitimate user with a valid
+   password.  Thus the work factor imposed on an attacker (who may have
+
+
+
+Raeburn                                                         [Page 5]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   many powerful workstations at his disposal) must be balanced against
+   the work factor imposed on the legitimate user (who may have a PDA or
+   cell phone); the available computing power on either side increases
+   as time goes on, as well.  A better way to deal with the brute-force
+   attack is through preauthentication mechanisms that provide better
+   protection of the user's long-term key.  Use of such mechanisms is
+   out of scope for this document.
+
+   If a site does wish to use this means of protection against a brute-
+   force attack, the iteration count should be chosen based on the
+   facilities expected to be available to an attacker, and the amount of
+   work the attacker should be required to perform to acquire the key or
+   password.
+
+   As an example:
+
+      The author's tests on a 2GHz Pentium 4 system indicated that in
+      one second, nearly 90000 iterations could be done, producing a
+      256-bit key.  This was using the SHA-1 assembly implementation
+      from OpenSSL, and a pre-release version of the PBKDF2 code for
+      MIT's Kerberos package, on a single system.  No attempt was made
+      to do multiple hashes in parallel, so we assume an attacker doing
+      so can probably do at least 100000 iterations per second --
+      rounded up to 2**17, for ease of calculation.  For simplicity, we
+      also assume the final AES encryption step costs nothing.
+
+      Paul Leach estimates [LEACH] that a password-cracking dictionary
+      may have on the order of 2**21 entries, with capitalization,
+      punctuation, and other variations contributing perhaps a factor of
+      2**11, giving a ballpark estimate of 2**32.
+
+      Thus, for a known iteration count N and a known salt string, an
+      attacker with some number of computers comparable to the author's
+      would need roughly N*2**15 CPU seconds to convert the entire
+      dictionary plus variations into keys.
+
+      An attacker using a dozen such computers for a month would have
+      roughly 2**25 CPU seconds available.  So using 2**12 (4096)
+      iterations would mean an attacker with a dozen such computers
+      dedicated to a brute-force attack against a single key (actually,
+      any password-derived keys sharing the same salt and iteration
+      count) would process all the variations of the dictionary entries
+      in four months, and on average, would likely find the user's
+      password in two months.
+
+      Thus, if this form of attack is of concern, an iteration count a
+      few orders of magnitude higher should be chosen, and users should
+      be required to change their passwords every few months.  Perhaps
+
+
+
+Raeburn                                                         [Page 6]
+
+INTERNET DRAFT                                                 June 2003
+
+
+      several orders of magnitude, since many users will tend to use the
+      shorter and simpler passwords (as much as they can get away with,
+      given a site's password quality checks) that the attacker would
+      likely try first.
+
+      Since this estimate is based on currently available CPU power, the
+      iteration counts used for this mode of defense should be increased
+      over time, at perhaps 40%-60% each year or so.
+
+      Note that if the attacker has a large amount of storage available,
+      intermediate results could be cached, saving a lot of work for the
+      next attack with the same salt and a greater number of iterations
+      than had been run at the point where the intermediate results were
+      saved.  Thus, it would be wise to generate a new random salt
+      string when passwords are changed.  The default salt string,
+      derived from the principal name, only protects against the use of
+      one dictionary of keys against multiple users.
+
+   If the PBKDF2 iteration count can be spoofed by an intruder on the
+   network, and the limit on the accepted iteration count is very high,
+   the intruder may be able to introduce a form of denial of service
+   attack against the client by sending a very high iteration count,
+   causing the client to spend a great deal of CPU time computing an
+   incorrect key.
+
+   An intruder spoofing the KDC reply, providing a low iteration count,
+   and reading the client's reply from the network may be able to reduce
+   the work needed in the brute-force attack outlined above.  Thus,
+   implementations may wish to enforce lower bounds on the number of
+   iterations that will be used.
+
+   Since threat models and typical end-user equipment will vary widely
+   from site to site, allowing site-specific configuration of such
+   bounds is recommended.
+
+   Any benefit against other attacks specific to the HMAC or SHA-1
+   algorithms is probably achieved with a fairly small number of
+   iterations.
+
+   In the "optimistic preauthentication" case mentioned in section 3,
+   the client may attempt to produce a key without first communicating
+   with the KDC.  If the client has no additional information, it can
+   only guess as to the iteration count to be used.  Even such
+   heuristics as "iteration count X was used to acquire tickets for the
+   same principal only N hours ago" can be wrong.  Given the
+   recommendation above for increasing the iteration counts used over
+   time, it is impossible to recommend any specific default value for
+   this case; allowing site-local configuration is recommended.  (If the
+
+
+
+Raeburn                                                         [Page 7]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   lower and upper bound checks described above are implemented, the
+   default count for optimistic preauthentication should be between
+   those bounds.)
+
+   Cipher text stealing mode, since it requires no additional padding in
+   most cases, will reveal the exact length of each message being
+   encrypted, rather than merely bounding it to a small range of
+   possible lengths as in CBC mode.  Such obfuscation should not be
+   relied upon at higher levels in any case; if the length must be
+   obscured from an outside observer, it should be done by intentionally
+   varying the length of the message to be encrypted.
+
+   The author is not a cryptographer.  Caveat emptor.
+
+9. IANA Considerations
+
+   None.
+
+10. Acknowledgements
+
+   Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
+   Leach, Marcus Watts and others for feedback on earlier versions of
+   this document.
+
+A. Sample test vectors
+
+   Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
+   included below.
+
+   Iteration count = 1
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+   128-bit AES key:
+       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
+   256-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
+   256-bit AES key:
+       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
+       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 8]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   Iteration count = 2
+   Pass phrase = "password"
+   Salt="ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+   128-bit AES key:
+       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
+   256-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
+   256-bit AES key:
+       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
+       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
+
+   Iteration count = 1200
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+   128-bit AES key:
+       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
+   256-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
+   256-bit AES key:
+       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
+       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
+
+   Iteration count = 5
+   Pass phrase = "password"
+   Salt=0x1234567878563412
+   128-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+   128-bit AES key:
+       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
+   256-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
+   256-bit AES key:
+       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
+       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
+   (This test is based on values given in [PECMS].)
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 9]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   Iteration count = 1200
+   Pass phrase = (64 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt="pass phrase equals block size"
+   128-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+   128-bit AES key:
+       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
+   256-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
+   256-bit AES key:
+       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
+       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
+
+   Iteration count = 1200
+   Pass phrase = (65 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt = "pass phrase exceeds block size"
+   128-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+   128-bit AES key:
+       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
+   256-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
+   256-bit AES key:
+       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
+       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
+
+   Iteration count = 50
+   Pass phrase = g-clef (0xf09d849e)
+   Salt = "EXAMPLE.COMpianist"
+   128-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+   128-bit AES key:
+       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
+   256-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
+   256-bit AES key:
+       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
+       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
+
+   Some test vectors for CBC with cipher text stealing, using an initial
+   vector of all-zero.
+
+
+
+
+
+Raeburn                                                        [Page 10]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   AES 128-bit key:
+       63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20
+   Output:
+       c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+       97
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
+   Output:
+       fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+   Output:
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 11]
+
+INTERNET DRAFT                                                 June 2003
+
+
+   Input:
+       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+       61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
+   Output:
+       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+       48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+
+Normative References
+
+   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
+   and Sons, New York, 1996.
+
+   [AES] National Institute of Standards and Technology, U.S. Department
+   of Commerce, "Advanced Encryption Standard", Federal Information
+   Processing Standards Publication 197, Washington, DC, November 2001.
+
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
+   progress.
+
+   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
+   Specification Version 2.0", RFC 2898, September 2000.
+
+   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+   RC5-CTS Algorithms", RFC 2040, October 1996.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+   3", RFC 2026, October 1996.
+
+   [SHA1] National Institute of Standards and Technology, U.S.
+   Department of Commerce, "Secure Hash Standard", Federal Information
+   Processing Standards Publication 180-1, Washington, DC, April 1995.
+
+Informative References
+
+   [LEACH] Leach, P., email to IETF Kerberos working group mailing list,
+   5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
+
+   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
+   December 2001.
+
+
+
+
+
+
+
+Raeburn                                                        [Page 12]
+
+INTERNET DRAFT                                                 June 2003
+
+
+Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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."
+
+Notes to RFC Editor
+
+   Assuming this document goes through Last Call along with the Kerberos
+   crypto framework draft, the reference entry for [KCRYPTO] will list
+   the draft name, not the RFC number.  This should be replaced with the
+   RFC info.
+
+   Remove Kerberos working group contact info from the Abstract; it's
+   right for the draft, but not the final RFC.
+
+
+
+
+
+
+Raeburn                                                        [Page 13]
diff --git a/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt
new file mode 100644
index 00000000000..c0d9ba60d89
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt
@@ -0,0 +1,959 @@
+Kerberos Working Group                                        K. Raeburn
+Document: draft-raeburn-krb-rijndael-krb-07.txt                      MIT
+                                                           July 19, 2004
+                                                expires January 19, 2005
+
+
+                     AES Encryption for Kerberos 5
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to 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 US National Institute of Standards and Technology has chosen a
+   new Advanced Encryption Standard, which is significantly faster and
+   (it is believed) more secure than the old DES algorithm.  This
+   document is a specification for the addition of this algorithm to the
+   Kerberos cryptosystem suite.
+
+
+1. Introduction
+
+
+   This document defines encryption key and checksum types for Kerberos
+   5 using the AES algorithm recently chosen by NIST.  These new types
+   support 128-bit block encryption, and key sizes of 128 or 256 bits.
+
+
+   Using the "simplified profile" of [KCRYPTO], we can define a pair of
+   encryption and checksum schemes.  AES is used with cipher text
+   stealing to avoid message expansion, and SHA-1 [SHA1] is the
+   associated checksum function.
+
+
+
+
+
+
+Raeburn                                                         [Page 1]
+INTERNET DRAFT                                                 July 2004
+
+
+
+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 [KEYWORDS].
+
+
+3. Protocol Key Representation
+
+
+   The profile in [KCRYPTO] treats keys and random octet strings as
+   conceptually different.  But since the AES key space is dense, we can
+   use any bit string of appropriate length as a key.  We use the byte
+   representation for the key described in [AES], where the first bit of
+   the bit string is the high bit of the first byte of the byte string
+   (octet string) representation.
+
+
+4. Key Generation From Pass Phrases or Random Data
+
+
+   Given the above format for keys, we can generate keys from the
+   appropriate amounts of random data (128 or 256 bits) by simply
+   copying the input string.
+
+
+   To generate an encryption key from a pass phrase and salt string, we
+   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
+   indicated below, to generate an intermediate key (of the same length
+   as the desired final key), which is then passed into the DK function
+   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
+   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
+   produces a "random octet string", hence the application of the
+   random-to-key function even though it's effectively a simple identity
+   operation.)  The resulting key is the user's long-term key for use
+   with the encryption algorithm in question.
+
+
+    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
+    key = DK(tkey, "kerberos")
+
+
+   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
+   passphrase and salt, as described in Appendix B.1 to PKCS#5.
+
+
+   The number of iterations is specified by the string-to-key parameters
+   supplied.  The parameter string is four octets indicating an unsigned
+   number in big-endian order.  This is the number of iterations to be
+   performed.  If the value is 00 00 00 00, the number of iterations to
+   be performed is 4294967296 (2**32).  (Thus the minimum expressable
+   iteration count is 1.)
+
+
+   For environments where slower hardware is the norm, implementations
+   of protocols such as Kerberos may wish to limit the number of
+   iterations to prevent a spoofed response supplied by an attacker from
+
+
+
+
+Raeburn                                                         [Page 2]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   consuming lots of client-side CPU time; if such a limit is
+   implemented, it SHOULD be no less than 50000.  Even for environments
+   with fast hardware, 4 billion iterations is likely to take a fairly
+   long time; much larger bounds might still be enforced, and it might
+   be wise for implementations to permit interruption of this operation
+   by the user if the environment allows for it.
+
+
+   If the string-to-key parameters are not supplied, the value used is
+   00 00 10 00 (decimal 4096, indicating 4096 iterations).
+
+
+   Note that this is not a requirement, nor even a recommendation, for
+   this value to be used in "optimistic preauthentication" (e.g.,
+   attempting timestamp-based preauthentication using the user's long-
+   term key, without having first communicated with the KDC) in the
+   absence of additional information, nor as a default value for sites
+   to use for their principals' long-term keys in their Kerberos
+   database.  It is simply the interpretation of the absence of the
+   string-to-key parameter field when the KDC has had an opportunity to
+   provide it.
+
+
+   Sample test vectors are given in appendix B.
+
+
+5. Cipher Text Stealing
+
+
+   Cipher block chaining is used to encrypt messages.  Unlike previous
+   Kerberos cryptosystems, we use cipher text stealing to handle the
+   possibly partial final block of the message.
+
+
+   Cipher text stealing is described on pages 195-196 of [AC], and
+   section 8 of [RC5]; it has the advantage that no message expansion is
+   done during encryption of messages of arbitrary sizes as is typically
+   done in CBC mode with padding.  Some errata for [RC5] are listed in
+   appendix A, and are considered part of the cipher text stealing
+   technique as used here.
+
+
+   Cipher text stealing, as defined in [RC5], assumes that more than one
+   block of plain text is available.  If exactly one block is to be
+   encrypted, that block is simply encrypted with AES (also known as ECB
+   mode).  Input of less than one block is padded at the end to one
+   block; the values of the padding bits are unspecified.
+   (Implementations MAY use all-zero padding, but protocols MUST NOT
+   rely on the result being deterministic.  Implementations MAY use
+   random padding, but protocols MUST NOT rely on the result not being
+   deterministic.  Note that in most cases, the Kerberos encryption
+   profile will add a random confounder independent of this padding.)
+
+
+   For consistency, cipher text stealing is always used for the last two
+   blocks of the data to be encrypted, as in [RC5].  If the data length
+
+
+
+
+Raeburn                                                         [Page 3]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   is a multiple of the block size, this is equivalent to plain CBC mode
+   with the last two cipher text blocks swapped.
+
+
+   A test vector is given in appendix B.
+
+
+   The initial vector carried out from one encryption for use in a
+   following encryption is the next to last block of the encryption
+   output; this is the encrypted form of the last plaintext block.  When
+   decrypting, the next to last block of the supplied ciphertext is
+   carried forward as the next initial vector.
+
+
+6. Kerberos Algorithm Profile Parameters
+
+
+   This is a summary of the parameters to be used with the simplified
+   algorithm profile described in [KCRYPTO]:
+
+
+   +--------------------------------------------------------------------+
+   |               protocol key format        128- or 256-bit string    |
+   |                                                                    |
+   |            string-to-key function        PBKDF2+DK with variable   |
+   |                                          iteration count (see      |
+   |                                          above)                    |
+   |                                                                    |
+   |  default string-to-key parameters        00 00 10 00               |
+   |                                                                    |
+   |        key-generation seed length        key size                  |
+   |                                                                    |
+   |            random-to-key function        identity function         |
+   |                                                                    |
+   |                  hash function, H        SHA-1                     |
+   |                                                                    |
+   |               HMAC output size, h        12 octets (96 bits)       |
+   |                                                                    |
+   |             message block size, m        1 octet                   |
+   |                                                                    |
+   |  encryption/decryption functions,        AES in CBC-CTS mode       |
+   |  E and D                                 (cipher block size 16     |
+   |                                          octets), with next to     |
+   |                                          last block as CBC-style   |
+   |                                          ivec                      |
+   +--------------------------------------------------------------------+
+
+
+   Using this profile with each key size gives us two each of encryption
+   and checksum algorithm definitions.
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 4]
+INTERNET DRAFT                                                 July 2004
+
+
+
+7. Assigned Numbers
+
+
+   The following encryption type numbers are assigned:
+
+
+   +--------------------------------------------------------------------+
+   |                         encryption types                           |
+   +--------------------------------------------------------------------+
+   |         type name                  etype value          key size   |
+   +--------------------------------------------------------------------+
+   |   aes128-cts-hmac-sha1-96              17                 128      |
+   |   aes256-cts-hmac-sha1-96              18                 256      |
+   +--------------------------------------------------------------------+
+
+
+   The following checksum type numbers are assigned:
+
+
+   +--------------------------------------------------------------------+
+   |                          checksum types                            |
+   +--------------------------------------------------------------------+
+   |        type name                 sumtype value           length    |
+   +--------------------------------------------------------------------+
+   |    hmac-sha1-96-aes128                15                   96      |
+   |    hmac-sha1-96-aes256                16                   96      |
+   +--------------------------------------------------------------------+
+
+
+   These checksum types will be used with the corresponding encryption
+   types defined above.
+
+
+8. Security Considerations
+
+
+   This new algorithm has not been around long enough to receive the
+   decades of intense analysis that DES has received.  It is possible
+   that some weakness exists that has not been found by the
+   cryptographers analyzing these algorithms before and during the AES
+   selection process.
+
+
+   The use of the HMAC function has drawbacks for certain pass phrase
+   lengths.  For example, a pass phrase longer than the hash function
+   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
+   bytes) before applying the main HMAC algorithm.  However, entropy is
+   generally sparse in pass phrases, especially in long ones, so this
+   may not be a problem in the rare cases of users with long pass
+   phrases.
+
+
+   Also, generating a 256-bit key from a pass phrase of any length may
+   be deceptive, since the effective entropy in pass-phrase-derived key
+   cannot be nearly that large, given the properties of the string-to-
+   key function described here.
+
+
+
+
+
+Raeburn                                                         [Page 5]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   The iteration count in PBKDF2 appears to be useful primarily as a
+   constant multiplier for the amount of work required for an attacker
+   using brute-force methods.  Unfortunately, it also multiplies, by the
+   same amount, the work needed by a legitimate user with a valid
+   password.  Thus the work factor imposed on an attacker (who may have
+   many powerful workstations at his disposal) must be balanced against
+   the work factor imposed on the legitimate user (who may have a PDA or
+   cell phone); the available computing power on either side increases
+   as time goes on, as well.  A better way to deal with the brute-force
+   attack is through preauthentication mechanisms that provide better
+   protection of the user's long-term key.  Use of such mechanisms is
+   out of scope for this document.
+
+
+   If a site does wish to use this means of protection against a brute-
+   force attack, the iteration count should be chosen based on the
+   facilities available to both attacker and legitimate user, and the
+   amount of work the attacker should be required to perform to acquire
+   the key or password.
+
+
+   As an example:
+
+
+      The author's tests on a 2GHz Pentium 4 system indicated that in
+      one second, nearly 90000 iterations could be done, producing a
+      256-bit key.  This was using the SHA-1 assembly implementation
+      from OpenSSL, and a pre-release version of the PBKDF2 code for
+      MIT's Kerberos package, on a single system.  No attempt was made
+      to do multiple hashes in parallel, so we assume an attacker doing
+      so can probably do at least 100000 iterations per second --
+      rounded up to 2**17, for ease of calculation.  For simplicity, we
+      also assume the final AES encryption step costs nothing.
+
+
+      Paul Leach estimates [LEACH] that a password-cracking dictionary
+      may have on the order of 2**21 entries, with capitalization,
+      punctuation, and other variations contributing perhaps a factor of
+      2**11, giving a ballpark estimate of 2**32.
+
+
+      Thus, for a known iteration count N and a known salt string, an
+      attacker with some number of computers comparable to the author's
+      would need roughly N*2**15 CPU seconds to convert the entire
+      dictionary plus variations into keys.
+
+
+      An attacker using a dozen such computers for a month would have
+      roughly 2**25 CPU seconds available.  So using 2**12 (4096)
+      iterations would mean an attacker with a dozen such computers
+      dedicated to a brute-force attack against a single key (actually,
+      any password-derived keys sharing the same salt and iteration
+      count) would process all the variations of the dictionary entries
+      in four months, and on average, would likely find the user's
+
+
+
+
+Raeburn                                                         [Page 6]
+INTERNET DRAFT                                                 July 2004
+
+
+
+      password in two months.
+
+
+      Thus, if this form of attack is of concern, an iteration count a
+      few orders of magnitude higher should be chosen, and users should
+      be required to change their passwords every few months.  Perhaps
+      several orders of magnitude, since many users will tend to use the
+      shorter and simpler passwords (as much as they can get away with,
+      given a site's password quality checks) that the attacker would
+      likely try first.
+
+
+      Since this estimate is based on currently available CPU power, the
+      iteration counts used for this mode of defense should be increased
+      over time, at perhaps 40%-60% each year or so.
+
+
+      Note that if the attacker has a large amount of storage available,
+      intermediate results could be cached, saving a lot of work for the
+      next attack with the same salt and a greater number of iterations
+      than had been run at the point where the intermediate results were
+      saved.  Thus, it would be wise to generate a new random salt
+      string when passwords are changed.  The default salt string,
+      derived from the principal name, only protects against the use of
+      one dictionary of keys against multiple users.
+
+
+   If the PBKDF2 iteration count can be spoofed by an intruder on the
+   network, and the limit on the accepted iteration count is very high,
+   the intruder may be able to introduce a form of denial of service
+   attack against the client by sending a very high iteration count,
+   causing the client to spend a great deal of CPU time computing an
+   incorrect key.
+
+
+   An intruder spoofing the KDC reply, providing a low iteration count,
+   and reading the client's reply from the network may be able to reduce
+   the work needed in the brute-force attack outlined above.  Thus,
+   implementations may wish to enforce lower bounds on the number of
+   iterations that will be used.
+
+
+   Since threat models and typical end-user equipment will vary widely
+   from site to site, allowing site-specific configuration of such
+   bounds is recommended.
+
+
+   Any benefit against other attacks specific to the HMAC or SHA-1
+   algorithms is probably achieved with a fairly small number of
+   iterations.
+
+
+   In the "optimistic preauthentication" case mentioned in section 3,
+   the client may attempt to produce a key without first communicating
+   with the KDC.  If the client has no additional information, it can
+   only guess as to the iteration count to be used.  Even such
+
+
+
+
+Raeburn                                                         [Page 7]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   heuristics as "iteration count X was used to acquire tickets for the
+   same principal only N hours ago" can be wrong.  Given the
+   recommendation above for increasing the iteration counts used over
+   time, it is impossible to recommend any specific default value for
+   this case; allowing site-local configuration is recommended.  (If the
+   lower and upper bound checks described above are implemented, the
+   default count for optimistic preauthentication should be between
+   those bounds.)
+
+
+   Cipher text stealing mode, since it requires no additional padding in
+   most cases, will reveal the exact length of each message being
+   encrypted, rather than merely bounding it to a small range of
+   possible lengths as in CBC mode.  Such obfuscation should not be
+   relied upon at higher levels in any case; if the length must be
+   obscured from an outside observer, it should be done by intentionally
+   varying the length of the message to be encrypted.
+
+
+9. IANA Considerations
+
+
+   Kerberos encryption and checksum type values used in section 7 were
+   previously reserved in [KCRYPTO] for the mechanisms defined in this
+   document.  The registries should be updated to list this document as
+   the reference.
+
+
+10. Acknowledgements
+
+
+   Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
+   Leach, Marcus Watts, Larry Zhu and others for feedback on earlier
+   versions of this document.
+
+
+A. Errata for RFC 2040 section 8
+
+
+   (Copied from the RFC Editor's errata web site on July 8, 2004.)
+
+
+   Reported By: Bob Baldwin; baldwin@plusfive.com
+   Date: Fri, 26 Mar 2004 06:49:02 -0800
+
+
+   In Section 8, Description of RC5-CTS, of the encryption method, it says:
+
+
+       1. Exclusive-or Pn-1 with the previous ciphertext
+          block, Cn-2, to create Xn-1.
+
+
+   It should say:
+
+
+       1. Exclusive-or Pn-1 with the previous ciphertext
+          block, Cn-2, to create Xn-1.  For short messages where
+          Cn-2 does not exist, use IV.
+
+
+
+
+
+Raeburn                                                         [Page 8]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   Reported By: Bob Baldwin; baldwin@plusfive.com
+   Date: Mon, 22 Mar 2004 20:26:40 -0800
+
+
+   In Section 8, first paragraph, second sentence says:
+
+
+       This mode handles any length of plaintext and produces ciphertext
+       whose length matches the plaintext length.
+
+
+   In Section 8, first paragraph, second sentence should read:
+
+
+       This mode handles any length of plaintext longer than one
+       block and produces ciphertext whose length matches the
+       plaintext length.
+
+
+   In Section 8, step 6 of the decryption method says:
+
+
+       6. Decrypt En to create Pn-1.
+
+
+   In Section 8, step 6 of the decryption method should read:
+
+
+       6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
+          For short messages where Cn-2 does not exist, use the IV.
+
+
+B. Sample test vectors
+
+
+   Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
+   included below.
+
+
+   Iteration count = 1
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+   128-bit AES key:
+       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
+   256-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
+   256-bit AES key:
+       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
+       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                         [Page 9]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   Iteration count = 2
+   Pass phrase = "password"
+   Salt="ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+   128-bit AES key:
+       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
+   256-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
+   256-bit AES key:
+       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
+       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
+
+
+   Iteration count = 1200
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+   128-bit AES key:
+       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
+   256-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
+   256-bit AES key:
+       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
+       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
+
+
+   Iteration count = 5
+   Pass phrase = "password"
+   Salt=0x1234567878563412
+   128-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+   128-bit AES key:
+       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
+   256-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
+   256-bit AES key:
+       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
+       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
+   (This test is based on values given in [PECMS].)
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 10]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   Iteration count = 1200
+   Pass phrase = (64 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt="pass phrase equals block size"
+   128-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+   128-bit AES key:
+       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
+   256-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
+   256-bit AES key:
+       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
+       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
+
+
+   Iteration count = 1200
+   Pass phrase = (65 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt = "pass phrase exceeds block size"
+   128-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+   128-bit AES key:
+       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
+   256-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
+   256-bit AES key:
+       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
+       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
+
+
+   Iteration count = 50
+   Pass phrase = g-clef (0xf09d849e)
+   Salt = "EXAMPLE.COMpianist"
+   128-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+   128-bit AES key:
+       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
+   256-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
+   256-bit AES key:
+       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
+       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
+
+
+   Some test vectors for CBC with cipher text stealing, using an initial
+   vector of all-zero.
+
+
+
+
+
+
+Raeburn                                                        [Page 11]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   AES 128-bit key:
+     0000:  63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20
+   Output:
+     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+     0010:  97
+   Next IV:
+     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
+   Output:
+     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
+   Next IV:
+     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+   Output:
+     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+   Next IV:
+     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
+   Output:
+     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+     0010:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
+   Next IV:
+     0000:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+
+
+
+
+Raeburn                                                        [Page 12]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+   Output:
+     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+     0010:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+   Next IV:
+     0000:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+     0030:  61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
+   Output:
+     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+     0010:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+     0020:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+     0030:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+   Next IV:
+     0000:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+
+
+Normative References
+
+
+   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
+   and Sons, New York, 1996.
+
+
+   [AES] National Institute of Standards and Technology, U.S. Department
+   of Commerce, "Advanced Encryption Standard", Federal Information
+   Processing Standards Publication 197, Washington, DC, November 2001.
+
+
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
+   progress.
+
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, March 1997.
+
+
+   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
+   Specification Version 2.0", RFC 2898, September 2000.
+
+
+   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
+
+
+
+
+Raeburn                                                        [Page 13]
+INTERNET DRAFT                                                 July 2004
+
+
+
+   RC5-CTS Algorithms", RFC 2040, October 1996.
+
+
+   [SHA1] National Institute of Standards and Technology, U.S.
+   Department of Commerce, "Secure Hash Standard", Federal Information
+   Processing Standards Publication 180-1, Washington, DC, April 1995.
+
+
+Informative References
+
+
+   [LEACH] Leach, P., email to IETF Kerberos working group mailing list,
+   5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
+
+
+   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
+   December 2001.
+
+
+Author's Address
+
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+   raeburn@mit.edu
+
+
+IPR notices
+
+
+   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 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.
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 14]
+INTERNET DRAFT                                                 July 2004
+
+
+
+Full Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  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."
+
+
+Notes to RFC Editor
+
+
+   The reference entry for [KCRYPTO] lists the draft name, not the RFC
+   number.  This should be replaced with the RFC info when available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                                                        [Page 15] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-richards-otp-kerberos-00.txt b/third_party/heimdal/doc/standardisation/draft-richards-otp-kerberos-00.txt
new file mode 100644
index 00000000000..963136a9763
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-richards-otp-kerberos-00.txt
@@ -0,0 +1,728 @@
+
+
+
+Network Working Group                                        G. Richards
+Internet-Draft                                      RSA Security UK Ltd.
+Expires: December 4, 2006                                   June 2, 2006
+
+
+                              OTP Kerberos
+                      draft-richards-otp-kerberos-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on December 4, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Kerberos protocol provides a framework authenticating a client
+   using the exchange of pre-authentication data.  This document
+   describes the use of this framework to carry out One Time Password
+   (OTP) authentication.
+
+
+
+
+
+
+
+
+Richards                Expires December 4, 2006                [Page 1]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.3.  OTP Hardening  . . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Key Derivation . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . .  6
+     3.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . .  6
+     3.2.  PA-OTP-RESPONSE  . . . . . . . . . . . . . . . . . . . . .  7
+     3.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . .  8
+     3.4.  PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+     5.1.  Active attacks . . . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  Denial of service attacks  . . . . . . . . . . . . . . . .  9
+     5.3.  Use of Hardening Value . . . . . . . . . . . . . . . . . . 10
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richards                Expires December 4, 2006                [Page 2]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+1.  Introduction
+
+   A One-Time Password (OTP) token may be a handheld hardware device, a
+   hardware device connected to a personal computer through an
+   electronic interface such as USB, or a software module resident on a
+   personal computer, which generates one-time passwords that may be
+   used to authenticate a user towards some service.  This document
+   describes an extensions to Kerberos V5 [RFC4120] to support pre-
+   authentication using a OTPs.
+
+   In this proposal, the KDC sends the client information on which token
+   to be used and how the OTP is to be generated.  The client then uses
+   the OTP value instead of the conventional password to generate the
+   timestamp encryption key and sends the encrypted timestamp along with
+   information on the OTP to the KDC in in pre-authentication data of a
+   KRB_AS_REQ.  The KDC then uses the OTP information provided by the
+   client to generate the same encryption key, allowing it to verify the
+   timestamp.
+
+   This proposal is partially based upon previous work on integrating
+   single-use authentication mechanisms into Kerberos [NeZoHo98] and
+   uses the existing password-change extensions to handle PIN change as
+   described in [RFC3244].
+
+   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 [RFC2119].
+
+   << This is the first draft of this document and so is liable to
+   change significantly. >>
+
+
+2.  Usage Overview
+
+2.1.  Pre-Authentication
+
+   The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
+   and KRB_ERROR.  The client begins by sending an initial KRB_AS_REQ to
+   the KDC possibly containing pre-authentication data such as the
+   standard Kerberos password data.  The KDC will then determine in an
+   implementation dependent fashion whether OTP authentication is
+   required and if it is, it will respond with a KRB_ERROR message with:
+
+   o  An error code of KDC_ERR_PREAUTH_REQUIRED
+   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
+
+   The PA-OTP-CHALLENGE contains information on the type of OTP required
+   and the token to be used to generate it.  The client uses this
+
+
+
+Richards                Expires December 4, 2006                [Page 3]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+   information to locate the token and generate the OTP which is used,
+   instead of the user's password, to generate an encryption key and
+   encrypt a timestamp.
+
+   The encrypted timestamp is then sent to the KDC as pre-auth data in a
+   second KRB_AS_REQ in the standard manner but additional information
+   on the OTP and the key derivation is also sent in a PA-OTP-RESPONSE.
+
+   The KDC then uses the information in the PA-OTP-RESPONSE to generate
+   the same key as the client allowing it to validate the encrypted
+   timestamp.  If the validation succeeds then the KDC returns the TGT
+   in a KRB_AS_REP.
+
+2.2.  PIN Change
+
+   If, following successful validation of a PA-OTP-RESPONSE in a
+   KRB_AS_REQ, the KDC requires that the user changes their PIN then it
+   will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
+   This pre-auth data can be used to return a new PIN to the user if the
+   KDC has updated the PIN or to indicate to the user that they must
+   change their PIN.
+
+   In the latter case, user PIN change shall be handled by a PIN change
+   service supporting the ChangePasswdData in a KRB_AP_REQ as described
+   in [RFC3244].  If such a user PIN change is required then the KDC
+   SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
+   only issues tickets for the PIN change service until the PIN has been
+   changed.
+
+2.3.  OTP Hardening
+
+   Since OTPs may be relatively short, it is important to slow down an
+   attacker sufficiently so that it is economically unattractive to
+   brute-force search for an OTP given an observed OTP-Kerberos
+   exchange.  One way to do this is to derive the Kerberos user key from
+   the OTP instead of the password in the same manner as described in
+   [RFC3962] but to use a high number of iterated hashes of the OTP in
+   the PBKDF2 key derivation function from [RFC2898].  Another is for
+   the client to include a hardening value unknown to the attacker in
+   the key derivation.
+
+   Unlike the a traditional "salt" value which is normally sent in the
+   clear, this hardening value will instead be transferred from the KDC
+   to the client in encrypted form.  When the client receives a PA-OTP-
+   CHALLENGE from a KDC it will search for an associated hardening
+   value.  If it finds a value then it will use it in the key derivation
+   as specified in Section 2.4.
+
+
+
+
+Richards                Expires December 4, 2006                [Page 4]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+   The use of a hardening value will influence the iteration count used
+   by the client in the random-to-key calculation.  The value sent by
+   the KDC in the s2kparams of the ETYPE-INFO2 pre-authentication type
+   specifies the value used if there is no hardening value stored on the
+   client for the server.  If the client has a hardening value stored
+   for the server, then the iteration count of 1 SHOULD be used as the
+   security of the scheme is provided through the hardening value.  If
+   the client does not have a hardening value stored, then it SHOULD set
+   the iteration count in the key derivation to the maximum value that
+   is both supported by the KDC and permitted by any local policy
+   constraints.  The identifier of any hardening value used and the
+   value of the iteration count are sent by the client to the KDC in a
+   PA-OTP_RESPONSE included in the KRB_AS_REQ.
+
+   When the KDC receives a PA-OTP-RESPONSE, it will use the identifier
+   to locate the hardening value.  If a hardening value is found then it
+   will be used along with the iterationCount to generate the user key.
+   If the hardening value identifier is omitted then only the
+   iterationCount SHALL be used.  If a hardening value identifier is
+   included but the corresponding value could not be found then the KDC
+   SHALL respond with a KDC_ERR_PREAUTH_REQUIRED error as described
+   above but SHALL set the noHardening flag in the PA-OTP-CHALLENGE.
+
+   The hardening value to be used by the client in the next KRB_AS_REQ
+   will be sent by the KDC in a PA-OTP-CONFIRM contained in the
+   KRB_AS_REP.  The inclusion of a PA-OTP-CONFIRM is only REQUIRED if
+   the client did not use a hardening value to generate the timestamp
+   encryption key.  However, it is RECOMMENDED that it be included in
+   all such responses to ensure that a new hardening value is used in
+   all client requests.
+
+2.4.  Key Derivation
+
+   The encryption key used to encrypt the time stamp SHALL be generated
+   using the PBKDF2 password-based key derivation function as specified
+   in [RFC3962].  Conformant KDCs MUST support at least one of the
+   encryption types aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
+   defined in [RFC3962] and MUST return PA-ETYPE-INFO2 pre-
+   authentication types with the corresponding etype values.
+
+   In order to use the hardening scheme described in Section 2.3, the
+   information provided by the KDC in the ETYPE-INFO2 pre-authentication
+   type SHALL be used by the client as follows:
+
+   o  If the client does not have a hardening value associated with the
+      KDC then the number of iterations specified in the s2kparams SHALL
+      be used.  If the client has a hardening value then an iteration
+      count of 1 SHALL be used instead.
+
+
+
+Richards                Expires December 4, 2006                [Page 5]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+   o  The salt value SHALL have the hardening value concatenated if
+      there is one associated with the KDC.
+
+             tkey = random-to-key(PBKDF2(OTP, salt|hardening,
+                           iteration_count, key_length))
+             key = DK(tkey, "kerberos")
+
+
+3.  OTP Kerberos Types
+
+3.1.  PA-OTP-CHALLENGE
+
+   This is a pre-authentication type sent by the KDC to the client in a
+   KRB_ERROR.  It contains information for the client on how to generate
+   an OTP and how to use the OTP in the generation of the key used to
+   encrypt the pre-authentication data.
+
+             PA-OTP-CHALLENGE ::= SEQUENCE {
+               flags            ChallengeFlags
+               otp-challenge[0] OCTET STRING OPTIONAL,
+               otp-length   [1] INTEGER      OPTIONAL,
+               otp-service  [2] UTF8String   OPTIONAL,
+               otp-keyID    [3] OCTET STRING OPTIONAL,
+               otp-algID    [4] INTEGER      OPTIONAL
+             }
+             ChallengeFlags ::= KerberosFlags
+             -- noHardening (0),
+
+   noHardening
+      If the noHardening flag is set then the client MUST NOT use any
+      stored hardening value in the key derivation.  Instead, it MUST
+      use the iteration count provided by the KDC.
+   otp-challenge
+      The otp-challenge is used by the KDC to send a challenge value for
+      use in the OTP calculation.  The challenge is an optional octet
+      string that SHOULD be uniquely generated for each request it is
+      present in, and SHOULD be eight octets or longer when present.
+      When the challenge is not present, the OTP will be calculated on
+      the current token state only.  The client MAY ignore a provided
+      challenge if and only if the OTP token the client is interacting
+      with is not capable of including a challenge in the OTP
+      calculation.  In this case, KDC policies will determine whether to
+      accept a provided OTP value or not.
+
+
+
+
+
+
+
+
+Richards                Expires December 4, 2006                [Page 6]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+   otp-length
+      The otp-length is used by the KDC to specify the desired length of
+      the generated OTP.
+
+   otp-service
+      An identifier of the service supported by the KDC.  This value can
+      be used by the client to locate information such as the hardening
+      value and OTP key to use.
+
+   otp-keyID
+      The identifier of the OTP key to be used in the OTP calculation.
+      If this value is not present then the client SHOULD use other
+      values such as the otp-service and otp-algiID to locate the
+      appropriate key.
+   otp-algID
+      The identifier of the algorithm to use when generating the OTP.
+
+3.2.  PA-OTP-RESPONSE
+
+   This is a pre-authentication type sent by the client to the KDC in a
+   KRB_AS_REQ containing the encrypted pre-authentication data.  It
+   contains information on the OTP used and how the key was generated
+   that encrypts the pre-authentication data.  This information will
+   then allow the KDC to generate the same key and validate the pre-
+   authentication data.
+
+             PA-OTP-RESPONSE ::= SEQUENCE {
+               iterationCount[0] INTEGER      OPTIONAL,
+               identifier    [1] OCTET STRING OPTIONAL,
+               otp-challenge [2] OCTET STRING OPTIONAL,
+               otp-time      [2] KerberosTime OPTIONAL,
+               otp-counter   [3] OCTET STRING OPTIONAL,
+               otp-format    [4] OTPFormat    OPTIONAL,
+               otp-keyID     [5] OCTET STRING OPTIONAL
+             }
+
+             OTPFormat ::= INTEGER {
+                 decimal(0),
+                 hexadecimal(1),
+                 alphanumeric(2),
+                 binary(3)
+             }
+
+   iterationCount
+      The actual value of the iteration count used by the client in the
+      key derivation.  If omitted then the specified or default
+      iteration count is used.  If present then it will generally be
+      less than the value used in the string-to-key parameters if a
+
+
+
+Richards                Expires December 4, 2006                [Page 7]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+      hardening value is used.
+
+   identifier
+      An octet string identifying the hardening value used by the client
+      in the key derivation.  If omitted then no hardening was used.
+
+   otp-challenge
+      Value used by the client to send the challenge used in the OTP
+      calculation.  It MUST be sent to the KDC if and only if the value
+      would otherwise be unknown to the KDC.  For example, the token or
+      client modified or generated challenge.
+
+   otp-time
+      Value used by the client to send the time used in the OTP
+      calculation.
+
+   otp-counter
+      The counter value used in the OTP calculation.  Use of this
+      element is OPTIONAL but it MAY be used by a client to simplify the
+      OTP calculations of the KDC to contain the counter value as
+      reported by the OTP token.
+
+   otp-format
+      The format of the generated OTP.
+
+   otp-keyID
+      The identifier of the OTP key used.
+
+3.3.  PA-OTP-CONFIRM
+
+   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
+   client requires a new hardening value.
+
+             PA-OTP-CONFIRM ::= SEQUENCE {
+               identifier        OCTET STRING,
+               encHardeningValue EncryptedData  -- EncHardeningValue
+             }
+             EncHardeningValue ::= OCTET STRING SIZE (16..MAX)
+
+   identifier
+      An octet string identifying the hardening value used by the client
+      in the key derivation.
+
+   encHardeningValue
+      The hardening value that the client SHOULD use in future key
+      derivations.  It is encrypted as described in section 5.2.9 of
+      [RFC4120] using the current user key as derived by the KDC from
+      the OTP.
+
+
+
+Richards                Expires December 4, 2006                [Page 8]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+3.4.  PA-ENC-PIN
+
+   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
+   user must change their PIN or if the user's PIN has been changed.
+
+             PA-ENC-PIN     ::= EncryptedData -- PA-ENC-PIN-ENC
+             PA-ENC-PIN-ENC ::= SEQUENCE {
+               flags         PinFlags
+               pin       [0] UTF8String OPTIONAL
+               minLength [1] INTEGER    OPTIONAL
+               maxLength [2] INTEGER    OPTIONAL
+             }
+
+             PinFlags ::= KerberosFlags
+             -- systemSetPin (0)
+
+   If the systemSetPin flag is set then the pin field MUST be present
+   and the presence of this pre-auth type indicates that the user's PIN
+   has been changed to the value contained within the pin field.
+
+   If the pin field is omitted then this pre-auth type indicates that
+   the user must change their PIN using the PIN change service and that
+   the KDC will only issue tickets for the PIN change service until the
+   PIN has been changed.
+
+   If the pin field is present and the systemPin flag is not set then
+   the user must change their PIN subject to the restrictions of the
+   other fields or may alternatively use the returned PIN.
+
+
+4.  IANA Considerations
+
+   A registry may be required for the otp-AlgID values as introduced in
+   Section 3.1.  No other IANA actions are anticipated.
+
+
+5.  Security Considerations
+
+5.1.  Active attacks
+
+   <<TBD: Could an attacker change the iteration count in the PA-
+   ETYPE_INFO2? >>
+
+5.2.  Denial of service attacks
+
+   An active attacker may replace the iteration count value in the PA-
+   OTP-RESPONSE sent by the client to slow down an authentication
+   server.  Authentication servers SHOULD protect against this, e.g. by
+
+
+
+Richards                Expires December 4, 2006                [Page 9]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+   disregarding PA-OTP-RESPONSE elements with an iteration count value
+   higher than some pre- or dynamically- (depending on load) set number.
+
+5.3.  Use of Hardening Value
+
+   As described in Section 2.3, the use of a hardening value will slow
+   down an attacker's search for a matching OTP.  The ability to
+   transfer a hardening value in encrypted form from the KDC to the
+   client means that, even though there may be an initial computational
+   cost for the KDC to authenticate the user due to a high iteration
+   count, subsequent authentications will be efficient, while at the
+   same time more secure, since a pre-shared, 128 bits long, hardening
+   value will not be easily found by an attacker.
+
+   If a client does not have a hardening value for a KDC then it will
+   have to generate the user key using only an iteration count.  An
+   attacker observing such a KRB_AS_REQ may, depending on available
+   resources, be able to successfully attack that request.  Once the
+   correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
+   will potentially give the attacker access to the server-provided
+   hardening value.  For this reason, initial exchanges with KDC servers
+   SHOULD occur in a secure environment, and if not, the iteration count
+   MUST be significantly higher than for messages where a pre-shared
+   hardening value is used.  The lifetime of this value must also be
+   calculated with this in mind.  Finally, the value MUST be securely
+   stored by the client and the KDC, associated with the user.
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
+              Specification Version 2.0", RFC 2898, September 2000.
+
+   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
+              2000 Kerberos Change Password and Set Password Protocols",
+              RFC 3244, February 2002.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+
+
+Richards                Expires December 4, 2006               [Page 10]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+6.2.  Informative References
+
+   [NeZoHo98]
+              Neuman, C., Zorn, G., Trostle, J., and K. Horstein,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-cat-kerberos-password-04 (work in
+              progress), November 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richards                Expires December 4, 2006               [Page 11]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+Author's Address
+
+   Gareth Richards
+   RSA Security UK Ltd.
+   RSA House
+   Western Road
+   Bracknell, Berkshire  RG12 1RT
+   UK
+
+   Email: grichards@rsasecurity.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richards                Expires December 4, 2006               [Page 12]
+
+Internet-Draft                OTP Kerberos                     June 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Richards                Expires December 4, 2006               [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-richards-otp-kerberos-01.txt b/third_party/heimdal/doc/standardisation/draft-richards-otp-kerberos-01.txt
new file mode 100644
index 00000000000..5db9c39f87c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-richards-otp-kerberos-01.txt
@@ -0,0 +1,1232 @@
+
+
+
+Network Working Group                                        G. Richards
+Internet-Draft                         RSA, The Security Division of EMC
+Intended status: Standards Track                        October 11, 2006
+Expires: April 14, 2007
+
+
+                              OTP Kerberos
+                     draft-richards-otp-kerberos-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 14, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Kerberos protocol provides a framework authenticating a client
+   using the exchange of pre-authentication data.  This document
+   describes the use of this framework to carry out One Time Password
+   (OTP) authentication.
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 1]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.3.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  4
+   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  4
+     3.1.  Shared Secret  . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  Client Request . . . . . . . . . . . . . . . . . . . . . .  5
+     3.3.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  5
+     3.4.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7
+     3.5.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  7
+     3.6.  Updating the Secret  . . . . . . . . . . . . . . . . . . .  9
+   4.  Reply Key Generation Algorithms  . . . . . . . . . . . . . . .  9
+     4.1.  Using the OTP Value Directly . . . . . . . . . . . . . . .  9
+     4.2.  Hardening the OTP Value  . . . . . . . . . . . . . . . . .  9
+       4.2.1.  Using an Iteration Count . . . . . . . . . . . . . . . 10
+       4.2.2.  Using a Shared Secret and OTP  . . . . . . . . . . . . 10
+       4.2.3.  Using a Password and OTP . . . . . . . . . . . . . . . 11
+     4.3.  Generating the Key without the OTP . . . . . . . . . . . . 11
+       4.3.1.  Using the Password . . . . . . . . . . . . . . . . . . 11
+       4.3.2.  Using a Shared Secret  . . . . . . . . . . . . . . . . 11
+   5.  OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12
+     5.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12
+     5.2.  PA-OTP-RESPONSE  . . . . . . . . . . . . . . . . . . . . . 13
+     5.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16
+     5.4.  PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16
+     5.5.  OTPChalKeyParam  . . . . . . . . . . . . . . . . . . . . . 17
+     5.6.  OTPRespKeyParam  . . . . . . . . . . . . . . . . . . . . . 18
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+     7.1.  Active attacks . . . . . . . . . . . . . . . . . . . . . . 19
+     7.2.  Denial of service attacks  . . . . . . . . . . . . . . . . 19
+     7.3.  Use of a Shared Secret Value . . . . . . . . . . . . . . . 19
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   Intellectual Property and Copyright Statements . . . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 2]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+1.  Introduction
+
+   A One-Time Password (OTP) token may be a handheld hardware device, a
+   hardware device connected to a personal computer through an
+   electronic interface such as USB or a software module resident on a
+   personal computer.  All these devices generate one-time passwords
+   that may be used to authenticate a user towards some service.  This
+   document describes extensions to Kerberos V5 [RFC4120] to support
+   pre-authentication using an OTP.
+
+   In this proposal, the KDC sends the client a random nonce,
+   information on which OTP token is to be used, how the OTP is to be
+   generated using that token and how the Reply Key is to be generated.
+   The Reply Key is then used to encrypt the nonce value and the
+   encrypted value is returned to the KDC as the pre-authentication
+   data.  Depending on whether the KDC can obtain the OTP value, the OTP
+   value is either used in the generation of the Reply Key or is
+   encrypted using the key and returned to the KDC along with the
+   encrypted nonce.  The encrypted nonce, an optional encrypted OTP
+   value and information on how the Reply Key and OTP value were
+   generated are sent to the KDC and used by the KDC to generate the
+   same Reply Key and decrypt and verify the nonce.
+
+   This proposal is partially based upon previous work on integrating
+   single-use authentication mechanisms into Kerberos [HoReNeZo04] and
+   uses the existing password-change extensions to handle PIN change as
+   described in [RFC3244].
+
+   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 [RFC2119].
+
+   << This is an early draft of this document and so is liable to change
+   significantly. >>
+
+
+2.  Usage Overview
+
+2.1.  Pre-Authentication
+
+   The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
+   and KRB_ERROR.  The client begins by sending an initial KRB_AS_REQ to
+   the KDC that may contain pre-authentication data such as the standard
+   Kerberos password data.  The KDC will then determine, in an
+   implementation dependent fashion, whether OTP authentication is
+   required and if it is, it will respond with a KRB_ERROR message
+   containing a PA-OTP-CHALLENGE in the PA-DATA.
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 3]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   The PA-OTP-CHALLENGE contains information on how the OTP should be
+   generated, how the Reply Key should be generated and a nonce.  The
+   client uses this information to locate the token and generate the
+   OTP, generate the Reply Key and then encrypt the nonce using the
+   generated key.  Depending on the type of OTP, the Reply Key may be
+   generated using the OTP value or alternatively, the generated OTP
+   will instead be encrypted along with the nonce using the key.
+
+   The encrypted nonce along with information on how the OTP and Reply
+   Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA-
+   DATA element.  The KDC then uses this information to generate the
+   same key as the client, allowing it to verify the pre-authentication
+   by decrypting the nonce.  If the validation succeeds then the KDC
+   returns the TGT in a KRB_AS_REP.
+
+2.2.  PIN Change
+
+   If, following successful validation of a PA-OTP-RESPONSE in a
+   KRB_AS_REQ, the KDC requires that the user changes their PIN then it
+   will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
+   This pre-auth data can be used to return a new PIN to the user if the
+   KDC has updated the PIN or to indicate to the user that they must
+   change their PIN.
+
+   In the latter case, user PIN change shall be handled by a PIN change
+   service supporting the ChangePasswdData in a KRB_AP_REQ as described
+   in [RFC3244].  If such a user PIN change is required then the KDC
+   SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
+   only issues tickets for the PIN change service until the PIN has been
+   changed.
+
+2.3.  Re-Synchronization
+
+   It is possible with time and event-based tokens, that the client and
+   OTP server will loose synchronization.  If, when processing a PA-OTP-
+   RESPONSE, the pre-authentication validation fails for this reason
+   then the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
+   CHALLENGE in the PA-DATA with the "nextOTP" flag set.  The setting of
+   this flag will cause the client to re-try the authentication using
+   the OTP for the next token "state".
+
+
+3.  Pre-Authentication Protocol Details
+
+3.1.  Shared Secret
+
+   The method of deriving the Reply Key shall depend upon:
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 4]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   o  Whether the OTP is of sufficiently high entropy to generate the
+      key alone.
+
+   o  Whether the OTP has insufficient entropy and so must be
+      strengthened.
+
+   o  Whether the OTP value used can be obtained by the KDC.
+
+   If the OTP value is of low entropy then it is important to slow down
+   an attacker sufficiently to make it economically unattractive to
+   brute-force search for an OTP given an observed OTP-Kerberos
+   exchange.  If the OTP value cannot be obtained by the KDC then it
+   cannot be used in the derivation of the Reply Key but shall be
+   encrypted using the generated key rather than used to derive the key
+   and so the Reply Key must be derived from some other value.  Both of
+   these issues can be solved using shared secret value known by the
+   client and KDC but unknown to the attacker.
+
+   This protocol supports the following types of secret:
+
+   o  A pre-shared secret can be established between the client and KDC
+      and stored on the client.
+
+   o  Diffie-Hellman key agreement (as defined in [RFC2631]) can be used
+      to establish a shared secret value ZZ.  The server's public key,
+      and the base and prime are stored on the client.
+
+   The pre-shared secret value or the Diffie-Hellman shared secret
+   value, ZZ, are converted to a value of the required length for the
+   encryption scheme's random-to-key function using the n-fold function
+   (both defined in [RFC3961]).
+
+3.2.  Client Request
+
+   The client begins by sending an initial KRB_AS_REQ possibly
+   containing other pre-authentication data.  If the KDC determines that
+   OTP-based pre-authentication is required and the request does not
+   contain a PA-OTP-RESPONSE then it will respond as described in
+   Section 3.3.
+
+   Alternatively, if the client has all the necessary information, it
+   MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and
+   include it in the initial request.
+
+3.3.  KDC Challenge
+
+   If the user is required to authenticate using an OTP then the KDC
+   SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:
+
+
+
+Richards                 Expires April 14, 2007                 [Page 5]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   o  An error code of KDC_ERR_PREAUTH_REQUIRED
+
+   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
+
+   The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by
+   the generated Reply Key and it MAY also contain information on how
+   the OTP value is to be generated and information on how the Reply Key
+   is to be generated in an otp-keyParam element.
+
+   Use of the otp-keyParam element is OPTIONAL.  If it is not present
+   the Reply Key SHALL be generated directly from the OTP value as
+   specified in Section 4.1 and the OTP value SHALL NOT be included in
+   the client response.
+
+   If the otp-keyParam element is present and the "sendOTP" flag is set
+   then the OTP value MUST NOT be used in the generation of the Reply
+   Key but it must instead be returned to the KDC encrypted using the
+   key.  The Reply Key MUST be derived using one of the methods
+   described in Section 4.3.  If the "sendOTP" flag is not set then the
+   OTP value is to be used in the key derivation then the client MUST
+   use one of the methods described in Section 4.2.
+
+   The otp-keyParam element will control the use of a shared secret in
+   the key derivation.  If the "noSecret" flag is set the the client
+   MUST NOT use a secret value in the key derivation.  If the "noSecret"
+   flag is not set and secret identifier is present then the client MUST
+   NOT use any other secret value.  If the "noSecret" flag is not set
+   and a secret identifier is not present then the client MAY still use
+   a value if there is a value associated with the KDC.
+
+   If the "noSecret" flag is not set and the client can locate a secret
+   value for the KDC then the Reply Key will be generated using one of
+   the following methods:
+
+   o  If the OTP is to be included in the key derivation then the key
+      SHALL be derived as specified in Section 4.2.2.
+
+   o  If the OTP is to be sent encrypted in the response then the key
+      SHALL be derived as specified in Section 4.3.2.
+
+   If the client fails to find a shared secret for the KDC or the
+   "noSecret" flag was set in the challenge then the Reply Key will be
+   generated using one of the following methods:
+
+   o  If the OTP is to be used in the key derivation then the KDC MAY
+      specify an iteration count.  If such a value is specified then the
+      key SHALL be derived from the OTP as described in Section 4.2.1.
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 6]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   o  If the OTP is to be used in the key derivation but an iteration
+      count was not specified then the key SHALL be derived from the OTP
+      value and the user's Kerberos password as described in
+      Section 4.2.3.
+
+   o  If the OTP is to be sent encrypted then the key SHALL be derived
+      from the user's Kerberos password as described in section
+      Section 4.3.1.
+
+3.4.  Client Response
+
+   The client will use the generated Reply Key to encrypt the nonce from
+   the KDC challenge and, if required, to encrypt the OTP value.  This
+   encrypted data SHALL be sent to the KDC in the otp-encData of a PA-
+   OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ.
+
+   This response MAY also include information on how the Reply Key was
+   generated in an optional otp-keyParam element.  The client MUST NOT
+   include this element if the Reply Key was generated directly from the
+   OTP value.  The element MUST be included if the Reply Key was
+   generated using either a secret value or an iteration count and
+   contain the secret identifier and iteration count value.  If the
+   Reply Key was generated using a password then the element MUST be
+   present and MUST be empty.
+
+   The response SHOULD also include information on the generated OTP
+   value.
+
+3.5.  Verifying the pre-auth Data
+
+   If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use
+   the information in the otp-keyParam to generate the same Reply Key
+   and decrypt the encrypted nonce contained in the otp-encData.
+
+   If the encrypted OTP value is not included in the otp-encData then
+   the Reply Key was generated using the OTP value.  The KDC SHALL
+   therefore use the OTP information in the PA-OTP-RESPONSE to obtain
+   the OTP value for the user and use the value along with the
+   information in the otp-keyParam to generate the Reply Key. This
+   information SHALL be used as follows:
+
+   o  If the otp-keyParam is not present then the Reply Key SHALL be
+      generated directly from the OTP value as described in Section 4.1.
+
+   o  If the otp-keyParam is present but empty then the Reply Key SHALL
+      be generated using the OTP value and the user's Kerberos Password
+      as described in Section 4.2.3.
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 7]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   o  If the otp-keyParam is present and contains a secret identifier
+      then the Reply Key SHALL be generated using the OTP value and the
+      secret value as described in Section 4.2.2.
+
+      If the identified secret value can not be found then the KDC SHALL
+      respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
+      but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
+
+   o  if the otp-keyParam is present and contains an iteration count
+      then the Reply Key shall be generated from the OTP value using the
+      iteration count value as described in Section 4.2.1.
+
+   If the encrypted OTP value is included in the otp-encData then the
+   Reply Key was not generated using the OTP value but was instead used
+   to encrypt the OTP value.  The KDC SHALL therefore use the
+   information in the otp-keyParam to generate the Reply Key and decrypt
+   the OTP value.  It SHALL then validate the decrypted value using the
+   OTP information included in the response and fail the authentication
+   if the value is not valid.
+
+   This Reply Key SHALL be generated as follows:
+
+   o  If the otp-keyParam is not present the the KDC SHALL fail the pre-
+      authentication with an error of KDC_ERR_PREAUTH_FAILED.
+
+      If the otp-keyParam is omitted then the Reply Key was generated
+      directly from the OTP value and so is an error if the OTP value is
+      encrypted using the key.
+
+   o  If the otp-keyParam is present but empty then the Reply Key SHALL
+      be generated using the user's Kerberos Password as described in
+      Section 4.3.1.
+
+   o  If the otp-keyParam is present and contains a secret identifier
+      then the Reply Key SHALL be generated using the secret value as
+      described in Section 4.3.2.
+
+      If the identified secret value can not be found then the KDC SHALL
+      respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
+      but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
+
+   o  If the otp-keyParam is present and contains an iteration count
+      then the KDC SHALL fail the authentication with an error of
+      KDC_ERR_PREAUTH_FAILED.
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 8]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+3.6.  Updating the Secret
+
+   The secret value can be pre-configured on the client but MAY also be
+   transferred from the KDC to the client in encrypted form in the PA-
+   OTP-CONFIRM of the KRB_AS_REP.  If a client receives a new secret
+   value in this way then it MUST update any stored value associated
+   with the KDC.
+
+
+4.  Reply Key Generation Algorithms
+
+4.1.  Using the OTP Value Directly
+
+   If only the OTP value is to be used then the Reply Key SHALL be
+   generated by passing the OTP value through string-to-key (defined in
+   [RFC3961]).
+
+             K = string-to-key(OTP)
+
+   The salt and additional parameters for string-to-key will be as
+   defined in section 3.1.3 of [RFC4120].
+
+4.2.  Hardening the OTP Value
+
+   If the OTP value requires strengthening then several methods shall be
+   supported.
+
+   o  The OTP can be used on its own in the key derivation but run
+      through an iteration process many times as described in
+      Section 4.2.1.
+
+   o  A secret value, shared between the KDC and client can be used
+      along with the OTP value to derive the key as described in
+      Section 4.2.2.
+
+   o  The user's Kerberos password can be used along with the OTP value
+      in the key derivation as described in Section 4.2.3.
+
+   A shared secret can only be used if the client supports the storing
+   of persistent values and has such a value stored.  The other two
+   methods could be used to establish a secret value or when client are
+   not capable of storing such values.
+
+   <<Is there value in another mode which uses the Kerberos password in
+   conjunction with an iteration-hardened OTP value?>>
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                 [Page 9]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+4.2.1.  Using an Iteration Count
+
+   An initial key is generated by running the OTP value through string-
+   to-key.
+
+             K = string-to-key(OTP)
+
+   The following key generation process is then repeated iteration count
+   times with the resulting key being used as the protocol key for the
+   next iteration.
+
+   A sequence of octets, R, is produced from K by iterating over calls
+   to the function pseudo-random (defined in [RFC3961]) and appending
+   the results until at least the number of bits required by random-to-
+   key have been produced.  If the result of the iteration is longer
+   than the required length then the result shall be truncated.
+
+   The octet string parameter for pseudo-random shall be the ASCII
+   string "CombineA" with the loop number appended.  This string has the
+   following byte value:
+
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
+
+   A new key is then generated by running R through random-to-key.
+
+             K = random-to-key(R)
+
+4.2.2.  Using a Shared Secret and OTP
+
+   Two intermediate keys, K1 and K2, shall be generated by running the
+   OTP value once through string-to-key and the shared secret through
+   random-to-key.
+
+             K1 = random-to-key(shared secret)
+             K2 = string-to-key(OTP)
+
+   Two sequences of octets, R1 and R2, are then produced from K1 and K2
+   by iterating over calls to pseudo-random and appending the results
+   until the required number of bits have been generated for random-to-
+   key.  If the result of the iteration is longer than the required
+   length then the result shall be truncated.
+
+   The octet string parameter for pseudo-random shall be the ASCII
+   string "CombineA" for K1 and "CombineB" for K2 with the loop number
+   appended.  These have the following byte values:
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 10]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
+      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42}
+
+   The final key is then generated by combining R1 and R2 using
+   exclusive-OR and running the result through random-to-key.
+
+             K = random-to-key(R1 ^ R2)
+
+   << Check on issue around combining DES keys. >>
+
+4.2.3.  Using a Password and OTP
+
+   Two intermediate keys, K1 and K2, shall be generated by running the
+   OTP and password through string-to-key.
+
+             K1 = string-to-key(Password)
+             K2 = string-to-key(OTP)
+
+   The same process as described in Section 4.2.2 is then used to derive
+   the final reply key.
+
+4.3.  Generating the Key without the OTP
+
+   If the OTP value cannot be used in the derivation of the reply key
+   then this protocol supports the following options:
+
+   o  A secret value, shared between the KDC and client can be used to
+      derive the key as described in Section 4.3.2.
+
+   o  The user's Kerberos password can be used in the key derivation as
+      described in Section 4.3.1.
+
+   A shared secret can only be used if the client supports the storing
+   of persistent values and has such a value stored.  The password-only
+   method could be used to establish a secret value or when clients are
+   not capable of storing such values.
+
+4.3.1.  Using the Password
+
+   The Reply Key SHALL be generated by passing the password value
+   through string-to-key (defined in [RFC3961]).
+
+4.3.2.  Using a Shared Secret
+
+   The reply key shall be generated by running the shared secret value
+   through random-to-key.
+
+             K = random-to-key(shared secret)
+
+
+
+Richards                 Expires April 14, 2007                [Page 11]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+5.  OTP Kerberos Types
+
+5.1.  PA-OTP-CHALLENGE
+
+   This is a pre-authentication type sent by the KDC to the client in a
+   KRB_ERROR.  It contains information for the client on how to generate
+   the OTP and reply key.
+
+             PA-OTP-CHALLENGE ::= SEQUENCE {
+               otp-flags         OTPFlags,
+               otp-nonce         UInt32,
+               otp-etype         INTEGER,
+               otp-track-id  [0] OCTET STRING    OPTIONAL,
+               otp-challenge [1] OCTET STRING    OPTIONAL,
+               otp-length    [2] INTEGER         OPTIONAL,
+               otp-service   [3] UTF8String      OPTIONAL,
+               otp-keyID     [4] OCTET STRING    OPTIONAL,
+               otp-algID     [5] INTEGER         OPTIONAL,
+               otp-keyParam  [6] OTPChalKeyParam OPTIONAL
+             }
+
+             OTPFlags ::= KerberosFlags
+             -- nextOTP (0)
+
+   otp-flags
+      If the "nextOTP" flag is set then the OTP calculated SHALL be
+      based on the next token "state" rather than the current one.  As
+      an example, for a time-based token, this means the next time slot.
+      For an event-based token, this could mean the next counter value,
+      if counter values are used.
+
+   otp-nonce
+      A KDC-supplied nonce value to be encrypted by the client in the
+      PA-OTP-RESPONSE.
+
+   otp-etype
+      The encryption type to be used by the client for all encrypted
+      fields in the PA-OTP-RESPONSE.
+
+   otp-track-id
+      This optional element is used by the KDC to link a client response
+      to the corresponding KDC challenge.  If present, this element MUST
+      be copied by the client to the corresponding element in the PA-
+      OTP-RESPONSE.
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 12]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   otp-challenge
+      The otp-challenge is used by the KDC to send a challenge value for
+      use in the OTP calculation.  The challenge is an optional octet
+      string that SHOULD be uniquely generated for each request it is
+      present in, and SHOULD be eight octets or longer when present.
+      When the challenge is not present, the OTP will be calculated on
+      the current token state only.  The client MAY ignore a provided
+      challenge if and only if the OTP token the client is interacting
+      with is not capable of including a challenge in the OTP
+      calculation.  In this case, KDC policies will determine whether to
+      accept a provided OTP value or not.
+
+   otp-length
+      The otp-length is used by the KDC to specify the desired length of
+      the generated OTP.
+
+   otp-service
+      An identifier of the service supported by the KDC.  This value can
+      be used by the client to locate information such as the shared
+      secret value and OTP key to use.
+
+   otp-keyID
+      The identifier of the OTP key to be used in the OTP calculation.
+      If this value is not present then the client SHOULD use other
+      values such as the otp-service and otp-algID to locate the
+      appropriate key.
+
+   otp-algID
+      The identifier of the algorithm to use when generating the OTP.
+
+   otp-keyParam
+      Information on how the Reply Key should be generated from the OTP
+      and shared secret.  If the value is not present then the reply key
+      MUST be generated directly from the OTP value.
+
+   <<TBD: Should a checksum be added to allow the client to verify the
+   challenge?>>
+
+5.2.  PA-OTP-RESPONSE
+
+   This is a pre-authentication type sent by the client to the KDC in a
+   KRB_AS_REQ containing the encrypted pre-authentication data.  It
+   contains information on the OTP used and how the key was generated
+   that encrypts the pre-authentication data.  This information will
+   then allow the KDC to generate the same key and validate the pre-
+   authentication data.
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 13]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+             PA-OTP-RESPONSE ::= SEQUENCE {
+               otp-flags         OTPFlags,
+               otp-nonce         UInt32,
+               otp-encData       EncryptedData,
+                                      -- PA-ENC-RESPONSE
+                                      -- Key usage of <<TBD>>
+               otp-track-id  [0] OCTET STRING    OPTIONAL,
+               otp-challenge [1] OCTET STRING    OPTIONAL,
+               otp-time      [2] KerberosTime    OPTIONAL,
+               otp-counter   [3] OCTET STRING    OPTIONAL,
+               otp-format    [4] OTPFormat       OPTIONAL,
+               otp-keyID     [5] OCTET STRING    OPTIONAL,
+               otp-keyParam  [6] OTPRespKeyParam OPTIONAL
+             }
+
+
+
+             OTPFormat ::= INTEGER {
+               decimal(0),
+               hexadecimal(1),
+               alphanumeric(2),
+               binary(3)
+             }
+
+
+
+             PA-ENC-RESPONSE ::= SEQUENCE {
+               nonce     OCTET STRING OPTIONAL,
+               otp   [0] OCTET STRING OPTIONAL
+             }
+
+   otp-flags
+      If the "nextOTP" flag is set then the OTP was calculated based on
+      the next token "state" rather than the current one.  This flag
+      MUST be set if and only if it was set in a corresponding PA-OTP-
+      CHALLENGE.
+
+   otp-nonce
+      The nonce value encrypted in the otp-encData.  If the PA-OTP-
+      RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value
+      MUST be a copy of the corresponding value in the challenge.  If no
+      challenge was received then the nonce value MUST be generated by
+      the client.
+
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 14]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   otp-track-id
+      This element MUST be included if and only if an otp-track-id was
+      included in the corresponding PA-OTP-CHALLENGE.  If included, then
+      the value MUST be copied from the PA-OTP-CHALLENGE.
+
+   otp-challenge
+      Value used by the client to send the challenge used in the OTP
+      calculation.  It MUST be sent to the KDC if and only if the value
+      would otherwise be unknown to the KDC.  For example, the token or
+      client modified or generated challenge.
+
+   otp-time
+      Value used by the client to send the time used in the OTP
+      calculation.
+
+   otp-counter
+      The counter value used in the OTP calculation.  Use of this
+      element is OPTIONAL but it MAY be used by a client to simplify the
+      OTP calculations of the KDC to contain the counter value as
+      reported by the OTP token.
+
+   otp-format
+      The format of the generated OTP.
+
+   otp-keyID
+      The identifier of the OTP key used.
+
+   otp-keyParam
+      Information on how the reply key was generated from the OTP and
+      shared secret.  If the value is not present then the reply key was
+      generated directly from the OTP value.
+
+   otp-encData
+      The otp-encData field contains the result of the pre-
+      authentication process and is encrypted using the generated Reply
+      Key. The fields of this element are populated as follows:
+
+      nonce
+         The value of otp-nonce.
+
+      otp
+         The generated OTP value.  Present if the "sendOTP" flag is set
+         in the challenge.
+
+   <<TBD: Does the response need something such as an encrypted
+   timestamp to protect against replay?>>
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 15]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+5.3.  PA-OTP-CONFIRM
+
+   This is a pre-authentication type returned by the KDC in a KRB_AS_REP
+   if the client requires a new shared secret value.  The value is
+   encrypted as described in section 5.2.9 of [RFC4120] using the
+   current reply key as derived by the KDC from the OTP.
+
+             PA-OTP-CONFIRM ::= SEQUENCE {
+               identifier      OCTET STRING,
+               newSecretValue  EncryptedData  -- OTPNewSecret
+                                              -- Key usage of <<TBD>>
+             }
+
+             OTPNewSecret ::= CHOICE {
+               sharedSecret [0] OCTET STRING,
+               dhParams     [1] DHParam
+             }
+
+             DHParam ::= SEQUENCE {
+               dhParameter DHParameter,
+               dhPublic    INTEGER
+             }
+
+   identifier
+      An octet string identifying the new secret value.
+
+   newSecretValue
+      The new secret data encrypted using the current Reply Key. The
+      encrypted data can be of one of the following types:
+
+      sharedSecret
+         A random bit string.
+
+      dhParams
+         A Diffie-Hellman public value, prime and modulus.
+
+5.4.  PA-ENC-PIN
+
+   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
+   user must change their PIN or if the user's PIN has been changed.
+
+
+
+
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 16]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+             PA-ENC-PIN     ::= EncryptedData -- PA-ENC-PIN-ENC
+                                              -- Key usage of <<TBD>>
+             PA-ENC-PIN-ENC ::= SEQUENCE {
+               flags         PinFlags,
+               pin       [0] UTF8String OPTIONAL,
+               minLength [1] INTEGER    OPTIONAL,
+               maxLength [2] INTEGER    OPTIONAL
+             }
+
+             PinFlags ::= KerberosFlags
+               -- systemSetPin (0)
+
+   If the "systemSetPin" flag is set then the user's PIN has been
+   changed and the new PIN value is contained in the pin field.  The PIN
+   field MUST therefore be present.
+
+   If the "systemSetPin" flag is not set then the user's PIN has not
+   been changed by the server but it MUST instead be changed by the user
+   using the PIN change service.  Restrictions on the size of the PIN
+   MAY be given by the minLength and maxLength fields.  If the pin field
+   is present then it contains a PIN value that MAY be used by the user
+   when changing the PIN.  The KDC MAY only issue tickets for the PIN
+   change service until the PIN has been changed.
+
+5.5.  OTPChalKeyParam
+
+   This data type can optionally be included by the KDC in a PA-OTP-
+   CHALLENGE to instruct the client on how to generate the reply key.
+
+   This value is included in the challenge if the OTP generated by the
+   token is too weak to be used alone in the generation of the key.
+
+             OTPChalKeyParam ::= SEQUENCE {
+               flags              ChallengeFlags,
+               identifer      [0] OCTET STRING OPTIONAL,
+               iterationCount [1] INTEGER OPTIONAL
+             }
+
+             ChallengeFlags ::= KerberosFlags
+               -- sendOTP  (0)
+               -- noSecret (1)
+
+   flags
+      Flags controlling the generation of the Reply Key.
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 17]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+      sendOTP
+         If the "sendOTP" flag is set then the client MUST NOT use the
+         OTP value to generate the reply key.  It must instead use the
+         generated key to encrypt the OTP value and include the
+         encrypted value in the PA-OTP-RESPONSE.
+
+      noSecret
+         If the "noSecret" flag is set then the client MUST NOT use any
+         stored secret value in the derivation of the Reply Key. If the
+         "sendOTP" flag is also set then the Kerberos password MUST be
+         used.  If the "sendOTP" flag is not set then the iteration
+         count MUST be used if it is present or the Kerberos password
+         MUST be used if the iteration count is not specified.
+
+   identifier
+      Name of the secret that the client SHOULD use to generate the
+      reply key.
+
+      If a secret is specified but cannot be located by the client and
+      an iteration count is specified then the client should generate
+      the key using the iteration count.  If a secret value is specified
+      and cannot be located and an iteration count is not specified then
+      the reply key MUST be generated using the user's Kerberos
+      password.
+
+   iterationCount
+      This value contains the iteration count to use when the generated
+      OTP value is used in the derivation of the reply key.  This value
+      is used by the client if a shared secret is not specified or is
+      specified but cannot be found.  The value has no meaning if the
+      "sendOTP" flag is set.
+
+5.6.  OTPRespKeyParam
+
+   This data type can optionally be included by the client in a PA-OTP-
+   RESPONSE to inform the KDC of how the reply key was generated.
+
+             OTPRespKeyParam ::= SEQUENCE {
+               iterationCount [0] INTEGER OPTIONAL,
+               secret SEQUENCE {
+                 identifier       OCTET STRING,
+                 dhPublic     [1] INTEGER OPTIONAL
+               }
+             }
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 18]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   iterationCount
+      The actual value of the iteration count used by the client in the
+      key derivation.  If omitted then no iteration was used in the
+      derivation of the reply key.
+
+   secret
+      Information on the secret used in the key derivation.  If this
+      value is omitted then no shared secret was used.
+
+      identifier
+         An octet string identifying the shared secret value used by the
+         client in the key derivation.
+      dhPublic
+         The client's Diffie-Hellman public key.  Present only if a
+         Diffie-Hellman secret was used.
+
+
+6.  IANA Considerations
+
+   A registry may be required for the otp-AlgID values as introduced in
+   Section 5.1.  No other IANA actions are anticipated.
+
+
+7.  Security Considerations
+
+7.1.  Active attacks
+
+   <<TBS >>
+
+7.2.  Denial of service attacks
+
+   An active attacker may replace the iteration count value in the PA-
+   OTP-RESPONSE sent by the client to slow down an authentication
+   server.  Authentication servers SHOULD protect against this, e.g. by
+   disregarding PA-OTP-RESPONSE elements with an iteration count value
+   higher than some pre- or dynamically- (depending on load) set number.
+
+7.3.  Use of a Shared Secret Value
+
+   As described in Section 3.1, the use of a shared secret value will
+   slow down an attacker's search for a matching OTP.  The ability to
+   transfer such a value in encrypted form from the KDC to the client
+   means that, even though there may be an initial computational cost
+   for the KDC to authenticate the user if an iteration count is used,
+   subsequent authentications will be efficient, while at the same time
+   more secure, since a pre-shared, value will not be easily found by an
+   attacker.
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 19]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+   If a client does not have a pre-configured secret value for a KDC
+   then it will have to generate the Reply Key using an iteration count
+   or the Kerberos password.  If an iteration count is used then an
+   attacker observing such a KRB_AS_REQ may, depending on available
+   resources, be able to successfully attack that request.  Once the
+   correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
+   will potentially give the attacker access to the server-provided
+   secret value.  For this reason, initial exchanges with KDC servers
+   SHOULD occur in a secure environment and the lifetime of this value
+   must also be calculated with this in mind.  Finally, the value MUST
+   be securely stored by the client and the KDC, associated with the
+   user.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
+              RFC 2631, June 1999.
+
+   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
+              2000 Kerberos Change Password and Set Password Protocols",
+              RFC 3244, February 2002.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+8.2.  Informative References
+
+   [HoReNeZo04]
+              Horstein, K., Renard, K., Neuman, C., and G. Zorn,
+              "Integrating Single-use Authentication Mechanisms with
+              Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
+              progress), July 2004.
+
+
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 20]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+Author's Address
+
+   Gareth Richards
+   RSA, The Security Division of EMC
+   RSA House
+   Western Road
+   Bracknell, Berkshire  RG12 1RT
+   UK
+
+   Email: grichards@rsa.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 21]
+
+Internet-Draft                OTP Kerberos                  October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Richards                 Expires April 14, 2007                [Page 22]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt b/third_party/heimdal/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt
new file mode 100644
index 00000000000..d70f3c9dca6
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                 S. Sakane
+Expires: April 29, 2007                          Yokogawa Electric Corp.
+                                                               S. Zrelli
+                                                                   JAIST
+                                                             M. Ishiyama
+                                                           Toshiba Corp.
+                                                        October 26, 2006
+
+
+             Problem statement on the cross-realm operation
+                    of Kerberos in a specific system
+            draft-sakane-krb-cross-problem-statement-01.txt
+
+
+
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft expires in April 29, 2007.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 1]
+
+Internet-Draft                                              October 2006
+
+
+Abstract
+
+   There are some issues when the cross-realm operation of the Kerberos
+   Version 5 [RFC4120] is employed into the specific systems.  This
+   document describes some manners of the real example, and lists
+   requirements of the operation in such real system.  Then it clarifies
+   issues when we apply the cross-realm operation to such specific
+   system.
+
+
+
+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 [RFC2119].
+
+   It is assumed that the readers are familiar with the terms and
+   concepts described in the Kerberos Version 5 [RFC4120].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 2]
+
+Internet-Draft                                              October 2006
+
+
+Table of Contents
+
+    1. Introduction .................................................  4
+    2. Kerberos system ..............................................  4
+       2.1. Kerberos basic operation ................................  4
+       2.2. Cross-realm operation ...................................  5
+    3. Manner of operations in the real environment .................  6
+    4. Requirement ..................................................  7
+    5. Issues .......................................................  8
+       5.1. Scalability of the direct trust model ...................  8
+       5.2. Exposure to DoS Attacks .................................  8
+       5.3. No PFS in case of the indirect trust model ..............  9
+       5.4. Unreliability of authentication chain ...................  9
+       5.5. Client's performance ....................................  9
+       5.6. Pre-authentication problem in roaming scenarios ......... 10
+    6. Implementation consideration ................................. 10
+    7. IANA Considerations .......................................... 11
+    8. Security Considerations ...................................... 11
+    9. Acknowledgments .............................................. 11
+   10. References ................................................... 11
+       10.1. Normative References ................................... 11
+       10.2. Informative References ................................. 11
+   Authors' Addresses ............................................... 12
+   Full Copyright Statement ......................................... 12
+   Intellectual Property Statement .................................. 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 3]
+
+Internet-Draft                                              October 2006
+
+
+1.  Introduction
+
+   The Kerberos Version 5 is a widely deployed mechanism that a server
+   can authenticate a client access.  Each client belongs to a managed
+   domain called realm.  Kerberos supports the authentication in case of
+   situation that a client and a server belong to different realms.
+   This is called the cross-realm operation.
+
+   Meanwhile, there are lots of manners of operation in the real system,
+   where Kerberos could be applied.  Sometimes, there are several
+   managed domain in such system.  and it requires the authentication
+   mechanism over the different managed domains.  When the cross-realm
+   operation of Kerberos is applied to such specific systems, some
+   issues come out.
+
+   This document briefly describes the Kerberos Version 5 system and the
+   cross-realm operation.  Then, it describes two real systems that can
+   be applied the Kerberos system, and describes nine requirements of
+   those systems in term both of management and operation.  Finally, it
+   lists six issues of the cross-realm operation when it is applied to
+   those system.
+
+   Note that it might not describe whole of issues of the cross-realm
+   operation.  It also does not propose any solution to solve issues
+   described in this document.  In further step, we have to analyze, and
+   compare candidates of solutions.  This work will be in another
+   document.
+
+   This document is assumed that the readers are familiar with the terms
+   and concepts described in the Kerberos Version 5 [RFC4120].
+
+
+2.  Kerberos system
+
+
+2.1.  Kerberos basic operation
+
+   Kerberos [RFC4120] is a widely deployed authentication system.  The
+   authentication process in Kerberos involves principals and a Key
+   Distribution Center (KDC).  The principals can be users or services.
+   Each KDC maintains a principals database and shares a secret key with
+   each registered principal.
+
+   The authentication process allows a user to acquire the needed
+   credentials from the KDC.  These credentials allow services to
+   authenticate the users before granting them access to the resources.
+   An important part of the credentials are called Tickets.  There are
+   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
+
+
+
+S.Sakane, et al.                                                [Page 4]
+
+Internet-Draft                                              October 2006
+
+
+   The TGT is obtained periodically from the KDC and has a limited limit
+   after which it expires and the user must renew it.  The TGT is used
+   to obtain the other kind of tickets, Service Tickets.  The user
+   obtains a TGT from the Authentication Service (AS), a logical
+   component of the KDC.  The process of obtaining a TGT is referred to
+   as 'AS exchange'.  When a TGT request is issued by an user, the AS
+   responds by sending a reply packet containing the credentials which
+   consists of the TGT along with a random key called 'TGS Session Key'.
+   The TGT contains a set of information encrypted using a secret key
+   associated with a special service referred to as TGS (Ticket Granting
+   Service).  The TGS session key is encrypted using the user's key so
+   that the user can obtain the TGS session key only if she knows the
+   secret key shared with the KDC.  The TGT then is used to obtain
+   Service Tickets from the Ticket Granting Service (TGS)- the second
+   component of the KDC.  The process of obtaining service tickets is
+   referred to as 'TGS exchange'.  The request for a service ticket
+   consists on a packet containing a TGT and an 'Authenticator'.  The
+   Authenticator is encrypted using the TGS session key and contains the
+   identity of the user as well as time stamps (for protection against
+   replay attacks).  After decrypting the TGT (which was encrypted by
+   the AS using the TGS's secret key), the TGS extracts the TGS session
+   key.  Using that session key, it decrypts the Authenticator and
+   authenticates the user.  Then, the TGS issues credentials requested
+   by the user.  These credentials consist on a service ticket and a
+   session key that will be used to authenticate the user with the
+   desired application service.
+
+
+2.2.  Cross-realm operation
+
+   The Kerberos protocol provides the cross-realm authentication
+   capabilities.  This allows users to obtain service tickets to access
+   services in foreign realms.  In order to access such services, the
+   users first contact their home KDC asking for a TGT that will be used
+   with the TGS of the foreign realm.  If the home realm and the foreign
+   realm share keys and have an established trust relationship, the home
+   KDC delivers the requested TGT.
+
+   However, if the home realm does not share cross-realm keys with the
+   foreign realm, the home KDC will provide a TGT that can be used with
+   an intermediary foreign realm that is likely to be sharing cross-
+   realm keys with the target realm.  The client can use this
+   'intermediary TGT' to communicate with the intermediary KDC which
+   will iterate the actions taken by the home KDC: If the intermediary
+   KDC does not share cross-realm keys with the target foreign realm it
+   will point the user to another intermediary KDC (just as in the first
+   exchange between the user and its home KDC).  However, in the other
+   case (when it shares cross- realm keys with the target realm), the
+
+
+
+S.Sakane, et al.                                                [Page 5]
+
+Internet-Draft                                              October 2006
+
+
+   intermediary KDC will issue a TGT that can be used with the KDC of
+   the target realm.  After obtaining a TGT for the desired foreign
+   realm, the client uses it to obtain service tickets from the TGS of
+   the foreign realm.  Finally, the user access the service using the
+   service ticket.
+
+   When the realms belong to the same institution, a chain of trust can
+   be determined by the client or the KDC by following the DNS domain
+   hierarchy and supposing that the parent domains share keys with all
+   its child sub-domains.  However, because the inter-realm trust model
+   is not necessarily constructing the hierarchic approach anytime, the
+   trust path must be specified manually.  When intermediary realms are
+   involved, the success of the cross-realm operation completely depends
+   on the realms that are part of the authentication path.
+
+
+3.  Manner of operations in the real environment
+
+   This section describes examples of operation in the real environment.
+   And it also describes its requirement in term of both management and
+   operation.  These requirements make the issues easier understanding.
+   We refers to the world's largest petrochemical company [SHELLCHEM].
+   It produces bulk petrochemicals and their delivery to large
+   industrial customers.  There are 43 typical plants of the company all
+   over the world.  They are managed by the operation sites placed in 35
+   countries.  This section shows two examples of them.
+
+   One is the CSPC (CNOOC and Shell Petrochemical Company Limited)
+   [CSPC], an example of the centralized plant.  The CSPC is a joint
+   enterprise of CNOOC and SHELL.  Its plant is one of the hugest
+   systems of a petrochemical industry placed in the area of 3.4 square
+   meters in the north coast of Daya Bay, Guangdong, which is at the
+   southeast of China.  3,000 network segments are established in the
+   system.  16,000 control devices are connected to the local area
+   network.  These devices belong to different 9 sub systems, A control
+   device has some control points, which are controlled and monitored by
+   other devices remotely.  There are 200,000 control points in all.
+   They are controlled by 3 different control center.
+
+   Another is the NAM (Nederlandse Aardolie Maatschappij), an example of
+   the distributed plant system.  The NAM is a partnership enterprise of
+   Shell and Exxon.  It is a plant system group that geographically
+   distributes to scatter in the area of 863 square meters of
+   Netherlands.  26 plants, each is named "cluster", are scattered in
+   the area.  They are connected each other by a private ATM WAN.  Each
+   cluster has approximately 500-1,000 control devices.  These devices
+   are managed by each local control center in each cluster.  In the
+   entire system of the NAM, there are one million control points.
+
+
+
+S.Sakane, et al.                                                [Page 6]
+
+Internet-Draft                                              October 2006
+
+
+   The end control devices in the both of the systems are basically
+   connected to a local network by a twisted pair cable, which is a low
+   band-width of 32 kbps.  Every system supposes that no ad-hoc device
+   is never connected to the system since they are well designed before
+   they are implemented.  Low clock CPU, for example H8 [RNSS-H8] and
+   M16C [RNSS-M16C], are employed by many control devices.  Furthermore,
+   to suppress power consumption, these CPU may be lowered the number of
+   clocks.  A controller in this system collects condition of device
+   from multiple control devices, and the system uses them to make a
+   decision how to control devices.  If it took time for data to reach,
+   they could not be associated.  The travel time of data from the
+   device to the controller is demanded within 1 second.  A part of the
+   operation, like control of these system, maintenance, and the
+   environmental monitoring, is consigned to an external organization.
+   Agents who are consigned walk around the plant to get their
+   information, or watch the plant from a remote site.  Currently, each
+   plant is independently operated.  However, it is not impossible to
+   monitor and control all of plants distributed in the world.
+
+
+4.  Requirement
+
+   This section listed requirements derived from the previous section.
+   There are seven requirements in term of management domain separation.
+
+   A-1  It is necessary to allow different independent management
+        domains to coexist because two or more organizations enter to
+        the system.
+
+   A-2  It is necessary to allow a management domain to delegate its
+        management authority to its sub domains or another management
+        domain because the plants are distributed to the wide area.
+
+   A-3  It is necessary that a device controls other devices that belong
+        to a same domain from remote because the plants are distributed
+        to the wide area.
+
+   A-4  It is necessary that a device controls other devices that belong
+        to a different domain from local.
+
+   A-5  It is necessary that a device controls other devices that belong
+        to a different domain from remote.
+
+   A-6  It is necessary for the agents who are consigned to watch and
+        control the device at the plant, which is different domain from
+        the agents' one.
+
+   Because of above requirements, the cross-realm operation of Kerberos
+
+
+
+S.Sakane, et al.                                                [Page 7]
+
+Internet-Draft                                              October 2006
+
+
+   seems suitable for this system.  The requirements derived from other
+   viewpoints is listed as follows.
+
+   B-1  It is demanded to reduce the management cost as much as
+        possible.
+
+   B-2  The communication for observing and controlling devices must
+        have confidentiality and integrity.  And, it is necessary to
+        think about the threat of other security like the DoS attack.
+
+   B-3  It is necessary to consider the processing performance of the
+        device.  And, it is necessary to suppress the power consumption
+        of the device.
+
+   B-4  It is necessary to consider bandwidth of the communication.
+
+
+5.  Issues
+
+   This section lists the issues in the cross-realm operation when we
+   consider the above requirements.
+
+
+5.1.  Scalability of the direct trust model
+
+   In the direct relationship of trust between each realm, the realms
+   involved in the cross-realm operation share keys and their respective
+   TGS principals are registered in each other's KDC.  When direct trust
+   relationships are used, the KDC of each realm must maintain keys with
+   all foreign realms.  This can become a cumbersome task when the
+   number of realms increase.  This also increases maintenance cost.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements A-1 and A-2, and is related to B-1.
+
+
+5.2.  Exposure to DoS Attacks
+
+   One of the assumption made when allowing the cross-realm operation in
+   Kerberos is that users can communicate with KDCs located in remote
+   realms.  This practice introduces security threats because KDCs are
+   open to the public network.  Administrators may think of restricting
+   the access to the KDC to the trusted realms only.  However, this
+   approach is not scalable and does not really protect the KDC.
+   Indeed, when the remote realms have several IP prefixes (e.g. control
+   centers or outsourcing companies, located world wide), then the
+   administrator of the local KDC must collect the list of prefixes that
+   belong to these organization.  The filtering rules must then
+
+
+
+S.Sakane, et al.                                                [Page 8]
+
+Internet-Draft                                              October 2006
+
+
+   explicitly allow the incoming traffic from any host that belongs to
+   one of these prefixes.  This makes the administrator's tasks more
+   complicated and prone to human errors.  And also, the maintenance
+   cost increases.  On the other hand, when ranges of external IP
+   addresses are allowed to communicate with the KDC, the risk of
+   becoming target to attacks from remote malicious users increases.
+
+   This issue will happen as a result meeting the requirements A-3, A-4
+   and A-5.  And it is related to B-1 and B-2.
+
+
+5.3.  No PFS in case of the indirect trust model
+
+   In [SPECCROSS], any KDC in the authentication path can learn the
+   session key that will be used between the client and the desired
+   service.  This means that any intermediary realm is able to spoof the
+   identity either of the service or the client as well as to eavesdrop
+   on the communication between the client and the server.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements A-1 and A-2, and is related to B-2.
+
+
+5.4.  Unreliability of authentication chain
+
+   When the relationship of trust is constructed like a chain or
+   hierarchical, the authentication path is not dependable since it
+   strongly depends on intermediary realms that might not be under the
+   same authority.  If any of the realms in the authentication path is
+   not available, then the principals of the end-realms can not perform
+   the cross-realm operation.
+
+   The end-point realms do not have full control and responsibility of
+   the success of the operations even if their respective KDCs are fully
+   functional.  Dependability of a system decreases if the system relies
+   on uncontrolled components.  We can not be sure at 100% about the
+   result of the authentication since we do not know how is it going in
+   intermediary realms.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements A-1 and A-2, and is related to B-2.
+
+
+5.5.  Client's performance
+
+   In the cross-realm operation, Kerberos clients have to perform TGS
+   exchanges with all the KDCs in the trust path, including the home KDC
+   and the target KDC.  TGS exchange requires cryptographic operations.
+
+
+
+S.Sakane, et al.                                                [Page 9]
+
+Internet-Draft                                              October 2006
+
+
+   This exchange demands important processing time especially when the
+   client has limited computational capabilities.  The overhead of these
+   cross-realm exchanges grows into unacceptable delays.
+
+   We ported the MIT Kerberos library (version 1.2.4), implemented a
+   Kerberos client on our original board with H8 (16-bit, 20MHz), and
+   measured the process time of each Kerberos message.  It takes 195
+   milliseconds to perform a TGS exchange with the on-board H/W crypto
+   engine.  Indeed, this result seems reasonable to the requirement of
+   the response time for the control network.  However, we did not
+   modify the clock speed of the H8 during our measurement.  The
+   processing time must be slower in a real environment because H8 is
+   used with lowered clock speed in such system.  Also, the delays can
+   grow to unacceptable delays when the number of intermediary realms
+   increases.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements A-1 and A-2, and is related to B-3.
+
+
+5.6.  Pre-authentication problem in roaming scenarios
+
+   In roaming scenarios, the client needs to contact her home KDC to
+   obtain a cross-realm TGT for the local (or visited) realm.  However,
+   the policy of the network access providers or the gateway in the
+   local network usually does not allow clients to communicate with
+   hosts in the Internet unless they provide valid authentication
+   credentials.  In this manner, the client encounters a chicken-and-egg
+   problem where two resources are interdependent; the Internet
+   connection is needed to contact the home KDC and for obtaining
+   credentials, and on the other hand, the Internet connection is only
+   granted for clients who have valid credentials.  As a result, the
+   Kerberos protocol can not be used as it is for authenticating roaming
+   clients requesting network access.
+
+   This issue will happen as a result meeting the requirements A-6.
+
+
+6.  Implementation consideration
+
+   This document just describes issues of the cross-realm operation in
+   the specific systems.  However, there are important matters to be
+   considered, when we solve these issues and implement solution.
+   Solution must not introduce new problem.  Solution should use
+   existing components or protocols as much as possible, should not
+   introduce any definition of new component.  Solution must not require
+   a KDC to have any additional process.  You must not forget that there
+   would be a trade-off matter anytime.  So an implementation may not
+
+
+
+S.Sakane, et al.                                               [Page 10]
+
+Internet-Draft                                              October 2006
+
+
+   solve all of the problems stated in this document.
+
+
+7.  IANA Considerations
+
+   This document makes no request of IANA.
+
+
+8.  Security Considerations
+
+   This document just clarifies some issues of the cross-realm operation
+   of the Kerberos V system.  There is especially not describing
+   security.  Some troubles might be caused to your system by malicious
+   user who misuses the description of this document if it dares to say.
+
+
+9.  Acknowledgments
+
+   The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa,
+   Ken'ichi Kamada and Atsushi Inoue.  They gave us lots of comments and
+   input for this document.
+
+
+10.  References
+
+
+10.1.  Normative References
+
+   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                 Kerberos Network Authentication Service (V5)", RFC
+                 4120, July 2005.
+
+
+10.2.  Informative References
+
+   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
+                 531,00.html
+
+   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
+                 jsp&fp=/products/mpumcu/h8_family/
+
+   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
+                 ng.jsp&fp=/products/mpumcu/m16c_family/
+
+   [RFC2119]     S.Bradner, "Key words for use in RFCs to Indicate
+                 Requirement Levels", RFC 2119, March 1997.
+
+
+
+
+
+S.Sakane, et al.                                               [Page 11]
+
+Internet-Draft                                              October 2006
+
+
+   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html
+
+   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
+                 Walstad, "Specifying Kerberos 5 Cross-Realm
+                 Authentication", Fifth Workshop on Issues in the Theory
+                 of Security, Jan 2005.
+
+Authors' Addresses
+
+   Shoichi Sakane
+   Yokogawa Electric Corporation
+   2-9-32 Nakacho, Musashino-shi,
+   Tokyo  180-8750 Japan
+   E-mail: Shouichi.Sakane@jp.yokogawa.com,
+
+
+   Saber Zrelli
+   Japan Advanced Institute of Science and Technology
+   1-1 Asahidai, Nomi,
+   Ishikawa  923-1292 Japan
+   E-mail: zrelli@jaist.ac.jp
+
+
+   Masahiro Ishiyama
+   Toshiba Corporation
+   1, komukai-toshiba-cho, Saiwai-ku,
+   Kawasaki  212-8582 Japan
+   E-mail: masahiro@isl.rdc.toshiba.co.jp
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.Sakane, et al.                                               [Page 12]
+
+Internet-Draft                                              October 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                               [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-sakane-krb-cross-problem-statement-03.txt b/third_party/heimdal/doc/standardisation/draft-sakane-krb-cross-problem-statement-03.txt
new file mode 100644
index 00000000000..2ac425adaf8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-sakane-krb-cross-problem-statement-03.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                 S. Sakane
+Intended Status: Informational                   Yokogawa Electric Corp.
+Expires: January 10, 2008                                      S. Zrelli
+                                                                   JAIST
+                                                             M. Ishiyama
+                                                           Toshiba Corp.
+                                                            July 9, 2007
+
+
+             Problem statement on the cross-realm operation
+                    of Kerberos in a specific system
+            draft-sakane-krb-cross-problem-statement-03.txt
+
+
+
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   This Internet-Draft expires in January 10, 2008.
+
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 1]
+
+Internet-Draft                                                 July 2007
+
+
+Abstract
+
+   There are some issues when the cross-realm operation of the Kerberos
+   Version 5 [RFC4120] is employed into actual specific systems.  This
+   document describes some examples of actual systems, and lists
+   requirements and restriction of the operation in such system.  Then
+   it describes issues when we apply the cross-realm operation to such
+   system.
+
+
+
+Conventions used in this document
+
+   It is assumed that the readers are familiar with the terms and
+   concepts described in the Kerberos Version 5 [RFC4120].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 2]
+
+Internet-Draft                                                 July 2007
+
+
+Table of Contents
+
+    1. Introduction .................................................  4
+    2. Kerberos system ..............................................  4
+       2.1. Kerberos basic operation ................................  4
+       2.2. Cross-realm operation ...................................  5
+    3. Example of actual environment ................................  6
+    4. Requirements .................................................  7
+    5. Issues .......................................................  8
+       5.1. Unreliability of authentication chain ...................  8
+       5.2. No PFS in case of the indirect trust model ..............  8
+       5.3. Scalability of the direct trust model ...................  9
+       5.4. Exposure to DoS Attacks .................................  9
+       5.5. Client's performance ....................................  9
+       5.6. Pre-authentication problem in roaming scenarios ......... 10
+    6. Implementation consideration ................................. 10
+    7. IANA Considerations .......................................... 11
+    8. Security Considerations ...................................... 11
+    9. Acknowledgments .............................................. 11
+   10. References ................................................... 11
+       10.1. Normative References ................................... 11
+       10.2. Informative References ................................. 11
+   Authors' Addresses ............................................... 12
+   Full Copyright Statement ......................................... 12
+   Intellectual Property Statement .................................. 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                                [Page 3]
+
+Internet-Draft                                                 July 2007
+
+
+1.  Introduction
+
+   The Kerberos Version 5 is a widely deployed mechanism that a server
+   can authenticate a client access.  Each client belongs to a managed
+   domain called realm.  Kerberos supports the authentication in case of
+   situation that a client and a server belong to different realms.
+   This is called the cross-realm operation.
+
+   Meanwhile, there are lots of manners of operation in actual systems,
+   where Kerberos could be applied.  Large system or distributed system
+   are typically split into several managed domain.  The reason is, for
+   example, geographical reason or different management policy.  Even in
+   such system, an authentication mechanism over the different managed
+   domains is required.  When the cross-realm operation of Kerberos is
+   applied to such systems, some issues come out.
+
+   This document briefly describes the Kerberos Version 5 system and the
+   cross-realm operation.  Then, it describes two actual systems that
+   could be applied the Kerberos system, and describes seven
+   requirements of those systems in term both of management and
+   operation.  Finally, it lists six issues of the cross-realm operation
+   when it is applied to those system.
+
+   Note that this document might not describe whole of issues of the
+   cross-realm operation.  It also does not propose any solution to
+   solve issues which described in this document.  In further step, we
+   have to analyze the issues, define problems and explore the
+   solutions.  This work will be in another document.
+
+   This document is assumed that the readers are familiar with the terms
+   and concepts described in the Kerberos Version 5 [RFC4120].
+
+
+2.  Kerberos system
+
+
+2.1.  Kerberos basic operation
+
+   Kerberos [RFC4120] is a widely deployed authentication system.  The
+   authentication process in Kerberos involves principals and a Key
+   Distribution Center (KDC).  The principals can be users or services.
+   Each KDC maintains a principals database and shares a secret key with
+   each registered principal.
+
+   The authentication process allows a user to acquire the needed
+   credentials from the KDC.  These credentials allow services to
+   authenticate the users before granting them access to the resources.
+   An important part of the credentials are called Tickets.  There are
+
+
+
+S.Sakane, et al.                                                [Page 4]
+
+Internet-Draft                                                 July 2007
+
+
+   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
+   The TGT is obtained periodically from the KDC and has a limited limit
+   after which it expires and the user must renew it.  The TGT is used
+   to obtain the other kind of tickets, Service Tickets.  The user
+   obtains a TGT from the Authentication Service (AS), a logical
+   component of the KDC.  The process of obtaining a TGT is referred to
+   as 'AS exchange'.  When a TGT request is issued by an user, the AS
+   responds by sending a reply packet containing the credentials which
+   consists of the TGT along with a random key called 'TGS Session Key'.
+   The TGT contains a set of information encrypted using a secret key
+   associated with a special service referred to as TGS (Ticket Granting
+   Service).  The TGS session key is encrypted using the user's key so
+   that the user can obtain the TGS session key only if she knows the
+   secret key shared with the KDC.  The TGT then is used to obtain
+   Service Tickets from the Ticket Granting Service (TGS)- the second
+   component of the KDC.  The process of obtaining service tickets is
+   referred to as 'TGS exchange'.  The request for a service ticket
+   consists on a packet containing a TGT and an 'Authenticator'.  The
+   Authenticator is encrypted using the TGS session key and contains the
+   identity of the user as well as time stamps (for protection against
+   replay attacks).  After decrypting the TGT (which was encrypted by
+   the AS using the TGS's secret key), the TGS extracts the TGS session
+   key.  Using that session key, it decrypts the Authenticator and
+   authenticates the user.  Then, the TGS issues credentials requested
+   by the user.  These credentials consist on a service ticket and a
+   session key that will be used to authenticate the user with the
+   desired application service.
+
+
+2.2.  Cross-realm operation
+
+   The Kerberos protocol provides the cross-realm authentication
+   capabilities.  This allows users to obtain service tickets to access
+   services in foreign realms.  In order to access such services, the
+   users first contact their home KDC asking for a TGT that will be used
+   with the TGS of the foreign realm.  If the home realm and the foreign
+   realm share keys and have an established trust relationship, the home
+   KDC delivers the requested TGT.
+
+   However, if the home realm does not share inter-realm keys with the
+   foreign realm, the home KDC will provide a TGT that can be used with
+   an intermediary foreign realm that is likely to be sharing inter-
+   realm keys with the target realm.  The client can use this
+   'intermediary TGT' to communicate with the intermediary KDC which
+   will iterate the actions taken by the home KDC.  If the intermediary
+   KDC does not share inter-realm keys with the target foreign realm it
+   will point the user to another intermediary KDC (just as in the first
+   exchange between the user and its home KDC).  However, in the other
+
+
+
+S.Sakane, et al.                                                [Page 5]
+
+Internet-Draft                                                 July 2007
+
+
+   case (when it shares inter-realm keys with the target realm), the
+   intermediary KDC will issue a TGT that can be used with the KDC of
+   the target realm.  After obtaining a TGT for the desired foreign
+   realm, the client uses it to obtain service tickets from the TGS of
+   the foreign realm.  Finally, the user access the service using the
+   service ticket.
+
+   When the realms belong to the same institution, a chain of trust can
+   be determined by the client or the KDC by following the DNS domain
+   hierarchy and supposing that the parent domains share keys with all
+   its child sub-domains.  However, because the inter-realm trust model
+   is not necessarily constructing the hierarchic approach anytime, the
+   trust path must be specified manually.  When intermediary realms are
+   involved, the success of the cross-realm operation completely depends
+   on the realms that are part of the authentication path.
+
+
+3.  Example of actual environment
+
+   In order to help understanding both requirements and restriction,
+   this section describes scale and operation of actual systems, where
+   it is possible to apply Kerberos.
+
+   We refer to actual petrochemical enterprise [SHELLCHEM], and show two
+   examples among its plants.  The enterprise produces bulk
+   petrochemicals and their delivery to large industrial customers.
+   There are 43 typical plants of the enterprise all over the world.
+   They are managed by the operation sites placed in 35 countries.  This
+   section shows two examples of them.
+
+   One is an example of a centralized system [CSPC].  CSPC is operated
+   by a joint enterprise of two companies.  This system is one of the
+   largest systems of this enterprise in the world.  This is placed in
+   the area of 3.4 square kilo meters in the north coast of Daya Bay,
+   Guangdong, which is at the southeast of China.  3,000 network
+   segments are established in the system.  16,000 control devices are
+   connected to the local area network.  These devices belong to
+   different 9 sub systems, A control device has some control points,
+   which are controlled and monitored by other devices remotely.  There
+   are 200,000 control points in all.  They are controlled by 3
+   different control center.
+
+   Another example is a distributed system [NAM].  The NAM (Nederlandse
+   Aardolie Maatschappij) is operated by a partnership company of two
+   enterprises that represent the oil company.  This system is
+   constituted by some plants that are geographically distributed within
+   the range of 863 square kilometers in the northern part of
+   Netherlands.  26 plants, each is named "cluster", are scattered in
+
+
+
+S.Sakane, et al.                                                [Page 6]
+
+Internet-Draft                                                 July 2007
+
+
+   the area.  They are connected each other by a private ATM WAN.  Each
+   cluster has approximately 500-1,000 control devices.  These devices
+   are managed by each local control center in each cluster.  In the
+   entire system of the NAM, there are one million control points.
+
+   In the both of the systems, the end devices are basically connected
+   to a local network by a twisted pair cable, which is a low band-width
+   of 32 kbps.  Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS-
+   M16C], are employed by many control devices.  Furthermore, to
+   suppress power consumption, these CPU may be lowered the number of
+   clocks.  Because there is a requirement of the explosion-proof.  The
+   requirement restricts the amount of total energy in the device.
+
+   A device on the network collects data from other devices which are
+   monitoring condition of the system.  The device uses the data to make
+   a decision how to control another devices.  And then the device gives
+   more than one instruction that controls other devices.  If it took
+   time for data to reach, they could not be associated.  The travel
+   time of data from the device to the other device is demanded within 1
+   second at least.
+
+   A part of the operation, like control of these system, maintenance,
+   and the environmental monitoring, is consigned to an external
+   organization.  Agents who are consigned walk around the plant to get
+   their information, or watch the plant from a remote site.
+
+
+4.  Requirements
+
+   This section lists the requirements derived from the previous
+   section.  R-1, R-2, R-3 and R-4 are related to the management of the
+   divided system.  R-5, R-6 and R-7 are related to the restriction to
+   such industrial network.
+
+
+   R-1  It is necessary to partition a management domain into some
+        domains.  Or it is necessary to delegate a management authority
+        to another independent management domain.
+
+   R-2  It is necessary to allow different independent management
+        domains to coexist on the same network because two or more
+        organizations need to enter into the system and to management
+        it.
+
+   R-3  It is necessary that a device controls other devices that belong
+        to a different domain.
+
+
+
+
+
+S.Sakane, et al.                                                [Page 7]
+
+Internet-Draft                                                 July 2007
+
+
+   R-4  It is necessary to consider that a device is not always
+        geographically or network topologically close to the other
+        devices even when the devices belong to a same management
+        domain.
+
+   R-5  It is demanded to reduce the management cost as much as
+        possible.
+
+   R-6  It is necessary to consider the processing performance of the
+        device.  And, it is necessary to suppress the power consumption
+        of the device.
+
+   R-7  It is necessary to consider bandwidth of the communication.
+
+
+5.  Issues
+
+   This section lists the issues in the cross-realm operation when we
+   apply the Kerberos version 5 into the system described in the section
+   3, and consider the system applied the Kerberos with the requirements
+   described in the section 4.
+
+
+5.1.  Unreliability of authentication chain
+
+   When the relationship of trust is constructed like a chain or
+   hierarchical, the authentication path is not dependable since it
+   strongly depends on intermediary realms that might not be under the
+   same authority.  If any of the realms in the authentication path is
+   not available, then the principals of the end-realms can not perform
+   the cross-realm operation.
+
+   The end-point realms do not have full control and responsibility of
+   the success of the operations even if their respective KDCs are fully
+   functional.  Dependability of a system decreases if the system relies
+   on uncontrolled components.  We can not be sure at 100% about the
+   result of the authentication since we do not know how is it going in
+   intermediary realms.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1 and R-2.
+
+
+5.2.  No PFS in case of the indirect trust model
+
+   In [SPECCROSS], any KDC in the authentication path can learn the
+   session key that will be used between the client and the desired
+   service.  This means that any intermediary realm is able to spoof the
+
+
+
+S.Sakane, et al.                                                [Page 8]
+
+Internet-Draft                                                 July 2007
+
+
+   identity either of the service or the client as well as to eavesdrop
+   on the communication between the client and the server.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1 and R-2.
+
+
+5.3.  Scalability of the direct trust model
+
+   In the direct relationship of trust between each realm, the realms
+   involved in the cross-realm operation share keys and their respective
+   TGS principals are registered in each other's KDC.  When direct trust
+   relationships are used, the KDC of each realm must maintain keys with
+   all foreign realms.  This can become a cumbersome task when the
+   number of realms increase.  This also increases maintenance cost.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1, R-2 and R-5.
+
+
+5.4.  Exposure to DoS Attacks
+
+   One of the assumption made when allowing the cross-realm operation in
+   Kerberos is that users can communicate with KDCs located in remote
+   realms.  This practice introduces security threats because KDCs are
+   open to the public network.  Administrators may think of restricting
+   the access to the KDC to the trusted realms only.  However, this
+   approach is not scalable and does not really protect the KDC.
+   Indeed, when the remote realms have several IP prefixes (e.g. control
+   centers or outsourcing companies, located world wide), then the
+   administrator of the local KDC must collect the list of prefixes that
+   belong to these organization.  The filtering rules must then
+   explicitly allow the incoming traffic from any host that belongs to
+   one of these prefixes.  This makes the administrator's tasks more
+   complicated and prone to human errors.  And also, the maintenance
+   cost increases.  On the other hand, when ranges of external IP
+   addresses are allowed to communicate with the KDC, the risk of
+   becoming target to attacks from remote malicious users increases.
+
+
+5.5.  Client's performance
+
+   In the cross-realm operation, Kerberos clients have to perform TGS
+   exchanges with all the KDCs in the trust path, including the home KDC
+   and the target KDC.  TGS exchange requires cryptographic operations.
+   This exchange demands important processing time especially when the
+   client has limited computational capabilities.  The overhead of these
+   cross-realm exchanges grows into unacceptable delays.
+
+
+
+S.Sakane, et al.                                                [Page 9]
+
+Internet-Draft                                                 July 2007
+
+
+   We ported the MIT Kerberos library (version 1.2.4), implemented a
+   Kerberos client on our original board with H8 (16-bit, 20MHz), and
+   measured the process time of each Kerberos message [KRBIMPL].  It
+   takes 195 milliseconds to perform a TGS exchange with the on-board
+   H/W crypto engine.  Indeed, this result seems reasonable to the
+   requirement of the response time for the control network.  However,
+   we did not modify the clock speed of the H8 during our measurement.
+   The processing time must be slower in a actual environment because H8
+   is used with lowered clock speed in such system.  Also, the delays
+   can grow to unacceptable delays when the number of intermediary
+   realms increases.
+
+   This issue will happen as a by-product of a result meeting the
+   requirements R-1, R-2, R-6 and R-7.
+
+
+5.6.  Pre-authentication problem in roaming scenarios
+
+   In roaming scenarios, the client needs to contact her home KDC to
+   obtain a cross-realm TGT for the local (or visited) realm.  However,
+   the policy of the network access providers or the gateway in the
+   local network usually does not allow clients to communicate with
+   hosts in the Internet unless they provide valid authentication
+   credentials.  In this manner, the client encounters a chicken-and-egg
+   problem where two resources are interdependent; the Internet
+   connection is needed to contact the home KDC and for obtaining
+   credentials, and on the other hand, the Internet connection is only
+   granted for clients who have valid credentials.  As a result, the
+   Kerberos protocol can not be used as it is for authenticating roaming
+   clients requesting network access.
+
+   This issue will happen as a result meeting the requirements R-3 and
+   R-4.
+
+
+6.  Implementation consideration
+
+   This document just describes issues of the cross-realm operation.
+   However, there are important matters to be considered, when we solve
+   these issues and implement solution.  Solution must not introduce new
+   problem.  Solution should use existing components or protocols as
+   much as possible, should not introduce any definition of new
+   component.  Solution must not require a KDC to have any additional
+   process.  You must not forget that there would be a trade-off matter
+   anytime.  So an implementation may not solve all of the problems
+   stated in this document.
+
+
+
+
+
+S.Sakane, et al.                                               [Page 10]
+
+Internet-Draft                                                 July 2007
+
+
+7.  IANA Considerations
+
+   This document makes no request of IANA.
+
+
+8.  Security Considerations
+
+   This document just clarifies some issues of the cross-realm operation
+   of the Kerberos V system.  There is especially not describing
+   security.  Some troubles might be caused to your system by malicious
+   user who misuses the description of this document if it dares to say.
+
+
+9.  Acknowledgments
+
+   The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa,
+   Ken'ichi Kamada and Atsushi Inoue.  They gave us lots of comments and
+   input for this document.
+
+
+10.  References
+
+
+10.1.  Normative References
+
+   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                 Kerberos Network Authentication Service (V5)", RFC
+                 4120, July 2005.
+
+
+10.2.  Informative References
+
+   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
+                 531,00.html
+
+   [KRBIMPL]     "A Prototype of a Secure Autonomous Bootstrap Mechanism
+                 for Control Networks", Nobuo Okabe, Shoichi Sakane,
+                 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki,
+                 SAINT, pp. 56-62, IEEE Computer Society, 2006.
+
+   [NAM]         http://www.nam.nl/
+
+   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
+                 jsp&fp=/products/mpumcu/h8_family/
+
+   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
+                 ng.jsp&fp=/products/mpumcu/m16c_family/
+
+
+
+
+S.Sakane, et al.                                               [Page 11]
+
+Internet-Draft                                                 July 2007
+
+
+   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html
+
+   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
+                 Walstad, "Specifying Kerberos 5 Cross-Realm
+                 Authentication", Fifth Workshop on Issues in the Theory
+                 of Security, Jan 2005.
+
+Authors' Addresses
+
+   Shoichi Sakane
+   Yokogawa Electric Corporation
+   2-9-32 Nakacho, Musashino-shi,
+   Tokyo  180-8750 Japan
+   E-mail: Shouichi.Sakane@jp.yokogawa.com,
+
+
+   Saber Zrelli
+   Japan Advanced Institute of Science and Technology
+   1-1 Asahidai, Nomi,
+   Ishikawa  923-1292 Japan
+   E-mail: zrelli@jaist.ac.jp
+
+
+   Masahiro Ishiyama
+   Toshiba Corporation
+   1, komukai-toshiba-cho, Saiwai-ku,
+   Kawasaki  212-8582 Japan
+   E-mail: masahiro@isl.rdc.toshiba.co.jp
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.Sakane, et al.                                               [Page 12]
+
+Internet-Draft                                                 July 2007
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+S.Sakane, et al.                                               [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/third_party/heimdal/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
new file mode 100644
index 00000000000..321c5ba0998
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-srp.txt b/third_party/heimdal/doc/standardisation/draft-srp.txt
new file mode 100644
index 00000000000..9c4cc954d7f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-srp.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                             Love Hornquist Astrand
+<draft-hornquist-astrand-krb-wg-srp.txt>          Stockholms universitet
+Internet-Draft                                            December, 2003
+Expire in six months
+
+            Using SRP for Initial Authentication in Kerberos
+
+Status of this Memo
+
+ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
+
+   This memo provides information for the Internet community. ...
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved. ...
+
+
+Abstract
+
+   This document describes how to use SRP as a preauthentication
+   mechanism in Kerberos 5 [RFC1510].  This mechanism makes the initial
+   ticket request and response secure against dictionary attacks on
+   users passwords.
+
+Introduction
+
+   Kerberos without preauthentication make the protocol susceptible to
+   both to password dictionary attacks on initial tickets.  There are
+   several pre-authentication mechanisms that tries to solve and/or
+   minimize this problem.
+
+   Encrypted time stamp have the same problem as Kerberos without
+   preauthentication, opportunities of the attacker to get key material
+   is only fewer.  SAM require hardware token and typically, for most
+   SAM types, still require the user to have a password since they don't
+   provide enough key-material for Kerberos to encrypt the response
+   with.  PKINIT large and complicated, and like SAM often require
+   hardware.  Extra-tgt requires infrastructure to use, a key/bootstrap
+   must be present on each host that the users are expected to use.
+
+   The dictionary attack can also be solved by forcing the users to
+   select good password.
+
+   XXX Jacques' DH preauth ?
+   XXX tls protected as-req
+
+   SRP, Secure Remote Password protocol, [RFC2945], is a password
+
+
+
+Hornquist Astrand                                               [Page 1]
+
+Internet Draft                                            December, 2003
+
+
+   authentication and key-exchange protocol that can be used over
+   untrusted networks.  SRP is designed to be resistable to dictionary
+   attacks (both by passive and active attackers).
+
+Specification
+
+   This document is based on SRP-6.
+
+   XXX read and think about rfc2944 (SRP over telnet)
+
+   SRP + Kerberos 5 preauthentication
+
+   Krb-srp-cookie in the protocol to enable the server be stateless.
+
+   TBA KRB-SRP-PREAUTH number
+
+   - Client send the AS-REQ
+
+   - Server looks up the principal, and finds N, g, v, salt, H.  Then
+   the server generates the random number b and calculate B.  All
+   operations are performed modulus N.
+
+        B = 3v + g^b
+
+   and sends back a KRB-SRP-CHALLENGE md-data in a KRB-ERROR. If the
+   server is stateless, it can store the information (encrypted) it
+   needs in krb-srp-cookie.
+
+   - If the client chooses to use the SRP preauthentication mechanism it
+   sends back KRB-SRP-CLIENT-RESPONSE.  If krb-srp-cookie is present in
+   KRB-SRP-CHALLENGE its copied to KRB-SRP-CLIENT-RESPONSE.  The client
+   generates the random number a and calculates
+
+        A = g^a
+        S = (B - 3g^x)^(a+ux)
+        M1 = H(DER(A) | DER(B) | DER(S))
+
+   u is H(DER(A) | DER(B)), where DER(n) is the n encoded with the
+   integer tag.
+
+   The client then it calculates the shared key K
+
+        K = s-to-key-bytes(S)
+
+   KRB-SRP-CLIENT-RESPONSE-ENC-DATA is filled in by the client,
+   encrypted with the shared key K
+
+   XXX should a keyed checksum just be used instead ?
+
+
+
+Hornquist Astrand                                               [Page 2]
+
+Internet Draft                                            December, 2003
+
+
+   XXX does this replace the need for M1
+
+   - When the server receives the KRB-SRP-CLIENT-RESPONSE response it
+   calculates
+
+        S = (Av^u)^b
+
+   and the shared key K,
+
+        K = s-to-key-bytes(S)
+
+   verifies the content in krb-srp-enc, and M1.  If everything checks
+   out ok, the server sends back the AS-REP.  The key that the AS-REP is
+   encrypted with is the SRP session key, K.
+
+   XXX Should the server send back M2 ?
+
+   s-to-key defined as:
+
+        b = DER(S)
+        if length of b is even, drop first char
+        b1 = H(b[0] | b[2] | b[4] | ...)
+        b2 = H(b[1] | b[3] | b[5] | ...)
+        K = random-to-key(b1 | b2).
+
+   random-to-key is the random to key function in [KCRYPTO].
+
+ASN.1 specification
+
+   XXX Krb-Nonce
+
+   KERBEROS-PREAUTH-SRP DEFINITIONS ::=
+
+   BEGIN
+
+   IMPORTS Checksum, Krb-Nonce FROM krb5;
+
+   KRB-SRP-CHALLENGE ::= SEQUENCE {
+           krb-srp-salt[0]         OCTET STRING,
+           krb-srp-N[1]            INTEGER,
+           krb-srp-g[2]            INTEGER,
+           krb-srp-B[3]            INTEGER,
+           krb-srp-hash[4]         OBJECT IDENTIFIER,
+           krb-srp-flags[5]        INTEGER (SIZE 4),
+           krb-srp-cookie[6]       OCTET STRING OPTIONAL -- must include nonce ?
+   }
+
+   -- flags: "use combined s2k + srp key" ?
+
+
+
+Hornquist Astrand                                               [Page 3]
+
+Internet Draft                                            December, 2003
+
+
+   KRB-SRP-CLIENT-RESPONSE ::= SEQUENCE {
+           krb-srp-A[0]            INTEGER,
+           krb-srp-M1[1]           OCTET STRING,
+           krb-srp-hash[2]         OBJECT IDENTIFIER,
+           krb-srp-enc[3]          EncryptedData, -- bind nonce to pa
+           krb-srp-cookie[4]       OCTET STRING OPTIONAL
+   }
+
+   KRB-SRP-CLIENT-RESPONSE-ENC-DATA :: SEQUENCE {
+           krb-srp-checksum[0]     Checksum,
+           krb-srp-flags[1]        INTEGER (SIZE 4),
+           krb-srp-nonce[2]        Krb-Nonce
+   }
+
+   KRB-SRP-SERVER-RESPONSE ::= SEQUENCE {
+           krb-srp-M2[0]           OCTET STRING
+   }
+
+   END
+
+Issues
+
+   send group/generator by name ?
+
+   how to bind request to pa data ?
+
+   what key should be used, the key from SRP, or the compiled key from
+   s2k + SRP, right now its a flag.
+
+Requirements on the KDC
+
+   The KDC needs to know more information for each principal.  At least
+   the KDC needs to store:
+
+   N, the safe prime
+   g, the generator
+   v, the password verifier
+   salt, that salt that the principal used to form the verifier, v
+   H, hash function used to form the verifier, v
+
+   Also, since the KDC no longer have a list of keys, and thus an
+   implicit list what encryption types the principal is allowed use, it
+   needs to have a list for all the encryption types a user is allowed
+   to use with SRP preauthentication mechanism.
+
+Security considerations
+
+   SRP
+
+
+
+Hornquist Astrand                                               [Page 4]
+
+Internet Draft                                            December, 2003
+
+
+   see Security considerations in Nisses SSH SRP draft.
+
+   Kerberos
+
+   Preauthentication
+
+   SRP preauthentication mechanism doesn't require the client to compute
+   something before the server sends "expensive" cryptographic
+   operations.
+
+   Preauthentication have the problem that the response is not
+   authenticated, so a active attacker can modify that response from the
+   KDC to remove SRP to have the client choose a weaker initial
+   authentication method.
+
+References
+
+   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
+   Authentication Service (V5)", RFC 1510, September 1993.
+
+   [SRP] T. Wu, "The Secure Remote Password Protocol", In Proceedings of
+   the 1998 ISOC Network and Distributed System Security Symposium, San
+   Diego, CA, pp. 97-111.
+
+   [RFC2945] Wu, T, "The SRP Authentication and Key Exchange System",
+   RFC2945, September 2000.
+
+   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
+   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in
+   progress.
+
+Author's Address
+
+   Love Hornquist Astrand
+   Enheten for it och media
+   Stockholms universitet
+   S-106 91  STOCKHOLM
+   SWEDEN
+
+   EMail: lha@it.su.se
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved. ...
+
+
+
+
+
+
+
+Hornquist Astrand                                               [Page 5]
+
diff --git a/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-00.txt b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-00.txt
new file mode 100644
index 00000000000..f5d1c4c2e30
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-00.txt
@@ -0,0 +1,412 @@
+CAT Working Group                                              M. Swift 
+Internet Draft                                                Microsoft 
+Document: draft-swift-win2k-krb-referrals-00.txt           October 1999 
+Category: Informational                                                 
+ 
+ 
+           Generating KDC Referrals to locate Kerberos realms 
+ 
+ 
+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 draft documents a new method for a Kerberos Key Distribution 
+   Center (KDC) to respond to client requests for tickets as is used in 
+   Microsoft's Windows 2000 implementation of Kerberos. The KDC will 
+   handle requests for principals in other realms by returning either a 
+   referral error or a cross-realm TGT to another realm on the referral 
+   path. 
+    
+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. Introduction 
+    
+   The Kerberos TGS and AS protocols, as defined in RFC 1510 [3], 
+   require that client software be able to parse principal names into a 
+   realm and an account portion. However, if a site want to deploy a 
+   Kerberos realm infrastructure separately from its DNS 
+   infrastructure, Kerberos must be able to handle the case where the 
+   client software does not know what realm contains a given service or 
+   user principal name. In addition, the current protocol requires the 
+   client to know the hierarchy of realms by explicitly asking for a 
+
+  
+Swift                  Category - Informational                      1 
+
+                            KDC Referrals                October 1999 
+ 
+ 
+   referral to a specific realm rather than letting the KDC pick the 
+   next realm on the referral path. 
+    
+   To rectify these problems, this draft introduces three new kinds of 
+   KDC referrals: 
+    
+   1. AS ticket referrals, in which the client doesnÆt know which realm 
+     contains a user account. 
+   2. TGS ticket referrals, in which the client doesnÆt know which realm 
+     contains a server account. 
+   3. Cross realm shortcut referrals, in which the KDC chooses the next 
+     path on a referral chain 
+    
+4. Realm Organization Model 
+    
+   This draft assumes that the world of principals is arranged on 
+   multiple levels: the realm, the enterprise, and the world. A KDC may 
+   issue tickets for any principal in its realm or cross-realm tickets 
+   for realms with which it has a direct trust relationship. The KDC 
+   also has access to a trusted directory or name service that can 
+   resolve any name from within its enterprise into a realm. This 
+   trusted name service removes the need to use an untrusted DNS lookup 
+   for name resolution. 
+    
+   For example, consider the following configuration, where lines 
+   indicate trust relationships: 
+    
+                  MS.COM  
+                /        \ 
+               /          \ 
+        OFFICE.MS.COM    NT.MS.COM 
+    
+   In this configuration, all users in the MS.COM enterprise could have 
+   a principal name such as alice@ms.com, with the same realm portion. 
+   In addition, servers at MS.COM should be able to have DNS host names 
+   from any DNS domain independent of what Kerberos realm their 
+   principal resides in. 
+    
+5. Principal Names 
+    
+5.1 Service Principal Names 
+    
+   The standard Kerberos model in RFC 1510 [3] gives each Kerberos 
+   principal a single name. However, if a service is reachable by 
+   several addresses, it may be useful for a principal to have multiple 
+   names. Consider a service running on a multi-homed machine. Rather 
+   than requiring a separate principal and password for each name it 
+   exports, a single account with multiple names could be used. 
+    
+   Multiple names are also useful for services in that clients need not 
+   perform DNS lookups to resolve a host name into a full DNS address. 
+   Instead, the service may have a name for each of its supported host 
+   names, including its IP address. Nonetheless, it is still convenient 
+  
+Swift                  Category - Informational                      2 
+
+                            KDC Referrals                October 1999 
+ 
+ 
+   for the service to not have to be aware of all these names. Thus a 
+   new name may be added to DNS for a service by updating DNS and the 
+   KDC database without having to notify the service. In addition, it 
+   implies that these aliases are globally unique: they do not include 
+   a specifier dictating what domain contains the principal. Thus, an 
+   alias for a server is of the form "name/name/name" and may be 
+   transmitted as any name type. 
+    
+5.2 Client Principal Names 
+    
+   Similarly, a client account may also have multiple principal names. 
+   More useful, though, is a globally unique name that allows 
+   unification of email and security principal names. For example, all 
+   users at Microsoft may have a client principal name of the form 
+   "joe@MS.COM" even though the principals are contained in multiple 
+   realms. This global name is again an alias for the true client 
+   principal name, which is indicates what realm contains the 
+   principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 
+   "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 
+   This change requires a new client principal name type, as the AS-REQ 
+   message only contains a single realm field, and the realm portion of 
+   this name doesn't correspond to any realm security realm. Thus, the 
+   entire name "alice@MS.COM" is transmitted in the client name field 
+   of the AS-REQ message, with a name type of KRB-NT-ENTERPRISE-
+   PRINCIPAL. 
+    
+        #define KRB-NT-ENTERPRISE-PRINCIPAL     10 
+    
+5.3 Name Canonicalization 
+    
+   In order to support name aliases, the Kerberos client must 
+   explicitly request the name-canonicalization KDC option (bit 12) in 
+   the ticket flags for the TGS-REQ. This option is an indicator to the 
+   KDC that if it fails to find the name in the local database as a 
+   normal principal name, it should try to look the name up as an alias 
+   both locally and in a global directory. This flag indicates to the 
+   KDC that the client is prepared to receive a reply with a different 
+   client or server principal name than the request. Thus, the 
+   KDCOptions types is redefined as: 
+    
+        KDCOptions ::=   BIT STRING { 
+                          reserved(0), 
+                          forwardable(1), 
+                          forwarded(2), 
+                          proxiable(3), 
+                          proxy(4), 
+                          allow-postdate(5), 
+                          postdated(6), 
+                          unused7(7), 
+                          renewable(8), 
+                          unused9(9), 
+                          unused10(10), 
+                          unused11(11), 
+  
+Swift                  Category - Informational                      3 
+
+                            KDC Referrals                October 1999 
+ 
+ 
+                          name-canonicalize(12), 
+                          renewable-ok(27), 
+                          enc-tkt-in-skey(28), 
+                          renew(30), 
+                          validate(31) 
+         } 
+    
+6. Client Referrals 
+    
+   The simplest form of ticket referral is for a user requesting a 
+   ticket using an AS-REQ. In this case, the client machine will send 
+   the AS request to a convenient realm, probably either the realm of 
+   the client machine or the realm portion of the client name. In the 
+   case of the name Alice@MS.COM, the client may optimistically choose 
+   to send the request to MS.COM. The client will send the string 
+   "alice@MS.COM" in the client principal name field using the KRB-NT-
+   ENTERPRISE-PRINCIPAL name type. The KDC will try to lookup the name 
+   in its local account database. If the account is present, it will 
+   return a KDC reply structure with the appropriate ticket. If the 
+   account is not present and the name-canonicalize option is 
+   requested, it will try to lookup the entire name (Alice@MS.COM) in 
+   the global directory. If this lookup is unsuccessful, it will return 
+   the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, 
+   it will return an error KDC_ERR_WRONG_REALM (0x44) and in the error 
+   message, the cname and crealm field will contain the client name and 
+   the true realm of the client. If the KDC contains the account 
+   locally, it will return a normal ticket. The client name and realm 
+   portions of the ticket and KDC reply message will be the client's 
+   true name in the realm, not the globally unique name. 
+    
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 
+   new AS request to the realm specified by the crealm field of the 
+   error message. 
+ 
+7. Server Referrals 
+    
+   The server referral mechanism is a bit more complex than the client 
+   referral mechanism. The primary problem is that the KDC must return 
+   a referral ticket rather than an error message, so it must include 
+   in the TGS response information about what realm contains the 
+   service. This is done by returning information about the server name 
+   in the pre-auth data field of the KDC reply. 
+    
+   If the KDC resolves the server principal name into a principal in 
+   its realm, it may return a normal ticket. If the name-canonicalize 
+   bit is not set, then the KDC should only look up the name as a 
+   normal principal name. Otherwise, it should search all aliases as 
+   well. The server principal name in both the ticket and the KDC reply 
+   should be the true server principal name instead of one of the 
+   aliases. This prevents the application server from needing to know 
+   about all its aliases. 
+    
+
+  
+Swift                  Category - Informational                      4 
+
+                            KDC Referrals                October 1999 
+ 
+ 
+   If the KDC doesnÆt find the principal locally but is able to 
+   resolved it into a realm from the global directory, then it should 
+   return a cross-realm ticket granting ticket to the next hop on the 
+   trust path towards that realm. In this case, the KDC will return the 
+   server realm as a PA data type. The data itself is an ASN.1 encoded 
+   structure containing the server's realm, and if known, true 
+   principal name. The preauthentication data type is KRB5-PADATA-
+   SERVER-REFERRAL-INFO. 
+    
+        #define KRB5-PADATA-SERVER-REFERRAL-INFO        20 
+         
+        KERB-PA-SERV-REFERRAL   ::= SEQUENCE { 
+                referred-server-name[1]   KERB-PRINCIPAL-NAME OPTIONAL, 
+                referred-server-realm[0]  KERB-REALM 
+        } 
+    
+   The client may use the referred-server-name field to tell if it 
+   already has a ticket to the server in its ticket cache. 
+    
+   The client can use this information to request a chain of cross-
+   realm ticket granting tickets until it reaches this realm, and can 
+   then expect to receive a valid service ticket. 
+    
+8. Cross Realm Routing 
+    
+   The current Kerberos protocol requires the client libraries to 
+   explicitly request a cross-realm TGT for each pair of realms on a 
+   referral chain. As a result, the client machines need to be aware of 
+   the trust hierarchy and of any short-cut trusts (those that arenÆt 
+   parent-child trusts). This requires a lot of configuration on the 
+   client. Instead, the client should be able to request a TGT to the 
+   target realm from each realm on the route. The KDC will determine 
+   the best path for the client and return a cross-realm TGT. The 
+   client software has to be aware that a request for a cross-realm TGT 
+   may return a TGT for a realm different from the one requested. 
+    
+9. Security Considerations 
+ 
+   The original Kerberos specification stated that the server principal 
+   name in the KDC reply was the same as the server name in the 
+   request. These protocol changes break that assumption, so the client 
+   may be vulnerable to a denial of service attack by an attacker that 
+   replays replies from previous requests. It can verify that the 
+   request was one of its own by checking the client-address field or 
+   authtime field, though, so the damage is limited. 
+    
+10. References 
+    
+ 
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
+      9, RFC 2026, October 1996. 
+    
+ 
+  
+Swift                  Category - Informational                      5 
+
+                            KDC Referrals                October 1999 
+ 
+ 
+ 
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
+      Levels", BCP 14, RFC 2119, March 1997 
+    
+   3  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
+      Service (V5)", RFC 1510, September 1993 
+    
+    
+10. Author's Addresses 
+    
+   Michael Swift 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: mikesw@microsoft.com 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      6 
+
+                            KDC Referrals                October 1999 
+ 
+ 
+    
+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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      7 
+
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
new file mode 100644
index 00000000000..85d745684b2
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
new file mode 100644
index 00000000000..929fdfce227
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
@@ -0,0 +1,395 @@
+
+
+Kerberos Working Group                                         M. Swift 
+Internet Draft                                         University of WA 
+Document: draft-swift-win2k-krb-user2user-01.txt              J. Brezak 
+Category: Informational                                       Microsoft 
+                                                               P. Moore 
+                                                    Sandia National Labs
+                                                              March 2001 
+
+ 
+           User to User Kerberos Authentication using GSS-API 
+ 
+ 
+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 
+    
+   This draft documents a simple extension to the Kerberos GSS-API 
+   mechanism to support user to user authentication both in the case 
+   where the client application explicitly requests user to user 
+   authentication and when it does not know whether the server supports 
+   user to user authentication. 
+    
+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. Introduction 
+    
+   The Kerberos user to user authentication mechanism allows for a 
+   client application to connect to a service that is not in possession 
+   of a long term secret key. Instead, the session ticket from the 
+   KERB-AP-REQ is encrypted using the session key from the service's 
+   ticket granting ticket. According to RFC 1510 [3]: 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+        If the ENC-TKT-IN-SKEY option has been specified and an 
+        additional ticket has been included in the request, the KDC 
+        will decrypt the additional ticket using the key for the server 
+        to which the additional ticket was issued and verify that it is 
+        a ticket-granting ticket. If the 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 (This allows easy 
+        implementation of user-to-user authentication, which uses 
+        ticket-granting ticket session keys in lieu of secret server 
+        keys in situations where such secret keys could be easily 
+        compromised). 
+    
+   RFC2078 [5], in section 5.2, discusses a ôDouble-TGT K-5ö mechanism 
+   and scenario, but not in the detail required in order to implement 
+   the mechanism.  The RFC for the Kerberos V5 GSS-API mechanism at the 
+   time this draft was prepared, RFC 1964 [4] does not support user-to-
+   user authentication.  
+    
+   This draft provides details as to mechanism type, token identifiers, 
+   messages and message types sufficient to document an implementation 
+   of user-to-user authentication in Kerberos GSS-API.  It follows the 
+   scenario described in RFC2078. 
+    
+   The approach documented in this draft has been used to support user-
+   to-user authentication in the Microsoft Windows 2000 SSPI with the 
+   Kerberos V5 protocol, and in a patched Kerberos V5 implementation 
+   being used to support a computing grid at Sandia, Lawrence 
+   Livermore, and Los Alamos National Laboratories. 
+    
+4. User to User as a New Mechanism 
+    
+   A new mechanism OID may be used to establish a user-to-user session: 
+    
+        {iso(1) member-body(2) United States(840) mit(113554) 
+        infosys(1) gssapi(2) krb5(2) usertouser(3)}  
+    
+   In the case that the client application knows that the server 
+   requires user-to-user authentication, then the initial call to 
+   GSS_Init_Sec_Context will request this mechanism. This new mechanism 
+   is used with a token exchange that extends the conventional Kerberos 
+   GSS-API protocol by adding an additional round trip to request the 
+   TGT from the service. As with all Kerberos GSS-API messages, the 
+   following tokens are encapsulated in the GSS-API framing. The first 
+   token of the exchange will have an innerContextToken with a 2-octet 
+   TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 
+   Kerberos V5 message as follows: 
+    
+        KERB-TGT-REQUEST ::= SEQUENCE { 
+                pvno[0]                         INTEGER, 
+                msg-type[1]                     INTEGER, 
+                server-name[2]                  PrincipalName OPTIONAL, 
+                realm[3]                        Realm OPTIONAL 
+  
+Swift                  Category - Informational                      2 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+        } 
+         
+   The TGT request consists of four fields: 
+    
+        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
+                type is KRB_TGT_REQ (16). 
+         
+        server-name : this field optionally contains the name of the 
+                server. If the client application doesn't know the 
+                server name this can be left blank and the server 
+                application will pick the appropriate server 
+                credentials which may be the default credential. 
+         
+        realm : this field optionally contains the realm of the server. 
+                If the client application doesn't know the server realm 
+                this field can be left blank and the server application 
+                will pick the appropriate server credentials which may 
+                be the server's default realm. 
+         
+   The server name and realm are included to allow a server application 
+   to act for multiple principles in different realms and to choose 
+   which credentials to use. 
+    
+   The response to the KERB-TGT-REQUEST message will be a 
+   KERB_TGT_REPLY token which will have an innerContextToken with a 2-
+   octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 
+   Kerberos V5 message as follows: 
+    
+        KERB-TGT-REPLY ::= SEQUENCE { 
+                pvno[0]                         INTEGER, 
+                msg-type[1]                     INTEGER, 
+                ticket[2]                       Ticket 
+                } 
+    
+   The TGT reply contains the following fields: 
+    
+        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
+                type is KRB_TGT_REP (17) 
+         
+        ticket : contains the TGT for the service specified by the 
+                server name and realm passed by the client or the 
+                default service. 
+    
+   If the service does not possess a ticket granting ticket, it should 
+   return the error KRB_AP_ERR_NO_TGT (0x43). 
+    
+   If the server name and realm in the KERB-TGT-REQUEST message do not 
+   match the name of the service, then the service should return the 
+   error KRB_AP_ERR_NOT_US. 
+    
+   Following the exchange of the TGT request messages, the initiator 
+   requests a ticket to the service from the KDC using a KERB-TGS-REQ 
+   with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 
+  
+Swift                  Category - Informational                      3 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+   additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 
+   the rest of the authentication identical to the Kerberos GSS-API 
+   mechanism defined in RFC 1964 [4]. 
+    
+5. User-to-User when applied via KDC policy 
+    
+   Implementations MAY support the ability apply a policy on a user 
+   account such that the KDC will not allow conventional service ticket 
+   requests, and when presented with a KERB_TGS_REQ that does not 
+   contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 
+   respond with a KRB-ERROR with the msg-type 
+   KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 
+    
+   In this case, the client need not explicitly request user-to-user in 
+   order to get a user-to-user connection. Implementations may use this 
+   error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 
+   the next round uses the mechanism described in section 4.   
+    
+6. User to User when applied by server policy 
+    
+   In the case that the client application doesn't know that a service 
+   requires user-to-user authentication, and requests and receives a 
+   conventional KRB_AP_REP, the client will send the KRB_AP_REP 
+   request, and the server will respond with a KRB_ERROR token as 
+   described in RFC1964, with a msg-type of 
+   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
+   pass the TGT in the data field of this error message. In response to 
+   this error, the initiator sets flags and returns a 
+   GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
+   described in section 4. 
+    
+7. Security Considerations 
+ 
+   These extensions simply enable an existing Kerberos 5 authentication 
+   protocol so that it may be used from GSSAPI. 
+    
+   There is some risk in a server handing out its ticket-granting-
+   ticket to any client that requests it, in that it gives an attacker 
+   a piece of encrypted material to decrypt. However, the same material 
+   may be obtained from listening to any legitimate client connection. 
+    
+   It should be noted here that the exchange described in section 6 
+   requires that the KDC provide tickets for user accounts, which will 
+   contain known plaintext encrypted in the usersÆ private key. The 
+   risk associated with this is entirely mitigated where a KDC supports 
+   the KDC_MUST_USE_USER2USER feature, which allows a restriction on 
+   user accounts to ensure that all tickets for that account are 
+   encrypted in the TGT session key, and not the long term key of the 
+   user. 
+    
+8. References 
+    
+
+  
+Swift                  Category - Informational                      4 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+ 
+   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)",  RFC 1510. 
+    
+   4  J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 
+    
+   5  J. Linn, ôGeneric Security Service Application Program Interface, 
+      Version 2ö, RFC 2078 
+    
+9. Author's Addresses 
+    
+   Michael Swift 
+   University of Washington 
+   Seattle, Washington 
+   Email: mikesw@cs.washington.edu 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+   Patrick Moore 
+   Sandia National Laboratories 
+   PO Box 5800 Mail Stop 
+   Albuquerque, New Mexico 
+   Email: pcmoore@sandia.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      5 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+    
+ 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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      6 
+
+
+
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-02.txt b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-02.txt
new file mode 100644
index 00000000000..c0424bf7e75
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-02.txt
@@ -0,0 +1,354 @@
+
+
+Kerberos Working Group                                         M. Swift 
+Internet Draft                                         University of WA 
+Document: draft-swift-win2k-krb-user2user-02.txt              J. Brezak 
+Category: Informational                                       Microsoft 
+                                                               P. Moore 
+                                                    Sandia National Labs
+                                                              April 2001 
+ 
+
+           User to User Kerberos Authentication using GSS-API 
+ 
+ 
+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 
+    
+   This draft documents a simple extension to the Kerberos GSS-API 
+   mechanism to support user to user authentication both in the case 
+   where the client application explicitly requests user to user 
+   authentication and when it does not know whether the server supports 
+   user to user authentication. 
+    
+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. Introduction 
+    
+   The Kerberos user to user authentication mechanism allows for a 
+   client application to connect to a service that is not in possession 
+   of a long term secret key. Instead, the session ticket from the 
+   KERB-AP-REQ is encrypted using the session key from the service's 
+   ticket granting ticket. According to RFC 1510 [3]: 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+        If the ENC-TKT-IN-SKEY option has been specified and an 
+        additional ticket has been included in the request, the KDC 
+        will decrypt the additional ticket using the key for the server 
+        to which the additional ticket was issued and verify that it is 
+        a ticket-granting ticket. If the 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 (This allows easy 
+        implementation of user-to-user authentication, which uses 
+        ticket-granting ticket session keys in lieu of secret server 
+        keys in situations where such secret keys could be easily 
+        compromised). 
+    
+   RFC2078 [5], in section 5.2, discusses a "Double-TGT K-5" mechanism 
+   and scenario, but not in the detail required in order to implement 
+   the mechanism.  The RFC for the Kerberos V5 GSS-API mechanism at the 
+   time this draft was prepared, RFC 1964 [4] does not support user-to-
+   user authentication.  
+    
+   This draft provides details as to mechanism type, token identifiers, 
+   messages and message types sufficient to document an implementation 
+   of user-to-user authentication in Kerberos GSS-API.  It follows the 
+   scenario described in RFC2078. 
+    
+   The approach documented in this draft has been used to support user-
+   to-user authentication in the Microsoft Windows 2000 SSPI with the 
+   Kerberos V5 protocol, and in a patched Kerberos V5 implementation 
+   being used to support a computing grid at Sandia, Lawrence 
+   Livermore, and Los Alamos National Laboratories. 
+    
+4. User to User as a New Mechanism 
+    
+   A new mechanism OID may be used to establish a user-to-user session: 
+    
+        {iso(1) member-body(2) United States(840) mit(113554) 
+        infosys(1) gssapi(2) krb5(2) usertouser(3)}  
+    
+   In the case that the client application knows that the server 
+   requires user-to-user authentication, then the initial call to 
+   GSS_Init_Sec_Context will request this mechanism. This new mechanism 
+   is used with a token exchange that extends the conventional Kerberos 
+   GSS-API protocol by adding an additional round trip to request the 
+   TGT from the service. As with all Kerberos GSS-API messages, the 
+   following tokens are encapsulated in the GSS-API framing. The first 
+   token of the exchange will have an innerContextToken with a 2-octet 
+   TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 
+   Kerberos V5 message as follows: 
+    
+        KERB-TGT-REQUEST ::= SEQUENCE { 
+                pvno[0]                         INTEGER, 
+                msg-type[1]                     INTEGER, 
+                server-name[2]                  PrincipalName OPTIONAL, 
+                realm[3]                        Realm OPTIONAL 
+  
+Swift                  Category - Informational                      2 
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+        } 
+         
+   The TGT request consists of four fields: 
+    
+        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
+                type is KRB_TGT_REQ (16). 
+         
+        server-name : this field optionally contains the name of the 
+                server. If the client application doesn't know the 
+                server name this can be left blank and the server 
+                application will pick the appropriate server 
+                credentials which may be the default credential. 
+         
+        realm : this field optionally contains the realm of the server. 
+                If the client application doesn't know the server realm 
+                this field can be left blank and the server application 
+                will pick the appropriate server credentials which may 
+                be the server's default realm. 
+         
+   The server name and realm are included to allow a server application 
+   to act for multiple principles in different realms and to choose 
+   which credentials to use. 
+    
+   The response to the KERB-TGT-REQUEST message will be a 
+   KERB_TGT_REPLY token which will have an innerContextToken with a 2-
+   octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 
+   Kerberos V5 message as follows: 
+    
+        KERB-TGT-REPLY ::= SEQUENCE { 
+                pvno[0]                         INTEGER, 
+                msg-type[1]                     INTEGER, 
+                ticket[2]                       Ticket 
+                } 
+    
+   The TGT reply contains the following fields: 
+    
+        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
+                type is KRB_TGT_REP (17) 
+         
+        ticket : contains the TGT for the service specified by the 
+                server name and realm passed by the client or the 
+                default service. 
+    
+   If the service does not possess a ticket granting ticket, it should 
+   return the error KRB_AP_ERR_NO_TGT (0x43). 
+    
+   If the server name and realm in the KERB-TGT-REQUEST message do not 
+   match the name of the service, then the service should return the 
+   error KRB_AP_ERR_NOT_US. 
+    
+   Following the exchange of the TGT request messages, the initiator 
+   requests a ticket to the service from the KDC using a KERB-TGS-REQ 
+   with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 
+  
+Swift                  Category - Informational                      3 
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+   additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 
+   the rest of the authentication identical to the Kerberos GSS-API 
+   mechanism defined in RFC 1964 [4]. 
+    
+5. User-to-User when applied via KDC policy 
+    
+   Implementations MAY support the ability apply a policy on a user 
+   account such that the KDC will not allow conventional service ticket 
+   requests, and when presented with a KERB_TGS_REQ that does not 
+   contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 
+   respond with a KRB-ERROR with the msg-type 
+   KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 
+    
+   In this case, the client need not explicitly request user-to-user in 
+   order to get a user-to-user connection. Implementations may use this 
+   error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 
+   the next round uses the mechanism described in section 4.   
+    
+6. User to User when applied by server policy 
+    
+   In the case that the client application doesn't know that a service 
+   requires user-to-user authentication, and requests and receives a 
+   conventional KRB_AP_REP, the client will send the KRB_AP_REP 
+   request, and the server will respond with a KRB_ERROR token as 
+   described in RFC1964, with a msg-type of 
+   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
+   pass the TGT in the data field of this error message. In response to 
+   this error, the initiator sets flags and returns a 
+   GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
+   described in section 4. 
+    
+7. Security Considerations 
+ 
+   These extensions simply enable an existing Kerberos 5 authentication 
+   protocol so that it may be used from GSSAPI. 
+    
+   There is some risk in a server handing out its ticket-granting-
+   ticket to any client that requests it, in that it gives an attacker 
+   a piece of encrypted material to decrypt. However, the same material 
+   may be obtained from listening to any legitimate client connection. 
+    
+   It should be noted here that the exchange described in section 6 
+   requires that the KDC provide tickets for user accounts, which will 
+   contain known plaintext encrypted in the usersÆ private key. The 
+   risk associated with this is entirely mitigated where a KDC supports 
+   the KDC_MUST_USE_USER2USER feature, which allows a restriction on 
+   user accounts to ensure that all tickets for that account are 
+   encrypted in the TGT session key, and not the long term key of the 
+   user. 
+    
+8. References 
+    
+
+  
+Swift                  Category - Informational                      4 
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+ 
+   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)",  RFC 1510. 
+    
+   4  J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 
+    
+   5  J. Linn, "Generic Security Service Application Program Interface, 
+      Version 2", RFC 2078 
+    
+9. Author's Addresses 
+    
+   Michael Swift 
+   University of Washington 
+   Seattle, Washington 
+   Email: mikesw@cs.washington.edu 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+   Patrick Moore 
+   Sandia National Laboratories 
+   PO Box 5800 Mail Stop 
+   Albuquerque, New Mexico 
+   Email: pcmoore@sandia.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      5 
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+    
+ 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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      6 
+
diff --git a/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-03.txt b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-03.txt
new file mode 100644
index 00000000000..b4cd288b4a1
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-swift-win2k-krb-user2user-03.txt
@@ -0,0 +1,395 @@
+
+
+Kerberos Working Group                                         M. Swift 
+Internet Draft                                         University of WA 
+Document: draft-swift-win2k-krb-user2user-03.txt              J. Brezak 
+Category: Informational                                       Microsoft 
+                                                               P. Moore 
+                                                    Sandia National Labs
+                                                           October 2001 
+ 
+ 
+           User to User Kerberos Authentication using GSS-API 
+ 
+ 
+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 
+    
+   This draft documents a simple extension to the Kerberos GSS-API 
+   mechanism to support user to user authentication both in the case 
+   where the client application explicitly requests user to user 
+   authentication and when it does not know whether the server supports 
+   user to user authentication. 
+    
+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. Introduction 
+    
+   The Kerberos user to user authentication mechanism allows for a 
+   client application to connect to a service that is not in possession 
+   of a long term secret key. Instead, the session ticket from the 
+   KERB-AP-REQ is encrypted using the session key from the service's 
+   ticket granting ticket. According to RFC 1510 [3]: 
+    
+
+  
+Swift                  Category - Informational                      1 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+        If the ENC-TKT-IN-SKEY option has been specified and an 
+        additional ticket has been included in the request, the KDC 
+        will decrypt the additional ticket using the key for the server 
+        to which the additional ticket was issued and verify that it is 
+        a ticket-granting ticket. If the 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 (This allows easy 
+        implementation of user-to-user authentication, which uses 
+        ticket-granting ticket session keys in lieu of secret server 
+        keys in situations where such secret keys could be easily 
+        compromised). 
+    
+   RFC2078 [5], in section 5.2, discusses a "Double-TGT K-5" mechanism 
+   and scenario, but not in the detail required in order to implement 
+   the mechanism.  The RFC for the Kerberos V5 GSS-API mechanism at the 
+   time this draft was prepared, RFC 1964 [4] does not support user-to-
+   user authentication.  
+    
+   This draft provides details as to mechanism type, token identifiers, 
+   messages and message types sufficient to document an implementation 
+   of user-to-user authentication in Kerberos GSS-API.  It follows the 
+   scenario described in RFC2078. 
+    
+   The approach documented in this draft has been used to support user-
+   to-user authentication in the Microsoft Windows 2000 SSPI with the 
+   Kerberos V5 protocol, and in a patched Kerberos V5 implementation 
+   being used to support a computing grid at Sandia, Lawrence 
+   Livermore, and Los Alamos National Laboratories. 
+    
+4. User to User as a New Mechanism 
+    
+   A new mechanism OID may be used to establish a user-to-user session: 
+    
+        {iso(1) member-body(2) United States(840) mit(113554) 
+        infosys(1) gssapi(2) krb5(2) usertouser(3)}  
+    
+   In the case that the client application knows that the server 
+   requires user-to-user authentication, then the initial call to 
+   GSS_Init_Sec_Context will request this mechanism. This new mechanism 
+   is used with a token exchange that extends the conventional Kerberos 
+   GSS-API protocol by adding an additional round trip to request the 
+   TGT from the service. As with all Kerberos GSS-API messages, the 
+   following tokens are encapsulated in the GSS-API framing. The first 
+   token of the exchange will have an innerContextToken with a 2-octet 
+   TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 
+   Kerberos V5 message as follows: 
+    
+        KERB-TGT-REQUEST ::= SEQUENCE { 
+                pvno[0]                         INTEGER, 
+                msg-type[1]                     INTEGER, 
+                server-name[2]                  PrincipalName OPTIONAL, 
+                realm[3]                        Realm OPTIONAL 
+  
+Swift                  Category - Informational                      2 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+        } 
+         
+   The TGT request consists of four fields: 
+    
+        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
+                type is KRB_TGT_REQ (16). 
+         
+        server-name : this field optionally contains the name of the 
+                server. If the client application doesn't know the 
+                server name this can be left blank and the server 
+                application will pick the appropriate server 
+                credentials which may be the default credential. 
+         
+        realm : this field optionally contains the realm of the server. 
+                If the client application doesn't know the server realm 
+                this field can be left blank and the server application 
+                will pick the appropriate server credentials which may 
+                be the server's default realm. 
+         
+   The server name and realm are included to allow a server application 
+   to act for multiple principles in different realms and to choose 
+   which credentials to use. 
+    
+   The response to the KERB-TGT-REQUEST message will be a 
+   KERB_TGT_REPLY token which will have an innerContextToken with a 2-
+   octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 
+   Kerberos V5 message as follows: 
+    
+        KERB-TGT-REPLY ::= SEQUENCE { 
+                pvno[0]                         INTEGER, 
+                msg-type[1]                     INTEGER, 
+                ticket[2]                       Ticket 
+                } 
+    
+   The TGT reply contains the following fields: 
+    
+        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
+                type is KRB_TGT_REP (17) 
+         
+        ticket : contains the TGT for the service specified by the 
+                server name and realm passed by the client or the 
+                default service. 
+    
+   If the service does not possess a ticket granting ticket, it should 
+   return the error KRB_AP_ERR_NO_TGT (0x43). 
+    
+   If the server name and realm in the KERB-TGT-REQUEST message do not 
+   match the name of the service, then the service should return the 
+   error KRB_AP_ERR_NOT_US. 
+    
+   Following the exchange of the TGT request messages, the initiator 
+   requests a ticket to the service from the KDC using a KERB-TGS-REQ 
+   with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 
+  
+Swift                  Category - Informational                      3 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+   additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 
+   the rest of the authentication identical to the Kerberos GSS-API 
+   mechanism defined in RFC 1964 [4]. 
+    
+5. User-to-User when applied via KDC policy 
+    
+   Implementations MAY support the ability apply a policy on a user 
+   account such that the KDC will not allow conventional service ticket 
+   requests, and when presented with a KERB_TGS_REQ that does not 
+   contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 
+   respond with a KRB-ERROR with the msg-type 
+   KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 
+    
+   In this case, the client need not explicitly request user-to-user in 
+   order to get a user-to-user connection. Implementations may use this 
+   error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 
+   the next round uses the mechanism described in section 4.   
+    
+6. User to User when applied by server policy 
+    
+   In the case that the client application doesn't know that a service 
+   requires user-to-user authentication, and requests and receives a 
+   conventional KRB_AP_REP, the client will send the KRB_AP_REP 
+   request, and the server will respond with a KRB_ERROR token as 
+   described in RFC1964, with a msg-type of 
+   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
+   pass the TGT in the data field of this error message. In response to 
+   this error, the initiator sets flags and returns a 
+   GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
+   described in section 4. 
+    
+7. Security Considerations 
+ 
+   These extensions simply enable an existing Kerberos 5 authentication 
+   protocol so that it may be used from GSSAPI. 
+    
+   There is some risk in a server handing out its ticket-granting-
+   ticket to any client that requests it, in that it gives an attacker 
+   a piece of encrypted material to decrypt. However, the same material 
+   may be obtained from listening to any legitimate client connection. 
+    
+   It should be noted here that the exchange described in section 6 
+   requires that the KDC provide tickets for user accounts, which will 
+   contain known plaintext encrypted in the usersÆ private key. The 
+   risk associated with this is entirely mitigated where a KDC supports 
+   the KDC_MUST_USE_USER2USER feature, which allows a restriction on 
+   user accounts to ensure that all tickets for that account are 
+   encrypted in the TGT session key, and not the long term key of the 
+   user. 
+    
+8. References 
+    
+
+  
+Swift                  Category - Informational                      4 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+ 
+   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)",  RFC 1510. 
+    
+   4  J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 
+    
+   5  J. Linn, "Generic Security Service Application Program Interface, 
+      Version 2", RFC 2078 
+    
+9. Author's Addresses 
+    
+   Michael Swift 
+   University of Washington 
+   Seattle, Washington 
+   Email: mikesw@cs.washington.edu 
+    
+   John Brezak 
+   Microsoft 
+   One Microsoft Way 
+   Redmond, Washington 
+   Email: jbrezak@microsoft.com 
+    
+   Patrick Moore 
+   Sandia National Laboratories 
+   PO Box 5800 Mail Stop 
+   Albuquerque, New Mexico 
+   Email: pcmoore@sandia.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      5 
+
+
+
+
+
+
+
+
+                 User to User Kerberos Authentication     October 1999 
+ 
+ 
+    
+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." 
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Swift                  Category - Informational                      6 
+
+
+
+
+
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/third_party/heimdal/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
new file mode 100644
index 00000000000..68c170b499e
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/third_party/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
new file mode 100644
index 00000000000..b89108a53be
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt
new file mode 100644
index 00000000000..e9611e395bf
--- /dev/null
+++ b/third_party/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/third_party/heimdal/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt
new file mode 100644
index 00000000000..f310a02363a
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt
@@ -0,0 +1,557 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+
+            GSS-API Domain-Based Service Names and Name Type
+            draft-williams-gssapi-domain-based-names-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document describes domainname-based service principal names and
+   the corresponding name type for the GSS-API.
+
+
+   Domain-based service names are similar to host-based service names,
+   but using a domain name (not necessarily and Internat domain name)
+   instead of or in addition to a hostname.  The primary purpose of
+   domain-based service names is to provide a way to name clustered
+   services after the domain which they service, thereby allowing their
+   clients to authorize the service's servers based on authentication of
+   their names.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+Table of Contents
+
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   3. Name Type OID and Symbolic Name  . . . . . . . . . . . . . . . . 5
+   4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . . 6
+   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 8
+   7. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
+      Intellectual Property and Copyright Statements . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+2.  Introduction
+
+
+   The use of hostbased principal names for domain-wide services
+   presents the problem of how to distinguish between an instance of a
+   hostbased service that is authorized to respond for a domain and one
+   that isn't.
+
+
+   Consider LDAP.  LDAP with SASL and the Kerberos V GSS-API mechanism
+   uses a hostbased principal with a service name of "ldap", a
+   reasonable approach, provided there is only one logical LDAP
+   directory in a Kerberos realm's domain, and that all ldap servers in
+   that realm serve that one LDAP directory.  If there were other LDAP
+   directories, then clients could not tell which service is authorized
+   to serve which directory, not without assuming a secure method for
+   finding LDAP servers (e.g., DNSSEC).  This is a significant, and
+   oft-unstated restriction on users of LDAP.
+
+
+   Domain based names can eliminate this problem by allowing LDAP
+   service names to indicate which LDAP directory they are authorized to
+   serve.
+
+
+   A domain-based name consists of three required elements:
+   o  a service name
+   o  a domain name
+   o  a hostname
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+3.  Name Type OID and Symbolic Name
+
+
+   The new name type has an OID of
+      [NOTE:  OID assignment to be made with IANA.]
+
+
+      {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6)
+      gss-domain-based(5)}
+
+
+   The recommended symbolic name for this GSS-API name type is
+   "GSS_C_NT_DOMAINBASED_SERVICE".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+4.  Query and Display Syntaxes
+
+
+   There is a single syntax that applies to both query and display forms
+   of domain-based names.  (We ignore string profile matters here as the
+   GSS-API's, and its mechanisms' use of character strings are out of
+   scope for this document.)
+
+
+   The syntax is:
+      domain-based-name :=
+         | <service> '@' <domain> '@' <hostname>
+         | <service> '@@' <hostname>
+
+
+   The domain name element is only optional in the query syntax of
+   domain-based names.
+
+
+   A missing domain name is always to be added by the GSS-API mechanisms
+   during name canonicalization, using whatever default values are
+   appropriate for the mechanisms.
+
+
+   Therefore the display form of domain-based MNs (see [RFC2743]) MUST
+   include all three elements of domain-based names.
+
+
+   Note that for Internet domain names the trailing '.' is not and MUST
+   NOT be included in the domain name (or hostname) parts of the display
+   form GSS-API domain-based MNs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+5.  Examples
+
+
+   o  ldap@@ds1.example.tld
+   o  ldap@example.tld@ds1.example.tld
+
+
+   o  kadmin@@kdc1.example.tld
+   o  kadmin@example.tld@kdc1.example.tld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+6.  Security Considerations
+
+
+   Use of GSS-API domain-based names may not be negotiable by some
+   GSS-API mechanisms, and some acceptors may not support GSS-API
+   domain-based names.  In such cases initiators are left to fallback on
+   the use of hostbased names, in which case the initiators MUST also
+   verify that the acceptor's hostbased name is authorized to provide
+   the given service for the domain that the initiator had wanted.
+
+
+   The above security consideration also applies to all GSS-API
+   initiators who lack support for domain-based service names.
+
+
+7  Normative
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Author's Address
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+Internet-Draft           GSS Domain Based Names                July 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
new file mode 100644
index 00000000000..6184b649173
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
@@ -0,0 +1,617 @@
+
+
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+     Namespace Considerations and Registries for GSS-API Extensions
+              draft-williams-gssapi-extensions-iana-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes the ways in which the GSS-API may be extended
+   and directs the creation of IANA registries for GSS-API namespaces
+   that may be affected by any extensions.
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+Table of Contents
+
+   1. Conventions used in this document  . . . . . . . . . . . . . .   3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3. Extensions to the GSS-API  . . . . . . . . . . . . . . . . . .   5
+   4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . .   6
+   5. Language Binding-Specific GSS-API Namespaces . . . . . . . . .   7
+   6. Extension-Specific GSS-API Namespaces  . . . . . . . . . . . .   8
+   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .   9
+   8. Security Considerations  . . . . . . . . . . . . . . . . . . .  10
+   9. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  10
+      Intellectual Property and Copyright Statements . . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+2.  Introduction
+
+   There is a need for generic and mechanism-specific extensions to the
+   Generic Security Services Application Programming Interface
+   (GSS-API).  As such extensions are designed and standardized, both at
+   the IETF and elsewhere, there is a non-trivial risk of namespace
+   pollution and conflicts.  To avoid this we set out guidelines for
+   extending the GSS-API and create IANA registries of GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+3.  Extensions to the GSS-API
+
+   Extensions to the GSS-API can be categorized as follows:
+   o  Generic
+   o  Implementation-specific
+   o  Mechanism-specific
+   o  Language binding-specific
+   o  Any combination of two or all three of the last three
+
+   Extensions to the GSS-API may be purely semantic, without effect on
+   the GSS-API's namespaces.  Or they may introduce new functions,
+   constants, types, etc...; these clearly affect the GSS-API
+   namespaces.
+
+   Extensions that affect the GSS-API namespaces should be registered
+   with the IANA< along with their specific effects on the GSS-API
+   namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+4.  Generic GSS-API Namespaces
+
+   All the function, constant and type names, as well as all the
+   constant values specified in the base GSS-API specification for the
+   basic generic GSS-API namespace.
+
+   The generic GSS-API namespaces are:
+   o  Type names
+   o  Function names
+   o  Constant names for each type
+   o  Constant values for each type
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+5.  Language Binding-Specific GSS-API Namespaces
+
+   <Add text; discuss header, module, library, class namespaces and
+   whatever else comes up that is language-specific and appropriate for
+   registration with the IANA.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+6.  Extension-Specific GSS-API Namespaces
+
+   Extensions to the GSS-API may create additional namespaces.  IANA
+   registries SHOULD be created for any such new namespaces.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+7.  IANA Considerations
+
+   The following registries should be established upon publication of
+   this document as an RFC:
+   o  GSS-API Type Name Registry
+   o  GSS-API Function Name Registry
+   o  GSS-API Constant Name Registry
+   o  GSS-API Constant Value Registry
+   o  GSS-API Class/Header/Library/Module Name Registry
+
+   Entries in these registries should consist of:
+   o  Namespace name
+   o  Symbol name or prefix, OR value or value range.
+   o  [optional] Reference to normative reference for the registration.
+   o  [optional] Programming language
+   o  [optional] Entry sub-type (e.g., "header name")
+   o  [optional] Mechanism OID(s) and/or OID prefix(es) associated with
+      the entry
+   o  [optional] Magic
+   o  [optional] Expert Review (body or people who reviewed the
+      registration)
+   o  [optional] Description (in English)
+
+   <Add text on guidelines for IANA consideration of registration
+   applications, particularly with respect to entries w/o normative
+   references, "magic" entries (e.g., special values of 'time' types
+   which indicate something other than absolute or relative time, such
+   as GSS_C_INDEFINITE), expert review requirements for registrations w/
+   o normative references, etc....>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+8.  Security Considerations
+
+   This document has no security considerations.
+
+9  Normative
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 10]
+
+Internet-Draft      GSS-API Namespace Considerations           July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004               [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-williams-gssapi-prf-00.txt b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-prf-00.txt
new file mode 100644
index 00000000000..097ce851504
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-prf-00.txt
@@ -0,0 +1,498 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                    S. Hartman
+                                                                     MIT
+                                                               July 2004
+
+
+
+                  A PRF API extension for the GSS-API
+                    draft-williams-gssapi-prf-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   GSS-API for keying application protocols given an established GSS-API
+   security context.
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 1]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+Table of Contents
+
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
+   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   5.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  6
+       Intellectual Property and Copyright Statements . . . . . . . .  8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 2]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 3]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+2.  Introduction
+
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API for authentication, but not for
+   transport security (for whatever reasons), and since the GSS-API does
+   not provide a method for obtaining keying material from established
+   security contexts such applications cannot make effective use of the
+   GSS-API.
+
+
+   To address this need we define a PRF extension to the GSS-API.
+
+
+   At this point EAP may be the primary consumer of this extension.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 4]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+3.  GSS_Pseudo_random()
+
+
+   Inputs:
+
+
+   o  context CONTEXT handle,
+   o  prf_in OCTET STRING
+
+
+   Outputs:
+
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  prf_out OCTET STRING
+
+
+   Return major_status codes:
+   o  GSS_S_COMPLETE indicates no error.
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+   o  GSS_S_FAILURE indicates failure or lack of support; the minor
+      status code may provide additional information.
+
+
+   This function applies the context's mechanism's keyed PRF function to
+   the input data (prf_in), keyed with key material associated with the
+   given security context and outputs the result (prf_out).
+
+
+3.1  C-Bindings
+
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32                  *minor_status,
+     gss_ctx_id_t                       context,
+     const gss_buffer_t         prf_in,
+     gss_buffer_t            prf_out
+   );
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 5]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+4.  Security Considerations
+
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   session keys and should preserve the forward security properties of
+   the mechanisms' key exchanges.
+
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.  Cryptographic hash functions which do not provide strong
+   collision resistance should not be used, except through HMAC.
+
+
+   GSS mechanisms' PRF functions may output fewer octets than the
+   application may need, therefore GSS-API applications that use
+   GSS_Pseudo_random() may require a "PRF+" construction based on
+   GSS_Pseudo_random().
+
+
+   [Question:  Should GSS_Pseudo_random() have an input roughly
+   corresponding to the "key usage" used for key derivation in Kerberos
+   V?]
+
+
+5  Normative
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Authors' Addresses
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+   Sam Hartman
+   Massachussets Institute of Technology
+   ...
+   ..., MA  ...
+   US
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 6]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 7]
+Internet-Draft      A PRF Extension for the GSS-API            July 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 8] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt
new file mode 100644
index 00000000000..b14696e42f4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt
@@ -0,0 +1,466 @@
+
+INTERNET-DRAFT                                          Nicolas Williams
+                                                        Sun Microsystems
+                                                          September 2003
+
+
+
+           GSS-APIv2 Extension for Storing Delegated Credentials
+             <draft-williams-gssapi-store-deleg-creds-01.txt>
+
+
+
+
+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.
+
+   This draft expires on January 30th, 2004. Please send comments to
+   the authors.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines a new function for the GSS-API which allows
+   applications to store delegated (and other) credentials in the
+   implicit GSS-API credential store.  This is needed for GSS-API
+   applications to use delegated credentials as they would use other
+   credentials.
+
+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 [RFC2119].
+
+N. Williams							[Page 1]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+
+Table of Contents
+
+   1  Introduction
+   2  GSS_Store_cred()
+   2.1  C-Bindings for GSS_Store_cred()
+   3  Examples
+   4  Security Considerations
+   5  References
+   5.1  Normative References
+   6  Author's Address
+
+1  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   [NOTE:  This assumption can be seen in sections 1.1.1.2 and 1.1.1.3
+           of RFC2743 as well as in section 3.5 of RFC2744.
+
+	   Note to the RFC editor: please remove this note before
+	   publication.]
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change - which is precisely the raison d'etre of credential
+   delegation.  But the GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+
+N. Williams							[Page 2]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   replace the process image obliterates the delegated credentials
+   handle.  
+
+   [NOTE:  Delegated credentials are practically unusable on Unix
+	   implementations of Secure Shell (SSHv2) servers, except where
+	   there are extended interfaces for dealing with delegated
+	   credentials, which to date have always been
+	   mechanism-specific interfaces.
+
+	   Note to the RFC editor: please remove this note before
+	   publication.]
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred() a primitive is needed which allows storing of
+   credentials in the implicit credential store.  This primitive we call
+   "GSS_Store_cred()."
+
+   [NOTE:  Simon Wilkinson's patches to OpenSSH for GSS-API sport a
+           simple internal interface for storing delegated credentials
+	   in users' credential store - this internal interface wraps
+	   around two mechanism specific internal interfaces for storing
+	   GSI and Kerberos V credentials.
+
+	   Simon's code shows that:
+
+	   a) a generic method is needed for making delegated
+	      credentials available for indirect use through acquisition
+	      (as opposed to just using the actual delegated cred
+	      handle)
+
+           b) it is possible to design and implement such a generic
+	      method for storing delegated credentials.
+
+	   No new concepts are added to the GSS-API by this document,
+	   but the implicit existence of a credential store in the
+	   background is made explicit, and a deficiency of the GSS-API
+	   is corrected.
+
+	   Compare this to the GGF proposal which includes a credential
+	   import/export facility (like the existing context import/
+	   export facility), but with an option to export as
+	   "environment variables," meaning something like "store these
+	   input creds in some new credential store and then tell me the
+	   name of that credential store through some output environment
+	   variable"[*].  Thus, the GGF export-cred-to-environment-
+	   variable proposal adds knowledge of environment variables to
+	   the GSS-API, which this proposal does not.  Note that a
+	   credential import/export facility along the lines of the
+	   existing context import/export facility may be useful and
+	   complements the GSS_Store_cred() interface; in fact, with
+	   GSS_Store_cred() it should be possible to remove the
+	   'option_req' input parameter and export-to-env-var features
+
+N. Williams							[Page 3]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+	   of the GGF's GSS_Export_cred() credential export proposal.
+
+	   [*]  For the exact semantics see section 1.2, paragraph 6 of
+	        draft-engert-ggf-gss-extensions-00.txt
+
+	   One side effect of GSS_Store_cred(), however, is that it
+	   allows applications that can switch their current credential
+	   store to move credentials from one store to the other; this
+	   is a direct result of making it possible to store a
+	   credential given a GSS-API credential handle.  Perhaps there
+	   should be some text allowing, or recommending, that
+	   implementations of GSS_Store_cred() allow only the storage of
+	   credentials acquired through credential delegation.
+
+	   Note to the RFC editor: please remove this note before
+	   publication.]
+
+2  GSS_Store_cred()
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+   -- NOT be GSS_C_NO_CREDENTIAL
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID
+   -- then store all the elements of the input_cred_handle, otherwise
+   -- store only the element of the corresponding mechanism
+
+   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
+   -- same principal in the credential store
+
+   o  default_cred BOOLEAN -- if TRUE make the stored credential
+   -- available as the default credential (for acquisition with
+   -- GSS_C_NO_NAME as the desired name or for use as
+   -- GSS_C_NO_CREDENTIAL)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+   -- mechanism OIDs for which credential elements were successfully
+   -- stored
+
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+   -- kind of credential was stored (useful when the cred_usage input
+   -- parameter is set to INITIATE-AND-ACCEPT)
+
+
+N. Williams							[Page 4]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+   stored.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials
+   had expired or expired before they could be stored.
+
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+   available.
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+   credential could not be stored because a credential for the same
+   principal exists in the current credential store and the
+   overwrite_cred input argument was FALSE.
+
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+   for some other reason.  The minor status code may provide more
+   information if a non-GSS_C_NULL_OID desired_mech_element was given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument, in which case the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor or both usages of the input credential may be
+   stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   Finally, if the current credential store has no default credential
+   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
+   if the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential will be
+   available for acquisition with GSS_C_NO_NAME as the desired name
+   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
+   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
+   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+N. Williams							[Page 5]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+
+2.1  C-Bindings for GSS_Store_cred()
+
+   The C-bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+   OM_uint32 gss_store_cred(
+      OM_uint32         *minor_status,
+      gss_cred_id_t     input_cred,
+      gss_cred_usage_t  cred_usage,
+      const gss_OID     desired_mech,
+      OM_uint32         overwrite_cred,
+      OM_uint32         default_cred,
+      gss_OID_set       *elements_stored,
+      gss_cred_usage_t  *cred_usage_stored)
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+3  Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+   /*
+    * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE, an
+    * initiator name (hereafter, "src_name") and a delegated credential
+    * handle (hereafter "deleg_cred").>
+    *
+    * <"requested_username" is a username derived from the initiator
+    * name or explicitly requested by the initiator application.>
+    */
+   ...
+
+   if (authorize_gss_client(src_name, requested_username)) {
+      /*
+       * For Unix-type platforms this may mean calling setuid() and it
+       * may or may not also mean setting/unsetting such environment
+       * variables as KRB5CCNAME and what not.
+       */
+      if (change_user_context(requested_username))
+         (void) gss_store_creds(&minor_status, deleg_cred,
+				GSS_C_INITIATE, actual_mech,
+				0, 1, NULL, NULL);
+      }
+      else ...
+   }
+   else ...
+
+4  Security Considerations
+
+
+N. Williams							[Page 6]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API
+   C-Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+5  References
+
+5.1  Normative References
+
+   [RFC2026]
+      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
+      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
+      Practice.
+
+   [RFC2119]
+      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
+      Indicate Requirement Levels," March 1997, Status: Best Current
+      Practice.
+
+   [RFC2743]
+      J. Linn, RFC2743: "Generic Security Service Application Program
+      Interface Version 2, Update 1," January 2000, Status: Proposed
+      Standard.
+
+   [RFC2744]
+      J. Wray, RFC2744: "Generic Security Service API Version 2 :
+      C-bindings," January 2000, Status: Proposed Standard.
+
+6  Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX 78727
+   Email: Nicolas.Williams@sun.com
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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
+
+N. Williams							[Page 7]
+
+DRAFT		GSS_Store_cred()			Expires March 2004
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+N. Williams							[Page 8]
diff --git a/third_party/heimdal/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
new file mode 100644
index 00000000000..c7d879b042c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
@@ -0,0 +1,1200 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+
+                         Guide to the GSS-APIv3
+                draft-williams-gssapi-v3-guide-to-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
+   documents describes the extensions being proposed, the resons,
+   possible future directions, and portability, IANA and security
+   considerations.  This document does not define any protocol or
+   interface and is purely informational.
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+Table of Contents
+
+
+   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  5
+   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  6
+   5.  Security Context Extensibility Extensions  . . . . . . . . . .  7
+   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  8
+   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . .  9
+   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 11
+   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
+   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 13
+   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 14
+   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 15
+   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 16
+   15. Portability Considerations . . . . . . . . . . . . . . . . . . 17
+   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
+       Intellectual Property and Copyright Statements . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+2.  Introduction
+
+
+   [NOTE: the references section is current fairly empty; the various
+   KITTEN WG work items will be added to this I-D in a subsequent
+   revision.]
+
+
+   Since the advent of the GSS-APIv2 it has come to be used in a number
+   of Internet (and other) protocols and a number of implementations
+   exist.  In that time implementors and protocol designers have come to
+   understand both, the GSS-API's strengths, and its shortcommings; we
+   believe now that a number of extensions to the GSS-API are needed.
+   Here these proposed extensions, forming what we may call the GSS-API
+   version 3, are described at a high-level.;
+
+
+   Some of these extensions are intended to facilitate further
+   extensions, so that further major revisions to the GSS-API may not be
+   necessary.  Others are intended to fill voids in the the GSS-APIv2.
+
+
+   The extensions being proposed are:
+      A pseudo-mechanism OID for the GSS-API itself
+      Mechanism attribute inquiry facilities
+      Security context extensibility extensions
+      Credential extensibility extensions
+      Credential export/import
+      GSS_Store_cred(), for making delegated credentials available for
+      acquisition
+      Pseudo-mechanism stacking
+      Naming extensions, to facilitate authorization by identifiers
+      other than names
+      Additional name types, specifically domain-based naming
+      A pseudo-random function interface
+      Channel bindings specifications
+      Semantic extensions relating to thread- and/or fork-safety
+      [Have I missed anything?  I have a feeling I have.  Re-keying?]
+      ...
+
+
+   Additionally, because we foresee future minor extensions, including,
+   specifically, extensions which may impact the various namespaces
+   associated with APIs (symbol names, constant values, class names,
+   etc...) we also propose the establishment of IANA registries for
+   these namespaces.
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+3.  A Pseudo-Mechanism OID for the GSS-API Itself
+
+
+   A mechanism OID is assigned to identify and refer to the GSS-API
+   iself.  This is necessary to enable the use of extended inquiry
+   interfaces to inquire about features of a GSS-API implementation
+   specifically, apart from actual mechanisms.
+
+
+   But also, this OID is needed for better error handling, so that minor
+   status codes produced in generic contexts that lack a mechanism OID
+   can be distinguished from minor status codes for a "default"
+   mechanism and properly displayed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+4.  Mechanism Attribute Inquiry Facilities
+
+
+   In the course of designing a pseudo-mechanism stacking facility, as
+   well as while considering the impact of all of these extensions on
+   portability, a need for interfaces through which to discover or
+   inquire by features provided by GSS-API mechanisms was discovered.
+
+
+   The proposed mechanism attribute inquiry interfaces consist of:
+      GSS_Inquire_mech_attrs_for_mech()
+      GSS_Indicate_mechs_by_mech_attrs()
+      GSS_Display_mech_attr()
+
+
+   These extensions facilitate portability by allowing GSS-APIv3
+   applications to discover the features provided by a given
+   implementation of the GSS-API or any mechanisms.  These extensions
+   are also useful in facilitating stackable pseudo-mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+5.  Security Context Extensibility Extensions
+
+
+   In order to facilitate future security context options we introduce a
+   GSS_Create_sec_context() interface that creates a security context
+   object, for use with extensions and with GSS_Init_sec_context(),
+   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
+   security contexts are in a non-established state until they are
+   established through the use of GSS_Init_sec_context() or
+   GSS_Accept_sec_context().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+6.  Credential Extensibility Extensions
+
+
+   In order to facilitate future extensions to GSS credentials we
+   introduce a GSS_Create_credential(), similar to
+   GSS_Create_sec_context(), interface that creates an "empty"
+   credential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 8]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+7.  Credential Export/Import
+
+
+   To allow for passing of credentials between different "session
+   contexts," between different hosts, or for storage of post-dated
+   credentials, we introduce a credential export/import facility, much
+   like the security context export/import facility of the GSS-APIv2.
+
+
+   Together with credential extensibility and other extensions this
+   facility may allow for:
+      Credential delegation at any time
+      Post-dated credentials, and storage of the such for subsequent
+      use.
+      ...?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 9]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+8.  GSS_Store_cred()
+
+
+   This extension fills a void in the GSS-APIv2 where delegated
+   credentials could not be used except in the context of the same
+   process that received them.  With this extension acceptor
+   applications can now make delegated credentials available for use,
+   with GSS_Acquire_cred() et.  al., in other process contexts.
+
+
+   [Manipulation of "credential stores" is (may be?) out of scope for
+   this document.]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 10]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+9.  Pseudo-Mechanism Stacking
+
+
+   A number of pseudo-mechanisms are being proposed which are designed
+   to "stack" atop other mechanisms.  The possiblities are many,
+   including: a compression mechanism, a perfect forward security
+   mechanism, an many others.
+
+
+   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
+   (SPNEGO) available.  With this proposal the mechanism taxonomy is
+   quite expanded:
+      Concrete mechanisms (e.g., the Kerberos V mechanism)
+      Composite mechanisms (a concrete mechanism composed with one or
+      more stackable pseudo-mechanisms)
+      Stackable pseudo-mechanisms
+      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
+
+
+   Although composed mechanisms may be made available for use by
+   GSS-APIv2 applications without any further extensions, use of
+   stackable pseudo-mechanisms can complicate mechanism negotiation;
+   additionally, discovery of mechanisms appropriate for use in one or
+   another context would require hard-coding information about them in
+   GSS-APIv2 applications.  Extensions to the GSS-APIv2 could facilitate
+   use of composite.
+
+
+   The mechanism attribute inquiry facilities, together with the
+   forllowing additional interfaces, provide for a complete interface to
+   mechanism composition and for managing the complexity of mechanism
+   negotiation:
+      GSS_Compose_oid()
+      GSS_Decompose_oid()
+      GSS_Release_oid()
+      GSS_Indicate_negotiable_mechs()
+      GSS_Negotiate_mechs()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 11]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+10.  Naming Extensions
+
+
+   Some applications make use of exported names, as produced by
+   GSS_Export_name(), to create/manage/evaluate access control lists; we
+   call this name-based authorization.
+
+
+   Exported names typically encode names that are meant for display to
+   humans, not internal identifiers.
+
+
+   In practice this creates a number of problems.  E.g., the referential
+   integrity of such access control lists is hard to maintain as
+   principals are added, removed, renamed or old principal names reused.
+
+
+   Additionally, some mechanisms may lack a notion of a "canonical" name
+   for some or all of their principals.  Such mechanisms cannot be used
+   by applications that rely on name-based authorization.
+
+
+   <Describe the proposed extensions in this area.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 12]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+11.  Additional Name Types
+
+
+   <Decribe domain-based names and the need for them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 13]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+12.  GSS_Pseudo_random()
+
+
+   <Decribe GSS_Pseudo_random() and the need for it.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 14]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+13.  Channel Bindings Specifications
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 15]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+14.  Semantic and Miscallaneous Extensions
+
+
+   The GSS-APIv2 specifications say nothing about the thread-safety,
+   much less the fork-safety, of the GSS-API.  Thread-safety and
+   fork-safety are, after all, platform- and/or language-specific
+   matters.  But as support for multi-threading spreads the matter of
+   thread-safety cannot be avoided.  The matter of fork-safety is
+   specific to platforms that provide a "fork()" function, or similar.
+
+
+   <describe the GSS-APIv3's thread-safety requirements>
+
+
+   <reference the portability considerations section>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 16]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+15.  Portability Considerations
+
+
+   The potential for additional generic, mechanism-specific, language
+   binding-specific and, most importantly, semantic extensions to the
+   GSS-APIv3 may create application portability problems.  The mechanism
+   attribute inquiry facilities of the GSS-APIv3 and the
+   pseudo-mechanism OID for the GSS-API itself double as a run-time
+   facility for discovery of feature availability.  Run-time feature
+   discovery facilities, in turn, can be used at application build-time
+   as well by building small applications to display the available
+   features.
+
+
+   <...>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 17]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+16.  IANA Considerations
+
+
+   <Describe the namespace issues associated with future minor
+   extensions to the GSS-APIv3 and the IANA registries to be created to
+   cope with them.>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 18]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+17.  Security Considerations
+
+
+   <...>
+
+
+18  Normative
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Author's Address
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004               [Page 19]
+Internet-Draft           Guide to the GSS-APIv3                July 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004               [Page 20] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt b/third_party/heimdal/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt
new file mode 100644
index 00000000000..51f154e0a64
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt
@@ -0,0 +1,432 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                     July 2004
+
+
+
+   GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS
+                               Mechanism
+          draft-williams-krb5-gssapi-domain-based-names-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document describes the mapping of GSS-API domainname-based
+   service principal names onto Kerberos V principal names.
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 1]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+Table of Contents
+
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Domain-Based Names for the Kerberos V GSS-API Mechanism  . . . . 4
+   3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+   4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   5. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Intellectual Property and Copyright Statements . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 2]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 3]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+2.  Domain-Based Names for the Kerberos V GSS-API Mechanism
+
+
+   In accordance with [DOMAIN-BASED-NAMES] this document provides the
+   mechanism-specific details needed to implement GSS-API [RFC2743]
+   domain-based service names with the Kerberos V GSS-API mechanism
+   [RFC1964].
+
+
+   GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
+   names as follows:
+   o  the <service> name becomes the first (0th) component of the
+      Kerberos V principal name;
+   o  the <domain> name becomes the second component of the Kerberos V
+      principal name; if the <domain> name is missing in the GSS name
+      then a default domain name MUST be substituted (though no
+      mechanism for determining this default is given here; this is an
+      implementation-specific detail);
+   o  the <hostname>, if present, becomes the third component of the
+      Kerberos V principal name;
+   o  the realm of the resulting principal name is that which
+      corresponds to the domain name, treated as a hostname, or, if none
+      can be determined in this way, then the realm of the hostname, if
+      present, and, finally, if that is not possible, the default realm
+      for the GSS-API caller.
+
+
+   The same name canonicalization considerations and methods as used
+   elsewhere in the Kerberos V GSS-API mechanism [RFC1964] and Kerberos
+   V [RFC1510] in general apply here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 4]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+3.  Examples
+
+
+   o  "ldap@@ds1.example.tld" may map to "ldap/example.tld/
+      ds1.example.tld@EXAMPLE.TLD"
+   o  "ldap@example.tld@ds1.example.tld" may map to "ldap/example.tld/
+      ds1.example.tld@EXAMPLE.TLD"
+
+
+   o  "kadmin@@kdc1.example.tld" may map to "kadmin/example.tld/
+      kdc1.example.tld@EXAMPLE.TLD"
+   o  "kadmin@example.tld@kdc1.example.tld" may map to "kadmin/
+      example.tld/kdc1.example.tld@EXAMPLE.TLD"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 5]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+4.  Security Considerations
+
+
+   See [DOMAIN-BASED-NAMES].
+
+
+5  Normative
+
+
+   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510, September 1993.
+
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+
+Author's Address
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams               Expires December 30, 2004                [Page 6]
+Internet-Draft        Kerberos Domain Based Names              July 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams               Expires December 30, 2004                [Page 7] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt b/third_party/heimdal/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
new file mode 100644
index 00000000000..ca588cd735c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
@@ -0,0 +1,373 @@
+NETWORK WORKING GROUP                                        N. Williams
+Internet-Draft                                                       Sun
+Expires: December 30, 2004                                    S. Hartman
+                                                                     MIT
+                                                               July 2004
+
+
+
+               A PRF for the Kerberos V GSS-API Mechanism
+                 draft-williams-krb5-gssapi-prf-00.txt
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on December 30, 2004.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V GSS-API mechanism, based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 1]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+Table of Contents
+
+
+   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
+   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
+   4. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
+      Intellectual Property and Copyright Statements . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 2]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+1.  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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 3]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+2.  Introduction
+
+
+   The GSS-API PRF function for the Kerberos V mechanism shall be the
+   output of the enctype's PRF function keyed with the negotiated
+   session key of the security context (e.g., the acceptor's subkey) and
+   key usage X (TBD).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 4]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+3.  Security Considerations
+
+
+   Kerberos V enctypes' PRF functions should use a key derived from
+   contexts' session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.  Cryptographic hash functions which do not provide strong
+   collision resistance should not be used, except through HMAC.
+
+
+4  Normative
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+Authors' Addresses
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+   Sam Hartman
+   Massachussets Institute of Technology
+   ...
+   ..., MA  ...
+   US
+
+
+   EMail: hartmans@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 5]
+Internet-Draft       A PRF for the Kerberos V Mech             July 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Williams & Hartman     Expires December 30, 2004                [Page 6] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-00.txt b/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-00.txt
new file mode 100644
index 00000000000..dd902349590
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-00.txt
@@ -0,0 +1,3585 @@
+
+
+INTERNET-DRAFT                                                    Tom Yu
+draft-yu-krb-wg-kerberos-extensions-00.txt                           MIT
+Expires: 09 August 2004                                 09 February 2004
+
+        The Kerberos Network Authentication Service (Version 5)
+
+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
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes version 5 of the Kerberos network
+   authentication protocol.  It describes changes to the protocol which
+   allow for extensions to be made to the protocol without creating
+   interoperability problems.
+
+   [ This document is a VERY rough draft.  Many sections are not yet
+   fully filled out.  The main purpose is to illustrate the beginnings
+   of a new document structure as a starting point. ]
+
+Key Words for Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in RFC 2119.
+
+
+Yu                          Expires: Aug 2004                   [Page 1]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+Table of Contents
+
+   Status of This Memo .......................................  1
+   Copyright Notice ..........................................  1
+   Abstract ..................................................  1
+   Key Words for Requirements ................................  1
+   Table of Contents .........................................  2
+   1.  Introduction ..........................................  4
+   1.1.  Kerberos Protocol Overview ..........................  4
+   1.2.  Overview of Document ................................  5
+   2.  Extensibility .........................................  5
+   3.  Criticality ...........................................  6
+   4.  Use of ASN.1 ..........................................  6
+   4.1.  Module Header .......................................  6
+   4.2.  Top-Level Type ......................................  7
+   4.3.  Parameterized Types .................................  7
+   4.4.  Constraints .........................................  8
+   4.5.  New Types ...........................................  8
+   5.  Basic Types ...........................................  8
+   5.1.  Constrained Integer Types ...........................  8
+   5.2.  KerberosTime ........................................  9
+   5.3.  KerberosString ......................................  9
+   6.  Principals ............................................ 10
+   6.1.  Name Types .......................................... 10
+   6.2.  Principal Name Reuse ................................ 11
+   7.  Types Relating to Encryption .......................... 11
+   7.1.  EncryptedData ....................................... 11
+   7.2.  EncryptionKey ....................................... 13
+   7.3.  Checksums ........................................... 13
+   7.3.1.  ChecksumOf ........................................ 14
+   7.3.2.  Signed ............................................ 15
+   8.  Tickets ............................................... 15
+   8.1.  Timestamps .......................................... 16
+   8.2.  Ticket Flags ........................................ 16
+   8.2.1.  Flags Relating to Initial Ticket Acquisition ...... 17
+   8.2.2.  Invalid Tickets ................................... 17
+   8.2.3.  OK as Delegate .................................... 18
+   8.3.  Renewable Tickets ................................... 18
+   8.4.  Postdated Tickets ................................... 19
+   8.5.  Proxiable and Proxy Tickets ......................... 20
+   8.6.  Forwardable Tickets ................................. 21
+   8.7.  Transited Realms .................................... 21
+   8.8.  Authorization Data .................................. 21
+   8.9.  Encrypted Part of Ticket ............................ 21
+   8.10.  Cleartext Part of Ticket ........................... 22
+   9.  Credential Acquisition ................................ 23
+   9.1.  KDC-REQ ............................................. 24
+   9.2.  PA-DATA ............................................. 26
+   9.3.  KDC-REQ Processing .................................. 26
+   9.3.1.  Handling Replays .................................. 26
+   9.3.2.  Request Validation ................................ 26
+
+Yu                          Expires: Aug 2004                   [Page 2]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   9.3.2.1.  AS-REQ Authentication ........................... 27
+   9.3.2.2.  TGS-REQ Authentication .......................... 27
+   9.3.2.3.  Principal Validation ............................ 27
+   9.3.3.  Timestamp Handling ................................ 27
+   9.3.3.1.  AS-REQ Timestamp Processing ..................... 28
+   9.3.3.2.  TGS-REQ Timestamp Processing .................... 29
+   9.3.4.  Key Selection ..................................... 29
+   9.3.5.  Checking For Revoked Tickets ...................... 30
+   9.4.  Reply Validation .................................... 30
+   10.  Application Authentication ........................... 30
+   11.  Session Key Use ...................................... 30
+   11.1.  KRB-SAFE ........................................... 30
+   11.2.  KRB-PRIV ........................................... 30
+   11.3.  KRB-CRED ........................................... 30
+   12.  Security Considerations .............................. 30
+   12.1.  Time Synchronization ............................... 30
+   12.2.  Replays ............................................ 30
+   12.3.  Principal Name Reuse ............................... 30
+   12.4.  Password Guessing .................................. 30
+   12.5.  Forward Secrecy .................................... 30
+   12.6.  Authorization ...................................... 31
+   12.7.  Login Authentication ............................... 31
+   Appendices ................................................ 31
+   A.  ASN.1 Module (Normative) .............................. 31
+   B.  Kerberos and Character Encodings (Informative) ........ 60
+   C.  Kerberos History (Informative) ........................ 62
+   Normative References ...................................... 62
+   Informative References .................................... 63
+   Acknowledgments ........................................... 63
+   Author's Address .......................................... 63
+   Full Copyright Statement .................................. 63
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                   [Page 3]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+1.  Introduction
+
+   The Kerberos network authentication protocol is a trusted third-party
+   protocol utilizing symmetric-key cryptography.  It assumes that all
+   communications between parties in the protocol may be arbitrarily
+   tampered with or monitored, and that the security of the overall
+   system depends only on the effectiveness of the cryptographic
+   techniques and the secrecy of the keys used.  The protocol
+   authenticates an application client's identity to an application
+   server, and likewise authenticates the application server's identity
+   to the application client.  These assurances are made possible by the
+   client and the server sharing secrets with the trusted third party:
+   the Kerberos server, also known as the Key Distribution Center (KDC).
+   In addition, the protocol establishes an ephemeral shared secret (the
+   session key) between the client and the server, allowing the
+   protection of further communications between them.
+
+1.1.  Kerberos Protocol Overview
+
+   Kerberos comprises three main sub-protocols: credentials acquisition,
+   application authentication, and session key usage.  A client acquires
+   credentials by asking the for KDC a credential for a service; the KDC
+   issues the credential, consisting of a ticket and a session key.  The
+   ticket, containing the client's identity, timestamps, expiration
+   time, and a session key, is a encrypted in a key known to the
+   application server.  The KDC encrypts the credential using a key
+   known to the client, and transmits the credential to the client.
+
+   There are two means of requesting credentials: the Authentication
+   Service (AS) exchange, and the Ticket-Granting Service (TGS)
+   exchange.  The AS exchange typically involves a client using a
+   password-derived key to decrypt the response.  The TGS exchange
+   involves the KDC behaving as an application, which the client
+   authenticates to using a Ticket-Granting Ticket (TGT).  The client
+   usually obtains the TGT by using the AS exchange.
+
+   Application authentication consists of the client establishing the
+   session key with the application server by transmitting the ticket to
+   the application server, along with an authenticator.  The
+   authenticator contains a timestamp and additional data encrypted
+   using the ticket's session key.  The application server decrypts the
+   ticket, extracting the session key.  The application server then uses
+   the session key to decrypt the authenticator.  Upon successful
+   decryption of the authenticator, the application server knows that
+   the data in the authenticator were sent by the client named in the
+   associated ticket.  Additionally, since authenticators expire more
+   quickly than tickets, the application server has some assurance that
+   the transaction is not a replay.  The application server may send an
+   encrypted acknowledgment to the client, verifying its identity to the
+   client.
+
+
+Yu                          Expires: Aug 2004                   [Page 4]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   Once application authentication has occurred, the client and server
+   may use the established session key to protect further traffic.  This
+   protection may consist of protection of integrity only, or of
+   protection of confidentiality and integrity.  Additional measures
+   exist for a client to forward credentials to a server.
+
+   The entire scheme depends on loosely synchronized clocks.
+   Synchronization of the clock on the KDC with the application server
+   clock allows the application server to accurately determine whether a
+   credential is expired.  Likewise, synchronization of the clock on the
+   client with the application server clock prevents replay attacks
+   utilizing the same credential.  Careful design of the application
+   protocol may allow replay prevention without requiring client-server
+   clock synchronization.
+
+   Following the establishment of a session key between the application
+   client and the application server, the Kerberos protocol provides
+   messages that use the session key to protect the integrity or
+   confidentiality of communications between the client and the server.
+   Additionally, the client may forward credentials to the application
+   server.
+
+   The credentials acquisition protocol takes place over specific,
+   defined transports (UDP and TCP).  Application protocols define which
+   transport to use for the session key establishment protocol and for
+   messages using the session key; the application may choose to perform
+   its own encapsulation of the Kerberos messages, for example.
+
+1.2.  Overview of Document
+
+   The remainder of this document begins by describing the general
+   frameworks for protocol extensibility, including whether to interpret
+   unknown extensions as critical.  It then defines the protocol
+   messages and exchanges.
+
+   The definition of the Kerberos protocol uses Abstract Syntax Notation
+   One (ASN.1) [X680], which specifies notation for describing the
+   abstract content of protocol messages.  This document defines a
+   number of base types using ASN.1; these base types subsequently
+   appear in multiple types which define actual protocol messages.
+   Definitions of principal names and of tickets, which are central to
+   the protocol, also appear preceding the protocol message definitions.
+
+2.  Extensibility
+
+   As originally defined in [RFC1510], the Kerberos protocol does not
+   readily allow for backwards-compatible extensions to the protocol.
+   Various proposals to extend the Kerberos protocol have appeared since
+   RFC 1510, many of them creating problems for backwards compatibility.
+   This document adopts the technique of creating new extensible types
+   which encode to messages which are very similar to RFC 1510 messages
+
+Yu                          Expires: Aug 2004                   [Page 5]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   on the wire.  This similarity allows implementors to use shared code
+   paths for encoding and decoding both new and old messages.
+
+   The protocol defined in RFC 1510 already contains some elements
+   allowing for limited backwards-compatible extensions to the protocol.
+   Most of these elements consist of "typed holes"; these are octet
+   strings whose contents have types defined by an assigned number.
+   This document adds a number of typed holes to types which have
+   previously lacked typed holes.  This document also describes
+   procedures for the IETF to use the extensibility model of ASN.1 make
+   further backwards-compatible extensions of the Kerberos protocol, if
+   typed holes prove inadequate for some desired extension.
+
+3.  Criticality
+
+   In general, implementations SHOULD treat unknown extension, flags,
+   etc. as non-critical; i.e., they should ignore them when they do not
+   understand them.  Exceptions are clearly marked.  An implementation
+   SHOULD NOT reject a request merely because it does not understand
+   some element of the request.  As a related consequence,
+   implementations SHOULD handle talking to other implementations which
+   do not implement some requested options.  This may require designers
+   of extensions or options to provide means detect whether extensions
+   or options are rejected, or whether such extensions or options are
+   merely not understood, or (perhaps maliciously) deleted in transit.
+
+4.  Use of ASN.1
+
+   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
+   Even though ASN.1 theoretically allows the description of protocol
+   messages to be independent of the encoding rules used to encode the
+   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
+   the semantics of the notation, such as whether tags carry any
+   semantic content to the application, may cause the use of other ASN.1
+   encoding rules to be problematic.
+
+   Implementors not using existing ASN.1 compilers or support libraries
+   are cautioned to thoroughly read and understand the actual ASN.1
+   specification to ensure correct implementation behavior.  There is
+   more complexity in the notation than is immediately obvious, and some
+   tutorials and guides to ASN.1 are misleading or erroneous.
+
+4.1.  Module Header
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                   [Page 6]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- Rest of definitions here
+
+      END
+
+   This specifies that the tagging context for the module will be
+   explicit and that automatic tagging is not done.
+
+   Some other publications [RFC1510] [RFC1964] erroneously specify an
+   object identifier (OID) having an incorrect value of "5" for the
+   "dod" component of the OID.  In the case of RFC 1964, use of the
+   "correct" OID value would result in a change in the wire protocol;
+   therefore, the RFC 1964 OID remains unchanged for now.
+
+4.2.  Top-Level Type
+
+   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
+   Data Units or PDUs) which an application may directly reference.
+   Applications SHOULD NOT transmit any types other than those which are
+   alternatives of the KRB-PDU CHOICE.
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+4.3.  Parameterized Types
+
+   This document uses ASN.1 parameterized types [X683] to make
+   definitions of types more readable.  For some types, some or all of
+
+Yu                          Expires: Aug 2004                   [Page 7]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   the parameters are advisory, i.e., they are not encoded in any form
+   for transmission in a protocol message.  These advisory parameters
+   can describe implementation behavior associated with the type.
+
+4.4.  Constraints
+
+   This document uses ASN.1 constraints, including the
+   "UserDefinedConstraint" syntax [X682].  Some constraints can be
+   handled automatically by tools that can parse them.  Uses of the
+   "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will
+   typically need to have behavior manually coded; these uses provide a
+   formalized way of conveying intended implementation behavior.
+
+4.5.  New Types
+
+   This document defines a number of new ASN.1 types.  The names of
+   these types will typically have a suffix like "Ext", indicating that
+   the types are intended to support extensibility.  Types original to
+   RFC 1510 have been renamed to have a suffix like "1510".  The "Ext"
+   and "1510" types often contain a number of common elements; these
+   common elements have a suffix like "Common".  The "1510" types have
+   various ASN.1 constraints applied to them; the constraints limit the
+   possible values of the "1510" types to those permitted by RFC 1510 or
+   by [KCLAR].  The "Ext" types may have different constraints,
+   typically to force string values to be sent as UTF-8.
+
+5.  Basic Types
+
+   Certain ASN.1 types in Kerberos appear in numerous other types.
+
+5.1.  Constrained Integer Types
+
+   In [RFC1510], many types contained references to the unconstrained
+   INTEGER type.  Since an unconstrained INTEGER may contain any
+   possible abstract integer value, most of the unconstrained references
+   to INTEGER in [RFC1510] have been constrained to 32 bits or smaller.
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+   The "Int32" type often contains an assigned number identifying the
+   type of a protocol element.  Unless otherwise stated, non-negative
+   values are registered, and negative values are available for local
+   use.
+
+
+
+Yu                          Expires: Aug 2004                   [Page 8]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+      -- sequence numbers
+      --
+      -- We may want to increase this to 2**64 and define a UInt64
+      -- type.
+      SeqNum          ::= UInt32
+
+
+      -- nonces
+      --
+      -- Likewise, we may want to make this UInt64.
+      Nonce           ::= UInt32
+
+   While these types have different abstract types from their
+   equivalents in [RFC1510], their DER encodings remain identical.
+
+5.2.  KerberosTime
+
+      -- must not have fractional seconds
+      KerberosTime    ::= GeneralizedTime
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes. A
+   KerberosTime value MUST NOT include any fractional portions of the
+   seconds.  As required by the DER, it further MUST NOT include any
+   separators, and it specifies the UTC time zone (Z). Example: The only
+   valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is "19851106210627Z".
+
+5.3.  KerberosString
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+   The KerberosString type is used for strings in various places in the
+   Kerberos protocol.  For compatibility with RFC 1510, GeneralString
+   values constrained to IA5String (US-ASCII) are permitted in messages
+   exchanged with RFC 1510 implementations.  The new protocol messages
+   contain strings encoded as UTF-8.  KerberosString values are present
+   in principal names and in error messages.  Control characters SHOULD
+   NOT be used in principal names, and used with caution in error
+   messages.
+
+
+
+Yu                          Expires: Aug 2004                   [Page 9]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   For detailed background regarding the history of character string use
+   in Kerberos, as well as discussion of some compatibility issues, see
+   Appendix B.
+
+6.  Principals
+
+   Principals are participants in the Kerberos protocol.  A "realm"
+   consists of principals in one administrative domain, served by one
+   KDC (or one replicated set of KDCs).  Each principal name has an
+   arbitrary number of components, though typical principal names will
+   only have one or two components.  A principal name is meant to be
+   readable by and meaningful to humans, especially in a realm lacking a
+   centrally adminstered authorization infrastructure.
+
+      Realm           ::= KerberosString
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is not recommended.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+
+   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
+   character with the code 0 (the US-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.
+
+   name-type
+        Specifies the type of name that follows.  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).
+
+   name-string
+        Encodes a sequence of components that form a name, each
+        component encoded as a KerberosString.  Taken together, a
+        PrincipalName and a Realm form a principal identifier.  Most
+        PrincipalNames will have only a few components (typically one or
+        two).
+
+6.1.  Name Types
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 10]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+6.2.  Principal Name Reuse
+
+   Realm administrators SHOULD use extreme caution when considering
+   reusing a principal name.  A service administrator might explicitly
+   enter principal names into a local access control list (ACL) for the
+   service.  If such local ACLs exist independently of a centrally
+   administered authorization infrastructure, realm administrators
+   SHOULD NOT reuse principal names until confirming that all extant ACL
+   entries referencing that principal name have been updated.  Failure
+   to perform this check can result in a security vulnerability, as a
+   new principal can inadvertently inherit unauthorized privileges upon
+   receiving a reused principal name.  An organization whose Kerberos-
+   authenticated services all use a centrally-adminstered authorization
+   infrastructure may not need to take these precautions regarding
+   principal name reuse.
+
+7.  Types Relating to Encryption
+
+   Many Kerberos protocol messages contain encryptions of various data
+   types.  Kerberos protocol messages also contain checksums
+   (signatures) of various types.
+
+7.1.  EncryptedData
+
+   The "EncryptedData" type contains the encryption of another data
+   type.  The recipient uses fields within EncryptedData to determine
+   which key to use for decryption.
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 11]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
+      SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+
+   EType
+        Integer type for assigned numbers for encryption algorithms.
+        Defined in [KCRYPTO]
+
+   KeyUsage
+        Integer type for assigned numbers for key usages.  Key usage
+        values are inputs to the encryption and decryption functions
+        described in [KCRYPTO].
+
+   Type
+        Advisory parameter indicating the ASN.1 type whose DER encoding
+        is the plaintext encrypted into the EncryptedData.
+
+   Keys
+        Advisory parameter indicating which key to use to perform the
+        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
+        detailed description of the containing message will indicate
+        which key to use under which conditions.
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 12]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+           -- KeyToUse identifies which key is to be used to encrypt or
+           -- sign a given value.
+           --
+           -- Values of KeyToUse are never actually transmitted over the
+           -- wire, or even used directly by the implementation in any
+           -- way, as key usages are; it exists primarily to identify
+           -- which key gets used for what purpose.  Thus, the specific
+           -- numeric values associated with this type are irrelevant.
+           KeyToUse        ::= ENUMERATED {
+               -- unspecified
+               key-unspecified,
+               -- server long term key
+               key-server,
+               -- client long term key
+               key-client,
+               -- key selected by KDC for encryption of a KDC-REP
+               key-kdc-rep,
+               -- session key from ticket
+               key-session,
+               -- subsession key negotiated via AP-REQ/AP-REP
+               key-subsession,
+               ...
+           }
+
+
+   KeyUsages
+        Advisory parameter indicating which "KeyUsage" value is used to
+        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
+        the detailed description of the containing message will indicate
+        which key usage to use under which conditions.
+
+7.2.  EncryptionKey
+
+   The "EncryptionKey" type holds an encryption key.
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+   keytype
+        This "EType" identifies the encryption algorithm, described in
+        [KCRYPTO].
+
+   keyvalue
+        Contains the actual key.
+
+7.3.  Checksums
+
+
+
+Yu                          Expires: Aug 2004                  [Page 13]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   Several types contain checksums (actually signatures) of data.
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum { KeyToUse:Keys, KeyUsage:KeyUsages } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+   CksumType
+        Integer type for assigned numbers for signature algorithms.
+        Defined in [KCRYPTO]
+
+   Keys
+        As in EncryptedData
+
+   KeyUsages
+        As in EncryptedData
+
+   cksumtype
+        Signature algorithm used to produce the signature.
+
+   checksum
+        The actual checksum.
+
+7.3.1.  ChecksumOf
+
+   ChecksumOf is like "Checksum", but specifies which type is signed.
+
+      -- a Checksum that must contain the checksum of a particular type
+      ChecksumOf { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
+      Checksum { Keys, KeyUsages }
+      (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 14]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   Type
+        Indicates the ASN.1 type whose DER encoding is signed.
+
+7.3.2.  Signed
+
+   Signed is like "ChecksumOf", but contains an actual instance of the
+   type being signed in addition to the signature.
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed { InnerType, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
+      SEQUENCE {
+          cksum       [0] ChecksumOf
+                              { InnerType, Keys, KeyUsages } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+8.  Tickets
+
+   The important fields of a ticket are in the encrypted part.  The
+   components in common between the RFC 1510 and the extensible versions
+   are
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+   crealm
+        This field contains the client's realm.
+
+   cname
+        This field contains the client's name.
+
+   caddr
+        This field lists the network addresses (if absent, all addresses
+        are permitted) from which the ticket is valid.
+
+
+
+Yu                          Expires: Aug 2004                  [Page 15]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   Descriptions of the other fields appear in the following sections.
+
+8.1.  Timestamps
+
+   Three of the ticket timestamps may be requested from the KDC.  The
+   timestamps may differ from those requested, depending on site policy.
+
+   authtime
+        The time at which the client authenticated, as recorded by the
+        KDC.
+
+   starttime
+        The earliest time when the ticket is valid.  If not present, the
+        ticket is valid starting at the authtime.  This is requested as
+        the "from" field of KDC-REQ-BODY-COMMON.
+
+   endtime
+        This time is requested in the "till" field of KDC-REQ-BODY-
+        COMMON.  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 time is requested in the "rtime" field of KDC-REQ-BODY-
+        COMMON.  It 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.
+
+8.2.  Ticket Flags
+
+   A number of flags may be set in the ticket, further defining some of
+   its capabilities.  Some of these flags map to flags in a KDC request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 16]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+8.2.1.  Flags Relating to Initial Ticket Acquisition
+
+   [ adapted KCLAR 2.1. ]
+
+   Several flags indicate the details of how the initial ticket was
+   acquired.
+
+   initial
+        The "initial" flag indicates that a ticket was issued using the
+        AS protocol, rather than issued based on a ticket-granting
+        ticket.  Application servers (e.g., a password-changing program)
+        requiring a client's definite knowledge of its secret keycan
+        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.
+
+   pre-authent
+        The "pre-authent" flag indicates that some sort of pre-
+        authentication was used during the AS exchange.
+
+   hw-authent
+        The "hw-authent" flag indicates that some sort of hardware-based
+        pre-authentication occurred during the AS exchange.
+
+   Both the "pre-authent" and the "hw-authent" flags may be present with
+   or without the "initial" flag; such tickets with the "initial" flag
+   clear are ones which are derived from initial tickets with the "pre-
+   authent" or "hw-authent" flags set.
+
+
+Yu                          Expires: Aug 2004                  [Page 17]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+8.2.2.  Invalid Tickets
+
+   [ KCLAR 2.2. ]
+
+   The "invalid" flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets which have this flag set.  A postdated
+   ticket will 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 9.3.5).
+
+8.2.3.  OK as Delegate
+
+   [ KCLAR 2.8. ]
+
+   For some applications a client may need to delegate authority to a
+   server to act on its behalf in contacting other services.  This
+   requires that the client forward credentials to an intermediate
+   server.  The ability for a client to obtain a service ticket to a
+   server conveys no information to the client about whether the server
+   should be trusted to accept delegated credentials.  The "ok-as-
+   delegate" flag provides a way for a KDC to communicate local realm
+   policy to a client regarding whether an intermediate server is
+   trusted to accept such credentials.
+
+   The copy of the ticket flags visible to the client may have the "ok-
+   as-delegate" flag set to indicate to the client that the server
+   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.  It is acceptable 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.
+
+8.3.  Renewable Tickets
+
+   [ adapted KCLAR 2.3. ]
+
+   Renewable tickets can be used to mitigate the consequences of ticket
+   theft.  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
+
+Yu                          Expires: Aug 2004                  [Page 18]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   secret key, an even greater risk.
+
+   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.  It can usually be ignored by application
+   servers.  However, some particularly careful application servers MAY
+   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 clear by default,
+   but a client can request it be set by setting the "renewable" option
+   in the 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.
+
+8.4.  Postdated Tickets
+
+   [ KCLAR 2.4. ]
+
+   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 TGS. It can be ignored by application servers.  This flag MUST be
+   set in a ticket-granting ticket in order for the KDC 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 AS-REQ [?also TGS-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
+
+Yu                          Expires: Aug 2004                  [Page 19]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   the postdating in the 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 for
+   validation before use.
+
+8.5.  Proxiable and Proxy Tickets
+
+   [ KCLAR 2.5. ]
+
+   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, users wishing to delegate their
+   identity in a form usable for all purposes 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 may contain a set of network addresses from which they are
+   valid. When granting a proxy, the client MUST specify the new network
+   address from which the proxy is to be used, or indicate that the
+
+Yu                          Expires: Aug 2004                  [Page 20]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   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.
+
+8.6.  Forwardable Tickets
+
+   [ KCLAR 2.6. ]
+
+8.7.  Transited Realms
+
+   [ KCLAR 2.7., plus new stuff ]
+
+8.8.  Authorization Data
+
+8.9.  Encrypted Part of Ticket
+
+   The complete definition of the encrypted part is
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+      EncTicketPart1510 ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (WITH COMPONENTS { ia5 PRESENT }),
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          })
+      })
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 21]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      EncTicketPartExt ::= EncTicketPartCommon
+      (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (WITH COMPONENTS { ia5 ABSENT }),
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          }),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- explicitly constrain authorization-data to be non-empty
+          -- if present
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+8.10.  Cleartext Part of Ticket
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 22]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      Ticket1510 ::= SEQUENCE {
+          -- "COMPONENTS OF" drops the extension marker from
+          -- TicketCommon
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (WITH COMPONENTS { ia5 PRESENT }),
+          sname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          }),
+          extensions ABSENT
+      })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon
+      (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (WITH COMPONENTS { ia5 ABSENT }),
+          sname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          })
+      })
+
+
+      TEType                  ::= Int32
+
+      TICKETEXTENSION         ::= TYPEDHOLE { TEType }
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TICKETEXTENSION.&id
+                                      ({TicketExtension-Set}),
+          te-data             [1] OCTET STRING (TICKETEXTENSION.&Type)
+                                      ({TicketExtension-Set}{@te-type})
+      }
+
+      -- no mandatory ticket extensions currently
+      TicketExtensionSet TICKETEXTENSION ::= { ... }
+
+
+9.  Credential Acquisition
+
+
+
+Yu                          Expires: Aug 2004                  [Page 23]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   There are two exchanges that can be used for acquiring credentials:
+   the AS exchange and the TGS exchange.  These exchanges have many
+   similarities, and this document describes them in parallel, noting
+   which behaviors are specific to one type of exchange.  The AS request
+   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
+   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
+   are forms of KDC replies (KDC-REP).
+
+9.1.  KDC-REQ
+
+   The KDC-REQ has a large number of fields in common between the RFC
+   1510 and the extensible versions.
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 24]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+      }
+
+
+   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
+   an EncTicketPartCommon.  The KDC copies most of them unchanged,
+   provided that their values meet site policy.
+
+   kdc-options
+        These flags do not correspond directly to "flags" in
+        EncTicketPartCommon.  [ insert mapping table here ]
+
+   cname
+        This field is copied to the "cname" field in
+        EncTicketPartCommon.  The "cname" field is required in an AS-
+        REQ; the client places its own name here.  In a TGS-REQ, the
+        "cname" in the ticket in the AP-REQ takes precedence.
+
+   realm
+        This field is the server's realm, and also holds the client's
+        realm in an AS-REQ.
+
+
+Yu                          Expires: Aug 2004                  [Page 25]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   The "from", "till", and "rtime" fields correspond to the "starttime",
+   "endtime", and "renew-till" fields of EncTicketPartCommon.
+
+   addresses
+        This field corresponds to the "caddr" field of
+        EncTicketPartCommon.
+
+   enc-authorization-data
+        For TGS-REQ, this field contains authorization data encrypted
+        using either the TGT session key or the AP-REQ subsession key;
+        these may be copied into the "authorization-data" field of
+        EncTicketPartCommon if policy permits.
+
+9.2.  PA-DATA
+
+   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
+   authenticate an AS-REQ; they may also modify several of the
+   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
+   to the client about which long-term key (usually password-derived) to
+   use.  PA-DATA may also include "hints" about which pre-authentication
+   mechanisms to use, or include data for input into a pre-
+   authentication mechanism.
+
+9.3.  KDC-REQ Processing
+
+   Processing of a KDC-REQ proceeds through several steps.  An
+   implementation need not perform these steps exactly as described, as
+   long as the resulting behavior is as if the steps were performed as
+   described.  The KDC performs replay handling on receipt of the
+   request; it then validates the request, adjusts timestamps, and
+   selects the keys used in the reply.  It copies data from the request
+   into the issued ticket, adjusting for policy.  The KDC then transmits
+   the reply to the client.
+
+9.3.1.  Handling Replays
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+   successfully processed, the KDC MUST respond with an KDC-REP message
+   rather than a replay error.  In order to reduce the amount of
+   ciphertext given to a potential attacker, KDCs MAY send the same
+   response generated when the request was first handled.  KDCs MUST
+   obey this replay behavior even if the actual transport in use is
+   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
+   and the entire request is not identical to a recently successfully
+   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
+   appropriate for AP-REQ processing.
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 26]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+9.3.2.  Request Validation
+
+9.3.2.1.  AS-REQ Authentication
+
+   Site policy determines whether a given client principal is required
+   to provide some pre-authentication prior to receiving an AS-REP.
+   Since the default reply key is typically the client's long-term
+   password-based key, an attacker may easily request known plaintext
+   (in the form of an AS-REP) upon which to mount a dictionary attack.
+   Pre-authentication can limit the possibility of such an attack.
+
+   If site policy requires pre-authentication for a client principal,
+   and no pre-authentication is provided, the KDC returns the error
+   "kdc-err-preauth-required".  Accompanying this error are "e-data"
+   which include hints telling the client which pre-authentication
+   mechanisms to use, or data for input to pre-authentication mechanisms
+   (e.g., input to challenge-response systems).  If pre-authentication
+   fails, the KDC returns the error "kdc-err-preauth-failed".
+
+   [ may need additional changes based on Sam's preauth draft ]
+
+9.3.2.2.  TGS-REQ Authentication
+
+   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
+   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
+   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
+   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
+   request.  [ padata not signed by authenticator! ] Any error from the
+   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
+   The service principal in the ticket of the AP-REQ may be a ticket-
+   granting service principal, or a normal application service
+   principal.  An AP-REQ ticket which is not a ticket-granting ticket
+   MUST NOT be used to issue a ticket for any service other than the one
+   named in the ticket.  In this case, the "renew", "validate", or
+   "proxy" [?also forwarded?]  option must be set in the request.
+
+9.3.2.3.  Principal Validation
+
+   If the client principal in an AS-REQ is unknown, the KDC returns the
+   error "kdc-err-c-principal-unknown".  If the server principal is
+   unknown, the KDC returns the error "kdc-err-c-principal-unknown".
+
+9.3.3.  Timestamp Handling
+
+   [ some aspects of timestamp handling, especially regarding postdating
+   and renewal, are difficult to read in KCLAR... needs closer
+   examination here ]
+
+   For the AS exchange, the "authtime" of a ticket is set to the local
+   time at the KDC.  For the TGS exchange, the KDC sets the "authtime"
+   to that of the ticket in the AP-REQ authenticating the TGS-REQ.
+
+Yu                          Expires: Aug 2004                  [Page 27]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   [?application server can spoof the authtime.  security issues for
+   hot-list?] [ MIT implementation may change authtime of renewed
+   tickets; needs check... ]
+
+   Processing of "starttime" (requested in the "from" field) differs
+   depending on whether the "postdated" option is set in the request.
+   If the "postdated" option is not set, and the requested "starttime"
+   is in the future beyond the window of acceptable clock skew, the KDC
+   returns the error "kdc-err-cannot-postdate".  If the "postdated"
+   option is not set, and the requested "starttime" is absent or does
+   not indicate a time in the future beyond the acceptable clock skew,
+   the KDC sets the "starttime" to the KDC's current time.  The
+   "postdated" option MUST NOT be honored if the ticket is being
+   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
+   Otherwise, if the "postdated" option is set, and site policy permits,
+   the KDC sets the "starttime" as requested, and sets the "invalid"
+   flag in the new ticket.
+
+9.3.3.1.  AS-REQ Timestamp Processing
+
+   The "endtime" of the ticket will be set to the earlier of the
+   requested "till" time and a time determined by local policy, possibly
+   determined using factors specific to the realm or principal. For
+   example, the expiration time MAY be set to the earliest of the
+   following:
+
+   *    The expiration time (till) requested.
+
+   *    The ticket's start time plus the maximum allowable lifetime
+        associated with the client principal from the authentication
+        server's database.
+
+   *    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.
+
+   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 MAY be set to the earliest of:
+
+
+
+Yu                          Expires: Aug 2004                  [Page 28]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   *    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.
+
+9.3.3.2.  TGS-REQ Timestamp Processing
+
+   If the TGS-REQ has the TGT in its AP-REQ, and the TGS-REQ requests an
+   "endtime" (in the "till" field), then the "endtime" of the new ticket
+   is set to the minimum of (a) the requested "endtime" value, (b) the
+   "endtime" in the TGT, and (c) an "endtime" determined by site policy
+   on ticket lifetimes.  If the new ticket is a renewal, the "endtime"
+   of the new ticket is bounded by (a) the requested "endtime" value,
+   (b) the value of the "renew-till" value of the old, and (c) the
+   "starttime" of the new ticket plus the life (endtime - starttime) of
+   the old ticket.  [ the previous sentence is a bit confusing; adapted
+   from KCLAR 3.3.3. ]
+
+   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
+   a "starttime", "endtime", or "renew-till" time later than the "renew-
+   till" time of the TGT.
+
+9.3.4.  Key Selection
+
+   Three keys are involved in creating a KDC-REP.  The reply key is used
+   to encrypt the encrypted part of the KDC-REP.  The session key is
+   stored in the encrypted part of the ticket, and is also present in
+   the part of the reply which is visible to the client.  The ticket key
+   is used to encrypt the ticket.  These keys all have initial values
+   for a given exchange; pre-authentication and other extension
+   mechanisms may change the value used for any of these keys.
+
+   [ again, may need changes based on Sam's preauth draft ]
+
+   The set of encryption types the client will understand appears in the
+   "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set of
+   possible reply keys and the set of session key encryption types based
+   on the "etype" field.
+
+   For the AS exchange, the reply key is initially a long-term key of
+   the client, limited to those encryption types specified by the
+   "etype" field.  The KDC SHOULD use the first valid strong "etype" for
+   which an encryption key is available.  For the TGS exchange, the
+   reply key is initially the subsession key of the Authenticator, or,
+   if that is not present, the session key of the ticket used to
+   authenticate the TGS-REQ.
+
+
+Yu                          Expires: Aug 2004                  [Page 29]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   The ticket key is initially the long-term key of the service.  User-
+   to-user authentication sets the ticket key to be the session key of
+   the additional ticket in the request.
+
+   The session key is initially randomly generated, and has an
+   encryption type which both the client and the server will understand.
+   Typically, the KDC has prior knowledge of which encryption types the
+   server will understand.  It selects the first valid strong "etype"
+   listed the request which the server also will understand.
+
+9.3.5.  Checking For Revoked Tickets
+
+9.4.  Reply Validation
+
+10.  Application Authentication
+
+11.  Session Key Use
+
+11.1.  KRB-SAFE
+
+11.2.  KRB-PRIV
+
+11.3.  KRB-CRED
+
+12.  Security Considerations
+
+12.1.  Time Synchronization
+
+   Time synchronization between the KDC and application servers is
+   necessary to prevent acceptance of expired tickets.
+
+   Time synchronization is needed between application servers and
+   clients to prevent replay attacks if a replay cache is being used.
+   If negotiated subsession keys are used to encrypt application data,
+   replay caches may not be necessary.
+
+12.2.  Replays
+
+12.3.  Principal Name Reuse
+
+   See Section 6.2.
+
+12.4.  Password Guessing
+
+12.5.  Forward Secrecy
+
+   [from KCLAR 10.; needs some rewriting]
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB-PRIV message,
+
+Yu                          Expires: Aug 2004                  [Page 30]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the TGS-REP
+   message.  The session key from the ticket-granting ticket was sent to
+   the user in the AS-REP message encrypted in the user's secret key,
+   and embedded in the ticket-granting ticket, which was encrypted in
+   the key of the KDC.  Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+12.6.  Authorization
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  Kerberos does not, by
+   itself, provide authorization.  Applications SHOULD NOT accept the
+   mere issuance of a service ticket by the Kerberos server as granting
+   authority to use the service.
+
+12.7.  Login Authentication
+
+   Some applications, particularly those which provide login access when
+   provided with a password, SHOULD NOT treat successful acquisition of
+   credentials as sufficient proof of the user's identity.  An attacker
+   posing as a user could generate an illegitimate KDC-REP message which
+   decrypts properly.  To authenticate a user logging on to a local
+   system, the credentials obtained SHOULD be used in a TGS exchange to
+   obtain credentials for a local service.  Successful use of those
+   credentials to authenticate to the local service assures that the
+   initially obtained credentials are from a valid KDC.
+
+Appendices
+
+A.  ASN.1 Module (Normative)
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 31]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related
+      -- OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
+      -- OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2)
+      }
+
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+      --
+      -- *** basic types
+      --
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+Yu                          Expires: Aug 2004                  [Page 32]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+      -- sequence numbers
+      --
+      -- We may want to increase this to 2**64 and define a UInt64
+      -- type.
+      SeqNum          ::= UInt32
+
+
+      -- nonces
+      --
+      -- Likewise, we may want to make this UInt64.
+      Nonce           ::= UInt32
+
+
+      -- must not have fractional seconds
+      KerberosTime    ::= GeneralizedTime
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+      -- used for language tags
+      LangTag ::= PrintableString (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+      Realm           ::= KerberosString
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is not recommended.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 33]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+      -- Yet another refinement to kludge around historical
+      -- implementation bugs... we still send at least 32 bits, but
+      -- this parameterized type allows us to actually use named bit
+      -- string syntax to define flags, sort of.
+      KerberosFlags { NamedBits }
+          ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- must be a valid value of -- NamedBits
+          -- but if the value to be sent would otherwise be shorter
+          -- than 32 bits, it must be padded with trailing zero bits
+          -- to 32 bits.  Otherwise, no trailing zero bits may be
+          -- present.
+      })
+
+
+      AddrType        ::= Int32
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 34]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      --
+      -- *** typed hole support
+      --
+
+
+      -- Object class for generic typed holes, e.g., padata,
+      -- authorizationdata.
+      --
+      -- Its parameter specifies the name of integer type used as a
+      -- unique identifier; usually this type is an aliased Int32.
+      --
+      -- Usually, the &Type field will be an OctetstringHole, but if
+      -- there is a need to use a non-ASN.1 encoded type, it may be
+      -- simply an OCTET STRING, possibly with some comments
+      -- describing its contents.
+      TYPEDHOLE { IntType } ::= CLASS {
+          &id-int     IntType UNIQUE,
+          &id-oid     RELATIVE-OID UNIQUE OPTIONAL,
+          &Type,
+          &desc       ObjectDescriptor OPTIONAL
+      } WITH SYNTAX {
+          SYNTAX              &Type
+          IDENTIFIED BY       &id-int
+          [ OID               &id-oid ]
+          [ DESCRIPTION       &desc ]
+      }
+
+
+      -- An octet string wrapping another ASN.1 type.
+      OctetstringHole { Type } ::= OCTET STRING (CONTAINING Type)
+
+
+      --
+      -- *** crypto-related types and assignments
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 35]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+      -- The following numbers are provisional... conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 36]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      et-aes128-cts-hmac-sha1-96      EType ::= 17 -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18 -- AES
+      et-rc4-hmac                     EType ::= 23 -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24 -- Microsoft
+      et-subkey-keymaterial           EType ::= 65 -- opaque; PacketCable
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
+      SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+
+
+Yu                          Expires: Aug 2004                  [Page 37]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+      CksumType       ::= Int32
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum { KeyToUse:Keys, KeyUsage:KeyUsages } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 38]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- a Checksum that must contain the checksum of a particular type
+      ChecksumOf { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
+      Checksum { Keys, KeyUsages }
+      (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed { InnerType, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
+      SEQUENCE {
+          cksum       [0] ChecksumOf
+                              { InnerType, Keys, KeyUsages } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+      --
+      -- *** Tickets
+      --
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 39]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      Ticket1510 ::= SEQUENCE {
+          -- "COMPONENTS OF" drops the extension marker from
+          -- TicketCommon
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (WITH COMPONENTS { ia5 PRESENT }),
+          sname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          }),
+          extensions ABSENT
+      })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon
+      (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (WITH COMPONENTS { ia5 ABSENT }),
+          sname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          })
+      })
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 40]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+      EncTicketPart1510 ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (WITH COMPONENTS { ia5 PRESENT }),
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          })
+      })
+
+
+      EncTicketPartExt ::= EncTicketPartCommon
+      (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (WITH COMPONENTS { ia5 ABSENT }),
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          }),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- explicitly constrain authorization-data to be non-empty
+          -- if present
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 41]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      --
+      -- *** Authorization Data
+      --
+
+
+      ADType          ::= Int32
+
+      AUTHDATA        ::= TYPEDHOLE { ADType }
+
+      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be non-empty.
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] AUTHDATA.&id-int ({Authdata-Set}),
+          ad-data             [1] OCTET STRING (AUTHDATA.&Type)
+                                      ({Authdata-Set}{@ad-type})
+      }
+
+
+      -- Mandatory AuthorizationData
+      Authdata-Set AUTHDATA ::= {
+          ad-if-relevant |
+          ad-kdcissued |
+          ad-and-or |
+          ad-mandatory-for-kdc ,
+          ...
+      }
+
+
+      ad-if-relevant AUTHDATA ::= {
+          SYNTAX              OctetstringHole { AuthorizationData }
+          IDENTIFIED BY       1
+          DESCRIPTION
+          "Encapsulates another AuthorizationData.
+      Intended for application servers; receiving application servers
+      MAY ignore."
+      }
+
+
+      ad-kdcissued AUTHDATA ::= {
+          SYNTAX              OctetstringHole { AD-KDCIssued }
+          IDENTIFIED BY       4
+          DESCRIPTION "KDC-issued privilege attributes"
+      }
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 42]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+              AuthorizationData, { key-session },
+              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+      AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+
+      ad-and-or AUTHDATA ::= {
+          SYNTAX              OctetstringHole { AD-AND-OR }
+          IDENTIFIED BY       5
+          DESCRIPTION "And/Or"
+      }
+
+      AD-AND-OR               ::= SEQUENCE {
+              condition-count [0] INTEGER,
+              elements        [1] AuthorizationData
+      }
+
+
+      ad-mandatory-for-kdc AUTHDATA ::= {
+          SYNTAX              OctetstringHole { AuthorizationData }
+          IDENTIFIED BY       8
+          DESCRIPTION "KDCs MUST interpret any AuthorizationData
+      wrapped in this."
+      }
+
+
+      TrType                  ::= Int32 -- must be registered
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+          tr-type     [0] TrType,
+          contents    [1] OCTET STRING
+      }
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 43]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      TEType                  ::= Int32
+
+      TICKETEXTENSION         ::= TYPEDHOLE { TEType }
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TICKETEXTENSION.&id
+                                      ({TicketExtension-Set}),
+          te-data             [1] OCTET STRING (TICKETEXTENSION.&Type)
+                                      ({TicketExtension-Set}{@te-type})
+      }
+
+      -- no mandatory ticket extensions currently
+      TicketExtensionSet TICKETEXTENSION ::= { ... }
+
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+      --
+      -- *** KDC protocol
+      --
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 44]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as outside,
+              -- to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as outside,
+              -- to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 45]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF LangTag OPTIONAL,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 46]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+      }
+
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          }),
+          realm (WITH COMPONENTS { ia5 PRESENT }),
+          sname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          }),
+          till PRESENT
+      })
+
+Yu                          Expires: Aug 2004                  [Page 47]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          }),
+          realm (WITH COMPONENTS { ia5 ABSENT }),
+          sname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          }),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+      KDCOptionsBits ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+Yu                          Expires: Aug 2004                  [Page 48]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      AS-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 11] KDC-REP-1510 { EncASRepPart }
+          (WITH COMPONENTS { ..., msg-type (11) }),
+          ext         [APPLICATION  7]  Signed {
+              [APPLICATION 7] KDC-REP-EXT { EncASRepPart },
+              { key-reply }, { ku-ASRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (7) })
+      }
+
+
+      TGS-REP         ::= CHOICE {
+          rfc1510     [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart }
+          (WITH COMPONENTS { ..., msg-type (13) }),
+          ext         [APPLICATION  9]  Signed {
+              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPart },
+              { key-reply }, { ku-TGSRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (9) })
+      }
+
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP definitions
+              -- to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and using --
+                                        -- Authenticator session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using --
+                                         -- subsession key -- }
+          },
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks agaginst client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+Yu                          Expires: Aug 2004                  [Page 49]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (WITH COMPONENTS { ia5 PRESENT}),
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 PRESENT }))
+          }),
+          req-cksum ABSENT,
+          lang-tag ABSENT
+      })
+
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (WITH COMPONENTS { ia5 ABSENT }),
+          cname (WITH COMPONENTS {
+              ...,
+              name-string (WITH COMPONENT
+                           (WITH COMPONENTS { ia5 ABSENT }))
+          })
+      })
+
+
+      EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+      EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+      EncKDCRepPart   ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementation
+      }
+
+
+
+Yu                          Expires: Aug 2004                  [Page 50]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- convert to use object class?
+      LRType          ::=     Int32
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+          lr-type     [0] LRType,
+          lr-value    [1] KerberosTime
+      }
+
+
+      --
+      -- *** preauth
+      --
+
+
+      PaDataType ::= Int32
+
+      -- TYPEDHOLE class that uses PaDataType as its unique ID type.
+      PADATA-OBJ ::= TYPEDHOLE { PaDataType }
+
+      PA-DATA ::= SEQUENCE {
+          -- NOTE: first tag is [1], not [0]
+          padata-type         [1] CHOICE {
+              -- example of possible use of RELATIVE-OIDs
+              int     PADATA-OBJ.&id-int ({PaDataSet}),
+              oid     PADATA-OBJ.&id-oid ({PaDataSet}{@int})
+          },
+          padata-value        [2] OCTET STRING (PADATA-OBJ.&Type)
+                                      ({PaDataSet}{@padata-type.int})
+      }
+
+
+      PaDataSet PADATA-OBJ ::= {
+          pa-tgs-req |
+          pa-enc-timestamp |
+          pa-etype-info |
+          pa-etype-info2 |
+          pa-pw-salt |
+          pa-as-req ,
+          ...
+      }
+
+
+      pa-tgs-req PADATA-OBJ ::= {
+          SYNTAX              OctetstringHole { AP-REQ }
+          IDENTIFIED BY       1
+          DESCRIPTION
+          "AP-REQ authenticating a TGS-REQ"
+      }
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 51]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      pa-enc-timestamp PADATA-OBJ ::= {
+          SYNTAX              OctetstringHole { PA-ENC-TIMESTAMP }
+          IDENTIFIED BY       2
+          DESCRIPTION
+          "Encrypted timestamp preauth;
+      Encryption key used is client's long-term key."
+      }
+
+      PA-ENC-TIMESTAMP ::= EncryptedData {
+          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
+      }
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+      pa-etype-info PADATA-OBJ ::= {
+          SYNTAX              OctetstringHole { ETYPE-INFO }
+          IDENTIFIED BY       11
+          DESCRIPTION
+          "Hints returned in AS-REP or KRB-ERROR to help client
+      choose a password-derived key, either for preauthentication or
+      for decryption of the reply."
+      }
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+
+      pa-etype-info2 PADATA-OBJ ::= {
+          SYNTAX              OctetstringHole { ETYPE-INFO2 }
+          IDENTIFIED BY       19
+          DESCRIPTION
+          "Similar to etype-info, but with parameters provided for
+      the string-to-key function."
+      }
+
+      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
+                                      OF ETYPE-INFO-ENTRY
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+Yu                          Expires: Aug 2004                  [Page 52]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      pa-pw-salt PADATA-OBJ ::= {
+          SYNTAX              OCTET STRING (CONSTRAINED BY {
+            -- Must consist of the salt string to be used by the
+            -- client, in an unspecified character encoding. -- })
+          IDENTIFIED BY       3
+          DESCRIPTION
+          "Obsolescent.  Salt for client's long-term key.
+      Its character encoding is unspecified."
+      }
+
+
+      pa-as-req PADATA-OBJ ::= {
+          SYNTAX              OctetstringHole { AS-REQ
+                                                (WITH COMPONENTS {
+                                                    ext }) }
+          IDENTIFIED BY       42 -- provisional
+          DESCRIPTION
+          "An extensible AS-REQ may be sent as a padata in a
+      non-extensible AS-REQ to allow for backwards compatibility."
+      }
+
+
+      --
+      -- *** Application session setup
+      --
+
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          extensions          [5] ApReqExtensions OPTIONAL,
+          ...
+      }
+
+
+
+Yu                          Expires: Aug 2004                  [Page 53]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      AP-REQ-1510 ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          extensions ABSENT
+      })
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt only,
+          -- since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (WITH COMPONENTS { ia5 ABSENT }),
+                  cname (WITH COMPONENTS {
+                      ...,
+                      name-string (WITH COMPONENT
+                                   (WITH COMPONENTS { ia5 ABSENT }))
+                  }),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+      ApReqExtType    ::= Int32
+
+      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apReqExt-Type       [0] ApReqExtType,
+          apReqExt-Data       [1] OCTET STRING
+      }
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 54]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15),
+          extensions ABSENT
+      })
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt }
+      (WITH COMPONENTS { ..., msg-type (19) })
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 55]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      ApRepExtType    ::= Int32
+
+      -- convert to use object class?
+      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apRepExt-Type       [0] ApRepExtType,
+          apRepExt-Data       [1] OCTET STRING
+      }
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          authorization-data ABSENT
+      })
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Application messages
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 56]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would allow us to
+      -- make safe-body optional, allowing for a GSS-MIC sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 57]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+      (WITH COMPONENTS { ..., msg-type (24) })
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds OPTIONAL,
+          s-address   [4] HostAddress OPTIONAL,
+          r-address   [5] HostAddress OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 58]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      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
+      }
+
+
+      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
+          pvno            [0] INTEGER (5),
+          msg-type        [1] INTEGER (16),
+          sname           [2] PrincipalName OPTIONAL,
+          srealm          [3] Realm OPTIONAL,
+          ...
+      }
+
+
+      --
+      -- *** Error messages
+      --
+
+
+      ErrCode ::= Int32
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 59]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          -- effectively drops the extension marker
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30),
+          typed-data ABSENT,
+          nonce ABSENT,
+          lang-tag ABSENT
+      })
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+      (WITH COMPONENTS { ..., msg-type (23) })
+
+
+      TDType ::= Int32
+
+      -- convert to information object class later
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+          data-type   [0] TDType,
+          data-value  [1] OCTET STRING OPTIONAL
+      }
+
+
+      END
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 60]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+B.  Kerberos and Character Encodings (Informative)
+
+   [adapted from KCLAR 5.2.1]
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO-2022/ECMA-35
+   [ISO-2022/ECMA-35] to switch character sets, and the default
+   character set that is designated as G0 is the ISO-646/ECMA-6
+   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
+   ASCII), which mostly works.
+
+   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER previously
+   prohibited the designation of character sets as any but the G0 and C0
+   sets.  This had the side effect of prohibiting the use of ISO-8859
+   (ISO Latin) [ISO-8859] character-sets or any other character-sets
+   that utilize a 96-character set, since it is prohibited by
+   ISO-2022/ECMA-35 to designate them as the G0 code element.  Recent
+   revisions to the ASN.1 standards resolve this contradiction.
+
+   In practice, many implementations treat RFC 1510 GeneralStrings as if
+   they were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to conform to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   [the following should probably be rewritten and moved into the
+   principal name section]
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way. Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+
+
+Yu                          Expires: Aug 2004                  [Page 61]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters. This is a violation of the ASN.1
+   standard. Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard. As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+C.  Kerberos History (Informative)
+
+   [Adapted from KCLAR "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 Ts'o, 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 [KNT94].
+
+
+Yu                          Expires: Aug 2004                  [Page 62]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+Normative References
+
+   [KCRYPTO]
+
+   [RFC2119]
+
+   [X680]
+
+   [X681]
+
+   [X682]
+
+   [X683]
+
+   [X690]
+
+Informative References
+
+   [DS81]
+
+   [KCLAR]
+
+   [KNT94]
+
+   [NS78]
+
+   [RFC1510]
+
+   [RFC1964]
+
+   [ISO8859]
+
+Acknowledgments
+
+   Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-04.
+
+Author's Address
+
+   Tom Yu
+   77 Massachusetts Ave
+   Cambridge, MA 02139
+   USA
+   tlyu@mit.edu
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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
+
+Yu                          Expires: Aug 2004                  [Page 63]
+
+Internet-Draft            yu-krb-extensions-00               09 Feb 2004
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Aug 2004                  [Page 64]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt b/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt
new file mode 100644
index 00000000000..426693193b7
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt
@@ -0,0 +1,5127 @@
+INTERNET-DRAFT                                                    Tom Yu
+draft-yu-krb-wg-kerberos-extensions-01.txt                           MIT
+Expires: 19 Jan 2005                                        19 July 2004
+
+
+        The Kerberos Network Authentication Service (Version 5)
+
+
+Status of This Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   or will be disclosed, and any of which I become aware will be
+   disclosed, in accordance with RFC 3668.
+
+
+   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
+
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document describes version 5 of the Kerberos network
+   authentication protocol.  It describes changes to the protocol which
+   allow for extensions to be made to the protocol without creating
+   interoperability problems.
+
+
+Key Words for Requirements
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in RFC 2119.
+
+
+
+
+
+Yu                          Expires: Jan 2005                   [Page 1]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+Table of Contents
+
+
+   Status of This Memo .......................................  1
+   Copyright Notice ..........................................  1
+   Abstract ..................................................  1
+   Key Words for Requirements ................................  1
+   Table of Contents .........................................  2
+   1.  Introduction ..........................................  4
+   1.1.  Kerberos Protocol Overview ..........................  4
+   1.2.  Overview of Document ................................  5
+   2.  Extensibility .........................................  5
+   3.  Backwards Compatibility ...............................  6
+   4.  Criticality ...........................................  6
+   5.  Use of ASN.1 in Kerberos ..............................  6
+   5.1.  Module Header .......................................  7
+   5.2.  Top-Level Type ......................................  7
+   5.3.  Previously Unused ASN.1 Notation ....................  8
+   5.3.1.  Parameterized Types ...............................  8
+   5.3.2.  COMPONENTS OF Notation ............................  8
+   5.3.3.  Constraints .......................................  8
+   5.4.  New Types ...........................................  9
+   6.  Basic Types ........................................... 10
+   6.1.  Constrained Integer Types ........................... 10
+   6.2.  KerberosTime ........................................ 11
+   6.3.  KerberosString ...................................... 11
+   7.  Principals ............................................ 11
+   7.1.  Name Types .......................................... 12
+   7.2.  Principal Type Definition ........................... 12
+   7.3.  Principal Name Reuse ................................ 13
+   7.4.  Realm Names ......................................... 13
+   7.5.  Printable Representations of Principal Names ........ 13
+   7.6.  Ticket-Granting Service Principal ................... 13
+   7.6.1.  Cross-Realm TGS Principals ........................ 14
+   8.  Types Relating to Encryption .......................... 14
+   8.1.  Assigned Numbers for Encryption ..................... 14
+   8.1.1.  EType ............................................. 14
+   8.1.2.  Key Usages ........................................ 15
+   8.2.  Which Key to Use .................................... 16
+   8.3.  EncryptionKey ....................................... 17
+   8.4.  EncryptedData ....................................... 17
+   8.5.  Checksums ........................................... 18
+   8.5.1.  ChecksumOf ........................................ 19
+   8.5.2.  Signed ............................................ 20
+   9.  Tickets ............................................... 20
+   9.1.  Timestamps .......................................... 21
+   9.2.  Ticket Flags ........................................ 21
+   9.2.1.  Flags Relating to Initial Ticket Acquisition ...... 22
+   9.2.2.  Invalid Tickets ................................... 22
+   9.2.3.  OK as Delegate .................................... 23
+   9.3.  Renewable Tickets ................................... 23
+   9.4.  Postdated Tickets ................................... 24
+
+
+Yu                          Expires: Jan 2005                   [Page 2]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   9.5.  Proxiable and Proxy Tickets ......................... 25
+   9.6.  Forwardable Tickets ................................. 26
+   9.7.  Transited Realms .................................... 27
+   9.8.  Authorization Data .................................. 27
+   9.9.  Encrypted Part of Ticket ............................ 27
+   9.10.  Cleartext Part of Ticket ........................... 28
+   10.  Credential Acquisition ............................... 28
+   10.1.  KDC-REQ ............................................ 29
+   10.2.  PA-DATA ............................................ 31
+   10.3.  KDC-REQ Processing ................................. 31
+   10.3.1.  Handling Replays ................................. 31
+   10.3.2.  Request Validation ............................... 32
+   10.3.2.1.  AS-REQ Authentication .......................... 32
+   10.3.2.2.  TGS-REQ Authentication ......................... 32
+   10.3.2.3.  Principal Validation ........................... 32
+   10.3.2.4.  Checking For Revoked or Invalid Tickets ........ 32
+   10.3.3.  Timestamp Handling ............................... 33
+   10.3.3.1.  AS-REQ Timestamp Processing .................... 33
+   10.3.3.2.  TGS-REQ Timestamp Processing ................... 34
+   10.3.4.  Handling Transited Realms ........................ 35
+   10.3.5.  Address Processing ............................... 35
+   10.3.6.  Ticket Flag Processing ........................... 35
+   10.3.7.  Key Selection .................................... 36
+   10.3.7.1.  Reply Key and Session Key Selection ............ 37
+   10.3.7.2.  Ticket Key Selection ........................... 37
+   10.4.  Reply Validation ................................... 37
+   11.  Session Key Exchange ................................. 37
+   11.1.  AP-REQ ............................................. 37
+   11.2.  AP-REP ............................................. 40
+   12.  Session Key Use ...................................... 41
+   12.1.  KRB-SAFE ........................................... 41
+   12.2.  KRB-PRIV ........................................... 42
+   12.3.  KRB-CRED ........................................... 42
+   13.  Security Considerations .............................. 43
+   13.1.  Time Synchronization ............................... 43
+   13.2.  Replays ............................................ 44
+   13.3.  Principal Name Reuse ............................... 44
+   13.4.  Password Guessing .................................. 44
+   13.5.  Forward Secrecy .................................... 44
+   13.6.  Authorization ...................................... 44
+   13.7.  Login Authentication ............................... 44
+   14.  Acknowledgments ...................................... 45
+   Appendices ................................................ 45
+   A.  ASN.1 Module (Normative) .............................. 45
+   B.  Kerberos and Character Encodings (Informative) ........ 76
+   C.  Kerberos History (Informative) ........................ 77
+   D.  Notational Differences from [KCLAR] ................... 78
+   Normative References ...................................... 79
+   Informative References .................................... 79
+   Author's Address .......................................... 80
+   Full Copyright Statement .................................. 80
+
+
+Yu                          Expires: Jan 2005                   [Page 3]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+1.  Introduction
+
+
+   The Kerberos network authentication protocol is a trusted third-party
+   protocol utilizing symmetric-key cryptography.  It assumes that all
+   communications between parties in the protocol may be arbitrarily
+   tampered with or monitored, and that the security of the overall
+   system depends only on the effectiveness of the cryptographic
+   techniques and the secrecy of the keys used.  The protocol
+   authenticates an application client's identity to an application
+   server, and likewise authenticates the application server's identity
+   to the application client.  These assurances are made possible by the
+   client and the server sharing secrets with the trusted third party:
+   the Kerberos server, also known as the Key Distribution Center (KDC).
+   In addition, the protocol establishes an ephemeral shared secret (the
+   session key) between the client and the server, allowing the
+   protection of further communications between them.
+
+
+1.1.  Kerberos Protocol Overview
+
+
+   Kerberos comprises three main sub-protocols: credentials acquisition,
+   session key exchange, and session key usage.  A client acquires
+   credentials by asking the KDC for a credential for a service; the KDC
+   issues the credential, which contains a ticket and a session key.
+   The ticket, containing the client's identity, timestamps, expiration
+   time, and a session key, is a encrypted in a key known to the
+   application server.  The KDC encrypts the credential using a key
+   known to the client, and transmits the credential to the client.
+
+
+   There are two means of requesting credentials: the Authentication
+   Service (AS) exchange, and the Ticket-Granting Service (TGS)
+   exchange.  In the typical AS exchange, a client uses a password-
+   derived key to decrypt the response.  In the TGS exchange, the KDC
+   behaves as an application, which the client authenticates to using a
+   Ticket-Granting Ticket (TGT).  The client usually obtains the TGT by
+   using the AS exchange.
+
+
+   Session key exchange consists of the client transmitting the ticket
+   to the application server, accompanied by an authenticator.  The
+   authenticator contains a timestamp and additional data encrypted
+   using the ticket's session key.  The application server decrypts the
+   ticket, extracting the session key.  The application server then uses
+   the session key to decrypt the authenticator.  Upon successful
+   decryption of the authenticator, the application server knows that
+   the data in the authenticator were sent by the client named in the
+   associated ticket.  Additionally, since authenticators expire more
+   quickly than tickets, the application server has some assurance that
+   the transaction is not a replay.  The application server may send an
+   encrypted acknowledgment to the client, verifying its identity to the
+   client.
+
+
+
+
+Yu                          Expires: Jan 2005                   [Page 4]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   Once session key exchange has occurred, the client and server may use
+   the established session key to protect further traffic.  This
+   protection may consist of protection of integrity only, or of
+   protection of confidentiality and integrity.  Additional measures
+   exist for a client to securely forward credentials to a server.
+
+
+   The entire scheme depends on loosely synchronized clocks.
+   Synchronization of the clock on the KDC with the application server
+   clock allows the application server to accurately determine whether a
+   credential is expired.  Likewise, synchronization of the clock on the
+   client with the application server clock prevents replay attacks
+   utilizing the same credential.  Careful design of the application
+   protocol may allow replay prevention without requiring client-server
+   clock synchronization.
+
+
+   After establishing a session key, application client and the
+   application server can exchange Kerberos protocol messages that use
+   the session key to protect the integrity or confidentiality of
+   communications between the client and the server.  Additionally, the
+   client may forward credentials to the application server.
+
+
+   The credentials acquisition protocol takes place over specific,
+   defined transports (UDP and TCP).  Application protocols define which
+   transport to use for the session key establishment protocol and for
+   messages using the session key; the application may choose to perform
+   its own encapsulation of the Kerberos messages, for example.
+
+
+1.2.  Overview of Document
+
+
+   The remainder of this document begins by describing the general
+   frameworks for protocol extensibility, including whether to interpret
+   unknown extensions as critical.  It then defines the protocol
+   messages and exchanges.
+
+
+   The definition of the Kerberos protocol uses Abstract Syntax Notation
+   One (ASN.1) [X680], which specifies notation for describing the
+   abstract content of protocol messages.  This document defines a
+   number of base types using ASN.1; these base types subsequently
+   appear in multiple types which define actual protocol messages.
+   Definitions of principal names and of tickets, which are central to
+   the protocol, also appear preceding the protocol message definitions.
+
+
+2.  Extensibility
+
+
+   As originally defined in RFC 1510, the Kerberos protocol does not
+   readily allow for backwards-compatible extensions to the protocol.
+   Various proposals to extend the Kerberos protocol have appeared since
+   RFC 1510, many of them creating problems for backwards compatibility.
+   This document adopts the technique of creating new extensible types
+   which encode to messages which are very similar to RFC 1510 messages
+   on the wire.  This similarity allows implementors to use shared code
+
+
+Yu                          Expires: Jan 2005                   [Page 5]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   paths for encoding and decoding both new and old messages.
+
+
+   The protocol defined in RFC 1510 already contains some elements
+   allowing for limited backwards-compatible extensions to the protocol.
+   Most of these elements consist of "typed holes"; these are octet
+   strings having associated assigned numbers indicating the intended
+   interpretation of the octet string.  This document typed holes to
+   some types which have previously lacked typed holes.  This document
+   also describes procedures for the IETF to use the extensibility model
+   of ASN.1 to make further backwards-compatible extensions of the
+   Kerberos protocol, if typed holes prove inadequate for some desired
+   extension.
+
+
+3.  Backwards Compatibility
+
+
+   This document describes two sets (for the most part) of ASN.1 types.
+   The first set of types is wire-encoding compatible with RFC 1510 and
+   [KCLAR].  The second set of types is the set of types enabling
+   extensibility.  This second set may be referred to as "extensibility-
+   enabled types". [ need to make this consistent throughout? ]
+
+
+   A major difference between the new extensibility-enabled types and
+   the types for RFC 1510 compatibility is that the extensibility-
+   enabled types allow for the use of UTF-8 encodings in various
+   character strings in the protocol.  Each party in the protocol must
+   have some knowledge of the capabilities of the other parties in the
+   protocol.  There are methods for establishing this knowledge without
+   necessarily requiring explicit configuration.
+
+
+   An extensibility-enabled client can detect whether a KDC supports the
+   extensibility-enabled types by requesting an extensibility-enabled
+   reply.  If the KDC replies with an extensibility-enabled reply, the
+   client knows that the KDC supports extensibility.  If the KDC issues
+   an extensibility-enabled ticket, the client knows that the service
+   named in the ticket is extensibility-enabled.
+
+
+4.  Criticality
+
+
+   In general, implementations SHOULD treat unknown extension, flags,
+   etc. as non-critical; i.e., they should ignore them when they do not
+   understand them.  Exceptions are clearly marked.  An implementation
+   SHOULD NOT reject a request merely because it does not understand
+   some element of the request.  As a related consequence,
+   implementations SHOULD handle talking to other implementations which
+   do not implement some requested options.  This may require designers
+   of extensions or options to provide means to detect whether
+   extensions or options are rejected, or whether such extensions or
+   options are merely not understood, or whether such extensions or
+   options are (perhaps maliciously) deleted or modified in transit.
+
+
+
+
+Yu                          Expires: Jan 2005                   [Page 6]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+5.  Use of ASN.1 in Kerberos
+
+
+   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
+   Even though ASN.1 theoretically allows the description of protocol
+   messages to be independent of the encoding rules used to encode the
+   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
+   the semantics of the notation, such as whether tags carry any
+   semantic content to the application, may cause the use of other ASN.1
+   encoding rules to be problematic.
+
+
+   Implementors not using existing ASN.1 tools (e.g., compilers or
+   support libraries) are cautioned to thoroughly read and understand
+   the actual ASN.1 specification to ensure correct implementation
+   behavior.  There is more complexity in the notation than is
+   immediately obvious, and some tutorials and guides to ASN.1 are
+   misleading or erroneous.  Recommended tutorials and guides include
+   [Dub00], [Lar99], though there is still no substitute for reading the
+   actual ASN.1 specification.
+
+
+5.1.  Module Header
+
+
+   The type definitions in this document assume an ASN.1 module
+   definition of the following form:
+
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+      -- Rest of definitions here
+
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and that automatic tagging is not done.
+
+
+   Some other publications [RFC1510] [RFC1964] erroneously specify an
+   object identifier (OID) having an incorrect value of "5" for the
+   "dod" component of the OID.  In the case of RFC 1964, use of the
+   "correct" OID value would result in a change in the wire protocol;
+   therefore, the RFC 1964 OID remains unchanged for now.
+
+
+5.2.  Top-Level Type
+
+
+   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
+   Data Units or PDUs) which an application may directly reference.
+   Applications SHOULD NOT transmit any types other than those which are
+   alternatives of the KRB-PDU CHOICE.
+
+
+
+
+
+Yu                          Expires: Jan 2005                   [Page 7]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+
+5.3.  Previously Unused ASN.1 Notation
+
+
+   Some aspects of ASN.1 notation used in this document were not used in
+   [KCLAR], and may be unfamiliar to some readers.
+
+
+5.3.1.  Parameterized Types
+
+
+   This document uses ASN.1 parameterized types [X683] to make
+   definitions of types more readable.  For some types, some or all of
+   the parameters are advisory, i.e., they are not encoded in any form
+   for transmission in a protocol message.  These advisory parameters
+   can describe implementation behavior associated with the type.
+
+
+5.3.2.  COMPONENTS OF Notation
+
+
+   The "COMPONENTS OF" notation, used to define the RFC 1510
+   compatibility types, extracts all of the component types of an ASN.1
+   SEQUENCE type.  The extension marker (the "..." notation) and any
+   extension components are not extracted by "COMPONENTS OF".  The
+   "COMPONENTS OF" notation permits concise definition of multiple types
+   which have many components in common with each other.
+
+
+5.3.3.  Constraints
+
+
+   This document uses ASN.1 constraints, including the
+   "UserDefinedConstraint" syntax [X682].  Some constraints can be
+   handled automatically by tools that can parse them.  Uses of the
+   "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will
+   typically need to have behavior manually coded; these uses provide a
+
+
+Yu                          Expires: Jan 2005                   [Page 8]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   formalized way of conveying intended implementation behavior.
+
+
+   The "WITH COMPONENTS" constraint notation allows constraints to apply
+   to component types of a SEQUENCE type.  This constraint notation
+   effectively allows constraints to "reach into" a type to constrain
+   its component types.
+
+
+5.4.  New Types
+
+
+   This document defines a number of ASN.1 types which are new since
+   RFC 1510.  The names of these types will typically have a suffix like
+   "Ext", indicating that the types are intended to support
+   extensibility.  Types original to RFC 1510 have been renamed to have
+   a suffix like "1510".  The "Ext" and "1510" types often contain a
+   number of common elements; these common elements have a suffix like
+   "Common".  The "1510" types have various ASN.1 constraints applied to
+   them; the constraints limit the possible values of the "1510" types
+   to those permitted by RFC 1510 or by [KCLAR].  The "Ext" types may
+   have different constraints, typically to force string values to be
+   sent as UTF-8.
+
+
+   For example, consider
+
+
+      -- example "common" type
+      Foo-Common      ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING,
+          ...,
+          c           [2] INTEGER,
+          ...
+      }
+
+
+      -- example "RFC 1510 compatibility" type
+      Foo-1510        ::= SEQUENCE {
+          -- the COMPONENTS OF notation drops the extension marker
+          -- and all extension additions.
+          COMPONENTS OF Foo-Common
+      }
+
+
+      -- example "extensibility-enabled" type
+      Foo-Ext         ::= Foo-Common
+
+
+   where "Foo-Common" is a common type used to define both the "1510"
+   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
+   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
+   not contain the extension marker, nor does it contain the extension
+   component "c".  The type "Foo-1510" is equivalent to
+   "Foo-1510-Equiv", shown below.
+
+
+
+
+
+Yu                          Expires: Jan 2005                   [Page 9]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- example type equivalent to Foo-1510
+      Foo-1510-Equiv  ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING
+      }
+
+
+
+6.  Basic Types
+
+
+   Certain ASN.1 types in Kerberos appear repeatedly in other Kerberos
+   types.
+
+
+6.1.  Constrained Integer Types
+
+
+   In RFC 1510, many types contained references to the unconstrained
+   INTEGER type.  Since an unconstrained INTEGER may contain any
+   possible abstract integer value, most of the unconstrained references
+   to INTEGER in RFC 1510 have been constrained to 32 bits or smaller.
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+   The "Int32" type often contains an assigned number identifying the
+   type of a protocol element.  Unless otherwise stated, non-negative
+   values are registered, and negative values are available for local
+   use.
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+   The "UInt64" type is used in places where 32 bits of precision may
+   provide inadequate security.
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+   While these types have different abstract types from their
+   equivalents in RFC 1510, their DER encodings remain identical.
+
+
+Yu                          Expires: Jan 2005                  [Page 10]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   Nonces and sequence numbers are constrained to 32 bits in the
+   RFC 1510 backwards-compatibility types.
+
+
+6.2.  KerberosTime
+
+
+      -- must not have fractional seconds
+      KerberosTime    ::= GeneralizedTime
+
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
+   KerberosTime value MUST NOT include any fractional portions of the
+   seconds.  As required by the DER, it further MUST NOT include any
+   separators, and it specifies the UTC time zone (Z).  Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is "19851106210627Z".
+
+
+6.3.  KerberosString
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+   The KerberosString type is used for strings in various places in the
+   Kerberos protocol.  For compatibility with RFC 1510, GeneralString
+   values constrained to IA5String (US-ASCII) are permitted in messages
+   exchanged with RFC 1510 implementations.  The new protocol messages
+   contain strings encoded as UTF-8.  KerberosString values are present
+   in principal names and in error messages.  Control characters SHOULD
+   NOT be used in principal names, and used with caution in error
+   messages.
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+   KerberosStringIA5 and KerberosStringExt respectively force and forbid
+   the use of the "ia5" alternative.  These types are used as
+   constraints on other types for backwards compatibility purposes.
+
+
+   For detailed background regarding the history of character string use
+   in Kerberos, as well as discussion of some compatibility issues, see
+   Appendix B.
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 11]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+7.  Principals
+
+
+   Principals are participants in the Kerberos protocol.  A "realm"
+   consists of principals in one administrative domain, served by one
+   KDC (or one replicated set of KDCs).  Each principal name has an
+   arbitrary number of components, though typical principal names will
+   only have one or two components.  A principal name is meant to be
+   readable by and meaningful to humans, especially in a realm lacking a
+   centrally adminstered authorization infrastructure.
+
+
+7.1.  Name Types
+
+
+   Each Principal has NameType indicating what sort of name it is.  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).
+
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+
+7.2.  Principal Type Definition
+
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is not recommended.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 12]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   name-type
+        hint of the type of name that follows
+
+
+   name-string
+        The "name-string" encodes a sequence of components that form a
+        name, each component encoded as a KerberosString.  Taken
+        together, a PrincipalName and a Realm form a principal
+        identifier.  Most PrincipalNames will have only a few components
+        (typically one or two).
+
+
+7.3.  Principal Name Reuse
+
+
+   Realm administrators SHOULD use extreme caution when considering
+   reusing a principal name.  A service administrator might explicitly
+   enter principal names into a local access control list (ACL) for the
+   service.  If such local ACLs exist independently of a centrally
+   administered authorization infrastructure, realm administrators
+   SHOULD NOT reuse principal names until confirming that all extant ACL
+   entries referencing that principal name have been updated.  Failure
+   to perform this check can result in a security vulnerability, as a
+   new principal can inadvertently inherit unauthorized privileges upon
+   receiving a reused principal name.  An organization whose Kerberos-
+   authenticated services all use a centrally-adminstered authorization
+   infrastructure may not need to take these precautions regarding
+   principal name reuse.
+
+
+7.4.  Realm Names
+
+
+      Realm           ::= KerberosString
+
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+
+   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
+   character with the code 0 (the US-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.
+
+
+7.5.  Printable Representations of Principal Names
+
+
+   [ perhaps non-normative? ]
+
+
+   The printable form of a principal name consists of the concatenation
+   of components of the PrincipalName value using the slash character
+   (/), followed by an at-sign (@), followed by the realm name.
+
+
+
+Yu                          Expires: Jan 2005                  [Page 13]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+7.6.  Ticket-Granting Service Principal
+
+
+   The PrincipalName value corresponding to a ticket-granting service
+   has two components: the first component is the string "krbtgt", and
+   the second component is the realm name of the TGS which will accept a
+   ticket-granting ticket having this service principal name.  The realm
+   name of service always indicates which realm issued the ticket.  A
+   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
+   obtaining tickets in the same realm would have the following ASN.1
+   values for its "realm" and "sname" components, respectively:
+
+
+      -- Example Realm and PrincipalName for a TGS
+
+
+      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
+
+
+      tgtPrinc1       PrincipalName ::= {
+          name-type nt-srv-inst,
+          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
+      }
+
+
+   Its printable representation would be written as
+   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
+
+
+7.6.1.  Cross-Realm TGS Principals
+
+
+   It is possible for a principal in one realm to authenticate to a
+   service in another realm.  A KDC can issue a cross-realm ticket-
+   granting ticket to allow one of its principals to authenticate to a
+   service in a foreign realm.  For example, the TGS principal
+   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
+   client principal in the realm A.EXAMPLE.COM to authenticate to a
+   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
+   issues a ticket to a client originating in A.EXAMPLE.COM, the
+   client's realm name remains "A.EXAMPLE.COM", even though the service
+   principal will have the realm "B.EXAMPLE.COM".
+
+
+8.  Types Relating to Encryption
+
+
+   Many Kerberos protocol messages contain encryptions of various data
+   types.  Kerberos protocol messages also contain checksums
+   (signatures) of various types.
+
+
+8.1.  Assigned Numbers for Encryption
+
+
+   Encryption algorithm identifiers and key usages both have assigned
+   numbers, described in [KCRYPTO].
+
+
+8.1.1.  EType
+
+
+   EType is the integer type for assigned numbers for encryption
+   algorithms.  Defined in [KCRYPTO].
+
+
+Yu                          Expires: Jan 2005                  [Page 14]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+8.1.2.  Key Usages
+
+
+   KeyUsage is the integer type for assigned numbers for key usages.
+   Key usage values are inputs to the encryption and decryption
+   functions described in [KCRYPTO].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 15]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+8.2.  Which Key to Use
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 16]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+
+8.3.  EncryptionKey
+
+
+   The "EncryptionKey" type holds an encryption key.
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+   keytype
+        This "EType" identifies the encryption algorithm, described in
+        [KCRYPTO].
+
+
+   keyvalue
+        Contains the actual key.
+
+
+8.4.  EncryptedData
+
+
+   The "EncryptedData" type contains the encryption of another data
+   type.  The recipient uses fields within EncryptedData to determine
+   which key to use for decryption.
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 17]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+
+   KeyUsages
+        Advisory parameter indicating which key usage to use when
+        encrypting the ciphertext.  If "KeyUsages" indicate multiple
+        "KeyUsage" values, the detailed description of the containing
+        message will indicate which key to use under which conditions.
+
+
+   Type
+        Advisory parameter indicating the ASN.1 type whose DER encoding
+        is the plaintext encrypted into the EncryptedData.
+
+
+   Keys
+        Advisory parameter indicating which key to use to perform the
+        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
+        detailed description of the containing message will indicate
+        which key to use under which conditions.
+
+
+   KeyUsages
+        Advisory parameter indicating which "KeyUsage" value is used to
+        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
+        the detailed description of the containing message will indicate
+        which key usage to use under which conditions.
+
+
+8.5.  Checksums
+
+
+   Several types contain checksums (actually signatures) of data.
+
+
+
+Yu                          Expires: Jan 2005                  [Page 18]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      CksumType       ::= Int32
+
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+   CksumType
+        Integer type for assigned numbers for signature algorithms.
+        Defined in [KCRYPTO]
+
+
+   Keys
+        As in EncryptedData
+
+
+   KeyUsages
+        As in EncryptedData
+
+
+   cksumtype
+        Signature algorithm used to produce the signature.
+
+
+   checksum
+        The actual checksum.
+
+
+8.5.1.  ChecksumOf
+
+
+   ChecksumOf is like "Checksum", but specifies which type is signed.
+
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 19]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   Type
+        Indicates the ASN.1 type whose DER encoding is signed.
+
+
+8.5.2.  Signed
+
+
+   Signed is like "ChecksumOf", but contains an actual instance of the
+   type being signed in addition to the signature.
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+
+9.  Tickets
+
+
+   [ A large number of items described here are duplicated in the
+   sections describing KDC-REQ processing.  Should find a way to avoid
+   this duplication. ]
+
+
+   A ticket binds a principal name to a session key.  The important
+   fields of a ticket are in the encrypted part.  The components in
+   common between the RFC 1510 and the extensible versions are
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+   crealm
+        This field contains the client's realm.
+
+
+   cname
+        This field contains the client's name.
+
+
+Yu                          Expires: Jan 2005                  [Page 20]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   caddr
+        This field lists the network addresses (if absent, all addresses
+        are permitted) from which the ticket is valid.
+
+
+   Descriptions of the other fields appear in the following sections.
+
+
+9.1.  Timestamps
+
+
+   Three of the ticket timestamps may be requested from the KDC.  The
+   timestamps may differ from those requested, depending on site policy.
+
+
+   authtime
+        The time at which the client authenticated, as recorded by the
+        KDC.
+
+
+   starttime
+        The earliest time when the ticket is valid.  If not present, the
+        ticket is valid starting at the authtime.  This is requested as
+        the "from" field of KDC-REQ-BODY-COMMON.
+
+
+   endtime
+        This time is requested in the "till" field of KDC-REQ-BODY-
+        COMMON.  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 time is requested in the "rtime" field of KDC-REQ-BODY-
+        COMMON.  It 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.
+
+
+9.2.  Ticket Flags
+
+
+   A number of flags may be set in the ticket, further defining some of
+   its capabilities.  Some of these flags map to flags in a KDC request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 21]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+
+9.2.1.  Flags Relating to Initial Ticket Acquisition
+
+
+   [ adapted KCLAR 2.1. ]
+
+
+   Several flags indicate the details of how the initial ticket was
+   acquired.
+
+
+   initial
+        The "initial" flag indicates that a ticket was issued using the
+        AS protocol, rather than issued based on a ticket-granting
+        ticket.  Application servers (e.g., a password-changing program)
+        requiring a client's definite knowledge of its secret key can
+        insist that this flag be set in any tickets they accept, thus
+        being assured that the client's key was recently presented to
+        the application client.
+
+
+   pre-authent
+        The "pre-authent" flag indicates that some sort of pre-
+        authentication was used during the AS exchange.
+
+
+   hw-authent
+        The "hw-authent" flag indicates that some sort of hardware-based
+        pre-authentication occurred during the AS exchange.
+
+
+   Both the "pre-authent" and the "hw-authent" flags may be present with
+   or without the "initial" flag; such tickets with the "initial" flag
+   clear are ones which are derived from initial tickets with the "pre-
+   authent" or "hw-authent" flags set.
+
+
+
+Yu                          Expires: Jan 2005                  [Page 22]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+9.2.2.  Invalid Tickets
+
+
+   [ KCLAR 2.2. ]
+
+
+   The "invalid" flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets which have this flag set.  A postdated
+   ticket will 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 10.3.2.4).
+
+
+9.2.3.  OK as Delegate
+
+
+   [ KCLAR 2.8. ]
+
+
+   The "ok-as-delegate" flag provides a way for a KDC to communicate
+   local realm policy to a client regarding whether the service for
+   which the ticket is issued is trusted to accept delegated
+   credentials.  For some applications, a client may need to delegate
+   credentials to a service to act on its behalf in contacting other
+   services.  The ability of a client to obtain a service ticket for a
+   service conveys no information to the client about whether the
+   service should be trusted to accept delegated credentials.
+
+
+   The copy of the ticket flags visible to the client may have the "ok-
+   as-delegate" flag set to indicate to the client that the service
+   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 service.  It is acceptable 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.
+
+
+9.3.  Renewable Tickets
+
+
+   [ adapted KCLAR 2.3. ]
+
+
+   The "renewable" flag indicates whether the ticket may be renewed.
+
+
+   Renewable tickets can be used to mitigate the consequences of ticket
+   theft.  Applications may desire to hold credentials which can be
+   valid for long periods of time.  However, this can expose the
+   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
+
+
+Yu                          Expires: Jan 2005                  [Page 23]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   periodically would require the application to have long-term access
+   to the client's secret key, which is an even greater risk.
+
+
+   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 present an unexpired renewable ticket to the
+   KDC, setting the "renew" option 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.  It can usually be ignored by application
+   servers.  However, some particularly careful application servers MAY
+   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 clear by default,
+   but a client can request it be set by setting the "renewable" option
+   in the 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.
+
+
+9.4.  Postdated Tickets
+
+
+   postdated
+        indicates a ticket which has been postdated
+
+
+   may-postdate
+        indicates that postdated tickets may be issued based on this
+        ticket
+
+
+   [ KCLAR 2.4. ]
+
+
+   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.
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 24]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   The "may-postdate" flag in a ticket is normally only interpreted by
+   the TGS.  It can be ignored by application servers.  This flag MUST
+   be set in a ticket-granting ticket in order for the KDC 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 AS-REQ [?also TGS-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 AS-REQ message.  The life (endtime minus
+   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 minus 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 for
+   validation before use.
+
+
+9.5.  Proxiable and Proxy Tickets
+
+
+   proxy
+        indicates a proxy ticket
+
+
+   proxiable
+        indicates that proxy tickets may be issued based on this ticket
+
+
+   [ KCLAR 2.5. ]
+
+
+   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, users wishing to delegate their
+   identity in a form usable for all purposes 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
+
+
+Yu                          Expires: Jan 2005                  [Page 25]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   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 may contain a set of network addresses from which they are
+   valid.  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.
+
+
+9.6.  Forwardable Tickets
+
+
+   forwarded
+        indicates a forwarded ticket
+
+
+   forwardable
+        indicates that forwarded tickets may be issued based on this
+        ticket
+
+
+   [ KCLAR 2.6. ]
+
+
+   Authentication forwarding is an instance of a proxy where the service
+   that is granted is 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
+
+
+Yu                          Expires: Jan 2005                  [Page 26]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   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.
+
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+
+9.7.  Transited Realms
+
+
+   [ KCLAR 2.7., plus new stuff ]
+
+
+9.8.  Authorization Data
+
+
+9.9.  Encrypted Part of Ticket
+
+
+   The complete definition of the encrypted part is
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+Yu                          Expires: Jan 2005                  [Page 27]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+9.10.  Cleartext Part of Ticket
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+10.  Credential Acquisition
+
+
+   There are two exchanges that can be used for acquiring credentials:
+   the AS exchange and the TGS exchange.  These exchanges have many
+   similarities, and this document describes them in parallel, noting
+
+
+Yu                          Expires: Jan 2005                  [Page 28]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   which behaviors are specific to one type of exchange.  The AS request
+   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
+   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
+   are forms of KDC replies (KDC-REP).
+
+
+10.1.  KDC-REQ
+
+
+   The KDC-REQ has a large number of fields in common between the RFC
+   1510 and the extensible versions.
+
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 29]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+      }
+
+
+
+   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
+   an EncTicketPartCommon.  The KDC copies most of them unchanged,
+   provided that their values meet site policy.
+
+
+   kdc-options
+        These flags do not correspond directly to "flags" in
+        EncTicketPartCommon.
+
+
+   cname
+        This field is copied to the "cname" field in
+        EncTicketPartCommon.  The "cname" field is required in an AS-
+        REQ; the client places its own name here.  In a TGS-REQ, the
+        "cname" in the ticket in the AP-REQ takes precedence.
+
+
+   realm
+        This field is the server's realm, and also holds the client's
+        realm in an AS-REQ.
+
+
+
+Yu                          Expires: Jan 2005                  [Page 30]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   sname
+        The "sname" field indicates the server's name.  It may be absent
+        in a TGS-REQ which requests user-to-user authentication, in
+        which case the "sname" of the issued ticket will be taken from
+        the included additional ticket.
+
+
+   The "from", "till", and "rtime" fields correspond to the "starttime",
+   "endtime", and "renew-till" fields of EncTicketPartCommon.
+
+
+   addresses
+        This field corresponds to the "caddr" field of
+        EncTicketPartCommon.
+
+
+   enc-authorization-data
+        For TGS-REQ, this field contains authorization data encrypted
+        using either the TGT session key or the AP-REQ subsession key;
+        the KDC may copy these into the "authorization-data" field of
+        EncTicketPartCommon if policy permits.
+
+
+10.2.  PA-DATA
+
+
+   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
+   authenticate an AS-REQ; they may also modify several of the
+   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
+   to the client about which long-term key (usually password-derived) to
+   use.  PA-DATA may also include "hints" about which pre-authentication
+   mechanisms to use, or include data for input into a pre-
+   authentication mechanism.
+
+
+10.3.  KDC-REQ Processing
+
+
+   Processing of a KDC-REQ proceeds through several steps.  An
+   implementation need not perform these steps exactly as described, as
+   long as it behaves as if the steps were performed as described.  The
+   KDC performs replay handling upon receiving the request; it then
+   validates the request, adjusts timestamps, and selects the keys used
+   in the reply.  It copies data from the request into the issued
+   ticket, adjusting the values to conform with its policies.  The KDC
+   then transmits the reply to the client.
+
+
+10.3.1.  Handling Replays
+
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+   successfully processed, the KDC MUST respond with a KDC-REP message
+   rather than a replay error.  In order to reduce the amount of
+   ciphertext given to a potential attacker, KDCs MAY send the same
+   response generated when the request was first handled.  KDCs MUST
+   obey this replay behavior even if the actual transport in use is
+   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
+
+
+Yu                          Expires: Jan 2005                  [Page 31]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   and the entire request is not identical to a recently successfully
+   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
+   appropriate for AP-REQ processing.
+
+
+10.3.2.  Request Validation
+
+
+10.3.2.1.  AS-REQ Authentication
+
+
+   Site policy determines whether a given client principal is required
+   to provide some pre-authentication prior to receiving an AS-REP.
+   Since the default reply key is typically the client's long-term
+   password-based key, an attacker may easily request known plaintext
+   (in the form of an AS-REP) upon which to mount a dictionary attack.
+   Pre-authentication can limit the possibility of such an attack.
+
+
+   If site policy requires pre-authentication for a client principal,
+   and no pre-authentication is provided, the KDC returns the error
+   "kdc-err-preauth-required".  Accompanying this error are "e-data"
+   which include hints telling the client which pre-authentication
+   mechanisms to use, or data for input to pre-authentication mechanisms
+   (e.g., input to challenge-response systems).  If pre-authentication
+   fails, the KDC returns the error "kdc-err-preauth-failed".
+
+
+   [ may need additional changes based on Sam's preauth draft ]
+
+
+10.3.2.2.  TGS-REQ Authentication
+
+
+   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
+   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
+   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
+   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
+   request.  [ padata not signed by authenticator! ] Any error from the
+   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
+   The service principal in the ticket of the AP-REQ may be a ticket-
+   granting service principal, or a normal application service
+   principal.  A ticket which is not a ticket-granting ticket MUST NOT
+   be used to issue a ticket for any service other than the one named in
+   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
+   forwarded?]  option must be set in the request.
+
+
+10.3.2.3.  Principal Validation
+
+
+   If the client principal in an AS-REQ is unknown, the KDC returns the
+   error "kdc-err-c-principal-unknown".  If the server principal in a
+   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
+   unknown".
+
+
+10.3.2.4.  Checking For Revoked or Invalid Tickets
+
+
+   [ KCLAR 3.3.3.1 ]
+
+
+
+Yu                          Expires: Jan 2005                  [Page 32]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   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 to the KDC for the realm in which
+   the server resides.  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.  If TGTs have been issued for cross-realm authentication, use
+   of the cross-realm TGT will not be affected unless the hot-list is
+   propagated to the KDCs for the realms for which such cross-realm
+   tickets were issued.
+
+
+   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
+   issue any ticket unless the TGS-REQ requests the "validate" option.
+
+
+10.3.3.  Timestamp Handling
+
+
+   [ some aspects of timestamp handling, especially regarding postdating
+   and renewal, are difficult to read in KCLAR... needs closer
+   examination here ]
+
+
+   Processing of "starttime" (requested in the "from" field) differs
+   depending on whether the "postdated" option is set in the request.
+   If the "postdated" option is not set, and the requested "starttime"
+   is in the future beyond the window of acceptable clock skew, the KDC
+   returns the error "kdc-err-cannot-postdate".  If the "postdated"
+   option is not set, and the requested "starttime" is absent or does
+   not indicate a time in the future beyond the acceptable clock skew,
+   the KDC sets the "starttime" to the KDC's current time.  The
+   "postdated" option MUST NOT be honored if the ticket is being
+   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
+   Otherwise, if the "postdated" option is set, and site policy permits,
+   the KDC sets the "starttime" as requested, and sets the "invalid"
+   flag in the new ticket.
+
+
+   The "till" field is required in the RFC 1510 version of the KDC-REQ.
+   If the "till" field is equal to "19700101000000Z" (midnight, January
+   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
+
+
+   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
+   "renew-till" time is later than the "renew-till" time of the ticket
+   from which it is derived.
+
+
+10.3.3.1.  AS-REQ Timestamp Processing
+
+
+   In the AS exchange, the "authtime" of a ticket is set to the local
+   time at the KDC.
+
+
+Yu                          Expires: Jan 2005                  [Page 33]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   The "endtime" of the ticket will be set to the earlier of the
+   requested "till" time and a time determined by local policy, possibly
+   determined using factors specific to the realm or principal.  For
+   example, the expiration time MAY be set to the earliest of the
+   following:
+
+
+      * the expiration time ("till" value) requested
+
+
+      * the ticket's start time plus the maximum allowable lifetime
+        associated with the client principal from the authentication
+        server's database
+
+
+      * 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.
+
+
+   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 MAY be set to the earliest 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
+
+
+10.3.3.2.  TGS-REQ Timestamp Processing
+
+
+   In the TGS exchange, the KDC sets the "authtime" to that of the
+   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
+   server can print a ticket for itself with a spoofed authtime.
+   security issues for hot-list?] [ MIT implementation may change
+   authtime of renewed tickets; needs check... ]
+
+
+   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
+   requests an "endtime" (in the "till" field), then the "endtime" of
+   the new ticket is set to the minimum of
+
+
+
+Yu                          Expires: Jan 2005                  [Page 34]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      * the requested "endtime" value,
+
+
+      * the "endtime" in the TGT, and
+
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+
+   If the new ticket is a renewal, the "endtime" of the new ticket is
+   bounded by the minimum of
+
+
+      * the requested "endtime" value,
+
+
+      * the value of the "renew-till" value of the old,
+
+
+      * the "starttime" of the new ticket plus the lifetime (endtime
+        minus starttime) of the old ticket, i.e., the lifetime of the
+        new ticket may not exceed that of the ticket being renewed [
+        adapted from KCLAR 3.3.3. ], and
+
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+
+   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
+   a "starttime", "endtime", or "renew-till" time later than the "renew-
+   till" time of the TGT.
+
+
+10.3.4.  Handling Transited Realms
+
+
+   The KDC checks the ticket in a TGS-REQ against site policy, unless
+   the "disable-transited-check" option is set in the TGS-REQ.  If site
+   policy permits the transit path in the TGS-REQ ticket, the KDC sets
+   the "transited-policy-checked" flag in the issued ticket.  If the
+   "disable-transited-check" option is set, the issued ticket will have
+   the "transited-policy-checked" flag cleared.
+
+
+10.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
+   copied into the issued ticket.  If the "addresses" field is absent or
+   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
+   TGS-REQ into the issued ticket, unless the either "forwarded" or
+   "proxy" option is set.  If the "forwarded" option is set, and the
+   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
+   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
+   issued ticket.  The KDC behaves similarly if the "proxy" option is
+   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
+   The "proxy" option will not be honored on requests for additional
+   ticket-granting tickets.
+
+
+10.3.6.  Ticket Flag Processing
+
+
+   Many kdc-options request that the KDC set a corresponding flag in the
+   issued ticket.  kdc-options marked with an asterisk (*) in the
+   following table do not directly request the corresponding ticket flag
+   and therefore require special handling.
+
+
+Yu                          Expires: Jan 2005                  [Page 35]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+                                     |
+                   kdc-option        |   ticket flag affected
+            -------------------------+--------------------------
+            forwardable              | forwardable
+            forwarded                | forwarded
+            proxiable                | proxiable
+            proxy                    | proxy
+            allow-postdate           | may-postdate
+            postdated                | postdated
+            renewable                | renewable
+            requestanonymous         | anonymous
+            canonicalize             | -
+            disable-transited-check* | transited-policy-checked
+            renewable-ok*            | renewable
+            enc-tkt-in-skey          | -
+            renew                    | -
+            validate*                | invalid
+
+
+
+   forwarded
+        The KDC sets the "forwarded" flag in the issued ticket if the
+        "forwarded" option is set in the TGS-REQ and the "forwardable"
+        flag is set in the TGS-REQ ticket.
+
+
+   proxy
+        The KDC sets the "proxy" flag in the issued ticket if the
+        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
+        set in the TGS-REQ ticket.
+
+
+   disable-transited-check
+        The handling of the "disable-transited-check" kdc-option is
+        described in Section 10.3.4.
+
+
+   renewable-ok
+        The handling of the "renewable-ok" kdc-option is described in
+        Section 10.3.3.1.
+
+
+   validate
+        If the "validate" kdc-option is set in a TGS-REQ, and the
+        "starttime" has passed, the KDC will clear the "invalid" bit on
+        the ticket before re-issuing it.
+
+
+10.3.7.  Key Selection
+
+
+   Three keys are involved in creating a KDC-REP.  The reply key
+   encrypts the encrypted part of the KDC-REP.  The session key is
+   stored in the encrypted part of the ticket, and is also present in
+   the encrypted part of the KDC-REP so that the client can retrieve it.
+   The ticket key is used to encrypt the ticket.  These keys all have
+   initial values for a given exchange; pre-authentication and other
+   extension mechanisms may change the value used for any of these keys.
+
+
+
+Yu                          Expires: Jan 2005                  [Page 36]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   [ again, may need changes based on Sam's preauth draft ]
+
+
+10.3.7.1.  Reply Key and Session Key Selection
+
+
+   The set of encryption types which the client will understand appears
+   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
+   of possible reply keys and the set of session key encryption types
+   based on the "etype" field.
+
+
+   For the AS exchange, the reply key is initially a long-term key of
+   the client, limited to those encryption types listed in the "etype"
+   field.  The KDC SHOULD use the first valid strong "etype" for which
+   an encryption key is available.  For the TGS exchange, the reply key
+   is initially the subsession key of the Authenticator.  If the
+   Authenticator subsesion key is absent, the reply key is initially the
+   session key of the ticket used to authenticate the TGS-REQ.
+
+
+   The session key is initially randomly generated, and has an
+   encryption type which both the client and the server will understand.
+   Typically, the KDC has prior knowledge of which encryption types the
+   server will understand.  It selects the first valid strong "etype"
+   listed the request which the server also will understand.
+
+
+10.3.7.2.  Ticket Key Selection
+
+
+   The ticket key is initially the long-term key of the service.  The
+   "enc-tkt-in-skey" option requests user-to-user authentication, where
+   the ticket encryption key of the issued ticket is set equal to the
+   session key of the additional ticket in the request.
+
+
+10.4.  Reply Validation
+
+
+11.  Session Key Exchange
+
+
+   Session key exchange consists of the AP-REQ and AP-REP messages.  The
+   client sends the AP-REQ message, and the service responds with an AP-
+   REP message if mutual authentication is desired.  Following session
+   key exchange, the client and service share a secret session key, or
+   possibly a subsesion key, which can be used to protect further
+   communications.  Additionally, the session key exchange process can
+   establish initial sequence numbers which the client and service can
+   use to detect replayed messages.
+
+
+11.1.  AP-REQ
+
+
+   An AP-REQ message contains a ticket and a authenticator.  The
+   authenticator is ciphertext encrypted with the session key contained
+   in the ticket.  The plaintext contents of the authenticator are:
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 37]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+   The common parts between the RFC 1510 and the extensible versions of
+   the AP-REQ are:
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          ...
+      }
+
+
+   The complete definition of AP-REQ is:
+
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 38]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 39]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+
+11.2.  AP-REP
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 40]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+
+12.  Session Key Use
+
+
+12.1.  KRB-SAFE
+
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 41]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+12.2.  KRB-PRIV
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+12.3.  KRB-CRED
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 42]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+
+13.  Security Considerations
+
+
+13.1.  Time Synchronization
+
+
+   Time synchronization between the KDC and application servers is
+   necessary to prevent acceptance of expired tickets.
+
+
+Yu                          Expires: Jan 2005                  [Page 43]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   Time synchronization is needed between application servers and
+   clients to prevent replay attacks if a replay cache is being used.
+   If negotiated subsession keys are used to encrypt application data,
+   replay caches may not be necessary.
+
+
+13.2.  Replays
+
+
+13.3.  Principal Name Reuse
+
+
+   See Section 7.3.
+
+
+13.4.  Password Guessing
+
+
+13.5.  Forward Secrecy
+
+
+   [from KCLAR 10.; needs some rewriting]
+
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB-PRIV message,
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the TGS-REP
+   message.  The session key from the ticket-granting ticket was sent to
+   the user in the AS-REP message encrypted in the user's secret key,
+   and embedded in the ticket-granting ticket, which was encrypted in
+   the key of the KDC.  Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+
+13.6.  Authorization
+
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  Kerberos does not, by
+   itself, provide authorization.  Applications SHOULD NOT accept the
+   mere issuance of a service ticket by the Kerberos server as granting
+   authority to use the service.
+
+
+13.7.  Login Authentication
+
+
+   Some applications, particularly those which provide login access when
+   provided with a password, SHOULD NOT treat successful acquisition of
+   credentials as sufficient proof of the user's identity.  An attacker
+   posing as a user could generate an illegitimate KDC-REP message which
+   decrypts properly.  To authenticate a user logging on to a local
+   system, the credentials obtained SHOULD be used in a TGS exchange to
+
+
+Yu                          Expires: Jan 2005                  [Page 44]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   obtain credentials for a local service.  Successful use of those
+   credentials to authenticate to the local service assures that the
+   initially obtained credentials are from a valid KDC.
+
+
+14.  Acknowledgments
+
+
+   Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-06.
+
+
+Appendices
+
+
+A.  ASN.1 Module (Normative)
+
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related
+      -- OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
+      -- OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2)
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 45]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+
+      --
+      -- *** basic types
+      --
+
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+
+Yu                          Expires: Jan 2005                  [Page 46]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- must not have fractional seconds
+      KerberosTime    ::= GeneralizedTime
+
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 47]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is not recommended.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+
+      -- IA5 only
+      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringIA5))
+      })
+
+
+      -- IA5 excluded
+      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringExt))
+      })
+
+
+
+      Realm           ::= KerberosString
+
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+
+      -- Yet another refinement to kludge around historical
+      -- implementation bugs... we still send at least 32 bits, but
+      -- this parameterized type allows us to actually use named bit
+      -- string syntax to define flags, sort of.
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- must be a valid value of -- NamedBits
+          -- but if the value to be sent would otherwise be shorter
+          -- than 32 bits, it must be padded with trailing zero bits
+          -- to 32 bits.  Otherwise, no trailing zero bits may be
+          -- present.
+      })
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 48]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      AddrType        ::= Int32
+
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+
+      --
+      -- *** crypto-related types and assignments
+      --
+
+
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 49]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 50]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 51]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+
+      CksumType       ::= Int32
+
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 52]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+
+      --
+      -- *** Tickets
+      --
+
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+
+Yu                          Expires: Jan 2005                  [Page 53]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 54]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+
+      --
+      -- *** Authorization Data
+      --
+
+
+
+      ADType          ::= Int32
+
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+
+      ad-if-relevant          ADType ::= 1
+
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      AD-IF-RELEVANT          ::= AuthorizationData
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 55]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= 4
+
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+
+      ad-and-or               ADType ::= 5
+
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+
+
+      TrType                  ::= Int32 -- must be registered
+
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+          tr-type     [0] TrType,
+          contents    [1] OCTET STRING
+      }
+
+
+
+      TEType                  ::= Int32
+
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 56]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+
+      --
+      -- *** KDC protocol
+      --
+
+
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+
+Yu                          Expires: Jan 2005                  [Page 57]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 58]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+      }
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 59]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 60]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+      KDCOptionsBits ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+
+      AS-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 11] KDC-REP-1510 {
+              EncASRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (11) }),
+          ext         [APPLICATION  7]  Signed {
+              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+              { key-reply }, { ku-ASRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (7) })
+      }
+
+
+
+      TGS-REP         ::= CHOICE {
+          rfc1510     [APPLICATION 13] KDC-REP-1510 {
+              EncTGSRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (13) }),
+          ext         [APPLICATION  9]  Signed {
+              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+              { key-reply }, { ku-TGSRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (9) })
+      }
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 61]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks agaginst client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+Yu                          Expires: Jan 2005                  [Page 62]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+      LRType          ::=     Int32
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+          lr-type     [0] LRType,
+          lr-value    [1] KerberosTime
+      }
+
+
+
+      --
+      -- *** preauth
+      --
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 63]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      PaDataType      ::= Int32
+      PaDataOID       ::= RELATIVE-OID
+
+
+      PA-DATA ::= SEQUENCE {
+          -- NOTE: first tag is [1], not [0]
+          padata-type         [1] CHOICE {
+                              int     PaDataType,
+                              -- example of possible use
+                              -- of RELATIVE-OIDs
+                              oid     PaDataOID
+          },
+          padata-value        [2] OCTET STRING
+      }
+
+
+
+      PaDataSet PADATA-OBJ ::= {
+          pa-tgs-req |
+          pa-enc-timestamp |
+          pa-etype-info |
+          pa-etype-info2 |
+          pa-pw-salt |
+          pa-as-req ,
+          ...
+      }
+
+
+
+      -- AP-REQ authenticating a TGS-REQ
+      pa-tgs-req              PaDataType ::= 1
+      PA-TGS-REQ              ::= AP-REQ
+
+
+
+      -- Encrypted timestamp preauth
+      -- Encryption key used is client's long-term key.
+      pa-enc-timestamp        PaDataType ::= 2
+
+
+      PA-ENC-TIMESTAMP ::= EncryptedData {
+          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
+      }
+
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 64]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Hints returned in AS-REP or KRB-ERROR to help client
+      -- choose a password-derived key, either for preauthentication
+      -- or for decryption of the reply.
+      pa-etype-info           PaDataType ::= 11
+
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+
+
+      -- Similar to etype-info, but with parameters provided for
+      -- the string-to-key function.
+      pa-etype-info2          PaDataType ::= 19
+
+
+      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
+                                      OF ETYPE-INFO-ENTRY
+
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+
+
+      -- Obsolescent.  Salt for client's long-term key.
+      -- Its character encoding is unspecified.
+      pa-pw-salt              PaDataType ::= 3
+      -- The "padata-value" does not encode an ASN.1 type.
+      -- Instead, "padata-value" must consist of the salt string to
+      -- be used by the client, in an unspecified character
+      -- encoding.
+      }
+
+
+
+      -- An extensible AS-REQ may be sent as a padata in a
+      -- non-extensible AS-REQ to allow for backwards compatibility.
+      pa-as-req               PaDataType ::= 42 -- provisional
+      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
+
+
+
+      --
+      -- *** Session key exchange
+      --
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 65]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 66]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+      ApReqExtType    ::= Int32
+
+
+      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apReqExt-Type       [0] ApReqExtType,
+          apReqExt-Data       [1] OCTET STRING
+      }
+
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 67]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+
+      ApRepExtType    ::= Int32
+
+
+      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apRepExt-Type       [0] ApRepExtType,
+          apRepExt-Data       [1] OCTET STRING
+      }
+
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 68]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+
+      --
+      -- *** Application messages
+      --
+
+
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 69]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+Yu                          Expires: Jan 2005                  [Page 70]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+
+      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
+          pvno            [0] INTEGER (5),
+          msg-type        [1] INTEGER (16),
+          sname           [2] PrincipalName OPTIONAL,
+          srealm          [3] Realm OPTIONAL,
+          ...
+      }
+
+
+
+      --
+      -- *** Error messages
+      --
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 71]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      ErrCode ::= Int32
+
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+
+      TDType ::= Int32
+
+
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+          data-type   [0] TDType,
+          data-value  [1] OCTET STRING OPTIONAL
+      }
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 72]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      --
+      -- *** Error codes
+      --
+
+
+      -- No error
+      kdc-err-none                          ErrCode ::= 0
+      -- Client's entry in database has expired
+      kdc-err-name-exp                      ErrCode ::= 1
+      -- Server's entry in database has expired
+      kdc-err-service-exp                   ErrCode ::= 2
+      -- Requested protocol version number not supported
+      kdc-err-bad-pvno                      ErrCode ::= 3
+      -- Client's key encrypted in old master key
+      kdc-err-c-old-mast-kvno               ErrCode ::= 4
+      -- Server's key encrypted in old master key
+      kdc-err-s-old-mast-kvno               ErrCode ::= 5
+      -- Client not found in Kerberos database
+      kdc-err-c-principal-unknown           ErrCode ::= 6
+      -- Server not found in Kerberos database
+      kdc-err-s-principal-unknown           ErrCode ::= 7
+      -- Multiple principal entries in database
+      kdc-err-principal-not-unique          ErrCode ::= 8
+      -- The client or server has a null key
+      kdc-err-null-key                      ErrCode ::= 9
+      -- Ticket not eligible for postdating
+      kdc-err-cannot-postdate               ErrCode ::= 10
+      -- Requested start time is later than end time
+      kdc-err-never-valid                   ErrCode ::= 11
+      -- KDC policy rejects request
+      kdc-err-policy                        ErrCode ::= 12
+      -- KDC cannot accommodate requested option
+      kdc-err-badoption                     ErrCode ::= 13
+      -- KDC has no support for encryption type
+      kdc-err-etype-nosupp                  ErrCode ::= 14
+      -- KDC has no support for checksum type
+      kdc-err-sumtype-nosupp                ErrCode ::= 15
+      -- KDC has no support for padata type
+      kdc-err-padata-type-nosupp            ErrCode ::= 16
+      -- KDC has no support for transited type
+      kdc-err-trtype-nosupp                 ErrCode ::= 17
+      -- Clients credentials have been revoked
+      kdc-err-client-revoked                ErrCode ::= 18
+      -- Credentials for server have been revoked
+      kdc-err-service-revoked               ErrCode ::= 19
+      -- TGT has been revoked
+      kdc-err-tgt-revoked                   ErrCode ::= 20
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 73]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Client not yet valid - try again later
+      kdc-err-client-notyet                 ErrCode ::= 21
+      -- Server not yet valid - try again later
+      kdc-err-service-notyet                ErrCode ::= 22
+      -- Password has expired - change password to reset
+      kdc-err-key-expired                   ErrCode ::= 23
+      -- Pre-authentication information was invalid
+      kdc-err-preauth-failed                ErrCode ::= 24
+      -- Additional pre-authenticationrequired
+      kdc-err-preauth-required              ErrCode ::= 25
+      -- Requested server and ticket don't match
+      kdc-err-server-nomatch                ErrCode ::= 26
+      -- Server principal valid for user2user only
+      kdc-err-must-use-user2user            ErrCode ::= 27
+      -- KDC Policy rejects transited path
+      kdc-err-path-not-accpeted             ErrCode ::= 28
+      -- A service is not available
+      kdc-err-svc-unavailable               ErrCode ::= 29
+      -- Integrity check on decrypted field failed
+      krb-ap-err-bad-integrity              ErrCode ::= 31
+      -- Ticket expired
+      krb-ap-err-tkt-expired                ErrCode ::= 32
+      -- Ticket not yet valid
+      krb-ap-err-tkt-nyv                    ErrCode ::= 33
+      -- Request is a replay
+      krb-ap-err-repeat                     ErrCode ::= 34
+      -- The ticket isn't for us
+      krb-ap-err-not-us                     ErrCode ::= 35
+      -- Ticket and authenticator don't match
+      krb-ap-err-badmatch                   ErrCode ::= 36
+      -- Clock skew too great
+      krb-ap-err-skew                       ErrCode ::= 37
+      -- Incorrect net address
+      krb-ap-err-badaddr                    ErrCode ::= 38
+      -- Protocol version mismatch
+      krb-ap-err-badversion                 ErrCode ::= 39
+      -- Invalid msg type
+      krb-ap-err-msg-type                   ErrCode ::= 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 74]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Message stream modified
+      krb-ap-err-modified                   ErrCode ::= 41
+      -- Message out of order
+      krb-ap-err-badorder                   ErrCode ::= 42
+      -- Specified version of key is not available
+      krb-ap-err-badkeyver                  ErrCode ::= 44
+      -- Service key not available
+      krb-ap-err-nokey                      ErrCode ::= 45
+      -- Mutual authentication failed
+      krb-ap-err-mut-fail                   ErrCode ::= 46
+      -- Incorrect message direction
+      krb-ap-err-baddirection               ErrCode ::= 47
+      -- Alternative authentication method required
+      krb-ap-err-method                     ErrCode ::= 48
+      -- Incorrect sequence number in message
+      krb-ap-err-badseq                     ErrCode ::= 49
+      -- Inappropriate type of checksum in message
+      krb-ap-err-inapp-cksum                ErrCode ::= 50
+      -- Policy rejects transited path
+      krb-ap-path-not-accepted              ErrCode ::= 51
+      -- Response too big for UDP, retry with TCP
+      krb-err-response-too-big              ErrCode ::= 52
+      -- Generic error (description in e-text)
+      krb-err-generic                       ErrCode ::= 60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 75]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+      -- Field is too long for this implementation
+      krb-err-field-toolong                 ErrCode ::= 61
+      -- Reserved for PKINIT
+      kdc-error-client-not-trusted          ErrCode ::= 62
+      -- Reserved for PKINIT
+      kdc-error-kdc-not-trusted             ErrCode ::= 63
+      -- Reserved for PKINIT
+      kdc-error-invalid-sig                 ErrCode ::= 64
+      -- Reserved for PKINIT
+      kdc-err-key-too-weak                  ErrCode ::= 65
+      -- Reserved for PKINIT
+      kdc-err-certificate-mismatch          ErrCode ::= 66
+      -- No TGT available to validate USER-TO-USER
+      krb-ap-err-no-tgt                     ErrCode ::= 67
+      -- USER-TO-USER TGT issued different KDC
+      kdc-err-wrong-realm                   ErrCode ::= 68
+      -- Ticket must be for USER-TO-USER
+      krb-ap-err-user-to-user-required      ErrCode ::= 69
+      -- Reserved for PKINIT
+      kdc-err-cant-verify-certificate       ErrCode ::= 70
+      -- Reserved for PKINIT
+      kdc-err-invalid-certificate           ErrCode ::= 71
+      -- Reserved for PKINIT
+      kdc-err-revoked-certificate           ErrCode ::= 72
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unknown     ErrCode ::= 73
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unavailable ErrCode ::= 74
+
+
+
+      END
+
+
+
+B.  Kerberos and Character Encodings (Informative)
+
+
+   [adapted from KCLAR 5.2.1]
+
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO 2022 | ECMA-35
+   [ISO2022] to switch character sets, and the default character set
+   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
+   International Reference Version (IRV) (aka U.S. ASCII), which mostly
+   works.
+
+
+   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER previously
+   [X690-1997] prohibited the designation of character sets as any but
+   the G0 and C0 sets.  This had the side effect of prohibiting the use
+
+
+Yu                          Expires: Jan 2005                  [Page 76]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
+   other character-sets that utilize a 96-character set, since it is
+   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
+   element.  Recent revisions to the ASN.1 standards resolve this
+   contradiction.
+
+
+   In practice, many implementations treat RFC 1510 GeneralStrings as if
+   they were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to conform to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+
+   [the following should probably be rewritten and moved into the
+   principal name section]
+
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way.  Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters.  This is a violation of the ASN.1
+   standard.  Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard.  As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+
+
+Yu                          Expires: Jan 2005                  [Page 77]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+C.  Kerberos History (Informative)
+
+
+   [Adapted from KCLAR "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 Ts'o, 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 [KNT94].
+
+
+D.  Notational Differences from [KCLAR]
+
+
+   [ possible point for discussion ]
+
+
+   [KCLAR] uses notational conventions slightly different from this
+   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
+   language style identifier names for defined values.  In ASN.1
+   notation, identifiers referencing defined values must begin with a
+   lowercase letter and contain hyphen (-) characters rather than
+   underscore (_) characters, while identifiers referencing types begin
+   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
+   identifiers with underscores to identify defined values.  This has
+   the potential to create confusion, but neither document defines
+   values using actual ASN.1 value-assignment notation.
+
+
+   It is debatable whether it is advantageous to write all identifier
+   names (regardless of their ASN.1 token type) in all-uppercase letters
+   for the purpose of emphasis in running text.  The alternative is to
+
+
+Yu                          Expires: Jan 2005                  [Page 78]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   use double-quote characters (") when ambiguity is possible.
+
+
+Normative References
+
+
+   [ISO646]
+        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
+
+
+   [ISO2022]
+        "Information technology -- Character code structure and
+        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
+
+
+   [KCRYPTO]
+        draft-ietf-krb-wg-crypto-07.txt
+
+
+   [RFC2119]
+        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+        Requirement Levels", March 1997.
+
+
+   [X680]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Specification of basic notation", ITU-T Recommendation X.680
+        (2002) | ISO/IEC 8824-1:2002.
+
+
+   [X682]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Constraint specification", ITU-T Recommendation X.682 (2002) |
+        ISO/IEC 8824-3:2002.
+
+
+   [X683]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Parameterization of ASN.1 specifications", ITU-T Recommendation
+        X.683 (2002) | ISO/IEC 8824-4:2002.
+
+
+   [X690]
+        "Information technology -- ASN.1 encoding Rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+
+Informative References
+
+
+   [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).
+
+
+   [Dub00]
+        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
+        Systems", Elsevier-Morgan Kaufmann, 2000.
+        <http://www.oss.com/asn1/dubuisson.html>
+
+
+
+Yu                          Expires: Jan 2005                  [Page 79]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+   [ISO8859-1]
+        "Information technology -- 8-bit single-byte coded graphic
+        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
+        8859-1:1998.
+
+
+   [KCLAR]
+        draft-ietf-krb-wg-kerberos-clarifications-06.txt
+
+
+   [KNT94]
+        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+        Evolution of the Kerberos Authentication System".  In
+        Distributed Open Systems, pages 78-94.  IEEE Computer Society
+        Press, 1994.
+
+
+   [Lar96]
+        John Larmouth, "Understanding OSI", International Thomson
+        Computer Press, 1996.
+        <http://www.isi.salford.ac.uk/books/osi.html>
+
+
+   [Lar99]
+        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
+        1999.  <http://www.oss.com/asn1/larmouth.html>
+
+
+   [NS78]
+        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+        Authentication in Large Networks of Computers", Communications
+        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+
+   [RFC1510]
+        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
+        Service (v5)", RFC1510, September 1993, Status: Proposed
+        Standard.
+
+
+   [RFC1964]
+        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
+        June 1996, Status: Proposed Standard.
+
+
+   [X690-1997]
+        "Information technology -- ASN.1 encoding rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (1997) | ISO/IEC 8825-1:1998.
+
+
+Author's Address
+
+
+   Tom Yu
+   77 Massachusetts Ave
+   Cambridge, MA 02139
+   USA
+   tlyu@mit.edu
+
+
+
+Yu                          Expires: Jan 2005                  [Page 80]
+Internet-Draft            yu-krb-extensions-01               19 Jul 2004
+
+
+Full Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                          Expires: Jan 2005                  [Page 81] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-02.txt b/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-02.txt
new file mode 100644
index 00000000000..52f736b160c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-02.txt
@@ -0,0 +1,6867 @@
+INTERNET-DRAFT                                                    Tom Yu
+draft-yu-krb-wg-kerberos-extensions-02.txt                           MIT
+Expires: 25 April 2005                                   25 October 2004
+
+
+        The Kerberos Network Authentication Service (Version 5)
+
+
+Status of This Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   or will be disclosed, and any of which I become aware will be
+   disclosed, in accordance with RFC 3668.
+
+
+   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
+
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This document describes version 5 of the Kerberos network
+   authentication protocol.  It describes a framework to allow for
+   extensions to be made to the protocol without creating
+   interoperability problems.
+
+
+Key Words for Requirements
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in RFC 2119.
+
+
+
+
+
+Yu                         Expires: Apr 2005                    [Page 1]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+Table of Contents
+
+
+   Status of This Memo ..............................................  1
+   Copyright Notice .................................................  1
+   Abstract .........................................................  1
+   Key Words for Requirements .......................................  1
+   Table of Contents ................................................  2
+   1.  Introduction .................................................  5
+   1.1.  Kerberos Protocol Overview .................................  5
+   1.2.  Document Organization ......................................  6
+   2.  Compatibility Considerations .................................  6
+   2.1.  Extensibility ..............................................  7
+   2.2.  Compatibility with RFC 1510 ................................  7
+   2.3.  Backwards Compatibility ....................................  7
+   2.4.  1.4.2. Sending Extensible Messages .........................  8
+   2.5.  Criticality ................................................  8
+   2.6.  Authenticating Cleartext Portions of Messages ..............  9
+   2.7.  Capability Negotiation ..................................... 10
+   3.  Use of ASN.1 in Kerberos ..................................... 10
+   3.1.  Module Header .............................................. 11
+   3.2.  Top-Level Type ............................................. 11
+   3.3.  Previously Unused ASN.1 Notation (informative) ............. 12
+   3.3.1.  Parameterized Types ...................................... 12
+   3.3.2.  COMPONENTS OF Notation ................................... 12
+   3.3.3.  Constraints .............................................. 12
+   3.4.  New Types .................................................. 13
+   4.  Basic Types .................................................. 14
+   4.1.  Constrained Integer Types .................................. 14
+   4.2.  KerberosTime ............................................... 15
+   4.3.  KerberosString ............................................. 15
+   4.4.  Language Tags .............................................. 16
+   4.5.  KerberosFlags .............................................. 16
+   4.6.  Typed Holes ................................................ 16
+   4.7.  HostAddress and HostAddresses .............................. 17
+   4.7.1.  Internet (IPv4) Addresses ................................ 17
+   4.7.2.  Internet (IPv6) Addresses ................................ 17
+   4.7.3.  DECnet Phase IV addresses ................................ 18
+   4.7.4.  Netbios addresses ........................................ 18
+   4.7.5.  Directional Addresses .................................... 18
+   5.  Principals ................................................... 19
+   5.1.  Name Types ................................................. 19
+   5.2.  Principal Type Definition .................................. 19
+   5.3.  Principal Name Reuse ....................................... 20
+   5.4.  Realm Names ................................................ 20
+   5.5.  Printable Representations of Principal Names ............... 21
+   5.6.  Ticket-Granting Service Principal .......................... 21
+   5.6.1.  Cross-Realm TGS Principals ............................... 21
+   6.  Types Relating to Encryption ................................. 21
+   6.1.  Assigned Numbers for Encryption ............................ 22
+   6.1.1.  EType .................................................... 22
+   6.1.2.  Key Usages ............................................... 22
+
+
+Yu                         Expires: Apr 2005                    [Page 2]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   6.2.  Which Key to Use ........................................... 23
+   6.3.  EncryptionKey .............................................. 24
+   6.4.  EncryptedData .............................................. 24
+   6.5.  Checksums .................................................. 25
+   6.5.1.  ChecksumOf ............................................... 26
+   6.5.2.  Signed ................................................... 27
+   7.  Tickets ...................................................... 27
+   7.1.  Timestamps ................................................. 28
+   7.2.  Ticket Flags ............................................... 28
+   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 29
+   7.2.2.  Invalid Tickets .......................................... 29
+   7.2.3.  OK as Delegate ........................................... 30
+   7.2.4.  Renewable Tickets ........................................ 30
+   7.2.5.  Postdated Tickets ........................................ 31
+   7.2.6.  Proxiable and Proxy Tickets .............................. 32
+   7.2.7.  Forwarded and Forwardable Tickets ........................ 33
+   7.3.  Transited Realms ........................................... 34
+   7.4.  Authorization Data ......................................... 34
+   7.4.1.  AD-IF-RELEVANT ........................................... 35
+   7.4.2.  AD-KDCIssued ............................................. 35
+   7.4.3.  AD-AND-OR ................................................ 37
+   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 37
+   7.5.  Encrypted Part of Ticket ................................... 37
+   7.6.  Cleartext Part of Ticket ................................... 38
+   8.  Credential Acquisition ....................................... 40
+   8.1.  KDC-REQ .................................................... 40
+   8.2.  PA-DATA .................................................... 46
+   8.3.  KDC-REQ Processing ......................................... 46
+   8.3.1.  Handling Replays ......................................... 46
+   8.3.2.  Request Validation ....................................... 47
+   8.3.2.1.  AS-REQ Authentication .................................. 47
+   8.3.2.2.  TGS-REQ Authentication ................................. 47
+   8.3.2.3.  Principal Validation ................................... 47
+   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 48
+   8.3.3.  Timestamp Handling ....................................... 48
+   8.3.3.1.  AS-REQ Timestamp Processing ............................ 49
+   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 49
+   8.3.4.  Handling Transited Realms ................................ 50
+   8.3.5.  Address Processing ....................................... 50
+   8.3.6.  Ticket Flag Processing ................................... 51
+   8.3.7.  Key Selection ............................................ 52
+   8.3.7.1.  Reply Key and Session Key Selection .................... 52
+   8.3.7.2.  Ticket Key Selection ................................... 52
+   8.4.  KDC-REP .................................................... 52
+   8.5.  Reply Validation ........................................... 55
+   8.6.  IP Transports .............................................. 55
+   8.6.1.  UDP/IP transport ......................................... 55
+   8.6.2.  TCP/IP transport ......................................... 56
+   8.6.3.  KDC Discovery on IP Networks ............................. 57
+   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
+   8.6.3.2.  DNS SRV records for KDC location ....................... 58
+
+
+Yu                         Expires: Apr 2005                    [Page 3]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
+                Networks ............................................ 58
+   9.  Errors ....................................................... 58
+   10.  Session Key Exchange ........................................ 61
+   10.1.  AP-REQ .................................................... 61
+   10.2.  AP-REP .................................................... 63
+   11.  Session Key Use ............................................. 65
+   11.1.  KRB-SAFE .................................................. 65
+   11.2.  KRB-PRIV .................................................. 65
+   11.3.  KRB-CRED .................................................. 66
+   12.  Security Considerations ..................................... 67
+   12.1.  Time Synchronization ...................................... 67
+   12.2.  Replays ................................................... 67
+   12.3.  Principal Name Reuse ...................................... 67
+   12.4.  Password Guessing ......................................... 67
+   12.5.  Forward Secrecy ........................................... 67
+   12.6.  Authorization ............................................. 68
+   12.7.  Login Authentication ...................................... 68
+   13.  IANA Considerations ......................................... 68
+   14.  Acknowledgments ............................................. 69
+   Appendices ....................................................... 69
+   A.  ASN.1 Module (Normative) ..................................... 69
+   B.  Kerberos and Character Encodings (Informative) ...............103
+   C.  Kerberos History (Informative) ...............................104
+   D.  Notational Differences from [KCLAR] ..........................105
+   Normative References .............................................106
+   Informative References ...........................................106
+   Author's Address .................................................108
+   Full Copyright Statement .........................................108
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                    [Page 4]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+1.  Introduction
+
+
+   The Kerberos network authentication protocol is a trusted-third-party
+   protocol utilizing symmetric-key cryptography.  It assumes that all
+   communications between parties in the protocol may be arbitrarily
+   tampered with or monitored, and that the security of the overall
+   system depends only on the effectiveness of the cryptographic
+   techniques and the secrecy of the cryptographic keys used.  The
+   Kerberos protocol authenticates an application client's identity to
+   an application server, and likewise authenticates the application
+   server's identity to the application client.  These assurances are
+   made possible by the client and the server sharing secrets with the
+   trusted third party: the Kerberos server, also known as the Key
+   Distribution Center (KDC).  In addition, the protocol establishes an
+   ephemeral shared secret (the session key) between the client and the
+   server, allowing the protection of further communications between
+   them.
+
+
+   The Kerberos protocol, as originally specified, provides insufficient
+   means for extending the protocol in a backwards-compatible way.  This
+   deficiency has caused problems for interoperability.  This document
+   describes a framework which enables backwards-compatible extensions
+   to the Kerberos protocol.
+
+
+1.1.  Kerberos Protocol Overview
+
+
+   Kerberos comprises three main sub-protocols: credentials acquisition,
+   session key exchange, and session key usage.  A client acquires
+   credentials by asking the KDC for a credential for a service; the KDC
+   issues the credential, which contains a ticket and a session key.
+   The ticket, containing the client's identity, timestamps, expiration
+   time, and a session key, is a encrypted in a key known to the
+   application server.  The KDC encrypts the credential using a key
+   known to the client, and transmits the credential to the client.
+
+
+   There are two means of requesting credentials: the Authentication
+   Service (AS) exchange, and the Ticket-Granting Service (TGS)
+   exchange.  In the typical AS exchange, a client uses a password-
+   derived key to decrypt the response.  In the TGS exchange, the KDC
+   behaves as an application server; the client authenticates to the TGS
+   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
+   the TGT by using the AS exchange.
+
+
+   Session key exchange consists of the client transmitting the ticket
+   to the application server, accompanied by an authenticator.  The
+   authenticator contains a timestamp and additional data encrypted
+   using the ticket's session key.  The application server decrypts the
+   ticket, extracting the session key.  The application server then uses
+   the session key to decrypt the authenticator.  Upon successful
+   decryption of the authenticator, the application server knows that
+   the data in the authenticator were sent by the client named in the
+
+
+Yu                         Expires: Apr 2005                    [Page 5]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   associated ticket.  Additionally, since authenticators expire more
+   quickly than tickets, the application server has some assurance that
+   the transaction is not a replay.  The application server may send an
+   encrypted acknowledgment to the client, verifying its identity to the
+   client.
+
+
+   Once session key exchange has occurred, the client and server may use
+   the established session key to protect further traffic.  This
+   protection may consist of protection of integrity only, or of
+   protection of confidentiality and integrity.  Additional measures
+   exist for a client to securely forward credentials to a server.
+
+
+   The entire scheme depends on loosely synchronized clocks.
+   Synchronization of the clock on the KDC with the application server
+   clock allows the application server to accurately determine whether a
+   credential is expired.  Likewise, synchronization of the clock on the
+   client with the application server clock prevents replay attacks
+   utilizing the same credential.  Careful design of the application
+   protocol may allow replay prevention without requiring client-server
+   clock synchronization.
+
+
+   After establishing a session key, application client and the
+   application server can exchange Kerberos protocol messages that use
+   the session key to protect the integrity or confidentiality of
+   communications between the client and the server.  Additionally, the
+   client may forward credentials to the application server.
+
+
+   The credentials acquisition protocol takes place over specific,
+   defined transports (UDP and TCP).  Application protocols define which
+   transport to use for the session key establishment protocol and for
+   messages using the session key; the application may choose to perform
+   its own encapsulation of the Kerberos messages, for example.
+
+
+1.2.  Document Organization
+
+
+   The remainder of this document begins by describing the general
+   frameworks for protocol extensibility, including whether to interpret
+   unknown extensions as critical.  It then defines the protocol
+   messages and exchanges.
+
+
+   The definition of the Kerberos protocol uses Abstract Syntax Notation
+   One (ASN.1) [X680], which specifies notation for describing the
+   abstract content of protocol messages.  This document defines a
+   number of base types using ASN.1; these base types subsequently
+   appear in multiple types which define actual protocol messages.
+   Definitions of principal names and of tickets, which are central to
+   the protocol, also appear preceding the protocol message definitions.
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                    [Page 6]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+2.  Compatibility Considerations
+
+
+2.1.  Extensibility
+
+
+   In the past, significant interoperability problems have resulted from
+   conflicting assumptions about how the Kerberos protocol can be
+   extended.  As the deployed base of Kerberos grows, the ability to
+   extend the Kerberos protocol becomes more important.  In order to
+   ensure that vendors and the IETF can extend the protocol while
+   maintaining backwards compatibility, this document outlines a
+   framework for extending Kerberos.
+
+
+   Kerberos provides two general mechanisms for protocol extensibility.
+   Many protocol messages, including some defined in RFC 1510, contain
+   typed holes--sub-messages containing an octet string along with an
+   integer that identifies how to interpret the octet string.  The
+   integer identifiers are registered centrally, but can be used both
+   for vendor extensions and for extensions standardized in the IETF.
+   This document adds typed holes to a number of messages which
+   previously lacked typed holes.
+
+
+   Many new messages defined in this document also contain ASN.1
+   extension markers.  These markers allow future revisions of this
+   document to add additional elements to messages, for cases where
+   typed holes are inadequate for some reason.  Because tag numbers and
+   position in a sequence need to be coordinated in order to maintain
+   interoperability, implementations MUST NOT include ASN.1 extensions
+   except when those extensions are specified by IETF standards-track
+   documents.
+
+
+2.2.  Compatibility with RFC 1510
+
+
+   Implementations of RFC 1510 did not use extensible ASN.1 types.
+   Sending additional fields not in RFC 1510 to these implementations
+   results in undefined behavior.  Examples of this behavior are known
+   to include discarding messages with no error indications.
+
+
+   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
+   are used; one alternative of the CHOICE provides a message which is
+   wire-encoding compatible with RFC 1510, and the other alternative
+   provides the new, extensible message.
+
+
+   Implementations sending new messages MUST ensure that the recipient
+   supports these new messages.  Along with each extensible message is a
+   guideline for when that message MAY be used.  IF that guideline is
+   followed, then the recipient is guaranteed to understand the message.
+
+
+2.3.  Backwards Compatibility
+
+
+   This document describes two sets (for the most part) of ASN.1 types.
+   The first set of types is wire-encoding compatible with RFC 1510 and
+
+
+Yu                         Expires: Apr 2005                    [Page 7]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   [KCLAR].  The second set of types is the set of types enabling
+   extensibility.  This second set may be referred to as
+   "extensibility-enabled types". [ need to make this consistent
+   throughout? ]
+
+
+   A major difference between the new extensibility-enabled types and
+   the types for RFC 1510 compatibility is that the extensibility-
+   enabled types allow for the use of UTF-8 encodings in various
+   character strings in the protocol.  Each party in the protocol must
+   have some knowledge of the capabilities of the other parties in the
+   protocol.  There are methods for establishing this knowledge without
+   necessarily requiring explicit configuration.
+
+
+   An extensibility-enabled client can detect whether a KDC supports the
+   extensibility-enabled types by requesting an extensibility-enabled
+   reply.  If the KDC replies with an extensibility-enabled reply, the
+   client knows that the KDC supports extensibility.  If the KDC issues
+   an extensibility-enabled ticket, the client knows that the service
+   named in the ticket is extensibility-enabled.
+
+
+2.4.  1.4.2. Sending Extensible Messages
+
+
+   Care must be taken to make sure that old implementations can
+   understand messages sent to them even if they do not understand an
+   extension that is used.  Unless the sender knows the extension is
+   supported, the extension cannot change the semantics of the core
+   message or previously defined extensions.
+
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence.  The KDC should
+   only use the extension if this padata element is present in the AS-
+   REQ.  Even if policy requires the use of the extension, it is better
+   to return an error indicating that the extension is required than to
+   use the extension when the recipient may not support it; debugging
+   why implementations do not interoperate is easier when errors are
+   returned.
+
+
+2.5.  Criticality
+
+
+   Recipients of unknown message extensions (including typed holes, new
+   flags, and ASN.1 extension elements) should preserve the encoding of
+   the extension but otherwise ignore the presence of the extension;
+   i.e., unknown extensions SHOULD be treated as non-critical.  If a
+   copy of the message is used later--for example, when a Ticket
+   received in a KDC-REP is later used in an AP-REQ--then the unknown
+
+
+Yu                         Expires: Apr 2005                    [Page 8]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   extensions MUST be included.
+
+
+   An implementation SHOULD NOT reject a request merely because it does
+   not understand some element of the request.  As a related
+   consequence, implementations SHOULD handle communicating with other
+   implementations which do not implement some requested options.  This
+   may require designers of options to provide means to determine
+   whether an option has been rejected, not understood, or (perhaps
+   maliciously) deleted or modified in transit.
+
+
+   There is one exception to non-criticality described above: if an
+   unknown authorization data element is received by a server either in
+   an AP-REQ or in a Ticket contained in an AP-REQ, then the
+   authentication SHOULD fail.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether the restriction applies to that service then a security
+   weakness may result if authentication succeeds.  Authorization
+   elements meant to be truly optional can be enclosed in the AD-IF-
+   RELEVANT element.
+
+
+   Many RFC 1510 implementations ignore unknown authorization data
+   elements.  Depending on these implementations to honor authorization
+   data restrictions may create a security weakness.
+
+
+2.6.  Authenticating Cleartext Portions of Messages
+
+
+   Various denial of service attacks and downgrade attacks against
+   Kerberos are possible unless plaintexts are somehow protected against
+   modification.  An early design goal of Kerberos Version 5 was to
+   avoid encrypting more of the authentication exchange that was
+   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
+   in a KDC reply, for example.)  This minimization of encryption
+   reduces the load on the KDC and busy servers.  Also, during the
+   initial design of Version 5, the existence of legal restrictions on
+   the export of cryptography made it desirable to minimize of the
+   number of uses of encryption in the protocol.  Unfortunately,
+   performing this minimization created numerous instances of
+   unauthenticated security-relevant plaintext fields.
+
+
+   The extensible variants of the messages described in this document
+   wrap the actual message in an ASN.1 sequence containing a keyed
+   checksum of the contents of the message.  Guidelines in [XXX] section
+   3 specify when the checksum MUST be included and what key MUST be
+   used.  Guidelines on when to include a checksum are never ambiguous:
+   a particular PDU is never correct both with and without a checksum.
+   With the exception of the KRB-ERROR message, receiving
+   implementations MUST reject messages where a checksum is included and
+   not expected or where a checksum is expected but not included.  The
+   receiving implementation does not always have sufficient information
+   to know whether a KRB-ERROR should contain a checksum.  Even so,
+   KRB-ERROR messages with invalid checksums MUST be rejected and
+
+
+Yu                         Expires: Apr 2005                    [Page 9]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   implementations MAY consider the presence or absence of a checksum
+   when evaluating whether to trust the error.
+
+
+   This authenticated cleartext protection is provided only in the
+   extensible variants of the messages; it is never used when
+   communicating with an RFC 1510 implementation.
+
+
+2.7.  Capability Negotiation
+
+
+   Kerberos is a three-party protocol.  Each of the three parties
+   involved needs a means of detecting the capabilities supported by the
+   others.  Two of the parties, the KDC and the application server, do
+   not communicate directly in the Kerberos protocol.  Communicating
+   capabilities from the KDC to the application server requires using a
+   ticket as an intermediary.
+
+
+   The main capability requiring negotiation is the support of the
+   extensibility framework described in this document.  Negotiation of
+   this capability while remaining compatible with RFC 1510
+   implementations is possible.  The main complication is that the
+   client needs to know whether the application server supports the
+   extensibility framework prior to sending any message to the
+   application server.  This can be accomplished if the KDC has
+   knowledge of whether an application server supports the extensibility
+   framework.
+
+
+   Client software advertizes its capabilities when requesting
+   credentials from the KDC.  If the KDC recognizes the capabilities, it
+   acknowledges this fact to the client in its reply.  In addition, if
+   the KDC has knowledge that the application server supports certain
+   capabilities, it also communicates this knowledge to the client in
+   its reply.  The KDC can encode its own capabilities in the ticket so
+   that the application server may discover these capabilities.  The
+   client advertizes its capabilities to the application server when it
+   initiates authentication to the application server.
+
+
+3.  Use of ASN.1 in Kerberos
+
+
+   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
+   Even though ASN.1 theoretically allows the description of protocol
+   messages to be independent of the encoding rules used to encode the
+   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
+   the semantics of the notation, such as whether tags carry any
+   semantic content to the application, may cause the use of other ASN.1
+   encoding rules to be problematic.
+
+
+   Implementors not using existing ASN.1 tools (e.g., compilers or
+   support libraries) are cautioned to thoroughly read and understand
+   the actual ASN.1 specification to ensure correct implementation
+   behavior.  There is more complexity in the notation than is
+   immediately obvious, and some tutorials and guides to ASN.1 are
+
+
+Yu                         Expires: Apr 2005                   [Page 10]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   misleading or erroneous.  Recommended tutorials and guides include
+   [Dub00], [Lar99], though there is still no substitute for reading the
+   actual ASN.1 specification.
+
+
+3.1.  Module Header
+
+
+   The type definitions in this document assume an ASN.1 module
+   definition of the following form:
+
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+      -- Rest of definitions here
+
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and that automatic tagging is not done.
+
+
+   Some other publications [RFC1510] [RFC1964] erroneously specify an
+   object identifier (OID) having an incorrect value of "5" for the
+   "dod" component of the OID.  In the case of RFC 1964, use of the
+   "correct" OID value would result in a change in the wire protocol;
+   therefore, the RFC 1964 OID remains unchanged for now.
+
+
+3.2.  Top-Level Type
+
+
+   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
+   Data Units or PDUs) which an application may directly reference.
+   Applications SHOULD NOT transmit any types other than those which are
+   alternatives of the KRB-PDU CHOICE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 11]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+
+3.3.  Previously Unused ASN.1 Notation (informative)
+
+
+   Some aspects of ASN.1 notation used in this document were not used in
+   [KCLAR], and may be unfamiliar to some readers.  This subsection is
+   informative; for normative definitions of the notation, see the
+   actual ASN.1 specifications [X680], [X682], [X683].
+
+
+3.3.1.  Parameterized Types
+
+
+   This document uses ASN.1 parameterized types [X683] to make
+   definitions of types more readable.  For some types, some or all of
+   the parameters are advisory, i.e., they are not encoded in any form
+   for transmission in a protocol message.  These advisory parameters
+   can describe implementation behavior associated with the type.
+
+
+3.3.2.  COMPONENTS OF Notation
+
+
+   The "COMPONENTS OF" notation, used to define the RFC 1510
+   compatibility types, extracts all of the component types of an ASN.1
+   SEQUENCE type.  The extension marker (the "..." notation) and any
+   extension components are not extracted by "COMPONENTS OF".  The
+   "COMPONENTS OF" notation permits concise definition of multiple types
+   which have many components in common with each other.
+
+
+3.3.3.  Constraints
+
+
+   This document uses ASN.1 constraints, including the
+   "UserDefinedConstraint" notation [X682].  Some constraints can be
+   handled automatically by tools that can parse them.  Uses of the
+
+
+Yu                         Expires: Apr 2005                   [Page 12]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
+   typically need to have behavior manually coded; the notation provides
+   a formalized way of conveying intended implementation behavior.
+
+
+   The "WITH COMPONENTS" constraint notation allows constraints to apply
+   to component types of a SEQUENCE type.  This constraint notation
+   effectively allows constraints to "reach into" a type to constrain
+   its component types.
+
+
+3.4.  New Types
+
+
+   This document defines a number of ASN.1 types which are new since
+   [KCLAR].  The names of these types will typically have a suffix like
+   "Ext", indicating that the types are intended to support
+   extensibility.  Types original to RFC 1510 and [KCLAR] have been
+   renamed to have a suffix like "1510".  The "Ext" and "1510" types
+   often contain a number of common elements; these common elements have
+   a suffix like "Common".  The "1510" types have various ASN.1
+   constraints applied to them; the constraints limit the possible
+   values of the "1510" types to those permitted by RFC 1510 or by
+   [KCLAR].  The "Ext" types may have different constraints, typically
+   to force string values to be sent as UTF-8.
+
+
+   For example, consider
+
+
+      -- example "common" type
+      Foo-Common      ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING,
+          ...,
+          c           [2] INTEGER,
+          ...
+      }
+
+
+      -- example "RFC 1510 compatibility" type
+      Foo-1510        ::= SEQUENCE {
+          -- the COMPONENTS OF notation drops the extension marker
+          -- and all extension additions.
+          COMPONENTS OF Foo-Common
+      }
+
+
+      -- example "extensibility-enabled" type
+      Foo-Ext         ::= Foo-Common
+
+
+   where "Foo-Common" is a common type used to define both the "1510"
+   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
+   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
+   not contain the extension marker, nor does it contain the extension
+   component "c".  The type "Foo-1510" is equivalent to "Foo-1510-
+   Equiv", shown below.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 13]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- example type equivalent to Foo-1510
+      Foo-1510-Equiv  ::= SEQUENCE {
+          a           [0] INTEGER,
+          b           [1] OCTET STRING
+      }
+
+
+
+4.  Basic Types
+
+
+   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
+   types.
+
+
+4.1.  Constrained Integer Types
+
+
+   In RFC 1510, many types contained references to the unconstrained
+   INTEGER type.  Since an unconstrained INTEGER can contain almost any
+   possible abstract integer value, most of the unconstrained references
+   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
+   [KCLAR].
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+   The "Int32" type often contains an assigned number identifying the
+   contents of a typed hole.  Unless otherwise stated, non-negative
+   values are registered, and negative values are available for local
+   use.
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+   The "UInt32" type is used in some places where an unsigned 32-bit
+   integer is needed.
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+   The "UInt64" type is used in places where 32 bits of precision may
+   provide inadequate security.
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+   Sequence numbers were constrained to 32 bits in [KCLAR], but this
+   document allows for 64-bit sequence numbers.
+
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+
+Yu                         Expires: Apr 2005                   [Page 14]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
+   to 64 bits here.
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+   The "microseconds" type is intended to carry the microseconds part of
+   a time value.
+
+
+4.2.  KerberosTime
+
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
+   KerberosTime value MUST NOT include any fractional portions of the
+   seconds.  As required by the DER, it further MUST NOT include any
+   separators, and it specifies the UTC time zone (Z).  Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is "19851106210627Z".
+
+
+4.3.  KerberosString
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+   The KerberosString type is used for character strings in various
+   places in the Kerberos protocol.  For compatibility with RFC 1510,
+   GeneralString values constrained to IA5String (US-ASCII) are
+   permitted in messages exchanged with RFC 1510 implementations.  The
+   new protocol messages contain strings encoded as UTF-8, and these
+   strings MUST be normalized using [SASLPREP].  KerberosString values
+   are present in principal names and in error messages.  Control
+   characters SHOULD NOT be used in principal names, and used with
+   caution in error messages.
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+   KerberosStringIA5 requires the use of the "ia5" alternative, while
+
+
+Yu                         Expires: Apr 2005                   [Page 15]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   KerberosStringExt forbids it.  These types appear in ASN.1
+   constraints on messages.
+
+
+   For detailed background regarding the history of character string use
+   in Kerberos, as well as discussion of some compatibility issues, see
+   Appendix B.
+
+
+4.4.  Language Tags
+
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+   The "LangTag" type is used to specify language tags for localization
+   purposes, using the [RFC3066] format.
+
+
+4.5.  KerberosFlags
+
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+
+      })
+
+
+
+   The actual bit string type encoded in Kerberos messages does not use
+   named bits.  The advisory parameter of the KerberosFlags type names a
+   bit string type defined using named bits, whose value is encoded as
+   if it were a bit string with unnamed bits.  This practice is
+   necessary because the DER require trailing zero bits to be removed
+   when encoding bit strings defined using named bits.  Existing
+   implementations of Kerberos send exactly 32 bits rather than
+   truncating, so the size constraint requires the transmission of at
+   least 32 bits.  Trailing zero bits beyond the first 32 bits are
+   truncated.
+
+
+4.6.  Typed Holes
+
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+
+Yu                         Expires: Apr 2005                   [Page 16]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   The "TH-id" type is a generalized means to identify the contents of a
+   typed hole.  The "int32" alternative may be used for simple integer
+   assignments, in the same manner as "Int32", while the "rel-oid"
+   alternative may be used for hierarchical delegation.
+
+
+4.7.  HostAddress and HostAddresses
+
+
+      AddrType        ::= Int32
+
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+
+   addr-type
+        This field specifies the type of address that follows.
+
+
+   address
+        This field encodes a single address of the type identified by
+        "addr-type".
+
+
+   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.
+
+
+
+      addr-type |     meaning
+      __________|______________
+              2 |   IPv4
+              3 |   directional
+             12 |   DECnet
+             20 |   NetBIOS
+             24 |   IPv6
+
+
+
+
+4.7.1.  Internet (IPv4) Addresses
+
+
+   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
+   MSB order (most significant byte first). The IPv4 loopback address
+   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
+   two (2).
+
+
+
+Yu                         Expires: Apr 2005                   [Page 17]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+4.7.2.  Internet (IPv6) Addresses
+
+
+   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
+   in MSB order (most significant byte first). The type of IPv6
+   addresses is twenty-four (24). The following addresses MUST NOT
+   appear in any Kerberos PDU:
+
+
+      * the Unspecified Address
+
+
+      * the Loopback Address
+
+
+      * Link-Local addresses
+
+
+   This restriction applies to the inclusion in the address fields of
+   Kerberos PDUs, but not to the address fields of packets that might
+   carry such PDUs.  The restriction is necessary because the use of an
+   address with non-global scope could allow the acceptance of a message
+   sent from a node that may have the same address, but which is not the
+   host intended by the entity that added the restriction.  If the
+   link-local address type needs to be used for communication, then the
+   address restriction in tickets must not be used (i.e. addressless
+   tickets must be used).
+
+
+   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
+   2.
+
+
+4.7.3.  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).
+
+
+4.7.4.  Netbios addresses
+
+
+   Netbios addresses are 16-octet addresses typically composed of 1 to
+   15 alphanumeric characters and padded with the US-ASCII SPC character
+   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
+   0).  The type of Netbios addresses is twenty (20).
+
+
+4.7.5.  Directional Addresses
+
+
+   In many environments, including the sender address in KRB-SAFE and
+   KRB-PRIV messages is undesirable because the addresses may be changed
+   in transport by network address translators. However, if these
+   addresses are removed, the messages may be subject to a reflection
+   attack in which a message is reflected back to its originator. The
+   directional address type provides a way to avoid transport addresses
+   and reflection attacks.  Directional addresses are encoded as four
+   byte unsigned integers in network byte order.  If the message is
+   originated by the party sending the original AP-REQ message, then an
+   address of 0 SHOULD be used. If the message is originated by the
+   party to whom that AP-REQ was sent, then the address 1 SHOULD be
+
+
+Yu                         Expires: Apr 2005                   [Page 18]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   used.  Applications involving multiple parties can specify the use of
+   other addresses.
+
+
+   Directional addresses MUST only be used for the sender address field
+   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
+   ticket address or in a AP-REQ message.  This address type SHOULD only
+   be used in situations where the sending party knows that the
+   receiving party supports the address type.  This generally means that
+   directional addresses may only be used when the application protocol
+   requires their support.  Directional addresses are type (3).
+
+
+5.  Principals
+
+
+   Principals are participants in the Kerberos protocol.  A "realm"
+   consists of principals in one administrative domain, served by one
+   KDC (or one replicated set of KDCs).  Each principal name has an
+   arbitrary number of components, though typical principal names will
+   only have one or two components.  A principal name is meant to be
+   readable by and meaningful to humans, especially in a realm lacking a
+   centrally adminstered authorization infrastructure.
+
+
+5.1.  Name Types
+
+
+   Each PrincipalName has NameType indicating what sort of name it is.
+   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).
+
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 19]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+5.2.  Principal Type Definition
+
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+
+   name-type
+        hint of the type of name that follows
+
+
+   name-string
+        The "name-string" encodes a sequence of components that form a
+        name, each component encoded as a KerberosString.  Taken
+        together, a PrincipalName and a Realm form a principal
+        identifier.  Most PrincipalNames will have only a few components
+        (typically one or two).
+
+
+5.3.  Principal Name Reuse
+
+
+   Realm administrators SHOULD use extreme caution when considering
+   reusing a principal name.  A service administrator might explicitly
+   enter principal names into a local access control list (ACL) for the
+   service.  If such local ACLs exist independently of a centrally
+   administered authorization infrastructure, realm administrators
+   SHOULD NOT reuse principal names until confirming that all extant ACL
+   entries referencing that principal name have been updated.  Failure
+   to perform this check can result in a security vulnerability, as a
+   new principal can inadvertently inherit unauthorized privileges upon
+   receiving a reused principal name.  An organization whose Kerberos-
+   authenticated services all use a centrally-adminstered authorization
+   infrastructure may not need to take these precautions regarding
+   principal name reuse.
+
+
+5.4.  Realm Names
+
+
+      Realm           ::= KerberosString
+
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+
+   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
+   character with the code 0 (the US-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
+
+
+Yu                         Expires: Apr 2005                   [Page 20]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   the style of X.500 names.
+
+
+5.5.  Printable Representations of Principal Names
+
+
+   [ perhaps non-normative? ]
+
+
+   The printable form of a principal name consists of the concatenation
+   of components of the PrincipalName value using the slash character
+   (/), followed by an at-sign (@), followed by the realm name.  Any
+   occurrence of a backslash (\), slash (/) or at-sign (@) in the
+   PrincipalName value is quoted by a backslash.
+
+
+5.6.  Ticket-Granting Service Principal
+
+
+   The PrincipalName value corresponding to a ticket-granting service
+   has two components: the first component is the string "krbtgt", and
+   the second component is the realm name of the TGS which will accept a
+   ticket-granting ticket having this service principal name.  The realm
+   name of service always indicates which realm issued the ticket.  A
+   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
+   obtaining tickets in the same realm would have the following ASN.1
+   values for its "realm" and "sname" components, respectively:
+
+
+      -- Example Realm and PrincipalName for a TGS
+
+
+      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
+
+
+      tgtPrinc1       PrincipalName ::= {
+          name-type nt-srv-inst,
+          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
+      }
+
+
+   Its printable representation would be written as
+   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
+
+
+5.6.1.  Cross-Realm TGS Principals
+
+
+   It is possible for a principal in one realm to authenticate to a
+   service in another realm.  A KDC can issue a cross-realm ticket-
+   granting ticket to allow one of its principals to authenticate to a
+   service in a foreign realm.  For example, the TGS principal
+   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
+   client principal in the realm A.EXAMPLE.COM to authenticate to a
+   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
+   issues a ticket to a client originating in A.EXAMPLE.COM, the
+   client's realm name remains "A.EXAMPLE.COM", even though the service
+   principal will have the realm "B.EXAMPLE.COM".
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 21]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+6.  Types Relating to Encryption
+
+
+   Many Kerberos protocol messages contain encrypted encodings of
+   various data types.  Some Kerberos protocol messages also contain
+   checksums (signatures) of encodings of various types.
+
+
+6.1.  Assigned Numbers for Encryption
+
+
+   Encryption algorithm identifiers and key usages both have assigned
+   numbers, described in [KCRYPTO].
+
+
+6.1.1.  EType
+
+
+   EType is the integer type for assigned numbers for encryption
+   algorithms.  Defined in [KCRYPTO].
+
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+6.1.2.  Key Usages
+
+
+   KeyUsage is the integer type for assigned numbers for key usages.
+   Key usage values are inputs to the encryption and decryption
+
+
+Yu                         Expires: Apr 2005                   [Page 22]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   functions described in [KCRYPTO].
+
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+6.2.  Which Key to Use
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 23]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+
+6.3.  EncryptionKey
+
+
+   The "EncryptionKey" type holds an encryption key.
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+   keytype
+        This "EType" identifies the encryption algorithm, described in
+        [KCRYPTO].
+
+
+   keyvalue
+        Contains the actual key.
+
+
+6.4.  EncryptedData
+
+
+   The "EncryptedData" type contains the encryption of another data
+   type.  The recipient uses fields within EncryptedData to determine
+   which key to use for decryption.
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 24]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+
+   KeyUsages
+        Advisory parameter indicating which key usage to use when
+        encrypting the ciphertext.  If "KeyUsages" indicate multiple
+        "KeyUsage" values, the detailed description of the containing
+        message will indicate which key to use under which conditions.
+
+
+   Type
+        Advisory parameter indicating the ASN.1 type whose DER encoding
+        is the plaintext encrypted into the EncryptedData.
+
+
+   Keys
+        Advisory parameter indicating which key to use to perform the
+        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
+        detailed description of the containing message will indicate
+        which key to use under which conditions.
+
+
+   KeyUsages
+        Advisory parameter indicating which "KeyUsage" value is used to
+        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
+        the detailed description of the containing message will indicate
+        which key usage to use under which conditions.
+
+
+6.5.  Checksums
+
+
+   Several types contain checksums (actually signatures) of data.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 25]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      CksumType       ::= Int32
+
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+   CksumType
+        Integer type for assigned numbers for signature algorithms.
+        Defined in [KCRYPTO]
+
+
+   Keys
+        As in EncryptedData
+
+
+   KeyUsages
+        As in EncryptedData
+
+
+   cksumtype
+        Signature algorithm used to produce the signature.
+
+
+   checksum
+        The actual checksum.
+
+
+6.5.1.  ChecksumOf
+
+
+   ChecksumOf is similar to "Checksum", but specifies which type is
+   signed.
+
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+
+Yu                         Expires: Apr 2005                   [Page 26]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   Type
+        Indicates the ASN.1 type whose DER encoding is signed.
+
+
+6.5.2.  Signed
+
+
+   Signed is similar to "ChecksumOf", but contains an actual instance of
+   the type being signed in addition to the signature.
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+
+7.  Tickets
+
+
+   [ A large number of items described here are duplicated in the
+   sections describing KDC-REQ processing.  Should find a way to avoid
+   this duplication. ]
+
+
+   A ticket binds a principal name to a session key.  The important
+   fields of a ticket are in the encrypted part.  The components in
+   common between the RFC 1510 and the extensible versions are
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+   crealm
+        This field contains the client's realm.
+
+
+   cname
+        This field contains the client's name.
+
+
+Yu                         Expires: Apr 2005                   [Page 27]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   caddr
+        This field lists the network addresses (if absent, all addresses
+        are permitted) from which the ticket is valid.
+
+
+   Descriptions of the other fields appear in the following sections.
+
+
+7.1.  Timestamps
+
+
+   Three of the ticket timestamps may be requested from the KDC.  The
+   timestamps may differ from those requested, depending on site policy.
+
+
+   authtime
+        The time at which the client authenticated, as recorded by the
+        KDC.
+
+
+   starttime
+        The earliest time when the ticket is valid.  If not present, the
+        ticket is valid starting at the authtime.  This is requested as
+        the "from" field of KDC-REQ-BODY-COMMON.
+
+
+   endtime
+        This time is requested in the "till" field of KDC-REQ-BODY-
+        COMMON.  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 time is requested in the "rtime" field of KDC-REQ-BODY-
+        COMMON.  It 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.
+
+
+7.2.  Ticket Flags
+
+
+   A number of flags may be set in the ticket, further defining some of
+   its capabilities.  Some of these flags map to flags in a KDC request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 28]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+
+7.2.1.  Flags Relating to Initial Ticket Acquisition
+
+
+   [ adapted KCLAR 2.1. ]
+
+
+   Several flags indicate the details of how the initial ticket was
+   acquired.
+
+
+   initial
+        The "initial" flag indicates that a ticket was issued using the
+        AS protocol, rather than issued based on a ticket-granting
+        ticket.  Application servers (e.g., a password-changing program)
+        requiring a client's definite knowledge of its secret key can
+        insist that this flag be set in any tickets they accept, thus
+        being assured that the client's key was recently presented to
+        the application client.
+
+
+   pre-authent
+        The "pre-authent" flag indicates that some sort of pre-
+        authentication was used during the AS exchange.
+
+
+   hw-authent
+        The "hw-authent" flag indicates that some sort of hardware-based
+        pre-authentication occurred during the AS exchange.
+
+
+   Both the "pre-authent" and the "hw-authent" flags may be present with
+   or without the "initial" flag; such tickets with the "initial" flag
+   clear are ones which are derived from initial tickets with the "pre-
+   authent" or "hw-authent" flags set.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 29]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+7.2.2.  Invalid Tickets
+
+
+   [ KCLAR 2.2. ]
+
+
+   The "invalid" flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets which have this flag set.  A postdated
+   ticket will 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 8.3.2.4).
+
+
+7.2.3.  OK as Delegate
+
+
+   [ KCLAR 2.8. ]
+
+
+   The "ok-as-delegate" flag provides a way for a KDC to communicate
+   local realm policy to a client regarding whether the service for
+   which the ticket is issued is trusted to accept delegated
+   credentials.  For some applications, a client may need to delegate
+   credentials to a service to act on its behalf in contacting other
+   services.  The ability of a client to obtain a service ticket for a
+   service conveys no information to the client about whether the
+   service should be trusted to accept delegated credentials.
+
+
+   The copy of the ticket flags visible to the client may have the "ok-
+   as-delegate" flag set to indicate to the client that the service
+   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 service.  It is acceptable 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.
+
+
+7.2.4.  Renewable Tickets
+
+
+   [ adapted KCLAR 2.3. ]
+
+
+   The "renewable" flag indicates whether the ticket may be renewed.
+
+
+   Renewable tickets can be used to mitigate the consequences of ticket
+   theft.  Applications may desire to hold credentials which can be
+   valid for long periods of time.  However, this can expose the
+   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
+
+
+Yu                         Expires: Apr 2005                   [Page 30]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   periodically would require the application to have long-term access
+   to the client's secret key, which is an even greater risk.
+
+
+   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 present an unexpired renewable ticket to the
+   KDC, setting the "renew" option 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.  It can usually be ignored by application
+   servers.  However, some particularly careful application servers MAY
+   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 clear by default,
+   but a client can request it be set by setting the "renewable" option
+   in the 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.
+
+
+7.2.5.  Postdated Tickets
+
+
+   postdated
+        indicates a ticket which has been postdated
+
+
+   may-postdate
+        indicates that postdated tickets may be issued based on this
+        ticket
+
+
+   [ KCLAR 2.4. ]
+
+
+   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.
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 31]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   The "may-postdate" flag in a ticket is normally only interpreted by
+   the TGS.  It can be ignored by application servers.  This flag MUST
+   be set in a ticket-granting ticket in order for the KDC 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 AS-REQ [?also TGS-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 AS-REQ message.  The life (endtime minus
+   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 minus 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 for
+   validation before use.
+
+
+7.2.6.  Proxiable and Proxy Tickets
+
+
+   proxy
+        indicates a proxy ticket
+
+
+   proxiable
+        indicates that proxy tickets may be issued based on this ticket
+
+
+   [ KCLAR 2.5. ]
+
+
+   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, users wishing to delegate their
+   identity in a form usable for all purposes 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
+
+
+Yu                         Expires: Apr 2005                   [Page 32]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   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 may contain a set of network addresses from which they are
+   valid.  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.
+
+
+7.2.7.  Forwarded and Forwardable Tickets
+
+
+   forwarded
+        indicates a forwarded ticket
+
+
+   forwardable
+        indicates that forwarded tickets may be issued based on this
+        ticket
+
+
+   [ KCLAR 2.6. ]
+
+
+   Authentication forwarding is an instance of a proxy where the service
+   that is granted is 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
+
+
+Yu                         Expires: Apr 2005                   [Page 33]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   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.
+
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+
+7.3.  Transited Realms
+
+
+   [ KCLAR 2.7., plus new stuff ]
+
+
+7.4.  Authorization Data
+
+
+   [ KCLAR 5.2.6. ]
+
+
+      ADType          ::= TH-id
+
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+
+   ad-type
+        This field identifies the contents of the ad-data.  All negative
+        values are reserved for local use.  Non-negative values are
+        reserved for registered use.
+
+
+   ad-data
+        This field contains authorization data to be interpreted
+        according to the value of the corresponding ad-type field.
+
+
+   Each sequence of ADType and OCTET STRING is referred 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
+   AuthorizationData, and the interpretation of the encapsulating
+   element determines which enclosed elements must be interpreted, and
+   which may be ignored.
+
+
+   Depending on the meaning of the encapsulating element, the
+   encapsulated AuthorizationData may be ignored, interpreted as issued
+   directly by the KDC, or be stored in a separate plaintext part of the
+   ticket.  The types of the encapsulating elements are specified as
+
+
+Yu                         Expires: Apr 2005                   [Page 34]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   part of the Kerberos protocol because behavior based on these
+   container elements should be understood across implementations, while
+   other elements need only be understood by the applications which they
+   affect.
+
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator.  Unless encapsulated in a known
+   authorization data element modifying the criticality of the elements
+   it contains, an application server MUST reject the authentication of
+   a client whose AP-REQ or ticket contains an unrecognized
+   authorization data element.  Authorization data is intended to
+   restrict the use of a ticket.  If the service cannot determine
+   whether it is the target of a restriction, a security weakness may
+   exist if the ticket can be used for that service.  Authorization
+   elements that are truly optional can be enclosed in AD-IF-RELEVANT
+   element.
+
+
+
+      ad-type |           contents of ad-data
+      ________|_______________________________________
+            1 |   DER encoding of AD-IF-RELEVANT
+            4 |   DER encoding of AD-KDCIssued
+            5 |   DER encoding of AD-AND-OR
+            8 |   DER encoding of AD-MANDATORY-FOR-KDC
+
+
+
+
+7.4.1.  AD-IF-RELEVANT
+
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      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.  The ad-type for AD-IF-RELEVANT is (1).
+
+
+7.4.2.  AD-KDCIssued
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 35]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+
+   ad-checksum
+        A cryptographic checksum computed over the DER encoding of the
+        AuthorizationData in the "elements" field, keyed with the
+        session key.  Its checksumtype is the mandatory checksum type
+        for the encryption type of the session key, and its key usage
+        value is 19.
+
+
+   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
+        AuthorizationData issued by the KDC.
+
+
+   The KDC-issued ad-data field is intended to provide a means for
+   Kerberos credentials to embed within themselves privilege attributes
+   and other mechanisms for positive authorization, amplifying the
+   privileges of the principal beyond what it would have if using
+   credentials without such an authorization-data element.
+
+
+   This amplification of privileges cannot 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).  AuthorizationData encapsulated with in the
+   AD-KDCIssued element MUST be ignored by the application server if
+   this "signature" is not present.  Further, AuthorizationData
+   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
+
+
+Yu                         Expires: Apr 2005                   [Page 36]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   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 encapsulates MAY be safely ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+
+7.4.3.  AD-AND-OR
+
+
+      ad-and-or               ADType ::= int32 : 5
+
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisfied.  Therefore, 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.
+
+
+   The ad-type for AD-AND-OR is (5).
+
+
+7.4.4.  AD-MANDATORY-FOR-KDC
+
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+   be interpreted by the KDC.  KDCs that do not understand the type of
+   an element embedded within the mandatory-for-kdc element MUST reject
+   the request.
+
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+
+7.5.  Encrypted Part of Ticket
+
+
+   The complete definition of the encrypted part is
+
+
+
+Yu                         Expires: Apr 2005                   [Page 37]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+   with the common portion being
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+   The encrypted part of the backwards-compatibility form of a ticket
+   is:
+
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+   The encrypted part of the extensible form of a ticket is:
+
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 38]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+7.6.  Cleartext Part of Ticket
+
+
+   The complete definition of Ticket is:
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+   with the common portion being:
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+
+   The "sname" field provides the name of the target service principal
+   in cleartext, as a hint to aid the server in choosing the correct
+   decryption key.
+
+
+   The backwards-compatibility form of Ticket is:
+
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+
+   The extensible form of Ticket is:
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 39]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+   TicketExtensions, which may only be present in the extensible form of
+   Ticket, are a cleartext typed hole for extension use.
+   AuthorizationData already provides an encrypted typed hole.
+
+
+      TEType                  ::= TH-id
+
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+
+   A client will only receive an extensible Ticket if the application
+   server supports extensibility.
+
+
+8.  Credential Acquisition
+
+
+   There are two exchanges that can be used for acquiring credentials:
+   the AS exchange and the TGS exchange.  These exchanges have many
+   similarities, and this document describes them in parallel, noting
+   which behaviors are specific to one type of exchange.  The AS request
+   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
+   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
+   are forms of KDC replies (KDC-REP).
+
+
+   The credentials acquisition protocol operates over specific
+   transports.  Additionally, specific methods exist to permit a client
+   to discover the KDC host with which to communicate.
+
+
+8.1.  KDC-REQ
+
+
+   The KDC-REQ has a large number of fields in common between the RFC
+   1510 and the extensible versions.  The KDC-REQ type itself is never
+   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 40]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+
+   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
+   an EncTicketPartCommon.  The KDC copies most of them unchanged,
+   provided that the requested values meet site policy.
+
+
+Yu                         Expires: Apr 2005                   [Page 41]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   kdc-options
+        These flags do not correspond directly to "flags" in
+        EncTicketPartCommon.
+
+
+   cname
+        This field is copied to the "cname" field in
+        EncTicketPartCommon.  The "cname" field is required in an AS-
+        REQ; the client places its own name here.  In a TGS-REQ, the
+        "cname" in the ticket in the AP-REQ takes precedence.
+
+
+   realm
+        This field is the server's realm, and also holds the client's
+        realm in an AS-REQ.
+
+
+   sname
+        The "sname" field indicates the server's name.  It may be absent
+        in a TGS-REQ which requests user-to-user authentication, in
+        which case the "sname" of the issued ticket will be taken from
+        the included additional ticket.
+
+
+   The "from", "till", and "rtime" fields correspond to the "starttime",
+   "endtime", and "renew-till" fields of EncTicketPartCommon.
+
+
+   addresses
+        This field corresponds to the "caddr" field of
+        EncTicketPartCommon.
+
+
+   enc-authorization-data
+        For TGS-REQ, this field contains authorization data encrypted
+        using either the TGT session key or the AP-REQ subsession key;
+        the KDC may copy these into the "authorization-data" field of
+        EncTicketPartCommon if policy permits.
+
+
+   lang-tags
+        Only present in the extensible messages.  Specifies the set of
+        languages which the client is willing to accept in error
+        messages.
+
+
+   KDC options used in a KDC-REQ are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 42]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+   Different options apply to different phases of KDC-REQ processing.
+
+
+   The backwards-compatibility form of a KDC-REQ is:
+
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+
+   The extensible form of a KDC-REQ is:
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+
+   The backwards-compatibility form of a KDC-REQ-BODY is:
+
+
+Yu                         Expires: Apr 2005                   [Page 43]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+
+   The extensible form of a KDC-REQ-BODY is:
+
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+
+   The AS-REQ is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 44]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+
+   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
+   if the client does not know that the KDC supports the extensibility
+   framework.  A client SHOULD send the extensible AS-REQ alternative in
+   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
+   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
+   what if their contents conflict? ]
+
+
+   The TGS-REQ is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 45]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+
+8.2.  PA-DATA
+
+
+   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
+   authenticate an AS-REQ; they may also modify several of the
+   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
+   to the client about which long-term key (usually password-derived) to
+   use.  PA-DATA may also include "hints" about which pre-authentication
+   mechanisms to use, or include data for input into a pre-
+   authentication mechanism.
+
+
+   [ XXX enumerate standard padata here ]
+
+
+8.3.  KDC-REQ Processing
+
+
+   Processing of a KDC-REQ proceeds through several steps.  An
+   implementation need not perform these steps exactly as described, as
+   long as it behaves as if the steps were performed as described.  The
+   KDC performs replay handling upon receiving the request; it then
+   validates the request, adjusts timestamps, and selects the keys used
+   in the reply.  It copies data from the request into the issued
+   ticket, adjusting the values to conform with its policies.  The KDC
+   then transmits the reply to the client.
+
+
+8.3.1.  Handling Replays
+
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+
+
+Yu                         Expires: Apr 2005                   [Page 46]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   successfully processed, the KDC MUST respond with a KDC-REP message
+   rather than a replay error.  In order to reduce the amount of
+   ciphertext given to a potential attacker, KDCs MAY send the same
+   response generated when the request was first handled.  KDCs MUST
+   obey this replay behavior even if the actual transport in use is
+   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
+   and the entire request is not identical to a recently successfully
+   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
+   appropriate for AP-REQ processing.
+
+
+8.3.2.  Request Validation
+
+
+8.3.2.1.  AS-REQ Authentication
+
+
+   Site policy determines whether a given client principal is required
+   to provide some pre-authentication prior to receiving an AS-REP.
+   Since the default reply key is typically the client's long-term
+   password-based key, an attacker may easily request known plaintext
+   (in the form of an AS-REP) upon which to mount a dictionary attack.
+   Pre-authentication can limit the possibility of such an attack.
+
+
+   If site policy requires pre-authentication for a client principal,
+   and no pre-authentication is provided, the KDC returns the error
+   "kdc-err-preauth-required".  Accompanying this error are "e-data"
+   which include hints telling the client which pre-authentication
+   mechanisms to use, or data for input to pre-authentication mechanisms
+   (e.g., input to challenge-response systems).  If pre-authentication
+   fails, the KDC returns the error "kdc-err-preauth-failed".
+
+
+   [ may need additional changes based on Sam's preauth draft ]
+
+
+8.3.2.2.  TGS-REQ Authentication
+
+
+   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
+   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
+   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
+   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
+   request.  [ padata not signed by authenticator! ] Any error from the
+   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
+   The service principal in the ticket of the AP-REQ may be a ticket-
+   granting service principal, or a normal application service
+   principal.  A ticket which is not a ticket-granting ticket MUST NOT
+   be used to issue a ticket for any service other than the one named in
+   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
+   forwarded?]  option must be set in the request.
+
+
+8.3.2.3.  Principal Validation
+
+
+   If the client principal in an AS-REQ is unknown, the KDC returns the
+   error "kdc-err-c-principal-unknown".  If the server principal in a
+   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
+
+
+Yu                         Expires: Apr 2005                   [Page 47]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   unknown".
+
+
+8.3.2.4.  Checking For Revoked or Invalid Tickets
+
+
+   [ KCLAR 3.3.3.1 ]
+
+
+   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 to the KDC for the realm in which
+   the server resides.  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.  If TGTs have been issued for cross-realm authentication, use
+   of the cross-realm TGT will not be affected unless the hot-list is
+   propagated to the KDCs for the realms for which such cross-realm
+   tickets were issued.
+
+
+   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
+   issue any ticket unless the TGS-REQ requests the "validate" option.
+
+
+8.3.3.  Timestamp Handling
+
+
+   [ some aspects of timestamp handling, especially regarding postdating
+   and renewal, are difficult to read in KCLAR... needs closer
+   examination here ]
+
+
+   Processing of "starttime" (requested in the "from" field) differs
+   depending on whether the "postdated" option is set in the request.
+   If the "postdated" option is not set, and the requested "starttime"
+   is in the future beyond the window of acceptable clock skew, the KDC
+   returns the error "kdc-err-cannot-postdate".  If the "postdated"
+   option is not set, and the requested "starttime" is absent or does
+   not indicate a time in the future beyond the acceptable clock skew,
+   the KDC sets the "starttime" to the KDC's current time.  The
+   "postdated" option MUST NOT be honored if the ticket is being
+   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
+   Otherwise, if the "postdated" option is set, and site policy permits,
+   the KDC sets the "starttime" as requested, and sets the "invalid"
+   flag in the new ticket.
+
+
+   The "till" field is required in the RFC 1510 version of the KDC-REQ.
+   If the "till" field is equal to "19700101000000Z" (midnight, January
+   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
+
+
+   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
+   "renew-till" time is later than the "renew-till" time of the ticket
+
+
+Yu                         Expires: Apr 2005                   [Page 48]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   from which it is derived.
+
+
+8.3.3.1.  AS-REQ Timestamp Processing
+
+
+   In the AS exchange, the "authtime" of a ticket is set to the local
+   time at the KDC.
+
+
+   The "endtime" of the ticket will be set to the earlier of the
+   requested "till" time and a time determined by local policy, possibly
+   determined using factors specific to the realm or principal.  For
+   example, the expiration time MAY be set to the earliest of the
+   following:
+
+
+      * the expiration time ("till" value) requested
+
+
+      * the ticket's start time plus the maximum allowable lifetime
+        associated with the client principal from the authentication
+        server's database
+
+
+      * 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.
+
+
+   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 MAY be set to the earliest 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
+
+
+8.3.3.2.  TGS-REQ Timestamp Processing
+
+
+   In the TGS exchange, the KDC sets the "authtime" to that of the
+   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
+   server can print a ticket for itself with a spoofed authtime.
+
+
+Yu                         Expires: Apr 2005                   [Page 49]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   security issues for hot-list?] [ MIT implementation may change
+   authtime of renewed tickets; needs check... ]
+
+
+   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
+   requests an "endtime" (in the "till" field), then the "endtime" of
+   the new ticket is set to the minimum of
+
+
+      * the requested "endtime" value,
+
+
+      * the "endtime" in the TGT, and
+
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+
+   If the new ticket is a renewal, the "endtime" of the new ticket is
+   bounded by the minimum of
+
+
+      * the requested "endtime" value,
+
+
+      * the value of the "renew-till" value of the old,
+
+
+      * the "starttime" of the new ticket plus the lifetime (endtime
+        minus starttime) of the old ticket, i.e., the lifetime of the
+        new ticket may not exceed that of the ticket being renewed [
+        adapted from KCLAR 3.3.3. ], and
+
+
+      * an "endtime" determined by site policy on ticket lifetimes.
+
+
+   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
+   a "starttime", "endtime", or "renew-till" time later than the
+   "renew-till" time of the TGT.
+
+
+8.3.4.  Handling Transited Realms
+
+
+   The KDC checks the ticket in a TGS-REQ against site policy, unless
+   the "disable-transited-check" option is set in the TGS-REQ.  If site
+   policy permits the transit path in the TGS-REQ ticket, the KDC sets
+   the "transited-policy-checked" flag in the issued ticket.  If the
+   "disable-transited-check" option is set, the issued ticket will have
+   the "transited-policy-checked" flag cleared.
+
+
+8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
+   copied into the issued ticket.  If the "addresses" field is absent or
+   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
+   TGS-REQ into the issued ticket, unless the either "forwarded" or
+   "proxy" option is set.  If the "forwarded" option is set, and the
+   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
+   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
+   issued ticket.  The KDC behaves similarly if the "proxy" option is
+   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
+   The "proxy" option will not be honored on requests for additional
+   ticket-granting tickets.
+
+
+Yu                         Expires: Apr 2005                   [Page 50]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+8.3.6.  Ticket Flag Processing
+
+
+   Many kdc-options request that the KDC set a corresponding flag in the
+   issued ticket.  kdc-options marked with an asterisk (*) in the
+   following table do not directly request the corresponding ticket flag
+   and therefore require special handling.
+
+
+
+             kdc-option       |    ticket flag affected
+      ________________________|__________________________
+      forwardable             |  forwardable
+      forwarded               |  forwarded
+      proxiable               |  proxiable
+      proxy                   |  proxy
+      allow-postdate          |  may-postdate
+      postdated               |  postdated
+      renewable               |  renewable
+      requestanonymous        |  anonymous
+      canonicalize            |  -
+      disable-transited-check*|  transited-policy-checked
+      renewable-ok*           |  renewable
+      enc-tkt-in-skey         |  -
+      renew                   |  -
+      validate*               |  invalid
+
+
+
+
+   forwarded
+        The KDC sets the "forwarded" flag in the issued ticket if the
+        "forwarded" option is set in the TGS-REQ and the "forwardable"
+        flag is set in the TGS-REQ ticket.
+
+
+   proxy
+        The KDC sets the "proxy" flag in the issued ticket if the
+        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
+        set in the TGS-REQ ticket.
+
+
+   disable-transited-check
+        The handling of the "disable-transited-check" kdc-option is
+        described in Section 8.3.4.
+
+
+   renewable-ok
+        The handling of the "renewable-ok" kdc-option is described in
+        Section 8.3.3.1.
+
+
+   enc-tkt-in-skey
+        This flag modifies ticket key selection to use the session key
+        of an additional ticket included in the TGS-REQ, for the purpose
+        of user-to-user authentication.
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 51]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   validate
+        If the "validate" kdc-option is set in a TGS-REQ, and the
+        "starttime" has passed, the KDC will clear the "invalid" bit on
+        the ticket before re-issuing it.
+
+
+8.3.7.  Key Selection
+
+
+   Three keys are involved in creating a KDC-REP.  The reply key
+   encrypts the encrypted part of the KDC-REP.  The session key is
+   stored in the encrypted part of the ticket, and is also present in
+   the encrypted part of the KDC-REP so that the client can retrieve it.
+   The ticket key is used to encrypt the ticket.  These keys all have
+   initial values for a given exchange; pre-authentication and other
+   extension mechanisms may change the value used for any of these keys.
+
+
+   [ again, may need changes based on Sam's preauth draft ]
+
+
+8.3.7.1.  Reply Key and Session Key Selection
+
+
+   The set of encryption types which the client will understand appears
+   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
+   of possible reply keys and the set of session key encryption types
+   based on the "etype" field.
+
+
+   For the AS exchange, the reply key is initially a long-term key of
+   the client, limited to those encryption types listed in the "etype"
+   field.  The KDC SHOULD use the first valid strong "etype" for which
+   an encryption key is available.  For the TGS exchange, the reply key
+   is initially the subsession key of the Authenticator.  If the
+   Authenticator subsesion key is absent, the reply key is initially the
+   session key of the ticket used to authenticate the TGS-REQ.
+
+
+   The session key is initially randomly generated, and has an
+   encryption type which both the client and the server will understand.
+   Typically, the KDC has prior knowledge of which encryption types the
+   server will understand.  It selects the first valid strong "etype"
+   listed the request which the server also will understand.
+
+
+8.3.7.2.  Ticket Key Selection
+
+
+   The ticket key is initially the long-term key of the service.  The
+   "enc-tkt-in-skey" option requests user-to-user authentication, where
+   the ticket encryption key of the issued ticket is set equal to the
+   session key of the additional ticket in the request.
+
+
+8.4.  KDC-REP
+
+
+   The important parts of the KDC-REP are encrypted.
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 52]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+   Most of the fields of EncKDCRepPartCom are duplicates of the
+   corresponding fields in the returned ticket.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 53]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 54]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+
+   req-cksum
+        Signature of the original request using the reply key, to avoid
+        replay attacks against the client, among other things.  Only
+        present in the extensible version of KDC-REP.
+
+
+           AS-REP          ::= CHOICE {
+               rfc1510     [APPLICATION 11] KDC-REP-1510 {
+                   EncASRepPart1510
+               } (WITH COMPONENTS { ..., msg-type (11) }),
+               ext         [APPLICATION  7]  Signed {
+                   [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+                   { key-reply }, { ku-ASRep-cksum }
+               } (WITH COMPONENTS { ..., msg-type (7) })
+           }
+
+
+
+           TGS-REP         ::= CHOICE {
+               rfc1510     [APPLICATION 13] KDC-REP-1510 {
+                   EncTGSRepPart1510
+               } (WITH COMPONENTS { ..., msg-type (13) }),
+               ext         [APPLICATION  9]  Signed {
+                   [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+                   { key-reply }, { ku-TGSRep-cksum }
+               } (WITH COMPONENTS { ..., msg-type (9) })
+           }
+
+
+
+   The extensible versions of AS-REQ and TGS-REQ are signed with the
+   reply key, to prevent an attacker from performing a delayed denial-
+   of-service attack by substituting the ticket.
+
+
+8.5.  Reply Validation
+
+
+   [ signature verification ]
+
+
+8.6.  IP Transports
+
+
+   [ KCLAR 7.2 ]
+
+
+   Kerberos defines two IP transport mechanisms for the credentials
+   acquisition protocol: UDP/IP and TCP/IP.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 55]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+8.6.1.  UDP/IP transport
+
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
+   identify the IP address and port to which they will send their
+   request.
+
+
+   When contacting a 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 the KDC. The KDC will respond with a reply
+   datagram containing only an encoding of the reply message (either a
+   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
+   address. The response to a request made through UDP/IP transport MUST
+   also use UDP/IP transport. If the response can not be handled using
+   UDP (for example because it is too large), the KDC MUST return "krb-
+   err-response-too-big", forcing the client to retry the request using
+   the TCP transport.
+
+
+8.6.2.  TCP/IP transport
+
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+   requests and SHOULD listen for such requests on port 88 (decimal)
+   unless specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   initially try a request using the UDP transport. Clients SHOULD use
+   KDC discovery (Section 8.6.3) to identify the IP address and port to
+   which they will send their request.
+
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+
+   When the KDC-REQ message is sent to the KDC over a TCP stream, the
+   response (KDC-REP or KRB-ERROR message) MUST be returned to the
+   client on the same TCP stream that was established for the request.
+   The KDC MAY close the TCP stream after sending a response, but MAY
+   leave the stream open for a reasonable period of time if it expects a
+   followup. Care must be taken in managing TCP/IP connections on the
+   KDC to prevent denial of service attacks based on the number of open
+   TCP/IP connections.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 56]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   anytime after the receipt of a response.  A stream closure SHOULD NOT
+   be treated as a fatal error.  Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication) the client may
+   need to establish a new connection when it is ready to send
+   subsequent messages.  A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   followup messages.
+
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+
+   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
+   the TCP stream is preceded by the length of the request as 4 octets
+   in network byte order. The high bit of the length is reserved for
+   future expansion and MUST currently be set to zero.  If a KDC that
+   does not understand how to interpret a set high bit of the length
+   encoding receives a request with the high order bit of the length
+   set, it MUST return a KRB-ERROR message with the error "krb-err-
+   field-toolong" and MUST close the TCP stream.
+
+
+   If multiple requests are sent over a single TCP connection, and the
+   KDC sends multiple responses, the KDC is not required to send the
+   responses in the order of the corresponding requests.  This may
+   permit some implementations to send each response as soon as it is
+   ready even if earlier requests are still being processed (for
+   example, waiting for a response from an external device or database).
+
+
+8.6.3.  KDC Discovery on IP Networks
+
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored 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 using cross-realm authentication. This section
+   describes a method for using the Domain Name System [RFC 1035] for
+   storing KDC location information.
+
+
+8.6.3.1.  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
+   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
+   and "MyRealm" are all different, but resolve the same in the domain
+   name system, it is necessary that only one of the possible
+   combinations of upper and lower case characters be used in realm
+
+
+Yu                         Expires: Apr 2005                   [Page 57]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   names.
+
+
+8.6.3.2.  DNS SRV records for KDC location
+
+
+   KDC location information is to be stored using the DNS SRV RR [RFC
+   2782].  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 one of "udp", "tcp". If these SRV records are to be
+   used, both "udp" and "tcp" records MUST be specified for all KDC
+   deployments.
+
+
+   The Realm is the Kerberos realm that this record corresponds to.  The
+   realm MUST be a domain style realm name.
+
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2782.
+
+
+   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal) unless the KDC is configured
+   to listen on an alternate TCP port.
+
+
+   Implementation note: Many existing client implementations do not
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+
+8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
+
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority.  Weights are not used in these sample records.
+
+
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
+      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
+
+
+
+9.  Errors
+
+
+   The KRB-ERROR message is returned by the KDC if an error occurs
+   during credentials acquisition.  It may also be returned by an
+   application server if an error occurs during authentication.
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 58]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      ErrCode ::= Int32
+
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+
+   The extensible KRB-ERROR is only signed if there has been a key
+   negotiated with its recipient.  KRB-ERROR messages sent in response
+   to AS-REQ messages will probably not be signed unless a
+   preauthentication mechanism has negotiated a key.  (Signing using a
+   client's long-term key can expose ciphertext to dictionary attacks.)
+
+
+   The parts of a KRB-ERROR common to both the backwards-compatibility
+   and the extensibile messages are
+
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+
+Yu                         Expires: Apr 2005                   [Page 59]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   ctime, cusec
+        Client's time, if known from a KDC-REQ or AP-REQ.
+
+
+   stime, susec
+        KDC or application server's current time.
+
+
+   error-code
+        Numeric error code designating the error.
+
+
+   crealm, cname
+        Client's realm and name, if known.
+
+
+   realm, sname
+        server's realm and name. [ XXX what if these aren't known? ]
+
+
+   e-text
+        Human-readable text providing additional details for the error.
+
+
+   e-data
+        This field contains additional data about the error for use by
+        the client to help it recover from or handle the error. If the
+        "error-code" is "kdc-err-preauth-required", then the e-data
+        field will contain an encoding of a sequence of padata fields,
+        each corresponding to an acceptable pre-authentication method
+        and optionally containing data for the method:
+
+
+           METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+
+        For error codes defined in this document other than "kdc-err-
+        preauth-required", the format and contents of the e-data field
+        are implementation-defined.  Similarly, for future error codes,
+        the format and contents of the e-data field are implementation-
+        defined unless specified.
+
+
+   lang-tag
+        Indicates the language of the message in the "e-text" field.  It
+        is only present in the extensible KRB-ERROR.
+
+
+   nonce
+        is the nonce from a KDC-REQ.  It is only present in the
+        extensible KRB-ERROR.
+
+
+   typed-data
+        TYPED-DATA is a typed hole allowing for additional data to be
+        returned in error conditions, since "e-data" is insufficiently
+        flexible for some purposes.  TYPED-DATA is only present in the
+        extensible KRB-ERROR.
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 60]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+           TDType ::= TH-id
+
+
+           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+               data-type   [0] TDType,
+               data-value  [1] OCTET STRING OPTIONAL
+           }
+
+
+
+10.  Session Key Exchange
+
+
+   Session key exchange consists of the AP-REQ and AP-REP messages.  The
+   client sends the AP-REQ message, and the service responds with an
+   AP-REP message if mutual authentication is desired.  Following
+   session key exchange, the client and service share a secret session
+   key, or possibly a subsesion key, which can be used to protect
+   further communications.  Additionally, the session key exchange
+   process can establish initial sequence numbers which the client and
+   service can use to detect replayed messages.
+
+
+10.1.  AP-REQ
+
+
+   An AP-REQ message contains a ticket and a authenticator.  The
+   authenticator is ciphertext encrypted with the session key contained
+   in the ticket.  The plaintext contents of the authenticator are:
+
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+   The common parts between the RFC 1510 and the extensible versions of
+   the AP-REQ are:
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 61]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+   The complete definition of AP-REQ is:
+
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 62]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+
+10.2.  AP-REP
+
+
+   An AP-REP message provides mutual authentication of the service to
+   the client.
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+
+Yu                         Expires: Apr 2005                   [Page 63]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 64]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+
+11.  Session Key Use
+
+
+   Once a session key has been established, the client and server can
+   use several kinds of messages to securely transmit data.  KRB-SAFE
+   provides integrity protection for application data, while KRB-PRIV
+   provides confidentiality along with integrity protection.  The KRB-
+   CRED message provides a means of securely forwarding credentials from
+   the client host to the server host.
+
+
+11.1.  KRB-SAFE
+
+
+   The KRB-SAFE message provides integrity protection for an included
+   cleartext message.
+
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+11.2.  KRB-PRIV
+
+
+   The KRB-PRIV message provides confidentiality and integrity
+   protection.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 65]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+11.3.  KRB-CRED
+
+
+   The KRB-CRED message provides a means of securely transferring
+   credentials from the client to the service.
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 66]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+
+12.  Security Considerations
+
+
+12.1.  Time Synchronization
+
+
+   Time synchronization between the KDC and application servers is
+   necessary to prevent acceptance of expired tickets.
+
+
+   Time synchronization is needed between application servers and
+   clients to prevent replay attacks if a replay cache is being used.
+   If negotiated subsession keys are used to encrypt application data,
+   replay caches may not be necessary.
+
+
+12.2.  Replays
+
+
+12.3.  Principal Name Reuse
+
+
+   See Section 5.3.
+
+
+12.4.  Password Guessing
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 67]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+12.5.  Forward Secrecy
+
+
+   [from KCLAR 10.; needs some rewriting]
+
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB-PRIV message,
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if any of the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages is
+   transmitted over the network encrypted in the key of the application
+   server, and also encrypted under the session key from the user's
+   ticket-granting ticket when returned to the user in the TGS-REP
+   message.  The session key from the ticket-granting ticket was sent to
+   the user in the AS-REP message encrypted in the user's secret key,
+   and embedded in the ticket-granting ticket, which was encrypted in
+   the key of the KDC.  Application requiring perfect forward secrecy
+   must exchange keys through mechanisms that provide such assurance,
+   but may use Kerberos for authentication of the encrypted channel
+   established through such other means.
+
+
+12.6.  Authorization
+
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  Kerberos does not, by
+   itself, provide authorization.  Applications SHOULD NOT accept the
+   mere issuance of a service ticket by the Kerberos server as granting
+   authority to use the service.
+
+
+12.7.  Login Authentication
+
+
+   Some applications, particularly those which provide login access when
+   provided with a password, SHOULD NOT treat successful acquisition of
+   credentials as sufficient proof of the user's identity.  An attacker
+   posing as a user could generate an illegitimate KDC-REP message which
+   decrypts properly.  To authenticate a user logging on to a local
+   system, the credentials obtained SHOULD be used in a TGS exchange to
+   obtain credentials for a local service.  Successful use of those
+   credentials to authenticate to the local service assures that the
+   initially obtained credentials are from a valid KDC.
+
+
+13.  IANA Considerations
+
+
+   [ needs more work ]
+
+
+   Each use of Int32 in this document defines a number space.  [ XXX
+   enumerate these ] Negative numbers are reserved for private use;
+   local and experimental extensions should use these values.  Zero is
+   reserved and may not be assigned.
+
+
+
+Yu                         Expires: Apr 2005                   [Page 68]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   Typed hole contents may be identified by either Int32 values or by
+   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
+   namespace, assignments to the top level of the RELATIVE-OID space may
+   be made on a first-come, first-served basis.
+
+
+14.  Acknowledgments
+
+
+   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
+   clarifications-07.  The description of the general form of the
+   extensibility framework was derived from text by Sam Hartman.
+
+
+Appendices
+
+
+A.  ASN.1 Module (Normative)
+
+
+      KerberosV5Spec3 {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2) modules(4) krb5spec3(4)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+
+      -- OID arc for KerberosV5
+      --
+      -- This OID may be used to identify Kerberos protocol messages
+      -- encapsulated in other protocols.
+      --
+      -- This OID also designates the OID arc for KerberosV5-related
+      -- OIDs.
+      --
+      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
+      -- OID.
+      id-krb5         OBJECT IDENTIFIER ::= {
+          iso(1) identified-organization(3) dod(6) internet(1)
+          security(5) kerberosV5(2)
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 69]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- top-level type
+      --
+      -- Applications should not directly reference any types
+      -- other than KRB-PDU and its component types.
+      --
+      KRB-PDU         ::= CHOICE {
+          ticket      Ticket,
+          as-req      AS-REQ,
+          as-rep      AS-REP,
+          tgs-req     TGS-REQ,
+          tgs-rep     TGS-REP,
+          ap-req      AP-REQ,
+          ap-rep      AP-REP,
+          krb-safe    KRB-SAFE,
+          krb-priv    KRB-PRIV,
+          krb-cred    KRB-CRED,
+          tgt-req     TGT-REQ,
+          krb-error   KRB-ERROR,
+          ...
+      }
+
+
+
+      --
+      -- *** basic types
+      --
+
+
+
+      -- signed values representable in 32 bits
+      --
+      -- These are often used as assigned numbers for various things.
+      Int32           ::= INTEGER (-2147483648..2147483647)
+
+
+
+      -- Typed hole identifiers
+      TH-id           ::= CHOICE {
+          int32               Int32,
+          rel-oid             RELATIVE-OID
+      }
+
+
+
+      -- unsigned 32 bit values
+      UInt32          ::= INTEGER (0..4294967295)
+
+
+
+      -- unsigned 64 bit values
+      UInt64          ::= INTEGER (0..18446744073709551615)
+
+
+
+      -- sequence numbers
+      SeqNum          ::= UInt64
+
+
+
+Yu                         Expires: Apr 2005                   [Page 70]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- nonces
+      Nonce           ::= UInt64
+
+
+
+      -- microseconds
+      Microseconds    ::= INTEGER (0..999999)
+
+
+
+      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
+                              -- MUST NOT include fractional seconds
+      })
+
+
+
+      -- used for names and for error messages
+      KerberosString  ::= CHOICE {
+          ia5         GeneralString (IA5String),
+          utf8        UTF8String,
+          ...         -- no extension may be sent
+                      -- to an rfc1510 implementation --
+      }
+
+
+
+      -- IA5 choice only; useful for constraints
+      KerberosStringIA5       ::= KerberosString
+          (WITH COMPONENTS { ia5 PRESENT })
+
+
+      -- IA5 excluded; useful for constraints
+      KerberosStringExt       ::= KerberosString
+          (WITH COMPONENTS { ia5 ABSENT })
+
+
+
+      -- used for language tags
+      LangTag ::= PrintableString
+          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 71]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- assigned numbers for name types (used in principal names)
+      NameType        ::= Int32
+
+
+      -- Name type not known
+      nt-unknown              NameType ::= 0
+      -- Just the name of the principal as in DCE, or for users
+      nt-principal            NameType ::= 1
+      -- Service and other unique instance (krbtgt)
+      nt-srv-inst             NameType ::= 2
+      -- Service with host name as instance (telnet, rcommands)
+      nt-srv-hst              NameType ::= 3
+      -- Service with host as remaining components
+      nt-srv-xhst             NameType ::= 4
+      -- Unique ID
+      nt-uid                  NameType ::= 5
+      -- Encoded X.509 Distingished name [RFC 2253]
+      nt-x500-principal       NameType ::= 6
+      -- Name in form of SMTP email name (e.g. user@foo.com)
+      nt-smtp-name            NameType ::= 7
+      -- Enterprise name - may be mapped to principal name
+      nt-enterprise           NameType ::= 10
+
+
+
+      PrincipalName   ::= SEQUENCE {
+          name-type   [0] NameType,
+          -- May have zero elements, or individual elements may be
+          -- zero-length, but this is NOT RECOMMENDED.
+          name-string [1] SEQUENCE OF KerberosString
+      }
+
+
+
+      -- IA5 only
+      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringIA5))
+      })
+
+
+      -- IA5 excluded
+      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
+          ...,
+          name-string (WITH COMPONENT (KerberosStringExt))
+      })
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 72]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      Realm           ::= KerberosString
+
+
+      -- IA5 only
+      RealmIA5        ::= Realm (KerberosStringIA5)
+
+
+      -- IA5 excluded
+      RealmExt        ::= Realm (KerberosStringExt)
+
+
+
+      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
+          (CONSTRAINED BY {
+          -- MUST be a valid value of -- NamedBits
+          -- but if the value to be sent would be truncated to shorter
+          -- than 32 bits according to DER, the value MUST be padded
+          -- with trailing zero bits to 32 bits.  Otherwise, no
+          -- trailing zero bits may be present.
+
+
+      })
+
+
+
+      AddrType        ::= Int32
+
+
+      HostAddress     ::= SEQUENCE  {
+          addr-type   [0] AddrType,
+          address     [1] OCTET STRING
+      }
+
+
+      -- NOTE: HostAddresses is always used as an OPTIONAL field and
+      -- should not be a zero-length SEQUENCE OF.
+      --
+      -- The extensible messages explicitly constrain this to be
+      -- non-empty.
+      HostAddresses   ::= SEQUENCE OF HostAddress
+
+
+
+      --
+      -- *** crypto-related types and assignments
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 73]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Assigned numbers denoting encryption mechanisms.
+      EType ::= Int32
+
+
+      -- assigned numbers for encryption schemes
+      et-des-cbc-crc                  EType ::= 1
+      et-des-cbc-md4                  EType ::= 2
+      et-des-cbc-md5                  EType ::= 3
+      --     [reserved]                         4
+      et-des3-cbc-md5                 EType ::= 5
+      --     [reserved]                         6
+      et-des3-cbc-sha1                EType ::= 7
+      et-dsaWithSHA1-CmsOID           EType ::= 9
+      et-md5WithRSAEncryption-CmsOID  EType ::= 10
+      et-sha1WithRSAEncryption-CmsOID EType ::= 11
+      et-rc2CBC-EnvOID                EType ::= 12
+      et-rsaEncryption-EnvOID         EType ::= 13
+      et-rsaES-OAEP-ENV-OID           EType ::= 14
+      et-des-ede3-cbc-Env-OID         EType ::= 15
+      et-des3-cbc-sha1-kd             EType ::= 16
+      -- AES
+      et-aes128-cts-hmac-sha1-96      EType ::= 17
+      -- AES
+      et-aes256-cts-hmac-sha1-96      EType ::= 18
+      -- Microsoft
+      et-rc4-hmac                     EType ::= 23
+      -- Microsoft
+      et-rc4-hmac-exp                 EType ::= 24
+      -- opaque; PacketCable
+      et-subkey-keymaterial           EType ::= 65
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 74]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Assigned numbers denoting key usages.
+      KeyUsage ::= UInt32
+
+
+      --
+      -- Actual identifier names are provisional and subject to
+      -- change.
+      --
+      ku-pa-enc-ts                    KeyUsage ::= 1
+      ku-Ticket                       KeyUsage ::= 2
+      ku-EncASRepPart                 KeyUsage ::= 3
+      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
+      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
+      ku-pa-TGSReq-cksum              KeyUsage ::= 6
+      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
+      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
+      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
+      ku-Authenticator-cksum          KeyUsage ::= 10
+      ku-APReq-authenticator          KeyUsage ::= 11
+      ku-EncAPRepPart                 KeyUsage ::= 12
+      ku-EncKrbPrivPart               KeyUsage ::= 13
+      ku-EncKrbCredPart               KeyUsage ::= 14
+      ku-KrbSafe-cksum                KeyUsage ::= 15
+      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
+
+
+
+      -- The following numbers are provisional...
+      -- conflicts may exist elsewhere.
+      ku-Ticket-cksum                 KeyUsage ::= 25
+      ku-ASReq-cksum                  KeyUsage ::= 26
+      ku-TGSReq-cksum                 KeyUsage ::= 27
+      ku-ASRep-cksum                  KeyUsage ::= 28
+      ku-TGSRep-cksum                 KeyUsage ::= 29
+      ku-APReq-cksum                  KeyUsage ::= 30
+      ku-APRep-cksum                  KeyUsage ::= 31
+      ku-KrbCred-cksum                KeyUsage ::= 32
+      ku-KrbError-cksum               KeyUsage ::= 33
+      ku-KDCRep-cksum                 KeyUsage ::= 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 75]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- KeyToUse identifies which key is to be used to encrypt or
+      -- sign a given value.
+      --
+      -- Values of KeyToUse are never actually transmitted over the
+      -- wire, or even used directly by the implementation in any
+      -- way, as key usages are; it exists primarily to identify
+      -- which key gets used for what purpose.  Thus, the specific
+      -- numeric values associated with this type are irrelevant.
+      KeyToUse        ::= ENUMERATED {
+          -- unspecified
+          key-unspecified,
+          -- server long term key
+          key-server,
+          -- client long term key
+          key-client,
+          -- key selected by KDC for encryption of a KDC-REP
+          key-kdc-rep,
+          -- session key from ticket
+          key-session,
+          -- subsession key negotiated via AP-REQ/AP-REP
+          key-subsession,
+          ...
+      }
+
+
+
+      EncryptionKey   ::= SEQUENCE {
+          keytype     [0] EType,
+          keyvalue    [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 76]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+
+      -- "Type" specifies which ASN.1 type is encrypted to the
+      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
+      -- keys of which one key may be used to encrypt the data.
+      -- "KeyUsages" specifies a set of key usages, one of which may
+      -- be used to encrypt.
+      --
+      -- None of the parameters is transmitted over the wire.
+      EncryptedData {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          etype       [0] EType,
+          kvno        [1] UInt32 OPTIONAL,
+          cipher      [2] OCTET STRING (CONSTRAINED BY {
+              -- must be encryption of --
+              OCTET STRING (CONTAINING Type),
+              -- with one of the keys -- KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          }),
+          ...
+      }
+
+
+
+
+      CksumType       ::= Int32
+
+
+      -- The parameters specify which key to use to produce the
+      -- signature, as well as which key usage to use.  The
+      -- parameters are not actually sent over the wire.
+      Checksum {
+          KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksumtype   [0] CksumType,
+          checksum    [1] OCTET STRING (CONSTRAINED BY {
+              -- signed using one of the keys --
+              KeyToUse:Keys,
+              -- with key usage being one of --
+              KeyUsage:KeyUsages
+          })
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 77]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- a Checksum that must contain the checksum
+      -- of a particular type
+      ChecksumOf {
+          Type, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
+          ...,
+          checksum (CONSTRAINED BY {
+              -- must be checksum of --
+              OCTET STRING (CONTAINING Type)
+          })
+      })
+
+
+
+      -- parameterized type for wrapping authenticated plaintext
+      Signed {
+          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
+      } ::= SEQUENCE {
+          cksum       [0] ChecksumOf {
+              InnerType, Keys, KeyUsages
+          } OPTIONAL,
+          inner       [1] InnerType,
+          ...
+      }
+
+
+
+      --
+      -- *** Tickets
+      --
+
+
+
+      Ticket          ::= CHOICE {
+          rfc1510     [APPLICATION 1] Ticket1510,
+          ext         [APPLICATION 4] Signed {
+              TicketExt, { key-server }, { ku-Ticket-cksum }
+          }
+      }
+
+
+
+      -- takes a parameter specifying which type gets encrypted
+      TicketCommon { EncPart } ::= SEQUENCE {
+          tkt-vno     [0] INTEGER (5),
+          realm       [1] Realm,
+          sname       [2] PrincipalName,
+          enc-part    [3] EncryptedData {
+              EncPart, { key-server }, { ku-Ticket }
+          },
+          ...,
+          extensions          [4] TicketExtensions OPTIONAL,
+          ...
+      }
+
+
+
+Yu                         Expires: Apr 2005                   [Page 78]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      Ticket1510 ::= SEQUENCE {
+          COMPONENTS OF TicketCommon { EncTicketPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          realm (RealmIA5),
+          sname (PrincipalNameIA5)
+      })
+
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      TicketExt ::= [APPLICATION 4] TicketCommon {
+          EncTicketPartExt
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          realm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+      -- Encrypted part of ticket
+      EncTicketPart ::= CHOICE {
+          rfc1510     [APPLICATION 3] EncTicketPart1510,
+          ext         [APPLICATION 5] EncTicketPartExt
+      }
+
+
+
+      EncTicketPartCommon ::= 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,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 79]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      EncTicketPart1510 ::= SEQUENCE {
+          COMPONENTS OF EncTicketPartCommon
+      } (WITH COMPONENTS {
+          ...,
+          -- explicitly force IA5 in strings
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
+          ...,
+          -- explicitly force UTF-8 in strings
+          crealm (RealmExt),
+          cname (PrincipalNameExt),
+          -- explicitly constrain caddr to be non-empty if present
+          caddr (SIZE (1..MAX)),
+          -- forbid empty authorization-data encodings
+          authorization-data (SIZE (1..MAX))
+      })
+
+
+
+      --
+      -- *** Authorization Data
+      --
+
+
+
+      ADType          ::= TH-id
+
+
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+          ad-type             [0] ADType,
+          ad-data             [1] OCTET STRING
+      }
+
+
+
+      ad-if-relevant          ADType ::= int32 : 1
+
+
+      -- Encapsulates another AuthorizationData.
+      -- Intended for application servers; receiving application servers
+      -- MAY ignore.
+      AD-IF-RELEVANT          ::= AuthorizationData
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 80]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- KDC-issued privilege attributes
+      ad-kdcissued            ADType ::= int32 : 4
+
+
+      AD-KDCIssued            ::= SEQUENCE {
+          ad-checksum [0] ChecksumOf {
+                              AuthorizationData, { key-session },
+                              { ku-ad-KDCIssued-cksum }},
+          i-realm     [1] Realm OPTIONAL,
+          i-sname     [2] PrincipalName OPTIONAL,
+          elements    [3] AuthorizationData
+      }
+
+
+
+      ad-and-or               ADType ::= int32 : 5
+
+
+      AD-AND-OR               ::= SEQUENCE {
+          condition-count     [0] INTEGER,
+          elements            [1] AuthorizationData
+      }
+
+
+
+      -- KDCs MUST interpret any AuthorizationData wrapped in this.
+      ad-mandatory-for-kdc            ADType ::= int32 : 8
+      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
+
+
+
+      TrType                  ::= TH-id -- must be registered
+
+
+      -- encoded Transited field
+      TransitedEncoding       ::= SEQUENCE {
+          tr-type     [0] TrType,
+          contents    [1] OCTET STRING
+      }
+
+
+
+      TEType                  ::= TH-id
+
+
+      -- ticket extensions: for TicketExt only
+      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          te-type             [0] TEType,
+          te-data             [1] OCTET STRING
+      }
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 81]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
+
+
+      TicketFlagsBits ::= 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),
+          anonymous           (14),
+          cksummed-ticket     (15)
+      }
+
+
+
+      --
+      -- *** KDC protocol
+      --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 82]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AS-REQ  ::= CHOICE {
+          rfc1510     [APPLICATION 10] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (10),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          }),
+          ext         [APPLICATION 6]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 6] KDC-REQ-EXT,
+              -- not sure this is correct key to use; do we even want
+              -- to sign AS-REQ?
+              { key-client },
+              { ku-ASReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (6),
+              -- AS-REQ must include client name
+              req-body (WITH COMPONENTS { ..., cname PRESENT })
+          })
+      }
+
+
+
+      TGS-REQ ::= CHOICE {
+          rfc1510     [APPLICATION 12] KDC-REQ-1510
+          (WITH COMPONENTS {
+              ...,
+              msg-type (12),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          }),
+          ext         [APPLICATION 8]  Signed {
+              -- APPLICATION tag goes inside Signed{} as well as
+              -- outside, to prevent possible substitution attacks.
+              [APPLICATION 8] KDC-REQ-EXT,
+              { key-session }, { ku-TGSReq-cksum }
+          }
+          (WITH COMPONENTS {
+              ...,
+              msg-type  (8),
+              -- client name optional in TGS-REQ
+              req-body (WITH COMPONENTS { ..., cname ABSENT })
+          })
+      }
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 83]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REQ-COMMON  ::= SEQUENCE {
+      -- NOTE: first tag is [1], not [0]
+          pvno        [1] INTEGER (5),
+          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
+                                   | 12 -- TGS-REQ.rfc1510 --
+                                   | 6 -- AS-REQ.ext --
+                                   | 8 -- TGS-REQ.ext -- ),
+          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
+          -- NOTE: not empty
+      }
+
+
+
+      KDC-REQ-1510    ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-1510
+      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
+
+
+
+      -- APPLICATION tag goes inside Signed{} as well as outside,
+      -- to prevent possible substitution attacks.
+      KDC-REQ-EXT     ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-COMMON,
+          req-body    [4] KDC-REQ-BODY-EXT,
+          ...
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (6 | 8),
+          padata (SIZE (1..MAX))
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 84]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REQ-BODY-COMMON     ::= 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
+          -- was required in rfc1510;
+          -- still required for compat versions
+          -- of messages --,
+
+
+          rtime               [6] KerberosTime OPTIONAL,
+          nonce               [7] Nonce,
+          etype               [8] SEQUENCE OF EType
+          -- in preference order --,
+
+
+          addresses           [9] HostAddresses OPTIONAL,
+          enc-authorization-data      [10] EncryptedData {
+              AuthorizationData, { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          } OPTIONAL,
+
+
+          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
+          -- NOTE: not empty --,
+          ...
+          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
+                              LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      KDC-REQ-BODY-1510 ::= SEQUENCE {
+          COMPONENTS OF KDC-REQ-BODY-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameIA5),
+          realm (RealmIA5),
+          sname (PrincipalNameIA5),
+          till PRESENT,
+          nonce (UInt32)
+      })
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 85]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
+      (WITH COMPONENTS {
+          ...,
+          cname (PrincipalNameExt),
+          realm (RealmExt),
+          sname (PrincipalNameExt),
+          addresses (SIZE (1..MAX)),
+          enc-authorization-data (EncryptedData {
+              AuthorizationData (SIZE (1..MAX)),
+              { key-session | key-subsession },
+              { ku-TGSReqAuthData-subkey |
+                ku-TGSReqAuthData-sesskey }
+          }),
+          additional-tickets (SIZE (1..MAX))
+      })
+
+
+
+      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
+
+
+      KDCOptionsBits  ::= BIT STRING {
+          reserved            (0),
+          forwardable         (1),
+          forwarded           (2),
+          proxiable           (3),
+          proxy               (4),
+          allow-postdate      (5),
+          postdated           (6),
+          unused7             (7),
+          renewable           (8),
+          unused9             (9),
+          unused10            (10),
+          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)
+          -- XXX need "need ticket1" flag?
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 86]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AS-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 11] KDC-REP-1510 {
+              EncASRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (11) }),
+          ext         [APPLICATION  7]  Signed {
+              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
+              { key-reply }, { ku-ASRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (7) })
+      }
+
+
+
+      TGS-REP         ::= CHOICE {
+          rfc1510     [APPLICATION 13] KDC-REP-1510 {
+              EncTGSRepPart1510
+          } (WITH COMPONENTS { ..., msg-type (13) }),
+          ext         [APPLICATION  9]  Signed {
+              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
+              { key-reply }, { ku-TGSRep-cksum }
+          } (WITH COMPONENTS { ..., msg-type (9) })
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 87]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
+                                   13 -- TGS.rfc1510 -- |
+                                   7 -- AS-REP.ext -- |
+                                   9 -- TGS-REP.ext -- ),
+          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
+          crealm      [3] Realm,
+          cname       [4] PrincipalName,
+          ticket      [5] Ticket,
+
+
+          enc-part    [6] EncryptedData {
+              EncPart,
+              { key-reply },
+              -- maybe reach into EncryptedData in AS-REP/TGS-REP
+              -- definitions to apply constraints on key usages?
+              { ku-EncASRepPart -- if AS-REP -- |
+                ku-EncTGSRepPart-subkey -- if TGS-REP and
+                                        -- using Authenticator
+                                        -- session key -- |
+                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
+                                         -- subsession key -- }
+          },
+
+
+          ...,
+          -- In extensible version, KDC signs original request
+          -- to avoid replay attacks against client.
+          req-cksum   [7] ChecksumOf { CHOICE {
+              as-req          AS-REQ,
+              tgs-req         TGS-REQ
+          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
+          lang-tag    [8] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      KDC-REP-1510 { EncPart } ::= SEQUENCE {
+          COMPONENTS OF KDC-REP-COMMON { EncPart }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (11 | 13),
+          crealm (RealmIA5),
+          cname (PrincipalNameIA5)
+      })
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 88]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
+      (WITH COMPONENTS {
+          ...,
+          msg-type (7 | 9),
+          crealm (RealmExt),
+          cname (PrincipalNameExt)
+      })
+
+
+
+      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
+      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
+
+
+      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
+      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
+
+
+      EncKDCRepPartCom        ::= SEQUENCE {
+          key                 [0] EncryptionKey,
+          last-req            [1] LastReq,
+          nonce               [2] Nonce,
+          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,
+          ...
+      }
+
+
+      EncKDCRepPart1510       ::= SEQUENCE {
+          COMPONENTS OF EncKDCRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          srealm (RealmIA5),
+          sname (PrincipalNameIA5),
+          nonce UInt32 })
+
+
+      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
+          ...,
+          srealm (RealmExt),
+          sname (PrincipalNameExt)
+      })
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 89]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      LRType          ::=     TH-id
+      LastReq         ::=     SEQUENCE OF SEQUENCE {
+          lr-type     [0] LRType,
+          lr-value    [1] KerberosTime
+      }
+
+
+
+      --
+      -- *** preauth
+      --
+
+
+
+      PaDataType      ::= TH-id
+      PaDataOID       ::= RELATIVE-OID
+
+
+      PA-DATA ::= SEQUENCE {
+          -- NOTE: first tag is [1], not [0]
+          padata-type         [1] PaDataType,
+          padata-value        [2] OCTET STRING
+      }
+
+
+
+      -- AP-REQ authenticating a TGS-REQ
+      pa-tgs-req              PaDataType ::= int32 : 1
+      PA-TGS-REQ              ::= AP-REQ
+
+
+
+      -- Encrypted timestamp preauth
+      -- Encryption key used is client's long-term key.
+      pa-enc-timestamp        PaDataType ::= int32 : 2
+
+
+      PA-ENC-TIMESTAMP ::= EncryptedData {
+          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
+      }
+
+
+      PA-ENC-TS-ENC           ::= SEQUENCE {
+              patimestamp     [0] KerberosTime -- client's time --,
+              pausec          [1] Microseconds OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 90]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Hints returned in AS-REP or KRB-ERROR to help client
+      -- choose a password-derived key, either for preauthentication
+      -- or for decryption of the reply.
+      pa-etype-info           PaDataType ::= int32 : 11
+
+
+      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+
+      ETYPE-INFO-ENTRY        ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] OCTET STRING OPTIONAL
+      }
+
+
+
+      -- Similar to etype-info, but with parameters provided for
+      -- the string-to-key function.
+      pa-etype-info2          PaDataType ::= int32 : 19
+
+
+      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
+                                      OF ETYPE-INFO-ENTRY
+
+
+      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+              etype           [0] EType,
+              salt            [1] KerberosString OPTIONAL,
+              s2kparams       [2] OCTET STRING OPTIONAL
+      }
+
+
+
+      -- Obsolescent.  Salt for client's long-term key.
+      -- Its character encoding is unspecified.
+      pa-pw-salt              PaDataType ::= int32 : 3
+      -- The "padata-value" does not encode an ASN.1 type.
+      -- Instead, "padata-value" must consist of the salt string to
+      -- be used by the client, in an unspecified character
+      -- encoding.
+
+
+
+      -- An extensible AS-REQ may be sent as a padata in a
+      -- non-extensible AS-REQ to allow for backwards compatibility.
+      pa-as-req               PaDataType ::= int32 : 42 -- provisional
+      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
+
+
+
+      --
+      -- *** Session key exchange
+      --
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 91]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AP-REQ          ::= CHOICE {
+          rfc1510     [APPLICATION 14] AP-REQ-1510,
+          ext         [APPLICATION 18] Signed {
+              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
+          }
+      }
+
+
+
+      AP-REQ-COMMON   ::= SEQUENCE {
+          pvno                [0] INTEGER (5),
+          msg-type            [1] INTEGER (14 | 18),
+          ap-options          [2] APOptions,
+          ticket              [3] Ticket,
+          authenticator       [4] EncryptedData {
+              Authenticator,
+              { key-session },
+              { ku-APReq-authenticator |
+                ku-pa-TGSReq-authenticator }
+          },
+          ...,
+          extensions          [5] ApReqExtensions OPTIONAL,
+          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
+                                      OF LangTag OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REQ-1510 ::= SEQUENCE {
+          COMPONENTS OF AP-REQ-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (14),
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmIA5),
+                  cname (PrincipalNameIA5),
+                  seqnum (UInt32)
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 92]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AP-REQ-EXT      ::= AP-REQ-COMMON
+      (WITH COMPONENTS {
+          ...,
+          msg-type (18),
+          -- The following constraints on Authenticator assume that
+          -- we want to restrict the use of AP-REQ-EXT with TicketExt
+          -- only, since that is the only way we can enforce UTF-8.
+          authenticator (EncryptedData {
+              Authenticator (WITH COMPONENTS {
+                  ...,
+                  crealm (RealmExt),
+                  cname (PrincipalNameExt),
+                  authorization-data (SIZE (1..MAX))
+              }), { key-session }, { ku-APReq-authenticator }})
+      })
+
+
+
+      ApReqExtType    ::= TH-id
+
+
+      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apReqExt-Type       [0] ApReqExtType,
+          apReqExt-Data       [1] OCTET STRING
+      }
+
+
+
+      APOptions       ::= KerberosFlags { APOptionsBits }
+
+
+      APOptionsBits ::= BIT STRING {
+          reserved            (0),
+          use-session-key     (1),
+          mutual-required     (2)
+      }
+
+
+
+      -- plaintext of authenticator
+      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+          authenticator-vno   [0] INTEGER (5),
+          crealm              [1] Realm,
+          cname               [2] PrincipalName,
+          cksum               [3] Checksum {{ key-session },
+              { ku-Authenticator-cksum |
+                ku-pa-TGSReq-cksum }} OPTIONAL,
+          cusec               [4] Microseconds,
+          ctime               [5] KerberosTime,
+          subkey              [6] EncryptionKey OPTIONAL,
+          seq-number          [7] SeqNum OPTIONAL,
+          authorization-data  [8] AuthorizationData OPTIONAL
+      }
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 93]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      AP-REP          ::= CHOICE {
+          rfc1510     [APPLICATION 15] AP-REP-1510,
+          ext         [APPLICATION 19] Signed {
+              AP-REP-EXT,
+              { key-session | key-subsession }, { ku-APRep-cksum }}
+      }
+
+
+
+      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (15 | 19),
+          enc-part    [2] EncryptedData {
+              EncPart,
+              { key-session | key-subsession }, { ku-EncAPRepPart }},
+          ...,
+          extensions          [3] ApRepExtensions OPTIONAL,
+          ...
+      }
+
+
+
+      AP-REP-1510     ::= SEQUENCE {
+          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (15)
+      })
+
+
+
+      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
+          EncAPRepPartExt
+      } (WITH COMPONENTS { ..., msg-type (19) })
+
+
+
+      ApRepExtType    ::= TH-id
+
+
+      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
+          apRepExt-Type       [0] ApRepExtType,
+          apRepExt-Data       [1] OCTET STRING
+      }
+
+
+
+      EncAPRepPart    ::= CHOICE {
+          rfc1510     [APPLICATION 27] EncAPRepPart1510,
+          ext         [APPLICATION 31] EncAPRepPartExt
+      }
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 94]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      EncAPRepPart1510        ::= SEQUENCE {
+          COMPONENTS OF ENCAPRepPartCom
+      } (WITH COMPONENTS {
+          ...,
+          seq-number (UInt32),
+          authorization-data ABSENT
+      })
+
+
+
+      EncAPRepPartExt         ::= EncAPRepPartCom
+
+
+
+      EncAPRepPartCom          ::= SEQUENCE {
+          ctime               [0] KerberosTime,
+          cusec               [1] Microseconds,
+          subkey              [2] EncryptionKey OPTIONAL,
+          seq-number          [3] SeqNum OPTIONAL,
+          ...,
+          authorization-data  [4] AuthorizationData OPTIONAL,
+          ...
+      }
+
+
+
+      --
+      -- *** Application messages
+      --
+
+
+
+      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
+      -- allow us to  make safe-body optional, allowing for a GSS-MIC
+      -- sort of message.
+      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (20),
+          safe-body   [2] KRB-SAFE-BODY,
+          cksum       [3] ChecksumOf {
+              KRB-SAFE-BODY,
+              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 95]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KRB-SAFE-BODY   ::= SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress,
+          r-address   [5] HostAddress OPTIONAL,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (21),
+          enc-part    [3] EncryptedData {
+              EncKrbPrivPart,
+              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
+          ...
+      }
+
+
+
+      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+          user-data   [0] OCTET STRING,
+          timestamp   [1] KerberosTime OPTIONAL,
+          usec        [2] Microseconds OPTIONAL,
+          seq-number  [3] SeqNum OPTIONAL,
+          s-address   [4] HostAddress -- sender's addr --,
+          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
+          ...         -- ASN.1 extensions must be excluded
+                      -- when sending to rfc1510 implementations
+      }
+
+
+
+      KRB-CRED        ::= CHOICE {
+          rfc1510     [APPLICATION 22] KRB-CRED-1510,
+          ext         [APPLICATION 24] Signed {
+              KRB-CRED-EXT,
+              { key-session | key-subsession }, { ku-KrbCred-cksum }}
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 96]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KRB-CRED-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (22 | 24),
+          tickets     [2] SEQUENCE OF Ticket,
+          enc-part    [3] EncryptedData {
+              EncKrbCredPart,
+              { key-session | key-subsession }, { ku-EncKrbCredPart }},
+          ...
+      }
+
+
+
+      KRB-CRED-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-CRED-COMMON
+      } (WITH COMPONENTS { ..., msg-type (22) })
+
+
+
+      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
+          (WITH COMPONENTS { ..., msg-type (24) })
+
+
+
+      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+          ticket-info [0] SEQUENCE OF KrbCredInfo,
+          nonce       [1] Nonce OPTIONAL,
+          timestamp   [2] KerberosTime OPTIONAL,
+          usec        [3] Microseconds 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
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 97]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
+          pvno            [0] INTEGER (5),
+          msg-type        [1] INTEGER (16),
+          sname           [2] PrincipalName OPTIONAL,
+          srealm          [3] Realm OPTIONAL,
+          ...
+      }
+
+
+
+      --
+      -- *** Error messages
+      --
+
+
+
+      ErrCode ::= Int32
+
+
+      KRB-ERROR       ::= CHOICE {
+          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
+          ext         [APPLICATION 23] Signed {
+              KRB-ERROR-EXT, { ku-KrbError-cksum } }
+      }
+
+
+
+      KRB-ERROR-COMMON ::= SEQUENCE {
+          pvno        [0] INTEGER (5),
+          msg-type    [1] INTEGER (30 | 23),
+          ctime       [2] KerberosTime OPTIONAL,
+          cusec       [3] Microseconds OPTIONAL,
+          stime       [4] KerberosTime,
+          susec       [5] Microseconds,
+          error-code  [6] ErrCode,
+          crealm      [7] Realm OPTIONAL,
+          cname       [8] PrincipalName OPTIONAL,
+          realm       [9] Realm -- Correct realm --,
+          sname       [10] PrincipalName -- Correct name --,
+          e-text      [11] KerberosString OPTIONAL,
+          e-data      [12] OCTET STRING OPTIONAL,
+          ...,
+          typed-data          [13] TYPED-DATA OPTIONAL,
+          nonce               [14] Nonce OPTIONAL,
+          lang-tag            [15] LangTag OPTIONAL,
+          ...
+      }
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 98]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      KRB-ERROR-1510 ::= SEQUENCE {
+          COMPONENTS OF KRB-ERROR-COMMON
+      } (WITH COMPONENTS {
+          ...,
+          msg-type (30)
+      })
+
+
+
+      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
+          (WITH COMPONENTS { ..., msg-type (23) })
+
+
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+
+
+      TDType ::= TH-id
+
+
+      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+          data-type   [0] TDType,
+          data-value  [1] OCTET STRING OPTIONAL
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                   [Page 99]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      --
+      -- *** Error codes
+      --
+
+
+      -- No error
+      kdc-err-none                          ErrCode ::= 0
+      -- Client's entry in database has expired
+      kdc-err-name-exp                      ErrCode ::= 1
+      -- Server's entry in database has expired
+      kdc-err-service-exp                   ErrCode ::= 2
+      -- Requested protocol version number not supported
+      kdc-err-bad-pvno                      ErrCode ::= 3
+      -- Client's key encrypted in old master key
+      kdc-err-c-old-mast-kvno               ErrCode ::= 4
+      -- Server's key encrypted in old master key
+      kdc-err-s-old-mast-kvno               ErrCode ::= 5
+      -- Client not found in Kerberos database
+      kdc-err-c-principal-unknown           ErrCode ::= 6
+      -- Server not found in Kerberos database
+      kdc-err-s-principal-unknown           ErrCode ::= 7
+      -- Multiple principal entries in database
+      kdc-err-principal-not-unique          ErrCode ::= 8
+      -- The client or server has a null key
+      kdc-err-null-key                      ErrCode ::= 9
+      -- Ticket not eligible for postdating
+      kdc-err-cannot-postdate               ErrCode ::= 10
+      -- Requested start time is later than end time
+      kdc-err-never-valid                   ErrCode ::= 11
+      -- KDC policy rejects request
+      kdc-err-policy                        ErrCode ::= 12
+      -- KDC cannot accommodate requested option
+      kdc-err-badoption                     ErrCode ::= 13
+      -- KDC has no support for encryption type
+      kdc-err-etype-nosupp                  ErrCode ::= 14
+      -- KDC has no support for checksum type
+      kdc-err-sumtype-nosupp                ErrCode ::= 15
+      -- KDC has no support for padata type
+      kdc-err-padata-type-nosupp            ErrCode ::= 16
+      -- KDC has no support for transited type
+      kdc-err-trtype-nosupp                 ErrCode ::= 17
+      -- Clients credentials have been revoked
+      kdc-err-client-revoked                ErrCode ::= 18
+      -- Credentials for server have been revoked
+      kdc-err-service-revoked               ErrCode ::= 19
+      -- TGT has been revoked
+      kdc-err-tgt-revoked                   ErrCode ::= 20
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                  [Page 100]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Client not yet valid - try again later
+      kdc-err-client-notyet                 ErrCode ::= 21
+      -- Server not yet valid - try again later
+      kdc-err-service-notyet                ErrCode ::= 22
+      -- Password has expired - change password to reset
+      kdc-err-key-expired                   ErrCode ::= 23
+      -- Pre-authentication information was invalid
+      kdc-err-preauth-failed                ErrCode ::= 24
+      -- Additional pre-authenticationrequired
+      kdc-err-preauth-required              ErrCode ::= 25
+      -- Requested server and ticket don't match
+      kdc-err-server-nomatch                ErrCode ::= 26
+      -- Server principal valid for user2user only
+      kdc-err-must-use-user2user            ErrCode ::= 27
+      -- KDC Policy rejects transited path
+      kdc-err-path-not-accpeted             ErrCode ::= 28
+      -- A service is not available
+      kdc-err-svc-unavailable               ErrCode ::= 29
+      -- Integrity check on decrypted field failed
+      krb-ap-err-bad-integrity              ErrCode ::= 31
+      -- Ticket expired
+      krb-ap-err-tkt-expired                ErrCode ::= 32
+      -- Ticket not yet valid
+      krb-ap-err-tkt-nyv                    ErrCode ::= 33
+      -- Request is a replay
+      krb-ap-err-repeat                     ErrCode ::= 34
+      -- The ticket isn't for us
+      krb-ap-err-not-us                     ErrCode ::= 35
+      -- Ticket and authenticator don't match
+      krb-ap-err-badmatch                   ErrCode ::= 36
+      -- Clock skew too great
+      krb-ap-err-skew                       ErrCode ::= 37
+      -- Incorrect net address
+      krb-ap-err-badaddr                    ErrCode ::= 38
+      -- Protocol version mismatch
+      krb-ap-err-badversion                 ErrCode ::= 39
+      -- Invalid msg type
+      krb-ap-err-msg-type                   ErrCode ::= 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                  [Page 101]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Message stream modified
+      krb-ap-err-modified                   ErrCode ::= 41
+      -- Message out of order
+      krb-ap-err-badorder                   ErrCode ::= 42
+      -- Specified version of key is not available
+      krb-ap-err-badkeyver                  ErrCode ::= 44
+      -- Service key not available
+      krb-ap-err-nokey                      ErrCode ::= 45
+      -- Mutual authentication failed
+      krb-ap-err-mut-fail                   ErrCode ::= 46
+      -- Incorrect message direction
+      krb-ap-err-baddirection               ErrCode ::= 47
+      -- Alternative authentication method required
+      krb-ap-err-method                     ErrCode ::= 48
+      -- Incorrect sequence number in message
+      krb-ap-err-badseq                     ErrCode ::= 49
+      -- Inappropriate type of checksum in message
+      krb-ap-err-inapp-cksum                ErrCode ::= 50
+      -- Policy rejects transited path
+      krb-ap-path-not-accepted              ErrCode ::= 51
+      -- Response too big for UDP, retry with TCP
+      krb-err-response-too-big              ErrCode ::= 52
+      -- Generic error (description in e-text)
+      krb-err-generic                       ErrCode ::= 60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                  [Page 102]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+      -- Field is too long for this implementation
+      krb-err-field-toolong                 ErrCode ::= 61
+      -- Reserved for PKINIT
+      kdc-error-client-not-trusted          ErrCode ::= 62
+      -- Reserved for PKINIT
+      kdc-error-kdc-not-trusted             ErrCode ::= 63
+      -- Reserved for PKINIT
+      kdc-error-invalid-sig                 ErrCode ::= 64
+      -- Reserved for PKINIT
+      kdc-err-key-too-weak                  ErrCode ::= 65
+      -- Reserved for PKINIT
+      kdc-err-certificate-mismatch          ErrCode ::= 66
+      -- No TGT available to validate USER-TO-USER
+      krb-ap-err-no-tgt                     ErrCode ::= 67
+      -- USER-TO-USER TGT issued different KDC
+      kdc-err-wrong-realm                   ErrCode ::= 68
+      -- Ticket must be for USER-TO-USER
+      krb-ap-err-user-to-user-required      ErrCode ::= 69
+      -- Reserved for PKINIT
+      kdc-err-cant-verify-certificate       ErrCode ::= 70
+      -- Reserved for PKINIT
+      kdc-err-invalid-certificate           ErrCode ::= 71
+      -- Reserved for PKINIT
+      kdc-err-revoked-certificate           ErrCode ::= 72
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unknown     ErrCode ::= 73
+      -- Reserved for PKINIT
+      kdc-err-revocation-status-unavailable ErrCode ::= 74
+
+
+
+      END
+
+
+
+B.  Kerberos and Character Encodings (Informative)
+
+
+   [adapted from KCLAR 5.2.1]
+
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO 2022 | ECMA-35
+   [ISO2022] to switch character sets, and the default character set
+   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
+   International Reference Version (IRV) (aka U.S. ASCII), which mostly
+   works.
+
+
+   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER previously
+   [X690-1997] prohibited the designation of character sets as any but
+   the G0 and C0 sets.  This had the side effect of prohibiting the use
+
+
+Yu                         Expires: Apr 2005                  [Page 103]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
+   other character-sets that utilize a 96-character set, since it is
+   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
+   element.  Recent revisions to the ASN.1 standards resolve this
+   contradiction.
+
+
+   In practice, many implementations treat RFC 1510 GeneralStrings as if
+   they were 8-bit strings of whichever character set the implementation
+   defaults to, without regard for correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to conform to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+
+   [the following should probably be rewritten and moved into the
+   principal name section]
+
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way.  Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters.  This is a violation of the ASN.1
+   standard.  Most of these implementations encode US-ASCII in the left-
+   hand half, so as long the implementation transmits only US-ASCII, the
+   ASN.1 standard is not violated in this regard.  As soon as such an
+   implementation encodes unescaped locale-specific characters with the
+   high bit set, it violates the ASN.1 standard.
+
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the change of encoding by
+   using that escape sequence, the ASN.1 standard prohibits the use of
+   any escape sequences other than those used to designate/invoke "G" or
+   "C" sets allowed by GeneralString.
+
+
+
+Yu                         Expires: Apr 2005                  [Page 104]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+C.  Kerberos History (Informative)
+
+
+   [Adapted from KCLAR "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 Ts'o, 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 [KNT94].
+
+
+D.  Notational Differences from [KCLAR]
+
+
+   [ possible point for discussion ]
+
+
+   [KCLAR] uses notational conventions slightly different from this
+   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
+   language style identifier names for defined values.  In ASN.1
+   notation, identifiers referencing defined values must begin with a
+   lowercase letter and contain hyphen (-) characters rather than
+   underscore (_) characters, while identifiers referencing types begin
+   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
+   identifiers with underscores to identify defined values.  This has
+   the potential to create confusion, but neither document defines
+   values using actual ASN.1 value-assignment notation.
+
+
+   It is debatable whether it is advantageous to write all identifier
+   names (regardless of their ASN.1 token type) in all-uppercase letters
+   for the purpose of emphasis in running text.  The alternative is to
+
+
+Yu                         Expires: Apr 2005                  [Page 105]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   use double-quote characters (") when ambiguity is possible.
+
+
+Normative References
+
+
+   [ISO646]
+        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
+
+
+   [ISO2022]
+        "Information technology -- Character code structure and
+        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
+
+
+   [KCRYPTO]
+        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
+        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
+
+
+   [RFC2119]
+        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
+        Requirement Levels", March 1997.
+
+
+   [RFC3660]
+        H. Alvestrand, "Tags for the Identification of Languages",
+        RFC 3660, January 2001.
+
+
+   [SASLPREP]
+        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
+        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
+        progress.
+
+
+   [X680]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Specification of basic notation", ITU-T Recommendation X.680
+        (2002) | ISO/IEC 8824-1:2002.
+
+
+   [X682]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Constraint specification", ITU-T Recommendation X.682 (2002) |
+        ISO/IEC 8824-3:2002.
+
+
+   [X683]
+        "Information technology -- Abstract Syntax Notation One (ASN.1):
+        Parameterization of ASN.1 specifications", ITU-T Recommendation
+        X.683 (2002) | ISO/IEC 8824-4:2002.
+
+
+   [X690]
+        "Information technology -- ASN.1 encoding Rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+
+
+
+
+Yu                         Expires: Apr 2005                  [Page 106]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+Informative References
+
+
+   [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).
+
+
+   [Dub00]
+        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
+        Systems", Elsevier-Morgan Kaufmann, 2000.
+        <http://www.oss.com/asn1/dubuisson.html>
+
+
+   [ISO8859-1]
+        "Information technology -- 8-bit single-byte coded graphic
+        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
+        1:1998.
+
+
+   [KCLAR]
+        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
+        Network Authentication Service (V5)", draft-ietf-krb-wg-
+        kerberos-clarifications-07.txt, work in progress.
+
+
+   [KNT94]
+        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
+        Evolution of the Kerberos Authentication System".  In
+        Distributed Open Systems, pages 78-94.  IEEE Computer Society
+        Press, 1994.
+
+
+   [Lar96]
+        John Larmouth, "Understanding OSI", International Thomson
+        Computer Press, 1996.
+        <http://www.isi.salford.ac.uk/books/osi.html>
+
+
+   [Lar99]
+        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
+        1999.  <http://www.oss.com/asn1/larmouth.html>
+
+
+   [NS78]
+        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
+        Authentication in Large Networks of Computers", Communications
+        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
+
+
+   [RFC1510]
+        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
+        Service (v5)", RFC1510, September 1993, Status: Proposed
+        Standard.
+
+
+   [RFC1964]
+        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
+        June 1996, Status: Proposed Standard.
+
+
+
+Yu                         Expires: Apr 2005                  [Page 107]
+Internet-Draft            yu-krb-extensions-02               25 Oct 2004
+
+
+   [X690-2002]
+        "Information technology -- ASN.1 encoding rules: Specification
+        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
+        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
+        X.690 (2002) | ISO/IEC 8825-1:2002.
+
+
+Author's Address
+
+
+   Tom Yu
+   77 Massachusetts Ave
+   Cambridge, MA 02139
+   USA
+   tlyu@mit.edu
+
+
+Full Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yu                         Expires: Apr 2005                  [Page 108] 
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-00.txt b/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-00.txt
new file mode 100644
index 00000000000..35d2f070961
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-00.txt
@@ -0,0 +1,560 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Expires: June 4, 2005                                      K. Jaganathan
+                                                   Microsoft Corporation
+                                                           December 2004
+
+
+              Kerberos Cryptosystem Negotiation Extension
+                     draft-zhu-kerb-enctype-nego-00
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on June 4, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies an extension by Kerberos to negotiate new
+   encryption types between the client-server peers.
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 1]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
+   3.   Negotiation Protocol . . . . . . . . . . . . . . . . . . . .   5
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
+   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
+   6.   Normative References . . . . . . . . . . . . . . . . . . . .   7
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   7
+   A.   Leveraging this Enctype Negotiation in Windows SPNEGO
+        Implementations  . . . . . . . . . . . . . . . . . . . . . .   9
+        Intellectual Property and Copyright Statements . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 2]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+1.  Introduction
+
+   Under the current mechanism [CLAR], the KDC must limit the ticket
+   session key enctype chosen for a given service to one it believes is
+   supported by both the client and the server.  If both the client and
+   server understand a stronger enctype than is selected by the KDC,
+   they can not negotiate it.  As the result, the protection of
+   application traffic is often weaker than necessary when different
+   application software that support different set of enctypes can be
+   used by the same server principal.
+
+   This document specifies an extension to Kerberos to allow clients and
+   servers to negotiate a different and possible stronger cryptosystem
+   to be used in subsequent communication.
+
+   This extension utilizes an authorization data element in the
+   authenticator of the KRB_AP_REQ message [CLAR].  The client sends the
+   list of enctypes that it supports to the server, the server then
+   informs the client its choice.  The negotiated subkey is sent in the
+   KRB_AP_REP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 3]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 4]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+3.  Negotiation Protocol
+
+   If the client prefers an enctype over that of the service ticket
+   session key, then it MUST send the list of enctypes it supports
+   (including the one selected by the KDC), in decreasing preference
+   order.
+
+   The client sends the enctype list via the authorization-data of the
+   authenticator in the KRB_AP_REQ [CLAR].  A new authorization data
+   element type AD-ETYPE-NEGOTIATION (129) is defined.  This
+   authorization data element itself is enclosed in the AD-IF-RELEVANT
+   container, thus a correctly implemented server that does not
+   understand this element should ignore it [CLAR].  The value of this
+   authorization element contains the DER [X60] encoding of the
+   following ASN.1 type:
+
+           EtypeList ::= SEQUENCE OF Int32
+              -- the client's proposed enctype list in decreasing
+              -- preference order, favorite choice first
+
+   If the EtypeList is present and the server prefers an enctype from
+   the client's enctype list over that of the KRB_AP_REQ authenticator
+   subkey (if that is present) or the service ticket session key, the
+   server MUST create a subkey using that enctype.  This negotiated
+   subkey is sent in the subkey field of KRB_AP_REP message and it MUST
+   be used for subsequent communication.
+
+   Note that to preserve the quality of randomness provided by the KDC,
+   implementations of this protocol SHOULD consider using the service
+   ticket session key value as a source of additional entropy when
+   generating the negotiated subkey.  If the KRB_AP_REQ authenticator
+   subkey is present, it MAY also be used as a source of entropy.
+
+   The policy by which the client or the server chooses an enctype
+   (i.e., how the preference order for the supported enctypes is
+   selected) is an implementation-specific local matter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 5]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+4.  Security Considerations
+
+   The client's enctype list and the server's reply enctype are part of
+   encrypted data, thus the security considerations are the same as
+   those of the Kerberos encrypted data.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 6]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+5.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+6.  Normative References
+
+   [CLAR]     Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", August
+              2004.
+
+   [GSS-CFX]  Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
+              Version 5 GSS-API Mechanism: Version 2", November 2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [SPNEGOBIS]
+              Zhu, L., Leach, P., Jaganathan, K., Hartman, S. and W.
+              Ingersoll, "The Simple and Protected GSS-API Negotiation
+              Mechanism", November 2004.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 7]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 8]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+Appendix A.  Leveraging this Enctype Negotiation in Windows SPNEGO
+            Implementations
+
+   The SPNEGO implementations in Windows 2000, Windows XP and Windows
+   2003 do not generate or verify the mechlistMIC field when it is
+   required [SPNEGOBIS].
+
+   When the SPNEGO implementations that are updated according to
+   [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the
+   peer is updated, so that it can generate the mechlistMIC token when
+   the peer can process it.  With the bidirectional negotiation, the
+   updated SPNEGO implementation can achieve the following two goals:
+
+   o  It can remain backward compatible with legacy implementations, if
+      local policy allows unsafe and unprotected negotiation with
+      downlevel implementations when the mechlistMIC token exchange
+      would otherwise be required by [SPNEGOBIS].
+   o  The mechanism negotiation is protected according to [SPNEGOBIS]
+      when both peers are updated.
+
+   However, the updated SPNEGO implementation itself can not securely
+   inform the peer whether the local implementation is updated, thus it
+   has to obtain such information from the negotiated mechanism.
+
+   For Windows SPNEGO implementations, both the initiator and the
+   acceptor are assumed to have been updated if a "newer" [CLAR] or
+   different enctype is negotiated for use by the Kerberos GSS-API
+   mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                  [Page 9]
+
+Internet-Draft             Enctype Negotiation             December 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.               Expires June 4, 2005                 [Page 10]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt b/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt
new file mode 100644
index 00000000000..60be49b7a36
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt
@@ -0,0 +1,395 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Expires: October 2, 2005                                   K. Jaganathan
+                                                   Microsoft Corporation
+                                                          March 31, 2005
+
+
+              Kerberos Cryptosystem Negotiation Extension
+                      draft-zhu-kerb-enctype-nego-01
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   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 Internet-Draft will expire on October 2, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies an extension by Kerberos to negotiate new
+   encryption types between the client-server peers.
+
+
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 1]
+
+Internet-Draft             Enctype Negotiation                March 2005
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
+   3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
+   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 4
+   6.   Normative References . . . . . . . . . . . . . . . . . . . . . 4
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
+   A.   Leveraging this Enctype Negotiation in Windows SPNEGO
+        Implementations  . . . . . . . . . . . . . . . . . . . . . . . 5
+        Intellectual Property and Copyright Statements . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 2]
+
+Internet-Draft             Enctype Negotiation                March 2005
+
+
+1.  Introduction
+
+   Under the current mechanism [CLAR], the KDC must limit the ticket
+   session key enctype chosen for a given server to one it believes is
+   supported by both the client and the server.  If both the client and
+   server understand a stronger enctype than the one selected by the
+   KDC, they can not negotiate it.  As the result, the protection of
+   application traffic is often weaker than necessary when the server
+   can support different sets of enctypes depending on the server
+   application software being used.
+
+   This document specifies an extension to Kerberos to allow clients and
+   servers to negotiate a different and possible stronger cryptosystem
+   to be used in subsequent communication.
+
+   This extension utilizes an authorization data element in the
+   authenticator of the AP-REQ message [CLAR].  The client sends the
+   list of enctypes that it supports to the server, the server then
+   informs the client its choice.  The negotiated subkey is sent in the
+   AP-REP message [CLAR].
+
+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 [RFC2119].
+
+3.  Negotiation Extension
+
+   If the client prefers an enctype over that of the service ticket
+   session key, then it MUST send the list of enctypes it supports
+   (including the one selected by the KDC) in decreasing preference
+   order.
+
+   The client sends the enctype list via the authorization-data of the
+   authenticator in the AP-REQ [CLAR].  A new authorization data element
+   type AD-ETYPE-NEGOTIATION (129) is defined.  This authorization data
+   element itself is enclosed in the AD-IF-RELEVANT container, thus a
+   correctly implemented server that does not understand this element
+   should ignore it [CLAR].  The value of this authorization element
+   contains the DER [X60] encoding of the following ASN.1 type:
+
+           EtypeList ::= SEQUENCE OF Int32
+              -- Specifies the enctypes supported by the client.
+              -- This enctype list is in decreasing preference order
+              -- (favorite choice first).
+              -- Int32 is defined in [CLAR].
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 3]
+
+Internet-Draft             Enctype Negotiation                March 2005
+
+
+   If the EtypeList is present and the server prefers an enctype from
+   the client's enctype list over that of the AP-REQ authenticator
+   subkey (if that is present) or the service ticket session key, the
+   server MUST create a subkey using that enctype.  This negotiated
+   subkey is sent in the subkey field of AP-REP message and it MUST be
+   used for subsequent communication.
+
+   This negotiation extension MUST NOT be used when the client does not
+   expect the subkey in the AP-REP message from the server.
+
+   Note that to preserve the quality of randomness provided by the KDC,
+   implementations of this extension SHOULD consider using the service
+   ticket session key value as a source of additional entropy when
+   generating the negotiated subkey.  If the AP-REQ authenticator subkey
+   is present, it MAY also be used as a source of entropy.
+
+   The policy by which the client or the server chooses an enctype
+   (i.e., how the preference order for the supported enctypes is
+   selected) is an implementation-specific local matter.
+
+4.  Security Considerations
+
+   The client's enctype list and the server's reply enctype are part of
+   encrypted data, thus the security considerations are the same as
+   those of the Kerberos encrypted data.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+5.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+6.  Normative References
+
+   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-kerberos-clarifications.  Work in Progress. 
+                            
+   [GSS-CFX]  RFC-Editor: To be replaced by RFC number for draft-ietf-
+              krb-wg-gssapi-cfx.  Work in Progress. 
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 4]
+
+Internet-Draft             Enctype Negotiation                March 2005
+
+
+   [SPNEGOBIS]
+              RFC-Editor: To be replaced by RFC number for draft-ietf-
+              kitten-2478bis.  Work in progress.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
+              (BER), Canonical Encoding Rules (CER) and Distinguished 
+              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
+              ISO/IEC International Standard 8825-1:1998.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+Appendix A.  Leveraging this Enctype Negotiation in Windows SPNEGO
+            Implementations
+
+   The SPNEGO implementations in Windows 2000, Windows XP and Windows
+   2003 do not generate or verify the mechlistMIC field when it is
+   required [SPNEGOBIS].
+
+   When the SPNEGO implementations that are updated according to
+   [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the
+   peer is updated, so that it can generate the mechlistMIC token when
+   the peer can process it.  With the bidirectional negotiation, the
+   updated SPNEGO implementation can achieve the following two goals:
+
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 5]
+
+Internet-Draft             Enctype Negotiation                March 2005
+
+
+   o  It can remain backward compatible with legacy implementations, if
+      local policy allows unsafe and unprotected negotiation with
+      downlevel implementations when the mechlistMIC token exchange
+      would otherwise be required by [SPNEGOBIS].
+
+   o  The mechanism negotiation is protected according to [SPNEGOBIS]
+      when both peers are updated.
+
+   However, the updated SPNEGO implementation itself can not securely
+   inform the peer whether the local implementation is updated, thus it
+   has to obtain such information from the negotiated mechanism.
+
+   For Windows SPNEGO implementations, both the initiator and the
+   acceptor are assumed to have been updated if a "newer" [CLAR] or
+   different enctype is negotiated for use by the Kerberos GSS-API
+   mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 6]
+
+Internet-Draft             Enctype Negotiation                March 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.              Expires October 2, 2005                [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-03.txt b/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-03.txt
new file mode 100644
index 00000000000..dfc61bf6570
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-kerb-enctype-nego-03.txt
@@ -0,0 +1,397 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                                  P. Leach
+Updates: 4120 (if approved)                                K. Jaganathan
+Expires: January 20, 2006                          Microsoft Corporation
+                                                           July 19, 2005
+
+
+              Kerberos Cryptosystem Negotiation Extension
+                     draft-zhu-kerb-enctype-nego-03
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 20, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies an extension to the Kerberos protocol where
+   the client can send a list of supported encryption types in
+   decreasing preference order, and the server then selects an
+   encryption type that is supported by both the client and the server.
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 1]
+
+Internet-Draft             Enctype Negotiation                 July 2005
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
+   3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
+   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
+   5.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
+   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 5
+   7.   Normative References . . . . . . . . . . . . . . . . . . . . . 5
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
+        Intellectual Property and Copyright Statements . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 2]
+
+Internet-Draft             Enctype Negotiation                 July 2005
+
+
+1.  Introduction
+
+   Under the current mechanism [RFC4120], the KDC must limit the ticket
+   session key encryption type (enctype) chosen for a given server to
+   one it believes is supported by both the client and the server.  If
+   both the client and server understand a stronger enctype than the one
+   selected by the KDC, they can not negotiate it.  As the result, the
+   protection of application traffic is often weaker than necessary when
+   the server can support different sets of enctypes depending on the
+   server application software being used.
+
+   This document specifies an extension to the Kerberos protocol to
+   allow clients and servers to negotiate a different and possible
+   stronger cryptosystem to be used in subsequent communication.
+
+   This extension utilizes an authorization data element in the
+   authenticator of the AP-REQ message [RFC4120].  The client sends the
+   list of enctypes that it supports to the server, the server then
+   informs the client its choice.  The negotiated subkey is sent in the
+   AP-REP message [RFC4120].
+
+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 [RFC2119].
+
+3.  Negotiation Extension
+
+   If the client prefers an enctype over that of the service ticket
+   session key, then it sends the list of enctypes it supports
+   (including the one selected by the KDC) in decreasing preference
+   order.
+
+   The client sends the enctype list via the authorization-data of the
+   authenticator in the AP-REQ [RFC4120].  A new authorization data
+   element type AD-ETYPE-NEGOTIATION is defined.
+
+           AD-ETYPE-NEGOTIATION              129
+
+   This authorization data element itself is enclosed in the AD-IF-
+   RELEVANT container, thus a correctly implemented server that does not
+   understand this element should ignore it [RFC4120].  The value of
+   this authorization element contains the DER [X690] encoding of the
+   following ASN.1 type:
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 3]
+
+Internet-Draft             Enctype Negotiation                 July 2005
+
+
+           EtypeList ::= SEQUENCE OF Int32
+              -- Specifies the enctypes supported by the client.
+              -- This enctype list is in decreasing preference order
+              -- (favorite choice first).
+              -- Int32 is defined in [RFC4120].
+
+   If the EtypeList is present and the server prefers an enctype from
+   the client's enctype list over that of the AP-REQ authenticator
+   subkey (if that is present) or the service ticket session key, the
+   server MUST create a subkey using that enctype.  This negotiated
+   subkey is sent in the subkey field of AP-REP message and it is then
+   used as the protocol key or base key [RFC3961] for subsequent
+   communication.
+
+   This negotiation extension SHOULD NOT be used when the client does
+   not expect the subkey in the AP-REP message from the server.
+
+   A note on key generation: The KDC has a strong Pseudo-Random Number
+   Generator (PRNG), as such the client can take advantage of the
+   randomness provided by the KDC by reusing the KDC key data when
+   generating keys.  Implementations SHOULD use the service ticket
+   session key value as a source of additional entropy when generating
+   the negotiated subkey.  If the AP-REQ authenticator subkey is
+   present, it MAY also be used as a source of entropy.
+
+   The server MAY ignore the preference order indicated by the client.
+   The policy by which the client or the server chooses an enctype
+   (i.e., how the preference order for the supported enctypes is
+   selected) is a local matter.
+
+4.  Security Considerations
+
+   The client's enctype list and the server's reply enctype are part of
+   encrypted data, thus the security considerations are the same as
+   those of the Kerberos encrypted data.
+
+   Both the EtypeList and the server's sub-session key are protected by
+   the session key or sub-session key used for the AP-REQ, and as a
+   result, if a key for a stronger enctype is negotiated underneath a
+   key for a weaker enctype, an attacker capable of breaking the weaker
+   enctype can also discover the key for the stronger enctype.  The
+   advantage of this extension is to minimize the amount of cipher text
+   encrypted under a weak enctype to which an attacker has access.
+
+5.  Acknowledgements
+
+   The authors would like to thank the following individuals for their
+   comments and suggestions: Luke Howard, Tom Yu, Love Hornquist
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 4]
+
+Internet-Draft             Enctype Negotiation                 July 2005
+
+
+   Astrand, Sam Harman, Ken Raeburn and Martin Rex.
+
+6.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
+              (BER), Canonical Encoding Rules (CER) and Distinguished 
+              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
+              ISO/IEC International Standard 8825-1:1998.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: paulle@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 5]
+
+Internet-Draft             Enctype Negotiation                 July 2005
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 6]
+
+Internet-Draft             Enctype Negotiation                 July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.             Expires January 20, 2006                [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-negoex-01.txt b/third_party/heimdal/doc/standardisation/draft-zhu-negoex-01.txt
new file mode 100644
index 00000000000..21620a89662
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-negoex-01.txt
@@ -0,0 +1,1232 @@
+

+

+NETWORK WORKING GROUP                                             L. Zhu

+Internet-Draft                                                 K. Damour

+Updates: 4178 (if approved)                                 D. McPherson

+Intended status: Informational                     Microsoft Corporation

+Expires: January 15, 2009                                  July 14, 2008

+

+

+          The Extended GSS-API Negotiation Mechanism (NEGOEX)

+                          draft-zhu-negoex-01

+

+Status of this Memo

+

+   By submitting this Internet-Draft, each author represents that any

+   applicable patent or other IPR claims of which he or she is aware

+   have been or will be disclosed, and any of which he or she becomes

+   aware will be disclosed, in accordance with Section 6 of BCP 79.

+

+   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 Internet-Draft will expire on January 15, 2009.

+

+Abstract

+

+   This document defines the Extended Generic Security Service

+   Application Program Interface (GSS-API) Negotiation Mechanism

+   (NegoEx).  NegoEx is a pseudo-security mechanism that logically

+   extends the SPNEGO protocol as defined in RFC4178.

+

+   The NegoEx protocol itself is a security mechanism negotiated by

+   SPNEGO.  When selected as the common mechanism, NegoEx OPTIONALLY

+   adds a pair of meta-data messages for each negotiated security

+   mechanism.  The meta-data exchange allows security mechanisms to

+   exchange auxiliary information such as trust configurations, thus

+   NegoEx provides additional flexibility than just exchanging object

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 1]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   identifiers in SPNEGO.

+

+   NegoEx preserves the optimistic token semantics of SPNEGO and applies

+   that recursively.  Consequently a context establishment mechanism

+   token can be included in the initial NegoEx message, and NegoEx does

+   not require an extra round-trip when the initiator's optimistic token

+   is accepted by the target.

+

+   Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a

+   security mechanism MUST support in order to be negotiated by NegoEx.

+   This document defines these GSS-API extensions.

+

+   Unlike SPNEGO however, NegoEx defines its own way for signing the

+   protocol messages in order to protect the protocol negotiation.  The

+   NegoEx message signing or verification can occur before the security

+   context for the negotiated real security mechanism is fully

+   established.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 2]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+Table of Contents

+

+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

+   2.  Requirements Terminology . . . . . . . . . . . . . . . . . . .  6

+   3.  Presentation Language and Primitive Data Types . . . . . . . .  6

+     3.1.  Basic Block Size . . . . . . . . . . . . . . . . . . . . .  7

+     3.2.  Miscellaneous  . . . . . . . . . . . . . . . . . . . . . .  7

+     3.3.  Constants  . . . . . . . . . . . . . . . . . . . . . . . .  7

+     3.4.  Numbers  . . . . . . . . . . . . . . . . . . . . . . . . .  7

+     3.5.  Enum Types . . . . . . . . . . . . . . . . . . . . . . . .  7

+     3.6.  Typedef Declarations . . . . . . . . . . . . . . . . . . .  8

+     3.7.  Array Types  . . . . . . . . . . . . . . . . . . . . . . .  8

+     3.8.  Vector Types . . . . . . . . . . . . . . . . . . . . . . .  8

+     3.9.  Constructed Types  . . . . . . . . . . . . . . . . . . . .  9

+   4.  Cryptographic Computations . . . . . . . . . . . . . . . . . . 10

+   5.  The NegoEx Protocol  . . . . . . . . . . . . . . . . . . . . . 11

+     5.1.  Generation of the Initiator Initial Token  . . . . . . . . 11

+     5.2.  Receipt of the Initial Initiator Token and Generation

+           of the Initial Acceptor Response . . . . . . . . . . . . . 13

+     5.3.  Receipt of the Acceptor Initial Response and

+           Completion of Authentication after the Negotiation

+           Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 14

+     5.4.  Finalizing Negotiation . . . . . . . . . . . . . . . . . . 15

+     5.5.  High-level NegoEx Message Flow . . . . . . . . . . . . . . 15

+   6.  Supporting GSS-API Extensions  . . . . . . . . . . . . . . . . 16

+     6.1.  GSS_Query_meta_data  . . . . . . . . . . . . . . . . . . . 16

+     6.2.  GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 16

+     6.3.  GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 16

+     6.4.  GSS_Query_context_attr . . . . . . . . . . . . . . . . . . 16

+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16

+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17

+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17

+   10. Normative References . . . . . . . . . . . . . . . . . . . . . 17

+   Appendix A.  Protocol Data Structures and Constant Values  . . . . 17

+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

+   Intellectual Property and Copyright Statements . . . . . . . . . . 22

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 3]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+1.  Introduction

+

+   If more than one GSS-API mechanism is shared between the initator and

+   the acceptor, the Simple and Protected (GSS-API) Negotiation

+   Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose

+   a mutually preferred one.  This pseudo mechanism does well in the

+   most basic scenarios but suffers from a couple of drawbacks, notably:

+

+   o  First, the SPNEGO negotiation model is inefficient when

+      negotiating based on mechanism specific configuration information.

+      SPNEGO negotiation is based on exchanging object identifiers only,

+      and it does not allow exchange of auxiliary information in any

+      other from.  This is inefficient and often impractical in that one

+      object identifier effectively conveys only one bit of information.

+

+   o  Secondly, the SPNEGO negotiation model is inadequate when the

+      choice cannot be made by the acceptor in the initial response.  In

+      SPNEGO, the negotiation information is sent one-way from the

+      initiator for the acceptor to make a choice, and the acceptor must

+      choose one when it makes the initial response.  This negotiation

+      model is counter intuitive.  The selection of a security mechanism

+      is typically the result of selecting one type of credentials from

+      the available set, and the initiator typically does not wish to

+      reveal credentials information often associated with user

+      identities.  In practice, in order to operate in this model, the

+      Kerberos GSS-API mechanism [RFC4121] must acquire the context

+      establishment token in the initial call to GSS_Init_sec_context().

+      If the initiator fails to acquire the initial Kerberos GSS-API

+      context token, it must not offer Kerberos; otherwise the SPNEGO

+      context negotiation will fail without being able to select the

+      next available mechanism that could work.  Obtaining the initial

+      Kerberos GSS-API context token may require multiple round-trips of

+      network calls and the cost of the operation can be substantial.

+      It is suboptimal when multiple GSS-API mechanisms have to add the

+      extra cost that would not exist if the negotiated security

+      mechanism were selected based on configuration.

+

+   The Extended Generic Security Service Application Program Interface

+   (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these

+   concerns.  NegoEx is a pseudo security mechanism that is negotiated

+   by SPNEGO, and when negotiated, it can recursively negotiate real

+   security mechanisms.

+

+   Any security mechanism negotiated by NegoEx MUST support integrity

+   protection.

+

+   The basic form of NegoEx works as follows:

+

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 4]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   1.  The initiator proposes a list of mechanisms in decreasing

+       preference order.  For each of these mechanism, NegoEx

+       OPTIOINALLY includes a mechanism specific meta-data token.  GSS-

+       API extensions are defined later in this document for NegoEx to

+       query the meta-data token for inclusion in the NegoEx message.

+

+   2.  The acceptor then passes the meta-data token from the initiator

+       to the intended security mechanism.  A meta-data token for a

+       security mechanism not supported on the acceptor side is ignored.

+       New GSS-API extensions are defined later in this document for a

+       security mechanism to consume the meta-data token.  When

+       processing the received meta-data tokens, a security mechanism

+       that reports a failure is removed from the set of mutually

+       supported mechanisms.  The acceptor then responds with the list

+       of mutually supported mechanisms in decreasing preference order.

+       For each of these mechanism, NegoEx again OPTIOINALLY supplies a

+       mechanism specific meta-data token in the response.  These meta-

+       data tokens are returned to NegoEx via new GSS-API extensions as

+       described in the initial step.

+

+   3.  The initiator then passes the meta-data tokens to the intended

+       security mechanisms by invoking the new GSS-API extensions.  When

+       processing the received meta-data token, a security mechanism

+       that reports a failure is removed from the set of mutually

+       supported mechanisms for this negotiation context.  The initiator

+       then selects one from the set of mutually-supported mechanisms.

+       If more than one security mechanism is available, unless

+       otherwise specified, the preferred one in the acceptor's

+       preference order SHOULD be selected.  Once the common security

+       mechanism is identified, the security mechanism may also

+       negotiate mechanism-specific options during its context

+       establishments.  This will be inside the mechanism tokens, and

+       invisible to the NegoEx protocol.

+

+   4.  The selected security mechanism provides keying materials to

+       NegoEx, and NegoEx then signs and verifies the negotiation NegoEx

+       messages to protect the negotiation.

+

+   5.  The initiator and the acceptor proceed to exchange tokens until

+       the GSS-API context for selected security mechanism is

+       established.  Once the security context is established, the per-

+       message tokens are generated and verified in accordance with the

+       selected security mechanism.

+

+   NegoEx does not work outside of SPNEGO.  When negotiated by SPNEGO,

+   NegoEx uses the concepts developed in the GSS-API specification

+   [RFC2743].  The negotiation data is encapsulated in context-level

+   tokens.  Therefore, callers of the GSS-API do not need to be aware of

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 5]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   the existence of the negotiation tokens but only of the SPENGO

+   pseudo-security mechanism.

+

+   In its basic form NegoEx requires at least one extra round-trip.

+   Network connection setup is a critical performance characteristic of

+   any network infrastructure and extra round trips over WAN links,

+   packet radio networks, etc. really make a difference.  In order to

+   avoid such an extra round trip the initial security token of the

+   preferred mechanism for the initiator may be embedded in the initial

+   NegoEx token.  The optimistic mechanism token may be accompanied by

+   the meta-data tokens and the optimistic mechanism token MUST be that

+   of the first mechanism in the list of the mechanisms proposed by the

+   initiator.  The NegoEx message that contains signatures for

+   protecting the NegoEx negotiation can also be included along with the

+   mechanism token.  If the target preferred mechanism matches the

+   initiator's preferred mechanism, and when the NegoEx negotiation

+   protection messages are included along with the mechanism token, no

+   additional round trips are incurred by using the NegoEx protocol with

+   SPNEGO.

+

+   NegoEx does not update the ASN.1 structures of SPNEGO in that a large

+   deployment of SPNEGO does not have the ASN.1 extensibility marker in

+   the message definition.  There is no change to the SPNEGO messages.

+

+   NegoEx does not use ASN.1 encoding and it uses simple C structures

+   encoded in little endian for all its messages.

+

+   The rest of the document is organized as follows: Section 3 defines

+   the encoding of NegoEx data structures and all the primitive data

+   types.  Section 4 describes the cryptographic framework required by

+   the NegoEx for protecting the NegoEx negotiation.  Section 5 defines

+   the NegoEx messages and the NegoEx protocol.  Section 6 defines the

+   new GSS-API extensions that a security mechanism MUST support in

+   order to be negotiated by NegoEx.  These then are followed by the

+   security considerations section.  Lastly Appendix A contains all the

+   protocol constructs and constants.

+

+

+2.  Requirements Terminology

+

+   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 [RFC2119].

+

+

+3.  Presentation Language and Primitive Data Types

+

+   The following very basic and somewhat casually defined presentation

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 6]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   syntax will be used in all NegoEx messages.  Although it resembles

+   the programming language "C" in its syntax, it would be risky to draw

+   too many parallels.  The purpose of this presentation language is to

+   document NegoEx only; it has no general application beyond that

+   particular goal.

+

+   This section also defines all the primitive data types.  The

+   semantics of the data types is explained in the next section.

+

+3.1.  Basic Block Size

+

+   The representation of all data items is explicitly specified.  The

+   basic data block size is one octet.  Multiple octet data items are

+   concatenations of octets, from left to right, from top to bottom

+   Unless otherwise specific a multi-octet numeric is in little endian

+   order with the least significant octet first.

+

+3.2.  Miscellaneous

+

+   Comments start with "//"' and continue until the end of the line.

+

+3.3.  Constants

+

+   Constants are denoted using "#define" followed by the symbolic name

+   and then the constant value.

+

+3.4.  Numbers

+

+   UCHAR is the data type for a one-octet number.

+

+   ULONG is the data type for a 4-octet number encoded in little enidan.

+

+   USHORT is the data type for a 2-octet number encoded in little

+   endian.

+

+   ULONG64 is the data type for a 8-octet number encoded in little

+   endian.

+

+   GUID is the data type for a 16-octet number encoded in little endian.

+

+3.5.  Enum Types

+

+   An enum type is the data type for a number with a small number of

+   permissible values.  An instance of an enum type is a 4-octet number

+   encoded in little endian.

+

+   The definition of an enum type follows the simple "C" convention.

+

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 7]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   MESSAGE_TYPE is an enum type defined as follows:

+

+       enum

+       {

+           MESSAGE_TYPE_INITIATOR_NEGO = 0,

+           MESSAGE_TYPE_ACCEPTOR_NEGO,

+           MESSAGE_TYPE_INITIATOR_META_DATA,

+           MESSAGE_TYPE_ACCEPTOR_META_DATA,

+           MESSAGE_TYPE_CHALLENGE,

+               // an exchange message from the acceptor

+           MESSAGE_TYPE_AP_REQUEST,

+               // an exchange message from the initiator

+           MESSAGE_TYPE_VERIFY,

+           MESSAGE_TYPE_ALERT,

+       } MESSAGE_TYPE;

+

+   MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT

+   has the value 7.

+

+3.6.  Typedef Declarations

+

+   A typedef creates a synonym for the type.  This is used to create

+   more meaningful names for existing types.

+

+   The following two type synonyms are defined.

+

+   typedef GUID AUTH_SCHEME;

+   typedef GUID CONVERSATION_ID;

+

+3.7.  Array Types

+

+   Arrays are a data structure which holds multiple variables of the

+   same data type consecutively and the number of elements is fixed.  An

+   array is declared using "C" convention.  For example, the following

+   defines an array of 32 octets.

+

+   UCHAR Random[32];

+

+3.8.  Vector Types

+

+   Vectors are a data structure which holds multiple variables of the

+   same data type consecutively and the number of elements is not fixed.

+   A vector contains a fixed length header followed by a variable length

+   payload.  The header of a vector structure contains the count of

+   elements and the offset to the payload.  In this document all the

+   offset fields start from the beginning of the containing NegoEx

+   message.  The size of each element is specified by the vector type

+   definition.

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 8]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   The following vector types are defined.

+

+       struct

+       {

+           ULONG ByteArrayOffset; // each element contains an octet/byte

+           ULONG ByteArrayLength;

+       } BYTE_VECTOR;

+

+   BYTE_VECTOR encapsulates a variable length array of octets (or bytes)

+   that are stored consecutively.  Each element in is a byte (8 bits).

+

+       struct

+       {

+           ULONG AuthSchemeArrayOffset;

+                // each element contains an AUTH_SCHEME

+           USHORT AuthSchemeCount;

+       } AUTH_SCHEME_VECTOR;

+

+   AUTH_SCHEME_VECTOR encapsulates a variable length array of

+   AUTH_SCHEMEs that are stored consecutively.  Each element is a

+   structure of the type AUTH_SCHEME.

+

+       struct

+       {

+           ULONG ExtensionArrayOffset;

+               // each element contains an EXTENSION

+           USHORT ExtensionCount;

+       } EXTENSION_VECTOR;

+

+   EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs

+   that are stored consecutively.  Each element is a structure of the

+   type EXTENSION.

+

+3.9.  Constructed Types

+

+   Structure types may be constructed from primitive types for

+   convenience.  Each specification declares a new, unique type.  The

+   syntax for definition is much like that of C.

+

+         struct {

+             T1 f1;

+             T2 f2;

+             ...

+             Tn fn;

+         } T;

+

+

+   Structure definitions may be embedded.

+

+

+

+Zhu, et al.             Expires January 15, 2009                [Page 9]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   The following types are defined as constructed types:

+

+       struct

+       {

+           ULONG ExtensionType; // negative extensions are critical

+           BYTE_VECTOR ExtensionValue;

+       } EXTENSION;

+

+   An extension has two fields.  The ExtensionType field indicates how

+   the extension data should be interpreted.  The ExtensionValue field

+   contains the extension data.

+

+       //

+       // schemes defined for the checksum in the VERIFY message

+       //

+

+       struct

+       {

+           ULONG cbHeaderLength;

+           ULONG ChecksumScheme;

+           ULONG ChecksumType; // in the case of RFC3961 scheme, this is

+             // the RFC3961 checksum type

+           BYTE_VECTOR ChecksumValue;

+       } CHECKSUM;

+

+   The CHECKSUM structure contains 4 fields.  The cbHeaderLength length

+   contains the length of the structure defintion in octets, and this

+   field has a value of 20.

+

+   The ChecksumScheme field describes how checksum is computed and

+   verified.  Currently only one value is defined.

+

+   #define CHECKSUM_SCHEME_RFC3961 1

+

+   When the value of the ChecksumScheme field is 1

+   (CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a

+   sequence of octets computed according to [RFC3961] and the

+   ChecksumType field contains the checksum type value defined according

+   to [RFC3961].

+

+

+4.  Cryptographic Computations

+

+   The message signing and verification in NegoEx is based on [RFC3961].

+   [RFC3961] is used here as a generic framework and this application is

+   not Kerberos specific.

+

+   A security mechanism MUST support [RFC3961] in order to be negotiated

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 10]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   by NegoEx.

+

+

+5.  The NegoEx Protocol

+

+   This section describes the NegoEx protocol and it defines NegoEx

+   messages in the order that the messages can appear on the wire.  The

+   enum type MESSAGE_TYPE defined in Section 3.5 lists all NegoEx

+   message types.  A GSS-API context token for NegoEx consists of one or

+   more NegoEx messages.  If there are more than one NegoEx message,

+   these messages are concatenated together.  The smallest data unit for

+   NegoEx to compute the checksum for negotiation protection is a NegoEx

+   message.  Note that NegoEx is not a GSS-API mechanism itself and the

+   initial NegoEx context establishment token does not follow the

+   mechanism-independent token format defined in Section 3.1 of

+   [RFC2743].

+

+   A security mechanism negotiated by NegoEx is identified by a unique

+   identifier of the data type AUTH_SCHEME defined in Section 3.5.  The

+   value of the security mechanism is returned to NegoEx via the

+   GSS_Query_mechanism_info() GSS-API extension as defined in Section 6.

+

+   The object identifier of the NegoEx within SPNEGO is iso(1)

+   identified-organization(3) dod(6) internet(1) private(4)

+   enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30).

+   Note that NegoEx does not work outside of SPNEGO and it is not GSS-

+   API mechanism.

+

+5.1.  Generation of the Initiator Initial Token

+

+   The GSS-API initiator makes the first call to GSS_Init_sec_context()

+   with no input token, and the output token starts as a NEGO_MESSAGE

+   message with the MESSAGE_TYPE_INITIATOR_NEGO message type.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 11]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+       struct

+       {

+           ULONG64 Signature; // contains MESSAGE_SIGNATURE

+           MESSAGE_TYPE MessageType;

+           ULONG SequenceNum; // the message sequence number of this,

+                  // conversation, starting with 0 and sequentially

+                  // incremented

+           ULONG cbHeaderLength; // the header length of this message,

+              // including the message specific header, excluding the

+              // payload

+           ULONG cbMessageLength; // the length of this message

+           CONVERSATION_ID ConversationId;

+       } MESSAGE_HEADER;

+

+       struct

+       {

+           MESSAGE_HEADER Header;

+                    // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,

+                    // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor

+           UCHAR Random[32];

+           ULONG64 ProtocolVersion;

+                   // version of the protocol, this contains 0

+           AUTH_SCHEME_VECTOR AuthSchemes;

+           EXTENSION_VECTOR Extensions;

+       } NEGO_MESSAGE;

+

+   The initiator randomly generates a ConversationID and fills the

+   common header.  The ConversationID in subsequent NegoEx messages MUST

+   remain the same.  The initiator also fills the Random field using a

+   secure random number generator.  The initiator fills the AuthSchemes

+   with available security mechanisms supported by the initiator in

+   decreasing preference order.

+

+   The extensions field contains NegoEx extensions for future

+   extensibility.  There is no extension defined in this document.  All

+   negative extension types (the highest bit is set to 1) are critical.

+   If the receiver does not understand a critical extension, the

+   authentication attempt must be rejected.

+

+   The initiator can OPTIONALLY include a meta-data token, one for each

+   available security mechanism.

+

+   A meta-data token is returned to NegoEx for a security mechanism

+   using GSS_Query_meta_data() extension as defined in Section 6.  A

+   meta-data token is encapsulated in an EXCHANGE message with the

+   message type MESSAGE_TYPE_INITIATOR_META_DATA.

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 12]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+       struct

+       {

+           MESSAGE_HEADER Header;

+                // MESSAGE_TYPE_CHALLENGE for the acceptor,

+                // or MESSAGE_TYPE_AP_REQUEST for the initiator

+               // MESSAGE_TYPE_INITIATOR_META_DATA for

+               // the initiator metadata

+               // MESSAGE_TYPE_ACCEPTOR_META_DATA for

+               // the acceptor metadata

+           AUTH_SCHEME AuthScheme;

+           BYTE_VECTOR Exchange;

+               // contains the opaque handshake message for the

+               // authentication scheme

+       } EXCHANGE_MESSAGE;

+

+   The AuthScheme field signifies the security mechanism for which the

+   EXCHANGE message is targeted.  If a security mechanism fails to

+   produce the metadata token, it should be removed from the list of

+   supported security mechanism for this negotiation context.

+

+   If there are more than one exchange messages, the order in which the

+   exchange message is included bears no significance.  In other words,

+   the exchange messages are in an unordered set.  The NEGO_MESSAGE MAY

+   be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as

+   described above, in which case all the NegoEx messages concatenated

+   are returned as a single input token.

+

+   The first mechanism in the initiator proposed list can OPTIONALLY

+   include its initial context context in an AP_REQUEST message.

+

+   Both an AP_REQUSET(short for MESSAGE_TYPE_AP_REQUEST) message and a

+   INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA)

+   message are instances of the EXCHANGE_MESSAGE structure with

+   different message type values.  An AP_REQUEST message contains the

+   type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message

+   contains the type MESSAGE_TYPE_INITIATOR_META_DATA.

+

+5.2.  Receipt of the Initial Initiator Token and Generation of the

+      Initial Acceptor Response

+

+   Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor

+   verifies the NEGO_MESSAGE to make sure it is well-formed.  The

+   acceptor then computes the list of authentication schemes that are

+   mutually supported by examining the set of security mechanisms

+   proposed by the initiator and the meta-data tokens from the

+   initiator.  The meta-data tokens are passed to the security mechanism

+   via GSS_Exchange_meta_data() as defined in Section 6.

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 13]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   The acceptor MUST examine the NegoEx extensions in the NEGO_MESSAGE.

+   If there is an unknown critical extension, the authentication must be

+   rejected.

+

+   The acceptor's response starts as a NEGO_MESSAGE but with the

+   MESSAGE_TYPE_ACCEPTOR_NEGO.  The AuthSchemes field contains the list

+   of mutually supported security mechanism in decreasing preference

+   order of the acceptor.  The acceptor does not need to honor the

+   preference order proposed by the initiator when computing its

+   preference list.

+

+   The acceptor can OPTIONALLY include a meta-data token, one for each

+   available security mechanism.

+

+   A meta-data token is returned to NegoEx for a security mechanism

+   using GSS_Query_meta_data() extension as defined in Section 6.  A

+   meta-data token is encapsulated in an EXCHANGE message with the

+   message type MESSAGE_TYPE_ACCEPTOR_META_DATA.  For a given security

+   mechanism if a meta-token is received from the initiator,

+   GSS_Query_meta_data() MUST be invoked on the acceptor side for that

+   security mechanism, and the output meta-data token, if present, MUST

+   be included in the NegoEx reply.

+

+5.3.  Receipt of the Acceptor Initial Response and Completion of

+      Authentication after the Negotiation Phrase

+

+   Upon receipt of the initial response from the acceptor, the initial

+   verifies the NEGO_MESSAGE to make sure it is well-formed.  The

+   initiator then computes the list of authentication schemes that are

+   mutually supported by examining the set of security mechanisms

+   returned by the acceptor and the meta-data tokens from the acceptor

+   The meta-data tokens are passed to the security mechanism via

+   GSS_Exchange_meta_data() as defined in Section 6.

+

+   The initiator MUST examine the NegoEx extensions in the NEGO_MESSAGE.

+   If there is an unknown critical extension, the authentication must be

+   rejected.

+

+   After the initial exchange of NEGO_MESSAGE messages, the initiator

+   MUST choose the negotiated security mechanism.  The negotiated

+   security mechanism cannot be changed once it is selected.

+

+   The initiator and the acceptor can then proceed to exchange handshake

+   messages as determined by the negotiated security mechanism until its

+   authentication context is established.  The context tokens of the

+   negotiated security mechanism are encapsulated in an

+   EXCHANGE_MESSAGE.  If the context token is from the initiator, the

+   EXCHANGE_MESSAGE message has the message type

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 14]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+   MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is

+   MESSAGE_TYPE_CHALLENGE.

+

+5.4.  Finalizing Negotiation

+

+   Whenever there is a shared key established returned by

+   GSS_Query_context_attr(NEGOEX_SESSION_KEYS) as defined in Section 6,,

+   a VERIFY message is produced and included in the output token.  The

+   returned protocol key is used as the base key in the parlance of

+   RFC3961 to sign all the NegoEx messages in the negotiation context.

+

+   A VERIFY message is a VERIFY_MESSAGE structure.  The AuthScheme field

+   signifies from which security mechanism the protocol key was

+   obtained.  The checksum is computed based on RFC3961 and the key

+   usage number is 23 for the message is signed by the initiator, 25

+   otherwise.  The checksum is performed over all the previous NegoEx

+   messages in the context negotiation.

+

+       struct

+       {

+           MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY

+           AUTH_SCHEME AuthScheme;

+           CHECKSUM Checksum;

+                // contains the checksum of all the previously

+                // exchanged messages in the order they were sent.

+       } VERIFY_MESSAGE;

+

+   Note that the VERIFY_MESSAGE message can be included before the

+   security context for the negotiated security mechanism is fully

+   established.

+

+5.5.  High-level NegoEx Message Flow

+

+   The following text art summarizes the protocol message flow:

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 15]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+  INITIATOR_NEGO

+  *INITIATOR_META_DATA

+  *AP_REQUEST

+                                    --------->

+                                                           ACCEPTOR_NEGO

+                                                    ACCEPTOR_META_DATA*+

+                                    ---------                CHALLENGE*

+

+                                        .

+                                        .

+  *AP_REQUEST

+  VERIFY                            --------->

+                                                              CHALLENGE*

+                                    --------                     VERIFY

+         * Indicates optional or situation-dependent messages that are

+           not always sent.

+         + Indicates there can be more than one instance.

+

+

+6.  Supporting GSS-API Extensions

+

+   This section defined all the required GSS-API extensions required by

+   NegoEx.

+

+6.1.  GSS_Query_meta_data

+

+   TBD.

+

+6.2.  GSS_Exchange_meta_data

+

+   TBD.

+

+6.3.  GSS_Query_mechanism_info

+

+   TBD.

+

+6.4.  GSS_Query_context_attr

+

+   TBD.

+

+

+7.  Security Considerations

+

+   TBD.

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 16]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+8.  Acknowledgements

+

+   TBD.

+

+

+9.  IANA Considerations

+

+   There is no action required for IANA.

+

+

+10.  Normative References

+

+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

+              Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [RFC2743]  Linn, J., "Generic Security Service Application Program

+              Interface Version 2, Update 1", RFC 2743, January 2000.

+

+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

+              Kerberos 5", RFC 3961, February 2005.

+

+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

+              Kerberos Network Authentication Service (V5)", RFC 4120,

+              July 2005.

+

+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos

+              Version 5 Generic Security Service Application Program

+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,

+              July 2005.

+

+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The

+              Simple and Protected Generic Security Service Application

+              Program Interface (GSS-API) Negotiation Mechanism",

+              RFC 4178, October 2005.

+

+

+Appendix A.  Protocol Data Structures and Constant Values

+

+   This section complies all the protocol data structures and constant

+   values.

+

+       #define MESSAGE_SIGNATURE    0x535458454f47454ei64

+           // "NEGOEXTS"

+

+       struct

+       {

+           ULONG ByteArrayOffset; // each element contains a byte

+           ULONG ByteArrayLength;

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 17]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+       } BYTE_VECTOR;

+

+       struct

+       {

+           ULONG AuthSchemeArrayOffset;

+               // each element contains an AUTH_SCHEME

+           USHORT AuthSchemeCount;

+       } AUTH_SCHEME_VECTOR;

+

+       struct

+       {

+           ULONG ExtensionArrayOffset;

+               // each element contains an EXTENSION

+           USHORT ExtensionCount;

+       } EXTENSION_VECTOR;

+

+       struct

+       {

+           ULONG ExtensionType; // negative extensions are critical

+           BYTE_VECTOR ExtensionValue;

+       } EXTENSION;

+

+       //

+       // schemes defined for the checksum in the VERIFY message

+       //

+

+       #define CHECKSUM_SCHEME_RFC3961  1

+

+       struct

+       {

+           ULONG cbHeaderLength;

+           ULONG ChecksumScheme;

+           ULONG ChecksumType; // in the case of RFC3961 scheme, this is

+              // the RFC3961 checksum type

+           BYTE_VECTOR ChecksumValue;

+       } CHECKSUM;

+

+       typedef GUID AUTH_SCHEME;

+       typedef GUID CONVERSATION_ID;

+

+       enum

+       {

+           MESSAGE_TYPE_INITIATOR_NEGO = 0,

+           MESSAGE_TYPE_ACCEPTOR_NEGO,

+           MESSAGE_TYPE_INITIATOR_META_DATA,

+           MESSAGE_TYPE_ACCEPTOR_META_DATA,

+           MESSAGE_TYPE_CHALLENGE,

+               // an exchange message from the acceptor

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 18]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+           MESSAGE_TYPE_AP_REQUEST,

+               // an exchange message from the initiator

+           MESSAGE_TYPE_VERIFY,

+           MESSAGE_TYPE_ALERT,

+       } MESSAGE_TYPE;

+

+       struct

+       {

+           ULONG64 Signature; // contains MESSAGE_SIGNATURE

+           MESSAGE_TYPE MessageType;

+           ULONG SequenceNum; // the message sequence number of this,

+                  // conversation, starting with 0 and sequentially

+                  // incremented

+           ULONG cbHeaderLength; // the header length of this message,

+              // including the message specific header, excluding the

+              // payload

+           ULONG cbMessageLength; // the length of this message

+           CONVERSATION_ID ConversationId;

+       } MESSAGE_HEADER;

+

+       struct

+       {

+           MESSAGE_HEADER Header;

+                    // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,

+                    // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor

+           UCHAR Random[32];

+           ULONG64 ProtocolVersion;

+                   // version of the protocol, this contains 0

+           AUTH_SCHEME_VECTOR AuthSchemes;

+           EXTENSION_VECTOR Extensions;

+       } NEGO_MESSAGE;

+

+       struct

+       {

+           MESSAGE_HEADER Header;

+                // MESSAGE_TYPE_CHALLENGE for the acceptor,

+                // or MESSAGE_TYPE_AP_REQUEST for the initiator

+               // MESSAGE_TYPE_INITiATOR_META_DATA for

+               // the initiator metadata

+               // MESSAGE_TYPE_ACCEPTOR_META_DATA for

+               // the acceptor metadata

+           AUTH_SCHEME AuthScheme;

+           BYTE_VECTOR Exchange;

+               // contains the opaque handshake message for the

+               // authentication scheme

+       } EXCHANGE_MESSAGE;

+

+       struct

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 19]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+       {

+           MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY

+           AUTH_SCHEME AuthScheme;

+           CHECKSUM Checksum;

+                // contains the checksum of all the previously

+                // exchanged messages in the order they were sent.

+       } VERIFY_MESSAGE;

+

+       struct

+       {

+           ULONG AlertType;

+           BYTE_VECTOR AlertValue;

+       } ALERT;

+

+       //

+       // alert types

+       //

+

+       #define ALERT_TYPE_PULSE             1

+

+       //

+       // reason codes for the heartbeat message

+       //

+

+       #define ALERT_VERIFY_NO_KEY          1

+

+       struct

+       {

+           ULONG cbHeaderLength;

+           ULONG Reason;

+       } ALERT_PULSE;

+

+       struct

+       {

+           ULONG AlertArrayOffset; // the element is an ALERT

+           USHORT AlertCount; // contains the number of alerts

+       } ALERT_VECTOR;

+

+       struct

+       {

+           MESSAGE_HEADER Header;

+           AUTH_SCHEME AuthScheme;

+           ULONG ErrorCode; // an NTSTATUS code

+           ALERT_VECTOR Alerts;

+       } ALERT_MESSAGE;

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 20]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+Authors' Addresses

+

+   Larry Zhu

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: lzhu@microsoft.com

+

+

+   Kevin Damour

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: kdamour@microsoft.com

+

+

+   Dave McPherson

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: davemm@microsoft.com

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 21]

+

+Internet-Draft                   NEGOEX                        July 2008

+

+

+Full Copyright Statement

+

+   Copyright (C) The IETF Trust (2008).

+

+   This document is subject to the rights, licenses and restrictions

+   contained in BCP 78, and except as set forth therein, the authors

+   retain all their rights.

+

+   This document and the information contained herein are provided on an

+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

+

+

+Intellectual Property

+

+   The IETF takes no position regarding the validity or scope of any

+   Intellectual Property Rights 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; nor does it represent that it has

+   made any independent effort to identify any such rights.  Information

+   on the procedures with respect to rights in RFC documents can be

+   found in BCP 78 and BCP 79.

+

+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at

+   http://www.ietf.org/ipr.

+

+   The IETF invites any interested party to bring to its attention any

+   copyrights, patents or patent applications, or other proprietary

+   rights that may cover technology that may be required to implement

+   this standard.  Please address the information to the IETF at

+   ietf-ipr@ietf.org.

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.             Expires January 15, 2009               [Page 22]

+

+

diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-negoex-04.txt b/third_party/heimdal/doc/standardisation/draft-zhu-negoex-04.txt
new file mode 100644
index 00000000000..17f189fa621
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-negoex-04.txt
@@ -0,0 +1,1345 @@
+
+
+
+NETWORK WORKING GROUP                                           M. Short
+Internet-Draft                                                    L. Zhu
+Updates: 4178 (if approved)                                    K. Damour
+Intended status: Standards Track                            D. McPherson
+Expires: July 7, 2011                              Microsoft Corporation
+                                                         January 3, 2011
+
+
+        SPNEGO Extended Negotiation (NEGOEX) Security Mechanism
+                          draft-zhu-negoex-04
+
+Abstract
+
+   This document defines the SPNEGO Extended Negotiation (NEGOEX)
+   Security Mechanism.  NEGOEX enhances the capabilities of SPNEGO by
+   providing a security mechanism which can be negotiated by the SPNEGO
+   protocol as defined in RFC4178.
+
+   The NEGOEX protocol itself is a security mechanism negotiated by
+   SPNEGO.  When the NEGOEX security mechanism is selected by SPNEGO,
+   NEGOEX provides a method allowing selection of a common
+   authentication protocol based on factors beyond just the fact that
+   both client and server support a given security mechanism.  NEGOEX
+   OPTIONALLY adds a pair of meta-data messages for each negotiated
+   security mechanism.  The meta-data exchange allows security
+   mechanisms to exchange auxiliary information such as trust
+   configurations, thus NEGOEX provides more flexibility than just
+   exchanging security mechanism OIDs in SPNEGO.
+
+   NEGOEX preserves the optimistic token semantics of SPNEGO and applies
+   that recursively.  Consequently a context establishment mechanism
+   token can be included in the initial NEGOEX message, and NEGOEX does
+   not require an extra round-trip when the initiator's optimistic token
+   is accepted by the target.
+
+   Similar to SPNEGO, NEGOEX defines a few new GSS-API extensions that a
+   security mechanism MUST support in order to be negotiated by NEGOEX.
+   This document defines these GSS-API extensions.
+
+   Unlike SPNEGO however, NEGOEX defines its own way for signing the
+   protocol messages in order to protect the protocol negotiation.  The
+   NEGOEX message signing or verification can occur before the security
+   context for the negotiated real security mechanism is fully
+   established.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 1]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on July 7, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 2]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Requirements Terminology . . . . . . . . . . . . . . . . . . .  6
+   3.  Presentation Language and Primitive Data Types . . . . . . . .  7
+     3.1.  Basic Block Size . . . . . . . . . . . . . . . . . . . . .  7
+     3.2.  Miscellaneous  . . . . . . . . . . . . . . . . . . . . . .  7
+     3.3.  Constants  . . . . . . . . . . . . . . . . . . . . . . . .  7
+     3.4.  Numbers  . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     3.5.  Enum Types . . . . . . . . . . . . . . . . . . . . . . . .  7
+     3.6.  Typedef Declarations . . . . . . . . . . . . . . . . . . .  8
+     3.7.  Array Types  . . . . . . . . . . . . . . . . . . . . . . .  8
+     3.8.  Constructed Types  . . . . . . . . . . . . . . . . . . . .  8
+   4.  Vector Types . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  NEGOEX Messages  . . . . . . . . . . . . . . . . . . . . . . . 11
+   6.  Cryptographic Computations . . . . . . . . . . . . . . . . . . 12
+   7.  The NEGOEX Protocol  . . . . . . . . . . . . . . . . . . . . . 12
+     7.1.  High-level NEGOEX Message Flow . . . . . . . . . . . . . . 12
+     7.2.  NEGOEX Supported Security Mechanisms . . . . . . . . . . . 13
+     7.3.  ConversationID . . . . . . . . . . . . . . . . . . . . . . 13
+     7.4.  Generation of the Initiator Initial Token  . . . . . . . . 13
+     7.5.  Receipt of the Initial Initiator Token and Generation
+           of the Initial Acceptor Response . . . . . . . . . . . . . 15
+     7.6.  Receipt of the Acceptor Initial Response and
+           Completion of Authentication after the Negotiation
+           Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     7.7.  Finalizing Negotiation . . . . . . . . . . . . . . . . . . 16
+   8.  Supporting GSS-API Extensions  . . . . . . . . . . . . . . . . 17
+     8.1.  GSS_Query_meta_data  . . . . . . . . . . . . . . . . . . . 17
+     8.2.  GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 18
+     8.3.  GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 19
+     8.4.  GSS_Inquire_context  . . . . . . . . . . . . . . . . . . . 19
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
+   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+   12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
+   Appendix A.  Protocol Data Structures and Constant Values  . . . . 20
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 3]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+1.  Introduction
+
+   If more than one GSS-API mechanism is shared between the initator and
+   the acceptor, the Simple and Protected (GSS-API) Negotiation
+   Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose
+   a mutually preferred one.  This pseudo mechanism does well in the
+   most basic scenarios but suffers from a couple of drawbacks, notably:
+
+   o  Since the SPNEGO negotiation is based on purely on exchanging
+      security mechanism OIDs, security mechanisms can be selected which
+      cannot successfully authenticate the initator.  Just because an
+      initator and acceptor support the same security mechanism does not
+      mean that they have a mutually trusted authentication authority.
+      In such cases, the authentication will fail with the preferred
+      security mechanism, but might succeed with another common
+      mechanism.
+
+   o  Secondly, the SPNEGO negotiation model is inadequate when the
+      choice cannot be made by the acceptor in the initial response.  In
+      SPNEGO, the negotiation information is sent one-way from the
+      initiator for the acceptor to make a choice, and the acceptor must
+      choose one when it makes the initial response.  This negotiation
+      model is counter intuitive.  The selection of a security mechanism
+      is typically the result of selecting one type of credentials from
+      the available set, and the initiator typically does not wish to
+      reveal credentials information often associated with user
+      identities.  In practice, in order to operate in this model, the
+      Kerberos GSS-API mechanism [RFC4121] must acquire the context
+      establishment token in the initial call to GSS_Init_sec_context().
+      If the initiator fails to acquire the initial Kerberos GSS-API
+      context token, it must not offer Kerberos; otherwise the SPNEGO
+      context negotiation will fail without being able to select the
+      next available mechanism that could work.  Obtaining the initial
+      Kerberos GSS-API context token may require multiple round-trips of
+      network calls and the cost of the operation can be substantial.
+      It is suboptimal when multiple GSS-API mechanisms have to add the
+      extra cost that would not exist if the negotiated security
+      mechanism were selected based on configuration.
+
+   The SPNEGO Extended Negotiation (NEGOEX) Security Mechanism is
+   designed to address these concerns.  NEGOEX is a security mechanism
+   that is negotiated by SPNEGO, and when negotiated, it can recursively
+   negotiate other security mechanisms.
+
+   Any security mechanism negotiated by NEGOEX MUST support integrity
+   protection and addition GSS-API interfaces specified in Section 8.
+
+   The basic form of NEGOEX works as follows:
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 4]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   1.  The initiator proposes a list of mechanisms in decreasing
+       preference order.  For each of these mechanism, NEGOEX OPTIONALLY
+       includes a mechanism specific meta-data token.  GSS-API
+       extensions are defined later in this document for NEGOEX to query
+       the meta-data token for inclusion in the NEGOEX message.
+
+   2.  The acceptor then passes the meta-data token from the initiator
+       to the intended security mechanism.  A meta-data token for a
+       security mechanism not supported on the acceptor side is ignored.
+       New GSS-API extensions are defined later in this document for a
+       security mechanism to consume the meta-data token.  When
+       processing the received meta-data tokens, a security mechanism
+       that reports a failure is removed from the set of mutually
+       supported mechanisms.  The acceptor then responds with the list
+       of mutually supported mechanisms in decreasing preference order.
+       For each of these mechanism, NEGOEX again OPTIONALLY supplies a
+       mechanism specific meta-data token in the response which it
+       obtains from each remaining supported mechanism via the new GSS-
+       API extensions described in the initial step.
+
+   3.  The initiator then passes the meta-data tokens to the intended
+       security mechanisms by invoking the new GSS-API extensions.  When
+       processing the received meta-data token, a security mechanism
+       that reports a failure is removed from the set of mutually
+       supported mechanisms for this negotiation context.  The initiator
+       then selects one from the set of mutually-supported mechanisms.
+       If more than one security mechanism is available, unless
+       otherwise specified, the highest one in the acceptor's preference
+       order SHOULD be selected.  Later when the common security
+       mechanism is identified, the security mechanism may also
+       negotiate mechanism-specific options during its context
+       establishments.  This will be inside the mechanism tokens, and
+       invisible to the NEGOEX protocol during step 5.
+
+   4.  The selected security mechanism provides keying materials to
+       NEGOEX via new GSS-API extensions which defined later in this
+       document.  NEGOEX signs and verifies the negotiation NEGOEX
+       messages to protect the negotiation.
+
+   5.  The initiator and the acceptor proceed to exchange tokens until
+       the GSS-API context for selected security mechanism is
+       established.  Once the security context is established, the per-
+       message tokens are generated and verified in accordance with the
+       selected security mechanism.
+
+   NEGOEX does not work outside of SPNEGO.  When negotiated by SPNEGO,
+   NEGOEX uses the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 5]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+   the existence of the negotiation tokens but only of the SPNEGO
+   pseudo-security mechanism.
+
+   In its basic form NEGOEX requires at least one extra round-trip.
+   Network connection setup is a critical performance characteristic of
+   any network infrastructure and extra round trips over WAN links,
+   packet radio networks, etc. really make a difference.  In order to
+   avoid such an extra round trip the initial security token of the
+   preferred mechanism for the initiator may be embedded in the initial
+   NEGOEX token.  The optimistic mechanism token may be accompanied by
+   the meta-data tokens and the optimistic mechanism token MUST be that
+   of the first mechanism in the list of the mechanisms proposed by the
+   initiator.  The NEGOEX MESSAGE_TYPE_INITIATOR_NEGO message that
+   contains signatures for protecting the NEGOEX negotiation may also
+   accompany the optimistic mechanism token.  If the target preferred
+   mechanism matches the initiator's preferred mechanism, and when the
+   NEGOEX negotiation protection messages are included along with the
+   mechanism token, no additional round trips are incurred by using the
+   NEGOEX protocol with SPNEGO.
+
+   NEGOEX does not update the ASN.1 structures of SPNEGO [RFC4178]
+   because a widely deployed SPNEGO implementation does not have the
+   ASN.1 extensibility marker in the message definition.  There is no
+   change to the SPNEGO messages.
+
+   NEGOEX uses a C-like definition language to describe message formats.
+
+   The rest of the document is organized as follows:
+
+   o  Section 3 defines the encoding of NEGOEX data structures and all
+      the primitive data types.
+   o  Section 6 describes the cryptographic framework required by the
+      NEGOEX for protecting the NEGOEX negotiation.
+   o  Section 7 defines the NEGOEX messages and the NEGOEX protocol.
+   o  Section 8 defines the new GSS-API extensions that a security
+      mechanism MUST support in order to be negotiated by NEGOEX.
+   o  Section 9 contains the security considerations for NEGOEX.
+   o  Appendix A contains all the protocol constructs and constants.
+
+
+2.  Requirements Terminology
+
+   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 [RFC2119].
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 6]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+3.  Presentation Language and Primitive Data Types
+
+   The following very basic and somewhat casually defined presentation
+   syntax will be used in all NEGOEX messages.  Although it resembles
+   the programming language "C" in its syntax, it would be risky to draw
+   too many parallels.  The purpose of this presentation language is to
+   document NEGOEX only; it has no general application beyond that
+   particular goal.
+
+   This section also defines all the primitive data types.  The
+   semantics of the data types is explained in the next section.
+
+3.1.  Basic Block Size
+
+   The representation of all data items is explicitly specified.  The
+   basic data block size is one octet.  Multiple octet data items are
+   concatenations of octets, from left to right, from top to bottom
+   Unless otherwise specific a multi-octet numeric is in little endian
+   order with the least significant octet first.
+
+3.2.  Miscellaneous
+
+   Comments start with "//"' and continue until the end of the line.
+
+3.3.  Constants
+
+   Constants are denoted using "#define" followed by the symbolic name
+   and then the constant value.
+
+3.4.  Numbers
+
+   UCHAR is the data type for a one-octet number.
+
+   ULONG is the data type for a 4-octet number encoded in little endian.
+
+   USHORT is the data type for a 2-octet number encoded in little
+   endian.
+
+   ULONG64 is the data type for a 8-octet number encoded in little
+   endian.
+
+   GUID is the data type for a 16-octet number encoded in little endian.
+
+3.5.  Enum Types
+
+   An enum type is the data type for a number with a small number of
+   permissible values.  An instance of an enum type is a 4-octet number
+   encoded in little endian.
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 7]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   The definition of an enum type follows the simple "C" convention.
+
+   MESSAGE_TYPE is an enum type defined as follows:
+
+       enum
+       {
+           MESSAGE_TYPE_INITIATOR_NEGO = 0,
+           MESSAGE_TYPE_ACCEPTOR_NEGO,
+           MESSAGE_TYPE_INITIATOR_META_DATA,
+           MESSAGE_TYPE_ACCEPTOR_META_DATA,
+           MESSAGE_TYPE_CHALLENGE,
+               // an exchange message from the acceptor
+           MESSAGE_TYPE_AP_REQUEST,
+               // an exchange message from the initiator
+           MESSAGE_TYPE_VERIFY,
+           MESSAGE_TYPE_ALERT,
+       } MESSAGE_TYPE;
+
+   MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT
+   has the value 7.
+
+3.6.  Typedef Declarations
+
+   A typedef creates a synonym for the type.  This is used to create
+   more meaningful names for existing types.
+
+   The following two type synonyms are defined.
+
+   typedef GUID AUTH_SCHEME;
+   typedef GUID CONVERSATION_ID;
+
+3.7.  Array Types
+
+   Arrays are a data structure which holds multiple variables of the
+   same data type consecutively and the number of elements is fixed.  An
+   array is declared using "C" convention.  The following defines an
+   array of 32 octets.
+
+   UCHAR Random[32];
+
+3.8.  Constructed Types
+
+   Structure types may be constructed from primitive types for
+   convenience.  Each specification declares a new, unique type.  The
+   syntax for definition is much like that of C.
+
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 8]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+           struct {
+           T1 f1;
+           T2 f2;
+           ...
+           Tn fn;
+           } T;
+
+
+   Structure definitions may be embedded.
+
+   The following types are defined as constructed types:
+
+           struct
+           {
+           ULONG ExtensionType; // negative extensions are critical
+           BYTE_VECTOR ExtensionValue;
+           } EXTENSION;
+
+   An extension has two fields.  The ExtensionType field indicates how
+   the extension data should be interpreted.  The ExtensionValue field
+   contains the extension data.
+
+           //
+           // schemes defined for the checksum in the VERIFY message
+           //
+
+           struct
+           {
+           ULONG cbHeaderLength;
+           ULONG ChecksumScheme;
+           ULONG ChecksumType; // in the case of RFC3961 scheme, this is
+           // the RFC3961 checksum type
+           BYTE_VECTOR ChecksumValue;
+           } CHECKSUM;
+
+   The CHECKSUM structure contains 4 fields.  The cbHeaderLength length
+   contains the length of the structure defintion in octets, and this
+   field has a value of 20.
+
+   The ChecksumScheme field describes how checksum is computed and
+   verified.  Currently only one value is defined.
+
+           #define CHECKSUM_SCHEME_RFC3961 1
+
+   When the value of the ChecksumScheme field is 1
+   (CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a
+   sequence of octets computed according to [RFC3961] and the
+   ChecksumType field contains the checksum type value defined according
+
+
+
+Short, et al.             Expires July 7, 2011                  [Page 9]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   to [RFC3961].
+
+
+4.  Vector Types
+
+   Vectors are a data structure which holds multiple variables of the
+   same data type consecutively and the number of elements is not fixed.
+   A vector contains a fixed length header followed by a variable length
+   payload.  The header of a vector structure contains the count of
+   elements and the offset to the payload.  In this document all the
+   offset fields are relative to the beginning of the containing NEGOEX
+   message.  The size of each element is specified by the vector type
+   definition.
+
+   The following vector types are defined.
+
+       struct
+       {
+           ULONG ByteArrayOffset; // each element contains an octet/byte
+           ULONG ByteArrayLength;
+       } BYTE_VECTOR;
+
+   BYTE_VECTOR encapsulates a variable length array of octets (or bytes)
+   that are stored consecutively.  Each element in is a byte (8 bits).
+
+       struct
+       {
+           ULONG AuthSchemeArrayOffset;
+                // each element contains an AUTH_SCHEME
+           USHORT AuthSchemeCount;
+       } AUTH_SCHEME_VECTOR;
+
+   AUTH_SCHEME_VECTOR encapsulates a variable length array of
+   AUTH_SCHEMEs that are stored consecutively.  Each element is a
+   structure of the type AUTH_SCHEME.
+
+       struct
+       {
+           ULONG ExtensionArrayOffset;
+               // each element contains an EXTENSION
+           USHORT ExtensionCount;
+       } EXTENSION_VECTOR;
+
+   EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs
+   that are stored consecutively.  Each element is a structure of the
+   type EXTENSION.
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 10]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+5.  NEGOEX Messages
+
+   The following structure is the MESSAGE_HEADER:
+
+           struct
+           {
+           ULONG64 Signature; // contains MESSAGE_SIGNATURE
+           MESSAGE_TYPE MessageType;
+           ULONG SequenceNum; // the message sequence number of this,
+           // conversation, starting with 0 and sequentially
+           // incremented
+           ULONG cbHeaderLength; // the header length of this message,
+           // including the message specific header, excluding the
+           // payload
+           ULONG cbMessageLength; // the length of this message
+           CONVERSATION_ID ConversationId;
+           } MESSAGE_HEADER;
+
+   The following structure is the NEGO_MESSAGE:
+
+           struct
+           {
+           MESSAGE_HEADER Header;
+           // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,
+           // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor
+           UCHAR Random[32];
+           ULONG64 ProtocolVersion;
+           // version of the protocol, this contains 0
+           AUTH_SCHEME_VECTOR AuthSchemes;
+           EXTENSION_VECTOR Extensions;
+           } NEGO_MESSAGE;
+
+   The following structure is the EXCHANGE_MESSAGE:
+
+           struct
+           {
+           MESSAGE_HEADER Header;
+           // MESSAGE_TYPE_CHALLENGE for the acceptor,
+           // or MESSAGE_TYPE_AP_REQUEST for the initiator
+           // MESSAGE_TYPE_INITIATOR_META_DATA for
+           // the initiator metadata
+           // MESSAGE_TYPE_ACCEPTOR_META_DATA for
+           // the acceptor metadata
+           AUTH_SCHEME AuthScheme;
+           BYTE_VECTOR Exchange;
+           // contains the opaque handshake message for the
+           // authentication scheme
+           } EXCHANGE_MESSAGE;
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 11]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+6.  Cryptographic Computations
+
+   The message signing and verification in NEGOEX is based on [RFC3961].
+   [RFC3961] is used here as a generic framework and this application is
+   not Kerberos specific.
+
+   A security mechanism MUST support [RFC3961] in order to be negotiated
+   by NEGOEX.
+
+
+7.  The NEGOEX Protocol
+
+   This section describes the NEGOEX protocol and it defines NEGOEX
+   messages in the order that the messages can appear on the wire.  The
+   enum type MESSAGE_TYPE defined in Section 3.5 lists all NEGOEX
+   message types.  A GSS-API context token for NEGOEX consists of one or
+   more NEGOEX messages.  If there is more than one NEGOEX message,
+   these messages are concatenated together.  The smallest data unit for
+   NEGOEX to compute the checksum for negotiation protection is s NEGOEX
+   message.  Note that NEGOEX is not a GSS-API mechanism itself and the
+   initial NEGOEX context establishment token does not follow the
+   mechanism-independent token format defined in Section 3.1 of
+   [RFC2743].
+
+   The object identifier of the NEGOEX within SPNEGO is iso(1)
+   identified-organization(3) dod(6) internet(1) private(4)
+   enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30).
+
+7.1.  High-level NEGOEX Message Flow
+
+   The following text art summarizes the protocol message flow:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 12]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+        Initiator                                               Acceptor
+
+        INITIATOR_NEGO
+        +*INITIATOR_META_DATA
+        *AP_REQUEST
+                                    --------->
+                                                           ACCEPTOR_NEGO
+                                                    ACCEPTOR_META_DATA*+
+                                    <---------                CHALLENGE*
+
+                                        .
+                                        .
+
+        *AP_REQUEST                 --------->
+                                    <---------                CHALLENGE*
+
+                                        .
+                                        .
+        *AP_REQUEST
+        VERIFY                      --------->
+                                                              CHALLENGE*
+                                    <---------                    VERIFY
+        * Indicates optional or situation-dependent messages that are
+        not always sent.
+        + Indicates there can be more than one instance.
+
+
+7.2.  NEGOEX Supported Security Mechanisms
+
+   NEGOEX maintains an ordered list of supported security mechanisms
+   names to determine priority of security mechanisms.  A security
+   mechanism negotiable by NEGOEX is identified by a unique identifier
+   of data type AUTH_SCHEME defined in Section 3.5.  Supported security
+   mechanisms are referenced by their corresponding authentication
+   scheme IDs.  The authentication scheme ID of a security mechanism is
+   returned to NEGOEX by calling GSS_Query_mechanism_info() with the
+   name of the security mechnism as defined in Section 8.3.
+
+7.3.  ConversationID
+
+   Both initiator and acceptor must keep protocol state in the form of a
+   GUID, which will be referred to hereafter as the ConversationID.
+
+7.4.  Generation of the Initiator Initial Token
+
+   The GSS-API initiator makes the first call to GSS_Init_sec_context()
+   with no input token, and the output token will be a NEGO_MESSAGE
+   message with the MESSAGE_TYPE_INITIATOR_NEGO message followed by zero
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 13]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   or more EXCHANGE_MESSAGE messages containing meta-data tokens,
+   followed by zero or one AP_REQUEST messages containing an optimistic
+   initial context token.
+
+   The initiator generates a cryptographic strength random 16 byte
+   value, stores it as the ConversationID, then sets the MESSAGE_HEADER
+   header field with the same name to that value.  The ConversationID in
+   subsequent NEGOEX messages MUST remain the same.  The initiator also
+   fills the Random field using a secure random number generator.  The
+   initiator fills the AuthSchemes with available security mechanisms
+   supported by the initiator in decreasing preference order.
+
+   The extensions field contains NEGOEX extensions for future
+   extensibility.  There are no extensions defined in this document.
+   All negative extension types (the highest bit is set to 1) are
+   critical.  If the receiver does not understand a critical extension,
+   the authentication attempt must be rejected.
+
+   The initiator can OPTIONALLY include a meta-data token, one for each
+   available security mechanism.
+
+   A meta-data token is returned to NEGOEX for a security mechanism
+   using GSS_Query_meta_data() extension as defined in Section 8.1.  If
+   a non-empty meta-data token is returned, then the meta-data token is
+   encapsulated in an EXCHANGE message with the message type
+   MESSAGE_TYPE_INITIATOR_META_DATA.  On GSS_Query_meta_data call
+   failure, NEGOEX SHOULD remove the security mechanism from the set of
+   authentication schemes to be negotiated.
+
+   The AuthScheme field signifies the security mechanism for which the
+   EXCHANGE message is targeted.  If a security mechanism fails to
+   produce the metadata token, it should be removed from the list of
+   supported security mechanism for this negotiation context.
+
+   If there is more than one exchange message, the order in which the
+   exchange message is included bears no significance.  In other words,
+   the exchange messages are in an unordered set.  The NEGO_MESSAGE MAY
+   be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as
+   described above, in which case all the NEGOEX messages concatenated
+   are returned as a single output token.
+
+   The first mechanism in the initiator proposed list can OPTIONALLY
+   include its initial context token in an AP_REQUEST message.
+
+   Both an AP_REQUEST(short for MESSAGE_TYPE_AP_REQUEST) message and a
+   INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA)
+   message are instances of the EXCHANGE_MESSAGE structure with
+   different message type values.  An AP_REQUEST message contains the
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 14]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message
+   contains the type MESSAGE_TYPE_INITIATOR_META_DATA.
+
+7.5.  Receipt of the Initial Initiator Token and Generation of the
+      Initial Acceptor Response
+
+   Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor
+   verifies the NEGO_MESSAGE to make sure it is well-formed.  The
+   acceptor extracts the ConversationID from the NEGO_MESSAGE and stores
+   it as the ConversationID for the context handle.  The acceptor then
+   computes the list of authentication schemes that are mutually
+   supported by examining the set of security mechanisms proposed by the
+   initiator and the meta-data tokens from the initiator.  The meta-data
+   tokens are passed to the security mechanism via
+   GSS_Exchange_meta_data() as defined in Section 8.2.  On
+   GSS_Exchange_meta_data call failure, NEGOEX SHOULD remove the
+   security mechanism from the set of authentication schemes to be
+   negotiated.
+
+   The acceptor MUST examine the NEGOEX extensions in the NEGO_MESSAGE.
+   If there is an unknown critical extension, the authentication must be
+   rejected.
+
+   The acceptor's output token is a NEGO_MESSAGE but with the the
+   Header.MessageType set to MESSAGE_TYPE_ACCEPTOR_NEGO followed by zero
+   or more EXCHANGE_MESSAGE containing meta-data tokens.  The
+   AuthSchemes field contains the list of mutually supported security
+   mechanism in decreasing preference order of the acceptor.  The
+   acceptor does not need to honor the preference order proposed by the
+   initiator when computing its preference list.
+
+   As with the initiator, the acceptor can OPTIONALLY include a meta-
+   data token, one for each available security mechanism.
+
+   A meta-data token is obtained by NEGOEX for a security mechanism
+   using GSS_Query_meta_data() extension as defined in Section 8.1.  If
+   a non-empty meta-data token is returned, then the meta-data token is
+   encapsulated in an EXCHANGE message with the message type
+   MESSAGE_TYPE_ACCEPTOR_META_DATA.  For a given security mechanism if a
+   meta-token is received from the initiator, GSS_Query_meta_data() MUST
+   be invoked on the acceptor side for that security mechanism, and the
+   output meta-data token, if present, MUST be included in the NEGOEX
+   reply.  On GSS_Query_meta_data call failure, NEGOEX SHOULD remove the
+   security mechanism from the set of authentication schemes to be
+   negotiated.
+
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 15]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+7.6.  Receipt of the Acceptor Initial Response and Completion of
+      Authentication after the Negotiation Phrase
+
+   Upon receipt of the initial response token from the acceptor, the
+   application calls GSS_Init_sec_context with the response token.  The
+   initiator verifies the NEGOEX message received to make sure it is
+   well-formed.  The initiator ensures the correct context handle by
+   verifying that the ConversationID of the context handle matches the
+   conversation ID in the NEGOEX message received.  The initiator then
+   computes the list of authentication schemes that are mutually
+   supported by examining the set of security mechanisms returned by the
+   acceptor and the meta-data tokens from the acceptor The meta-data
+   tokens are passed to the security mechanism via
+   GSS_Exchange_meta_data() as defined in Section 8.2.  On
+   GSS_Exchange_meta_data call failure, NEGOEX SHOULD remove the
+   security mechanism from the set of authentication schemes to be
+   negotiated.
+
+   The initiator MUST examine the NEGOEX extensions in the NEGO_MESSAGE.
+   If there is an unknown critical extension, the authentication must be
+   rejected.
+
+   After the initial exchange of NEGO_MESSAGE messages, the initiator
+   MUST choose the negotiated security mechanism.  The negotiated
+   security mechanism cannot be changed once it is selected.
+
+   The initiator and the acceptor can then proceed to exchange handshake
+   messages by returning GSS_S_CONTINUE_NEEDED to the calling
+   application as determined by the negotiated security mechanism until
+   its authentication context is established.  The context tokens of the
+   negotiated security mechanism are encapsulated in an
+   EXCHANGE_MESSAGE.  If the context token is from the initiator, the
+   EXCHANGE_MESSAGE message has the message type
+   MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is
+   MESSAGE_TYPE_CHALLENGE.
+
+7.7.  Finalizing Negotiation
+
+   After the security mechanism has been selected, the initiator and
+   acceptor can use GSS_Inquire_context to obtain the Negoex_Verify_key
+   as defined in Section 8.4 to determine if there is a shared key for
+   the VERIFY message.  When there is a shared key established returned
+   by GSS_Inquire_context as defined in Section 8.4, a VERIFY message is
+   produced using the required checksum mechanism per RFC 3961 and
+   included in the output token.  The returned protocol key is used as
+   the base key in the parlance of RFC3961 to sign all the NEGOEX
+   messages in the negotiation context.
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 16]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   A VERIFY message is a VERIFY_MESSAGE structure.  The AuthScheme field
+   signifies from which security mechanism the protocol key was
+   obtained.  The checksum is computed based on RFC3961 and the key
+   usage number is 23 for the message signed by the initiator, 25
+   otherwise.  The checksum is performed over all the previous NEGOEX
+   messages in the context negotiation.
+
+       struct
+       {
+           MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY
+           AUTH_SCHEME AuthScheme;
+           CHECKSUM Checksum;
+                // contains the checksum of all the previously
+                // exchanged messages in the order they were sent.
+       } VERIFY_MESSAGE;
+
+   Note that the VERIFY_MESSAGE message can be included before the
+   security context for the negotiated security mechanism is fully
+   established.
+
+
+8.  Supporting GSS-API Extensions
+
+   This section defined all the required GSS-API extensions required by
+   NEGOEX which must be supported by security mechanisms usable with
+   NEGOEX.
+
+8.1.  GSS_Query_meta_data
+
+   Inputs:
+
+   o  input_context_handle CONTEXT HANDLE
+   o  targ_name INTERNAL NAME, optional
+   o  deleg_req_flag BOOLEAN,
+   o  mutual_req_flag BOOLEAN,
+   o  replay_det_req_flag BOOLEAN,
+   o  sequence_req_flag BOOLEAN,
+   o  conf_req_flag BOOLEAN,
+   o  integ_req_flag BOOLEAN,
+
+   Outputs:
+
+   o  metadata OCTET STRING,
+   o  output_context_handle CONTEXT HANDLE
+
+   Return major_status codes:
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 17]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   o  GSS_S_COMPLETE indicates that the context referenced by the
+      input_context_handle argument is valid, and that the output
+      metadata value represents the security mechanism's provided
+      metadata.  A security mechanism may return empty metadata.
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.  Return values other than
+      major_status and minor_status are undefined.
+   o  GSS_S_NO_CRED indicates that no metadata could be returned about
+      the referenced credentials either because the input cred_handle
+      was invalid or the caller lacks authorization to access the
+      referenced credentials.
+   o  GSS_S_UNAVAILABLE indicates that the authentication security
+      service does not support this operation.
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+      reasons unspecified at the GSS-API level.  Return values other
+      than major_status and minor_status are undefined.
+
+   GSS_Query_meta_data is used to retrieve a security mechanism's
+   metadata.
+
+8.2.  GSS_Exchange_meta_data
+
+   Inputs:
+
+   o  input_context_handle CONTEXT HANDLE
+   o  cred_handle CREDENTIAL HANDLE, optional
+   o  targ_name INTERNAL NAME, optional
+   o  deleg_req_flag BOOLEAN,
+   o  mutual_req_flag BOOLEAN,
+   o  replay_det_req_flag BOOLEAN,
+   o  sequence_req_flag BOOLEAN,
+   o  conf_req_flag BOOLEAN,
+   o  integ_req_flag BOOLEAN,
+   o  metadata OCTET STRING,
+
+   Outputs:
+
+   o  output_context_handle CONTEXT HANDLE
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the metadata was provided to the
+      security mechanism.
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.  Return values other than
+      major_status and minor_status are undefined.
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 18]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   o  GSS_S_NO_CRED indicates that the metadata passed requested
+      credentials not available via this credential handle.
+   o  GSS_S_UNAVAILABLE indicates that the security mechanism does not
+      support this operation.
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+      reasons unspecified at the GSS-API level.  Return values other
+      than major_status and minor_status are undefined.
+
+   GSS_Exchange_meta_data is used to provide the metadata to each
+   security mechanism.
+
+8.3.  GSS_Query_mechanism_info
+
+   Inputs:
+
+   o  SecMechName STRING,
+
+   Outputs:
+
+   o  AuthScheme AUTH_SCHEME
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the authentication scheme value
+      represents the security mechanism's AUTH_SCHEME.
+   o  GSS_S_FAILURE indicates that the security mechanism does not
+      support NEGOEX.  Return values other than major_status and
+      minor_status are undefined.
+
+   GSS_Query_mechanism_info returns a security mechanism's
+   authentication scheme value.
+
+8.4.  GSS_Inquire_context
+
+   The following output is added to GSS_Inquire_context as defined in
+   [RFC2743].
+
+   Outputs:
+
+   o  Negoex_Verify_key OCTET STRING
+
+   This new output is the key to be used by NEGOEX for the VERIFY
+   message.
+
+
+9.  Security Considerations
+
+   Security mechanism SHOULD support providing VERIFY key material.
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 19]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+   This ensures that VERIFY messages are generated to make NEGOEX safe
+   from downgrade attacks.
+
+
+10.  Acknowledgements
+
+   TBD.
+
+
+11.  IANA Considerations
+
+   There is no action required for IANA.
+
+
+12.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+
+Appendix A.  Protocol Data Structures and Constant Values
+
+   This section compiles all the protocol data structures and constant
+   values.
+
+       #define MESSAGE_SIGNATURE    0x535458454f47454ei64
+           // "NEGOEXTS"
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 20]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+       struct
+       {
+           ULONG ByteArrayOffset; // each element contains a byte
+           ULONG ByteArrayLength;
+       } BYTE_VECTOR;
+
+       struct
+       {
+           ULONG AuthSchemeArrayOffset;
+               // each element contains an AUTH_SCHEME
+           USHORT AuthSchemeCount;
+       } AUTH_SCHEME_VECTOR;
+
+       struct
+       {
+           ULONG ExtensionArrayOffset;
+               // each element contains an EXTENSION
+           USHORT ExtensionCount;
+       } EXTENSION_VECTOR;
+
+       struct
+       {
+           ULONG ExtensionType; // negative extensions are critical
+           BYTE_VECTOR ExtensionValue;
+       } EXTENSION;
+
+       //
+       // schemes defined for the checksum in the VERIFY message
+       //
+
+       #define CHECKSUM_SCHEME_RFC3961  1
+
+       struct
+       {
+           ULONG cbHeaderLength;
+           ULONG ChecksumScheme;
+           ULONG ChecksumType; // in the case of RFC3961 scheme, this is
+              // the RFC3961 checksum type
+           BYTE_VECTOR ChecksumValue;
+       } CHECKSUM;
+
+       typedef GUID AUTH_SCHEME;
+       typedef GUID CONVERSATION_ID;
+
+       enum
+       {
+           MESSAGE_TYPE_INITIATOR_NEGO = 0,
+           MESSAGE_TYPE_ACCEPTOR_NEGO,
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 21]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+           MESSAGE_TYPE_INITIATOR_META_DATA,
+           MESSAGE_TYPE_ACCEPTOR_META_DATA,
+           MESSAGE_TYPE_CHALLENGE,
+               // an exchange message from the acceptor
+           MESSAGE_TYPE_AP_REQUEST,
+               // an exchange message from the initiator
+           MESSAGE_TYPE_VERIFY,
+           MESSAGE_TYPE_ALERT,
+       } MESSAGE_TYPE;
+
+       struct
+       {
+           ULONG64 Signature; // contains MESSAGE_SIGNATURE
+           MESSAGE_TYPE MessageType;
+           ULONG SequenceNum; // the message sequence number of this,
+                  // conversation, starting with 0 and sequentially
+                  // incremented
+           ULONG cbHeaderLength; // the header length of this message,
+              // including the message specific header, excluding the
+              // payload
+           ULONG cbMessageLength; // the length of this message
+           CONVERSATION_ID ConversationId;
+       } MESSAGE_HEADER;
+
+       struct
+       {
+           MESSAGE_HEADER Header;
+                    // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,
+                    // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor
+           UCHAR Random[32];
+           ULONG64 ProtocolVersion;
+                   // version of the protocol, this contains 0
+           AUTH_SCHEME_VECTOR AuthSchemes;
+           EXTENSION_VECTOR Extensions;
+       } NEGO_MESSAGE;
+
+       struct
+       {
+           MESSAGE_HEADER Header;
+                // MESSAGE_TYPE_CHALLENGE for the acceptor,
+                // or MESSAGE_TYPE_AP_REQUEST for the initiator
+               // MESSAGE_TYPE_INITiATOR_META_DATA for
+               // the initiator metadata
+               // MESSAGE_TYPE_ACCEPTOR_META_DATA for
+               // the acceptor metadata
+           AUTH_SCHEME AuthScheme;
+           BYTE_VECTOR Exchange;
+               // contains the opaque handshake message for the
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 22]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+               // authentication scheme
+       } EXCHANGE_MESSAGE;
+
+       struct
+       {
+           MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY
+           AUTH_SCHEME AuthScheme;
+           CHECKSUM Checksum;
+                // contains the checksum of all the previously
+                // exchanged messages in the order they were sent.
+       } VERIFY_MESSAGE;
+
+       struct
+       {
+           ULONG AlertType;
+           BYTE_VECTOR AlertValue;
+       } ALERT;
+
+       //
+       // alert types
+       //
+
+       #define ALERT_TYPE_PULSE             1
+
+       //
+       // reason codes for the heartbeat message
+       //
+
+       #define ALERT_VERIFY_NO_KEY          1
+
+       struct
+       {
+           ULONG cbHeaderLength;
+           ULONG Reason;
+       } ALERT_PULSE;
+
+       struct
+       {
+           ULONG AlertArrayOffset; // the element is an ALERT
+           USHORT AlertCount; // contains the number of alerts
+       } ALERT_VECTOR;
+
+       struct
+       {
+           MESSAGE_HEADER Header;
+           AUTH_SCHEME AuthScheme;
+           ULONG ErrorCode; // an NTSTATUS code
+           ALERT_VECTOR Alerts;
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 23]
+
+Internet-Draft                   NEGOEX                     January 2011
+
+
+       } ALERT_MESSAGE;
+
+
+Authors' Addresses
+
+   Michiko Short
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: michikos@microsoft.com
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Kevin Damour
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: kdamour@microsoft.com
+
+
+   Dave McPherson
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: davemm@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+Short, et al.             Expires July 7, 2011                 [Page 24]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-00.txt b/third_party/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-00.txt
new file mode 100644
index 00000000000..94be6e2a690
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-00.txt
@@ -0,0 +1,610 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: March 17, 2006                                        K. Lauter
+                                                   Microsoft Corporation
+                                                      September 13, 2005
+
+
+                         ECC Support for PKINIT
+                        draft-zhu-pkinit-ecc-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on March 17, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes the use of Elliptic Curve certificates,
+   Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
+   (ECDH) key agreement within the framework of PKINIT - the Kerberos
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 1]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Using Elliptic Curve Certificates and Elliptic Curve
+       Signature Schemes  . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Using ECDH Key Exchange  . . . . . . . . . . . . . . . . . . .  4
+   5.  Choosing the Domain Parameters and the Key Size  . . . . . . .  6
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
+     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 2]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+1.  Introduction
+
+   Elliptic Curve Cryptography (ECC) is emerging as an attractive
+   public-key cryptosystem that provides security equivalent to
+   currently popular public-key mechanisms such as RSA and DSA with
+   smaller key sizes [LENSTRA] [NISTSP80057].
+
+   Currently [PKINIT] permits the use of ECC algorithms but it does not
+   specify how ECC parameters are chosen and how to derive the shared
+   key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
+   [IEEE1363].
+
+   This document describes how to use Elliptic Curve certificates,
+   Elliptic Curve signature schemes, and ECDH with [PKINIT].  However,
+   it should be noted that there is no syntactic or semantic change to
+   the existing [PKINIT] messages.  Both the client and the KDC
+   contribute one ECDH key pair using the key agrement protocol
+   described in this document.
+
+
+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 [RFC2119].
+
+
+3.  Using Elliptic Curve Certificates and Elliptic Curve Signature
+    Schemes
+
+   ECC certificates and signature schemes can be used in the
+   Cryptographic Message Syntax (CMS) [RFC3369] content type
+   'SignedData'.
+
+   X.509 certificates [RFC3280] containing ECC public keys or signed
+   using ECC signature schemes MUST comply with [RFC3279].
+
+   The elliptic curve domain parameters recommended in [X9.62],
+   [FIPS186-2], and [SECG] SHOULD be used.
+
+   The signatureAlgorithm field of the CMS data type SignerInfo can
+   contain one of the following ECC signature algorithm identifiers:
+
+      ecdsa-with-Sha1   [ECCPKALGS]
+      ecdsa-with-Sha256 [ECCPKALGS]
+      ecdsa-with-Sha384 [ECCPKALGS]
+      ecdsa-with-Sha512 [ECCPKALGS]
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 3]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+   The corresponding digestAlgorithm field contains one of the following
+   hash algorithm identifiers respectively:
+
+      id-sha1           [RFC3279]
+      id-sha256         [ECCPKALGS]
+      id-sha384         [ECCPKALGS]
+      id-sha512         [ECCPKALGS]
+
+   Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
+   sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
+   MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
+   MUST be used in conjunction with ecdsa-with-Sha512.
+
+   Implementations of this specfication MUST support ecdsa-with-Sha256
+   and SHOULD support ecdsa-with-Sha1.
+
+
+4.  Using ECDH Key Exchange
+
+   This section describes how ECDH can be used as the AS reply key
+   delivery method [PKINIT].  Note that the protocol description is
+   similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
+   described in [PKINIT].
+
+   If the client wishes to use ECDH key agreement method, it encodes its
+   ECDH public key value and the domain parameters [IEEE1363] for its
+   ECDH public key in clientPublicValue of the PA-PK-AS-REQ message
+   [PKINIT].
+
+   As described in [PKINIT], the ECDH domain parameters for the client's
+   public key are specified in the algorithm field of the type
+   SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
+   is mapped to a subjectPublicKey (a BIT STRING) according to
+   [RFC3279].
+
+   The following algorithm identifier is used to identify the client's
+   choice of the ECDH key agreement method for key delivery.
+
+        id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
+
+   If the domain parameters are not accepted by the KDC, the KDC sends
+   back an error message [RFC4120] with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT].  This error message
+   contains the list of domain parameters acceptable to the KDC.  This
+   list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
+   decreasing preference order.  The client can then pick a set of
+   domain parameters from the list and retry the authentication.
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 4]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+   Both the client and the KDC MUST have local policy that specifies
+   which set of domain parameters are acceptable if they do not have a
+   priori knowledge of the chosen domain parameters.  The need for such
+   local policy is explained in Section 6.
+
+   If the ECDH domain parameters are accepted by the KDC, the KDC sends
+   back its ECDH public key value in the subjectPublicKey field of the
+   PA-PK-AS-REP message [PKINIT].
+
+   As described in [PKINIT], the KDC's ECDH public key value is encoded
+   as a BIT STRING according to [RFC3279].
+
+   Note that in the steps above, the client can indicate to the KDC that
+   it wishes to reuse ECDH keys or to allow the KDC to do so, by
+   including the clientDHNonce field in the request [PKINIT], and the
+   KDC can then reuse the ECDH keys and include serverDHNonce field in
+   the reply [PKINIT].  This logic is the same as that of the Modular
+   Exponential Diffie-Hellman key agreement method [PKINIT].
+
+   If ECDH is negotiated as the key delivery method, both the KDC and
+   the client calculate the shared secret value and derive the reply key
+   as follows:
+
+   1) Let DHSharedSecret be the x-coordinate of the shared secret value
+      (an elliptic curve point).  DHSharedSecret is the output of
+      operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
+
+   2) DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+   3) The DHSharedSecret value derived above is used as input to the
+      octetstring2key() function to derive the AS reply key k, as
+      described in Section 3.2.3.1 of [PKINIT].
+
+   Both the client and KDC then proceed as described in [PKINIT] and
+   [RFC4120].
+
+   Lastly it should be noted that ECDH can be used with any certificates
+   and signature schemes.  However, a significant advantage of using
+   ECDH together with ECC certificates and signature schemes is that the
+   ECC domain parameters in the client or KDC certificates can be used.
+   This obviates the need of locally preconfigured domain parameters as
+   described in Section 6.
+
+
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 5]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+5.  Choosing the Domain Parameters and the Key Size
+
+   The domain parameters and the key size should be chosen so as to
+   provide sufficient cryptographic security [RFC3766].  The following
+   table, based on table 2 on page 63 of NIST SP800-57 part 1
+   [NISTSP80057], gives approximate comparable key sizes for symmetric-
+   and asymmetric-key cryptosystems based on the best-known algorithms
+   for attacking them.
+
+
+                 Symmetric    |  ECC       |   RSA
+                 -------------+----------- +------------
+                    80        |  160 - 223 |   1024
+                   112        |  224 - 255 |   2048
+                   128        |  256 - 383 |   3072
+                   192        |  384 - 511 |   7680
+                   256        |  512+      |  15360
+
+                Table 1: Comparable key sizes (in bits)
+
+   Thus, for example, when securing a 128-bit symmetric key, it is
+   prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
+   P-256 (secp256r1) as described below.
+
+   A set of ECDH domain parameters is also known as a curve.  A curve is
+   a named curve if the domain paratmeters are well known and can be
+   identified by an Object Identifier, otherwise it is called a custom
+   curve.  [PKINIT] supports both named curves and custom curves, see
+   Section 6 on the tradeoff of choosing between named curves and custom
+   curves.
+
+   The named curves recommended in this document are also recommended by
+   NIST [FIPS186-2].  These fifteen ECC curves are given in the
+   following table [FIPS186-2] [SECG].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 6]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+              Description                      SEC 2 OID
+              -----------------                ---------
+
+              ECPRGF192Random  group P-192     secp192r1
+              EC2NGF163Random  group B-163     sect163r2
+              EC2NGF163Koblitz group K-163     sect163k1
+
+              ECPRGF224Random  group P-224     secp224r1
+              EC2NGF233Random  group B-233     sect233r1
+              EC2NGF233Koblitz group K-233     sect233k1
+
+              ECPRGF256Random  group P-256     secp256r1
+              EC2NGF283Random  group B-283     sect283r1
+              EC2NGF283Koblitz group K-283     sect283k1
+
+              ECPRGF384Random  group P-384     secp384r1
+              EC2NGF409Random  group B-409     sect409r1
+              EC2NGF409Koblitz group K-409     sect409k1
+
+              ECPRGF521Random  group P-521     secp521r1
+              EC2NGF571Random  group B-571     sect571r1
+              EC2NGF571Koblitz group K-571     sect571k1
+
+
+6.  Security Considerations
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of ECDH domain parameters.
+
+   Beyond elliptic curve size, the main issue is elliptic curve
+   structure.  As a general principle, it is more conservative to use
+   elliptic curves with as little algebraic structure as possible - thus
+   random curves are more conservative than special curves such as
+   Koblitz curves, and curves over F_p with p random are more
+   conservative than curves over F_p with p of a special form (and
+   curves over F_p with p random might be considered more conservative
+   than curves over F_2^m as there is no choice between multiple fields
+   of similar size for characteristic 2).  Note, however, that algebraic
+   structure can also lead to implementation efficiencies and
+   implementors and users may, therefore, need to balance conservatism
+   against a need for efficiency.  Concrete attacks are known against
+   only very few special classes of curves, such as supersingular
+   curves, and these classes are excluded from the ECC standards such as
+   [IEEE1363] and [X9.62].
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 7]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+   Another issue is the potential for catastrophic failures when a
+   single elliptic curve is widely used.  In this case, an attack on the
+   elliptic curve might result in the compromise of a large number of
+   keys.  Again, this concern may need to be balanced against efficiency
+   and interoperability improvements associated with widely-used curves.
+   Substantial additional information on elliptic curve choice can be
+   found in [IEEE1363], [X9.62] and [FIPS186-2].
+
+
+7.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+
+8.  Acknowledgements
+
+   The following people have made significant contributions to this
+   draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross and Sam
+   Hartman.
+
+
+9.  References
+
+9.1.  Normative References
+
+   [ECCPKALGS]
+              RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-ecc-pkalgs.  Work in Progress.
+
+   [FIPS186-2]
+              NIST, "Digital Signature Standard", FIPS 186-2, 2000.
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key Cryptography",
+              IEEE 1363, 2000.
+
+   [NISTSP80057]
+              NIST, "Recommendation on Key Management", 
+              http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
+              August 2005.
+                            
+   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              cat-kerberos-pk-init.  Work in Progress.
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 8]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3369, August 2002.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+              
+   [X9.62]    ANSI, "Public Key Cryptography For The Financial Services
+              Industry: The Elliptic Curve Digital Signature Algorithm
+              (ECDSA)", ANSI X9.62, 1998.
+
+9.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+
+   [SECG]     SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
+              <http://www.secg.org/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                 [Page 9]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+   Kristin Lauter
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: klauter@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                [Page 10]
+
+Internet-Draft           ECC Support for PKINIT           September 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.              Expires March 17, 2006                [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-01.txt b/third_party/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-01.txt
new file mode 100644
index 00000000000..37863bbd2d5
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-01.txt
@@ -0,0 +1,611 @@
+
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Expires: September 3, 2006                                     K. Lauter
+                                                   Microsoft Corporation
+                                                           March 2, 2006
+
+
+                         ECC Support for PKINIT
+                        draft-zhu-pkinit-ecc-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on September 3, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the use of Elliptic Curve certificates,
+   Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
+   (ECDH) key agreement within the framework of PKINIT - the Kerberos
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 1]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Using Elliptic Curve Certificates and Elliptic Curve
+       Signature Schemes  . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Using ECDH Key Exchange  . . . . . . . . . . . . . . . . . . .  4
+   5.  Choosing the Domain Parameters and the Key Size  . . . . . . .  5
+   6.  Interoperability Requirements  . . . . . . . . . . . . . . . .  7
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     10.1.  Normative References  . . . . . . . . . . . . . . . . . .  8
+     10.2.  Informative References  . . . . . . . . . . . . . . . . .  9
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 2]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+1.  Introduction
+
+   Elliptic Curve Cryptography (ECC) is emerging as an attractive
+   public-key cryptosystem that provides security equivalent to
+   currently popular public-key mechanisms such as RSA and DSA with
+   smaller key sizes [LENSTRA] [NISTSP80057].
+
+   Currently [PKINIT] permits the use of ECC algorithms but it does not
+   specify how ECC parameters are chosen and how to derive the shared
+   key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
+   [IEEE1363] [X9.63].
+
+   This document describes how to use Elliptic Curve certificates,
+   Elliptic Curve signature schemes, and ECDH with [PKINIT].  However,
+   it should be noted that there is no syntactic or semantic change to
+   the existing [PKINIT] messages.  Both the client and the KDC
+   contribute one ECDH key pair using the key agrement protocol
+   described in this document.
+
+
+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 [RFC2119].
+
+
+3.  Using Elliptic Curve Certificates and Elliptic Curve Signature
+    Schemes
+
+   ECC certificates and signature schemes can be used in the
+   Cryptographic Message Syntax (CMS) [RFC3369] content type
+   'SignedData'.
+
+   X.509 certificates [RFC3280] containing ECC public keys or signed
+   using ECC signature schemes MUST comply with [RFC3279].
+
+   The elliptic curve domain parameters recommended in [X9.62],
+   [FIPS186-2], and [SECG] SHOULD be used.
+
+   The signatureAlgorithm field of the CMS data type SignerInfo can
+   contain one of the following ECC signature algorithm identifiers:
+
+      ecdsa-with-Sha1   [ECCPKALGS]
+      ecdsa-with-Sha256 [ECCPKALGS]
+      ecdsa-with-Sha384 [ECCPKALGS]
+      ecdsa-with-Sha512 [ECCPKALGS]
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 3]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+   The corresponding digestAlgorithm field contains one of the following
+   hash algorithm identifiers respectively:
+
+      id-sha1           [RFC3279]
+      id-sha256         [ECCPKALGS]
+      id-sha384         [ECCPKALGS]
+      id-sha512         [ECCPKALGS]
+
+   Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
+   sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
+   MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
+   MUST be used in conjunction with ecdsa-with-Sha512.
+
+   Implementations of this specfication MUST support ecdsa-with-Sha256
+   and SHOULD support ecdsa-with-Sha1.
+
+
+4.  Using ECDH Key Exchange
+
+   This section describes how ECDH can be used as the AS reply key
+   delivery method [PKINIT].  Note that the protocol description here is
+   similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
+   described in [PKINIT].
+
+   If the client wishes to use ECDH key agreement method, it encodes its
+   ECDH public key value and the domain parameters [IEEE1363] [X9.63]
+   for its ECDH public key in clientPublicValue of the PA-PK-AS-REQ
+   message [PKINIT].
+
+   As described in [PKINIT], the ECDH domain parameters for the client's
+   public key are specified in the algorithm field of the type
+   SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
+   is mapped to a subjectPublicKey (a BIT STRING) according to
+   [RFC3279].
+
+   The following algorithm identifier is used to identify the client's
+   choice of the ECDH key agreement method for key delivery.
+
+        id-ecPublicKey (Elliptic Curve Diffie-Hellman [ECCPKALGS])
+
+   If the domain parameters are not accepted by the KDC, the KDC sends
+   back an error message [RFC4120] with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT].  This error message
+   contains the list of domain parameters acceptable to the KDC.  This
+   list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
+   decreasing preference order.  The client can then pick a set of
+   domain parameters from the list and retry the authentication.
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 4]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+   Both the client and the KDC MUST have local policy that specifies
+   which set of domain parameters are acceptable if they do not have a
+   priori knowledge of the chosen domain parameters.  The need for such
+   local policy is explained in Section 7.
+
+   If the ECDH domain parameters are accepted by the KDC, the KDC sends
+   back its ECDH public key value in the subjectPublicKey field of the
+   PA-PK-AS-REP message [PKINIT].
+
+   As described in [PKINIT], the KDC's ECDH public key value is encoded
+   as a BIT STRING according to [RFC3279].
+
+   Note that in the steps above, the client can indicate to the KDC that
+   it wishes to reuse ECDH keys or to allow the KDC to do so, by
+   including the clientDHNonce field in the request [PKINIT], and the
+   KDC can then reuse the ECDH keys and include serverDHNonce field in
+   the reply [PKINIT].  This logic is the same as that of the Modular
+   Exponential Diffie-Hellman key agreement method [PKINIT].
+
+   If ECDH is negotiated as the key delivery method, then the PA-PK-AS-
+   REP and AS reply key are generated as in Section 3.2.3.1 of [PKINIT]
+   with the following difference: The DHSharedSecret is the x-coordinate
+   of the shared secret value (an elliptic curve point); DHSharedSecret
+   is the output of operation ECSVDP-DH as described in Section 7.2.1 of
+   [IEEE1363].
+
+   Both the client and KDC then proceed as described in [PKINIT] and
+   [RFC4120].
+
+   Lastly it should be noted that ECDH can be used with any certificates
+   and signature schemes.  However, a significant advantage of using
+   ECDH together with ECC certificates and signature schemes is that the
+   ECC domain parameters in the client or KDC certificates can be used.
+   This obviates the need of locally preconfigured domain parameters as
+   described in Section 7.
+
+
+5.  Choosing the Domain Parameters and the Key Size
+
+   The domain parameters and the key size should be chosen so as to
+   provide sufficient cryptographic security [RFC3766].  The following
+   table, based on table 2 on page 63 of NIST SP800-57 part 1
+   [NISTSP80057], gives approximate comparable key sizes for symmetric-
+   and asymmetric-key cryptosystems based on the best-known algorithms
+   for attacking them.
+
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 5]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+                 Symmetric    |  ECC       |   RSA
+                 -------------+----------- +------------
+                    80        |  160 - 223 |   1024
+                   112        |  224 - 255 |   2048
+                   128        |  256 - 383 |   3072
+                   192        |  384 - 511 |   7680
+                   256        |  512+      |  15360
+
+                Table 1: Comparable key sizes (in bits)
+
+   Thus, for example, when securing a 128-bit symmetric key, it is
+   prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
+   P-256 (secp256r1) as described below.
+
+   A set of ECDH domain parameters is also known as a curve.  A curve is
+   a named curve if the domain paratmeters are well known and can be
+   identified by an Object Identifier, otherwise it is called a custom
+   curve.  [PKINIT] supports both named curves and custom curves, see
+   Section 7 on the tradeoff of choosing between named curves and custom
+   curves.
+
+   The named curves recommended in this document are also recommended by
+   NIST [FIPS186-2].  These fifteen ECC curves are given in the
+   following table [FIPS186-2] [SECG].
+
+              Description                      SEC 2 OID
+              -----------------                ---------
+
+              ECPRGF192Random  group P-192     secp192r1
+              EC2NGF163Random  group B-163     sect163r2
+              EC2NGF163Koblitz group K-163     sect163k1
+
+              ECPRGF224Random  group P-224     secp224r1
+              EC2NGF233Random  group B-233     sect233r1
+              EC2NGF233Koblitz group K-233     sect233k1
+
+              ECPRGF256Random  group P-256     secp256r1
+              EC2NGF283Random  group B-283     sect283r1
+              EC2NGF283Koblitz group K-283     sect283k1
+
+              ECPRGF384Random  group P-384     secp384r1
+              EC2NGF409Random  group B-409     sect409r1
+              EC2NGF409Koblitz group K-409     sect409k1
+
+              ECPRGF521Random  group P-521     secp521r1
+              EC2NGF571Random  group B-571     sect571r1
+              EC2NGF571Koblitz group K-571     sect571k1
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 6]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+6.  Interoperability Requirements
+
+   Implementations conforming to this specification MUST support curve
+   P-256 and P-384.
+
+
+7.  Security Considerations
+
+   Kerberos error messages are not integrity protected, as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of ECDH domain parameters.
+
+   Beyond elliptic curve size, the main issue is elliptic curve
+   structure.  As a general principle, it is more conservative to use
+   elliptic curves with as little algebraic structure as possible - thus
+   random curves are more conservative than special curves such as
+   Koblitz curves, and curves over F_p with p random are more
+   conservative than curves over F_p with p of a special form (and
+   curves over F_p with p random might be considered more conservative
+   than curves over F_2^m as there is no choice between multiple fields
+   of similar size for characteristic 2).  Note, however, that algebraic
+   structure can also lead to implementation efficiencies and
+   implementors and users may, therefore, need to balance conservatism
+   against a need for efficiency.  Concrete attacks are known against
+   only very few special classes of curves, such as supersingular
+   curves, and these classes are excluded from the ECC standards such as
+   [IEEE1363] and [X9.62].
+
+   Another issue is the potential for catastrophic failures when a
+   single elliptic curve is widely used.  In this case, an attack on the
+   elliptic curve might result in the compromise of a large number of
+   keys.  Again, this concern may need to be balanced against efficiency
+   and interoperability improvements associated with widely-used curves.
+   Substantial additional information on elliptic curve choice can be
+   found in [IEEE1363], [X9.62] and [FIPS186-2].
+
+
+8.  IANA Considerations
+
+   No IANA actions are required for this document.
+
+
+9.  Acknowledgements
+
+   The following people have made significant contributions to this
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 7]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+   draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross, Sam Hartman,
+   Tolga Acar, and Stefan Santesson.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [ECCPKALGS]
+              RFC-Editor: To be replaced by RFC number for draft-ietf-
+              pkix-ecc-pkalgs.  Work in Progress.
+
+   [FIPS186-2]
+              NIST, "Digital Signature Standard", FIPS 186-2, 2000.
+
+   [IEEE1363]
+              IEEE, "Standard Specifications for Public Key Cryptography",
+              IEEE 1363, 2000.
+
+   [NISTSP80057]
+              NIST, "Recommendation on Key Management", 
+              http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
+              August 2005.
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 8]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+
+   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
+              cat-kerberos-pk-init.  Work in Progress.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)",
+              RFC 3369, August 2002.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [X9.62]    ANSI, "Public Key Cryptography For The Financial Services
+              Industry: The Elliptic Curve Digital Signature Algorithm
+              (ECDSA)", ANSI X9.62, 1998.
+  
+   [X9.63]    ANSI, "Public Key Cryptography for the Financial Services 
+              Industry: Key Agreement and Key Transport using Elliptic 
+              Curve Cryptography", ANSI X9.63, 2001.
+              
+
+9.2.  Informative References
+
+   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
+              Sizes", Journal of Cryptology 14 (2001) 255-293.
+
+   [SECG]     SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
+              <http://www.secg.org/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2006               [Page 9]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: karthikj@microsoft.com
+
+
+   Kristin Lauter
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: klauter@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.             Expires September 3, 2006              [Page 10]
+
+Internet-Draft           ECC Support for PKINIT               March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Zhu, et al.             Expires September 3, 2006              [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-pku2u-00.txt b/third_party/heimdal/doc/standardisation/draft-zhu-pku2u-00.txt
new file mode 100644
index 00000000000..09030bcdeec
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-pku2u-00.txt
@@ -0,0 +1,395 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                              A. Medvinsky
+Updates: 4120 (if approved)                        Microsoft Corporation
+Intended status: Standards Track                               J. Altman
+Expires: May 11, 2007                                  Secure End Points
+                                                        November 7, 2006
+
+
+  Public Key Cryptography based User to User Authentication - (PKU2U)
+                           draft-zhu-pku2u-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on May 11, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines the Public Key Cryptography based User to User
+   authentication protocol - PKU2U. PKU2U is based on RFC4456 and
+   RFC4120.  This enables peer to peer authentication using Kerberos
+   messages without requiring an online trusted third party.  In
+   addition, the binding of PKU2U for the Generic Security Service
+   Application Program Interface (GSS-API) per RFC2743 is defined based
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 1]
+
+Internet-Draft                    PKU2U                    November 2006
+
+
+   on RFC4121.
+
+
+Table of Contents
+
+   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2  Conventions Used in This Document  . . . . . . . . . . . . . . . 3
+   3  Protocol description . . . . . . . . . . . . . . . . . . . . . . 3
+   4  Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
+   5  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
+   6  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
+   7  Normative References . . . . . . . . . . . . . . . . . . . . . . 5
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 2]
+
+Internet-Draft                    PKU2U                    November 2006
+
+
+1  Introduction
+
+   Peer-to-peer systems are increasingly popular today.  In a peer-to-
+   peer system, all clients provide resources that contribute positively
+   to the total capacity of the overall system and there is no single
+   point of failure.  This distributed nature makes the system highly
+   scalable and robust.  In addition, the peer-to-peer system is self-
+   organized.  These enable services that just work.
+
+   In a peer-to-peer system, if the initiator can authenticate the
+   acceptor and then establish trust in the information received from
+   the peer, many attacks such as poisoning (e.g. providing data
+   contents are different from the description) and polluting (e.g.
+   inserting "bad" chunks/packets) can be mitigated or eliminated.
+   However, currently there is no interoperable GSS-API mechanism for
+   use in these environments.
+
+   The PKU2U protocol defined in this document extends PKINIT to support
+   peer-to-peer authentications without the use of Key Distribution
+   Center (KDC) [RFC4120].  Thus it enables peer to peer authentication
+   based on public key cryptography.  In addition, this document defines
+   the binding for GSS-API based on [RFC4121] and [WS-KERB], which makes
+   PKU2U readily available to the widely deployed GSS-API applications.
+
+
+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 [RFC2119].
+
+
+3  Protocol description
+
+   The PKU2U realm name is a reserved name that is defined according to
+   [KRB-NAME].  It has the value of "RESERVED:PKU2U".
+
+   PKU2U replaces the KDC in [RFC4556] with the identity of the
+   acceptor, and it updates the protocol with the following changes:
+
+   All the realm names in Kerberos messages are filled with the PKU2U
+   reserved realm.
+
+   The client name in AS-REQ [RFC4120] contains the name of the
+   initiator, and the server name contains the Kerberos name of the
+   acceptor.
+
+   The initiator signs the pre-authentication data as needed per
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 3]
+
+Internet-Draft                    PKU2U                    November 2006
+
+
+   [RFC4120] and constructs an AS-REQ, and then sends the request to the
+   acceptor using the same GSS-API encapsulation defined in [WS-KERB],
+   except the mechanism Objection Identifier (OID) for PKU2U is id-
+   kerberos-pku2u.
+
+      id-kerberos-pku2u ::=
+        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
+          pku2u(7) }
+
+   The client fills out the realm field in the ProxyData [WS-KERB] using
+   the reserved PKU2U realm.  Upon receipt of the WS_KRB_PROXY message,
+   the GSS-API acceptor processes the Kerberos message (an AS-REQ) that
+   follows the WS_KRB_PROXY header.
+
+   The acceptor validates the pre-authentication data in the request per
+   Section 3.2.2 of [RFC4556] and it MUST verify the binding between the
+   client name and the client's signing key, if the pre-authentication
+   data in the request is signed.  The client's X.509 certificate, if
+   present, MUST contain id-pkinit-KPClientAuth [RFC4556] or id-kp-
+   clientAuth [RFC3280].  If the client is authenticated as expected,
+   the acceptor issues a service ticket to the initiator per [RFC4120].
+
+   Upon receipt of the reply, the initiator validates the pre-
+   authentication data in the reply per Section 3.2.4 of [RFC4556].  As
+   stated earlier, there is no KDC in PKU2U, thus the requirement of the
+   id-pkinit-KPKdc is not applicable when PKU2U is used.  The initiator
+   MUST verify the binding between the signing key in the reply and the
+   acceptor.  When the GSS-API acceptor is identified using the
+   targ_name parameter of the GSS_Init_sec_context() call, the signing
+   key MUST be bound with the targ_name.  The acceptor's X.509
+   certificate MUST contain id-kp-clientAuth [RFC3280] or id-kp-
+   serverAuth [RFC3280] or id-pkinit-KPClientAuth [RFC4556].
+
+   The Kerberos principal name form and the host-based service Name
+   described in [RFC1964] MUST be supported by conforming
+   implementations of this specification.
+
+   Once the AS-REP in the reply is accepted, the initiator can use the
+   obtained service to construct an AP-REQ and communicate with the
+   acceptor.  The rest of the protocol and the GSS-API binding are the
+   same as defined in [WS-KERB] and [RFC4121].
+
+
+4  Security Considerations
+
+   The security considerations in [RFC4556] apply here.  In addition,
+   the initiator and the acceptor MUST be able to verify the binding
+   between the signing key and the associated identity.
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 4]
+
+Internet-Draft                    PKU2U                    November 2006
+
+
+5  Acknowledgements
+
+   The authors would like thanks Jeffery Hutzelman for his comments with
+   regarding to unifying [WS-KERB] with PKU2U .
+
+
+6  IANA Considerations
+
+   Section 3 defines the PKU2U realm.  The IANA registry for the
+   reserved names should be updated to reference this document.
+
+
+7.  Normative References
+
+   [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints", 
+              draft-ietf-krb-wg-naming, work in progress.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 5]
+
+Internet-Draft                    PKU2U                    November 2006
+
+
+   [WS-KERB] L. Zhu, "Kerberos for Web Services", draft-zhu-ws-kerb, work
+             in progress.
+             
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+   Ari Medvinsky
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: arimed@microsoft.com
+
+
+   Jeffery
+   Secure End Points
+   612 West 115th Street Room 716
+   New York, NY  10025
+   US
+
+   Email: jaltman@secureendpoint.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 6]
+
+Internet-Draft                    PKU2U                    November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu, et al.               Expires May 11, 2007                  [Page 7]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-pku2u-09.txt b/third_party/heimdal/doc/standardisation/draft-zhu-pku2u-09.txt
new file mode 100644
index 00000000000..e6d1b75e7d1
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-pku2u-09.txt
@@ -0,0 +1,1288 @@
+

+

+NETWORK WORKING GROUP                                             L. Zhu

+Internet-Draft                                     Microsoft Corporation

+Intended status: Standards Track                               J. Altman

+Expires: May 7, 2009                                    Secure Endpoints

+                                                             N. Williams

+                                                                     Sun

+                                                        November 3, 2008

+

+

+  Public Key Cryptography Based User-to-User Authentication - (PKU2U)

+                           draft-zhu-pku2u-09

+

+Status of this Memo

+

+   By submitting this Internet-Draft, each author represents that any

+   applicable patent or other IPR claims of which he or she is aware

+   have been or will be disclosed, and any of which he or she becomes

+   aware will be disclosed, in accordance with Section 6 of BCP 79.

+

+   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 Internet-Draft will expire on May 7, 2009.

+

+Abstract

+

+   This document defines a Generic Security Services Application Program

+   Interface (GSS-API) mechanism based on Public Key Infrastructure

+   (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the

+   Kerberos V GSS-API mechanism, but without requiring a Kerberos Key

+   Distribution Center (KDC).

+

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 1]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+Table of Contents

+

+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3

+   3.  The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . .  3

+   4.  The NULL Principal Name  . . . . . . . . . . . . . . . . . . .  4

+   5.  PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . .  4

+     5.1.  GSS_C_NT_DN  . . . . . . . . . . . . . . . . . . . . . . .  6

+     5.2.  GSS_C_NT_HOSTNAME  . . . . . . . . . . . . . . . . . . . .  6

+     5.3.  GSS_C_NT_EMAIL_ADDR  . . . . . . . . . . . . . . . . . . .  7

+     5.4.  GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . .  7

+     5.5.  GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . .  9

+     5.6.  GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based

+           Principal Names to Acceptor Certificates . . . . . . . . .  9

+   6.  The Protocol Description and the Context Establishment

+       Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

+     6.1.  Context Token Derived from KRB_AS_REQ  . . . . . . . . . . 12

+     6.2.  Context Token Derived from KRB_AS_REP  . . . . . . . . . . 15

+     6.3.  Context Tokens Imported from RFC4121 . . . . . . . . . . . 16

+   7.  Guidelines for Credentials Selection . . . . . . . . . . . . . 17

+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18

+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19

+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

+   11. Normative References . . . . . . . . . . . . . . . . . . . . . 19

+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

+   Intellectual Property and Copyright Statements . . . . . . . . . . 23

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 2]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+1.  Introduction

+

+   The Generic Security Services Application Programming Interface (GSS-

+   API) is a generic protocol and API for providing authentication and

+   session protection to applications.  It is generic in that it

+   supports multiple authentication mechanisms.  Today there exists only

+   one workable, widely deployed, standards-track GSS-API mechanism: the

+   Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on

+   Kerberos V [RFC4120].  There is a need to provide a GSS-API mechanism

+   which does not require Kerberos V Key Distribution Center (KDC)

+   infrastructure, and which supports the use of public key

+   cryptography, particularly Public Key Infrastructure (PKI) [RFC5280],

+   including the use of public key certificates without a PKI.

+

+   This document specifies such a mechanism: the Public Key User to User

+   mechanism (PKU2U).

+

+   PKU2U is based on building blocks taken from Kerberos V [RFC4120],

+   PKINIT, [RFC4556] (which in turn uses PKI [RFC5280]) building

+   blocks), and the Kerberos V GSS-API mechanism [RFC1964] [RFC4121].

+   In spite of using Kerberos V building blocks, PKU2U does not require

+   any Kerberos V KDC infrastructure.  And though PKU2U also uses PKI

+   building blocks, PKU2U can be used without a PKI by pre-sharing

+   certificates and/or pre-associating name/certificate bindings.

+

+   Therefore PKU2U can be used for true peer-to-peer authentication, as

+   well as for PKI-based authentication.

+

+

+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 [RFC2119].

+

+   In this document, the GSS-API initiator or acceptor is referred to as

+   the peer when the description is applicable to both the initiator and

+   the acceptor.

+

+

+3.  The PKU2U Realm Name

+

+   The PKU2U realm name is defined as a reserved Kerberos realm name per

+   [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U".

+

+   The PKU2U realm name has no meaning, but is intended to be used in

+   the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U

+   wherever realm names are needed.  Unless otherwise specified, the

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 3]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   realm name in any Kerberos message used by PKU2U is the PKU2U realm

+   name.

+

+

+4.  The NULL Principal Name

+

+   The NULL Kerberos principal name is defined as a well-known Kerberos

+   principal name based on [KRB-NAMING].  The value of the name-type

+   field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name-

+   string field is a sequence of two KerberosString components:

+   "WELLKNOWN", "NULL".

+

+   The NULL Kerberos principal name is used in the Kerberos messages

+   where there is no Kerberos representation of the principal name, for

+   example, when the client name is a Distinguished Name.  When the NULL

+   principal name is used in the Kerberos messages, the principal name

+   is either not used or provided separately (for example in the

+   PA_PKU2U_NAME padata defined in Section 6.1).

+

+

+5.  PKU2U Principal Naming

+

+   The GSS-API targ_name supplied for the initiator MUST NOT be

+   GSS_C_NO_NAME in PKU2U.

+

+   PKU2U principal names can be Kerberos principal names, and they can

+   also be distiguished names, or subject alternative names [RFC5280] as

+   they appear in the certificate of any PKU2U peer, as well as any

+   names agreed to out of band that do not appear in the peer

+   certificates.

+

+   Certificates may be associated with multiple principal names.  This

+   presents problems for the GSS-API bindings of a PKI-based mechanism

+   because, for example, for any given, established GSS-API security

+   mechanism there can be only one initiator name, and one acceptor

+   name, and credential handles may be associated with only one name.

+   We resolve these problems as follows:

+

+   o  We define multiple GSS-API name types corresponding to several

+      GeneralName choices [RFC5280], along with syntaxes, display forms,

+      and exported name token formats for each.  For most of the name-

+      types listed below the exported name token formats consists of a

+      GeneralName with the usual exported name token header as per-

+      RFC2743.  Two name-types are shared with the Kerberos V mechanism

+      and use the Kerberos V mechanism's query and display syntaxes,

+      canonicalization rules, and exported name token format.

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 4]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   o  The cred_name of a credential handle acquired with

+      GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished

+      Name (DN) of the certificate underlying the credential.  If there

+      are multiple certificates and private keys, then either one MUST

+      be selected by local, implementation-specific means, or credential

+      acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may

+      choose which of these two behaviors to provide).

+

+   o  When using desired_name values other than GSS_C_NT_NO_NAME for

+      credential handle acquisition then the implementation MUST use

+      exact matching of the given desired_name to a certificate's DN or

+      Subject Alternative Names (SANs) for all name-types given below,

+      except for GSS_C_NT_DN, where matching rules are fuzzier and given

+      below.  The names of a X.509 certificate will be compared to the

+      given desired_name in this order: certificate DN first, then SANs

+      in the order in which they appear in the certificate.  When

+      multiple certificates and private keys are available the order in

+      which the various certificates are searched is significant; no

+      canonical certificate collation order is defined herein.

+

+   o  The cred_name of a credential object acquired with a desired_name

+      other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or

+      SAN matched by the given desired_name.

+

+   o  We provide a method (see below) by which initiators can assert, in

+      their context tokens, one of these names of the initiator.  We

+      also provide a method of asserting names that do not appear in a

+      X.509 certificate, in which case the binding of X.509 certificate

+      to the asserted name is done out-of band.  The name to be

+      asserted, of course, is the cred_name of the cred_handle passed to

+      GSS_Init_sec_context().

+

+   o  The initiator's context tokens may also indicate what is the

+      expected name of the acceptor -- the targ_name passed in to

+      GSS_Init_sec_context().

+

+   o  No attempt is made to map Kerberos V realm names to trust anchor

+      certificate authority (CA) names.

+

+   o  We provide a method of matching host-based service principal names

+      to acceptor certificates, so that: a) initiators need not know the

+      particulars of an acceptor's certificates' names a priori, b)

+      acceptors can select a credential to accept a security context

+      with that the initiator will accept, c) existing certificates for

+      web servers, may be used as host-based service principal names as

+      though the service name were "HTTP".

+

+   Thus GSS-API initiator applications that use the GSS_C_NO_NAME as the

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 5]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   desired_name arguments of GSS_Acquire_cred() and GSS_Add_cred(), or

+   GSS_C_NO_CREDENTIAL as the cred argument of GSS_Init_sec_context()

+   will assert the selected X.509 certificate's subject DN, and that

+   X.509 certificate's subject DN will be the name returned by

+   GSS_Inquire_cred() and GSS_Inquire_cred_by_mech().

+

+   And portable GSS-API initiator applications using

+   GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing

+   a name to use as the targ_name input argument of

+   GSS_Init_sec_context()) will have a reasonable chance of success in

+   authenticating peers with X.509 certificates predating this

+   specification.

+

+5.1.  GSS_C_NT_DN

+

+   The name type GSS_C_NT_DN, with Object Identifier (OID) <TBD> (see

+   Section 10), is defined.  This corresponds to the 'directoryName'

+   choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1)

+   [CCITT.X680.2002] type defined in [RFC5280].

+

+   The query syntax and display form for names of this type SHALL be as

+   described in [RFC4514].

+

+   As RFC4514 says, "[c]omparison of DNs for equality is to be performed

+   in accordance with the distinguishedNameMatch matching rule

+   [RFC4517]".

+

+   There is no reasonable way to canonicalize names of this type without

+   providing certificates to match query forms of GSS_C_NT_DN against,

+   such as in the form of a directory.  Therefore

+   GSS_Canonicalize_name() as applied to names imported with the

+   GSS_C_NT_DN name-type MUST search available certificate databases, or

+   directories, or MUST fail.  No method of locating and searching

+   directories for matching certificate DNs is specified herein.  Note

+   though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context()

+   can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]).

+

+   The exported name token format for names of this type SHALL be the

+   Distinguished Encoding Rules (DER) [CCITT.X680.2002]

+   [CCITT.X690.2002] encoding of a GeneralName with directoryName as the

+   choice.

+

+   Implementation support for this name type is REQUIRED.

+

+5.2.  GSS_C_NT_HOSTNAME

+

+   The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is defined.  This

+   corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 6]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   defined in [RFC5280].

+

+   The query syntax for names of this type SHALL be a DNS name [RFC1034]

+   in either ACE or Unicode form [RFC3490].

+

+   The display and canonical form of names of this type SHALL be a DNS

+   domain name in ACE form, with character case folded down.

+   Canonicalization consists merely of applying the ToASCII() function

+   and case-folding the result.

+

+   The exported name token format for names of this type SHALL be the

+   DER encoding of a GeneralName with dNSName as the choice and the DNS

+   domain name in ACE form and case folded down.

+

+   Implementation support for this name type is OPTIONAL.

+

+5.3.  GSS_C_NT_EMAIL_ADDR

+

+   The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>, is defined.  This

+   corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1

+   type defined in [RFC5280].

+

+   The query syntax and display form for names of this type SHALL be the

+   text representation of an 'addr-spec' as defined in [RFC0822].

+

+   The canonical form of names of this type SHALL be the query form with

+   case folded down.  Note that the domain name part of an addr-spec is

+   a "domain name slot" and so the canonicalization rules for

+   GSS_C_NT_HOSTNAME given above apply here as well.

+

+   The exported name token form for this name type SHALL be the DER-

+   encoding of a GeneralName with the rfc822Name choice.

+

+   Implementation support for this name type is OPTIONAL.

+

+5.4.  GSS_KRB5_NT_PRINCIPAL_NAME

+

+   PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964].

+

+   The query, display, canonical and exported name token forms of names

+   of this type SHALL be as specified in RFC4121.  The realm name part

+   of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax;

+   when canonicalized, names of this type lacking a realm name will have

+   the well-known PKU2U realm name affixed.

+

+   When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted

+   or otherwise is the well-known PKU2U realm name, then the "cname"' or

+   sname fields of the Kerberos V PDUs used to construct PKU2U security

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 7]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   context tokens MUST be set to the principal name part of the given

+   NAME.  Otherwise the PA_PKU2U_NAME pre-authentication data MUST be

+   used to indicate a name of id-pkinit-san type [RFC4556] corresponding

+   to the given NAME.  See Section 5.4.

+

+   No attempt is made to map Kerberos V realm names to trust anchor

+   certificate authority (CA) names.

+

+   Note that having more than one mechanism share name-types has

+   implications for multi-mechanism, pluggable GSS-API implementations

+   (commonly referred to as "mechglue").  Specifically:

+

+   o  It must be the responsibility of the mechanism, not of the

+      mechglue, to ensure that the standard exported name token header

+      (which includes a mechanism OID), is included in exported name

+      tokens.  The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME

+      MN produced by PKU2U would have PKU2U's mechanism OID in the

+      header.

+

+   o  A pluggable mechglue must be able to find a mechanism that can

+      import an exported name token if an available mechanism can

+      produce that exported name token.  For example, a pluggable

+      mechglue where PKU2U is available but where the Kerberos V

+      mechanism [RFC1964] is not should still be able to import exported

+      Kerberos V name tokens since PKU2U can create such tokens.  One

+      way to do this would be for the mechglue to try the mechanism

+      named in the exported name token header, if it is available, else

+      try all other available mechanisms until one succeeds or all fail.

+      It would be reasonable for a mechglue implementer to require that

+      the Kerberos V mechanism be available if PKU2U is too.

+

+   o  It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use

+      a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name

+      argument value to acquire a PKU2U credential.  Similarly, it must

+      be possible to use a Kerberos V MN as the target_name in a call to

+      GSS_Init_sec_context with PKU2U as the mech OID.  A multi-

+      mechanism mechglue implementer would likely have a mechglue-layer

+      NAME object that internally keeps a reference to a NAME object

+      produced by the underlying mechanism, but a pluggable mechglue

+      could not expect two different mechanisms to be able to share

+      their internal NAME objects.  A clever implementer can work around

+      this by exporting the one mechanism's MN and then re-importing

+      using the target mechanism's GSS_Import_name() service function.

+

+   o  It must be possible for the credential inquiry functions (e.g.,

+      GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a

+      cred_name that is an MN of a different mechanism than the

+      credential element being inquired.

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 8]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   Implementation support for this name type, with defaulted realm name

+   or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use

+   with any other realm names.

+

+5.5.  GSS_C_NT_ANONYMOUS

+

+   This is a generic GSS-API name-type.  Implementation support for this

+   name type is OPTIONAL.  See Section 6.1 for more information.

+

+   See [RFC2743] and [RFC2744] for more information about this name

+   type.

+

+   The PKU2U mechanism only supports anonymous initiators, not

+   acceptors.

+

+   Implementation support for this name type is RECOMMENDED.

+

+5.6.  GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based Principal Names

+      to Acceptor Certificates

+

+   Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described

+   herein.

+

+   The query form of this name type is as per-RFC2743.  The canonical

+   and exported name token forms are as per-RFC1964.  The display form

+   of this name type is left unspecified, but should either be as per-

+   RFC2743 or the same as the display form for

+   GSS_KRB5_NT_PRINCIPAL_NAME [RFC1964].

+

+   Initiators using names of type GSS_C_NT_HOSTBASED_SERVICE to identify

+   target acceptors represent these names as Kerberos V principal names

+   as per [RFC1964] but with a well-known realm name of "WELLKNOWN:

+   PKU2U" (see Section 5.4).

+

+   Acceptors match such names to acceptor certificates as follows.

+   Initiators then match the certificate chosen by the acceptor in the

+   same manner.

+

+   Initiators can also assert host-based service names as the initiator

+   name.  In this case acceptors MUST also apply the matching rules

+   below, in order, to validate the initiator's assertion.

+

+   1.  If there is an out-of-band binding of the peer's host-based

+       service name to its certificate, then the certificate matches.

+

+   2.  If the peer has a certificate with an id-pkinit-san subject

+       alternative name matching the initiator-provided acceptor name,

+       then the X.509 certificate matches.

+

+

+

+Zhu, et al.                Expires May 7, 2009                  [Page 9]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   3.  If a X.509 certificate has a dNSName SAN that matches the

+       hostname part of the host-based service principal name, and

+       either the anyExtendedKeyUsage extended key usage (EKU), or no

+       EKU is present, or an EKU is present which corresponds to the

+       service part of the host-based service principal name, then the

+       X.509 certificate matches.  The id-kp-serverAuth EKU SHALL be

+       considered to match the 'HTTP' service name.  (See Section 10,

+       IANA considerations, where the GSS-API service name registry is

+       extended to include an EKU for each service name.)

+

+   4.  Implementations SHOULD, subject to local configuration, allow

+       matches where the single-component cn of the DN of a X.509

+       certificate matches the hostname part of the host-based service

+       name, for some or all service names.  This feature is needed to

+       allow the use of existing X.509 web certificates.

+

+   Implementation support for this name type as an acceptor name is

+   REQUIRED.  Implementation support for this name type as an initiator

+   name is OPTIONAL.

+

+

+6.  The Protocol Description and the Context Establishment Tokens

+

+   The PKU2U mechanism is a GSS-API mechanism based on [RFC4120],

+   [RFC4556] and [RFC4121].

+

+   The per-message tokens of the PKU2U mechanism are the same as those

+   of the Kerberos V GSS-API mechanism [RFC4121].

+

+   The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same

+   as that of the Kerberos V GSS-API mechanism [RFC4402].

+

+   The PKU2U security context token exchange consists of KRB_AS_REQ and

+   KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to

+   their ASN.1 description, but with other minor changes/requirements

+   described below) as context tokens, with the acceptor as the KDC,

+   followed by context tokens from [RFC4121] using the Kerberos V Ticket

+   PDU issued by the acceptor-as-KDC.  PKINIT [RFC4556] is the only

+   acceptable pre-authentication method in this document.  Caching the

+   ticket issued by the acceptor allows subsequent security context

+   exchanges between the same to peers to use a single context token

+   round-trip -- a "fast reconnect" feature.

+

+   PKU2U differs from Kerberos V with PKINIT in several minor ways as

+   follows (this is not a complete list):

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 10]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   o  KDC PDUs are not exchanged as usual in Kerberos, but wrapped as

+      [the first two] GSS-API context tokens.

+

+   o  PKU2U does not use KDC certificates.

+

+   o  PKU2U adds pa-data types for carrying the initiator's assertion of

+      its name and the targ_name passed to GSS_Init_sec_context().

+

+   PKU2U differs from the Kerberos V GSS-API mechanism in several ways:

+

+   o  KDC PDUs are not exchanged as described in [RFC4120], but wrapped

+      as GSS-API context tokens.

+

+   o  PKU2U allows the use of principal names matching PKI naming (see

+      Section 5).  PKU2U does support the use of Kerberos V naming, but

+      requires only support of Kerberos V naming to a limited extent

+      (full support is optional).

+

+   o  PKU2U adds an extension [GSS-EXTS] to the RFC4121 initial context

+      token for binding the AP-REQ to the AS exchange that precedes is

+      (that is, when the initiator has to request a ticket from the

+      acceptor).

+

+   o  The number of round-trips can vary.  If the initiator already has

+      a ticket for the acceptor then the context token exchange will be

+      half a round-trip or one round-trip, as per RFC4121.  Otherwise

+      one or two round-trips are added for the AS exchanges needed to

+      acquire a ticket.  Note that two AS exchanges may be required when

+      the initiator's initial choice of X.509 certificate does not match

+      the acceptor's trust anchors, in which case the acceptor SHOULD

+      reply with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what

+      the acceptor's trust anchors are, and then the initiator can

+      engage in a second AS exchange within the same GSS-API context.

+

+   To recapitulate, the acceptor and the initiator communicate by

+   tunneling the authentication service exchange messages through the

+   use of the GSS-API tokens and application traffic.  In the event of

+   security context token loss, message duplication, or out of order

+   message delivery, the security context MUST fail to establish.

+

+   All security context establishment tokens MUST follow the

+   InitialContextToken syntax defined in Section 3.1 of [RFC2743].

+   PKU2U is identified by the Objection Identifier (OID) id-kerberos-

+   pku2u.

+

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 11]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   The PKU2U OID is:

+

+   id-kerberos-pku2u ::=

+   { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)

+   pku2u(7) }

+

+   All context establishment tokens consist of some Kerberos V PDU or

+   another, prefixed with a two-octet token type ID, and the

+   InitialContextToken header (see above).

+

+   The innerToken described in section 3.1 of [RFC2743] and subsequent

+   GSS-API mechanism tokens have the following formats: it starts with a

+   two-octet token-identifier (TOK_ID), followed by a Kerberos message.

+   The TOK_ID values for the AS-REQ message and the AS-REP message are

+   defined in the table blow:

+

+           Token         TOK_ID Value in Hex

+       -----------------------------------------------

+         KRB_AS_REQ          05 00

+         KRB_AS_REP          06 00

+

+   The TOK_ID values for all other Kerberos messages are the same as

+   defined in [RFC4121].

+

+   It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U

+   can authenticate the acceptor without revealing the initiator's

+   identity

+

+6.1.  Context Token Derived from KRB_AS_REQ

+

+   When the initiator does not have a service ticket to the acceptor, it

+   requests a ticket from the acceptor instead of from the KDC by

+   constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context

+   token, with a token type ID prefixed.  This will be the initiator's

+   initial context token, therefore it MUST also have the standard

+   header bearing the OID of the mechanism being used (in this case,

+   PKU2U's OID).

+

+   The initiator MUST NOT set any KDC options in the 'kdc-options' field

+   of the AS-REQ.

+

+   The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known

+   PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING].

+

+   If the initiator wishes to assert a name of type

+   GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it

+   MUST set the 'cname' field of the AS-REQ accordingly if and only if

+   the realm name part of the given name object is defaulted or the

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 12]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   well-known PKU2U realm name.  Otherwise the initiator MUST add a pa-

+   data element (see below) stating the name that the initiator wishes

+   to assert, it MUST set the cname field to the NULL principal name as

+   defined in Section 4.

+

+   If the targ_name passed to GSS_Init_sec_context() is of type

+   GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of

+   the AS-REQ to match the parsed name as per [RFC4121].  If the target

+   name does not have a representation as a Kerberos principal name per

+   [RFC1964], then the initiator MUST add a pa-data element (see below)

+   stating the given targ_name and the initiator MUST set the 'sname'

+   field of the AS-REQ to the NULL principal name as defined in

+   Section 4.

+

+   The padata used to convey initiator and target names is of type

+   PA_PKU2U_NAME <136> and it's value consists of the DER

+   [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type

+   InitiatorNameAssertion (with explicit tagging).

+

+   InitiatorName ::= CHOICE {

+       -- -1 -> certificate DN

+       -- 0..16384 -> subjectAltName named by

+       --             this index

+       sanIndex INTEGER (-1..16384), -- DN or SAN

+       nameNotInCert GeneralName,    -- name not present in cert

+                                     -- (see RFC5280 for definition

+                                         of GeneralName)

+       ...

+   }

+

+   TargetName ::= CHOICE {

+       exportedTargName OTCET STRING, -- exported krb5 name

+       generalName [0] GeneralName,   -- all other PKI names

+                                      -- (tagged to distinguish

+                                      -- from nameNotInCert

+                                      -- choice of InitiatorName)

+       ...

+   }

+

+   InitiatorNameAssertion ::= SEQUENCE {

+       initiatorName InitiatorName OPTIONAL,

+       targetName TargetName OPTIONAL,

+       ...

+   }

+

+   The initiatorName, if present, contains the initiator's name.  The

+   initiator can fill out either the sanIndex field or the nameNotInCert

+   field to indicate the name of the initiator.

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 13]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   The sanIndex field, if present, is used to refer to either the

+   Distinguished Name or the SubjectAltName in the initiator's X.509

+   certificate.  A sanIndex value of -1 value refers to the initiator's

+   certificate's DN.  All other legal values of sanIndex refer to the

+   corresponding element of the SubjectAltName sequence.  A value of 0

+   means the first instance of GeneralName in the SubjectAltName

+   sequence, and 1 means the second, and so on.  If the sanIndex value

+   is equal or biger than the number of GeneralName elements in the

+   SubjectAltName, the security context establishment attempt MUST fail.

+

+   The nameNotInCert field, if present, contains the initiator's

+   GeneralName.

+

+   If an initiator name assertion is included, the acceptor MUST verify

+   that this asserted name is either present in the initiator's

+   certificate or otherwise bound to the initiator's certificate by out-

+   of-band provisioning (e.g., by a table lookup).  Failure to validate

+   the asserted initiator's name MUST cause GSS_Accept_sec_context() to

+   return an error and, optionally, to output a KRB_ERROR context token

+   as per-RFC4121.

+

+   The initiatorName field MUST NOT be present if the initiator is

+   anonymous or if the 'cname' field of the AS-REQ is not the NULL name

+   (see Section 4).

+

+   Target names passed to GSS_Init_sec_context() that can be represented

+   as Kerberos V principal names, namely, names of

+   GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be

+   represented as the 'sname' field of the AS-REQ or as the

+   exportedTargName choice of TargetName (if the realm part is not the

+   PKU2U realm name).  The contents of the exportedTargName octet string

+   MUST be an exported name token for the Kerberos V mechanism

+   containing a Kerberos V principal name.

+

+   Other target names are represented as a generalName choice of

+   TargetName.  These may be present in an acceptor certificate, or

+   agreed out of band.

+

+   The acceptor MUST select an appropriate acceptor credential that

+   matches the AS-REQ's 'sname' (if not NULL) or the targetName provided

+   in the InitiatorNameAssertion, when present.

+

+   The targetName field MUST NOT be present if the 'sname' field of the

+   AS-REQ is not the NULL name.  The targetName field MUST be present if

+   the 'sname' field of the AS-REQ is the NULL name.

+

+   The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName

+   and targetName both shouldn't be present.

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 14]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   Implementation note: the encrypted part of a PKU2U Ticket can be

+   anything at all since the only entity that will consumer a given

+   PKU2U Ticket is the same entity that issued it.  Implementers may

+   choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and

+   DER encoding.

+

+6.2.  Context Token Derived from KRB_AS_REP

+

+   When the initiator's initial context token is a AS-REQ then the

+   acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or

+   a token derived from a KRB_AS_REP PDU [RFC4120] constructed to

+   respond to the initiator's KRB_AS_REQ.

+

+   The initiator MUST use PKINIT pre-authentication and the acceptor

+   MUST require it.  If the initiator does not use PKINIT pre-

+   authentication then the acceptor MUST respond with a KRB-ERROR and

+   indicate that PKINIT is required.

+

+   If the initiator's KRB_AS_REQ token is valid, and the asserted

+   initiator's name, if present, is bound with the initiator's

+   certificate, and the acceptor can select a certificate based on the

+   initiator's asserted targ_name, the acceptor then constructs a

+   KRB_AS_REP using PKINIT as described in [RFC4556], except that the

+   acceptor's certificate is used in the place of the KDC certificate.

+   If and only if the initiator's X.509 certficate is validated using

+   PKI, the acceptor SHOULD include an authorization element

+   AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket.  If an

+   InitiatorName is included in the PA_PKU2U_NAME padata in the request,

+   an authorization element of the type ad-pku2u-client-name <143> MUST

+   be included in the returned ticet and this authorization element

+   contains the DER encoded InitiatorName in the request.

+

+   The initiator then validates the KRB-AS-REP reply context token

+   according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of

+   [RFC4556].  The inclusion of the EKU KeyPurposeId [RFC5280] id-

+   pkinit-KPKdc in the X.509 certificate in the response is not

+   applicable when PKU2U is used because there is no KDC involved in

+   this protocol.  The initiator MUST verify that the acceptor's

+   certificate is bound with the targ_name passed in to

+   GSS_Init_sec_context(), by verifying either the targ_name matches

+   with either the subject DN or one instance of the SubjectAltName name

+   in the acceptor's certificate, or otherwise the targ_name is bound

+   with the acceptor's certificate by out-of-band provisioning (e.g., by

+   a table lookup).  Failure to validate this name binding MUST cause

+   the authentication to be rejected.

+

+   The 'flags' field of the AS-REP MUST have only the 'initial' and

+   'pre-authent' flags set.

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 15]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   The 'authtime' field of the AS-REP MUST be set to the acceptor's

+   current time as it is when it formats the AS-REP.

+

+   Otherwise all other aspects of the AS-REP are as described in

+   [RFC4120].

+

+   The values of the tkt-vno, realm and 'sname' fields of the Ticket

+   issued by the acceptor are unspecified.  The initiator MUST NOT

+   examine them for correctness.  Cut-n-paste attacks are prevented by

+   the fact that PKU2U provides integrity protection for all cleartext

+   in Kerberos V PDUs used by PKU2U (and for the mechanism OID).

+

+6.3.  Context Tokens Imported from RFC4121

+

+   Once the initiator has a Kerberos V Ticket for the acceptor the

+   security context token exchange will continue with those of the

+   Kerberos V GSS-API mechanism [RFC4121] with the following

+   modifications:

+

+   o  The mechanism OID of PKU2U SHALL be used instead of that of the

+      Kerberos V GSS-API mechanism;

+

+   o  The 'crealm' field of the initiator's Authenticator MUST be set to

+      the PKU2U realm name and if the 'cname" field is the NULL

+      principal name, an authorization element of the type ad-pku2u-

+      client-name <143> MUST be included in the authenticator and this

+      authorization element contains the DER encoded InitiatorName in

+      the AS-REQ based on which the ticket was obtained;

+

+   o  The sub-session key MUST be used in the initiator's Authenticator;

+

+   o  The contents of the encrypted part of the Ticket can be

+      implementation specific since the only entity consuming it will be

+      the same entity that issues it;

+

+   o  If the initiator's initial context token is a KRB_AS_REQ token

+      (i.e., not KRB_AP_REQ token), then the Exts field in the

+      Authenticator of the KRB_AP_REQ-derived token MUST contain an

+      extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined

+      next in this section.

+

+   The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of

+   the Authenticator are set as per [RFC4121] and [RFC4120].

+

+   The 'cksum' field of the Authenticator MUST be set as per [RFC4121].

+   The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS]

+   contains the DER encoding of the ASN.1 structure KRB-FINISHED.

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 16]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   GSS_EXTS_FINISHED             2

+       --- The type for the checksum extension.

+

+   KRB-FINISHED ::= SEQUENCE {

+       gss-mic [1] Checksum,

+           -- Contains the checksum (RFC3961) of the GSS-API tokens

+           -- that have been exchanged between the initiator and the

+           -- acceptor and prior to the containing AP-REQ GSS-API token.

+           -- The checksum is performed over the GSS-API

+           -- context tokens in the order that the tokens were sent.

+        ...

+   }

+

+   The gss-mic field contains a Kerberos checksum [RFC3961] that is

+   computed over all the preceding context tokens of this GSS-API

+   context (including the InitialContextToken header), concatenated in

+   chronological order (note that GSS-API context token exchanges are

+   synchronous).  The checksum type is the required checksum type of the

+   enctype of the subkey in the authenticator, the protocol key for the

+   checksum operation is the authenticator subkey, and the key usage

+   number is KEY_USAGE_FINISHED <41>.

+

+   The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121,

+   except that if the context token exchange included an AS exchange,

+   then the acceptor MUST also validate the GSS_EXTS_FINISHED and return

+   an error if it is not valid or not present.  But if a KRB_AP_REQ

+   context token is the initial context token then the acceptor MUST

+   return an error if GSS_EXTS_FINISHED is present.

+

+   The GSS_EXTS_FINISHED (along with the ticket) binds the second part

+   of the context token exchange to the first, and it binds the pa-data

+   used in the request as well (this needs to be done because PKINIT

+   does not bind pa-data other than PKINIT pa-data from the request).

+   GSS_EXTS_FINISHED also protects all otherwise unauthenticated

+   plaintext in Kerberos V PDUs.  Note that GSS_EXTS_FINISHED also

+   protects the mechanism OID in the InitialContextToken header.

+

+   The acceptor MUST verify that the ad-pku2u-client-name authorization

+   element is present in the authenticator if and only there is an

+   authorization element of the same type in the ticket and the values

+   of these two elements MUST match exactly based on bit-wise

+   comparison.

+

+

+7.  Guidelines for Credentials Selection

+

+   If a peer, either the initiator or the acceptor, has multiple pairs

+   of public-key private keys and certificates, a choice is to be made

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 17]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   in choosing the best fit.  The trustedCertifiers field in the PA-PK-

+   AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to

+   provide hints for guiding the selection of an appropriate certificate

+   chain by the acceptor.

+

+   If the initiator's X.509 certificate cannot be validated according to

+   [RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS

+   structure [RFC4556] that provides hints for guiding the selection of

+   an appropriate certificate by the initiator.  In this case

+   GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the

+   initiator gets to try again in its subsequent AS-REQ token.

+

+   The GSS-API does not provide a programming interface to make this

+   credential selection interactive, though implementers may provide

+   methods for user interaction related to credential selection and

+   acquisition (e.g., name and password/PIN prompts).  Whenever the

+   execution context allows for direct interaction of the mechanism with

+   the user then it is RECOMMENDED that implementations interact with

+   the user to select a credential whenever multiple credentials are

+   equally usable and no other mechanism is available to inform the

+   credential selection.

+

+   If the certificates cannot be selected interactively, multiple

+   certificates are equally usable, and there is no other mechanism

+   available for credential selection, then it is RECOMMENDED that

+   initiators fail the context.  Users should be able to retry using a

+   specific credential (this requires that distinct credentials have

+   distinct names that can be used to acquire each credential

+   separately).

+

+

+8.  Security Considerations

+

+   The security considerations in [RFC4120], [RFC4121], [RFC4556] and

+   [RFC5280] apply here.  This mechanism relaxes some requirements of

+   PKINIT and adds a device for protecting otherwise unauthenticated

+   plaintext in the protocol (see Section 6.3) -- it is crucial that

+   this device be faithfully implemented.  It is also crucial that both

+   the initiator and the acceptor MUST be able to verify the binding

+   between the signing key and the asserted identity.

+

+   Note that PKU2U is just as susceptible to replays of AP-REQs as the

+   traditional Kerberos V GSS-API mechanism [RFC4121], though only when

+   using an AP-REQ as the initial security context token.  It is

+   important, therefore, to use a replay cache to detect replays.

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 18]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+9.  Acknowledgements

+

+   The authors would like to thank Jeffrey Hutzelman for his insightful

+   comments on the earlier revisions of this document.

+

+   In addition, the following individuals have provided review comments

+   for this document: Sam Hartman, Leif Johansson, Olga Kornievskaia,

+   Martin Rex, and Sunil Gottumukkala.

+

+   Ari Medvinsky provided help in editing the initial revisions of this

+   document.

+

+   The text for the DN mapping is compiled from the email discussions

+   among the following individuals: Howard Chu, Martin Rex, Jeffrey

+   Hutzelman, Kevin Coffman, Henry B. Hotz, Leif Johansson, and Olga

+   Kornievskaia.  Howard and Jeffery clearly illustrated the challenges

+   in creating a unique mapping, while Nicolas and Martin demonstrated

+   the relevance and interactions to GSS-API and Kerberos.

+

+

+10.  IANA Considerations

+

+   This document defines the PKU2U realm and the place-holder well-known

+   principal name.  The IANA registry for the reserved names should be

+   updated to reference this document.  Two entries are added: one entry

+   for the well-known realm "WELLKNOWN:PKU2U", and another for the well-

+   known principal name "WELLKNOWN/NULL".

+

+   This document defines GSS_EXTS_FINISHED extension type.  The

+   corresponding IANA registry [GSS-EXTS] need to be updated to

+   reference this document.  The following single registration should be

+   added in the registry for "Kerberos V GSS-API mechanism extension

+   types": 2, "GSS-API token checksum", "Extension to provide a checksum

+   for GSS-API tokens", the RFC # of this document.

+

+   This document also instructs the IANA to extend the "SMI Security for

+   Name System Designators Codes (nametypes)" registry to include an OID

+   for each registration, and to allocate OIDs for the following GSS-API

+   name-types in that registry:

+   o  gss-distinguished-name (GSS_C_NT_DN)

+   o  gss-hostname (GSS_C_NT_HOSTNAME)

+   o  gss-IP-address (GSS_C_NT_IP_ADDR)

+   o  gss-e-mail-address (GSS_C_NT_EMAIL_ADDR)

+

+

+11.  Normative References

+

+   [CCITT.X680.2002]

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 19]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+              International International Telephone and Telegraph

+              Consultative Committee, "Abstract Syntax Notation One

+              (ASN.1): Specification of basic notation",

+              CCITT Recommendation X.680, July 2002.

+

+   [CCITT.X690.2002]

+              International International Telephone and Telegraph

+              Consultative Committee, "ASN.1 encoding rules:

+              Specification of basic encoding Rules (BER), Canonical

+              encoding rules (CER) and Distinguished encoding rules

+              (DER)", CCITT Recommendation X.690, July 2002.

+

+   [GSS-EXTS]

+              Emery, S., "Kerberos Version 5 GSS-API Channel Binding

+              Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility (work

+              in progress), 2007.

+

+   [KRB-ANON]

+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",

+              draft-ietf-krb-wg-anon (work in progress), 2007.

+

+   [KRB-NAMING]

+              Zhu, L., "Additional Kerberos Naming Constraints",

+              draft-ietf-krb-wg-naming (work in progress), 2007.

+

+   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet

+              text messages", STD 11, RFC 822, August 1982.

+

+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",

+              STD 13, RFC 1034, November 1987.

+

+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",

+              RFC 1964, June 1996.

+

+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

+              Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [RFC2743]  Linn, J., "Generic Security Service Application Program

+              Interface Version 2, Update 1", RFC 2743, January 2000.

+

+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :

+              C-bindings", RFC 2744, January 2000.

+

+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,

+              "Internationalizing Domain Names in Applications (IDNA)",

+              RFC 3490, March 2003.

+

+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 20]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+              Kerberos 5", RFC 3961, February 2005.

+

+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

+              Kerberos Network Authentication Service (V5)", RFC 4120,

+              July 2005.

+

+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos

+              Version 5 Generic Security Service Application Program

+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,

+              July 2005.

+

+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API

+              Extension for the Generic Security Service Application

+              Program Interface (GSS-API)", RFC 4401, February 2006.

+

+   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the

+              Kerberos V Generic Security Service Application Program

+              Interface (GSS-API) Mechanism", RFC 4402, February 2006.

+

+   [RFC4514]  Zeilenga, K., "Lightweight Directory Access Protocol

+              (LDAP): String Representation of Distinguished Names",

+              RFC 4514, June 2006.

+

+   [RFC4517]  Legg, S., "Lightweight Directory Access Protocol (LDAP):

+              Syntaxes and Matching Rules", RFC 4517, June 2006.

+

+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

+

+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,

+              Housley, R., and W. Polk, "Internet X.509 Public Key

+              Infrastructure Certificate and Certificate Revocation List

+              (CRL) Profile", RFC 5280, May 2008.

+

+

+Authors' Addresses

+

+   Larry Zhu

+   Microsoft Corporation

+   One Microsoft Way

+   Redmond, WA  98052

+   US

+

+   Email: lzhu@microsoft.com

+

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 21]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+   Jeffery Altman

+   Secure Endpoints

+   255 W 94th St

+   New York, NY  10025

+   US

+

+   Email: jaltman@secure-endpoints.com

+

+

+   Nicolas Williams

+   Sun Microsystems

+   5300 Riata Trace Ct

+   Austin, TX  78727

+   US

+

+   Email: Nicolas.Williams@sun.com

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 22]

+

+Internet-Draft                    PKU2U                    November 2008

+

+

+Full Copyright Statement

+

+   Copyright (C) The IETF Trust (2008).

+

+   This document is subject to the rights, licenses and restrictions

+   contained in BCP 78, and except as set forth therein, the authors

+   retain all their rights.

+

+   This document and the information contained herein are provided on an

+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

+

+

+Intellectual Property

+

+   The IETF takes no position regarding the validity or scope of any

+   Intellectual Property Rights 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; nor does it represent that it has

+   made any independent effort to identify any such rights.  Information

+   on the procedures with respect to rights in RFC documents can be

+   found in BCP 78 and BCP 79.

+

+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at

+   http://www.ietf.org/ipr.

+

+   The IETF invites any interested party to bring to its attention any

+   copyrights, patents or patent applications, or other proprietary

+   rights that may cover technology that may be required to implement

+   this standard.  Please address the information to the IETF at

+   ietf-ipr@ietf.org.

+

+

+

+

+

+

+

+

+

+

+

+Zhu, et al.                Expires May 7, 2009                 [Page 23]

+

+

diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-spnego-2478bis-00.txt b/third_party/heimdal/doc/standardisation/draft-zhu-spnego-2478bis-00.txt
new file mode 100644
index 00000000000..d696f063e97
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-spnego-2478bis-00.txt
@@ -0,0 +1,1155 @@
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                             K. Jaganathan
+Obsoletes: 2478 (if approved)                                    R. Ward
+Expires: April 18, 2005                            Microsoft Corporation
+                                                        October 18, 2004
+
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+                      draft-zhu-spnego-2478bis-00
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   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 Internet-Draft will expire on April 18, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+   This document specifies a security negotiation mechanism for the
+   Generic Security Service Application Program Interface (GSS-API)
+   which is described in RFC 2743.
+
+
+   This mechanism allows negotiating and choosing one security mechanism
+   from a common set of security mechanisms shared by GSS-API peers.
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 1]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+   Once the common security mechanism is identified, the security
+   mechanism MAY also negotiate mechanism-specific options during its
+   context establishment, but that will be inside the mechanism tokens,
+   and invisible to this protocol.
+
+
+Table of Contents
+
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Negotiation Model  . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  5
+     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  6
+   4.  Data Elements  . . . . . . . . . . . . . . . . . . . . . . . . 11
+     4.1   Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 11
+     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 11
+       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 12
+       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 13
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
+   A.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 17
+       Intellectual Property and Copyright Statements . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 2]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+1.  Introduction
+
+
+   The GSS-API [RFC2743] provides a generic interface which can be
+   layered atop different security mechanisms such that if communicating
+   peers acquire GSS-API credentials for the same security mechanism,
+   then a security context MAY be established between them (subject to
+   policy).  However, GSS-API doesn't prescribe the method by which
+   GSS-API peers can establish whether they have a common security
+   mechanism.
+
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo-security mechanism, represented by the
+   object identifier iso.org.dod.internet.security.mechanism.snego
+   (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band
+   whether their credentials share common GSS-API security mechanism(s),
+   and if so, to invoke normal security context establishment for a
+   selected common security mechanism.  This is most useful for
+   applications that are based on GSS-API implementations which support
+   multiple security mechanisms.
+
+
+   The simple and protected GSS-API mechanism negotiation is based on
+   the following negotiation model: the initiator proposes one security
+   mechanism or a list of security mechanisms in its preference order
+   (favorite choice first), the acceptor (the target) either accepts the
+   proposed security mechanism, or chooses one from the offered list, or
+   rejects the proposed value(s).  The target then informs the initiator
+   of its choice.
+
+
+   In order to avoid an extra round trip, the initial security token of
+   the preferred mechanism for the initiator SHOULD be embedded in the
+   initial negotiation token (as defined in Section 4.2).  If the target
+   preferred mechanism matches the initiator's preferred mechanism, no
+   additional round trips may be incurred by using the negotiation
+   protocol.
+
+
+   The negotiation is protected and all the underlying mechanisms
+   offered by the initiator MUST be capable of integrity protection.
+
+
+   The Simple and Protected GSS-API Negotiation Mechanism uses the
+   concepts developed in the GSS-API specification [RFC2743].  The
+   negotiation data is encapsulated in context-level tokens.  Therefore,
+   callers of the GSS-API do not need to be aware of the existence of
+   the negotiation tokens but only of the new pseudo-security mechanism.
+   A failure in the negotiation phase causes a major status code to be
+   returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 3]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 4]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+3.  Negotiation Model
+
+
+3.1  Negotiation Description
+
+
+   Each OID represents one GSS-API mechanism or one variant of it.
+
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms (in preference order, favorite choice first), and
+   OPTIONALLY the initial security token for the preferred mechanism of
+   the initiator (i.e.  the first of the list).
+
+
+   The target then processes the token from the initiator.  This will
+   result in one of three possible states (as defined in Section 4.2.2):
+   accept_completed, accept_incomplete, or reject.  A reject state will
+   terminate the negotiation.  An accept_completed state indicates that
+   not only was the initiator-selected mechanism acceptable to the
+   target, but that the initial token was sufficient to complete the
+   authentication.  An accept_incomplete state indicates that the target
+   has selected a different mechanism or the preferred mechanism is
+   acceptable, but this mechanism requires at least one additional
+   message to complete the authentication.  The target MAY produce a
+   context level token for a reject state.
+
+
+   The first negotiation token sent by the acceptor contains the result
+   of the negotiation (accept_completed, accept_incomplete or reject)
+   and, in case of accept, the agreed security mechanism.  It MUST also
+   include the response mechanism token to the initial mechanism token
+   from the initiator, when the first proposed mechanism of the
+   initiator has been selected and an initial mechanism token was
+   provided by the initiator.  However, if the initiator's preferred
+   mechanism is not possible, the target will not emit a response
+   mechanism token in the first reply.
+
+
+   The policy by which the target chooses a mechanism is an
+   implementation-specific local matter.  In the absence of other
+   policy, the target MUST choose the first mechanism in the list for
+   which valid credentials are available.
+
+
+   The first negotiation token is the negTokenInit message and all
+   subsequent negotiation tokens are the negTokenResp message, as
+   defined in Section 4.2.
+
+
+   The use of partially-established contexts (as indicated by the
+   prot_ready_state in [RFC2743]), either for this mechanism or
+   mechanisms negotiated using this mechanism, is prohibited.
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 5]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+3.2  Negotiation Procedure
+
+
+   The negotiation procedure is summarized as follows:
+
+
+   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests (either explicitly, with the negotiation mechanism,
+      or through accepting a default, when the default is the
+      negotiation mechanism) that the Simple and Protected GSS-API
+      Negotiation Mechanism is used;
+
+
+   (b) The initiator GSS-API implementation emits a negotiation token
+      containing a list of supported security mechanisms for the
+      credentials used for this context establishment, and OPTIONALLY an
+      initial security token for the first mechanism from that list
+      (i.e.  the preferred mechanism), and indicates
+      GSS_S_CONTINUE_NEEDED status;
+
+
+   (c) The GSS-API initiator application sends the token to the target
+      application;
+
+
+   (d) The GSS-API target application deposits the token through
+      invoking GSS_Accept_sec_context.  The target GSS-API application
+      will do one of the following:
+
+
+      (I) If the initiator's preferred mechanism is accepted by the
+         target, an initial token is included in the first token from
+         the initiator, no further mechanism token from the initiator is
+         needed for the chosen mechanism to establish the security
+         context, (e.g.  when the authentication mechanism is unilateral
+         or mutual authentication has been performed and involves a
+         single token in either direction), and the initiator has not
+         sent a MIC token (the output token of the GSS_GetMIC() call
+         [RFC2743], the input to GSS_GetMIC() is the OTCET STRING field
+         representing the MechTypes in the initial NegTokenInit token),
+         of the mechanism list, the acceptor will do one of the
+         following:
+
+
+         1) If the initiator's preferred mechanism is accepted and there
+            is no policy on the target such that a different mechanism
+            other than the initiator's preferred mechanism could have
+            been selected given a different list of mechanisms,
+            GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE and it
+            MUST produce a negotiation token with the accept_completed
+            state, and with no MIC of the mechanism list.  This is
+            referred in this document as the Safe to Omit MIC (SOMIC)
+            rule number 1.  The resulting negotiation token MUST include
+            the security token if one is returned by the selected
+            mechanism;
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 6]
+
+
+         2) If the initiator's preferred mechanism is accepted and there
+            is policy exists on the target such that a different
+            mechanism other than the initiator's preferred mechanism
+            could have been selected given a different list of
+            mechanisms, GSS_Accept_sec_context() MUST indicate
+            GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
+            a MIC MUST be generated by the target.  This MIC is to be
+            verified by the initiator and the result will be sent back
+            to the acceptor.  This is referred in this document as the
+            Safe to Omit MIC (SOMIC) rule number 2.  The resulting
+            negotiation token MUST include the security token if one is
+            returned by the selected mechanism.
+
+
+         3) If there is a MIC token and it is correct,
+            GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE with
+            no output token; If there is an incorrect MIC token,
+            GSS_Accept_sec_context() must indicate GSS_S_BAD_MIC status,
+            OPTIONALLY returning a negotiation token with the reject
+            state.
+
+
+      (II) If the initiator's preferred mechanism is accepted, and an
+         initial token from this mechanism is sent by the initiator, but
+         a failure is returned by the chosen mechanism,
+         GSS_Accept_sec_context() MUST report the failure and the
+         mech_type output parameter indicates the selected mechanism.
+         The target MUST produce a negotiation token with the reject
+         state if the selected mechanism returns a response token (e.g.
+         a KRB_ERROR when the Kerberos Version 5 GSS-API mechanism is
+         chosen [GSSAPICFX]);
+
+
+      (III) If the initiator's preferred mechanism is accepted, and an
+         initial token from this mechanism is sent by the initiator, but
+         at last one more initiator token need to be transferred to
+         establish the context, GSS_Accept_sec_context() MUST indicate
+         GSS_S_CONTINUE_NEEDED status, returning a negotiation token
+         with the accept_incomplete state, the response mechanism token,
+         and no MIC token.
+
+
+      (IV) If the initiator's preferred mechanism is accepted, but no
+         initial token from this mechanism is sent by the initiator,
+         GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
+         status, returning a negotiation token with the
+         accept_incomplete state, the selected mechanism, no response
+         mechanism token or MIC token.
+
+
+      (V) If a proposed mechanism is accepted, and it is not the
+         initiator's preferred mechanism, GSS_Accept_sec_context() MUST
+         indicate GSS_S_CONTINUE_NEEDED status, returning a negotiation
+         token with the accept_incomplete state, the selected mechanism,
+         no response mechanism token or MIC token.  The negotiation will
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 7]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+         be the agreed security mechanism if the negotiation is
+         successful.
+
+
+   (e) The GSS-API target application returns the negotiation token to
+      the initiator application;
+
+
+   (f) The GSS-API initiator application deposits the token through
+      invoking GSS_Init_sec_context().  The initiator will do one of the
+      following:
+
+
+      (I) When the negotiation token carries an accept_completed result,
+         the initiator MUST do one of the following:
+
+
+         1) If the selected mechanism is the initiator's preferred
+            mechanism, the initiator SHALL NOT reject the negotiation if
+            no MIC token is present.  This is referred in this document
+            as the Safe to Omit MIC ("SOMIC") rule number 3.  The
+            initiator MUST deposit the security token if one is
+            included, GSS_Init_sec_context() MUST indicate
+            GSS_S_BAD_MECH status if the context is not established
+            after this GSS_Init_sec_context() call.  If a MIC token is
+            present, the initiator MUST verify it and a GSS_S_BAD_MIC
+            must be returned if the MIC is incorrect;
+
+
+         2) If the selected mechanism is not the initiator's preferred
+            mechanism, and there is no or an incorrect MIC token,
+            GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC status.
+            This is referred in this document as the Safe to Omit MIC
+            ("SOMIC") rule number 4.
+
+
+      (II) When the negotiation token carries a reject result without a
+         response security token, GSS_Init_sec_context() MUST indicate
+         GSS_S_BAD_MECH status;
+
+
+      (III) When the negotiation token carries a reject result with a
+         response security token, the initiator MUST deposit the
+         security token, and GSS_Init_sec_context() MUST indicate a
+         failure status reported by the underlying mechanism, and the
+         output mech_type indicates the selected mechanism;
+
+
+      (IV) When the negotiation token carries an accept_incomplete
+         result and further mechanism tokens from the acceptor must be
+         transferred in order to complete context establishment,
+         GSS_Init_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
+         status, returning an output token with the accept_incomplete,
+         and the selected mechanism's context level token;
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 8]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+      (V) When the negotiation token carries an accept_incomplete
+         result, no further mechanism token need to be transferred from
+         the acceptor to complete the context establishment, the
+         initiator MUST do one of the following:
+
+
+         1) If a MIC token was included, the initiator MUST verify it
+            and GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC if
+            the MIC is incorrect; GSS_Init_sec_context() MUST indicate
+            GSS_S_COMPLETE and produce a negotiation with the
+            accept_completed state if the MIC is correct.  This is
+            referred in this document as the Safe to Omit MIC ("SOMIC")
+            rule number 5;
+
+
+         2) If no MIC token was present, GSS_Init_sec_context() MUST
+            indicate GSS_S_BAD_MIC statue, This is referred in this
+            document as the Safe to Omit MIC ("SOMIC") rule number 6.
+
+
+   (g) The initiator application then sends the output_token to the
+      target if one is returned.  The security context initialization is
+      then continued according to the standard GSS-API conventions for
+      the selected mechanism, where the tokens of the selected mechanism
+      are encapsulated until the GSS_S_COMPLETE is returned for both the
+      initiator and the target.  When no further mechanism token is
+      needed to be transferred and the context for the chosen mechanism
+      is established, the initiator and the acceptor will need to either
+      apply the "SOMIC" rules above and skip MIC generation and
+      verification, or generate and verify the MIC token to protect the
+      negotiation.
+
+
+   (h) When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
+      parameter is not yet valid.  When GSS_S_COMPLETE is returned, the
+      mech_type output parameter indicates the selected mechanism.
+
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested but was not supported.
+
+
+   When GSS_Acquire_cred is invoked with the negotiation mechanism as
+   desired_mechs, an implementation-specific default credential is used
+   to carry on the negotiation.  A set of mechanisms as specified
+   locally by the system administrator is then available for
+   negotiation.  If there is a desire for the caller to make its own
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                 [Page 9]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+   choice, then an additional API has to be used as defined in [PRTSTK].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 10]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+4.  Data Elements
+
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+      SPNEGOASNOneSpec {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) mechanism(5) snego (2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+
+      -- rest of definitions here
+
+
+      END
+
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+
+   The encoding of SPNEGO protocol messages shall obey the Distinguished
+   Encoding Rules (DER) of ASN.1 as described in [X690].
+
+
+4.1  Mechanism Type
+
+
+           MechType ::= OBJECT IDENTIFIER
+             -- OID represents each security mechanism as suggested by
+             -- [RFC2743]
+
+
+
+4.2  Negotiation Tokens
+
+
+   The syntax of the initial negotiation tokens follows the
+   InitialContextToken syntax defined in [RFC2743].  The security
+   mechanism of the initial negotiation token is identified by the
+   Object Identifier in Section 1.  All subsequent tokens are not
+   encapsulated in the above generic token framing.
+
+
+   This section specifies the syntax of initial and subsequent context
+   level tokens.
+
+
+           NegotiationToken ::= CHOICE {
+               negTokenInit    [0] NegTokenInit,
+               negTokenResp    [1] negTokenResp
+           }
+
+
+           MechTypeList ::= SEQUENCE OF MechType
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 11]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+4.2.1  negTokenInit
+
+
+           NegTokenInit ::= SEQUENCE {
+               mechTypes       [0] MechTypeList,
+               reqFlags        [1] ContextFlags  OPTIONAL,
+               mechToken       [2] OCTET STRING  OPTIONAL,
+               mechListMIC     [3] OCTET STRING  OPTIONAL,
+               ...
+           }
+
+
+           ContextFlags ::= BIT STRING {
+               delegFlag       (0),
+               mutualFlag      (1),
+               replayFlag      (2),
+               sequenceFlag    (3),
+               anonFlag        (4),
+               confFlag        (5),
+               integFlag       (6)
+           }
+
+
+   This is the message for the initial negotiation token.
+
+
+   mechTypes
+
+
+         This field contains one or more security mechanisms in the
+         preference order (favorite choice first) supported by the
+         initiator (as indicated in the field mechTypes).
+
+
+   reqFlags
+
+
+         This field, if present, contains the service options that are
+         requested to establish the context.  The context flags SHOULD
+         be filled in from the req_flags parameter of
+         GSS_Init_sec_context().  This field SHALL NOT influence the
+         outcome of the negotiation.
+
+
+   mechToken
+
+
+         This field, is present, contains an optimistic negotiation
+         response.
+
+
+   mechListMIC
+
+
+         This field, if present, contains the result of a GSS_GetMIC()
+         [RFC2743] of the MechTypes field in the initial NegTokenInit
+         token.  It allows verifying that the list initially sent by the
+         initiator has been received unmodified by the target.
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 12]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+4.2.2  negTokenResp
+
+
+               NegTokenResp ::= SEQUENCE {
+                   negResult       [0] ENUMERATED {
+                       accept_completed    (0),
+                       accept_incomplete   (1),
+                       reject              (2)
+                       },
+                   supportedMech   [1] MechType      OPTIONAL,
+                   responseToken   [2] OCTET STRING  OPTIONAL,
+                   mechListMIC     [3] OCTET STRING  OPTIONAL,
+                       -- used only by the acceptor
+                   ...
+               }
+
+
+   This is the message for all the subsequent tokens.
+
+
+   negResult
+
+
+         Result of the negotiation exchange, specified by the target.
+         This can be:
+
+
+         accept_completed
+            A security mechanism is selected, and the context is
+            established for the sender;
+
+
+         accept_incomplete
+            Further exchanges are necessary;
+
+
+         reject
+            The sender reject the proposed security mechanism(s).
+
+
+         accept_completed indicates that a context has been successfully
+         established, while the result accept_incomplete indicates that
+         additional token exchanges are needed.
+
+
+         For those targets that support piggybacking the initial
+         mechToken, an optimistic negotiation response is possible and
+         includes in that case a responseToken which MAY continue the
+         authentication exchange (e.g.  when mutual authentication has
+         been requested or when unilateral authentication requires
+         several round trips).  Otherwise the responseToken is used to
+         carry the tokens specific to the mechanism selected.
+
+
+         The mechListMIC, when present, is a MIC computed over the
+         MechTypes using the mechanism list field in the initial token
+         (encoded in DER).
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 13]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+   supportedMech
+
+
+         This field is present and only present in the first
+         negTokenResp token.  It is a choice from the mechanisms offered
+         by the initiator.
+
+
+   responseToken
+
+
+         This field, if present, contains the security token of the
+         selected mechanism.
+
+
+   mechListMIC
+
+
+         This field, if present, contains the result of a GSS_GetMIC()
+         [RFC2743] of the MechTypes field in the initial NegTokenInit
+         token.  It allows verifying that the list initially sent by the
+         initiator has been received unmodified by the target.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 14]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+5.  Security Considerations
+
+
+   In order to produce the MIC for the mechanism list, the mechanism
+   MUST provide integirty protection.  When one of the mechanisms
+   proposed by the initiator does not support integrity protection, then
+   the negotiation is exposed to all threats a non secured service is
+   exposed.  In particular, an active attacker can force to use a
+   security mechanism which is not the common preferred one (when
+   multiple security mechanisms are shared between peers) but which is
+   acceptable anyway to the target, thus this mechanism does not support
+   selecting a mechanism that does not support integrity protection.
+
+
+   In any case, the communicating peers MAY be exposed to the denial of
+   service threat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 15]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+6.  Acknowledgments
+
+
+   The authors wish to thank Paul Leach and Todd Stecher for theirs
+   comments and suggestions on earlier versions of this document.
+
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478], of which some of the text has been retained in this
+   document.
+
+
+7  References
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+   [PRTSTK]   RFC-Editor: To be replaced by RFC number for draft-williams
+              -gssapi-stackable-pseudo-mechs.  Work in progress.
+              
+   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
+              (BER), Canonical Encoding Rules (CER) and Distinguished 
+              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
+              ISO/IEC International Standard 8825-1:1998.
+
+
+Authors' Addresses
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+
+   EMail: lzhu@microsoft.com
+
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+
+   EMail: karthikj@microsoft.com
+
+
+
+   Richard B. Ward
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+
+   EMail: richardw@microsoft.com
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 16]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+Appendix A.  Changes since RFC2478
+
+
+      The following changes are designed to be compatible with an
+      incorrect implementation of RFC 2478 shipped in Windows 2000.  A
+      correct implementation of this protocol that negotiates the 2 leg
+      Kerberos GSS-API mechanism as the only available security
+      mechanism should be ale to interoperate with the implementation of
+      Windows 2000 when the mangled OID (1.2.840.48018.1.2.2) can be
+      used to identify Kerberos.
+
+
+      *  The negTokenTarg is changed to negTokenResp and it is now the
+         format for all subsequent negotiation messages.
+      *  negTokenInit is the message for the initial token and that
+         token only.
+      *  mechTypes in negTokenInit is no longer optional.
+      *  negResult is no longer optional in the negTokenResp token.
+      *  The initiator does not send the MIC token.
+      *  Add rules when it is safe to omit the MIC token.  Search for
+         SOMIC.
+
+
+      The following changes are to address the problems in RFC 2478.
+
+
+      *  reqFlags is not protected therefore it should not impact the
+         negotiation.
+      *  BER encoding is required.
+      *  GSS_GetMIC() input is clarified.
+      *  Nico's stackable pseudo mechanism draft is used to replace the
+         support APIs.
+      *  We no longer support negotiating mechanisms that do not provide
+         for integrity.  That support does not add security values but
+         blows up the interoperability test matrix.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 17]
+Internet-Draft       GSS-API Negotiation Mechanism          October 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+Zhu, et al.              Expires April 18, 2005                [Page 18]
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-00.txt b/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-00.txt
new file mode 100644
index 00000000000..95cb10332d8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-00.txt
@@ -0,0 +1,528 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                             October 17, 2006
+Intended status: Standards Track
+Expires: April 20, 2007
+
+
+                       Kerberos for Web Services
+                          draft-zhu-ws-kerb-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 20, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol and the
+   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
+   exchange messages with the KDC using the GSS-API server as the proxy,
+   by encapsulating the Kerberos messages inside GSS-API tokens.  With
+   these extensions, Kerberos is suitable for securing communication
+   between the client and web services over the Internet.
+
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 1]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
+   3.  GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Addresses in Tickets  . . . . . . . . . . . . . . . . . . . . . 6
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 2]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+1.  Introduction
+
+   The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
+   promises minimal or no exposure of weak client keys and strong client
+   authentication.  The Kerberos support of anonymity [KRB-ANON]
+   provides for privacy.  These advancements make Kerberos suitable over
+   the Internet.
+
+   The traditional client-push Kerberos protocol does not work well in
+   the Web services environments where the KDC is not accessible to the
+   client, but is accessible to the web server.  For example, the KDC is
+   commonly placed behind a firewall together with the application
+   server.  The lack of accessibility to the KDC by the client could
+   also occur are when the client does not have an IP address prior to
+   authenticating to an access point.
+
+   Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743] allows security mechanisms exchange arbitrary messages
+   between the client and the server via the application traffic,
+   independent of the underlying transports.  A protocol based on
+   [RFC4121] is thus defined to allow the GSS-API client to exchange
+   Kerberos messages with the KDC by using the GSS-API server as the
+   proxy.  The server-pull model defined in this specification is
+   benefical for clients with limited processing power such as mobile
+   devices, or when the client and the server message exchange has high
+   network latency.
+
+           Client <---------> WS-KERB proxy <----------> KDC
+
+   The Kerberos client MUST use a pre-authentication mechanism such as
+   FAST [KRB-PAFW] to avoid exposure of long term client keys to the
+   server, before and after the server is authenticated, and hide the
+   client identity from adversary who can eavesdrop the application
+   traffic if such level of privacy is desirable.
+
+
+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 [RFC2119].
+
+
+3.  GSS-API Encapsulation
+
+   The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
+   accordance with the mechanism proposed by [RFC4178] for negotiating
+   protocol variations, is id-kerberos-ws:
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 3]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+      id-kerberos-ws ::=
+        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
+          webService(6) }
+
+   The first token of the GSS-API WS-KERB mechanism MUST have the
+   generic token framing described in section 3.1 of [RFC2743] with the
+   mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
+   KERB token MUST NOT have this framing.
+
+   The GSS-API WS-KERB mechanism MUST always provide server
+   authentication, even if the client does not ask for it.  When server-
+   authentication is performed, the GSS-API server will always send back
+   an AP-REP, and as described later in this section this mechanism
+   provides integrity protection for all client-server proxy message
+   exchanges.
+
+   The innerToken described in section 3.1 of [RFC2743] and subsequent
+   GSS-API tokens have the following formats: it starts with a two-octet
+   token-identifier (TOK_ID), followed by a WS-KERB message or a
+   Kerberos message.
+
+
+             Token/Message       TOK_ID Value in Hex
+           -----------------------------------------
+             WS_KRB_PROXY         05 01
+
+   Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
+   is defined in this document.  The TOK_ID values for [RFC4120]
+   Kerberos messages are the same as those defined for the GSS-API
+   Kerberos mechanism [RFC4121].
+
+   The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
+   structure immediately followed by a Kerberos message.  The Kerberos
+   message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
+   ERROR as defined in [RFC4120].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 4]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+           WS-KRB-HEADER ::= SEQUENCE {
+               pvno            [1] INTEGER (5) ,
+               msg-type        [2] INTEGER (23),
+               proxy-data      [3] ProxyData,
+               ...
+           }
+
+           ProxyData :: = SEQUENCE {
+               realm           [1] Realm,
+               cookie          [3] OCTET STRING OPTIONAL,
+                  -- opaque data, if sent by the server,
+                  -- MUST be copied by the client unchanged into
+                  -- the next WS-KERB message.
+               ...
+           }
+
+
+   The WS-KRB-HEADER structure and all the Kerberos messages MUST be
+   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
+   Encoding Rules (DER) [X680] [X690].
+
+   The GSS-API WS-KERB client fills out the realm field in the ProxyData
+   of the first request with the client realm.  If the client does not
+   know the client realm [REFERALS], it MUST fill it out using the
+   client's default realm name such as the realm of the client host.
+   Typically the Kerberos message in the first WS_KRB_PROXY message from
+   the client is an AS-REQ message.
+
+   Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB server
+   MUST use the proxy-data in the message from the client to locate the
+   KDC and sends the encapsulated Kerberos message to that KDC.  In
+   order to reduce the number of roundtrips between the client and the
+   server, the server SHOULD process any message exchange with the KDC
+   if the exchange is unauthenticated, such as client-referral message
+   exchange [REFERALS].  If the server can not process the KDC response
+   by itself, for example when the knowledge of the client keys is
+   required, it sends back to the client the KDC reply message
+   encapsulated in a WS_KRB_PROXY message.  The server MUST fill out the
+   realm name whose KDC produced the response.  The server SHOULD use
+   the XKDC mechanism described in [KRB-PAFW] to allow the client's KDC
+   to obtain a service ticket to the server, thus further reduce the
+   number of roundtrips between the GSS-API client and the GSS-API
+   server.  The GSS-API server can send opaque data in the cookie field
+   of the WS-KRB-HEADER structure in the server reply to the client, in
+   order to, for example, reduce the amount of state information kept by
+   the GSS-API server.  The content and the encoding of the cookie field
+   is a local matter of the server.  The client MUST copy the verbatim
+   cookie from the previous server response, when the cookie is present,
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 5]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+   whenever it sends an additional WS-KRB-PROXY message to the server.
+   The client processes the KDC response, and fills out the realm name
+   it believes to whom the server should send the encapsulated Kerberos
+   message.
+
+   When the client obtains a service ticket, the client then sends a
+   KRB_AP_REQ message to the server, and proceed as defined in
+   [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
+   by the client.  The extension type is 2 and the content is the ASN.1
+   DER encoding of the type Checksum.  The checksum is performed over
+   all GSS-API messages as exchanged between the client and the server
+   before the KRB_AP_REQ message, and in the order of the exchange.  The
+   checksum type is the required checksum type for the enctype of the
+   subkey in the authenticator, the protocol key is the authenticator
+   subkey, and the key usage number is TBA-1.  The server MUST verify
+   this checksum in the GSS-API authenticator extension, then respond
+   with an AP-REP extension [GSS-EXTS].  The AP-REP extension type is 2
+   and the the content is the ASN.1 DER encoding of the type Checksum.
+   This checksum is performed over all GSS-API messages as exchanged
+   between the client and the server before the KRB_AP_REQ message, and
+   in the order of the exchange.  The checksum type is the required
+   checksum type for the enctype of the authenticator subkey in the
+   request, and the protocol key is the authenticator subkey, and the
+   key usage number is TBA-2.  The client MUST then verify this
+   checksum.
+
+
+4.  Addresses in Tickets
+
+   In WS-KERB, the machine sending requests to the KDC is the GSS-API
+   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 [RFC4120], the addresses field of the AS-REQ and
+   TGS-REQ requests SHOULD be blank and the caddr field of the ticket
+   SHOULD similarly be left blank.
+
+
+5.  Security Considerations
+
+   Similar to other network access protocols, WS-KERB allows an
+   unauthenticated client (possibly outside the security perimeter of an
+   organization) to send messages that are proxied to interior servers.
+
+   In a scenario where DNS SRV RR's are being used to locate the KDC,
+   WS-KERB is being used, and an external attacker can modify DNS
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 6]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+   responses to the WS-KERB proxy, there are several countermeasures to
+   prevent arbitrary messages from being sent to internal servers:
+
+   1.  KDC port numbers can be statically configured on the WS-KERB
+       proxy.  In this case, the messages will always be sent to KDC's.
+       For an organization that runs KDC's on a static port (usually
+       port 88) and does not run any other servers on the same port,
+       this countermeasure would be easy to administer and should be
+       effective.
+
+   2.  The proxy can do application level sanity checking and filtering.
+       This countermeasure should eliminate many of the above attacks.
+
+   3.  DNS security can be deployed.  This countermeasure is probably
+       overkill for this particular problem, but if an organization has
+       already deployed DNS security for other reasons, then it might
+       make sense to leverage it here.  Note that Kerberos could be used
+       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
+       the proxy will be unprotected, but an attack here is at most a
+       denial of service (the initial lookup will be for the proxy's KDC
+       to facilitate Kerberos protection of subsequent DNS exchanges
+       between itself and the DNS server).
+
+
+6.  Acknowledgements
+
+   The server-proxy idea is based on the early revisions of this
+   document written by Jonathan Trostle, Michael Swift, Bernard Aboba
+   and Glen Zorn.
+
+   The rest of the ideas mostly came from hallway conversations between
+   the author and Nicolas Williams.
+
+
+7.  IANA Considerations
+
+   There is no IANA action required for this document.
+
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 7]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
+              Support", draft-ietf-krb-wg-anon, work in progress.
+
+
+   [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework", 
+              draft-ietf-krb-wg-preauth-framework, work in progress.
+              
+   [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in 
+              progess.
+
+   [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos 
+              Realms", draft-ietf-krb-wg-kerberos-referrals, work in
+              progress.
+              
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).
+
+
+Author's Address
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 8]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu                      Expires April 20, 2007                 [Page 9]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-01.txt b/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-01.txt
new file mode 100644
index 00000000000..7fa7075d3dd
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-01.txt
@@ -0,0 +1,505 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                                 October 2006
+Intended status: Standards Track
+Expires: April 4, 2007
+
+
+                       Kerberos for Web Services
+                          draft-zhu-ws-kerb-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on April 4, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol and the
+   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
+   exchange messages with the KDC using the GSS-API acceptor as the
+   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
+   With these extensions, Kerberos is suitable for securing
+   communication between the client and web services over the Internet.
+
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 1]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
+   3.  GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Addresses in Tickets  . . . . . . . . . . . . . . . . . . . . . 6
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 2]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+1.  Introduction
+
+   The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
+   promises minimal or no exposure of weak client keys and strong client
+   authentication.  The Kerberos support of anonymity [KRB-ANON]
+   provides for privacy.  These advancements make Kerberos suitable over
+   the Internet.
+
+   The traditional client-push Kerberos protocol does not work well in
+   the Web services environments where the KDC is not accessible to the
+   client, but is accessible to the web server.  For example, the KDC is
+   commonly placed behind a firewall together with the application
+   server.  The lack of accessibility to the KDC by the client could
+   also occur are when the client does not have an IP address prior to
+   authenticating to an access point.
+
+   Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743] allows security mechanisms exchange arbitrary messages
+   between the initiator and the acceptor via the application traffic,
+   independent of the underlying transports.  A protocol based on
+   [RFC4121] is thus defined to allow the GSS-API initiator to exchange
+   Kerberos messages with the KDC by using the GSS-API acceptor as the
+   proxy.  The acceptor-pull model defined in this specification is
+   benefical for initiators with limited processing power such as mobile
+   devices, or when the transport layer between the initiator and the
+   acceptor has high network latency.
+
+           Client --------- WS-KERB proxy ---------- KDC
+
+   The Kerberos client MUST avoid exposure of long term client keys to
+   the GSS-API acceptor, before and after the Kerberos server is
+   authenticated.  This can be accomplished by using Kerberos-FAST [KRB-
+   PAFW].  Furthermore, the initiator can use the anonymous option as
+   defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity
+   from adversary who can eavesdrop the application traffic.
+
+
+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 [RFC2119].
+
+
+3.  GSS-API Encapsulation
+
+   The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
+   accordance with the mechanism proposed by [RFC4178] for negotiating
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 3]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+   protocol variations, is id-kerberos-ws.
+
+      id-kerberos-ws ::=
+        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
+          webService(6) }
+
+   The first token of the GSS-API WS-KERB mechanism MUST have the
+   generic token framing described in section 3.1 of [RFC2743] with the
+   mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
+   KERB token MUST NOT have this framing.
+
+   The GSS-API WS-KERB mechanism MUST always provide mutual
+   authentication, even if the initiator does not ask for it.  When
+   mutual-authentication is performed, the GSS-API acceptor will always
+   send back an AP-REP, and as described later in this section this
+   mechanism provides integrity protection for all initiator-acceptor
+   proxy message exchanges.
+
+   The innerToken described in section 3.1 of [RFC2743] and subsequent
+   GSS-API tokens have the following formats: it starts with a two-octet
+   token-identifier (TOK_ID), followed by a WS-KERB message or a
+   Kerberos message.
+
+
+             Token/Message       TOK_ID Value in Hex
+           -----------------------------------------
+             WS_KRB_PROXY         05 01
+
+   Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
+   is defined in this document.  The TOK_ID values for [RFC4120]
+   Kerberos messages are the same as those defined for the GSS-API
+   Kerberos mechanism [RFC4121].
+
+   The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
+   structure immediately followed by a Kerberos message.  The Kerberos
+   message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
+   ERROR as defined in [RFC4120].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 4]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+           WS-KRB-HEADER ::= SEQUENCE {
+               proxy-data      [1] ProxyData,
+               ...
+           }
+
+           ProxyData :: = SEQUENCE {
+               realm           [1] Realm,
+               cookie          [3] OCTET STRING OPTIONAL,
+                  -- opaque data, if sent by the acceptor,
+                  -- MUST be copied by the client unchanged into
+                  -- the next WS-KERB message.
+               ...
+           }
+
+
+   The WS-KRB-HEADER structure and all the Kerberos messages MUST be
+   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
+   Encoding Rules (DER) [X680] [X690].
+
+   The GSS-API initiator fills out the realm field in the ProxyData of
+   the first request with the client realm.  If the client does not know
+   the client realm [REFERALS], it MUST fill it out using the client's
+   default realm name such as the realm of the client host.  Typically
+   the Kerberos message in the first WS_KRB_PROXY message from the
+   client is an AS-REQ message.
+
+   Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB
+   acceptor MUST use the proxy-data in the message from the client to
+   locate the KDC and sends the encapsulated Kerberos message to that
+   KDC.  Unless otherwise specified, the acceptor can locate the KDC per
+   Section 7.2.3.2 of [RFC4120].
+
+   In order to reduce the number of roundtrips between the initiator and
+   the acceptor, the acceptor SHOULD process any message exchange with
+   the KDC if the exchange is unauthenticated, such as client-referral
+   message exchange [REFERALS].  If the acceptor can not process the KDC
+   response by itself, for example when the knowledge of the client keys
+   is required, it sends back to the client the KDC reply message
+   encapsulated in a WS_KRB_PROXY message.  The acceptor MUST fill out
+   the realm name whose KDC produced the response.  The acceptor SHOULD
+   use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW]
+   to allow the KDC of the client's realm to obtain a service ticket
+   addressed to the acceptor, thus further reduce the number of
+   roundtrips between the GSS-API initiator and the GSS-API acceptor.
+   The GSS-API acceptor can send opaque data in the cookie field of the
+   WS-KRB-HEADER structure in the reply from the acceptor to the
+   initiator, in order to, for example, to facilitate state managements
+   on the GSS-API acceptor.  The content and the encoding of the cookie
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 5]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+   field is a local matter of the acceptor.  The initiator MUST copy the
+   verbatim cookie from the previous acceptor response, when the cookie
+   is present, whenever it sends an additional WS-KRB-PROXY message to
+   the acceptor.  The client processes the KDC response, and fills out
+   the realm name it believes to whom the acceptor should send the
+   encapsulated Kerberos message.
+
+   When the client obtains a service ticket, the initiator then sends a
+   KRB_AP_REQ message to the acceptor, and proceed as defined in
+   [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
+   by the initiator.  The extension type is 2 and the content is the
+   ASN.1 DER encoding of the type Checksum.  The checksum is performed
+   over all GSS-API messages as exchanged between the initiator and the
+   acceptor before the KRB_AP_REQ message, and in the order of the
+   exchange.  The checksum type is the required checksum type for the
+   enctype of the subkey in the authenticator, the protocol key is the
+   authenticator subkey, and the key usage number is TBA-1.  The
+   acceptor MUST verify this checksum in the GSS-API authenticator
+   extension, then respond with an AP-REP extension [GSS-EXTS].  The AP-
+   REP extension type is 2 and the the content is the ASN.1 DER encoding
+   of the type Checksum.  This checksum is performed over all GSS-API
+   messages as exchanged between the initiator and the acceptor before
+   the KRB_AP_REQ message, and in the order of the exchange.  The
+   checksum type is the required checksum type for the enctype of the
+   authenticator subkey in the request, and the protocol key is the
+   authenticator subkey, and the key usage number is TBA-2.  The
+   initiator MUST then verify this checksum.
+
+
+4.  Addresses in Tickets
+
+   In WS-KERB, the machine sending requests to the KDC is the GSS-API
+   acceptor and not the initiator.  As a result, the initiator 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 [RFC4120], the addresses field of the
+   AS-REQ and TGS-REQ requests SHOULD be blank and the caddr field of
+   the ticket SHOULD similarly be left blank.
+
+
+5.  Security Considerations
+
+   Similar to other network access protocols, WS-KERB allows an
+   unauthenticated client (possibly outside the security perimeter of an
+   organization) to send messages that are proxied to interior servers.
+
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 6]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+   In a scenario where DNS SRV RR's are being used to locate the KDC,
+   WS-KERB is being used, and an external attacker can modify DNS
+   responses to the WS-KERB proxy, there are several countermeasures to
+   prevent arbitrary messages from being sent to internal servers:
+
+   1.  KDC port numbers can be statically configured on the WS-KERB
+       proxy.  In this case, the messages will always be sent to KDC's.
+       For an organization that runs KDC's on a static port (usually
+       port 88) and does not run any other servers on the same port,
+       this countermeasure would be easy to administer and should be
+       effective.
+
+   2.  The proxy can do application level sanity checking and filtering.
+       This countermeasure should eliminate many of the above attacks.
+
+   3.  DNS security can be deployed.  This countermeasure is probably
+       overkill for this particular problem, but if an organization has
+       already deployed DNS security for other reasons, then it might
+       make sense to leverage it here.  Note that Kerberos could be used
+       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
+       the proxy will be unprotected, but an attack here is at most a
+       denial of service (the initial lookup will be for the proxy's KDC
+       to facilitate Kerberos protection of subsequent DNS exchanges
+       between itself and the DNS server).
+
+
+6.  Acknowledgements
+
+   The acceptor-proxy idea is based on the early revisions of this
+   document written by Jonathan Trostle, Michael Swift, Bernard Aboba
+   and Glen Zorn.
+
+   The rest of the ideas mostly came from hallway conversations between
+   the author and Nicolas Williams.
+
+
+7.  IANA Considerations
+
+   There is no IANA action required for this document.
+
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 7]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
+              Support", draft-ietf-krb-wg-anon, work in progress.
+
+   [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework", 
+              draft-ietf-krb-wg-preauth-framework, work in progress.
+              
+   [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in 
+              progess.
+
+   [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos 
+              Realms", draft-ietf-krb-wg-kerberos-referrals, work in
+              progress.
+              
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).
+
+
+Author's Address
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 8]
+
+Internet-Draft                   WS-KERB                    October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu                       Expires April 4, 2007                 [Page 9]
+
+
diff --git a/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-03.txt b/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-03.txt
new file mode 100644
index 00000000000..7b091af416d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/draft-zhu-ws-kerb-03.txt
@@ -0,0 +1,616 @@
+
+
+NETWORK WORKING GROUP                                             L. Zhu
+Internet-Draft                                     Microsoft Corporation
+Updates: 4120 (if approved)                                    J. Altman
+Intended status: Standards Track                        Secure Endpoints
+Expires: January 10, 2008                                   July 9, 2007
+
+
+ Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
+                              API (IAKERB)
+                          draft-zhu-ws-kerb-03
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   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 Internet-Draft will expire on January 10, 2008.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol and the
+   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
+   exchange messages with the KDC using the GSS-API acceptor as the
+   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
+   With these extensions a client can obtain Kerberos tickets for
+   services where the KDC is not accessible to the client, but is
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 1]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   accessible to the application server.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  GSS-API Encapsulation  . . . . . . . . . . . . . . . . . . . .  3
+   4.  Addresses in Tickets . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
+     8.2.  Informative references . . . . . . . . . . . . . . . . . .  9
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 2]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+1.  Introduction
+
+   When authenticating using Kerberos V5, clients obtain tickets from a
+   KDC and present them to services.  This model of operation cannot
+   work if the client does not have access to the KDC.  For example, in
+   remote access scenarios, the client must initially authenticate to an
+   access point in order to gain full access to the network.  Here the
+   client may be unable to directly contact the KDC either because it
+   does not have an IP address, or the access point packet filter does
+   not allow the client to send packets to the Internet before it
+   authenticates to the access point.
+
+   Recent advancements in extending Kerberos permit Kerberos
+   authentication to complete with the assistance of a proxy.  The
+   Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents
+   the exposure of weak client keys over the open network.  The Kerberos
+   support of anonymity [KRB-ANON] provides for privacy and further
+   complicates traffic analysis.  The kdc-referrals option defined in
+   [KRB-PAFW] may reduce the number of messages exchanged while
+   obtaining a ticket to exactly two even in cross-realm
+   authentications.
+
+   Building upon these Kerberos extensions, this document extends
+   [RFC4120] and [RFC4121] such that the client can communicate with the
+   KDC using a Generic Security Service Application Program Interface
+   (GSS-API) [RFC2743] acceptor as the proxy.  The GSS-API acceptor
+   relays the KDC request and reply messages between the client and the
+   KDC.  The GSS-API acceptor, when relaying the Kerberos messages, is
+   called an IAKERB proxy.  Consequently, IAKERB as defined in this
+   document requires the use of GSS-API.
+
+
+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 [RFC2119].
+
+
+3.  GSS-API Encapsulation
+
+   The mechanism Objection Identifier (OID) for GSS-API IAKERB, in
+   accordance with the mechanism proposed by [RFC4178] for negotiating
+   protocol variations, is id-kerberos-iakerb:
+
+      id-kerberos-iakerb ::=
+        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
+          iakerb(5) }
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 3]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   The initial context establishment token of IAKERB MUST have the
+   generic token framing described in section 3.1 of [RFC2743] with the
+   mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB
+   context establishment token MUST NOT have this token framing.
+
+   The client starts by constructing the ticket request, and if the
+   ticket request is being made to the KDC, the client, instead of
+   contacting the KDC directly, encapsulates the request message into
+   the output token of the GSS_Init_security_context() call and returns
+   GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
+   token is required in order to establish the context.  The output
+   token is then passed for use as the input token to the
+   GSS_Accept_sec_context() call in accordance with GSS-API.  The GSS-
+   API acceptor extracts the Kerberos request in the input token,
+   locates the target KDC, and sends the request on behalf of the
+   client.  After receiving the KDC reply, the GSS-API acceptor then
+   encapsulates the reply message into the output token of
+   GSS_Accept_sec_context().  The GSS-API acceptor returns
+   GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
+   token is required in order to establish the context.  The output
+   token is passed to the initiator in accordance with GSS-API.
+
+          Client <---------> IAKERB proxy <---------> KDC
+
+   The innerToken described in section 3.1 of [RFC2743] and subsequent
+   GSS-API mechanism tokens have the following formats: it starts with a
+   two-octet token-identifier (TOK_ID), followed by an IAKERB message or
+   a Kerberos message.
+
+   Only one IAKERB specific message, namely the IAKERB_PROXY message, is
+   defined in this document.  The TOK_ID values for Kerberos messages
+   are the same as defined in [RFC4121].
+
+                 Token          TOK_ID Value in Hex
+              --------------------------------------
+               IAKERB_PROXY           05 01
+
+   The content of the IAKERB_PROXY message is defined as an IAKERB-
+   HEADER structure immediately followed by a Kerberos message.  The
+   Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP,
+   or a KRB-ERROR as defined in [RFC4120].
+
+
+
+
+
+
+
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 4]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+           IAKERB-HEADER ::= SEQUENCE {
+               target-realm      [1] UTF8String,
+                  -- The name of the target realm.
+               cookie            [2] OCTET STRING OPTIONAL,
+                  -- Opaque data, if sent by the server,
+                  -- MUST be copied by the client verbatim into
+                  -- the next IAKRB_PROXY message.
+               ...
+           }
+
+   The IAKERB-HEADER structure and all the Kerberos messages MUST be
+   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
+   Encoding Rules (DER) [X680] [X690].
+
+   The IAKERB client fills out the IAKERB-HEADER structure as follows:
+   the target-realm contains the realm name the ticket request is
+   addressed to.  In the initial message from the client, the cookie
+   field is absent.  The client MUST specify a target-realm.  If the
+   client does not know the realm of the client's true principal name
+   [REFERALS], it MUST specify a realm it knows.  This can be the realm
+   of the client's host.
+
+   Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor
+   inspects the target-realm field in the IAKERB_HEADER, and locates a
+   KDC of that realm, and sends the ticket request to that KDC.
+
+   When the GSS-API acceptor is unable to obtain an IP address for a KDC
+   in the client's realm, it sends a KRB_ERROR message with the code
+   KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails
+   to establish.  There is no accompanying error data defined in this
+   document for this error code.
+
+           KRB_AP_ERR_IAKERB_KDC_NOT_FOUND      85
+               -- The IAKERB proxy could not find a KDC.
+
+   When the GSS-API acceptor has an IP address for a KDC in the client
+   realm, but does not receive a response from any KDC in the realm
+   (including in response to retries), it sends a KRB_ERROR message with
+   the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the
+   context fails to establish.  There is no accompanying error data
+   defined in this document for this error code.
+
+           KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE    86
+               -- The KDC did not respond to the IAKERB proxy.
+
+   The IAKERB proxy can send opaque data in the cookie field of the
+   IAKERB-HEADER structure in the server reply to the client, in order
+   to, for example, minimize the amount of state information kept by the
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 5]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   GSS-API acceptor.  The content and the encoding of the cookie field
+   is a local matter of the IAKERB proxy.  The client MUST copy the
+   cookie verbatim from the previous server response whenever the cookie
+   is present into the subsequent tokens that contains an IAKERB_PROXY
+   message.
+
+   When the client obtained a service ticket, the client sends a
+   KRB_AP_REQ message to the server, and performs the client-server
+   application exchange as defined in [RFC4120] and [RFC4121].
+
+   For implementations comforming to this specification, the
+   authenticator subkey in the AP-REQ MUST alway be present, and the
+   Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an
+   extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data
+   contains the ASN.1 DER encoding of the structure IAKERB-FINISHED.
+
+           GSS_EXTS_IAKERB_FINISHED             TBD
+                --- Data type for the IAKERB checksum.
+
+           IAKERB-FINISHED ::= {
+                iakerb-messages [1] Checksum,
+                    -- Contains the checksum of the GSS-API tokens
+                    -- exchanged between the initiator and the acceptor,
+                    -- and prior to the containing AP_REQ GSS-API token.
+                    -- The checksum is performed over the GSS-API tokens
+                    -- in the order that the tokens were sent.
+                 ...
+           }
+
+   The iakerb-messages field in the IAKERB-FINISHED structure contains a
+   checksum of all the GSS-API tokens exchanged between the initiator
+   and the acceptor, and prior to the GSS-API token containing the
+   AP_REQ.  This checksum is performed over these GSS-API tokens in the
+   order that the tokens were sent.  In the parlance of [RFC3961], the
+   checksum type is the required checksum type for the enctype of the
+   subkey in the authenticator, the protocol key for the checksum
+   operation is the authenticator subkey, and the key usage number is
+   KEY_USAGE_IAKERB_FINISHED.
+
+           KEY_USAGE_IAKERB_FINISHED            42
+
+   The GSS-API acceptor MUST then verify the checksum contained in the
+   GSS_EXTS_IAKERB_FINISHED extension.  This checksum provides integrity
+   protection for the messages exchanged including the unauthenticated
+   clear texts in the IAKERB-HEADER structure.
+
+   If the pre-authentication data is encrypted in the long-term
+   password-based key of the principal, the risk of security exposures
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 6]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   is significant.  Implementations SHOULD provide the AS_REQ armoring
+   as defined in [KRB-PAFW] unless an alternative protection is
+   deployed.  In addition, the anonymous Kerberos FAST option is
+   RECOMMENDED for the client to complicate traffic analysis.
+
+
+4.  Addresses in Tickets
+
+   In IAKERB, the machine sending requests to the KDC is the GSS-API
+   acceptor 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 [RFC4120], the addresses field of the AS-REQ and
+   TGS-REQ requests SHOULD be blank and the caddr field of the ticket
+   SHOULD similarly be left blank.
+
+
+5.  Security Considerations
+
+   A typical IAKERB client sends the AS_REQ with pre-authentication data
+   encrypted in the long-term keys of the user before the server is
+   authenticated.  This enables offline attacks by un-trusted servers.
+   To mitigate this threat, the client SHOULD use Kerberos
+   FAST[KRB-PAFW] and require KDC authentication to protect the user's
+   credentials.
+
+   The client name is in clear text in the authentication exchange
+   messages and ticket granting service exchanges according to [RFC4120]
+   whereas the client name is encrypted in client- server application
+   exchange messages.  By using the IAKERB proxy to relay the ticket
+   requests and responses, the client's identity could be revealed in
+   the client-server traffic where the same identity could have been
+   concealed if IAKERB were not used.  Hence, to complicate traffic
+   analysis and provide privacy for the IAKERB client, the IAKERB client
+   SHOULD request the anonymous Kerberos FAST option [KRB-PAFW].
+
+   Similar to other network access protocols, IAKERB allows an
+   unauthenticated client (possibly outside the security perimeter of an
+   organization) to send messages that are proxied to interior servers.
+
+   In a scenario where DNS SRV RR's are being used to locate the KDC,
+   IAKERB is being used, and an external attacker can modify DNS
+   responses to the IAKERB proxy, there are several countermeasures to
+   prevent arbitrary messages from being sent to internal servers:
+
+
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 7]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   1.  KDC port numbers can be statically configured on the IAKERB
+       proxy.  In this case, the messages will always be sent to KDC's.
+       For an organization that runs KDC's on a static port (usually
+       port 88) and does not run any other servers on the same port,
+       this countermeasure would be easy to administer and should be
+       effective.
+
+   2.  The proxy can do application level sanity checking and filtering.
+       This countermeasure should eliminate many of the above attacks.
+
+   3.  DNS security can be deployed.  This countermeasure is probably
+       overkill for this particular problem, but if an organization has
+       already deployed DNS security for other reasons, then it might
+       make sense to leverage it here.  Note that Kerberos could be used
+       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
+       the proxy will be unprotected, but an attack here is at most a
+       denial of service (the initial lookup will be for the proxy's KDC
+       to facilitate Kerberos protection of subsequent DNS exchanges
+       between itself and the DNS server).
+
+
+6.  Acknowledgements
+
+   Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
+   earlier revision of this document.
+
+   The hallway conversations between Larry Zhu and Nicolas Williams
+   formed the basis of this document.
+
+
+7.  IANA Considerations
+
+   There is no IANA action required for this document.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [GSS-EXTS]
+              Emery, S., "Kerberos Version 5 GSS-API Channel Binding
+              Hash Agility",
+              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in
+              progress), 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 8]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+8.2.  Informative references
+
+   [KRB-ANON]
+              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
+              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
+
+   [KRB-PAFW]
+              Zhu, L. and S. Hartman, "A Generalized Framework for
+              Kerberos Pre-Authentication",
+              draft-ietf-krb-wg-preauth-framework-06.txt (work in
+              progress), 2007.
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Email: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+Zhu & Altman            Expires January 10, 2008                [Page 9]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+   Jeffery Altman
+   Secure Endpoints
+   255 W 94th St
+   New York, NY  10025
+   US
+
+   Email: jaltman@secure-endpoints.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Altman            Expires January 10, 2008               [Page 10]
+
+Internet-Draft                   IAKERB                        July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Zhu & Altman            Expires January 10, 2008               [Page 11]
+
+
diff --git a/third_party/heimdal/doc/standardisation/rc4-hmac.txt b/third_party/heimdal/doc/standardisation/rc4-hmac.txt
new file mode 100644
index 00000000000..9ebe39e0aab
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rc4-hmac.txt
@@ -0,0 +1,589 @@
+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/third_party/heimdal/doc/standardisation/rfc1508.txt b/third_party/heimdal/doc/standardisation/rfc1508.txt
new file mode 100644
index 00000000000..132b855e05e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc1508.txt
@@ -0,0 +1,2747 @@
+
+
+
+
+
+
+Network Working Group                                            J. Linn
+Request for Comments: 1508                         Geer Zolot Associates
+                                                          September 1993
+
+
+         Generic Security Service Application Program Interface
+
+Status of this Memo
+
+   This RFC specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" for the standardization state and status
+   of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This Generic Security Service Application Program Interface (GSS-API)
+   definition provides security services to callers in a generic
+   fashion, supportable with a range of underlying mechanisms and
+   technologies and hence allowing source-level portability of
+   applications to different environments. This specification defines
+   GSS-API services and primitives at a level independent of underlying
+   mechanism and programming language environment, and is to be
+   complemented by other, related specifications:
+
+        documents defining specific parameter bindings for particular
+        language environments
+
+        documents defining token formats, protocols, and procedures to
+        be implemented in order to realize GSS-API services atop
+        particular security mechanisms
+
+Table of Contents
+
+   1. GSS-API Characteristics and Concepts .......................    2
+   1.1. GSS-API Constructs .......................................    5
+   1.1.1.  Credentials ...........................................    5
+   1.1.2.  Tokens ................................................    6
+   1.1.3.  Security Contexts .....................................    7
+   1.1.4.  Mechanism Types .......................................    8
+   1.1.5.  Naming ................................................    9
+   1.1.6.  Channel Bindings ......................................   10
+   1.2.  GSS-API Features and Issues .............................   11
+   1.2.1.  Status Reporting ......................................   11
+   1.2.2.  Per-Message Security Service Availability .............   12
+   1.2.3.  Per-Message Replay Detection and Sequencing ...........   13
+   1.2.4.  Quality of Protection .................................   15
+
+
+
+Linn                                                            [Page 1]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   2. Interface Descriptions .....................................   15
+   2.1.  Credential management calls .............................   17
+   2.1.1.  GSS_Acquire_cred call .................................   17
+   2.1.2.  GSS_Release_cred call .................................   19
+   2.1.3.  GSS_Inquire_cred call .................................   20
+   2.2.  Context-level calls .....................................   21
+   2.2.1.  GSS_Init_sec_context call .............................   21
+   2.2.2.  GSS_Accept_sec_context call ...........................   26
+   2.2.3.  GSS_Delete_sec_context call ...........................   29
+   2.2.4.  GSS_Process_context_token call ........................   30
+   2.2.5.  GSS_Context_time call .................................   31
+   2.3.  Per-message calls .......................................   32
+   2.3.1.  GSS_Sign call .........................................   32
+   2.3.2.  GSS_Verify call .......................................   33
+   2.3.3.  GSS_Seal call .........................................   35
+   2.3.4.  GSS_Unseal call .......................................   36
+   2.4.  Support calls ...........................................   37
+   2.4.1.  GSS_Display_status call ...............................   37
+   2.4.2.  GSS_Indicate_mechs call ...............................   38
+   2.4.3.  GSS_Compare_name call .................................   38
+   2.4.4.  GSS_Display_name call .................................   39
+   2.4.5.  GSS_Import_name call ..................................   40
+   2.4.6.  GSS_Release_name call .................................   41
+   2.4.7.  GSS_Release_buffer call ...............................   41
+   2.4.8.  GSS_Release_oid_set call ..............................   42
+   3. Mechanism-Specific Example Scenarios .......................   42
+   3.1.  Kerberos V5, single-TGT .................................   43
+   3.2.  Kerberos V5, double-TGT .................................   43
+   3.3.  X.509 Authentication Framework ..........................   44
+   4. Related Activities .........................................   45
+   5. Acknowledgments ............................................   46
+   6. Security Considerations ....................................   46
+   7. Author's Address ...........................................   46
+   Appendix A ....................................................   47
+   Appendix B ....................................................   48
+   Appendix C ....................................................   49
+
+1. GSS-API Characteristics and Concepts
+
+   The operational paradigm in which GSS-API operates is as follows. A
+   typical GSS-API caller is itself a communications protocol, calling
+   on GSS-API in order to protect its communications with
+   authentication, integrity, and/or confidentiality security services.
+   A GSS-API caller accepts tokens provided to it by its local GSS-API
+   implementation and transfers the tokens to a peer on a remote system;
+   that peer passes the received tokens to its local GSS-API
+   implementation for processing. The security services available
+   through GSS-API in this fashion are implementable (and have been
+
+
+
+Linn                                                            [Page 2]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   implemented) over a range of underlying mechanisms based on secret-
+   key and public-key cryptographic technologies.
+
+   The GSS-API separates the operations of initializing a security
+   context between peers, achieving peer entity authentication (This
+   security service definition, and other definitions used in this
+   document, corresponds to that provided in International Standard ISO
+   7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context() and
+   GSS_Accept_sec_context() calls), from the operations of providing
+   per-message data origin authentication and data integrity protection
+   (GSS_Sign() and GSS_Verify() calls) for messages subsequently
+   transferred in conjunction with that context. Per-message GSS_Seal()
+   and GSS_Unseal() calls provide the data origin authentication and
+   data integrity services which GSS_Sign() and GSS_Verify() offer, and
+   also support selection of confidentiality services as a caller
+   option.  Additional calls provide supportive functions to the GSS-
+   API's users.
+
+   The following paragraphs provide an example illustrating the
+   dataflows involved in use of the GSS-API by a client and server in a
+   mechanism-independent fashion, establishing a security context and
+   transferring a protected message. The example assumes that credential
+   acquisition has already been completed.  The example assumes that the
+   underlying authentication technology is capable of authenticating a
+   client to a server using elements carried within a single token, and
+   of authenticating the server to the client (mutual authentication)
+   with a single returned token; this assumption holds for presently-
+   documented CAT mechanisms but is not necessarily true for other
+   cryptographic technologies and associated protocols.
+
+   The client calls GSS_Init_sec_context()  to establish a security
+   context to the server identified by targ_name, and elects to set the
+   mutual_req_flag so that mutual authentication is performed in the
+   course of context establishment. GSS_Init_sec_context()  returns an
+   output_token to be passed to the server, and indicates
+   GSS_CONTINUE_NEEDED status pending completion of the mutual
+   authentication sequence. Had mutual_req_flag not been set, the
+   initial call to GSS_Init_sec_context()  would have returned
+   GSS_COMPLETE status. The client sends the output_token to the server.
+
+   The server passes the received token as the input_token parameter to
+   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
+   GSS_COMPLETE status, provides the client's authenticated identity in
+   the src_name result, and provides an output_token to be passed to the
+   client. The server sends the output_token to the client.
+
+   The client passes the received token as the input_token parameter to
+   a successor call to GSS_Init_sec_context(),  which processes data
+
+
+
+Linn                                                            [Page 3]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   included in the token in order to achieve mutual authentication from
+   the client's viewpoint. This call to GSS_Init_sec_context()  returns
+   GSS_COMPLETE status, indicating successful mutual authentication and
+   the completion of context establishment for this example.
+
+   The client generates a data message and passes it to GSS_Seal().
+   GSS_Seal() performs data origin authentication, data integrity, and
+   (optionally) confidentiality processing on the message and
+   encapsulates the result into output_message, indicating GSS_COMPLETE
+   status. The client sends the output_message to the server.
+
+   The server passes the received message to GSS_Unseal().  GSS_Unseal
+   inverts the encapsulation performed by GSS_Seal(),  deciphers the
+   message if the optional confidentiality feature was applied, and
+   validates the data origin authentication and data integrity checking
+   quantities. GSS_Unseal()  indicates successful validation by
+   returning GSS_COMPLETE status along with the resultant
+   output_message.
+
+   For purposes of this example, we assume that the server knows by
+   out-of-band means that this context will have no further use after
+   one protected message is transferred from client to server. Given
+   this premise, the server now calls GSS_Delete_sec_context() to flush
+   context-level information. GSS_Delete_sec_context() returns a
+   context_token for the server to pass to the client.
+
+   The client passes the returned context_token to
+   GSS_Process_context_token(),  which returns GSS_COMPLETE status after
+   deleting context-level information at the client system.
+
+   The GSS-API design assumes and addresses several basic goals,
+   including:
+
+      Mechanism independence: The GSS-API defines an interface to
+      cryptographically implemented strong authentication and other
+      security services at a generic level which is independent of
+      particular underlying mechanisms. For example, GSS-API-provided
+      services can be implemented by secret-key technologies (e.g.,
+      Kerberos) or public-key approaches (e.g., X.509).
+
+      Protocol environment independence: The GSS-API is independent of
+      the communications protocol suites with which it is employed,
+      permitting use in a broad range of protocol environments. In
+      appropriate environments, an intermediate implementation "veneer"
+      which is oriented to a particular communication protocol (e.g.,
+      Remote Procedure Call (RPC)) may be interposed between
+      applications which call that protocol and the GSS-API, thereby
+      invoking GSS-API facilities in conjunction with that protocol's
+
+
+
+Linn                                                            [Page 4]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+      communications invocations.
+
+      Protocol association independence: The GSS-API's security context
+      construct is independent of communications protocol association
+      constructs. This characteristic allows a single GSS-API
+      implementation to be utilized by a variety of invoking protocol
+      modules on behalf of those modules' calling applications. GSS-API
+      services can also be invoked directly by applications, wholly
+      independent of protocol associations.
+
+      Suitability to a range of implementation placements: GSS-API
+      clients are not constrained to reside within any Trusted Computing
+      Base (TCB) perimeter defined on a system where the GSS-API is
+      implemented; security services are specified in a manner suitable
+      to both intra-TCB and extra-TCB callers.
+
+1.1. GSS-API Constructs
+
+   This section describes the basic elements comprising the GSS-API.
+
+1.1.1.  Credentials
+
+   Credentials structures provide the prerequisites enabling peers to
+   establish security contexts with each other. A caller may designate
+   that its default credential be used for context establishment calls
+   without presenting an explicit handle to that credential.
+   Alternately, those GSS-API callers which need to make explicit
+   selection of particular credentials structures may make references to
+   those credentials through GSS-API-provided credential handles
+   ("cred_handles").
+
+   A single credential structure may be used for initiation of outbound
+   contexts and acceptance of inbound contexts. Callers needing to
+   operate in only one of these modes may designate this fact when
+   credentials are acquired for use, allowing underlying mechanisms to
+   optimize their processing and storage requirements. The credential
+   elements defined by a particular mechanism may contain multiple
+   cryptographic keys, e.g., to enable authentication and message
+   encryption to be performed with different algorithms.
+
+   A single credential structure may accommodate credential information
+   associated with multiple underlying mechanisms (mech_types); a
+   credential structure's contents will vary depending on the set of
+   mech_types supported by a particular GSS-API implementation.
+   Commonly, a single mech_type will be used for all security contexts
+   established by a particular initiator to a particular target; the
+   primary motivation for supporting credential sets representing
+   multiple mech_types is to allow initiators on systems which are
+
+
+
+Linn                                                            [Page 5]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   equipped to handle multiple types to initiate contexts to targets on
+   other systems which can accommodate only a subset of the set
+   supported at the initiator's system.
+
+   It is the responsibility of underlying system-specific mechanisms and
+   OS functions below the GSS-API to ensure that the ability to acquire
+   and use credentials associated with a given identity is constrained
+   to appropriate processes within a system. This responsibility should
+   be taken seriously by implementors, as the ability for an entity to
+   utilize a principal's credentials is equivalent to the entity's
+   ability to successfully assert that principal's identity.
+
+   Once a set of GSS-API credentials is established, the transferability
+   of that credentials set to other processes or analogous constructs
+   within a system is a local matter, not defined by the GSS-API. An
+   example local policy would be one in which any credentials received
+   as a result of login to a given user account, or of delegation of
+   rights to that account, are accessible by, or transferable to,
+   processes running under that account.
+
+   The credential establishment process (particularly when performed on
+   behalf of users rather than server processes) is likely to require
+   access to passwords or other quantities which should be protected
+   locally and exposed for the shortest time possible. As a result, it
+   will often be appropriate for preliminary credential establishment to
+   be performed through local means at user login time, with the
+   result(s) cached for subsequent reference. These preliminary
+   credentials would be set aside (in a system-specific fashion) for
+   subsequent use, either:
+
+      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
+      call, returning an explicit handle to reference that credential
+
+      as the default credentials installed on behalf of a process
+
+1.1.2. Tokens
+
+   Tokens are data elements transferred between GSS-API callers, and are
+   divided into two classes. Context-level tokens are exchanged in order
+   to establish and manage a security context between peers. Per-message
+   tokens are exchanged in conjunction with an established context to
+   provide protective security services for corresponding data messages.
+   The internal contents of both classes of tokens are specific to the
+   particular underlying mechanism used to support the GSS-API; Appendix
+   B of this document provides a uniform recommendation for designers of
+   GSS-API support mechanisms, encapsulating mechanism-specific
+   information along with a globally-interpretable mechanism identifier.
+
+
+
+
+Linn                                                            [Page 6]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   Tokens are opaque from the viewpoint of GSS-API callers. They are
+   generated within the GSS-API implementation at an end system,
+   provided to a GSS-API caller to be transferred to the peer GSS-API
+   caller at a remote end system, and processed by the GSS-API
+   implementation at that remote end system. Tokens may be output by
+   GSS-API primitives (and are to be transferred to GSS-API peers)
+   independent of the status indications which those primitives
+   indicate. Token transfer may take place in an in-band manner,
+   integrated into the same protocol stream used by the GSS-API callers
+   for other data transfers, or in an out-of-band manner across a
+   logically separate channel.
+
+   Development of GSS-API support primitives based on a particular
+   underlying cryptographic technique and protocol does not necessarily
+   imply that GSS-API callers invoking that GSS-API mechanism type will
+   be able to interoperate with peers invoking the same technique and
+   protocol outside the GSS-API paradigm.  For example, the format of
+   GSS-API tokens defined in conjunction with a particular mechanism,
+   and the techniques used to integrate those tokens into callers'
+   protocols, may not be the same as those used by non-GSS-API callers
+   of the same underlying technique.
+
+1.1.3.  Security Contexts
+
+   Security contexts are established between peers, using credentials
+   established locally in conjunction with each peer or received by
+   peers via delegation. Multiple contexts may exist simultaneously
+   between a pair of peers, using the same or different sets of
+   credentials. Coexistence of multiple contexts using different
+   credentials allows graceful rollover when credentials expire.
+   Distinction among multiple contexts based on the same credentials
+   serves applications by distinguishing different message streams in a
+   security sense.
+
+   The GSS-API is independent of underlying protocols and addressing
+   structure, and depends on its callers to transport GSS-API-provided
+   data elements. As a result of these factors, it is a caller
+   responsibility to parse communicated messages, separating GSS-API-
+   related data elements from caller-provided data.  The GSS-API is
+   independent of connection vs. connectionless orientation of the
+   underlying communications service.
+
+   No correlation between security context and communications protocol
+   association is dictated. (The optional channel binding facility,
+   discussed in Section 1.1.6 of this document, represents an
+   intentional exception to this rule, supporting additional protection
+   features within GSS-API supporting mechanisms.) This separation
+   allows the GSS-API to be used in a wide range of communications
+
+
+
+Linn                                                            [Page 7]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   environments, and also simplifies the calling sequences of the
+   individual calls. In many cases (depending on underlying security
+   protocol, associated mechanism, and availability of cached
+   information), the state information required for context setup can be
+   sent concurrently with initial signed user data, without interposing
+   additional message exchanges.
+
+1.1.4.  Mechanism Types
+
+   In order to successfully establish a security context with a target
+   peer, it is necessary to identify an appropriate underlying mechanism
+   type (mech_type) which both initiator and target peers support. The
+   definition of a mechanism embodies not only the use of a particular
+   cryptographic technology (or a hybrid or choice among alternative
+   cryptographic technologies), but also definition of the syntax and
+   semantics of data element exchanges which that mechanism will employ
+   in order to support security services.
+
+   It is recommended that callers initiating contexts specify the
+   "default" mech_type value, allowing system-specific functions within
+   or invoked by the GSS-API implementation to select the appropriate
+   mech_type, but callers may direct that a particular mech_type be
+   employed when necessary.
+
+   The means for identifying a shared mech_type to establish a security
+   context with a peer will vary in different environments and
+   circumstances; examples include (but are not limited to):
+
+      use of a fixed mech_type, defined by configuration, within an
+      environment
+
+      syntactic convention on a target-specific basis, through
+      examination of a target's name
+
+      lookup of a target's name in a naming service or other database in
+      order to identify mech_types supported by that target
+
+      explicit negotiation between GSS-API callers in advance of
+      security context setup
+
+   When transferred between GSS-API peers, mech_type specifiers (per
+   Appendix B, represented as Object Identifiers (OIDs)) serve to
+   qualify the interpretation of associated tokens. (The structure and
+   encoding of Object Identifiers is defined in ISO/IEC 8824,
+   "Specification of Abstract Syntax Notation One (ASN.1)" and in
+   ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract
+   Syntax Notation One (ASN.1)".) Use of hierarchically structured OIDs
+   serves to preclude ambiguous interpretation of mech_type specifiers.
+
+
+
+Linn                                                            [Page 8]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   The OID representing the DASS MechType, for example, is
+   1.3.12.2.1011.7.5.
+
+1.1.5.  Naming
+
+   The GSS-API avoids prescription of naming structures, treating the
+   names transferred across the interface in order to initiate and
+   accept security contexts as opaque octet string quantities.  This
+   approach supports the GSS-API's goal of implementability atop a range
+   of underlying security mechanisms, recognizing the fact that
+   different mechanisms process and authenticate names which are
+   presented in different forms. Generalized services offering
+   translation functions among arbitrary sets of naming environments are
+   outside the scope of the GSS-API; availability and use of local
+   conversion functions to translate among the naming formats supported
+   within a given end system is anticipated.
+
+   Two distinct classes of name representations are used in conjunction
+   with different GSS-API parameters:
+
+      a printable form (denoted by OCTET STRING), for acceptance from
+      and presentation to users; printable name forms are accompanied by
+      OID tags identifying the namespace to which they correspond
+
+      an internal form (denoted by INTERNAL NAME), opaque to callers and
+      defined by individual GSS-API implementations; GSS-API
+      implementations supporting multiple namespace types are
+      responsible for maintaining internal tags to disambiguate the
+      interpretation of particular names
+
+      Tagging of printable names allows GSS-API callers and underlying
+      GSS-API mechanisms to disambiguate name types and to determine
+      whether an associated name's type is one which they are capable of
+      processing, avoiding aliasing problems which could result from
+      misinterpreting a name of one type as a name of another type.
+
+   In addition to providing means for names to be tagged with types,
+   this specification defines primitives to support a level of naming
+   environment independence for certain calling applications. To provide
+   basic services oriented towards the requirements of callers which
+   need not themselves interpret the internal syntax and semantics of
+   names, GSS-API calls for name comparison (GSS_Compare_name()),
+   human-readable display (GSS_Display_name()),  input conversion
+   (GSS_Import_name()), and internal name deallocation
+   (GSS_Release_name())  functions are defined. (It is anticipated that
+   these proposed GSS-API calls will be implemented in many end systems
+   based on system-specific name manipulation primitives already extant
+   within those end systems; inclusion within the GSS-API is intended to
+
+
+
+Linn                                                            [Page 9]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   offer GSS-API callers a portable means to perform specific
+   operations, supportive of authorization and audit requirements, on
+   authenticated names.)
+
+   GSS_Import_name()  implementations can, where appropriate, support
+   more than one printable syntax corresponding to a given namespace
+   (e.g., alternative printable representations for X.500 Distinguished
+   Names), allowing flexibility for their callers to select among
+   alternative representations. GSS_Display_name() implementations
+   output a printable syntax selected as appropriate to their
+   operational environments; this selection is a local matter. Callers
+   desiring portability across alternative printable syntaxes should
+   refrain from implementing comparisons based on printable name forms
+   and should instead use the GSS_Compare_name()  call to determine
+   whether or not one internal-format name matches another.
+
+1.1.6.  Channel Bindings
+
+   The GSS-API accommodates the concept of caller-provided channel
+   binding ("chan_binding") information, used by GSS-API callers to bind
+   the establishment of a security context to relevant characteristics
+   (e.g., addresses, transformed representations of encryption keys) of
+   the underlying communications channel and of protection mechanisms
+   applied to that communications channel.  Verification by one peer of
+   chan_binding information provided by the other peer to a context
+   serves to protect against various active attacks. The caller
+   initiating a security context must determine the chan_binding values
+   before making the GSS_Init_sec_context()  call, and consistent values
+   must be provided by both peers to a context. Callers should not
+   assume that underlying mechanisms provide confidentiality protection
+   for channel binding information.
+
+   Use or non-use of the GSS-API channel binding facility is a caller
+   option, and GSS-API supporting mechanisms can support operation in an
+   environment where NULL channel bindings are presented. When non-NULL
+   channel bindings are used, certain mechanisms will offer enhanced
+   security value by interpreting the bindings' content (rather than
+   simply representing those bindings, or signatures computed on them,
+   within tokens) and will therefore depend on presentation of specific
+   data in a defined format. To this end, agreements among mechanism
+   implementors are defining conventional interpretations for the
+   contents of channel binding arguments, including address specifiers
+   (with content dependent on communications protocol environment) for
+   context initiators and acceptors. (These conventions are being
+   incorporated into related documents.) In order for GSS-API callers to
+   be portable across multiple mechanisms and achieve the full security
+   functionality available from each mechanism, it is strongly
+   recommended that GSS-API callers provide channel bindings consistent
+
+
+
+Linn                                                           [Page 10]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   with these conventions and those of the networking environment in
+   which they operate.
+
+1.2.  GSS-API Features and Issues
+
+   This section describes aspects of GSS-API operations, of the security
+   services which the GSS-API provides, and provides commentary on
+   design issues.
+
+1.2.1.  Status Reporting
+
+   Each GSS-API call provides two status return values. Major_status
+   values provide a mechanism-independent indication of call status
+   (e.g., GSS_COMPLETE, GSS_FAILURE, GSS_CONTINUE_NEEDED), sufficient to
+   drive normal control flow within the caller in a generic fashion.
+   Table 1 summarizes the defined major_status return codes in tabular
+   fashion.
+
+   Table 1: GSS-API Major Status Codes
+
+      FATAL ERROR CODES
+
+      GSS_BAD_BINDINGS             channel binding mismatch
+      GSS_BAD_MECH                 unsupported mechanism requested
+      GSS_BAD_NAME                 invalid name provided
+      GSS_BAD_NAMETYPE             name of unsupported type provided
+      GSS_BAD_STATUS               invalid input status selector
+      GSS_BAD_SIG                  token had invalid signature
+      GSS_CONTEXT_EXPIRED          specified security context expired
+      GSS_CREDENTIALS_EXPIRED      expired credentials detected
+      GSS_DEFECTIVE_CREDENTIAL     defective credential detected
+      GSS_DEFECTIVE_TOKEN          defective token detected
+      GSS_FAILURE                  failure, unspecified at GSS-API
+                                   level
+      GSS_NO_CONTEXT               no valid security context specified
+      GSS_NO_CRED                  no valid credentials provided
+
+      INFORMATORY STATUS CODES
+
+      GSS_COMPLETE                 normal completion
+      GSS_CONTINUE_NEEDED          continuation call to routine
+                                   required
+      GSS_DUPLICATE_TOKEN          duplicate per-message token
+                                   detected
+      GSS_OLD_TOKEN                timed-out per-message token
+                                   detected
+      GSS_UNSEQ_TOKEN              out-of-order per-message token
+                                   detected
+
+
+
+Linn                                                           [Page 11]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   Minor_status provides more detailed status information which may
+   include status codes specific to the underlying security mechanism.
+   Minor_status values are not specified in this document.
+
+   GSS_CONTINUE_NEEDED major_status returns, and optional message
+   outputs, are provided in GSS_Init_sec_context()  and
+   GSS_Accept_sec_context()  calls so that different mechanisms'
+   employment of different numbers of messages within their
+   authentication sequences need not be reflected in separate code paths
+   within calling applications. Instead, such cases are accomodated with
+   sequences of continuation calls to GSS_Init_sec_context()  and
+   GSS_Accept_sec_context().  The same mechanism is used to encapsulate
+   mutual authentication within the GSS-API's context initiation calls.
+
+   For mech_types which require interactions with third-party servers in
+   order to establish a security context, GSS-API context establishment
+   calls may block pending completion of such third-party interactions.
+   On the other hand, no GSS-API calls pend on serialized interactions
+   with GSS-API peer entities.  As a result, local GSS-API status
+   returns cannot reflect unpredictable or asynchronous exceptions
+   occurring at remote peers, and reflection of such status information
+   is a caller responsibility outside the GSS-API.
+
+1.2.2. Per-Message Security Service Availability
+
+   When a context is established, two flags are returned to indicate the
+   set of per-message protection security services which will be
+   available on the context:
+
+      the integ_avail flag indicates whether per-message integrity and
+      data origin authentication services are available
+
+      the conf_avail flag indicates whether per-message confidentiality
+      services are available, and will never be returned TRUE unless the
+      integ_avail flag is also returned TRUE
+
+      GSS-API callers desiring per-message security services should
+      check the values of these flags at context establishment time, and
+      must be aware that a returned FALSE value for integ_avail means
+      that invocation of GSS_Sign()  or GSS_Seal() primitives on the
+      associated context will apply no cryptographic protection to user
+      data messages.
+
+   The GSS-API per-message protection service primitives, as the
+   category name implies, are oriented to operation at the granularity
+   of protocol data units. They perform cryptographic operations on the
+   data units, transfer cryptographic control information in tokens,
+   and, in the case of GSS_Seal(), encapsulate the protected data unit.
+
+
+
+Linn                                                           [Page 12]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   As such, these primitives are not oriented to efficient data
+   protection for stream-paradigm protocols (e.g., Telnet) if
+   cryptography must be applied on an octet-by-octet basis.
+
+1.2.3. Per-Message Replay Detection and Sequencing
+
+   Certain underlying mech_types are expected to offer support for
+   replay detection and/or sequencing of messages transferred on the
+   contexts they support. These optionally-selectable protection
+   features are distinct from replay detection and sequencing features
+   applied to the context establishment operation itself; the presence
+   or absence of context-level replay or sequencing features is wholly a
+   function of the underlying mech_type's capabilities, and is not
+   selected or omitted as a caller option.
+
+   The caller initiating a context provides flags (replay_det_req_flag
+   and sequence_req_flag) to specify whether the use of per-message
+   replay detection and sequencing features is desired on the context
+   being established. The GSS-API implementation at the initiator system
+   can determine whether these features are supported (and whether they
+   are optionally selectable) as a function of mech_type, without need
+   for bilateral negotiation with the target. When enabled, these
+   features provide recipients with indicators as a result of GSS-API
+   processing of incoming messages, identifying whether those messages
+   were detected as duplicates or out-of-sequence. Detection of such
+   events does not prevent a suspect message from being provided to a
+   recipient; the appropriate course of action on a suspect message is a
+   matter of caller policy.
+
+   The semantics of the replay detection and sequencing services applied
+   to received messages, as visible across the interface which the GSS-
+   API provides to its clients, are as follows:
+
+   When replay_det_state is TRUE, the possible major_status returns for
+   well-formed and correctly signed messages are as follows:
+
+      1. GSS_COMPLETE indicates that the message was within the window
+      (of time or sequence space) allowing replay events to be detected,
+      and that the message was not a replay of a previously-processed
+      message within that window.
+
+      2. GSS_DUPLICATE_TOKEN indicates that the signature on the
+      received message was correct, but that the message was recognized
+      as a duplicate of a previously-processed message.
+
+      3. GSS_OLD_TOKEN indicates that the signature on the received
+      message was correct, but that the message is too old to be checked
+      for duplication.
+
+
+
+Linn                                                           [Page 13]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   When sequence_state is TRUE, the possible major_status returns for
+   well-formed and correctly signed messages are as follows:
+
+      1. GSS_COMPLETE indicates that the message was within the window
+      (of time or sequence space) allowing replay events to be detected,
+      and that the message was not a replay of a previously-processed
+      message within that window.
+
+      2. GSS_DUPLICATE_TOKEN indicates that the signature on the
+      received message was correct, but that the message was recognized
+      as a duplicate of a previously-processed message.
+
+      3. GSS_OLD_TOKEN indicates that the signature on the received
+      message was correct, but that the token is too old to be checked
+      for duplication.
+
+      4. GSS_UNSEQ_TOKEN indicates that the signature on the received
+      message was correct, but that it is earlier in a sequenced stream
+      than a message already processed on the context.  [Note:
+      Mechanisms can be architected to provide a stricter form of
+      sequencing service, delivering particular messages to recipients
+      only after all predecessor messages in an ordered stream have been
+      delivered.  This type of support is incompatible with the GSS-API
+      paradigm in which recipients receive all messages, whether in
+      order or not, and provide them (one at a time, without intra-GSS-
+      API message buffering) to GSS-API routines for validation.  GSS-
+      API facilities provide supportive functions, aiding clients to
+      achieve strict message stream integrity in an efficient manner in
+      conjunction with sequencing provisions in communications
+      protocols, but the GSS-API does not offer this level of message
+      stream integrity service by itself.]
+
+   As the message stream integrity features (especially sequencing) may
+   interfere with certain applications' intended communications
+   paradigms, and since support for such features is likely to be
+   resource intensive, it is highly recommended that mech_types
+   supporting these features allow them to be activated selectively on
+   initiator request when a context is established. A context initiator
+   and target are provided with corresponding indicators
+   (replay_det_state and sequence_state), signifying whether these
+   features are active on a given context.
+
+   An example mech_type supporting per-message replay detection could
+   (when replay_det_state is TRUE) implement the feature as follows: The
+   underlying mechanism would insert timestamps in data elements output
+   by GSS_Sign() and GSS_Seal(), and would maintain (within a time-
+   limited window) a cache (qualified by originator-recipient pair)
+   identifying received data elements processed by GSS_Verify() and
+
+
+
+Linn                                                           [Page 14]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   GSS_Unseal(). When this feature is active, exception status returns
+   (GSS_DUPLICATE_TOKEN, GSS_ OLD_TOKEN) will be provided when
+   GSS_Verify() or GSS_Unseal() is presented with a message which is
+   either a detected duplicate of a prior message or which is too old to
+   validate against a cache of recently received messages.
+
+1.2.4.  Quality of Protection
+
+   Some mech_types will provide their users with fine granularity
+   control over the means used to provide per-message protection,
+   allowing callers to trade off security processing overhead
+   dynamically against the protection requirements of particular
+   messages. A per-message quality-of-protection parameter (analogous to
+   quality-of-service, or QOS) selects among different QOP options
+   supported by that mechanism. On context establishment for a multi-QOP
+   mech_type, context-level data provides the prerequisite data for a
+   range of protection qualities.
+
+   It is expected that the majority of callers will not wish to exert
+   explicit mechanism-specific QOP control and will therefore request
+   selection of a default QOP. Definitions of, and choices among, non-
+   default QOP values are mechanism-specific, and no ordered sequences
+   of QOP values can be assumed equivalent across different mechanisms.
+   Meaningful use of non-default QOP values demands that callers be
+   familiar with the QOP definitions of an underlying mechanism or
+   mechanisms, and is therefore a non-portable construct.
+
+2.  Interface Descriptions
+
+   This section describes the GSS-API's service interface, dividing the
+   set of calls offered into four groups. Credential management calls
+   are related to the acquisition and release of credentials by
+   principals. Context-level calls are related to the management of
+   security contexts between principals. Per-message calls are related
+   to the protection of individual messages on established security
+   contexts. Support calls provide ancillary functions useful to GSS-API
+   callers. Table 2 groups and summarizes the calls in tabular fashion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 15]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+      Table 2:  GSS-API Calls
+
+      CREDENTIAL MANAGEMENT
+
+      GSS_Acquire_cred             acquire credentials for use
+      GSS_Release_cred             release credentials after use
+      GSS_Inquire_cred             display information about
+                                   credentials
+
+      CONTEXT-LEVEL CALLS
+
+      GSS_Init_sec_context         initiate outbound security context
+      GSS_Accept_sec_context       accept inbound security context
+      GSS_Delete_sec_context       flush context when no longer needed
+      GSS_Process_context_token    process received control token on
+                                   context
+      GSS_Context_time             indicate validity time remaining on
+                                   context
+
+      PER-MESSAGE CALLS
+
+      GSS_Sign                     apply signature, receive as token
+                                   separate from message
+      GSS_Verify                   validate signature token along with
+                                   message
+      GSS_Seal                     sign, optionally encrypt,
+                                   encapsulate
+      GSS_Unseal                   decapsulate, decrypt if needed,
+                                   validate signature
+
+      SUPPORT CALLS
+
+      GSS_Display_status           translate status codes to printable
+                                   form
+      GSS_Indicate_mechs           indicate mech_types supported on
+                                   local system
+      GSS_Compare_name             compare two names for equality
+      GSS_Display_name             translate name to printable form
+      GSS_Import_name              convert printable name to
+                                   normalized form
+      GSS_Release_name             free storage of normalized-form
+                                   name
+      GSS_Release_buffer           free storage of printable name
+      GSS_Release_oid_set          free storage of OID set object
+
+
+
+
+
+
+
+Linn                                                           [Page 16]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+2.1.  Credential management calls
+
+   These GSS-API calls provide functions related to the management of
+   credentials. Their characterization with regard to whether or not
+   they may block pending exchanges with other network entities (e.g.,
+   directories or authentication servers) depends in part on OS-specific
+   (extra-GSS-API) issues, so is not specified in this document.
+
+   The GSS_Acquire_cred()  call is defined within the GSS-API in support
+   of application portability, with a particular orientation towards
+   support of portable server applications. It is recognized that (for
+   certain systems and mechanisms) credentials for interactive users may
+   be managed differently from credentials for server processes; in such
+   environments, it is the GSS-API implementation's responsibility to
+   distinguish these cases and the procedures for making this
+   distinction are a local matter. The GSS_Release_cred()  call provides
+   a means for callers to indicate to the GSS-API that use of a
+   credentials structure is no longer required. The GSS_Inquire_cred()
+   call allows callers to determine information about a credentials
+   structure.
+
+2.1.1.  GSS_Acquire_cred call
+
+   Inputs:
+
+   o  desired_name INTERNAL NAME, -NULL requests locally-determined
+      default
+
+   o  lifetime_req INTEGER,-in seconds; 0 requests default
+
+   o  desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
+      system-selected default
+
+   o  cred_usage INTEGER-0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_cred_handle OCTET STRING,
+
+   o  actual_mechs SET OF OBJECT IDENTIFIER,
+
+   o  lifetime_rec INTEGER -in seconds, or reserved value for
+      INDEFINITE
+
+
+
+Linn                                                           [Page 17]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that requested credentials were
+      successfully established, for the duration indicated in
+      lifetime_rec, suitable for the usage requested in cred_usage, for
+      the set of mech_types indicated in actual_mechs, and that those
+      credentials can be referenced for subsequent use with the handle
+      returned in output_cred_handle.
+
+   o  GSS_BAD_MECH indicates that a mech_type unsupported by the GSS-API
+      implementation type was requested, causing the credential
+      establishment operation to fail.
+
+   o  GSS_BAD_NAMETYPE indicates that the provided desired_name is
+      uninterpretable or of a type unsupported by the supporting GSS-API
+      implementation, so no credentials could be established for the
+      accompanying desired_name.
+
+   o  GSS_BAD_NAME indicates that the provided desired_name is
+      inconsistent in terms of internally-incorporated type specifier
+      information, so no credentials could be established for the
+      accompanying desired_name.
+
+   o  GSS_FAILURE indicates that credential establishment failed for
+      reasons unspecified at the GSS-API level, including lack of
+      authorization to establish and use credentials associated with the
+      identity named in the input desired_name argument.
+
+   GSS_Acquire_cred()  is used to acquire credentials so that a
+   principal can (as a function of the input cred_usage parameter)
+   initiate and/or accept security contexts under the identity
+   represented by the desired_name input argument. On successful
+   completion, the returned output_cred_handle result provides a handle
+   for subsequent references to the acquired credentials.  Typically,
+   single-user client processes using only default credentials for
+   context establishment purposes will have no need to invoke this call.
+
+   A caller may provide the value NULL for desired_name, signifying a
+   request for credentials corresponding to a default principal
+   identity.  The procedures used by GSS-API implementations to select
+   the appropriate principal identity in response to this form of
+   request are local matters. It is possible that multiple pre-
+   established credentials may exist for the same principal identity
+   (for example, as a result of multiple user login sessions) when
+   GSS_Acquire_cred() is called; the means used in such cases to select
+   a specific credential are local matters.  The input lifetime_req
+   argument to GSS_Acquire_cred() may provide useful information for
+   local GSS-API implementations to employ in making this disambiguation
+
+
+
+Linn                                                           [Page 18]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   in a manner which will best satisfy a caller's intent.
+
+   The lifetime_rec result indicates the length of time for which the
+   acquired credentials will be valid, as an offset from the present. A
+   mechanism may return a reserved value indicating INDEFINITE if no
+   constraints on credential lifetime are imposed.  A caller of
+   GSS_Acquire_cred()  can request a length of time for which acquired
+   credentials are to be valid (lifetime_req argument), beginning at the
+   present, or can request credentials with a default validity interval.
+   (Requests for postdated credentials are not supported within the
+   GSS-API.) Certain mechanisms and implementations may bind in
+   credential validity period specifiers at a point preliminary to
+   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
+   user login procedures). As a result, callers requesting non-default
+   values for lifetime_req must recognize that such requests cannot
+   always be honored and must be prepared to accommodate the use of
+   returned credentials with different lifetimes as indicated in
+   lifetime_rec.
+
+   The caller of GSS_Acquire_cred() can explicitly specify a set of
+   mech_types which are to be accommodated in the returned credentials
+   (desired_mechs argument), or can request credentials for a system-
+   defined default set of mech_types. Selection of the system-specified
+   default set is recommended in the interests of application
+   portability. The actual_mechs return value may be interrogated by the
+   caller to determine the set of mechanisms with which the returned
+   credentials may be used.
+
+2.1.2.  GSS_Release_cred call
+
+   Input:
+
+   o  cred_handle OCTET STRING-NULL specifies default credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the credentials referenced by the
+      input cred_handle were released for purposes of subsequent access
+      by the caller. The effect on other processes which may be
+      authorized shared access to such credentials is a local matter.
+
+
+
+
+
+Linn                                                           [Page 19]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_NO_CRED indicates that no release operation was performed,
+      either because the input cred_handle was invalid or because the
+      caller lacks authorization to access the referenced credentials.
+
+   o  GSS_FAILURE indicates that the release operation failed for
+      reasons unspecified at the GSS-API level.
+
+   Provides a means for a caller to explicitly request that credentials
+   be released when their use is no longer required. Note that system-
+   specific credential management functions are also likely to exist,
+   for example to assure that credentials shared among processes are
+   properly deleted when all affected processes terminate, even if no
+   explicit release requests are issued by those processes.  Given the
+   fact that multiple callers are not precluded from gaining authorized
+   access to the same credentials, invocation of GSS_Release_cred()
+   cannot be assumed to delete a particular set of credentials on a
+   system-wide basis.
+
+2.1.3.  GSS_Inquire_cred call
+
+      Input:
+
+      o  cred_handle OCTET STRING -NULL specifies default credentials
+
+      Outputs:
+
+      o  major_status INTEGER,
+
+      o  minor_status INTEGER,
+
+      o  cred_name INTERNAL NAME,
+
+      o  lifetime_rec INTEGER -in seconds, or reserved value for
+         INDEFINITE
+
+      o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+         2=ACCEPT-ONLY
+
+      o  mech_set SET OF OBJECT IDENTIFIER
+
+      Return major_status codes:
+
+      o  GSS_COMPLETE indicates that the credentials referenced by the
+         input cred_handle argument were valid, and that the output
+         cred_name, lifetime_rec, and cred_usage values represent,
+         respectively, the credentials' associated principal name,
+         remaining lifetime, suitable usage modes, and supported
+         mechanism types.
+
+
+
+Linn                                                           [Page 20]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+      o  GSS_NO_CRED indicates that no information could be returned
+         about the referenced credentials, either because the input
+         cred_handle was invalid or because the caller lacks
+         authorization to access the referenced credentials.
+
+      o  GSS_FAILURE indicates that the release operation failed for
+         reasons unspecified at the GSS-API level.
+
+   The GSS_Inquire_cred()  call is defined primarily for the use of
+   those callers which make use of default credentials rather than
+   acquiring credentials explicitly with GSS_Acquire_cred().  It enables
+   callers to determine a credential structure's associated principal
+   name, remaining validity period, usability for security context
+   initiation and/or acceptance, and supported mechanisms.
+
+2.2.  Context-level calls
+
+   This group of calls is devoted to the establishment and management of
+   security contexts between peers. A context's initiator calls
+   GSS_Init_sec_context(),  resulting in generation of a token which the
+   caller passes to the target. At the target, that token is passed to
+   GSS_Accept_sec_context().  Depending on the underlying mech_type and
+   specified options, additional token exchanges may be performed in the
+   course of context establishment; such exchanges are accommodated by
+   GSS_CONTINUE_NEEDED status returns from GSS_Init_sec_context()  and
+   GSS_Accept_sec_context().  Either party to an established context may
+   invoke GSS_Delete_sec_context()  to flush context information when a
+   context is no longer required. GSS_Process_context_token()  is used
+   to process received tokens carrying context-level control
+   information. GSS_Context_time()  allows a caller to determine the
+   length of time for which an established context will remain valid.
+
+2.2.1.  GSS_Init_sec_context call
+
+   Inputs:
+
+   o  claimant_cred_handle OCTET STRING, -NULL specifies "use
+      default"
+
+   o  input_context_handle INTEGER, -0 specifies "none assigned
+      yet"
+
+   o  targ_name INTERNAL NAME,
+
+   o  mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
+      default"
+
+   o  deleg_req_flag BOOLEAN,
+
+
+
+Linn                                                           [Page 21]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  mutual_req_flag BOOLEAN,
+
+   o  replay_det_req_flag BOOLEAN,
+
+   o  sequence_req_flag BOOLEAN,
+
+   o  lifetime_req INTEGER,-0 specifies default lifetime
+
+   o  chan_bindings OCTET STRING,
+
+   o  input_token OCTET STRING-NULL or token received from target
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_context_handle INTEGER,
+
+   o  mech_type OBJECT IDENTIFIER, -actual mechanism always
+      indicated, never NULL
+
+   o  output_token OCTET STRING, -NULL or token to pass to context
+      target
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  lifetime_rec INTEGER - in seconds, or reserved value for
+      INDEFINITE
+
+   This call may block pending network interactions for those mech_types
+   in which an authentication server or other network entity must be
+   consulted on behalf of a context initiator in order to generate an
+   output_token suitable for presentation to a specified target.
+
+   Return major_status codes:
+
+
+
+
+Linn                                                           [Page 22]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_COMPLETE indicates that context-level information was
+      successfully initialized, and that the returned output_token will
+      provide sufficient information for the target to perform per-
+      message processing on the newly-established context.
+
+   o  GSS_CONTINUE_NEEDED indicates that control information in the
+      returned output_token must be sent to the target, and that a reply
+      must be received and passed as the input_token argument to a
+      continuation call to GSS_Init_sec_context(),  before per-message
+      processing can be performed in conjunction with this context.
+
+   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
+      the input_token failed, preventing further processing from being
+      performed based on that token.
+
+   o  GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks
+      performed on the credential structure referenced by
+      claimant_cred_handle failed, preventing further processing from
+      being performed using that credential structure.
+
+   o  GSS_BAD_SIG indicates that the received input_token contains an
+      incorrect signature, so context setup cannot be accomplished.
+
+   o  GSS_NO_CRED indicates that no context was established, either
+      because the input cred_handle was invalid, because the referenced
+      credentials are valid for context acceptor use only, or because
+      the caller lacks authorization to access the referenced
+      credentials.
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the credentials provided
+      through the input claimant_cred_handle argument are no longer
+      valid, so context establishment cannot be completed.
+
+   o  GSS_BAD_BINDINGS indicates that a mismatch between the caller-
+      provided chan_bindings and those extracted from the input_token
+      was detected, signifying a security-relevant event and preventing
+      context establishment. (This result will be returned by
+      GSS_Init_sec_context only for contexts where mutual_state is
+      TRUE.)
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided; this major status will be
+      returned only for successor calls following GSS_CONTINUE_NEEDED
+      status returns.
+
+   o  GSS_BAD_NAMETYPE indicates that the provided targ_name is of a
+      type uninterpretable or unsupported by the supporting GSS-API
+      implementation, so context establishment cannot be completed.
+
+
+
+Linn                                                           [Page 23]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_BAD_NAME indicates that the provided targ_name is inconsistent
+      in terms of internally-incorporated type specifier information, so
+      context establishment cannot be accomplished.
+
+   o  GSS_FAILURE indicates that context setup could not be accomplished
+      for reasons unspecified at the GSS-API level, and that no
+      interface-defined recovery action is available.
+
+   This routine is used by a context initiator, and ordinarily emits one
+   (or, for the case of a multi-step exchange, more than one)
+   output_token suitable for use by the target within the selected
+   mech_type's protocol. Using information in the credentials structure
+   referenced by claimant_cred_handle, GSS_Init_sec_context()
+   initializes the data structures required to establish a security
+   context with target targ_name. The claimant_cred_handle must
+   correspond to the same valid credentials structure on the initial
+   call to GSS_Init_sec_context()  and on any successor calls resulting
+   from GSS_CONTINUE_NEEDED status returns; different protocol sequences
+   modeled by the GSS_CONTINUE_NEEDED mechanism will require access to
+   credentials at different points in the context establishment
+   sequence.
+
+   The input_context_handle argument is 0, specifying "not yet
+   assigned", on the first GSS_Init_sec_context()  call relating to a
+   given context. That call returns an output_context_handle for future
+   references to this context. When continuation attempts to
+   GSS_Init_sec_context()  are needed to perform context establishment,
+   the previously-returned non-zero handle value is entered into the
+   input_context_handle argument and will be echoed in the returned
+   output_context_handle argument. On such continuation attempts (and
+   only on continuation attempts) the input_token value is used, to
+   provide the token returned from the context's target.
+
+   The chan_bindings argument is used by the caller to provide
+   information binding the security context to security-related
+   characteristics (e.g., addresses, cryptographic keys) of the
+   underlying communications channel. See Section 1.1.6 of this document
+   for more discussion of this argument's usage.
+
+   The input_token argument contains a message received from the target,
+   and is significant only on a call to GSS_Init_sec_context() which
+   follows a previous return indicating GSS_CONTINUE_NEEDED
+   major_status.
+
+   It is the caller's responsibility to establish a communications path
+   to the target, and to transmit any returned output_token (independent
+   of the accompanying returned major_status value) to the target over
+   that path. The output_token can, however, be transmitted along with
+
+
+
+Linn                                                           [Page 24]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   the first application-provided input message to be processed by
+   GSS_Sign() or GSS_Seal() in conjunction with a successfully-
+   established context.
+
+   The initiator may request various context-level functions through
+   input flags: the deleg_req_flag requests delegation of access rights,
+   the mutual_req_flag requests mutual authentication, the
+   replay_det_req_flag requests that replay detection features be
+   applied to messages transferred on the established context, and the
+   sequence_req_flag requests that sequencing be enforced. (See Section
+   1.2.3 for more information on replay detection and sequencing
+   features.)
+
+   Not all of the optionally-requestable features will be available in
+   all underlying mech_types; the corresponding return state values
+   (deleg_state, mutual_state, replay_det_state, sequence_state)
+   indicate, as a function of mech_type processing capabilities and
+   initiator-provided input flags, the set of features which will be
+   active on the context. These state indicators' values are undefined
+   unless the routine's major_status indicates COMPLETE. Failure to
+   provide the precise set of features requested by the caller does not
+   cause context establishment to fail; it is the caller's prerogative
+   to delete the context if the feature set provided is unsuitable for
+   the caller's use.  The returned mech_type value indicates the
+   specific mechanism employed on the context, and will never indicate
+   the value for "default".
+
+   The conf_avail return value indicates whether the context supports
+   per-message confidentiality services, and so informs the caller
+   whether or not a request for encryption through the conf_req_flag
+   input to GSS_Seal() can be honored. In similar fashion, the
+   integ_avail return value indicates whether per-message integrity
+   services are available (through either GSS_Sign() or GSS_Seal()) on
+   the established context.
+
+   The lifetime_req input specifies a desired upper bound for the
+   lifetime of the context to be established, with a value of 0 used to
+   request a default lifetime. The lifetime_rec return value indicates
+   the length of time for which the context will be valid, expressed as
+   an offset from the present; depending on mechanism capabilities,
+   credential lifetimes, and local policy, it may not correspond to the
+   value requested in lifetime_req.  If no constraints on context
+   lifetime are imposed, this may be indicated by returning a reserved
+   value representing INDEFINITE lifetime_req. The values of conf_avail,
+   integ_avail, and lifetime_rec are undefined unless the routine's
+   major_status indicates COMPLETE.
+
+   If the mutual_state is TRUE, this fact will be reflected within the
+
+
+
+Linn                                                           [Page 25]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   output_token. A call to GSS_Accept_sec_context() at the target in
+   conjunction with such a context will return a token, to be processed
+   by a continuation call to GSS_Init_sec_context(), in order to achieve
+   mutual authentication.
+
+2.2.2.  GSS_Accept_sec_context call
+
+   Inputs:
+
+   o  acceptor_cred_handle OCTET STRING,-NULL specifies "use
+      default"
+
+   o  input_context_handle INTEGER, -0 specifies "not yet assigned"
+
+   o  chan_bindings OCTET STRING,
+
+   o  input_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  src_name INTERNAL NAME,
+
+   o  mech_type OBJECT IDENTIFIER,
+
+   o  output_context_handle INTEGER,
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  lifetime_rec INTEGER, - in seconds, or reserved value for
+      INDEFINITE
+
+   o  delegated_cred_handle OCTET STRING,
+
+   o  output_token OCTET STRING -NULL or token to pass to context
+
+
+
+Linn                                                           [Page 26]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+      initiator
+
+   This call may block pending network interactions for those mech_types
+   in which a directory service or other network entity must be
+   consulted on behalf of a context acceptor in order to validate a
+   received input_token.
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that context-level data structures were
+      successfully initialized, and that per-message processing can now
+      be performed in conjunction with this context.
+
+   o  GSS_CONTINUE_NEEDED indicates that control information in the
+      returned output_token must be sent to the initiator, and that a
+      response must be received and passed as the input_token argument
+      to a continuation call to GSS_Accept_sec_context(), before per-
+      message processing can be performed in conjunction with this
+      context.
+
+   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
+      the input_token failed, preventing further processing from being
+      performed based on that token.
+
+   o  GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks
+      performed on the credential structure referenced by
+      acceptor_cred_handle failed, preventing further processing from
+      being performed using that credential structure.
+
+   o  GSS_BAD_SIG indicates that the received input_token contains an
+      incorrect signature, so context setup cannot be accomplished.
+
+   o  GSS_DUPLICATE_TOKEN indicates that the signature on the received
+      input_token was correct, but that the input_token was recognized
+      as a duplicate of an input_token already processed. No new context
+      is established.
+
+   o  GSS_OLD_TOKEN indicates that the signature on the received
+      input_token was correct, but that the input_token is too old to be
+      checked for duplication against previously-processed input_tokens.
+      No new context is established.
+
+   o  GSS_NO_CRED indicates that no context was established, either
+      because the input cred_handle was invalid, because the referenced
+      credentials are valid for context initiator use only, or because
+      the caller lacks authorization to access the referenced
+      credentials.
+
+
+
+
+Linn                                                           [Page 27]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the credentials provided
+      through the input acceptor_cred_handle argument are no longer
+      valid, so context establishment cannot be completed.
+
+   o  GSS_BAD_BINDINGS indicates that a mismatch between the caller-
+      provided chan_bindings and those extracted from the input_token
+      was detected, signifying a security-relevant event and preventing
+      context establishment.
+
+   o GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided; this major status will be
+      returned only for successor calls following GSS_CONTINUE_NEEDED
+      status returns.
+
+   o  GSS_FAILURE indicates that context setup could not be accomplished
+      for reasons unspecified at the GSS-API level, and that no
+      interface-defined recovery action is available.
+
+   The GSS_Accept_sec_context()  routine is used by a context target.
+   Using information in the credentials structure referenced by the
+   input acceptor_cred_handle, it verifies the incoming input_token and
+   (following the successful completion of a context establishment
+   sequence) returns the authenticated src_name and the mech_type used.
+   The acceptor_cred_handle must correspond to the same valid
+   credentials structure on the initial call to GSS_Accept_sec_context()
+   and on any successor calls resulting from GSS_CONTINUE_NEEDED status
+   returns; different protocol sequences modeled by the
+   GSS_CONTINUE_NEEDED mechanism will require access to credentials at
+   different points in the context establishment sequence.
+
+   The input_context_handle argument is 0, specifying "not yet
+   assigned", on the first GSS_Accept_sec_context()  call relating to a
+   given context. That call returns an output_context_handle for future
+   references to this context; when continuation attempts to
+   GSS_Accept_sec_context()  are needed to perform context
+   establishment, that handle value will be entered into the
+   input_context_handle argument.
+
+   The chan_bindings argument is used by the caller to provide
+   information binding the security context to security-related
+   characteristics (e.g., addresses, cryptographic keys) of the
+   underlying communications channel. See Section 1.1.6 of this document
+   for more discussion of this argument's usage.
+
+   The returned state results (deleg_state, mutual_state,
+   replay_det_state, and sequence_state) reflect the same context state
+   values as returned to GSS_Init_sec_context()'s  caller at the
+   initiator system.
+
+
+
+Linn                                                           [Page 28]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   The conf_avail return value indicates whether the context supports
+   per-message confidentiality services, and so informs the caller
+   whether or not a request for encryption through the conf_req_flag
+   input to GSS_Seal()  can be honored. In similar fashion, the
+   integ_avail return value indicates whether per-message integrity
+   services are available (through either GSS_Sign()  or GSS_Seal())  on
+   the established context.
+
+   The lifetime_rec return value indicates the length of time for which
+   the context will be valid, expressed as an offset from the present.
+   The values of deleg_state, mutual_state, replay_det_state,
+   sequence_state, conf_avail, integ_avail, and lifetime_rec are
+   undefined unless the accompanying major_status indicates COMPLETE.
+
+   The delegated_cred_handle result is significant only when deleg_state
+   is TRUE, and provides a means for the target to reference the
+   delegated credentials. The output_token result, when non-NULL,
+   provides a context-level token to be returned to the context
+   initiator to continue a multi-step context establishment sequence. As
+   noted with GSS_Init_sec_context(),  any returned token should be
+   transferred to the context's peer (in this case, the context
+   initiator), independent of the value of the accompanying returned
+   major_status.
+
+   Note: A target must be able to distinguish a context-level
+   input_token, which is passed to GSS_Accept_sec_context(),  from the
+   per-message data elements passed to GSS_Verify()  or GSS_Unseal().
+   These data elements may arrive in a single application message, and
+   GSS_Accept_sec_context()  must be performed before per-message
+   processing can be performed successfully.
+
+2.2.3. GSS_Delete_sec_context call
+
+   Input:
+
+   o  context_handle INTEGER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_context_token OCTET STRING
+
+   Return major_status codes:
+
+
+
+
+
+Linn                                                           [Page 29]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_COMPLETE indicates that the context was recognized, that
+      relevant context-specific information was flushed, and that the
+      returned output_context_token is ready for transfer to the
+      context's peer.
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provide, so no deletion was performed.
+
+   o  GSS_FAILURE indicates that the context is recognized, but that the
+      GSS_Delete_sec_context()  operation could not be performed for
+      reasons unspecified at the GSS-API level.
+
+   This call may block pending network interactions for mech_types in
+   which active notification must be made to a central server when a
+   security context is to be deleted.
+
+   This call can be made by either peer in a security context, to flush
+   context-specific information and to return an output_context_token
+   which can be passed to the context's peer informing it that the
+   peer's corresponding context information can also be flushed. (Once a
+   context is established, the peers involved are expected to retain
+   cached credential and context-related information until the
+   information's expiration time is reached or until a
+   GSS_Delete_sec_context() call is made.) Attempts to perform per-
+   message processing on a deleted context will result in error returns.
+
+2.2.4.  GSS_Process_context_token call
+
+   Inputs:
+
+   o  context_handle INTEGER,
+
+   o  input_context_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the input_context_token was
+      successfully processed in conjunction with the context referenced
+      by context_handle.
+
+   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
+      the received context_token failed, preventing further processing
+
+
+
+Linn                                                           [Page 30]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+      from being performed with that token.
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided.
+
+   o  GSS_FAILURE indicates that the context is recognized, but that the
+      GSS_Process_context_token()  operation could not be performed for
+      reasons unspecified at the GSS-API level.
+
+   This call is used to process context_tokens received from a peer once
+   a context has been established, with corresponding impact on
+   context-level state information. One use for this facility is
+   processing of the context_tokens generated by
+   GSS_Delete_sec_context();  GSS_Process_context_token() will not block
+   pending network interactions for that purpose. Another use is to
+   process tokens indicating remote-peer context establishment failures
+   after the point where the local GSS-API implementation has already
+   indicated GSS_COMPLETE status.
+
+2.2.5.  GSS_Context_time call
+
+   Input:
+
+   o  context_handle INTEGER,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  lifetime_rec INTEGER - in seconds, or reserved value for
+      INDEFINITE
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the referenced context is valid, and
+      will remain valid for the amount of time indicated in
+      lifetime_rec.
+
+   o  GSS_CONTEXT_EXPIRED indicates that data items related to the
+      referenced context have expired.
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
+      but that its associated credentials have expired.
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided.
+
+
+
+Linn                                                           [Page 31]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_FAILURE indicates that the requested operation failed for
+      reasons unspecified at the GSS-API level.
+
+   This call is used to determine the amount of time for which a
+   currently established context will remain valid.
+
+2.3.  Per-message calls
+
+   This group of calls is used to perform per-message protection
+   processing on an established security context. None of these calls
+   block pending network interactions. These calls may be invoked by a
+   context's initiator or by the context's target.  The four members of
+   this group should be considered as two pairs; the output from
+   GSS_Sign()  is properly input to GSS_Verify(),  and the output from
+   GSS_Seal() is properly input to GSS_Unseal().
+
+   GSS_Sign()  and GSS_Verify() support data origin authentication and
+   data integrity services. When GSS_Sign()  is invoked on an input
+   message, it yields a per-message token containing data items which
+   allow underlying mechanisms to provide the specified security
+   services. The original message, along with the generated per-message
+   token, is passed to the remote peer; these two data elements are
+   processed by GSS_Verify(),  which validates the message in
+   conjunction with the separate token.
+
+   GSS_Seal()  and GSS_Unseal() support caller-requested confidentiality
+   in addition to the data origin authentication and data integrity
+   services offered by GSS_Sign()  and GSS_Verify(). GSS_Seal()  outputs
+   a single data element, encapsulating optionally enciphered user data
+   as well as associated token data items.  The data element output from
+   GSS_Seal()  is passed to the remote peer and processed by
+   GSS_Unseal()  at that system. GSS_Unseal() combines decipherment (as
+   required) with validation of data items related to authentication and
+   integrity.
+
+2.3.1.  GSS_Sign call
+
+   Inputs:
+
+   o  context_handle INTEGER,
+
+   o  qop_req INTEGER,-0 specifies default QOP
+
+   o  message OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+
+
+Linn                                                           [Page 32]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  minor_status INTEGER,
+
+   o  per_msg_token OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that a signature, suitable for an
+      established security context, was successfully applied and that
+      the message and corresponding per_msg_token are ready for
+      transmission.
+
+   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
+      expired, so that the requested operation cannot be performed.
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
+      but that its associated credentials have expired, so that the
+      requested operation cannot be performed.
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided.
+
+   o  GSS_FAILURE indicates that the context is recognized, but that the
+      requested operation could not be performed for reasons unspecified
+      at the GSS-API level.
+
+   Using the security context referenced by context_handle, apply a
+   signature to the input message (along with timestamps and/or other
+   data included in support of mech_type-specific mechanisms) and return
+   the result in per_msg_token. The qop_req parameter allows quality-
+   of-protection control. The caller passes the message and the
+   per_msg_token to the target.
+
+   The GSS_Sign()  function completes before the message and
+   per_msg_token is sent to the peer; successful application of
+   GSS_Sign()  does not guarantee that a corresponding GSS_Verify() has
+   been (or can necessarily be) performed successfully when the message
+   arrives at the destination.
+
+2.3.2.  GSS_Verify call
+
+   Inputs:
+
+   o  context_handle INTEGER,
+
+   o  message OCTET STRING,
+
+   o  per_msg_token OCTET STRING
+
+
+
+
+Linn                                                           [Page 33]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   Outputs:
+
+   o  qop_state INTEGER,
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the message was successfully verified.
+
+   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
+      the received per_msg_token failed, preventing further processing
+      from being performed with that token.
+
+   o  GSS_BAD_SIG indicates that the received per_msg_token contains an
+      incorrect signature for the message.
+
+   o  GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN values
+      appear in conjunction with the optional per-message replay
+      detection features described in Section 1.2.3; their semantics are
+      described in that section.
+
+   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
+      expired, so that the requested operation cannot be performed.
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
+      but that its associated credentials have expired, so that the
+      requested operation cannot be performed.
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided.
+
+   o  GSS_FAILURE indicates that the context is recognized, but that the
+      GSS_Verify()  operation could not be performed for reasons
+      unspecified at the GSS-API level.
+
+   Using the security context referenced by context_handle, verify that
+   the input per_msg_token contains an appropriate signature for the
+   input message, and apply any active replay detection or sequencing
+   features. Return an indication of the quality-of-protection applied
+   to the processed message in the qop_state result.
+
+
+
+
+
+
+
+
+Linn                                                           [Page 34]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+2.3.3. GSS_Seal call
+
+   Inputs:
+
+   o  context_handle INTEGER,
+
+   o  conf_req_flag BOOLEAN,
+
+   o  qop_req INTEGER,-0 specifies default QOP
+
+   o  input_message OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  conf_state BOOLEAN,
+
+   o  output_message OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the input_message was successfully
+      processed and that the output_message is ready for transmission.
+
+   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
+      expired, so that the requested operation cannot be performed.
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
+      but that its associated credentials have expired, so that the
+      requested operation cannot be performed.
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided.
+
+   o  GSS_FAILURE indicates that the context is recognized, but that the
+      GSS_Seal()  operation could not be performed for reasons
+      unspecified at the GSS-API level.
+
+   Performs the data origin authentication and data integrity functions
+   of GSS_Sign().  If the input conf_req_flag is TRUE, requests that
+   confidentiality be applied to the input_message.  Confidentiality may
+   not be supported in all mech_types or by all implementations; the
+   returned conf_state flag indicates whether confidentiality was
+   provided for the input_message. The qop_req parameter allows
+   quality-of-protection control.
+
+
+
+Linn                                                           [Page 35]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   In all cases, the GSS_Seal()  call yields a single output_message
+   data element containing (optionally enciphered) user data as well as
+   control information.
+
+2.3.4. GSS_Unseal call
+
+   Inputs:
+
+   o  context_handle INTEGER,
+
+   o  input_message OCTET STRING
+
+   Outputs:
+
+   o  conf_state BOOLEAN,
+
+   o  qop_state INTEGER,
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_message OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the input_message was successfully
+      processed and that the resulting output_message is available.
+
+   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
+      the per_msg_token extracted from the input_message failed,
+      preventing further processing from being performed.
+
+   o  GSS_BAD_SIG indicates that an incorrect signature was detected for
+      the message.
+
+   o  GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN values
+      appear in conjunction with the optional per-message replay
+      detection features described in Section 1.2.3; their semantics are
+      described in that section.
+
+   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
+      expired, so that the requested operation cannot be performed.
+
+   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
+      but that its associated credentials have expired, so that the
+      requested operation cannot be performed.
+
+
+
+
+Linn                                                           [Page 36]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
+      the input context_handle provided.
+
+   o  GSS_FAILURE indicates that the context is recognized, but that the
+      GSS_Unseal()  operation could not be performed for reasons
+      unspecified at the GSS-API level.
+
+   Processes a data element generated (and optionally enciphered) by
+   GSS_Seal(),  provided as input_message. The returned conf_state value
+   indicates whether confidentiality was applied to the input_message.
+   If conf_state is TRUE, GSS_Unseal()  deciphers the input_message.
+   Returns an indication of the quality-of-protection applied to the
+   processed message in the qop_state result. GSS_Seal()  performs the
+   data integrity and data origin authentication checking functions of
+   GSS_Verify()  on the plaintext data. Plaintext data is returned in
+   output_message.
+
+2.4.  Support calls
+
+   This group of calls provides support functions useful to GSS-API
+   callers, independent of the state of established contexts. Their
+   characterization with regard to blocking or non-blocking status in
+   terms of network interactions is unspecified.
+
+2.4.1.  GSS_Display_status call
+
+   Inputs:
+
+   o  status_value INTEGER,-GSS-API major_status or minor_status
+      return value
+
+   o  status_type INTEGER,-1 if major_status, 2 if minor_status
+
+   o  mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
+      status translation
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  status_string_set SET OF OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that a valid printable status
+      representation (possibly representing more than one status event
+
+
+
+Linn                                                           [Page 37]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+      encoded within the status_value) is available in the returned
+      status_string_set.
+
+   o  GSS_BAD_MECH indicates that translation in accordance with an
+      unsupported mech_type was requested, so translation could not be
+      performed.
+
+   o  GSS_BAD_STATUS indicates that the input status_value was invalid,
+      or that the input status_type carried a value other than 1 or 2,
+      so translation could not be performed.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Provides a means for callers to translate GSS-API-returned major and
+   minor status codes into printable string representations.
+
+2.4.2.  GSS_Indicate_mechs call
+
+   Input:
+
+   o  (none)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that a set of available mechanisms has
+      been returned in mech_set.
+
+   o  GSS_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of mechanism types available on
+   the local system. This call is intended for support of specialized
+   callers who need to request non-default mech_type sets from
+   GSS_Acquire_cred(),  and should not be needed by other callers.
+
+2.4.3.  GSS_Compare_name call
+
+   Inputs:
+
+
+
+
+Linn                                                           [Page 38]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  name1 INTERNAL NAME,
+
+   o  name2 INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_equal BOOLEAN
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that name1 and name2 were comparable, and
+      that the name_equal result indicates whether name1 and name2 were
+      equal or unequal.
+
+   o  GSS_BAD_NAMETYPE indicates that one or both of name1 and name2
+      contained internal type specifiers uninterpretable by the
+      supporting GSS-API implementation, or that the two names' types
+      are different and incomparable, so the equality comparison could
+      not be completed.
+
+   o  GSS_BAD_NAME indicates that one or both of the input names was
+      ill-formed in terms of its internal type specifier, so the
+      equality comparison could not be completed.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to compare two internal name representations for
+   equality.
+
+2.4.4.  GSS_Display_name call
+
+   Inputs:
+
+   o  name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_string OCTET STRING,
+
+
+
+
+Linn                                                           [Page 39]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  name_type OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that a valid printable name representation
+      is available in the returned name_string.
+
+   o  GSS_BAD_NAMETYPE indicates that the provided name was of a type
+      uninterpretable by the supporting GSS-API implementation, so no
+      printable representation could be generated.
+
+   o  GSS_BAD_NAME indicates that the contents of the provided name were
+      inconsistent with the internally-indicated name type, so no
+      printable representation could be generated.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to translate an internal name representation into a
+   printable form with associated namespace type descriptor. The syntax
+   of the printable form is a local matter.
+
+2.4.5.  GSS_Import_name call
+
+   Inputs:
+
+   o  input_name_string OCTET STRING,
+
+   o  input_name_type OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_name INTERNAL NAME
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that a valid name representation is output
+      in output_name and described by the type value in
+      output_name_type.
+
+   o  GSS_BAD_NAMETYPE indicates that the input_name_type is unsupported
+      by the GSS-API implementation, so the import operation could not
+      be completed.
+
+
+
+
+Linn                                                           [Page 40]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  GSS_BAD_NAME indicates that the provided input_name_string is
+      ill-formed in terms of the input_name_type, so the import
+      operation could not be completed.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to provide a printable name representation, designate
+   the type of namespace in conjunction with which it should be parsed,
+   and convert that printable representation to an internal form
+   suitable for input to other GSS-API routines.  The syntax of the
+   input_name is a local matter.
+
+2.4.6. GSS_Release_name call
+
+   Inputs:
+
+   o  name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the storage associated with the input
+      name was successfully released.
+
+   o  GSS_BAD_NAME indicates that the input name argument did not
+      contain a valid name.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an internal
+   name representation.
+
+2.4.7. GSS_Release_buffer call
+
+   Inputs:
+
+   o  buffer OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+
+
+Linn                                                           [Page 41]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the storage associated with the input
+      buffer was successfully released.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an OCTET STRING
+   buffer allocated by another GSS-API call.
+
+2.4.8. GSS_Release_oid_set call
+
+   Inputs:
+
+   o  buffer SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_COMPLETE indicates that the storage associated with the input
+      object identifier set was successfully released.
+
+   o  GSS_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an object
+   identifier set object allocated by another GSS-API call.
+
+3.  Mechanism-Specific Example Scenarios
+
+   This section provides illustrative overviews of the use of various
+   candidate mechanism types to support the GSS-API. These discussions
+   are intended primarily for readers familiar with specific security
+   technologies, demonstrating how GSS-API functions can be used and
+   implemented by candidate underlying mechanisms. They should not be
+   regarded as constrictive to implementations or as defining the only
+   means through which GSS-API functions can be realized with a
+   particular underlying technology, and do not demonstrate all GSS-API
+   features with each technology.
+
+
+
+
+Linn                                                           [Page 42]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+3.1. Kerberos V5, single-TGT
+
+   OS-specific login functions yield a TGT to the local realm Kerberos
+   server; TGT is placed in a credentials structure for the client.
+   Client calls GSS_Acquire_cred()  to acquire a cred_handle in order to
+   reference the credentials for use in establishing security contexts.
+
+   Client calls GSS_Init_sec_context().  If the requested service is
+   located in a different realm, GSS_Init_sec_context()  gets the
+   necessary TGT/key pairs needed to traverse the path from local to
+   target realm; these data are placed in the owner's TGT cache. After
+   any needed remote realm resolution, GSS_Init_sec_context()  yields a
+   service ticket to the requested service with a corresponding session
+   key; these data are stored in conjunction with the context. GSS-API
+   code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
+   response(s) (in the successful case) or KRB_ERROR.
+
+   Assuming success, GSS_Init_sec_context()  builds a Kerberos-formatted
+   KRB_AP_REQ message, and returns it in output_token.  The client sends
+   the output_token to the service.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(),  which verifies the authenticator, provides
+   the service with the client's authenticated name, and returns an
+   output_context_handle.
+
+   Both parties now hold the session key associated with the service
+   ticket, and can use this key in subsequent GSS_Sign(), GSS_Verify(),
+   GSS_Seal(), and GSS_Unseal() operations.
+
+3.2. Kerberos V5, double-TGT
+
+   TGT acquisition as above.
+
+   Note: To avoid unnecessary frequent invocations of error paths when
+   implementing the GSS-API atop Kerberos V5, it seems appropriate to
+   represent "single-TGT K-V5" and "double-TGT K-V5" with separate
+   mech_types, and this discussion makes that assumption.
+
+   Based on the (specified or defaulted) mech_type,
+   GSS_Init_sec_context()  determines that the double-TGT protocol
+   should be employed for the specified target. GSS_Init_sec_context()
+   returns GSS_CONTINUE_NEEDED major_status, and its returned
+   output_token contains a request to the service for the service's TGT.
+   (If a service TGT with suitably long remaining lifetime already
+   exists in a cache, it may be usable, obviating the need for this
+   step.) The client passes the output_token to the service.  Note: this
+   scenario illustrates a different use for the GSS_CONTINUE_NEEDED
+
+
+
+Linn                                                           [Page 43]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   status return facility than for support of mutual authentication;
+   note that both uses can coexist as successive operations within a
+   single context establishment operation.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(),  which recognizes it as a request for TGT.
+   (Note that current Kerberos V5 defines no intra-protocol mechanism to
+   represent such a request.) GSS_Accept_sec_context()  returns
+   GSS_CONTINUE_NEEDED major_status and provides the service's TGT in
+   its output_token. The service sends the output_token to the client.
+
+   The client passes the received token as the input_token argument to a
+   continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
+   the received service TGT and uses it as part of a service ticket
+   request to the Kerberos authentication server, storing the returned
+   service ticket and session key in conjunction with the context.
+   GSS_Init_sec_context()  builds a Kerberos-formatted authenticator,
+   and returns it in output_token along with GSS_COMPLETE return
+   major_status. The client sends the output_token to the service.
+
+   Service passes the received token as the input_token argument to a
+   continuation call to GSS_Accept_sec_context().
+   GSS_Accept_sec_context()  verifies the authenticator, provides the
+   service with the client's authenticated name, and returns
+   major_status GSS_COMPLETE.
+
+   GSS_Sign(),  GSS_Verify(), GSS_Seal(), and GSS_Unseal()  as above.
+
+3.3.  X.509 Authentication Framework
+
+   This example illustrates use of the GSS-API in conjunction with
+   public-key mechanisms, consistent with the X.509 Directory
+   Authentication Framework.
+
+   The GSS_Acquire_cred()  call establishes a credentials structure,
+   making the client's private key accessible for use on behalf of the
+   client.
+
+   The client calls GSS_Init_sec_context(),  which interrogates the
+   Directory to acquire (and validate) a chain of public-key
+   certificates, thereby collecting the public key of the service.  The
+   certificate validation operation determines that suitable signatures
+   were applied by trusted authorities and that those certificates have
+   not expired. GSS_Init_sec_context()  generates a secret key for use
+   in per-message protection operations on the context, and enciphers
+   that secret key under the service's public key.
+
+   The enciphered secret key, along with an authenticator quantity
+
+
+
+Linn                                                           [Page 44]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   signed with the client's private key, is included in the output_token
+   from GSS_Init_sec_context().  The output_token also carries a
+   certification path, consisting of a certificate chain leading from
+   the service to the client; a variant approach would defer this path
+   resolution to be performed by the service instead of being asserted
+   by the client. The client application sends the output_token to the
+   service.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context().  GSS_Accept_sec_context() validates the
+   certification path, and as a result determines a certified binding
+   between the client's distinguished name and the client's public key.
+   Given that public key, GSS_Accept_sec_context() can process the
+   input_token's authenticator quantity and verify that the client's
+   private key was used to sign the input_token. At this point, the
+   client is authenticated to the service. The service uses its private
+   key to decipher the enciphered secret key provided to it for per-
+   message protection operations on the context.
+
+   The client calls GSS_Sign()  or GSS_Seal() on a data message, which
+   causes per-message authentication, integrity, and (optional)
+   confidentiality facilities to be applied to that message. The service
+   uses the context's shared secret key to perform corresponding
+   GSS_Verify()  and GSS_Unseal() calls.
+
+4.  Related Activities
+
+   In order to implement the GSS-API atop existing, emerging, and future
+   security mechanisms:
+
+      object identifiers must be assigned to candidate GSS-API
+      mechanisms and the name types which they support
+
+      concrete data element formats must be defined for candidate
+      mechanisms
+
+   Calling applications must implement formatting conventions which will
+   enable them to distinguish GSS-API tokens from other data carried in
+   their application protocols.
+
+   Concrete language bindings are required for the programming
+   environments in which the GSS-API is to be employed; such bindings
+   for the C language are available in an associated RFC.
+
+
+
+
+
+
+
+
+Linn                                                           [Page 45]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+5.  Acknowledgments
+
+   This proposal is the result of a collaborative effort.
+   Acknowledgments are due to the many members of the IETF Security Area
+   Advisory Group (SAAG) and the Common Authentication Technology (CAT)
+   Working Group for their contributions at meetings and by electronic
+   mail. Acknowledgments are also due to Kannan Alagappan, Doug Barlow,
+   Bill Brown, Cliff Kahn, Charlie Kaufman, Butler Lampson, Richard
+   Pitkin, Joe Tardo, and John Wray of Digital Equipment Corporation,
+   and John Carr, John Kohl, Jon Rochlis, Jeff Schiller, and Ted T'so of
+   MIT and Project Athena.  Joe Pato and Bill Sommerfeld of HP/Apollo,
+   Walt Tuvell of OSF, and Bill Griffith and Mike Merritt of AT&T,
+   provided inputs which helped to focus and clarify directions.
+   Precursor work by Richard Pitkin, presented to meetings of the
+   Trusted Systems Interoperability Group (TSIG), helped to demonstrate
+   the value of a generic, mechanism-independent security service API.
+
+6. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+7. Author's Address
+
+   John Linn
+   Geer Zolot Associates
+   One Main St.
+   Cambridge, MA  02142  USA
+
+   Phone: +1 617.374.3700
+   Email: Linn@gza.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 46]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+APPENDIX  A
+
+PACS AND AUTHORIZATION SERVICES
+
+   Consideration has been given to modifying the GSS-API service
+   interface to recognize and manipulate Privilege Attribute
+   Certificates (PACs) as in ECMA 138, carrying authorization data as a
+   side effect of establishing a security context, but no such
+   modifications have been incorporated at this time. This appendix
+   provides rationale for this decision and discusses compatibility
+   alternatives between PACs and the GSS-API which do not require that
+   PACs be made visible to GSS-API callers.
+
+   Existing candidate mechanism types such as Kerberos and X.509 do not
+   incorporate PAC manipulation features, and exclusion of such
+   mechanisms from the set of candidates equipped to fully support the
+   GSS-API seems inappropriate. Inclusion (and GSS-API visibility) of a
+   feature supported by only a limited number of mechanisms could
+   encourage the development of ostensibly portable applications which
+   would in fact have only limited portability.
+
+   The status quo, in which PACs are not visible across the GSS-API
+   interface, does not preclude implementations in which PACs are
+   carried transparently, within the tokens defined and used for certain
+   mech_types, and stored within peers' credentials and context-level
+   data structures. While invisible to API callers, such PACs could be
+   used by operating system or other local functions as inputs in the
+   course of mediating access requests made by callers. This course of
+   action allows dynamic selection of PAC contents, if such selection is
+   administratively-directed rather than caller-directed.
+
+   In a distributed computing environment, authentication must span
+   different systems; the need for such authentication provides
+   motivation for GSS-API definition and usage. Heterogeneous systems in
+   a network can intercommunicate, with globally authenticated names
+   comprising the common bond between locally defined access control
+   policies. Access control policies to which authentication provides
+   inputs are often local, or specific to particular operating systems
+   or environments. If the GSS-API made particular authorization models
+   visible across its service interface, its scope of application would
+   become less general. The current GSS-API paradigm is consistent with
+   the precedent set by Kerberos, neither defining the interpretation of
+   authorization-related data nor enforcing access controls based on
+   such data.
+
+   The GSS-API is a general interface, whose callers may reside inside
+   or outside any defined TCB or NTCB boundaries. Given this
+   characteristic, it appears more realistic to provide facilities which
+
+
+
+Linn                                                           [Page 47]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+   provide "value-added" security services to its callers than to offer
+   facilities which enforce restrictions on those callers. Authorization
+   decisions must often be mediated below the GSS-API level in a local
+   manner against (or in spite of) applications, and cannot be
+   selectively invoked or omitted at those applications' discretion.
+   Given that the GSS-API's placement prevents it from providing a
+   comprehensive solution to the authorization issue, the value of a
+   partial contribution specific to particular authorization models is
+   debatable.
+
+APPENDIX  B
+
+MECHANISM-INDEPENDENT TOKEN FORMAT
+
+   This appendix specifies a mechanism-independent level of
+   encapsulating representation for the initial token of a GSS-API
+   context establishment sequence, incorporating an identifier of the
+   mechanism type to be used on that context. Use of this format (with
+   ASN.1-encoded data elements represented in BER, constrained in the
+   interests of parsing simplicity to the Distinguished Encoding Rule
+   (DER) BER subset defined in X.509, clause 8.7) is recommended to the
+   designers of GSS-API implementations based on various mechanisms, so
+   that tokens can be interpreted unambiguously at GSS-API peers. There
+   is no requirement that the mechanism-specific innerContextToken,
+   innerMsgToken, and sealedUserData data elements be encoded in ASN.1
+   BER.
+
+          -- optional top-level token definitions to
+          -- frame different mechanisms
+
+          GSS-API DEFINITIONS ::=
+
+          BEGIN
+
+          MechType ::= OBJECT IDENTIFIER
+          -- data structure definitions
+
+          -- callers must be able to distinguish among
+          -- InitialContextToken, SubsequentContextToken,
+          -- PerMsgToken, and SealedMessage data elements
+          -- based on the usage in which they occur
+
+          InitialContextToken ::=
+          -- option indication (delegation, etc.) indicated within
+          -- mechanism-specific token
+          [APPLICATION 0] IMPLICIT SEQUENCE {
+                  thisMech MechType,
+                  innerContextToken ANY DEFINED BY thisMech
+
+
+
+Linn                                                           [Page 48]
+
+RFC 1508               Generic Security Interface         September 1993
+
+
+                     -- contents mechanism-specific
+                  }
+
+          SubsequentContextToken ::= innerContextToken ANY
+          -- interpretation based on predecessor InitialContextToken
+
+          PerMsgToken ::=
+          -- as emitted by GSS_Sign and processed by GSS_Verify
+                  innerMsgToken ANY
+
+          SealedMessage ::=
+          -- as emitted by GSS_Seal and processed by GSS_Unseal
+          -- includes internal, mechanism-defined indicator
+          -- of whether or not encrypted
+                  sealedUserData ANY
+
+          END
+
+APPENDIX  C
+
+MECHANISM DESIGN CONSTRAINTS
+
+   The following constraints on GSS-API mechanism designs are adopted in
+   response to observed caller protocol requirements, and adherence
+   thereto is anticipated in subsequent descriptions of GSS-API
+   mechanisms to be documented in standards-track Internet
+   specifications.
+
+   Use of the approach defined in Appendix B of this specification,
+   applying a mechanism type tag to the InitialContextToken, is
+   required.
+
+   It is strongly recommended that mechanisms offering per-message
+   protection services also offer at least one of the replay detection
+   and sequencing services, as mechanisms offering neither of the latter
+   will fail to satisfy recognized requirements of certain candidate
+   caller protocols.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 49]
+
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/rfc1509.txt b/third_party/heimdal/doc/standardisation/rfc1509.txt
new file mode 100644
index 00000000000..f36cd80e6dc
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc1509.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Network Working Group                                            J. Wray
+Request for Comments: 1509                 Digital Equipment Corporation
+                                                          September 1993
+
+
+               Generic Security Service API : C-bindings
+
+Status of this Memo
+
+   This RFC specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" for the standardization state and status
+   of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies C language bindings for the Generic Security
+   Service Application Program Interface (GSS-API), which is described
+   at a language-independent conceptual level in other documents.
+
+   The Generic Security Service Application Programming Interface (GSS-
+   API) provides security services to its callers, and is intended for
+   implementation atop alternative underlying cryptographic mechanisms.
+   Typically, GSS-API callers will be application protocols into which
+   security enhancements are integrated through invocation of services
+   provided by the GSS-API. The GSS-API allows a caller application to
+   authenticate a principal identity associated with a peer application,
+   to delegate rights to a peer, and to apply security services such as
+   confidentiality and integrity on a per-message basis.
+
+1. INTRODUCTION
+
+   The Generic Security Service Application Programming Interface [1]
+   provides security services to calling applications.  It allows a
+   communicating application to authenticate the user associated with
+   another application, to delegate rights to another application, and
+   to apply security services such as confidentiality and integrity on a
+   per-message basis.
+
+   There are four stages to using the GSSAPI:
+
+   (a) The application acquires a set of credentials with which it may
+       prove its identity to other processes.  The application's
+       credentials vouch for its global identity, which may or may not
+       be related to the local username under which it is running.
+
+
+
+
+
+Wray                                                            [Page 1]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   (b) A pair of communicating applications establish a joint security
+       context using their credentials.  The security context is a
+       pair of GSSAPI data structures that contain shared state
+       information, which is required in order that per-message
+       security services may be provided.  As part of the
+       establishment of a security context, the context initiator is
+       authenticated to the responder, and may require that the
+       responder is authenticated in turn.  The initiator may
+       optionally give the responder the right to initiate further
+       security contexts.  This transfer of rights is termed
+       delegation, and is achieved by creating a set of credentials,
+       similar to those used by the originating application, but which
+       may be used by the responder.  To establish and maintain the
+       shared information that makes up the security context, certain
+       GSSAPI calls will return a token data structure, which is a
+       cryptographically protected opaque data type.  The caller of
+       such a GSSAPI routine is responsible for transferring the token
+       to the peer application, which should then pass it to a
+       corresponding GSSAPI routine which will decode it and extract
+       the information.
+
+   (c) Per-message services are invoked to apply either:
+
+       (i) integrity and data origin authentication, or
+
+       (ii) confidentiality, integrity and data origin authentication
+            to application data, which are treated by GSSAPI as
+            arbitrary octet-strings.  The application transmitting a
+            message that it wishes to protect will call the appropriate
+            GSSAPI routine (sign or seal) to apply protection, specifying
+            the appropriate security context, and send the result to the
+            receiving application.  The receiver will pass the received
+            data to the corresponding decoding routine (verify or unseal)
+            to remove the protection and validate the data.
+
+   (d) At the completion of a communications session (which may extend
+       across several connections), the peer applications call GSSAPI
+       routines to delete the security context.  Multiple contexts may
+       also be used (either successively or simultaneously) within a
+       single communications association.
+
+2. GSSAPI Routines
+
+   This section lists the functions performed by each of the GSSAPI
+   routines and discusses their major parameters, describing how they
+   are to be passed to the routines.  The routines are listed in figure
+   4-1.
+
+
+
+
+Wray                                                            [Page 2]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                      Figure 4-1  GSSAPI Routines
+
+
+            Routine                               Function
+
+            gss_acquire_cred               Assume a global identity
+
+            gss_release_cred               Discard credentials
+
+            gss_init_sec_context           Initiate a security context
+                                           with a peer application
+
+            gss_accept_sec_context         Accept a security context
+                                           initiated by a peer
+                                           application
+
+            gss_process_context_token      Process a token on a security
+                                           context from a peer
+                                           application
+
+            gss_delete_sec_context         Discard a security context
+
+            gss_context_time               Determine for how long a
+                                           context will remain valid
+
+            gss_sign                       Sign a message; integrity
+                                           service
+
+            gss_verify                     Check signature on a message
+
+            gss_seal                       Sign (optionally encrypt) a
+                                           message; confidentiality
+                                           service
+
+            gss_unseal                     Verify (optionally decrypt)
+                                           message
+
+            gss_display_status             Convert an API status code
+                                           to text
+
+            gss_indicate_mechs             Determine underlying
+                                           authentication mechanism
+
+            gss_compare_name               Compare two internal-form
+                                           names
+
+            gss_display_name               Convert opaque name to text
+
+
+
+
+Wray                                                            [Page 3]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+            gss_import_name                Convert a textual name to
+                                           internal-form
+
+            gss_release_name               Discard an internal-form
+                                           name
+
+            gss_release_buffer             Discard a buffer
+
+            gss_release_oid_set            Discard a set of object
+                                           identifiers
+
+            gss_inquire_cred               Determine information about
+                                           a credential
+
+   Individual GSSAPI implementations may augment these routines by
+   providing additional mechanism-specific routines if required
+   functionality is not available from the generic forms.  Applications
+   are encouraged to use the generic routines wherever possible on
+   portability grounds.
+
+2.1. Data Types and Calling Conventions
+
+   The following conventions are used by the GSSAPI:
+
+2.1.1. Structured data types
+
+   Wherever these GSSAPI C-bindings describe structured data, only
+   fields that must be provided by all GSSAPI implementation are
+   documented.  Individual implementations may provide additional
+   fields, either for internal use within GSSAPI routines, or for use by
+   non-portable applications.
+
+2.1.2. Integer types
+
+   GSSAPI defines the following integer data type:
+
+                 OM_uint32      32-bit unsigned integer
+
+   Where guaranteed minimum bit-count is important, this portable data
+   type is used by the GSSAPI routine definitions. Individual GSSAPI
+   implementations will include appropriate typedef definitions to map
+   this type onto a built-in data type.
+
+2.1.3. String and similar data
+
+   Many of the GSSAPI routines take arguments and return values that
+   describe contiguous multiple-byte data.  All such data is passed
+   between the GSSAPI and the caller using the gss_buffer_t data type.
+
+
+
+Wray                                                            [Page 4]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   This data type is a pointer to a buffer descriptor, which consists of
+   a length field that contains the total number of bytes in the datum,
+   and a value field which contains a pointer to the actual datum:
+
+                 typedef struct gss_buffer_desc_struct {
+                    size_t  length;
+                    void    *value;
+                 } gss_buffer_desc, *gss_buffer_t;
+
+   Storage for data passed to the application by a GSSAPI routine using
+   the gss_buffer_t conventions is allocated by the GSSAPI routine.  The
+   application may free this storage by invoking the gss_release_buffer
+   routine.  Allocation of the gss_buffer_desc object is always the
+   responsibility of the application;  Unused gss_buffer_desc objects
+   may be initialized to the value GSS_C_EMPTY_BUFFER.
+
+2.1.3.1. Opaque data types
+
+   Certain multiple-word data items are considered opaque data types at
+   the GSSAPI, because their internal structure has no significance
+   either to the GSSAPI or to the caller.  Examples of such opaque data
+   types are the input_token parameter to gss_init_sec_context (which is
+   opaque to the caller), and the input_message parameter to gss_seal
+   (which is opaque to the GSSAPI).  Opaque data is passed between the
+   GSSAPI and the application using the gss_buffer_t datatype.
+
+2.1.3.2. Character strings
+
+   Certain multiple-word data items may be regarded as simple ISO
+   Latin-1 character strings.  An example of this is the
+   input_name_buffer parameter to gss_import_name.  Some GSSAPI routines
+   also return character strings.  Character strings are passed between
+   the application and the GSSAPI using the gss_buffer_t datatype,
+   defined earlier.
+
+2.1.4. Object Identifiers
+
+   Certain GSSAPI procedures take parameters of the type gss_OID, or
+   Object identifier.  This is a type containing ISO-defined tree-
+   structured values, and is used by the GSSAPI caller to select an
+   underlying security mechanism.  A value of type gss_OID has the
+   following structure:
+
+                 typedef struct gss_OID_desc_struct {
+                    OM_uint32 length;
+                    void      *elements;
+                 } gss_OID_desc, *gss_OID;
+
+
+
+
+Wray                                                            [Page 5]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   The elements field of this structure points to the first byte of an
+   octet string containing the ASN.1 BER encoding of the value of the
+   gss_OID.  The length field contains the number of bytes in this
+   value.  For example, the  gss_OID value corresponding to {iso(1)
+   identified- oganization(3) icd-ecma(12) member-company(2) dec(1011)
+   cryptoAlgorithms(7) SPX(5)} meaning SPX (Digital's X.509
+   authentication mechanism) has a length field of 7 and an elements
+   field pointing to seven octets containing the following octal values:
+   53,14,2,207,163,7,5. GSSAPI implementations should provide constant
+   gss_OID values to allow callers to request any supported mechanism,
+   although applications are encouraged on portability grounds to accept
+   the default mechanism.   gss_OID values should also be provided to
+   allow applications to specify particular name types (see section
+   2.1.10).  Applications should treat gss_OID_desc values returned by
+   GSSAPI routines as read-only.  In particular, the application should
+   not attempt to deallocate them.  The gss_OID_desc datatype is
+   equivalent to the X/Open OM_object_identifier datatype [2].
+
+2.1.5. Object Identifier Sets
+
+   Certain GSSAPI procedures take parameters of the type gss_OID_set.
+   This type represents one or more object identifiers (section 2.1.4).
+   A gss_OID_set object has the following structure:
+
+                 typedef struct gss_OID_set_desc_struct {
+                    int       count;
+                    gss_OID   elements;
+                 } gss_OID_set_desc, *gss_OID_set;
+
+   The count field contains the number of OIDs within the set.  The
+   elements field is a pointer to an array of gss_OID_desc objects, each
+   of which describes a single OID. gss_OID_set values are used to name
+   the available mechanisms supported by the GSSAPI, to request the use
+   of specific mechanisms, and to indicate which mechanisms a given
+   credential supports.  Storage associated with gss_OID_set values
+   returned to the application by the GSSAPI may be deallocated by the
+   gss_release_oid_set routine.
+
+2.1.6. Credentials
+
+   A credential handle is a caller-opaque atomic datum that identifies a
+   GSSAPI credential data structure.  It is represented by the caller-
+   opaque type gss_cred_id_t, which may be implemented as either an
+   arithmetic or a pointer type.  Credentials describe a principal, and
+   they give their holder the ability to act as that principal.  The
+   GSSAPI does not make the actual credentials available to
+   applications; instead the credential handle is used to identify a
+   particular credential, held internally by GSSAPI or underlying
+
+
+
+Wray                                                            [Page 6]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   mechanism.  Thus the credential handle contains no security-relavent
+   information, and requires no special protection by the application.
+   Depending on the implementation, a given credential handle may refer
+   to different credentials when presented to the GSSAPI by different
+   callers.  Individual GSSAPI implementations should define both the
+   scope of a credential handle and the scope of a credential itself
+   (which must be at least as wide as that of a handle).  Possibilities
+   for credential handle scope include the process that acquired the
+   handle, the acquiring process and its children, or all processes
+   sharing some local identification information (e.g., UID).  If no
+   handles exist by which a given credential may be reached, the GSSAPI
+   may delete the credential.
+
+   Certain routines allow credential handle parameters to be omitted to
+   indicate the use of a default credential.  The mechanism by which a
+   default credential is established and its scope should be defined by
+   the individual GSSAPI implementation.
+
+2.1.7. Contexts
+
+   The gss_ctx_id_t data type contains a caller-opaque atomic value that
+   identifies one end of a GSSAPI security context.  It may be
+   implemented as either an arithmetic or a pointer type. Depending on
+   the implementation, a given gss_ctx_id_t value may refer to different
+   GSSAPI security contexts when presented to the GSSAPI by different
+   callers.  The security context holds state information about each end
+   of a peer communication, including cryptographic state information.
+   Individual GSSAPI implementations should define the scope of a
+   context.  Since no way is provided by which a new gss_ctx_id_t value
+   may be obtained for an existing context, the scope of a context
+   should be the same as the scope of a gss_ctx_id_t.
+
+2.1.8. Authentication tokens
+
+   A token is a caller-opaque type that GSSAPI uses to maintain
+   synchronization between the context data structures at each end of a
+   GSSAPI security context.  The token is a cryptographically protected
+   bit-string, generated by the underlying mechanism at one end of a
+   GSSAPI security context for use by the peer mechanism at the other
+   end.  Encapsulation (if required) and transfer of the token are the
+   responsibility of the peer applications.  A token is passed between
+   the GSSAPI and the application using the gss_buffer_t conventions.
+
+2.1.9. Status values
+
+   One or more status codes are returned by each GSSAPI routine.  Two
+   distinct sorts of status codes are returned.  These are termed GSS
+   status codes and Mechanism status codes.
+
+
+
+Wray                                                            [Page 7]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+2.1.9.1. GSS status codes
+
+   GSSAPI routines return GSS status codes as their OM_uint32 function
+   value.  These codes indicate errors that are independent of the
+   underlying mechanism used to provide the security service.  The
+   errors that can be indicated via a GSS status code are either generic
+   API routine errors (errors that are defined in the GSSAPI
+   specification) or calling errors (errors that are specific to these
+   bindings).
+
+   A GSS status code can indicate a single fatal generic API error from
+   the routine and a single calling error.  In addition, supplementary
+   status information may be indicated via the setting of bits in the
+   supplementary info field of a GSS status code.
+
+   These errors are encoded into the 32-bit GSS status code as follows:
+
+      MSB                                                        LSB
+      |------------------------------------------------------------|
+      | Calling Error | Routine Error  |    Supplementary Info     |
+      |------------------------------------------------------------|
+   Bit 31           24 23            16 15                        0
+
+   Hence if a GSSAPI routine returns a GSS status code whose upper 16
+   bits contain a non-zero value, the call failed.  If the calling error
+   field is non-zero, the invoking application's call of the routine was
+   erroneous.  Calling errors are defined in table 5-1.  If the routine
+   error field is non-zero, the routine failed for one of the routine-
+   specific reasons listed below in table 5-2.  Whether or not the upper
+   16 bits indicate a failure or a success, the routine may indicate
+   additional information by setting bits in the supplementary info
+   field of the status code.  The meaning of individual bits is listed
+   below in table 5-3.
+
+                     Table 5-1  Calling Errors
+
+              Name                    Value in        Meaning
+                                        Field
+         GSS_S_CALL_INACCESSIBLE_READ     1           A required input
+                                                      parameter could
+                                                      not be read.
+         GSS_S_CALL_INACCESSIBLE_WRITE    2           A required output
+                                                      parameter could
+                                                      not be written.
+         GSS_S_CALL_BAD_STRUCTURE         3           A parameter was
+                                                      malformed
+
+
+
+
+
+Wray                                                            [Page 8]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                     Table 5-2  Routine Errors
+
+               Name             Value in       Meaning
+                                 Field
+
+         GSS_S_BAD_MECH             1      An unsupported mechanism was
+                                           requested
+         GSS_S_BAD_NAME             2      An invalid name was supplied
+         GSS_S_BAD_NAMETYPE         3      A supplied name was of an
+                                           unsupported type
+         GSS_S_BAD_BINDINGS         4      Incorrect channel bindings
+                                           were supplied
+         GSS_S_BAD_STATUS           5      An invalid status code was
+                                           supplied
+
+         GSS_S_BAD_SIG              6      A token had an invalid
+                                           signature
+         GSS_S_NO_CRED              7      No credentials were supplied
+         GSS_S_NO_CONTEXT           8      No context has been
+                                           established
+         GSS_S_DEFECTIVE_TOKEN      9      A token was invalid
+         GSS_S_DEFECTIVE_CREDENTIAL 10     A credential was invalid
+         GSS_S_CREDENTIALS_EXPIRED  11     The referenced credentials
+                                           have expired
+         GSS_S_CONTEXT_EXPIRED      12     The context has expired
+         GSS_S_FAILURE              13     Miscellaneous failure
+                                           (see text)
+
+                     Table 5-3  Supplementary Status Bits
+
+         Name                Bit Number         Meaning
+         GSS_S_CONTINUE_NEEDED   0 (LSB)  The routine must be called
+                                          again to complete its
+                                          function.
+                                          See routine documentation for
+                                          detailed description.
+         GSS_S_DUPLICATE_TOKEN   1        The token was a duplicate of
+                                          an earlier token
+         GSS_S_OLD_TOKEN         2        The token's validity period
+                                          has expired
+         GSS_S_UNSEQ_TOKEN       3        A later token has already been
+                                          processed
+
+   The routine documentation also uses the name GSS_S_COMPLETE, which is
+   a zero value, to indicate an absence of any API errors or
+   supplementary information bits.
+
+
+
+
+
+Wray                                                            [Page 9]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   All GSS_S_xxx symbols equate to complete OM_uint32 status codes,
+   rather than to bitfield values.  For example, the actual value of the
+   symbol GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is 3
+   << 16.
+
+   The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and
+   GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a GSS
+   status code and removes all but the relevant field.  For example, the
+   value obtained by applying GSS_ROUTINE_ERROR to a status code removes
+   the calling errors and supplementary info fields, leaving only the
+   routine errors field.  The values delivered by these macros may be
+   directly compared with a GSS_S_xxx symbol of the appropriate type.
+   The macro GSS_ERROR() is also provided, which when applied to a GSS
+   status code returns a non-zero value if the status code indicated a
+   calling or routine error, and a zero value otherwise.
+
+   A GSSAPI implementation may choose to signal calling errors in a
+   platform-specific manner instead of, or in addition to the routine
+   value; routine errors and supplementary info should be returned via
+   routine status values only.
+
+2.1.9.2. Mechanism-specific status codes
+
+   GSSAPI routines return a minor_status parameter, which is used to
+   indicate specialized errors from the underlying security mechanism.
+   This parameter may contain a single mechanism-specific error,
+   indicated by a OM_uint32 value.
+
+   The minor_status parameter will always be set by a GSSAPI routine,
+   even if it returns a calling error or one of the generic API errors
+   indicated above as fatal, although other output parameters may remain
+   unset in such cases.  However, output parameters that are expected to
+   return pointers to storage allocated by a routine must always set set
+   by the routine, even in the event of an error, although in such cases
+   the GSSAPI routine may elect to set the returned parameter value to
+   NULL to indicate that no storage was actually allocated.  Any length
+   field associated with such pointers (as in a gss_buffer_desc
+   structure) should also be set to zero in such cases.
+
+   The GSS status code GSS_S_FAILURE is used to indicate that the
+   underlying mechanism detected an error for which no specific GSS
+   status code is defined.  The mechanism status code will provide more
+   details about the error.
+
+2.1.10. Names
+
+   A name is used to identify a person or entity.  GSSAPI authenticates
+   the relationship between a name and the entity claiming the name.
+
+
+
+Wray                                                           [Page 10]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   Two distinct representations are defined for names:
+
+        (a) A printable form, for presentation to a user
+
+        (b) An internal form, for presentation at the API
+
+   The syntax of a printable name is defined by the GSSAPI
+   implementation, and may be dependent on local system configuration,
+   or on individual user preference.  The internal form provides a
+   canonical representation of the name that is independent of
+   configuration.
+
+   A given GSSAPI implementation may support names drawn from multiple
+   namespaces.  In such an implementation, the internal form of the name
+   must include fields that identify the namespace from which the name
+   is drawn.  The namespace from which a printable name is drawn is
+   specified by an accompanying object identifier.
+
+   Routines (gss_import_name and  gss_display_name) are provided to
+   convert names between their printable representations and the
+   gss_name_t type.  gss_import_name may support multiple syntaxes for
+   each supported namespace, allowing users the freedom to choose a
+   preferred name representation.  gss_display_name should use an
+   implementation-chosen preferred syntax for each supported name-type.
+
+   Comparison of internal-form names is accomplished via the
+   gss_compare_names routine.  This removes the need for the application
+   program to understand the syntaxes of the various printable names
+   that a given GSSAPI implementation may support.
+
+   Storage is allocated by routines that return gss_name_t values.  A
+   procedure, gss_release_name, is provided to free storage associated
+   with a name.
+
+2.1.11. Channel Bindings
+
+   GSSAPI supports the use of user-specified tags to identify a given
+   context to the peer application.  These tags are used to identify the
+   particular communications channel that carries the context.  Channel
+   bindings are communicated to the GSSAPI using the following
+   structure:
+
+
+
+
+
+
+
+
+
+
+Wray                                                           [Page 11]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                 typedef struct gss_channel_bindings_struct {
+                    OM_uint32       initiator_addrtype;
+                    gss_buffer_desc initiator_address;
+                    OM_uint32       acceptor_addrtype;
+                    gss_buffer_desc acceptor_address;
+                    gss_buffer_desc application_data;
+                 } *gss_channel_bindings_t;
+
+   The initiator_addrtype and acceptor_addrtype fields denote the type
+   of addresses contained in the initiator_address and acceptor_address
+   buffers.  The address type should be one of the following:
+
+          GSS_C_AF_UNSPEC      Unspecified address type
+          GSS_C_AF_LOCAL       Host-local address type
+          GSS_C_AF_INET        DARPA Internet address type
+          GSS_C_AF_IMPLINK     ARPAnet IMP address type (eg IP)
+          GSS_C_AF_PUP         pup protocols (eg BSP) address type
+          GSS_C_AF_CHAOS       MIT CHAOS protocol address type
+          GSS_C_AF_NS          XEROX NS address type
+          GSS_C_AF_NBS         nbs address type
+          GSS_C_AF_ECMA        ECMA address type
+          GSS_C_AF_DATAKIT     datakit protocols address type
+          GSS_C_AF_CCITT       CCITT protocols (eg X.25)
+          GSS_C_AF_SNA         IBM SNA address type
+          GSS_C_AF_DECnet      DECnet address type
+          GSS_C_AF_DLI         Direct data link interface address type
+          GSS_C_AF_LAT         LAT address type
+          GSS_C_AF_HYLINK      NSC Hyperchannel address type
+          GSS_C_AF_APPLETALK   AppleTalk address type
+          GSS_C_AF_BSC         BISYNC 2780/3780 address type
+          GSS_C_AF_DSS         Distributed system services address type
+          GSS_C_AF_OSI         OSI TP4 address type
+          GSS_C_AF_X25         X25
+          GSS_C_AF_NULLADDR    No address specified
+
+   Note that these name address families rather than specific addressing
+   formats.  For address families that contain several alternative
+   address forms, the initiator_address and acceptor_address fields must
+   contain sufficient information to determine which address form is
+   used.  When not otherwise specified, addresses should be specified in
+   network byte-order.
+
+   Conceptually, the GSSAPI concatenates the initiator_addrtype,
+   initiator_address, acceptor_addrtype, acceptor_address and
+   application_data to form an octet string.  The mechanism signs this
+   octet string, and binds the signature to the context establishment
+   token emitted by gss_init_sec_context.  The same bindings are
+   presented by the context acceptor to gss_accept_sec_context, and a
+
+
+
+Wray                                                           [Page 12]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   signature is calculated in the same way.  The calculated signature is
+   compared with that found in the token, and if the signatures differ,
+   gss_accept_sec_context will return a GSS_S_BAD_BINDINGS error, and
+   the context will not be established.  Some mechanisms may include the
+   actual channel binding data in the token (rather than just a
+   signature); applications should therefore not use confidential data
+   as channel-binding components.  Individual mechanisms may impose
+   additional constraints on addresses and address types that may appear
+   in channel bindings.  For example, a mechanism may verify that the
+   initiator_address field of the channel bindings presented to
+   gss_init_sec_context contains the correct network address of the host
+   system.
+
+2.1.12. Optional parameters
+
+   Various parameters are described as optional.  This means that they
+   follow a convention whereby a default value may be requested.  The
+   following conventions are used for omitted parameters.  These
+   conventions apply only to those parameters that are explicitly
+   documented as optional.
+
+2.1.12.1. gss_buffer_t types
+
+   Specify GSS_C_NO_BUFFER as a value.  For an input parameter this
+   signifies that default behavior is requested, while for an output
+   parameter it indicates that the information that would be returned
+   via the parameter is not required by the application.
+
+2.1.12.2. Integer types (input)
+
+   Individual parameter documentation lists values to be used to
+   indicate default actions.
+
+2.1.12.3. Integer types (output)
+
+   Specify NULL as the value for the pointer.
+
+2.1.12.4. Pointer types
+
+   Specify NULL as the value.
+
+2.1.12.5. Object IDs
+
+   Specify GSS_C_NULL_OID as the value.
+
+2.1.12.6. Object ID Sets
+
+   Specify GSS_C_NULL_OID_SET as the value.
+
+
+
+Wray                                                           [Page 13]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+2.1.12.7. Credentials
+
+   Specify GSS_C_NO_CREDENTIAL to use the default credential handle.
+
+2.1.12.8. Channel Bindings
+
+   Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings
+   are not to be used.
+
+3. GSSAPI routine descriptions
+
+2.1. gss_acquire_cred
+
+      OM_uint32  gss_acquire_cred (
+                     OM_uint32 *     minor_status,
+                     gss_name_t      desired_name,
+                     OM_uint32       time_req,
+                     gss_OID_set     desired_mechs,
+                     int             cred_usage,
+                     gss_cred_id_t * output_cred_handle,
+                     gss_OID_set *   actual_mechs,
+                      OM_int32 *      time_rec)
+   Purpose:
+
+   Allows an application to acquire a handle for a pre-existing
+   credential by name.  GSSAPI implementations must impose a local
+   access-control policy on callers of this routine to prevent
+   unauthorized callers from acquiring credentials to which they are not
+   entitled.  This routine is not intended to provide a "login to the
+   network" function, as such a function would result in the creation of
+   new credentials rather than merely acquiring a handle to existing
+   credentials.  Such functions, if required, should be defined in
+   implementation-specific extensions to the API.
+
+   If credential acquisition is time-consuming for a mechanism, the
+   mechanism may chooses to delay the actual acquisition until the
+   credential is required (e.g., by gss_init_sec_context or
+   gss_accept_sec_context).  Such mechanism-specific implementation
+   decisions should be invisible to the calling application; thus a call
+   of gss_inquire_cred immediately following the call of
+   gss_acquire_cred must return valid credential data, and may therefore
+   incur the overhead of a deferred credential acquisition.
+
+   Parameters:
+
+      desired_name      gss_name_t, read
+                        Name of principal whose credential
+                        should be acquired
+
+
+
+Wray                                                           [Page 14]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      time_req          integer, read
+                        number of seconds that credentials
+                        should remain valid
+
+      desired_mechs     Set of Object IDs, read
+                        set of underlying security mechanisms that
+                        may be used.  GSS_C_NULL_OID_SET may be used
+                        to obtain an implementation-specific default.
+
+      cred_usage        integer, read
+                        GSS_C_BOTH - Credentials may be used
+                                     either to initiate or accept
+                                     security contexts.
+                        GSS_C_INITIATE - Credentials will only be
+                                         used to initiate security
+                                         contexts.
+                        GSS_C_ACCEPT - Credentials will only be used to
+                                       accept security contexts.
+
+      output_cred_handle   gss_cred_id_t, modify
+                           The returned credential handle.
+
+      actual_mechs      Set of Object IDs, modify, optional
+                        The set of mechanisms for which the
+                        credential is valid.  Specify NULL
+                        if not required.
+
+      time_rec          Integer, modify, optional
+                        Actual number of seconds for which the
+                        returned credentials will remain valid.  If the
+                        implementation does not support expiration of
+                        credentials, the value GSS_C_INDEFINITE will
+                        be returned. Specify NULL if not required
+
+      minor_status      Integer, modify
+                        Mechanism specific status code.
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_MECH    Unavailable mechanism requested
+
+      GSS_S_BAD_NAMETYPE Type contained within desired_name parameter is
+                        not supported
+
+      GSS_S_BAD_NAME    Value supplied for desired_name parameter is
+
+
+
+Wray                                                           [Page 15]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                        ill-formed.
+
+      GSS_S_FAILURE     Unspecified failure.  The minor_status parameter
+                        contains more detailed information
+
+3.2. gss_release_cred
+
+      OM_uint32  gss_release_cred (
+                     OM_uint32 *     minor_status,
+                     gss_cred_id_t * cred_handle)
+
+   Purpose:
+
+   Informs GSSAPI that the specified credential handle is no longer
+   required by the process.  When all processes have released a
+   credential, it will be deleted.
+
+   Parameters:
+
+      cred_handle       gss_cred_id_t, modify, optional
+                        buffer containing opaque credential
+                        handle.  If  GSS_C_NO_CREDENTIAL  is supplied,
+                        the default credential will be released
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_NO_CRED     Credentials could not be accessed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wray                                                           [Page 16]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+3.3. gss_init_sec_context
+
+      OM_uint32  gss_init_sec_context (
+                     OM_uint32 *     minor_status,
+                     gss_cred_id_t   claimant_cred_handle,
+                     gss_ctx_id_t *  context_handle,
+                     gss_name_t      target_name,
+                     gss_OID         mech_type,
+                     int             req_flags,
+                     int             time_req,
+                     gss_channel_bindings_t
+                                     input_chan_bindings,
+                     gss_buffer_t    input_token
+                     gss_OID *       actual_mech_type,
+                     gss_buffer_t    output_token,
+                     int *           ret_flags,
+                     OM_uint32 *     time_rec )
+
+   Purpose:
+
+   Initiates the establishment of a security context between the
+   application and a remote peer.  Initially, the input_token parameter
+   should be specified as GSS_C_NO_BUFFER.  The routine may return a
+   output_token which should be transferred to the peer application,
+   where the peer application will present it to gss_accept_sec_context.
+   If no token need be sent, gss_init_sec_context will indicate this by
+   setting the length field of the output_token argument to zero.  To
+   complete the context establishment, one or more reply tokens may be
+   required from the peer application; if so, gss_init_sec_context will
+   return a status indicating GSS_S_CONTINUE_NEEDED in which case it
+   should be called again when the reply token is received from the peer
+   application, passing the token to gss_init_sec_context via the
+   input_token parameters.
+
+   The values returned via the ret_flags and time_rec parameters are not
+   defined unless the routine returns GSS_S_COMPLETE.
+
+   Parameters:
+
+      claimant_cred_handle  gss_cred_id_t, read, optional
+                            handle for credentials claimed.  Supply
+                            GSS_C_NO_CREDENTIAL to use default
+                            credentials.
+
+      context_handle    gss_ctx_id_t, read/modify
+                        context handle for new context.  Supply
+                        GSS_C_NO_CONTEXT for first call; use value
+                        returned by first call in continuation calls.
+
+
+
+Wray                                                           [Page 17]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      target_name       gss_name_t, read
+                        Name of target
+
+      mech_type         OID, read, optional
+                        Object ID of desired mechanism. Supply
+                        GSS_C_NULL_OID to obtain an implementation
+                        specific default
+
+      req_flags         bit-mask, read
+                        Contains four independent flags, each of
+                        which requests that the context support a
+                        specific service option.  Symbolic
+                        names are provided for each flag, and the
+                        symbolic names corresponding to the required
+                        flags should be logically-ORed
+                        together to form the bit-mask value.  The
+                        flags are:
+
+                        GSS_C_DELEG_FLAG
+                              True - Delegate credentials to remote peer
+                              False - Don't delegate
+                        GSS_C_MUTUAL_FLAG
+                              True - Request that remote peer
+                                     authenticate itself
+                              False - Authenticate self to remote peer
+                                      only
+                        GSS_C_REPLAY_FLAG
+                              True - Enable replay detection for signed
+                                     or sealed messages
+                              False - Don't attempt to detect
+                                      replayed messages
+                        GSS_C_SEQUENCE_FLAG
+                              True - Enable detection of out-of-sequence
+                                     signed or sealed messages
+                              False - Don't attempt to detect
+                                      out-of-sequence messages
+
+      time_req          integer, read
+                        Desired number of seconds for which context
+                        should remain valid.  Supply 0 to request a
+                        default validity period.
+
+      input_chan_bindings     channel bindings, read
+                              Application-specified bindings.  Allows
+                              application to securely bind channel
+                              identification information to the security
+                              context.
+
+
+
+
+Wray                                                           [Page 18]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      input_token       buffer, opaque, read, optional (see text)
+                        Token received from peer application.
+                        Supply GSS_C_NO_BUFFER on initial call.
+
+      actual_mech_type  OID, modify
+                        actual mechanism used.
+
+      output_token      buffer, opaque, modify
+                        token to be sent to peer application.  If
+                        the length field of the returned buffer is
+                        zero, no token need be sent to the peer
+                        application.
+
+      ret_flags         bit-mask, modify
+                        Contains six independent flags, each of which
+                        indicates that the context supports a specific
+                        service option.  Symbolic names are provided
+                        for each flag, and the symbolic names
+                        corresponding to the required flags should be
+                        logically-ANDed with the ret_flags value to test
+                        whether a given option is supported by the
+                        context.  The flags are:
+
+                        GSS_C_DELEG_FLAG
+                              True - Credentials were delegated to
+                                     the remote peer
+                              False - No credentials were delegated
+                        GSS_C_MUTUAL_FLAG
+                              True - Remote peer has been asked to
+                                     authenticated itself
+                              False - Remote peer has not been asked to
+                                      authenticate itself
+                        GSS_C_REPLAY_FLAG
+                              True - replay of signed or sealed messages
+                                     will be detected
+                              False - replayed messages will not be
+                                      detected
+                        GSS_C_SEQUENCE_FLAG
+                              True - out-of-sequence signed or sealed
+                                     messages will be detected
+                              False - out-of-sequence messages will not
+                                      be detected
+                        GSS_C_CONF_FLAG
+                              True - Confidentiality service may be
+                                     invoked by calling seal routine
+                              False - No confidentiality service (via
+                                      seal) available. seal will provide
+                                      message encapsulation, data-origin
+
+
+
+Wray                                                           [Page 19]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                                      authentication and integrity
+                                      services only.
+                        GSS_C_INTEG_FLAG
+                              True - Integrity service may be invoked by
+                                     calling either gss_sign or gss_seal
+                                     routines.
+                              False - Per-message integrity service
+                                      unavailable.
+
+      time_rec          integer, modify, optional
+                        number of seconds for which the context
+                        will remain valid. If the implementation does
+                        not support credential expiration, the value
+                        GSS_C_INDEFINITE will be returned.  Specify
+                        NULL if not required.
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+   Function value:
+
+   GSS status code:
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
+                     application is required to complete thecontext, and
+                     that gss_init_sec_context must be called again with
+                     that token.
+
+   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on
+                     the input_token failed
+
+   GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
+                     performed on the credential failed.
+
+   GSS_S_NO_CRED     The supplied credentials were not valid for context
+                     initiation, or the credential handle did not
+                     reference any credentials.
+
+   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired
+
+   GSS_S_BAD_BINDINGS The input_token contains different channel
+                     bindings to those specified via the
+                     input_chan_bindings parameter
+
+   GSS_S_BAD_SIG     The input_token contains an invalid signature, or a
+                     signature that could not be verified
+
+
+
+Wray                                                           [Page 20]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal error
+                     during context establishment
+
+   GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of
+                     a token already processed.  This is a fatal error
+                     during context establishment.
+
+   GSS_S_NO_CONTEXT  Indicates that the supplied context handle did not
+                     refer to a valid context
+
+   GSS_S_BAD_NAMETYPE The provided target_name parameter contained an
+                     invalid or unsupported type of name
+
+   GSS_S_BAD_NAME    The provided target_name parameter was ill-formed.
+
+   GSS_S_FAILURE     Failure.  See minor_status for more information
+
+3.4. gss_accept_sec_context
+
+      OM_uint32  gss_accept_sec_context (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t *  context_handle,
+                     gss_cred_id_t   verifier_cred_handle,
+                     gss_buffer_t    input_token_buffer
+                     gss_channel_bindings_t
+                                     input_chan_bindings,
+                     gss_name_t *    src_name,
+                     gss_OID *       mech_type,
+                     gss_buffer_t    output_token,
+                     int *           ret_flags,
+                     OM_uint32 *     time_rec,
+                     gss_cred_id_t * delegated_cred_handle)
+
+   Purpose:
+
+   Allows a remotely initiated security context between the application
+   and a remote peer to be established.  The routine may return a
+   output_token which should be transferred to the peer application,
+   where the peer application will present it to gss_init_sec_context.
+   If no token need be sent, gss_accept_sec_context will indicate this
+   by setting the length field of the output_token argument to zero.  To
+   complete the context establishment, one or more reply tokens may be
+   required from the peer application; if so, gss_accept_sec_context
+   will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it
+   should be called again when the reply token is received from the peer
+   application, passing the token to gss_accept_sec_context via the
+   input_token parameters.
+
+
+
+
+Wray                                                           [Page 21]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   The values returned via the src_name, ret_flags, time_rec, and
+   delegated_cred_handle parameters are not defined unless the routine
+   returns GSS_S_COMPLETE.
+
+   Parameters:
+
+      context_handle    gss_ctx_id_t, read/modify
+                        context handle for new context.  Supply
+                        GSS_C_NO_CONTEXT for first call; use value
+                        returned in subsequent calls.
+
+      verifier_cred_handle    gss_cred_id_t, read, optional
+                              Credential handle claimed by context
+      acceptor.
+                              Specify GSS_C_NO_CREDENTIAL to use default
+                              credentials.  If GSS_C_NO_CREDENTIAL is
+                              specified, but the caller has no default
+                              credentials established, an
+                              implementation-defined default credential
+                              may be used.
+
+      input_token_buffer      buffer, opaque, read
+                              token obtained from remote application
+
+      input_chan_bindings     channel bindings, read
+                              Application-specified bindings.  Allows
+                              application to securely bind channel
+                              identification information to the security
+                              context.
+
+      src_name          gss_name_t, modify, optional
+                        Authenticated name of context initiator.
+                        After use, this name should be deallocated by
+                        passing it to gss_release_name.  If not required,
+                        specify NULL.
+
+      mech_type         Object ID, modify
+                        Security mechanism used.  The returned
+                        OID value will be a pointer into static
+                        storage, and should be treated as read-only
+                        by the caller.
+
+      output_token      buffer, opaque, modify
+                        Token to be passed to peer application. If the
+                        length field of the returned token buffer is 0,
+                        then no token need be passed to the peer
+                        application.
+
+
+
+
+Wray                                                           [Page 22]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      ret_flags         bit-mask, modify
+                        Contains six independent flags, each of
+                        which indicates that the context supports a
+                        specific service option.  Symbolic names are
+                        provided for each flag, and the symbolic names
+                        corresponding to the required flags
+                        should be logically-ANDed with the ret_flags
+                        value to test whether a given option is
+                        supported by the context.  The flags are:
+                        GSS_C_DELEG_FLAG
+                              True - Delegated credentials are available
+                                     via the delegated_cred_handle
+                                     parameter
+                              False - No credentials were delegated
+                        GSS_C_MUTUAL_FLAG
+                              True - Remote peer asked for mutual
+                                     authentication
+                              False - Remote peer did not ask for mutual
+                                      authentication
+                        GSS_C_REPLAY_FLAG
+                              True - replay of signed or sealed messages
+                                     will be detected
+                              False - replayed messages will not be
+                                      detected
+                        GSS_C_SEQUENCE_FLAG
+                              True - out-of-sequence signed or sealed
+                                     messages will be detected
+                              False - out-of-sequence messages will not
+                                      be detected
+                        GSS_C_CONF_FLAG
+                              True - Confidentiality service may be
+                                     invoked by calling seal routine
+                              False - No confidentiality service (via
+                                      seal) available. seal will
+                                      provide message encapsulation,
+                                      data-origin authentication and
+                                      integrity services only.
+                        GSS_C_INTEG_FLAG
+                              True - Integrity service may be invoked
+                                     by calling either gss_sign or
+                                     gss_seal routines.
+                              False - Per-message integrity service
+                                      unavailable.
+
+      time_rec          integer, modify, optional
+                        number of seconds for which the context
+                        will remain valid. Specify NULL if not required.
+
+
+
+
+Wray                                                           [Page 23]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      delegated_cred_handle
+                        gss_cred_id_t, modify
+                        credential handle for credentials received from
+                        context initiator.  Only valid if deleg_flag in
+                        ret_flags is true.
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
+                        application is required to complete the context,
+                        and that gss_accept_sec_context must be called
+                        again with that token.
+
+      GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks
+                        performed on the input_token failed.
+
+      GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
+                        performed on the credential failed.
+
+      GSS_S_NO_CRED The supplied credentials were not valid for
+                        context acceptance, or the credential handle
+                        did not reference any credentials.
+
+      GSS_S_CREDENTIALS_EXPIRED The referenced credentials have
+                        expired.
+
+      GSS_S_BAD_BINDINGS The input_token contains different channel
+                        bindings to those specified via the
+                        input_chan_bindings parameter.
+
+      GSS_S_NO_CONTEXT Indicates that the supplied context handle did
+                       not refer to a valid context.
+
+      GSS_S_BAD_SIG    The input_token contains an invalid signature.
+
+      GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal
+                        error during context establishment.
+
+      GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a
+                        duplicate of a token already processed.  This
+                        is a fatal error during context establishment.
+
+
+
+Wray                                                           [Page 24]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      GSS_S_FAILURE     Failure.  See minor_status for more information.
+
+3.5. gss_process_context_token
+
+      OM_uint32  gss_process_context_token (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t    context_handle,
+                     gss_buffer_t    token_buffer)
+
+   Purpose:
+
+   Provides a way to pass a token to the security service.  Usually,
+   tokens are associated either with context establishment (when they
+   would be passed to gss_init_sec_context or gss_accept_sec_context) or
+   with per-message security service (when they would be passed to
+   gss_verify or gss_unseal).  Occasionally, tokens may be received at
+   other times, and gss_process_context_token allows such tokens to be
+   passed to the underlying security service for processing.  At
+   present, such additional tokens may only be generated by
+   gss_delete_sec_context.  GSSAPI implementation may use this service
+   to implement deletion of the security context.
+
+   Parameters:
+
+      context_handle    gss_ctx_id_t, read
+                        context handle of context on which token is to
+                        be processed
+
+      token_buffer      buffer, opaque, read
+                        pointer to first byte of token to process
+
+      minor_status      integer, modify
+                        Implementation specific status code.
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks
+                        performed on the token failed
+
+      GSS_S_FAILURE     Failure.  See minor_status for more information
+
+      GSS_S_NO_CONTEXT The context_handle did not refer to a valid
+                       context
+
+
+
+
+Wray                                                           [Page 25]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+3.6. gss_delete_sec_context
+
+      OM_uint32  gss_delete_sec_context (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t *  context_handle,
+                     gss_buffer_t    output_token)
+
+   Purpose:
+
+   Delete a security context.  gss_delete_sec_context will delete the
+   local data structures associated with the specified security context,
+   and generate an output_token, which when passed to the peer
+   gss_process_context_token will instruct it to do likewise.  No
+   further security services may be obtained using the context specified
+   by context_handle.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      context_handle    gss_ctx_id_t, modify
+                        context handle identifying context to delete.
+
+      output_token      buffer, opaque, modify
+                        token to be sent to remote application to
+                        instruct it to also delete the context
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_FAILURE     Failure, see minor_status for more information
+
+      GSS_S_NO_CONTEXT  No valid context was supplied
+
+3.7. gss_context_time
+
+      OM_uint32  gss_context_time (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t    context_handle,
+                     OM_uint32 *     time_rec)
+   Purpose:
+
+   Determines the number of seconds for which the specified context will
+   remain valid.
+
+
+
+Wray                                                           [Page 26]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      Parameters:
+
+      minor_status      integer, modify
+                        Implementation specific status code.
+
+      context_handle    gss_ctx_id_t, read
+                        Identifies the context to be interrogated.
+
+      time_rec          integer, modify
+                        Number of seconds that the context will remain
+                        valid.  If the context has already expired,
+                        zero will be returned.
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_CONTEXT_EXPIRED The context has already expired
+
+      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
+                        associated credentials have expired
+
+      GSS_S_NO_CONTEXT The context_handle parameter did not identify a
+                        valid context
+
+3.8. gss_sign
+
+      OM_uint32  gss_sign (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t    context_handle,
+                     int             qop_req,
+                     gss_buffer_t    message_buffer,
+                     gss_buffer_t    msg_token)
+   Purpose:
+
+   Generates a cryptographic signature for the supplied message, and
+   places the signature in a token for transfer to the peer application.
+   The qop_req parameter allows a choice between several cryptographic
+   algorithms, if supported by the chosen mechanism.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Implementation specific status code.
+
+      context_handle    gss_ctx_id_t, read
+                        identifies the context on which the message
+
+
+
+Wray                                                           [Page 27]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                        will be sent
+
+      qop_req           integer, read, optional
+                        Specifies requested quality of protection.
+                        Callers are encouraged, on portability grounds,
+                        to accept the default quality of protection
+                        offered by the chosen mechanism, which may be
+                        requested by specifying GSS_C_QOP_DEFAULT for
+                        this parameter.  If an unsupported protection
+                        strength is requested, gss_sign will return a
+                        major_status of GSS_S_FAILURE.
+
+      message_buffer    buffer, opaque, read
+                        message to be signed
+
+      msg_token         buffer, opaque, modify
+                        buffer to receive token
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_CONTEXT_EXPIRED The context has already expired
+
+      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
+                        associated credentials have expired
+
+      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
+                        valid context
+
+      GSS_S_FAILURE     Failure. See minor_status for more information.
+
+3.9. gss_verify
+
+      OM_uint32  gss_verify (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t    context_handle,
+                     gss_buffer_t    message_buffer,
+                     gss_buffer_t    token_buffer,
+                     int *           qop_state)
+   Purpose:
+
+   Verifies that a cryptographic signature, contained in the token
+   parameter, fits the supplied message.  The qop_state parameter allows
+   a message recipient to determine the strength of protection that was
+   applied to the message.
+
+
+
+Wray                                                           [Page 28]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      context_handle    gss_ctx_id_t, read
+                        identifies the context on which the message
+                        arrived
+
+      message_buffer    buffer, opaque, read
+                        message to be verified
+
+      token_buffer      buffer, opaque, read
+                        token associated with message
+
+      qop_state         integer, modify
+                        quality of protection gained from signature
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
+
+      GSS_S_BAD_SIG     The signature was incorrect
+
+      GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
+                        signature for the message, but it had already
+                        been processed
+
+      GSS_S_OLD_TOKEN   The token was valid, and contained a correct
+                        signature for the message, but it is too old
+
+      GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct
+                        signature for the message, but has been
+                        verified out of sequence; an earlier token has
+                        been signed or sealed by the remote
+                        application, but not yet been processed
+                        locally.
+
+      GSS_S_CONTEXT_EXPIRED The context has already expired
+
+      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
+                        associated credentials have expired
+
+
+
+
+
+Wray                                                           [Page 29]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
+                        valid context
+
+      GSS_S_FAILURE     Failure.  See minor_status for more information.
+
+3.10. gss_seal
+
+      OM_uint32  gss_seal (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t    context_handle,
+                     int             conf_req_flag,
+                     int             qop_req
+                     gss_buffer_t    input_message_buffer,
+                     int *           conf_state,
+                     gss_buffer_t    output_message_buffer)
+
+   Purpose:
+
+   Cryptographically signs and optionally encrypts the specified
+   input_message.  The output_message contains both the signature and
+   the message.  The qop_req parameter allows a choice between several
+   cryptographic algorithms, if supported by the chosen mechanism.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      context_handle    gss_ctx_id_t, read
+                        identifies the context on which the message
+                        will be sent
+
+      conf_req_flag     boolean, read
+                        True - Both confidentiality and integrity
+                               services are requested
+                        False - Only integrity service is requested
+
+      qop_req           integer, read, optional
+                        Specifies required quality of protection.  A
+                        mechanism-specific default may be requested by
+                        setting qop_req to GSS_C_QOP_DEFAULT.  If an
+                        unsupported protection strength is requested,
+                        gss_seal will return a major_status of
+                        GSS_S_FAILURE.
+
+      input_message_buffer   buffer, opaque, read
+                             message to be sealed
+
+
+
+
+Wray                                                           [Page 30]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      conf_state        boolean, modify
+                        True - Confidentiality, data origin
+                               authentication and integrity services
+                               have been applied
+                        False - Integrity and data origin services only
+                                has been applied.
+
+      output_message_buffer  buffer, opaque, modify
+                             buffer to receive sealed message
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_CONTEXT_EXPIRED The context has already expired
+
+      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
+                        associated credentials have expired
+
+      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
+                        valid context
+
+      GSS_S_FAILURE     Failure.  See minor_status for more information.
+
+3.11. gss_unseal
+
+      OM_uint32  gss_unseal (
+                     OM_uint32 *     minor_status,
+                     gss_ctx_id_t    context_handle,
+                     gss_buffer_t    input_message_buffer,
+                     gss_buffer_t    output_message_buffer,
+                     int *           conf_state,
+                     int *           qop_state)
+
+   Purpose:
+
+   Converts a previously sealed message back to a usable form, verifying
+   the embedded signature.  The conf_state parameter indicates whether
+   the message was encrypted; the qop_state parameter indicates the
+   strength of protection that was used to provide the confidentiality
+   and integrity services.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+
+
+Wray                                                           [Page 31]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      context_handle    gss_ctx_id_t, read
+                        identifies the context on which the message
+                        arrived
+
+      input_message_buffer   buffer, opaque, read
+                             sealed message
+
+      output_message_buffer  buffer, opaque, modify
+                             buffer to receive unsealed message
+
+      conf_state        boolean, modify
+                        True - Confidentiality and integrity protection
+                               were used
+                        False - Inteegrity service only was used
+
+      qop_state         integer, modify
+                        quality of protection gained from signature
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
+
+      GSS_S_BAD_SIG     The signature was incorrect
+
+      GSS_S_DUPLICATE_TOKEN The token was valid, and contained a
+                        correct signature for the message, but it had
+                        already been processed
+
+      GSS_S_OLD_TOKEN The token was valid, and contained a correct
+                        signature for the message, but it is too old
+
+      GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct
+                        signature for the message, but has been
+                        verified out of sequence; an earlier token has
+                        been signed or sealed by the remote
+                        application, but not yet been processed
+                        locally.
+
+      GSS_S_CONTEXT_EXPIRED The context has already expired
+
+      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
+                        associated credentials have expired
+
+
+
+
+
+Wray                                                           [Page 32]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
+                        valid context
+
+      GSS_S_FAILURE     Failure.  See minor_status for more information.
+
+3.12. gss_display_status
+
+      OM_uint32  gss_display_status (
+                     OM_uint32 *     minor_status,
+                     int             status_value,
+                     int             status_type,
+                     gss_OID         mech_type,
+                     int *           message_context,
+                     gss_buffer_t    status_string)
+
+   Purpose:
+
+   Allows an application to obtain a textual representation of a GSSAPI
+   status code, for display to the user or for logging purposes.  Since
+   some status values may indicate multiple errors, applications may
+   need to call gss_display_status multiple times, each call generating
+   a single text string.  The message_context parameter is used to
+   indicate which error message should be extracted from a given
+   status_value; message_context should be initialized to 0, and
+   gss_display_status will return a non-zero value if there are further
+   messages to extract.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      status_value      integer, read
+                        Status value to be converted
+
+      status_type       integer, read
+                        GSS_C_GSS_CODE - status_value is a GSS status
+                                         code
+                        GSS_C_MECH_CODE - status_value is a mechanism
+                                          status code
+
+      mech_type         Object ID, read, optional
+                        Underlying mechanism (used to interpret a
+                        minor status value) Supply GSS_C_NULL_OID to
+                        obtain the system default.
+
+      message_context   integer, read/modify
+                        Should be initialized to zero by caller
+
+
+
+Wray                                                           [Page 33]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                        on first call.  If further messages are
+                        contained in the status_value parameter,
+                        message_context will be non-zero on return,
+                        and this value should be passed back to
+                        subsequent calls, along with the same
+                        status_value, status_type and mech_type
+                        parameters.
+
+      status_string     buffer, character string, modify
+                        textual interpretation of the status_value
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_MECH    Indicates that translation in accordance with
+                        an unsupported mechanism type was requested
+
+      GSS_S_BAD_STATUS The status value was not recognized, or the
+                        status type was neither GSS_C_GSS_CODE nor
+                        GSS_C_MECH_CODE.
+
+
+3.13. gss_indicate_mechs
+
+      OM_uint32  gss_indicate_mechs (
+                     OM_uint32 *     minor_status,
+                     gss_OID_set *   mech_set)
+
+   Purpose:
+
+         Allows an application to determine which underlying security
+         mechanisms are available.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      mech_set          set of Object IDs, modify
+                        set of implementation-supported mechanisms.
+                        The returned gss_OID_set value will be a
+                        pointer into static storage, and should be
+                        treated as read-only by the caller.
+
+
+
+
+
+Wray                                                           [Page 34]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+3.14. gss_compare_name
+
+      OM_uint32  gss_compare_name (
+                     OM_uint32 *     minor_status,
+                     gss_name_t      name1,
+                     gss_name_t      name2,
+                     int *           name_equal)
+
+   Purpose:
+
+   Allows an application to compare two internal-form names to determine
+   whether they refer to the same entity.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      name1             gss_name_t, read
+                        internal-form  name
+
+      name2             gss_name_t, read
+                        internal-form  name
+
+      name_equal        boolean, modify
+                        True - names refer to same entity
+                        False - names refer to different entities
+                                (strictly, the names are not known to
+                                refer to the same identity).
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_NAMETYPE The type contained within either name1 or
+                        name2 was unrecognized, or the names were of
+                        incomparable types.
+
+      GSS_S_BAD_NAME    One or both of name1 or name2 was ill-formed
+
+
+
+
+
+Wray                                                           [Page 35]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+3.15. gss_display_name
+
+      OM_uint32  gss_display_name (
+                     OM_uint32 *     minor_status,
+                     gss_name_t      input_name,
+                     gss_buffer_t    output_name_buffer,
+                     gss_OID *       output_name_type)
+
+   Purpose:
+
+   Allows an application to obtain a textual representation of an opaque
+   internal-form  name for display purposes.  The syntax of a printable
+   name is defined by the GSSAPI implementation.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code.
+
+      input_name        gss_name_t, read
+                        name to be displayed
+
+      output_name_buffer   buffer, character-string, modify
+                           buffer to receive textual name string
+
+      output_name_type  Object ID, modify
+                        The type of the returned name.  The returned
+                        gss_OID will be a pointer into static storage,
+                        and should be treated as read-only by the caller
+
+   Function value:
+
+      GSS status code:
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_NAMETYPE The type of input_name was not recognized
+
+      GSS_S_BAD_NAME    input_name was ill-formed
+
+3.16. gss_import_name
+
+      OM_uint32 gss_import_name (
+                    OM_uint32 *     minor_status,
+                    gss_buffer_t    input_name_buffer,
+                    gss_OID         input_name_type,
+                    gss_name_t *    output_name)
+
+
+
+
+Wray                                                           [Page 36]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   Purpose:
+
+   Convert a printable name to internal form.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code
+
+      input_name_buffer    buffer, character-string, read
+                           buffer containing printable name to convert
+
+      input_name_type   Object ID, read, optional
+                        Object Id specifying type of printable
+                        name.  Applications may specify either
+                        GSS_C_NULL_OID to use a local system-specific
+                        printable syntax, or an OID registered by the
+                        GSSAPI implementation to name a particular
+                        namespace.
+
+      output_name       gss_name_t, modify
+                        returned name in internal form
+
+   Function value:
+
+      GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_NAMETYPE The input_name_type was unrecognized
+
+      GSS_S_BAD_NAME    The input_name parameter could not be
+                        interpreted as a name of the specified type
+
+3.17. gss_release_name
+
+      OM_uint32 gss_release_name (
+                    OM_uint32 *     minor_status,
+                    gss_name_t *    name)
+
+   Purpose:
+
+   Free GSSAPI-allocated storage associated with an internal form name.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code
+
+
+
+Wray                                                           [Page 37]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+      name              gss_name_t, modify
+                        The name to be deleted
+
+   Function value:
+
+      GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_BAD_NAME    The name parameter did not contain a valid name
+
+3.18. gss_release_buffer
+
+      OM_uint32 gss_release_buffer (
+                    OM_uint32 *     minor_status,
+                    gss_buffer_t    buffer)
+
+   Purpose:
+
+   Free storage associated with a buffer format name.  The storage must
+   have been allocated by a GSSAPI routine.  In addition to freeing the
+   associated storage, the routine will zero the length field in the
+   buffer parameter.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code
+
+      buffer            buffer, modify
+                        The storage associated with the buffer will be
+                        deleted.  The gss_buffer_desc object will not
+                        be freed, but its length field will be zeroed.
+
+   Function value:
+
+      GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+3.19. gss_release_oid_set
+
+      OM_uint32 gss_release_oid_set (
+                    OM_uint32 *     minor_status,
+                    gss_OID_set *   set)
+
+   Purpose:
+
+
+
+
+Wray                                                           [Page 38]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   Free storage associated with a gss_OID_set object.  The storage must
+   have been allocated by a GSSAPI routine.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code
+
+      set               Set of Object IDs, modify
+                        The storage associated with the gss_OID_set
+                        will be deleted.
+
+   Function value:
+
+      GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+3.20. gss_inquire_cred
+
+      OM_uint32 gss_inquire_cred (
+                    OM_uint32  *    minor_status,
+                    gss_cred_id_t   cred_handle,
+                    gss_name_t *    name,
+                    OM_uint32 *     lifetime,
+                    int *           cred_usage,
+                    gss_OID_set *   mechanisms )
+
+   Purpose:
+
+   Obtains information about a credential.  The caller must already have
+   obtained a handle that refers to the credential.
+
+   Parameters:
+
+      minor_status      integer, modify
+                        Mechanism specific status code
+
+      cred_handle       gss_cred_id_t, read
+                        A handle that refers to the target credential.
+                        Specify GSS_C_NO_CREDENTIAL to inquire about
+                        the default credential.
+
+      name              gss_name_t, modify
+                        The name whose identity the credential asserts.
+                        Specify NULL if not required.
+
+      lifetime          Integer, modify
+
+
+
+Wray                                                           [Page 39]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+                        The number of seconds for which the credential
+                        will remain valid.  If the credential has
+                        expired, this parameter will be set to zero.
+                        If the implementation does not support
+                        credential expiration, the value
+                        GSS_C_INDEFINITE will be returned.  Specify
+                        NULL if not required.
+
+      cred_usage        Integer, modify
+                        How the credential may be used.  One of the
+                        following:
+                           GSS_C_INITIATE
+                           GSS_C_ACCEPT
+                           GSS_C_BOTH
+                        Specify NULL if not required.
+
+      mechanisms        gss_OID_set, modify
+                        Set of mechanisms supported by the credential.
+                        Specify NULL if not required.
+
+   Function value:
+
+      GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+      GSS_S_NO_CRED     The referenced credentials could not be
+                        accessed.
+
+      GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were
+                        invalid.
+
+      GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
+                        If the lifetime parameter was not passed as
+                        NULL, it will be set to 0.
+
+
+  #ifndef GSSAPI_H_
+  #define GSSAPI_H_
+
+  /*
+   * First, define the platform-dependent types.
+   */
+  typedef <platform-specific> OM_uint32;
+  typedef <platform-specific> gss_ctx_id_t;
+  typedef <platform-specific> gss_cred_id_t;
+  typedef <platform-specific> gss_name_t;
+
+
+
+
+Wray                                                           [Page 40]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+  /*
+   * Note that a platform supporting the xom.h X/Open header file
+   * may make use of that header for the definitions of OM_uint32
+   * and the structure to which gss_OID_desc equates.
+   */
+
+  typedef struct gss_OID_desc_struct {
+        OM_uint32 length;
+        void      *elements;
+  } gss_OID_desc, *gss_OID;
+
+  typedef struct gss_OID_set_desc_struct  {
+        int     count;
+        gss_OID elements;
+  } gss_OID_set_desc, *gss_OID_set;
+
+  typedef struct gss_buffer_desc_struct {
+        size_t length;
+        void *value;
+  } gss_buffer_desc, *gss_buffer_t;
+
+  typedef struct gss_channel_bindings_struct {
+        OM_uint32 initiator_addrtype;
+        gss_buffer_desc initiator_address;
+        OM_uint32 acceptor_addrtype;
+        gss_buffer_desc acceptor_address;
+        gss_buffer_desc application_data;
+  } *gss_channel_bindings_t;
+
+
+  /*
+   * Six independent flags each of which indicates that a context
+   * supports a specific service option.
+   */
+  #define GSS_C_DELEG_FLAG 1
+  #define GSS_C_MUTUAL_FLAG 2
+  #define GSS_C_REPLAY_FLAG 4
+  #define GSS_C_SEQUENCE_FLAG 8
+  #define GSS_C_CONF_FLAG 16
+  #define GSS_C_INTEG_FLAG 32
+
+
+  /*
+   * Credential usage options
+   */
+  #define GSS_C_BOTH 0
+  #define GSS_C_INITIATE 1
+  #define GSS_C_ACCEPT 2
+
+
+
+Wray                                                           [Page 41]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+  /*
+   * Status code types for gss_display_status
+   */
+  #define GSS_C_GSS_CODE 1
+  #define GSS_C_MECH_CODE 2
+
+  /*
+   * The constant definitions for channel-bindings address families
+   */
+  #define GSS_C_AF_UNSPEC     0;
+  #define GSS_C_AF_LOCAL      1;
+  #define GSS_C_AF_INET       2;
+  #define GSS_C_AF_IMPLINK    3;
+  #define GSS_C_AF_PUP        4;
+  #define GSS_C_AF_CHAOS      5;
+  #define GSS_C_AF_NS         6;
+  #define GSS_C_AF_NBS        7;
+  #define GSS_C_AF_ECMA       8;
+  #define GSS_C_AF_DATAKIT    9;
+  #define GSS_C_AF_CCITT      10;
+  #define GSS_C_AF_SNA        11;
+  #define GSS_C_AF_DECnet     12;
+  #define GSS_C_AF_DLI        13;
+  #define GSS_C_AF_LAT        14;
+  #define GSS_C_AF_HYLINK     15;
+  #define GSS_C_AF_APPLETALK  16;
+  #define GSS_C_AF_BSC        17;
+  #define GSS_C_AF_DSS        18;
+  #define GSS_C_AF_OSI        19;
+  #define GSS_C_AF_X25        21;
+
+  #define GSS_C_AF_NULLADDR   255;
+
+  #define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
+  #define GSS_C_NULL_OID ((gss_OID) 0)
+  #define GSS_C_NULL_OID_SET ((gss_OID_set) 0)
+  #define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
+  #define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
+  #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
+  #define GSS_C_EMPTY_BUFFER {0, NULL}
+
+  /*
+   * Define the default Quality of Protection for per-message
+   * services.  Note that an implementation that offers multiple
+   * levels of QOP may either reserve a value (for example zero,
+   * as assumed here) to mean "default protection", or alternatively
+   * may simply equate GSS_C_QOP_DEFAULT to a specific explicit QOP
+   * value.
+
+
+
+Wray                                                           [Page 42]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+   */
+  #define GSS_C_QOP_DEFAULT 0
+
+  /*
+   * Expiration time of 2^32-1 seconds means infinite lifetime for a
+   * credential or security context
+   */
+  #define GSS_C_INDEFINITE 0xfffffffful
+
+
+  /* Major status codes */
+
+  #define GSS_S_COMPLETE 0
+
+  /*
+   * Some "helper" definitions to make the status code macros obvious.
+   */
+  #define GSS_C_CALLING_ERROR_OFFSET 24
+  #define GSS_C_ROUTINE_ERROR_OFFSET 16
+  #define GSS_C_SUPPLEMENTARY_OFFSET 0
+  #define GSS_C_CALLING_ERROR_MASK 0377ul
+  #define GSS_C_ROUTINE_ERROR_MASK 0377ul
+  #define GSS_C_SUPPLEMENTARY_MASK 0177777ul
+
+  /*
+   * The macros that test status codes for error conditions
+   */
+  #define GSS_CALLING_ERROR(x) \
+    (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
+  #define GSS_ROUTINE_ERROR(x) \
+    (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
+  #define GSS_SUPPLEMENTARY_INFO(x) \
+    (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
+  #define GSS_ERROR(x) \
+    ((GSS_CALLING_ERROR(x) != 0) || (GSS_ROUTINE_ERROR(x) != 0))
+
+
+  /*
+   * Now the actual status code definitions
+   */
+
+  /*
+   * Calling errors:
+   */
+  #define GSS_S_CALL_INACCESSIBLE_READ \
+                               (1ul << GSS_C_CALLING_ERROR_OFFSET)
+  #define GSS_S_CALL_INACCESSIBLE_WRITE \
+                               (2ul << GSS_C_CALLING_ERROR_OFFSET)
+
+
+
+Wray                                                           [Page 43]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+  #define GSS_S_CALL_BAD_STRUCTURE \
+                               (3ul << GSS_C_CALLING_ERROR_OFFSET)
+
+  /*
+   * Routine errors:
+   */
+  #define GSS_S_BAD_MECH (1ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_BAD_NAME (2ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_BAD_NAMETYPE (3ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_BAD_BINDINGS (4ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_BAD_STATUS (5ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_BAD_SIG (6ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_NO_CRED (7ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_NO_CONTEXT (8ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_DEFECTIVE_CREDENTIAL (10ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_CREDENTIALS_EXPIRED (11ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_CONTEXT_EXPIRED (12ul << GSS_C_ROUTINE_ERROR_OFFSET)
+  #define GSS_S_FAILURE (13ul << GSS_C_ROUTINE_ERROR_OFFSET)
+
+  /*
+   * Supplementary info bits:
+   */
+  #define GSS_S_CONTINUE_NEEDED (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
+  #define GSS_S_DUPLICATE_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
+  #define GSS_S_OLD_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
+  #define GSS_S_UNSEQ_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
+
+
+  /*
+   * Finally, function prototypes for the GSSAPI routines.
+   */
+
+  OM_uint32 gss_acquire_cred
+             (OM_uint32*,       /* minor_status */
+              gss_name_t,       /* desired_name */
+              OM_uint32,        /* time_req */
+              gss_OID_set,      /* desired_mechs */
+              int,              /* cred_usage */
+              gss_cred_id_t*,   /* output_cred_handle */
+              gss_OID_set*,     /* actual_mechs */
+              OM_uint32*        /* time_rec */
+             );
+
+  OM_uint32 gss_release_cred,
+             (OM_uint32*,       /* minor_status */
+              gss_cred_id_t*    /* cred_handle */
+             );
+
+
+
+Wray                                                           [Page 44]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+  OM_uint32 gss_init_sec_context
+             (OM_uint32*,       /* minor_status */
+              gss_cred_id_t,    /* claimant_cred_handle */
+              gss_ctx_id_t*,    /* context_handle */
+              gss_name_t,       /* target_name */
+              gss_OID,          /* mech_type */
+              int,              /* req_flags */
+              OM_uint32,        /* time_req */
+              gss_channel_bindings_t,
+                                /* input_chan_bindings */
+              gss_buffer_t,     /* input_token */
+              gss_OID*,         /* actual_mech_type */
+              gss_buffer_t,     /* output_token */
+              int*,             /* ret_flags */
+              OM_uint32*        /* time_rec */
+             );
+
+  OM_uint32 gss_accept_sec_context
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t*,    /* context_handle */
+              gss_cred_id_t,    /* verifier_cred_handle */
+              gss_buffer_t,     /* input_token_buffer */
+              gss_channel_bindings_t,
+                                /* input_chan_bindings */
+              gss_name_t*,      /* src_name */
+              gss_OID*,         /* mech_type */
+              gss_buffer_t,     /* output_token */
+              int*,             /* ret_flags */
+              OM_uint32*,       /* time_rec */
+              gss_cred_id_t*    /* delegated_cred_handle */
+             );
+
+  OM_uint32 gss_process_context_token
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t,     /* context_handle */
+              gss_buffer_t      /* token_buffer */
+             );
+
+  OM_uint32 gss_delete_sec_context
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t*,    /* context_handle */
+              gss_buffer_t      /* output_token */
+             );
+
+
+
+
+
+
+
+
+Wray                                                           [Page 45]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+  OM_uint32 gss_context_time
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t,     /* context_handle */
+              OM_uint32*        /* time_rec */
+             );
+
+  OM_uint32 gss_sign
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t,     /* context_handle */
+              int,              /* qop_req */
+              gss_buffer_t,     /* message_buffer */
+              gss_buffer_t      /* message_token */
+             );
+
+  OM_uitn32 gss_verify
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t,     /* context_handle */
+              gss_buffer_t,     /* message_buffer */
+              gss_buffer_t,     /* token_buffer */
+              int*              /* qop_state */
+             );
+
+  OM_uint32 gss_seal
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t,     /* context_handle */
+              int,              /* conf_req_flag */
+              int,              /* qop_req */
+              gss_buffer_t,     /* input_message_buffer */
+              int*,             /* conf_state */
+              gss_buffer_t      /* output_message_buffer */
+             );
+
+  OM_uint32 gss_unseal
+             (OM_uint32*,       /* minor_status */
+              gss_ctx_id_t,     /* context_handle */
+              gss_buffer_t,     /* input_message_buffer */
+              gss_buffer_t,     /* output_message_buffer */
+              int*,             /* conf_state */
+              int*              /* qop_state */
+             );
+
+
+
+
+
+
+
+
+
+
+
+Wray                                                           [Page 46]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+  OM_uint32 gss_display_status
+             (OM_uint32*,       /* minor_status */
+              OM_uint32,        /* status_value */
+              int,              /* status_type */
+              gss_OID,          /* mech_type */
+              int*,             /* message_context */
+              gss_buffer_t      /* status_string */
+             );
+
+  OM_uint32 gss_indicate_mechs
+             (OM_uint32*,       /* minor_status */
+              gss_OID_set*      /* mech_set */
+             );
+
+  OM_uint32 gss_compare_name
+             (OM_uint32*,       /* minor_status */
+              gss_name_t,       /* name1 */
+              gss_name_t,       /* name2 */
+              int*              /* name_equal */
+             );
+
+  OM_uint32 gss_display_name,
+             (OM_uint32*,      /* minor_status */
+              gss_name_t,      /* input_name */
+              gss_buffer_t,     /* output_name_buffer */
+              gss_OID*         /* output_name_type */
+             );
+
+  OM_uint32 gss_import_name
+             (OM_uint32*,       /* minor_status */
+              gss_buffer_t,     /* input_name_buffer */
+              gss_OID,          /* input_name_type */
+              gss_name_t*       /* output_name */
+             );
+
+  OM_uint32 gss_release_name
+             (OM_uint32*,       /* minor_status */
+              gss_name_t*       /* input_name */
+             );
+
+  OM_uint32 gss_release_buffer
+             (OM_uint32*,       /* minor_status */
+              gss_buffer_t      /* buffer */
+             );
+
+  OM_uint32 gss_release_oid_set
+             (OM_uint32*,       /* minor_status */
+              gss_OID_set*      /* set */
+
+
+
+Wray                                                           [Page 47]
+
+RFC 1509            GSSAPI - Overview and C bindings      September 1993
+
+
+             );
+
+  OM_uint32 gss_inquire_cred
+             (OM_uint32 *,      /* minor_status */
+              gss_cred_id_t,    /* cred_handle */
+              gss_name_t *,     /* name */
+              OM_uint32 *,      /* lifetime */
+              int *,            /* cred_usage */
+              gss_OID_set *     /* mechanisms */
+             );
+
+
+
+  #endif /* GSSAPI_H_ */
+
+References
+
+   [1] Linn, J., "Generic Security Service Application Program
+       Interface", RFC 1508, Geer Zolot Associate, September 1993.
+
+   [2] "OSI Object Management API Specification, Version 2.0 t", X.400
+       API Association & X/Open Company Limited, August 24, 1990.
+       Specification of datatypes and routines for manipulating
+       information objects.
+
+Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+Author's Address
+
+   John Wray
+   Digital Equipment Corporation
+   550 King Street, LKG2-2/AA6
+   Littleton, MA  01460
+   USA
+
+   Phone: +1-508-486-5210
+   EMail: Wray@tuxedo.enet.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+Wray                                                           [Page 48]
+
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/rfc1510.txt b/third_party/heimdal/doc/standardisation/rfc1510.txt
new file mode 100644
index 00000000000..bc810cc506f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc1510.txt
@@ -0,0 +1,6275 @@
+
+
+
+
+
+
+Network Working Group                                            J. Kohl
+Request for Comments: 1510                 Digital Equipment Corporation
+                                                               C. Neuman
+                                                                     ISI
+                                                          September 1993
+
+
+            The Kerberos Network Authentication Service (V5)
+
+Status of this Memo
+
+   This RFC specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" for the standardization state and status
+   of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document gives an overview and specification of Version 5 of the
+   protocol for the Kerberos network authentication system. Version 4,
+   described elsewhere [1,2], is presently in production use at MIT's
+   Project Athena, and at other Internet sites.
+
+Overview
+
+   Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
+   Moira, and Zephyr are trademarks of the Massachusetts Institute of
+   Technology (MIT).  No commercial use of these trademarks may be made
+   without prior written permission of MIT.
+
+   This RFC 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; for Version 4 they are fully
+   described in the Kerberos portion of the Athena Technical Plan [1].
+   The protocols are under review, and are not being submitted for
+   consideration as an Internet standard at this time.  Comments are
+   encouraged.  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.
+
+
+
+
+
+Kohl & Neuman                                                   [Page 1]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+Background
+
+   The Kerberos model is based in part on Needham and Schroeder's
+   trusted third-party authentication protocol [3] and on modifications
+   suggested by Denning and Sacco [4].  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 4 is publicly available, and has seen wide use across the
+   Internet.
+
+   Version 5 (described in this document) has evolved from Version 4
+   based on new requirements and desires for features not available in
+   Version 4.  Details on the differences between Kerberos Versions 4
+   and 5 can be found in [5].
+
+Table of Contents
+
+   1. Introduction .......................................    5
+   1.1. Cross-Realm Operation ............................    7
+   1.2. Environmental assumptions ........................    8
+   1.3. Glossary of terms ................................    9
+   2. Ticket flag uses and requests ......................   12
+   2.1. Initial and pre-authenticated tickets ............   12
+   2.2. Invalid tickets ..................................   12
+   2.3. Renewable tickets ................................   12
+   2.4. Postdated tickets ................................   13
+   2.5. Proxiable and proxy tickets ......................   14
+   2.6. Forwardable tickets ..............................   15
+   2.7. Other KDC options ................................   15
+   3. Message Exchanges ..................................   16
+   3.1. The Authentication Service Exchange ..............   16
+   3.1.1. Generation of KRB_AS_REQ message ...............   17
+   3.1.2. Receipt of KRB_AS_REQ message ..................   17
+   3.1.3. Generation of KRB_AS_REP message ...............   17
+   3.1.4. Generation of KRB_ERROR message ................   19
+   3.1.5. Receipt of KRB_AS_REP message ..................   19
+   3.1.6. Receipt of KRB_ERROR message ...................   20
+   3.2. The Client/Server Authentication Exchange ........   20
+   3.2.1. The KRB_AP_REQ message .........................   20
+   3.2.2. Generation of a KRB_AP_REQ message .............   20
+   3.2.3. Receipt of KRB_AP_REQ message ..................   21
+   3.2.4. Generation of a KRB_AP_REP message .............   23
+   3.2.5. Receipt of KRB_AP_REP message ..................   23
+
+
+
+Kohl & Neuman                                                   [Page 2]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   3.2.6. Using the encryption key .......................   24
+   3.3. The Ticket-Granting Service (TGS) Exchange .......   24
+   3.3.1. Generation of KRB_TGS_REQ message ..............   25
+   3.3.2. Receipt of KRB_TGS_REQ message .................   26
+   3.3.3. Generation of KRB_TGS_REP message ..............   27
+   3.3.3.1. Encoding the transited field .................   29
+   3.3.4. Receipt of KRB_TGS_REP message .................   31
+   3.4. The KRB_SAFE Exchange ............................   31
+   3.4.1. Generation of a KRB_SAFE message ...............   31
+   3.4.2. Receipt of KRB_SAFE message ....................   32
+   3.5. The KRB_PRIV Exchange ............................   33
+   3.5.1. Generation of a KRB_PRIV message ...............   33
+   3.5.2. Receipt of KRB_PRIV message ....................   33
+   3.6. The KRB_CRED Exchange ............................   34
+   3.6.1. Generation of a KRB_CRED message ...............   34
+   3.6.2. Receipt of KRB_CRED message ....................   34
+   4. The Kerberos Database ..............................   35
+   4.1. Database contents ................................   35
+   4.2. Additional fields ................................   36
+   4.3. Frequently Changing Fields .......................   37
+   4.4. Site Constants ...................................   37
+   5. Message Specifications .............................   38
+   5.1. ASN.1 Distinguished Encoding Representation ......   38
+   5.2. ASN.1 Base Definitions ...........................   38
+   5.3. Tickets and Authenticators .......................   42
+   5.3.1. Tickets ........................................   42
+   5.3.2. Authenticators .................................   47
+   5.4. Specifications for the AS and TGS exchanges ......   49
+   5.4.1. KRB_KDC_REQ definition .........................   49
+   5.4.2. KRB_KDC_REP definition .........................   56
+   5.5. Client/Server (CS) message specifications ........   58
+   5.5.1. KRB_AP_REQ definition ..........................   58
+   5.5.2. KRB_AP_REP definition ..........................   60
+   5.5.3. Error message reply ............................   61
+   5.6. KRB_SAFE message specification ...................   61
+   5.6.1. KRB_SAFE definition ............................   61
+   5.7. KRB_PRIV message specification ...................   62
+   5.7.1. KRB_PRIV definition ............................   62
+   5.8. KRB_CRED message specification ...................   63
+   5.8.1. KRB_CRED definition ............................   63
+   5.9. Error message specification ......................   65
+   5.9.1. KRB_ERROR definition ...........................   66
+   6. Encryption and Checksum Specifications .............   67
+   6.1. Encryption Specifications ........................   68
+   6.2. Encryption Keys ..................................   71
+   6.3. Encryption Systems ...............................   71
+   6.3.1. The NULL Encryption System (null) ..............   71
+   6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71
+
+
+
+Kohl & Neuman                                                   [Page 3]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4)  72
+   6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5)  72
+   6.4. Checksums ........................................   74
+   6.4.1. The CRC-32 Checksum (crc32) ....................   74
+   6.4.2. The RSA MD4 Checksum (rsa-md4) .................   75
+   6.4.3. RSA MD4 Cryptographic Checksum Using DES
+   (rsa-md4-des) .........................................   75
+   6.4.4. The RSA MD5 Checksum (rsa-md5) .................   76
+   6.4.5. RSA MD5 Cryptographic Checksum Using DES
+   (rsa-md5-des) .........................................   76
+   6.4.6. DES cipher-block chained checksum (des-mac)
+   6.4.7. RSA MD4 Cryptographic Checksum Using DES
+   alternative (rsa-md4-des-k) ...........................   77
+   6.4.8. DES cipher-block chained checksum alternative
+   (des-mac-k) ...........................................   77
+   7. Naming Constraints .................................   78
+   7.1. Realm Names ......................................   77
+   7.2. Principal Names ..................................   79
+   7.2.1. Name of server principals ......................   80
+   8. Constants and other defined values .................   80
+   8.1. Host address types ...............................   80
+   8.2. KDC messages .....................................   81
+   8.2.1. IP transport ...................................   81
+   8.2.2. OSI transport ..................................   82
+   8.2.3. Name of the TGS ................................   82
+   8.3. Protocol constants and associated values .........   82
+   9. Interoperability requirements ......................   86
+   9.1. Specification 1 ..................................   86
+   9.2. Recommended KDC values ...........................   88
+   10. Acknowledgments ...................................   88
+   11. References ........................................   89
+   12. Security Considerations ...........................   90
+   13. Authors' Addresses ................................   90
+   A. Pseudo-code for protocol processing ................   91
+   A.1. KRB_AS_REQ generation ............................   91
+   A.2. KRB_AS_REQ verification and KRB_AS_REP generation    92
+   A.3. KRB_AS_REP verification ..........................   95
+   A.4. KRB_AS_REP and KRB_TGS_REP common checks .........   96
+   A.5. KRB_TGS_REQ generation ...........................   97
+   A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation  98
+   A.7. KRB_TGS_REP verification .........................  104
+   A.8. Authenticator generation .........................  104
+   A.9. KRB_AP_REQ generation ............................  105
+   A.10. KRB_AP_REQ verification .........................  105
+   A.11. KRB_AP_REP generation ...........................  106
+   A.12. KRB_AP_REP verification .........................  107
+   A.13. KRB_SAFE generation .............................  107
+   A.14. KRB_SAFE verification ...........................  108
+
+
+
+Kohl & Neuman                                                   [Page 4]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   A.15. KRB_SAFE and KRB_PRIV common checks .............  108
+   A.16. KRB_PRIV generation .............................  109
+   A.17. KRB_PRIV verification ...........................  110
+   A.18. KRB_CRED generation .............................  110
+   A.19. KRB_CRED verification ...........................  111
+   A.20. KRB_ERROR generation ............................  112
+
+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
+   authentication 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. (Note,
+   however, that many applications use Kerberos' functions only upon the
+   initiation of a stream-based network connection, and assume the
+   absence of any "hijackers" who might subvert such a connection.  Such
+   use implicitly trusts the host addresses involved.)  Kerberos
+   performs authentication under these conditions as a trusted third-
+   party authentication service by using conventional cryptography,
+   i.e., shared secret key.  (shared secret key - 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.)
+
+   The 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.
+
+   The implementation 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
+
+
+
+Kohl & Neuman                                                   [Page 5]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   transactions, a typical network application adds one or two calls to
+   the Kerberos library, which results in the transmission of the
+   necessary messages to achieve authentication.
+
+   The Kerberos protocol consists of several sub-protocols (or
+   exchanges).  There are two 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 sends the TGT to
+   the TGS in the same manner as if it were contacting any other
+   application server which requires Kerberos credentials.  The reply is
+   encrypted in the session key from the TGT.
+
+   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 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
+   was originated by 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 integrity of the
+   messages exchanged between principals can be secured by encrypting
+   the data to be passed using the session key passed in the ticket, and
+   contained in the credentials.
+
+   The authentication exchanges mentioned above require read-only access
+   to the Kerberos database.  Sometimes, however, the entries in the
+
+
+
+Kohl & Neuman                                                   [Page 6]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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).  The administration protocol is not described in this
+   document. There is also a protocol for maintaining multiple copies of
+   the Kerberos database, but this can be considered an implementation
+   detail and may vary to support different database technologies.
+
+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 use its
+   authentication remotely (Of course, with appropriate permission the
+   client could arrange registration of a separately-named principal 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).  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 some database in order to construct an
+
+
+
+Kohl & Neuman                                                   [Page 7]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+1.2.  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 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 not-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 per-server basis.  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
+
+
+
+Kohl & Neuman                                                   [Page 8]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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.3.  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.
+
+
+
+
+
+
+Kohl & Neuman                                                   [Page 9]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+
+   Principal           A uniquely named client or server
+                       instance that participates in a network
+                       communication.
+
+
+
+
+Kohl & Neuman                                                  [Page 10]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+
+   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.
+
+
+
+Kohl & Neuman                                                  [Page 11]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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 knowledge of a client's
+   secret key (e.g., a passwordchanging 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).
+
+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 shortlived 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
+
+
+
+Kohl & Neuman                                                  [Page 12]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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-
+
+
+
+Kohl & Neuman                                                  [Page 13]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 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 by
+   default.
+
+   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 (It is permissible to request or
+   issue tickets with no network addresses specified, but we do not
+   recommend it).  For this reason, a client wishing to grant a proxy
+   must request a new ticket valid for the network address of the
+   service to be granted the proxy.
+
+   The PROXY flag is set in a ticket by the  TGS  when  it issues a
+   proxy ticket.  Application servers may check this flag and require
+   additional authentication  from  the  agent presenting the proxy in
+   order to provide an audit trail.
+
+
+
+
+
+Kohl & Neuman                                                  [Page 14]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+2.6.  Forwardable tickets
+
+   Authentication forwarding is an instance of the proxy case 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 end result
+   can still be achieved if the user engages in the AS exchange with 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 it be set 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 wish 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 to-be-issued ticket for the end
+   server is to be encrypted in the session key from the additional
+   ticket-granting ticket provided with the request.  See section 3.3.3
+   for specific details.
+
+
+
+
+
+Kohl & Neuman                                                  [Page 15]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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 usually initiated by a client when
+   it wishes to obtain authentication credentials for a given server but
+   currently holds no credentials.  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.  (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 session and
+   change another user's password.)  This exchange does not by itself
+   provide any assurance of the the identity of the user.  (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 the local server through successful completion of the
+   Client/Server exchange.)
+
+   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
+
+
+
+Kohl & Neuman                                                  [Page 16]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 also 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 or fabrications of such messages.
+
+   In the normal case 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 if desired, but the
+   mechanism is not currently specified.
+
+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 preauthentication 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 nonrenewable ticket (due to
+   configuration constraints; see section 4).  See section A.1 for
+   pseudocode.
+
+   The client prepares the KRB_AS_REQ message and sends it to the KDC.
+
+3.1.2. Receipt of KRB_AS_REQ message
+
+   If all goes well, processing the KRB_AS_REQ message will result in
+   the creation of a ticket for the client to present to the server.
+   The format for the ticket is described in section 5.3.1.  The
+   contents of the ticket are determined as follows.
+
+3.1.3. Generation of KRB_AS_REP message
+
+   The authentication server looks up the client and server principals
+   named in the KRB_AS_REQ in its database, extracting their respective
+   keys.  If required, the server pre-authenticates the request, and if
+   the pre-authentication check fails, an error message with the code
+   KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate
+   the requested encryption type, an error message with code
+
+
+
+Kohl & Neuman                                                  [Page 17]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
+   session key ("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 would be
+   more desirable to use a truly random number generator, such as one
+   based on measurements of random physical phenomena.).
+
+   If the requested start time is absent or indicates a time in the
+   past, then the start time of the ticket is set to the authentication
+   server's current time. If it indicates a time in the future, 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:
+
+
+
+Kohl & Neuman                                                  [Page 18]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   +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 postdated (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, 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
+
+
+
+Kohl & Neuman                                                  [Page 19]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.  If those credentials can be verified, then the identity
+   of the user can be assured.
+
+3.1.6. Receipt of KRB_ERROR message
+
+   If the reply message type is KRB_ERROR, then the client interprets it
+   as an error and performs whatever application-specific tasks are
+   necessary to recover.
+
+3.2.  The Client/Server Authentication Exchange
+
+                        Summary
+
+   Message direction                         Message type    Section
+   Client to Application server              KRB_AP_REQ      5.5.1
+   [optional] Application server to client   KRB_AP_REP or   5.5.2
+                                             KRB_ERROR       5.9.1
+
+   The client/server authentication (CS) exchange is used by network
+   applications to authenticate the client to the server and vice versa.
+   The client must have already acquired credentials for the server
+   using the AS or TGS exchange.
+
+3.2.1. The KRB_AP_REQ message
+
+   The KRB_AP_REQ contains authentication information which should be
+   part of the first message in an authenticated transaction.  It
+   contains a ticket, an authenticator, and some additional bookkeeping
+   information (see section 5.5.1 for the exact format).  The ticket by
+   itself is insufficient to authenticate a client, since tickets are
+   passed across the network in cleartext(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.), 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 it.  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
+
+
+
+Kohl & Neuman                                                  [Page 20]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   TGS exchange) a ticket and session key for the desired service.  The
+   client may re-use any tickets it holds until they expire.  The client
+   then 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 (Note that this can make
+   applications based on unreliable transports difficult to code
+   correctly, if the transport might deliver duplicated messages.  In
+   such cases, a new authenticator must be generated for each retry.).
+   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 (This is
+   used for user-to-user authentication as described in [6]).  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
+
+
+
+Kohl & Neuman                                                  [Page 21]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 (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.).  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.
+
+
+
+
+Kohl & Neuman                                                  [Page 22]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+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). [Note: 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.]  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 (Note that for
+   encrypting the KRB_AP_REP message, the sub-session key is not used,
+   even if present in the Authenticator.) 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
+
+
+
+Kohl & Neuman                                                  [Page 23]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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
+   (Implementations of the protocol may wish to provide routines to
+   choose subkeys based on session keys and random numbers and to
+   orchestrate a negotiated key to be returned in the KRB_AP_REP
+   message.).  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 a 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.
+
+   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 or KRB_ERROR responses
+   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
+
+
+
+Kohl & Neuman                                                  [Page 24]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 subsession 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
+   [Note: This can be accomplished in several ways.  It might be known
+   beforehand (since the realm is part of the principal identifier), or
+   it might be stored in a nameserver.  Presently, however, this
+   information is obtained from a configuration 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
+   authenticated.  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.].  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 the local Kerberos server (using the
+
+
+
+Kohl & Neuman                                                  [Page 25]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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; as long as the secret keys exchanged by realms
+   are kept secret, only denial of service results from 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 (If the client selects a sub-session key, care must be
+   taken to ensure the randomness of the selected subsession key.  One
+   approach would be to generate a random number and XOR it with the
+   session key from the ticket-granting ticket.). 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 in 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
+
+
+
+Kohl & Neuman                                                  [Page 26]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+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.
+
+
+
+
+Kohl & Neuman                                                  [Page 27]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 (endtimestarttime) 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 or indicates a time in the
+   past, then the start time of the ticket is set to the authentication
+   server's current time.  If it indicates a time in the future, 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
+   MAYPOSTDATE 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 (This allows easy implementation of user-to-
+   user authentication [6], which uses ticket-granting ticket session
+   keys in lieu of secret server keys in situations where such secret
+
+
+
+Kohl & Neuman                                                  [Page 28]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   keys could be easily compromised.).
+
+   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, and the server is registered in the realm of
+   the KDC, If the RENEW option is requested, then the KDC will verify
+   that the RENEWABLE flag is 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,
+   the KDC will issue the appropriate new ticket.
+
+   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 dates 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.1.  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,
+
+
+
+Kohl & Neuman                                                  [Page 29]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 preceding 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 endpoints,
+   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 (For the purpose of appending, the realm preceding
+   the first listed realm is considered to be the null realm ("")).  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".
+
+
+
+Kohl & Neuman                                                  [Page 30]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 (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.). 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 collisionproof 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 some sort of
+   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
+
+
+
+Kohl & Neuman                                                  [Page 31]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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
+   collisionproof keyed checksum, and if it is not, a
+   KRB_AP_ERR_INAPP_CKSUM error is generated.  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 timestamp and usec or a sequence
+   number is present, a KRB_AP_ERR_MODIFIED error is generated.
+
+
+
+Kohl & Neuman                                                  [Page 32]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 modified 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.  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
+
+
+
+Kohl & Neuman                                                  [Page 33]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 timestamp 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 raddress 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.
+
+
+
+Kohl & Neuman                                                  [Page 34]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 (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.).
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 35]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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
+
+
+
+Kohl & Neuman                                                  [Page 36]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 [7]), or to identify the "string to key" conversion algorithm
+   used for a principal's key.  (See the discussion of the padata field
+   in section 5.4.2 for details on why this can be useful.)  Other bits
+   are used to indicate that certain ticket options should not be
+   allowed in tickets encrypted under a principal's key (one bit each):
+   Disallow issuing postdated tickets, disallow issuing forwardable
+   tickets, disallow issuing tickets based on TGT authentication,
+   disallow issuing renewable tickets, disallow issuing proxiable
+   tickets, and disallow issuing tickets for which the principal is the
+   server.
+
+   The mod_date field contains the time of last modification of the
+   entry, and the mod_name field contains the name of the principal
+   which last modified the entry.
+
+4.3.  Frequently Changing Fields
+
+   Some KDC implementations may wish to maintain the last time that a
+   request was made by a particular principal.  Information that might
+   be maintained includes the time of the last request, the time of the
+   last request for a ticket-granting ticket, the time of the last use
+   of a ticket-granting ticket, or other times.  This information can
+   then be returned to the user in the last-req field (see section 5.2).
+
+   Other frequently changing information that can be maintained is the
+   latest expiration time for any tickets that have been issued using
+   each key.  This field would be used to indicate how long old keys
+   must remain valid to allow the continued use of outstanding tickets.
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 37]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+      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.
+
+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 [8].
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 38]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 General
+               String.  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 SEQUENCE {
+                        addr-type[0]             INTEGER,
+                        address[1]               OCTET STRING
+    }
+
+
+   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
+
+
+
+Kohl & Neuman                                                  [Page 39]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   address; HostAddresses contains a sequence of possibly many
+   addresses.
+
+   AuthorizationData ::=   SEQUENCE OF SEQUENCE {
+                           ad-type[0]               INTEGER,
+                           ad-data[1]               OCTET STRING
+   }
+
+
+   ad-data   This field contains authorization data to be
+             interpreted according to the value of the
+             corresponding ad-type field.
+
+   ad-type   This field specifies the format for the ad-data
+             subfield.  All negative values are reserved for
+             local use.  Non-negative values are reserved for
+             registered use.
+
+                   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)
+                   }
+
+                  KDCOptions ::=   BIT STRING {
+                                   reserved(0),
+                                   forwardable(1),
+                                   forwarded(2),
+                                   proxiable(3),
+                                   proxy(4),
+                                   allow-postdate(5),
+                                   postdated(6),
+
+
+
+Kohl & Neuman                                                  [Page 40]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                                   unused7(7),
+                                   renewable(8),
+                                   unused9(9),
+                                   unused10(10),
+                                   unused11(11),
+                                   renewable-ok(27),
+                                   enc-tkt-in-skey(28),
+                                   renew(30),
+                                   validate(31)
+                  }
+
+
+            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).
+
+   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.
+
+
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 41]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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.
+
+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
+}
+-- 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
+
+
+
+Kohl & Neuman                                                  [Page 42]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             always be identical.
+
+   sname     This field specifies the name part of the server's
+             identity.
+
+   enc-part  This field holds the encrypted encoding of the
+             EncTicketPart sequence.
+
+   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.
+
+
+
+
+Kohl & Neuman                                                  [Page 43]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             4         PROXY      When set, this flag indicates that a
+                                   ticket is a proxy.
+
+             5         MAY-POSTDATE The MAY-POSTDATE flag is normally
+                                   only interpreted by the TGS, and can
+                                   be ignored by end servers.  This flag
+                                   tells the ticket-granting server that
+                                   a post- dated ticket may be issued
+                                   based on this ticket-granting ticket.
+
+             6         POSTDATED   This flag indicates that this ticket
+                                   has been postdated.  The end-service
+                                   can check the authtime field to see
+                                   when the original authentication
+                                   occurred.
+
+             7         INVALID     This flag indicates that a ticket is
+                                   invalid, and it must be validated by
+                                   the KDC before use.  Application
+                                   servers must reject tickets which
+                                   have this flag set.
+
+             8         RENEWABLE   The RENEWABLE flag is normally only
+                                   interpreted by the TGS, and can
+                                   usually be ignored by end servers
+                                   (some particularly careful servers
+                                   may wish to disallow renewable
+                                   tickets).  A renewable ticket can be
+                                   used to obtain a replacement 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 authenticated by the KDC before a
+                                   ticket was issued.  The strength of
+                                   the preauthentication 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
+
+
+
+Kohl & Neuman                                                  [Page 44]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                                   client.  The hardware authentication
+                                   method is selected by the KDC and the
+                                   strength of the method is not
+                                   indicated.
+
+             12-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.1 for details on how
+             this field encodes the traversed realms.
+
+   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 (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.).
+
+   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
+
+
+
+Kohl & Neuman                                                  [Page 45]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             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.
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 46]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.  The data in this field are specific to the end
+             service.  It is expected that 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 subfields, 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.
+
+             It is interesting to note that 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 [9] 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,
+
+
+
+Kohl & Neuman                                                  [Page 47]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+               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 application 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.
+
+             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.
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 48]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 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,
+            rtime[6]             KerberosTime OPTIONAL,
+            nonce[7]             INTEGER,
+
+
+
+Kohl & Neuman                                                  [Page 49]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+            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 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 collisionproof) 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
+   }
+
+
+
+
+Kohl & Neuman                                                  [Page 50]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             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.
+
+             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
+             "smartcards" with Kerberos.  The details of such extensions
+             are beyond the scope of this specification.  See [10] 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:
+
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 51]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             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
+                                  subsequent request if the ticket-
+                                  granting ticket on which it is based
+                                  is also forwardable.
+
+             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
+                                  proxiable 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 subsequent request if
+
+
+
+Kohl & Neuman                                                  [Page 52]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                                  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-26    RESERVED     Reserved for future use.
+
+             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
+
+
+
+Kohl & Neuman                                                  [Page 53]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                                  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 validate 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 validated 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.
+
+
+
+
+Kohl & Neuman                                                  [Page 54]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+   till      This field contains the expiration date requested by the
+             client in a ticket request.
+
+   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 gen erated
+             randomly, but if the correct time is known, it may suffice
+             (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.).
+
+   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).
+
+
+
+Kohl & Neuman                                                  [Page 55]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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,
+                 enc-part[6]                EncryptedData
+   }
+
+   EncASRepPart ::=    [APPLICATION 25[25]] EncKDCRepPart
+   EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
+
+   EncKDCRepPart ::=   SEQUENCE {
+               key[0]                       EncryptionKey,
+               last-req[1]                  LastReq,
+
+
+
+Kohl & Neuman                                                  [Page 56]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+               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
+   }
+
+   NOTE: In EncASRepPart, the application code in the encrypted
+         part of a message provides an additional check that
+         the message was decrypted properly.
+
+   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
+
+
+
+Kohl & Neuman                                                  [Page 57]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             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
+             expira    tion 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,
+
+
+
+Kohl & Neuman                                                  [Page 58]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                   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-KEYThe 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 specified, the ticket is
+                                  encrypted in the server's secret key.
+
+             2       MUTUAL-REQUIREDThe 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.
+
+
+
+
+Kohl & Neuman                                                  [Page 59]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+5.5.2.  KRB_AP_REP definition
+
+   The KRB_AP_REP message contains the Kerberos protocol version number,
+   the message type, and an encrypted timestamp. 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]     SEQUENCE {
+              ctime[0]                  KerberosTime,
+              cusec[1]                  INTEGER,
+              subkey[2]                 EncryptionKey OPTIONAL,
+              seq-number[3]             INTEGER OPTIONAL
+   }
+
+   NOTE: in EncAPRepPart, the application code in the encrypted part of
+   a message provides an additional check that the message was decrypted
+   properly.
+
+   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.
+
+
+
+
+
+Kohl & Neuman                                                  [Page 60]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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 session key.  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,
+               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.  It is to be encoded separately and then have the
+             checksum computed over it, for use in the cksum field.
+
+   cksum     This field contains the checksum of the application data.
+             Checksum details are described in section 6.4.  The
+
+
+
+Kohl & Neuman                                                  [Page 61]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             checksum is computed over the encoding of the KRB-SAFE-BODY
+             sequence.
+
+   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.
+
+   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
+   }
+
+
+
+
+
+Kohl & Neuman                                                  [Page 62]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
+                user-data[0]              OCTET STRING,
+                timestamp[1]              KerberosTime OPTIONAL,
+                usec[2]                   INTEGER OPTIONAL,
+                seq-number[3]             INTEGER OPTIONAL,
+                s-address[4]              HostAddress, -- sender's addr
+                r-address[5]              HostAddress OPTIONAL
+                                                      -- recip's addr
+   }
+
+   NOTE: In EncKrbPrivPart, the application code in the encrypted part
+   of a message provides an additional check that the message was
+   decrypted properly.
+
+   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 (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.).  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
+
+
+
+Kohl & Neuman                                                  [Page 63]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   each.  The information needed to use the tickets is encryped under an
+   encryption key previously exchanged.  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 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.
+
+
+
+Kohl & Neuman                                                  [Page 64]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 mes  sage 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
+             corresponding 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 not protected by any
+   encryption, it is quite possible for an intruder to synthesize or
+
+
+
+Kohl & Neuman                                                  [Page 65]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   modify such a message.  In particular, this means that 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
+   }
+
+   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 999. 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
+
+
+
+Kohl & Neuman                                                  [Page 66]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+             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 the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
+             the e-data field will contain an encoding of a sequence of
+             padata fields, each corresponding to an acceptable pre-
+             authentication method and optionally containing data for
+             the method:
+
+      METHOD-DATA ::=    SEQUENCE of PA-DATA
+
+   If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
+   contain an encoding of the following sequence:
+
+      METHOD-DATA ::=    SEQUENCE {
+                         method-type[0]   INTEGER,
+                         method-data[1]   OCTET STRING OPTIONAL
+       }
+
+   method-type will indicate the required alternate method; method-data
+   will contain any required additional information.
+
+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 [11], in conjunction with block chaining and checksum
+   methods [12].  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
+
+
+
+Kohl & Neuman                                                  [Page 67]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 plaintext 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 a discussion of the integrity characteristics of the candidate
+   encryption and checksum methods considered for Kerberos, the the
+   reader is referred to [13].
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 68]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   section 5 is a sequence consisting of an encryption type, an optional
+   key version number, and the ciphertext.
+
+   EncryptedData ::=   SEQUENCE {
+                       etype[0]     INTEGER, -- EncryptionType
+                       kvno[1]      INTEGER OPTIONAL,
+                       cipher[2]    OCTET STRING -- ciphertext
+   }
+
+   etype     This field identifies which encryption algorithm was used
+             to encipher the cipher.  Detailed specifications for
+             selected encryption types appear later in this section.
+
+   kvno      This field contains the version number of the key under
+             which data is encrypted.  It is only present in messages
+             encrypted under long lasting keys, such as principals'
+             secret keys.
+
+   cipher    This field contains the enciphered text, encoded as an
+             OCTET STRING.
+
+   The cipher field is generated by applying the specified encryption
+   algorithm to data composed of the message and algorithm-specific
+   inputs.  Encryption mechanisms defined for use with Kerberos must
+   take sufficient measures to guarantee the integrity of the plaintext,
+   and we recommend they also take measures to protect against
+   precomputed dictionary attacks.  If the encryption algorithm is not
+   itself capable of doing so, the protections can often be enhanced by
+   adding a checksum and a confounder.
+
+   The suggested format for the data to be encrypted includes a
+   confounder, a checksum, the encoded plaintext, and any necessary
+   padding.  The msg-seq field contains the part of the protocol message
+   described in section 5 which is to be encrypted.  The confounder,
+   checksum, and padding are all untagged and untyped, and their length
+   is exactly sufficient to hold the appropriate item.  The type and
+   length is implicit and specified by the particular encryption type
+   being used (etype).  The format for the data to be encrypted is
+   described in the following diagram:
+
+         +-----------+----------+-------------+-----+
+         |confounder |   check  |   msg-seq   | pad |
+         +-----------+----------+-------------+-----+
+
+   The format cannot be described in ASN.1, but for those who prefer an
+   ASN.1-like notation:
+
+
+
+
+
+Kohl & Neuman                                                  [Page 69]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+CipherText ::=   ENCRYPTED       SEQUENCE {
+         confounder[0]   UNTAGGED OCTET STRING(conf_length)     OPTIONAL,
+         check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
+         msg-seq[2]      MsgSequence,
+         pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
+}
+
+   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.
+
+   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 (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.). 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.
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 70]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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 key that
+             follows in the keyvalue field.  It will almost always
+             correspond to the encryption algorithm used to generate the
+             EncryptedData, though more than one algorithm may use the
+             same type of key (the mapping is many to one).  This might
+             happen, for example, if the encryption algorithm uses an
+             alternate checksum algorithm for an integrity check, or a
+             different chaining mechanism.
+
+   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 interpretations.
+
+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 [11] using the cipher block chaining mode [12].
+   A CRC-32 checksum (described in ISO 3309 [14]) 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 collisionproof, an
+
+
+
+Kohl & Neuman                                                  [Page 71]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   attacker could use a probabilistic chosenplaintext attack to generate
+   a valid message even if a confounder is used [13]. 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 [11] using the cipher block chaining mode [12].
+   An MD4 checksum (described in [15]) 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 descbc-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 [11] using the cipher block chaining mode [12].
+   An MD5 checksum (described in [16]) 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 8-octet blocks 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 "semiweak" 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 constant
+   F0F0F0F0F0F0F0F0.
+
+
+
+Kohl & Neuman                                                  [Page 72]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.]
+
+   To generate a DES key from a text string (password), the text string
+   normally must have the realm and each component of the principal's
+   name appended(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.), then padded with ASCII nulls to an 8 byte
+   boundary.  This string is then fan-folded and eXclusive-ORed with
+   itself to form an 8 byte DES key.  The parity is corrected on the
+   key, and it is used to generate a DES CBC checksum on the initial
+   string (with the realm and name appended).  Next, parity is corrected
+   on the CBC checksum.  If the result matches a "weak" or "semiweak"
+   key as described in the DES specification, it is eXclusive-ORed with
+   the constant 00000000000000F0.  Finally, the result is returned as
+   the key.  Pseudocode follows:
+
+        string_to_key(string,realm,name) {
+             odd = 1;
+             s = string + realm;
+             for(each component in name) {
+                  s = s + component;
+             }
+             tempkey = NULL;
+             pad(s); /* with nulls to 8 byte boundary */
+             for(8byteblock in s) {
+                  if(odd == 0)  {
+                      odd = 1;
+                      reverse(8byteblock)
+                  }
+                  else odd = 0;
+                  tempkey = tempkey XOR 8byteblock;
+             }
+             fixparity(tempkey);
+             key = DES-CBC-check(s,tempkey);
+             fixparity(key);
+             if(is_weak_key_key(key))
+                  key = key XOR 0xF0;
+             return(key);
+        }
+
+
+
+Kohl & Neuman                                                  [Page 73]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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 as well 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 collisionproof
+   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 [14].  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 [13] 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
+
+
+
+Kohl & Neuman                                                  [Page 74]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   significant threat.
+
+6.4.2. The RSA MD4 Checksum (rsa-md4)
+
+   The RSA-MD4 checksum calculates a checksum using the RSA MD4
+   algorithm [15].  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-md4des)
+
+   The RSA-MD4-DES checksum calculates a keyed collisionproof 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 (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.).  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"; those keys shall
+   not be used for generating RSA-MD4 checksums for use in Kerberos.
+
+   The format for the checksum is described in the following 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)
+   }
+
+
+
+Kohl & Neuman                                                  [Page 75]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+6.4.4. The RSA MD5 Checksum (rsa-md5)
+
+   The RSA-MD5 checksum calculates a checksum using the RSA MD5
+   algorithm [16].  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-md5des)
+
+   The RSA-MD5-DES checksum calculates a keyed collisionproof 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 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"; 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
+
+
+
+Kohl & Neuman                                                  [Page 76]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   eXclusive-ORing the key with the 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 "semiweak" keys;
+   those keys shall not be used for generating DES-MAC checksums for use
+   in Kerberos, nor shall a key be used whose veriant 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 cipherblock-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 (desmac-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
+
+
+
+Kohl & Neuman                                                  [Page 77]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   this checksum type is the old method for encoding the DESMAC checksum
+   and it is no longer recommended.
+
+   The DES specifications identify some "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.
+
+   There are presently four styles of realm names: domain, X500, other,
+   and reserved.  Examples of each style follow:
+
+        domain:   host.subdomain.domain (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 (/).
+
+   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
+
+
+
+Kohl & Neuman                                                  [Page 78]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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).  This constraint may be eliminated in the future.  The
+   following name types are defined:
+
+      name-type      value   meaning
+      NT-UNKNOWN       0     Name type not known
+      NT-PRINCIPAL     1     Just the name of the principal as in
+                             DCE, or for users
+      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 host as remaining components
+      NT-UID           5     Unique ID
+
+   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).
+
+
+
+Kohl & Neuman                                                  [Page 79]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 ticket
+   which 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 SRVXHST 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 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.  For services such as telnet and the
+   Berkeley R commands which run with system privileges, the first
+   component will be the string "host" instead of a service specific
+   identifier.
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 80]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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 <sys/socket.h> with
+   symbolic names AF_xxx (where xxx is an abbreviation of the address
+   family name).
+
+
+   Internet addresses
+
+      Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
+      order.  The type of internet addresses is two (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).
+
+8.2.  KDC messages
+
+8.2.1. IP transport
+
+   When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
+   using 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
+
+
+
+Kohl & Neuman                                                  [Page 81]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+8.2.2. OSI transport
+
+   During authentication of an OSI client to and 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(5),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-SRVINST, 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.
+
+
+
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 82]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+---------------+-----------+----------+----------------+---------------
+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
+
+-------------------------------+-------------------+-------------
+Checksum type                  |sumtype value      |checksum size
+-------------------------------+-------------------+-------------
+CRC32                           1                   4
+rsa-md4                         2                   16
+rsa-md4-des                     3                   24
+des-mac                         4                   16
+des-mac-k                       5                   8
+rsa-md4-des-k                   6                   16
+rsa-md5                         7                   16
+rsa-md5-des                     8                   24
+
+-------------------------------+-----------------
+padata type                    |padata-type value
+-------------------------------+-----------------
+PA-TGS-REQ                      1
+PA-ENC-TIMESTAMP                2
+PA-PW-SALT                      3
+
+-------------------------------+-------------
+authorization data type        |ad-type value
+-------------------------------+-------------
+reserved values                 0-63
+OSF-DCE                         64
+SESAME                          65
+
+-------------------------------+-----------------
+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
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 83]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+--------------+-------+-----------------------------------------
+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
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 84]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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-authentication
+                                   required*
+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
+
+
+
+Kohl & Neuman                                                  [Page 85]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                                   message
+KRB_ERR_GENERIC               60   Generic error (description in e-text)
+KRB_ERR_FIELD_TOOLONG         61   Field is too long for this
+                                   implementation
+
+   *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.
+
+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 1
+
+   This section defines the first specification of these options.
+   Implementations which are configured in this way can be said to
+   support Kerberos Version 5 Specification 1 (5.1).
+
+   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: Encryption: DES-CBC-MD5
+   Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
+
+   Realm Names
+
+   All implementations must understand hierarchical realms in both the
+   Internet Domain and the X.500 style.  When a ticket granting ticket
+   for an unknown realm is requested, the KDC must be able to determine
+   the names of the intermediate realms between the KDCs realm and the
+   requested realm.
+
+
+
+
+Kohl & Neuman                                                  [Page 86]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   Transited field encoding
+
+   DOMAIN-X500-COMPRESS (described in section 3.3.3.1) 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-ENCTIMESTAMP
+   as an acceptable method, the client should retry the initial request
+   using the PA-ENC-TIMESTAMP preauthentication method. Servers need not
+   support the PAENC-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. By default, servers should not accept 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-TKTIN-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.
+
+
+
+Kohl & Neuman                                                  [Page 87]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   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.
+
+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.  Acknowledgments
+
+   Early versions of this document, describing version 4 of the
+   protocol, were written by Jennifer Steiner (formerly at Project
+   Athena); these drafts provided an excellent starting point for this
+   current version 5 specification.  Many people in the Internet
+   community have contributed ideas and suggested protocol changes for
+   version 5. Notable contributions came from Ted Anderson, Steve
+   Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows,
+   Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill
+   Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon,
+   Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted
+   T'so, and Stanley Zanarotti.  Many others commented and helped shape
+   this specification into its current form.
+
+
+
+
+
+
+
+Kohl & Neuman                                                  [Page 88]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+11.  References
+
+   [1]  Miller, S., Neuman, C., Schiller, J., and  J. Saltzer, "Section
+        E.2.1: Kerberos  Authentication and Authorization System",
+        M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
+        1987.
+
+   [2]  Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
+        Authentication Service for Open Network Systems", pp. 191-202 in
+        Usenix Conference Proceedings, Dallas, Texas, February, 1988.
+
+   [3]  Needham, R., and M. Schroeder, "Using Encryption for
+        Authentication in Large Networks of Computers", Communications
+        of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
+
+   [4]  Denning, D., and G. Sacco, "Time stamps in Key Distribution
+        Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
+        August 1981.
+
+   [5]  Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
+        Kerberos Authentication Service", in an IEEE Computer Society
+        Text soon to be published, June 1992.
+
+   [6]  Davis, D., and R. Swick, "Workstation Services and Kerberos
+        Authentication at Project Athena", Technical Memorandum TM-424,
+        MIT Laboratory for Computer Science, February 1990.
+
+   [7]  Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
+        Raeburn, "Section E.1: Service Management System, M.I.T.
+        Project Athena, Cambridge, Mas sachusetts (1987).
+
+   [8]  CCITT, Recommendation X.509: The Directory Authentication
+        Framework, December 1988.
+
+   [9]  Neuman, C., "Proxy-Based Authorization and Accounting for
+        Distributed Systems," in Proceedings of the 13th International
+        Conference on Distributed Computing Systems", Pittsburgh, PA,
+        May 1993.
+
+   [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
+        Attacks", Open Software Foundation DCE Request for Comments 26,
+        December 1992.
+
+   [11] National Bureau of Standards, U.S. Department of Commerce, "Data
+        Encryption Standard", Federal Information Processing Standards
+        Publication 46, Washington, DC (1977).
+
+
+
+
+
+Kohl & Neuman                                                  [Page 89]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+   [12] National Bureau of Standards, U.S. Department of Commerce, "DES
+        Modes of Operation", Federal Information Processing Standards
+        Publication 81, Springfield, VA, December 1980.
+
+   [13] Stubblebine S., and V. Gligor, "On Message Integrity in
+        Cryptographic Protocols", in Proceedings of the IEEE Symposium
+        on Research in Security and Privacy, Oakland, California, May
+        1992.
+
+   [14] International Organization for Standardization, "ISO Information
+        Processing Systems - Data Communication High-Level Data Link
+        Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
+        Edition.
+
+   [15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT
+        Laboratory for Computer Science, April 1992.
+
+   [16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
+        Laboratory for Computer Science, April 1992.
+
+   [17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
+        Authentication System", Computer Communications Review, Vol.
+        20(5), pp. 119-132, October 1990.
+
+12.  Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+13.  Authors' Addresses
+
+   John Kohl
+   Digital Equipment Corporation
+   110 Spit Brook Road, M/S ZKO3-3/U14
+   Nashua, NH  03062
+
+   Phone: 603-881-2481
+   EMail: jtkohl@zk3.dec.com
+
+
+   B. Clifford Neuman
+   USC/Information Sciences Institute
+   4676 Admiralty Way #1001
+   Marina del Rey, CA 90292-6695
+
+   Phone: 310-822-1511
+   EMail: bcn@isi.edu
+
+
+
+
+
+Kohl & Neuman                                                  [Page 90]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+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
+
+
+
+Kohl & Neuman                                                  [Page 91]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+A.2.  KRB_AS_REQ verification and KRB_AS_REP generation
+        decode message into req;
+
+        client := lookup(req.cname,req.realm);
+        server := lookup(req.sname,req.realm);
+        get system_time;
+        kdc_time := system_time.seconds;
+
+        if (!client) then
+                /* no client in Database */
+                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
+        endif
+        if (!server) then
+                /* no server in Database */
+                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
+        endif
+
+        if(client.pa_enc_timestamp_required and
+           pa_enc_timestamp not present) then
+                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
+        endif
+
+        if(pa_enc_timestamp present) then
+                decrypt req.padata-value into decrypted_enc_timestamp
+                        using client.key;
+                        using auth_hdr.authenticator.subkey;
+                if (decrypt_error()) then
+                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
+                if(decrypted_enc_timestamp is not within allowable
+                        skew) then error_out(KDC_ERR_PREAUTH_FAILED);
+                endif
+                if(decrypted_enc_timestamp and usec is replay)
+                        error_out(KDC_ERR_PREAUTH_FAILED);
+                endif
+                add decrypted_enc_timestamp and usec to replay cache;
+        endif
+
+        use_etype := first supported etype in req.etypes;
+
+        if (no support for req.etypes) then
+                error_out(KDC_ERR_ETYPE_NOSUPP);
+        endif
+
+        new_tkt.vno := ticket version; /* = 5 */
+        new_tkt.sname := req.sname;
+        new_tkt.srealm := req.srealm;
+        reset all flags in new_tkt.flags;
+
+
+
+
+Kohl & Neuman                                                  [Page 92]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        /* 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.ALLOW-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.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);
+
+
+
+Kohl & Neuman                                                  [Page 93]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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;
+
+
+
+Kohl & Neuman                                                  [Page 94]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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
+
+        /* 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
+
+
+
+Kohl & Neuman                                                  [Page 95]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                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
+        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;
+
+
+
+Kohl & Neuman                                                  [Page 96]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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
+
+
+
+
+Kohl & Neuman                                                  [Page 97]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        /* 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
+
+
+
+Kohl & Neuman                                                  [Page 98]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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(server)) then
+                        server := best_intermediate_tgs(server);
+                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;
+
+
+
+Kohl & Neuman                                                  [Page 99]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                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.POSTDATE is set) then
+                if (tgt.flags.POSTDATE is reset)
+                        error_out(KDC_ERR_BADOPTION);
+                endif
+                set new_tkt.flags.POSTDATE;
+        endif
+        if (req.kdc-options.POSTDATED is set) then
+                if (tgt.flags.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
+
+
+
+Kohl & Neuman                                                 [Page 100]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                        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);
+
+                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);
+
+
+
+Kohl & Neuman                                                 [Page 101]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                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)
+        endif
+
+
+
+Kohl & Neuman                                                 [Page 102]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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,
+
+
+
+Kohl & Neuman                                                 [Page 103]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                        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
+
+
+
+Kohl & Neuman                                                 [Page 104]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+A.9.  KRB_AP_REQ generation
+        obtain ticket and session_key from cache;
+
+        packet.pvno := protocol version; /* 5 */
+        packet.msg-type := message type; /* KRB_AP_REQ */
+
+        if (desired(MUTUAL_AUTHENTICATION)) then
+                set packet.ap-options.MUTUAL-REQUIRED;
+        else
+                reset packet.ap-options.MUTUAL-REQUIRED;
+        endif
+        if (using session key for ticket) then
+                set packet.ap-options.USE-SESSION-KEY;
+        else
+                reset packet.ap-options.USE-SESSION-KEY;
+        endif
+        packet.ticket := ticket; /* ticket */
+        generate authenticator;
+        encode authenticator into OCTET STRING;
+        encrypt OCTET STRING into packet.authenticator
+                             using session_key;
+
+A.10.  KRB_AP_REQ verification
+        receive packet;
+        if (packet.pvno != 5) then
+                either process using other protocol spec
+                or error_out(KRB_AP_ERR_BADVERSION);
+        endif
+        if (packet.msg-type != KRB_AP_REQ) then
+                error_out(KRB_AP_ERR_MSG_TYPE);
+        endif
+        if (packet.ticket.tkt_vno != 5) then
+                either process using other protocol spec
+                or error_out(KRB_AP_ERR_BADVERSION);
+        endif
+        if (packet.ap_options.USE-SESSION-KEY is set) then
+                retrieve session key from ticket-granting ticket for
+                 packet.ticket.{sname,srealm,enc-part.etype};
+        else
+           retrieve service key for
+           packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
+        endif
+        if (no_key_available) then
+                if (cannot_find_specified_skvno) then
+                        error_out(KRB_AP_ERR_BADKEYVER);
+                else
+                        error_out(KRB_AP_ERR_NOKEY);
+                endif
+
+
+
+Kohl & Neuman                                                 [Page 105]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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
+        /* 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;
+
+
+
+Kohl & Neuman                                                 [Page 106]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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 */
+
+
+
+Kohl & Neuman                                                 [Page 107]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        body.user-data := buffer; /* DATA */
+        if (using timestamp) then
+                get system_time;
+                body.timestamp, body.usec := system_time;
+        endif
+        if (using sequence numbers) then
+                body.seq-number := sequence number;
+        endif
+        body.s-address := sender host addresses;
+        if (only one recipient) then
+                body.r-address := recipient host address;
+        endif
+        checksum.cksumtype := checksum type;
+        compute checksum over body;
+        checksum.checksum := checksum value; /* checksum.checksum */
+        packet.cksum := checksum;
+        packet.safe-body := body;
+
+A.14.  KRB_SAFE verification
+        receive packet;
+        if (packet.pvno != 5) then
+                either process using other protocol spec
+                or error_out(KRB_AP_ERR_BADVERSION);
+        endif
+        if (packet.msg-type != KRB_SAFE) then
+                error_out(KRB_AP_ERR_MSG_TYPE);
+        endif
+        if (packet.checksum.cksumtype is not both collision-proof
+                                             and keyed) then
+                error_out(KRB_AP_ERR_INAPP_CKSUM);
+        endif
+        if (safe_priv_common_checks_ok(packet)) then
+                set computed_checksum := checksum(packet.body);
+                if (computed_checksum != packet.checksum) then
+                        error_out(KRB_AP_ERR_MODIFIED);
+                endif
+                return (packet, PACKET_IS_GENUINE);
+        else
+                return common_checks_error;
+        endif
+
+A.15.  KRB_SAFE and KRB_PRIV common checks
+        if (packet.s-address != O/S_sender(packet)) then
+            /* O/S report of sender not who claims to have sent it */
+            error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if ((packet.r-address is present) and
+            (packet.r-address != local_host_address)) then
+
+
+
+Kohl & Neuman                                                 [Page 108]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                /* was not sent to proper place */
+                error_out(KRB_AP_ERR_BADADDR);
+        endif
+        if (((packet.timestamp is present) and
+             (not in_clock_skew(packet.timestamp,packet.usec))) or
+            (packet.timestamp is not present and timestamp expected))
+                then error_out(KRB_AP_ERR_SKEW);
+        endif
+        if (repeated(packet.timestamp,packet.usec,packet.s-address))
+                then error_out(KRB_AP_ERR_REPEAT);
+        endif
+        if (((packet.seq-number is present) and
+             ((not in_sequence(packet.seq-number)))) or
+            (packet.seq-number is not present and sequence expected))
+                then error_out(KRB_AP_ERR_BADORDER);
+        endif
+        if (packet.timestamp not present and
+            packet.seq-number not present) then
+                error_out(KRB_AP_ERR_MODIFIED);
+        endif
+
+        save_identifier(packet.{timestamp,usec,s-address},
+                        sender_principal(packet));
+
+        return PACKET_IS_OK;
+
+A.16.  KRB_PRIV generation
+        collect user data in buffer;
+
+        /* assemble packet: */
+        packet.pvno := protocol version; /* 5 */
+        packet.msg-type := message type; /* KRB_PRIV */
+
+        packet.enc-part.etype := encryption type;
+
+        body.user-data := buffer;
+        if (using timestamp) then
+                get system_time;
+                body.timestamp, body.usec := system_time;
+        endif
+        if (using sequence numbers) then
+                body.seq-number := sequence number;
+        endif
+        body.s-address := sender host addresses;
+        if (only one recipient) then
+                body.r-address := recipient host address;
+        endif
+
+
+
+
+Kohl & Neuman                                                 [Page 109]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        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;
+                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;
+
+
+
+Kohl & Neuman                                                 [Page 110]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+                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);
+
+
+
+Kohl & Neuman                                                 [Page 111]
+
+RFC 1510                        Kerberos                  September 1993
+
+
+        endif
+        if (not in_clock_skew(packet.timestamp,packet.usec)) then
+                error_out(KRB_AP_ERR_SKEW);
+        endif
+        if (repeated(packet.timestamp,packet.usec,packet.s-address))
+                then error_out(KRB_AP_ERR_REPEAT);
+        endif
+        if (packet.nonce is required or present) and
+           (packet.nonce != expected-nonce) then
+                error_out(KRB_AP_ERR_MODIFIED);
+        endif
+
+        for (ticket[n] in tickets that were forwarded) do
+                save_for_later(ticket[n],key[n],principal[n],
+                               server[n],times[n],flags[n]);
+        return
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Kohl & Neuman                                                 [Page 112]
+
\ No newline at end of file
diff --git a/third_party/heimdal/doc/standardisation/rfc1750.txt b/third_party/heimdal/doc/standardisation/rfc1750.txt
new file mode 100644
index 00000000000..56d478c7eef
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc1750.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 1750                                           DEC
+Category: Informational                                       S. Crocker
+                                                               Cybercash
+                                                             J. Schiller
+                                                                     MIT
+                                                           December 1994
+
+
+                Randomness Recommendations for Security
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Security systems today are built on increasingly strong cryptographic
+   algorithms that foil pattern analysis attempts. However, the security
+   of these systems is dependent on generating secret quantities for
+   passwords, cryptographic keys, and similar quantities.  The use of
+   pseudo-random processes to generate secret quantities can result in
+   pseudo-security.  The sophisticated attacker of these security
+   systems may find it easier to reproduce the environment that produced
+   the secret quantities, searching the resulting small set of
+   possibilities, than to locate the quantities in the whole of the
+   number space.
+
+   Choosing random quantities to foil a resourceful and motivated
+   adversary is surprisingly difficult.  This paper points out many
+   pitfalls in using traditional pseudo-random number generation
+   techniques for choosing such quantities.  It recommends the use of
+   truly random hardware techniques and shows that the existing hardware
+   on many systems can be used for this purpose.  It provides
+   suggestions to ameliorate the problem when a hardware solution is not
+   available.  And it gives examples of how large such quantities need
+   to be for some particular applications.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 1]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+Acknowledgements
+
+   Comments on this document that have been incorporated were received
+   from (in alphabetic order) the following:
+
+        David M. Balenson (TIS)
+        Don Coppersmith (IBM)
+        Don T. Davis (consultant)
+        Carl Ellison (Stratus)
+        Marc Horowitz (MIT)
+        Christian Huitema (INRIA)
+        Charlie Kaufman (IRIS)
+        Steve Kent (BBN)
+        Hal Murray (DEC)
+        Neil Haller (Bellcore)
+        Richard Pitkin (DEC)
+        Tim Redmond (TIS)
+        Doug Tygar (CMU)
+
+Table of Contents
+
+   1. Introduction........................................... 3
+   2. Requirements........................................... 4
+   3. Traditional Pseudo-Random Sequences.................... 5
+   4. Unpredictability....................................... 7
+   4.1 Problems with Clocks and Serial Numbers............... 7
+   4.2 Timing and Content of External Events................  8
+   4.3 The Fallacy of Complex Manipulation..................  8
+   4.4 The Fallacy of Selection from a Large Database.......  9
+   5. Hardware for Randomness............................... 10
+   5.1 Volume Required...................................... 10
+   5.2 Sensitivity to Skew.................................. 10
+   5.2.1 Using Stream Parity to De-Skew..................... 11
+   5.2.2 Using Transition Mappings to De-Skew............... 12
+   5.2.3 Using FFT to De-Skew............................... 13
+   5.2.4 Using Compression to De-Skew....................... 13
+   5.3 Existing Hardware Can Be Used For Randomness......... 14
+   5.3.1 Using Existing Sound/Video Input................... 14
+   5.3.2 Using Existing Disk Drives......................... 14
+   6. Recommended Non-Hardware Strategy..................... 14
+   6.1 Mixing Functions..................................... 15
+   6.1.1 A Trivial Mixing Function.......................... 15
+   6.1.2 Stronger Mixing Functions.......................... 16
+   6.1.3 Diff-Hellman as a Mixing Function.................. 17
+   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
+   6.1.5 Other Factors in Choosing a Mixing Function........ 18
+   6.2 Non-Hardware Sources of Randomness................... 19
+   6.3 Cryptographically Strong Sequences................... 19
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 2]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   6.3.1 Traditional Strong Sequences....................... 20
+   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
+   7. Key Generation Standards.............................. 22
+   7.1 US DoD Recommendations for Password Generation....... 23
+   7.2 X9.17 Key Generation................................. 23
+   8. Examples of Randomness Required....................... 24
+   8.1  Password Generation................................. 24
+   8.2 A Very High Security Cryptographic Key............... 25
+   8.2.1 Effort per Key Trial............................... 25
+   8.2.2 Meet in the Middle Attacks......................... 26
+   8.2.3 Other Considerations............................... 26
+   9. Conclusion............................................ 27
+   10. Security Considerations.............................. 27
+   References............................................... 28
+   Authors' Addresses....................................... 30
+
+1. Introduction
+
+   Software cryptography is coming into wider use.  Systems like
+   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
+   network landscape [PEM].  These systems provide substantial
+   protection against snooping and spoofing.  However, there is a
+   potential flaw.  At the heart of all cryptographic systems is the
+   generation of secret, unguessable (i.e., random) numbers.
+
+   For the present, the lack of generally available facilities for
+   generating such unpredictable numbers is an open wound in the design
+   of cryptographic software.  For the software developer who wants to
+   build a key or password generation procedure that runs on a wide
+   range of hardware, the only safe strategy so far has been to force
+   the local installation to supply a suitable routine to generate
+   random numbers.  To say the least, this is an awkward, error-prone
+   and unpalatable solution.
+
+   It is important to keep in mind that the requirement is for data that
+   an adversary has a very low probability of guessing or determining.
+   This will fail if pseudo-random data is used which only meets
+   traditional statistical tests for randomness or which is based on
+   limited range sources, such as clocks.  Frequently such random
+   quantities are determinable by an adversary searching through an
+   embarrassingly small space of possibilities.
+
+   This informational document suggests techniques for producing random
+   quantities that will be resistant to such attack.  It recommends that
+   future systems include hardware random number generation or provide
+   access to existing hardware that can be used for this purpose.  It
+   suggests methods for use if such hardware is not available.  And it
+   gives some estimates of the number of random bits required for sample
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 3]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   applications.
+
+2. Requirements
+
+   Probably the most commonly encountered randomness requirement today
+   is the user password. This is usually a simple character string.
+   Obviously, if a password can be guessed, it does not provide
+   security.  (For re-usable passwords, it is desirable that users be
+   able to remember the password.  This may make it advisable to use
+   pronounceable character strings or phrases composed on ordinary
+   words.  But this only affects the format of the password information,
+   not the requirement that the password be very hard to guess.)
+
+   Many other requirements come from the cryptographic arena.
+   Cryptographic techniques can be used to provide a variety of services
+   including confidentiality and authentication.  Such services are
+   based on quantities, traditionally called "keys", that are unknown to
+   and unguessable by an adversary.
+
+   In some cases, such as the use of symmetric encryption with the one
+   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
+   parties who wish to communicate confidentially and/or with
+   authentication must all know the same secret key.  In other cases,
+   using what are called asymmetric or "public key" cryptographic
+   techniques, keys come in pairs.  One key of the pair is private and
+   must be kept secret by one party, the other is public and can be
+   published to the world.  It is computationally infeasible to
+   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
+
+   The frequency and volume of the requirement for random quantities
+   differs greatly for different cryptographic systems.  Using pure RSA
+   [CRYPTO*], random quantities are required when the key pair is
+   generated, but thereafter any number of messages can be signed
+   without any further need for randomness.  The public key Digital
+   Signature Algorithm that has been proposed by the US National
+   Institute of Standards and Technology (NIST) requires good random
+   numbers for each signature.  And encrypting with a one time pad, in
+   principle the strongest possible encryption technique, requires a
+   volume of randomness equal to all the messages to be processed.
+
+   In most of these cases, an adversary can try to determine the
+   "secret" key by trial and error.  (This is possible as long as the
+   key is enough smaller than the message that the correct key can be
+   uniquely identified.)  The probability of an adversary succeeding at
+   this must be made acceptably low, depending on the particular
+   application.  The size of the space the adversary must search is
+   related to the amount of key "information" present in the information
+   theoretic sense [SHANNON].  This depends on the number of different
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 4]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   secret values possible and the probability of each value as follows:
+
+                      -----
+                       \
+        Bits-of-info =  \  - p   * log  ( p  )
+                        /     i       2    i
+                       /
+                      -----
+
+   where i varies from 1 to the number of possible secret values and p
+   sub i is the probability of the value numbered i.  (Since p sub i is
+   less than one, the log will be negative so each term in the sum will
+   be non-negative.)
+
+   If there are 2^n different values of equal probability, then n bits
+   of information are present and an adversary would, on the average,
+   have to try half of the values, or 2^(n-1) , before guessing the
+   secret quantity.  If the probability of different values is unequal,
+   then there is less information present and fewer guesses will, on
+   average, be required by an adversary.  In particular, any values that
+   the adversary can know are impossible, or are of low probability, can
+   be initially ignored by an adversary, who will search through the
+   more probable values first.
+
+   For example, consider a cryptographic system that uses 56 bit keys.
+   If these 56 bit keys are derived by using a fixed pseudo-random
+   number generator that is seeded with an 8 bit seed, then an adversary
+   needs to search through only 256 keys (by running the pseudo-random
+   number generator with every possible seed), not the 2^56 keys that
+   may at first appear to be the case. Only 8 bits of "information" are
+   in these 56 bit keys.
+
+3. Traditional Pseudo-Random Sequences
+
+   Most traditional sources of random numbers use deterministic sources
+   of "pseudo-random" numbers.  These typically start with a "seed"
+   quantity and use numeric or logical operations to produce a sequence
+   of values.
+
+   [KNUTH] has a classic exposition on pseudo-random numbers.
+   Applications he mentions are simulation of natural phenomena,
+   sampling, numerical analysis, testing computer programs, decision
+   making, and games.  None of these have the same characteristics as
+   the sort of security uses we are talking about.  Only in the last two
+   could there be an adversary trying to find the random quantity.
+   However, in these cases, the adversary normally has only a single
+   chance to use a guessed value.  In guessing passwords or attempting
+   to break an encryption scheme, the adversary normally has many,
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 5]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   perhaps unlimited, chances at guessing the correct value and should
+   be assumed to be aided by a computer.
+
+   For testing the "randomness" of numbers, Knuth suggests a variety of
+   measures including statistical and spectral.  These tests check
+   things like autocorrelation between different parts of a "random"
+   sequence or distribution of its values.  They could be met by a
+   constant stored random sequence, such as the "random" sequence
+   printed in the CRC Standard Mathematical Tables [CRC].
+
+   A typical pseudo-random number generation technique, known as a
+   linear congruence pseudo-random number generator, is modular
+   arithmetic where the N+1th value is calculated from the Nth value by
+
+        V    = ( V  * a + b )(Mod c)
+         N+1      N
+
+   The above technique has a strong relationship to linear shift
+   register pseudo-random number generators, which are well understood
+   cryptographically [SHIFT*].  In such generators bits are introduced
+   at one end of a shift register as the Exclusive Or (binary sum
+   without carry) of bits from selected fixed taps into the register.
+
+   For example:
+
+      +----+     +----+     +----+                      +----+
+      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
+      |  0 |     |  1 |     |  2 |                      |  n |   |
+      +----+     +----+     +----+                      +----+   |
+        |                     |            |                     |
+        |                     |            V                  +-----+
+        |                     V            +----------------> |     |
+        V                     +-----------------------------> | XOR |
+        +---------------------------------------------------> |     |
+                                                              +-----+
+
+
+       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
+        N+1         N         0       2
+
+   The goodness of traditional pseudo-random number generator algorithms
+   is measured by statistical tests on such sequences.  Carefully chosen
+   values of the initial V and a, b, and c or the placement of shift
+   register tap in the above simple processes can produce excellent
+   statistics.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 6]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   These sequences may be adequate in simulations (Monte Carlo
+   experiments) as long as the sequence is orthogonal to the structure
+   of the space being explored.  Even there, subtle patterns may cause
+   problems.  However, such sequences are clearly bad for use in
+   security applications.  They are fully predictable if the initial
+   state is known.  Depending on the form of the pseudo-random number
+   generator, the sequence may be determinable from observation of a
+   short portion of the sequence [CRYPTO*, STERN].  For example, with
+   the generators above, one can determine V(n+1) given knowledge of
+   V(n).  In fact, it has been shown that with these techniques, even if
+   only one bit of the pseudo-random values is released, the seed can be
+   determined from short sequences.
+
+   Not only have linear congruent generators been broken, but techniques
+   are now known for breaking all polynomial congruent generators
+   [KRAWCZYK].
+
+4. Unpredictability
+
+   Randomness in the traditional sense described in section 3 is NOT the
+   same as the unpredictability required for security use.
+
+   For example, use of a widely available constant sequence, such as
+   that from the CRC tables, is very weak against an adversary. Once
+   they learn of or guess it, they can easily break all security, future
+   and past, based on the sequence [CRC].  Yet the statistical
+   properties of these tables are good.
+
+   The following sections describe the limitations of some randomness
+   generation techniques and sources.
+
+4.1 Problems with Clocks and Serial Numbers
+
+   Computer clocks, or similar operating system or hardware values,
+   provide significantly fewer real bits of unpredictability than might
+   appear from their specifications.
+
+   Tests have been done on clocks on numerous systems and it was found
+   that their behavior can vary widely and in unexpected ways.  One
+   version of an operating system running on one set of hardware may
+   actually provide, say, microsecond resolution in a clock while a
+   different configuration of the "same" system may always provide the
+   same lower bits and only count in the upper bits at much lower
+   resolution.  This means that successive reads on the clock may
+   produce identical values even if enough time has passed that the
+   value "should" change based on the nominal clock resolution. There
+   are also cases where frequently reading a clock can produce
+   artificial sequential values because of extra code that checks for
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 7]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   the clock being unchanged between two reads and increases it by one!
+   Designing portable application code to generate unpredictable numbers
+   based on such system clocks is particularly challenging because the
+   system designer does not always know the properties of the system
+   clocks that the code will execute on.
+
+   Use of a hardware serial number such as an Ethernet address may also
+   provide fewer bits of uniqueness than one would guess.  Such
+   quantities are usually heavily structured and subfields may have only
+   a limited range of possible values or values easily guessable based
+   on approximate date of manufacture or other data.  For example, it is
+   likely that most of the Ethernet cards installed on Digital Equipment
+   Corporation (DEC) hardware within DEC were manufactured by DEC
+   itself, which significantly limits the range of built in addresses.
+
+   Problems such as those described above related to clocks and serial
+   numbers make code to produce unpredictable quantities difficult if
+   the code is to be ported across a variety of computer platforms and
+   systems.
+
+4.2 Timing and Content of External Events
+
+   It is possible to measure the timing and content of mouse movement,
+   key strokes, and similar user events.  This is a reasonable source of
+   unguessable data with some qualifications.  On some machines, inputs
+   such as key strokes are buffered.  Even though the user's inter-
+   keystroke timing may have sufficient variation and unpredictability,
+   there might not be an easy way to access that variation.  Another
+   problem is that no standard method exists to sample timing details.
+   This makes it hard to build standard software intended for
+   distribution to a large range of machines based on this technique.
+
+   The amount of mouse movement or the keys actually hit are usually
+   easier to access than timings but may yield less unpredictability as
+   the user may provide highly repetitive input.
+
+   Other external events, such as network packet arrival times, can also
+   be used with care.  In particular, the possibility of manipulation of
+   such times by an adversary must be considered.
+
+4.3 The Fallacy of Complex Manipulation
+
+   One strategy which may give a misleading appearance of
+   unpredictability is to take a very complex algorithm (or an excellent
+   traditional pseudo-random number generator with good statistical
+   properties) and calculate a cryptographic key by starting with the
+   current value of a computer system clock as the seed.  An adversary
+   who knew roughly when the generator was started would have a
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 8]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   relatively small number of seed values to test as they would know
+   likely values of the system clock.  Large numbers of pseudo-random
+   bits could be generated but the search space an adversary would need
+   to check could be quite small.
+
+   Thus very strong and/or complex manipulation of data will not help if
+   the adversary can learn what the manipulation is and there is not
+   enough unpredictability in the starting seed value.  Even if they can
+   not learn what the manipulation is, they may be able to use the
+   limited number of results stemming from a limited number of seed
+   values to defeat security.
+
+   Another serious strategy error is to assume that a very complex
+   pseudo-random number generation algorithm will produce strong random
+   numbers when there has been no theory behind or analysis of the
+   algorithm.  There is a excellent example of this fallacy right near
+   the beginning of chapter 3 in [KNUTH] where the author describes a
+   complex algorithm.  It was intended that the machine language program
+   corresponding to the algorithm would be so complicated that a person
+   trying to read the code without comments wouldn't know what the
+   program was doing.  Unfortunately, actual use of this algorithm
+   showed that it almost immediately converged to a single repeated
+   value in one case and a small cycle of values in another case.
+
+   Not only does complex manipulation not help you if you have a limited
+   range of seeds but blindly chosen complex manipulation can destroy
+   the randomness in a good seed!
+
+4.4 The Fallacy of Selection from a Large Database
+
+   Another strategy that can give a misleading appearance of
+   unpredictability is selection of a quantity randomly from a database
+   and assume that its strength is related to the total number of bits
+   in the database.  For example, typical USENET servers as of this date
+   process over 35 megabytes of information per day.  Assume a random
+   quantity was selected by fetching 32 bytes of data from a random
+   starting point in this data.  This does not yield 32*8 = 256 bits
+   worth of unguessability.  Even after allowing that much of the data
+   is human language and probably has more like 2 or 3 bits of
+   information per byte, it doesn't yield 32*2.5 = 80 bits of
+   unguessability.  For an adversary with access to the same 35
+   megabytes the unguessability rests only on the starting point of the
+   selection.  That is, at best, about 25 bits of unguessability in this
+   case.
+
+   The same argument applies to selecting sequences from the data on a
+   CD ROM or Audio CD recording or any other large public database.  If
+   the adversary has access to the same database, this "selection from a
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 9]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   large volume of data" step buys very little.  However, if a selection
+   can be made from data to which the adversary has no access, such as
+   system buffers on an active multi-user system, it may be of some
+   help.
+
+5. Hardware for Randomness
+
+   Is there any hope for strong portable randomness in the future?
+   There might be.  All that's needed is a physical source of
+   unpredictable numbers.
+
+   A thermal noise or radioactive decay source and a fast, free-running
+   oscillator would do the trick directly [GIFFORD].  This is a trivial
+   amount of hardware, and could easily be included as a standard part
+   of a computer system's architecture.  Furthermore, any system with a
+   spinning disk or the like has an adequate source of randomness
+   [DAVIS].  All that's needed is the common perception among computer
+   vendors that this small additional hardware and the software to
+   access it is necessary and useful.
+
+5.1 Volume Required
+
+   How much unpredictability is needed?  Is it possible to quantify the
+   requirement in, say, number of random bits per second?
+
+   The answer is not very much is needed.  For DES, the key is 56 bits
+   and, as we show in an example in Section 8, even the highest security
+   system is unlikely to require a keying material of over 200 bits.  If
+   a series of keys are needed, it can be generated from a strong random
+   seed using a cryptographically strong sequence as explained in
+   Section 6.3.  A few hundred random bits generated once a day would be
+   enough using such techniques.  Even if the random bits are generated
+   as slowly as one per second and it is not possible to overlap the
+   generation process, it should be tolerable in high security
+   applications to wait 200 seconds occasionally.
+
+   These numbers are trivial to achieve.  It could be done by a person
+   repeatedly tossing a coin.  Almost any hardware process is likely to
+   be much faster.
+
+5.2 Sensitivity to Skew
+
+   Is there any specific requirement on the shape of the distribution of
+   the random numbers?  The good news is the distribution need not be
+   uniform.  All that is needed is a conservative estimate of how non-
+   uniform it is to bound performance.  Two simple techniques to de-skew
+   the bit stream are given below and stronger techniques are mentioned
+   in Section 6.1.2 below.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 10]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+5.2.1 Using Stream Parity to De-Skew
+
+   Consider taking a sufficiently long string of bits and map the string
+   to "zero" or "one".  The mapping will not yield a perfectly uniform
+   distribution, but it can be as close as desired.  One mapping that
+   serves the purpose is to take the parity of the string.  This has the
+   advantages that it is robust across all degrees of skew up to the
+   estimated maximum skew and is absolutely trivial to implement in
+   hardware.
+
+   The following analysis gives the number of bits that must be sampled:
+
+   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
+   between 0 and 0.5 and is a measure of the "eccentricity" of the
+   distribution.  Consider the distribution of the parity function of N
+   bit samples.  The probabilities that the parity will be one or zero
+   will be the sum of the odd or even terms in the binomial expansion of
+   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
+   e, the probability of a zero.
+
+   These sums can be computed easily as
+
+                         N            N
+        1/2 * ( ( p + q )  + ( p - q )  )
+   and
+                         N            N
+        1/2 * ( ( p + q )  - ( p - q )  ).
+
+   (Which one corresponds to the probability the parity will be 1
+   depends on whether N is odd or even.)
+
+   Since p + q = 1 and p - q = 2e, these expressions reduce to
+
+                       N
+        1/2 * [1 + (2e) ]
+   and
+                       N
+        1/2 * [1 - (2e) ].
+
+   Neither of these will ever be exactly 0.5 unless e is zero, but we
+   can bring them arbitrarily close to 0.5.  If we want the
+   probabilities to be within some delta d of 0.5, i.e. then
+
+                            N
+        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 11]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
+   1, so its log is negative.  Division by a negative number reverses
+   the sense of an inequality.)
+
+   The following table gives the length of the string which must be
+   sampled for various degrees of skew in order to come within 0.001 of
+   a 50/50 distribution.
+
+                       +---------+--------+-------+
+                       | Prob(1) |    e   |    N  |
+                       +---------+--------+-------+
+                       |   0.5   |  0.00  |    1  |
+                       |   0.6   |  0.10  |    4  |
+                       |   0.7   |  0.20  |    7  |
+                       |   0.8   |  0.30  |   13  |
+                       |   0.9   |  0.40  |   28  |
+                       |   0.95  |  0.45  |   59  |
+                       |   0.99  |  0.49  |  308  |
+                       +---------+--------+-------+
+
+   The last entry shows that even if the distribution is skewed 99% in
+   favor of ones, the parity of a string of 308 samples will be within
+   0.001 of a 50/50 distribution.
+
+5.2.2 Using Transition Mappings to De-Skew
+
+   Another technique, originally due to von Neumann [VON NEUMANN], is to
+   examine a bit stream as a sequence of non-overlapping pairs. You
+   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
+   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
+   probability of a 0 is 0.5-e where e is the eccentricity of the source
+   and described in the previous section.  Then the probability of each
+   pair is as follows:
+
+            +------+-----------------------------------------+
+            | pair |            probability                  |
+            +------+-----------------------------------------+
+            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
+            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
+            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
+            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
+            +------+-----------------------------------------+
+
+   This technique will completely eliminate any bias but at the expense
+   of taking an indeterminate number of input bits for any particular
+   desired number of output bits.  The probability of any particular
+   pair being discarded is 0.5 + 2e^2 so the expected number of input
+   bits to produce X output bits is X/(0.25 - e^2).
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 12]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   This technique assumes that the bits are from a stream where each bit
+   has the same probability of being a 0 or 1 as any other bit in the
+   stream and that bits are not correlated, i.e., that the bits are
+   identical independent distributions.  If alternate bits were from two
+   correlated sources, for example, the above analysis breaks down.
+
+   The above technique also provides another illustration of how a
+   simple statistical analysis can mislead if one is not always on the
+   lookout for patterns that could be exploited by an adversary.  If the
+   algorithm were mis-read slightly so that overlapping successive bits
+   pairs were used instead of non-overlapping pairs, the statistical
+   analysis given is the same; however, instead of provided an unbiased
+   uncorrelated series of random 1's and 0's, it instead produces a
+   totally predictable sequence of exactly alternating 1's and 0's.
+
+5.2.3 Using FFT to De-Skew
+
+   When real world data consists of strongly biased or correlated bits,
+   it may still contain useful amounts of randomness.  This randomness
+   can be extracted through use of the discrete Fourier transform or its
+   optimized variant, the FFT.
+
+   Using the Fourier transform of the data, strong correlations can be
+   discarded.  If adequate data is processed and remaining correlations
+   decay, spectral lines approaching statistical independence and
+   normally distributed randomness can be produced [BRILLINGER].
+
+5.2.4 Using Compression to De-Skew
+
+   Reversible compression techniques also provide a crude method of de-
+   skewing a skewed bit stream.  This follows directly from the
+   definition of reversible compression and the formula in Section 2
+   above for the amount of information in a sequence.  Since the
+   compression is reversible, the same amount of information must be
+   present in the shorter output than was present in the longer input.
+   By the Shannon information equation, this is only possible if, on
+   average, the probabilities of the different shorter sequences are
+   more uniformly distributed than were the probabilities of the longer
+   sequences.  Thus the shorter sequences are de-skewed relative to the
+   input.
+
+   However, many compression techniques add a somewhat predicatable
+   preface to their output stream and may insert such a sequence again
+   periodically in their output or otherwise introduce subtle patterns
+   of their own.  They should be considered only a rough technique
+   compared with those described above or in Section 6.1.2.  At a
+   minimum, the beginning of the compressed sequence should be skipped
+   and only later bits used for applications requiring random bits.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 13]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+5.3 Existing Hardware Can Be Used For Randomness
+
+   As described below, many computers come with hardware that can, with
+   care, be used to generate truly random quantities.
+
+5.3.1 Using Existing Sound/Video Input
+
+   Increasingly computers are being built with inputs that digitize some
+   real world analog source, such as sound from a microphone or video
+   input from a camera.  Under appropriate circumstances, such input can
+   provide reasonably high quality random bits.  The "input" from a
+   sound digitizer with no source plugged in or a camera with the lens
+   cap on, if the system has enough gain to detect anything, is
+   essentially thermal noise.
+
+   For example, on a SPARCstation, one can read from the /dev/audio
+   device with nothing plugged into the microphone jack.  Such data is
+   essentially random noise although it should not be trusted without
+   some checking in case of hardware failure.  It will, in any case,
+   need to be de-skewed as described elsewhere.
+
+   Combining this with compression to de-skew one can, in UNIXese,
+   generate a huge amount of medium quality random data by doing
+
+        cat /dev/audio | compress - >random-bits-file
+
+5.3.2 Using Existing Disk Drives
+
+   Disk drives have small random fluctuations in their rotational speed
+   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
+   time instrumentation to a system, a series of measurements can be
+   obtained that include this randomness. Such data is usually highly
+   correlated so that significant processing is needed, including FFT
+   (see section 5.2.3).  Nevertheless experimentation has shown that,
+   with such processing, disk drives easily produce 100 bits a minute or
+   more of excellent random data.
+
+   Partly offsetting this need for processing is the fact that disk
+   drive failure will normally be rapidly noticed.  Thus, problems with
+   this method of random number generation due to hardware failure are
+   very unlikely.
+
+6. Recommended Non-Hardware Strategy
+
+   What is the best overall strategy for meeting the requirement for
+   unguessable random numbers in the absence of a reliable hardware
+   source?  It is to obtain random input from a large number of
+   uncorrelated sources and to mix them with a strong mixing function.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 14]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Such a function will preserve the randomness present in any of the
+   sources even if other quantities being combined are fixed or easily
+   guessable.  This may be advisable even with a good hardware source as
+   hardware can also fail, though this should be weighed against any
+   increase in the chance of overall failure due to added software
+   complexity.
+
+6.1 Mixing Functions
+
+   A strong mixing function is one which combines two or more inputs and
+   produces an output where each output bit is a different complex non-
+   linear function of all the input bits.  On average, changing any
+   input bit will change about half the output bits.  But because the
+   relationship is complex and non-linear, no particular output bit is
+   guaranteed to change when any particular input bit is changed.
+
+   Consider the problem of converting a stream of bits that is skewed
+   towards 0 or 1 to a shorter stream which is more random, as discussed
+   in Section 5.2 above.  This is simply another case where a strong
+   mixing function is desired, mixing the input bits to produce a
+   smaller number of output bits.  The technique given in Section 5.2.1
+   of using the parity of a number of bits is simply the result of
+   successively Exclusive Or'ing them which is examined as a trivial
+   mixing function immediately below.  Use of stronger mixing functions
+   to extract more of the randomness in a stream of skewed bits is
+   examined in Section 6.1.2.
+
+6.1.1 A Trivial Mixing Function
+
+   A trivial example for single bit inputs is the Exclusive Or function,
+   which is equivalent to addition without carry, as show in the table
+   below.  This is a degenerate case in which the one output bit always
+   changes for a change in either input bit.  But, despite its
+   simplicity, it will still provide a useful illustration.
+
+                   +-----------+-----------+----------+
+                   |  input 1  |  input 2  |  output  |
+                   +-----------+-----------+----------+
+                   |     0     |     0     |     0    |
+                   |     0     |     1     |     1    |
+                   |     1     |     0     |     1    |
+                   |     1     |     1     |     0    |
+                   +-----------+-----------+----------+
+
+   If inputs 1 and 2 are uncorrelated and combined in this fashion then
+   the output will be an even better (less skewed) random bit than the
+   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
+   above, then the output eccentricity relates to the input eccentricity
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 15]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   as follows:
+
+        e       = 2 * e        * e
+         output        input 1    input 2
+
+   Since e is never greater than 1/2, the eccentricity is always
+   improved except in the case where at least one input is a totally
+   skewed constant.  This is illustrated in the following table where
+   the top and left side values are the two input eccentricities and the
+   entries are the output eccentricity:
+
+     +--------+--------+--------+--------+--------+--------+--------+
+     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
+     +--------+--------+--------+--------+--------+--------+--------+
+     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
+     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
+     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
+     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
+     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
+     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
+     +--------+--------+--------+--------+--------+--------+--------+
+
+   However, keep in mind that the above calculations assume that the
+   inputs are not correlated.  If the inputs were, say, the parity of
+   the number of minutes from midnight on two clocks accurate to a few
+   seconds, then each might appear random if sampled at random intervals
+   much longer than a minute.  Yet if they were both sampled and
+   combined with xor, the result would be zero most of the time.
+
+6.1.2 Stronger Mixing Functions
+
+   The US Government Data Encryption Standard [DES] is an example of a
+   strong mixing function for multiple bit quantities.  It takes up to
+   120 bits of input (64 bits of "data" and 56 bits of "key") and
+   produces 64 bits of output each of which is dependent on a complex
+   non-linear function of all input bits.  Other strong encryption
+   functions with this characteristic can also be used by considering
+   them to mix all of their key and data input bits.
+
+   Another good family of mixing functions are the "message digest" or
+   hashing functions such as The US Government Secure Hash Standard
+   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
+   all take an arbitrary amount of input and produce an output mixing
+   all the input bits. The MD* series produce 128 bits of output and SHS
+   produces 160 bits.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 16]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Although the message digest functions are designed for variable
+   amounts of input, DES and other encryption functions can also be used
+   to combine any number of inputs.  If 64 bits of output is adequate,
+   the inputs can be packed into a 64 bit data quantity and successive
+   56 bit keys, padding with zeros if needed, which are then used to
+   successively encrypt using DES in Electronic Codebook Mode [DES
+   MODES].  If more than 64 bits of output are needed, use more complex
+   mixing.  For example, if inputs are packed into three quantities, A,
+   B, and C, use DES to encrypt A with B as a key and then with C as a
+   key to produce the 1st part of the output, then encrypt B with C and
+   then A for more output and, if necessary, encrypt C with A and then B
+   for yet more output.  Still more output can be produced by reversing
+   the order of the keys given above to stretch things. The same can be
+   done with the hash functions by hashing various subsets of the input
+   data to produce multiple outputs.  But keep in mind that it is
+   impossible to get more bits of "randomness" out than are put in.
+
+   An example of using a strong mixing function would be to reconsider
+   the case of a string of 308 bits each of which is biased 99% towards
+   zero.  The parity technique given in Section 5.2.1 above reduced this
+   to one bit with only a 1/1000 deviance from being equally likely a
+   zero or one.  But, applying the equation for information given in
+   Section 2, this 308 bit sequence has 5 bits of information in it.
+   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
+   result would yield 5 unbiased random bits as opposed to the single
+   bit given by calculating the parity of the string.
+
+6.1.3 Diffie-Hellman as a Mixing Function
+
+   Diffie-Hellman exponential key exchange is a technique that yields a
+   shared secret between two parties that can be made computationally
+   infeasible for a third party to determine even if they can observe
+   all the messages between the two communicating parties.  This shared
+   secret is a mixture of initial quantities generated by each of them
+   [D-H].  If these initial quantities are random, then the shared
+   secret contains the combined randomness of them both, assuming they
+   are uncorrelated.
+
+6.1.4 Using a Mixing Function to Stretch Random Bits
+
+   While it is not necessary for a mixing function to produce the same
+   or fewer bits than its inputs, mixing bits cannot "stretch" the
+   amount of random unpredictability present in the inputs.  Thus four
+   inputs of 32 bits each where there is 12 bits worth of
+   unpredicatability (such as 4,096 equally probable values) in each
+   input cannot produce more than 48 bits worth of unpredictable output.
+   The output can be expanded to hundreds or thousands of bits by, for
+   example, mixing with successive integers, but the clever adversary's
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 17]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   search space is still 2^48 possibilities.  Furthermore, mixing to
+   fewer bits than are input will tend to strengthen the randomness of
+   the output the way using Exclusive Or to produce one bit from two did
+   above.
+
+   The last table in Section 6.1.1 shows that mixing a random bit with a
+   constant bit with Exclusive Or will produce a random bit.  While this
+   is true, it does not provide a way to "stretch" one random bit into
+   more than one.  If, for example, a random bit is mixed with a 0 and
+   then with a 1, this produces a two bit sequence but it will always be
+   either 01 or 10.  Since there are only two possible values, there is
+   still only the one bit of original randomness.
+
+6.1.5 Other Factors in Choosing a Mixing Function
+
+   For local use, DES has the advantages that it has been widely tested
+   for flaws, is widely documented, and is widely implemented with
+   hardware and software implementations available all over the world
+   including source code available by anonymous FTP.  The SHS and MD*
+   family are younger algorithms which have been less tested but there
+   is no particular reason to believe they are flawed.  Both MD5 and SHS
+   were derived from the earlier MD4 algorithm.  They all have source
+   code available by anonymous FTP [SHS, MD2, MD4, MD5].
+
+   DES and SHS have been vouched for the the US National Security Agency
+   (NSA) on the basis of criteria that primarily remain secret.  While
+   this is the cause of much speculation and doubt, investigation of DES
+   over the years has indicated that NSA involvement in modifications to
+   its design, which originated with IBM, was primarily to strengthen
+   it.  No concealed or special weakness has been found in DES.  It is
+   almost certain that the NSA modification to MD4 to produce the SHS
+   similarly strengthened the algorithm, possibly against threats not
+   yet known in the public cryptographic community.
+
+   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
+   been freely licensed only for non-profit use in connection with
+   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
+   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
+   but too slow, MD4 is fast but too weak, and MD5 is just right.
+
+   Another advantage of the MD* or similar hashing algorithms over
+   encryption algorithms is that they are not subject to the same
+   regulations imposed by the US Government prohibiting the unlicensed
+   export or import of encryption/decryption software and hardware.  The
+   same should be true of DES rigged to produce an irreversible hash
+   code but most DES packages are oriented to reversible encryption.
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 18]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+6.2 Non-Hardware Sources of Randomness
+
+   The best source of input for mixing would be a hardware randomness
+   such as disk drive timing affected by air turbulence, audio input
+   with thermal noise, or radioactive decay.  However, if that is not
+   available there are other possibilities.  These include system
+   clocks, system or input/output buffers, user/system/hardware/network
+   serial numbers and/or addresses and timing, and user input.
+   Unfortunately, any of these sources can produce limited or
+   predicatable values under some circumstances.
+
+   Some of the sources listed above would be quite strong on multi-user
+   systems where, in essence, each user of the system is a source of
+   randomness.  However, on a small single user system, such as a
+   typical IBM PC or Apple Macintosh, it might be possible for an
+   adversary to assemble a similar configuration.  This could give the
+   adversary inputs to the mixing process that were sufficiently
+   correlated to those used originally as to make exhaustive search
+   practical.
+
+   The use of multiple random inputs with a strong mixing function is
+   recommended and can overcome weakness in any particular input.  For
+   example, the timing and content of requested "random" user keystrokes
+   can yield hundreds of random bits but conservative assumptions need
+   to be made.  For example, assuming a few bits of randomness if the
+   inter-keystroke interval is unique in the sequence up to that point
+   and a similar assumption if the key hit is unique but assuming that
+   no bits of randomness are present in the initial key value or if the
+   timing or key value duplicate previous values.  The results of mixing
+   these timings and characters typed could be further combined with
+   clock values and other inputs.
+
+   This strategy may make practical portable code to produce good random
+   numbers for security even if some of the inputs are very weak on some
+   of the target systems.  However, it may still fail against a high
+   grade attack on small single user systems, especially if the
+   adversary has ever been able to observe the generation process in the
+   past.  A hardware based random source is still preferable.
+
+6.3 Cryptographically Strong Sequences
+
+   In cases where a series of random quantities must be generated, an
+   adversary may learn some values in the sequence.  In general, they
+   should not be able to predict other values from the ones that they
+   know.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 19]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   The correct technique is to start with a strong random seed, take
+   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
+   do not reveal the complete state of the generator in the sequence
+   elements.  If each value in the sequence can be calculated in a fixed
+   way from the previous value, then when any value is compromised, all
+   future values can be determined.  This would be the case, for
+   example, if each value were a constant function of the previously
+   used values, even if the function were a very strong, non-invertible
+   message digest function.
+
+   It should be noted that if your technique for generating a sequence
+   of key values is fast enough, it can trivially be used as the basis
+   for a confidentiality system.  If two parties use the same sequence
+   generating technique and start with the same seed material, they will
+   generate identical sequences.  These could, for example, be xor'ed at
+   one end with data being send, encrypting it, and xor'ed with this
+   data as received, decrypting it due to the reversible properties of
+   the xor operation.
+
+6.3.1 Traditional Strong Sequences
+
+   A traditional way to achieve a strong sequence has been to have the
+   values be produced by hashing the quantities produced by
+   concatenating the seed with successive integers or the like and then
+   mask the values obtained so as to limit the amount of generator state
+   available to the adversary.
+
+   It may also be possible to use an "encryption" algorithm with a
+   random key and seed value to encrypt and feedback some or all of the
+   output encrypted value into the value to be encrypted for the next
+   iteration.  Appropriate feedback techniques will usually be
+   recommended with the encryption algorithm.  An example is shown below
+   where shifting and masking are used to combine the cypher output
+   feedback.  This type of feedback is recommended by the US Government
+   in connection with DES [DES MODES].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 20]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+      +---------------+
+      |       V       |
+      |  |     n      |
+      +--+------------+
+            |      |           +---------+
+            |      +---------> |         |      +-----+
+         +--+                  | Encrypt | <--- | Key |
+         |           +-------- |         |      +-----+
+         |           |         +---------+
+         V           V
+      +------------+--+
+      |      V     |  |
+      |       n+1     |
+      +---------------+
+
+   Note that if a shift of one is used, this is the same as the shift
+   register technique described in Section 3 above but with the all
+   important difference that the feedback is determined by a complex
+   non-linear function of all bits rather than a simple linear or
+   polynomial combination of output from a few bit position taps.
+
+   It has been shown by Donald W. Davies that this sort of shifted
+   partial output feedback significantly weakens an algorithm compared
+   will feeding all of the output bits back as input.  In particular,
+   for DES, repeated encrypting a full 64 bit quantity will give an
+   expected repeat in about 2^63 iterations.  Feeding back anything less
+   than 64 (and more than 0) bits will give an expected repeat in
+   between 2**31 and 2**32 iterations!
+
+   To predict values of a sequence from others when the sequence was
+   generated by these techniques is equivalent to breaking the
+   cryptosystem or inverting the "non-invertible" hashing involved with
+   only partial information available.  The less information revealed
+   each iteration, the harder it will be for an adversary to predict the
+   sequence.  Thus it is best to use only one bit from each value.  It
+   has been shown that in some cases this makes it impossible to break a
+   system even when the cryptographic system is invertible and can be
+   broken if all of each generated value was revealed.
+
+6.3.2 The Blum Blum Shub Sequence Generator
+
+   Currently the generator which has the strongest public proof of
+   strength is called the Blum Blum Shub generator after its inventors
+   [BBS].  It is also very simple and is based on quadratic residues.
+   It's only disadvantage is that is is computationally intensive
+   compared with the traditional techniques give in 6.3.1 above.  This
+   is not a serious draw back if it is used for moderately infrequent
+   purposes, such as generating session keys.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 21]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Simply choose two large prime numbers, say p and q, which both have
+   the property that you get a remainder of 3 if you divide them by 4.
+   Let n = p * q.  Then you choose a random number x relatively prime to
+   n.  The initial seed for the generator and the method for calculating
+   subsequent values are then
+
+                   2
+        s    =  ( x  )(Mod n)
+         0
+
+                   2
+        s    = ( s   )(Mod n)
+         i+1      i
+
+   You must be careful to use only a few bits from the bottom of each s.
+   It is always safe to use only the lowest order bit.  If you use no
+   more than the
+
+                  log  ( log  ( s  ) )
+                     2      2    i
+
+   low order bits, then predicting any additional bits from a sequence
+   generated in this manner is provable as hard as factoring n.  As long
+   as the initial x is secret, you can even make n public if you want.
+
+   An intersting characteristic of this generator is that you can
+   directly calculate any of the s values.  In particular
+
+                     i
+               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
+      s  = ( s                                          )(Mod n)
+       i      0
+
+   This means that in applications where many keys are generated in this
+   fashion, it is not necessary to save them all.  Each key can be
+   effectively indexed and recovered from that small index and the
+   initial s and n.
+
+7. Key Generation Standards
+
+   Several public standards are now in place for the generation of keys.
+   Two of these are described below.  Both use DES but any equally
+   strong or stronger mixing function could be substituted.
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 22]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+7.1 US DoD Recommendations for Password Generation
+
+   The United States Department of Defense has specific recommendations
+   for password generation [DoD].  They suggest using the US Data
+   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
+   follows:
+
+        use an initialization vector determined from
+             the system clock,
+             system ID,
+             user ID, and
+             date and time;
+        use a key determined from
+             system interrupt registers,
+             system status registers, and
+             system counters; and,
+        as plain text, use an external randomly generated 64 bit
+        quantity such as 8 characters typed in by a system
+        administrator.
+
+   The password can then be calculated from the 64 bit "cipher text"
+   generated in 64-bit Output Feedback Mode.  As many bits as are needed
+   can be taken from these 64 bits and expanded into a pronounceable
+   word, phrase, or other format if a human being needs to remember the
+   password.
+
+7.2 X9.17 Key Generation
+
+   The American National Standards Institute has specified a method for
+   generating a sequence of keys as follows:
+
+        s  is the initial 64 bit seed
+         0
+
+        g  is the sequence of generated 64 bit key quantities
+         n
+
+        k is a random key reserved for generating this key sequence
+
+        t is the time at which a key is generated to as fine a resolution
+            as is available (up to 64 bits).
+
+        DES ( K, Q ) is the DES encryption of quantity Q with key K
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 23]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+        g    = DES ( k, DES ( k, t ) .xor. s  )
+         n                                  n
+
+        s    = DES ( k, DES ( k, t ) .xor. g  )
+         n+1                                n
+
+   If g sub n is to be used as a DES key, then every eighth bit should
+   be adjusted for parity for that use but the entire 64 bit unmodified
+   g should be used in calculating the next s.
+
+8. Examples of Randomness Required
+
+   Below are two examples showing rough calculations of needed
+   randomness for security.  The first is for moderate security
+   passwords while the second assumes a need for a very high security
+   cryptographic key.
+
+8.1  Password Generation
+
+   Assume that user passwords change once a year and it is desired that
+   the probability that an adversary could guess the password for a
+   particular account be less than one in a thousand.  Further assume
+   that sending a password to the system is the only way to try a
+   password.  Then the crucial question is how often an adversary can
+   try possibilities.  Assume that delays have been introduced into a
+   system so that, at most, an adversary can make one password try every
+   six seconds.  That's 600 per hour or about 15,000 per day or about
+   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
+   unlikely someone could actually try continuously for a year.  In
+   fact, even if log files are only checked monthly, 500,000 tries is
+   more plausible before the attack is noticed and steps taken to change
+   passwords and make it harder to try more passwords.
+
+   To have a one in a thousand chance of guessing the password in
+   500,000 tries implies a universe of at least 500,000,000 passwords or
+   about 2^29.  Thus 29 bits of randomness are needed. This can probably
+   be achieved using the US DoD recommended inputs for password
+   generation as it has 8 inputs which probably average over 5 bits of
+   randomness each (see section 7.1).  Using a list of 1000 words, the
+   password could be expressed as a three word phrase (1,000,000,000
+   possibilities) or, using case insensitive letters and digits, six
+   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
+
+   For a higher security password, the number of bits required goes up.
+   To decrease the probability by 1,000 requires increasing the universe
+   of passwords by the same factor which adds about 10 bits.  Thus to
+   have only a one in a million chance of a password being guessed under
+   the above scenario would require 39 bits of randomness and a password
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 24]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   that was a four word phrase from a 1000 word list or eight
+   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
+   are needed implying a five word phrase or ten letter/digit password.
+
+   In a real system, of course, there are also other factors.  For
+   example, the larger and harder to remember passwords are, the more
+   likely users are to write them down resulting in an additional risk
+   of compromise.
+
+8.2 A Very High Security Cryptographic Key
+
+   Assume that a very high security key is needed for symmetric
+   encryption / decryption between two parties.  Assume an adversary can
+   observe communications and knows the algorithm being used.  Within
+   the field of random possibilities, the adversary can try key values
+   in hopes of finding the one in use.  Assume further that brute force
+   trial of keys is the best the adversary can do.
+
+8.2.1 Effort per Key Trial
+
+   How much effort will it take to try each key?  For very high security
+   applications it is best to assume a low value of effort.  Even if it
+   would clearly take tens of thousands of computer cycles or more to
+   try a single key, there may be some pattern that enables huge blocks
+   of key values to be tested with much less effort per key.  Thus it is
+   probably best to assume no more than a couple hundred cycles per key.
+   (There is no clear lower bound on this as computers operate in
+   parallel on a number of bits and a poor encryption algorithm could
+   allow many keys or even groups of keys to be tested in parallel.
+   However, we need to assume some value and can hope that a reasonably
+   strong algorithm has been chosen for our hypothetical high security
+   task.)
+
+   If the adversary can command a highly parallel processor or a large
+   network of work stations, 2*10^10 cycles per second is probably a
+   minimum assumption for availability today.  Looking forward just a
+   couple years, there should be at least an order of magnitude
+   improvement.  Thus assuming 10^9 keys could be checked per second or
+   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
+   reasonable.  This implies a need for a minimum of 51 bits of
+   randomness in keys to be sure they cannot be found in a month.  Even
+   then it is possible that, a few years from now, a highly determined
+   and resourceful adversary could break the key in 2 weeks (on average
+   they need try only half the keys).
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 25]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+8.2.2 Meet in the Middle Attacks
+
+   If chosen or known plain text and the resulting encrypted text are
+   available, a "meet in the middle" attack is possible if the structure
+   of the encryption algorithm allows it.  (In a known plain text
+   attack, the adversary knows all or part of the messages being
+   encrypted, possibly some standard header or trailer fields.  In a
+   chosen plain text attack, the adversary can force some chosen plain
+   text to be encrypted, possibly by "leaking" an exciting text that
+   would then be sent by the adversary over an encrypted channel.)
+
+   An oversimplified explanation of the meet in the middle attack is as
+   follows: the adversary can half-encrypt the known or chosen plain
+   text with all possible first half-keys, sort the output, then half-
+   decrypt the encoded text with all the second half-keys.  If a match
+   is found, the full key can be assembled from the halves and used to
+   decrypt other parts of the message or other messages.  At its best,
+   this type of attack can halve the exponent of the work required by
+   the adversary while adding a large but roughly constant factor of
+   effort.  To be assured of safety against this, a doubling of the
+   amount of randomness in the key to a minimum of 102 bits is required.
+
+   The meet in the middle attack assumes that the cryptographic
+   algorithm can be decomposed in this way but we can not rule that out
+   without a deep knowledge of the algorithm.  Even if a basic algorithm
+   is not subject to a meet in the middle attack, an attempt to produce
+   a stronger algorithm by applying the basic algorithm twice (or two
+   different algorithms sequentially) with different keys may gain less
+   added security than would be expected.  Such a composite algorithm
+   would be subject to a meet in the middle attack.
+
+   Enormous resources may be required to mount a meet in the middle
+   attack but they are probably within the range of the national
+   security services of a major nation.  Essentially all nations spy on
+   other nations government traffic and several nations are believed to
+   spy on commercial traffic for economic advantage.
+
+8.2.3 Other Considerations
+
+   Since we have not even considered the possibilities of special
+   purpose code breaking hardware or just how much of a safety margin we
+   want beyond our assumptions above, probably a good minimum for a very
+   high security cryptographic key is 128 bits of randomness which
+   implies a minimum key length of 128 bits.  If the two parties agree
+   on a key by Diffie-Hellman exchange [D-H], then in principle only
+   half of this randomness would have to be supplied by each party.
+   However, there is probably some correlation between their random
+   inputs so it is probably best to assume that each party needs to
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 26]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   provide at least 96 bits worth of randomness for very high security
+   if Diffie-Hellman is used.
+
+   This amount of randomness is beyond the limit of that in the inputs
+   recommended by the US DoD for password generation and could require
+   user typing timing, hardware random number generation, or other
+   sources.
+
+   It should be noted that key length calculations such at those above
+   are controversial and depend on various assumptions about the
+   cryptographic algorithms in use.  In some cases, a professional with
+   a deep knowledge of code breaking techniques and of the strength of
+   the algorithm in use could be satisfied with less than half of the
+   key size derived above.
+
+9. Conclusion
+
+   Generation of unguessable "random" secret quantities for security use
+   is an essential but difficult task.
+
+   We have shown that hardware techniques to produce such randomness
+   would be relatively simple.  In particular, the volume and quality
+   would not need to be high and existing computer hardware, such as
+   disk drives, can be used.  Computational techniques are available to
+   process low quality random quantities from multiple sources or a
+   larger quantity of such low quality input from one source and produce
+   a smaller quantity of higher quality, less predictable key material.
+   In the absence of hardware sources of randomness, a variety of user
+   and software sources can frequently be used instead with care;
+   however, most modern systems already have hardware, such as disk
+   drives or audio input, that could be used to produce high quality
+   randomness.
+
+   Once a sufficient quantity of high quality seed key material (a few
+   hundred bits) is available, strong computational techniques are
+   available to produce cryptographically strong sequences of
+   unpredicatable quantities from this seed material.
+
+10. Security Considerations
+
+   The entirety of this document concerns techniques and recommendations
+   for generating unguessable "random" quantities for use as passwords,
+   cryptographic keys, and similar security uses.
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 27]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+References
+
+   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
+   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
+   Press, Inc.
+
+   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
+   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
+
+   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
+   1981, David Brillinger.
+
+   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
+   Publishing Company.
+
+   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
+   John Wiley & Sons, 1981, Alan G. Konheim.
+
+   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
+   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
+   Meyer & Stephen M. Matyas.
+
+   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
+   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
+
+   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
+   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
+   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
+   Philip Fenstermacher.
+
+   [DES] -  Data Encryption Standard, United States of America,
+   Department of Commerce, National Institute of Standards and
+   Technology, Federal Information Processing Standard (FIPS) 46-1.
+   - Data Encryption Algorithm, American National Standards Institute,
+   ANSI X3.92-1981.
+   (See also FIPS 112, Password Usage, which includes FORTRAN code for
+   performing DES.)
+
+   [DES MODES] - DES Modes of Operation, United States of America,
+   Department of Commerce, National Institute of Standards and
+   Technology, Federal Information Processing Standard (FIPS) 81.
+   - Data Encryption Algorithm - Modes of Operation, American National
+   Standards Institute, ANSI X3.106-1983.
+
+   [D-H] - New Directions in Cryptography, IEEE Transactions on
+   Information Technology, November, 1976, Whitfield Diffie and Martin
+   E. Hellman.
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 28]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   [DoD] - Password Management Guideline, United States of America,
+   Department of Defense, Computer Security Center, CSC-STD-002-85.
+   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
+   as one of its appendices.)
+
+   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
+   David K. Gifford
+
+   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
+   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
+   Company, Second Edition 1982, Donald E. Knuth.
+
+   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
+   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
+
+   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
+   Kaliski
+   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
+   Rivest
+   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
+   Rivest
+
+   [PEM] - RFCs 1421 through 1424:
+   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
+   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
+   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
+   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
+   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
+   II: Certificate-Based Key Management, 02/10/1993, S. Kent
+   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
+   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
+
+   [SHANNON] - The Mathematical Theory of Communication, University of
+   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
+   System Technical Journal, July and October 1948)
+
+   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
+   Edition 1982, Solomon W. Golomb.
+
+   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
+   Systems, Aegean Park Press, 1984, Wayne G. Barker.
+
+   [SHS] - Secure Hash Standard, United States of American, National
+   Institute of Science and Technology, Federal Information Processing
+   Standard (FIPS) 180, April 1993.
+
+   [STERN] - Secret Linear Congruential Generators are not
+   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 29]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   [VON NEUMANN] - Various techniques used in connection with random
+   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
+   J. von Neumann.
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Digital Equipment Corporation
+   550 King Street, LKG2-1/BB3
+   Littleton, MA 01460
+
+   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
+   EMail:   dee@lkg.dec.com
+
+
+   Stephen D. Crocker
+   CyberCash Inc.
+   2086 Hunters Crest Way
+   Vienna, VA 22181
+
+   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
+   EMail:   crocker@cybercash.com
+
+
+   Jeffrey I. Schiller
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone:   +1 617 253 0161(w)
+   EMail:   jis@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 30]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc1831.txt b/third_party/heimdal/doc/standardisation/rfc1831.txt
new file mode 100644
index 00000000000..0556c9e83f3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc1831.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                      R. Srinivasan
+Request for Comments: 1831                              Sun Microsystems
+Category: Standards Track                                    August 1995
+
+
+      RPC: Remote Procedure Call Protocol Specification Version 2
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+ABSTRACT
+
+   This document describes the ONC Remote Procedure Call (ONC RPC
+   Version 2) protocol as it is currently deployed and accepted.  "ONC"
+   stands for "Open Network Computing".
+
+TABLE OF CONTENTS
+
+      1. INTRODUCTION                                              2
+      2. TERMINOLOGY                                               2
+      3. THE RPC MODEL                                             2
+      4. TRANSPORTS AND SEMANTICS                                  4
+      5. BINDING AND RENDEZVOUS INDEPENDENCE                       5
+      6. AUTHENTICATION                                            5
+      7. RPC PROTOCOL REQUIREMENTS                                 5
+      7.1 RPC Programs and Procedures                              6
+      7.2 Authentication                                           7
+      7.3 Program Number Assignment                                8
+      7.4 Other Uses of the RPC Protocol                           8
+      7.4.1 Batching                                               8
+      7.4.2 Broadcast Remote Procedure Calls                       8
+      8. THE RPC MESSAGE PROTOCOL                                  9
+      9. AUTHENTICATION PROTOCOLS                                 12
+      9.1 Null Authentication                                     13
+      10. RECORD MARKING STANDARD                                 13
+      11. THE RPC LANGUAGE                                        13
+      11.1 An Example Service Described in the RPC Language       13
+      11.2 The RPC Language Specification                         14
+      11.3 Syntax Notes                                           15
+      APPENDIX A: SYSTEM AUTHENTICATION                           16
+      REFERENCES                                                  17
+      Security Considerations                                     18
+      Author's Address                                            18
+
+
+
+Srinivasan                  Standards Track                     [Page 1]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+1. INTRODUCTION
+
+   This document specifies version two of the message protocol used in
+   ONC Remote Procedure Call (RPC).  The message protocol is specified
+   with the eXternal Data Representation (XDR) language [9].  This
+   document assumes that the reader is familiar with XDR.  It does not
+   attempt to justify remote procedure calls systems or describe their
+   use.  The paper by Birrell and Nelson [1] is recommended as an
+   excellent background for the remote procedure call concept.
+
+2. TERMINOLOGY
+
+   This document discusses clients, calls, servers, replies, services,
+   programs, procedures, and versions.  Each remote procedure call has
+   two sides: an active client side that makes the call to a server,
+   which sends back a reply.  A network service is a collection of one
+   or more remote programs.  A remote program implements one or more
+   remote procedures; the procedures, their parameters, and results are
+   documented in the specific program's protocol specification.  A
+   server may support more than one version of a remote program in order
+   to be compatible with changing protocols.
+
+   For example, a network file service may be composed of two programs.
+   One program may deal with high-level applications such as file system
+   access control and locking.  The other may deal with low-level file
+   input and output and have procedures like "read" and "write".  A
+   client of the network file service would call the procedures
+   associated with the two programs of the service on behalf of the
+   client.
+
+   The terms client and server only apply to a particular transaction; a
+   particular hardware entity (host) or software entity (process or
+   program) could operate in both roles at different times.  For
+   example, a program that supplies remote execution service could also
+   be a client of a network file service.
+
+3. THE RPC MODEL
+
+   The ONC RPC protocol is based on the remote procedure call model,
+   which is similar to the local procedure call model.  In the local
+   case, the caller places arguments to a procedure in some well-
+   specified location (such as a register window).  It then transfers
+   control to the procedure, and eventually regains control.  At that
+   point, the results of the procedure are extracted from the well-
+   specified location, and the caller continues execution.
+
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 2]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+   The remote procedure call model is similar.  One thread of control
+   logically winds through two processes: the caller's process, and a
+   server's process.  The caller process first sends a call message to
+   the server process and waits (blocks) for a reply message.  The call
+   message includes the procedure's parameters, and the reply message
+   includes the procedure's results.  Once the reply message is
+   received, the results of the procedure are extracted, and caller's
+   execution is resumed.
+
+   On the server side, a process is dormant awaiting the arrival of a
+   call message.  When one arrives, the server process extracts the
+   procedure's parameters, computes the results, sends a reply message,
+   and then awaits the next call message.
+
+   In this model, only one of the two processes is active at any given
+   time.  However, this model is only given as an example.  The ONC RPC
+   protocol makes no restrictions on the concurrency model implemented,
+   and others are possible.  For example, an implementation may choose
+   to have RPC calls be asynchronous, so that the client may do useful
+   work while waiting for the reply from the server.  Another
+   possibility is to have the server create a separate task to process
+   an incoming call, so that the original server can be free to receive
+   other requests.
+
+   There are a few important ways in which remote procedure calls differ
+   from local procedure calls:
+
+      1. Error handling: failures of the remote server or network must
+      be handled when using remote procedure calls.
+
+      2. Global variables and side-effects: since the server does not
+      have access to the client's address space, hidden arguments cannot
+      be passed as global variables or returned as side effects.
+
+      3. Performance:  remote procedures usually operate one or more
+      orders of magnitude slower than local procedure calls.
+
+      4. Authentication: since remote procedure calls can be transported
+      over unsecured networks, authentication may be necessary.
+      Authentication prevents one entity from masquerading as some other
+      entity.
+
+   The conclusion is that even though there are tools to automatically
+   generate client and server libraries for a given service, protocols
+   must still be designed carefully.
+
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 3]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+4. TRANSPORTS AND SEMANTICS
+
+   The RPC protocol can be implemented on several different transport
+   protocols.  The RPC protocol does not care how a message is passed
+   from one process to another, but only with specification and
+   interpretation of messages.  However, the application may wish to
+   obtain information about (and perhaps control over) the transport
+   layer through an interface not specified in this document.  For
+   example, the transport protocol may impose a restriction on the
+   maximum size of RPC messages, or it may be stream-oriented like TCP
+   with no size limit.  The client and server must agree on their
+   transport protocol choices.
+
+   It is important to point out that RPC does not try to implement any
+   kind of reliability and that the application may need to be aware of
+   the type of transport protocol underneath RPC.  If it knows it is
+   running on top of a reliable transport such as TCP [6], then most of
+   the work is already done for it.  On the other hand, if it is running
+   on top of an unreliable transport such as UDP [7], it must implement
+   its own time-out, retransmission, and duplicate detection policies as
+   the RPC protocol does not provide these services.
+
+   Because of transport independence, the RPC protocol does not attach
+   specific semantics to the remote procedures or their execution
+   requirements.  Semantics can be inferred from (but should be
+   explicitly specified by) the underlying transport protocol.  For
+   example, consider RPC running on top of an unreliable transport such
+   as UDP.  If an application retransmits RPC call messages after time-
+   outs, and does not receive a reply, it cannot infer anything about
+   the number of times the procedure was executed.  If it does receive a
+   reply, then it can infer that the procedure was executed at least
+   once.
+
+   A server may wish to remember previously granted requests from a
+   client and not regrant them in order to insure some degree of
+   execute-at-most-once semantics.  A server can do this by taking
+   advantage of the transaction ID that is packaged with every RPC
+   message.  The main use of this transaction ID is by the client RPC
+   entity in matching replies to calls.  However, a client application
+   may choose to reuse its previous transaction ID when retransmitting a
+   call.  The server may choose to remember this ID after executing a
+   call and not execute calls with the same ID in order to achieve some
+   degree of execute-at-most-once semantics.  The server is not allowed
+   to examine this ID in any other way except as a test for equality.
+
+   On the other hand, if using a "reliable" transport such as TCP, the
+   application can infer from a reply message that the procedure was
+   executed exactly once, but if it receives no reply message, it cannot
+
+
+
+Srinivasan                  Standards Track                     [Page 4]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+   assume that the remote procedure was not executed.  Note that even if
+   a connection-oriented protocol like TCP is used, an application still
+   needs time-outs and reconnection to handle server crashes.
+
+   There are other possibilities for transports besides datagram- or
+   connection-oriented protocols.  For example, a request-reply protocol
+   such as VMTP [2] is perhaps a natural transport for RPC.  ONC RPC
+   uses both TCP and UDP transport protocols.  Section 10 (RECORD
+   MARKING STANDARD) describes the mechanism employed by ONC RPC to
+   utilize a connection-oriented, stream-oriented transport such as TCP.
+
+5. BINDING AND RENDEZVOUS INDEPENDENCE
+
+   The act of binding a particular client to a particular service and
+   transport parameters is NOT part of this RPC protocol specification.
+   This important and necessary function is left up to some higher-level
+   software.
+
+   Implementors could think of the RPC protocol as the jump-subroutine
+   instruction ("JSR") of a network; the loader (binder) makes JSR
+   useful, and the loader itself uses JSR to accomplish its task.
+   Likewise, the binding software makes RPC useful, possibly using RPC
+   to accomplish this task.
+
+6. AUTHENTICATION
+
+   The RPC protocol provides the fields necessary for a client to
+   identify itself to a service, and vice-versa, in each call and reply
+   message.  Security and access control mechanisms can be built on top
+   of this message authentication.  Several different authentication
+   protocols can be supported.  A field in the RPC header indicates
+   which protocol is being used. More information on specific
+   authentication protocols is in section 9: "Authentication Protocols".
+
+7. RPC PROTOCOL REQUIREMENTS
+
+   The RPC protocol must provide for the following:
+
+      (1) Unique specification of a procedure to be called.
+      (2) Provisions for matching response messages to request messages.
+      (3) Provisions for authenticating the caller to service and
+          vice-versa.
+
+
+
+
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 5]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+   Besides these requirements, features that detect the following are
+   worth supporting because of protocol roll-over errors, implementation
+   bugs, user error, and network administration:
+
+      (1) RPC protocol mismatches.
+      (2) Remote program protocol version mismatches.
+      (3) Protocol errors (such as misspecification of a procedure's
+          parameters).
+      (4) Reasons why remote authentication failed.
+      (5) Any other reasons why the desired procedure was not called.
+
+7.1 RPC Programs and Procedures
+
+   The RPC call message has three unsigned integer fields -- remote
+   program number, remote program version number, and remote procedure
+   number -- which uniquely identify the procedure to be called.
+   Program numbers are administered by a central authority
+   (rpc@sun.com).  Once implementors have a program number, they can
+   implement their remote program; the first implementation would most
+   likely have the version number 1.  Because most new protocols evolve,
+   a version field of the call message identifies which version of the
+   protocol the caller is using.  Version numbers enable support of both
+   old and new protocols through the same server process.
+
+   The procedure number identifies the procedure to be called.  These
+   numbers are documented in the specific program's protocol
+   specification.  For example, a file service's protocol specification
+   may state that its procedure number 5 is "read" and procedure number
+   12 is "write".
+
+   Just as remote program protocols may change over several versions,
+   the actual RPC message protocol could also change.  Therefore, the
+   call message also has in it the RPC version number, which is always
+   equal to two for the version of RPC described here.
+
+   The reply message to a request message has enough information to
+   distinguish the following error conditions:
+
+      (1) The remote implementation of RPC does not support protocol
+      version 2.  The lowest and highest supported RPC version numbers
+      are returned.
+
+      (2) The remote program is not available on the remote system.
+
+      (3) The remote program does not support the requested version
+      number.  The lowest and highest supported remote program version
+      numbers are returned.
+
+
+
+
+Srinivasan                  Standards Track                     [Page 6]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+      (4) The requested procedure number does not exist.  (This is
+      usually a client side protocol or programming error.)
+
+      (5) The parameters to the remote procedure appear to be garbage
+      from the server's point of view.  (Again, this is usually caused
+      by a disagreement about the protocol between client and service.)
+
+7.2 Authentication
+
+   Provisions for authentication of caller to service and vice-versa are
+   provided as a part of the RPC protocol.  The call message has two
+   authentication fields, the credential and verifier.  The reply
+   message has one authentication field, the response verifier.  The RPC
+   protocol specification defines all three fields to be the following
+   opaque type (in the eXternal Data Representation (XDR) language [9]):
+
+      enum auth_flavor {
+         AUTH_NONE       = 0,
+         AUTH_SYS        = 1,
+         AUTH_SHORT      = 2
+         /* and more to be defined */
+      };
+
+      struct opaque_auth {
+         auth_flavor flavor;
+         opaque body<400>;
+      };
+
+   In other words, any "opaque_auth" structure is an "auth_flavor"
+   enumeration followed by up to 400 bytes which are opaque to
+   (uninterpreted by) the RPC protocol implementation.
+
+   The interpretation and semantics of the data contained within the
+   authentication fields is specified by individual, independent
+   authentication protocol specifications.  (Section 9 defines the
+   various authentication protocols.)
+
+   If authentication parameters were rejected, the reply message
+   contains information stating why they were rejected.
+
+
+
+
+
+
+
+
+
+
+
+
+Srinivasan                  Standards Track                     [Page 7]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+7.3 Program Number Assignment
+
+   Program numbers are given out in groups of hexadecimal 20000000
+   (decimal 536870912) according to the following chart:
+
+              0 - 1fffffff   defined by rpc@sun.com
+       20000000 - 3fffffff   defined by user
+       40000000 - 5fffffff   transient
+       60000000 - 7fffffff   reserved
+       80000000 - 9fffffff   reserved
+       a0000000 - bfffffff   reserved
+       c0000000 - dfffffff   reserved
+       e0000000 - ffffffff   reserved
+
+   The first group is a range of numbers administered by rpc@sun.com and
+   should be identical for all sites.  The second range is for
+   applications peculiar to a particular site.  This range is intended
+   primarily for debugging new programs.  When a site develops an
+   application that might be of general interest, that application
+   should be given an assigned number in the first range.  Application
+   developers may apply for blocks of RPC program numbers in the first
+   range by sending electronic mail to "rpc@sun.com".  The third group
+   is for applications that generate program numbers dynamically.  The
+   final groups are reserved for future use, and should not be used.
+
+7.4 Other Uses of the RPC Protocol
+
+   The intended use of this protocol is for calling remote procedures.
+   Normally, each call message is matched with a reply message.
+   However, the protocol itself is a message-passing protocol with which
+   other (non-procedure call) protocols can be implemented.
+
+7.4.1 Batching
+
+   Batching is useful when a client wishes to send an arbitrarily large
+   sequence of call messages to a server.  Batching typically uses
+   reliable byte stream protocols (like TCP) for its transport.  In the
+   case of batching, the client never waits for a reply from the server,
+   and the server does not send replies to batch calls.  A sequence of
+   batch calls is usually terminated by a legitimate remote procedure
+   call operation in order to flush the pipeline and get positive
+   acknowledgement.
+
+7.4.2 Broadcast Remote Procedure Calls
+
+   In broadcast protocols, the client sends a broadcast call to the
+   network and waits for numerous replies.  This requires the use of
+   packet-based protocols (like UDP) as its transport protocol.  Servers
+
+
+
+Srinivasan                  Standards Track                     [Page 8]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+   that support broadcast protocols usually respond only when the call
+   is successfully processed and are silent in the face of errors, but
+   this varies with the application.
+
+   The principles of broadcast RPC also apply to multicasting - an RPC
+   request can be sent to a multicast address.
+
+8. THE RPC MESSAGE PROTOCOL
+
+   This section defines the RPC message protocol in the XDR data
+   description language [9].
+
+      enum msg_type {
+         CALL  = 0,
+         REPLY = 1
+      };
+
+   A reply to a call message can take on two forms: The message was
+   either accepted or rejected.
+
+      enum reply_stat {
+         MSG_ACCEPTED = 0,
+         MSG_DENIED   = 1
+      };
+
+   Given that a call message was accepted, the following is the status
+   of an attempt to call a remote procedure.
+
+      enum accept_stat {
+         SUCCESS       = 0, /* RPC executed successfully             */
+         PROG_UNAVAIL  = 1, /* remote hasn't exported program        */
+         PROG_MISMATCH = 2, /* remote can't support version #        */
+         PROC_UNAVAIL  = 3, /* program can't support procedure       */
+         GARBAGE_ARGS  = 4, /* procedure can't decode params         */
+         SYSTEM_ERR    = 5  /* errors like memory allocation failure */
+      };
+
+   Reasons why a call message was rejected:
+
+      enum reject_stat {
+         RPC_MISMATCH = 0, /* RPC version number != 2          */
+         AUTH_ERROR = 1    /* remote can't authenticate caller */
+      };
+
+   Why authentication failed:
+
+      enum auth_stat {
+         AUTH_OK           = 0,  /* success                          */
+
+
+
+Srinivasan                  Standards Track                     [Page 9]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+         /*
+          * failed at remote end
+          */
+         AUTH_BADCRED      = 1,  /* bad credential (seal broken)     */
+         AUTH_REJECTEDCRED = 2,  /* client must begin new session    */
+         AUTH_BADVERF      = 3,  /* bad verifier (seal broken)       */
+         AUTH_REJECTEDVERF = 4,  /* verifier expired or replayed     */
+         AUTH_TOOWEAK      = 5,  /* rejected for security reasons    */
+         /*
+          * failed locally
+          */
+         AUTH_INVALIDRESP  = 6,  /* bogus response verifier          */
+         AUTH_FAILED       = 7   /* reason unknown                   */
+      };
+
+   The RPC message:
+
+   All messages start with a transaction identifier, xid, followed by a
+   two-armed discriminated union.  The union's discriminant is a
+   msg_type which switches to one of the two types of the message.  The
+   xid of a REPLY message always matches that of the initiating CALL
+   message.  NB: The xid field is only used for clients matching reply
+   messages with call messages or for servers detecting retransmissions;
+   the service side cannot treat this id as any type of sequence number.
+
+      struct rpc_msg {
+         unsigned int xid;
+         union switch (msg_type mtype) {
+         case CALL:
+            call_body cbody;
+         case REPLY:
+            reply_body rbody;
+         } body;
+      };
+
+   Body of an RPC call:
+
+   In version 2 of the RPC protocol specification, rpcvers must be equal
+   to 2.  The fields prog, vers, and proc specify the remote program,
+   its version number, and the procedure within the remote program to be
+   called.  After these fields are two authentication parameters:  cred
+   (authentication credential) and verf (authentication verifier).  The
+   two authentication parameters are followed by the parameters to the
+   remote procedure, which are specified by the specific program
+   protocol.
+
+   The purpose of the authentication verifier is to validate the
+   authentication credential.  Note that these two items are
+
+
+
+Srinivasan                  Standards Track                    [Page 10]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+   historically separate, but are always used together as one logical
+   entity.
+
+      struct call_body {
+         unsigned int rpcvers;       /* must be equal to two (2) */
+         unsigned int prog;
+         unsigned int vers;
+         unsigned int proc;
+         opaque_auth  cred;
+         opaque_auth  verf;
+         /* procedure specific parameters start here */
+      };
+
+   Body of a reply to an RPC call:
+
+      union reply_body switch (reply_stat stat) {
+      case MSG_ACCEPTED:
+         accepted_reply areply;
+      case MSG_DENIED:
+         rejected_reply rreply;
+      } reply;
+
+   Reply to an RPC call that was accepted by the server:
+
+   There could be an error even though the call was accepted.  The first
+   field is an authentication verifier that the server generates in
+   order to validate itself to the client.  It is followed by a union
+   whose discriminant is an enum accept_stat.  The SUCCESS arm of the
+   union is protocol specific.  The PROG_UNAVAIL, PROC_UNAVAIL,
+   GARBAGE_ARGS, and SYSTEM_ERR arms of the union are void.  The
+   PROG_MISMATCH arm specifies the lowest and highest version numbers of
+   the remote program supported by the server.
+
+      struct accepted_reply {
+         opaque_auth verf;
+         union switch (accept_stat stat) {
+         case SUCCESS:
+            opaque results[0];
+            /*
+             * procedure-specific results start here
+             */
+          case PROG_MISMATCH:
+             struct {
+                unsigned int low;
+                unsigned int high;
+             } mismatch_info;
+          default:
+             /*
+
+
+
+Srinivasan                  Standards Track                    [Page 11]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+              * Void.  Cases include PROG_UNAVAIL, PROC_UNAVAIL,
+              * GARBAGE_ARGS, and SYSTEM_ERR.
+              */
+             void;
+          } reply_data;
+      };
+
+   Reply to an RPC call that was rejected by the server:
+
+   The call can be rejected for two reasons: either the server is not
+   running a compatible version of the RPC protocol (RPC_MISMATCH), or
+   the server rejects the identity of the caller (AUTH_ERROR). In case
+   of an RPC version mismatch, the server returns the lowest and highest
+   supported RPC version numbers.  In case of invalid authentication,
+   failure status is returned.
+
+      union rejected_reply switch (reject_stat stat) {
+      case RPC_MISMATCH:
+         struct {
+            unsigned int low;
+            unsigned int high;
+         } mismatch_info;
+      case AUTH_ERROR:
+         auth_stat stat;
+      };
+
+9. AUTHENTICATION PROTOCOLS
+
+   As previously stated, authentication parameters are opaque, but
+   open-ended to the rest of the RPC protocol.  This section defines two
+   standard "flavors" of authentication.  Implementors are free to
+   invent new authentication types, with the same rules of flavor number
+   assignment as there is for program number assignment.  The "flavor"
+   of a credential or verifier refers to the value of the "flavor" field
+   in the opaque_auth structure. Flavor numbers, like RPC program
+   numbers, are also administered centrally, and developers may assign
+   new flavor numbers by applying through electronic mail to
+   "rpc@sun.com".  Credentials and verifiers are represented as variable
+   length opaque data (the "body" field in the opaque_auth structure).
+
+   In this document, two flavors of authentication are described.  Of
+   these, Null authentication (described in the next subsection) is
+   mandatory - it must be available in all implementations.  System
+   authentication is described in Appendix A.  It is strongly
+   recommended that implementors include System authentication in their
+   implementations.  Many applications use this style of authentication,
+   and availability of this flavor in an implementation will enhance
+   interoperability.
+
+
+
+Srinivasan                  Standards Track                    [Page 12]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+9.1 Null Authentication
+
+   Often calls must be made where the client does not care about its
+   identity or the server does not care who the client is.  In this
+   case, the flavor of the RPC message's credential, verifier, and reply
+   verifier is "AUTH_NONE".  Opaque data associated with "AUTH_NONE" is
+   undefined.  It is recommended that the length of the opaque data be
+   zero.
+
+10. RECORD MARKING STANDARD
+
+   When RPC messages are passed on top of a byte stream transport
+   protocol (like TCP), it is necessary to delimit one message from
+   another in order to detect and possibly recover from protocol errors.
+   This is called record marking (RM).  One RPC message fits into one RM
+   record.
+
+   A record is composed of one or more record fragments.  A record
+   fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
+   fragment data.  The bytes encode an unsigned binary number; as with
+   XDR integers, the byte order is from highest to lowest.  The number
+   encodes two values -- a boolean which indicates whether the fragment
+   is the last fragment of the record (bit value 1 implies the fragment
+   is the last fragment) and a 31-bit unsigned binary value which is the
+   length in bytes of the fragment's data.  The boolean value is the
+   highest-order bit of the header; the length is the 31 low-order bits.
+   (Note that this record specification is NOT in XDR standard form!)
+
+11. THE RPC LANGUAGE
+
+   Just as there was a need to describe the XDR data-types in a formal
+   language, there is also need to describe the procedures that operate
+   on these XDR data-types in a formal language as well.  The RPC
+   Language is an extension to the XDR language, with the addition of
+   "program", "procedure", and "version" declarations.  The following
+   example is used to describe the essence of the language.
+
+11.1 An Example Service Described in the RPC Language
+
+   Here is an example of the specification of a simple ping program.
+
+   program PING_PROG {
+         /*
+          * Latest and greatest version
+          */
+         version PING_VERS_PINGBACK {
+            void
+            PINGPROC_NULL(void) = 0;
+
+
+
+Srinivasan                  Standards Track                    [Page 13]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+            /*
+             * Ping the client, return the round-trip time
+             * (in microseconds). Returns -1 if the operation
+             * timed out.
+             */
+            int
+            PINGPROC_PINGBACK(void) = 1;
+         } = 2;
+
+         /*
+          * Original version
+          */
+         version PING_VERS_ORIG {
+            void
+            PINGPROC_NULL(void) = 0;
+         } = 1;
+      } = 1;
+
+      const PING_VERS = 2;      /* latest version */
+
+   The first version described is PING_VERS_PINGBACK with two
+   procedures, PINGPROC_NULL and PINGPROC_PINGBACK.  PINGPROC_NULL takes
+   no arguments and returns no results, but it is useful for computing
+   round-trip times from the client to the server and back again.  By
+   convention, procedure 0 of any RPC protocol should have the same
+   semantics, and never require any kind of authentication.  The second
+   procedure is used for the client to have the server do a reverse ping
+   operation back to the client, and it returns the amount of time (in
+   microseconds) that the operation used.  The next version,
+   PING_VERS_ORIG, is the original version of the protocol and it does
+   not contain PINGPROC_PINGBACK procedure. It is useful for
+   compatibility with old client programs, and as this program matures
+   it may be dropped from the protocol entirely.
+
+11.2 The RPC Language Specification
+
+   The RPC language is identical to the XDR language defined in RFC
+   1014, except for the added definition of a "program-def" described
+   below.
+
+   program-def:
+      "program" identifier "{"
+         version-def
+         version-def *
+      "}" "=" constant ";"
+
+   version-def:
+      "version" identifier "{"
+
+
+
+Srinivasan                  Standards Track                    [Page 14]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+          procedure-def
+          procedure-def *
+      "}" "=" constant ";"
+
+   procedure-def:
+      type-specifier identifier "(" type-specifier
+        ("," type-specifier )* ")" "=" constant ";"
+
+11.3 Syntax Notes
+
+   (1) The following keywords are added and cannot be used as
+   identifiers: "program" and "version";
+
+   (2) A version name cannot occur more than once within the scope of a
+   program definition. Nor can a version number occur more than once
+   within the scope of a program definition.
+
+   (3) A procedure name cannot occur more than once within the scope of
+   a version definition. Nor can a procedure number occur more than once
+   within the scope of version definition.
+
+   (4) Program identifiers are in the same name space as constant and
+   type identifiers.
+
+   (5) Only unsigned constants can be assigned to programs, versions and
+   procedures.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srinivasan                  Standards Track                    [Page 15]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+APPENDIX A: SYSTEM AUTHENTICATION
+
+   The client may wish to identify itself, for example, as it is
+   identified on a UNIX(tm) system.  The flavor of the client credential
+   is "AUTH_SYS".  The opaque data constituting the credential encodes
+   the following structure:
+
+      struct authsys_parms {
+         unsigned int stamp;
+         string machinename<255>;
+         unsigned int uid;
+         unsigned int gid;
+         unsigned int gids<16>;
+      };
+
+   The "stamp" is an arbitrary ID which the caller machine may generate.
+   The "machinename" is the name of the caller's machine (like
+   "krypton").  The "uid" is the caller's effective user ID.  The "gid"
+   is the caller's effective group ID.  The "gids" is a counted array of
+   groups which contain the caller as a member.  The verifier
+   accompanying the credential should have "AUTH_NONE" flavor value
+   (defined above).  Note this credential is only unique within a
+   particular domain of machine names, uids, and gids.
+
+   The flavor value of the verifier received in the reply message from
+   the server may be "AUTH_NONE" or "AUTH_SHORT".  In the case of
+   "AUTH_SHORT", the bytes of the reply verifier's string encode an
+   opaque structure.  This new opaque structure may now be passed to the
+   server instead of the original "AUTH_SYS" flavor credential.  The
+   server may keep a cache which maps shorthand opaque structures
+   (passed back by way of an "AUTH_SHORT" style reply verifier) to the
+   original credentials of the caller.  The caller can save network
+   bandwidth and server cpu cycles by using the shorthand credential.
+
+   The server may flush the shorthand opaque structure at any time.  If
+   this happens, the remote procedure call message will be rejected due
+   to an authentication error.  The reason for the failure will be
+   "AUTH_REJECTEDCRED".  At this point, the client may wish to try the
+   original "AUTH_SYS" style of credential.
+
+   It should be noted that use of this flavor of authentication does not
+   guarantee any security for the users or providers of a service, in
+   itself.  The authentication provided by this scheme can be considered
+   legitimate only when applications using this scheme and the network
+   can be secured externally, and privileged transport addresses are
+   used for the communicating end-points (an example of this is the use
+   of privileged TCP/UDP ports in Unix systems - note that not all
+   systems enforce privileged transport address mechanisms).
+
+
+
+Srinivasan                  Standards Track                    [Page 16]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+REFERENCES
+
+   [1]  Birrell, A. D.  & Nelson, B. J., "Implementing Remote Procedure
+        Calls", XEROX CSL-83-7, October 1983.
+
+   [2]  Cheriton, D., "VMTP: Versatile Message Transaction Protocol",
+        Preliminary Version 0.3, Stanford University, January 1987.
+
+   [3]  Diffie & Hellman, "New Directions in Cryptography", IEEE
+        Transactions on Information Theory IT-22, November 1976.
+
+   [4]  Mills, D., "Network Time Protocol", RFC 1305, UDEL,
+        March 1992.
+
+   [5]  National Bureau of Standards, "Data Encryption Standard",
+        Federal Information Processing Standards Publication 46, January
+        1977.
+
+   [6]  Postel, J., "Transmission Control Protocol - DARPA Internet
+        Program Protocol Specification", STD 7, RFC 793, USC/Information
+        Sciences Institute, September 1981.
+
+   [7]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+        USC/Information Sciences Institute, August 1980.
+
+   [8]  Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
+        RFC 1700, USC/Information Sciences Institute, October 1994.
+
+   [9]  Srinivasan, R., "XDR: External Data Representation Standard",
+        RFC 1832, Sun Microsystems, Inc., August 1995.
+
+   [10] Miller, S., Neuman, C., Schiller, J., and  J. Saltzer, "Section
+        E.2.1: Kerberos  Authentication and Authorization System",
+        M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
+        1987.
+
+   [11] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
+        Authentication Service for Open Network Systems", pp. 191-202 in
+        Usenix Conference Proceedings, Dallas, Texas, February 1988.
+
+   [12] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
+        Service (V5)", RFC 1510, Digital Equipment Corporation,
+        USC/Information Sciences Institute, September 1993.
+
+
+
+
+
+
+
+
+Srinivasan                  Standards Track                    [Page 17]
+
+RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Raj Srinivasan
+   Sun Microsystems, Inc.
+   ONC Technologies
+   2550 Garcia Avenue
+   M/S MTV-5-40
+   Mountain View, CA  94043
+   USA
+
+   Phone: 415-336-2478
+   Fax:   415-336-6015
+   EMail: raj@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Srinivasan                  Standards Track                    [Page 18]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc1964.txt b/third_party/heimdal/doc/standardisation/rfc1964.txt
new file mode 100644
index 00000000000..f2960b961dd
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc1964.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                            J. Linn
+Request for Comments: 1964                       OpenVision Technologies
+Category: Standards Track                                      June 1996
+
+
+                The Kerberos Version 5 GSS-API Mechanism
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+ABSTRACT
+
+   This specification defines protocols, procedures, and conventions to
+   be employed by peers implementing the Generic Security Service
+   Application Program Interface (as specified in RFCs 1508 and 1509)
+   when using Kerberos Version 5 technology (as specified in RFC 1510).
+
+ACKNOWLEDGMENTS
+
+   Much of the material in this memo is based on working documents
+   drafted by John Wray of Digital Equipment Corporation and on
+   discussions, implementation activities, and interoperability testing
+   involving Marc Horowitz, Ted Ts'o, and John Wray.  Particular thanks
+   are due to each of these individuals for their contributions towards
+   development and availability of GSS-API support within the Kerberos
+   Version 5 code base.
+
+1. Token Formats
+
+   This section discusses protocol-visible characteristics of the GSS-
+   API mechanism to be implemented atop Kerberos V5 security technology
+   per RFC-1508 and RFC-1510; it defines elements of protocol for
+   interoperability and is independent of language bindings per RFC-
+   1509.
+
+   Tokens transferred between GSS-API peers (for security context
+   management and per-message protection purposes) are defined.  The
+   data elements exchanged between a GSS-API endpoint implementation and
+   the Kerberos KDC are not specific to GSS-API usage and are therefore
+   defined within RFC-1510 rather than within this specification.
+
+
+
+
+
+
+Linn                        Standards Track                     [Page 1]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   To support ongoing experimentation, testing, and evolution of the
+   specification, the Kerberos V5 GSS-API mechanism as defined in this
+   and any successor memos will be identified with the following Object
+   Identifier, as defined in RFC-1510, until the specification is
+   advanced to the level of Proposed Standard RFC:
+
+   {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}
+
+   Upon advancement to the level of Proposed Standard RFC, the Kerberos
+   V5 GSS-API mechanism will be identified by an Object Identifier
+   having the value:
+
+   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
+   gssapi(2) krb5(2)}
+
+1.1. Context Establishment Tokens
+
+   Per RFC-1508, Appendix B, the initial context establishment token
+   will be enclosed within framing as follows:
+
+   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 of the initial context token will consist of a
+   Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
+   (TOK_ID) field, which shall contain the value 01 00.
+
+   The above GSS-API framing shall be applied to all tokens emitted by
+   the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
+   context-deletion, and per-message tokens, not just to the initial
+   token in a context establishment sequence.  While not required by
+   RFC-1508, this enables implementations to perform enhanced error-
+   checking. The innerContextToken field of context establishment tokens
+   for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
+   (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
+   field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
+   messages and 03 00 for KRB_ERROR messages.
+
+
+
+
+
+
+Linn                        Standards Track                     [Page 2]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+1.1.1. Initial Token
+
+   Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:
+
+   AP-REQ ::= [APPLICATION 14] SEQUENCE {
+           pvno [0]        INTEGER,        -- indicates Version 5
+           msg-type [1]    INTEGER,        -- indicates KRB_AP_REQ
+           ap-options[2]   APOptions,
+           ticket[3]       Ticket,
+           authenticator[4]        EncryptedData
+   }
+
+   APOptions ::= BIT STRING {
+           reserved (0),
+           use-session-key (1),
+           mutual-required (2)
+   }
+
+   Ticket ::= [APPLICATION 1] SEQUENCE {
+           tkt-vno [0]     INTEGER,        -- indicates Version 5
+           realm [1]       Realm,
+           sname [2]       PrincipalName,
+           enc-part [3]    EncryptedData
+   }
+
+   -- 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
+   }
+
+   -- 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,
+
+
+
+Linn                        Standards Track                     [Page 3]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+           subkey[6]               EncryptionKey OPTIONAL,
+           seq-number[7]           INTEGER OPTIONAL,
+           authorization-data[8]   AuthorizationData OPTIONAL
+   }
+
+   For purposes of this specification, the authenticator shall include
+   the optional sequence number, and the checksum field shall be used to
+   convey channel binding, service flags, and optional delegation
+   information.  The checksum will have a type of 0x8003 (a value being
+   registered within the Kerberos protocol specification), and a value
+   field of at least 24 bytes in length.  The length of the value field
+   is extended beyond 24 bytes if and only if an optional facility to
+   carry a Kerberos-defined KRB_CRED message for delegation purposes is
+   supported by an implementation and active on a context. When
+   delegation is active, a TGT with its FORWARDABLE flag set will be
+   transferred within the KRB_CRED message.
+
+   The checksum value field's format is as follows:
+
+   Byte    Name    Description
+   0..3    Lgth    Number of bytes in Bnd field;
+                   Currently contains hex 10 00 00 00
+                   (16, represented in little-endian form)
+   4..19   Bnd     MD5 hash of channel bindings, taken over all non-null
+                   components of bindings, in order of declaration.
+                   Integer fields within channel bindings are represented
+                   in little-endian order for the purposes of the MD5
+                   calculation.
+   20..23  Flags   Bit vector of context-establishment flags,
+                   with values consistent with RFC-1509, p. 41:
+                           GSS_C_DELEG_FLAG:       1
+                           GSS_C_MUTUAL_FLAG:      2
+                           GSS_C_REPLAY_FLAG:      4
+                           GSS_C_SEQUENCE_FLAG:    8
+                           GSS_C_CONF_FLAG:        16
+                           GSS_C_INTEG_FLAG:       32
+                   The resulting bit vector is encoded into bytes 20..23
+                   in little-endian form.
+   24..25  DlgOpt  The Delegation Option identifier (=1) [optional]
+   26..27  Dlgth   The length of the Deleg field. [optional]
+   28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional]
+
+   In computing the contents of the "Bnd" field, the following detailed
+   points apply:
+
+        (1) Each integer field shall be formatted into four bytes, using
+        little-endian byte ordering, for purposes of MD5 hash
+        computation.
+
+
+
+Linn                        Standards Track                     [Page 4]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+        (2) All input length fields within gss_buffer_desc elements of a
+        gss_channel_bindings_struct, even those which are zero-valued,
+        shall be included in the hash calculation; the value elements of
+        gss_buffer_desc elements shall be dereferenced, and the
+        resulting data shall be included within the hash computation,
+        only for the case of gss_buffer_desc elements having non-zero
+        length specifiers.
+
+        (3) If the caller passes the value GSS_C_NO_BINDINGS instead of
+        a valid channel bindings structure, the Bnd field shall be set
+        to 16 zero-valued bytes.
+
+   In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token)
+   from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
+   GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set
+   as the logical AND of the initiator's corresponding request flag to
+   GSS_Init_sec_context() and a Boolean indicator of whether that
+   optional service is available to GSS_Init_sec_context()'s caller.
+   GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no corresponding
+   context-level input indicator flags to GSS_Init_sec_context() exist,
+   shall each be set to indicate whether their respective per-message
+   protection services are available for use on the context being
+   established.
+
+   When input source address channel binding values are provided by a
+   caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
+   source address specifier value within the input structure is
+   GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
+   context's peer bears address restrictions, it is recommended that an
+   implementation of the Kerberos V5 GSS-API mechanism should check that
+   the source address as provided by the caller matches that in the
+   received token, and should return the GSS_S_BAD_BINDINGS major_status
+   value if a mismatch is detected. Note: discussion is ongoing about
+   the strength of recommendation to be made in this area, and on the
+   circumstances under which such a recommendation should be applicable;
+   implementors are therefore advised that changes on this matter may be
+   included in subsequent versions of this specification.
+
+1.1.2. Response Tokens
+
+   A context establishment sequence based on the Kerberos V5 mechanism
+   will perform one-way authentication (without confirmation or any
+   return token from target to initiator in response to the initiator's
+   KRB_AP_REQ) if the mutual_req bit is not set in the application's
+   call to GSS_Init_sec_context().  Applications requiring confirmation
+   that their authentication was successful should request mutual
+   authentication, resulting in a "mutual-required" indication within
+   KRB_AP_REQ APoptions and the setting of the mutual_req bit in the
+
+
+
+Linn                        Standards Track                     [Page 5]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   flags field of the authenticator checksum.  In response to such a
+   request, the context target will reply to the initiator with a token
+   containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
+   context establishment exchange.
+
+   Relevant KRB_AP_REP syntax is as follows:
+
+   AP-REP ::= [APPLICATION 15] SEQUENCE {
+           pvno [0]        INTEGER,        -- represents Kerberos V5
+           msg-type [1]    INTEGER,        -- represents KRB_AP_REP
+           enc-part [2]    EncryptedData
+   }
+
+   EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
+           ctime [0]       KerberosTime,
+           cusec [1]       INTEGER,
+           subkey [2]      EncryptionKey OPTIONAL,
+           seq-number [3]  INTEGER OPTIONAL
+   }
+
+   The optional seq-number element within the AP-REP's EncAPRepPart
+   shall be included.
+
+   The syntax of KRB_ERROR is as follows:
+
+   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
+   }
+
+   Values to be transferred in the error-code field of a KRB-ERROR
+   message are defined in [RFC-1510], not in this specification.
+
+
+
+
+
+
+
+
+Linn                        Standards Track                     [Page 6]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+1.2. Per-Message and Context Deletion Tokens
+
+   Three classes of tokens are defined in this section: "MIC" tokens,
+   emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed
+   by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens,
+   emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by
+   calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion
+   tokens, emitted by calls to GSS_Delete_sec_context() and consumed by
+   calls to GSS_Process_context_token().  Note: References to GSS-API
+   per-message routines in the remainder of this specification will be
+   based on those routines' newer recommended names rather than those
+   names' predecessors.
+
+   Several variants of cryptographic keys are used in generation and
+   processing of per-message tokens:
+
+        (1) context key: uses Kerberos session key (or subkey, if
+        present in authenticator emitted by context initiator) directly
+
+        (2) confidentiality key: forms variant of context key by
+        exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.
+
+        (3) MD2.5 seed key: forms variant of context key by reversing
+        the bytes of the context key (i.e. if the original key is the
+        8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
+        will be {hh, gg, ff, ee, dd, cc, bb, aa}).
+
+1.2.1. Per-message Tokens - MIC
+
+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 as received.  The token has the following format:
+
+   Byte no          Name           Description
+    0..1           TOK_ID          Identification field.
+                                   Tokens emitted by GSS_GetMIC() contain
+                                   the hex value 01 01 in this field.
+    2..3           SGN_ALG         Integrity algorithm indicator.
+                                   00 00 - DES MAC MD5
+                                   01 00 - MD2.5
+                                   02 00 - DES MAC
+    4..7           Filler          Contains ff ff ff ff
+    8..15          SND_SEQ         Sequence number field.
+    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+
+
+
+
+
+Linn                        Standards Track                     [Page 7]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   GSS-API tokens must be encapsulated within the higher-level protocol
+   by the application; no embedded length field is necessary.
+
+1.2.1.1. Checksum
+
+   Checksum calculation procedure (common to all algorithms): Checksums
+   are calculated over the data field, logically prepended by the first
+   8 bytes of the plaintext packet header.  The resulting value binds
+   the data to the packet type and signature algorithm identifier
+   fields.
+
+   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
+   [RFC-1321] hash over the plaintext data, and then computing a DES-CBC
+   MAC on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is
+   computed per [FIPS-PUB-113], employing the context key and a zero IV.
+   The 8-byte result is stored in the SGN_CKSUM field.
+
+   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
+   16-byte zero-block, using a zero IV and a key formed by reversing the
+   bytes of the context key (i.e. if the original key is the 8-byte
+   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
+   {hh, gg, ff, ee, dd, cc, bb, aa}).   The resulting 16-byte value is
+   logically prepended to the to-be-signed data.  A standard MD5
+   checksum is calculated over the combined data, and the first 8 bytes
+   of the result are stored in the SGN_CKSUM field.  Note 1: we refer to
+   this algorithm informally as "MD2.5" to connote the fact that it uses
+   half of the 128 bits generated by MD5; use of only a subset of the
+   MD5 bits is intended to protect against the prospect that data could
+   be postfixed to an existing message with corresponding modifications
+   being made to the checksum.  Note 2: This algorithm is fairly novel
+   and has received more limited evaluation than that to which other
+   integrity algorithms have been subjected.  An initial, limited
+   evaluation indicates that it may be significantly weaker than DES MAC
+   MD5.
+
+   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
+   plaintext data per [FIPS-PUB-113], employing the context key and a
+   zero IV. Padding procedures to accomodate plaintext data lengths
+   which may not be integral multiples of 8 bytes are defined in [FIPS-
+   PUB-113].  The result is an 8-byte value, which is stored in the
+   SGN_CKSUM field.  Support for this algorithm may not be present in
+   all implementations.
+
+1.2.1.2. Sequence Number
+
+   Sequence number field: The 8 byte plaintext sequence number field is
+   formed from the sender's four-byte sequence number as follows.  If
+   the four bytes of the sender's sequence number are named s0, s1, s2
+
+
+
+Linn                        Standards Track                     [Page 8]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   and s3 (from least to most significant), the plaintext sequence
+   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
+   di), where 'di' is the direction-indicator (Hex 0 - sender is the
+   context initiator, Hex FF - sender is the context acceptor).  The
+   field is then DES-CBC encrypted using the context key and an IV
+   formed from the first 8 bytes of the previously calculated SGN_CKSUM
+   field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
+   sequence number is incremented by one.
+
+   The receiver of the token will first verify the SGN_CKSUM field.  If
+   valid, the sequence number field may be decrypted and compared to the
+   expected sequence number.  The repetition of the (effectively 1-bit)
+   direction indicator within the sequence number field provides
+   redundancy so that the receiver may verify that the decryption
+   succeeded.
+
+   Since the checksum computation is used as an IV to the sequence
+   number decryption, attempts to splice a checksum and sequence number
+   from different messages will be detected.  The direction indicator
+   will detect packets that have been maliciously reflected.
+
+   The sequence number provides a basis for detection of replayed
+   tokens.  Replay detection can be performed using state information
+   retained on received sequence numbers, interpreted in conjunction
+   with the security context on which they arrive.
+
+   Provision of per-message replay and out-of-sequence detection
+   services is optional for implementations of the Kerberos V5 GSS-API
+   mechanism.  Further, it is recommended that implementations of the
+   Kerberos V5 GSS-API mechanism which offer these services should honor
+   a caller's request that the services be disabled on a context.
+   Specifically, if replay_det_req_flag is input FALSE, replay_det_state
+   should be returned FALSE and the GSS_DUPLICATE_TOKEN and
+   GSS_OLD_TOKEN stati should not be indicated as a result of duplicate
+   detection when tokens are processed; if sequence_req_flag is input
+   FALSE, sequence_state should be returned FALSE and
+   GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should
+   not be indicated as a result of out-of-sequence detection when tokens
+   are processed.
+
+1.2.2. Per-message Tokens - Wrap
+
+   Use of the GSS_Wrap() call yields a token which encapsulates the
+   input user data (optionally encrypted) along with associated
+   integrity check quantities. The token emitted by GSS_Wrap() consists
+   of an integrity header whose format is identical to that emitted by
+   GSS_GetMIC() (except that the TOK_ID field contains the value 02 01),
+   followed by a body portion that contains either the plaintext data
+
+
+
+Linn                        Standards Track                     [Page 9]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   (if SEAL_ALG = ff ff) or encrypted data for any other supported value
+   of SEAL_ALG.  Currently, only SEAL_ALG = 00 00 is supported, and
+   means that DES-CBC encryption is being used to protect the data.
+
+   The GSS_Wrap() token has the following format:
+
+   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.
+                                   00 00 - DES MAC MD5
+                                   01 00 - MD2.5
+                                   02 00 - DES MAC
+    4..5           SEAL_ALG        ff ff - none
+                                   00 00 - DES
+    6..7           Filler          Contains ff ff
+    8..15          SND_SEQ         Encrypted sequence number field.
+    16..23         SGN_CKSUM       Checksum of plaintext padded data,
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+    24..last       Data            encrypted or plaintext padded data
+
+   GSS-API tokens must be encapsulated within the higher-level protocol
+   by the application; no embedded length field is necessary.
+
+1.2.2.1. Checksum
+
+   Checksum calculation procedure (common to all algorithms): Checksums
+   are calculated over the plaintext padded data field, logically
+   prepended by the first 8 bytes of the plaintext packet header.  The
+   resulting signature binds the data to the packet type, protocol
+   version, and signature algorithm identifier fields.
+
+   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
+   hash over the plaintext padded data, and then computing a DES-CBC MAC
+   on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is computed
+   per [FIPS-PUB-113], employing the context key and a zero IV. The 8-
+   byte result is stored in the SGN_CKSUM field.
+
+   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
+   16-byte zero-block, using a zero IV and a key formed by reversing the
+   bytes of the context key (i.e., if the original key is the 8-byte
+   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
+   {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
+   logically pre-pended to the "to-be-signed data".  A standard MD5
+   checksum is calculated over the combined data, and the first 8 bytes
+   of the result are stored in the SGN_CKSUM field.
+
+
+
+Linn                        Standards Track                    [Page 10]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
+   plaintext padded data per [FIPS-PUB-113], employing the context key
+   and a zero IV. The plaintext padded data is already assured to be an
+   integral multiple of 8 bytes; no additional padding is required or
+   applied in order to accomplish MAC calculation.  The result is an 8-
+   byte value, which is stored in the SGN_CKSUM field.  Support for this
+   lgorithm may not be present in all implementations.
+
+1.2.2.2. Sequence Number
+
+   Sequence number field: The 8 byte plaintext sequence number field is
+   formed from the sender's four-byte sequence number as follows.  If
+   the four bytes of the sender's sequence number are named s0, s1, s2
+   and s3 (from least to most significant), the plaintext sequence
+   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
+   di), where 'di' is the direction-indicator (Hex 0 - sender is the
+   context initiator, Hex FF - sender is the context acceptor).
+
+   The field is then DES-CBC encrypted using the context key and an IV
+   formed from the first 8 bytes of the SEAL_CKSUM field.
+
+   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
+   sequence numbers are incremented by one.
+
+1.2.2.3. Padding
+
+   Data padding: Before encryption and/or signature calculation,
+   plaintext data is padded to the next highest multiple of 8 bytes, by
+   appending between 1 and 8 bytes, the value of each such byte being
+   the total number of pad bytes.  For example, given data of length 20
+   bytes, four pad bytes will be appended, and each byte will contain
+   the hex value 04.  An 8-byte random confounder is prepended to the
+   data, and signatures are calculated over the resulting padded
+   plaintext.
+
+   After padding, the data is encrypted according to the algorithm
+   specified in the SEAL_ALG field.  For SEAL_ALG=DES (the only non-null
+   algorithm currently supported), the data is encrypted using DES-CBC,
+   with an IV of zero.  The key used is derived from the established
+   context key by XOR-ing the context key with the hexadecimal constant
+   f0f0f0f0f0f0f0f0.
+
+1.2.3. Context deletion token
+
+   The token emitted by GSS_Delete_sec_context() is based on the packet
+   format for tokens emitted by GSS_GetMIC().  The context-deletion
+   token has the following format:
+
+
+
+
+Linn                        Standards Track                    [Page 11]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   Byte no          Name           Description
+    0..1           TOK_ID          Identification field.
+                                   Tokens emitted by
+                                   GSS_Delete_sec_context() contain
+                                   the hex value 01 02 in this field.
+    2..3           SGN_ALG         Integrity algorithm indicator.
+                                   00 00 - DES MAC MD5
+                                   01 00 - MD2.5
+                                   02 00 - DES MAC
+    4..7           Filler          Contains ff ff ff ff
+    8..15          SND_SEQ         Sequence number field.
+    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
+                                   calculated according to algorithm
+                                   specified in SGN_ALG field.
+
+   SGN_ALG and SND_SEQ will be calculated as for tokens emitted by
+   GSS_GetMIC().  The SGN_CKSUM will be calculated as for tokens emitted
+   by GSS_GetMIC(), except that the user-data component of the "to-be-
+   signed" data will be a zero-length string.
+
+2. Name Types and Object Identifiers
+
+   This section discusses the name types which may be passed as input to
+   the Kerberos V5 GSS-API 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-1509.  In addition to specifying OID values for name type
+   identifiers, symbolic names are included and recommended to GSS-API
+   implementors in the interests of convenience to callers.  It is
+   understood that not all implementations of the Kerberos V5 GSS-API
+   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 V5 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 GSS-API 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
+
+
+
+Linn                        Standards Track                    [Page 12]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   portability, implementors of mechanisms are encouraged to support
+   name forms as defined in this section, even if their mechanisms are
+   independent of Kerberos V5.
+
+2.1. Mandatory Name Forms
+
+   This section discusses name forms which are to be supported by all
+   conformant implementations of the Kerberos V5 GSS-API mechanism.
+
+2.1.1. Kerberos Principal Name Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(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 V5 implementation, such
+   names are parseable with the krb5_parse_name() function.)  The
+   elements included within this name representation are as follows,
+   proceeding 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.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 13]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+        (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.
+
+2.1.2. Host-Based Service Name Form
+
+   This name form has been incorporated at the mechanism-independent
+   GSS-API level as of GSS-API, Version 2.  This subsection retains the
+   Object Identifier and symbolic name assignments previously made at
+   the Kerberos V5 GSS-API mechanism level, and adopts the definition as
+   promoted to the mechanism-independent level.
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) service_name(4)}.  The previously recommended symbolic
+   name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".  The
+   currently preferred symbolic name for this type is
+   "GSS_C_NT_HOSTBASED_SERVICE".
+
+   This name type is used to represent services associated with host
+   computers.  This name form is constructed using two elements,
+   "service" and "hostname", as follows:
+
+      service@hostname
+
+   When a reference to a name of this type is resolved, the "hostname"
+   is canonicalized by attempting a DNS lookup and using the fully-
+   qualified domain name which is returned, or by using the "hostname"
+   as provided if the DNS lookup fails.  The canonicalization operation
+   also maps the host's name into lower-case characters.
+
+   The "hostname" element may be omitted. If no "@" separator is
+   included, the entire name is interpreted as the service specifier,
+   with the "hostname" defaulted to the canonicalized name of the local
+   host.
+
+   Values for the "service" element will be registered with the IANA.
+
+2.1.3. Exported Name Object Form for Kerberos V5 Mechanism
+
+   Support for this name form is not required for GSS-V1
+   implementations, but will be required for use in conjunction with the
+   GSS_Export_name() call planned for GSS-API Version 2.  Use of this
+   name form will be signified by a "GSS-API Exported Name Object" OID
+   value which will be defined at the mechanism-independent level for
+
+
+
+Linn                        Standards Track                    [Page 14]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   GSS-API Version 2.
+
+   This name type represents a self-describing object, whose framing
+   structure will be defined at the mechanism-independent level for
+   GSS-API Version 2.  When generated by the Kerberos V5 mechanism, the
+   Mechanism OID within the exportable name shall be that of the
+   Kerberos V5 mechanism.  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
+        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).
+
+2.2. Optional Name Forms
+
+   This section discusses additional name forms which may optionally be
+   supported by implementations of the Kerberos V5 GSS-API mechanism.
+   It is recognized that some of the name forms cited here are derived
+   from UNIX(tm) operating system platforms; some listed forms may be
+   irrelevant to non-UNIX platforms, and definition of additional forms
+   corresponding to such platforms may also be appropriate.  It is also
+   recognized that OS-specific functions outside GSS-API are likely to
+   exist in order to perform translations among these forms, and that
+   GSS-API implementations supporting these forms may themselves be
+   layered atop such OS-specific functions.  Inclusion of this support
+   within GSS-API implementations is intended as a convenience to
+   applications.
+
+2.2.1. User Name Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) user_name(1)}.  The recommended symbolic name for this
+   type is "GSS_KRB5_NT_USER_NAME".
+
+   This name type is used to indicate a named user on a local system.
+
+
+
+Linn                        Standards Track                    [Page 15]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   Its interpretation is OS-specific.  This name form is constructed as:
+
+      username
+
+   Assuming that users' principal names are the same as their local
+   operating system names, an implementation of GSS_Import_name() based
+   on Kerberos V5 technology can process names of this form by
+   postfixing an "@" sign and the name of the local realm.
+
+2.2.2. Machine UID Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) machine_uid_name(2)}.  The recommended symbolic name for
+   this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
+
+   This name type is used to indicate a numeric user identifier
+   corresponding to a user on a local system.  Its interpretation is
+   OS-specific.  The gss_buffer_desc representing a name of this type
+   should contain a locally-significant uid_t, represented in host byte
+   order.  The GSS_Import_name() operation resolves this uid into a
+   username, which is then treated as the User Name Form.
+
+2.2.3. String UID Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) string_uid_name(3)}.  The recommended symbolic name for
+   this type is "GSS_KRB5_NT_STRING_UID_NAME".
+
+   This name type is used to indicate a string of digits representing
+   the numeric user identifier of a user on a local system.  Its
+   interpretation is OS-specific. This name type is similar to the
+   Machine UID Form, except that the buffer contains a string
+   representing the uid_t.
+
+3. Credentials Management
+
+   The Kerberos V5 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 V5 credentials
+   cache, sometimes known as a ticket file.
+
+
+
+
+Linn                        Standards Track                    [Page 16]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   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 V5 key table, or srvtab file.  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 V5 mechanism's credential handle may contain references
+   to either or both types of credentials.  It is a local matter how the
+   Kerberos V5 mechanism implementation finds the appropriate Kerberos
+   V5 credentials cache or key table.
+
+   However, when the Kerberos V5 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 V5 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.
+
+4. Parameter Definitions
+
+   This section defines parameter values used by the Kerberos V5 GSS-API
+   mechanism.  It defines interface elements in support of portability,
+   and assumes use of C language bindings per RFC-1509.
+
+4.1. Minor Status Codes
+
+   This section recommends common symbolic names for minor_status values
+   to be returned by the Kerberos V5 GSS-API mechanism.  Use of these
+   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 GSS-API 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.
+
+
+
+Linn                        Standards Track                    [Page 17]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+4.1.1. Non-Kerberos-specific codes
+
+   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" */
+
+4.1.2. Kerberos-specific-codes
+
+   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" */
+
+4.2. Quality of Protection Values
+
+   This section defines Quality of Protection (QOP) values to be used
+   with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and
+   GSS_GetMIC() routines in order to select among alternate integrity
+   and confidentiality algorithms. Additional QOP values may be added in
+   future versions of this specification.  Non-overlapping bit positions
+   are and will be employed in order that both integrity and
+
+
+
+Linn                        Standards Track                    [Page 18]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+   confidentiality QOP may be selected within a single parameter, via
+   inclusive-OR of the specified integrity and confidentiality values.
+
+4.2.1. Integrity Algorithms
+
+   The following Quality of Protection (QOP) values are currently
+   defined for the Kerberos V5 GSS-API mechanism, and are used to select
+   among alternate integrity checking algorithms.
+
+   GSS_KRB5_INTEG_C_QOP_MD5        (numeric value: 1)
+           /* Integrity using partial MD5 ("MD2.5") of plaintext */
+
+   GSS_KRB5_INTEG_C_QOP_DES_MD5    (numeric value: 2)
+           /* Integrity using DES MAC of MD5 of plaintext */
+
+   GSS_KRB5_INTEG_C_QOP_DES_MAC    (numeric value: 3)
+           /* Integrity using DES MAC of plaintext */
+
+4.2.2. Confidentiality Algorithms
+
+   Only one confidentiality QOP value is currently defined for the
+   Kerberos V5 GSS-API mechanism:
+
+   GSS_KRB5_CONF_C_QOP_DES         (numeric value: 0)
+           /* Confidentiality with DES */
+
+   Note: confidentiality QOP should be indicated only by GSS-API calls
+   capable of providing confidentiality services. If non-zero
+   confidentiality QOP values are defined in future to represent
+   different algorithms, therefore, the bit positions containing those
+   values should be cleared before being returned by implementations of
+   GSS_GetMIC() and GSS_VerifyMIC().
+
+4.3. Buffer Sizes
+
+   All implementations of this specification shall be capable of
+   accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(),
+   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
+   the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer
+   as input to GSS_Unwrap(). Support for larger buffer sizes is optional
+   but recommended.
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 19]
+
+RFC 1964               Kerberos Version 5 GSS-API              June 1996
+
+
+5. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+6. References
+
+
+   [RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+   1321, April 1992.
+
+   [RFC-1508]: Linn, J., "Generic Security Service Application Program
+   Interface", RFC 1508, September 1993.
+
+   [RFC-1509]: Wray, J., "Generic Security Service Application Program
+   Interface: C-bindings", RFC 1509, September 1993.
+
+   [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network
+   Authentication Service (V5)", RFC 1510, September 1993.
+
+   [FIPS-PUB-113]: National Bureau of Standards, Federal Information
+   Processing Standard 113, "Computer Data Authentication", May 1985.
+
+AUTHOR'S ADDRESS
+
+   John Linn
+   OpenVision Technologies
+   One Main St.
+   Cambridge, MA  02142  USA
+
+   Phone: +1 617.374.2245
+   EMail: John.Linn@ov.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 20]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2078.txt b/third_party/heimdal/doc/standardisation/rfc2078.txt
new file mode 100644
index 00000000000..1dd1e4aebd2
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2078.txt
@@ -0,0 +1,4763 @@
+
+
+
+
+
+
+Network Working Group                                           J. Linn
+Request for Comments: 2078                      OpenVision Technologies
+Category: Standards Track                                  January 1997
+Obsoletes: 1508
+
+
+   Generic Security Service Application Program Interface, Version 2
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Generic Security Service Application Program Interface (GSS-API),
+   as defined in RFC-1508, provides security services to callers in a
+   generic fashion, supportable with a range of underlying mechanisms
+   and technologies and hence allowing source-level portability of
+   applications to different environments. This specification defines
+   GSS-API services and primitives at a level independent of underlying
+   mechanism and programming language environment, and is to be
+   complemented by other, related specifications:
+
+      documents defining specific parameter bindings for particular
+      language environments
+
+      documents defining token formats, protocols, and procedures to be
+      implemented in order to realize GSS-API services atop particular
+      security mechanisms
+
+   This memo revises RFC-1508, making specific, incremental changes in
+   response to implementation experience and liaison requests. It is
+   intended, therefore, that this memo or a successor version thereto
+   will become the basis for subsequent progression of the GSS-API
+   specification on the standards track.
+
+Table of Contents
+
+   1: GSS-API Characteristics and Concepts..........................  3
+   1.1: GSS-API Constructs..........................................  6
+   1.1.1:  Credentials..............................................  6
+   1.1.1.1: Credential Constructs and Concepts......................  6
+   1.1.1.2: Credential Management...................................  7
+   1.1.1.3: Default Credential Resolution...........................  8
+
+
+
+Linn                        Standards Track                     [Page 1]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   1.1.2: Tokens....................................................  9
+   1.1.3:  Security Contexts........................................ 10
+   1.1.4:  Mechanism Types.......................................... 11
+   1.1.5:  Naming................................................... 12
+   1.1.6:  Channel Bindings......................................... 14
+   1.2:  GSS-API Features and Issues................................ 15
+   1.2.1:  Status Reporting......................................... 15
+   1.2.2: Per-Message Security Service Availability................. 17
+   1.2.3: Per-Message Replay Detection and Sequencing............... 18
+   1.2.4:  Quality of Protection.................................... 20
+   1.2.5: Anonymity Support......................................... 21
+   1.2.6: Initialization............................................ 22
+   1.2.7: Per-Message Protection During Context Establishment....... 22
+   1.2.8: Implementation Robustness................................. 23
+   2:  Interface Descriptions....................................... 23
+   2.1:  Credential management calls................................ 25
+   2.1.1:  GSS_Acquire_cred call.................................... 26
+   2.1.2:  GSS_Release_cred call.................................... 28
+   2.1.3:  GSS_Inquire_cred call.................................... 29
+   2.1.4:  GSS_Add_cred call........................................ 31
+   2.1.5:  GSS_Inquire_cred_by_mech call............................ 33
+   2.2:  Context-level calls........................................ 34
+   2.2.1:  GSS_Init_sec_context call................................ 34
+   2.2.2:  GSS_Accept_sec_context call.............................. 40
+   2.2.3:  GSS_Delete_sec_context call.............................. 44
+   2.2.4:  GSS_Process_context_token call........................... 46
+   2.2.5:  GSS_Context_time call.................................... 47
+   2.2.6:  GSS_Inquire_context call................................. 47
+   2.2.7:  GSS_Wrap_size_limit call................................. 49
+   2.2.8:  GSS_Export_sec_context call.............................. 50
+   2.2.9:  GSS_Import_sec_context call.............................. 52
+   2.3:  Per-message calls.......................................... 53
+   2.3.1:  GSS_GetMIC call.......................................... 54
+   2.3.2:  GSS_VerifyMIC call....................................... 55
+   2.3.3:  GSS_Wrap call............................................ 56
+   2.3.4:  GSS_Unwrap call.......................................... 58
+   2.4:  Support calls.............................................. 59
+   2.4.1:  GSS_Display_status call.................................. 60
+   2.4.2:  GSS_Indicate_mechs call.................................. 60
+   2.4.3:  GSS_Compare_name call.................................... 61
+   2.4.4:  GSS_Display_name call.................................... 62
+   2.4.5:  GSS_Import_name call..................................... 63
+   2.4.6:  GSS_Release_name call.................................... 64
+   2.4.7:  GSS_Release_buffer call.................................. 65
+   2.4.8:  GSS_Release_OID_set call................................. 65
+   2.4.9:  GSS_Create_empty_OID_set call............................ 66
+   2.4.10: GSS_Add_OID_set_member call.............................. 67
+   2.4.11: GSS_Test_OID_set_member call............................. 67
+
+
+
+Linn                        Standards Track                     [Page 2]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   2.4.12: GSS_Release_OID call..................................... 68
+   2.4.13: GSS_OID_to_str call...................................... 68
+   2.4.14: GSS_Str_to_OID call...................................... 69
+   2.4.15: GSS_Inquire_names_for_mech call.......................... 69
+   2.4.16: GSS_Inquire_mechs_for_name call.......................... 70
+   2.4.17: GSS_Canonicalize_name call............................... 71
+   2.4.18: GSS_Export_name call..................................... 72
+   2.4.19: GSS_Duplicate_name call.................................. 73
+   3: Data Structure Definitions for GSS-V2 Usage................... 73
+   3.1: Mechanism-Independent Token Format.......................... 74
+   3.2: Mechanism-Independent Exported Name Object Format........... 77
+   4: Name Type Definitions......................................... 77
+   4.1: Host-Based Service Name Form................................ 77
+   4.2: User Name Form.............................................. 78
+   4.3: Machine UID Form............................................ 78
+   4.4: String UID Form............................................. 79
+   5:  Mechanism-Specific Example Scenarios......................... 79
+   5.1: Kerberos V5, single-TGT..................................... 79
+   5.2: Kerberos V5, double-TGT..................................... 80
+   5.3:  X.509 Authentication Framework............................. 81
+   6:  Security Considerations...................................... 82
+   7:  Related Activities........................................... 82
+   Appendix A: Mechanism Design Constraints......................... 83
+   Appendix B: Compatibility with GSS-V1............................ 83
+
+1: GSS-API Characteristics and Concepts
+
+   GSS-API operates in the following paradigm.  A typical GSS-API caller
+   is itself a communications protocol, calling on GSS-API in order to
+   protect its communications with authentication, integrity, and/or
+   confidentiality security services.  A GSS-API caller accepts tokens
+   provided to it by its local GSS-API implementation and transfers the
+   tokens to a peer on a remote system; that peer passes the received
+   tokens to its local GSS-API implementation for processing. The
+   security services available through GSS-API in this fashion are
+   implementable (and have been implemented) over a range of underlying
+   mechanisms based on secret-key and public-key cryptographic
+   technologies.
+
+   The GSS-API separates the operations of initializing a security
+   context between peers, achieving peer entity authentication (This
+   security service definition, and other definitions used in this
+   document, corresponds to that provided in International Standard ISO
+   7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context()  and
+   GSS_Accept_sec_context() calls), from the operations of providing
+   per-message data origin authentication and data integrity protection
+   (GSS_GetMIC()  and GSS_VerifyMIC()  calls) for messages subsequently
+   transferred in conjunction with that context.  When establishing a
+
+
+
+Linn                        Standards Track                     [Page 3]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   security context, the GSS-API enables a context initiator to
+   optionally permit its credentials to be delegated, meaning that the
+   context acceptor may initiate further security contexts on behalf of
+   the initiating caller. Per-message GSS_Wrap()  and GSS_Unwrap() calls
+   provide the data origin authentication and data integrity services
+   which GSS_GetMIC()  and GSS_VerifyMIC() offer, and also support
+   selection of confidentiality services as a caller option.  Additional
+   calls provide supportive functions to the GSS-API's users.
+
+   The following paragraphs provide an example illustrating the
+   dataflows involved in use of the GSS-API by a client and server in a
+   mechanism-independent fashion, establishing a security context and
+   transferring a protected message. The example assumes that credential
+   acquisition has already been completed.  The example assumes that the
+   underlying authentication technology is capable of authenticating a
+   client to a server using elements carried within a single token, and
+   of authenticating the server to the client (mutual authentication)
+   with a single returned token; this assumption holds for presently-
+   documented CAT mechanisms but is not necessarily true for other
+   cryptographic technologies and associated protocols.
+
+   The client calls GSS_Init_sec_context()  to establish a security
+   context to the server identified by targ_name, and elects to set the
+   mutual_req_flag so that mutual authentication is performed in the
+   course of context establishment. GSS_Init_sec_context()  returns an
+   output_token to be passed to the server, and indicates
+   GSS_S_CONTINUE_NEEDED status pending completion of the mutual
+   authentication sequence. Had mutual_req_flag not been set, the
+   initial call to GSS_Init_sec_context()  would have returned
+   GSS_S_COMPLETE status. The client sends the output_token to the
+   server.
+
+   The server passes the received token as the input_token parameter to
+   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
+   GSS_S_COMPLETE status, provides the client's authenticated identity
+   in the src_name result, and provides an output_token to be passed to
+   the client. The server sends the output_token to the client.
+
+   The client passes the received token as the input_token parameter to
+   a successor call to GSS_Init_sec_context(),  which processes data
+   included in the token in order to achieve mutual authentication from
+   the client's viewpoint. This call to GSS_Init_sec_context()  returns
+   GSS_S_COMPLETE status, indicating successful mutual authentication
+   and the completion of context establishment for this example.
+
+   The client generates a data message and passes it to GSS_Wrap().
+   GSS_Wrap() performs data origin authentication, data integrity, and
+   (optionally) confidentiality processing on the message and
+
+
+
+Linn                        Standards Track                     [Page 4]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   encapsulates the result into output_message, indicating
+   GSS_S_COMPLETE status. The client sends the output_message to the
+   server.
+
+   The server passes the received message to GSS_Unwrap().  GSS_Unwrap()
+   inverts the encapsulation performed by GSS_Wrap(),  deciphers the
+   message if the optional confidentiality feature was applied, and
+   validates the data origin authentication and data integrity checking
+   quantities. GSS_Unwrap()  indicates successful validation by
+   returning GSS_S_COMPLETE status along with the resultant
+   output_message.
+
+   For purposes of this example, we assume that the server knows by
+   out-of-band means that this context will have no further use after
+   one protected message is transferred from client to server. Given
+   this premise, the server now calls GSS_Delete_sec_context() to flush
+   context-level information.  Optionally, the server-side application
+   may provide a token buffer to GSS_Delete_sec_context(), to receive a
+   context_token to be transferred to the client in order to request
+   that client-side context-level information be deleted.
+
+   If a context_token is transferred, the client passes the
+   context_token to GSS_Process_context_token(), which returns
+   GSS_S_COMPLETE status after deleting context-level information at the
+   client system.
+
+   The GSS-API design assumes and addresses several basic goals,
+   including:
+
+      Mechanism independence: The GSS-API defines an interface to
+      cryptographically implemented strong authentication and other
+      security services at a generic level which is independent of
+      particular underlying mechanisms. For example, GSS-API-provided
+      services can be implemented by secret-key technologies (e.g.,
+      Kerberos) or public-key approaches (e.g., X.509).
+
+      Protocol environment independence: The GSS-API is independent of
+      the communications protocol suites with which it is employed,
+      permitting use in a broad range of protocol environments. In
+      appropriate environments, an intermediate implementation "veneer"
+      which is oriented to a particular communication protocol (e.g.,
+      Remote Procedure Call (RPC)) may be interposed between
+      applications which call that protocol and the GSS-API, thereby
+      invoking GSS-API facilities in conjunction with that protocol's
+      communications invocations.
+
+      Protocol association independence: The GSS-API's security context
+      construct is independent of communications protocol association
+
+
+
+Linn                        Standards Track                     [Page 5]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      constructs. This characteristic allows a single GSS-API
+      implementation to be utilized by a variety of invoking protocol
+      modules on behalf of those modules' calling applications. GSS-API
+      services can also be invoked directly by applications, wholly
+      independent of protocol associations.
+
+      Suitability to a range of implementation placements: GSS-API
+      clients are not constrained to reside within any Trusted Computing
+      Base (TCB) perimeter defined on a system where the GSS-API is
+      implemented; security services are specified in a manner suitable
+      to both intra-TCB and extra-TCB callers.
+
+1.1: GSS-API Constructs
+
+   This section describes the basic elements comprising the GSS-API.
+
+1.1.1:  Credentials
+
+1.1.1.1: Credential Constructs and Concepts
+
+   Credentials provide the prerequisites which permit GSS-API peers to
+   establish security contexts with each other. A caller may designate
+   that the credential elements which are to be applied for context
+   initiation or acceptance be selected by default.  Alternately, those
+   GSS-API callers which need to make explicit selection of particular
+   credentials structures may make references to those credentials
+   through GSS-API-provided credential handles ("cred_handles").  In all
+   cases, callers' credential references are indirect, mediated by GSS-
+   API implementations and not requiring callers to access the selected
+   credential elements.
+
+   A single credential structure may be used to initiate outbound
+   contexts and to accept inbound contexts. Callers needing to operate
+   in only one of these modes may designate this fact when credentials
+   are acquired for use, allowing underlying mechanisms to optimize
+   their processing and storage requirements. The credential elements
+   defined by a particular mechanism may contain multiple cryptographic
+   keys, e.g., to enable authentication and message encryption to be
+   performed with different algorithms.
+
+   A GSS-API credential structure may contain multiple credential
+   elements, each containing mechanism-specific information for a
+   particular underlying mechanism (mech_type), but the set of elements
+   within a given credential structure represent a common entity.  A
+   credential structure's contents will vary depending on the set of
+   mech_types supported by a particular GSS-API implementation. Each
+   credential element identifies the data needed by its mechanism in
+   order to establish contexts on behalf of a particular principal, and
+
+
+
+Linn                        Standards Track                     [Page 6]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   may contain separate credential references for use in context
+   initiation and context acceptance.  Multiple credential elements
+   within a given credential having overlapping combinations of
+   mechanism, usage mode, and validity period are not permitted.
+
+   Commonly, a single mech_type will be used for all security contexts
+   established by a particular initiator to a particular target. A major
+   motivation for supporting credential sets representing multiple
+   mech_types is to allow initiators on systems which are equipped to
+   handle multiple types to initiate contexts to targets on other
+   systems which can accommodate only a subset of the set supported at
+   the initiator's system.
+
+1.1.1.2: Credential Management
+
+   It is the responsibility of underlying system-specific mechanisms and
+   OS functions below the GSS-API to ensure that the ability to acquire
+   and use credentials associated with a given identity is constrained
+   to appropriate processes within a system. This responsibility should
+   be taken seriously by implementors, as the ability for an entity to
+   utilize a principal's credentials is equivalent to the entity's
+   ability to successfully assert that principal's identity.
+
+   Once a set of GSS-API credentials is established, the transferability
+   of that credentials set to other processes or analogous constructs
+   within a system is a local matter, not defined by the GSS-API. An
+   example local policy would be one in which any credentials received
+   as a result of login to a given user account, or of delegation of
+   rights to that account, are accessible by, or transferable to,
+   processes running under that account.
+
+   The credential establishment process (particularly when performed on
+   behalf of users rather than server processes) is likely to require
+   access to passwords or other quantities which should be protected
+   locally and exposed for the shortest time possible. As a result, it
+   will often be appropriate for preliminary credential establishment to
+   be performed through local means at user login time, with the
+   result(s) cached for subsequent reference. These preliminary
+   credentials would be set aside (in a system-specific fashion) for
+   subsequent use, either:
+
+      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
+      call, returning an explicit handle to reference that credential
+
+      to comprise default credential elements to be installed, and to be
+      used when default credential behavior is requested on behalf of a
+      process
+
+
+
+
+Linn                        Standards Track                     [Page 7]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+1.1.1.3: Default Credential Resolution
+
+   The gss_init_sec_context and gss_accept_sec_context routines allow
+   the value GSS_C_NO_CREDENTIAL to be specified as their credential
+   handle parameter.  This special credential-handle indicates a desire
+   by the application to act as a default principal.  While individual
+   GSS-API implementations are free to determine such default behavior
+   as appropriate to the mechanism, the following default behavior by
+   these routines is recommended for portability:
+
+   GSS_Init_sec_context:
+
+      (i) If there is only a single principal capable of initiating
+      security contexts that the application is authorized to act on
+      behalf of, then that principal shall be used, otherwise
+
+      (ii) If the platform maintains a concept of a default network-
+      identity, and if the application is authorized to act on behalf of
+      that identity for the purpose of initiating security contexts,
+      then the principal corresponding to that identity shall be used,
+      otherwise
+
+      (iii) If the platform maintains a concept of a default local
+      identity, and provides a means to map local identities into
+      network-identities, and if the application is authorized to act on
+      behalf of the network-identity image of the default local identity
+      for the purpose of initiating security contexts, then the
+      principal corresponding to that identity shall be used, otherwise
+
+      (iv) A user-configurable default identity should be used.
+
+   GSS_Accept_sec_context:
+
+      (i) If there is only a single authorized principal identity
+      capable of accepting security contexts, then that principal shall
+      be used, otherwise
+
+      (ii) If the mechanism can determine the identity of the target
+      principal by examining the context-establishment token, and if the
+      accepting application is authorized to act as that principal for
+      the purpose of accepting security contexts, then that principal
+      identity shall be used, otherwise
+
+      (iii) If the mechanism supports context acceptance by any
+      principal, and mutual authentication was not requested, any
+      principal that the application is authorized to accept security
+      contexts under may be used, otherwise
+
+
+
+
+Linn                        Standards Track                     [Page 8]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      (iv) A user-configurable default identity shall be used.
+
+   The purpose of the above rules is to allow security contexts to be
+   established by both initiator and acceptor using the default behavior
+   wherever possible.  Applications requesting default behavior are
+   likely to be more portable across mechanisms and platforms than ones
+   that use GSS_Acquire_cred to request a specific identity.
+
+1.1.2: Tokens
+
+   Tokens are data elements transferred between GSS-API callers, and are
+   divided into two classes. Context-level tokens are exchanged in order
+   to establish and manage a security context between peers. Per-message
+   tokens relate to an established context and are exchanged to provide
+   protective security services (i.e., data origin authentication,
+   integrity, and optional confidentiality) for corresponding data
+   messages.
+
+   The first context-level token obtained from GSS_Init_sec_context() is
+   required to indicate at its very beginning a globally-interpretable
+   mechanism identifier, i.e., an Object Identifier (OID) of the
+   security mechanism. The remaining part of this token as well as the
+   whole content of all other tokens are specific to the particular
+   underlying mechanism used to support the GSS-API. Section 3 of this
+   document provides, for designers of GSS-API support mechanisms, the
+   description of the header of the first context-level token which is
+   then followed by mechanism-specific information.
+
+   Tokens' contents are opaque from the viewpoint of GSS-API callers.
+   They are generated within the GSS-API implementation at an end
+   system, provided to a GSS-API caller to be transferred to the peer
+   GSS-API caller at a remote end system, and processed by the GSS-API
+   implementation at that remote end system. Tokens may be output by
+   GSS-API calls (and should be transferred to GSS-API peers) whether or
+   not the calls' status indicators indicate successful completion.
+   Token transfer may take place in an in-band manner, integrated into
+   the same protocol stream used by the GSS-API callers for other data
+   transfers, or in an out-of-band manner across a logically separate
+   channel.
+
+   Different GSS-API tokens are used for different purposes (e.g.,
+   context initiation, context acceptance, protected message data on an
+   established context), and it is the responsibility of a GSS-API
+   caller receiving tokens to distinguish their types, associate them
+   with corresponding security contexts, and pass them to appropriate
+   GSS-API processing routines.  Depending on the caller protocol
+   environment, this distinction may be accomplished in several ways.
+
+
+
+
+Linn                        Standards Track                     [Page 9]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   The following examples illustrate means through which tokens' types
+   may be distinguished:
+
+      - implicit tagging based on state information (e.g., all tokens on
+      a new association are considered to be context establishment
+      tokens until context establishment is completed, at which point
+      all tokens are considered to be wrapped data objects for that
+      context),
+
+      - explicit tagging at the caller protocol level,
+
+      - a hybrid of these approaches.
+
+   Commonly, the encapsulated data within a token includes internal
+   mechanism-specific tagging information, enabling mechanism-level
+   processing modules to distinguish tokens used within the mechanism
+   for different purposes.  Such internal mechanism-level tagging is
+   recommended to mechanism designers, and enables mechanisms to
+   determine whether a caller has passed a particular token for
+   processing by an inappropriate GSS-API routine.
+
+   Development of GSS-API support primitives based on a particular
+   underlying cryptographic technique and protocol (i.e., conformant to
+   a specific GSS-API mechanism definition) does not necessarily imply
+   that GSS-API callers using that GSS-API mechanism will be able to
+   interoperate with peers invoking the same technique and protocol
+   outside the GSS-API paradigm, or with peers implementing a different
+   GSS-API mechanism based on the same underlying technology.  The
+   format of GSS-API tokens defined in conjunction with a particular
+   mechanism, and the techniques used to integrate those tokens into
+   callers' protocols, may not be interoperable with the tokens used by
+   non-GSS-API callers of the same underlying technique.
+
+1.1.3:  Security Contexts
+
+   Security contexts are established between peers, using credentials
+   established locally in conjunction with each peer or received by
+   peers via delegation. Multiple contexts may exist simultaneously
+   between a pair of peers, using the same or different sets of
+   credentials. Coexistence of multiple contexts using different
+   credentials allows graceful rollover when credentials expire.
+   Distinction among multiple contexts based on the same credentials
+   serves applications by distinguishing different message streams in a
+   security sense.
+
+   The GSS-API is independent of underlying protocols and addressing
+   structure, and depends on its callers to transport GSS-API-provided
+   data elements. As a result of these factors, it is a caller
+
+
+
+Linn                        Standards Track                    [Page 10]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   responsibility to parse communicated messages, separating GSS-API-
+   related data elements from caller-provided data.  The GSS-API is
+   independent of connection vs. connectionless orientation of the
+   underlying communications service.
+
+   No correlation between security context and communications protocol
+   association is dictated. (The optional channel binding facility,
+   discussed in Section 1.1.6 of this document, represents an
+   intentional exception to this rule, supporting additional protection
+   features within GSS-API supporting mechanisms.) This separation
+   allows the GSS-API to be used in a wide range of communications
+   environments, and also simplifies the calling sequences of the
+   individual calls. In many cases (depending on underlying security
+   protocol, associated mechanism, and availability of cached
+   information), the state information required for context setup can be
+   sent concurrently with initial signed user data, without interposing
+   additional message exchanges.
+
+1.1.4:  Mechanism Types
+
+   In order to successfully establish a security context with a target
+   peer, it is necessary to identify an appropriate underlying mechanism
+   type (mech_type) which both initiator and target peers support. The
+   definition of a mechanism embodies not only the use of a particular
+   cryptographic technology (or a hybrid or choice among alternative
+   cryptographic technologies), but also definition of the syntax and
+   semantics of data element exchanges which that mechanism will employ
+   in order to support security services.
+
+   It is recommended that callers initiating contexts specify the
+   "default" mech_type value, allowing system-specific functions within
+   or invoked by the GSS-API implementation to select the appropriate
+   mech_type, but callers may direct that a particular mech_type be
+   employed when necessary.
+
+   The means for identifying a shared mech_type to establish a security
+   context with a peer will vary in different environments and
+   circumstances; examples include (but are not limited to):
+
+      use of a fixed mech_type, defined by configuration, within an
+      environment
+
+      syntactic convention on a target-specific basis, through
+      examination of a target's name
+
+      lookup of a target's name in a naming service or other database in
+      order to identify mech_types supported by that target
+
+
+
+
+Linn                        Standards Track                    [Page 11]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      explicit negotiation between GSS-API callers in advance of
+      security context setup
+
+   When transferred between GSS-API peers, mech_type specifiers (per
+   Section 3, represented as Object Identifiers (OIDs)) serve to qualify
+   the interpretation of associated tokens. (The structure and encoding
+   of Object Identifiers is defined in ISO/IEC 8824, "Specification of
+   Abstract Syntax Notation One (ASN.1)" and in ISO/IEC 8825,
+   "Specification of Basic Encoding Rules for Abstract Syntax Notation
+   One (ASN.1)".) Use of hierarchically structured OIDs serves to
+   preclude ambiguous interpretation of mech_type specifiers. The OID
+   representing the DASS MechType, for example, is 1.3.12.2.1011.7.5,
+   and that of the Kerberos V5 mechanism, once advanced to the level of
+   Proposed Standard, will be 1.2.840.113554.1.2.2.
+
+1.1.5:  Naming
+
+   The GSS-API avoids prescribing naming structures, treating the names
+   which are transferred across the interface in order to initiate and
+   accept security contexts as opaque objects.  This approach supports
+   the GSS-API's goal of implementability atop a range of underlying
+   security mechanisms, recognizing the fact that different mechanisms
+   process and authenticate names which are presented in different
+   forms. Generalized services offering translation functions among
+   arbitrary sets of naming environments are outside the scope of the
+   GSS-API; availability and use of local conversion functions to
+   translate among the naming formats supported within a given end
+   system is anticipated.
+
+   Different classes of name representations are used in conjunction
+   with different GSS-API parameters:
+
+      - Internal form (denoted in this document by INTERNAL NAME),
+      opaque to callers and defined by individual GSS-API
+      implementations.  GSS-API implementations supporting multiple
+      namespace types must maintain internal tags to disambiguate the
+      interpretation of particular names.  A Mechanism Name (MN) is a
+      special case of INTERNAL NAME, guaranteed to contain elements
+      corresponding to one and only one mechanism; calls which are
+      guaranteed to emit MNs or which require MNs as input are so
+      identified within this specification.
+
+      - Contiguous string ("flat") form (denoted in this document by
+      OCTET STRING); accompanied by OID tags identifying the namespace
+      to which they correspond.  Depending on tag value, flat names may
+      or may not be printable strings for direct acceptance from and
+      presentation to users. Tagging of flat names allows GSS-API
+      callers and underlying GSS-API mechanisms to disambiguate name
+
+
+
+Linn                        Standards Track                    [Page 12]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      types and to determine whether an associated name's type is one
+      which they are capable of processing, avoiding aliasing problems
+      which could result from misinterpreting a name of one type as a
+      name of another type.
+
+      - The GSS-API Exported Name Object, a special case of flat name
+      designated by a reserved OID value, carries a canonicalized form
+      of a name suitable for binary comparisons.
+
+   In addition to providing means for names to be tagged with types,
+   this specification defines primitives to support a level of naming
+   environment independence for certain calling applications. To provide
+   basic services oriented towards the requirements of callers which
+   need not themselves interpret the internal syntax and semantics of
+   names, GSS-API calls for name comparison (GSS_Compare_name()),
+   human-readable display (GSS_Display_name()), input conversion
+   (GSS_Import_name()), internal name deallocation (GSS_Release_name()),
+   and internal name duplication (GSS_Duplicate_name()) functions are
+   defined. (It is anticipated that these proposed GSS-API calls will be
+   implemented in many end systems based on system-specific name
+   manipulation primitives already extant within those end systems;
+   inclusion within the GSS-API is intended to offer GSS-API callers a
+   portable means to perform specific operations, supportive of
+   authorization and audit requirements, on authenticated names.)
+
+   GSS_Import_name() implementations can, where appropriate, support
+   more than one printable syntax corresponding to a given namespace
+   (e.g., alternative printable representations for X.500 Distinguished
+   Names), allowing flexibility for their callers to select among
+   alternative representations. GSS_Display_name() implementations
+   output a printable syntax selected as appropriate to their
+   operational environments; this selection is a local matter. Callers
+   desiring portability across alternative printable syntaxes should
+   refrain from implementing comparisons based on printable name forms
+   and should instead use the GSS_Compare_name()  call to determine
+   whether or not one internal-format name matches another.
+
+   The GSS_Canonicalize_name() and GSS_Export_name() calls enable
+   callers to acquire and process Exported Name Objects, canonicalized
+   and translated in accordance with the procedures of a particular
+   GSS-API mechanism.  Exported Name Objects can, in turn, be input to
+   GSS_Import_name(), yielding equivalent MNs. These facilities are
+   designed specifically to enable efficient storage and comparison of
+   names (e.g., for use in access control lists).
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 13]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   The following diagram illustrates the intended dataflow among name-
+   related GSS-API processing routines.
+
+                        GSS-API library defaults
+                               |
+                               |
+                               V                         text, for
+   text -------------->  internal_name (IN) -----------> display only
+         import_name()          /          display_name()
+                               /
+                              /
+                             /
+    accept_sec_context()    /
+          |                /
+          |               /
+          |              /  canonicalize_name()
+          |             /
+          |            /
+          |           /
+          |          /
+          |         /
+          |        |
+          V        V     <---------------------
+    single mechanism        import_name()         exported name: flat
+    internal_name (MN)                            binary "blob" usable
+                         ---------------------->  for access control
+                            export_name()
+
+1.1.6:  Channel Bindings
+
+   The GSS-API accommodates the concept of caller-provided channel
+   binding ("chan_binding") information.  Channel bindings are used to
+   strengthen the quality with which peer entity authentication is
+   provided during context establishment, by limiting the scope within
+   which an intercepted context establishment token can be reused by an
+   attacker. Specifically, they enable GSS-API callers to bind the
+   establishment of a security context to relevant characteristics
+   (e.g., addresses, transformed representations of encryption keys) of
+   the underlying communications channel, of protection mechanisms
+   applied to that communications channel, and to application-specific
+   data.
+
+   The caller initiating a security context must determine the
+   appropriate channel binding values to provide as input to the
+   GSS_Init_sec_context() call, and consistent values must be provided
+   to GSS_Accept_sec_context() by the context's target, in order for
+   both peers' GSS-API mechanisms to validate that received tokens
+   possess correct channel-related characteristics. Use or non-use of
+
+
+
+Linn                        Standards Track                    [Page 14]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   the GSS-API channel binding facility is a caller option.  GSS-API
+   mechanisms can operate in an environment where NULL channel bindings
+   are presented; mechanism implementors are encouraged, but not
+   required, to make use of caller-provided channel binding data within
+   their mechanisms. Callers should not assume that underlying
+   mechanisms provide confidentiality protection for channel binding
+   information.
+
+   When non-NULL channel bindings are provided by callers, certain
+   mechanisms can offer enhanced security value by interpreting the
+   bindings' content (rather than simply representing those bindings, or
+   integrity check values computed on them, within tokens) and will
+   therefore depend on presentation of specific data in a defined
+   format. To this end, agreements among mechanism implementors are
+   defining conventional interpretations for the contents of channel
+   binding arguments, including address specifiers (with content
+   dependent on communications protocol environment) for context
+   initiators and acceptors. (These conventions are being incorporated
+   in GSS-API mechanism specifications and into the GSS-API C language
+   bindings specification.) In order for GSS-API callers to be portable
+   across multiple mechanisms and achieve the full security
+   functionality which each mechanism can provide, it is strongly
+   recommended that GSS-API callers provide channel bindings consistent
+   with these conventions and those of the networking environment in
+   which they operate.
+
+1.2:  GSS-API Features and Issues
+
+   This section describes aspects of GSS-API operations, of the security
+   services which the GSS-API provides, and provides commentary on
+   design issues.
+
+1.2.1:  Status Reporting
+
+   Each GSS-API call provides two status return values. Major_status
+   values provide a mechanism-independent indication of call status
+   (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED),
+   sufficient to drive normal control flow within the caller in a
+   generic fashion. Table 1 summarizes the defined major_status return
+   codes in tabular fashion.
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 15]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+Table 1: GSS-API Major Status Codes
+
+   FATAL ERROR CODES
+
+   GSS_S_BAD_BINDINGS            channel binding mismatch
+   GSS_S_BAD_MECH                unsupported mechanism requested
+   GSS_S_BAD_NAME                invalid name provided
+   GSS_S_BAD_NAMETYPE            name of unsupported type provided
+   GSS_S_BAD_STATUS              invalid input status selector
+   GSS_S_BAD_SIG                 token had invalid integrity check
+   GSS_S_CONTEXT_EXPIRED         specified security context expired
+   GSS_S_CREDENTIALS_EXPIRED     expired credentials detected
+   GSS_S_DEFECTIVE_CREDENTIAL    defective credential detected
+   GSS_S_DEFECTIVE_TOKEN         defective token detected
+   GSS_S_FAILURE                 failure, unspecified at GSS-API
+                                   level
+   GSS_S_NO_CONTEXT              no valid security context specified
+   GSS_S_NO_CRED                 no valid credentials provided
+   GSS_S_BAD_QOP                 unsupported QOP value
+   GSS_S_UNAUTHORIZED            operation unauthorized
+   GSS_S_UNAVAILABLE             operation unavailable
+   GSS_S_DUPLICATE_ELEMENT       duplicate credential element requested
+   GSS_S_NAME_NOT_MN             name contains multi-mechanism elements
+
+   INFORMATORY STATUS CODES
+
+   GSS_S_COMPLETE                normal completion
+   GSS_S_CONTINUE_NEEDED         continuation call to routine
+                                  required
+   GSS_S_DUPLICATE_TOKEN         duplicate per-message token
+                                  detected
+   GSS_S_OLD_TOKEN               timed-out per-message token
+                                  detected
+   GSS_S_UNSEQ_TOKEN             reordered (early) per-message token
+                                  detected
+   GSS_S_GAP_TOKEN               skipped predecessor token(s)
+                                  detected
+
+   Minor_status provides more detailed status information which may
+   include status codes specific to the underlying security mechanism.
+   Minor_status values are not specified in this document.
+
+   GSS_S_CONTINUE_NEEDED major_status returns, and optional message
+   outputs, are provided in GSS_Init_sec_context() and
+   GSS_Accept_sec_context()  calls so that different mechanisms'
+   employment of different numbers of messages within their
+   authentication sequences need not be reflected in separate code paths
+   within calling applications. Instead, such cases are accommodated
+
+
+
+Linn                        Standards Track                    [Page 16]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   with sequences of continuation calls to GSS_Init_sec_context()  and
+   GSS_Accept_sec_context().  The same mechanism is used to encapsulate
+   mutual authentication within the GSS-API's context initiation calls.
+
+   For mech_types which require interactions with third-party servers in
+   order to establish a security context, GSS-API context establishment
+   calls may block pending completion of such third-party interactions.
+
+   On the other hand, no GSS-API calls pend on serialized interactions
+   with GSS-API peer entities.  As a result, local GSS-API status
+   returns cannot reflect unpredictable or asynchronous exceptions
+   occurring at remote peers, and reflection of such status information
+   is a caller responsibility outside the GSS-API.
+
+1.2.2: Per-Message Security Service Availability
+
+   When a context is established, two flags are returned to indicate the
+   set of per-message protection security services which will be
+   available on the context:
+
+      the integ_avail flag indicates whether per-message integrity and
+      data origin authentication services are available
+
+      the conf_avail flag indicates whether per-message confidentiality
+      services are available, and will never be returned TRUE unless the
+      integ_avail flag is also returned TRUE
+
+      GSS-API callers desiring per-message security services should
+      check the values of these flags at context establishment time, and
+      must be aware that a returned FALSE value for integ_avail means
+      that invocation of GSS_GetMIC()  or GSS_Wrap() primitives on the
+      associated context will apply no cryptographic protection to user
+      data messages.
+
+   The GSS-API per-message integrity and data origin authentication
+   services provide assurance to a receiving caller that protection was
+   applied to a message by the caller's peer on the security context,
+   corresponding to the entity named at context initiation.  The GSS-API
+   per-message confidentiality service provides assurance to a sending
+   caller that the message's content is protected from access by
+   entities other than the context's named peer.
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 17]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   The GSS-API per-message protection service primitives, as the
+   category name implies, are oriented to operation at the granularity
+   of protocol data units. They perform cryptographic operations on the
+   data units, transfer cryptographic control information in tokens,
+   and, in the case of GSS_Wrap(), encapsulate the protected data unit.
+   As such, these primitives are not oriented to efficient data
+   protection for stream-paradigm protocols (e.g., Telnet) if
+   cryptography must be applied on an octet-by-octet basis.
+
+1.2.3: Per-Message Replay Detection and Sequencing
+
+   Certain underlying mech_types offer support for replay detection
+   and/or sequencing of messages transferred on the contexts they
+   support. These optionally-selectable protection features are distinct
+   from replay detection and sequencing features applied to the context
+   establishment operation itself; the presence or absence of context-
+   level replay or sequencing features is wholly a function of the
+   underlying mech_type's capabilities, and is not selected or omitted
+   as a caller option.
+
+   The caller initiating a context provides flags (replay_det_req_flag
+   and sequence_req_flag) to specify whether the use of per-message
+   replay detection and sequencing features is desired on the context
+   being established. The GSS-API implementation at the initiator system
+   can determine whether these features are supported (and whether they
+   are optionally selectable) as a function of mech_type, without need
+   for bilateral negotiation with the target. When enabled, these
+   features provide recipients with indicators as a result of GSS-API
+   processing of incoming messages, identifying whether those messages
+   were detected as duplicates or out-of-sequence. Detection of such
+   events does not prevent a suspect message from being provided to a
+   recipient; the appropriate course of action on a suspect message is a
+   matter of caller policy.
+
+   The semantics of the replay detection and sequencing services applied
+   to received messages, as visible across the interface which the GSS-
+   API provides to its clients, are as follows:
+
+   When replay_det_state is TRUE, the possible major_status returns for
+   well-formed and correctly signed messages are as follows:
+
+      1. GSS_S_COMPLETE indicates that the message was within the window
+      (of time or sequence space) allowing replay events to be detected,
+      and that the message was not a replay of a previously-processed
+      message within that window.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 18]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic
+      checkvalue on the received message was correct, but that the
+      message was recognized as a duplicate of a previously-processed
+      message.
+
+      3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on
+      the received message was correct, but that the message is too old
+      to be checked for duplication.
+
+   When sequence_state is TRUE, the possible major_status returns for
+   well-formed and correctly signed messages are as follows:
+
+      1. GSS_S_COMPLETE indicates that the message was within the window
+      (of time or sequence space) allowing replay events to be detected,
+      that the message was not a replay of a previously-processed
+      message within that window, and that no predecessor sequenced
+      messages are missing relative to the last received message (if
+      any) processed on the context with a correct cryptographic
+      checkvalue.
+
+      2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value
+      on the received message was correct, but that the message was
+      recognized as a duplicate of a previously-processed message.
+
+      3. GSS_S_OLD_TOKEN indicates that the integrity check value on the
+      received message was correct, but that the token is too old to be
+      checked for duplication.
+
+      4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue
+      on the received message was correct, but that it is earlier in a
+      sequenced stream than a message already processed on the context.
+      [Note: Mechanisms can be architected to provide a stricter form of
+      sequencing service, delivering particular messages to recipients
+      only after all predecessor messages in an ordered stream have been
+      delivered.  This type of support is incompatible with the GSS-API
+      paradigm in which recipients receive all messages, whether in
+      order or not, and provide them (one at a time, without intra-GSS-
+      API message buffering) to GSS-API routines for validation.  GSS-
+      API facilities provide supportive functions, aiding clients to
+      achieve strict message stream integrity in an efficient manner in
+      conjunction with sequencing provisions in communications
+      protocols, but the GSS-API does not offer this level of message
+      stream integrity service by itself.]
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 19]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on
+      the received message was correct, but that one or more predecessor
+      sequenced messages have not been successfully processed relative
+      to the last received message (if any) processed on the context
+      with a correct cryptographic checkvalue.
+
+   As the message stream integrity features (especially sequencing) may
+   interfere with certain applications' intended communications
+   paradigms, and since support for such features is likely to be
+   resource intensive, it is highly recommended that mech_types
+   supporting these features allow them to be activated selectively on
+   initiator request when a context is established. A context initiator
+   and target are provided with corresponding indicators
+   (replay_det_state and sequence_state), signifying whether these
+   features are active on a given context.
+
+   An example mech_type supporting per-message replay detection could
+   (when replay_det_state is TRUE) implement the feature as follows: The
+   underlying mechanism would insert timestamps in data elements output
+   by GSS_GetMIC()  and GSS_Wrap(), and would maintain (within a time-
+   limited window) a cache (qualified by originator-recipient pair)
+   identifying received data elements processed by GSS_VerifyMIC()  and
+   GSS_Unwrap(). When this feature is active, exception status returns
+   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when
+   GSS_VerifyMIC()  or GSS_Unwrap() is presented with a message which is
+   either a detected duplicate of a prior message or which is too old to
+   validate against a cache of recently received messages.
+
+1.2.4:  Quality of Protection
+
+   Some mech_types provide their users with fine granularity control
+   over the means used to provide per-message protection, allowing
+   callers to trade off security processing overhead dynamically against
+   the protection requirements of particular messages. A per-message
+   quality-of-protection parameter (analogous to quality-of-service, or
+   QOS) selects among different QOP options supported by that mechanism.
+   On context establishment for a multi-QOP mech_type, context-level
+   data provides the prerequisite data for a range of protection
+   qualities.
+
+   It is expected that the majority of callers will not wish to exert
+   explicit mechanism-specific QOP control and will therefore request
+   selection of a default QOP. Definitions of, and choices among, non-
+   default QOP values are mechanism-specific, and no ordered sequences
+   of QOP values can be assumed equivalent across different mechanisms.
+   Meaningful use of non-default QOP values demands that callers be
+   familiar with the QOP definitions of an underlying mechanism or
+   mechanisms, and is therefore a non-portable construct.  The
+
+
+
+Linn                        Standards Track                    [Page 20]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   GSS_S_BAD_QOP major_status value is defined in order to indicate that
+   a provided QOP value is unsupported for a security context, most
+   likely because that value is unrecognized by the underlying
+   mechanism.
+
+1.2.5: Anonymity Support
+
+   In certain situations or environments, an application may wish to
+   authenticate a peer and/or protect communications using GSS-API per-
+   message services without revealing its own identity.  For example,
+   consider an application which provides read access to a research
+   database, and which permits queries by arbitrary requestors.  A
+   client of such a service might wish to authenticate the service, to
+   establish trust in the information received from it, but might not
+   wish to disclose its identity to the service for privacy reasons.
+
+   In ordinary GSS-API usage, a context initiator's identity is made
+   available to the context acceptor as part of the context
+   establishment process.  To provide for anonymity support, a facility
+   (input anon_req_flag to GSS_Init_sec_context()) is provided through
+   which context initiators may request that their identity not be
+   provided to the context acceptor.  Mechanisms are not required to
+   honor this request, but a caller will be informed (via returned
+   anon_state indicator from GSS_Init_sec_context()) whether or not the
+   request is honored. Note that authentication as the anonymous
+   principal does not necessarily imply that credentials are not
+   required in order to establish a context.
+
+   The following Object Identifier value is provided as a means to
+   identify anonymous names, and can be compared against in order to
+   determine, in a mechanism-independent fashion, whether a name refers
+   to an anonymous principal:
+
+   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
+   3(gss-anonymous-name)}
+
+   The recommended symbolic name corresponding to this definition is
+   GSS_C_NT_ANONYMOUS.
+
+   Four possible combinations of anon_state and mutual_state are
+   possible, with the following results:
+
+      anon_state == FALSE, mutual_state == FALSE: initiator
+      authenticated to target.
+
+      anon_state == FALSE, mutual_state == TRUE: initiator authenticated
+      to target, target authenticated to initiator.
+
+
+
+
+Linn                        Standards Track                    [Page 21]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      anon_state == TRUE, mutual_state == FALSE: initiator authenticated
+      as anonymous principal to target.
+
+      anon_state == TRUE, mutual_state == TRUE: initiator authenticated
+      as anonymous principal to target, target authenticated to
+      initiator.
+
+1.2.6: Initialization
+
+   No initialization calls (i.e., calls which must be invoked prior to
+   invocation of other facilities in the interface) are defined in GSS-
+   API.  As an implication of this fact, GSS-API implementations must
+   themselves be self-initializing.
+
+1.2.7: Per-Message Protection During Context Establishment
+
+   A facility is defined in GSS-V2 to enable protection and buffering of
+   data messages for later transfer while a security context's
+   establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases
+   where the caller side already possesses the necessary session key to
+   enable this processing. Specifically, a new state Boolean, called
+   prot_ready_state, is added to the set of information returned by
+   GSS_Init_sec_context(), GSS_Accept_sec_context(), and
+   GSS_Inquire_context().
+
+   For context establishment calls, this state Boolean is valid and
+   interpretable when the associated major_status is either
+   GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE.  Callers of GSS-API (both
+   initiators and acceptors) can assume that per-message protection (via
+   GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
+   available and ready for use if either: prot_ready_state == TRUE, or
+   major_status == GSS_S_COMPLETE, though mutual authentication (if
+   requested) cannot be guaranteed until GSS_S_COMPLETE is returned.
+
+   This achieves full, transparent backward compatibility for GSS-API V1
+   callers, who need not even know of the existence of prot_ready_state,
+   and who will get the expected behavior from GSS_S_COMPLETE, but who
+   will not be able to use per-message protection before GSS_S_COMPLETE
+   is returned.
+
+   It is not a requirement that GSS-V2 mechanisms ever return TRUE
+   prot_ready_state before completion of context establishment (indeed,
+   some mechanisms will not evolve usable message protection keys,
+   especially at the context acceptor, before context establishment is
+   complete).  It is expected but not required that GSS-V2 mechanisms
+   will return TRUE prot_ready_state upon completion of context
+   establishment if they support per-message protection at all (however
+   GSS-V2 applications should not assume that TRUE prot_ready_state will
+
+
+
+Linn                        Standards Track                    [Page 22]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   always be returned together with the GSS_S_COMPLETE major_status,
+   since GSS-V2 implementations may continue to support GSS-V1 mechanism
+   code, which will never return TRUE prot_ready_state).
+
+   When prot_ready_state is returned TRUE, mechanisms shall also set
+   those context service indicator flags (deleg_state, mutual_state,
+   replay_det_state, sequence_state, anon_state, trans_state,
+   conf_avail, integ_avail) which represent facilities confirmed, at
+   that time, to be available on the context being established.  In
+   situations where prot_ready_state is returned before GSS_S_COMPLETE,
+   it is possible that additional facilities may be confirmed and
+   subsequently indicated when GSS_S_COMPLETE is returned.
+
+1.2.8: Implementation Robustness
+
+   This section recommends aspects of GSS-API implementation behavior in
+   the interests of overall robustness.
+
+   If a token is presented for processing on a GSS-API security context
+   and that token is determined to be invalid for that context, the
+   context's state should not be disrupted for purposes of processing
+   subsequent valid tokens.
+
+   Certain local conditions at a GSS-API implementation (e.g.,
+   unavailability of memory) may preclude, temporarily or permanently,
+   the successful processing of tokens on a GSS-API security context,
+   typically generating GSS_S_FAILURE major_status returns along with
+   locally-significant minor_status.  For robust operation under such
+   conditions, the following recommendations are made:
+
+      Failing calls should free any memory they allocate, so that
+      callers may retry without causing further loss of resources.
+
+      Failure of an individual call on an established context should not
+      preclude subsequent calls from succeeding on the same context.
+
+      Whenever possible, it should be possible for
+      GSS_Delete_sec_context() calls to be successfully processed even
+      if other calls cannot succeed, thereby enabling context-related
+      resources to be released.
+
+2:  Interface Descriptions
+
+   This section describes the GSS-API's service interface, dividing the
+   set of calls offered into four groups. Credential management calls
+   are related to the acquisition and release of credentials by
+   principals. Context-level calls are related to the management of
+   security contexts between principals. Per-message calls are related
+
+
+
+Linn                        Standards Track                    [Page 23]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   to the protection of individual messages on established security
+   contexts. Support calls provide ancillary functions useful to GSS-API
+   callers. Table 2 groups and summarizes the calls in tabular fashion.
+
+Table 2:  GSS-API Calls
+
+   CREDENTIAL MANAGEMENT
+
+   GSS_Acquire_cred             acquire credentials for use
+   GSS_Release_cred             release credentials after use
+   GSS_Inquire_cred             display information about
+                                credentials
+   GSS_Add_cred                 construct credentials incrementally
+   GSS_Inquire_cred_by_mech     display per-mechanism credential
+                                information
+
+   CONTEXT-LEVEL CALLS
+
+   GSS_Init_sec_context         initiate outbound security context
+   GSS_Accept_sec_context       accept inbound security context
+   GSS_Delete_sec_context       flush context when no longer needed
+   GSS_Process_context_token    process received control token on
+                                context
+   GSS_Context_time             indicate validity time remaining on
+                                      context
+   GSS_Inquire_context          display information about context
+   GSS_Wrap_size_limit          determine GSS_Wrap token size limit
+   GSS_Export_sec_context       transfer context to other process
+   GSS_Import_sec_context       import transferred context
+
+   PER-MESSAGE CALLS
+
+   GSS_GetMIC                   apply integrity check, receive as
+                                token separate from message
+   GSS_VerifyMIC                validate integrity check token
+                                along with message
+   GSS_Wrap                     sign, optionally encrypt,
+                                encapsulate
+   GSS_Unwrap                   decapsulate, decrypt if needed,
+                                validate integrity check
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 24]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   SUPPORT CALLS
+
+   GSS_Display_status           translate status codes to printable
+                                form
+   GSS_Indicate_mechs           indicate mech_types supported on
+                                local system
+   GSS_Compare_name             compare two names for equality
+   GSS_Display_name             translate name to printable form
+   GSS_Import_name              convert printable name to
+                                normalized form
+   GSS_Release_name             free storage of normalized-form
+                                name
+   GSS_Release_buffer           free storage of printable name
+   GSS_Release_OID              free storage of OID object
+   GSS_Release_OID_set          free storage of OID set object
+   GSS_Create_empty_OID_set     create empty OID set
+   GSS_Add_OID_set_member       add member to OID set
+   GSS_Test_OID_set_member      test if OID is member of OID set
+   GSS_OID_to_str               display OID as string
+   GSS_Str_to_OID               construct OID from string
+   GSS_Inquire_names_for_mech   indicate name types supported by
+                                mechanism
+   GSS_Inquire_mechs_for_name   indicates mechanisms supporting name
+                                type
+   GSS_Canonicalize_name        translate name to per-mechanism form
+   GSS_Export_name              externalize per-mechanism name
+   GSS_Duplicate_name           duplicate name object
+
+2.1:  Credential management calls
+
+   These GSS-API calls provide functions related to the management of
+   credentials. Their characterization with regard to whether or not
+   they may block pending exchanges with other network entities (e.g.,
+   directories or authentication servers) depends in part on OS-specific
+   (extra-GSS-API) issues, so is not specified in this document.
+
+   The GSS_Acquire_cred() call is defined within the GSS-API in support
+   of application portability, with a particular orientation towards
+   support of portable server applications. It is recognized that (for
+   certain systems and mechanisms) credentials for interactive users may
+   be managed differently from credentials for server processes; in such
+   environments, it is the GSS-API implementation's responsibility to
+   distinguish these cases and the procedures for making this
+   distinction are a local matter. The GSS_Release_cred()  call provides
+   a means for callers to indicate to the GSS-API that use of a
+   credentials structure is no longer required. The GSS_Inquire_cred()
+   call allows callers to determine information about a credentials
+   structure.  The GSS_Add_cred() call enables callers to append
+
+
+
+Linn                        Standards Track                    [Page 25]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   elements to an existing credential structure, allowing iterative
+   construction of a multi-mechanism credential. The
+   GSS_Inquire_cred_by_mech() call enables callers to extract per-
+   mechanism information describing a credentials structure.
+
+2.1.1:  GSS_Acquire_cred call
+
+   Inputs:
+
+   o  desired_name INTERNAL NAME, -NULL requests locally-determined
+      default
+
+   o  lifetime_req INTEGER,-in seconds; 0 requests default
+
+   o  desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
+      system-selected default
+
+   o  cred_usage INTEGER -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_cred_handle CREDENTIAL HANDLE,
+
+   o  actual_mechs SET OF OBJECT IDENTIFIER,
+
+   o  lifetime_rec INTEGER -in seconds, or reserved value for
+      INDEFINITE
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that requested credentials were
+      successfully established, for the duration indicated in
+      lifetime_rec, suitable for the usage requested in cred_usage,
+      for the set of mech_types indicated in actual_mechs, and that
+      those credentials can be referenced for subsequent use with
+      the handle returned in output_cred_handle.
+
+   o  GSS_S_BAD_MECH indicates that a mech_type unsupported by the
+      GSS-API implementation type was requested, causing the
+      credential establishment operation to fail.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 26]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
+      uninterpretable or of a type unsupported by the applicable
+      underlying GSS-API mechanism(s), so no credentials could be
+      established for the accompanying desired_name.
+
+   o  GSS_S_BAD_NAME indicates that the provided desired_name is
+      inconsistent in terms of internally-incorporated type specifier
+      information, so no credentials could be established for the
+      accompanying desired_name.
+
+   o  GSS_S_FAILURE indicates that credential establishment failed
+      for reasons unspecified at the GSS-API level, including lack
+      of authorization to establish and use credentials associated
+      with the identity named in the input desired_name argument.
+
+   GSS_Acquire_cred()  is used to acquire credentials so that a
+   principal can (as a function of the input cred_usage parameter)
+   initiate and/or accept security contexts under the identity
+   represented by the desired_name input argument. On successful
+   completion, the returned output_cred_handle result provides a handle
+   for subsequent references to the acquired credentials.  Typically,
+   single-user client processes requesting that default credential
+   behavior be applied for context establishment purposes will have no
+   need to invoke this call.
+
+   A caller may provide the value NULL for desired_name, signifying a
+   request for credentials corresponding to a principal identity
+   selected by default for the caller. The procedures used by GSS-API
+   implementations to select the appropriate principal identity in
+   response to such a request are local matters. It is possible that
+   multiple pre-established credentials may exist for the same principal
+   identity (for example, as a result of multiple user login sessions)
+   when GSS_Acquire_cred() is called; the means used in such cases to
+   select a specific credential are local matters.  The input
+   lifetime_req argument to GSS_Acquire_cred() may provide useful
+   information for local GSS-API implementations to employ in making
+   this disambiguation in a manner which will best satisfy a caller's
+   intent.
+
+   The lifetime_rec result indicates the length of time for which the
+   acquired credentials will be valid, as an offset from the present. A
+   mechanism may return a reserved value indicating INDEFINITE if no
+   constraints on credential lifetime are imposed.  A caller of
+   GSS_Acquire_cred()  can request a length of time for which acquired
+   credentials are to be valid (lifetime_req argument), beginning at the
+   present, or can request credentials with a default validity interval.
+   (Requests for postdated credentials are not supported within the
+   GSS-API.) Certain mechanisms and implementations may bind in
+
+
+
+Linn                        Standards Track                    [Page 27]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   credential validity period specifiers at a point preliminary to
+   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
+   user login procedures). As a result, callers requesting non-default
+   values for lifetime_req must recognize that such requests cannot
+   always be honored and must be prepared to accommodate the use of
+   returned credentials with different lifetimes as indicated in
+   lifetime_rec.
+
+   The caller of GSS_Acquire_cred()  can explicitly specify a set of
+   mech_types which are to be accommodated in the returned credentials
+   (desired_mechs argument), or can request credentials for a system-
+   defined default set of mech_types. Selection of the system-specified
+   default set is recommended in the interests of application
+   portability. The actual_mechs return value may be interrogated by the
+   caller to determine the set of mechanisms with which the returned
+   credentials may be used.
+
+2.1.2:  GSS_Release_cred call
+
+   Input:
+
+   o  cred_handle CREDENTIAL HANDLE - NULL specifies that
+      the credential elements used when default credential behavior
+      is requested be released.
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+      input cred_handle were released for purposes of subsequent
+      access by the caller. The effect on other processes which may
+      be authorized shared access to such credentials is a local
+      matter.
+
+   o  GSS_S_NO_CRED indicates that no release operation was
+      performed, either because the input cred_handle was invalid or
+      because the caller lacks authorization to access the
+      referenced credentials.
+
+   o  GSS_S_FAILURE indicates that the release operation failed for
+      reasons unspecified at the GSS-API level.
+
+
+
+
+
+Linn                        Standards Track                    [Page 28]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Provides a means for a caller to explicitly request that credentials
+   be released when their use is no longer required. Note that system-
+   specific credential management functions are also likely to exist,
+   for example to assure that credentials shared among processes are
+   properly deleted when all affected processes terminate, even if no
+   explicit release requests are issued by those processes. Given the
+   fact that multiple callers are not precluded from gaining authorized
+   access to the same credentials, invocation of GSS_Release_cred()
+   cannot be assumed to delete a particular set of credentials on a
+   system-wide basis.
+
+2.1.3:  GSS_Inquire_cred call
+
+   Input:
+
+   o  cred_handle CREDENTIAL HANDLE -NULL specifies that the
+      credential elements used when default credential behavior is
+      requested are to be queried
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  cred_name INTERNAL NAME,
+
+   o  lifetime_rec INTEGER -in seconds, or reserved value for
+      INDEFINITE
+
+   o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+      input cred_handle argument were valid, and that the output
+      cred_name, lifetime_rec, and cred_usage values represent,
+      respectively, the credentials' associated principal name,
+      remaining lifetime, suitable usage modes, and supported
+      mechanism types.
+
+   o  GSS_S_NO_CRED indicates that no information could be returned
+      about the referenced credentials, either because the input
+      cred_handle was invalid or because the caller lacks
+      authorization to access the referenced credentials.
+
+
+
+Linn                        Standards Track                    [Page 29]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
+      credentials are invalid.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
+      credentials have expired.
+
+   o  GSS_S_FAILURE indicates that the operation failed for
+      reasons unspecified at the GSS-API level.
+
+   The GSS_Inquire_cred() call is defined primarily for the use of those
+   callers which request use of default credential behavior rather than
+   acquiring credentials explicitly with GSS_Acquire_cred().  It enables
+   callers to determine a credential structure's associated principal
+   name, remaining validity period, usability for security context
+   initiation and/or acceptance, and supported mechanisms.
+
+   For a multi-mechanism credential, the returned "lifetime" specifier
+   indicates the shortest lifetime of any of the mechanisms' elements in
+   the credential (for either context initiation or acceptance
+   purposes).
+
+   GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
+   "cred_usage" if both of the following conditions hold:
+
+      (1) there exists in the credential an element which allows context
+      initiation using some mechanism
+
+      (2) there exists in the credential an element which allows context
+      acceptance using some mechanism (allowably, but not necessarily,
+      one of the same mechanism(s) qualifying for (1)).
+
+   If condition (1) holds but not condition (2), GSS_Inquire_cred()
+   should indicate INITIATE-ONLY for "cred_usage".  If condition (2)
+   holds but not condition (1), GSS_Inquire_cred() should indicate
+   ACCEPT-ONLY for "cred_usage".
+
+   Callers requiring finer disambiguation among available combinations
+   of lifetimes, usage modes, and mechanisms should call the
+   GSS_Inquire_cred_by_mech() routine, passing that routine one of the
+   mech OIDs returned by GSS_Inquire_cred().
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 30]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.1.4:  GSS_Add_cred call
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE - handle to credential
+      structure created with prior GSS_Acquire_cred() or
+      GSS_Add_cred() call, or NULL to append elements to the set
+      which are applied for the caller when default credential
+      behavior is specified.
+
+   o  desired_name INTERNAL NAME - NULL requests locally-determined
+      default
+
+   o  initiator_time_req INTEGER - in seconds; 0 requests default
+
+   o  acceptor_time_req INTEGER - in seconds; 0 requests default
+
+   o  desired_mech OBJECT IDENTIFIER
+
+   o  cred_usage INTEGER - 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+       2=ACCEPT-ONLY
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_cred_handle CREDENTIAL HANDLE, - NULL to request that
+      credential elements be added "in place" to the credential
+      structure  identified by input_cred_handle, non-NULL pointer
+      to request that a new credential structure and handle be created.
+
+   o  actual_mechs SET OF OBJECT IDENTIFIER,
+
+   o  initiator_time_rec INTEGER - in seconds, or reserved value for
+      INDEFINITE
+
+   o  acceptor_time_rec INTEGER - in seconds, or reserved value for
+      INDEFINITE
+
+   o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
+      supported by resulting credential.
+
+
+
+
+
+Linn                        Standards Track                    [Page 31]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by
+      the input_cred_handle argument were valid, and that the
+      resulting credential from GSS_Add_cred() is valid for the
+      durations indicated in initiator_time_rec and acceptor_time_rec,
+      suitable for the usage requested in cred_usage, and for the
+      mechanisms indicated in actual_mechs.
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech
+      specified a mechanism for which the referenced credential
+      already contained a credential element with overlapping
+      cred_usage and validity time specifiers.
+
+   o  GSS_S_BAD_MECH indicates that the input desired_mech specified
+      a mechanism unsupported by the GSS-API implementation, causing
+      the GSS_Add_cred() operation to fail.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name
+      is uninterpretable or of a type unsupported by the applicable
+      underlying GSS-API mechanism(s), so the GSS_Add_cred() operation
+      could not be performed for that name.
+
+   o  GSS_S_BAD_NAME indicates that the provided desired_name is
+      inconsistent in terms of internally-incorporated type specifier
+      information, so the GSS_Add_cred() operation could not be
+      performed for that name.
+
+   o  GSS_S_NO_CRED indicates that the input_cred_handle referenced
+      invalid or inaccessible credentials.
+
+   o  GSS_S_FAILURE indicates that the operation failed for
+      reasons unspecified at the GSS-API level, including lack of
+      authorization to establish or use credentials representing
+      the requested identity.
+
+   GSS_Add_cred() enables callers to construct credentials iteratively
+   by adding credential elements in successive operations, corresponding
+   to different mechanisms.  This offers particular value in multi-
+   mechanism environments, as the major_status and minor_status values
+   returned on each iteration are individually visible and can therefore
+   be interpreted unambiguously on a per-mechanism basis.
+
+   The same input desired_name, or default reference, should be used on
+   all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a
+   particular credential.
+
+
+
+
+
+Linn                        Standards Track                    [Page 32]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.1.5:  GSS_Inquire_cred_by_mech call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE  -- NULL specifies that the
+      credential elements used when default credential behavior is
+      requested are to be queried
+
+   o  mech_type OBJECT IDENTIFIER  -- specific mechanism for
+      which credentials are being queried
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  cred_name INTERNAL NAME, -- guaranteed to be MN
+
+   o  lifetime_rec_initiate INTEGER -- in seconds, or reserved value for
+      INDEFINITE
+
+   o  lifetime_rec_accept INTEGER -- in seconds, or reserved value for
+      INDEFINITE
+
+   o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+      input cred_handle argument were valid, that the mechanism
+      indicated by the input mech_type was represented with elements
+      within those credentials, and that the output cred_name,
+      lifetime_rec_initiate, lifetime_rec_accept, and cred_usage values
+      represent, respectively, the credentials' associated principal
+      name, remaining lifetimes, and suitable usage modes.
+
+   o  GSS_S_NO_CRED indicates that no information could be returned
+      about the referenced credentials, either because the input
+      cred_handle was invalid or because the caller lacks
+      authorization to access the referenced credentials.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
+      credentials are invalid.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
+      credentials have expired.
+
+
+
+Linn                        Standards Track                    [Page 33]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_BAD_MECH indicates that the referenced credentials do not
+      contain elements for the requested mechanism.
+
+   o  GSS_S_FAILURE indicates that the operation failed for reasons
+      unspecified at the GSS-API level.
+
+   The GSS_Inquire_cred_by_mech() call enables callers in multi-
+   mechanism environments to acquire specific data about available
+   combinations of lifetimes, usage modes, and mechanisms within a
+   credential structure.  The lifetime_rec_initiate result indicates the
+   available lifetime for context initiation purposes; the
+   lifetime_rec_accept result indicates the available lifetime for
+   context acceptance purposes.
+
+2.2:  Context-level calls
+
+   This group of calls is devoted to the establishment and management of
+   security contexts between peers. A context's initiator calls
+   GSS_Init_sec_context(),  resulting in generation of a token which the
+   caller passes to the target. At the target, that token is passed to
+   GSS_Accept_sec_context().  Depending on the underlying mech_type and
+   specified options, additional token exchanges may be performed in the
+   course of context establishment; such exchanges are accommodated by
+   GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context()  and
+   GSS_Accept_sec_context().
+
+   Either party to an established context may invoke
+   GSS_Delete_sec_context() to flush context information when a context
+   is no longer required. GSS_Process_context_token()  is used to
+   process received tokens carrying context-level control information.
+   GSS_Context_time()  allows a caller to determine the length of time
+   for which an established context will remain valid.
+   GSS_Inquire_context() returns status information describing context
+   characteristics. GSS_Wrap_size_limit() allows a caller to determine
+   the size of a token which will be generated by a GSS_Wrap()
+   operation.  GSS_Export_sec_context() and GSS_Import_sec_context()
+   enable transfer of active contexts between processes on an end
+   system.
+
+2.2.1:  GSS_Init_sec_context call
+
+   Inputs:
+
+   o  claimant_cred_handle CREDENTIAL HANDLE, -NULL specifies "use
+      default"
+
+   o  input_context_handle CONTEXT HANDLE, -0 specifies "none assigned
+      yet"
+
+
+
+Linn                        Standards Track                    [Page 34]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  targ_name INTERNAL NAME,
+
+   o  mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
+      default"
+
+   o  deleg_req_flag BOOLEAN,
+
+   o  mutual_req_flag BOOLEAN,
+
+   o  replay_det_req_flag BOOLEAN,
+
+   o  sequence_req_flag BOOLEAN,
+
+   o  anon_req_flag BOOLEAN,
+
+   o  lifetime_req INTEGER,-0 specifies default lifetime
+
+   o  chan_bindings OCTET STRING,
+
+   o  input_token OCTET STRING-NULL or token received from target
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_context_handle CONTEXT HANDLE,
+
+   o  mech_type OBJECT IDENTIFIER, -actual mechanism always
+      indicated, never NULL
+
+   o  output_token OCTET STRING, -NULL or token to pass to context
+      target
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  anon_state BOOLEAN,
+
+   o  trans_state BOOLEAN,
+
+   o  prot_ready_state BOOLEAN, -- see Section 1.2.7
+
+
+
+Linn                        Standards Track                    [Page 35]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  lifetime_rec INTEGER - in seconds, or reserved value for
+      INDEFINITE
+
+   This call may block pending network interactions for those mech_types
+   in which an authentication server or other network entity must be
+   consulted on behalf of a context initiator in order to generate an
+   output_token suitable for presentation to a specified target.
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that context-level information was
+      successfully initialized, and that the returned output_token
+      will provide sufficient information for the target to perform
+      per-message processing on the newly-established context.
+
+   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
+      returned output_token must be sent to the target, and that a
+      reply must be received and passed as the input_token argument
+      to a continuation call to GSS_Init_sec_context(),  before
+      per-message processing can be performed in conjunction with
+      this context.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
+      performed on the input_token failed, preventing further
+      processing from being performed based on that token.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
+      performed on the credential structure referenced by
+      claimant_cred_handle failed, preventing further processing from
+      being performed using that credential structure.
+
+   o  GSS_S_BAD_SIG indicates that the received input_token
+      contains an incorrect integrity check, so context setup cannot
+      be accomplished.
+
+   o  GSS_S_NO_CRED indicates that no context was established,
+      either because the input cred_handle was invalid, because the
+      referenced credentials are valid for context acceptor use
+      only, or because the caller lacks authorization to access the
+      referenced credentials.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials
+      provided through the input claimant_cred_handle argument are no
+      longer valid, so context establishment cannot be completed.
+
+
+
+Linn                        Standards Track                    [Page 36]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the
+      caller-provided chan_bindings and those extracted from the
+      input_token was detected, signifying a security-relevant
+      event and preventing context establishment. (This result will
+      be returned by GSS_Init_sec_context only for contexts where
+      mutual_state is TRUE.)
+
+   o  GSS_S_OLD_TOKEN indicates that the input_token is too old to
+      be checked for integrity. This is a fatal error during context
+      establishment.
+
+   o  GSS_S_DUPLICATE_TOKEN indicates that the input token has a
+      correct integrity check, but is a duplicate of a token already
+      processed. This is a fatal error during context establishment.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided; this major status will
+      be returned only for successor calls following GSS_S_CONTINUE_
+      NEEDED status returns.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided targ_name is
+      of a type uninterpretable or unsupported by the applicable
+      underlying GSS-API mechanism(s), so context establishment
+      cannot be completed.
+
+   o  GSS_S_BAD_NAME indicates that the provided targ_name is
+      inconsistent in terms of internally-incorporated type specifier
+      information, so context establishment cannot be accomplished.
+
+   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
+      or of a caller request specifying a mechanism unsupported by
+      the local system or with the caller's active credentials
+
+   o  GSS_S_FAILURE indicates that context setup could not be
+      accomplished for reasons unspecified at the GSS-API level, and
+      that no interface-defined recovery action is available.
+
+   This routine is used by a context initiator, and ordinarily emits one
+   (or, for the case of a multi-step exchange, more than one)
+   output_token suitable for use by the target within the selected
+   mech_type's protocol. Using information in the credentials structure
+   referenced by claimant_cred_handle, GSS_Init_sec_context()
+   initializes the data structures required to establish a security
+   context with target targ_name. The targ_name may be any valid
+   INTERNAL NAME; it need not be an MN. The claimant_cred_handle must
+   correspond to the same valid credentials structure on the initial
+   call to GSS_Init_sec_context()  and on any successor calls resulting
+   from GSS_S_CONTINUE_NEEDED status returns; different protocol
+
+
+
+Linn                        Standards Track                    [Page 37]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   sequences modeled by the GSS_S_CONTINUE_NEEDED facility will require
+   access to credentials at different points in the context
+   establishment sequence.
+
+   The input_context_handle argument is 0, specifying "not yet
+   assigned", on the first GSS_Init_sec_context()  call relating to a
+   given context. If successful (i.e., if accompanied by major_status
+   GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the
+   initial GSS_Init_sec_context() call returns a non-zero
+   output_context_handle for use in future references to this context.
+   Once a non-zero output_context_handle has been returned, GSS-API
+   callers should call GSS_Delete_sec_context() to release context-
+   related resources if errors occur in later phases of context
+   establishment, or when an established context is no longer required.
+
+   When continuation attempts to GSS_Init_sec_context() are needed to
+   perform context establishment, the previously-returned non-zero
+   handle value is entered into the input_context_handle argument and
+   will be echoed in the returned output_context_handle argument. On
+   such continuation attempts (and only on continuation attempts) the
+   input_token value is used, to provide the token returned from the
+   context's target.
+
+   The chan_bindings argument is used by the caller to provide
+   information binding the security context to security-related
+   characteristics (e.g., addresses, cryptographic keys) of the
+   underlying communications channel. See Section 1.1.6 of this document
+   for more discussion of this argument's usage.
+
+   The input_token argument contains a message received from the target,
+   and is significant only on a call to GSS_Init_sec_context()  which
+   follows a previous return indicating GSS_S_CONTINUE_NEEDED
+   major_status.
+
+   It is the caller's responsibility to establish a communications path
+   to the target, and to transmit any returned output_token (independent
+   of the accompanying returned major_status value) to the target over
+   that path. The output_token can, however, be transmitted along with
+   the first application-provided input message to be processed by
+   GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-
+   established context.
+
+   The initiator may request various context-level functions through
+   input flags: the deleg_req_flag requests delegation of access rights,
+   the mutual_req_flag requests mutual authentication, the
+   replay_det_req_flag requests that replay detection features be
+   applied to messages transferred on the established context, and the
+   sequence_req_flag requests that sequencing be enforced. (See Section
+
+
+
+Linn                        Standards Track                    [Page 38]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   1.2.3 for more information on replay detection and sequencing
+   features.)  The anon_req_flag requests that the initiator's identity
+   not be transferred within tokens to be sent to the acceptor.
+
+   Not all of the optionally-requestable features will be available in
+   all underlying mech_types. The corresponding return state values
+   deleg_state, mutual_state, replay_det_state, and sequence_state
+   indicate, as a function of mech_type processing capabilities and
+   initiator-provided input flags, the set of features which will be
+   active on the context.  The returned trans_state value indicates
+   whether the context is transferable to other processes through use of
+   GSS_Export_sec_context().  These state indicators' values are
+   undefined unless either the routine's major_status indicates
+   GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with
+   GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is
+   possible that additional features, not confirmed or indicated along
+   with TRUE prot_ready_state, will be confirmed and indicated when
+   GSS_S_COMPLETE is subsequently returned.
+
+   The returned anon_state and prot_ready_state values are significant
+   for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status
+   returns from GSS_Init_sec_context().  When anon_state is returned
+   TRUE, this indicates that neither the current token nor its
+   predecessors delivers or has delivered the initiator's identity.
+   Callers wishing to perform context establishment only if anonymity
+   support is provided should transfer a returned token from
+   GSS_Init_sec_context() to the peer only if it is accompanied by a
+   TRUE anon_state indicator.  When prot_ready_state is returned TRUE in
+   conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates
+   that per-message protection operations may be applied on the context:
+   see Section 1.2.7 for further discussion of this facility.
+
+   Failure to provide the precise set of features requested by the
+   caller does not cause context establishment to fail; it is the
+   caller's prerogative to delete the context if the feature set
+   provided is unsuitable for the caller's use.
+
+   The returned mech_type value indicates the specific mechanism
+   employed on the context, is valid only along with major_status
+   GSS_S_COMPLETE, and will never indicate the value for "default".
+   Note that, for the case of certain mechanisms which themselves
+   perform negotiation, the returned mech_type result may indicate
+   selection of a mechanism identified by an OID different than that
+   passed in the input mech_type argument.
+
+   The conf_avail return value indicates whether the context supports
+   per-message confidentiality services, and so informs the caller
+   whether or not a request for encryption through the conf_req_flag
+
+
+
+Linn                        Standards Track                    [Page 39]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   input to GSS_Wrap()  can be honored. In similar fashion, the
+   integ_avail return value indicates whether per-message integrity
+   services are available (through either GSS_GetMIC() or GSS_Wrap()) on
+   the established context. These state indicators' values are undefined
+   unless either the routine's major_status indicates GSS_S_COMPLETE, or
+   TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED
+   major_status.
+
+   The lifetime_req input specifies a desired upper bound for the
+   lifetime of the context to be established, with a value of 0 used to
+   request a default lifetime. The lifetime_rec return value indicates
+   the length of time for which the context will be valid, expressed as
+   an offset from the present; depending on mechanism capabilities,
+   credential lifetimes, and local policy, it may not correspond to the
+   value requested in lifetime_req.  If no constraints on context
+   lifetime are imposed, this may be indicated by returning a reserved
+   value representing INDEFINITE lifetime_req. The value of lifetime_rec
+   is undefined unless the routine's major_status indicates
+   GSS_S_COMPLETE.
+
+   If the mutual_state is TRUE, this fact will be reflected within the
+   output_token. A call to GSS_Accept_sec_context()  at the target in
+   conjunction with such a context will return a token, to be processed
+   by a continuation call to GSS_Init_sec_context(),  in order to
+   achieve mutual authentication.
+
+2.2.2:  GSS_Accept_sec_context call
+
+   Inputs:
+
+   o  acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies
+      "use default"
+
+   o  input_context_handle CONTEXT HANDLE, -- 0 specifies
+      "not yet assigned"
+
+   o  chan_bindings OCTET STRING,
+
+   o  input_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  src_name INTERNAL NAME, -- guaranteed to be MN
+
+
+
+
+Linn                        Standards Track                    [Page 40]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  mech_type OBJECT IDENTIFIER,
+
+   o  output_context_handle CONTEXT HANDLE,
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  anon_state BOOLEAN,
+
+   o  trans_state BOOLEAN,
+
+   o  prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  lifetime_rec INTEGER, - in seconds, or reserved value for
+      INDEFINITE
+
+   o  delegated_cred_handle CREDENTIAL HANDLE,
+
+   o  output_token OCTET STRING -NULL or token to pass to context
+      initiator
+
+   This call may block pending network interactions for those mech_types
+   in which a directory service or other network entity must be
+   consulted on behalf of a context acceptor in order to validate a
+   received input_token.
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that context-level data structures
+      were successfully initialized, and that per-message processing
+      can now be performed in conjunction with this context.
+
+   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
+      returned output_token must be sent to the initiator, and that
+      a response must be received and passed as the input_token
+      argument to a continuation call to GSS_Accept_sec_context(),
+      before per-message processing can be performed in conjunction
+      with this context.
+
+
+
+
+Linn                        Standards Track                    [Page 41]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+      on the input_token failed, preventing further processing from
+      being performed based on that token.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
+      performed on the credential structure referenced by
+      acceptor_cred_handle failed, preventing further processing from
+      being performed using that credential structure.
+
+   o  GSS_S_BAD_SIG indicates that the received input_token contains
+      an incorrect integrity check, so context setup cannot be
+      accomplished.
+
+   o  GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the
+      received input_token was correct, but that the input_token
+      was recognized as a duplicate of an input_token already
+      processed. No new context is established.
+
+   o  GSS_S_OLD_TOKEN indicates that the integrity check on the received
+      input_token was correct, but that the input_token is too old
+      to be checked for duplication against previously-processed
+      input_tokens. No new context is established.
+
+   o  GSS_S_NO_CRED indicates that no context was established, either
+      because the input cred_handle was invalid, because the
+      referenced credentials are valid for context initiator use
+      only, or because the caller lacks authorization to access the
+      referenced credentials.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
+      through the input acceptor_cred_handle argument are no
+      longer valid, so context establishment cannot be completed.
+
+   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the
+      caller-provided chan_bindings and those extracted from the
+      input_token was detected, signifying a security-relevant
+      event and preventing context establishment.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided; this major status will
+      be returned only for successor calls following GSS_S_CONTINUE_
+      NEEDED status returns.
+
+   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
+      specifying a mechanism unsupported by the local system or with
+      the caller's active credentials.
+
+
+
+
+
+Linn                        Standards Track                    [Page 42]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_FAILURE indicates that context setup could not be
+      accomplished for reasons unspecified at the GSS-API level, and
+      that no interface-defined recovery action is available.
+
+   The GSS_Accept_sec_context()  routine is used by a context target.
+   Using information in the credentials structure referenced by the
+   input acceptor_cred_handle, it verifies the incoming input_token and
+   (following the successful completion of a context establishment
+   sequence) returns the authenticated src_name and the mech_type used.
+   The returned src_name is guaranteed to be an MN, processed by the
+   mechanism under which the context was established. The
+   acceptor_cred_handle must correspond to the same valid credentials
+   structure on the initial call to GSS_Accept_sec_context() and on any
+   successor calls resulting from GSS_S_CONTINUE_NEEDED status returns;
+   different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED
+   mechanism will require access to credentials at different points in
+   the context establishment sequence.
+
+   The input_context_handle argument is 0, specifying "not yet
+   assigned", on the first GSS_Accept_sec_context()  call relating to a
+   given context.  If successful (i.e., if accompanied by major_status
+   GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the
+   initial GSS_Accept_sec_context() call returns a non-zero
+   output_context_handle for use in future references to this context.
+   Once a non-zero output_context_handle has been returned, GSS-API
+   callers should call GSS_Delete_sec_context() to release context-
+   related resources if errors occur in later phases of context
+   establishment, or when an established context is no longer required.
+
+   The chan_bindings argument is used by the caller to provide
+   information binding the security context to security-related
+   characteristics (e.g., addresses, cryptographic keys) of the
+   underlying communications channel. See Section 1.1.6 of this document
+   for more discussion of this argument's usage.
+
+   The returned state results (deleg_state, mutual_state,
+   replay_det_state, sequence_state, anon_state, trans_state, and
+   prot_ready_state) reflect the same information as described for
+   GSS_Init_sec_context(), and their values are significant under the
+   same return state conditions.
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 43]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   The conf_avail return value indicates whether the context supports
+   per-message confidentiality services, and so informs the caller
+   whether or not a request for encryption through the conf_req_flag
+   input to GSS_Wrap()  can be honored. In similar fashion, the
+   integ_avail return value indicates whether per-message integrity
+   services are available (through either GSS_GetMIC()  or GSS_Wrap())
+   on the established context.  These values are significant under the
+   same return state conditions as described under
+   GSS_Init_sec_context().
+
+   The lifetime_rec return value is significant only in conjunction with
+   GSS_S_COMPLETE major_status, and indicates the length of time for
+   which the context will be valid, expressed as an offset from the
+   present.
+
+   The mech_type return value indicates the specific mechanism employed
+   on the context, is valid only along with major_status GSS_S_COMPLETE,
+   and will never indicate the value for "default".
+
+   The delegated_cred_handle result is significant only when deleg_state
+   is TRUE, and provides a means for the target to reference the
+   delegated credentials. The output_token result, when non-NULL,
+   provides a context-level token to be returned to the context
+   initiator to continue a multi-step context establishment sequence. As
+   noted with GSS_Init_sec_context(),  any returned token should be
+   transferred to the context's peer (in this case, the context
+   initiator), independent of the value of the accompanying returned
+   major_status.
+
+   Note: A target must be able to distinguish a context-level
+   input_token, which is passed to GSS_Accept_sec_context(),  from the
+   per-message data elements passed to GSS_VerifyMIC()  or GSS_Unwrap().
+   These data elements may arrive in a single application message, and
+   GSS_Accept_sec_context()  must be performed before per-message
+   processing can be performed successfully.
+
+2.2.3: GSS_Delete_sec_context call
+
+   Input:
+
+   o  context_handle CONTEXT HANDLE
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 44]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  output_context_token OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the context was recognized, and that
+      relevant context-specific information was flushed.  If the caller
+      provides a non-null buffer to receive an output_context_token, and
+      the mechanism returns a non-NULL token into that buffer, the
+      returned output_context_token is ready for transfer to the
+      context's peer.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided, so no deletion was
+      performed.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but
+      that the GSS_Delete_sec_context()  operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   This call may block pending network interactions for mech_types in
+   which active notification must be made to a central server when a
+   security context is to be deleted.
+
+   This call can be made by either peer in a security context, to flush
+   context-specific information.  If a non-null output_context_token
+   parameter is provided by the caller, an output_context_token may be
+   returned to the caller.  If an output_context_token is provided to
+   the caller, it can be passed to the context's peer to inform the
+   peer's GSS-API implementation that the peer's corresponding context
+   information can also be flushed. (Once a context is established, the
+   peers involved are expected to retain cached credential and context-
+   related information until the information's expiration time is
+   reached or until a GSS_Delete_sec_context() call is made.)
+
+   The facility for context_token usage to signal context deletion is
+   retained for compatibility with GSS-API Version 1.  For current
+   usage, it is recommended that both peers to a context invoke
+   GSS_Delete_sec_context() independently, passing a null
+   output_context_token buffer to indicate that no context_token is
+   required.  Implementations of GSS_Delete_sec_context() should delete
+   relevant locally-stored context information.
+
+   Attempts to perform per-message processing on a deleted context will
+   result in error returns.
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 45]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.2.4:  GSS_Process_context_token call
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  input_context_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the input_context_token was
+      successfully processed in conjunction with the context
+      referenced by context_handle.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
+      performed on the received context_token failed, preventing
+      further processing from being performed with that token.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but
+      that the GSS_Process_context_token()  operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   This call is used to process context_tokens received from a peer once
+   a context has been established, with corresponding impact on
+   context-level state information. One use for this facility is
+   processing of the context_tokens generated by
+   GSS_Delete_sec_context();  GSS_Process_context_token() will not block
+   pending network interactions for that purpose. Another use is to
+   process tokens indicating remote-peer context establishment failures
+   after the point where the local GSS-API implementation has already
+   indicated GSS_S_COMPLETE status.
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 46]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.2.5:  GSS_Context_time call
+
+   Input:
+
+   o  context_handle CONTEXT HANDLE,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  lifetime_rec INTEGER - in seconds, or reserved value for
+      INDEFINITE
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the referenced context is valid,
+      and will remain valid for the amount of time indicated in
+      lifetime_rec.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that data items related to the
+      referenced context have expired.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
+      recognized, but that its associated credentials have expired.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+       reasons unspecified at the GSS-API level.
+
+   This call is used to determine the amount of time for which a
+   currently established context will remain valid.
+
+2.2.6:   GSS_Inquire_context call
+
+   Input:
+
+   o  context_handle CONTEXT HANDLE,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 47]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  src_name INTERNAL NAME,  -- name of context initiator,
+                               -- guaranteed to be MN
+
+   o  targ_name INTERNAL NAME,  -- name of context target,
+                                -- guaranteed to be MN
+
+
+   o  lifetime_rec INTEGER -- in seconds, or reserved value for
+      INDEFINITE,
+
+   o  mech_type OBJECT IDENTIFIER, -- the mechanism supporting this
+      security context
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  anon_state BOOLEAN,
+
+   o  trans_state BOOLEAN,
+
+   o  prot_ready_state BOOLEAN,
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the referenced context is valid
+      and that src_name, targ_name, lifetime_rec, mech_type, deleg_state,
+      mutual_state, replay_det_state, sequence_state, anon_state,
+      trans_state, prot_ready_state, conf_avail, integ_avail, and
+      locally_initiated return values describe the corresponding
+      characteristics of the context.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
+      context_handle is recognized, but that the referenced context
+      has expired.  Return values other than major_status and
+      minor_status are undefined.
+
+
+
+
+
+Linn                        Standards Track                    [Page 48]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided. Return values other than
+      major_status and minor_status are undefined.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+     reasons unspecified at the GSS-API level. Return values other than
+         major_status and minor_status are undefined.
+
+   This call is used to extract information describing characteristics
+   of a security context.
+
+2.2.7:   GSS_Wrap_size_limit call
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  qop INTEGER,
+
+   o  output_size INTEGER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  max_input_size INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates a successful token size determination:
+   an input message with a length in octets equal to the
+   returned max_input_size value will, when passed to GSS_Wrap()
+   for processing on the context identified by the context_handle
+   parameter and with the quality of protection specifier provided
+   in the qop parameter, yield an output token no larger than the
+   value of the provided output_size parameter.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
+   context_handle is recognized, but that the referenced context
+   has expired.  Return values other than major_status and
+   minor_status are undefined.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided. Return values other than
+   major_status and minor_status are undefined.
+
+
+
+
+Linn                        Standards Track                    [Page 49]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
+   recognized or supported for the context.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call is used to determine the largest input datum which may be
+   passed to GSS_Wrap() without yielding an output token larger than a
+   caller-specified value.
+
+2.2.8:   GSS_Export_sec_context call
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  interprocess_token OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the referenced context has been
+   successfully exported to a representation in the interprocess_token,
+   and is no longer available for use by the caller.
+
+   o  GSS_S_UNAVAILABLE indicates that the context export facility
+   is not available for use on the referenced context.  (This status
+   should occur only for contexts for which the trans_state value is
+   FALSE.) Return values other than major_status and minor_status are
+   undefined.
+
+   o GSS_S_CONTEXT_EXPIRED indicates that the provided input
+   context_handle is recognized, but that the referenced context has
+   expired.  Return values other than major_status and minor_status are
+   undefined.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided. Return values other than
+   major_status and minor_status are undefined.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 50]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call generates an interprocess token for transfer to another
+   process within an end system, in order to transfer control of a
+   security context to that process.  The recipient of the interprocess
+   token will call GSS_Import_sec_context() to accept the transfer.  The
+   GSS_Export_sec_context() operation is defined for use only with
+   security contexts which are fully and successfully established (i.e.,
+   those for which GSS_Init_sec_context() and GSS_Accept_sec_context()
+   have returned GSS_S_COMPLETE major_status).
+
+   To ensure portability, a caller of GSS_Export_sec_context() must not
+   assume that a context may continue to be used once it has been
+   exported; following export, the context referenced by the
+   context_handle cannot be assumed to remain valid.  Further, portable
+   callers must not assume that a given interprocess token can be
+   imported by GSS_Import_sec_context() more than once, thereby creating
+   multiple instantiations of a single context.  GSS-API implementations
+   may detect and reject attempted multiple imports, but are not
+   required to do so.
+
+   The internal representation contained within the interprocess token
+   is an implementation-defined local matter.  Interprocess tokens
+   cannot be assumed to be transferable across different GSS-API
+   implementations.
+
+   It is recommended that GSS-API implementations adopt policies suited
+   to their operational environments in order to define the set of
+   processes eligible to import a context, but specific constraints in
+   this area are local matters.  Candidate examples include transfers
+   between processes operating on behalf of the same user identity, or
+   processes comprising a common job.  However, it may be impossible to
+   enforce such policies in some implementations.
+
+   In support of the above goals, implementations may protect the
+   transferred context data by using cryptography to protect data within
+   the interprocess token, or by using interprocess tokens as a means to
+   reference local interprocess communication facilities (protected by
+   other means) rather than storing the context data directly within the
+   tokens.
+
+   Transfer of an open context may, for certain mechanisms and
+   implementations, reveal data about the credential which was used to
+   establish the context.  Callers should, therefore, be cautious about
+   the trustworthiness of processes to which they transfer contexts.
+   Although the GSS-API implementation may provide its own set of
+
+
+
+Linn                        Standards Track                    [Page 51]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   protections over the exported context, the caller is responsible for
+   protecting the interprocess token from disclosure, and for taking
+   care that the context is transferred to an appropriate destination
+   process.
+
+2.2.9:   GSS_Import_sec_context call
+
+   Inputs:
+
+   o  interprocess_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  context_handle CONTEXT HANDLE
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the context represented by the
+   input interprocess_token has been successfully transferred to
+   the caller, and is available for future use via the output
+   context_handle.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that the context represented by
+   the input interprocess_token has expired. Return values other
+   than major_status and minor_status are undefined.
+
+   o  GSS_S_NO_CONTEXT indicates that the context represented by the
+   input interprocess_token was invalid. Return values other than
+   major_status and minor_status are undefined.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token
+   was defective.  Return values other than major_status and
+   minor_status are undefined.
+
+   o  GSS_S_UNAVAILABLE indicates that the context import facility
+   is not available for use on the referenced context.  Return values
+   other than major_status and minor_status are undefined.
+
+   o  GSS_S_UNAUTHORIZED indicates that the context represented by
+   the input interprocess_token is unauthorized for transfer to the
+   caller. Return values other than major_status and minor_status
+   are undefined.
+
+
+
+
+
+Linn                        Standards Track                    [Page 52]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call processes an interprocess token generated by
+   GSS_Export_sec_context(), making the transferred context available
+   for use by the caller.  After a successful GSS_Import_sec_context()
+   operation, the imported context is available for use by the importing
+   process.
+
+   For further discussion of the security and authorization issues
+   regarding this call, please see the discussion in Section 2.2.8.
+
+2.3:  Per-message calls
+
+   This group of calls is used to perform per-message protection
+   processing on an established security context. None of these calls
+   block pending network interactions. These calls may be invoked by a
+   context's initiator or by the context's target.  The four members of
+   this group should be considered as two pairs; the output from
+   GSS_GetMIC()  is properly input to GSS_VerifyMIC(),  and the output
+   from GSS_Wrap() is properly input to GSS_Unwrap().
+
+   GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication
+   and data integrity services. When GSS_GetMIC()  is invoked on an
+   input message, it yields a per-message token containing data items
+   which allow underlying mechanisms to provide the specified security
+   services. The original message, along with the generated per-message
+   token, is passed to the remote peer; these two data elements are
+   processed by GSS_VerifyMIC(),  which validates the message in
+   conjunction with the separate token.
+
+   GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality
+   in addition to the data origin authentication and data integrity
+   services offered by GSS_GetMIC()  and GSS_VerifyMIC(). GSS_Wrap()
+   outputs a single data element, encapsulating optionally enciphered
+   user data as well as associated token data items.  The data element
+   output from GSS_Wrap()  is passed to the remote peer and processed by
+   GSS_Unwrap()  at that system. GSS_Unwrap() combines decipherment (as
+   required) with validation of data items related to authentication and
+   integrity.
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 53]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.3.1:  GSS_GetMIC call
+
+   Note: This call is functionally equivalent to the GSS_Sign call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Sign are deprecated.
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  qop_req INTEGER,-0 specifies default QOP
+
+   o  message OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  per_msg_token OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that an integrity check, suitable for an
+      established security context, was successfully applied and
+      that the message and corresponding per_msg_token are ready
+      for transmission.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
+      items have expired, so that the requested operation cannot be
+      performed.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is recognized,
+      but that its associated credentials have expired, so
+      that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.
+
+   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
+      recognized or supported for the context.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but
+      that the requested operation could not be performed for
+      reasons unspecified at the GSS-API level.
+
+
+
+Linn                        Standards Track                    [Page 54]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Using the security context referenced by context_handle, apply an
+   integrity check to the input message (along with timestamps and/or
+   other data included in support of mech_type-specific mechanisms) and
+   return the result in per_msg_token. The qop_req parameter,
+   interpretation of which is discussed in Section 1.2.4, allows
+   quality-of-protection control. The caller passes the message and the
+   per_msg_token to the target.
+
+   The GSS_GetMIC()  function completes before the message and
+   per_msg_token is sent to the peer; successful application of
+   GSS_GetMIC()  does not guarantee that a corresponding GSS_VerifyMIC()
+   has been (or can necessarily be) performed successfully when the
+   message arrives at the destination.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.3.2:  GSS_VerifyMIC call
+
+   Note: This call is functionally equivalent to the GSS_Verify call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Verify are deprecated.
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  message OCTET STRING,
+
+   o  per_msg_token OCTET STRING
+
+   Outputs:
+
+   o  qop_state INTEGER,
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the message was successfully
+      verified.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 55]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+      on the received per_msg_token failed, preventing
+      further processing from being performed with that token.
+
+   o  GSS_S_BAD_SIG indicates that the received per_msg_token contains
+      an incorrect integrity check for the message.
+
+   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN,
+      and GSS_S_GAP_TOKEN values appear in conjunction with the
+      optional per-message replay detection features described
+      in Section 1.2.3; their semantics are described in that section.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
+      items have expired, so that the requested operation cannot be
+      performed.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
+   recognized,
+      but that its associated credentials have expired, so
+      that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but
+      that the GSS_VerifyMIC() operation could not be performed for
+      reasons unspecified at the GSS-API level.
+
+   Using the security context referenced by context_handle, verify that
+   the input per_msg_token contains an appropriate integrity check for
+   the input message, and apply any active replay detection or
+   sequencing features. Return an indication of the quality-of-
+   protection applied to the processed message in the qop_state result.
+   Since the GSS_VerifyMIC() routine never provides a confidentiality
+   service, its implementations should not return non-zero values in the
+   confidentiality fields of the output qop_state.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.3.3: GSS_Wrap call
+
+   Note: This call is functionally equivalent to the GSS_Seal call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Seal are deprecated.
+
+
+
+
+Linn                        Standards Track                    [Page 56]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  conf_req_flag BOOLEAN,
+
+   o  qop_req INTEGER,-0 specifies default QOP
+
+   o  input_message OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  conf_state BOOLEAN,
+
+   o  output_message OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the input_message was successfully
+      processed and that the output_message is ready for
+      transmission.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
+      items have expired, so that the requested operation cannot be
+      performed.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
+   recognized,
+      but that its associated credentials have expired, so
+      that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.
+
+   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
+      recognized or supported for the context.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but
+      that the GSS_Wrap()  operation could not be performed for
+      reasons unspecified at the GSS-API level.
+
+   Performs the data origin authentication and data integrity functions
+   of GSS_GetMIC().  If the input conf_req_flag is TRUE, requests that
+   confidentiality be applied to the input_message.  Confidentiality may
+
+
+
+Linn                        Standards Track                    [Page 57]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   not be supported in all mech_types or by all implementations; the
+   returned conf_state flag indicates whether confidentiality was
+   provided for the input_message. The qop_req parameter, interpretation
+   of which is discussed in Section 1.2.4, allows quality-of-protection
+   control.
+
+   In all cases, the GSS_Wrap()  call yields a single output_message
+   data element containing (optionally enciphered) user data as well as
+   control information.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.3.4: GSS_Unwrap call
+
+   Note: This call is functionally equivalent to the GSS_Unseal call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Unseal are deprecated.
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  input_message OCTET STRING
+
+   Outputs:
+
+   o  conf_state BOOLEAN,
+
+   o  qop_state INTEGER,
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_message OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the input_message was
+      successfully processed and that the resulting output_message is
+      available.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+      on the per_msg_token extracted from the input_message
+      failed, preventing further processing from being performed.
+
+
+
+Linn                        Standards Track                    [Page 58]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_BAD_SIG indicates that an incorrect integrity check was
+   detected
+      for the message.
+
+   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN,
+      and GSS_S_GAP_TOKEN values appear in conjunction with the
+      optional per-message replay detection features described
+      in Section 1.2.3; their semantics are described in that section.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
+      items have expired, so that the requested operation cannot be
+      performed.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
+   recognized,
+      but that its associated credentials have expired, so
+      that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+      for the input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but
+      that the GSS_Unwrap()  operation could not be performed for
+      reasons unspecified at the GSS-API level.
+
+   Processes a data element generated (and optionally enciphered) by
+   GSS_Wrap(),  provided as input_message. The returned conf_state value
+   indicates whether confidentiality was applied to the input_message.
+   If conf_state is TRUE, GSS_Unwrap()  deciphers the input_message.
+   Returns an indication of the quality-of-protection applied to the
+   processed message in the qop_state result. GSS_Wrap()  performs the
+   data integrity and data origin authentication checking functions of
+   GSS_VerifyMIC()  on the plaintext data. Plaintext data is returned in
+   output_message.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.4:  Support calls
+
+   This group of calls provides support functions useful to GSS-API
+   callers, independent of the state of established contexts. Their
+   characterization with regard to blocking or non-blocking status in
+   terms of network interactions is unspecified.
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 59]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.4.1:  GSS_Display_status call
+
+   Inputs:
+
+   o  status_value INTEGER,-GSS-API major_status or minor_status
+      return value
+
+   o  status_type INTEGER,-1 if major_status, 2 if minor_status
+
+   o  mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
+      status translation
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  status_string_set SET OF OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a valid printable status
+      representation (possibly representing more than one status event
+      encoded within the status_value) is available in the returned
+      status_string_set.
+
+   o  GSS_S_BAD_MECH indicates that translation in accordance with an
+      unsupported mech_type was requested, so translation could not
+      be performed.
+
+   o  GSS_S_BAD_STATUS indicates that the input status_value was
+      invalid, or that the input status_type carried a value other
+      than 1 or 2, so translation could not be performed.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Provides a means for callers to translate GSS-API-returned major and
+   minor status codes into printable string representations.
+
+2.4.2:  GSS_Indicate_mechs call
+
+   Input:
+
+   o  (none)
+
+
+
+
+
+Linn                        Standards Track                    [Page 60]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a set of available mechanisms has
+      been returned in mech_set.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of mechanism types available on
+   the local system. This call is intended for support of specialized
+   callers who need to request non-default mech_type sets from
+   GSS_Acquire_cred(),  and should not be needed by other callers.
+
+2.4.3:  GSS_Compare_name call
+
+   Inputs:
+
+   o  name1 INTERNAL NAME,
+
+   o  name2 INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_equal BOOLEAN
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that name1 and name2 were comparable,
+      and that the name_equal result indicates whether name1 and
+      name2 represent the same entity.
+
+   o  GSS_S_BAD_NAMETYPE indicates that one or both of name1 and
+      name2 contained internal type specifiers uninterpretable
+      by the applicable underlying GSS-API mechanism(s), or that
+      the two names' types are different and incomparable, so that
+      the comparison operation could not be completed.
+
+
+
+Linn                        Standards Track                    [Page 61]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_BAD_NAME indicates that one or both of the input names
+      was ill-formed in terms of its internal type specifier, so
+      the comparison operation could not be completed.
+
+   o  GSS_S_FAILURE indicates that the call's operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to compare two internal name representations to
+   determine whether they refer to the same entity.  If either name
+   presented to GSS_Compare_name() denotes an anonymous principal,
+   GSS_Compare_name() shall indicate FALSE.  It is not required that
+   either or both inputs name1 and name2 be MNs; for some
+   implementations and cases, GSS_S_BAD_NAMETYPE may be returned,
+   indicating name incomparability, for the case where neither input
+   name is an MN.
+
+2.4.4:  GSS_Display_name call
+
+   Inputs:
+
+   o  name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_string OCTET STRING,
+
+   o  name_type OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a valid printable name
+      representation is available in the returned name_string.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided name was of a
+      type uninterpretable by the applicable underlying GSS-API
+      mechanism(s), so no printable representation could be generated.
+
+   o  GSS_S_BAD_NAME indicates that the contents of the provided name
+      were inconsistent with the internally-indicated name type, so
+      no printable representation could be generated.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+
+
+
+Linn                        Standards Track                    [Page 62]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Allows callers to translate an internal name representation into a
+   printable form with associated namespace type descriptor. The syntax
+   of the printable form is a local matter.
+
+   If the input name represents an anonymous identity, a reserved value
+   (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
+
+2.4.5:  GSS_Import_name call
+
+   Inputs:
+
+   o  input_name_string OCTET STRING,
+
+   o  input_name_type OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_name INTERNAL NAME
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a valid name representation is
+      output in output_name and described by the type value in
+      output_name_type.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input_name_type is unsupported
+      by the applicable underlying GSS-API mechanism(s), so the import
+      operation could not be completed.
+
+   o  GSS_S_BAD_NAME indicates that the provided input_name_string
+      is ill-formed in terms of the input_name_type, so the import
+      operation could not be completed.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to provide a name representation as a contiguous octet
+   string, designate the type of namespace in conjunction with which it
+   should be parsed, and convert that representation to an internal form
+   suitable for input to other GSS-API routines.  The syntax of the
+   input_name_string is defined in conjunction with its associated name
+   type; depending on the input_name_type, the associated
+   input_name_string may or may not be a printable string. Note: The
+   input_name_type argument serves to describe and qualify the
+
+
+
+Linn                        Standards Track                    [Page 63]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   interpretation of the associated input_name_string; it does not
+   specify the data type of the returned output_name.
+
+   If a mechanism claims support for a particular name type, its
+   GSS_Import_name() operation shall be able to accept all possible
+   values conformant to the external name syntax as defined for that
+   name type.  These imported values may correspond to:
+
+      (1) locally registered entities (for which credentials may be
+      acquired),
+
+      (2) non-local entities (for which local credentials cannot be
+      acquired, but which may be referenced as targets of initiated
+      security contexts or initiators of accepted security contexts), or
+      to
+
+      (3) neither of the above.
+
+   Determination of whether a particular name belongs to class (1), (2),
+   or (3) as described above is not guaranteed to be performed by the
+   GSS_Import_name() function.
+
+   The internal name generated by a GSS_Import_name() operation may be a
+   single-mechanism MN, and is likely to be an MN within a single-
+   mechanism implementation, but portable callers must not depend on
+   this property (and must not, therefore, assume that the output from
+   GSS_Import_name() can be passed directly to GSS_Export_name() without
+   first being processed through GSS_Canonicalize_name()).
+
+2.4.6: GSS_Release_name call
+
+   Inputs:
+
+   o  name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the storage associated with the
+      input name was successfully released.
+
+   o  GSS_S_BAD_NAME indicates that the input name argument did not
+      contain a valid name.
+
+
+
+Linn                        Standards Track                    [Page 64]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an internal
+   name representation.  This call's specific behavior depends on the
+   language and programming environment within which a GSS-API
+   implementation operates, and is therefore detailed within applicable
+   bindings specifications; in particular, this call may be superfluous
+   within bindings where memory management is automatic.
+
+2.4.7: GSS_Release_buffer call
+
+   Inputs:
+
+   o  buffer OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the storage associated with the
+      input buffer was successfully released.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an OCTET STRING
+   buffer allocated by another GSS-API call.  This call's specific
+   behavior depends on the language and programming environment within
+   which a GSS-API implementation operates, and is therefore detailed
+   within applicable bindings specifications; in particular, this call
+   may be superfluous within bindings where memory management is
+   automatic.
+
+2.4.8: GSS_Release_OID_set call
+
+   Inputs:
+
+   o  buffer SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 65]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the storage associated with the
+      input object identifier set was successfully released.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an object
+   identifier set object allocated by another GSS-API call.  This call's
+   specific behavior depends on the language and programming environment
+   within which a GSS-API implementation operates, and is therefore
+   detailed within applicable bindings specifications; in particular,
+   this call may be superfluous within bindings where memory management
+   is automatic.
+
+2.4.9: GSS_Create_empty_OID_set call
+
+   Inputs:
+
+   o  (none)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  oid_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   Creates an object identifier set containing no object identifiers, to
+   which members may be subsequently added using the
+   GSS_Add_OID_set_member() routine.  These routines are intended to be
+   used to construct sets of mechanism object identifiers, for input to
+   GSS_Acquire_cred().
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 66]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+2.4.10: GSS_Add_OID_set_member call
+
+   Inputs:
+
+   o  member_oid OBJECT IDENTIFIER,
+
+   o  oid_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   Adds an Object Identifier to an Object Identifier set.  This routine
+   is intended for use in conjunction with GSS_Create_empty_OID_set()
+   when constructing a set of mechanism OIDs for input to
+   GSS_Acquire_cred().
+
+2.4.11: GSS_Test_OID_set_member call
+
+   Inputs:
+
+   o  member OBJECT IDENTIFIER,
+
+   o  set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  present BOOLEAN
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+
+
+
+
+Linn                        Standards Track                    [Page 67]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Interrogates an Object Identifier set to determine whether a
+   specified Object Identifier is a member.  This routine is intended to
+   be used with OID sets returned by GSS_Indicate_mechs(),
+   GSS_Acquire_cred(), and GSS_Inquire_cred().
+
+2.4.12: GSS_Release_OID call
+
+   Inputs:
+
+   o  oid OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   Allows the caller to release the storage associated with an OBJECT
+   IDENTIFIER buffer allocated by another GSS-API call. This call's
+   specific behavior depends on the language and programming environment
+   within which a GSS-API implementation operates, and is therefore
+   detailed within applicable bindings specifications; in particular,
+   this call may be superfluous within bindings where memory management
+   is automatic.
+
+2.4.13: GSS_OID_to_str call
+
+   Inputs:
+
+   o  oid OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  oid_str OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+
+
+Linn                        Standards Track                    [Page 68]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   The function GSS_OID_to_str() returns a string representing the input
+   OID in numeric ASN.1 syntax format (curly-brace enclosed, space-
+   delimited, e.g., "{2 16 840 1 113687 1 2 1}"). The string is
+   releasable using GSS_Release_buffer(). If the input "oid" does not
+   represent a syntactically valid object identifier, GSS_S_FAILURE
+   status is returned and the returned oid_str result is NULL.
+
+2.4.14: GSS_Str_to_OID call
+
+   Inputs:
+
+   o  oid_str OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  oid OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   The function GSS_Str_to_OID() constructs and returns an OID from its
+   printable form; implementations should be able to accept the numeric
+   ASN.1 syntax form as described for GSS_OID_to_str(), and this form
+   should be used for portability, but implementations of this routine
+   may also accept other formats (e.g., "1.2.3.3"). The OID is suitable
+   for release using the function GSS_Release_OID(). If the input
+   oid_str cannot be translated into an OID, GSS_S_FAILURE status is
+   returned and the "oid" result is NULL.
+
+2.4.15:  GSS_Inquire_names_for_mech call
+
+   Input:
+
+   o  input_mech_type OBJECT IDENTIFIER, -- mechanism type
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 69]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   o  minor_status INTEGER,
+
+   o  name_type_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the output name_type_set contains
+      a list of name types which are supported by the locally available
+      mechanism identified by input_mech_type.
+
+   o  GSS_S_BAD_MECH indicates that the mechanism identified by
+      input_mech_type was unsupported within the local implementation,
+      causing the query to fail.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of name types which are
+   supportable by a specific locally-available mechanism.
+
+2.4.16: GSS_Inquire_mechs_for_name call
+
+   Inputs:
+
+   o  input_name INTERNAL NAME,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_types SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a set of object identifiers,
+      corresponding to the set of mechanisms suitable for processing
+      the input_name, is available in mech_types.
+
+   o  GSS_S_BAD_NAME indicates that the input_name could not be
+      processed.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the type of the input_name
+      is unsupported by the GSS-API implementation.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+
+
+Linn                        Standards Track                    [Page 70]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   This routine returns the mechanism set with which the input_name may
+   be processed.  After use, the mech_types object should be freed by
+   the caller via the GSS_Release_OID_set() call.  Note: it is
+   anticipated that implementations of GSS_Inquire_mechs_for_name() will
+   commonly operate based on type information describing the
+   capabilities of available mechanisms; it is not guaranteed that all
+   identified mechanisms will necessarily be able to canonicalize (via
+   GSS_Canonicalize_name()) a particular name.
+
+2.4.17: GSS_Canonicalize_name call
+
+   Inputs:
+
+   o  input_name INTERNAL NAME,
+
+   o  mech_type OBJECT IDENTIFIER  -- must be explicit mechanism,
+                                      not "default" specifier
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_name INTERNAL NAME
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a mechanism-specific reduction of
+      the input_name, as processed by the mechanism identified by
+      mech_type, is available in output_name.
+
+   o  GSS_S_BAD_MECH indicates that the identified mechanism is
+      unsupported.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input name does not
+      contain an element with suitable type for processing by the
+      identified mechanism.
+
+   o  GSS_S_BAD_NAME indicates that the input name contains an
+      element with suitable type for processing by the identified
+      mechanism, but that this element could not be processed
+      successfully.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+
+
+
+
+Linn                        Standards Track                    [Page 71]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   This routine reduces a GSS-API internal name, which may in general
+   contain elements corresponding to multiple mechanisms, to a
+   mechanism-specific Mechanism Name (MN) by applying the translations
+   corresponding to the mechanism identified by mech_type.
+
+2.4.18: GSS_Export_name call
+
+   Inputs:
+
+   o  input_name INTERNAL NAME, -- required to be MN
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_name OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a flat representation of the
+      input name is available in output_name.
+
+   o  GSS_S_NAME_NOT_MN indicates that the input name contained
+      elements corresponding to multiple mechanisms, so cannot
+      be exported into a single-mechanism flat form.
+
+   o  GSS_S_BAD_NAME indicates that the input name was an MN,
+      but could not be processed.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input name was an MN,
+      but that its type is unsupported by the GSS-API implementation.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   This routine creates a flat name representation, suitable for
+   bytewise comparison or for input to GSS_Import_name() in conjunction
+   with the reserved GSS-API Exported Name Object OID, from a internal-
+   form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name()
+   or GSS_Accept_sec_context().
+
+   The emitted GSS-API Exported Name Object is self-describing; no
+   associated parameter-level OID need be emitted by this call.  This
+   flat representation consists of a mechanism-independent wrapper
+   layer, defined in Section 3.2 of this document, enclosing a
+   mechanism-defined name representation.
+
+
+
+Linn                        Standards Track                    [Page 72]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   In all cases, the flat name output by GSS_Export_name() to correspond
+   to a particular input MN must be invariant over time within a
+   particular installation.
+
+   The GSS_S_NAME_NOT_MN status code is provided to enable
+   implementations to reject input names which are not MNs.  It is not,
+   however, required for purposes of conformance to this specification
+   that all non-MN input names must necessarily be rejected.
+
+2.4.19: GSS_Duplicate_name call
+
+   Inputs:
+
+   o  src_name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  dest_name INTERNAL NAME
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that dest_name references an internal
+      name object containing the same name as passed to src_name.
+
+   o  GSS_S_BAD_NAME indicates that the input name was invalid.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input name's type
+      is unsupported by the GSS-API implementation.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not
+      be performed for reasons unspecified at the GSS-API level.
+
+   This routine takes input internal name src_name, and returns another
+   reference (dest_name) to that name which can be used even if src_name
+   is later freed.  (Note: This may be implemented by copying or through
+   use of reference counts.)
+
+3: Data Structure Definitions for GSS-V2 Usage
+
+   Subsections of this section define, for interoperability and
+   portability purposes, certain data structures for use with GSS-V2.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 73]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+3.1: Mechanism-Independent Token Format
+
+   This section specifies a mechanism-independent level of encapsulating
+   representation for the initial token of a GSS-API context
+   establishment sequence, incorporating an identifier of the mechanism
+   type to be used on that context and enabling tokens to be interpreted
+   unambiguously at GSS-API peers. Use of this format is required for
+   initial context establishment tokens of Internet standards-track
+   GSS-API mechanisms; use in non-initial tokens is optional.
+
+   The encoding format for the token tag is derived from ASN.1 and DER
+   (per illustrative ASN.1 syntax included later within this
+   subsection), but its concrete representation is defined directly in
+   terms of octets rather than at the ASN.1 level in order to facilitate
+   interoperable implementation without use of general ASN.1 processing
+   code.  The token tag consists of the following elements, in order:
+
+      1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
+      constructed form, definite length encoding follows.
+
+      2. Token length octets, specifying length of subsequent data
+      (i.e., the summed lengths of elements 3-5 in this list, and of the
+      mechanism-defined token object following the tag).  This element
+      comprises a variable number of octets:
+
+      2a. If the indicated value is less than 128, it shall be
+      represented in a single octet with bit 8 (high order) set to "0"
+      and the remaining bits representing the value.
+
+      2b. If the indicated value is 128 or more, it shall be represented
+      in two or more octets, with bit 8 of the first octet set to "1"
+      and the remaining bits of the first octet specifying the number of
+      additional octets.  The subsequent octets carry the value, 8 bits
+      per octet, most significant digit first.  The minimum number of
+      octets shall be used to encode the length (i.e., no octets
+      representing leading zeros shall be included within the length
+      encoding).
+
+      3. 0x06 -- Tag for OBJECT IDENTIFIER
+
+      4. Object identifier length -- length (number of octets) of the
+      encoded object identifier contained in element 5, encoded per
+      rules as described in 2a. and 2b. above.
+
+      5. Object identifier octets -- variable number of octets, encoded
+      per ASN.1 BER rules:
+
+
+
+
+
+Linn                        Standards Track                    [Page 74]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+      5a. The first octet contains the sum of two values: (1) the top-
+      level object identifier component, multiplied by 40 (decimal), and
+      (2) the second-level object identifier component.  This special
+      case is the only point within an object identifier encoding where
+      a single octet represents contents of more than one component.
+
+      5b. Subsequent octets, if required, encode successively-lower
+      components in the represented object identifier.  A component's
+      encoding may span multiple octets, encoding 7 bits per octet (most
+      significant bits first) and with bit 8 set to "1" on all but the
+      final octet in the component's encoding.  The minimum number of
+      octets shall be used to encode each component (i.e., no octets
+      representing leading zeros shall be included within a component's
+      encoding).
+
+      (Note: In many implementations, elements 3-5 may be stored and
+      referenced as a contiguous string constant.)
+
+   The token tag is immediately followed by a mechanism-defined token
+   object.  Note that no independent size specifier intervenes following
+   the object identifier value to indicate the size of the mechanism-
+   defined token object.  While ASN.1 usage within mechanism-defined
+   tokens is permitted, there is no requirement that the mechanism-
+   specific innerContextToken, innerMsgToken, and sealedUserData data
+   elements must employ ASN.1 BER/DER encoding conventions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 75]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   The following ASN.1 syntax is included for descriptive purposes only,
+   to illustrate structural relationships among token and tag objects.
+   For interoperability purposes, token and tag encoding shall be
+   performed using the concrete encoding procedures described earlier in
+   this subsection.
+
+       GSS-API DEFINITIONS ::=
+
+       BEGIN
+
+       MechType ::= OBJECT IDENTIFIER
+       -- data structure definitions
+
+       -- callers must be able to distinguish among
+       -- InitialContextToken, SubsequentContextToken,
+       -- PerMsgToken, and SealedMessage data elements
+       -- based on the usage in which they occur
+
+       InitialContextToken ::=
+       -- option indication (delegation, etc.) indicated within
+       -- mechanism-specific token
+       [APPLICATION 0] IMPLICIT SEQUENCE {
+               thisMech MechType,
+               innerContextToken ANY DEFINED BY thisMech
+                  -- contents mechanism-specific
+                  -- ASN.1 structure not required
+               }
+
+       SubsequentContextToken ::= innerContextToken ANY
+       -- interpretation based on predecessor InitialContextToken
+       -- ASN.1 structure not required
+
+       PerMsgToken ::=
+       -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
+       -- ASN.1 structure not required
+               innerMsgToken ANY
+
+       SealedMessage ::=
+       -- as emitted by GSS_Wrap and processed by GSS_Unwrap
+       -- includes internal, mechanism-defined indicator
+       -- of whether or not encrypted
+       -- ASN.1 structure not required
+               sealedUserData ANY
+
+       END
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 76]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+3.2: Mechanism-Independent Exported Name Object Format
+
+   This section specifies a mechanism-independent level of encapsulating
+   representation for names exported via the GSS_Export_name() call,
+   including an object identifier representing the exporting mechanism.
+   The format of names encapsulated via this representation shall be
+   defined within individual mechanism drafts.  Name objects of this
+   type will be identified with the following Object Identifier:
+
+   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
+   4(gss-api-exported-name)}
+
+   No name type OID is included in this mechanism-independent level of
+   format definition, since (depending on individual mechanism
+   specifications) the enclosed name may be implicitly typed or may be
+   explicitly typed using a means other than OID encoding.
+
+        Length    Name          Description
+
+        2               TOK_ID          Token Identifier
+                                        For exported name objects, this
+                                        must be hex 04 01.
+        2               MECH_OID_LEN    Length of the Mechanism OID
+        MECH_OID_LEN    MECH_OID        Mechanism OID, in DER
+        4               NAME_LEN        Length of name
+        NAME_LEN        NAME            Exported name; format defined in
+                                        applicable mechanism draft.
+
+4: Name Type Definitions
+
+   This section includes definitions for name types and associated
+   syntaxes which are defined in a mechanism-independent fashion at the
+   GSS-API level rather than being defined in individual mechanism
+   specifications.
+
+4.1: Host-Based Service Name Form
+
+   The following Object Identifier value is provided as a means to
+   identify this name form:
+
+   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
+   2(gss-host-based-services)}
+
+   The recommended symbolic name for this type is
+   "GSS_C_NT_HOSTBASED_SERVICE".
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 77]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   This name type is used to represent services associated with host
+   computers.  This name form is constructed using two elements,
+   "service" and "hostname", as follows:
+
+                             service@hostname
+
+   When a reference to a name of this type is resolved, the "hostname"
+   is canonicalized by attempting a DNS lookup and using the fully-
+   qualified domain name which is returned, or by using the "hostname"
+   as provided if the DNS lookup fails.  The canonicalization operation
+   also maps the host's name into lower-case characters.
+
+   The "hostname" element may be omitted. If no "@" separator is
+   included, the entire name is interpreted as the service specifier,
+   with the "hostname" defaulted to the canonicalized name of the local
+   host.
+
+   Values for the "service" element are registered with the IANA.
+
+4.2: User Name Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) user_name(1)}. The recommended mechanism-independent
+   symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
+   name form and OID is defined within the Kerberos V5 GSS-API
+   mechanism, but the symbolic name recommended there begins with a
+   "GSS_KRB5_NT_" prefix.)
+
+   This name type is used to indicate a named user on a local system.
+   Its interpretation is OS-specific.  This name form is constructed as:
+
+                                 username
+
+4.3: Machine UID Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) machine_uid_name(2)}.  The recommended mechanism-
+   independent symbolic name for this type is
+   "GSS_C_NT_MACHINE_UID_NAME".  (Note: the same name form and OID is
+   defined within the Kerberos V5 GSS-API mechanism, but the symbolic
+   name recommended there begins with a "GSS_KRB5_NT_" prefix.)
+
+   This name type is used to indicate a numeric user identifier
+   corresponding to a user on a local system.  Its interpretation is
+   OS-specific.  The gss_buffer_desc representing a name of this type
+   should contain a locally-significant uid_t, represented in host byte
+
+
+
+Linn                        Standards Track                    [Page 78]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   order.  The GSS_Import_name() operation resolves this uid into a
+   username, which is then treated as the User Name Form.
+
+4.4: String UID Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) string_uid_name(3)}.  The recommended symbolic name for
+   this type is "GSS_C_NT_STRING_UID_NAME".  (Note: the same name form
+   and OID is defined within the Kerberos V5 GSS-API mechanism, but the
+   symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
+
+   This name type is used to indicate a string of digits representing
+   the numeric user identifier of a user on a local system.  Its
+   interpretation is OS-specific. This name type is similar to the
+   Machine UID Form, except that the buffer contains a string
+   representing the uid_t.
+
+5:  Mechanism-Specific Example Scenarios
+
+   This section provides illustrative overviews of the use of various
+   candidate mechanism types to support the GSS-API. These discussions
+   are intended primarily for readers familiar with specific security
+   technologies, demonstrating how GSS-API functions can be used and
+   implemented by candidate underlying mechanisms. They should not be
+   regarded as constrictive to implementations or as defining the only
+   means through which GSS-API functions can be realized with a
+   particular underlying technology, and do not demonstrate all GSS-API
+   features with each technology.
+
+5.1: Kerberos V5, single-TGT
+
+   OS-specific login functions yield a TGT to the local realm Kerberos
+   server; TGT is placed in a credentials structure for the client.
+   Client calls GSS_Acquire_cred()  to acquire a cred_handle in order to
+   reference the credentials for use in establishing security contexts.
+
+   Client calls GSS_Init_sec_context().  If the requested service is
+   located in a different realm, GSS_Init_sec_context()  gets the
+   necessary TGT/key pairs needed to traverse the path from local to
+   target realm; these data are placed in the owner's TGT cache. After
+   any needed remote realm resolution, GSS_Init_sec_context()  yields a
+   service ticket to the requested service with a corresponding session
+   key; these data are stored in conjunction with the context. GSS-API
+   code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
+   response(s) (in the successful case) or KRB_ERROR.
+
+
+
+
+
+Linn                        Standards Track                    [Page 79]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   Assuming success, GSS_Init_sec_context()  builds a Kerberos-formatted
+   KRB_AP_REQ message, and returns it in output_token.  The client sends
+   the output_token to the service.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(),  which verifies the authenticator, provides
+   the service with the client's authenticated name, and returns an
+   output_context_handle.
+
+   Both parties now hold the session key associated with the service
+   ticket, and can use this key in subsequent GSS_GetMIC(),
+   GSS_VerifyMIC(),  GSS_Wrap(), and GSS_Unwrap() operations.
+
+5.2: Kerberos V5, double-TGT
+
+   TGT acquisition as above.
+
+   Note: To avoid unnecessary frequent invocations of error paths when
+   implementing the GSS-API atop Kerberos V5, it seems appropriate to
+   represent "single-TGT K-V5" and "double-TGT K-V5" with separate
+   mech_types, and this discussion makes that assumption.
+
+   Based on the (specified or defaulted) mech_type,
+   GSS_Init_sec_context()  determines that the double-TGT protocol
+   should be employed for the specified target. GSS_Init_sec_context()
+   returns GSS_S_CONTINUE_NEEDED major_status, and its returned
+   output_token contains a request to the service for the service's TGT.
+   (If a service TGT with suitably long remaining lifetime already
+   exists in a cache, it may be usable, obviating the need for this
+   step.) The client passes the output_token to the service.  Note: this
+   scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED
+   status return facility than for support of mutual authentication;
+   note that both uses can coexist as successive operations within a
+   single context establishment operation.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(),  which recognizes it as a request for TGT.
+   (Note that current Kerberos V5 defines no intra-protocol mechanism to
+   represent such a request.) GSS_Accept_sec_context()  returns
+   GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in
+   its output_token. The service sends the output_token to the client.
+
+   The client passes the received token as the input_token argument to a
+   continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
+   the received service TGT and uses it as part of a service ticket
+   request to the Kerberos authentication server, storing the returned
+   service ticket and session key in conjunction with the context.
+   GSS_Init_sec_context()  builds a Kerberos-formatted authenticator,
+
+
+
+Linn                        Standards Track                    [Page 80]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   and returns it in output_token along with GSS_S_COMPLETE return
+   major_status. The client sends the output_token to the service.
+
+   Service passes the received token as the input_token argument to a
+   continuation call to GSS_Accept_sec_context().
+   GSS_Accept_sec_context()  verifies the authenticator, provides the
+   service with the client's authenticated name, and returns
+   major_status GSS_S_COMPLETE.
+
+   GSS_GetMIC(),  GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap()  as
+   above.
+
+5.3:  X.509 Authentication Framework
+
+   This example illustrates use of the GSS-API in conjunction with
+   public-key mechanisms, consistent with the X.509 Directory
+   Authentication Framework.
+
+   The GSS_Acquire_cred()  call establishes a credentials structure,
+   making the client's private key accessible for use on behalf of the
+   client.
+
+   The client calls GSS_Init_sec_context(),  which interrogates the
+   Directory to acquire (and validate) a chain of public-key
+   certificates, thereby collecting the public key of the service.  The
+   certificate validation operation determines that suitable integrity
+   checks were applied by trusted authorities and that those
+   certificates have not expired. GSS_Init_sec_context()  generates a
+   secret key for use in per-message protection operations on the
+   context, and enciphers that secret key under the service's public
+   key.
+
+   The enciphered secret key, along with an authenticator quantity
+   signed with the client's private key, is included in the output_token
+   from GSS_Init_sec_context().  The output_token also carries a
+   certification path, consisting of a certificate chain leading from
+   the service to the client; a variant approach would defer this path
+   resolution to be performed by the service instead of being asserted
+   by the client. The client application sends the output_token to the
+   service.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context().  GSS_Accept_sec_context() validates the
+   certification path, and as a result determines a certified binding
+   between the client's distinguished name and the client's public key.
+   Given that public key, GSS_Accept_sec_context() can process the
+   input_token's authenticator quantity and verify that the client's
+   private key was used to sign the input_token. At this point, the
+
+
+
+Linn                        Standards Track                    [Page 81]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   client is authenticated to the service. The service uses its private
+   key to decipher the enciphered secret key provided to it for per-
+   message protection operations on the context.
+
+   The client calls GSS_GetMIC()  or GSS_Wrap() on a data message, which
+   causes per-message authentication, integrity, and (optional)
+   confidentiality facilities to be applied to that message. The service
+   uses the context's shared secret key to perform corresponding
+   GSS_VerifyMIC()  and GSS_Unwrap() calls.
+
+6:  Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+7:  Related Activities
+
+   In order to implement the GSS-API atop existing, emerging, and future
+   security mechanisms:
+
+      object identifiers must be assigned to candidate GSS-API
+      mechanisms and the name types which they support
+
+      concrete data element formats and processing procedures must be
+      defined for candidate mechanisms
+
+   Calling applications must implement formatting conventions which will
+   enable them to distinguish GSS-API tokens from other data carried in
+   their application protocols.
+
+   Concrete language bindings are required for the programming
+   environments in which the GSS-API is to be employed, as RFC-1509
+   defines for the C programming language and GSS-V1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 82]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+APPENDIX A
+
+MECHANISM DESIGN CONSTRAINTS
+
+   The following constraints on GSS-API mechanism designs are adopted in
+   response to observed caller protocol requirements, and adherence
+   thereto is anticipated in subsequent descriptions of GSS-API
+   mechanisms to be documented in standards-track Internet
+   specifications.
+
+   It is strongly recommended that mechanisms offering per-message
+   protection services also offer at least one of the replay detection
+   and sequencing services, as mechanisms offering neither of the latter
+   will fail to satisfy recognized requirements of certain candidate
+   caller protocols.
+
+APPENDIX B
+
+                         COMPATIBILITY WITH GSS-V1
+
+   It is the intent of this document to define an interface and
+   procedures which preserve compatibility between GSS-V1 (RFC-1508)
+   callers and GSS- V2 providers.  All calls defined in GSS-V1 are
+   preserved, and it has been a goal that GSS-V1 callers should be able
+   to operate atop GSS-V2 provider implementations.  Certain detailed
+   changes, summarized in this section, have been made in order to
+   resolve omissions identified in GSS-V1.
+
+   The following GSS-V1 constructs, while supported within GSS-V2, are
+   deprecated:
+
+      Names for per-message processing routines: GSS_Seal() deprecated
+      in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
+      GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
+      GSS_Verify() deprecated in favor of GSS_VerifyMIC().
+
+      GSS_Delete_sec_context() facility for context_token usage,
+      allowing mechanisms to signal context deletion, is retained for
+      compatibility with GSS-V1.  For current usage, it is recommended
+      that both peers to a context invoke GSS_Delete_sec_context()
+      independently, passing a null output_context_token buffer to
+      indicate that no context_token is required.  Implementations of
+      GSS_Delete_sec_context() should delete relevant locally-stored
+      context information.
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 83]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   This GSS-V2 specification adds the following calls which are not
+   present in GSS-V1:
+
+      Credential management calls: GSS_Add_cred(),
+      GSS_Inquire_cred_by_mech().
+
+      Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
+      GSS_Export_sec_context(), GSS_Import_sec_context().
+
+      Per-message calls: No new calls.  Existing calls have been renamed.
+
+      Support calls: GSS_Create_empty_OID_set(),
+      GSS_Add_OID_set_member(), GSS_Test_OID_set_member(),
+      GSS_Release_OID(), GSS_OID_to_str(), GSS_Str_to_OID(),
+      GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(),
+      GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
+
+   This GSS-V2 specification introduces three new facilities applicable
+   to security contexts, indicated using the following context state
+   values which are not present in GSS-V1:
+
+      anon_state, set TRUE to indicate that a context's initiator is
+      anonymous from the viewpoint of the target; Section 1.2.5 of this
+      specification provides a summary description of the GSS-V2
+      anonymity support facility, support and use of which is optional.
+
+      prot_ready_state, set TRUE to indicate that a context may be used
+      for per-message protection before final completion of context
+      establishment; Section 1.2.7 of this specification provides a
+      summary description of the GSS-V2 facility enabling mechanisms to
+      selectively permit per-message protection during context
+      establishment, support and use of which is optional.
+
+      trans_state, set TRUE to indicate that a context is transferable to
+      another process using the GSS-V2 GSS_Export_sec_context() facility.
+
+   These state values are represented (at the C bindings level) in
+   positions within a bit vector which are unused in GSS-V1, and may be
+   safely ignored by GSS-V1 callers.
+
+   Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
+   implementors in the following areas: implementation robustness,
+   credential management, behavior in multi-mechanism configurations,
+   naming support, and inclusion of optional sequencing services.  The
+   token tagging facility as defined in GSS-V2, Section 3.1, is now
+   described directly in terms of octets to facilitate interoperable
+   implementation without general ASN.1 processing code; the
+   corresponding ASN.1 syntax, included for descriptive purposes, is
+
+
+
+Linn                        Standards Track                    [Page 84]
+
+RFC 2078                        GSS-API                     January 1997
+
+
+   unchanged from that in GSS-V1. For use in conjunction with added
+   naming support facilities, a new Exported Name Object construct is
+   added.  Additional name types are introduced in Section 4.
+
+   This GSS-V2 specification adds the following major_status values
+   which are not defined in GSS-V1:
+
+     GSS_S_BAD_QOP                 unsupported QOP value
+     GSS_S_UNAUTHORIZED            operation unauthorized
+     GSS_S_UNAVAILABLE             operation unavailable
+     GSS_S_DUPLICATE_ELEMENT       duplicate credential element requested
+     GSS_S_NAME_NOT_MN             name contains multi-mechanism elements
+     GSS_S_GAP_TOKEN               skipped predecessor token(s)
+                                    detected
+
+   Of these added status codes, only two values are defined to be
+   returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
+   GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
+   GSS_VerifyMIC() and GSS_Unwrap()).
+
+   Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
+   have been updated to allow return of additional major_status values
+   from the set as defined in GSS-V1: GSS_Inquire_cred() has
+   GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
+   returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
+   GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
+   GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
+
+Author's Address
+
+   John Linn
+   OpenVision Technologies
+   One Main St.
+   Cambridge, MA  02142  USA
+
+   Phone: +1 617.374.2245
+   EMail: John.Linn@ov.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 85]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2203.txt b/third_party/heimdal/doc/standardisation/rfc2203.txt
new file mode 100644
index 00000000000..2f6a8a0d0f3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2203.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                          M. Eisler
+Request for Comments: 2203                                       A. Chiu
+Category: Standards Track                                        L. Ling
+                                                          September 1997
+
+
+                   RPCSEC_GSS Protocol Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo describes an ONC/RPC security flavor that allows RPC
+   protocols to access the Generic Security Services Application
+   Programming Interface (referred to henceforth as GSS-API).
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  The ONC RPC Message Protocol . . . . . . . . . . . . . . . . . 2
+   3.  Flavor Number Assignment . . . . . . . . . . . . . . . . . . . 3
+   4.  New auth_stat Values . . . . . . . . . . . . . . . . . . . . . 3
+   5.  Elements of the RPCSEC_GSS Security Protocol . . . . . . . . . 3
+   5.1.  Version Selection  . . . . . . . . . . . . . . . . . . . . . 5
+   5.2.  Context Creation . . . . . . . . . . . . . . . . . . . . . . 5
+   5.2.1.  Mechanism and QOP Selection  . . . . . . . . . . . . . . . 5
+   5.2.2.  Context Creation Requests  . . . . . . . . . . . . . . . . 6
+   5.2.3.  Context Creation Responses . . . . . . . . . . . . . . . . 8
+   5.2.3.1.  Context Creation Response - Successful Acceptance  . . . 8
+   5.2.3.1.1.  Client Processing of Successful Context Creation
+               Responses  . . . . . . . . . . . . . . . . . . . . . . 9
+   5.2.3.2.  Context Creation Response - Unsuccessful Cases . . . . . 9
+   5.3.  RPC Data Exchange  . . . . . . . . . . . . . . . . . . . .  10
+   5.3.1.  RPC Request Header . . . . . . . . . . . . . . . . . . .  10
+   5.3.2.  RPC Request Data . . . . . . . . . . . . . . . . . . . .  11
+   5.3.2.1.  RPC Request Data - No Data Integrity . . . . . . . . .  11
+   5.3.2.2.  RPC Request Data - With Data Integrity . . . . . . . .  11
+   5.3.2.3.  RPC Request Data - With Data Privacy . . . . . . . . .  12
+   5.3.3.  Server Processing of RPC Data Requests . . . . . . . . .  12
+   5.3.3.1.  Context Management . . . . . . . . . . . . . . . . . .  12
+   5.3.3.2.  Server Reply - Request Accepted  . . . . . . . . . . .  14
+   5.3.3.3.  Server Reply - Request Denied  . . . . . . . . . . . .  15
+
+
+
+Eisler, et. al.             Standards Track                     [Page 1]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   5.3.3.4.  Mapping of GSS-API Errors to Server Responses  . . . .  16
+   5.3.3.4.1.  GSS_GetMIC() Failure . . . . . . . . . . . . . . . .  16
+   5.3.3.4.2.  GSS_VerifyMIC() Failure  . . . . . . . . . . . . . .  16
+   5.3.3.4.3.  GSS_Unwrap() Failure . . . . . . . . . . . . . . . .  16
+   5.3.3.4.4.  GSS_Wrap() Failure . . . . . . . . . . . . . . . . .  16
+   5.4.  Context Destruction  . . . . . . . . . . . . . . . . . . .  17
+   6.  Set of GSS-API Mechanisms  . . . . . . . . . . . . . . . . .  17
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
+   7.1.  Privacy of Call Header . . . . . . . . . . . . . . . . . .  18
+   7.2.  Sequence Number Attacks  . . . . . . . . . . . . . . . . .  18
+   7.2.1.  Sequence Numbers Above the Window  . . . . . . . . . . .  18
+   7.2.2.  Sequence Numbers Within or Below the Window  . . . . . .  18
+   7.3.  Message Stealing Attacks . . . . . . . . . . . . . . . . .  19
+   Appendix A. GSS-API Major Status Codes . . . . . . . . . . . . .  20
+   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  22
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  23
+
+1.  Introduction
+
+   This document describes the protocol used by the RPCSEC_GSS security
+   flavor.  Security flavors have been called authentication flavors for
+   historical reasons. This memo recognizes that there are two other
+   security services besides authentication, integrity, and privacy, and
+   so defines a new RPCSEC_GSS security flavor.
+
+   The protocol is described using the XDR language [Srinivasan-xdr].
+   The reader is assumed to be familiar with ONC RPC and the security
+   flavor mechanism [Srinivasan-rpc].  The reader is also assumed to be
+   familiar with the GSS-API framework [Linn].  The RPCSEC_GSS security
+   flavor uses GSS-API interfaces to provide security services that are
+   independent of the underlying security mechanism.
+
+2.  The ONC RPC Message Protocol
+
+   This memo refers to the following XDR types of the ONC RPC protocol,
+   which are described in the document entitled Remote Procedure Call
+   Protocol Specification Version 2 [Srinivasan-rpc]:
+
+      msg_type
+      reply_stat
+      auth_flavor
+      accept_stat
+      reject_stat
+      auth_stat
+      opaque_auth
+      rpc_msg
+      call_body
+      reply_body
+
+
+
+Eisler, et. al.             Standards Track                     [Page 2]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+      accepted_reply
+      rejected_reply
+
+3.  Flavor Number Assignment
+
+   The RPCSEC_GSS security flavor has been assigned the value of 6:
+
+      enum auth_flavor {
+          ...
+          RPCSEC_GSS = 6      /* RPCSEC_GSS security flavor */
+      };
+
+4.  New auth_stat Values
+
+   RPCSEC_GSS requires the addition of two new values to the auth_stat
+   enumerated type definition:
+
+      enum auth_stat {
+              ...
+              /*
+               * RPCSEC_GSS errors
+               */
+              RPCSEC_GSS_CREDPROBLEM = 13,
+              RPCSEC_GSS_CTXPROBLEM = 14
+      };
+
+   The descriptions of these two new values are defined later in this
+   memo.
+
+5.  Elements of the RPCSEC_GSS Security Protocol
+
+   An RPC session based on the RPCSEC_GSS security flavor consists of
+   three phases: context creation, RPC data exchange, and context
+   destruction.  In the following discussion, protocol elements for
+   these three phases are described.
+
+   The following description of the RPCSEC_GSS protocol uses some of the
+   definitions within XDR language description of the RPC protocol.
+
+   Context creation and destruction use control messages that are not
+   dispatched to service procedures registered by an RPC server.  The
+   program and version numbers used in these control messages are the
+   same as the RPC service's program and version numbers.  The procedure
+   number used is NULLPROC (zero).  A field in the credential
+   information (the gss_proc field which is defined in the
+   rpc_gss_cred_t structure below) specifies whether a message is to be
+   interpreted as a control message or a regular RPC message.  If this
+   field is set to RPCSEC_GSS_DATA, no control action is implied; in
+
+
+
+Eisler, et. al.             Standards Track                     [Page 3]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   this case, it is a regular data message.  If this field is set to any
+   other value, a control action is implied.  This is described in the
+   following sections.
+
+   Just as with normal RPC data exchange messages, the transaction
+   identifier (the xid field in struct rpc_msg), should be set to unique
+   values on each call for context creation and context destruction.
+
+   The following definitions are used for describing the protocol.
+
+      /* RPCSEC_GSS control procedures */
+
+
+      enum rpc_gss_proc_t {
+              RPCSEC_GSS_DATA = 0,
+              RPCSEC_GSS_INIT = 1,
+              RPCSEC_GSS_CONTINUE_INIT = 2,
+              RPCSEC_GSS_DESTROY = 3
+      };
+
+      /* RPCSEC_GSS services */
+
+      enum rpc_gss_service_t {
+          /* Note: the enumerated value for 0 is reserved. */
+          rpc_gss_svc_none = 1,
+          rpc_gss_svc_integrity = 2,
+          rpc_gss_svc_privacy = 3
+      };
+
+      /* Credential */
+
+      /*
+       * Note: version 0 is reserved for possible future
+       * definition of a version negotiation protocol
+       *
+       */
+      #define RPCSEC_GSS_VERS_1 1
+
+      struct rpc_gss_cred_t {
+          union switch (unsigned int version) { /* version of
+                                                      RPCSEC_GSS */
+          case RPCSEC_GSS_VERS_1:
+              struct {
+                  rpc_gss_proc_t gss_proc;  /* control procedure */
+                  unsigned int seq_num;   /* sequence number */
+                  rpc_gss_service_t service; /* service used */
+                  opaque handle<>;       /* context handle */
+              } rpc_gss_cred_vers_1_t;
+
+
+
+Eisler, et. al.             Standards Track                     [Page 4]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+          }
+      };
+
+      /* Maximum sequence number value */
+
+      #define MAXSEQ 0x80000000
+
+5.1.  Version Selection
+
+   This document defines just one protocol version (RPCSEC_GSS_VERS_1).
+   The client should assume that the server supports RPCSEC_GSS_VERS_1
+   and issue a Context Creation message (as described in the section
+   RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
+   MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
+   AUTH_REJECTED_CRED.
+
+5.2.  Context Creation
+
+   Before RPC data is exchanged on a session using the RPCSEC_GSS
+   flavor, a context must be set up between the client and the server.
+   Context creation may involve zero or more RPC exchanges.  The number
+   of exchanges depends on the security mechanism.
+
+5.2.1.  Mechanism and QOP Selection
+
+   There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API
+   mechanism identifiers or QOP values. At minimum, it is expected that
+   implementations of the RPCSEC_GSS protocol provide a means to:
+
+   *    specify mechanism identifiers, QOP values, and RPCSEC_GSS
+        service values on the client side, and to
+
+   *    enforce mechanism identifiers, QOP values, and RPCSEC_GSS
+        service values on a per-request basis on the server side.
+
+   It is necessary that above capabilities exist so that applications
+   have the means to conform the required set of required set of
+   <mechanism, QOP, service> tuples (See the section entitled Set of
+   GSS-API Mechanisms).  An application may negotiate <mechanism, QOP,
+   service> selection within its protocol or via an out of band
+   protocol. Hence it may be necessary for RPCSEC_GSS implementations to
+   provide programming interfaces for the specification and enforcement
+   of <mechanism, QOP, service>.
+
+   Additionally, implementations may depend on negotiation schemes
+   constructed as pseudo-mechanisms under the GSS-API.  Because such
+   schemes are below the GSS-API layer, the RPCSEC_GSS protocol, as
+   specified in this document, can make use of them.
+
+
+
+Eisler, et. al.             Standards Track                     [Page 5]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+5.2.2.  Context Creation Requests
+
+   The first RPC request from the client to the server initiates context
+   creation.  Within the RPC message protocol's call_body structure,
+   rpcvers is set to 2. prog and vers are always those for the service
+   being accessed.  The proc is always set to NULLPROC (zero).
+
+   Within the RPC message protocol's cred structure, flavor is set to
+   RPCSEC_GSS (6).  The opaque data of the cred structure (the body
+   field) constituting the credential encodes the rpc_gss_cred_t
+   structure defined previously.
+
+   The values of the fields contained in the rpc_gss_cred_t structure
+   are set as follows.  The version field is set to the version of the
+   RPCSEC_GSS protocol the client wants to use.  The remainder of this
+   memo documents version RPCSEC_GSS_VERS_1 of RPCSEC_GSS, and so the
+   version field would be set to RPCSEC_GSS_VERS_1.  The gss_proc field
+   must be set to RPCSEC_GSS_INIT for the first creation request.  In
+   subsequent creation requests, the gss_proc field must be set to
+   RPCSEC_GSS_CONTINUE_INIT.  In a creation request, the seq_num and
+   service fields are undefined and both must be ignored by the server.
+   In the first creation request, the handle field is NULL (opaque data
+   of zero length).  In subsequent creation requests, handle must be
+   equal to the value returned by the server.  The handle field serves
+   as the identifier for the context, and will not change for the
+   duration of the context, including responses to
+   RPCSEC_GSS_CONTINUE_INIT.
+
+   The verifier field in the RPC message header is also described by the
+   opaque_auth structure.  All creation requests have the NULL verifier
+   (AUTH_NONE flavor with zero length opaque data).
+
+   Following the verifier are the call data (procedure specific
+   parameters).  Note that the proc field of the call_body structure is
+   set to NULLPROC, and thus normally there would be zero octets
+   following the verifier.  However, since there is no RPC data exchange
+   during a context creation, it is safe to transfer information
+   following the verifier.  It is necessary to "overload" the call data
+   in this way, rather than pack the GSS-API token into the RPC header,
+   because RPC Version 2 restricts the amount of data that can be sent
+   in the header.  The opaque body of the credential and verifier fields
+   can be each at most 400 octets long, and GSS tokens can be longer
+   than 800 octets.
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                     [Page 6]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   The call data for a context creation request is described by the
+   following structure for all creation requests:
+
+      struct rpc_gss_init_arg {
+          opaque gss_token<>;
+      };
+
+   Here, gss_token is the token returned by the call to  GSS-API's
+   GSS_Init_sec_context() routine, opaquely encoded.  The value of this
+   field will likely be different in each creation request, if there is
+   more than one creation request.  If no token is returned by the call
+   to GSS_Init_sec_context(), the context must have been created
+   (assuming no errors), and there will not be any more creation
+   requests.
+
+   When GSS_Init_sec_context() is called, the parameters
+   replay_det_req_flag and sequence_req_flag must be turned off. The
+   reasons for this are:
+
+   *    ONC RPC can be used over unreliable transports and provides no
+        layer to reliably re-assemble messages. Thus it is possible for
+        gaps in message sequencing to occur, as well as out of order
+        messages.
+
+   *    RPC servers can be multi-threaded, and thus the order in which
+        GSS-API messages are signed or wrapped can be different from the
+        order in which the messages are verified or unwrapped, even if
+        the requests are sent on reliable transports.
+
+   *    To maximize convenience of implementation, the order in which an
+        ONC RPC entity will verify the header and verify/unwrap the body
+        of an RPC call or reply is left unspecified.
+
+   The RPCSEC_GSS protocol provides for protection from replay attack,
+   yet tolerates out-of-order delivery or processing of messages and
+   tolerates dropped requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                     [Page 7]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+5.2.3.  Context Creation Responses
+
+5.2.3.1.  Context Creation Response - Successful Acceptance
+
+   The response to a successful creation request has an MSG_ACCEPTED
+   response with a status of SUCCESS.  The results field encodes a
+   response with the following structure:
+
+      struct rpc_gss_init_res {
+              opaque handle<>;
+              unsigned int gss_major;
+              unsigned int gss_minor;
+              unsigned int seq_window;
+              opaque gss_token<>;
+      };
+
+   Here, handle is non-NULL opaque data that serves as the context
+   identifier. The client must use this value in all subsequent requests
+   whether control messages or otherwise).  The gss_major and gss_minor
+   fields contain the results of the call to GSS_Accept_sec_context()
+   executed by the server.  The values for the gss_major field are
+   defined in Appendix A of this document.  The values for the gss_minor
+   field are GSS-API mechanism specific and are defined in the
+   mechanism's specification.  If gss_major is not one of GSS_S_COMPLETE
+   or GSS_S_CONTINUE_NEEDED, the context setup has failed; in this case
+   handle and gss_token must be set to NULL by the server.  The value of
+   gss_minor is dependent on the value of gss_major and the security
+   mechanism used.  The gss_token field contains any token returned by
+   the GSS_Accept_sec_context() call executed by the server.  A token
+   may be returned for both successful values of gss_major.  If the
+   value is GSS_S_COMPLETE, it indicates that the server is not
+   expecting any more tokens, and the RPC Data Exchange phase must begin
+   on the subsequent request from the client. If the value is
+   GSS_S_CONTINUE_NEEDED, the server is expecting another token.  Hence
+   the client must send at least one more creation request (with
+   gss_proc set to RPCSEC_GSS_CONTINUE_INIT in the request's credential)
+   carrying the required token.
+
+   In a successful response, the seq_window field is set to the sequence
+   window length supported by the server for this context.  This window
+   specifies the maximum number of client requests that may be
+   outstanding for this context. The server will accept "seq_window"
+   requests at a time, and these may be out of order.  The client may
+   use this number to determine the number of threads that can
+   simultaneously send requests on this context.
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                     [Page 8]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   If gss_major is GSS_S_COMPLETE, the verifier's (the verf element in
+   the response) flavor field is set to RPCSEC_GSS, and the body field
+   set to the checksum of the seq_window (in network order). The QOP
+   used for this checksum is 0 (zero), which is the default QOP.  For
+   all other values of gss_major, a NULL verifier (AUTH_NONE flavor with
+   zero-length opaque data) is used.
+
+5.2.3.1.1.  Client Processing of Successful Context Creation Responses
+
+   If the value of gss_major in the response is GSS_S_CONTINUE_NEEDED,
+   then the client, per the GSS-API specification, must invoke
+   GSS_Init_sec_context() using the token returned in gss_token in the
+   context creation response. The client must then generate a context
+   creation request, with gss_proc set to RPCSEC_GSS_CONTINUE_INIT.
+
+   If the value of gss_major in the response is GSS_S_COMPLETE, and if
+   the client's previous invocation of GSS_Init_sec_context() returned a
+   gss_major value of GSS_S_CONTINUE_NEEDED, then the client, per the
+   GSS-API specification, must invoke GSS_Init_sec_context() using the
+   token returned in gss_token in the context creation response. If
+   GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is
+   successfully set up, and the RPC data exchange phase must begin on
+   the subsequent request from the client.
+
+5.2.3.2.  Context Creation Response - Unsuccessful Cases
+
+   An MSG_ACCEPTED reply (to a creation request) with an acceptance
+   status of other than SUCCESS has a NULL verifier (flavor set to
+   AUTH_NONE, and zero length opaque data in the body field), and is
+   formulated as usual for different status values.
+
+   An MSG_DENIED reply (to a creation request) is also formulated as
+   usual.  Note that MSG_DENIED could be returned because the server's
+   RPC implementation does not recognize the RPCSEC_GSS security flavor.
+   RFC 1831 does not specify the appropriate reply status in this
+   instance, but common implementation practice appears to be to return
+   a rejection status of AUTH_ERROR with an auth_stat of
+   AUTH_REJECTEDCRED. Even though two new values (RPCSEC_GSS_CREDPROBLEM
+   and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type,
+   neither of these two can be returned in responses to context creation
+   requests.  The auth_stat new values can be used for responses to
+   normal (data) requests.  This is described later.
+
+   MSG_DENIED might also be returned if the RPCSEC_GSS version number in
+   the credential is not supported on the server. In that case, the
+   server returns a rejection status of AUTH_ERROR, with an auth_stat of
+
+   AUTH_REJECTED_CRED.
+
+
+
+Eisler, et. al.             Standards Track                     [Page 9]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+5.3.  RPC Data Exchange
+
+   The data exchange phase is entered after a context has been
+   successfully set up. The format of the data exchanged depends on the
+   security service used for the request.  Although clients can change
+   the security service and QOP used on a per-request basis, this may
+   not be acceptable to all RPC services; some RPC services may "lock"
+   the data exchange phase into using the QOP and service used on the
+   first data exchange message.  For all three modes of service (no data
+   integrity, data integrity, data privacy), the RPC request header has
+   the same format.
+
+5.3.1.  RPC Request Header
+
+   The credential has the opaque_auth structure described earlier.  The
+   flavor field is set to RPCSEC_GSS.  The credential body is created by
+   XDR encoding the rpc_gss_cred_t structure listed earlier into an
+   octet stream, and then opaquely encoding this octet stream as the
+   body field.
+
+   Values of the fields contained in the rpc_gss_cred_t structure are
+   set as follows.  The version field is set to same version value that
+   was used to create the context, which within the scope of this memo
+   will always be RPCSEC_GSS_VERS_1.  The gss_proc field is set to
+   RPCSEC_GSS_DATA.  The service field is set to indicate the desired
+   service (one of rpc_gss_svc_none, rpc_gss_svc_integrity, or
+   rpc_gss_svc_privacy).  The handle field is set to the context handle
+   value received from the RPC server during context creation.  The
+   seq_num field can start at any value below MAXSEQ, and must be
+   incremented (by one or more) for successive requests.  Use of
+   sequence numbers is described in detail when server processing of the
+   request is discussed.
+
+   The verifier has the opaque_auth structure described earlier.  The
+   flavor field is set to RPCSEC_GSS.  The body field is set as follows.
+   The checksum of the RPC header (up to and including the credential)
+   is computed using the GSS_GetMIC() call with the desired QOP.  This
+   returns the checksum as an opaque octet stream and its length.  This
+   is encoded into the body field.  Note that the QOP is not explicitly
+   specified anywhere in the request.  It is implicit in the checksum or
+   encrypted data.  The same QOP value as is used for the header
+   checksum must also be used for the data (for checksumming or
+   encrypting), unless the service used for the request is
+   rpc_gss_svc_none.
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 10]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+5.3.2.  RPC Request Data
+
+5.3.2.1.  RPC Request Data - No Data Integrity
+
+   If the service specified is rpc_gss_svc_none, the data (procedure
+   arguments) are not integrity or privacy protected.  They are sent in
+   exactly the same way as they would be if the AUTH_NONE flavor were
+   used (following the verifier).  Note, however, that since the RPC
+   header is integrity protected, the sender will still be authenticated
+   in this case.
+
+5.3.2.2.  RPC Request Data - With Data Integrity
+
+   When data integrity is used, the request data is represented as
+   follows:
+
+      struct rpc_gss_integ_data {
+          opaque databody_integ<>;
+          opaque checksum<>;
+      };
+
+   The databody_integ field is created as follows.  A structure
+   consisting of a sequence number followed by the procedure arguments
+   is constructed. This is shown below as the type rpc_gss_data_t:
+
+      struct rpc_gss_data_t {
+          unsigned int seq_num;
+          proc_req_arg_t arg;
+      };
+
+   Here, seq_num must have the same value as in the credential.  The
+   type proc_req_arg_t is the procedure specific XDR type describing the
+   procedure arguments (and so is not specified here).  The octet stream
+   corresponding to the XDR encoded rpc_gss_data_t structure and its
+   length are placed in the databody_integ field. Note that because the
+   XDR type of databody_integ is opaque, the XDR encoding of
+   databody_integ will include an initial four octet length field,
+   followed by the XDR encoded octet stream of rpc_gss_data_t.
+
+   The checksum field represents the checksum of the XDR encoded octet
+   stream corresponding to the XDR encoded rpc_gss_data_t structure
+   (note, this is not the checksum of the databody_integ field).  This
+   is obtained using the GSS_GetMIC() call, with the same QOP as was
+   used to compute the header checksum (in the verifier). The
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 11]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   GSS_GetMIC() call returns the checksum as an opaque octet stream and
+   its length. The checksum field of struct rpc_gss_integ_data has an
+   XDR type of opaque. Thus the checksum length from GSS_GetMIC() is
+   encoded as a four octet  length field, followed by the checksum,
+   padded to a multiple of four octets.
+
+5.3.2.3.  RPC Request Data - With Data Privacy
+
+   When data privacy is used, the request data is represented as
+   follows:
+
+      struct rpc_gss_priv_data {
+          opaque databody_priv<>
+      };
+
+   The databody_priv field is created as follows.  The rpc_gss_data_t
+   structure described earlier is constructed again in the same way as
+   for the case of data integrity.  Next, the GSS_Wrap() call is invoked
+   to encrypt the octet stream corresponding to the rpc_gss_data_t
+   structure, using the same value for QOP (argument qop_req to
+   GSS_Wrap()) as was used for the header checksum (in the verifier) and
+   conf_req_flag (an argument to GSS_Wrap()) of TRUE.  The GSS_Wrap()
+   call returns an opaque octet stream (representing the encrypted
+   rpc_gss_data_t structure) and its length, and this is encoded as the
+   databody_priv field. Since databody_priv has an XDR type of opaque,
+   the length returned by GSS_Wrap() is encoded as the four octet
+   length, followed by the encrypted octet stream (padded to a multiple
+   of four octets).
+
+5.3.3.  Server Processing of RPC Data Requests
+
+5.3.3.1.  Context Management
+
+   When a request is received by the server, the following are verified
+   to be acceptable:
+
+   *    the version number in the credential
+
+   *    the service specified in the credential
+
+   *    the context handle specified in the credential
+
+   *    the header checksum in the verifier (via GSS_VerifyMIC())
+
+   *    the sequence number (seq_num) specified in the credential (more
+        on this follows)
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 12]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   The gss_proc field in the credential must be set to RPCSEC_GSS_DATA
+   for data requests (otherwise, the message will be interpreted as a
+   control message).
+
+   The server maintains a window of "seq_window" sequence numbers,
+   starting with the last sequence number seen and extending backwards.
+   If a sequence number higher than the last number seen is received
+   (AND if GSS_VerifyMIC() on the header checksum from the verifier
+   returns GSS_S_COMPLETE), the window is moved forward to the new
+   sequence number.  If the last sequence number seen is N, the server
+   is prepared to receive requests with sequence numbers in the range N
+   through (N - seq_window + 1), both inclusive.  If the sequence number
+   received falls below this range, it is silently discarded.  If the
+   sequence number is within this range, and the server has not seen it,
+   the request is accepted, and the server turns on a bit to "remember"
+   that this sequence number has been seen.  If the server determines
+   that it has already seen a sequence number within the window, the
+   request is silently discarded. The server should select a seq_window
+   value based on the number requests it expects to process
+   simultaneously. For example, in a threaded implementation seq_window
+   might be equal to the number of server threads. There are no known
+   security issues with selecting a large window. The primary issue is
+   how much space the server is willing to allocate to keep track of
+   requests received within the window.
+
+   The reason for discarding requests silently is that the server is
+   unable to determine if the duplicate or out of range request was due
+   to a sequencing problem in the client, network, or the operating
+   system, or due to some quirk in routing, or a replay attack by an
+   intruder.  Discarding the request allows the client to recover after
+   timing out, if indeed the duplication was unintentional or well
+   intended.  Note that a consequence of the silent discard is that
+   clients may increment the seq_num by more than one. The effect of
+   this is that the window will move forward more quickly. It is not
+   believed that there is any benefit to doing this.
+
+   Note that the sequence number algorithm requires that the client
+   increment the sequence number even if it is retrying a request with
+   the same RPC transaction identifier.  It is not infrequent for
+   clients to get into a situation where they send two or more attempts
+   and a slow server sends the reply for the first attempt. With
+   RPCSEC_GSS, each request and reply will have a unique sequence
+   number. If the client wishes to improve turn around time on the RPC
+   call, it can cache the RPCSEC_GSS sequence number of each request it
+   sends. Then when it receives a response with a matching RPC
+   transaction identifier, it can compute the checksum of each sequence
+   number in the cache to try to match the checksum in the reply's
+   verifier.
+
+
+
+Eisler, et. al.             Standards Track                    [Page 13]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   The data is decoded according to the service specified in the
+   credential.  In the case of integrity or privacy, the server ensures
+   that the QOP value is acceptable, and that it is the same as that
+   used for the header checksum in the verifier.  Also, in the case of
+   integrity or privacy, the server will reject the message (with a
+   reply status of MSG_ACCEPTED, and an acceptance status of
+   GARBAGE_ARGS) if the sequence number embedded in the request body is
+   different from the sequence number in the credential.
+
+5.3.3.2.  Server Reply - Request Accepted
+
+   An MSG_ACCEPTED reply to a request in the data exchange phase will
+   have the verifier's (the verf element in the response) flavor field
+   set to RPCSEC_GSS, and the body field set to the checksum (the output
+   of GSS_GetMIC()) of the sequence number (in network order) of the
+   corresponding request.  The QOP used is the same as the QOP used for
+   the corresponding request.
+
+   If the status of the reply is not SUCCESS, the rest of the message is
+   formatted as usual.
+
+   If the status of the message is SUCCESS, the format of the rest of
+   the message depends on the service specified in the corresponding
+   request message. Basically, what follows the verifier in this case
+   are the procedure results, formatted in different ways depending on
+   the requested service.
+
+   If no data integrity was requested, the procedure results are
+   formatted as for the AUTH_NONE security flavor.
+
+   If data integrity was requested, the results are encoded in exactly
+   the same way as the procedure arguments were in the corresponding
+   request.  See the section 'RPC Request Data - With Data Integrity.'
+   The only difference is that the structure representing the
+   procedure's result - proc_res_arg_t - must be substituted in place of
+   the request argument structure proc_req_arg_t.  The QOP used for the
+   checksum must be the same as that used for constructing the reply
+   verifier.
+
+   If data privacy was requested, the results are encoded in exactly the
+   same way as the procedure arguments were in the corresponding
+   request.  See the section 'RPC Request Data - With Data Privacy.' The
+   QOP used for  encryption must be the same as that used for
+   constructing the reply verifier.
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 14]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+5.3.3.3.  Server Reply - Request Denied
+
+   An MSG_DENIED reply (to a data request) is formulated as usual.  Two
+   new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have
+   been defined for the auth_stat type.  When the reason for denial of
+   the request is a reject_stat of AUTH_ERROR, one of the two new
+   auth_stat values could be returned in addition to the existing
+   values.  These two new values have special significance from the
+   existing reasons for denial of a request.
+
+   The server maintains a list of contexts for the clients that are
+   currently in session with it.  Normally, a context is destroyed when
+   the client ends the session corresponding to it.  However, due to
+   resource constraints, the server may destroy a context prematurely
+   (on an LRU basis, or if the server machine is rebooted, for example).
+   In this case, when a client request comes in, there may not be a
+   context corresponding to its handle. The server rejects the request,
+   with the reason RPCSEC_GSS_CREDPROBLEM in this case.  Upon receiving
+   this error, the client must refresh the context - that is,
+   reestablish it after destroying the old one - and try the request
+   again.  This error is also returned if the context handle matches
+   that of a different context that was allocated after the client's
+   context was destroyed (this will be detected by a failure in
+   verifying the header checksum).
+
+   If the GSS_VerifyMIC() call on the header checksum (contained in the
+   verifier) fails to return GSS_S_COMPLETE, the server rejects the
+   request and returns an auth_stat of RPCSEC_GSS_CREDPROBLEM.
+
+   When the client's sequence number exceeds the maximum the server will
+   allow, the server will reject the request with the reason
+   RPCSEC_GSS_CTXPROBLEM.  Also, if security credentials become stale
+   while in use (due to ticket expiry in the case of the Kerberos V5
+   mechanism, for example), the failures which result cause the
+   RPCSEC_GSS_CTXPROBLEM reason to be returned.  In these cases also,
+   the client must refresh the context, and retry the request.
+
+   For other errors, retrying will not rectify the problem and the
+   client must not refresh the context until the problem causing the
+   client request to be denied is rectified.
+
+   If the version field in the credential does not match the version of
+   RPCSEC_GSS that was used when the context was created, the
+   AUTH_BADCRED value is returned.
+
+   If there is a problem with the credential, such a bad length, illegal
+   control procedure, or an illegal service, the appropriate auth_stat
+   status is AUTH_BADCRED.
+
+
+
+Eisler, et. al.             Standards Track                    [Page 15]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   Other errors can be returned as appropriate.
+
+5.3.3.4.  Mapping of GSS-API Errors to Server Responses
+
+   During the data exchange phase, the server may invoke GSS_GetMIC(),
+   GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of these
+   routines fail to return GSS_S_COMPLETE, then various unsuccessful
+   responses can be returned. The are described as follows for each of
+   the aforementioned four interfaces.
+
+5.3.3.4.1.  GSS_GetMIC() Failure
+
+   When GSS_GetMIC() is called to generate the verifier in the response,
+   a failure results in an RPC response with a reply status of
+   MSG_DENIED, reject status of AUTH_ERROR and an auth status of
+   RPCSEC_GSS_CTXPROBLEM.
+
+   When GSS_GetMIC() is called to sign the call results (service is
+   rpc_gss_svc_integrity), a failure results in no RPC response being
+   sent. Since ONC RPC server applications will typically control when a
+   response is sent, the failure indication will be returned to the
+   server application and it can take appropriate action (such as
+   logging the error).
+
+5.3.3.4.2.  GSS_VerifyMIC() Failure
+
+   When GSS_VerifyMIC() is called to verify the verifier in request, a
+   failure results in an RPC response with a reply status of MSG_DENIED,
+   reject status of AUTH_ERROR and an auth status of
+   RPCSEC_GSS_CREDPROBLEM.
+
+   When GSS_VerifyMIC() is called to verify the call arguments (service
+   is rpc_gss_svc_integrity), a failure results in an RPC response with
+   a reply status of MSG_ACCEPTED, and an acceptance status of
+   GARBAGE_ARGS.
+
+5.3.3.4.3.  GSS_Unwrap() Failure
+
+   When GSS_Unwrap() is called to decrypt the call arguments (service is
+   rpc_gss_svc_privacy), a failure results in an RPC response with a
+   reply status of MSG_ACCEPTED, and an acceptance status of
+   GARBAGE_ARGS.
+
+5.3.3.4.4.  GSS_Wrap() Failure
+
+   When GSS_Wrap() is called to encrypt the call results (service is
+   rpc_gss_svc_privacy), a failure results in no RPC response being
+   sent. Since ONC RPC server applications will typically control when a
+
+
+
+Eisler, et. al.             Standards Track                    [Page 16]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   response is sent, the failure indication will be returned to the
+   application and it can take appropriate action (such as logging the
+   error).
+
+5.4.  Context Destruction
+
+   When the client is done using the session, it must send a control
+   message informing the server that it no longer requires the context.
+   This message is formulated just like a data request packet, with the
+   following differences:  the credential has gss_proc set to
+   RPCSEC_GSS_DESTROY, the procedure specified in the header is
+   NULLPROC, and there are no procedure arguments.  The sequence number
+   in the request must be valid, and the header checksum in the verifier
+   must be valid, for the server to accept the message.  The server
+   sends a response as it would to a data request.  The client and
+   server must then destroy the context for the session.
+
+   If the request to destroy the context fails for some reason, the
+   client need not take any special action.  The server must be prepared
+   to deal with situations where clients never inform the server that
+   they no longer are in session and so don't need the server to
+   maintain a context.  An LRU mechanism or an aging mechanism should be
+   employed by the server to clean up in such cases.
+
+6.  Set of GSS-API Mechanisms
+
+   RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and
+   as such it is inappropriate for the RPCSEC_GSS specification to
+   enumerate a minimum set of required security mechanisms and/or
+   quality of protections.
+
+   If an application protocol specification references RPCSEC_GSS, the
+   protocol specification must list a mandatory set of { mechanism, QOP,
+   service } triples, such that an implementation cannot claim
+   conformance to the protocol specification unless it implements the
+   set of triples. Within each triple, mechanism is a GSS-API security
+   mechanism, QOP is a valid quality-of-protection within the mechanism,
+   and service is either rpc_gss_svc_integrity or rpc_gss_svc_privacy.
+
+   For example, a network filing protocol built on RPC that depends on
+   RPCSEC_GSS for security, might require that Kerberos V5 with the
+   default QOP using the rpc_gss_svc_integrity service be supported by
+   implementations conforming to the network filing protocol
+   specification.
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 17]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+7.  Security Considerations
+
+7.1.  Privacy of Call Header
+
+   The reader will note that for the privacy option, only the call
+   arguments and results are encrypted. Information about the
+   application in the form of RPC program number, program version
+   number, and program procedure number is transmitted in the clear.
+   Encrypting these fields in the RPC call header would have changed the
+   size and format of the call header. This would have required revising
+   the RPC protocol which was beyond the scope of this proposal. Storing
+   the encrypted numbers in the credential would have obviated a
+   protocol change, but would have introduced more overloading of fields
+   and would have made implementations of RPC more complex. Even if the
+   fields were encrypted somehow, in most cases an attacker can
+   determine the program number and version number by examining the
+   destination address of the request and querying the rpcbind service
+   on the destination host [Srinivasan-bind].  In any case, even by not
+   encrypting the three numbers, RPCSEC_GSS still improves the state of
+   security over what existing RPC services have had available
+   previously. Implementors of new RPC services that are concerned about
+   this risk may opt to design in a "sub-procedure" field that is
+   included in the service specific call arguments.
+
+7.2.  Sequence Number Attacks
+
+7.2.1.  Sequence Numbers Above the Window
+
+   An attacker cannot coax the server into raising the sequence number
+   beyond the range the legitimate client is aware of (and thus engineer
+   a denial of server attack) without constructing an RPC request that
+   will pass the header checksum. If the cost of verifying the header
+   checksum is sufficiently large (depending on the speed of the
+   processor doing the checksum and the cost of checksum algorithm), it
+   is possible to envision a denial of service attack (vandalism, in the
+   form of wasting processing resources) whereby the attacker sends
+   requests that are above the window. The simplest method might be for
+   the attacker to monitor the network traffic and then choose a
+   sequence number that is far above the current sequence number. Then
+   the attacker can send bogus requests using the above window sequence
+   number.
+
+7.2.2.  Sequence Numbers Within or Below the Window
+
+   If the attacker sends requests that are within or below the window,
+   then even if the header checksum is successfully verified, the server
+   will silently discard the requests because the server assumes it has
+   already processed the request. In this case, a server can optimize by
+
+
+
+Eisler, et. al.             Standards Track                    [Page 18]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   skipping the header checksum verification if the sequence number is
+   below the window, or if it is within the window, not attempt the
+   checksum verification if the sequence number has already been seen.
+
+7.3.  Message Stealing Attacks
+
+   This proposal does not address attacks where an attacker can block or
+   steal messages without being detected by the server. To implement
+   such protection would be tantamount to assuming a state in the RPC
+   service. RPCSEC_GSS does not worsen this situation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 19]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+Appendix A. GSS-API Major Status Codes
+
+   The GSS-API definition [Linn] does not include numerical values for
+   the various GSS-API major status codes. It is expected that this will
+   be addressed in future RFC. Until then, this appendix defines the
+   values for each GSS-API major status code listed in the GSS-API
+   definition.  If in the future, the GSS-API definition defines values
+   for the codes that are different than what follows, then implementors
+   of RPCSEC_GSS will be obliged to map them into the values defined
+   below. If in the future, the GSS-API definition defines additional
+   status codes not defined below, then the RPCSEC_GSS definition will
+   subsume those additional values.
+
+   Here are the definitions of each GSS_S_* major status that the
+   implementor of RPCSEC_GSS can expect in the gss_major major field of
+   rpc_gss_init_res.  These definitions are not in RPC description
+   language form.  The numbers are in base 16 (hexadecimal):
+
+      GSS_S_COMPLETE                  0x00000000
+      GSS_S_CONTINUE_NEEDED           0x00000001
+      GSS_S_DUPLICATE_TOKEN           0x00000002
+      GSS_S_OLD_TOKEN                 0x00000004
+      GSS_S_UNSEQ_TOKEN               0x00000008
+      GSS_S_GAP_TOKEN                 0x00000010
+      GSS_S_BAD_MECH                  0x00010000
+      GSS_S_BAD_NAME                  0x00020000
+      GSS_S_BAD_NAMETYPE              0x00030000
+      GSS_S_BAD_BINDINGS              0x00040000
+      GSS_S_BAD_STATUS                0x00050000
+      GSS_S_BAD_MIC                   0x00060000
+      GSS_S_BAD_SIG                   0x00060000
+      GSS_S_NO_CRED                   0x00070000
+      GSS_S_NO_CONTEXT                0x00080000
+      GSS_S_DEFECTIVE_TOKEN           0x00090000
+      GSS_S_DEFECTIVE_CREDENTIAL      0x000a0000
+      GSS_S_CREDENTIALS_EXPIRED       0x000b0000
+      GSS_S_CONTEXT_EXPIRED           0x000c0000
+      GSS_S_FAILURE                   0x000d0000
+      GSS_S_BAD_QOP                   0x000e0000
+      GSS_S_UNAUTHORIZED              0x000f0000
+      GSS_S_UNAVAILABLE               0x00100000
+      GSS_S_DUPLICATE_ELEMENT         0x00110000
+      GSS_S_NAME_NOT_MN               0x00120000
+      GSS_S_CALL_INACCESSIBLE_READ    0x01000000
+      GSS_S_CALL_INACCESSIBLE_WRITE   0x02000000
+      GSS_S_CALL_BAD_STRUCTURE        0x03000000
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 20]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   Note that the GSS-API major status is split into three fields as
+   follows:
+
+        Most Significant Bit                     Least Significant Bit
+        |------------------------------------------------------------|
+        | Calling Error | Routine Error  |    Supplementary Info     |
+        |------------------------------------------------------------|
+      Bit 31           24 23            16 15                        0
+
+   Up to one status in the Calling Error field can be logically ORed
+   with up to one status in the Routine Error field which in turn can be
+   logically ORed with zero or more statuses in the Supplementary Info
+   field. If the resulting major status has a non-zero Calling Error
+   and/or a non-zero Routine Error, then the applicable GSS-API
+   operation has failed.  For purposes of RPCSEC_GSS, this means that
+   the GSS_Accept_sec_context() call executed by the server has failed.
+
+   If the major status is equal GSS_S_COMPLETE, then this indicates the
+   absence of any Errors or Supplementary Info.
+
+   The meanings of most of the GSS_S_* status are defined in the GSS-API
+   definition, which the exceptions of:
+
+   GSS_S_BAD_MIC       This code has the same meaning as GSS_S_BAD_SIG.
+
+   GSS_S_CALL_INACCESSIBLE_READ
+                        A required input parameter could not be read.
+
+   GSS_S_CALL_INACCESSIBLE_WRITE
+                        A required input parameter could not be written.
+
+   GSS_S_CALL_BAD_STRUCTURE
+                       A parameter was malformed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 21]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+Acknowledgements
+
+   Much of the protocol was based on the AUTH_GSSAPI security flavor
+   developed by Open Vision Technologies [Jaspan].  In particular, we
+   acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen
+   McDermott.
+
+   Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike
+   Eisler.  Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to
+   Sun Microsystems' implementation of RPCSEC_GSS.
+
+   Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie
+   Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the
+   specification and gave valuable feedback.
+
+   Steve Nahm and Kathy Slattery reviewed various drafts of this
+   specification.
+
+   Much of content of Appendix A was excerpted from John Wray's Work in
+   Progress on GSS-API Version 2 C-bindings.
+
+References
+
+   [Eisler]            Eisler, M., Schemers, R., and Srinivasan, R.
+                       (1996).  "Security Mechanism Independence in ONC
+                       RPC," Proceedings of the Sixth Annual USENIX
+                       Security Symposium, pp. 51-65.
+
+   [Jaspan]            Jaspan, B. (1995). "GSS-API Security for ONC
+                       RPC," `95 Proceedings of The Internet Society
+                       Symposium on Network and Distributed System
+                       Security, pp. 144- 151.
+
+   [Linn]              Linn, J., "Generic Security Service Application
+                       Program Interface, Version 2", RFC 2078, January
+                       1997.
+
+   [Srinivasan-bind]   Srinivasan, R., "Binding Protocols for
+                       ONC RPC Version 2", RFC 1833, August 1995.
+
+   [Srinivasan-rpc]    Srinivasan, R., "RPC: Remote Procedure Call
+                       Protocol Specification Version 2", RFC 1831,
+                       August 1995.
+
+   [Srinivasan-xdr]    Srinivasan, R., "XDR: External Data
+                       Representation Standard", RFC 1832, August 1995.
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 22]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+Authors' Addresses
+
+   Michael Eisler
+   Sun Microsystems, Inc.
+   M/S UCOS03
+   2550 Garcia Avenue
+   Mountain View, CA 94043
+
+   Phone: +1 (719) 599-9026
+   EMail: mre@eng.sun.com
+
+
+   Alex Chiu
+   Sun Microsystems, Inc.
+   M/S UMPK17-203
+   2550 Garcia Avenue
+   Mountain View, CA 94043
+
+   Phone: +1 (415) 786-6465
+   EMail: hacker@eng.sun.com
+
+
+   Lin Ling
+   Sun Microsystems, Inc.
+   M/S UMPK17-201
+   2550 Garcia Avenue
+   Mountain View, CA 94043
+
+   Phone: +1 (415) 786-5084
+   EMail: lling@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 23]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2228.txt b/third_party/heimdal/doc/standardisation/rfc2228.txt
new file mode 100644
index 00000000000..1fbfcbfa09f
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2228.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                        M. Horowitz
+Request for Comments: 2228                              Cygnus Solutions
+Updates: 959                                                     S. Lunt
+Category: Standards Track                                       Bellcore
+                                                            October 1997
+
+                        FTP Security Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+Abstract
+
+   This document defines extensions to the FTP specification STD 9, RFC
+   959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985).  These extensions
+   provide strong authentication, integrity, and confidentiality on both
+   the control and data channels with the introduction of new optional
+   commands, replies, and file transfer encodings.
+
+   The following new optional commands are introduced in this
+   specification:
+
+      AUTH (Authentication/Security Mechanism),
+      ADAT (Authentication/Security Data),
+      PROT (Data Channel Protection Level),
+      PBSZ (Protection Buffer Size),
+      CCC (Clear Command Channel),
+      MIC (Integrity Protected Command),
+      CONF (Confidentiality Protected Command), and
+      ENC (Privacy Protected Command).
+
+   A new class of reply types (6yz) is also introduced for protected
+   replies.
+
+   None of the above commands are required to be implemented, but
+   interdependencies exist.  These dependencies are documented with the
+   commands.
+
+   Note that this specification is compatible with STD 9, RFC 959.
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 1]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+1.  Introduction
+
+   The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
+   and in place on the Internet uses usernames and passwords passed in
+   cleartext to authenticate clients to servers (via the USER and PASS
+   commands).  Except for services such as "anonymous" FTP archives,
+   this represents a security risk whereby passwords can be stolen
+   through monitoring of local and wide-area networks.  This either aids
+   potential attackers through password exposure and/or limits
+   accessibility of files by FTP servers who cannot or will not accept
+   the inherent security risks.
+
+   Aside from the problem of authenticating users in a secure manner,
+   there is also the problem of authenticating servers, protecting
+   sensitive data and/or verifying its integrity.  An attacker may be
+   able to access valuable or sensitive data merely by monitoring a
+   network, or through active means may be able to delete or modify the
+   data being transferred so as to corrupt its integrity.  An active
+   attacker may also initiate spurious file transfers to and from a site
+   of the attacker's choice, and may invoke other commands on the
+   server.  FTP does not currently have any provision for the encryption
+   or verification of the authenticity of commands, replies, or
+   transferred data.  Note that these security services have value even
+   to anonymous file access.
+
+   Current practice for sending files securely is generally either:
+
+      1.  via FTP of files pre-encrypted under keys which are manually
+          distributed,
+
+      2.  via electronic mail containing an encoding of a file encrypted
+          under keys which are manually distributed,
+
+      3.  via a PEM message, or
+
+      4.  via the rcp command enhanced to use Kerberos.
+
+   None of these means could be considered even a de facto standard, and
+   none are truly interactive.  A need exists to securely transfer files
+   using FTP in a secure manner which is supported within the FTP
+   protocol in a consistent manner and which takes advantage of existing
+   security infrastructure and technology.  Extensions are necessary to
+   the FTP specification if these security services are to be introduced
+   into the protocol in an interoperable way.
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 2]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   Although the FTP control connection follows the Telnet protocol, and
+   Telnet has defined an authentication and encryption option [TELNET-
+   SEC], [RFC-1123] explicitly forbids the use of Telnet option
+   negotiation over the control connection (other than Synch and IP).
+
+   Also, the Telnet authentication and encryption option does not
+   provide for integrity protection only (without confidentiality), and
+   does not address the protection of the data channel.
+
+2.  FTP Security Overview
+
+   At the highest level, the FTP security extensions seek to provide an
+   abstract mechanism for authenticating and/or authorizing connections,
+   and integrity and/or confidentiality protecting commands, replies,
+   and data transfers.
+
+   In the context of FTP security, authentication is the establishment
+   of a client's identity and/or a server's identity in a secure way,
+   usually using cryptographic techniques.  The basic FTP protocol does
+   not have a concept of authentication.
+
+   Authorization is the process of validating a user for login.  The
+   basic authorization process involves the USER, PASS, and ACCT
+   commands.  With the FTP security extensions, authentication
+   established using a security mechanism may also be used to make the
+   authorization decision.
+
+   Without the security extensions, authentication of the client, as
+   this term is usually understood, never happens.  FTP authorization is
+   accomplished with a password, passed on the network in the clear as
+   the argument to the PASS command.  The possessor of this password is
+   assumed to be authorized to transfer files as the user named in the
+   USER command, but the identity of the client is never securely
+   established.
+
+   An FTP security interaction begins with a client telling the server
+   what security mechanism it wants to use with the AUTH command.  The
+   server will either accept this mechanism, reject this mechanism, or,
+   in the case of a server which does not implement the security
+   extensions, reject the command completely.  The client may try
+   multiple security mechanisms until it requests one which the server
+   accepts.  This allows a rudimentary form of negotiation to take
+   place.  (If more complex negotiation is desired, this may be
+   implemented as a security mechanism.)  The server's reply will
+   indicate if the client must respond with additional data for the
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 3]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   security mechanism to interpret.  If none is needed, this will
+   usually mean that the mechanism is one where the password (specified
+   by the PASS command) is to be interpreted differently, such as with a
+   token or one-time password system.
+
+   If the server requires additional security information, then the
+   client and server will enter into a security data exchange.  The
+   client will send an ADAT command containing the first block of
+   security data.  The server's reply will indicate if the data exchange
+   is complete, if there was an error, or if more data is needed.  The
+   server's reply can optionally contain security data for the client to
+   interpret.  If more data is needed, the client will send another ADAT
+   command containing the next block of data, and await the server's
+   reply.  This exchange can continue as many times as necessary.  Once
+   this exchange completes, the client and server have established a
+   security association.  This security association may include
+   authentication (client, server, or mutual) and keying information for
+   integrity and/or confidentiality, depending on the mechanism in use.
+
+   The term "security data" here is carefully chosen.  The purpose of
+   the security data exchange is to establish a security association,
+   which might not actually include any authentication at all, between
+   the client and the server as described above.  For instance, a
+   Diffie-Hellman exchange establishes a secret key, but no
+   authentication takes place.  If an FTP server has an RSA key pair but
+   the client does not, then the client can authenticate the server, but
+   the server cannot authenticate the client.
+
+   Once a security association is established, authentication which is a
+   part of this association may be used instead of or in addition to the
+   standard username/password exchange for authorizing a user to connect
+   to the server.  A username specified by the USER command is always
+   required to specify the identity to be used on the server.
+
+   In order to prevent an attacker from inserting or deleting commands
+   on the control stream, if the security association supports
+   integrity, then the server and client must use integrity protection
+   on the control stream, unless it first transmits a CCC command to
+   turn off this requirement.  Integrity protection is performed with
+   the MIC and ENC commands, and the 63z reply codes.  The CCC command
+   and its reply must be transmitted with integrity protection.
+   Commands and replies may be transmitted without integrity (that is,
+   in the clear or with confidentiality only) only if no security
+   association is established, the negotiated security association does
+   not support integrity, or the CCC command has succeeded.
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 4]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   Once the client and server have negotiated with the PBSZ command an
+   acceptable buffer size for encapsulating protected data over the data
+   channel, the security mechanism may also be used to protect data
+   channel transfers.
+
+   Policy is not specified by this document.  In particular, client and
+   server implementations may choose to implement restrictions on what
+   operations can be performed depending on the security association
+   which exists.  For example, a server may require that a client
+   authorize via a security mechanism rather than using a password,
+   require that the client provide a one-time password from a token,
+   require at least integrity protection on the command channel, or
+   require that certain files only be transmitted encrypted.  An
+   anonymous ftp client might refuse to do file transfers without
+   integrity protection in order to insure the validity of files
+   downloaded.
+
+   No particular set of functionality is required, except as
+   dependencies described in the next section.  This means that none of
+   authentication, integrity, or confidentiality are required of an
+   implementation, although a mechanism which does none of these is not
+   of much use.  For example, it is acceptable for a mechanism to
+   implement only integrity protection, one-way authentication and/or
+   encryption, encryption without any authentication or integrity
+   protection, or any other subset of functionality if policy or
+   technical considerations make this desirable.  Of course, one peer
+   might require as a matter of policy stronger protection than the
+   other is able to provide, preventing perfect interoperability.
+
+3.  New FTP Commands
+
+   The following commands are optional, but dependent on each other.
+   They are extensions to the FTP Access Control Commands.
+
+   The reply codes documented here are generally described as
+   recommended, rather than required.  The intent is that reply codes
+   describing the full range of success and failure modes exist, but
+   that servers be allowed to limit information presented to the client.
+   For example, a server might implement a particular security
+   mechanism, but have a policy restriction against using it.  The
+   server should respond with a 534 reply code in this case, but may
+   respond with a 504 reply code if it does not wish to divulge that the
+   disallowed mechanism is supported.  If the server does choose to use
+   a different reply code than the recommended one, it should try to use
+   a reply code which only differs in the last digit.  In all cases, the
+   server must use a reply code which is documented as returnable from
+   the command received, and this reply code must begin with the same
+   digit as the recommended reply code for the situation.
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 5]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   AUTHENTICATION/SECURITY MECHANISM (AUTH)
+
+      The argument field is a Telnet string identifying a supported
+      mechanism.  This string is case-insensitive.  Values must be
+      registered with the IANA, except that values beginning with "X-"
+      are reserved for local use.
+
+      If the server does not recognize the AUTH command, it must respond
+      with reply code 500.  This is intended to encompass the large
+      deployed base of non-security-aware ftp servers, which will
+      respond with reply code 500 to any unrecognized command.  If the
+      server does recognize the AUTH command but does not implement the
+      security extensions, it should respond with reply code 502.
+
+      If the server does not understand the named security mechanism, it
+      should respond with reply code 504.
+
+      If the server is not willing to accept the named security
+      mechanism, it should respond with reply code 534.
+
+      If the server is not able to accept the named security mechanism,
+      such as if a required resource is unavailable, it should respond
+      with reply code 431.
+
+      If the server is willing to accept the named security mechanism,
+      but requires security data, it must respond with reply code 334.
+
+      If the server is willing to accept the named security mechanism,
+      and does not require any security data, it must respond with reply
+      code 234.
+
+      If the server is responding with a 334 reply code, it may include
+      security data as described in the next section.
+
+      Some servers will allow the AUTH command to be reissued in order
+      to establish new authentication.  The AUTH command, if accepted,
+      removes any state associated with prior FTP Security commands.
+      The server must also require that the user reauthorize (that is,
+      reissue some or all of the USER, PASS, and ACCT commands) in this
+      case (see section 4 for an explanation of "authorize" in this
+      context).
+
+
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 6]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   AUTHENTICATION/SECURITY DATA (ADAT)
+
+      The argument field is a Telnet string representing base 64 encoded
+      security data (see Section 9, "Base 64 Encoding").  If a reply
+      code indicating success is returned, the server may also use a
+      string of the form "ADAT=base64data" as the text part of the reply
+      if it wishes to convey security data back to the client.
+
+      The data in both cases is specific to the security mechanism
+      specified by the previous AUTH command.  The ADAT command, and the
+      associated replies, allow the client and server to conduct an
+      arbitrary security protocol.  The security data exchange must
+      include enough information for both peers to be aware of which
+      optional features are available.  For example, if the client does
+      not support data encryption, the server must be made aware of
+      this, so it will know not to send encrypted command channel
+      replies.  It is strongly recommended that the security mechanism
+      provide sequencing on the command channel, to insure that commands
+      are not deleted, reordered, or replayed.
+
+      The ADAT command must be preceded by a successful AUTH command,
+      and cannot be issued once a security data exchange completes
+      (successfully or unsuccessfully), unless it is preceded by an AUTH
+      command to reset the security state.
+
+      If the server has not yet received an AUTH command, or if a prior
+      security data exchange completed, but the security state has not
+      been reset with an AUTH command, it should respond with reply code
+      503.
+
+      If the server cannot base 64 decode the argument, it should
+      respond with reply code 501.
+
+      If the server rejects the security data (if a checksum fails, for
+      instance), it should respond with reply code 535.
+
+      If the server accepts the security data, and requires additional
+      data, it should respond with reply code 335.
+
+      If the server accepts the security data, but does not require any
+      additional data (i.e., the security data exchange has completed
+      successfully), it must respond with reply code 235.
+
+      If the server is responding with a 235 or 335 reply code, then it
+      may include security data in the text part of the reply as
+      specified above.
+
+
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 7]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+      If the ADAT command returns an error, the security data exchange
+      will fail, and the client must reset its internal security state.
+      If the client becomes unsynchronized with the server (for example,
+      the server sends a 234 reply code to an AUTH command, but the
+      client has more data to transmit), then the client must reset the
+      server's security state.
+
+   PROTECTION BUFFER SIZE (PBSZ)
+
+      The argument is a decimal integer representing the maximum size,
+      in bytes, of the encoded data blocks to be sent or received during
+      file transfer.  This number shall be no greater than can be
+      represented in a 32-bit unsigned integer.
+
+      This command allows the FTP client and server to negotiate a
+      maximum protected buffer size for the connection.  There is no
+      default size; the client must issue a PBSZ command before it can
+      issue the first PROT command.
+
+      The PBSZ command must be preceded by a successful security data
+      exchange.
+
+      If the server cannot parse the argument, or if it will not fit in
+      32 bits, it should respond with a 501 reply code.
+
+      If the server has not completed a security data exchange with the
+      client, it should respond with a 503 reply code.
+
+      Otherwise, the server must reply with a 200 reply code.  If the
+      size provided by the client is too large for the server, it must
+      use a string of the form "PBSZ=number" in the text part of the
+      reply to indicate a smaller buffer size.  The client and the
+      server must use the smaller of the two buffer sizes if both buffer
+      sizes are specified.
+
+   DATA CHANNEL PROTECTION LEVEL (PROT)
+
+      The argument is a single Telnet character code specifying the data
+      channel protection level.
+
+      This command indicates to the server what type of data channel
+      protection the client and server will be using.  The following
+      codes are assigned:
+
+         C - Clear
+         S - Safe
+         E - Confidential
+         P - Private
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 8]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+      The default protection level if no other level is specified is
+      Clear.  The Clear protection level indicates that the data channel
+      will carry the raw data of the file transfer, with no security
+      applied.  The Safe protection level indicates that the data will
+      be integrity protected.  The Confidential protection level
+      indicates that the data will be confidentiality protected.  The
+      Private protection level indicates that the data will be integrity
+      and confidentiality protected.
+
+      It is reasonable for a security mechanism not to provide all data
+      channel protection levels.  It is also reasonable for a mechanism
+      to provide more protection at a level than is required (for
+      instance, a mechanism might provide Confidential protection, but
+      include integrity-protection in that encoding, due to API or other
+      considerations).
+
+      The PROT command must be preceded by a successful protection
+      buffer size negotiation.
+
+      If the server does not understand the specified protection level,
+      it should respond with reply code 504.
+
+      If the current security mechanism does not support the specified
+      protection level, the server should respond with reply code 536.
+
+      If the server has not completed a protection buffer size
+      negotiation with the client, it should respond with a 503 reply
+      code.
+
+      The PROT command will be rejected and the server should reply 503
+      if no previous PBSZ command was issued.
+
+      If the server is not willing to accept the specified protection
+      level, it should respond with reply code 534.
+
+      If the server is not able to accept the specified protection
+      level, such as if a required resource is unavailable, it should
+      respond with reply code 431.
+
+      Otherwise, the server must reply with a 200 reply code to indicate
+      that the specified protection level is accepted.
+
+   CLEAR COMMAND CHANNEL (CCC)
+
+      This command does not take an argument.
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                     [Page 9]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+      It is desirable in some environments to use a security mechanism
+      to authenticate and/or authorize the client and server, but not to
+      perform any integrity checking on the subsequent commands.  This
+      might be used in an environment where IP security is in place,
+      insuring that the hosts are authenticated and that TCP streams
+      cannot be tampered, but where user authentication is desired.
+
+      If unprotected commands are allowed on any connection, then an
+      attacker could insert a command on the control stream, and the
+      server would have no way to know that it was invalid.  In order to
+      prevent such attacks, once a security data exchange completes
+      successfully, if the security mechanism supports integrity, then
+      integrity (via the MIC or ENC command, and 631 or 632 reply) must
+      be used, until the CCC command is issued to enable non-integrity
+      protected control channel messages.  The CCC command itself must
+      be integrity protected.
+
+      Once the CCC command completes successfully, if a command is not
+      protected, then the reply to that command must also not be
+      protected.  This is to support interoperability with clients which
+      do not support protection once the CCC command has been issued.
+
+      This command must be preceded by a successful security data
+      exchange.
+
+      If the command is not integrity-protected, the server must respond
+      with a 533 reply code.
+
+      If the server is not willing to turn off the integrity
+      requirement, it should respond with a 534 reply code.
+
+      Otherwise, the server must reply with a 200 reply code to indicate
+      that unprotected commands and replies may now be used on the
+      command channel.
+
+   INTEGRITY PROTECTED COMMAND (MIC) and
+   CONFIDENTIALITY PROTECTED COMMAND (CONF) and
+   PRIVACY PROTECTED COMMAND (ENC)
+
+      The argument field of MIC is a Telnet string consisting of a base
+      64 encoded "safe" message produced by a security mechanism
+      specific message integrity procedure.  The argument field of CONF
+      is a Telnet string consisting of a base 64 encoded "confidential"
+      message produced by a security mechanism specific confidentiality
+      procedure.  The argument field of ENC is a Telnet string
+      consisting of a base 64 encoded "private" message produced by a
+      security mechanism specific message integrity and confidentiality
+      procedure.
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 10]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+      The server will decode and/or verify the encoded message.
+
+      This command must be preceded by a successful security data
+      exchange.
+
+      A server may require that the first command after a successful
+      security data exchange be CCC, and not implement the protection
+      commands at all.  In this case, the server should respond with a
+      502 reply code.
+
+      If the server cannot base 64 decode the argument, it should
+      respond with a 501 reply code.
+
+      If the server has not completed a security data exchange with the
+      client, it should respond with a 503 reply code.
+
+      If the server has completed a security data exchange with the
+      client using a mechanism which supports integrity, and requires a
+      CCC command due to policy or implementation limitations, it should
+      respond with a 503 reply code.
+
+      If the server rejects the command because it is not supported by
+      the current security mechanism, the server should respond with
+      reply code 537.
+
+      If the server rejects the command (if a checksum fails, for
+      instance), it should respond with reply code 535.
+
+      If the server is not willing to accept the command (if privacy is
+      required by policy, for instance, or if a CONF command is received
+      before a CCC command), it should respond with reply code 533.
+
+      Otherwise, the command will be interpreted as an FTP command.  An
+      end-of-line code need not be included, but if one is included, it
+      must be a Telnet end-of-line code, not a local end-of-line code.
+
+      The server may require that, under some or all circumstances, all
+      commands be protected.  In this case, it should make a 533 reply
+      to commands other than MIC, CONF, and ENC.
+
+4.  Login Authorization
+
+   The security data exchange may, among other things, establish the
+   identity of the client in a secure way to the server.  This identity
+   may be used as one input to the login authorization process.
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 11]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   In response to the FTP login commands (AUTH, PASS, ACCT), the server
+   may choose to change the sequence of commands and replies specified
+   by RFC 959 as follows.  There are also some new replies available.
+
+   If the server is willing to allow the user named by the USER command
+   to log in based on the identity established by the security data
+   exchange, it should respond with reply code 232.
+
+   If the security mechanism requires a challenge/response password, it
+   should respond to the USER command with reply code 336.  The text
+   part of the reply should contain the challenge.  The client must
+   display the challenge to the user before prompting for the password
+   in this case.  This is particularly relevant to more sophisticated
+   clients or graphical user interfaces which provide dialog boxes or
+   other modal input.  These clients should be careful not to prompt for
+   the password before the username has been sent to the server, in case
+   the user needs the challenge in the 336 reply to construct a valid
+   password.
+
+5.  New FTP Replies
+
+   The new reply codes are divided into two classes.  The first class is
+   new replies made necessary by the new FTP Security commands.  The
+   second class is a new reply type to indicate protected replies.
+
+   5.1.  New individual reply codes
+
+      232 User logged in, authorized by security data exchange.
+      234 Security data exchange complete.
+      235 [ADAT=base64data]
+            ; This reply indicates that the security data exchange
+            ; completed successfully.  The square brackets are not
+            ; to be included in the reply, but indicate that
+            ; security data in the reply is optional.
+
+      334 [ADAT=base64data]
+            ; This reply indicates that the requested security mechanism
+            ; is ok, and includes security data to be used by the client
+            ; to construct the next command.  The square brackets are not
+            ; to be included in the reply, but indicate that
+            ; security data in the reply is optional.
+      335 [ADAT=base64data]
+            ; This reply indicates that the security data is
+            ; acceptable, and more is required to complete the
+            ; security data exchange.  The square brackets
+            ; are not to be included in the reply, but indicate
+            ; that security data in the reply is optional.
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 12]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+      336 Username okay, need password.  Challenge is "...."
+            ; The exact representation of the challenge should be chosen
+            ; by the mechanism to be sensible to the human user of the
+            ; system.
+
+      431 Need some unavailable resource to process security.
+
+      533 Command protection level denied for policy reasons.
+      534 Request denied for policy reasons.
+      535 Failed security check (hash, sequence, etc).
+      536 Requested PROT level not supported by mechanism.
+      537 Command protection level not supported by security mechanism.
+
+   5.2.  Protected replies.
+
+      One new reply type is introduced:
+
+         6yz   Protected reply
+
+            There are three reply codes of this type.  The first, reply
+            code 631 indicates an integrity protected reply.  The
+            second, reply code 632, indicates a confidentiality and
+            integrity protected reply.  the third, reply code 633,
+            indicates a confidentiality protected reply.
+
+            The text part of a 631 reply is a Telnet string consisting
+            of a base 64 encoded "safe" message produced by a security
+            mechanism specific message integrity procedure.  The text
+            part of a 632 reply is a Telnet string consisting of a base
+            64 encoded "private" message produced by a security
+            mechanism specific message confidentiality and integrity
+            procedure.  The text part of a 633 reply is a Telnet string
+            consisting of a base 64 encoded "confidential" message
+            produced by a security mechanism specific message
+            confidentiality procedure.
+
+            The client will decode and verify the encoded reply.  How
+            failures decoding or verifying replies are handled is
+            implementation-specific.  An end-of-line code need not be
+            included, but if one is included, it must be a Telnet end-
+            of-line code, not a local end-of-line code.
+
+            A protected reply may only be sent if a security data
+            exchange has succeeded.
+
+            The 63z reply may be a multiline reply.  In this case, the
+            plaintext reply must be broken up into a number of
+            fragments.  Each fragment must be protected, then base 64
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 13]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+            encoded in order into a separate line of the multiline
+            reply.  There need not be any correspondence between the
+            line breaks in the plaintext reply and the encoded reply.
+            Telnet end-of-line codes must appear in the plaintext of the
+            encoded reply, except for the final end-of-line code, which
+            is optional.
+
+            The multiline reply must be formatted more strictly than the
+            continuation specification in RFC 959.  In particular, each
+            line before the last must be formed by the reply code,
+            followed immediately by a hyphen, followed by a base 64
+            encoded fragment of the reply.
+
+            For example, if the plaintext reply is
+
+               123-First line
+               Second line
+                 234 A line beginning with numbers
+               123 The last line
+
+            then the resulting protected reply could be any of the
+            following (the first example has a line break only to fit
+            within the margins):
+
+  631 base64(protect("123-First line\r\nSecond line\r\n  234 A line
+  631-base64(protect("123-First line\r\n"))
+  631-base64(protect("Second line\r\n"))
+  631-base64(protect("  234 A line beginning with numbers\r\n"))
+  631 base64(protect("123 The last line"))
+
+  631-base64(protect("123-First line\r\nSecond line\r\n  234 A line b"))
+  631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
+
+6.  Data Channel Encapsulation
+
+   When data transfers are protected between the client and server (in
+   either direction), certain transformations and encapsulations must be
+   performed so that the recipient can properly decode the transmitted
+   file.
+
+   The sender must apply all protection services after transformations
+   associated with the representation type, file structure, and transfer
+   mode have been performed.  The data sent over the data channel is,
+   for the purposes of protection, to be treated as a byte stream.
+
+   When performing a data transfer in an authenticated manner, the
+   authentication checks are performed on individual blocks of the file,
+   rather than on the file as a whole. Consequently, it is possible for
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 14]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   insertion attacks to insert blocks into the data stream (i.e.,
+   replays) that authenticate correctly, but result in a corrupted file
+   being undetected by the receiver. To guard against such attacks, the
+   specific security mechanism employed should include mechanisms to
+   protect against such attacks.  Many GSS-API mechanisms usable with
+   the specification in Appendix I, and the Kerberos mechanism in
+   Appendix II do so.
+
+   The sender must take the input byte stream, and break it up into
+   blocks such that each block, when encoded using a security mechanism
+   specific procedure, will be no larger than the buffer size negotiated
+   by the client with the PBSZ command.  Each block must be encoded,
+   then transmitted with the length of the encoded block prepended as a
+   four byte unsigned integer, most significant byte first.
+
+   When the end of the file is reached, the sender must encode a block
+   of zero bytes, and send this final block to the recipient before
+   closing the data connection.
+
+   The recipient will read the four byte length, read a block of data
+   that many bytes long, then decode and verify this block with a
+   security mechanism specific procedure.  This must be repeated until a
+   block encoding a buffer of zero bytes is received.  This indicates
+   the end of the encoded byte stream.
+
+   Any transformations associated with the representation type, file
+   structure, and transfer mode are to be performed by the recipient on
+   the byte stream resulting from the above process.
+
+   When using block transfer mode, the sender's (cleartext) buffer size
+   is independent of the block size.
+
+   The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
+   command if the current protection level is not at the level dictated
+   by the server's security requirements for the particular file
+   transfer.
+
+   If any data protection services fail at any time during data transfer
+   at the server end (including an attempt to send a buffer size greater
+   than the negotiated maximum), the server will send a 535 reply to the
+   data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
+
+
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 15]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+7.  Potential policy considerations
+
+   While there are no restrictions on client and server policy, there
+   are a few recommendations which an implementation should implement.
+
+    - Once a security data exchange takes place, a server should require
+      all commands be protected (with integrity and/or confidentiality),
+      and it should protect all replies.  Replies should use the same
+      level of protection as the command which produced them.  This
+      includes replies which indicate failure of the MIC, CONF, and ENC
+      commands.  In particular, it is not meaningful to require that
+      AUTH and ADAT be protected; it is meaningful and useful to require
+      that PROT and PBSZ be protected.  In particular, the use of CCC is
+      not recommended, but is defined in the interest of
+      interoperability between implementations which might desire such
+      functionality.
+
+    - A client should encrypt the PASS command whenever possible.  It is
+      reasonable for the server to refuse to accept a non-encrypted PASS
+      command if the server knows encryption is available.
+
+    - Although no security commands are required to be implemented, it
+      is recommended that an implementation provide all commands which
+      can be implemented, given the mechanisms supported and the policy
+      considerations of the site (export controls, for instance).
+
+8.  Declarative specifications
+
+   These sections are modelled after sections 5.3 and 5.4 of RFC 959,
+   which describe the same information, except for the standard FTP
+   commands and replies.
+
+   8.1.  FTP Security commands and arguments
+
+      AUTH <SP> <mechanism-name> <CRLF>
+      ADAT <SP> <base64data> <CRLF>
+      PROT <SP> <prot-code> <CRLF>
+      PBSZ <SP> <decimal-integer> <CRLF>
+      MIC <SP> <base64data> <CRLF>
+      CONF <SP> <base64data> <CRLF>
+      ENC <SP> <base64data> <CRLF>
+
+      <mechanism-name> ::= <string>
+      <base64data> ::= <string>
+              ; must be formatted as described in section 9
+      <prot-code> ::= C | S | E | P
+      <decimal-integer> ::= any decimal integer from 1 to (2^32)-1
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 16]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   8.2.  Command-Reply sequences
+
+      Security Association Setup
+         AUTH
+            234
+            334
+            502, 504, 534, 431
+            500, 501, 421
+         ADAT
+            235
+            335
+            503, 501, 535
+            500, 501, 421
+      Data protection negotiation commands
+         PBSZ
+            200
+            503
+            500, 501, 421, 530
+         PROT
+            200
+            504, 536, 503, 534, 431
+            500, 501, 421, 530
+      Command channel protection commands
+         MIC
+            535, 533
+            500, 501, 421
+         CONF
+            535, 533
+            500, 501, 421
+         ENC
+            535, 533
+            500, 501, 421
+      Security-Enhanced login commands (only new replies listed)
+         USER
+            232
+            336
+      Data channel commands (only new replies listed)
+         STOR
+            534, 535
+         STOU
+            534, 535
+         RETR
+            534, 535
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 17]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+         LIST
+            534, 535
+         NLST
+            534, 535
+         APPE
+            534, 535
+
+      In addition to these reply codes, any security command can return
+      500, 501, 502, 533, or 421.  Any ftp command can return a reply
+      code encapsulated in a 631, 632, or 633 reply once a security data
+      exchange has completed successfully.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 18]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+9.  State Diagrams
+
+   This section includes a state diagram which demonstrates the flow of
+   authentication and authorization in a security enhanced FTP
+   implementation.  The rectangular blocks show states where the client
+   must issue a command, and the diamond blocks show states where the
+   server must issue a response.
+
+
+          ,------------------,  USER
+       __\| Unauthenticated  |_________\
+      |  /| (new connection) |         /|
+      |   `------------------'          |
+      |            |                    |
+      |            | AUTH               |
+      |            V                    |
+      |           / \                   |
+      | 4yz,5yz  /   \   234            |
+      |<--------<     >------------->.  |
+      |          \   /               |  |
+      |           \_/                |  |
+      |            |                 |  |
+      |            | 334             |  |
+      |            V                 |  |
+      |  ,--------------------,      |  |
+      |  | Need Security Data |<--.  |  |
+      |  `--------------------'   |  |  |
+      |            |              |  |  |
+      |            | ADAT         |  |  |
+      |            V              |  |  |
+      |           / \             |  |  |
+      | 4yz,5yz  /   \   335      |  |  |
+      `<--------<     >-----------'  |  |
+                 \   /               |  |
+                  \_/                |  |
+                   |                 |  |
+                   | 235             |  |
+                   V                 |  |
+           ,---------------.         |  |
+      ,--->| Authenticated |<--------'  |  After the client and server
+      |    `---------------'            |  have completed authenti-
+      |            |                    |  cation, command must be
+      |            | USER               |  integrity-protected if
+      |            |                    |  integrity is available.  The
+      |            |<-------------------'  CCC command may be issued to
+      |            V                       relax this restriction.
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 19]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+      |           / \
+      | 4yz,5yz  /   \   2yz
+      |<--------<     >------------->.
+      |          \   /               |
+      |           \_/                |
+      |            |                 |
+      |            | 3yz             |
+      |            V                 |
+      |    ,---------------.         |
+      |    | Need Password |         |
+      |    `---------------'         |
+      |            |                 |
+      |            | PASS            |
+      |            V                 |
+      |           / \                |
+      | 4yz,5yz  /   \   2yz         |
+      |<--------<     >------------->|
+      |          \   /               |
+      |           \_/                |
+      |            |                 |
+      |            | 3yz             |
+      |            V                 |
+      |    ,--------------.          |
+      |    | Need Account |          |
+      |    `--------------'          |
+      |            |                 |
+      |            | ACCT            |
+      |            V                 |
+      |           / \                |
+      | 4yz,5yz  /   \   2yz         |
+      `<--------<     >------------->|
+                 \   /               |
+                  \_/                |
+                   |                 |
+                   | 3yz             |
+                   V                 |
+             ,-------------.         |
+             | Authorized  |/________|
+             | (Logged in) |\
+             `-------------'
+
+
+
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 20]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+10.  Base 64 Encoding
+
+   Base 64 encoding is the same as the Printable Encoding described in
+   Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
+   included. This encoding is defined as follows.
+
+   Proceeding from left to right, the bit string resulting from the
+   mechanism specific protection routine is encoded into characters
+   which are universally representable at all sites, though not
+   necessarily with the same bit patterns (e.g., although the character
+   "E" is represented in an ASCII-based system as hexadecimal 45 and as
+   hexadecimal C5 in an EBCDIC-based system, the local significance of
+   the two representations is equivalent).
+
+   A 64-character subset of International Alphabet IA5 is used, enabling
+   6 bits to be represented per printable character.  (The proposed
+   subset of characters is represented identically in IA5 and ASCII.)
+   The character "=" signifies a special processing function used for
+   padding within the printable encoding procedure.
+
+   The encoding process represents 24-bit groups of input bits as output
+   strings of 4 encoded characters.  Proceeding from left to right
+   across a 24-bit input group output from the security mechanism
+   specific message protection procedure, each 6-bit group is used as an
+   index into an array of 64 printable characters, namely "[A-Z][a-
+   z][0-9]+/".  The character referenced by the index is placed in the
+   output string.  These characters are selected so as to be universally
+   representable, and the set excludes characters with particular
+   significance to Telnet (e.g., "<CR>", "<LF>", IAC).
+
+   Special processing is performed if fewer than 24 bits are available
+   in an input group at the end of a message.  A full encoding quantum
+   is always completed at the end of a message.  When fewer than 24
+   input bits are available in an input group, zero bits are added (on
+   the right) to form an integral number of 6-bit groups.  Output
+   character positions which are not required to represent actual input
+   data are set to the character "=".  Since all canonically encoded
+   output is an integral number of octets, only the following cases can
+   arise: (1) the final quantum of encoding input is an integral
+   multiple of 24 bits; here, the final unit of encoded output will be
+   an integral multiple of 4 characters with no "=" padding, (2) the
+   final quantum of encoding input is exactly 8 bits; here, the final
+   unit of encoded output will be two characters followed by two "="
+   padding characters, or (3) the final quantum of encoding input is
+   exactly 16 bits; here, the final unit of encoded output will be three
+   characters followed by one "=" padding character.
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 21]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   Implementors must keep in mind that the base 64 encodings in ADAT,
+   MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily
+   long.  Thus, the entire line must be read before it can be processed.
+   Several successive reads on the control channel may be necessary.  It
+   is not appropriate to for a server to reject a command containing a
+   base 64 encoding simply because it is too long (assuming that the
+   decoding is otherwise well formed in the context in which it was
+   sent).
+
+   Case must not be ignored when reading commands and replies containing
+   base 64 encodings.
+
+11.  Security Considerations
+
+   This entire document deals with security considerations related to
+   the File Transfer Protocol.
+
+   Third party file transfers cannot be secured using these extensions,
+   since a security context cannot be established between two servers
+   using these facilities (no control connection exists between servers
+   over which to pass ADAT tokens).  Further work in this area is
+   deferred.
+
+12.  Acknowledgements
+
+   I would like to thank the members of the CAT WG, as well as all
+   participants in discussions on the "cat-ietf@mit.edu" mailing list,
+   for their contributions to this document.  I would especially like to
+   thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
+   Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk
+   for their contributions to this work.  Of course, without Steve Lunt,
+   the author of the first six revisions of this document, it would not
+   exist at all.
+
+13.  References
+
+   [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
+      Option", Work in Progress.
+
+   [RFC-1123] Braden, R., "Requirements for Internet Hosts --
+      Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
+      Mail: Part I: Message Encryption and Authentication Procedures",
+      RFC 1421, February 1993.
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 22]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+14.  Author's Address
+
+   Marc Horowitz
+   Cygnus Solutions
+   955 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: +1 617 354 7688
+   EMail: marc@cygnus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 23]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+Appendix I: Specification under the GSSAPI
+
+   In order to maximise the utility of new security mechanisms, it is
+   desirable that new mechanisms be implemented as GSSAPI mechanisms
+   rather than as FTP security mechanisms.  This will enable existing
+   ftp implementations to support the new mechanisms more easily, since
+   little or no code will need to be changed.  In addition, the
+   mechanism will be usable by other protocols, such as IMAP, which are
+   built on top of the GSSAPI, with no additional specification or
+   implementation work needed by the mechanism designers.
+
+   The security mechanism name (for the AUTH command) associated with
+   all mechanisms employing the GSSAPI is GSSAPI.  If the server
+   supports a security mechanism employing the GSSAPI, it must respond
+   with a 334 reply code indicating that an ADAT command is expected
+   next.
+
+   The client must begin the authentication exchange by calling
+   GSS_Init_Sec_Context, passing in 0 for input_context_handle
+   (initially), and a targ_name equal to output_name from
+   GSS_Import_Name called with input_name_type of Host-Based Service and
+   input_name_string of "ftp@hostname" where "hostname" is the fully
+   qualified host name of the server with all letters in lower case.
+   (Failing this, the client may try again using input_name_string of
+   "host@hostname".) The output_token must then be base 64 encoded and
+   sent to the server as the argument to an ADAT command.  If
+   GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client
+   must expect a token to be returned in the reply to the ADAT command.
+   This token must subsequently be passed to another call to
+   GSS_Init_Sec_Context.  In this case, if GSS_Init_Sec_Context returns
+   no output_token, then the reply code from the server for the previous
+   ADAT command must have been 235.  If GSS_Init_Sec_Context returns
+   GSS_S_COMPLETE, then no further tokens are expected from the server,
+   and the client must consider the server authenticated.
+
+   The server must base 64 decode the argument to the ADAT command and
+   pass the resultant token to GSS_Accept_Sec_Context as input_token,
+   setting acceptor_cred_handle to NULL (for "use default credentials"),
+   and 0 for input_context_handle (initially).  If an output_token is
+   returned, it must be base 64 encoded and returned to the client by
+   including "ADAT=base64string" in the text of the reply.  If
+   GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be
+   235, and the server must consider the client authenticated.  If
+   GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code
+   must be 335.  Otherwise, the reply code should be 535, and the text
+   of the reply should contain a descriptive error message.
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 24]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   The chan_bindings input to GSS_Init_Sec_Context and
+   GSS_Accept_Sec_Context should use the client internet address and
+   server internet address as the initiator and acceptor addresses,
+   respectively.  The address type for both should be GSS_C_AF_INET. No
+   application data should be specified.
+
+   Since GSSAPI supports anonymous peers to security contexts, it is
+   possible that the client's authentication of the server does not
+   actually establish an identity.
+
+   The procedure associated with MIC commands, 631 replies, and Safe
+   file transfers is:
+
+      GSS_Wrap for the sender, with conf_flag == FALSE
+
+      GSS_Unwrap for the receiver
+
+   The procedure associated with ENC commands, 632 replies, and Private
+   file transfers is:
+
+      GSS_Wrap for the sender, with conf_flag == TRUE
+      GSS_Unwrap for the receiver
+
+   CONF commands and 633 replies are not supported.
+
+   Both the client and server should inspect the value of conf_avail to
+   determine whether the peer supports confidentiality services.
+
+   When the security state is reset (when AUTH is received a second
+   time, or when REIN is received), this should be done by calling the
+   GSS_Delete_sec_context function.
+
+Appendix II:  Specification under Kerberos version 4
+
+   The security mechanism name (for the AUTH command) associated with
+   Kerberos Version 4 is KERBEROS_V4.  If the server supports
+   KERBEROS_V4, it must respond with a 334 reply code indicating that an
+   ADAT command is expected next.
+
+   The client must retrieve a ticket for the Kerberos principal
+   "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
+   of "ftp", an instance equal to the first part of the canonical host
+   name of the server with all letters in lower case (as returned by
+   krb_get_phost(3)), the server's realm name (as returned by
+   krb_realmofhost(3)), and an arbitrary checksum.  The ticket must then
+   be base 64 encoded and sent as the argument to an ADAT command.
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 25]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+   If the "ftp" principal name is not a registered principal in the
+   Kerberos database, then the client may fall back on the "rcmd"
+   principal name (same instance and realm).  However, servers must
+   accept only one or the other of these principal names, and must not
+   be willing to accept either.  Generally, if the server has a key for
+   the "ftp" principal in its srvtab, then that principal only must be
+   used, otherwise the "rcmd" principal only must be used.
+
+   The server must base 64 decode the argument to the ADAT command and
+   pass the result to krb_rd_req(3).  The server must add one to the
+   checksum from the authenticator, convert the result to network byte
+   order (most significant byte first), and sign it using
+   krb_mk_safe(3), and base 64 encode the result.  Upon success, the
+   server must reply to the client with a 235 code and include
+   "ADAT=base64string" in the text of the reply.  Upon failure, the
+   server should reply 535.
+
+   Upon receipt of the 235 reply from the server, the client must parse
+   the text of the reply for the base 64 encoded data, decode it,
+   convert it from network byte order, and pass the result to
+   krb_rd_safe(3).  The client must consider the server authenticated if
+   the resultant checksum is equal to one plus the value previously
+   sent.
+
+   The procedure associated with MIC commands, 631 replies, and Safe
+   file transfers is:
+
+      krb_mk_safe(3) for the sender
+      krb_rd_safe(3) for the receiver
+
+   The procedure associated with ENC commands, 632 replies, and Private
+   file transfers is:
+
+      krb_mk_priv(3) for the sender
+      krb_rd_priv(3) for the receiver
+
+   CONF commands and 633 replies are not supported.
+
+   Note that this specification for KERBEROS_V4 contains no provision
+   for negotiating alternate means for integrity and confidentiality
+   routines.  Note also that the ADAT exchange does not convey whether
+   the peer supports confidentiality services.
+
+   In order to stay within the allowed PBSZ, implementors must take note
+   that a cleartext buffer will grow by 31 bytes when processed by
+   krb_mk_safe(3) and will grow by 26 bytes when processed by
+   krb_mk_priv(3).
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 26]
+
+RFC 2228                FTP Security Extensions             October 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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
+   andand 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz & Lunt             Standards Track                    [Page 27]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2253.txt b/third_party/heimdal/doc/standardisation/rfc2253.txt
new file mode 100644
index 00000000000..a7439eed776
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2253.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wahl
+Request for Comments: 2253                           Critical Angle Inc.
+Obsoletes: 1779                                                 S. Kille
+Category: Standards Track                                     Isode Ltd.
+                                                                T. Howes
+                                           Netscape Communications Corp.
+                                                           December 1997
+
+
+              Lightweight Directory Access Protocol (v3):
+           UTF-8 String Representation of Distinguished Names
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+IESG Note
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 1]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+Abstract
+
+   The X.500 Directory uses distinguished names as the primary keys to
+   entries in the directory.  Distinguished Names are encoded in ASN.1
+   in the X.500 Directory protocols.  In the Lightweight Directory
+   Access Protocol, a string representation of distinguished names is
+   transferred.  This specification defines the string format for
+   representing names, which is designed to give a clean representation
+   of commonly used distinguished names, while being able to represent
+   any distinguished name.
+
+   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 [6].
+
+1.  Background
+
+   This specification assumes familiarity with X.500 [1], and the
+   concept of Distinguished Name.  It is important to have a common
+   format to be able to unambiguously represent a distinguished name.
+   The primary goal of this specification is ease of encoding and
+   decoding.  A secondary goal is to have names that are human readable.
+   It is not expected that LDAP clients with a human user interface
+   would display these strings directly to the user, but would most
+   likely be performing translations (such as expressing attribute type
+   names in one of the local national languages).
+
+2.  Converting DistinguishedName from ASN.1 to a String
+
+   In X.501 [2] the ASN.1 structure of distinguished name is defined as:
+
+       DistinguishedName ::= RDNSequence
+
+       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 2]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+        AttributeTypeAndValue
+
+       AttributeTypeAndValue ::= SEQUENCE {
+        type  AttributeType,
+        value AttributeValue }
+
+   The following sections define the algorithm for converting from an
+   ASN.1 structured representation to a UTF-8 string representation.
+
+2.1. Converting the RDNSequence
+
+   If the RDNSequence is an empty sequence, the result is the empty or
+   zero length string.
+
+   Otherwise, the output consists of the string encodings of each
+   RelativeDistinguishedName in the RDNSequence (according to 2.2),
+   starting with the last element of the sequence and moving backwards
+   toward the first.
+
+   The encodings of adjoining RelativeDistinguishedNames are separated
+   by a comma character (',' ASCII 44).
+
+2.2.  Converting RelativeDistinguishedName
+
+   When converting from an ASN.1 RelativeDistinguishedName to a string,
+   the output consists of the string encodings of each
+   AttributeTypeAndValue (according to 2.3), in any order.
+
+   Where there is a multi-valued RDN, the outputs from adjoining
+   AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
+   character.
+
+2.3.  Converting AttributeTypeAndValue
+
+   The AttributeTypeAndValue is encoded as the string representation of
+   the AttributeType, followed by an equals character ('=' ASCII 61),
+   followed by the string representation of the AttributeValue.  The
+   encoding of the AttributeValue is given in section 2.4.
+
+   If the AttributeType is in a published table of attribute types
+   associated with LDAP [4], then the type name string from that table
+   is used, otherwise it is encoded as the dotted-decimal encoding of
+   the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
+   described in [3].  As an example, strings for a few of the attribute
+   types frequently seen in RDNs include:
+
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 3]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+                    String  X.500 AttributeType
+                    ------------------------------
+                    CN      commonName
+                    L       localityName
+                    ST      stateOrProvinceName
+                    O       organizationName
+                    OU      organizationalUnitName
+                    C       countryName
+                    STREET  streetAddress
+                    DC      domainComponent
+                    UID     userid
+
+2.4.  Converting an AttributeValue from ASN.1 to a String
+
+   If the AttributeValue is of a type which does not have a string
+   representation defined for it, then it is simply encoded as an
+   octothorpe character ('#' ASCII 35) followed by the hexadecimal
+   representation of each of the bytes of the BER encoding of the X.500
+   AttributeValue.  This form SHOULD be used if the AttributeType is of
+   the dotted-decimal form.
+
+   Otherwise, if the AttributeValue is of a type which has a string
+   representation, the value is converted first to a UTF-8 string
+   according to its syntax specification (see for example section 6 of
+   [4]).
+
+   If the UTF-8 string does not have any of the following characters
+   which need escaping, then that string can be used as the string
+   representation of the value.
+
+    o   a space or "#" character occurring at the beginning of the
+        string
+
+    o   a space character occurring at the end of the string
+
+    o   one of the characters ",", "+", """, "\", "<", ">" or ";"
+
+   Implementations MAY escape other characters.
+
+   If a character to be escaped is one of the list shown above, then it
+   is prefixed by a backslash ('\' ASCII 92).
+
+   Otherwise the character to be escaped is replaced by a backslash and
+   two hex digits, which form a single byte in the code of the
+   character.
+
+   Examples of the escaping mechanism are shown in section 5.
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 4]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+3. Parsing a String back to a Distinguished Name
+
+   The structure of the string is specified in a BNF grammar, based on
+   the grammar defined in RFC 822 [5].  Server implementations parsing a
+   DN string generated by an LDAPv2 client MUST also accept (and ignore)
+   the variants given in section 4 of this document.
+
+distinguishedName = [name]                    ; may be empty string
+
+name       = name-component *("," name-component)
+
+name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
+
+attributeTypeAndValue = attributeType "=" attributeValue
+
+attributeType = (ALPHA 1*keychar) / oid
+keychar    = ALPHA / DIGIT / "-"
+
+oid        = 1*DIGIT *("." 1*DIGIT)
+
+attributeValue = string
+
+string     = *( stringchar / pair )
+             / "#" hexstring
+             / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
+
+quotechar     = <any character except "\" or QUOTATION >
+
+special    = "," / "=" / "+" / "<" /  ">" / "#" / ";"
+
+pair       = "\" ( special / "\" / QUOTATION / hexpair )
+stringchar = <any character except one of special, "\" or QUOTATION >
+
+hexstring  = 1*hexpair
+hexpair    = hexchar hexchar
+
+hexchar    = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+             / "a" / "b" / "c" / "d" / "e" / "f"
+
+ALPHA      =  <any ASCII alphabetic character>
+                                         ; (decimal 65-90 and 97-122)
+DIGIT      =  <any ASCII decimal digit>  ; (decimal 48-57)
+QUOTATION  =  <the ASCII double quotation mark character '"' decimal 34>
+
+
+
+
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 5]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+4.  Relationship with RFC 1779 and LDAPv2
+
+   The syntax given in this document is more restrictive than the syntax
+   in RFC 1779.  Implementations parsing a string generated by an LDAPv2
+   client MUST accept the syntax of RFC 1779.  Implementations MUST NOT,
+   however, generate any of the RFC 1779 encodings which are not
+   described above in section 2.
+
+   Implementations MUST allow a semicolon character to be used instead
+   of a comma to separate RDNs in a distinguished name, and MUST also
+   allow whitespace characters to be present on either side of the comma
+   or semicolon.  The whitespace characters are ignored, and the
+   semicolon replaced with a comma.
+
+   Implementations MUST allow an oid in the attribute type to be
+   prefixed by one of the character strings "oid." or "OID.".
+
+   Implementations MUST allow for space (' ' ASCII 32) characters to be
+   present between name-component and ',', between attributeTypeAndValue
+   and '+', between attributeType and '=', and between '=' and
+   attributeValue.  These space characters are ignored when parsing.
+
+   Implementations MUST allow a value to be surrounded by quote ('"'
+   ASCII 34) characters, which are not part of the value.  Inside the
+   quoted value, the following characters can occur without any
+   escaping:
+
+                   ",", "=", "+", "<", ">", "#" and ";"
+
+5.  Examples
+
+   This notation is designed to be convenient for common forms of name.
+   This section gives a few examples of distinguished names written
+   using this notation.  First is a name containing three relative
+   distinguished names (RDNs):
+
+   CN=Steve Kille,O=Isode Limited,C=GB
+
+   Here is an example name containing three RDNs, in which the first RDN
+   is multi-valued:
+
+   OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
+
+   This example shows the method of quoting of a comma in an
+   organization name:
+
+   CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 6]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+   An example name in which a value contains a carriage return
+   character:
+
+   CN=Before\0DAfter,O=Test,C=GB
+
+   An example name in which an RDN was of an unrecognized type.  The
+   value is the BER encoding of an OCTET STRING containing two bytes
+   0x48 and 0x69.
+
+   1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
+
+   Finally, an example of an RDN surname value consisting of 5 letters:
+
+   Unicode Letter Description      10646 code UTF-8  Quoted
+   =============================== ========== ====== =======
+   LATIN CAPITAL LETTER L          U0000004C  0x4C   L
+   LATIN SMALL LETTER U            U00000075  0x75   u
+   LATIN SMALL LETTER C WITH CARON U0000010D  0xC48D \C4\8D
+   LATIN SMALL LETTER I            U00000069  0x69   i
+   LATIN SMALL LETTER C WITH ACUTE U00000107  0xC487 \C4\87
+
+   Could be written in printable ASCII (useful for debugging purposes):
+
+   SN=Lu\C4\8Di\C4\87
+
+6.  References
+
+   [1] The Directory -- overview of concepts, models and services.
+       ITU-T Rec. X.500(1993).
+
+   [2] The Directory -- Models. ITU-T Rec. X.501(1993).
+
+   [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+       Access  Protocol (v3)", RFC 2251, December 1997.
+
+   [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+       Directory Access Protocol (v3): Attribute Syntax Definitions",
+       RFC 2252, December 1997.
+
+   [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
+       Messages", STD 11, RFC 822, August 1982.
+
+   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", RFC 2119.
+
+
+
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 7]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+7.  Security Considerations
+
+7.1. Disclosure
+
+   Distinguished Names typically consist of descriptive information
+   about the entries they name, which can be people, organizations,
+   devices or other real-world objects.  This frequently includes some
+   of the following kinds of information:
+
+   - the common name of the object (i.e. a person's full name)
+   - an email or TCP/IP address
+   - its physical location (country, locality, city, street address)
+   - organizational attributes (such as department name or affiliation)
+
+   Most countries have privacy laws regarding the publication of
+   information about people.
+
+7.2. Use of Distinguished Names in Security Applications
+
+   The transformations of an AttributeValue value from its X.501 form to
+   an LDAP string representation are not always reversible back to the
+   same BER or DER form.  An example of a situation which requires the
+   DER form of a distinguished name is the verification of an X.509
+   certificate.
+
+   For example, a distinguished name consisting of one RDN with one AVA,
+   in which the type is commonName and the value is of the TeletexString
+   choice with the letters 'Sam' would be represented in LDAP as the
+   string CN=Sam.  Another distinguished name in which the value is
+   still 'Sam' but of the PrintableString choice would have the same
+   representation CN=Sam.
+
+   Applications which require the reconstruction of the DER form of the
+   value SHOULD NOT use the string representation of attribute syntaxes
+   when converting a distinguished name to the LDAP format.  Instead,
+   they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
+   as described in the first paragraph of section 2.4.
+
+8.  Authors' Addresses
+
+   Mark Wahl
+   Critical Angle Inc.
+   4815 W. Braker Lane #502-385
+   Austin, TX 78759
+   USA
+
+   EMail:  M.Wahl@critical-angle.com
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 8]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+   Steve Kille
+   Isode Ltd.
+   The Dome
+   The Square
+   Richmond, Surrey
+   TW9 1DT
+   England
+
+   Phone:  +44-181-332-9091
+   EMail:  S.Kille@ISODE.COM
+
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Rd, MS MV068
+   Mountain View, CA 94043
+   USA
+
+   Phone:  +1 650 937-3419
+   EMail:   howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.              Proposed Standard                    [Page 9]
+
+RFC 2253               LADPv3 Distinguished Names          December 1997
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.              Proposed Standard                   [Page 10]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2478.txt b/third_party/heimdal/doc/standardisation/rfc2478.txt
new file mode 100644
index 00000000000..83395577d48
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2478.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         E. Baize
+Request for Comments: 2478                                   D. Pinkas
+Category: Standards Track                                         Bull
+                                                         December 1998
+
+
+         The Simple and Protected GSS-API Negotiation Mechanism
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.  ABSTRACT
+
+   This document specifies a Security Negotiation Mechanism for the
+   Generic Security Service Application Program Interface (GSS-API)
+   which is described in [1].
+
+   The GSS-API provides a generic interface which can be layered atop
+   different security mechanisms such that if communicating peers
+   acquire GSS-API credentials for the same security mechanism, then a
+   security context may be established between them (subject to policy).
+   However, GSS-API doesn't prescribe the method by which GSS-API peers
+   can establish whether they have a common security mechanism.
+
+   The Simple and Protected GSS-API Negotiation Mechanism defined here
+   is a pseudo-security mechanism, represented by the object identifier
+   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
+   enables GSS-API peers to determine in-band whether their credentials
+   share common GSS-API security mechanism(s), and if so, to invoke
+   normal security context establishment for a selected common security
+   mechanism. This is most useful for applications that are based on
+   GSS-API implementations which support multiple security mechanisms.
+
+   This allows to negotiate different security mechanisms, different
+   options within a given security mechanism or different options from
+   several security mechanisms.
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                     [Page 1]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+   Once the common security mechanism is identified, the security
+   mechanism may also negotiate mechanism-specific options during its
+   context establishment. This will be inside the mechanism tokens, and
+   invisible to the SPNEGO protocol.
+
+   The simple and protected GSS-API mechanism negotiation is based on
+   the following negotiation model : the initiator proposes one security
+   mechanism or an ordered list of security mechanisms, the target
+   either accepts the proposed security mechanism, or chooses one from
+   an offered set, or rejects the proposed value(s). The target then
+   informs the initiator of its choice.
+
+   In its basic form this protocol requires an extra-round trip. Network
+   connection setup is a critical performance characteristic of any
+   network infrastructure and extra round trips over WAN links, packet
+   radio networks, etc. really make a difference. In order to avoid such
+   an extra round trip the initial security token of the preferred
+   mechanism for the initiator may be embedded in the initial token. If
+   the target preferred mechanism matches the initiator's preferred
+   mechanism, no additional round trips are incurred by using the
+   negotiation protocol.
+
+   The simple and protected GSS-API mechanism negotiation provides a
+   technique to protect the negotiation that must be used when the
+   underlying mechanism selected by the target is capable of integrity
+   protection.
+
+   When all the mechanisms proposed by the initiator support integrity
+   protection or when the selected mechanism supports integrity
+   protection, then the negotiation mechanism becomes protected since
+   this guarantees that the appropriate mechanism supported by both
+   peers has been selected.
+
+   The Simple and Protected GSS-API Negotiation Mechanism uses the
+   concepts developed in the GSS-API specification [1]. The negotiation
+   data is encapsulated in context-level tokens. Therefore, callers of
+   the GSS-API do not need to be aware of the existence of the
+   negotiation tokens but only of the new pseudo-security mechanism. A
+   failure in the negotiation phase causes a major status code to be
+   returned: GSS_S_BAD_MECH.
+
+
+
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                     [Page 2]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+2.  NEGOTIATION MODEL
+
+2.1.  Negotiation description
+
+   The model for security mechanism negotiation reuses a subset of the
+   concepts specified in [2].
+
+   Each OID represents one GSS-API mechanism or one variant of it.
+
+    -  When one security mechanism is proposed by the initiator, it
+       represents the only security mechanism supported or selected
+       (when the additional APIs defined in the Annex A are used) by the
+       initiator.
+
+    -  When several security mechanisms are proposed by the initiator,
+       they represent a set of security mechanisms supported or selected
+       (when the additional APIs defined in the Annex A are used) by the
+       initiator.
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms, a set of options (e.g. deleg, replay, conf flags)
+   that should be supported by the selected mechanism and optionally the
+   initial security token for the desired mechanism of the initiator
+   (i.e. the first of the list).
+
+   The first negotiation token sent by the target contains the result of
+   the negotiation (accept_completed, accept_incomplete or reject) and,
+   in case of accept, the agreed security mechanism. It may also include
+   the response to the initial security token from the initiator, when
+   the first proposed mechanism of the initiator has been selected. When
+   the first mechanism is acceptable to the target,it should respond to
+   the initial security token for the desired mechanism of the initiator
+   when it is present. However, if this is not possible, the target can
+   simply ignore it and omit the responseToken from the first reply.
+
+   Implementations that can piggyback the initial token will be rewarded
+   by faster connection setup.
+
+   In case of a successful negotiation, the security mechanism
+   represents the value suitable for the target, and picked up from the
+   list offered by the initiator.  The policy by which the target
+   chooses a mechanism is an implementation-specific local matter.  In
+   the absence of other policy, the target should chose the first
+   mechanism in the list for which valid credentials are available.
+
+   Once a mechanism has been selected, the tokens specific to the
+   selected mechanism are carried within the negotiation tokens (in the
+   mechToken for the initiator and in the responseToken for the target).
+
+
+
+Baize & Pinkas              Standards Track                     [Page 3]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+2.2.  Negotiation procedure
+
+   The negotiation procedure is summarised as follows:
+
+   (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
+       requests (either explicitly, with the negotiation mechanism, or
+       through accepting a default, when the default is the negotiation
+       mechanism) that the Simple and Protected GSS-API Negotiation
+       Mechanism be used;
+
+   (b) the initiator GSS-API implementation emits a negotiation token
+       containing a list of supported security mechanisms for the
+       credentials used for this context establishment, and optionally
+       an initial security token for the first mechanism from that list
+       (i.e. the preferred mechanism), and indicates
+       GSS_S_CONTINUE_NEEDED status;
+
+   (c) The GSS-API initiator sends the token to the target application;
+
+   (d) The GSS-API target deposits the token through invoking
+       GSS_Accept_sec_context. The target GSS-API implementation emits a
+       negotiation token containing which if any of the proposed
+       mechanisms it supports (or has selected).
+
+   If the mechanism selected by the target matches the preferred
+   mechanism identified by the initiator and the initiator provides a
+   mechToken, the negotiation token response may contain also an initial
+   security token from that mechanism.
+
+   If the preferred mechanism is accepted, GSS_Accept_sec_context()
+   indicates GSS_S_COMPLETE when unilateral or mutual authentication has
+   been performed and involves a single token in either direction.
+
+   If a proposed mechanism is accepted, and it was not the preferred
+   mechanism, or if the first negotiation token sent by the initiator
+   did not included a mechToken, then the negotiation token response
+   sent by the target may contain also a response token from that
+   mechanism which transmits mechanism-specific information (e.g. to
+   transmit a certificate). The initiator may ignore such an initial
+   token if it is not prepared to process it.
+
+   If a proposed mechanism other than the preferred mechanism is
+   accepted, or the preferred mechanism is accepted but involves
+   multiple exchanges (e.g. challenge-response authentication), then
+   GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                     [Page 4]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+   If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
+   indicates GSS_S_BAD_MECH status. The security context initialisation
+   has failed.
+
+   (e) The GSS-API target returns the token to the initiator
+       application;
+
+   (f) The GSS-API initiator deposits the token through invoking
+       GSS_Init_sec_context.
+
+   GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,
+   GSS_S_COMPLETE or GSS_S_BAD_MECH status.
+
+      The GSS_S_BAD_MECH status is returned when the negotiation token
+      carries a reject result or when the negotiation token carries an
+      accept result and the mechanism selected by the target is not
+      included in the initial list sent by the initiator.
+
+      The GSS_S_BAD_MIC status is returned when the selected mechanism
+      supports a MIC token but the MIC computed over the list of
+      mechanisms sent by the initiator is missing or incorrect.
+
+      If the negotiation token carries a reject result, the context
+      establishment is impossible. For example, a rejection will occur
+      if the target doesn't support the initiator's proposed mechanism
+      type(s). Upon failure of the mechanism negotiation procedure, the
+      mech_type output parameter value is the negotiation mechanism
+      type.
+
+      The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
+      token carries an accept result and further tokens must be
+      transferred in order to complete context establishment for the
+      selected mechanism. In that case GSS_Init_sec_context() returns an
+      initial context token as output_token (with the selected
+      mechanism's context token encapsulated within that output_token).
+
+      The initiator then sends the output_token to the target. The
+      security context initialisation is then continued according to the
+      standard GSS-API conventions for the selected mechanism, where the
+      tokens of the selected mechanism are encapsulated until the
+      GSS_S_COMPLETE is returned for both the initiator and the target.
+      When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
+      parameter is not yet valid.
+
+      When GSS_S_COMPLETE is returned, the mech_type output parameter
+      indicates the selected mechanism. When the final negotiation token
+      does not contain a MIC, the initiator GSS-API implementation must
+      check the returned/selected mechanism is on the originally
+
+
+
+Baize & Pinkas              Standards Track                     [Page 5]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+      submitted list of mechanisms and also verify that the selected
+      mechanism is not able to support a MIC. When the final negotiation
+      token contains a MIC over the initial mechanisms list sent by the
+      initiator, the MIC must be verified.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters. i.e., these parameters are not applicable to the
+   negotiation process per se.
+
+   The initiator GSS-API calling application may need to know when the
+   negotiation exchanges were protected or not. For this, when
+   GSS_S_COMPLETE is returned, it can simply test the integ_avail flag.
+   When this flag is set it indicates that the negotiation was
+   protected.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as if a particular basic security mechanism had
+   been requested but was not supported.
+
+   When GSS_Acquire_cred is invoked with the negotiation mechanism as
+   desired_mechs, an implementation-specific default credential is used
+   to carry on the negotiation. A set of mechanisms as specified locally
+   by the system administrator is then available for negotiation. If
+   there is a desire for the caller to make its own choice, then an
+   additional API has to be used (see Appendix A).
+
+3.  DATA ELEMENTS
+
+3.1.  Mechanism Type
+
+   MechType::= OBJECT IDENTIFIER
+
+   mechType
+        Each security mechanism is as defined in [1].
+
+3.2.  Negotiation Tokens
+
+   The syntax of the negotiation tokens follows the InitialContextToken
+   syntax defined in [1]. The security mechanism of the initial
+   negotiation token is identified by the Object Identifier
+   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                     [Page 6]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+3.2.1. Syntax
+
+   This section specifies the syntax of the corresponding
+   "innerContextToken" field for the first token and subsequent
+   negotiation tokens. During the mechanism negociation, the
+   "innerContextToken" field contains the ASN.1 structure
+   "NegociationToken" given below, encoded using the DER encoding
+   conventions.
+
+NegotiationToken ::= CHOICE {
+                              negTokenInit  [0]  NegTokenInit,
+                              negTokenTarg  [1]  NegTokenTarg }
+
+MechTypeList ::= SEQUENCE OF MechType
+
+NegTokenInit ::= SEQUENCE {
+                            mechTypes       [0] MechTypeList  OPTIONAL,
+                            reqFlags        [1] ContextFlags  OPTIONAL,
+                            mechToken       [2] OCTET STRING  OPTIONAL,
+                            mechListMIC     [3] OCTET STRING  OPTIONAL
+                         }
+
+ContextFlags ::= BIT STRING {
+        delegFlag       (0),
+        mutualFlag      (1),
+        replayFlag      (2),
+        sequenceFlag    (3),
+        anonFlag        (4),
+        confFlag        (5),
+        integFlag       (6)
+}
+
+negTokenInit
+     Negotiation token sent by the initiator to the target, which
+     contains, for the first token sent, one or more security mechanisms
+     supported by the initiator (as indicated in the field mechTypes)
+     and the service options (reqFlags) that are requested to establish
+     the context. The context flags should be filled in from the
+     req_flags parameter of init_sec_context().
+
+     The mechToken field is optional for the first token sent that all
+     target implementations would not have to support. However for those
+     targets that do support piggybacking the initial mechToken, an
+     optimistic negotiation response is possible. Otherwise the
+     mechToken is used to carry the tokens specific to the mechanism
+     selected.
+
+
+
+
+
+Baize & Pinkas              Standards Track                     [Page 7]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+     The mechListMIC is an optional field. In the case that the chosen
+     mechanism supports integrity, the initiator may optionally include
+     a mechListMIC which is the result of a GetMIC of the MechTypes in
+     the initial NegTokenInit and return GSS_S_COMPLETE.
+
+     When the chosen mechanism uses an odd number of messages, the final
+     mechanism token will be sent from the initiator to the acceptor. In
+     this case, there is a tradeoff between using the optimal number of
+     messages, or using an additional message from the acceptor to the
+     initiator in order to give the initiator assurance that no
+     modification of the initiator's mechanism list occurred. The
+     implementation can choose which tradeoff to make (see section 4.2.2
+     for further details for the processing of that field).
+
+NegTokenTarg ::= SEQUENCE {
+    negResult      [0] ENUMERATED {
+                            accept_completed    (0),
+                            accept_incomplete   (1),
+                            reject              (2) }          OPTIONAL,
+    supportedMech  [1] MechType                                OPTIONAL,
+    responseToken  [2] OCTET STRING                            OPTIONAL,
+    mechListMIC    [3] OCTET STRING                            OPTIONAL
+}
+
+negTokenTarg
+     Negotiation token returned by the target to the initiator which
+     contains, for the first token returned, a global negotiation result
+     and the security mechanism selected (if any).
+
+negResult
+     The result accept_completed indicates that a context has been
+     successfully established, while the result accept_incomplete
+     indicates that additional token exchanges are needed.
+
+          Note: For the case where (a) a single-token context setup is
+          used and (b) the preferred mechanism does not support the
+          integrity facility which would cause a mechListMIC to be
+          generated and enclosed, this feature allows to make a
+          difference between a mechToken sent by the initiator but not
+          processed by the target (accept_incomplete) and a mechToken
+          sent by the initiator and processed by the target
+          (accept_completed).
+
+     For those targets that support piggybacking the initial mechToken,
+     an optimistic negotiation response is possible and includes in that
+     case a responseToken which may continue the authentication exchange
+     (e.g. when mutual authentication has been requested or when
+     unilateral authentication requires several round trips). Otherwise
+
+
+
+Baize & Pinkas              Standards Track                     [Page 8]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+     the responseToken is used to carry the tokens specific to the
+     mechanism selected. For subsequent tokens (if any) returned by the
+     target, negResult, and supportedMech are not present.
+
+     For the last token returned by the target, the mechListMIC, when
+     present, is a MIC computed over the MechTypes using the selected
+     mechanism.
+
+negResult
+     Result of the negotiation exchange, specified by the target.
+
+     This can be either :
+
+          accept_completed
+               The target accepts the preferred security mechanism,
+                and the context is established for the target or,
+
+          accept_incomplete
+               The target accepts one of the proposed security
+               mechanisms and further exchanges are necessary, or,
+
+          reject
+               The target rejects all the proposed security
+               mechanisms.
+
+supportedMech
+     This field has to be present when negResult is "accept_completed"
+     or "accept_incomplete". It is a choice from the mechanisms offered
+     by the initiator.
+
+responseToken
+     This field may be used either to transmit the response to the
+     mechToken when sent by the initiator and when the first mechanism
+     from the list has been selected by the target or to carry the
+     tokens specific to the selected security mechanism.
+
+mechListMIC
+     If the selected mechanism is capable of integrity protection, this
+     field must be present in the last message of the negotiation,
+     (i.e., when the underlying mechanism returns a non-empty token and
+     a major status of GSS_S_COMPLETE); it contains the result of a
+     GetMIC of the MechTypes field in the initial NegTokenInit.  It
+     allows to verify that the list initially sent by the initiator has
+     been received unmodified by the target.
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                     [Page 9]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+3.2.2. Processing of mechListMIC.
+
+   If the mechanism selected by the negotiation does not support
+   integrity, then no mechListMIC is included, otherwise a mechListMIC
+   must be used and validated as indicated below.
+
+   If the mechanism supports integrity and uses an even number of
+   messages, then the target must compute a MIC as described above, and
+   send this in the final NegTokenTarg along with the final mechToken.
+   The initiator when receiving the last token must require that the
+   mechListMIC field be present and valid. In the absence of a valid
+   mechListMIC, the negotiation must fail as if the last context
+   establishment token was invalid.
+
+   In the case that the chosen mechanism supports integrity and uses an
+   odd number of messages, the final mechanism token will be sent from
+   the initiator to the target. In this case, there is a tradeoff
+   between using the optimal number of messages, or using an additional
+   message from the target to the initiator in order to give the
+   initiator assurance that no modification of the initiator's mechanism
+   list occurred. The implementation can choose which tradeoff to make.
+
+   When generating the final NegTokenInit message, the NegTokenInit may
+   optionally include a mechListMIC which is the result of a GetMIC of
+   the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
+   The target must check the presence of the MIC computed over the
+   mechList sent in the initial NegTokenInit. Three cases may then be
+   considered:
+
+      1) If the mechListMIC is present and correct, then
+         GSS_S_COMPLETE is returned to the target with no token; the
+         context is established by the target.
+
+      2) If the mechListMIC is present but invalid, then the context
+         establishment must fail.  An error major status code is
+         returned to the target.
+
+      3) If the mechListMIC is not included in the final NegTokenInit,
+         then GSS_S_COMPLETE must be returned to the target with a
+         token. This token must be a NegTokenTarg, with a MIC included
+         as described above, and no responseToken.  The application will
+         then send this token back to the initiator, which must verify
+         that the mechListMIC field is present and valid.
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 10]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+         Note: If the MIC was originally sent by the initiator, but
+                thenafter deleted by an attacker, the target will send
+                back a token according to the description above, but the
+                initiator will be unable to process that returned token
+                and the context establishment must then fail.
+
+4.  EXAMPLES : SECURITY MECHANISM NEGOTIATION
+
+   Here are some examples of security mechanism negotiation between an
+   initiator (I) and a target (T).
+
+4.1.  Initial steps
+
+   (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
+
+   (I) invokes GSS_Init_sec_context() with :
+
+   Input
+     mech_type = OID for negotiation mechanism or NULL, if the
+     negotiation mechanism is the default mechanism.
+
+   Output
+     major_status = GSS_S_CONTINUE_NEEDED
+     output_token = negTokenInit
+
+   The negotiation token (negTokenInit) contains two security mechanisms
+   with :
+     mechType = GSS-MECH1 or
+     mechType = GSS-MECH2
+
+   (I) sends to (T) the negotiation token.
+
+4.2  Successful negotiation steps
+
+   (T) supports GSS-MECH2
+   (T) receives the negotiation token (negTokenInit) from (I)
+   (T) invokes GSS_Accept_sec_context() with :
+
+   Input
+        input_token = negTokenInit
+
+   Output
+        major_status = GSS_S_CONTINUE_NEEDED
+        output_token = negTokenTarg
+
+   The negotiation token (negTokenTarg) contains :
+        negResult = accept (the negotiation result)
+        supportedMech : mechType = GSS-MECH2
+
+
+
+Baize & Pinkas              Standards Track                    [Page 11]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+   (T) returns the negotiation token (negTokenTarg) to (I)
+   (I) invokes GSS_Init_sec_context() with :
+
+   Input
+        input_token = negTokenTarg
+
+   Output
+        major_status = GSS_S_COMPLETE
+        output_token = initialContextToken (initial context token
+                                            for GSS-MECH2)
+        mech_type = GSS-MECH2
+
+   The subsequent steps are security mechanism specific, and work as
+   specified in [1].  The output tokens from the security mechanism are
+   encapsulated in a NegTokenTarg message (with the supportedMech field
+   omitted, and the mechListMIC included with the last token).
+
+4.3.  Failed negotiation steps
+
+   (T) supports GSS-MECH3.
+   (T) receives the negotiation token (negTokenInit) from (I)
+   (T) invokes GSS_Accept_sec_context() with :
+
+   Input
+        input_token = negTokenInit
+
+   Output
+        major_status = GSS_S_BAD_MECH
+        output_token = negTokenTarg
+
+   The negotiation token (negTokenTarg) contains :
+
+        negResult = reject (the negotiation result)
+
+   (T) returns the negotiation token (negTokenTarg) to (I)
+   (I) invokes GSS_Init_sec_context() with :
+
+   Input
+        input_token = negTokenTarg
+
+   Output
+        major_status = GSS_S_BAD_MECH
+
+   The security context establishment has failed.
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 12]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+4.4 Successful Negotiation with preferred mechanism info
+
+   (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
+
+   (I) invokes GSS_Init_sec_context() with :
+
+   Input
+        mech_type = OID for negotiation mechanism or NULL, if the
+        negotiation mechanism is the default mechanism.
+
+   Output
+        major_status = GSS_S_CONTINUE_NEEDED
+        output_token = negTokenInit
+
+   The negotiation token (negTokenInit) contains two security mechanisms
+   with :
+        mechType = GSS-MECH1 or
+        mechType = GSS-MECH2
+
+        mechToken = output_token from GSS_Init_sec_context
+       ( first mechType) as described in [1]
+
+   (I) sends to (T) the negotiation token.
+
+   (T) supports GSS-MECH1.
+   (T) receives the negotiation token (negTokenInit) from (I)
+   (T) invokes GSS_Accept_sec_context() with :
+
+   Input
+        input_token = negTokenInit
+
+   Output
+        major_status = GSS_S_CONTINUE_NEEDED
+        output_token = negTokenTarg
+
+   The negotiation token (negTokenTarg) contains :
+        negResult = accept (the negotiation result)
+        supportedMech : mechType = GSS-MECH1
+
+        mechToken = output_token from
+                         GSS_Accept_sec_context(mechToken )
+
+   (T) returns the negotiation token (negTokenTarg) to (I)
+   (I) invokes GSS_Init_sec_context() with :
+
+   Input
+        input_token = negTokenTarg
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 13]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+   Output
+        major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
+        output_token = ContextToken (initial or subsequent context token
+                       for GSS-MECH1)
+        mech_type = GSS-MECH1
+
+   Specific implementations of the protocol can support the optimistic
+   negotiation by completing the security context establishment using the
+   agreed upon mechanism as described in [1].  As described above in
+   section 5.2, the output tokens from the security mechanisms are
+   encapsulated in a NegTokenTarg message (with the negResult and
+   supportedMech fields omitted, and the mechListMIC included with the
+   last token).
+
+5.  SECURITY CONSIDERATIONS
+
+   When the mechanism selected by the target from the list supplied by
+   the initiator supports integrity protection, then the negotiation is
+   protected.
+
+   When one of the mechanisms proposed by the initiator does not support
+   integrity protection, then the negotiation is exposed to all threats
+   a non secured service is exposed. In particular, an active attacker
+   can force to use a security mechanism which is not the common
+   preferred one (when multiple security mechanisms are shared between
+   peers) but which is acceptable anyway to the target.
+
+   In any case, the communicating peers may be exposed to the denial of
+   service threat.
+
+6.  ACKNOWLEDGMENTS
+
+   Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of
+   Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum
+   Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for
+   reviewing earlier versions of this document and for providing useful
+   inputs. Acknowledgments are also due to Peter Brundrett of Microsoft
+   for his proposal for an optimistic negotiation, and for Bill
+   Sommerfeld of Epilogue Technology for his proposal for protecting the
+   negotiation.
+
+
+
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 14]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+APPENDIX A
+
+
+   GSS-API NEGOTIATION SUPPORT API
+
+   In order to provide to a GSS-API caller (either the initiator or the
+   target or both) the ability to choose among the set of supported
+   mechanisms a reduced set of mechanisms for negotiation, two
+   additional APIs are defined:
+
+   GSS_Get_neg_mechs() indicates the set of security mechanisms
+   available on the local system to the caller for negotiation.
+
+   GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+   used on the local system by the caller for negotiation.
+
+A.1.  GSS_Set_neg_mechs call
+
+   Input:
+        cred_handle          CREDENTIAL HANDLE
+                             - NULL specifies default credentials
+        mech_set             SET OF OBJECT IDENTIFIER
+
+   Outputs:
+        major_status INTEGER,
+        minor_status INTEGER,
+
+   Return major_status codes :
+     GSS_S_COMPLETE indicates that the set of security mechanisms
+     available for negotiation has been set to mech_set. GSS_S_FAILURE
+     indicates that the requested operation could not be performed for
+     reasons unspecified at the GSS-API level.
+
+   Allows callers to specify the set of security mechanisms that may be
+   negotiated with the credential identified by cred_handle. This call
+   is intended for support of specialised callers who need to restrict
+   the set of negotiable security mechanisms from the set of all
+   security mechanisms available to the caller (based on available
+   credentials). Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative mechanism preference for the target.
+
+
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 15]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+A.2.  GSS_Get_neg_mechs call
+
+   Input:
+        cred_handle    CREDENTIAL HANDLE
+                       - NULL specifies default credentials
+
+   Outputs:
+        major_status INTEGER,
+        minor_status INTEGER,
+        mech_set     SET OF OBJECT IDENTIFIER
+
+   Return major_status codes :
+        GSS_S_COMPLETE indicates that the set of security mechanisms
+        available for negotiation has been returned in
+        mech_option_set.
+        GSS_S_FAILURE indicates that the requested operation could not
+        be performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of security mechanisms available
+   for negotiation with the credential identified by cred_handle. This
+   call is intended for support of specialised callers who need to
+   reduce the set of negotiable security mechanisms from the set of
+   supported security mechanisms available to the caller (based on
+   available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system. Since this call has no
+   input parameter, the returned set is not necessarily available for
+   all credentials.
+
+REFERENCES
+
+   [1] Linn, J., "Generic Security Service Application Program
+       Interface", RFC 2078, January 1997.
+
+   [2] Standard ECMA-206, "Association Context Management including
+       Security Context Management", December 1993.  Available on
+       http://www.ecma.ch
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 16]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+AUTHORS' ADDRESSES
+
+   Eric Baize
+   Bull - 300 Concord Road
+   Billerica, MA 01821 - USA
+
+   Phone: +1 978 294 61 37
+   Fax: +1 978 294 61 09
+   EMail: Eric.Baize@bull.com
+
+
+   Denis Pinkas
+   Bull
+   Rue Jean-Jaures
+   BP 68
+   78340 Les Clayes-sous-Bois - FRANCE
+
+   Phone: +33 1 30 80 34 87
+   Fax: +33 1 30 80 33 21
+   EMail: Denis.Pinkas@bull.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 17]
+
+RFC 2478             GSS-API Negotiation Mechanism         December 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baize & Pinkas              Standards Track                    [Page 18]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2743.txt b/third_party/heimdal/doc/standardisation/rfc2743.txt
new file mode 100644
index 00000000000..e5da571abb4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2743.txt
@@ -0,0 +1,5659 @@
+
+
+
+
+
+
+Network Working Group                                            J. Linn
+Request for Comments: 2743                              RSA Laboratories
+Obsoletes: 2078                                             January 2000
+Category: Standards Track
+
+
+         Generic Security Service Application Program Interface
+                          Version 2, Update 1
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   The Generic Security Service Application Program Interface (GSS-API),
+   Version 2, as defined in [RFC-2078], provides security services to
+   callers in a generic fashion, supportable with a range of underlying
+   mechanisms and technologies and hence allowing source-level
+   portability of applications to different environments. This
+   specification defines GSS-API services and primitives at a level
+   independent of underlying mechanism and programming language
+   environment, and is to be complemented by other, related
+   specifications:
+
+      documents defining specific parameter bindings for particular
+      language environments
+
+      documents defining token formats, protocols, and procedures to be
+      implemented in order to realize GSS-API services atop particular
+      security mechanisms
+
+   This memo obsoletes [RFC-2078], making specific, incremental changes
+   in response to implementation experience and liaison requests. It is
+   intended, therefore, that this memo or a successor version thereto
+   will become the basis for subsequent progression of the GSS-API
+   specification on the standards track.
+
+
+
+
+
+Linn                        Standards Track                     [Page 1]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+TABLE OF CONTENTS
+
+   1: GSS-API Characteristics and Concepts . . . . . . . . . . . .  4
+   1.1: GSS-API Constructs . . . . . . . . . . . . . . . . . . . .  6
+   1.1.1:  Credentials . . . . . . . . . . . . . . . . . . . . . .  6
+   1.1.1.1: Credential Constructs and Concepts . . . . . . . . . .  6
+   1.1.1.2: Credential Management  . . . . . . . . . . . . . . . .  7
+   1.1.1.3: Default Credential Resolution  . . . . . . . . . . . .  8
+   1.1.2: Tokens . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   1.1.3:  Security Contexts . . . . . . . . . . . . . . . . . . . 11
+   1.1.4:  Mechanism Types . . . . . . . . . . . . . . . . . . . . 12
+   1.1.5:  Naming  . . . . . . . . . . . . . . . . . . . . . . . . 13
+   1.1.6:  Channel Bindings  . . . . . . . . . . . . . . . . . . . 16
+   1.2:  GSS-API Features and Issues . . . . . . . . . . . . . . . 17
+   1.2.1:  Status Reporting  and Optional Service Support  . . . . 17
+   1.2.1.1: Status Reporting . . . . . . . . . . . . . . . . . . . 17
+   1.2.1.2: Optional Service Support . . . . . . . . . . . . . . . 19
+   1.2.2: Per-Message Security Service Availability  . . . . . . . 20
+   1.2.3: Per-Message Replay Detection and Sequencing  . . . . . . 21
+   1.2.4:  Quality of Protection . . . . . . . . . . . . . . . . . 24
+   1.2.5: Anonymity Support  . . . . . . . . . . . . . . . . . . . 25
+   1.2.6: Initialization . . . . . . . . . . . . . . . . . . . . . 25
+   1.2.7: Per-Message Protection During Context Establishment  . . 26
+   1.2.8: Implementation Robustness  . . . . . . . . . . . . . . . 27
+   1.2.9: Delegation . . . . . . . . . . . . . . . . . . . . . . . 28
+   1.2.10: Interprocess Context Transfer . . . . . . . . . . . . . 28
+   2:  Interface Descriptions  . . . . . . . . . . . . . . . . . . 29
+   2.1:  Credential management calls . . . . . . . . . . . . . . . 31
+   2.1.1:  GSS_Acquire_cred call . . . . . . . . . . . . . . . . . 31
+   2.1.2:  GSS_Release_cred call . . . . . . . . . . . . . . . . . 34
+   2.1.3:  GSS_Inquire_cred call . . . . . . . . . . . . . . . . . 35
+   2.1.4:  GSS_Add_cred call . . . . . . . . . . . . . . . . . . . 37
+   2.1.5:  GSS_Inquire_cred_by_mech call . . . . . . . . . . . . . 40
+   2.2:  Context-level calls . . . . . . . . . . . . . . . . . . . 41
+   2.2.1:  GSS_Init_sec_context call . . . . . . . . . . . . . . . 42
+   2.2.2:  GSS_Accept_sec_context call . . . . . . . . . . . . . . 49
+   2.2.3:  GSS_Delete_sec_context call . . . . . . . . . . . . . . 53
+   2.2.4:  GSS_Process_context_token call  . . . . . . . . . . . . 54
+   2.2.5:  GSS_Context_time call . . . . . . . . . . . . . . . . . 55
+   2.2.6:  GSS_Inquire_context call  . . . . . . . . . . . . . . . 56
+   2.2.7:  GSS_Wrap_size_limit call  . . . . . . . . . . . . . . . 57
+   2.2.8:  GSS_Export_sec_context call . . . . . . . . . . . . . . 59
+   2.2.9:  GSS_Import_sec_context call . . . . . . . . . . . . . . 61
+   2.3:  Per-message calls . . . . . . . . . . . . . . . . . . . . 62
+   2.3.1:  GSS_GetMIC call . . . . . . . . . . . . . . . . . . . . 63
+   2.3.2:  GSS_VerifyMIC call  . . . . . . . . . . . . . . . . . . 64
+   2.3.3:  GSS_Wrap call . . . . . . . . . . . . . . . . . . . . . 65
+   2.3.4:  GSS_Unwrap call . . . . . . . . . . . . . . . . . . . . 66
+
+
+
+Linn                        Standards Track                     [Page 2]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   2.4:  Support calls . . . . . . . . . . . . . . . . . . . . . . 68
+   2.4.1:  GSS_Display_status call . . . . . . . . . . . . . . . . 68
+   2.4.2:  GSS_Indicate_mechs call . . . . . . . . . . . . . . . . 69
+   2.4.3:  GSS_Compare_name call . . . . . . . . . . . . . . . . . 70
+   2.4.4:  GSS_Display_name call . . . . . . . . . . . . . . . . . 71
+   2.4.5:  GSS_Import_name call  . . . . . . . . . . . . . . . . . 72
+   2.4.6:  GSS_Release_name call . . . . . . . . . . . . . . . . . 73
+   2.4.7:  GSS_Release_buffer call . . . . . . . . . . . . . . . . 74
+   2.4.8:  GSS_Release_OID_set call  . . . . . . . . . . . . . . . 74
+   2.4.9:  GSS_Create_empty_OID_set call . . . . . . . . . . . . . 75
+   2.4.10: GSS_Add_OID_set_member call . . . . . . . . . . . . . . 76
+   2.4.11: GSS_Test_OID_set_member call  . . . . . . . . . . . . . 76
+   2.4.12: GSS_Inquire_names_for_mech call . . . . . . . . . . . . 77
+   2.4.13: GSS_Inquire_mechs_for_name call . . . . . . . . . . . . 77
+   2.4.14: GSS_Canonicalize_name call  . . . . . . . . . . . . . . 78
+   2.4.15: GSS_Export_name call  . . . . . . . . . . . . . . . . . 79
+   2.4.16: GSS_Duplicate_name call . . . . . . . . . . . . . . . . 80
+   3: Data Structure Definitions for GSS-V2 Usage  . . . . . . . . 81
+   3.1: Mechanism-Independent Token Format . . . . . . . . . . . . 81
+   3.2: Mechanism-Independent Exported Name Object Format  . . . . 84
+   4: Name Type Definitions  . . . . . . . . . . . . . . . . . . . 85
+   4.1: Host-Based Service Name Form . . . . . . . . . . . . . . . 85
+   4.2: User Name Form . . . . . . . . . . . . . . . . . . . . . . 86
+   4.3: Machine UID Form . . . . . . . . . . . . . . . . . . . . . 87
+   4.4: String UID Form  . . . . . . . . . . . . . . . . . . . . . 87
+   4.5: Anonymous Nametype . . . . . . . . . . . . . . . . . . . . 87
+   4.6: GSS_C_NO_OID . . . . . . . . . . . . . . . . . . . . . . . 88
+   4.7: Exported Name Object . . . . . . . . . . . . . . . . . . . 88
+   4.8: GSS_C_NO_NAME  . . . . . . . . . . . . . . . . . . . . . . 88
+   5:  Mechanism-Specific Example Scenarios  . . . . . . . . . . . 88
+   5.1: Kerberos V5, single-TGT  . . . . . . . . . . . . . . . . . 89
+   5.2: Kerberos V5, double-TGT  . . . . . . . . . . . . . . . . . 89
+   5.3:  X.509 Authentication Framework  . . . . . . . . . . . . . 90
+   6:  Security Considerations . . . . . . . . . . . . . . . . . . 91
+   7:  Related Activities  . . . . . . . . . . . . . . . . . . . . 92
+   8:  Referenced Documents  . . . . . . . . . . . . . . . . . . . 93
+   Appendix A: Mechanism Design Constraints  . . . . . . . . . . . 94
+   Appendix B: Compatibility with GSS-V1 . . . . . . . . . . . . . 94
+   Appendix C: Changes Relative to RFC-2078  . . . . . . . . . . . 96
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . .100
+   Full Copyright Statement  . . . . . . . . . . . . . . . . . . .101
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                     [Page 3]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+1: GSS-API Characteristics and Concepts
+
+   GSS-API operates in the following paradigm.  A typical GSS-API caller
+   is itself a communications protocol, calling on GSS-API in order to
+   protect its communications with authentication, integrity, and/or
+   confidentiality security services.  A GSS-API caller accepts tokens
+   provided to it by its local GSS-API implementation and transfers the
+   tokens to a peer on a remote system; that peer passes the received
+   tokens to its local GSS-API implementation for processing. The
+   security services available through GSS-API in this fashion are
+   implementable (and have been implemented) over a range of underlying
+   mechanisms based on secret-key and public-key cryptographic
+   technologies.
+
+   The GSS-API separates the operations of initializing a security
+   context between peers, achieving peer entity authentication
+   (GSS_Init_sec_context() and GSS_Accept_sec_context() calls), from the
+   operations of providing per-message data origin authentication and
+   data integrity protection (GSS_GetMIC() and GSS_VerifyMIC() calls)
+   for messages subsequently transferred in conjunction with that
+   context.  (The definition for the peer entity authentication service,
+   and other definitions used in this document, corresponds to that
+   provided in [ISO-7498-2].) When establishing a security context, the
+   GSS-API enables a context initiator to optionally permit its
+   credentials to be delegated, meaning that the context acceptor may
+   initiate further security contexts on behalf of the initiating
+   caller. Per-message GSS_Wrap() and GSS_Unwrap() calls provide the
+   data origin authentication and data integrity services which
+   GSS_GetMIC() and GSS_VerifyMIC() offer, and also support selection of
+   confidentiality services as a caller option. Additional calls provide
+   supportive functions to the GSS-API's users.
+
+   The following paragraphs provide an example illustrating the
+   dataflows involved in use of the GSS-API by a client and server in a
+   mechanism-independent fashion, establishing a security context and
+   transferring a protected message. The example assumes that credential
+   acquisition has already been completed.  The example also assumes
+   that the underlying authentication technology is capable of
+   authenticating a client to a server using elements carried within a
+   single token, and of authenticating the server to the client (mutual
+   authentication) with a single returned token; this assumption holds
+   for some presently-documented CAT mechanisms but is not necessarily
+   true for other cryptographic technologies and associated protocols.
+
+   The client calls GSS_Init_sec_context() to establish a security
+   context to the server identified by targ_name, and elects to set the
+   mutual_req_flag so that mutual authentication is performed in the
+   course of context establishment. GSS_Init_sec_context() returns an
+
+
+
+Linn                        Standards Track                     [Page 4]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   output_token to be passed to the server, and indicates
+   GSS_S_CONTINUE_NEEDED status pending completion of the mutual
+   authentication sequence. Had mutual_req_flag not been set, the
+   initial call to GSS_Init_sec_context() would have returned
+   GSS_S_COMPLETE status. The client sends the output_token to the
+   server.
+
+   The server passes the received token as the input_token parameter to
+   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
+   GSS_S_COMPLETE status, provides the client's authenticated identity
+   in the src_name result, and provides an output_token to be passed to
+   the client. The server sends the output_token to the client.
+
+   The client passes the received token as the input_token parameter to
+   a successor call to GSS_Init_sec_context(), which processes data
+   included in the token in order to achieve mutual authentication from
+   the client's viewpoint. This call to GSS_Init_sec_context() returns
+   GSS_S_COMPLETE status, indicating successful mutual authentication
+   and the completion of context establishment for this example.
+
+   The client generates a data message and passes it to GSS_Wrap().
+   GSS_Wrap() performs data origin authentication, data integrity, and
+   (optionally) confidentiality processing on the message and
+   encapsulates the result into output_message, indicating
+   GSS_S_COMPLETE status. The client sends the output_message to the
+   server.
+
+   The server passes the received message to GSS_Unwrap().  GSS_Unwrap()
+   inverts the encapsulation performed by GSS_Wrap(), deciphers the
+   message if the optional confidentiality feature was applied, and
+   validates the data origin authentication and data integrity checking
+   quantities. GSS_Unwrap() indicates successful validation by returning
+   GSS_S_COMPLETE status along with the resultant output_message.
+
+   For purposes of this example, we assume that the server knows by
+   out-of-band means that this context will have no further use after
+   one protected message is transferred from client to server. Given
+   this premise, the server now calls GSS_Delete_sec_context() to flush
+   context-level information.  Optionally, the server-side application
+   may provide a token buffer to GSS_Delete_sec_context(), to receive a
+   context_token to be transferred to the client in order to request
+   that client-side context-level information be deleted.
+
+   If a context_token is transferred, the client passes the
+   context_token to GSS_Process_context_token(), which returns
+   GSS_S_COMPLETE status after deleting context-level information at the
+   client system.
+
+
+
+
+Linn                        Standards Track                     [Page 5]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   The GSS-API design assumes and addresses several basic goals,
+   including:
+
+      Mechanism independence: The GSS-API defines an interface to
+      cryptographically implemented strong authentication and other
+      security services at a generic level which is independent of
+      particular underlying mechanisms. For example, GSS-API-provided
+      services have been implemented using secret-key technologies
+      (e.g., Kerberos, per [RFC-1964]) and with public-key approaches
+      (e.g., SPKM, per [RFC-2025]).
+
+      Protocol environment independence: The GSS-API is independent of
+      the communications protocol suites with which it is employed,
+      permitting use in a broad range of protocol environments. In
+      appropriate environments, an intermediate implementation "veneer"
+      which is oriented to a particular communication protocol may be
+      interposed between applications which call that protocol and the
+      GSS-API (e.g., as defined in [RFC-2203] for Open Network Computing
+      Remote Procedure Call (RPC)), thereby invoking GSS-API facilities
+      in conjunction with that protocol's communications invocations.
+
+      Protocol association independence: The GSS-API's security context
+      construct is independent of communications protocol association
+      constructs. This characteristic allows a single GSS-API
+      implementation to be utilized by a variety of invoking protocol
+      modules on behalf of those modules' calling applications. GSS-API
+      services can also be invoked directly by applications, wholly
+      independent of protocol associations.
+
+      Suitability to a range of implementation placements: GSS-API
+      clients are not constrained to reside within any Trusted Computing
+      Base (TCB) perimeter defined on a system where the GSS-API is
+      implemented; security services are specified in a manner suitable
+      to both intra-TCB and extra-TCB callers.
+
+1.1: GSS-API Constructs
+
+   This section describes the basic elements comprising the GSS-API.
+
+1.1.1:  Credentials
+
+1.1.1.1: Credential Constructs and Concepts
+
+   Credentials provide the prerequisites which permit GSS-API peers to
+   establish security contexts with each other. A caller may designate
+   that the credential elements which are to be applied for context
+   initiation or acceptance be selected by default.  Alternately, those
+   GSS-API callers which need to make explicit selection of particular
+
+
+
+Linn                        Standards Track                     [Page 6]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   credentials structures may make references to those credentials
+   through GSS-API-provided credential handles ("cred_handles").  In all
+   cases, callers' credential references are indirect, mediated by GSS-
+   API implementations and not requiring callers to access the selected
+   credential elements.
+
+   A single credential structure may be used to initiate outbound
+   contexts and to accept inbound contexts. Callers needing to operate
+   in only one of these modes may designate this fact when credentials
+   are acquired for use, allowing underlying mechanisms to optimize
+   their processing and storage requirements. The credential elements
+   defined by a particular mechanism may contain multiple cryptographic
+   keys, e.g., to enable authentication and message encryption to be
+   performed with different algorithms.
+
+   A GSS-API credential structure may contain multiple credential
+   elements, each containing mechanism-specific information for a
+   particular underlying mechanism (mech_type), but the set of elements
+   within a given credential structure represent a common entity.  A
+   credential structure's contents will vary depending on the set of
+   mech_types supported by a particular GSS-API implementation. Each
+   credential element identifies the data needed by its mechanism in
+   order to establish contexts on behalf of a particular principal, and
+   may contain separate credential references for use in context
+   initiation and context acceptance.  Multiple credential elements
+   within a given credential having overlapping combinations of
+   mechanism, usage mode, and validity period are not permitted.
+
+   Commonly, a single mech_type will be used for all security contexts
+   established by a particular initiator to a particular target. A major
+   motivation for supporting credential sets representing multiple
+   mech_types is to allow initiators on systems which are equipped to
+   handle multiple types to initiate contexts to targets on other
+   systems which can accommodate only a subset of the set supported at
+   the initiator's system.
+
+1.1.1.2: Credential Management
+
+   It is the responsibility of underlying system-specific mechanisms and
+   OS functions below the GSS-API to ensure that the ability to acquire
+   and use credentials associated with a given identity is constrained
+   to appropriate processes within a system. This responsibility should
+   be taken seriously by implementors, as the ability for an entity to
+   utilize a principal's credentials is equivalent to the entity's
+   ability to successfully assert that principal's identity.
+
+
+
+
+
+
+Linn                        Standards Track                     [Page 7]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Once a set of GSS-API credentials is established, the transferability
+   of that credentials set to other processes or analogous constructs
+   within a system is a local matter, not defined by the GSS-API. An
+   example local policy would be one in which any credentials received
+   as a result of login to a given user account, or of delegation of
+   rights to that account, are accessible by, or transferable to,
+   processes running under that account.
+
+   The credential establishment process (particularly when performed on
+   behalf of users rather than server processes) is likely to require
+   access to passwords or other quantities which should be protected
+   locally and exposed for the shortest time possible. As a result, it
+   will often be appropriate for preliminary credential establishment to
+   be performed through local means at user login time, with the
+   result(s) cached for subsequent reference. These preliminary
+   credentials would be set aside (in a system-specific fashion) for
+   subsequent use, either:
+
+      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
+      call, returning an explicit handle to reference that credential
+
+      to comprise default credential elements to be installed, and to be
+      used when default credential behavior is requested on behalf of a
+      process
+
+1.1.1.3: Default Credential Resolution
+
+   The GSS_Init_sec_context() and GSS_Accept_sec_context() routines
+   allow the value GSS_C_NO_CREDENTIAL to be specified as their
+   credential handle parameter.  This special credential handle
+   indicates a desire by the application to act as a default principal.
+   In support of application portability, support for the default
+   resolution behavior described below for initiator credentials
+   (GSS_Init_sec_context() usage) is mandated; support for the default
+   resolution behavior described below for acceptor credentials
+   (GSS_Accept_sec_context() usage) is recommended. If default
+   credential resolution fails, GSS_S_NO_CRED status is to be returned.
+
+      GSS_Init_sec_context:
+
+         (i) If there is only a single principal capable of initiating
+         security contexts that the application is authorized to act on
+         behalf of, then that principal shall be used, otherwise
+
+
+
+
+
+
+
+
+Linn                        Standards Track                     [Page 8]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+         (ii) If the platform maintains a concept of a default network-
+         identity, and if the application is authorized to act on behalf
+         of that identity for the purpose of initiating security
+         contexts, then the principal corresponding to that identity
+         shall be used, otherwise
+
+         (iii) If the platform maintains a concept of a default local
+         identity, and provides a means to map local identities into
+         network-identities, and if the application is authorized to act
+         on behalf of the network-identity image of the default local
+         identity for the purpose of initiating security contexts, then
+         the principal corresponding to that identity shall be used,
+         otherwise
+
+         (iv) A user-configurable default identity should be used.
+
+      GSS_Accept_sec_context:
+
+         (i) If there is only a single authorized principal identity
+         capable of accepting security contexts, then that principal
+         shall be used, otherwise
+
+         (ii) If the mechanism can determine the identity of the target
+         principal by examining the context-establishment token, and if
+         the accepting application is authorized to act as that
+         principal for the purpose of accepting security contexts, then
+         that principal identity shall be used, otherwise
+
+         (iii) If the mechanism supports context acceptance by any
+         principal, and mutual authentication was not requested, any
+         principal that the application is authorized to accept security
+         contexts under may be used, otherwise
+
+         (iv) A user-configurable default identity shall be used.
+
+   The purpose of the above rules is to allow security contexts to be
+   established by both initiator and acceptor using the default behavior
+   wherever possible.  Applications requesting default behavior are
+   likely to be more portable across mechanisms and platforms than those
+   that use GSS_Acquire_cred() to request a specific identity.
+
+1.1.2: Tokens
+
+   Tokens are data elements transferred between GSS-API callers, and are
+   divided into two classes. Context-level tokens are exchanged in order
+   to establish and manage a security context between peers. Per-message
+   tokens relate to an established context and are exchanged to provide
+
+
+
+
+Linn                        Standards Track                     [Page 9]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   protective security services (i.e., data origin authentication,
+   integrity, and optional confidentiality) for corresponding data
+   messages.
+
+   The first context-level token obtained from GSS_Init_sec_context() is
+   required to indicate at its very beginning a globally-interpretable
+   mechanism identifier, i.e., an Object Identifier (OID) of the
+   security mechanism. The remaining part of this token as well as the
+   whole content of all other tokens are specific to the particular
+   underlying mechanism used to support the GSS-API. Section 3.1 of this
+   document provides, for designers of GSS-API mechanisms, the
+   description of the header of the first context-level token which is
+   then followed by mechanism-specific information.
+
+   Tokens' contents are opaque from the viewpoint of GSS-API callers.
+   They are generated within the GSS-API implementation at an end
+   system, provided to a GSS-API caller to be transferred to the peer
+   GSS-API caller at a remote end system, and processed by the GSS-API
+   implementation at that remote end system.
+
+   Context-level tokens may be output by GSS-API calls (and should be
+   transferred to GSS-API peers) whether or not the calls' status
+   indicators indicate successful completion.  Per-message tokens, in
+   contrast, are to be returned only upon successful completion of per-
+   message calls. Zero-length tokens are never returned by GSS routines
+   for transfer to a peer. Token transfer may take place in an in-band
+   manner, integrated into the same protocol stream used by the GSS-API
+   callers for other data transfers, or in an out-of-band manner across
+   a logically separate channel.
+
+   Different GSS-API tokens are used for different purposes (e.g.,
+   context initiation, context acceptance, protected message data on an
+   established context), and it is the responsibility of a GSS-API
+   caller receiving tokens to distinguish their types, associate them
+   with corresponding security contexts, and pass them to appropriate
+   GSS-API processing routines.  Depending on the caller protocol
+   environment, this distinction may be accomplished in several ways.
+
+   The following examples illustrate means through which tokens' types
+   may be distinguished:
+
+      - implicit tagging based on state information (e.g., all tokens on
+      a new association are considered to be context establishment
+      tokens until context establishment is completed, at which point
+      all tokens are considered to be wrapped data objects for that
+      context),
+
+
+
+
+
+Linn                        Standards Track                    [Page 10]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      - explicit tagging at the caller protocol level,
+
+      - a hybrid of these approaches.
+
+   Commonly, the encapsulated data within a token includes internal
+   mechanism-specific tagging information, enabling mechanism-level
+   processing modules to distinguish tokens used within the mechanism
+   for different purposes.  Such internal mechanism-level tagging is
+   recommended to mechanism designers, and enables mechanisms to
+   determine whether a caller has passed a particular token for
+   processing by an inappropriate GSS-API routine.
+
+   Development of GSS-API mechanisms based on a particular underlying
+   cryptographic technique and protocol (i.e., conformant to a specific
+   GSS-API mechanism definition) does not necessarily imply that GSS-API
+   callers using that GSS-API mechanism will be able to interoperate
+   with peers invoking the same technique and protocol outside the GSS-
+   API paradigm, or with peers implementing a different GSS-API
+   mechanism based on the same underlying technology.  The format of
+   GSS-API tokens defined in conjunction with a particular mechanism,
+   and the techniques used to integrate those tokens into callers'
+   protocols, may not be interoperable with the tokens used by non-GSS-
+   API callers of the same underlying technique.
+
+1.1.3:  Security Contexts
+
+   Security contexts are established between peers, using credentials
+   established locally in conjunction with each peer or received by
+   peers via delegation. Multiple contexts may exist simultaneously
+   between a pair of peers, using the same or different sets of
+   credentials. Coexistence of multiple contexts using different
+   credentials allows graceful rollover when credentials expire.
+   Distinction among multiple contexts based on the same credentials
+   serves applications by distinguishing different message streams in a
+   security sense.
+
+   The GSS-API is independent of underlying protocols and addressing
+   structure, and depends on its callers to transport GSS-API-provided
+   data elements. As a result of these factors, it is a caller
+   responsibility to parse communicated messages, separating GSS-API-
+   related data elements from caller-provided data.  The GSS-API is
+   independent of connection vs. connectionless orientation of the
+   underlying communications service.
+
+   No correlation between security context and communications protocol
+   association is dictated. (The optional channel binding facility,
+   discussed in Section 1.1.6 of this document, represents an
+   intentional exception to this rule, supporting additional protection
+
+
+
+Linn                        Standards Track                    [Page 11]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   features within GSS-API supporting mechanisms.) This separation
+   allows the GSS-API to be used in a wide range of communications
+   environments, and also simplifies the calling sequences of the
+   individual calls. In many cases (depending on underlying security
+   protocol, associated mechanism, and availability of cached
+   information), the state information required for context setup can be
+   sent concurrently with initial signed user data, without interposing
+   additional message exchanges.  Messages may be protected and
+   transferred in both directions on an established GSS-API security
+   context concurrently; protection of messages in one direction does
+   not interfere with protection of messages in the reverse direction.
+
+   GSS-API implementations are expected to retain inquirable context
+   data on a context until the context is released by a caller, even
+   after the context has expired, although underlying cryptographic data
+   elements may be deleted after expiration in order to limit their
+   exposure.
+
+1.1.4:  Mechanism Types
+
+   In order to successfully establish a security context with a target
+   peer, it is necessary to identify an appropriate underlying mechanism
+   type (mech_type) which both initiator and target peers support. The
+   definition of a mechanism embodies not only the use of a particular
+   cryptographic technology (or a hybrid or choice among alternative
+   cryptographic technologies), but also definition of the syntax and
+   semantics of data element exchanges which that mechanism will employ
+   in order to support security services.
+
+   It is recommended that callers initiating contexts specify the
+   "default" mech_type value, allowing system-specific functions within
+   or invoked by the GSS-API implementation to select the appropriate
+   mech_type, but callers may direct that a particular mech_type be
+   employed when necessary.
+
+   For GSS-API purposes, the phrase "negotiating mechanism" refers to a
+   mechanism which itself performs negotiation in order to select a
+   concrete mechanism which is shared between peers and is then used for
+   context establishment.  Only those mechanisms which are defined in
+   their specifications as negotiating mechanisms are to yield selected
+   mechanisms with different identifier values than the value which is
+   input by a GSS-API caller, except for the case of a caller requesting
+   the "default" mech_type.
+
+   The means for identifying a shared mech_type to establish a security
+   context with a peer will vary in different environments and
+   circumstances; examples include (but are not limited to):
+
+
+
+
+Linn                        Standards Track                    [Page 12]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      use of a fixed mech_type, defined by configuration, within an
+      environment
+
+      syntactic convention on a target-specific basis, through
+      examination of a target's name lookup of a target's name in a
+      naming service or other database in order to identify mech_types
+      supported by that target
+
+      explicit negotiation between GSS-API callers in advance of
+      security context setup
+
+      use of a negotiating mechanism
+
+   When transferred between GSS-API peers, mech_type specifiers (per
+   Section 3 of this document, represented as Object Identifiers (OIDs))
+   serve to qualify the interpretation of associated tokens. (The
+   structure and encoding of Object Identifiers is defined in [ISOIEC-
+   8824] and [ISOIEC-8825].) Use of hierarchically structured OIDs
+   serves to preclude ambiguous interpretation of mech_type specifiers.
+   The OID representing the DASS ([RFC-1507]) MechType, for example, is
+   1.3.12.2.1011.7.5, and that of the Kerberos V5 mechanism ([RFC-
+   1964]), having been advanced to the level of Proposed Standard, is
+   1.2.840.113554.1.2.2.
+
+1.1.5:  Naming
+
+   The GSS-API avoids prescribing naming structures, treating the names
+   which are transferred across the interface in order to initiate and
+   accept security contexts as opaque objects.  This approach supports
+   the GSS-API's goal of implementability atop a range of underlying
+   security mechanisms, recognizing the fact that different mechanisms
+   process and authenticate names which are presented in different
+   forms. Generalized services offering translation functions among
+   arbitrary sets of naming environments are outside the scope of the
+   GSS-API; availability and use of local conversion functions to
+   translate among the naming formats supported within a given end
+   system is anticipated.
+
+   Different classes of name representations are used in conjunction
+   with different GSS-API parameters:
+
+      - Internal form (denoted in this document by INTERNAL NAME),
+      opaque to callers and defined by individual GSS-API
+      implementations.  GSS-API implementations supporting multiple
+      namespace types must maintain internal tags to disambiguate the
+      interpretation of particular names.  A Mechanism Name (MN) is a
+      special case of INTERNAL NAME, guaranteed to contain elements
+
+
+
+
+Linn                        Standards Track                    [Page 13]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      corresponding to one and only one mechanism; calls which are
+      guaranteed to emit MNs or which require MNs as input are so
+      identified within this specification.
+
+      - Contiguous string ("flat") form (denoted in this document by
+      OCTET STRING); accompanied by OID tags identifying the namespace
+      to which they correspond.  Depending on tag value, flat names may
+      or may not be printable strings for direct acceptance from and
+      presentation to users. Tagging of flat names allows GSS-API
+      callers and underlying GSS-API mechanisms to disambiguate name
+      types and to determine whether an associated name's type is one
+      which they are capable of processing, avoiding aliasing problems
+      which could result from misinterpreting a name of one type as a
+      name of another type.
+
+      - The GSS-API Exported Name Object, a special case of flat name
+      designated by a reserved OID value, carries a canonicalized form
+      of a name suitable for binary comparisons.
+
+   In addition to providing means for names to be tagged with types,
+   this specification defines primitives to support a level of naming
+   environment independence for certain calling applications. To provide
+   basic services oriented towards the requirements of callers which
+   need not themselves interpret the internal syntax and semantics of
+   names, GSS-API calls for name comparison (GSS_Compare_name()),
+   human-readable display (GSS_Display_name()), input conversion
+   (GSS_Import_name()), internal name deallocation (GSS_Release_name()),
+   and internal name duplication (GSS_Duplicate_name()) functions are
+   defined. (It is anticipated that these proposed GSS-API calls will be
+   implemented in many end systems based on system-specific name
+   manipulation primitives already extant within those end systems;
+   inclusion within the GSS-API is intended to offer GSS-API callers a
+   portable means to perform specific operations, supportive of
+   authorization and audit requirements, on authenticated names.)
+
+   GSS_Import_name() implementations can, where appropriate, support
+   more than one printable syntax corresponding to a given namespace
+   (e.g., alternative printable representations for X.500 Distinguished
+   Names), allowing flexibility for their callers to select among
+   alternative representations. GSS_Display_name() implementations
+   output a printable syntax selected as appropriate to their
+   operational environments; this selection is a local matter. Callers
+   desiring portability across alternative printable syntaxes should
+   refrain from implementing comparisons based on printable name forms
+   and should instead use the GSS_Compare_name()  call to determine
+   whether or not one internal-format name matches another.
+
+
+
+
+
+Linn                        Standards Track                    [Page 14]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   When used in large access control lists, the overhead of invoking
+   GSS_Import_name() and GSS_Compare_name() on each name from the ACL
+   may be prohibitive.  As an alternative way of supporting this case,
+   GSS-API defines a special form of the contiguous string name which
+   may be compared directly (e.g., with memcmp()).  Contiguous names
+   suitable for comparison are generated by the GSS_Export_name()
+   routine, which requires an MN as input.  Exported names may be re-
+   imported by the GSS_Import_name() routine, and the resulting internal
+   name will also be an MN.  The symbolic constant GSS_C_NT_EXPORT_NAME
+   identifies the "export name" type. Structurally, an exported name
+   object consists of a header containing an OID identifying the
+   mechanism that authenticated the name, and a trailer containing the
+   name itself, where the syntax of the trailer is defined by the
+   individual mechanism specification.  The precise format of an
+   exported name is defined in Section 3.2 of this specification.
+
+   Note that the results obtained by using GSS_Compare_name() will in
+   general be different from those obtained by invoking
+   GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the
+   exported names.  The first series of operations determines whether
+   two (unauthenticated) names identify the same principal; the second
+   whether a particular mechanism would authenticate them as the same
+   principal.  These two operations will in general give the same
+   results only for MNs.
+
+   The following diagram illustrates the intended dataflow among name-
+   related GSS-API processing routines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 15]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+                        GSS-API library defaults
+                               |
+                               |
+                               V                         text, for
+   text -------------->  internal_name (IN) -----------> display only
+         import_name()          /          display_name()
+                               /
+                              /
+                             /
+    accept_sec_context()    /
+          |                /
+          |               /
+          |              /  canonicalize_name()
+          |             /
+          |            /
+          |           /
+          |          /
+          |         /
+          |        |
+          V        V     <---------------------
+    single mechanism        import_name()         exported name: flat
+    internal_name (MN)                            binary "blob" usable
+                         ---------------------->  for access control
+                            export_name()
+
+1.1.6:  Channel Bindings
+
+   The GSS-API accommodates the concept of caller-provided channel
+   binding ("chan_binding") information.  Channel bindings are used to
+   strengthen the quality with which peer entity authentication is
+   provided during context establishment, by limiting the scope within
+   which an intercepted context establishment token can be reused by an
+   attacker. Specifically, they enable GSS-API callers to bind the
+   establishment of a security context to relevant characteristics
+   (e.g., addresses, transformed representations of encryption keys) of
+   the underlying communications channel, of protection mechanisms
+   applied to that communications channel, and to application-specific
+   data.
+
+   The caller initiating a security context must determine the
+   appropriate channel binding values to provide as input to the
+   GSS_Init_sec_context() call, and consistent values must be provided
+   to GSS_Accept_sec_context() by the context's target, in order for
+   both peers' GSS-API mechanisms to validate that received tokens
+   possess correct channel-related characteristics. Use or non-use of
+   the GSS-API channel binding facility is a caller option.  GSS-API
+   mechanisms can operate in an environment where NULL channel bindings
+   are presented; mechanism implementors are encouraged, but not
+
+
+
+Linn                        Standards Track                    [Page 16]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   required, to make use of caller-provided channel binding data within
+   their mechanisms. Callers should not assume that underlying
+   mechanisms provide confidentiality protection for channel binding
+   information.
+
+   When non-NULL channel bindings are provided by callers, certain
+   mechanisms can offer enhanced security value by interpreting the
+   bindings' content (rather than simply representing those bindings, or
+   integrity check values computed on them, within tokens) and will
+   therefore depend on presentation of specific data in a defined
+   format. To this end, agreements among mechanism implementors are
+   defining conventional interpretations for the contents of channel
+   binding arguments, including address specifiers (with content
+   dependent on communications protocol environment) for context
+   initiators and acceptors. (These conventions are being incorporated
+   in GSS-API mechanism specifications and into the GSS-API C language
+   bindings specification.) In order for GSS-API callers to be portable
+   across multiple mechanisms and achieve the full security
+   functionality which each mechanism can provide, it is strongly
+   recommended that GSS-API callers provide channel bindings consistent
+   with these conventions and those of the networking environment in
+   which they operate.
+
+1.2:  GSS-API Features and Issues
+
+   This section describes aspects of GSS-API operations, of the security
+   services which the GSS-API provides, and provides commentary on
+   design issues.
+
+1.2.1:  Status Reporting and Optional Service Support
+
+1.2.1.1: Status Reporting
+
+   Each GSS-API call provides two status return values. Major_status
+   values provide a mechanism-independent indication of call status
+   (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED),
+   sufficient to drive normal control flow within the caller in a
+   generic fashion. Table 1 summarizes the defined major_status return
+   codes in tabular fashion.
+
+   Sequencing-related informatory major_status codes
+   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and
+   GSS_S_GAP_TOKEN) can be indicated in conjunction with either
+   GSS_S_COMPLETE or GSS_S_FAILURE status for GSS-API per-message calls.
+   For context establishment calls, these sequencing-related codes will
+   be indicated only in conjunction with GSS_S_FAILURE status (never in
+
+
+
+
+
+Linn                        Standards Track                    [Page 17]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   conjunction with GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and,
+   therefore, always correspond to fatal failures if encountered during
+   the context establishment phase.
+
+   Table 1: GSS-API Major Status Codes
+
+   FATAL ERROR CODES
+
+   GSS_S_BAD_BINDINGS            channel binding mismatch
+   GSS_S_BAD_MECH                unsupported mechanism requested
+   GSS_S_BAD_NAME                invalid name provided
+   GSS_S_BAD_NAMETYPE            name of unsupported type provided
+   GSS_S_BAD_STATUS              invalid input status selector
+   GSS_S_BAD_SIG                 token had invalid integrity check
+   GSS_S_BAD_MIC                   preferred alias for GSS_S_BAD_SIG
+   GSS_S_CONTEXT_EXPIRED         specified security context expired
+   GSS_S_CREDENTIALS_EXPIRED     expired credentials detected
+   GSS_S_DEFECTIVE_CREDENTIAL    defective credential detected
+   GSS_S_DEFECTIVE_TOKEN         defective token detected
+   GSS_S_FAILURE                 failure, unspecified at GSS-API
+                                   level
+   GSS_S_NO_CONTEXT              no valid security context specified
+   GSS_S_NO_CRED                 no valid credentials provided
+   GSS_S_BAD_QOP                 unsupported QOP value
+   GSS_S_UNAUTHORIZED            operation unauthorized
+   GSS_S_UNAVAILABLE             operation unavailable
+   GSS_S_DUPLICATE_ELEMENT       duplicate credential element requested
+   GSS_S_NAME_NOT_MN             name contains multi-mechanism elements
+
+   INFORMATORY STATUS CODES
+
+   GSS_S_COMPLETE                normal completion
+   GSS_S_CONTINUE_NEEDED         continuation call to routine
+                                  required
+   GSS_S_DUPLICATE_TOKEN         duplicate per-message token
+                                  detected
+   GSS_S_OLD_TOKEN               timed-out per-message token
+                                  detected
+   GSS_S_UNSEQ_TOKEN             reordered (early) per-message token
+                                  detected
+   GSS_S_GAP_TOKEN               skipped predecessor token(s)
+                                  detected
+
+   Minor_status provides more detailed status information which may
+   include status codes specific to the underlying security mechanism.
+   Minor_status values are not specified in this document.
+
+
+
+
+
+Linn                        Standards Track                    [Page 18]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   GSS_S_CONTINUE_NEEDED major_status returns, and optional message
+   outputs, are provided in GSS_Init_sec_context() and
+   GSS_Accept_sec_context() calls so that different mechanisms'
+   employment of different numbers of messages within their
+   authentication sequences need not be reflected in separate code paths
+   within calling applications. Instead, such cases are accommodated
+   with sequences of continuation calls to GSS_Init_sec_context()  and
+   GSS_Accept_sec_context().  The same facility is used to encapsulate
+   mutual authentication within the GSS-API's context initiation calls.
+
+   For mech_types which require interactions with third-party servers in
+   order to establish a security context, GSS-API context establishment
+   calls may block pending completion of such third-party interactions.
+   On the other hand, no GSS-API calls pend on serialized interactions
+   with GSS-API peer entities.  As a result, local GSS-API status
+   returns cannot reflect unpredictable or asynchronous exceptions
+   occurring at remote peers, and reflection of such status information
+   is a caller responsibility outside the GSS-API.
+
+1.2.1.2: Optional Service Support
+
+   A context initiator may request various optional services at context
+   establishment time. Each of these services is requested by setting a
+   flag in the req_flags input parameter to GSS_Init_sec_context().
+
+   The optional services currently defined are:
+
+      - Delegation - The (usually temporary) transfer of rights from
+      initiator to acceptor, enabling the acceptor to authenticate
+      itself as an agent of the initiator.
+
+      - Mutual Authentication - In addition to the initiator
+      authenticating its identity to the context acceptor, the context
+      acceptor should also authenticate itself to the initiator.
+
+      - Replay detection - In addition to providing message integrity
+      services, GSS_GetMIC() and GSS_Wrap() should include message
+      numbering information to enable GSS_VerifyMIC() and GSS_Unwrap()
+      to detect if a message has been duplicated.
+
+      - Out-of-sequence detection - In addition to providing message
+      integrity services, GSS_GetMIC() and GSS_Wrap() should include
+      message sequencing information to enable GSS_VerifyMIC() and
+      GSS_Unwrap() to detect if a message has been received out of
+      sequence.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 19]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      - Anonymous authentication - The establishment of the security
+      context should not reveal the initiator's identity to the context
+      acceptor.
+
+      - Available per-message confidentiality - requests that per-
+      message confidentiality services be available on the context.
+
+      - Available per-message integrity - requests that per-message
+      integrity services be available on the context.
+
+   Any currently undefined bits within such flag arguments should be
+   ignored by GSS-API implementations when presented by an application,
+   and should be set to zero when returned to the application by the
+   GSS-API implementation.
+
+   Some mechanisms may not support all optional services, and some
+   mechanisms may only support some services in conjunction with others.
+   Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the
+   applications which services will be available from the context when
+   the establishment phase is complete, via the ret_flags output
+   parameter.  In general, if the security mechanism is capable of
+   providing a requested service, it should do so, even if additional
+   services must be enabled in order to provide the requested service.
+   If the mechanism is incapable of providing a requested service, it
+   should proceed without the service, leaving the application to abort
+   the context establishment process if it considers the requested
+   service to be mandatory.
+
+   Some mechanisms may specify that support for some services is
+   optional, and that implementors of the mechanism need not provide it.
+   This is most commonly true of the confidentiality service, often
+   because of legal restrictions on the use of data-encryption, but may
+   apply to any of the services.  Such mechanisms are required to send
+   at least one token from acceptor to initiator during context
+   establishment when the initiator indicates a desire to use such a
+   service, so that the initiating GSS-API can correctly indicate
+   whether the service is supported by the acceptor's GSS-API.
+
+1.2.2: Per-Message Security Service Availability
+
+   When a context is established, two flags are returned to indicate the
+   set of per-message protection security services which will be
+   available on the context:
+
+      the integ_avail flag indicates whether per-message integrity and
+      data origin authentication services are available
+
+
+
+
+
+Linn                        Standards Track                    [Page 20]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      the conf_avail flag indicates whether per-message confidentiality
+      services are available, and will never be returned TRUE unless the
+      integ_avail flag is also returned TRUE
+
+   GSS-API callers desiring per-message security services should check
+   the values of these flags at context establishment time, and must be
+   aware that a returned FALSE value for integ_avail means that
+   invocation of GSS_GetMIC() or GSS_Wrap() primitives on the associated
+   context will apply no cryptographic protection to user data messages.
+
+   The GSS-API per-message integrity and data origin authentication
+   services provide assurance to a receiving caller that protection was
+   applied to a message by the caller's peer on the security context,
+   corresponding to the entity named at context initiation.  The GSS-API
+   per-message confidentiality service provides assurance to a sending
+   caller that the message's content is protected from access by
+   entities other than the context's named peer.
+
+   The GSS-API per-message protection service primitives, as the
+   category name implies, are oriented to operation at the granularity
+   of protocol data units. They perform cryptographic operations on the
+   data units, transfer cryptographic control information in tokens,
+   and, in the case of GSS_Wrap(), encapsulate the protected data unit.
+   As such, these primitives are not oriented to efficient data
+   protection for stream-paradigm protocols (e.g., Telnet) if
+   cryptography must be applied on an octet-by-octet basis.
+
+1.2.3: Per-Message Replay Detection and Sequencing
+
+   Certain underlying mech_types offer support for replay detection
+   and/or sequencing of messages transferred on the contexts they
+   support. These optionally-selectable protection features are distinct
+   from replay detection and sequencing features applied to the context
+   establishment operation itself; the presence or absence of context-
+   level replay or sequencing features is wholly a function of the
+   underlying mech_type's capabilities, and is not selected or omitted
+   as a caller option.
+
+   The caller initiating a context provides flags (replay_det_req_flag
+   and sequence_req_flag) to specify whether the use of per-message
+   replay detection and sequencing features is desired on the context
+   being established. The GSS-API implementation at the initiator system
+   can determine whether these features are supported (and whether they
+   are optionally selectable) as a function of the selected mechanism,
+   without need for bilateral negotiation with the target. When enabled,
+   these features provide recipients with indicators as a result of
+   GSS-API processing of incoming messages, identifying whether those
+   messages were detected as duplicates or out-of-sequence. Detection of
+
+
+
+Linn                        Standards Track                    [Page 21]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   such events does not prevent a suspect message from being provided to
+   a recipient; the appropriate course of action on a suspect message is
+   a matter of caller policy.
+
+   The semantics of the replay detection and sequencing services applied
+   to received messages, as visible across the interface which the GSS-
+   API provides to its clients, are as follows:
+
+   When replay_det_state is TRUE, the possible major_status returns for
+   well-formed and correctly signed messages are as follows:
+
+      1. GSS_S_COMPLETE, without concurrent indication of
+      GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN, indicates that the
+      message was within the window (of time or sequence space) allowing
+      replay events to be detected, and that the message was not a
+      replay of a previously-processed message within that window.
+
+      2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic
+      checkvalue on the received message was correct, but that the
+      message was recognized as a duplicate of a previously-processed
+      message.  In addition to identifying duplicated tokens originated
+      by a context's peer, this status may also be used to identify
+      reflected copies of locally-generated tokens; it is recommended
+      that mechanism designers include within their protocols facilities
+      to detect and report such tokens.
+
+      3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on
+      the received message was correct, but that the message is too old
+      to be checked for duplication.
+
+   When sequence_state is TRUE, the possible major_status returns for
+   well-formed and correctly signed messages are as follows:
+
+      1. GSS_S_COMPLETE, without concurrent indication of
+      GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, or
+      GSS_S_GAP_TOKEN, indicates that the message was within the window
+      (of time or sequence space) allowing replay events to be detected,
+      that the message was not a replay of a previously-processed
+      message within that window, and that no predecessor sequenced
+      messages are missing relative to the last received message (if
+      any) processed on the context with a correct cryptographic
+      checkvalue.
+
+      2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value
+      on the received message was correct, but that the message was
+      recognized as a duplicate of a previously-processed message.  In
+      addition to identifying duplicated tokens originated by a
+      context's peer, this status may also be used to identify reflected
+
+
+
+Linn                        Standards Track                    [Page 22]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      copies of locally-generated tokens; it is recommended that
+      mechanism designers include within their protocols facilities to
+      detect and report such tokens.
+
+      3. GSS_S_OLD_TOKEN indicates that the integrity check value on the
+      received message was correct, but that the token is too old to be
+      checked for duplication.
+
+      4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue
+      on the received message was correct, but that it is earlier in a
+      sequenced stream than a message already processed on the context.
+      [Note: Mechanisms can be architected to provide a stricter form of
+      sequencing service, delivering particular messages to recipients
+      only after all predecessor messages in an ordered stream have been
+      delivered.  This type of support is incompatible with the GSS-API
+      paradigm in which recipients receive all messages, whether in
+      order or not, and provide them (one at a time, without intra-GSS-
+      API message buffering) to GSS-API routines for validation.  GSS-
+      API facilities provide supportive functions, aiding clients to
+      achieve strict message stream integrity in an efficient manner in
+      conjunction with sequencing provisions in communications
+      protocols, but the GSS-API does not offer this level of message
+      stream integrity service by itself.]
+
+      5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on
+      the received message was correct, but that one or more predecessor
+      sequenced messages have not been successfully processed relative
+      to the last received message (if any) processed on the context
+      with a correct cryptographic checkvalue.
+
+   As the message stream integrity features (especially sequencing) may
+   interfere with certain applications' intended communications
+   paradigms, and since support for such features is likely to be
+   resource intensive, it is highly recommended that mech_types
+   supporting these features allow them to be activated selectively on
+   initiator request when a context is established. A context initiator
+   and target are provided with corresponding indicators
+   (replay_det_state and sequence_state), signifying whether these
+   features are active on a given context.
+
+   An example mech_type supporting per-message replay detection could
+   (when replay_det_state is TRUE) implement the feature as follows: The
+   underlying mechanism would insert timestamps in data elements output
+   by GSS_GetMIC() and GSS_Wrap(), and would maintain (within a time-
+   limited window) a cache (qualified by originator-recipient pair)
+   identifying received data elements processed by GSS_VerifyMIC() and
+   GSS_Unwrap(). When this feature is active, exception status returns
+   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when
+
+
+
+Linn                        Standards Track                    [Page 23]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   GSS_VerifyMIC() or GSS_Unwrap() is presented with a message which is
+   either a detected duplicate of a prior message or which is too old to
+   validate against a cache of recently received messages.
+
+1.2.4:  Quality of Protection
+
+   Some mech_types provide their users with fine granularity control
+   over the means used to provide per-message protection, allowing
+   callers to trade off security processing overhead dynamically against
+   the protection requirements of particular messages. A per-message
+   quality-of-protection parameter (analogous to quality-of-service, or
+   QOS) selects among different QOP options supported by that mechanism.
+   On context establishment for a multi-QOP mech_type, context-level
+   data provides the prerequisite data for a range of protection
+   qualities.
+
+   It is expected that the majority of callers will not wish to exert
+   explicit mechanism-specific QOP control and will therefore request
+   selection of a default QOP. Definitions of, and choices among, non-
+   default QOP values are mechanism-specific, and no ordered sequences
+   of QOP values can be assumed equivalent across different mechanisms.
+   Meaningful use of non-default QOP values demands that callers be
+   familiar with the QOP definitions of an underlying mechanism or
+   mechanisms, and is therefore a non-portable construct.  The
+   GSS_S_BAD_QOP major_status value is defined in order to indicate that
+   a provided QOP value is unsupported for a security context, most
+   likely because that value is unrecognized by the underlying
+   mechanism.
+
+   In the interests of interoperability, mechanisms which allow optional
+   support of particular QOP values shall satisfy one of the following
+   conditions.  Either:
+
+      (i) All implementations of the mechanism are required to be
+      capable of processing messages protected using any QOP value,
+      regardless of whether they can apply protection corresponding to
+      that QOP, or
+
+      (ii) The set of mutually-supported receiver QOP values must be
+      determined during context establishment, and messages may be
+      protected by either peer using only QOP values from this
+      mutually-supported set.
+
+   NOTE: (i) is just a special-case of (ii), where implementations are
+   required to support all QOP values on receipt.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 24]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+1.2.5: Anonymity Support
+
+   In certain situations or environments, an application may wish to
+   authenticate a peer and/or protect communications using GSS-API per-
+   message services without revealing its own identity.  For example,
+   consider an application which provides read access to a research
+   database, and which permits queries by arbitrary requestors.  A
+   client of such a service might wish to authenticate the service, to
+   establish trust in the information received from it, but might not
+   wish to disclose its identity to the service for privacy reasons.
+
+   In ordinary GSS-API usage, a context initiator's identity is made
+   available to the context acceptor as part of the context
+   establishment process.  To provide for anonymity support, a facility
+   (input anon_req_flag to GSS_Init_sec_context()) is provided through
+   which context initiators may request that their identity not be
+   provided to the context acceptor.  Mechanisms are not required to
+   honor this request, but a caller will be informed (via returned
+   anon_state indicator from GSS_Init_sec_context()) whether or not the
+   request is honored. Note that authentication as the anonymous
+   principal does not necessarily imply that credentials are not
+   required in order to establish a context.
+
+   Section 4.5 of this document defines the Object Identifier value used
+   to identify an anonymous principal.
+
+   Four possible combinations of anon_state and mutual_state are
+   possible, with the following results:
+
+      anon_state == FALSE, mutual_state == FALSE: initiator
+      authenticated to target.
+
+      anon_state == FALSE, mutual_state == TRUE: initiator authenticated
+      to target, target authenticated to initiator.
+
+      anon_state == TRUE, mutual_state == FALSE: initiator authenticated
+      as anonymous principal to target.
+
+      anon_state == TRUE, mutual_state == TRUE: initiator authenticated
+      as anonymous principal to target, target authenticated to
+      initiator.
+
+1.2.6: Initialization
+
+   No initialization calls (i.e., calls which must be invoked prior to
+   invocation of other facilities in the interface) are defined in GSS-
+   API.  As an implication of this fact, GSS-API implementations must
+   themselves be self-initializing.
+
+
+
+Linn                        Standards Track                    [Page 25]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+1.2.7: Per-Message Protection During Context Establishment
+
+   A facility is defined in GSS-V2 to enable protection and buffering of
+   data messages for later transfer while a security context's
+   establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases
+   where the caller side already possesses the necessary session key to
+   enable this processing. Specifically, a new state Boolean, called
+   prot_ready_state, is added to the set of information returned by
+   GSS_Init_sec_context(), GSS_Accept_sec_context(), and
+   GSS_Inquire_context().
+
+   For context establishment calls, this state Boolean is valid and
+   interpretable when the associated major_status is either
+   GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE.  Callers of GSS-API (both
+   initiators and acceptors) can assume that per-message protection (via
+   GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
+   available and ready for use if either: prot_ready_state == TRUE, or
+   major_status == GSS_S_COMPLETE, though mutual authentication (if
+   requested) cannot be guaranteed until GSS_S_COMPLETE is returned.
+   Callers making use of per-message protection services in advance of
+   GSS_S_COMPLETE status should be aware of the possibility that a
+   subsequent context establishment step may fail, and that certain
+   context data (e.g., mech_type) as returned for subsequent calls may
+   change.
+
+   This approach achieves full, transparent backward compatibility for
+   GSS-API V1 callers, who need not even know of the existence of
+   prot_ready_state, and who will get the expected behavior from
+   GSS_S_COMPLETE, but who will not be able to use per-message
+   protection before GSS_S_COMPLETE is returned.
+
+   It is not a requirement that GSS-V2 mechanisms ever return TRUE
+   prot_ready_state before completion of context establishment (indeed,
+   some mechanisms will not evolve usable message protection keys,
+   especially at the context acceptor, before context establishment is
+   complete).  It is expected but not required that GSS-V2 mechanisms
+   will return TRUE prot_ready_state upon completion of context
+   establishment if they support per-message protection at all (however
+   GSS-V2 applications should not assume that TRUE prot_ready_state will
+   always be returned together with the GSS_S_COMPLETE major_status,
+   since GSS-V2 implementations may continue to support GSS-V1 mechanism
+   code, which will never return TRUE prot_ready_state).
+
+   When prot_ready_state is returned TRUE, mechanisms shall also set
+   those context service indicator flags (deleg_state, mutual_state,
+   replay_det_state, sequence_state, anon_state, trans_state,
+   conf_avail, integ_avail) which represent facilities confirmed, at
+   that time, to be available on the context being established.  In
+
+
+
+Linn                        Standards Track                    [Page 26]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   situations where prot_ready_state is returned before GSS_S_COMPLETE,
+   it is possible that additional facilities may be confirmed and
+   subsequently indicated when GSS_S_COMPLETE is returned.
+
+1.2.8: Implementation Robustness
+
+   This section recommends aspects of GSS-API implementation behavior in
+   the interests of overall robustness.
+
+   Invocation of GSS-API calls is to incur no undocumented side effects
+   visible at the GSS-API level.
+
+   If a token is presented for processing on a GSS-API security context
+   and that token generates a fatal error in processing or is otherwise
+   determined to be invalid for that context, the context's state should
+   not be disrupted for purposes of processing subsequent valid tokens.
+
+   Certain local conditions at a GSS-API implementation (e.g.,
+   unavailability of memory) may preclude, temporarily or permanently,
+   the successful processing of tokens on a GSS-API security context,
+   typically generating GSS_S_FAILURE major_status returns along with
+   locally-significant minor_status.  For robust operation under such
+   conditions, the following recommendations are made:
+
+      Failing calls should free any memory they allocate, so that
+      callers may retry without causing further loss of resources.
+
+      Failure of an individual call on an established context should not
+      preclude subsequent calls from succeeding on the same context.
+
+      Whenever possible, it should be possible for
+      GSS_Delete_sec_context() calls to be successfully processed even
+      if other calls cannot succeed, thereby enabling context-related
+      resources to be released.
+
+   A failure of GSS_GetMIC() or GSS_Wrap() due to an attempt to use an
+   unsupported QOP will not interfere with context validity, nor shall
+   such a failure impact the ability of the application to subsequently
+   invoke GSS_GetMIC() or GSS_Wrap() using a supported QOP. Any state
+   information concerning sequencing of outgoing messages shall be
+   unchanged by an unsuccessful call of GSS_GetMIC() or GSS_Wrap().
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 27]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+1.2.9: Delegation
+
+   The GSS-API allows delegation to be controlled by the initiating
+   application via a Boolean parameter to GSS_Init_sec_context(), the
+   routine that establishes a security context.  Some mechanisms do not
+   support delegation, and for such mechanisms attempts by an
+   application to enable delegation are ignored.
+
+   The acceptor of a security context for which the initiator enabled
+   delegation will receive (via the delegated_cred_handle parameter of
+   GSS_Accept_sec_context()) a credential handle that contains the
+   delegated identity, and this credential handle may be used to
+   initiate subsequent GSS-API security contexts as an agent or delegate
+   of the initiator.  If the original initiator's identity is "A" and
+   the delegate's identity is "B", then, depending on the underlying
+   mechanism, the identity embodied by the delegated credential may be
+   either "A" or "B acting for A".
+
+   For many mechanisms that support delegation, a simple Boolean does
+   not provide enough control.  Examples of additional aspects of
+   delegation control that a mechanism might provide to an application
+   are duration of delegation, network addresses from which delegation
+   is valid, and constraints on the tasks that may be performed by a
+   delegate.  Such controls are presently outside the scope of the GSS-
+   API.  GSS-API implementations supporting mechanisms offering
+   additional controls should provide extension routines that allow
+   these controls to be exercised (perhaps by modifying the initiator's
+   GSS-API credential prior to its use in establishing a context).
+   However, the simple delegation control provided by GSS-API should
+   always be able to over-ride other mechanism-specific delegation
+   controls; if the application instructs GSS_Init_sec_context() that
+   delegation is not desired, then the implementation must not permit
+   delegation to occur.  This is an exception to the general rule that a
+   mechanism may enable services even if they are not requested;
+   delegation may only be provided at the explicit request of the
+   application.
+
+1.2.10: Interprocess Context Transfer
+
+   GSS-API V2 provides routines (GSS_Export_sec_context() and
+   GSS_Import_sec_context()) which allow a security context to be
+   transferred between processes on a single machine.  The most common
+   use for such a feature is a client-server design where the server is
+   implemented as a single process that accepts incoming security
+   contexts, which then launches child processes to deal with the data
+   on these contexts.  In such a design, the child processes must have
+   access to the security context data structure created within the
+
+
+
+
+Linn                        Standards Track                    [Page 28]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   parent by its call to GSS_Accept_sec_context() so that they can use
+   per-message protection services and delete the security context when
+   the communication session ends.
+
+   Since the security context data structure is expected to contain
+   sequencing information, it is impractical in general to share a
+   context between processes.  Thus GSS-API provides a call
+   (GSS_Export_sec_context()) that the process which currently owns the
+   context can call to declare that it has no intention to use the
+   context subsequently, and to create an inter-process token containing
+   information needed by the adopting process to successfully import the
+   context.  After successful completion of this call, the original
+   security context is made inaccessible to the calling process by GSS-
+   API, and any context handles referring to this context are no longer
+   valid.  The originating process transfers the inter-process token to
+   the adopting process, which passes it to GSS_Import_sec_context(),
+   and a fresh context handle is created such that it is functionally
+   identical to the original context.
+
+   The inter-process token may contain sensitive data from the original
+   security context (including cryptographic keys).  Applications using
+   inter-process tokens to transfer security contexts must take
+   appropriate steps to protect these tokens in transit.
+   Implementations are not required to support the inter-process
+   transfer of security contexts.  The ability to transfer a security
+   context is indicated when the context is created, by
+   GSS_Init_sec_context() or GSS_Accept_sec_context() indicating a TRUE
+   trans_state return value.
+
+2:  Interface Descriptions
+
+   This section describes the GSS-API's service interface, dividing the
+   set of calls offered into four groups. Credential management calls
+   are related to the acquisition and release of credentials by
+   principals. Context-level calls are related to the management of
+   security contexts between principals. Per-message calls are related
+   to the protection of individual messages on established security
+   contexts. Support calls provide ancillary functions useful to GSS-API
+   callers. Table 2 groups and summarizes the calls in tabular fashion.
+
+   Table 2:  GSS-API Calls
+
+   CREDENTIAL MANAGEMENT
+
+   GSS_Acquire_cred             acquire credentials for use
+   GSS_Release_cred             release credentials after use
+   GSS_Inquire_cred             display information about
+                                credentials
+
+
+
+Linn                        Standards Track                    [Page 29]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   GSS_Add_cred                 construct credentials incrementally
+   GSS_Inquire_cred_by_mech     display per-mechanism credential
+                                  information
+
+   CONTEXT-LEVEL CALLS
+
+   GSS_Init_sec_context         initiate outbound security context
+   GSS_Accept_sec_context       accept inbound security context
+   GSS_Delete_sec_context       flush context when no longer needed
+   GSS_Process_context_token    process received control token on
+                                  context
+   GSS_Context_time             indicate validity time remaining on
+                                     context
+   GSS_Inquire_context          display information about context
+   GSS_Wrap_size_limit          determine GSS_Wrap token size limit
+   GSS_Export_sec_context       transfer context to other process
+   GSS_Import_sec_context       import transferred context
+
+   PER-MESSAGE CALLS
+
+   GSS_GetMIC                   apply integrity check, receive as
+                                  token separate from message
+   GSS_VerifyMIC                validate integrity check token
+                                  along with message
+   GSS_Wrap                     sign, optionally encrypt,
+                                  encapsulate
+   GSS_Unwrap                   decapsulate, decrypt if needed,
+                                  validate integrity check
+
+   SUPPORT CALLS
+
+   GSS_Display_status           translate status codes to printable
+                                  form
+   GSS_Indicate_mechs           indicate mech_types supported on
+                                  local system
+   GSS_Compare_name             compare two names for equality
+   GSS_Display_name             translate name to printable form
+   GSS_Import_name              convert printable name to
+                                  normalized form
+   GSS_Release_name             free storage of normalized-form
+                                  name
+   GSS_Release_buffer           free storage of general GSS-allocated
+                                  object
+   GSS_Release_OID_set          free storage of OID set object
+   GSS_Create_empty_OID_set     create empty OID set
+   GSS_Add_OID_set_member       add member to OID set
+   GSS_Test_OID_set_member      test if OID is member of OID set
+   GSS_Inquire_names_for_mech   indicate name types supported by
+
+
+
+Linn                        Standards Track                    [Page 30]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+                                  mechanism
+   GSS_Inquire_mechs_for_name   indicates mechanisms supporting name
+                                  type
+   GSS_Canonicalize_name        translate name to per-mechanism form
+   GSS_Export_name              externalize per-mechanism name
+   GSS_Duplicate_name           duplicate name object
+
+2.1:  Credential management calls
+
+   These GSS-API calls provide functions related to the management of
+   credentials. Their characterization with regard to whether or not
+   they may block pending exchanges with other network entities (e.g.,
+   directories or authentication servers) depends in part on OS-specific
+   (extra-GSS-API) issues, so is not specified in this document.
+
+   The GSS_Acquire_cred() call is defined within the GSS-API in support
+   of application portability, with a particular orientation towards
+   support of portable server applications. It is recognized that (for
+   certain systems and mechanisms) credentials for interactive users may
+   be managed differently from credentials for server processes; in such
+   environments, it is the GSS-API implementation's responsibility to
+   distinguish these cases and the procedures for making this
+   distinction are a local matter. The GSS_Release_cred() call provides
+   a means for callers to indicate to the GSS-API that use of a
+   credentials structure is no longer required. The GSS_Inquire_cred()
+   call allows callers to determine information about a credentials
+   structure.  The GSS_Add_cred() call enables callers to append
+   elements to an existing credential structure, allowing iterative
+   construction of a multi-mechanism credential. The
+   GSS_Inquire_cred_by_mech() call enables callers to extract per-
+   mechanism information describing a credentials structure.
+
+2.1.1:  GSS_Acquire_cred call
+
+   Inputs:
+
+   o  desired_name INTERNAL NAME, -- NULL requests locally-determined
+   -- default
+
+   o  lifetime_req INTEGER, -- in seconds; 0 requests default
+
+   o  desired_mechs SET OF OBJECT IDENTIFIER, -- NULL requests
+   -- system-selected default
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+
+
+
+
+Linn                        Standards Track                    [Page 31]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL,
+   -- caller must release with GSS_Release_cred()
+
+   o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned non-NULL,
+   -- caller must release with GSS_Release_oid_set()
+
+   o  lifetime_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that requested credentials were
+   successfully established, for the duration indicated in lifetime_rec,
+   suitable for the usage requested in cred_usage, for the set of
+   mech_types indicated in actual_mechs, and that those credentials can
+   be referenced for subsequent use with the handle returned in
+   output_cred_handle.
+
+   o  GSS_S_BAD_MECH indicates that a mech_type unsupported by the GSS-
+   API implementation type was requested, causing the credential
+   establishment operation to fail.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
+   uninterpretable or of a type unsupported by the applicable underlying
+   GSS-API mechanism(s), so no credentials could be established for the
+   accompanying desired_name.
+
+   o  GSS_S_BAD_NAME indicates that the provided desired_name is
+   inconsistent in terms of internally-incorporated type specifier
+   information, so no credentials could be established for the
+   accompanying desired_name.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that underlying credential
+   elements corresponding to the requested desired_name have expired, so
+   requested credentials could not be established.
+
+   o GSS_S_NO_CRED indicates that no credential elements corresponding
+   to the requested desired_name and usage could be accessed, so
+   requested credentials could not be established.  In particular, this
+   status should be returned upon temporary user-fixable conditions
+
+
+
+
+
+Linn                        Standards Track                    [Page 32]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   preventing successful credential establishment and upon lack of
+   authorization to establish and use credentials associated with the
+   identity named in the input desired_name argument.
+
+   o  GSS_S_FAILURE indicates that credential establishment failed for
+   reasons unspecified at the GSS-API level.
+
+   GSS_Acquire_cred() is used to acquire credentials so that a principal
+   can (as a function of the input cred_usage parameter) initiate and/or
+   accept security contexts under the identity represented by the
+   desired_name input argument. On successful completion, the returned
+   output_cred_handle result provides a handle for subsequent references
+   to the acquired credentials.  Typically, single-user client processes
+   requesting that default credential behavior be applied for context
+   establishment purposes will have no need to invoke this call.
+
+   A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name,
+   which will be interpreted as a request for a credential handle that
+   will invoke default behavior when passed to GSS_Init_sec_context(),
+   if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or
+   GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or
+   GSS_C_BOTH.  It is possible that multiple pre-established credentials
+   may exist for the same principal identity (for example, as a result
+   of multiple user login sessions) when GSS_Acquire_cred() is called;
+   the means used in such cases to select a specific credential are
+   local matters.  The input lifetime_req argument to GSS_Acquire_cred()
+   may provide useful information for local GSS-API implementations to
+   employ in making this disambiguation in a manner which will best
+   satisfy a caller's intent.
+
+   This routine is expected to be used primarily by context acceptors,
+   since implementations are likely to provide mechanism-specific ways
+   of obtaining GSS-API initiator credentials from the system login
+   process.  Some implementations may therefore not support the
+   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
+   GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name
+   resulting from applying GSS_Inquire_context() to an active context,
+   or a name resulting from applying GSS_Inquire_cred() against a
+   credential handle corresponding to default behavior. It is important
+   to recognize that the explicit name which is yielded by resolving a
+   default reference may change over time, e.g., as a result of local
+   credential element management operations outside GSS-API; once
+   resolved, however, the value of such an explicit name will remain
+   constant.
+
+   The lifetime_rec result indicates the length of time for which the
+   acquired credentials will be valid, as an offset from the present. A
+   mechanism may return a reserved value indicating INDEFINITE if no
+
+
+
+Linn                        Standards Track                    [Page 33]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   constraints on credential lifetime are imposed.  A caller of
+   GSS_Acquire_cred() can request a length of time for which acquired
+   credentials are to be valid (lifetime_req argument), beginning at the
+   present, or can request credentials with a default validity interval.
+   (Requests for postdated credentials are not supported within the
+   GSS-API.) Certain mechanisms and implementations may bind in
+   credential validity period specifiers at a point preliminary to
+   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
+   user login procedures). As a result, callers requesting non-default
+   values for lifetime_req must recognize that such requests cannot
+   always be honored and must be prepared to accommodate the use of
+   returned credentials with different lifetimes as indicated in
+   lifetime_rec.
+
+   The caller of GSS_Acquire_cred() can explicitly specify a set of
+   mech_types which are to be accommodated in the returned credentials
+   (desired_mechs argument), or can request credentials for a system-
+   defined default set of mech_types. Selection of the system-specified
+   default set is recommended in the interests of application
+   portability. The actual_mechs return value may be interrogated by the
+   caller to determine the set of mechanisms with which the returned
+   credentials may be used.
+
+2.1.2:  GSS_Release_cred call
+
+   Input:
+
+   o  cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL
+   -- is specified, the call will complete successfully, but
+   -- will have no effect; no credential elements will be
+   -- released.
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+   input cred_handle were released for purposes of subsequent access by
+   the caller. The effect on other processes which may be authorized
+   shared access to such credentials is a local matter.
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 34]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_NO_CRED indicates that no release operation was performed,
+   either because the input cred_handle was invalid or because the
+   caller lacks authorization to access the referenced credentials.
+
+   o  GSS_S_FAILURE indicates that the release operation failed for
+   reasons unspecified at the GSS-API level.
+
+   Provides a means for a caller to explicitly request that credentials
+   be released when their use is no longer required. Note that system-
+   specific credential management functions are also likely to exist,
+   for example to assure that credentials shared among processes are
+   properly deleted when all affected processes terminate, even if no
+   explicit release requests are issued by those processes. Given the
+   fact that multiple callers are not precluded from gaining authorized
+   access to the same credentials, invocation of GSS_Release_cred()
+   cannot be assumed to delete a particular set of credentials on a
+   system-wide basis.
+
+2.1.3:  GSS_Inquire_cred call
+
+   Input:
+
+   o  cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL
+   -- is specified, default initiator credentials are queried
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  cred_name INTERNAL NAME,  -- caller must release with
+   -- GSS_Release_name()
+
+   o  lifetime_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+   o  mech_set SET OF OBJECT IDENTIFIER  -- caller must release
+   -- with GSS_Release_oid_set()
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 35]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+   input cred_handle argument were valid, and that the output cred_name,
+   lifetime_rec, and cred_usage values represent, respectively, the
+   credentials' associated principal name, remaining lifetime, suitable
+   usage modes, and supported mechanism types.
+
+   o  GSS_S_NO_CRED indicates that no information could be returned
+   about the referenced credentials, either because the input
+   cred_handle was invalid or because the caller lacks authorization to
+   access the referenced credentials.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
+   credentials are invalid.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
+   credentials have expired.
+
+   o  GSS_S_FAILURE indicates that the operation failed for reasons
+   unspecified at the GSS-API level.
+
+   The GSS_Inquire_cred() call is defined primarily for the use of those
+   callers which request use of default credential behavior rather than
+   acquiring credentials explicitly with GSS_Acquire_cred().  It enables
+   callers to determine a credential structure's associated principal
+   name, remaining validity period, usability for security context
+   initiation and/or acceptance, and supported mechanisms.
+
+   For a multi-mechanism credential, the returned "lifetime" specifier
+   indicates the shortest lifetime of any of the mechanisms' elements in
+   the credential (for either context initiation or acceptance
+   purposes).
+
+   GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
+   "cred_usage" if both of the following conditions hold:
+
+      (1) there exists in the credential an element which allows context
+      initiation using some mechanism
+
+      (2) there exists in the credential an element which allows context
+      acceptance using some mechanism (allowably, but not necessarily,
+      one of the same mechanism(s) qualifying for (1)).
+
+   If condition (1) holds but not condition (2), GSS_Inquire_cred()
+   should indicate INITIATE-ONLY for "cred_usage".  If condition (2)
+   holds but not condition (1), GSS_Inquire_cred() should indicate
+   ACCEPT-ONLY for "cred_usage".
+
+
+
+Linn                        Standards Track                    [Page 36]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Callers requiring finer disambiguation among available combinations
+   of lifetimes, usage modes, and mechanisms should call the
+   GSS_Inquire_cred_by_mech() routine, passing that routine one of the
+   mech OIDs returned by GSS_Inquire_cred().
+
+2.1.4:  GSS_Add_cred call
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE -- handle to credential
+   -- structure created with prior GSS_Acquire_cred() or
+   -- GSS_Add_cred() call; see text for definition of behavior
+   -- when GSS_C_NO_CREDENTIAL provided.
+
+   o  desired_name INTERNAL NAME
+
+   o  initiator_time_req INTEGER -- in seconds; 0 requests default
+
+   o  acceptor_time_req INTEGER -- in seconds; 0 requests default
+
+   o  desired_mech OBJECT IDENTIFIER
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_cred_handle CREDENTIAL HANDLE, -- NULL to request that
+   -- credential elements be added "in place" to the credential
+   -- structure identified by input_cred_handle,
+   -- non-NULL pointer to request that
+   -- a new credential structure and handle be created.
+   -- if credential handle returned, caller must release with
+   -- GSS_Release_cred()
+
+   o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must
+   -- release with GSS_Release_oid_set()
+
+   o  initiator_time_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+
+
+
+Linn                        Standards Track                    [Page 37]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+   o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
+   -- supported by resulting credential.
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+   input_cred_handle argument were valid, and that the resulting
+   credential from GSS_Add_cred() is valid for the durations indicated
+   in initiator_time_rec and acceptor_time_rec, suitable for the usage
+   requested in cred_usage, and for the mechanisms indicated in
+   actual_mechs.
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech
+   specified a mechanism for which the referenced credential already
+   contained a credential element with overlapping cred_usage and
+   validity time specifiers.
+
+   o  GSS_S_BAD_MECH indicates that the input desired_mech specified a
+   mechanism unsupported by the GSS-API implementation, causing the
+   GSS_Add_cred() operation to fail.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
+   uninterpretable or of a type unsupported by the applicable underlying
+   GSS-API mechanism(s), so the GSS_Add_cred() operation could not be
+   performed for that name.
+
+   o  GSS_S_BAD_NAME indicates that the provided desired_name is
+   inconsistent in terms of internally-incorporated type specifier
+   information, so the GSS_Add_cred() operation could not be performed
+   for that name.
+
+   o  GSS_S_NO_CRED indicates that the input_cred_handle referenced
+   invalid or inaccessible credentials. In particular, this status
+   should be returned upon temporary user-fixable conditions preventing
+   successful credential establishment or upon lack of authorization to
+   establish or use credentials representing the requested identity.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that referenced credential
+   elements have expired, so the GSS_Add_cred() operation could not be
+   performed.
+
+   o  GSS_S_FAILURE indicates that the operation failed for reasons
+   unspecified at the GSS-API level.
+
+
+
+
+
+Linn                        Standards Track                    [Page 38]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   GSS_Add_cred() enables callers to construct credentials iteratively
+   by adding credential elements in successive operations, corresponding
+   to different mechanisms.  This offers particular value in multi-
+   mechanism environments, as the major_status and minor_status values
+   returned on each iteration are individually visible and can therefore
+   be interpreted unambiguously on a per-mechanism basis. A credential
+   element is identified by the name of the principal to which it
+   refers.  GSS-API implementations must impose a local access control
+   policy on callers of this routine to prevent unauthorized callers
+   from acquiring credential elements to which they are not entitled.
+   This routine is not intended to provide a "login to the network"
+   function, as such a function would involve the creation of new
+   mechanism-specific authentication data, rather than merely acquiring
+   a GSS-API handle to existing data.  Such functions, if required,
+   should be defined in implementation-specific extension routines.
+
+   If credential acquisition is time-consuming for a mechanism, the
+   mechanism may choose to delay the actual acquisition until the
+   credential is required (e.g. by GSS_Init_sec_context() or
+   GSS_Accept_sec_context()).  Such mechanism-specific implementation
+   decisions should be invisible to the calling application; thus a call
+   of GSS_Inquire_cred() immediately following the call of
+   GSS_Acquire_cred() must return valid credential data, and may
+   therefore incur the overhead of a deferred credential acquisition.
+
+   If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL
+   output_cred_handle must be supplied.  For the case of
+   GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create
+   the credential referenced by its output_cred_handle based on default
+   behavior.  That is, the call will have the same effect as if the
+   caller had previously called GSS_Acquire_cred(), specifying the same
+   usage and passing GSS_C_NO_NAME as the desired_name parameter
+   (thereby obtaining an explicit credential handle corresponding to
+   default behavior), had passed that credential handle to
+   GSS_Add_cred(), and had finally called GSS_Release_cred() on the
+   credential handle received from GSS_Acquire_cred().
+
+   This routine is expected to be used primarily by context acceptors,
+   since implementations are likely to provide mechanism-specific ways
+   of obtaining GSS-API initiator credentials from the system login
+   process.  Some implementations may therefore not support the
+   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
+   GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name
+   resulting from applying GSS_Inquire_context() to an active context,
+   or a name resulting from applying GSS_Inquire_cred() against a
+   credential handle corresponding to default behavior. It is important
+   to recognize that the explicit name which is yielded by resolving a
+   default reference may change over time, e.g., as a result of local
+
+
+
+Linn                        Standards Track                    [Page 39]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   credential element management operations outside GSS-API; once
+   resolved, however, the value of such an explicit name will remain
+   constant.
+
+   A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name,
+   which will be interpreted as a request for a credential handle that
+   will invoke default behavior when passed to GSS_Init_sec_context(),
+   if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or
+   GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or
+   GSS_C_BOTH.
+
+   The same input desired_name, or default reference, should be used on
+   all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a
+   particular credential.
+
+2.1.5:  GSS_Inquire_cred_by_mech call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL
+   -- specified, default initiator credentials are queried
+
+   o  mech_type OBJECT IDENTIFIER  -- specific mechanism for
+   -- which credentials are being queried
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  cred_name INTERNAL NAME, -- guaranteed to be MN; caller must
+   -- release with GSS_Release_name()
+
+   o  lifetime_rec_initiate INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   o  lifetime_rec_accept INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+   -- 2=ACCEPT-ONLY
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials referenced by the
+   input cred_handle argument were valid, that the mechanism indicated
+   by the input mech_type was represented with elements within those
+
+
+
+Linn                        Standards Track                    [Page 40]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   credentials, and that the output cred_name, lifetime_rec_initiate,
+   lifetime_rec_accept, and cred_usage values represent, respectively,
+   the credentials' associated principal name, remaining lifetimes, and
+   suitable usage modes.
+
+   o  GSS_S_NO_CRED indicates that no information could be returned
+   about the referenced credentials, either because the input
+   cred_handle was invalid or because the caller lacks authorization to
+   access the referenced credentials.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
+   credentials are invalid.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
+   credentials have expired.
+
+   o  GSS_S_BAD_MECH indicates that the referenced credentials do not
+   contain elements for the requested mechanism.
+
+   o  GSS_S_FAILURE indicates that the operation failed for reasons
+   unspecified at the GSS-API level.
+
+   The GSS_Inquire_cred_by_mech() call enables callers in multi-
+   mechanism environments to acquire specific data about available
+   combinations of lifetimes, usage modes, and mechanisms within a
+   credential structure.  The lifetime_rec_initiate result indicates the
+   available lifetime for context initiation purposes; the
+   lifetime_rec_accept result indicates the available lifetime for
+   context acceptance purposes.
+
+2.2:  Context-level calls
+
+   This group of calls is devoted to the establishment and management of
+   security contexts between peers. A context's initiator calls
+   GSS_Init_sec_context(), resulting in generation of a token which the
+   caller passes to the target. At the target, that token is passed to
+   GSS_Accept_sec_context(). Depending on the underlying mech_type and
+   specified options, additional token exchanges may be performed in the
+   course of context establishment; such exchanges are accommodated by
+   GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and
+   GSS_Accept_sec_context().
+
+   Either party to an established context may invoke
+   GSS_Delete_sec_context() to flush context information when a context
+   is no longer required. GSS_Process_context_token() is used to process
+   received tokens carrying context-level control information.
+   GSS_Context_time() allows a caller to determine the length of time
+   for which an established context will remain valid.
+
+
+
+Linn                        Standards Track                    [Page 41]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   GSS_Inquire_context() returns status information describing context
+   characteristics. GSS_Wrap_size_limit() allows a caller to determine
+   the size of a token which will be generated by a GSS_Wrap()
+   operation.  GSS_Export_sec_context() and GSS_Import_sec_context()
+   enable transfer of active contexts between processes on an end
+   system.
+
+2.2.1:  GSS_Init_sec_context call
+
+   Inputs:
+
+   o  claimant_cred_handle CREDENTIAL HANDLE, -- NULL specifies "use
+   -- default"
+
+   o  input_context_handle CONTEXT HANDLE, -- 0
+   -- (GSS_C_NO_CONTEXT) specifies "none assigned yet"
+
+   o  targ_name INTERNAL NAME,
+
+   o  mech_type OBJECT IDENTIFIER, -- NULL parameter specifies "use
+   -- default"
+
+   o  deleg_req_flag BOOLEAN,
+
+   o  mutual_req_flag BOOLEAN,
+
+   o  replay_det_req_flag BOOLEAN,
+
+   o  sequence_req_flag BOOLEAN,
+
+   o  anon_req_flag BOOLEAN,
+
+   o  conf_req_flag BOOLEAN,
+
+   o  integ_req_flag BOOLEAN,
+
+   o  lifetime_req INTEGER, -- 0 specifies default lifetime
+
+   o  chan_bindings OCTET STRING,
+
+   o  input_token OCTET STRING -- NULL or token received from target
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 42]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  output_context_handle CONTEXT HANDLE,  -- once returned non-NULL,
+   -- caller must release with GSS_Delete_sec_context()
+
+   o  mech_type OBJECT IDENTIFIER, -- actual mechanism always
+   -- indicated, never NULL; caller should treat as read-only
+   -- and should not attempt to release
+
+   o  output_token OCTET STRING, -- NULL or token to pass to context
+   -- target; caller must release with GSS_Release_buffer()
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  anon_state BOOLEAN,
+
+   o  trans_state BOOLEAN,
+
+   o  prot_ready_state BOOLEAN, -- see Section 1.2.7
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  lifetime_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   This call may block pending network interactions for those mech_types
+   in which an authentication server or other network entity must be
+   consulted on behalf of a context initiator in order to generate an
+   output_token suitable for presentation to a specified target.
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that context-level information was
+   successfully initialized, and that the returned output_token will
+   provide sufficient information for the target to perform per-message
+   processing on the newly-established context.
+
+   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
+   returned output_token must be sent to the target, and that a reply
+   must be received and passed as the input_token argument
+
+
+
+
+
+Linn                        Standards Track                    [Page 43]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   to a continuation call to GSS_Init_sec_context(), before per-message
+   processing can be performed in conjunction with this context (unless
+   the prot_ready_state value is concurrently returned TRUE).
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+   on the input_token failed, preventing further processing from being
+   performed based on that token.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
+   performed on the credential structure referenced by
+   claimant_cred_handle failed, preventing further processing from being
+   performed using that credential structure.
+
+   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received
+   input_token contains an incorrect integrity check, so context setup
+   cannot be accomplished.
+
+   o  GSS_S_NO_CRED indicates that no context was established, either
+   because the input cred_handle was invalid, because the referenced
+   credentials are valid for context acceptor use only, because the
+   caller lacks authorization to access the referenced credentials, or
+   because the resolution of default credentials failed.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
+   through the input claimant_cred_handle argument are no longer valid,
+   so context establishment cannot be completed.
+
+   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-
+   provided chan_bindings and those extracted from the input_token was
+   detected, signifying a security-relevant event and preventing context
+   establishment. (This result will be returned by
+   GSS_Init_sec_context() only for contexts where mutual_state is TRUE.)
+
+   o  GSS_S_OLD_TOKEN indicates that the input_token is too old to be
+   checked for integrity. This is a fatal error during context
+   establishment.
+
+   o  GSS_S_DUPLICATE_TOKEN indicates that the input token has a correct
+   integrity check, but is a duplicate of a token already processed.
+   This is a fatal error during context establishment.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided; this major status will be
+   returned only for successor calls following GSS_S_CONTINUE_ NEEDED
+   status returns.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 44]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_BAD_NAMETYPE indicates that the provided targ_name is of a
+   type uninterpretable or unsupported by the applicable underlying
+   GSS-API mechanism(s), so context establishment cannot be completed.
+
+   o  GSS_S_BAD_NAME indicates that the provided targ_name is
+   inconsistent in terms of internally-incorporated type specifier
+   information, so context establishment cannot be accomplished.
+
+   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
+   or of a caller request specifying a mechanism unsupported by the
+   local system or with the caller's active credentials
+
+   o  GSS_S_FAILURE indicates that context setup could not be
+   accomplished for reasons unspecified at the GSS-API level, and that
+   no interface-defined recovery action is available.
+
+   This routine is used by a context initiator, and ordinarily emits an
+   output_token suitable for use by the target within the selected
+   mech_type's protocol.  For the case of a multi-step exchange, this
+   output_token will be one in a series, each generated by a successive
+   call. Using information in the credentials structure referenced by
+   claimant_cred_handle, GSS_Init_sec_context() initializes the data
+   structures required to establish a security context with target
+   targ_name.
+
+   The targ_name may be any valid INTERNAL NAME; it need not be an MN.
+   In addition to support for other name types, it is recommended (newly
+   as of GSS-V2, Update 1) that mechanisms be able to accept
+   GSS_C_NO_NAME as an input type for targ_name.  While recommended,
+   such support is not required, and it is recognized that not all
+   mechanisms can construct tokens without explicitly naming the context
+   target, even when mutual authentication of the target is not
+   obtained.  Callers wishing to make use of this facility and concerned
+   with portability should be aware that support for GSS_C_NO_NAME as
+   input targ_name type is unlikely to be provided within mechanism
+   definitions specified prior to GSS-V2, Update 1.
+
+   The claimant_cred_handle must correspond to the same valid
+   credentials structure on the initial call to GSS_Init_sec_context()
+   and on any successor calls resulting from GSS_S_CONTINUE_NEEDED
+   status returns; different protocol sequences modeled by the
+   GSS_S_CONTINUE_NEEDED facility will require access to credentials at
+   different points in the context establishment sequence.
+
+   The caller-provided input_context_handle argument is to be 0
+   (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first
+   GSS_Init_sec_context()  call relating to a given context. If
+   successful (i.e., if accompanied by major_status GSS_S_COMPLETE or
+
+
+
+Linn                        Standards Track                    [Page 45]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   GSS_S_CONTINUE_NEEDED), and only if successful, the initial
+   GSS_Init_sec_context() call returns a non-zero output_context_handle
+   for use in future references to this context.  Once a non-zero
+   output_context_handle has been returned, GSS-API callers should call
+   GSS_Delete_sec_context() to release context-related resources if
+   errors occur in later phases of context establishment, or when an
+   established context is no longer required. If GSS_Init_sec_context()
+   is passed the handle of a context which is already fully established,
+   GSS_S_FAILURE status is returned.
+
+   When continuation attempts to GSS_Init_sec_context() are needed to
+   perform context establishment, the previously-returned non-zero
+   handle value is entered into the input_context_handle argument and
+   will be echoed in the returned output_context_handle argument. On
+   such continuation attempts (and only on continuation attempts) the
+   input_token value is used, to provide the token returned from the
+   context's target.
+
+   The chan_bindings argument is used by the caller to provide
+   information binding the security context to security-related
+   characteristics (e.g., addresses, cryptographic keys) of the
+   underlying communications channel. See Section 1.1.6 of this document
+   for more discussion of this argument's usage.
+
+   The input_token argument contains a message received from the target,
+   and is significant only on a call to GSS_Init_sec_context() which
+   follows a previous return indicating GSS_S_CONTINUE_NEEDED
+   major_status.
+
+   It is the caller's responsibility to establish a communications path
+   to the target, and to transmit any returned output_token (independent
+   of the accompanying returned major_status value) to the target over
+   that path. The output_token can, however, be transmitted along with
+   the first application-provided input message to be processed by
+   GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-
+   established context. (Note: when the GSS-V2 prot_ready_state
+   indicator is returned TRUE, it can be possible to transfer a
+   protected message before context establishment is complete:  see also
+   Section 1.2.7)
+
+   The initiator may request various context-level functions through
+   input flags: the deleg_req_flag requests delegation of access rights,
+   the mutual_req_flag requests mutual authentication, the
+   replay_det_req_flag requests that replay detection features be
+   applied to messages transferred on the established context, and the
+   sequence_req_flag requests that sequencing be enforced. (See Section
+
+
+
+
+
+Linn                        Standards Track                    [Page 46]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   1.2.3 for more information on replay detection and sequencing
+   features.)  The anon_req_flag requests that the initiator's identity
+   not be transferred within tokens to be sent to the acceptor.
+
+   The conf_req_flag and integ_req_flag provide informatory inputs to
+   the GSS-API implementation as to whether, respectively, per-message
+   confidentiality and per-message integrity services will be required
+   on the context.  This information is important as an input to
+   negotiating mechanisms.  It is important to recognize, however, that
+   the inclusion of these flags (which are newly defined for GSS-V2)
+   introduces a backward incompatibility with callers implemented to
+   GSS-V1, where the flags were not defined.  Since no GSS-V1 callers
+   would set these flags, even if per-message services are desired,
+   GSS-V2 mechanism implementations which enable such services
+   selectively based on the flags' values may fail to provide them to
+   contexts established for GSS-V1 callers.  It may be appropriate under
+   certain circumstances, therefore, for such mechanism implementations
+   to infer these service request flags to be set if a caller is known
+   to be implemented to GSS-V1.
+
+   Not all of the optionally-requestable features will be available in
+   all underlying mech_types. The corresponding return state values
+   deleg_state, mutual_state, replay_det_state, and sequence_state
+   indicate, as a function of mech_type processing capabilities and
+   initiator-provided input flags, the set of features which will be
+   active on the context.  The returned trans_state value indicates
+   whether the context is transferable to other processes through use of
+   GSS_Export_sec_context().  These state indicators' values are
+   undefined unless either the routine's major_status indicates
+   GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with
+   GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is
+   possible that additional features, not confirmed or indicated along
+   with TRUE prot_ready_state, will be confirmed and indicated when
+   GSS_S_COMPLETE is subsequently returned.
+
+   The returned anon_state and prot_ready_state values are significant
+   for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status
+   returns from GSS_Init_sec_context(). When anon_state is returned
+   TRUE, this indicates that neither the current token nor its
+   predecessors delivers or has delivered the initiator's identity.
+   Callers wishing to perform context establishment only if anonymity
+   support is provided should transfer a returned token from
+   GSS_Init_sec_context() to the peer only if it is accompanied by a
+   TRUE anon_state indicator.  When prot_ready_state is returned TRUE in
+   conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates
+   that per-message protection operations may be applied on the context:
+   see Section 1.2.7 for further discussion of this facility.
+
+
+
+
+Linn                        Standards Track                    [Page 47]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Failure to provide the precise set of features requested by the
+   caller does not cause context establishment to fail; it is the
+   caller's prerogative to delete the context if the feature set
+   provided is unsuitable for the caller's use.
+
+   The returned mech_type value indicates the specific mechanism
+   employed on the context; it will never indicate the value for
+   "default".  A valid mech_type result must be returned along with a
+   GSS_S_COMPLETE status return; GSS-API implementations may (but are
+   not required to) also return mech_type along with predecessor calls
+   indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is
+   determinable) in conjunction with fatal error cases.  For the case of
+   mechanisms which themselves perform negotiation, the returned
+   mech_type result may indicate selection of a mechanism identified by
+   an OID different than that passed in the input mech_type argument,
+   and the returned value may change between successive calls returning
+   GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
+
+   The conf_avail return value indicates whether the context supports
+   per-message confidentiality services, and so informs the caller
+   whether or not a request for encryption through the conf_req_flag
+   input to GSS_Wrap() can be honored. In similar fashion, the
+   integ_avail return value indicates whether per-message integrity
+   services are available (through either GSS_GetMIC() or GSS_Wrap()) on
+   the established context. These state indicators' values are undefined
+   unless either the routine's major_status indicates GSS_S_COMPLETE, or
+   TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED
+   major_status.
+
+   The lifetime_req input specifies a desired upper bound for the
+   lifetime of the context to be established, with a value of 0 used to
+   request a default lifetime. The lifetime_rec return value indicates
+   the length of time for which the context will be valid, expressed as
+   an offset from the present; depending on mechanism capabilities,
+   credential lifetimes, and local policy, it may not correspond to the
+   value requested in lifetime_req.  If no constraints on context
+   lifetime are imposed, this may be indicated by returning a reserved
+   value representing INDEFINITE lifetime_req. The value of lifetime_rec
+   is undefined unless the routine's major_status indicates
+   GSS_S_COMPLETE.
+
+   If the mutual_state is TRUE, this fact will be reflected within the
+   output_token. A call to GSS_Accept_sec_context() at the target in
+   conjunction with such a context will return a token, to be processed
+   by a continuation call to GSS_Init_sec_context(), in order to achieve
+   mutual authentication.
+
+
+
+
+
+Linn                        Standards Track                    [Page 48]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+2.2.2:  GSS_Accept_sec_context call
+
+   Inputs:
+
+   o  acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies
+   -- "use default"
+
+   o  input_context_handle CONTEXT HANDLE, -- 0
+   -- (GSS_C_NO_CONTEXT) specifies "not yet assigned"
+
+   o  chan_bindings OCTET STRING,
+
+   o  input_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  src_name INTERNAL NAME, -- guaranteed to be MN
+   -- once returned, caller must release with GSS_Release_name()
+
+   o  mech_type OBJECT IDENTIFIER, -- caller should treat as
+   -- read-only; does not need to be released
+
+   o  output_context_handle CONTEXT HANDLE, -- once returned
+   -- non-NULL in context establishment sequence, caller
+   -- must release with GSS_Delete_sec_context()
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  anon_state BOOLEAN,
+
+   o  trans_state BOOLEAN,
+
+   o  prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+
+
+
+Linn                        Standards Track                    [Page 49]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  lifetime_rec INTEGER, -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   o  delegated_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL,
+   -- caller must release with GSS_Release_cred()
+
+   o  output_token OCTET STRING -- NULL or token to pass to context
+   -- initiator; if returned non-NULL, caller must release with
+   -- GSS_Release_buffer()
+
+   This call may block pending network interactions for those mech_types
+   in which a directory service or other network entity must be
+   consulted on behalf of a context acceptor in order to validate a
+   received input_token.
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that context-level data structures were
+   successfully initialized, and that per-message processing can now be
+   performed in conjunction with this context.
+
+   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
+   returned output_token must be sent to the initiator, and that a
+   response must be received and passed as the input_token argument to a
+   continuation call to GSS_Accept_sec_context(), before per-message
+   processing can be performed in conjunction with this context.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+   on the input_token failed, preventing further processing from being
+   performed based on that token.
+
+   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
+   performed on the credential structure referenced by
+   acceptor_cred_handle failed, preventing further processing from being
+   performed using that credential structure.
+
+   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received
+   input_token contains an incorrect integrity check, so context setup
+   cannot be accomplished.
+
+   o  GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the
+   received input_token was correct, but that the input_token was
+   recognized as a duplicate of an input_token already processed. No new
+   context is established.
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 50]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_OLD_TOKEN indicates that the integrity check on the received
+   input_token was correct, but that the input_token is too old to be
+   checked for duplication against previously-processed input_tokens. No
+   new context is established.
+
+   o  GSS_S_NO_CRED indicates that no context was established, either
+   because the input cred_handle was invalid, because the referenced
+   credentials are valid for context initiator use only, because the
+   caller lacks authorization to access the referenced credentials, or
+   because the procedure for default credential resolution failed.
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
+   through the input acceptor_cred_handle argument are no longer valid,
+   so context establishment cannot be completed.
+
+   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-
+   provided chan_bindings and those extracted from the input_token was
+   detected, signifying a security-relevant event and preventing context
+   establishment.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided; this major status will be
+   returned only for successor calls following GSS_S_CONTINUE_ NEEDED
+   status returns.
+
+   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
+   specifying a mechanism unsupported by the local system or with the
+   caller's active credentials.
+
+   o  GSS_S_FAILURE indicates that context setup could not be
+   accomplished for reasons unspecified at the GSS-API level, and that
+   no interface-defined recovery action is available.
+
+   The GSS_Accept_sec_context() routine is used by a context target.
+   Using information in the credentials structure referenced by the
+   input acceptor_cred_handle, it verifies the incoming input_token and
+   (following the successful completion of a context establishment
+   sequence) returns the authenticated src_name and the mech_type used.
+   The returned src_name is guaranteed to be an MN, processed by the
+   mechanism under which the context was established. The
+   acceptor_cred_handle must correspond to the same valid credentials
+   structure on the initial call to GSS_Accept_sec_context() and on any
+   successor calls resulting from GSS_S_CONTINUE_NEEDED status returns;
+   different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED
+   mechanism will require access to credentials at different points in
+   the context establishment sequence.
+
+
+
+
+
+Linn                        Standards Track                    [Page 51]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   The caller-provided input_context_handle argument is to be 0
+   (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first
+   GSS_Accept_sec_context() call relating to a given context. If
+   successful (i.e., if accompanied by major_status GSS_S_COMPLETE or
+   GSS_S_CONTINUE_NEEDED), and only if successful, the initial
+   GSS_Accept_sec_context() call returns a non-zero
+   output_context_handle for use in future references to this context.
+   Once a non-zero output_context_handle has been returned, GSS-API
+   callers should call GSS_Delete_sec_context() to release context-
+   related resources if errors occur in later phases of context
+   establishment, or when an established context is no longer required.
+   If GSS_Accept_sec_context() is passed the handle of a context which
+   is already fully established, GSS_S_FAILURE status is returned.
+
+   The chan_bindings argument is used by the caller to provide
+   information binding the security context to security-related
+   characteristics (e.g., addresses, cryptographic keys) of the
+   underlying communications channel. See Section 1.1.6 of this document
+   for more discussion of this argument's usage.
+
+   The returned state results (deleg_state, mutual_state,
+   replay_det_state, sequence_state, anon_state, trans_state, and
+   prot_ready_state) reflect the same information as described for
+   GSS_Init_sec_context(), and their values are significant under the
+   same return state conditions.
+
+   The conf_avail return value indicates whether the context supports
+   per-message confidentiality services, and so informs the caller
+   whether or not a request for encryption through the conf_req_flag
+   input to GSS_Wrap() can be honored. In similar fashion, the
+   integ_avail return value indicates whether per-message integrity
+   services are available (through either GSS_GetMIC()  or GSS_Wrap())
+   on the established context.  These values are significant under the
+   same return state conditions as described under
+   GSS_Init_sec_context().
+
+   The lifetime_rec return value is significant only in conjunction with
+   GSS_S_COMPLETE major_status, and indicates the length of time for
+   which the context will be valid, expressed as an offset from the
+   present.
+
+   The returned mech_type value indicates the specific mechanism
+   employed on the context; it will never indicate the value for
+   "default".  A valid mech_type result must be returned whenever
+   GSS_S_COMPLETE status is indicated; GSS-API implementations may (but
+   are not required to) also return mech_type along with predecessor
+   calls indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is
+   determinable) in conjunction with fatal error cases.  For the case of
+
+
+
+Linn                        Standards Track                    [Page 52]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   mechanisms which themselves perform negotiation, the returned
+   mech_type result may indicate selection of a mechanism identified by
+   an OID different than that passed in the input mech_type argument,
+   and the returned value may change between successive calls returning
+   GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
+
+   The delegated_cred_handle result is significant only when deleg_state
+   is TRUE, and provides a means for the target to reference the
+   delegated credentials. The output_token result, when non-NULL,
+   provides a context-level token to be returned to the context
+   initiator to continue a multi-step context establishment sequence. As
+   noted with GSS_Init_sec_context(), any returned token should be
+   transferred to the context's peer (in this case, the context
+   initiator), independent of the value of the accompanying returned
+   major_status.
+
+   Note: A target must be able to distinguish a context-level
+   input_token, which is passed to GSS_Accept_sec_context(), from the
+   per-message data elements passed to GSS_VerifyMIC()  or GSS_Unwrap().
+   These data elements may arrive in a single application message, and
+   GSS_Accept_sec_context() must be performed before per-message
+   processing can be performed successfully.
+
+2.2.3: GSS_Delete_sec_context call
+
+   Input:
+
+   o  context_handle CONTEXT HANDLE
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_context_token OCTET STRING
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the context was recognized, and that
+   relevant context-specific information was flushed.  If the caller
+   provides a non-null buffer to receive an output_context_token, and
+   the mechanism returns a non-NULL token into that buffer, the returned
+   output_context_token is ready for transfer to the context's peer.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided, so no deletion was performed.
+
+
+
+
+Linn                        Standards Track                    [Page 53]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but that
+   the GSS_Delete_sec_context() operation could not be performed for
+   reasons unspecified at the GSS-API level.
+
+   This call can be made by either peer in a security context, to flush
+   context-specific information. Once a non-zero output_context_handle
+   has been returned by context establishment calls, GSS-API callers
+   should call GSS_Delete_sec_context() to release context-related
+   resources if errors occur in later phases of context establishment,
+   or when an established context is no longer required.  This call may
+   block pending network interactions for mech_types in which active
+   notification must be made to a central server when a security context
+   is to be deleted.
+
+   If a non-null output_context_token parameter is provided by the
+   caller, an output_context_token may be returned to the caller.  If an
+   output_context_token is provided to the caller, it can be passed to
+   the context's peer to inform the peer's GSS-API implementation that
+   the peer's corresponding context information can also be flushed.
+   (Once a context is established, the peers involved are expected to
+   retain cached credential and context-related information until the
+   information's expiration time is reached or until a
+   GSS_Delete_sec_context() call is made.)
+
+   The facility for context_token usage to signal context deletion is
+   retained for compatibility with GSS-API Version 1.  For current
+   usage, it is recommended that both peers to a context invoke
+   GSS_Delete_sec_context() independently, passing a null
+   output_context_token buffer to indicate that no context_token is
+   required.  Implementations of GSS_Delete_sec_context() should delete
+   relevant locally-stored context information.
+
+   Attempts to perform per-message processing on a deleted context will
+   result in error returns.
+
+2.2.4:  GSS_Process_context_token call
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  input_context_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+Linn                        Standards Track                    [Page 54]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the input_context_token was
+   successfully processed in conjunction with the context referenced by
+   context_handle.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+   on the received context_token failed, preventing further processing
+   from being performed with that token.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but that
+   the GSS_Process_context_token() operation could not be performed for
+   reasons unspecified at the GSS-API level.
+
+   This call is used to process context_tokens received from a peer once
+   a context has been established, with corresponding impact on
+   context-level state information. One use for this facility is
+   processing of the context_tokens generated by
+   GSS_Delete_sec_context(); GSS_Process_context_token() will not block
+   pending network interactions for that purpose. Another use is to
+   process tokens indicating remote-peer context establishment failures
+   after the point where the local GSS-API implementation has already
+   indicated GSS_S_COMPLETE status.
+
+2.2.5:  GSS_Context_time call
+
+   Input:
+
+   o  context_handle CONTEXT HANDLE,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  lifetime_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the referenced context is valid, and
+   will remain valid for the amount of time indicated in lifetime_rec.
+
+
+
+
+
+Linn                        Standards Track                    [Page 55]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that data items related to the
+   referenced context have expired.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level.
+
+   This call is used to determine the amount of time for which a
+   currently established context will remain valid.
+
+2.2.6: GSS_Inquire_context call
+
+   Input:
+
+   o  context_handle CONTEXT HANDLE,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  src_name INTERNAL NAME,  -- name of context initiator,
+   -- guaranteed to be MN;
+   -- caller must release with GSS_Release_name() if returned
+
+   o  targ_name INTERNAL NAME,  -- name of context target,
+   -- guaranteed to be MN;
+   -- caller must release with GSS_Release_name() if returned
+
+   o  lifetime_rec INTEGER -- in seconds, or reserved value for
+   -- INDEFINITE or EXPIRED
+
+   o  mech_type OBJECT IDENTIFIER, -- the mechanism supporting this
+   -- security context; caller should treat as read-only and not
+   -- attempt to release
+
+   o  deleg_state BOOLEAN,
+
+   o  mutual_state BOOLEAN,
+
+   o  replay_det_state BOOLEAN,
+
+   o  sequence_state BOOLEAN,
+
+   o  anon_state BOOLEAN,
+
+
+
+Linn                        Standards Track                    [Page 56]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  trans_state BOOLEAN,
+
+   o  prot_ready_state BOOLEAN,
+
+   o  conf_avail BOOLEAN,
+
+   o  integ_avail BOOLEAN,
+
+   o  locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
+
+   o  open BOOLEAN, -- TRUE if context fully established, FALSE
+   -- if partly established (in CONTINUE_NEEDED state)
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the referenced context is valid and
+   that deleg_state, mutual_state, replay_det_state, sequence_state,
+   anon_state, trans_state, prot_ready_state, conf_avail, integ_avail,
+   locally_initiated, and open return values describe the corresponding
+   characteristics of the context.  If open is TRUE, lifetime_rec is
+   also returned: if open is TRUE and the context peer's name is known,
+   src_name and targ_name are valid in addition to the values listed
+   above.  The mech_type value must be returned for contexts where open
+   is TRUE and may be returned for contexts where open is FALSE.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided. Return values other than
+   major_status and minor_status are undefined.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call is used to extract information describing characteristics
+   of a security context.  Note that GSS-API implementations are
+   expected to retain inquirable context data on a context until the
+   context is released by a caller, even after the context has expired,
+   although underlying cryptographic data elements may be deleted after
+   expiration in order to limit their exposure.
+
+2.2.7:   GSS_Wrap_size_limit call
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  conf_req_flag BOOLEAN,
+
+
+
+
+Linn                        Standards Track                    [Page 57]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  qop INTEGER,
+
+   o  output_size INTEGER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  max_input_size INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates a successful token size determination:
+   an input message with a length in octets equal to the returned
+   max_input_size value will, when passed to GSS_Wrap() for processing
+   on the context identified by the context_handle parameter with the
+   confidentiality request state as provided in conf_req_flag and with
+   the quality of protection specifier provided in the qop parameter,
+   yield an output token no larger than the value of the provided
+   output_size parameter.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
+   context_handle is recognized, but that the referenced context has
+   expired.  Return values other than major_status and minor_status are
+   undefined.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided. Return values other than
+   major_status and minor_status are undefined.
+
+   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
+   recognized or supported for the context.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call is used to determine the largest input datum which may be
+   passed to GSS_Wrap() without yielding an output token larger than a
+   caller-specified value.
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 58]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+2.2.8:   GSS_Export_sec_context call
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  interprocess_token OCTET STRING  -- caller must release
+   -- with GSS_Release_buffer()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the referenced context has been
+   successfully exported to a representation in the interprocess_token,
+   and is no longer available for use by the caller.
+
+   o  GSS_S_UNAVAILABLE indicates that the context export facility is
+   not available for use on the referenced context.  (This status should
+   occur only for contexts for which the trans_state value is FALSE.)
+   Return values other than major_status and minor_status are undefined.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
+   context_handle is recognized, but that the referenced context has
+   expired.  Return values other than major_status and minor_status are
+   undefined.
+
+   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
+   for the input context_handle provided. Return values other than
+   major_status and minor_status are undefined.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call generates an interprocess token for transfer to another
+   process within an end system, in order to transfer control of a
+   security context to that process.  The recipient of the interprocess
+   token will call GSS_Import_sec_context() to accept the transfer.  The
+   GSS_Export_sec_context() operation is defined for use only with
+   security contexts which are fully and successfully established (i.e.,
+   those for which GSS_Init_sec_context() and GSS_Accept_sec_context()
+   have returned GSS_S_COMPLETE major_status).
+
+
+
+
+Linn                        Standards Track                    [Page 59]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   A successful GSS_Export_sec_context() operation deactivates the
+   security context for the calling process; for this case, the GSS-API
+   implementation shall deallocate all process-wide resources associated
+   with the security context and shall set the context_handle to
+   GSS_C_NO_CONTEXT.  In the event of an error that makes it impossible
+   to complete export of the security context, the GSS-API
+   implementation must not return an interprocess token and should
+   strive to leave the security context referenced by the context_handle
+   untouched.  If this is impossible, it is permissible for the
+   implementation to delete the security context, provided that it also
+   sets the context_handle parameter to GSS_C_NO_CONTEXT.
+
+   Portable callers must not assume that a given interprocess token can
+   be imported by GSS_Import_sec_context() more than once, thereby
+   creating multiple instantiations of a single context.  GSS-API
+   implementations may detect and reject attempted multiple imports, but
+   are not required to do so.
+
+   The internal representation contained within the interprocess token
+   is an implementation-defined local matter.  Interprocess tokens
+   cannot be assumed to be transferable across different GSS-API
+   implementations.
+
+   It is recommended that GSS-API implementations adopt policies suited
+   to their operational environments in order to define the set of
+   processes eligible to import a context, but specific constraints in
+   this area are local matters.  Candidate examples include transfers
+   between processes operating on behalf of the same user identity, or
+   processes comprising a common job.  However, it may be impossible to
+   enforce such policies in some implementations.
+
+   In support of the above goals, implementations may protect the
+   transferred context data by using cryptography to protect data within
+   the interprocess token, or by using interprocess tokens as a means to
+   reference local interprocess communication facilities (protected by
+   other means) rather than storing the context data directly within the
+   tokens.
+
+   Transfer of an open context may, for certain mechanisms and
+   implementations, reveal data about the credential which was used to
+   establish the context.  Callers should, therefore, be cautious about
+   the trustworthiness of processes to which they transfer contexts.
+   Although the GSS-API implementation may provide its own set of
+   protections over the exported context, the caller is responsible for
+   protecting the interprocess token from disclosure, and for taking
+   care that the context is transferred to an appropriate destination
+   process.
+
+
+
+
+Linn                        Standards Track                    [Page 60]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+2.2.9:   GSS_Import_sec_context call
+
+   Inputs:
+
+   o  interprocess_token OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  context_handle CONTEXT HANDLE  -- if successfully returned,
+   -- caller must release with GSS_Delete_sec_context()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the context represented by the input
+   interprocess_token has been successfully transferred to the caller,
+   and is available for future use via the output context_handle.
+
+   o  GSS_S_NO_CONTEXT indicates that the context represented by the
+   input interprocess_token was invalid. Return values other than
+   major_status and minor_status are undefined.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token
+   was defective.  Return values other than major_status and
+   minor_status are undefined.
+
+   o  GSS_S_UNAVAILABLE indicates that the context import facility is
+   not available for use on the referenced context.  Return values other
+   than major_status and minor_status are undefined.
+
+   o  GSS_S_UNAUTHORIZED indicates that the context represented by the
+   input interprocess_token is unauthorized for transfer to the caller.
+   Return values other than major_status and minor_status are undefined.
+
+   o  GSS_S_FAILURE indicates that the requested operation failed for
+   reasons unspecified at the GSS-API level. Return values other than
+   major_status and minor_status are undefined.
+
+   This call processes an interprocess token generated by
+   GSS_Export_sec_context(), making the transferred context available
+   for use by the caller.  After a successful GSS_Import_sec_context()
+   operation, the imported context is available for use by the importing
+   process. In particular, the imported context is usable for all per-
+   message operations and may be deleted or exported by its importer.
+   The inability to receive delegated credentials through
+
+
+
+Linn                        Standards Track                    [Page 61]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   gss_import_sec_context() precludes establishment of new contexts
+   based on information delegated to the importer's end system within
+   the context which is being imported, unless those delegated
+   credentials are obtained through separate routines (e.g., XGSS-API
+   calls) outside the GSS-V2 definition.
+
+   For further discussion of the security and authorization issues
+   regarding this call, please see the discussion in Section 2.2.8.
+
+2.3:  Per-message calls
+
+   This group of calls is used to perform per-message protection
+   processing on an established security context. None of these calls
+   block pending network interactions. These calls may be invoked by a
+   context's initiator or by the context's target.  The four members of
+   this group should be considered as two pairs; the output from
+   GSS_GetMIC() is properly input to GSS_VerifyMIC(), and the output
+   from GSS_Wrap() is properly input to GSS_Unwrap().
+
+   GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication
+   and data integrity services. When GSS_GetMIC() is invoked on an input
+   message, it yields a per-message token containing data items which
+   allow underlying mechanisms to provide the specified security
+   services. The original message, along with the generated per-message
+   token, is passed to the remote peer; these two data elements are
+   processed by GSS_VerifyMIC(), which validates the message in
+   conjunction with the separate token.
+
+   GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality
+   in addition to the data origin authentication and data integrity
+   services offered by GSS_GetMIC() and GSS_VerifyMIC(). GSS_Wrap()
+   outputs a single data element, encapsulating optionally enciphered
+   user data as well as associated token data items.  The data element
+   output from GSS_Wrap() is passed to the remote peer and processed by
+   GSS_Unwrap() at that system. GSS_Unwrap() combines decipherment (as
+   required) with validation of data items related to authentication and
+   integrity.
+
+   Although zero-length tokens are never returned by GSS calls for
+   transfer to a context's peer, a zero-length object may be passed by a
+   caller into GSS_Wrap(), in which case the corresponding peer calling
+   GSS_Unwrap() on the transferred token will receive a zero-length
+   object as output from GSS_Unwrap().  Similarly, GSS_GetMIC() can be
+   called on an empty object, yielding a MIC which GSS_VerifyMIC() will
+   successfully verify against the active security context in
+   conjunction with a zero-length object.
+
+
+
+
+
+Linn                        Standards Track                    [Page 62]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+2.3.1:  GSS_GetMIC call
+
+   Note: This call is functionally equivalent to the GSS_Sign call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Sign are deprecated.
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  qop_req INTEGER, -- 0 specifies default QOP
+
+   o  message OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  per_msg_token OCTET STRING  -- caller must release
+   -- with GSS_Release_buffer()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that an integrity check, suitable for an
+   established security context, was successfully applied and that the
+   message and corresponding per_msg_token are ready for transmission.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
+   have expired, so that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
+   input context_handle provided.
+
+   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
+   recognized or supported for the context.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but that
+   the requested operation could not be performed for reasons
+   unspecified at the GSS-API level.
+
+   Using the security context referenced by context_handle, apply an
+   integrity check to the input message (along with timestamps and/or
+   other data included in support of mech_type-specific mechanisms) and
+   (if GSS_S_COMPLETE status is indicated) return the result in
+
+
+
+Linn                        Standards Track                    [Page 63]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   per_msg_token. The qop_req parameter, interpretation of which is
+   discussed in Section 1.2.4, allows quality-of-protection control. The
+   caller passes the message and the per_msg_token to the target.
+
+   The GSS_GetMIC() function completes before the message and
+   per_msg_token is sent to the peer; successful application of
+   GSS_GetMIC() does not guarantee that a corresponding GSS_VerifyMIC()
+   has been (or can necessarily be) performed successfully when the
+   message arrives at the destination.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.3.2:  GSS_VerifyMIC call
+
+   Note: This call is functionally equivalent to the GSS_Verify call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Verify are deprecated.
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  message OCTET STRING,
+
+   o  per_msg_token OCTET STRING
+
+   Outputs:
+
+   o  qop_state INTEGER,
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the message was successfully
+   verified.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+   on the received per_msg_token failed, preventing further processing
+   from being performed with that token.
+
+   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received
+   per_msg_token contains an incorrect integrity check for the message.
+
+
+
+Linn                        Standards Track                    [Page 64]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and
+   GSS_S_GAP_TOKEN values appear in conjunction with the optional per-
+   message replay detection features described in Section 1.2.3; their
+   semantics are described in that section.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
+   have expired, so that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
+   input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but that
+   the GSS_VerifyMIC() operation could not be performed for reasons
+   unspecified at the GSS-API level.
+
+   Using the security context referenced by context_handle, verify that
+   the input per_msg_token contains an appropriate integrity check for
+   the input message, and apply any active replay detection or
+   sequencing features. Returns an indication of the quality-of-
+   protection applied to the processed message in the qop_state result.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.3.3: GSS_Wrap call
+
+   Note: This call is functionally equivalent to the GSS_Seal call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Seal are deprecated.
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  conf_req_flag BOOLEAN,
+
+   o  qop_req INTEGER, -- 0 specifies default QOP
+
+   o  input_message OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 65]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  conf_state BOOLEAN,
+
+   o  output_message OCTET STRING  -- caller must release with
+   -- GSS_Release_buffer()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the input_message was successfully
+   processed and that the output_message is ready for transmission.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
+   have expired, so that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
+   input context_handle provided.
+
+   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
+   recognized or supported for the context.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but that
+   the GSS_Wrap() operation could not be performed for reasons
+   unspecified at the GSS-API level.
+
+   Performs the data origin authentication and data integrity functions
+   of GSS_GetMIC().  If the input conf_req_flag is TRUE, requests that
+   confidentiality be applied to the input_message.  Confidentiality may
+   not be supported in all mech_types or by all implementations; the
+   returned conf_state flag indicates whether confidentiality was
+   provided for the input_message. The qop_req parameter, interpretation
+   of which is discussed in Section 1.2.4, allows quality-of-protection
+   control.
+
+   When GSS_S_COMPLETE status is returned, the GSS_Wrap() call yields a
+   single output_message data element containing (optionally enciphered)
+   user data as well as control information.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.3.4: GSS_Unwrap call
+
+   Note: This call is functionally equivalent to the GSS_Unseal call as
+   defined in previous versions of this specification. In the interests
+   of backward compatibility, it is recommended that implementations
+   support this function under both names for the present; future
+   references to this function as GSS_Unseal are deprecated.
+
+
+
+
+
+Linn                        Standards Track                    [Page 66]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Inputs:
+
+   o  context_handle CONTEXT HANDLE,
+
+   o  input_message OCTET STRING
+
+   Outputs:
+
+   o  conf_state BOOLEAN,
+
+   o  qop_state INTEGER,
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_message OCTET STRING  -- caller must release with
+   -- GSS_Release_buffer()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the input_message was successfully
+   processed and that the resulting output_message is available.
+
+   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
+   on the per_msg_token extracted from the input_message failed,
+   preventing further processing from being performed.
+
+   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that an incorrect
+   integrity check was detected for the message.
+
+   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and
+   GSS_S_GAP_TOKEN values appear in conjunction with the optional per-
+   message replay detection features described in Section 1.2.3; their
+   semantics are described in that section.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
+   have expired, so that the requested operation cannot be performed.
+
+   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
+   input context_handle provided.
+
+   o  GSS_S_FAILURE indicates that the context is recognized, but that
+   the GSS_Unwrap() operation could not be performed for reasons
+   unspecified at the GSS-API level.
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 67]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Processes a data element generated (and optionally enciphered) by
+   GSS_Wrap(), provided as input_message. The returned conf_state value
+   indicates whether confidentiality was applied to the input_message.
+   If conf_state is TRUE, GSS_Unwrap() has deciphered the input_message.
+   Returns an indication of the quality-of-protection applied to the
+   processed message in the qop_state result. GSS_Unwrap() performs the
+   data integrity and data origin authentication checking functions of
+   GSS_VerifyMIC() on the plaintext data. Plaintext data is returned in
+   output_message.
+
+   Mechanisms which do not support per-message protection services
+   should return GSS_S_FAILURE if this routine is called.
+
+2.4:  Support calls
+
+   This group of calls provides support functions useful to GSS-API
+   callers, independent of the state of established contexts. Their
+   characterization with regard to blocking or non-blocking status in
+   terms of network interactions is unspecified.
+
+2.4.1:  GSS_Display_status call
+
+   Inputs:
+
+   o  status_value INTEGER, -- GSS-API major_status or minor_status
+   -- return value
+
+   o  status_type INTEGER, -- 1 if major_status, 2 if minor_status
+
+   o  mech_type OBJECT IDENTIFIER -- mech_type to be used for
+   -- minor_status translation
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  status_string_set SET OF OCTET STRING  -- required calls for
+   -- release by caller are specific to language bindings
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a valid printable status
+   representation (possibly representing more than one status event
+   encoded within the status_value) is available in the returned
+   status_string_set.
+
+
+
+
+Linn                        Standards Track                    [Page 68]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_BAD_MECH indicates that translation in accordance with an
+   unsupported mech_type was requested, so translation could not be
+   performed.
+
+   o  GSS_S_BAD_STATUS indicates that the input status_value was
+   invalid, or that the input status_type carried a value other than 1
+   or 2, so translation could not be performed.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Provides a means for callers to translate GSS-API-returned major and
+   minor status codes into printable string representations.  Note: some
+   language bindings may employ an iterative approach in order to emit
+   successive status components; this approach is acceptable but not
+   required for conformance with the current specification.
+
+   Although not contemplated in [RFC-2078], it has been observed that
+   some existing GSS-API implementations return GSS_S_CONTINUE_NEEDED
+   status when iterating through successive messages returned from
+   GSS_Display_status(). This behavior is deprecated;
+   GSS_S_CONTINUE_NEEDED should be returned only by
+   GSS_Init_sec_context() and GSS_Accept_sec_context().  For maximal
+   portability, however, it is recommended that defensive callers be
+   able to accept and ignore GSS_S_CONTINUE_NEEDED status if indicated
+   by GSS_Display_status() or any other call other than
+   GSS_Init_sec_context() or GSS_Accept_sec_context().
+
+2.4.2:  GSS_Indicate_mechs call
+
+   Input:
+
+   o  (none)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  mech_set SET OF OBJECT IDENTIFIER  -- caller must release
+   -- with GSS_Release_oid_set()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a set of available mechanisms has
+   been returned in mech_set.
+
+
+
+
+Linn                        Standards Track                    [Page 69]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of mechanism types available on
+   the local system. This call is intended for support of specialized
+   callers who need to request non-default mech_type sets from GSS-API
+   calls which accept input mechanism type specifiers.
+
+2.4.3:  GSS_Compare_name call
+
+   Inputs:
+
+   o  name1 INTERNAL NAME,
+
+   o  name2 INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_equal BOOLEAN
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that name1 and name2 were comparable, and
+   that the name_equal result indicates whether name1 and name2
+   represent the same entity.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the two input names' types are
+   different and incomparable, so that the comparison operation could
+   not be completed.
+
+   o  GSS_S_BAD_NAME indicates that one or both of the input names was
+   ill-formed in terms of its internal type specifier, so the comparison
+   operation could not be completed.
+
+   o  GSS_S_FAILURE indicates that the call's operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to compare two internal name representations to
+   determine whether they refer to the same entity.  If either name
+   presented to GSS_Compare_name() denotes an anonymous principal,
+   GSS_Compare_name() shall indicate FALSE.  It is not required that
+   either or both inputs name1 and name2 be MNs; for some
+
+
+
+
+
+Linn                        Standards Track                    [Page 70]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   implementations and cases, GSS_S_BAD_NAMETYPE may be returned,
+   indicating name incomparability, for the case where neither input
+   name is an MN.
+
+2.4.4:  GSS_Display_name call
+
+   Inputs:
+
+   o  name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_string OCTET STRING, -- caller must release
+   -- with GSS_Release_buffer()
+
+   o  name_type OBJECT IDENTIFIER  -- caller should treat
+   -- as read-only; does not need to be released
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a valid printable name
+   representation is available in the returned name_string.
+
+   o  GSS_S_BAD_NAME indicates that the contents of the provided name
+   were inconsistent with the internally-indicated name type, so no
+   printable representation could be generated.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to translate an internal name representation into a
+   printable form with associated namespace type descriptor. The syntax
+   of the printable form is a local matter.
+
+   If the input name represents an anonymous identity, a reserved value
+   (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
+
+   The GSS_C_NO_OID name type is to be returned only when the
+   corresponding internal name was created through import with
+   GSS_C_NO_OID. It is acceptable for mechanisms to normalize names
+   imported with GSS_C_NO_OID into other supported types and, therefore,
+   to display them with types other than GSS_C_NO_OID.
+
+
+
+
+
+Linn                        Standards Track                    [Page 71]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+2.4.5:  GSS_Import_name call
+
+   Inputs:
+
+   o  input_name_string OCTET STRING,
+
+   o  input_name_type OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  output_name INTERNAL NAME  -- caller must release with
+   -- GSS_Release_name()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a valid name representation is
+   output in output_name and described by the type value in
+   output_name_type.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input_name_type is
+   unsupported by the applicable underlying GSS-API mechanism(s), so the
+   import operation could not be completed.
+
+   o  GSS_S_BAD_NAME indicates that the provided input_name_string is
+   ill-formed in terms of the input_name_type, so the import operation
+   could not be completed.
+
+   o  GSS_S_BAD_MECH indicates that the input presented for import was
+   an exported name object and that its enclosed mechanism type was not
+   recognized or was unsupported by the GSS-API implementation.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to provide a name representation as a contiguous octet
+   string, designate the type of namespace in conjunction with which it
+   should be parsed, and convert that representation to an internal form
+   suitable for input to other GSS-API routines.  The syntax of the
+   input_name_string is defined in conjunction with its associated name
+   type; depending on the input_name_type, the associated
+   input_name_string may or may not be a printable string.  If the
+   input_name_type's value is GSS_C_NO_OID, a mechanism-specific default
+   printable syntax (which shall be specified in the corresponding GSS-
+   V2 mechanism specification) is assumed for the input_name_string;
+
+
+
+Linn                        Standards Track                    [Page 72]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   other input_name_type values as registered by GSS-API implementations
+   can be used to indicate specific non-default name syntaxes. Note: The
+   input_name_type argument serves to describe and qualify the
+   interpretation of the associated input_name_string; it does not
+   specify the data type of the returned output_name.
+
+   If a mechanism claims support for a particular name type, its
+   GSS_Import_name() operation shall be able to accept all possible
+   values conformant to the external name syntax as defined for that
+   name type.  These imported values may correspond to:
+
+      (1) locally registered entities (for which credentials may be
+      acquired),
+
+      (2) non-local entities (for which local credentials cannot be
+      acquired, but which may be referenced as targets of initiated
+      security contexts or initiators of accepted security contexts), or
+      to
+
+      (3) neither of the above.
+
+   Determination of whether a particular name belongs to class (1), (2),
+   or (3) as described above is not guaranteed to be performed by the
+   GSS_Import_name() function.
+
+   The internal name generated by a GSS_Import_name() operation may be a
+   single-mechanism MN, and is likely to be an MN within a single-
+   mechanism implementation, but portable callers must not depend on
+   this property (and must not, therefore, assume that the output from
+   GSS_Import_name() can be passed directly to GSS_Export_name() without
+   first being processed through GSS_Canonicalize_name()).
+
+2.4.6: GSS_Release_name call
+
+   Inputs:
+
+   o  name INTERNAL NAME
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the storage associated with the
+   input name was successfully released.
+
+
+
+Linn                        Standards Track                    [Page 73]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  GSS_S_BAD_NAME indicates that the input name argument did not
+   contain a valid name.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an internal
+   name representation.  This call's specific behavior depends on the
+   language and programming environment within which a GSS-API
+   implementation operates, and is therefore detailed within applicable
+   bindings specifications; in particular, implementation and invocation
+   of this call may be superfluous (and may be omitted) within bindings
+   where memory management is automatic.
+
+2.4.7: GSS_Release_buffer call
+
+   Inputs:
+
+   o  buffer OCTET STRING
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the storage associated with the
+   input buffer was successfully released.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an OCTET STRING
+   buffer allocated by another GSS-API call.  This call's specific
+   behavior depends on the language and programming environment within
+   which a GSS-API implementation operates, and is therefore detailed
+   within applicable bindings specifications; in particular,
+   implementation and invocation of this call may be superfluous (and
+   may be omitted) within bindings where memory management is automatic.
+
+2.4.8: GSS_Release_OID_set call
+
+   Inputs:
+
+   o  buffer SET OF OBJECT IDENTIFIER
+
+
+
+
+Linn                        Standards Track                    [Page 74]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the storage associated with the
+   input object identifier set was successfully released.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to release the storage associated with an object
+   identifier set object allocated by another GSS-API call.  This call's
+   specific behavior depends on the language and programming environment
+   within which a GSS-API implementation operates, and is therefore
+   detailed within applicable bindings specifications; in particular,
+   implementation and invocation of this call may be superfluous (and
+   may be omitted) within bindings where memory management is automatic.
+
+2.4.9: GSS_Create_empty_OID_set call
+
+   Inputs:
+
+   o  (none)
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  oid_set SET OF OBJECT IDENTIFIER  -- caller must release
+   -- with GSS_Release_oid_set()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   Creates an object identifier set containing no object identifiers, to
+   which members may be subsequently added using the
+   GSS_Add_OID_set_member() routine.  These routines are intended to be
+   used to construct sets of mechanism object identifiers, for input to
+   GSS_Acquire_cred().
+
+
+
+Linn                        Standards Track                    [Page 75]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+2.4.10: GSS_Add_OID_set_member call
+
+   Inputs:
+
+   o  member_oid OBJECT IDENTIFIER,
+
+   o  oid_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+   Adds an Object Identifier to an Object Identifier set.  This routine
+   is intended for use in conjunction with GSS_Create_empty_OID_set()
+   when constructing a set of mechanism OIDs for input to
+   GSS_Acquire_cred().
+
+2.4.11: GSS_Test_OID_set_member call
+
+   Inputs:
+
+   o  member OBJECT IDENTIFIER,
+
+   o  set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  present BOOLEAN
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates successful completion
+
+   o  GSS_S_FAILURE indicates that the operation failed
+
+
+
+
+
+Linn                        Standards Track                    [Page 76]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Interrogates an Object Identifier set to determine whether a
+   specified Object Identifier is a member.  This routine is intended to
+   be used with OID sets returned by GSS_Indicate_mechs(),
+   GSS_Acquire_cred(), and GSS_Inquire_cred().
+
+2.4.12:  GSS_Inquire_names_for_mech call
+
+   Input:
+
+   o  input_mech_type OBJECT IDENTIFIER, -- mechanism type
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  name_type_set SET OF OBJECT IDENTIFIER -- caller must release
+   -- with GSS_Release_oid_set()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the output name_type_set contains a
+   list of name types which are supported by the locally available
+   mechanism identified by input_mech_type.
+
+   o  GSS_S_BAD_MECH indicates that the mechanism identified by
+   input_mech_type was unsupported within the local implementation,
+   causing the query to fail.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   Allows callers to determine the set of name types which are
+   supportable by a specific locally-available mechanism.
+
+2.4.13: GSS_Inquire_mechs_for_name call
+
+   Inputs:
+
+   o  input_name INTERNAL NAME,
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+
+Linn                        Standards Track                    [Page 77]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  mech_types SET OF OBJECT IDENTIFIER  -- caller must release
+   -- with GSS_Release_oid_set()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a set of object identifiers,
+   corresponding to the set of mechanisms suitable for processing the
+   input_name, is available in mech_types.
+
+   o  GSS_S_BAD_NAME indicates that the input_name was ill-formed and
+   could not be processed.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input_name parameter
+   contained an invalid name type or a name type unsupported by the
+   GSS-API implementation.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   This routine returns the mechanism set with which the input_name may
+   be processed.
+
+   Each mechanism returned will recognize at least one element within
+   the name. It is permissible for this routine to be implemented within
+   a mechanism-independent GSS-API layer, using the type information
+   contained within the presented name, and based on registration
+   information provided by individual mechanism implementations.  This
+   means that the returned mech_types result may indicate that a
+   particular mechanism will understand a particular name when in fact
+   it would refuse to accept that name as input to
+   GSS_Canonicalize_name(), GSS_Init_sec_context(), GSS_Acquire_cred(),
+   or GSS_Add_cred(), due to some property of the particular name rather
+   than a property of the name type.  Thus, this routine should be used
+   only as a pre-filter for a call to a subsequent mechanism-specific
+   routine.
+
+2.4.14: GSS_Canonicalize_name call
+
+   Inputs:
+
+   o  input_name INTERNAL NAME,
+
+   o  mech_type OBJECT IDENTIFIER  -- must be explicit mechanism,
+   -- not "default" specifier or identifier of negotiating mechanism
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+
+
+Linn                        Standards Track                    [Page 78]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  minor_status INTEGER,
+
+   o  output_name INTERNAL NAME  -- caller must release with
+   -- GSS_Release_name()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a mechanism-specific reduction of
+   the input_name, as processed by the mechanism identified by
+   mech_type, is available in output_name.
+
+   o  GSS_S_BAD_MECH indicates that the identified mechanism is
+   unsupported for this operation; this may correspond either to a
+   mechanism wholly unsupported by the local GSS-API implementation or
+   to a negotiating mechanism with which the canonicalization operation
+   cannot be performed.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input name does not contain
+   an element with suitable type for processing by the identified
+   mechanism.
+
+   o  GSS_S_BAD_NAME indicates that the input name contains an element
+   with suitable type for processing by the identified mechanism, but
+   that this element could not be processed successfully.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   This routine reduces a GSS-API internal name input_name, which may in
+   general contain elements corresponding to multiple mechanisms, to a
+   mechanism-specific Mechanism Name (MN) output_name by applying the
+   translations corresponding to the mechanism identified by mech_type.
+   The contents of input_name are unaffected by the
+   GSS_Canonicalize_name() operation.  References to output_name will
+   remain valid until output_name is released, independent of whether or
+   not input_name is subsequently released.
+
+2.4.15: GSS_Export_name call
+
+   Inputs:
+
+   o  input_name INTERNAL NAME, -- required to be MN
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+
+
+Linn                        Standards Track                    [Page 79]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   o  output_name OCTET STRING  -- caller must release
+   -- with GSS_Release_buffer()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that a flat representation of the input
+   name is available in output_name.
+
+   o  GSS_S_NAME_NOT_MN indicates that the input name contained elements
+   corresponding to multiple mechanisms, so cannot be exported into a
+   single-mechanism flat form.
+
+   o  GSS_S_BAD_NAME indicates that the input name was an MN, but could
+   not be processed.
+
+   o  GSS_S_BAD_NAMETYPE indicates that the input name was an MN, but
+   that its type is unsupported by the GSS-API implementation.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   This routine creates a flat name representation, suitable for
+   bytewise comparison or for input to GSS_Import_name() in conjunction
+   with the reserved GSS-API Exported Name Object OID, from a internal-
+   form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name()
+   or GSS_Accept_sec_context().
+
+   The emitted GSS-API Exported Name Object is self-describing; no
+   associated parameter-level OID need be emitted by this call.  This
+   flat representation consists of a mechanism-independent wrapper
+   layer, defined in Section 3.2 of this document, enclosing a
+   mechanism-defined name representation.
+
+   In all cases, the flat name output by GSS_Export_name() to correspond
+   to a particular input MN must be invariant over time within a
+   particular installation.
+
+   The GSS_S_NAME_NOT_MN status code is provided to enable
+   implementations to reject input names which are not MNs.  It is not,
+   however, required for purposes of conformance to this specification
+   that all non-MN input names must necessarily be rejected.
+
+2.4.16: GSS_Duplicate_name call
+
+   Inputs:
+
+   o  src_name INTERNAL NAME
+
+
+
+
+Linn                        Standards Track                    [Page 80]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  dest_name INTERNAL NAME  -- caller must release
+   -- with GSS_Release_name()
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that dest_name references an internal
+   name object containing the same name as passed to src_name.
+
+   o  GSS_S_BAD_NAME indicates that the input name was invalid.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+   performed for reasons unspecified at the GSS-API level.
+
+   This routine takes input internal name src_name, and returns another
+   reference (dest_name) to that name which can be used even if src_name
+   is later freed.  (Note: This may be implemented by copying or through
+   use of reference counts.)
+
+3: Data Structure Definitions for GSS-V2 Usage
+
+   Subsections of this section define, for interoperability and
+   portability purposes, certain data structures for use with GSS-V2.
+
+3.1: Mechanism-Independent Token Format
+
+   This section specifies a mechanism-independent level of encapsulating
+   representation for the initial token of a GSS-API context
+   establishment sequence, incorporating an identifier of the mechanism
+   type to be used on that context and enabling tokens to be interpreted
+   unambiguously at GSS-API peers. Use of this format is required for
+   initial context establishment tokens of Internet standards-track
+   GSS-API mechanisms; use in non-initial tokens is optional.
+
+   The encoding format for the token tag is derived from ASN.1 and DER
+   (per illustrative ASN.1 syntax included later within this
+   subsection), but its concrete representation is defined directly in
+   terms of octets rather than at the ASN.1 level in order to facilitate
+   interoperable implementation without use of general ASN.1 processing
+   code.  The token tag consists of the following elements, in order:
+
+      1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
+      -- constructed form, definite length encoding follows.
+
+
+
+Linn                        Standards Track                    [Page 81]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      2. Token length octets, specifying length of subsequent data
+      (i.e., the summed lengths of elements 3-5 in this list, and of the
+      mechanism-defined token object following the tag).  This element
+      comprises a variable number of octets:
+
+         2a. If the indicated value is less than 128, it shall be
+         represented in a single octet with bit 8 (high order) set to
+         "0" and the remaining bits representing the value.
+
+         2b. If the indicated value is 128 or more, it shall be
+         represented in two or more octets, with bit 8 of the first
+         octet set to "1" and the remaining bits of the first octet
+         specifying the number of additional octets.  The subsequent
+         octets carry the value, 8 bits per octet, most significant
+         digit first.  The minimum number of octets shall be used to
+         encode the length (i.e., no octets representing leading zeros
+         shall be included within the length encoding).
+
+      3. 0x06 -- Tag for OBJECT IDENTIFIER
+
+      4. Object identifier length -- length (number of octets) of
+      -- the encoded object identifier contained in element 5,
+      -- encoded per rules as described in 2a. and 2b. above.
+
+      5. Object identifier octets -- variable number of octets,
+      -- encoded per ASN.1 BER rules:
+
+         5a. The first octet contains the sum of two values: (1) the
+         top-level object identifier component, multiplied by 40
+         (decimal), and (2) the second-level object identifier
+         component.  This special case is the only point within an
+         object identifier encoding where a single octet represents
+         contents of more than one component.
+
+         5b. Subsequent octets, if required, encode successively-lower
+         components in the represented object identifier.  A component's
+         encoding may span multiple octets, encoding 7 bits per octet
+         (most significant bits first) and with bit 8 set to "1" on all
+         but the final octet in the component's encoding.  The minimum
+         number of octets shall be used to encode each component (i.e.,
+         no octets representing leading zeros shall be included within a
+         component's encoding).
+
+      (Note: In many implementations, elements 3-5 may be stored and
+      referenced as a contiguous string constant.)
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 82]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   The token tag is immediately followed by a mechanism-defined token
+   object.  Note that no independent size specifier intervenes following
+   the object identifier value to indicate the size of the mechanism-
+   defined token object.  While ASN.1 usage within mechanism-defined
+   tokens is permitted, there is no requirement that the mechanism-
+   specific innerContextToken, innerMsgToken, and sealedUserData data
+   elements must employ ASN.1 BER/DER encoding conventions.
+
+   The following ASN.1 syntax is included for descriptive purposes only,
+   to illustrate structural relationships among token and tag objects.
+   For interoperability purposes, token and tag encoding shall be
+   performed using the concrete encoding procedures described earlier in
+   this subsection.
+
+      GSS-API DEFINITIONS ::=
+
+      BEGIN
+
+      MechType ::= OBJECT IDENTIFIER
+      -- data structure definitions
+      -- callers must be able to distinguish among
+      -- InitialContextToken, SubsequentContextToken,
+      -- PerMsgToken, and SealedMessage data elements
+      -- based on the usage in which they occur
+
+      InitialContextToken ::=
+      -- option indication (delegation, etc.) indicated within
+      -- mechanism-specific token
+      [APPLICATION 0] IMPLICIT SEQUENCE {
+              thisMech MechType,
+              innerContextToken ANY DEFINED BY thisMech
+                 -- contents mechanism-specific
+                 -- ASN.1 structure not required
+              }
+
+      SubsequentContextToken ::= innerContextToken ANY
+      -- interpretation based on predecessor InitialContextToken
+      -- ASN.1 structure not required
+
+      PerMsgToken ::=
+      -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
+      -- ASN.1 structure not required
+              innerMsgToken ANY
+
+      SealedMessage ::=
+      -- as emitted by GSS_Wrap and processed by GSS_Unwrap
+      -- includes internal, mechanism-defined indicator
+      -- of whether or not encrypted
+
+
+
+Linn                        Standards Track                    [Page 83]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      -- ASN.1 structure not required
+              sealedUserData ANY
+
+      END
+
+3.2: Mechanism-Independent Exported Name Object Format
+
+   This section specifies a mechanism-independent level of encapsulating
+   representation for names exported via the GSS_Export_name() call,
+   including an object identifier representing the exporting mechanism.
+   The format of names encapsulated via this representation shall be
+   defined within individual mechanism drafts.  The Object Identifier
+   value to indicate names of this type is defined in Section 4.7 of
+   this document.
+
+   No name type OID is included in this mechanism-independent level of
+   format definition, since (depending on individual mechanism
+   specifications) the enclosed name may be implicitly typed or may be
+   explicitly typed using a means other than OID encoding.
+
+   The bytes within MECH_OID_LEN and NAME_LEN elements are represented
+   most significant byte first (equivalently, in IP network byte order).
+
+        Length    Name          Description
+
+        2               TOK_ID          Token Identifier
+                                        For exported name objects, this
+                                        must be hex 04 01.
+        2               MECH_OID_LEN    Length of the Mechanism OID
+        MECH_OID_LEN    MECH_OID        Mechanism OID, in DER
+        4               NAME_LEN        Length of name
+        NAME_LEN        NAME            Exported name; format defined in
+                                        applicable mechanism draft.
+
+   A concrete example of the contents of an exported name object,
+   derived from the Kerberos Version 5 mechanism, is as follows:
+
+   04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 hx xx xx xl pp qq ... zz
+
+   04 01        mandatory token identifier
+
+   00 0B        2-byte length of the immediately following DER-encoded
+                ASN.1 value of type OID, most significant octet first
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 84]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   06 09 2A 86 48 86 F7 12 01 02 02    DER-encoded ASN.1 value
+                                       of type OID; Kerberos V5
+                                       mechanism OID indicates
+                                       Kerberos V5 exported name
+
+          in Detail:      06                  Identifier octet (6=OID)
+                          09                           Length octet(s)
+                          2A 86 48 86 F7 12 01 02 02   Content octet(s)
+
+   hx xx xx xl   4-byte length of the immediately following exported
+                 name blob, most significant octet first
+
+   pp qq ... zz  exported name blob of specified length,
+                 bits and bytes specified in the
+                 (Kerberos 5) GSS-API v2 mechanism spec
+
+4: Name Type Definitions
+
+   This section includes definitions for name types and associated
+   syntaxes which are defined in a mechanism-independent fashion at the
+   GSS-API level rather than being defined in individual mechanism
+   specifications.
+
+4.1: Host-Based Service Name Form
+
+   This name form shall be represented by the Object Identifier:
+
+   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
+   "gssapi(2) generic(1) service_name(4)}.
+
+   The recommended symbolic name for this type is
+   "GSS_C_NT_HOSTBASED_SERVICE".
+
+   For reasons of compatibility with existing implementations, it is
+   recommended that this OID be used rather than the alternate value as
+   included in [RFC-2078]:
+
+   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
+   2(gss-host-based-services)}
+
+   While it is not recommended that this alternate value be emitted on
+   output by GSS implementations, it is recommended that it be accepted
+   on input as equivalent to the recommended value.
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 85]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   This name type is used to represent services associated with host
+   computers.  Support for this name form is recommended to mechanism
+   designers in the interests of portability, but is not mandated by
+   this specification. This name form is constructed using two elements,
+   "service" and "hostname", as follows:
+
+   service@hostname
+
+   When a reference to a name of this type is resolved, the "hostname"
+   may (as an example implementation strategy) be canonicalized by
+   attempting a DNS lookup and using the fully-qualified domain name
+   which is returned, or by using the "hostname" as provided if the DNS
+   lookup fails.  The canonicalization operation also maps the host's
+   name into lower-case characters.
+
+   The "hostname" element may be omitted. If no "@" separator is
+   included, the entire name is interpreted as the service specifier,
+   with the "hostname" defaulted to the canonicalized name of the local
+   host.
+
+   Documents specifying means for GSS integration into a particular
+   protocol should state either:
+
+      (a) that a specific IANA-registered name associated with that
+      protocol shall be used for the "service" element (this admits, if
+      needed, the possibility that a single name can be registered and
+      shared among a related set of protocols), or
+
+      (b) that the generic name "host" shall be used for the "service"
+      element, or
+
+      (c) that, for that protocol, fallback in specified order (a, then
+      b) or (b, then a) shall be applied.
+
+   IANA registration of specific names per (a) should be handled in
+   accordance with the "Specification Required" assignment policy,
+   defined by BCP 26, RFC 2434 as follows: "Values and their meaning
+   must be documented in an RFC or other available reference, in
+   sufficient detail so that interoperability between independent
+   implementations is possible."
+
+4.2: User Name Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) user_name(1)}. The recommended mechanism-independent
+   symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
+
+
+
+
+Linn                        Standards Track                    [Page 86]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   name form and OID is defined within the Kerberos V5 GSS-API
+   mechanism, but the symbolic name recommended there begins with a
+   "GSS_KRB5_NT_" prefix.)
+
+   This name type is used to indicate a named user on a local system.
+   Its syntax and interpretation may be OS-specific. This name form is
+   constructed as:
+
+   username
+
+4.3: Machine UID Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) machine_uid_name(2)}.  The recommended mechanism-
+   independent symbolic name for this type is
+   "GSS_C_NT_MACHINE_UID_NAME".  (Note: the same name form and OID is
+   defined within the Kerberos V5 GSS-API mechanism, but the symbolic
+   name recommended there begins with a "GSS_KRB5_NT_" prefix.)
+
+   This name type is used to indicate a numeric user identifier
+   corresponding to a user on a local system.  Its interpretation is
+   OS-specific.  The gss_buffer_desc representing a name of this type
+   should contain a locally-significant user ID, represented in host
+   byte order.  The GSS_Import_name() operation resolves this uid into a
+   username, which is then treated as the User Name Form.
+
+4.4: String UID Form
+
+   This name form shall be represented by the Object Identifier {iso(1)
+   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
+   generic(1) string_uid_name(3)}.  The recommended symbolic name for
+   this type is "GSS_C_NT_STRING_UID_NAME".  (Note: the same name form
+   and OID is defined within the Kerberos V5 GSS-API mechanism, but the
+   symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
+
+   This name type is used to indicate a string of digits representing
+   the numeric user identifier of a user on a local system.  Its
+   interpretation is OS-specific. This name type is similar to the
+   Machine UID Form, except that the buffer contains a string
+   representing the user ID.
+
+4.5: Anonymous Nametype
+
+   The following Object Identifier value is provided as a means to
+   identify anonymous names, and can be compared against in order to
+   determine, in a mechanism-independent fashion, whether a name refers
+   to an anonymous principal:
+
+
+
+Linn                        Standards Track                    [Page 87]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
+   3(gss-anonymous-name)}
+
+   The recommended symbolic name corresponding to this definition is
+   GSS_C_NT_ANONYMOUS.
+
+4.6: GSS_C_NO_OID
+
+   The recommended symbolic name GSS_C_NO_OID corresponds to a null
+   input value instead of an actual object identifier.  Where specified,
+   it indicates interpretation of an associated name based on a
+   mechanism-specific default printable syntax.
+
+4.7: Exported Name Object
+
+   Name objects of the Mechanism-Independent Exported Name Object type,
+   as defined in Section 3.2 of this document, will be identified with
+   the following Object Identifier:
+
+   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
+   4(gss-api-exported-name)}
+
+   The recommended symbolic name corresponding to this definition is
+   GSS_C_NT_EXPORT_NAME.
+
+4.8: GSS_C_NO_NAME
+
+   The recommended symbolic name GSS_C_NO_NAME indicates that no name is
+   being passed within a particular value of a parameter used for the
+   purpose of transferring names. Note: GSS_C_NO_NAME is not an actual
+   name type, and is not represented by an OID; its acceptability in
+   lieu of an actual name is confined to specific calls
+   (GSS_Acquire_cred(), GSS_Add_cred(), and GSS_Init_sec_context()) with
+   usages as identified within this specification.
+
+5:  Mechanism-Specific Example Scenarios
+
+   This section provides illustrative overviews of the use of various
+   candidate mechanism types to support the GSS-API. These discussions
+   are intended primarily for readers familiar with specific security
+   technologies, demonstrating how GSS-API functions can be used and
+   implemented by candidate underlying mechanisms. They should not be
+   regarded as constrictive to implementations or as defining the only
+   means through which GSS-API functions can be realized with a
+   particular underlying technology, and do not demonstrate all GSS-API
+   features with each technology.
+
+
+
+
+
+Linn                        Standards Track                    [Page 88]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+5.1: Kerberos V5, single-TGT
+
+   OS-specific login functions yield a TGT to the local realm Kerberos
+   server; TGT is placed in a credentials structure for the client.
+   Client calls GSS_Acquire_cred()  to acquire a cred_handle in order to
+   reference the credentials for use in establishing security contexts.
+
+   Client calls GSS_Init_sec_context().  If the requested service is
+   located in a different realm, GSS_Init_sec_context()  gets the
+   necessary TGT/key pairs needed to traverse the path from local to
+   target realm; these data are placed in the owner's TGT cache. After
+   any needed remote realm resolution, GSS_Init_sec_context() yields a
+   service ticket to the requested service with a corresponding session
+   key; these data are stored in conjunction with the context. GSS-API
+   code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
+   response(s) (in the successful case) or KRB_ERROR.
+
+   Assuming success, GSS_Init_sec_context()  builds a Kerberos-formatted
+   KRB_AP_REQ message, and returns it in output_token.  The client sends
+   the output_token to the service.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(),  which verifies the authenticator, provides
+   the service with the client's authenticated name, and returns an
+   output_context_handle.
+
+   Both parties now hold the session key associated with the service
+   ticket, and can use this key in subsequent GSS_GetMIC(),
+   GSS_VerifyMIC(),  GSS_Wrap(), and GSS_Unwrap() operations.
+
+5.2: Kerberos V5, double-TGT
+
+   TGT acquisition as above.
+
+   Note: To avoid unnecessary frequent invocations of error paths when
+   implementing the GSS-API atop Kerberos V5, it seems appropriate to
+   represent "single-TGT K-V5" and "double-TGT K-V5" with separate
+   mech_types, and this discussion makes that assumption.
+
+   Based on the (specified or defaulted) mech_type,
+   GSS_Init_sec_context()  determines that the double-TGT protocol
+   should be employed for the specified target. GSS_Init_sec_context()
+   returns GSS_S_CONTINUE_NEEDED major_status, and its returned
+   output_token contains a request to the service for the service's TGT.
+   (If a service TGT with suitably long remaining lifetime already
+   exists in a cache, it may be usable, obviating the need for this
+   step.) The client passes the output_token to the service.  Note: this
+   scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED
+
+
+
+Linn                        Standards Track                    [Page 89]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   status return facility than for support of mutual authentication;
+   note that both uses can coexist as successive operations within a
+   single context establishment operation.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(),  which recognizes it as a request for TGT.
+   (Note that current Kerberos V5 defines no intra-protocol mechanism to
+   represent such a request.) GSS_Accept_sec_context() returns
+   GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in
+   its output_token. The service sends the output_token to the client.
+
+   The client passes the received token as the input_token argument to a
+   continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
+   the received service TGT and uses it as part of a service ticket
+   request to the Kerberos authentication server, storing the returned
+   service ticket and session key in conjunction with the context.
+   GSS_Init_sec_context() builds a Kerberos-formatted authenticator, and
+   returns it in output_token along with GSS_S_COMPLETE return
+   major_status. The client sends the output_token to the service.
+
+   Service passes the received token as the input_token argument to a
+   continuation call to GSS_Accept_sec_context().
+   GSS_Accept_sec_context()  verifies the authenticator, provides the
+   service with the client's authenticated name, and returns
+   major_status GSS_S_COMPLETE.
+
+   GSS_GetMIC(),  GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap()  as
+   above.
+
+5.3:  X.509 Authentication Framework
+
+   This example illustrates use of the GSS-API in conjunction with
+   public-key mechanisms, consistent with the X.509 Directory
+   Authentication Framework.
+
+   The GSS_Acquire_cred() call establishes a credentials structure,
+   making the client's private key accessible for use on behalf of the
+   client.
+
+   The client calls GSS_Init_sec_context(), which interrogates the
+   Directory to acquire (and validate) a chain of public-key
+   certificates, thereby collecting the public key of the service.  The
+   certificate validation operation determines that suitable integrity
+   checks were applied by trusted authorities and that those
+   certificates have not expired. GSS_Init_sec_context() generates a
+   secret key for use in per-message protection operations on the
+   context, and enciphers that secret key under the service's public
+   key.
+
+
+
+Linn                        Standards Track                    [Page 90]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   The enciphered secret key, along with an authenticator quantity
+   signed with the client's private key, is included in the output_token
+   from GSS_Init_sec_context().  The output_token also carries a
+   certification path, consisting of a certificate chain leading from
+   the service to the client; a variant approach would defer this path
+   resolution to be performed by the service instead of being asserted
+   by the client. The client application sends the output_token to the
+   service.
+
+   The service passes the received token as the input_token argument to
+   GSS_Accept_sec_context(). GSS_Accept_sec_context() validates the
+   certification path, and as a result determines a certified binding
+   between the client's distinguished name and the client's public key.
+   Given that public key, GSS_Accept_sec_context() can process the
+   input_token's authenticator quantity and verify that the client's
+   private key was used to sign the input_token. At this point, the
+   client is authenticated to the service. The service uses its private
+   key to decipher the enciphered secret key provided to it for per-
+   message protection operations on the context.
+
+   The client calls GSS_GetMIC() or GSS_Wrap() on a data message, which
+   causes per-message authentication, integrity, and (optional)
+   confidentiality facilities to be applied to that message. The service
+   uses the context's shared secret key to perform corresponding
+   GSS_VerifyMIC()  and GSS_Unwrap() calls.
+
+6:  Security Considerations
+
+   This document specifies a service interface for security facilities
+   and services; as such, security considerations are considered
+   throughout the specification.  Nonetheless, it is appropriate to
+   summarize certain specific points relevant to GSS-API implementors
+   and calling applications.  Usage of the GSS-API interface does not in
+   itself provide security services or assurance; instead, these
+   attributes are dependent on the underlying mechanism(s) which support
+   a GSS-API implementation.  Callers must be attentive to the requests
+   made to GSS-API calls and to the status indicators returned by GSS-
+   API, as these specify the security service characteristics which
+   GSS-API will provide.  When the interprocess context transfer
+   facility is used, appropriate local controls should be applied to
+   constrain access to interprocess tokens and to the sensitive data
+   which they contain.
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 91]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+7:  Related Activities
+
+   In order to implement the GSS-API atop existing, emerging, and future
+   security mechanisms:
+
+      object identifiers must be assigned to candidate GSS-API
+      mechanisms and the name types which they support
+
+      concrete data element formats and processing procedures must be
+      defined for candidate mechanisms
+
+   Calling applications must implement formatting conventions which will
+   enable them to distinguish GSS-API tokens from other data carried in
+   their application protocols.
+
+   Concrete language bindings are required for the programming
+   environments in which the GSS-API is to be employed, as [RFC-1509]
+   defines for the C programming language and GSS-V1.  C Language
+   bindings for GSS-V2 are defined in [RFC-2744].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 92]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+8:  Referenced Documents
+
+   [ISO-7498-2]  International Standard ISO 7498-2-1988(E), Security
+                 Architecture.
+
+   [ISOIEC-8824] ISO/IEC 8824, "Specification of Abstract Syntax
+                 Notation One (ASN.1)".
+
+   [ISOIEC-8825] ISO/IEC 8825, "Specification of Basic Encoding Rules
+                 for Abstract Syntax Notation One (ASN.1)".)
+
+   [RFC-1507]:   Kaufman, C., "DASS: Distributed Authentication Security
+                 Service", RFC 1507, September 1993.
+
+   [RFC-1508]:   Linn, J., "Generic Security Service Application Program
+                 Interface", RFC 1508, September 1993.
+
+   [RFC-1509]:   Wray, J., "Generic Security Service API: C-bindings",
+                 RFC 1509, September 1993.
+
+   [RFC-1964]:   Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+                 RFC 1964, June 1996.
+
+   [RFC-2025]:   Adams, C., "The Simple Public-Key GSS-API Mechanism
+                 (SPKM)", RFC 2025, October 1996.
+
+   [RFC-2078]:   Linn, J., "Generic Security Service Application Program
+                 Interface, Version 2", RFC 2078, January 1997.
+
+   [RFC-2203]:   Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
+                 Specification", RFC 2203, September 1997.
+
+   [RFC-2744]:   Wray, J., "Generic Security Service API Version 2 :
+                 C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 93]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+APPENDIX A
+
+MECHANISM DESIGN CONSTRAINTS
+
+   The following constraints on GSS-API mechanism designs are adopted in
+   response to observed caller protocol requirements, and adherence
+   thereto is anticipated in subsequent descriptions of GSS-API
+   mechanisms to be documented in standards-track Internet
+   specifications.
+
+   It is strongly recommended that mechanisms offering per-message
+   protection services also offer at least one of the replay detection
+   and sequencing services, as mechanisms offering neither of the latter
+   will fail to satisfy recognized requirements of certain candidate
+   caller protocols.
+
+APPENDIX B
+
+COMPATIBILITY WITH GSS-V1
+
+   It is the intent of this document to define an interface and
+   procedures which preserve compatibility between GSS-V1 [RFC-1508]
+   callers and GSS-V2 providers.  All calls defined in GSS-V1 are
+   preserved, and it has been a goal that GSS-V1 callers should be able
+   to operate atop GSS-V2 provider implementations.  Certain detailed
+   changes, summarized in this section, have been made in order to
+   resolve omissions identified in GSS-V1.
+
+   The following GSS-V1 constructs, while supported within GSS-V2, are
+   deprecated:
+
+      Names for per-message processing routines: GSS_Seal() deprecated
+      in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
+      GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
+      GSS_Verify() deprecated in favor of GSS_VerifyMIC().
+
+      GSS_Delete_sec_context() facility for context_token usage,
+      allowing mechanisms to signal context deletion, is retained for
+      compatibility with GSS-V1.  For current usage, it is recommended
+      that both peers to a context invoke GSS_Delete_sec_context()
+      independently, passing a null output_context_token buffer to
+      indicate that no context_token is required.  Implementations of
+      GSS_Delete_sec_context() should delete relevant locally-stored
+      context information.
+
+   This GSS-V2 specification adds the following calls which are not
+   present in GSS-V1:
+
+
+
+
+Linn                        Standards Track                    [Page 94]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      Credential management calls: GSS_Add_cred(),
+      GSS_Inquire_cred_by_mech().
+
+      Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
+      GSS_Export_sec_context(), GSS_Import_sec_context().
+
+      Per-message calls: No new calls.  Existing calls have been
+      renamed.
+
+      Support calls: GSS_Create_empty_OID_set(),
+      GSS_Add_OID_set_member(), GSS_Test_OID_set_member(),
+      GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(),
+      GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
+
+   This GSS-V2 specification introduces three new facilities applicable
+   to security contexts, indicated using the following context state
+   values which are not present in GSS-V1:
+
+      anon_state, set TRUE to indicate that a context's initiator is
+      anonymous from the viewpoint of the target; Section 1.2.5 of this
+      specification provides a summary description of the GSS-V2
+      anonymity support facility, support and use of which is optional.
+
+      prot_ready_state, set TRUE to indicate that a context may be used
+      for per-message protection before final completion of context
+      establishment; Section 1.2.7 of this specification provides a
+      summary description of the GSS-V2 facility enabling mechanisms to
+      selectively permit per-message protection during context
+      establishment, support and use of which is optional.
+
+      trans_state, set TRUE to indicate that a context is transferable
+      to another process using the GSS-V2 GSS_Export_sec_context()
+      facility.
+
+   These state values are represented (at the C bindings level) in
+   positions within a bit vector which are unused in GSS-V1, and may be
+   safely ignored by GSS-V1 callers.
+
+   New conf_req_flag and integ_req_flag inputs are defined for
+   GSS_Init_sec_context(), primarily to provide information to
+   negotiating mechanisms.  This introduces a compatibility issue with
+   GSS-V1 callers, discussed in section 2.2.1 of this specification.
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                    [Page 95]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
+   implementors in the following areas: implementation robustness,
+   credential management, behavior in multi-mechanism configurations,
+   naming support, and inclusion of optional sequencing services.  The
+   token tagging facility as defined in GSS-V2, Section 3.1, is now
+   described directly in terms of octets to facilitate interoperable
+   implementation without general ASN.1 processing code; the
+   corresponding ASN.1 syntax, included for descriptive purposes, is
+   unchanged from that in GSS-V1. For use in conjunction with added
+   naming support facilities, a new Exported Name Object construct is
+   added.  Additional name types are introduced in Section 4.
+
+   This GSS-V2 specification adds the following major_status values
+   which are not defined in GSS-V1:
+
+        GSS_S_BAD_QOP                 unsupported QOP value
+        GSS_S_UNAUTHORIZED            operation unauthorized
+        GSS_S_UNAVAILABLE             operation unavailable
+        GSS_S_DUPLICATE_ELEMENT       duplicate credential element
+                                        requested
+        GSS_S_NAME_NOT_MN                   name contains multi-mechanism
+                                        elements
+        GSS_S_GAP_TOKEN               skipped predecessor token(s)
+                                        detected
+
+   Of these added status codes, only two values are defined to be
+   returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
+   GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
+   GSS_VerifyMIC() and GSS_Unwrap()).
+
+   Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
+   have been updated to allow return of additional major_status values
+   from the set as defined in GSS-V1: GSS_Inquire_cred() has
+   GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
+   returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
+   GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
+   GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
+
+APPENDIX C
+
+CHANGES RELATIVE TO RFC-2078
+
+   This document incorporates a number of changes relative to RFC-2078,
+   made primarily in response to implementation experience, for purposes
+   of alignment with the GSS-V2 C language bindings document, and to add
+   informative clarification.  This section summarizes technical changes
+   incorporated.
+
+
+
+
+Linn                        Standards Track                    [Page 96]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+   General:
+
+      Clarified usage of object release routines, and incorporated
+      statement that some may be omitted within certain operating
+      environments.
+
+      Removed GSS_Release_OID, GSS_OID_to_str(), and GSS_Str_to_OID()
+      routines.
+
+      Clarified circumstances under which zero-length tokens may validly
+      exist as inputs and outputs to/from GSS-API calls.
+
+      Added GSS_S_BAD_MIC status code as alias for GSS_S_BAD_SIG.
+
+      For GSS_Display_status(), deferred to language bindings the choice
+      of whether to return multiple status values in parallel or via
+      iteration, and added commentary deprecating return of
+      GSS_S_CONTINUE_NEEDED.
+
+      Adapted and incorporated clarifying material on optional service
+      support, delegation, and interprocess context transfer from C
+      bindings document.
+
+      Added and updated references to related documents, and to current
+      status of cited Kerberos mechanism OID.
+
+      Added general statement about GSS-API calls having no side effects
+      visible at the GSS-API level.
+
+   Context-related (including per-message protection issues):
+
+      Clarified GSS_Delete_sec_context() usage for partially-established
+      contexts.
+
+      Added clarification on GSS_Export_sec_context() and
+      GSS_Import_sec_context() behavior and context usage following an
+      export-import sequence.
+
+      Added informatory conf_req_flag, integ_req_flag inputs to
+      GSS_Init_sec_context().  (Note: this facility introduces a
+      backward incompatibility with GSS-V1 callers, discussed in Section
+      2.2.1; this implication was recognized and accepted in working
+      group discussion.)
+
+      Stated that GSS_S_FAILURE is to be returned if
+      GSS_Init_sec_context() or GSS_Accept_sec_context() is passed the
+      handle of a context which is already fully established.
+
+
+
+
+Linn                        Standards Track                    [Page 97]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      Re GSS_Inquire_sec_context(), stated that src_name and targ_name
+      are not returned until GSS_S_COMPLETE status is reached; removed
+      use of GSS_S_CONTEXT_EXPIRED status code (replacing with EXPIRED
+      lifetime return value); stated requirement to retain inquirable
+      data until context released by caller; added result value
+      indicating whether or not context is fully open.
+
+      Added discussion of interoperability conditions for mechanisms
+      permitting optional support of QOPs. Removed reference to
+      structured QOP elements in GSS_Verify_MIC().
+
+      Added discussion of use of GSS_S_DUPLICATE_TOKEN status to
+      indicate reflected per-message tokens.
+
+      Clarified use of informational sequencing codes from per-message
+      protection calls in conjunction with GSS_S_COMPLETE and
+      GSS_S_FAILURE major_status returns, adjusting status code
+      descriptions accordingly.
+
+      Added specific statements about impact of GSS_GetMIC() and
+      GSS_Wrap() failures on context state information, and generalized
+      existing statements about impact of processing failures on
+      received per-message tokens.
+
+      For GSS_Init_sec_context() and GSS_Accept_sec_context(), permitted
+      returned mech_type to be valid before GSS_S_COMPLETE, recognizing
+      that the value may change on successive continuation calls in the
+      negotiated mechanism case.
+
+      Deleted GSS_S_CONTEXT_EXPIRED status from
+      GSS_Import_sec_context().
+
+      Added conf_req_flag input to GSS_Wrap_size_limit().
+
+      Stated requirement for mechanisms' support of per-message
+      protection services to be usable concurrently in both directions
+      on a context.
+
+   Credential-related:
+
+      For GSS_Acquire_cred() and GSS_Add_cred(), aligned with C bindings
+      statement of likely non-support for INITIATE or BOTH credentials
+      if input name is neither empty nor a name resulting from applying
+      GSS_Inquire_cred() against the default credential.  Further,
+      stated that an explicit name returned by GSS_Inquire_context()
+      should also be accepted.  Added commentary about potentially
+      time-variant results of default resolution and attendant
+      implications.  Aligned with C bindings re behavior when
+
+
+
+Linn                        Standards Track                    [Page 98]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      GSS_C_NO_NAME provided for desired_name. In GSS_Acquire_cred(),
+      stated that NULL, rather than empty OID set, should be used for
+      desired_mechs in order to request default mechanism set.
+
+      Added GSS_S_CREDENTIALS_EXPIRED as returnable major_status for
+      GSS_Acquire_cred(), GSS_Add_cred(), also specifying GSS_S_NO_CRED
+      as appropriate return for temporary, user-fixable credential
+      unavailability.  GSS_Acquire_cred() and GSS_Add_cred() are also to
+      return GSS_S_NO_CRED if an authorization failure is encountered
+      upon credential acquisition.
+
+      Removed GSS_S_CREDENTIALS_EXPIRED status return from per-message
+      protection, GSS_Context_time(), and GSS_Inquire_context() calls.
+
+      For GSS_Add_cred(), aligned with C bindings' description of
+      behavior when addition of elements to the default credential is
+      requested.
+
+      Upgraded recommended default credential resolution algorithm to
+      status of requirement for initiator credentials.
+
+      For GSS_Release_cred(), GSS_Inquire_cred(), and
+      GSS_Inquire_cred_by_mech(), clarified behavior for input
+      GSS_C_NO_CREDENTIAL.
+
+   Name-related:
+
+      Aligned GSS_Inquire_mechs_for_name() description with C bindings.
+
+      Removed GSS_S_BAD_NAMETYPE status return from
+      GSS_Duplicate_name(), GSS_Display_name(); constrained its
+      applicability for GSS_Compare_name().
+
+      Aligned with C bindings statement re GSS_Import_name() behavior
+      with GSS_C_NO_OID input name type, and stated that GSS-V2
+      mechanism specifications are to define processing procedures
+      applicable to their mechanisms.  Also clarified GSS_C_NO_OID usage
+      with GSS_Display_name().
+
+      Downgraded reference to name canonicalization via DNS lookup to an
+      example.
+
+      For GSS_Canonicalize_name(), stated that neither negotiated
+      mechanisms nor the default mechanism are supported input
+      mech_types for this operation, and specified GSS_S_BAD_MECH status
+      to be returned in this case.  Clarified that the
+      GSS_Canonicalize_name() operation is non-destructive to its input
+      name.
+
+
+
+Linn                        Standards Track                    [Page 99]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+      Clarified semantics of GSS_C_NT_USER_NAME name type.
+
+      Added descriptions of additional name types.  Also added
+      discussion of GSS_C_NO_NAME and its constrained usage with
+      specific GSS calls.
+
+      Adapted and incorporated C bindings discussion about name
+      comparisons with exported name objects.
+
+      Added recommendation to mechanism designers for support of host-
+      based service name type, deferring any requirement statement to
+      individual mechanism specifications.  Added discussion of host-
+      based service's service name element and proposed approach for
+      IANA registration policy therefor.
+
+      Clarified byte ordering within exported name object.  Stated that
+      GSS_S_BAD_MECH is to be returned if, in the course of attempted
+      import of an exported name object, the name object's enclosed
+      mechanism type is unrecognized or unsupported.
+
+      Stated that mechanisms may optionally accept GSS_C_NO_NAME as an
+      input target name to GSS_Init_sec_context(), with comment that
+      such support is unlikely within mechanisms predating GSS-V2,
+      Update 1.
+
+AUTHOR'S ADDRESS
+
+   John Linn
+   RSA Laboratories
+   20 Crosby Drive
+   Bedford, MA  01730 USA
+
+   Phone: +1 781.687.7817
+   EMail: jlinn@rsasecurity.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                   [Page 100]
+
+RFC 2743                        GSS-API                     January 2000
+
+
+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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                        Standards Track                   [Page 101]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc2744.txt b/third_party/heimdal/doc/standardisation/rfc2744.txt
new file mode 100644
index 00000000000..7f0c61946f2
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc2744.txt
@@ -0,0 +1,5659 @@
+
+
+
+
+
+
+Network Working Group                                             J. Wray
+Request for Comments: 2744                                Iris Associates
+Obsoletes: 1509                                              January 2000
+Category: Standards Track
+
+
+          Generic Security Service API Version 2 : C-bindings
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document specifies C language bindings for Version 2, Update 1
+   of the Generic Security Service Application Program Interface (GSS-
+   API), which is described at a language-independent conceptual level
+   in RFC-2743 [GSSAPI].  It obsoletes RFC-1509, making specific
+   incremental changes in response to implementation experience and
+   liaison requests.  It is intended, therefore, that this memo or a
+   successor version thereof will become the basis for subsequent
+   progression of the GSS-API specification on the standards track.
+
+   The Generic Security Service Application Programming Interface
+   provides security services to its callers, and is intended for
+   implementation atop a variety of underlying cryptographic mechanisms.
+   Typically, GSS-API callers will be application protocols into which
+   security enhancements are integrated through invocation of services
+   provided by the GSS-API. The GSS-API allows a caller application to
+   authenticate a principal identity associated with a peer application,
+   to delegate rights to a peer, and to apply security services such as
+   confidentiality and integrity on a per-message basis.
+
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                     [Page 1]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+1.   Introduction
+
+   The Generic Security Service Application Programming Interface
+   [GSSAPI] provides security services to calling applications.  It
+   allows a communicating application to authenticate the user
+   associated with another application, to delegate rights to another
+   application, and to apply security services such as confidentiality
+   and integrity on a per-message basis.
+
+   There are four stages to using the GSS-API:
+
+   a) The application acquires a set of credentials with which it may
+      prove its identity to other processes. The application's
+      credentials vouch for its global identity, which may or may not be
+      related to any local username under which it may be running.
+
+   b) A pair of communicating applications establish a joint security
+      context using their credentials.  The security context is a pair
+      of GSS-API data structures that contain shared state information,
+      which is required in order that per-message security services may
+      be provided.  Examples of state that might be shared between
+      applications as part of a security context are cryptographic keys,
+      and message sequence numbers.  As part of the establishment of a
+      security context, the context initiator is authenticated to the
+      responder, and may require that the responder is authenticated in
+      turn.  The initiator may optionally give the responder the right
+      to initiate further security contexts, acting as an agent or
+      delegate of the initiator.  This transfer of rights is termed
+      delegation, and is achieved by creating a set of credentials,
+      similar to those used by the initiating application, but which may
+      be used by the responder.
+
+      To establish and maintain the shared information that makes up the
+      security context, certain GSS-API calls will return a token data
+      structure, which is an opaque data type that may contain
+      cryptographically protected data.  The caller of such a GSS-API
+      routine is responsible for transferring the token to the peer
+      application, encapsulated if necessary in an application-
+      application protocol.  On receipt of such a token, the peer
+      application should pass it to a corresponding GSS-API routine
+      which will decode the token and extract the information, updating
+      the security context state information accordingly.
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                     [Page 2]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   c) Per-message services are invoked to apply either:
+
+      integrity and data origin authentication, or confidentiality,
+      integrity and data origin authentication to application data,
+      which are treated by GSS-API as arbitrary octet-strings.  An
+      application transmitting a message that it wishes to protect will
+      call the appropriate GSS-API routine (gss_get_mic or gss_wrap) to
+      apply protection, specifying the appropriate security context, and
+      send the resulting token to the receiving application.  The
+      receiver will pass the received token (and, in the case of data
+      protected by gss_get_mic, the accompanying message-data) to the
+      corresponding decoding routine (gss_verify_mic or gss_unwrap) to
+      remove the protection and validate the data.
+
+   d) At the completion of a communications session (which may extend
+      across several transport connections), each application calls a
+      GSS-API routine to delete the security context.  Multiple contexts
+      may also be used (either successively or simultaneously) within a
+      single communications association, at the option of the
+      applications.
+
+2.   GSS-API Routines
+
+      This section lists the routines that make up the GSS-API, and
+      offers a brief description of the purpose of each routine.
+      Detailed descriptions of each routine are listed in alphabetical
+      order in section 5.
+
+   Table 2-1  GSS-API Credential-management Routines
+
+   Routine                Section              Function
+   -------                -------              --------
+   gss_acquire_cred           5.2  Assume a global identity; Obtain
+                                   a GSS-API credential handle for
+                                   pre-existing credentials.
+   gss_add_cred               5.3  Construct credentials
+                                   incrementally
+   gss_inquire_cred           5.21 Obtain information about a
+                                   credential
+   gss_inquire_cred_by_mech   5.22 Obtain per-mechanism information
+                                   about a credential.
+   gss_release_cred           5.27 Discard a credential handle.
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                     [Page 3]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Table 2-2  GSS-API Context-Level Routines
+
+   Routine                 Section              Function
+   -------                 -------              --------
+   gss_init_sec_context       5.19 Initiate a security context with
+                                   a peer application
+   gss_accept_sec_context     5.1  Accept a security context
+                                   initiated by a
+                                   peer application
+   gss_delete_sec_context     5.9  Discard a security context
+   gss_process_context_token  5.25 Process a token on a security
+                                   context from a peer application
+   gss_context_time           5.7  Determine for how long a context
+                                   will remain valid
+   gss_inquire_context        5.20 Obtain information about a
+                                   security context
+   gss_wrap_size_limit        5.34 Determine token-size limit for
+                                   gss_wrap on a context
+   gss_export_sec_context     5.14 Transfer a security context to
+                                   another process
+   gss_import_sec_context     5.17 Import a transferred context
+
+
+   Table 2-3  GSS-API Per-message Routines
+
+   Routine                 Section              Function
+   -------                 -------              --------
+   gss_get_mic                5.15 Calculate a cryptographic message
+                                   integrity code (MIC) for a
+                                   message; integrity service
+   gss_verify_mic             5.32 Check a MIC against a message;
+                                   verify integrity of a received
+                                   message
+   gss_wrap                   5.33 Attach a MIC to a message, and
+                                   optionally encrypt the message
+                                   content;
+                                   confidentiality service
+   gss_unwrap                 5.31 Verify a message with attached
+                                   MIC, and decrypt message content
+                                   if necessary.
+
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                     [Page 4]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Table 2-4  GSS-API Name manipulation Routines
+
+   Routine                 Section              Function
+   -------                 -------              --------
+   gss_import_name            5.16 Convert a contiguous string name
+                                   to internal-form
+   gss_display_name           5.10 Convert internal-form name to
+                                   text
+   gss_compare_name           5.6  Compare two internal-form names
+
+   gss_release_name           5.28 Discard an internal-form name
+   gss_inquire_names_for_mech 5.24 List the name-types supported by
+                                   the specified mechanism
+   gss_inquire_mechs_for_name 5.23 List mechanisms that support the
+                                   specified name-type
+   gss_canonicalize_name      5.5  Convert an internal name to an MN
+   gss_export_name            5.13 Convert an MN to export form
+   gss_duplicate_name         5.12 Create a copy of an internal name
+
+
+   Table 2-5  GSS-API Miscellaneous Routines
+
+   Routine                Section              Function
+   -------                -------              --------
+   gss_add_oid_set_member    5.4  Add an object identifier to
+                                  a set
+   gss_display_status        5.11 Convert a GSS-API status code
+                                  to text
+   gss_indicate_mechs        5.18 Determine available underlying
+                                  authentication mechanisms
+   gss_release_buffer        5.26 Discard a buffer
+   gss_release_oid_set       5.29 Discard a set of object
+                                  identifiers
+   gss_create_empty_oid_set  5.8  Create a set containing no
+                                  object identifiers
+   gss_test_oid_set_member   5.30 Determines whether an object
+                                       identifier is a member of a set.
+
+   Individual GSS-API implementations may augment these routines by
+   providing additional mechanism-specific routines if required
+   functionality is not available from the generic forms. Applications
+   are encouraged to use the generic routines wherever possible on
+   portability grounds.
+
+
+
+
+
+
+
+
+Wray                        Standards Track                     [Page 5]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+3.   Data Types and Calling Conventions
+
+   The following conventions are used by the GSS-API C-language
+   bindings:
+
+3.1. Integer types
+
+   GSS-API uses the following integer data type:
+
+   OM_uint32    32-bit unsigned integer
+
+   Where guaranteed minimum bit-count is important, this portable data
+   type is used by the GSS-API routine definitions.  Individual GSS-API
+   implementations will include appropriate typedef definitions to map
+   this type onto a built-in data type.  If the platform supports the
+   X/Open xom.h header file, the OM_uint32 definition contained therein
+   should be used; the GSS-API header file in Appendix A contains logic
+   that will detect the prior inclusion of xom.h, and will not attempt
+   to re-declare OM_uint32.  If the X/Open header file is not available
+   on the platform, the GSS-API implementation should use the smallest
+   natural unsigned integer type that provides at least 32 bits of
+   precision.
+
+3.2. String and similar data
+
+   Many of the GSS-API routines take arguments and return values that
+   describe contiguous octet-strings.  All such data is passed between
+   the GSS-API and the caller using the gss_buffer_t data type.  This
+   data type is a pointer to a buffer descriptor, which consists of a
+   length field that contains the total number of bytes in the datum,
+   and a value field which contains a pointer to the actual datum:
+
+   typedef struct gss_buffer_desc_struct {
+      size_t    length;
+      void      *value;
+   } gss_buffer_desc, *gss_buffer_t;
+
+   Storage for data returned to the application by a GSS-API routine
+   using the gss_buffer_t conventions is allocated by the GSS-API
+   routine.  The application may free this storage by invoking the
+   gss_release_buffer routine.  Allocation of the gss_buffer_desc object
+   is always the responsibility of the application;  unused
+   gss_buffer_desc objects may be initialized to the value
+   GSS_C_EMPTY_BUFFER.
+
+
+
+
+
+
+
+Wray                        Standards Track                     [Page 6]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+3.2.1. Opaque data types
+
+   Certain multiple-word data items are considered opaque data types at
+   the GSS-API, because their internal structure has no significance
+   either to the GSS-API or to the caller.  Examples of such opaque data
+   types are the input_token parameter to gss_init_sec_context (which is
+   opaque to the caller), and the input_message parameter to gss_wrap
+   (which is opaque to the GSS-API).  Opaque data is passed between the
+   GSS-API and the application using the gss_buffer_t datatype.
+
+3.2.2. Character strings
+
+   Certain multiple-word data items may be regarded as simple ISO
+   Latin-1 character strings.  Examples are the printable strings passed
+   to gss_import_name via the input_name_buffer parameter. Some GSS-API
+   routines also return character strings.  All such character strings
+   are passed between the application and the GSS-API implementation
+   using the gss_buffer_t datatype, which is a pointer to a
+   gss_buffer_desc object.
+
+   When a gss_buffer_desc object describes a printable string, the
+   length field of the gss_buffer_desc should only count printable
+   characters within the string.  In particular, a trailing NUL
+   character should NOT be included in the length count, nor should
+   either the GSS-API implementation or the application assume the
+   presence of an uncounted trailing NUL.
+
+3.3. Object Identifiers
+
+   Certain GSS-API procedures take parameters of the type gss_OID, or
+   Object identifier.  This is a type containing ISO-defined tree-
+   structured values, and is used by the GSS-API caller to select an
+   underlying security mechanism and to specify namespaces.  A value of
+   type gss_OID has the following structure:
+
+   typedef struct gss_OID_desc_struct {
+      OM_uint32   length;
+      void        *elements;
+   } gss_OID_desc, *gss_OID;
+
+   The elements field of this structure points to the first byte of an
+   octet string containing the ASN.1 BER encoding of the value portion
+   of the normal BER TLV encoding of the gss_OID.  The length field
+   contains the number of bytes in this value.  For example, the gss_OID
+   value corresponding to {iso(1) identified-organization(3) icd-
+   ecma(12) member-company(2) dec(1011) cryptoAlgorithms(7) DASS(5)},
+   meaning the DASS X.509 authentication mechanism, has a length field
+   of 7 and an elements field pointing to seven octets containing the
+
+
+
+Wray                        Standards Track                     [Page 7]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   following octal values: 53,14,2,207,163,7,5. GSS-API implementations
+   should provide constant gss_OID values to allow applications to
+   request any supported mechanism, although applications are encouraged
+   on portability grounds to accept the default mechanism.  gss_OID
+   values should also be provided to allow applications to specify
+   particular name types (see section 3.10).  Applications should treat
+   gss_OID_desc values returned by GSS-API routines as read-only.  In
+   particular, the application should not attempt to deallocate them
+   with free().  The gss_OID_desc datatype is equivalent to the X/Open
+   OM_object_identifier datatype[XOM].
+
+3.4. Object Identifier Sets
+
+   Certain GSS-API procedures take parameters of the type gss_OID_set.
+   This type represents one or more object identifiers (section 2.3).  A
+   gss_OID_set object has the following structure:
+
+   typedef struct gss_OID_set_desc_struct {
+      size_t    count;
+      gss_OID   elements;
+   } gss_OID_set_desc, *gss_OID_set;
+
+   The count field contains the number of OIDs within the set.  The
+   elements field is a pointer to an array of gss_OID_desc objects, each
+   of which describes a single OID.  gss_OID_set values are used to name
+   the available mechanisms supported by the GSS-API, to request the use
+   of specific mechanisms, and to indicate which mechanisms a given
+   credential supports.
+
+   All OID sets returned to the application by GSS-API are dynamic
+   objects (the gss_OID_set_desc, the "elements" array of the set, and
+   the "elements" array of each member OID are all dynamically
+   allocated), and this storage must be deallocated by the application
+   using the gss_release_oid_set() routine.
+
+3.5. Credentials
+
+   A credential handle is a caller-opaque atomic datum that identifies a
+   GSS-API credential data structure.  It is represented by the caller-
+   opaque type gss_cred_id_t, which should be implemented as a pointer
+   or arithmetic type.  If a pointer implementation is chosen, care must
+   be taken to ensure that two gss_cred_id_t values may be compared with
+   the == operator.
+
+   GSS-API credentials can contain mechanism-specific principal
+   authentication data for multiple mechanisms.  A GSS-API credential is
+   composed of a set of credential-elements, each of which is applicable
+   to a single mechanism.  A credential may contain at most one
+
+
+
+Wray                        Standards Track                     [Page 8]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   credential-element for each supported mechanism. A credential-element
+   identifies the data needed by a single mechanism to authenticate a
+   single principal, and conceptually contains two credential-references
+   that describe the actual mechanism-specific authentication data, one
+   to be used by GSS-API for initiating contexts,  and one to be used
+   for accepting contexts.  For mechanisms that do not distinguish
+   between acceptor and initiator credentials, both references would
+   point to the same underlying mechanism-specific authentication data.
+
+   Credentials describe a set of mechanism-specific principals, and give
+   their holder the ability to act as any of those principals. All
+   principal identities asserted by a single GSS-API credential should
+   belong to the same entity, although enforcement of this property is
+   an implementation-specific matter.  The GSS-API does not make the
+   actual credentials available to applications; instead a credential
+   handle is used to identify a particular credential, held internally
+   by GSS-API.  The combination of GSS-API credential handle and
+   mechanism identifies the principal whose identity will be asserted by
+   the credential when used with that mechanism.
+
+   The gss_init_sec_context and gss_accept_sec_context routines allow
+   the value GSS_C_NO_CREDENTIAL to be specified as their credential
+   handle parameter.  This special credential-handle indicates a desire
+   by the application to act as a default principal.  While individual
+   GSS-API implementations are free to determine such default behavior
+   as appropriate to the mechanism, the following default behavior by
+   these routines is recommended for portability:
+
+   gss_init_sec_context
+
+      1) If there is only a single principal capable of initiating
+         security contexts for the chosen mechanism that the application
+         is authorized to act on behalf of, then that principal shall be
+         used, otherwise
+
+      2) If the platform maintains a concept of a default network-
+         identity for the chosen mechanism, and if the application is
+         authorized to act on behalf of that identity for the purpose of
+         initiating security contexts, then the principal corresponding
+         to that identity shall be used, otherwise
+
+      3) If the platform maintains a concept of a default local
+         identity, and provides a means to map local identities into
+         network-identities for the chosen mechanism, and if the
+         application is authorized to act on behalf of the network-
+         identity image of the default local identity for the purpose of
+
+
+
+
+
+Wray                        Standards Track                     [Page 9]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+         initiating security contexts using the chosen mechanism, then
+         the principal corresponding to that identity shall be used,
+         otherwise
+
+      4) A user-configurable default identity should be used.
+
+   gss_accept_sec_context
+
+      1) If there is only a single authorized principal identity capable
+         of accepting security contexts for the chosen mechanism, then
+         that principal shall be used, otherwise
+
+      2) If the mechanism can determine the identity of the target
+         principal by examining the context-establishment token, and if
+         the accepting application is authorized to act as that
+         principal for the purpose of accepting security contexts using
+         the chosen mechanism, then that principal identity shall be
+         used, otherwise
+
+      3) If the mechanism supports context acceptance by any principal,
+         and if mutual authentication was not requested, any principal
+         that the application is authorized to accept security contexts
+         under using the chosen mechanism may be used, otherwise
+
+      4)A user-configurable default identity shall be used.
+
+   The purpose of the above rules is to allow security contexts to be
+   established by both initiator and acceptor using the default behavior
+   wherever possible.  Applications requesting default behavior are
+   likely to be more portable across mechanisms and platforms than ones
+   that use gss_acquire_cred to request a specific identity.
+
+3.6. Contexts
+
+   The gss_ctx_id_t data type contains a caller-opaque atomic value that
+   identifies one end of a GSS-API security context.  It should be
+   implemented as a pointer or arithmetic type.  If a pointer type is
+   chosen, care should be taken to ensure that two gss_ctx_id_t values
+   may be compared with the == operator.
+
+   The security context holds state information about each end of a peer
+   communication, including cryptographic state information.
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 10]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+3.7. Authentication tokens
+
+   A token is a caller-opaque type that GSS-API uses to maintain
+   synchronization between the context data structures at each end of a
+   GSS-API security context.  The token is a cryptographically protected
+   octet-string, generated by the underlying mechanism at one end of a
+   GSS-API security context for use by the peer mechanism at the other
+   end.  Encapsulation (if required) and transfer of the token are the
+   responsibility of the peer applications.  A token is passed between
+   the GSS-API and the application using the gss_buffer_t conventions.
+
+3.8. Interprocess tokens
+
+   Certain GSS-API routines are intended to transfer data between
+   processes in multi-process programs.  These routines use a caller-
+   opaque octet-string, generated by the GSS-API in one process for use
+   by the GSS-API in another process.  The calling application is
+   responsible for transferring such tokens between processes in an OS-
+   specific manner.  Note that, while GSS-API implementors are
+   encouraged to avoid placing sensitive information within interprocess
+   tokens, or to cryptographically protect them, many implementations
+   will be unable to avoid placing key material or other sensitive data
+   within them.  It is the application's responsibility to ensure that
+   interprocess tokens are protected in transit, and transferred only to
+   processes that are trustworthy. An interprocess token is passed
+   between the GSS-API and the application using the gss_buffer_t
+   conventions.
+
+3.9. Status values
+
+   Every GSS-API routine returns two distinct values to report status
+   information to the caller: GSS status codes and Mechanism status
+   codes.
+
+3.9.1. GSS status codes
+
+   GSS-API routines return GSS status codes as their OM_uint32 function
+   value.  These codes indicate errors that are independent of the
+   underlying mechanism(s) used to provide the security service.  The
+   errors that can be indicated via a GSS status code are either generic
+   API routine errors (errors that are defined in the GSS-API
+   specification) or calling errors (errors that are specific to these
+   language bindings).
+
+   A GSS status code can indicate a single fatal generic API error from
+   the routine and a single calling error.  In addition, supplementary
+   status information may be indicated via the setting of bits in the
+   supplementary info field of a GSS status code.
+
+
+
+Wray                        Standards Track                    [Page 11]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   These errors are encoded into the 32-bit GSS status code as follows:
+
+      MSB                                                        LSB
+      |------------------------------------------------------------|
+      |  Calling Error | Routine Error  |    Supplementary Info    |
+      |------------------------------------------------------------|
+   Bit 31            24 23            16 15                       0
+
+   Hence if a GSS-API routine returns a GSS status code whose upper 16
+   bits contain a non-zero value, the call failed.  If the calling error
+   field is non-zero, the invoking application's call of the routine was
+   erroneous.  Calling errors are defined in table 5-1.  If the routine
+   error field is non-zero, the routine failed for one of the routine-
+   specific reasons listed below in table 5-2.  Whether or not the upper
+   16 bits indicate a failure or a success, the routine may indicate
+   additional information by setting bits in the supplementary info
+   field of the status code. The meaning of individual bits is listed
+   below in table 5-3.
+
+   Table 3-1  Calling Errors
+
+   Name                   Value in field           Meaning
+   ----                   --------------           -------
+   GSS_S_CALL_INACCESSIBLE_READ  1       A required input parameter
+                                         could not be read
+   GSS_S_CALL_INACCESSIBLE_WRITE 2       A required output parameter
+                                          could not be written.
+   GSS_S_CALL_BAD_STRUCTURE      3       A parameter was malformed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 12]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Table 3-2  Routine Errors
+
+   Name                   Value in field           Meaning
+   ----                   --------------           -------
+   GSS_S_BAD_MECH                1       An unsupported mechanism
+                                         was requested
+   GSS_S_BAD_NAME                2       An invalid name was
+                                         supplied
+   GSS_S_BAD_NAMETYPE            3       A supplied name was of an
+                                         unsupported type
+   GSS_S_BAD_BINDINGS            4       Incorrect channel bindings
+                                         were supplied
+   GSS_S_BAD_STATUS              5       An invalid status code was
+                                         supplied
+   GSS_S_BAD_MIC GSS_S_BAD_SIG   6       A token had an invalid MIC
+   GSS_S_NO_CRED                 7       No credentials were
+                                         supplied, or the
+                                         credentials were
+                                         unavailable or
+                                         inaccessible.
+   GSS_S_NO_CONTEXT              8       No context has been
+                                         established
+   GSS_S_DEFECTIVE_TOKEN         9       A token was invalid
+   GSS_S_DEFECTIVE_CREDENTIAL   10       A credential was invalid
+   GSS_S_CREDENTIALS_EXPIRED    11       The referenced credentials
+                                         have expired
+   GSS_S_CONTEXT_EXPIRED        12       The context has expired
+   GSS_S_FAILURE                13       Miscellaneous failure (see
+                                         text)
+   GSS_S_BAD_QOP                14       The quality-of-protection
+                                         requested could not be
+                                         provided
+   GSS_S_UNAUTHORIZED           15       The operation is forbidden
+                                         by local security policy
+   GSS_S_UNAVAILABLE            16       The operation or option is
+                                         unavailable
+   GSS_S_DUPLICATE_ELEMENT      17       The requested credential
+                                         element already exists
+   GSS_S_NAME_NOT_MN            18       The provided name was not a
+                                         mechanism name
+
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 13]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Table 3-3  Supplementary Status Bits
+
+   Name                   Bit Number           Meaning
+   ----                   ----------           -------
+   GSS_S_CONTINUE_NEEDED   0 (LSB)   Returned only by
+                                     gss_init_sec_context or
+                                     gss_accept_sec_context. The
+                                     routine must be called again
+                                     to complete its function.
+                                     See routine documentation for
+                                     detailed description
+   GSS_S_DUPLICATE_TOKEN   1         The token was a duplicate of
+                                     an earlier token
+   GSS_S_OLD_TOKEN         2         The token's validity period
+                                     has expired
+   GSS_S_UNSEQ_TOKEN       3         A later token has already been
+                                     processed
+   GSS_S_GAP_TOKEN         4         An expected per-message token
+                                     was not received
+
+   The routine documentation also uses the name GSS_S_COMPLETE, which is
+   a zero value, to indicate an absence of any API errors or
+   supplementary information bits.
+
+   All GSS_S_xxx symbols equate to complete OM_uint32 status codes,
+   rather than to bitfield values.  For example, the actual value of the
+   symbol GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is
+   3<<16.  The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and
+   GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a GSS
+   status code and removes all but the relevant field.  For example, the
+   value obtained by applying GSS_ROUTINE_ERROR to a status code removes
+   the calling errors and supplementary info fields, leaving only the
+   routine errors field.  The values delivered by these macros may be
+   directly compared with a GSS_S_xxx symbol of the appropriate type.
+   The macro GSS_ERROR() is also provided, which when applied to a GSS
+   status code returns a non-zero value if the status code indicated a
+   calling or routine error, and a zero value otherwise.  All macros
+   defined by GSS-API evaluate their argument(s) exactly once.
+
+   A GSS-API implementation may choose to signal calling errors in a
+   platform-specific manner instead of, or in addition to the routine
+   value;  routine errors and supplementary info should be returned via
+   major status values only.
+
+   The GSS major status code GSS_S_FAILURE is used to indicate that the
+   underlying mechanism detected an error for which no specific GSS
+   status code is defined.  The mechanism-specific status code will
+   provide more details about the error.
+
+
+
+Wray                        Standards Track                    [Page 14]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+3.9.2. Mechanism-specific status codes
+
+   GSS-API routines return a minor_status parameter, which is used to
+   indicate specialized errors from the underlying security mechanism.
+   This parameter may contain a single mechanism-specific error,
+   indicated by a OM_uint32 value.
+
+   The minor_status parameter will always be set by a GSS-API routine,
+   even if it returns a calling error or one of the generic API errors
+   indicated above as fatal, although most other output parameters may
+   remain unset in such cases.  However, output parameters that are
+   expected to return pointers to storage allocated by a routine must
+   always be set by the routine, even in the event of an error, although
+   in such cases the GSS-API routine may elect to set the returned
+   parameter value to NULL to indicate that no storage was actually
+   allocated.  Any length field associated with such pointers (as in a
+   gss_buffer_desc structure) should also be set to zero in such cases.
+
+3.10. Names
+
+   A name is used to identify a person or entity.  GSS-API authenticates
+   the relationship between a name and the entity claiming the name.
+
+   Since different authentication mechanisms may employ different
+   namespaces for identifying their principals, GSSAPI's naming support
+   is necessarily complex in multi-mechanism environments (or even in
+   some single-mechanism environments where the underlying mechanism
+   supports multiple namespaces).
+
+   Two distinct representations are defined for names:
+
+   An internal form.  This is the GSS-API "native" format for names,
+      represented by the implementation-specific gss_name_t type.  It is
+      opaque to GSS-API callers.  A single gss_name_t object may contain
+      multiple names from different namespaces, but all names should
+      refer to the same entity.  An example of such an internal name
+      would be the name returned from a call to the gss_inquire_cred
+      routine, when applied to a credential containing credential
+      elements for multiple authentication mechanisms employing
+      different namespaces.  This gss_name_t object will contain a
+      distinct name for the entity for each authentication mechanism.
+
+      For GSS-API implementations supporting multiple namespaces,
+      objects of type gss_name_t must contain sufficient information to
+      determine the namespace to which each primitive name belongs.
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 15]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Mechanism-specific contiguous octet-string forms.  A format
+      capable of containing a single name (from a single namespace).
+      Contiguous string names are always accompanied by an object
+      identifier specifying the namespace to which the name belongs, and
+      their format is dependent on the authentication mechanism that
+      employs the name.  Many, but not all, contiguous string names will
+      be printable, and may therefore be used by GSS-API applications
+      for communication with their users.
+
+   Routines (gss_import_name and gss_display_name) are provided to
+   convert names between contiguous string representations and the
+   internal gss_name_t type.  gss_import_name may support multiple
+   syntaxes for each supported namespace, allowing users the freedom to
+   choose a preferred name representation. gss_display_name should use
+   an implementation-chosen printable syntax for each supported name-
+   type.
+
+   If an application calls gss_display_name(), passing the internal name
+   resulting from a call to gss_import_name(), there is no guarantee the
+   the resulting contiguous string name will be the same as the original
+   imported string name.  Nor do name-space identifiers necessarily
+   survive unchanged after a journey through the internal name-form.  An
+   example of this might be a mechanism that authenticates X.500 names,
+   but provides an algorithmic mapping of Internet DNS names into X.500.
+   That mechanism's implementation of gss_import_name() might, when
+   presented with a DNS name, generate an internal name that contained
+   both the original DNS name and the equivalent X.500 name.
+   Alternatively, it might only store the X.500 name.  In the latter
+   case, gss_display_name() would most likely generate a printable X.500
+   name, rather than the original DNS name.
+
+   The process of authentication delivers to the context acceptor an
+   internal name.  Since this name has been authenticated by a single
+   mechanism, it contains only a single name (even if the internal name
+   presented by the context initiator to gss_init_sec_context had
+   multiple components).  Such names are termed internal mechanism
+   names, or "MN"s and the names emitted by gss_accept_sec_context() are
+   always of this type.  Since some applications may require MNs without
+   wanting to incur the overhead of an authentication operation, a
+   second function, gss_canonicalize_name(), is provided to convert a
+   general internal name into an MN.
+
+   Comparison of internal-form names may be accomplished via the
+   gss_compare_name() routine, which returns true if the two names being
+   compared refer to the same entity.  This removes the need for the
+   application program to understand the syntaxes of the various
+   printable names that a given GSS-API implementation may support.
+   Since GSS-API assumes that all primitive names contained within a
+
+
+
+Wray                        Standards Track                    [Page 16]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   given internal name refer to the same entity, gss_compare_name() can
+   return true if the two names have at least one primitive name in
+   common.  If the implementation embodies knowledge of equivalence
+   relationships between names taken from different namespaces, this
+   knowledge may also allow successful comparison of internal names
+   containing no overlapping primitive elements.
+
+   When used in large access control lists, the overhead of invoking
+   gss_import_name() and gss_compare_name() on each name from the ACL
+   may be prohibitive.  As an alternative way of supporting this case,
+   GSS-API defines a special form of the contiguous string name which
+   may be compared directly (e.g. with memcmp()).  Contiguous names
+   suitable for comparison are generated by the gss_export_name()
+   routine, which requires an MN as input.  Exported names may be re-
+   imported by the gss_import_name() routine, and the resulting internal
+   name will also be an MN.  The gss_OID constant GSS_C_NT_EXPORT_NAME
+   indentifies the "export name" type, and the value of this constant is
+   given in Appendix A.  Structurally, an exported name object consists
+   of a header containing an OID identifying the mechanism that
+   authenticated the name, and a trailer containing the name itself,
+   where the syntax of the trailer is defined by the individual
+   mechanism specification.   The precise format of an export name is
+   defined in the language-independent GSS-API specification [GSSAPI].
+
+   Note that the results obtained by using gss_compare_name() will in
+   general be different from those obtained by invoking
+   gss_canonicalize_name() and gss_export_name(), and then comparing the
+   exported names.  The first series of operation determines whether two
+   (unauthenticated) names identify the same principal; the second
+   whether a particular mechanism would authenticate them as the same
+   principal.  These two operations will in general give the same
+   results only for MNs.
+
+   The gss_name_t datatype should be implemented as a pointer type. To
+   allow the compiler to aid the application programmer by performing
+   type-checking, the use of (void *) is discouraged.  A pointer to an
+   implementation-defined type is the preferred choice.
+
+   Storage is allocated by routines that return gss_name_t values. A
+   procedure, gss_release_name, is provided to free storage associated
+   with an internal-form name.
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 17]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+3.11. Channel Bindings
+
+   GSS-API supports the use of user-specified tags to identify a given
+   context to the peer application.  These tags are intended to be used
+   to identify the particular communications channel that carries the
+   context.  Channel bindings are communicated to the GSS-API using the
+   following structure:
+
+   typedef struct gss_channel_bindings_struct {
+      OM_uint32       initiator_addrtype;
+      gss_buffer_desc initiator_address;
+      OM_uint32       acceptor_addrtype;
+      gss_buffer_desc acceptor_address;
+      gss_buffer_desc application_data;
+   } *gss_channel_bindings_t;
+
+   The initiator_addrtype and acceptor_addrtype fields denote the type
+   of addresses contained in the initiator_address and acceptor_address
+   buffers.  The address type should be one of the following:
+
+   GSS_C_AF_UNSPEC     Unspecified address type
+   GSS_C_AF_LOCAL      Host-local address type
+   GSS_C_AF_INET       Internet address type (e.g. IP)
+   GSS_C_AF_IMPLINK    ARPAnet IMP address type
+   GSS_C_AF_PUP        pup protocols (eg BSP) address type
+   GSS_C_AF_CHAOS      MIT CHAOS protocol address type
+   GSS_C_AF_NS         XEROX NS address type
+   GSS_C_AF_NBS        nbs address type
+   GSS_C_AF_ECMA       ECMA address type
+   GSS_C_AF_DATAKIT    datakit protocols address type
+   GSS_C_AF_CCITT      CCITT protocols
+   GSS_C_AF_SNA        IBM SNA address type
+   GSS_C_AF_DECnet     DECnet address type
+   GSS_C_AF_DLI        Direct data link interface address type
+   GSS_C_AF_LAT        LAT address type
+   GSS_C_AF_HYLINK     NSC Hyperchannel address type
+   GSS_C_AF_APPLETALK  AppleTalk address type
+   GSS_C_AF_BSC        BISYNC 2780/3780 address type
+   GSS_C_AF_DSS        Distributed system services address type
+   GSS_C_AF_OSI        OSI TP4 address type
+   GSS_C_AF_X25        X.25
+   GSS_C_AF_NULLADDR   No address specified
+
+   Note that these symbols name address families rather than specific
+   addressing formats.  For address families that contain several
+   alternative address forms, the initiator_address and acceptor_address
+   fields must contain sufficient information to determine which address
+
+
+
+
+Wray                        Standards Track                    [Page 18]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   form is used.  When not otherwise specified, addresses should be
+   specified in network byte-order (that is, native byte-ordering for
+   the address family).
+
+   Conceptually, the GSS-API concatenates the initiator_addrtype,
+   initiator_address, acceptor_addrtype, acceptor_address and
+   application_data to form an octet string.  The mechanism calculates a
+   MIC over this octet string, and binds the MIC to the context
+   establishment token emitted by gss_init_sec_context. The same
+   bindings are presented by the context acceptor to
+   gss_accept_sec_context, and a MIC is calculated in the same way. The
+   calculated MIC is compared with that found in the token, and if the
+   MICs differ, gss_accept_sec_context will return a GSS_S_BAD_BINDINGS
+   error, and the context will not be established.  Some mechanisms may
+   include the actual channel binding data in the token (rather than
+   just a MIC); applications should therefore not use confidential data
+   as channel-binding components.
+
+   Individual mechanisms may impose additional constraints on addresses
+   and address types that may appear in channel bindings.  For example,
+   a mechanism may verify that the initiator_address field of the
+   channel bindings presented to gss_init_sec_context contains the
+   correct network address of the host system.  Portable applications
+   should therefore ensure that they either provide correct information
+   for the address fields, or omit addressing information, specifying
+   GSS_C_AF_NULLADDR as the address-types.
+
+3.12. Optional parameters
+
+   Various parameters are described as optional.  This means that they
+   follow a convention whereby a default value may be requested.  The
+   following conventions are used for omitted parameters.  These
+   conventions apply only to those parameters that are explicitly
+   documented as optional.
+
+3.12.1. gss_buffer_t types
+
+   Specify GSS_C_NO_BUFFER as a value.  For an input parameter this
+   signifies that default behavior is requested, while for an output
+   parameter it indicates that the information that would be returned
+   via the parameter is not required by the application.
+
+3.12.2. Integer types (input)
+
+   Individual parameter documentation lists values to be used to
+   indicate default actions.
+
+
+
+
+
+Wray                        Standards Track                    [Page 19]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+3.12.3. Integer types (output)
+
+   Specify NULL as the value for the pointer.
+
+3.12.4. Pointer types
+
+   Specify NULL as the value.
+
+3.12.5. Object IDs
+
+   Specify GSS_C_NO_OID as the value.
+
+3.12.6. Object ID Sets
+
+   Specify GSS_C_NO_OID_SET as the value.
+
+3.12.7. Channel Bindings
+
+   Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings
+   are not to be used.
+
+4.   Additional Controls
+
+   This section discusses the optional services that a context initiator
+   may request of the GSS-API at context establishment. Each of these
+   services is requested by setting a flag in the req_flags input
+   parameter to gss_init_sec_context.
+
+   The optional services currently defined are:
+
+   Delegation - The (usually temporary) transfer of rights from
+       initiator to acceptor, enabling the acceptor to authenticate
+       itself as an agent of the initiator.
+
+   Mutual Authentication - In addition to the initiator authenticating
+       its identity to the context acceptor, the context acceptor should
+       also authenticate itself to the initiator.
+
+   Replay detection - In addition to providing message integrity
+       services, gss_get_mic and gss_wrap should include message
+       numbering information to enable gss_verify_mic and gss_unwrap to
+       detect if a message has been duplicated.
+
+   Out-of-sequence detection - In addition to providing message
+       integrity services, gss_get_mic and gss_wrap should include
+       message sequencing information to enable gss_verify_mic and
+       gss_unwrap to detect if a message has been received out of
+       sequence.
+
+
+
+Wray                        Standards Track                    [Page 20]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Anonymous authentication - The establishment of the security context
+       should not reveal the initiator's identity to the context
+       acceptor.
+
+   Any currently undefined bits within such flag arguments should be
+   ignored by GSS-API implementations when presented by an application,
+   and should be set to zero when returned to the application by the
+   GSS-API implementation.
+
+   Some mechanisms may not support all optional services, and some
+   mechanisms may only support some services in conjunction with others.
+   Both gss_init_sec_context and gss_accept_sec_context inform the
+   applications which services will be available from the context when
+   the establishment phase is complete, via the ret_flags output
+   parameter.  In general, if the security mechanism is capable of
+   providing a requested service, it should do so, even if additional
+   services must be enabled in order to provide the requested service.
+   If the mechanism is incapable of providing a requested service, it
+   should proceed without the service, leaving the application to abort
+   the context establishment process if it considers the requested
+   service to be mandatory.
+
+   Some mechanisms may specify that support for some services is
+   optional, and that implementors of the mechanism need not provide it.
+   This is most commonly true of the confidentiality service, often
+   because of legal restrictions on the use of data-encryption, but may
+   apply to any of the services.  Such mechanisms are required to send
+   at least one token from acceptor to initiator during context
+   establishment when the initiator indicates a desire to use such a
+   service, so that the initiating GSS-API can correctly indicate
+   whether the service is supported by the acceptor's GSS-API.
+
+4.1. Delegation
+
+   The GSS-API allows delegation to be controlled by the initiating
+   application via a boolean parameter to gss_init_sec_context(), the
+   routine that establishes a security context.  Some mechanisms do not
+   support delegation, and for such mechanisms attempts by an
+   application to enable delegation are ignored.
+
+   The acceptor of a security context for which the initiator enabled
+   delegation will receive (via the delegated_cred_handle parameter of
+   gss_accept_sec_context) a credential handle that contains the
+   delegated identity, and this credential handle may be used to
+   initiate subsequent GSS-API security contexts as an agent or delegate
+   of the initiator.  If the original initiator's identity is "A" and
+   the delegate's identity is "B", then, depending on the underlying
+   mechanism, the identity embodied by the delegated credential may be
+
+
+
+Wray                        Standards Track                    [Page 21]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   either "A" or "B acting for A".
+
+   For many mechanisms that support delegation, a simple boolean does
+   not provide enough control.  Examples of additional aspects of
+   delegation control that a mechanism might provide to an application
+   are duration of delegation, network addresses from which delegation
+   is valid, and constraints on the tasks that may be performed by a
+   delegate.  Such controls are presently outside the scope of the GSS-
+   API.  GSS-API implementations supporting mechanisms offering
+   additional controls should provide extension routines that allow
+   these controls to be exercised (perhaps by modifying the initiator's
+   GSS-API credential prior to its use in establishing a context).
+   However, the simple delegation control provided by GSS-API should
+   always be able to over-ride other mechanism-specific delegation
+   controls - If the application instructs gss_init_sec_context() that
+   delegation is not desired, then the implementation must not permit
+   delegation to occur. This is an exception to the general rule that a
+   mechanism may enable services even if they are not requested -
+   delegation may only be provided at the explicit request of the
+   application.
+
+4.2. Mutual authentication
+
+   Usually, a context acceptor will require that a context initiator
+   authenticate itself so that the acceptor may make an access-control
+   decision prior to performing a service for the initiator.  In some
+   cases, the initiator may also request that the acceptor authenticate
+   itself.  GSS-API allows the initiating application to request this
+   mutual authentication service by setting a flag when calling
+   gss_init_sec_context.
+
+   The initiating application is informed as to whether or not the
+   context acceptor has authenticated itself.  Note that some mechanisms
+   may not support mutual authentication, and other mechanisms may
+   always perform mutual authentication, whether or not the initiating
+   application requests it.  In particular, mutual authentication my be
+   required by some mechanisms in order to support replay or out-of-
+   sequence message detection, and for such mechanisms a request for
+   either of these services will automatically enable mutual
+   authentication.
+
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 22]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+4.3. Replay and out-of-sequence detection
+
+   The GSS-API may provide detection of mis-ordered message once a
+   security context has been established.  Protection may be applied to
+   messages by either application, by calling either gss_get_mic or
+   gss_wrap, and verified by the peer application by calling
+   gss_verify_mic or gss_unwrap.
+
+   gss_get_mic calculates a cryptographic MIC over an application
+   message, and returns that MIC in a token.  The application should
+   pass both the token and the message to the peer application, which
+   presents them to gss_verify_mic.
+
+   gss_wrap calculates a cryptographic MIC of an application message,
+   and places both the MIC and the message inside a single token.  The
+   Application should pass the token to the peer application, which
+   presents it to gss_unwrap to extract the message and verify the MIC.
+
+   Either pair of routines may be capable of detecting out-of-sequence
+   message delivery, or duplication of messages. Details of such mis-
+   ordered messages are indicated through supplementary status bits in
+   the major status code returned by gss_verify_mic or gss_unwrap.  The
+   relevant supplementary bits are:
+
+   GSS_S_DUPLICATE_TOKEN - The token is a duplicate of one that has
+                    already been received and processed.  Only
+                    contexts that claim to provide replay detection
+                    may set this bit.
+   GSS_S_OLD_TOKEN - The token is too old to determine whether or
+                    not it is a duplicate.  Contexts supporting
+                    out-of-sequence detection but not replay
+                    detection should always set this bit if
+                    GSS_S_UNSEQ_TOKEN is set; contexts that support
+                    replay detection should only set this bit if the
+                    token is so old that it cannot be checked for
+                    duplication.
+   GSS_S_UNSEQ_TOKEN - A later token has already been processed.
+   GSS_S_GAP_TOKEN - An earlier token has not yet been received.
+
+   A mechanism need not maintain a list of all tokens that have been
+   processed in order to support these status codes.  A typical
+   mechanism might retain information about only the most recent "N"
+   tokens processed, allowing it to distinguish duplicates and missing
+   tokens within the most recent "N" messages; the receipt of a token
+   older than the most recent "N" would result in a GSS_S_OLD_TOKEN
+   status.
+
+
+
+
+
+Wray                        Standards Track                    [Page 23]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+4.4. Anonymous Authentication
+
+   In certain situations, an application may wish to initiate the
+   authentication process to authenticate a peer, without revealing its
+   own identity.  As an example, consider an application providing
+   access to a database containing medical information, and offering
+   unrestricted access to the service.  A client of such a service might
+   wish to authenticate the service (in order to establish trust in any
+   information retrieved from it), but might not wish the service to be
+   able to obtain the client's identity (perhaps due to privacy concerns
+   about the specific inquiries, or perhaps simply to avoid being placed
+   on mailing-lists).
+
+   In normal use of the GSS-API, the initiator's identity is made
+   available to the acceptor as a result of the context establishment
+   process.  However, context initiators may request that their identity
+   not be revealed to the context acceptor. Many mechanisms do not
+   support anonymous authentication, and for such mechanisms the request
+   will not be honored.  An authentication token will be still be
+   generated, but the application is always informed if a requested
+   service is unavailable, and has the option to abort context
+   establishment if anonymity is valued above the other security
+   services that would require a context to be established.
+
+   In addition to informing the application that a context is
+   established anonymously (via the ret_flags outputs from
+   gss_init_sec_context and gss_accept_sec_context), the optional
+   src_name output from gss_accept_sec_context and gss_inquire_context
+   will, for such contexts, return a reserved internal-form name,
+   defined by the implementation.
+
+   When presented to gss_display_name, this reserved internal-form name
+   will result in a printable name that is syntactically distinguishable
+   from any valid principal name supported by the implementation,
+   associated with a name-type object identifier with the value
+   GSS_C_NT_ANONYMOUS, whose value us given in Appendix A.  The
+   printable form of an anonymous name should be chosen such that it
+   implies anonymity, since this name may appear in, for example, audit
+   logs.  For example, the string "<anonymous>" might be a good choice,
+   if no valid printable names supported by the implementation can begin
+   with "<" and end with ">".
+
+4.5. Confidentiality
+
+   If a context supports the confidentiality service, gss_wrap may be
+   used to encrypt application messages.  Messages are selectively
+   encrypted, under the control of the conf_req_flag input parameter to
+   gss_wrap.
+
+
+
+Wray                        Standards Track                    [Page 24]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+4.6. Inter-process context transfer
+
+   GSS-API V2 provides routines (gss_export_sec_context and
+   gss_import_sec_context) which allow a security context to be
+   transferred between processes on a single machine.  The most common
+   use for such a feature is a client-server design where the server is
+   implemented as a single process that accepts incoming security
+   contexts, which then launches child processes to deal with the data
+   on these contexts.  In such a design, the child processes must have
+   access to the security context data structure created within the
+   parent by its call to gss_accept_sec_context so that they can use
+   per-message protection services and delete the security context when
+   the communication session ends.
+
+   Since the security context data structure is expected to contain
+   sequencing information, it is impractical in general to share a
+   context between processes.  Thus GSS-API provides a call
+   (gss_export_sec_context) that the process which currently owns the
+   context can call to declare that it has no intention to use the
+   context subsequently, and to create an inter-process token containing
+   information needed by the adopting process to successfully import the
+   context.  After successful completion of gss_export_sec_context, the
+   original security context is made inaccessible to the calling process
+   by GSS-API, and any context handles referring to this context are no
+   longer valid.  The originating process transfers the inter-process
+   token to the adopting process, which passes it to
+   gss_import_sec_context, and a fresh gss_ctx_id_t is created such that
+   it is functionally identical to the original context.
+
+   The inter-process token may contain sensitive data from the original
+   security context (including cryptographic keys). Applications using
+   inter-process tokens to transfer security contexts must take
+   appropriate steps to protect these tokens in transit.
+
+   Implementations are not required to support the inter-process
+   transfer of security contexts.  The ability to transfer a security
+   context is indicated when the context is created, by
+   gss_init_sec_context or gss_accept_sec_context setting the
+   GSS_C_TRANS_FLAG bit in their ret_flags parameter.
+
+4.7. The use of incomplete contexts
+
+   Some mechanisms may allow the per-message services to be used before
+   the context establishment process is complete.  For example, a
+   mechanism may include sufficient information in its initial context-
+   level token for the context acceptor to immediately decode messages
+   protected with gss_wrap or gss_get_mic.  For such a mechanism, the
+   initiating application need not wait until subsequent context-level
+
+
+
+Wray                        Standards Track                    [Page 25]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   tokens have been sent and received before invoking the per-message
+   protection services.
+
+   The ability of a context to provide per-message services in advance
+   of complete context establishment is indicated by the setting of the
+   GSS_C_PROT_READY_FLAG bit in the ret_flags parameter from
+   gss_init_sec_context and gss_accept_sec_context. Applications wishing
+   to use per-message protection services on partially-established
+   contexts should check this flag before attempting to invoke gss_wrap
+   or gss_get_mic.
+
+5. GSS-API Routine Descriptions
+
+   In addition to the explicit major status codes documented here, the
+   code GSS_S_FAILURE may be returned by any routine, indicating an
+   implementation-specific or mechanism-specific error condition,
+   further details of which are reported via the minor_status parameter.
+
+5.1. gss_accept_sec_context
+
+   OM_uint32 gss_accept_sec_context (
+     OM_uint32           *minor_status,
+     gss_ctx_id_t        *context_handle,
+     const gss_cred_id_t acceptor_cred_handle,
+     const gss_buffer_t  input_token_buffer,
+     const gss_channel_bindings_t  input_chan_bindings,
+     const gss_name_t    *src_name,
+     gss_OID             *mech_type,
+     gss_buffer_t        output_token,
+     OM_uint32           *ret_flags,
+     OM_uint32           *time_rec,
+     gss_cred_id_t       *delegated_cred_handle)
+
+   Purpose:
+
+   Allows a remotely initiated security context between the application
+   and a remote peer to be established.  The routine may return a
+   output_token which should be transferred to the peer application,
+   where the peer application will present it to gss_init_sec_context.
+   If no token need be sent, gss_accept_sec_context will indicate this
+   by setting the length field of the output_token argument to zero.  To
+   complete the context establishment, one or more reply tokens may be
+   required from the peer application; if so, gss_accept_sec_context
+   will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it
+   should be called again when the reply token is received from the peer
+   application, passing the token to gss_accept_sec_context via the
+   input_token parameters.
+
+
+
+
+Wray                        Standards Track                    [Page 26]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Portable applications should be constructed to use the token length
+   and return status to determine whether a token needs to be sent or
+   waited for.  Thus a typical portable caller should always invoke
+   gss_accept_sec_context within a loop:
+
+   gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT;
+
+   do {
+     receive_token_from_peer(input_token);
+     maj_stat = gss_accept_sec_context(&min_stat,
+                                       &context_hdl,
+                                       cred_hdl,
+                                       input_token,
+                                       input_bindings,
+                                       &client_name,
+                                       &mech_type,
+                                       output_token,
+                                       &ret_flags,
+                                       &time_rec,
+                                       &deleg_cred);
+     if (GSS_ERROR(maj_stat)) {
+       report_error(maj_stat, min_stat);
+     };
+     if (output_token->length != 0) {
+       send_token_to_peer(output_token);
+
+       gss_release_buffer(&min_stat, output_token);
+     };
+     if (GSS_ERROR(maj_stat)) {
+       if (context_hdl != GSS_C_NO_CONTEXT)
+         gss_delete_sec_context(&min_stat,
+                                &context_hdl,
+                                GSS_C_NO_BUFFER);
+       break;
+     };
+   } while (maj_stat & GSS_S_CONTINUE_NEEDED);
+
+   Whenever the routine returns a major status that includes the value
+   GSS_S_CONTINUE_NEEDED, the context is not fully established and the
+   following restrictions apply to the output parameters:
+
+   The value returned via the time_rec parameter is undefined Unless the
+   accompanying ret_flags parameter contains the bit
+   GSS_C_PROT_READY_FLAG, indicating that per-message services may be
+   applied in advance of a successful completion status, the value
+   returned via the mech_type parameter may be undefined until the
+   routine returns a major status value of GSS_S_COMPLETE.
+
+
+
+
+Wray                        Standards Track                    [Page 27]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   The values of the GSS_C_DELEG_FLAG,
+   GSS_C_MUTUAL_FLAG,GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG,
+   GSS_C_CONF_FLAG,GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned
+   via the ret_flags parameter should contain the values that the
+   implementation expects would be valid if context establishment were
+   to succeed.
+
+   The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits
+   within ret_flags should indicate the actual state at the time
+   gss_accept_sec_context returns, whether or not the context is fully
+   established.
+
+   Although this requires that GSS-API implementations set the
+   GSS_C_PROT_READY_FLAG in the final ret_flags returned to a caller
+   (i.e. when accompanied by a GSS_S_COMPLETE status code), applications
+   should not rely on this behavior as the flag was not defined in
+   Version 1 of the GSS-API. Instead, applications should be prepared to
+   use per-message services after a successful context establishment,
+   according to the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG values.
+
+   All other bits within the ret_flags argument should be set to zero.
+   While the routine returns GSS_S_CONTINUE_NEEDED, the values returned
+   via the ret_flags argument indicate the services that the
+   implementation expects to be available from the established context.
+
+   If the initial call of gss_accept_sec_context() fails, the
+   implementation should not create a context object, and should leave
+   the value of the context_handle parameter set to GSS_C_NO_CONTEXT to
+   indicate this.  In the event of a failure on a subsequent call, the
+   implementation is permitted to delete the "half-built" security
+   context (in which case it should set the context_handle parameter to
+   GSS_C_NO_CONTEXT), but the preferred behavior is to leave the
+   security context (and the context_handle parameter) untouched for the
+   application to delete (using gss_delete_sec_context).
+
+   During context establishment, the informational status bits
+   GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN indicate fatal errors, and
+   GSS-API mechanisms should always return them in association with a
+   routine error of GSS_S_FAILURE.  This requirement for pairing did not
+   exist in version 1 of the GSS-API specification, so applications that
+   wish to run over version 1 implementations must special-case these
+   codes.
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 28]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   context_handle    gss_ctx_id_t, read/modify context handle for new
+                        context.  Supply GSS_C_NO_CONTEXT for first
+                        call; use value returned in subsequent calls.
+                        Once gss_accept_sec_context() has returned a
+                        value via this parameter, resources have been
+                        assigned to the corresponding context, and must
+                        be freed by the application after use with a
+                        call to gss_delete_sec_context().
+
+
+   acceptor_cred_handle  gss_cred_id_t, read Credential handle claimed
+                         by context acceptor. Specify
+                         GSS_C_NO_CREDENTIAL to accept the context as a
+                         default principal.  If GSS_C_NO_CREDENTIAL is
+                         specified, but no default acceptor principal is
+                         defined, GSS_S_NO_CRED will be returned.
+
+   input_token_buffer   buffer, opaque, read token obtained from remote
+                        application.
+
+   input_chan_bindings  channel bindings, read, optional Application-
+                        specified bindings.  Allows application to
+                        securely bind channel identification information
+                        to the security context.  If channel bindings
+                        are not used, specify GSS_C_NO_CHANNEL_BINDINGS.
+
+   src_name             gss_name_t, modify, optional Authenticated name
+                        of context initiator.  After use, this name
+                        should be deallocated by passing it to
+                        gss_release_name().  If not required, specify
+                        NULL.
+
+   mech_type            Object ID, modify, optional Security mechanism
+                        used.  The returned OID value will be a pointer
+                        into static storage, and should be treated as
+                        read-only by the caller (in particular, it does
+                        not need to be freed).  If not required, specify
+                        NULL.
+
+   output_token         buffer, opaque, modify Token to be passed to
+                        peer application.  If the length field of the
+                        returned token buffer is 0, then no token need
+                        be passed to the peer application.  If a non-
+                        zero length field is returned, the associated
+                        storage must be freed after use by the
+                        application with a call to gss_release_buffer().
+
+
+
+Wray                        Standards Track                    [Page 29]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   ret_flags            bit-mask, modify, optional Contains various
+                        independent flags, each of which indicates that
+                        the context supports a specific service option.
+                        If not needed, specify NULL.  Symbolic names are
+                        provided for each flag, and the symbolic names
+                        corresponding to the required flags should be
+                        logically-ANDed with the ret_flags value to test
+                        whether a given option is supported by the
+                        context.  The flags are:
+                        GSS_C_DELEG_FLAG
+                        True - Delegated credentials are available
+                               via the delegated_cred_handle
+                               parameter
+                        False - No credentials were delegated
+                        GSS_C_MUTUAL_FLAG
+                        True - Remote peer asked for mutual
+                               authentication
+                        False - Remote peer did not ask for mutual
+                                authentication
+                        GSS_C_REPLAY_FLAG
+                        True - replay of protected messages
+                               will be detected
+                        False - replayed messages will not be
+                                detected
+                        GSS_C_SEQUENCE_FLAG
+                        True - out-of-sequence protected
+                               messages will be detected
+                        False - out-of-sequence messages will not
+                                be detected
+                        GSS_C_CONF_FLAG
+                        True - Confidentiality service may be
+                               invoked by calling the gss_wrap
+                               routine
+                        False - No confidentiality service (via
+                                gss_wrap) available. gss_wrap will
+                                provide message encapsulation,
+                                data-origin authentication and
+                                integrity services only.
+                        GSS_C_INTEG_FLAG
+                        True - Integrity service may be invoked by
+                               calling either gss_get_mic or
+                               gss_wrap routines.
+                        False - Per-message integrity service
+                                unavailable.
+                        GSS_C_ANON_FLAG
+                        True - The initiator does not wish to
+                               be authenticated; the src_name
+                               parameter (if requested) contains
+
+
+
+Wray                        Standards Track                    [Page 30]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                               an anonymous internal name.
+                        False - The initiator has been
+                                authenticated normally.
+                        GSS_C_PROT_READY_FLAG
+                        True - Protection services (as specified
+                               by the states of the GSS_C_CONF_FLAG
+                               and GSS_C_INTEG_FLAG) are available
+                               if the accompanying major status
+                               return value is either GSS_S_COMPLETE
+                               or GSS_S_CONTINUE_NEEDED.
+                        False - Protection services (as specified
+                                by the states of the GSS_C_CONF_FLAG
+                                and GSS_C_INTEG_FLAG) are available
+                                only if the accompanying major status
+                                return value is GSS_S_COMPLETE.
+                        GSS_C_TRANS_FLAG
+                        True - The resultant security context may
+                               be transferred to other processes via
+                               a call to gss_export_sec_context().
+                        False - The security context is not
+                                transferable.
+                        All other bits should be set to zero.
+
+   time_rec             Integer, modify, optional
+                        number of seconds for which the context will
+                        remain valid. Specify NULL if not required.
+
+   delegated_cred_handle
+                        gss_cred_id_t, modify, optional credential
+                        handle for credentials received from context
+                        initiator.  Only valid if deleg_flag in
+                        ret_flags is true, in which case an explicit
+                        credential handle (i.e. not GSS_C_NO_CREDENTIAL)
+                        will be returned; if deleg_flag is false,
+                        gss_accept_context() will set this parameter to
+                        GSS_C_NO_CREDENTIAL.  If a credential handle is
+                        returned, the associated resources must be
+                        released by the application after use with a
+                        call to gss_release_cred().  Specify NULL if not
+                        required.
+
+   minor_status         Integer, modify
+                        Mechanism specific status code.
+
+   GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
+                         application is required to complete the
+                         context, and that gss_accept_sec_context must
+                         be called again with that token.
+
+
+
+Wray                        Standards Track                    [Page 31]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on
+                         the input_token failed.
+
+   GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
+                         performed on the credential failed.
+
+   GSS_S_NO_CRED     The supplied credentials were not valid for context
+                         acceptance, or the credential handle did not
+                         reference any credentials.
+
+   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
+
+   GSS_S_BAD_BINDINGS  The input_token contains different channel
+                         bindings to those specified via the
+                         input_chan_bindings parameter.
+
+   GSS_S_NO_CONTEXT  Indicates that the supplied context handle did not
+                         refer to a valid context.
+
+   GSS_S_BAD_SIG     The input_token contains an invalid MIC.
+
+   GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal error
+                         during context establishment.
+
+   GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of
+                         a token already processed.  This is a fatal
+                         error during context establishment.
+
+   GSS_S_BAD_MECH    The received token specified a mechanism that is
+                         not supported by the implementation or the
+                         provided credential.
+
+5.2. gss_acquire_cred
+
+   OM_uint32 gss_acquire_cred (
+     OM_uint32         *minor_status,
+     const gss_name_t  desired_name,
+     OM_uint32         time_req,
+     const gss_OID_set desired_mechs,
+     gss_cred_usage_t  cred_usage,
+     gss_cred_id_t     *output_cred_handle,
+     gss_OID_set       *actual_mechs,
+     OM_uint32         *time_rec)
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 32]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Purpose:
+
+   Allows an application to acquire a handle for a pre-existing
+   credential by name.  GSS-API implementations must impose a local
+   access-control policy on callers of this routine to prevent
+   unauthorized callers from acquiring credentials to which they are not
+   entitled.  This routine is not intended to provide a "login to the
+   network" function, as such a function would involve the creation of
+   new credentials rather than merely acquiring a handle to existing
+   credentials.  Such functions, if required, should be defined in
+   implementation-specific extensions to the API.
+
+   If desired_name is GSS_C_NO_NAME, the call is interpreted as a
+   request for a credential handle that will invoke default behavior
+   when passed to gss_init_sec_context() (if cred_usage is
+   GSS_C_INITIATE or GSS_C_BOTH) or gss_accept_sec_context() (if
+   cred_usage is GSS_C_ACCEPT or GSS_C_BOTH).
+
+   Mechanisms should honor the desired_mechs parameter, and return a
+   credential that is suitable to use only with the requested
+   mechanisms.  An exception to this is the case where one underlying
+   credential element can be shared by multiple mechanisms; in this case
+   it is permissible for an implementation to indicate all mechanisms
+   with which the credential element may be used.  If desired_mechs is
+   an empty set, behavior is undefined.
+
+   This routine is expected to be used primarily by context acceptors,
+   since implementations are likely to provide mechanism-specific ways
+   of obtaining GSS-API initiator credentials from the system login
+   process.  Some implementations may therefore not support the
+   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
+   gss_acquire_cred for any name other than GSS_C_NO_NAME, or a name
+   produced by applying either gss_inquire_cred to a valid credential,
+   or gss_inquire_context to an active context.
+
+   If credential acquisition is time-consuming for a mechanism, the
+   mechanism may choose to delay the actual acquisition until the
+   credential is required (e.g. by gss_init_sec_context or
+   gss_accept_sec_context).  Such mechanism-specific implementation
+   decisions should be invisible to the calling application; thus a call
+   of gss_inquire_cred immediately following the call of
+   gss_acquire_cred must return valid credential data, and may therefore
+   incur the overhead of a deferred credential acquisition.
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 33]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   desired_name      gss_name_t, read
+                     Name of principal whose credential
+                     should be acquired
+
+   time_req          Integer, read, optional
+                     number of seconds that credentials
+                     should remain valid. Specify GSS_C_INDEFINITE
+                     to request that the credentials have the maximum
+                     permitted lifetime.
+
+   desired_mechs     Set of Object IDs, read, optional
+                     set of underlying security mechanisms that
+                     may be used.  GSS_C_NO_OID_SET may be used
+                     to obtain an implementation-specific default.
+
+   cred_usage        gss_cred_usage_t, read
+                     GSS_C_BOTH - Credentials may be used
+                        either to initiate or accept
+                        security contexts.
+                     GSS_C_INITIATE - Credentials will only be
+                        used to initiate security contexts.
+                     GSS_C_ACCEPT - Credentials will only be used to
+                        accept security contexts.
+
+   output_cred_handle  gss_cred_id_t, modify
+                       The returned credential handle.  Resources
+                       associated with this credential handle must
+                       be released by the application after use
+                       with a call to gss_release_cred().
+
+   actual_mechs      Set of Object IDs, modify, optional
+                     The set of mechanisms for which the
+                     credential is valid.  Storage associated
+                     with the returned OID-set must be released by
+                     the application after use with a call to
+                     gss_release_oid_set().  Specify NULL if not
+                     required.
+
+   time_rec          Integer, modify, optional
+                     Actual number of seconds for which the
+                     returned credentials will remain valid.  If the
+                     implementation does not support expiration of
+                     credentials, the value GSS_C_INDEFINITE will
+                     be returned. Specify NULL if not required
+
+
+
+
+
+Wray                        Standards Track                    [Page 34]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   Function value:  GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_MECH    Unavailable mechanism requested
+
+   GSS_S_BAD_NAMETYPE Type contained within desired_name parameter
+                      is not supported
+
+   GSS_S_BAD_NAME    Value supplied for desired_name parameter is ill
+                     formed.
+
+   GSS_S_CREDENTIALS_EXPIRED The credentials could not be acquired
+                             Because they have expired.
+
+   GSS_S_NO_CRED     No credentials were found for the specified name.
+
+5.3. gss_add_cred
+
+   OM_uint32 gss_add_cred (
+     OM_uint32           *minor_status,
+     const gss_cred_id_t input_cred_handle,
+     const gss_name_t    desired_name,
+     const gss_OID       desired_mech,
+     gss_cred_usage_t    cred_usage,
+     OM_uint32           initiator_time_req,
+     OM_uint32           acceptor_time_req,
+     gss_cred_id_t       *output_cred_handle,
+     gss_OID_set         *actual_mechs,
+     OM_uint32           *initiator_time_rec,
+     OM_uint32           *acceptor_time_rec)
+
+   Purpose:
+
+   Adds a credential-element to a credential.  The credential-element is
+   identified by the name of the principal to which it refers.  GSS-API
+   implementations must impose a local access-control policy on callers
+   of this routine to prevent unauthorized callers from acquiring
+   credential-elements to which they are not entitled. This routine is
+   not intended to provide a "login to the network" function, as such a
+   function would involve the creation of new mechanism-specific
+   authentication data, rather than merely acquiring a GSS-API handle to
+   existing data.  Such functions, if required, should be defined in
+   implementation-specific extensions to the API.
+
+
+
+
+Wray                        Standards Track                    [Page 35]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   If desired_name is GSS_C_NO_NAME, the call is interpreted as a
+   request to add a credential element that will invoke default behavior
+   when passed to gss_init_sec_context() (if cred_usage is
+   GSS_C_INITIATE or GSS_C_BOTH) or gss_accept_sec_context() (if
+   cred_usage is GSS_C_ACCEPT or GSS_C_BOTH).
+
+   This routine is expected to be used primarily by context acceptors,
+   since implementations are likely to provide mechanism-specific ways
+   of obtaining GSS-API initiator credentials from the system login
+   process.  Some implementations may therefore not support the
+   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
+   gss_acquire_cred for any name other than GSS_C_NO_NAME, or a name
+   produced by applying either gss_inquire_cred to a valid credential,
+   or gss_inquire_context to an active context.
+
+   If credential acquisition is time-consuming for a mechanism, the
+   mechanism may choose to delay the actual acquisition until the
+   credential is required (e.g. by gss_init_sec_context or
+   gss_accept_sec_context).  Such mechanism-specific implementation
+   decisions should be invisible to the calling application; thus a call
+   of gss_inquire_cred immediately following the call of gss_add_cred
+   must return valid credential data, and may therefore incur the
+   overhead of a deferred credential acquisition.
+
+   This routine can be used to either compose a new credential
+   containing all credential-elements of the original in addition to the
+   newly-acquire credential-element, or to add the new credential-
+   element to an existing credential. If NULL is specified for the
+   output_cred_handle parameter argument, the new credential-element
+   will be added to the credential identified by input_cred_handle; if a
+   valid pointer is specified for the output_cred_handle parameter, a
+   new credential handle will be created.
+
+   If GSS_C_NO_CREDENTIAL is specified as the input_cred_handle,
+   gss_add_cred will compose a credential (and set the
+   output_cred_handle parameter accordingly) based on default behavior.
+   That is, the call will have the same effect as if the application had
+   first made a call to gss_acquire_cred(), specifying the same usage
+   and passing GSS_C_NO_NAME as the desired_name parameter to obtain an
+   explicit credential handle embodying default behavior, passed this
+   credential handle to gss_add_cred(), and finally called
+   gss_release_cred() on the first credential handle.
+
+   If GSS_C_NO_CREDENTIAL is specified as the input_cred_handle
+   parameter, a non-NULL output_cred_handle must be supplied.
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 36]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   input_cred_handle gss_cred_id_t, read, optional
+                     The credential to which a credential-element
+                     will be added.  If GSS_C_NO_CREDENTIAL is
+                     specified, the routine will compose the new
+                     credential based on default behavior (see
+                     description above).  Note that, while the
+                     credential-handle is not modified by
+                     gss_add_cred(), the underlying credential
+                     will be modified if output_credential_handle
+                     is NULL.
+
+   desired_name      gss_name_t, read.
+                     Name of principal whose credential
+                     should be acquired.
+
+   desired_mech      Object ID, read
+                     Underlying security mechanism with which the
+                     credential may be used.
+
+   cred_usage        gss_cred_usage_t, read
+                     GSS_C_BOTH - Credential may be used
+                     either to initiate or accept
+                     security contexts.
+                     GSS_C_INITIATE - Credential will only be
+                                      used to initiate security
+                                      contexts.
+                     GSS_C_ACCEPT - Credential will only be used to
+                                    accept security contexts.
+
+   initiator_time_req Integer, read, optional
+                      number of seconds that the credential
+                      should remain valid for initiating security
+                      contexts.  This argument is ignored if the
+                      composed credentials are of type GSS_C_ACCEPT.
+                      Specify GSS_C_INDEFINITE to request that the
+                      credentials have the maximum permitted
+                      initiator lifetime.
+
+   acceptor_time_req Integer, read, optional
+                     number of seconds that the credential
+                     should remain valid for accepting security
+                     contexts.  This argument is ignored if the
+                     composed credentials are of type GSS_C_INITIATE.
+
+
+
+Wray                        Standards Track                    [Page 37]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                     Specify GSS_C_INDEFINITE to request that the
+                     credentials have the maximum permitted initiator
+                     lifetime.
+
+   output_cred_handle gss_cred_id_t, modify, optional
+                      The returned credential handle, containing
+                      the new credential-element and all the
+                      credential-elements from input_cred_handle.
+                      If a valid pointer to a gss_cred_id_t is
+                      supplied for this parameter, gss_add_cred
+                      creates a new credential handle containing all
+                      credential-elements from the input_cred_handle
+                      and the newly acquired credential-element; if
+                      NULL is specified for this parameter, the newly
+                      acquired credential-element will be added
+                      to the credential identified by input_cred_handle.
+
+                      The resources associated with any credential
+                      handle returned via this parameter must be
+                      released by the application after use with a
+                      call to gss_release_cred().
+
+   actual_mechs      Set of Object IDs, modify, optional
+                     The complete set of mechanisms for which
+                     the new credential is valid.  Storage for
+                     the returned OID-set must be freed by the
+                     application after use with a call to
+                     gss_release_oid_set(). Specify NULL if
+                     not required.
+
+   initiator_time_rec Integer, modify, optional
+                      Actual number of seconds for which the
+                      returned credentials will remain valid for
+                      initiating contexts using the specified
+                      mechanism.  If the implementation or mechanism
+                      does not support expiration of credentials, the
+                      value GSS_C_INDEFINITE will be returned. Specify
+                      NULL if not required
+
+   acceptor_time_rec Integer, modify, optional
+                     Actual number of seconds for which the
+                     returned credentials will remain valid for
+                     accepting security contexts using the specified
+                     mechanism.  If the implementation or mechanism
+                     does not support expiration of credentials, the
+                     value GSS_C_INDEFINITE will be returned. Specify
+                     NULL if not required
+
+
+
+
+Wray                        Standards Track                    [Page 38]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_MECH    Unavailable mechanism requested
+
+   GSS_S_BAD_NAMETYPE Type contained within desired_name parameter
+                     is not supported
+
+   GSS_S_BAD_NAME    Value supplied for desired_name parameter is
+                     ill-formed.
+
+   GSS_S_DUPLICATE_ELEMENT The credential already contains an element
+                     for the requested mechanism with overlapping
+                     usage and validity period.
+
+   GSS_S_CREDENTIALS_EXPIRED The required credentials could not be
+                     added because they have expired.
+
+   GSS_S_NO_CRED     No credentials were found for the specified name.
+
+5.4. gss_add_oid_set_member
+
+   OM_uint32 gss_add_oid_set_member (
+     OM_uint32       *minor_status,
+     const gss_OID   member_oid,
+     gss_OID_set     *oid_set)
+
+   Purpose:
+
+   Add an Object Identifier to an Object Identifier set.  This routine
+   is intended for use in conjunction with gss_create_empty_oid_set when
+   constructing a set of mechanism OIDs for input to gss_acquire_cred.
+   The oid_set parameter must refer to an OID-set that was created by
+   GSS-API (e.g. a set returned by gss_create_empty_oid_set()). GSS-API
+   creates a copy of the member_oid and inserts this copy into the set,
+   expanding the storage allocated to the OID-set's elements array if
+   necessary.  The routine may add the new member OID anywhere within
+   the elements array, and implementations should verify that the new
+   member_oid is not already contained within the elements array; if the
+   member_oid is already present, the oid_set should remain unchanged.
+
+   Parameters:
+
+      minor_status      Integer, modify
+                        Mechanism specific status code
+
+
+
+
+
+Wray                        Standards Track                    [Page 39]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+      member_oid        Object ID, read
+                        The object identifier to copied into
+                        the set.
+
+      oid_set           Set of Object ID, modify
+                        The set in which the object identifier
+                        should be inserted.
+
+   Function value:   GSS status code
+
+      GSS_S_COMPLETE    Successful completion
+
+5.5. gss_canonicalize_name
+
+   OM_uint32 gss_canonicalize_name (
+     OM_uint32        *minor_status,
+     const gss_name_t input_name,
+     const gss_OID    mech_type,
+     gss_name_t       *output_name)
+
+   Purpose:
+
+   Generate a canonical mechanism name (MN) from an arbitrary internal
+   name.  The mechanism name is the name that would be returned to a
+   context acceptor on successful authentication of a context where the
+   initiator used the input_name in a successful call to
+   gss_acquire_cred, specifying an OID set containing <mech_type> as its
+   only member, followed by a call to gss_init_sec_context, specifying
+   <mech_type> as the authentication mechanism.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   input_name        gss_name_t, read
+                     The name for which a canonical form is
+                     desired
+
+   mech_type         Object ID, read
+                     The authentication mechanism for which the
+                     canonical form of the name is desired.  The
+                     desired mechanism must be specified explicitly;
+                     no default is provided.
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 40]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   output_name       gss_name_t, modify
+                     The resultant canonical name.  Storage
+                     associated with this name must be freed by
+                     the application after use with a call to
+                     gss_release_name().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion.
+
+   GSS_S_BAD_MECH    The identified mechanism is not supported.
+
+   GSS_S_BAD_NAMETYPE The provided internal name contains no elements
+                     that could be processed by the specified
+                     mechanism.
+
+   GSS_S_BAD_NAME    The provided internal name was ill-formed.
+
+5.6. gss_compare_name
+
+   OM_uint32 gss_compare_name (
+     OM_uint32        *minor_status,
+     const gss_name_t name1,
+     const gss_name_t name2,
+     int              *name_equal)
+
+   Purpose:
+
+   Allows an application to compare two internal-form names to determine
+   whether they refer to the same entity.
+
+   If either name presented to gss_compare_name denotes an anonymous
+   principal, the routines should indicate that the two names do not
+   refer to the same identity.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   name1             gss_name_t, read
+                     internal-form name
+
+   name2             gss_name_t, read
+                     internal-form name
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 41]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   name_equal        boolean, modify
+                     non-zero - names refer to same entity
+                     zero - names refer to different entities
+                           (strictly, the names are not known
+                           to refer to the same identity).
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_NAMETYPE The two names were of incomparable types.
+
+   GSS_S_BAD_NAME    One or both of name1 or name2 was ill-formed.
+
+5.7. gss_context_time
+
+   OM_uint32 gss_context_time (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     OM_uint32          *time_rec)
+
+   Purpose:
+
+   Determines the number of seconds for which the specified context will
+   remain valid.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Implementation specific status code.
+
+   context_handle    gss_ctx_id_t, read
+                     Identifies the context to be interrogated.
+
+   time_rec          Integer, modify
+                     Number of seconds that the context will remain
+                     valid.  If the context has already expired,
+                     zero will be returned.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_CONTEXT_EXPIRED The context has already expired
+
+   GSS_S_NO_CONTEXT  The context_handle parameter did not identify
+                     a valid context
+
+
+
+
+Wray                        Standards Track                    [Page 42]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.8. gss_create_empty_oid_set
+
+   OM_uint32 gss_create_empty_oid_set (
+     OM_uint32    *minor_status,
+     gss_OID_set  *oid_set)
+
+   Purpose:
+
+   Create an object-identifier set containing no object identifiers, to
+   which members may be subsequently added using the
+   gss_add_oid_set_member() routine.  These routines are intended to be
+   used to construct sets of mechanism object identifiers, for input to
+   gss_acquire_cred.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   oid_set           Set of Object IDs, modify
+                     The empty object identifier set.
+                     The routine will allocate the
+                     gss_OID_set_desc object, which the
+                     application must free after use with
+                     a call to gss_release_oid_set().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+5.9. gss_delete_sec_context
+
+   OM_uint32 gss_delete_sec_context (
+     OM_uint32    *minor_status,
+     gss_ctx_id_t *context_handle,
+     gss_buffer_t output_token)
+
+   Purpose:
+
+   Delete a security context.  gss_delete_sec_context will delete the
+   local data structures associated with the specified security context,
+   and may generate an output_token, which when passed to the peer
+   gss_process_context_token will instruct it to do likewise.  If no
+   token is required by the mechanism, the GSS-API should set the length
+   field of the output_token (if provided) to zero.  No further security
+   services may be obtained using the context specified by
+   context_handle.
+
+
+
+
+Wray                        Standards Track                    [Page 43]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   In addition to deleting established security contexts,
+   gss_delete_sec_context must also be able to delete "half-built"
+   security contexts resulting from an incomplete sequence of
+   gss_init_sec_context()/gss_accept_sec_context() calls.
+
+   The output_token parameter is retained for compatibility with version
+   1 of the GSS-API.  It is recommended that both peer applications
+   invoke gss_delete_sec_context passing the value GSS_C_NO_BUFFER for
+   the output_token parameter, indicating that no token is required, and
+   that gss_delete_sec_context should simply delete local context data
+   structures.  If the application does pass a valid buffer to
+   gss_delete_sec_context, mechanisms are encouraged to return a zero-
+   length token, indicating that no peer action is necessary, and that
+   no token should be transferred by the application.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   context_handle    gss_ctx_id_t, modify
+                     context handle identifying context to delete.
+                     After deleting the context, the GSS-API will set
+                     this context handle to GSS_C_NO_CONTEXT.
+
+   output_token      buffer, opaque, modify, optional
+                     token to be sent to remote application to
+                     instruct it to also delete the context.  It
+                     is recommended that applications specify
+                     GSS_C_NO_BUFFER for this parameter, requesting
+                     local deletion only.  If a buffer parameter is
+                     provided by the application, the mechanism may
+                     return a token in it;  mechanisms that implement
+                     only local deletion should set the length field of
+                     this token to zero to indicate to the application
+                     that no token is to be sent to the peer.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NO_CONTEXT  No valid context was supplied
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 44]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.10.gss_display_name
+
+   OM_uint32 gss_display_name (
+     OM_uint32        *minor_status,
+     const gss_name_t input_name,
+     gss_buffer_t     output_name_buffer,
+     gss_OID          *output_name_type)
+
+   Purpose:
+
+   Allows an application to obtain a textual representation of an opaque
+   internal-form  name for display purposes.  The syntax of a printable
+   name is defined by the GSS-API implementation.
+
+   If input_name denotes an anonymous principal, the implementation
+   should return the gss_OID value GSS_C_NT_ANONYMOUS as the
+   output_name_type, and a textual name that is syntactically distinct
+   from all valid supported printable names in output_name_buffer.
+
+   If input_name was created by a call to gss_import_name, specifying
+   GSS_C_NO_OID as the name-type, implementations that employ lazy
+   conversion between name types may return GSS_C_NO_OID via the
+   output_name_type parameter.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   input_name        gss_name_t, read
+                     name to be displayed
+
+   output_name_buffer  buffer, character-string, modify
+                     buffer to receive textual name string.
+                     The application must free storage associated
+                     with this name after use with a call to
+                     gss_release_buffer().
+
+   output_name_type  Object ID, modify, optional
+                     The type of the returned name.  The returned
+                     gss_OID will be a pointer into static storage,
+                     and should be treated as read-only by the caller
+                     (in particular, the application should not attempt
+                     to free it). Specify NULL if not required.
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 45]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_NAME    input_name was ill-formed
+
+5.11.gss_display_status
+
+   OM_uint32 gss_display_status (
+     OM_uint32      *minor_status,
+     OM_uint32      status_value,
+     int            status_type,
+     const gss_OID  mech_type,
+     OM_uint32      *message_context,
+     gss_buffer_t   status_string)
+
+   Purpose:
+
+   Allows an application to obtain a textual representation of a GSS-API
+   status code, for display to the user or for logging purposes.  Since
+   some status values may indicate multiple conditions, applications may
+   need to call gss_display_status multiple times, each call generating
+   a single text string.  The message_context parameter is used by
+   gss_display_status to store state information about which error
+   messages have already been extracted from a given status_value;
+   message_context must be initialized to 0 by the application prior to
+   the first call, and gss_display_status will return a non-zero value
+   in this parameter if there are further messages to extract.
+
+   The message_context parameter contains all state information required
+   by gss_display_status in order to extract further messages from the
+   status_value;  even when a non-zero value is returned in this
+   parameter, the application is not required to call gss_display_status
+   again unless subsequent messages are desired.  The following code
+   extracts all messages from a given status code and prints them to
+   stderr:
+
+   OM_uint32 message_context;
+   OM_uint32 status_code;
+   OM_uint32 maj_status;
+   OM_uint32 min_status;
+   gss_buffer_desc status_string;
+
+          ...
+
+   message_context = 0;
+
+   do {
+
+
+
+Wray                        Standards Track                    [Page 46]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+     maj_status = gss_display_status (
+                     &min_status,
+                     status_code,
+                     GSS_C_GSS_CODE,
+                     GSS_C_NO_OID,
+                     &message_context,
+                     &status_string)
+
+     fprintf(stderr,
+             "%.*s\n",
+            (int)status_string.length,
+
+            (char *)status_string.value);
+
+     gss_release_buffer(&min_status, &status_string);
+
+   } while (message_context != 0);
+
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   status_value      Integer, read
+                     Status value to be converted
+
+   status_type       Integer, read
+                     GSS_C_GSS_CODE - status_value is a GSS status
+                     code
+
+   GSS_C_MECH_CODE - status_value is a mechanism
+                     status code
+
+   mech_type         Object ID, read, optional
+                     Underlying mechanism (used to interpret a
+                     minor status value) Supply GSS_C_NO_OID to
+                     obtain the system default.
+
+   message_context   Integer, read/modify
+                     Should be initialized to zero by the
+                     application prior to the first call.
+                     On return from gss_display_status(),
+                     a non-zero status_value parameter indicates
+                     that additional messages may be extracted
+                     from the status code via subsequent calls
+
+
+
+
+
+Wray                        Standards Track                    [Page 47]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                     to gss_display_status(), passing the same
+                     status_value, status_type, mech_type, and
+                     message_context parameters.
+
+   status_string     buffer, character string, modify
+                     textual interpretation of the status_value.
+                     Storage associated with this parameter must
+                     be freed by the application after use with
+                     a call to gss_release_buffer().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_MECH    Indicates that translation in accordance with
+                     an unsupported mechanism type was requested
+
+   GSS_S_BAD_STATUS  The status value was not recognized, or the
+                     status type was neither GSS_C_GSS_CODE nor
+                     GSS_C_MECH_CODE.
+
+5.12. gss_duplicate_name
+
+   OM_uint32 gss_duplicate_name (
+     OM_uint32        *minor_status,
+     const gss_name_t src_name,
+     gss_name_t       *dest_name)
+
+   Purpose:
+
+   Create an exact duplicate of the existing internal name src_name.
+   The new dest_name will be independent of src_name (i.e. src_name and
+   dest_name must both be released, and the release of one shall not
+   affect the validity of the other).
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   src_name          gss_name_t, read
+                     internal name to be duplicated.
+
+   dest_name         gss_name_t, modify
+                     The resultant copy of <src_name>.
+                     Storage associated with this name must
+                     be freed by the application after use
+                     with a call to gss_release_name().
+
+
+
+Wray                        Standards Track                    [Page 48]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_NAME    The src_name parameter was ill-formed.
+
+5.13. gss_export_name
+
+   OM_uint32 gss_export_name (
+     OM_uint32        *minor_status,
+     const gss_name_t input_name,
+     gss_buffer_t     exported_name)
+
+   Purpose:
+
+   To produce a canonical contiguous string representation of a
+   mechanism name (MN), suitable for direct comparison (e.g. with
+   memcmp) for use in authorization functions (e.g. matching entries in
+   an access-control list).  The <input_name> parameter must specify a
+   valid MN (i.e. an internal name generated by gss_accept_sec_context
+   or by gss_canonicalize_name).
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   input_name        gss_name_t, read
+                     The MN to be exported
+
+   exported_name     gss_buffer_t, octet-string, modify
+                     The canonical contiguous string form of
+                     <input_name>.  Storage associated with
+                     this string must freed by the application
+                     after use with gss_release_buffer().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NAME_NOT_MN The provided internal name was not a mechanism
+                     name.
+
+   GSS_S_BAD_NAME    The provided internal name was ill-formed.
+
+   GSS_S_BAD_NAMETYPE The internal name was of a type not supported
+                     by the GSS-API implementation.
+
+
+
+
+Wray                        Standards Track                    [Page 49]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.14. gss_export_sec_context
+
+   OM_uint32 gss_export_sec_context (
+     OM_uint32    *minor_status,
+     gss_ctx_id_t *context_handle,
+     gss_buffer_t interprocess_token)
+
+   Purpose:
+
+   Provided to support the sharing of work between multiple processes.
+   This routine will typically be used by the context-acceptor, in an
+   application where a single process receives incoming connection
+   requests and accepts security contexts over them, then passes the
+   established context to one or more other processes for message
+   exchange. gss_export_sec_context() deactivates the security context
+   for the calling process and creates an interprocess token which, when
+   passed to gss_import_sec_context in another process, will re-activate
+   the context in the second process. Only a single instantiation of a
+   given context may be active at any one time; a subsequent attempt by
+   a context exporter to access the exported security context will fail.
+
+   The implementation may constrain the set of processes by which the
+   interprocess token may be imported, either as a function of local
+   security policy, or as a result of implementation decisions.  For
+   example, some implementations may constrain contexts to be passed
+   only between processes that run under the same account, or which are
+   part of the same process group.
+
+   The interprocess token may contain security-sensitive information
+   (for example cryptographic keys).  While mechanisms are encouraged to
+   either avoid placing such sensitive information within interprocess
+   tokens, or to encrypt the token before returning it to the
+   application, in a typical object-library GSS-API implementation this
+   may not be possible. Thus the application must take care to protect
+   the interprocess token, and ensure that any process to which the
+   token is transferred is trustworthy.
+
+   If creation of the interprocess token is successful, the
+   implementation shall deallocate all process-wide resources associated
+   with the security context, and set the context_handle to
+   GSS_C_NO_CONTEXT.  In the event of an error that makes it impossible
+   to complete the export of the security context, the implementation
+   must not return an interprocess token, and should strive to leave the
+   security context referenced by the context_handle parameter
+   untouched.  If this is impossible, it is permissible for the
+   implementation to delete the security context, providing it also sets
+   the context_handle parameter to GSS_C_NO_CONTEXT.
+
+
+
+
+Wray                        Standards Track                    [Page 50]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   context_handle    gss_ctx_id_t, modify
+                     context handle identifying the context to
+                     transfer.
+
+   interprocess_token   buffer, opaque, modify
+                        token to be transferred to target process.
+                        Storage associated with this token must be
+                        freed by the application after use with a
+                        call to gss_release_buffer().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_CONTEXT_EXPIRED The context has expired
+
+   GSS_S_NO_CONTEXT  The context was invalid
+
+   GSS_S_UNAVAILABLE The operation is not supported.
+
+5.15. gss_get_mic
+
+   OM_uint32 gss_get_mic (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     gss_qop_t             qop_req,
+     const gss_buffer_t message_buffer,
+     gss_buffer_t       msg_token)
+
+   Purpose:
+
+   Generates a cryptographic MIC for the supplied message, and places
+   the MIC in a token for transfer to the peer application. The qop_req
+   parameter allows a choice between several cryptographic algorithms,
+   if supported by the chosen mechanism.
+
+   Since some application-level protocols may wish to use tokens emitted
+   by gss_wrap() to provide "secure framing", implementations must
+   support derivation of MICs from zero-length messages.
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 51]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Implementation specific status code.
+
+   context_handle    gss_ctx_id_t, read
+                     identifies the context on which the message
+                     will be sent
+
+   qop_req           gss_qop_t, read, optional
+                     Specifies requested quality of protection.
+                     Callers are encouraged, on portability grounds,
+                     to accept the default quality of protection
+                     offered by the chosen mechanism, which may be
+                     requested by specifying GSS_C_QOP_DEFAULT for
+                     this parameter.  If an unsupported protection
+                     strength is requested, gss_get_mic will return a
+                     major_status of GSS_S_BAD_QOP.
+
+   message_buffer    buffer, opaque, read
+                     message to be protected
+
+   msg_token         buffer, opaque, modify
+                     buffer to receive token.  The application must
+                     free storage associated with this buffer after
+                     use with a call to gss_release_buffer().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_CONTEXT_EXPIRED The context has already expired
+
+   GSS_S_NO_CONTEXT  The context_handle parameter did not identify
+                     a valid context
+
+   GSS_S_BAD_QOP     The specified QOP is not supported by the
+                     mechanism.
+
+5.16. gss_import_name
+
+   OM_uint32 gss_import_name (
+     OM_uint32          *minor_status,
+     const gss_buffer_t input_name_buffer,
+     const gss_OID      input_name_type,
+     gss_name_t         *output_name)
+
+
+
+
+
+Wray                        Standards Track                    [Page 52]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Purpose:
+
+   Convert a contiguous string name to internal form.  In general, the
+   internal name returned (via the <output_name> parameter) will not be
+   an MN; the exception to this is if the <input_name_type> indicates
+   that the contiguous string provided via the <input_name_buffer>
+   parameter is of type GSS_C_NT_EXPORT_NAME, in which case the returned
+   internal name will be an MN for the mechanism that exported the name.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   input_name_buffer  buffer, octet-string, read
+                     buffer containing contiguous string name to convert
+
+   input_name_type   Object ID, read, optional
+                     Object ID specifying type of printable
+                     name.  Applications may specify either
+                     GSS_C_NO_OID to use a mechanism-specific
+                     default printable syntax, or an OID recognized
+                     by the GSS-API implementation to name a
+                     specific namespace.
+
+   output_name       gss_name_t, modify
+                     returned name in internal form.  Storage
+                     associated with this name must be freed
+                     by the application after use with a call
+                     to gss_release_name().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_NAMETYPE The input_name_type was unrecognized
+
+   GSS_S_BAD_NAME    The input_name parameter could not be interpreted
+                     as a name of the specified type
+
+   GSS_S_BAD_MECH    The input name-type was GSS_C_NT_EXPORT_NAME,
+                     but the mechanism contained within the
+                     input-name is not supported
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 53]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.17. gss_import_sec_context
+
+   OM_uint32 gss_import_sec_context (
+     OM_uint32          *minor_status,
+     const gss_buffer_t interprocess_token,
+     gss_ctx_id_t       *context_handle)
+
+   Purpose:
+
+   Allows a process to import a security context established by another
+   process.  A given interprocess token may be imported only once.  See
+   gss_export_sec_context.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   interprocess_token  buffer, opaque, modify
+                       token received from exporting process
+
+   context_handle    gss_ctx_id_t, modify
+                     context handle of newly reactivated context.
+                     Resources associated with this context handle
+                     must be released by the application after use
+                     with a call to gss_delete_sec_context().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion.
+
+   GSS_S_NO_CONTEXT  The token did not contain a valid context
+   reference.
+
+   GSS_S_DEFECTIVE_TOKEN The token was invalid.
+
+   GSS_S_UNAVAILABLE The operation is unavailable.
+
+   GSS_S_UNAUTHORIZED Local policy prevents the import of this context
+                      by the current process.
+
+5.18. gss_indicate_mechs
+
+   OM_uint32 gss_indicate_mechs (
+     OM_uint32   *minor_status,
+     gss_OID_set *mech_set)
+
+
+
+
+
+Wray                        Standards Track                    [Page 54]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Purpose:
+
+   Allows an application to determine which underlying security
+   mechanisms are available.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   mech_set          set of Object IDs, modify
+                     set of implementation-supported mechanisms.
+                     The returned gss_OID_set value will be a
+                     dynamically-allocated OID set, that should
+                     be released by the caller after use with a
+                     call to gss_release_oid_set().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+5.19. gss_init_sec_context
+
+   OM_uint32 gss_init_sec_context (
+     OM_uint32                    *minor_status,
+     const gss_cred_id_t          initiator_cred_handle,
+     gss_ctx_id_t                 *context_handle,\
+     const gss_name_t             target_name,
+     const gss_OID                mech_type,
+     OM_uint32                    req_flags,
+     OM_uint32                    time_req,
+     const gss_channel_bindings_t input_chan_bindings,
+     const gss_buffer_t           input_token
+     gss_OID                      *actual_mech_type,
+     gss_buffer_t                 output_token,
+     OM_uint32                    *ret_flags,
+     OM_uint32                    *time_rec )
+
+   Purpose:
+
+   Initiates the establishment of a security context between the
+   application and a remote peer.  Initially, the input_token parameter
+   should be specified either as GSS_C_NO_BUFFER, or as a pointer to a
+   gss_buffer_desc object whose length field contains the value zero.
+   The routine may return a output_token which should be transferred to
+   the peer application, where the peer application will present it to
+   gss_accept_sec_context.  If no token need be sent,
+   gss_init_sec_context will indicate this by setting the length field
+
+
+
+Wray                        Standards Track                    [Page 55]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   of the output_token argument to zero. To complete the context
+   establishment, one or more reply tokens may be required from the peer
+   application; if so, gss_init_sec_context will return a status
+   containing the supplementary information bit GSS_S_CONTINUE_NEEDED.
+   In this case, gss_init_sec_context should be called again when the
+   reply token is received from the peer application, passing the reply
+   token to gss_init_sec_context via the input_token parameters.
+
+   Portable applications should be constructed to use the token length
+   and return status to determine whether a token needs to be sent or
+   waited for.  Thus a typical portable caller should always invoke
+   gss_init_sec_context within a loop:
+
+   int context_established = 0;
+   gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT;
+          ...
+   input_token->length = 0;
+
+   while (!context_established) {
+     maj_stat = gss_init_sec_context(&min_stat,
+                                     cred_hdl,
+                                     &context_hdl,
+                                     target_name,
+                                     desired_mech,
+                                     desired_services,
+                                     desired_time,
+                                     input_bindings,
+                                     input_token,
+                                     &actual_mech,
+                                     output_token,
+                                     &actual_services,
+                                     &actual_time);
+     if (GSS_ERROR(maj_stat)) {
+       report_error(maj_stat, min_stat);
+     };
+
+     if (output_token->length != 0) {
+       send_token_to_peer(output_token);
+       gss_release_buffer(&min_stat, output_token)
+     };
+     if (GSS_ERROR(maj_stat)) {
+
+       if (context_hdl != GSS_C_NO_CONTEXT)
+         gss_delete_sec_context(&min_stat,
+                                &context_hdl,
+                                GSS_C_NO_BUFFER);
+       break;
+     };
+
+
+
+Wray                        Standards Track                    [Page 56]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+     if (maj_stat & GSS_S_CONTINUE_NEEDED) {
+       receive_token_from_peer(input_token);
+     } else {
+       context_established = 1;
+     };
+   };
+
+   Whenever the routine returns a major status that includes the value
+   GSS_S_CONTINUE_NEEDED, the context is not fully established and the
+   following restrictions apply to the output parameters:
+
+      The value returned via the time_rec parameter is undefined Unless
+      the accompanying ret_flags parameter contains the bit
+      GSS_C_PROT_READY_FLAG, indicating that per-message services may be
+      applied in advance of a successful completion status, the value
+      returned via the actual_mech_type parameter is undefined until the
+      routine returns a major status value of GSS_S_COMPLETE.
+
+      The values of the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
+      GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG, GSS_C_CONF_FLAG,
+      GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned via the
+      ret_flags parameter should contain the values that the
+      implementation expects would be valid if context establishment
+      were to succeed.  In particular, if the application has requested
+      a service such as delegation or anonymous authentication via the
+      req_flags argument, and such a service is unavailable from the
+      underlying mechanism, gss_init_sec_context should generate a token
+      that will not provide the service, and indicate via the ret_flags
+      argument that the service will not be supported.  The application
+      may choose to abort the context establishment by calling
+      gss_delete_sec_context (if it cannot continue in the absence of
+      the service), or it may choose to transmit the token and continue
+      context establishment (if the service was merely desired but not
+      mandatory).
+
+      The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits
+      within ret_flags should indicate the actual state at the time
+      gss_init_sec_context returns, whether or not the context is fully
+      established.
+
+      GSS-API implementations that support per-message protection are
+      encouraged to set the GSS_C_PROT_READY_FLAG in the final ret_flags
+      returned to a caller (i.e. when accompanied by a GSS_S_COMPLETE
+      status code).  However, applications should not rely on this
+      behavior as the flag was not defined in Version 1 of the GSS-API.
+      Instead, applications should determine what per-message services
+      are available after a successful context establishment according
+      to the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG values.
+
+
+
+Wray                        Standards Track                    [Page 57]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+      All other bits within the ret_flags argument should be set to
+      zero.
+
+   If the initial call of gss_init_sec_context() fails, the
+   implementation should not create a context object, and should leave
+   the value of the context_handle parameter set to GSS_C_NO_CONTEXT to
+   indicate this.  In the event of a failure on a subsequent call, the
+   implementation is permitted to delete the "half-built" security
+   context (in which case it should set the context_handle parameter to
+   GSS_C_NO_CONTEXT), but the preferred behavior is to leave the
+   security context untouched for the application to delete (using
+   gss_delete_sec_context).
+
+   During context establishment, the informational status bits
+   GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN indicate fatal errors, and
+   GSS-API mechanisms should always return them in association with a
+   routine error of GSS_S_FAILURE.  This requirement for pairing did not
+   exist in version 1 of the GSS-API specification, so applications that
+   wish to run over version 1 implementations must special-case these
+   codes.
+
+   Parameters:
+
+   minor_status      Integer,  modify
+                     Mechanism specific status code.
+
+   initiator_cred_handle  gss_cred_id_t, read, optional
+                          handle for credentials claimed.  Supply
+                          GSS_C_NO_CREDENTIAL to act as a default
+                          initiator principal.  If no default
+                          initiator is defined, the function will
+                          return GSS_S_NO_CRED.
+
+   context_handle    gss_ctx_id_t, read/modify
+                     context handle for new context.  Supply
+                     GSS_C_NO_CONTEXT for first call; use value
+                     returned by first call in continuation calls.
+                     Resources associated with this context-handle
+                     must be released by the application after use
+                     with a call to gss_delete_sec_context().
+
+   target_name       gss_name_t, read
+                     Name of target
+
+   mech_type         OID, read, optional
+                     Object ID of desired mechanism. Supply
+                     GSS_C_NO_OID to obtain an implementation
+                     specific default
+
+
+
+Wray                        Standards Track                    [Page 58]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   req_flags         bit-mask, read
+                     Contains various independent flags, each of
+                     which requests that the context support a
+                     specific service option.  Symbolic
+                     names are provided for each flag, and the
+                     symbolic names corresponding to the required
+                     flags should be logically-ORed
+                     together to form the bit-mask value.  The
+                     flags are:
+
+                     GSS_C_DELEG_FLAG
+                       True - Delegate credentials to remote peer
+                       False - Don't delegate
+
+                     GSS_C_MUTUAL_FLAG
+                       True - Request that remote peer
+                              authenticate itself
+                       False - Authenticate self to remote peer
+                               only
+
+                     GSS_C_REPLAY_FLAG
+                       True - Enable replay detection for
+                              messages protected with gss_wrap
+                              or gss_get_mic
+                       False - Don't attempt to detect
+                               replayed messages
+
+                     GSS_C_SEQUENCE_FLAG
+                       True - Enable detection of out-of-sequence
+                              protected messages
+                       False - Don't attempt to detect
+                               out-of-sequence messages
+
+                     GSS_C_CONF_FLAG
+                       True - Request that confidentiality service
+                              be made available (via gss_wrap)
+                       False - No per-message confidentiality service
+                               is required.
+
+                     GSS_C_INTEG_FLAG
+                       True - Request that integrity service be
+                              made available (via gss_wrap or
+                              gss_get_mic)
+                       False - No per-message integrity service
+                               is required.
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 59]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                     GSS_C_ANON_FLAG
+                       True - Do not reveal the initiator's
+                              identity to the acceptor.
+                       False - Authenticate normally.
+
+   time_req          Integer, read, optional
+                     Desired number of seconds for which context
+                     should remain valid.  Supply 0 to request a
+                     default validity period.
+
+   input_chan_bindings  channel bindings, read, optional
+                        Application-specified bindings.  Allows
+                        application to securely bind channel
+                        identification information to the security
+                        context.  Specify GSS_C_NO_CHANNEL_BINDINGS
+                        if channel bindings are not used.
+
+   input_token       buffer, opaque, read, optional (see text)
+                     Token received from peer application.
+                     Supply GSS_C_NO_BUFFER, or a pointer to
+                     a buffer containing the value GSS_C_EMPTY_BUFFER
+                     on initial call.
+
+   actual_mech_type  OID, modify, optional
+                     Actual mechanism used.  The OID returned via
+                     this parameter will be a pointer to static
+                     storage that should be treated as read-only;
+                     In particular the application should not attempt
+                     to free it.  Specify NULL if not required.
+
+   output_token      buffer, opaque, modify
+                     token to be sent to peer application.  If
+                     the length field of the returned buffer is
+                     zero, no token need be sent to the peer
+                     application.  Storage associated with this
+                     buffer must be freed by the application
+                     after use with a call to gss_release_buffer().
+
+   ret_flags         bit-mask, modify, optional
+                     Contains various independent flags, each of which
+                     indicates that the context supports a specific
+                     service option.  Specify NULL if not
+                     required.  Symbolic names are provided
+                     for each flag, and the symbolic names
+                     corresponding to the required flags should be
+                     logically-ANDed with the ret_flags value to test
+                     whether a given option is supported by the
+                     context.  The flags are:
+
+
+
+Wray                        Standards Track                    [Page 60]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                     GSS_C_DELEG_FLAG
+                       True - Credentials were delegated to
+                              the remote peer
+                       False - No credentials were delegated
+
+                     GSS_C_MUTUAL_FLAG
+                       True - The remote peer has authenticated
+                              itself.
+                       False - Remote peer has not authenticated
+                               itself.
+
+                     GSS_C_REPLAY_FLAG
+                       True - replay of protected messages
+                              will be detected
+                       False - replayed messages will not be
+                               detected
+
+                     GSS_C_SEQUENCE_FLAG
+                       True - out-of-sequence protected
+                              messages will be detected
+                       False - out-of-sequence messages will
+                               not be detected
+
+                     GSS_C_CONF_FLAG
+                       True - Confidentiality service may be
+                              invoked by calling gss_wrap routine
+                       False - No confidentiality service (via
+                               gss_wrap) available. gss_wrap will
+                               provide message encapsulation,
+                               data-origin authentication and
+                               integrity services only.
+
+                     GSS_C_INTEG_FLAG
+                       True - Integrity service may be invoked by
+                              calling either gss_get_mic or gss_wrap
+                              routines.
+                       False - Per-message integrity service
+                               unavailable.
+
+                     GSS_C_ANON_FLAG
+                       True - The initiator's identity has not been
+                              revealed, and will not be revealed if
+                              any emitted token is passed to the
+                              acceptor.
+                       False - The initiator's identity has been or
+                               will be authenticated normally.
+
+                     GSS_C_PROT_READY_FLAG
+
+
+
+Wray                        Standards Track                    [Page 61]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                       True - Protection services (as specified
+                              by the states of the GSS_C_CONF_FLAG
+                              and GSS_C_INTEG_FLAG) are available for
+                              use if the accompanying major status
+                              return value is either GSS_S_COMPLETE or
+                              GSS_S_CONTINUE_NEEDED.
+                       False - Protection services (as specified
+                               by the states of the GSS_C_CONF_FLAG
+                               and GSS_C_INTEG_FLAG) are available
+                               only if the accompanying major status
+                               return value is GSS_S_COMPLETE.
+
+                     GSS_C_TRANS_FLAG
+                       True - The resultant security context may
+                              be transferred to other processes via
+                              a call to gss_export_sec_context().
+                       False - The security context is not
+                               transferable.
+
+                     All other bits should be set to zero.
+
+   time_rec          Integer, modify, optional
+                     number of seconds for which the context
+                     will remain valid. If the implementation does
+                     not support context expiration, the value
+                     GSS_C_INDEFINITE will be returned.  Specify
+                     NULL if not required.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
+                         application is required to complete the
+                         context, and that gss_init_sec_context
+                         must be called again with that token.
+
+   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed
+                         on the input_token failed
+
+   GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
+                              performed on the credential failed.
+
+   GSS_S_NO_CRED     The supplied credentials were not valid for
+                     context initiation, or the credential handle
+                     did not reference any credentials.
+
+   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired
+
+
+
+Wray                        Standards Track                    [Page 62]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   GSS_S_BAD_BINDINGS The input_token contains different channel
+                      bindings to those specified via the
+                      input_chan_bindings parameter
+
+   GSS_S_BAD_SIG     The input_token contains an invalid MIC, or a MIC
+                     that could not be verified
+
+   GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal
+                     error during context establishment
+
+   GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate
+                         of a token already processed.  This is a
+                         fatal error during context establishment.
+
+   GSS_S_NO_CONTEXT  Indicates that the supplied context handle did
+                     not refer to a valid context
+
+   GSS_S_BAD_NAMETYPE The provided target_name parameter contained an
+                      invalid or unsupported type of name
+
+   GSS_S_BAD_NAME    The provided target_name parameter was ill-formed.
+
+   GSS_S_BAD_MECH    The specified mechanism is not supported by the
+                     provided credential, or is unrecognized by the
+                     implementation.
+
+5.20. gss_inquire_context
+
+   OM_uint32 gss_inquire_context (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     gss_name_t         *src_name,
+     gss_name_t         *targ_name,
+     OM_uint32          *lifetime_rec,
+     gss_OID            *mech_type,
+     OM_uint32          *ctx_flags,
+     int                *locally_initiated,
+     int                *open )
+
+   Purpose:
+
+   Obtains information about a security context.  The caller must
+   already have obtained a handle that refers to the context, although
+   the context need not be fully established.
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 63]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   context_handle    gss_ctx_id_t, read
+                     A handle that refers to the security context.
+
+   src_name          gss_name_t, modify, optional
+                     The name of the context initiator.
+                     If the context was established using anonymous
+                     authentication, and if the application invoking
+                     gss_inquire_context is the context acceptor,
+                     an anonymous name will be returned.  Storage
+                     associated with this name must be freed by the
+                     application after use with a call to
+                     gss_release_name().  Specify NULL if not
+                     required.
+
+   targ_name         gss_name_t, modify, optional
+                     The name of the context acceptor.
+                     Storage associated with this name must be
+                     freed by the application after use with a call
+                     to gss_release_name().  If the context acceptor
+                     did not authenticate itself, and if the initiator
+                     did not specify a target name in its call to
+                     gss_init_sec_context(), the value GSS_C_NO_NAME
+                     will be returned.  Specify NULL if not required.
+
+   lifetime_rec      Integer, modify, optional
+                     The number of seconds for which the context
+                     will remain valid.  If the context has
+                     expired, this parameter will be set to zero.
+                     If the implementation does not support
+                     context expiration, the value
+                     GSS_C_INDEFINITE will be returned.  Specify
+                     NULL if not required.
+
+   mech_type         gss_OID, modify, optional
+                     The security mechanism providing the
+                     context.  The returned OID will be a
+                     pointer to static storage that should
+                     be treated as read-only by the application;
+                     in particular the application should not
+                     attempt to free it.  Specify NULL if not
+                     required.
+
+
+
+
+
+Wray                        Standards Track                    [Page 64]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   ctx_flags         bit-mask, modify, optional
+                     Contains various independent flags, each of
+                     which indicates that the context supports
+                     (or is expected to support, if ctx_open is
+                     false) a specific service option.  If not
+                     needed, specify NULL.  Symbolic names are
+                     provided for each flag, and the symbolic names
+                     corresponding to the required flags
+                     should be logically-ANDed with the ret_flags
+                     value to test whether a given option is
+                     supported by the context.  The flags are:
+
+                     GSS_C_DELEG_FLAG
+                       True - Credentials were delegated from
+                              the initiator to the acceptor.
+                       False - No credentials were delegated
+
+                     GSS_C_MUTUAL_FLAG
+                       True - The acceptor was authenticated
+                              to the initiator
+                       False - The acceptor did not authenticate
+                               itself.
+
+                     GSS_C_REPLAY_FLAG
+                       True - replay of protected messages
+                              will be detected
+                       False - replayed messages will not be
+                               detected
+
+                     GSS_C_SEQUENCE_FLAG
+                       True - out-of-sequence protected
+                              messages will be detected
+                       False - out-of-sequence messages will not
+                               be detected
+
+                     GSS_C_CONF_FLAG
+                       True - Confidentiality service may be invoked
+                              by calling gss_wrap routine
+                       False - No confidentiality service (via
+                               gss_wrap) available. gss_wrap will
+                               provide message encapsulation,
+                               data-origin authentication and
+                               integrity services only.
+
+                     GSS_C_INTEG_FLAG
+                       True - Integrity service may be invoked by
+                              calling either gss_get_mic or gss_wrap
+                              routines.
+
+
+
+Wray                        Standards Track                    [Page 65]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                       False - Per-message integrity service
+                               unavailable.
+
+                     GSS_C_ANON_FLAG
+                       True - The initiator's identity will not
+                              be revealed to the acceptor.
+                              The src_name parameter (if
+                              requested) contains an anonymous
+                              internal name.
+                       False - The initiator has been
+                               authenticated normally.
+
+                     GSS_C_PROT_READY_FLAG
+                       True - Protection services (as specified
+                              by the states of the GSS_C_CONF_FLAG
+                              and GSS_C_INTEG_FLAG) are available
+                              for use.
+                       False - Protection services (as specified
+                               by the states of the GSS_C_CONF_FLAG
+                               and GSS_C_INTEG_FLAG) are available
+                               only if the context is fully
+                               established (i.e. if the open parameter
+                               is non-zero).
+
+                     GSS_C_TRANS_FLAG
+                       True - The resultant security context may
+                              be transferred to other processes via
+                              a call to gss_export_sec_context().
+                       False - The security context is not
+                               transferable.
+
+   locally_initiated Boolean, modify
+                     Non-zero if the invoking application is the
+                     context initiator.
+                     Specify NULL if not required.
+
+   open              Boolean, modify
+                     Non-zero if the context is fully established;
+                     Zero if a context-establishment token
+                     is expected from the peer application.
+                     Specify NULL if not required.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NO_CONTEXT  The referenced context could not be accessed.
+
+
+
+
+Wray                        Standards Track                    [Page 66]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.21. gss_inquire_cred
+
+   OM_uint32 gss_inquire_cred (
+     OM_uint32           *minor_status,
+     const gss_cred_id_t cred_handle,
+     gss_name_t          *name,
+     OM_uint32           *lifetime,
+     gss_cred_usage_t    *cred_usage,
+     gss_OID_set         *mechanisms )
+
+   Purpose:
+
+   Obtains information about a credential.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   cred_handle       gss_cred_id_t, read
+                     A handle that refers to the target credential.
+                     Specify GSS_C_NO_CREDENTIAL to inquire about
+                     the default initiator principal.
+
+   name              gss_name_t, modify, optional
+                     The name whose identity the credential asserts.
+                     Storage associated with this name should be freed
+                     by the application after use with a call to
+                     gss_release_name().  Specify NULL if not required.
+
+   lifetime          Integer, modify, optional
+                     The number of seconds for which the credential
+                     will remain valid.  If the credential has
+                     expired, this parameter will be set to zero.
+                     If the implementation does not support
+                     credential expiration, the value
+                     GSS_C_INDEFINITE will be returned.  Specify
+                     NULL if not required.
+
+   cred_usage        gss_cred_usage_t, modify, optional
+                     How the credential may be used.  One of the
+                     following:
+                     GSS_C_INITIATE
+                     GSS_C_ACCEPT
+                     GSS_C_BOTH
+                     Specify NULL if not required.
+
+
+
+
+
+Wray                        Standards Track                    [Page 67]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   mechanisms        gss_OID_set, modify, optional
+                     Set of mechanisms supported by the credential.
+                     Storage associated with this OID set must be
+                     freed by the application after use with a call
+                     to gss_release_oid_set().  Specify NULL if not
+                     required.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NO_CRED     The referenced credentials could not be accessed.
+
+   GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were invalid.
+
+   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
+                     If the lifetime parameter was not passed as NULL,
+                     it will be set to 0.
+
+5.22. gss_inquire_cred_by_mech
+
+   OM_uint32 gss_inquire_cred_by_mech (
+     OM_uint32           *minor_status,
+     const gss_cred_id_t cred_handle,
+     const gss_OID       mech_type,
+     gss_name_t          *name,
+     OM_uint32           *initiator_lifetime,
+     OM_uint32           *acceptor_lifetime,
+     gss_cred_usage_t    *cred_usage )
+
+   Purpose:
+
+   Obtains per-mechanism information about a credential.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   cred_handle       gss_cred_id_t, read
+                     A handle that refers to the target credential.
+                     Specify GSS_C_NO_CREDENTIAL to inquire about
+                     the default initiator principal.
+
+   mech_type         gss_OID, read
+                     The mechanism for which information should be
+                     returned.
+
+
+
+
+Wray                        Standards Track                    [Page 68]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   name              gss_name_t, modify, optional
+                     The name whose identity the credential asserts.
+                     Storage associated with this name must be
+                     freed by the application after use with a call
+                     to gss_release_name().  Specify NULL if not
+                     required.
+
+   initiator_lifetime  Integer, modify, optional
+                     The number of seconds for which the credential
+                     will remain capable of initiating security contexts
+                     under the specified mechanism.  If the credential
+                     can no longer be used to initiate contexts, or if
+                     the credential usage for this mechanism is
+                     GSS_C_ACCEPT, this parameter will be set to zero.
+                     If the implementation does not support expiration
+                     of initiator credentials, the value
+                     GSS_C_INDEFINITE will be returned.  Specify NULL
+                     if not required.
+
+   acceptor_lifetime Integer, modify, optional
+                     The number of seconds for which the credential
+                     will remain capable of accepting security contexts
+                     under the specified mechanism.  If the credential
+                     can no longer be used to accept contexts, or if
+                     the credential usage for this mechanism is
+                     GSS_C_INITIATE, this parameter will be set to zero.
+
+                     If the implementation does not support expiration
+                     of acceptor credentials, the value GSS_C_INDEFINITE
+                     will be returned.  Specify NULL if not required.
+
+   cred_usage        gss_cred_usage_t, modify, optional
+                     How the credential may be used with the specified
+                     mechanism.  One of the following:
+                       GSS_C_INITIATE
+                       GSS_C_ACCEPT
+                       GSS_C_BOTH
+                     Specify NULL if not required.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NO_CRED     The referenced credentials could not be accessed.
+
+   GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were invalid.
+
+
+
+
+
+Wray                        Standards Track                    [Page 69]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
+                    If the lifetime parameter was not passed as NULL,
+                    it will be set to 0.
+
+5.23. gss_inquire_mechs_for_name
+
+   OM_uint32 gss_inquire_mechs_for_name (
+     OM_uint32        *minor_status,
+     const gss_name_t input_name,
+     gss_OID_set      *mech_types )
+
+   Purpose:
+
+   Returns the set of mechanisms supported by the GSS-API implementation
+   that may be able to process the specified name.
+
+   Each mechanism returned will recognize at least one element within
+   the name.  It is permissible for this routine to be implemented
+   within a mechanism-independent GSS-API layer, using the type
+   information contained within the presented name, and based on
+   registration information provided by individual mechanism
+   implementations.  This means that the returned mech_types set may
+   indicate that a particular mechanism will understand the name when in
+   fact it would refuse to accept the name as input to
+   gss_canonicalize_name, gss_init_sec_context, gss_acquire_cred or
+   gss_add_cred (due to some property of the specific name, as opposed
+   to the name type).  Thus this routine should be used only as a pre-
+   filter for a call to a subsequent mechanism-specific routine.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Implementation specific status code.
+
+   input_name        gss_name_t, read
+                     The name to which the inquiry relates.
+
+   mech_types        gss_OID_set, modify
+                     Set of mechanisms that may support the
+                     specified name.  The returned OID set
+                     must be freed by the caller after use
+                     with a call to gss_release_oid_set().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_NAME    The input_name parameter was ill-formed.
+
+
+
+Wray                        Standards Track                    [Page 70]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   GSS_S_BAD_NAMETYPE The input_name parameter contained an invalid or
+                      unsupported type of name
+
+5.24. gss_inquire_names_for_mech
+
+   OM_uint32 gss_inquire_names_for_mech (
+     OM_uint32     *minor_status,
+     const gss_OID mechanism,
+     gss_OID_set   *name_types)
+
+   Purpose:
+
+   Returns the set of nametypes supported by the specified mechanism.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Implementation specific status code.
+
+   mechanism         gss_OID, read
+                     The mechanism to be interrogated.
+
+   name_types        gss_OID_set, modify
+                     Set of name-types supported by the specified
+                     mechanism.  The returned OID set must be
+                     freed by the application after use with a
+                     call to gss_release_oid_set().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+5.25. gss_process_context_token
+
+   OM_uint32 gss_process_context_token (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     const gss_buffer_t token_buffer)
+
+        Purpose:
+
+   Provides a way to pass an asynchronous token to the security service.
+   Most context-level tokens are emitted and processed synchronously by
+   gss_init_sec_context and gss_accept_sec_context, and the application
+   is informed as to whether further tokens are expected by the
+   GSS_C_CONTINUE_NEEDED major status bit.  Occasionally, a mechanism
+   may need to emit a context-level token at a point when the peer
+   entity is not expecting a token.  For example, the initiator's final
+
+
+
+Wray                        Standards Track                    [Page 71]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   call to gss_init_sec_context may emit a token and return a status of
+   GSS_S_COMPLETE, but the acceptor's call to gss_accept_sec_context may
+   fail.  The acceptor's mechanism may wish to send a token containing
+   an error indication to the initiator, but the initiator is not
+   expecting a token at this point, believing that the context is fully
+   established.  Gss_process_context_token provides a way to pass such a
+   token to the mechanism at any time.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Implementation specific status code.
+
+   context_handle    gss_ctx_id_t, read
+                     context handle of context on which token is to
+                     be processed
+
+   token_buffer      buffer, opaque, read
+                     token to process
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed
+                     on the token failed
+
+   GSS_S_NO_CONTEXT  The context_handle did not refer to a valid context
+
+5.26. gss_release_buffer
+
+   OM_uint32 gss_release_buffer (
+     OM_uint32    *minor_status,
+     gss_buffer_t buffer)
+
+   Purpose:
+
+   Free storage associated with a buffer.  The storage must have been
+   allocated by a GSS-API routine.  In addition to freeing the
+   associated storage, the routine will zero the length field in the
+   descriptor to which the buffer parameter refers, and implementations
+   are encouraged to additionally set the pointer field in the
+   descriptor to NULL.  Any buffer object returned by a GSS-API routine
+   may be passed to gss_release_buffer (even if there is no storage
+   associated with the buffer).
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 72]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   buffer            buffer, modify
+                     The storage associated with the buffer will be
+                     deleted.  The gss_buffer_desc object will not
+                     be freed, but its length field will be zeroed.
+
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+5.27. gss_release_cred
+
+   OM_uint32 gss_release_cred (
+     OM_uint32     *minor_status,
+     gss_cred_id_t *cred_handle)
+
+   Purpose:
+
+   Informs GSS-API that the specified credential handle is no longer
+   required by the application, and frees associated resources.
+   Implementations are encouraged to set the cred_handle to
+   GSS_C_NO_CREDENTIAL on successful completion of this call.
+
+   Parameters:
+
+   cred_handle       gss_cred_id_t, modify, optional
+                     Opaque handle identifying credential
+                     to be released.  If GSS_C_NO_CREDENTIAL
+                     is supplied, the routine will complete
+                     successfully, but will do nothing.
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NO_CRED     Credentials could not be accessed.
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 73]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.28. gss_release_name
+
+   OM_uint32 gss_release_name (
+     OM_uint32  *minor_status,
+     gss_name_t *name)
+
+   Purpose:
+
+   Free GSSAPI-allocated storage associated with an internal-form name.
+   Implementations are encouraged to set the name to GSS_C_NO_NAME on
+   successful completion of this call.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   name              gss_name_t, modify
+                     The name to be deleted
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_BAD_NAME    The name parameter did not contain a valid name
+
+5.29. gss_release_oid_set
+
+   OM_uint32 gss_release_oid_set (
+     OM_uint32   *minor_status,
+     gss_OID_set *set)
+
+   Purpose:
+
+   Free storage associated with a GSSAPI-generated gss_OID_set object.
+   The set parameter must refer to an OID-set that was returned from a
+   GSS-API routine.  gss_release_oid_set() will free the storage
+   associated with each individual member OID, the OID set's elements
+   array, and the gss_OID_set_desc.
+
+   Implementations are encouraged to set the gss_OID_set parameter to
+   GSS_C_NO_OID_SET on successful completion of this routine.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+
+
+
+Wray                        Standards Track                    [Page 74]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   set               Set of Object IDs, modify
+                     The storage associated with the gss_OID_set
+                     will be deleted.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+5.30. gss_test_oid_set_member
+
+   OM_uint32 gss_test_oid_set_member (
+     OM_uint32         *minor_status,
+     const gss_OID     member,
+     const gss_OID_set set,
+     int               *present)
+
+   Purpose:
+
+   Interrogate an Object Identifier set to determine whether a specified
+   Object Identifier is a member.  This routine is intended to be used
+   with OID sets returned by gss_indicate_mechs(), gss_acquire_cred(),
+   and gss_inquire_cred(), but will also work with user-generated sets.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   member            Object ID, read
+                     The object identifier whose presence
+                     is to be tested.
+
+   set               Set of Object ID, read
+                     The Object Identifier set.
+
+   present           Boolean, modify
+                     non-zero if the specified OID is a member
+                     of the set, zero if not.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 75]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.31. gss_unwrap
+
+   OM_uint32 gss_unwrap (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     const gss_buffer_t input_message_buffer,
+     gss_buffer_t       output_message_buffer,
+     int                *conf_state,
+     gss_qop_t          *qop_state)
+
+   Purpose:
+
+   Converts a message previously protected by gss_wrap back to a usable
+   form, verifying the embedded MIC.  The conf_state parameter indicates
+   whether the message was encrypted; the qop_state parameter indicates
+   the strength of protection that was used to provide the
+   confidentiality and integrity services.
+
+   Since some application-level protocols may wish to use tokens emitted
+   by gss_wrap() to provide "secure framing", implementations must
+   support the wrapping and unwrapping of zero-length messages.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   context_handle    gss_ctx_id_t, read
+                     Identifies the context on which the message
+                     arrived
+
+   input_message_buffer  buffer, opaque, read
+                     protected message
+
+   output_message_buffer  buffer, opaque, modify
+                     Buffer to receive unwrapped message.
+                     Storage associated with this buffer must
+                     be freed by the application after use use
+                     with a call to gss_release_buffer().
+
+   conf_state        boolean, modify, optional
+                     Non-zero - Confidentiality and integrity
+                                protection were used
+                     Zero - Integrity service only was used
+                     Specify NULL if not required
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 76]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   qop_state         gss_qop_t, modify, optional
+                     Quality of protection provided.
+                     Specify NULL if not required
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
+
+   GSS_S_BAD_SIG     The MIC was incorrect
+
+   GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
+                         MIC for the message, but it had already been
+                         processed
+
+   GSS_S_OLD_TOKEN   The token was valid, and contained a correct MIC
+                     for the message, but it is too old to check for
+                     duplication.
+
+   GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct MIC
+                     for the message, but has been verified out of
+                     sequence; a later token has already been
+                     received.
+
+   GSS_S_GAP_TOKEN   The token was valid, and contained a correct MIC
+                     for the message, but has been verified out of
+                     sequence; an earlier expected token has not yet
+                     been received.
+
+   GSS_S_CONTEXT_EXPIRED The context has already expired
+
+   GSS_S_NO_CONTEXT  The context_handle parameter did not identify
+                     a valid context
+
+5.32. gss_verify_mic
+
+   OM_uint32 gss_verify_mic (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     const gss_buffer_t message_buffer,
+     const gss_buffer_t token_buffer,
+     gss_qop_t          *qop_state)
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 77]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Purpose:
+
+   Verifies that a cryptographic MIC, contained in the token parameter,
+   fits the supplied message.  The qop_state parameter allows a message
+   recipient to determine the strength of protection that was applied to
+   the message.
+
+   Since some application-level protocols may wish to use tokens emitted
+   by gss_wrap() to provide "secure framing", implementations must
+   support the calculation and verification of MICs over zero-length
+   messages.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   context_handle    gss_ctx_id_t, read
+                     Identifies the context on which the message
+                     arrived
+
+   message_buffer    buffer, opaque, read
+                     Message to be verified
+
+   token_buffer      buffer, opaque, read
+                     Token associated with message
+
+   qop_state         gss_qop_t, modify, optional
+                     quality of protection gained from MIC
+                     Specify NULL if not required
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
+
+   GSS_S_BAD_SIG     The MIC was incorrect
+
+   GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
+                     MIC for the message, but it had already been
+                     processed
+
+   GSS_S_OLD_TOKEN   The token was valid, and contained a correct MIC
+                     for the message, but it is too old to check for
+                     duplication.
+
+
+
+
+
+Wray                        Standards Track                    [Page 78]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct MIC
+                     for the message, but has been verified out of
+                     sequence; a later token has already been received.
+
+   GSS_S_GAP_TOKEN   The token was valid, and contained a correct MIC
+                     for the message, but has been verified out of
+                     sequence; an earlier expected token has not yet
+                     been received.
+
+   GSS_S_CONTEXT_EXPIRED The context has already expired
+
+   GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
+                     valid context
+
+5.33. gss_wrap
+
+   OM_uint32 gss_wrap (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     int               conf_req_flag,
+     gss_qop_t          qop_req
+     const gss_buffer_t input_message_buffer,
+     int                *conf_state,
+     gss_buffer_t       output_message_buffer )
+
+   Purpose:
+
+   Attaches a cryptographic MIC and optionally encrypts the specified
+   input_message.  The output_message contains both the MIC and the
+   message.  The qop_req parameter allows a choice between several
+   cryptographic algorithms, if supported by the chosen mechanism.
+
+   Since some application-level protocols may wish to use tokens emitted
+   by gss_wrap() to provide "secure framing", implementations must
+   support the wrapping of zero-length messages.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code.
+
+   context_handle    gss_ctx_id_t, read
+                     Identifies the context on which the message
+                     will be sent
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 79]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   conf_req_flag     boolean, read
+                     Non-zero - Both confidentiality and integrity
+                                services are requested
+                     Zero - Only integrity service is requested
+
+   qop_req           gss_qop_t, read, optional
+                     Specifies required quality of protection.  A
+                     mechanism-specific default may be requested by
+                     setting qop_req to GSS_C_QOP_DEFAULT.  If an
+                     unsupported protection strength is requested,
+                     gss_wrap will return a major_status of
+                     GSS_S_BAD_QOP.
+
+   input_message_buffer  buffer, opaque, read
+                     Message to be protected
+
+   conf_state        boolean, modify, optional
+                     Non-zero - Confidentiality, data origin
+                                authentication and integrity
+                                services have been applied
+                     Zero - Integrity and data origin services only
+                            has been applied.
+                     Specify NULL if not required
+
+   output_message_buffer  buffer, opaque, modify
+                     Buffer to receive protected message.
+                     Storage associated with this message must
+                     be freed by the application after use with
+                     a call to gss_release_buffer().
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_CONTEXT_EXPIRED The context has already expired
+
+   GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
+                     valid context
+
+   GSS_S_BAD_QOP     The specified QOP is not supported by the
+                     mechanism.
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 80]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+5.34. gss_wrap_size_limit
+
+   OM_uint32 gss_wrap_size_limit (
+     OM_uint32          *minor_status,
+     const gss_ctx_id_t context_handle,
+     int                conf_req_flag,
+     gss_qop_t          qop_req,
+     OM_uint32          req_output_size,
+     OM_uint32          *max_input_size)
+
+   Purpose:
+
+   Allows an application to determine the maximum message size that, if
+   presented to gss_wrap with the same conf_req_flag and qop_req
+   parameters, will result in an output token containing no more than
+   req_output_size bytes.
+
+   This call is intended for use by applications that communicate over
+   protocols that impose a maximum message size.  It enables the
+   application to fragment messages prior to applying protection.
+
+   GSS-API implementations are recommended but not required to detect
+   invalid QOP values when gss_wrap_size_limit() is called. This routine
+   guarantees only a maximum message size, not the availability of
+   specific QOP values for message protection.
+
+   Successful completion of this call does not guarantee that gss_wrap
+   will be able to protect a message of length max_input_size bytes,
+   since this ability may depend on the availability of system resources
+   at the time that gss_wrap is called.  However, if the implementation
+   itself imposes an upper limit on the length of messages that may be
+   processed by gss_wrap, the implementation should not return a value
+   via max_input_bytes that is greater than this length.
+
+   Parameters:
+
+   minor_status      Integer, modify
+                     Mechanism specific status code
+
+   context_handle    gss_ctx_id_t, read
+                     A handle that refers to the security over
+                     which the messages will be sent.
+
+   conf_req_flag     Boolean, read
+                     Indicates whether gss_wrap will be asked
+                     to apply confidentiality protection in
+
+
+
+
+
+Wray                        Standards Track                    [Page 81]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+                     addition to integrity protection.  See
+                     the routine description for gss_wrap
+                     for more details.
+
+   qop_req           gss_qop_t, read
+                     Indicates the level of protection that
+                     gss_wrap will be asked to provide.  See
+                     the routine description for gss_wrap for
+                     more details.
+
+   req_output_size   Integer, read
+                     The desired maximum size for tokens emitted
+                     by gss_wrap.
+
+   max_input_size    Integer, modify
+                     The maximum input message size that may
+                     be presented to gss_wrap in order to
+                     guarantee that the emitted token shall
+                     be no larger than req_output_size bytes.
+
+   Function value:   GSS status code
+
+   GSS_S_COMPLETE    Successful completion
+
+   GSS_S_NO_CONTEXT  The referenced context could not be accessed.
+
+   GSS_S_CONTEXT_EXPIRED The context has expired.
+
+   GSS_S_BAD_QOP     The specified QOP is not supported by the
+                     mechanism.
+
+6.   Security Considerations
+
+   This document specifies a service interface for security facilities
+   and services; as such, security considerations appear throughout the
+   specification. Nonetheless, it is appropriate to summarize certain
+   specific points relevant to GSS-API implementors and calling
+   applications. Usage of the GSS-API interface does not in itself
+   provide security services or assurance; instead, these attributes are
+   dependent on the underlying mechanism(s) which support a GSS-API
+   implementation. Callers must be attentive to the requests made to
+   GSS-API calls and to the status indicators returned by GSS-API, as
+   these specify the security service characteristics which GSS-API will
+   provide. When the interprocess context transfer facility is used,
+   appropriate local controls should be applied to constrain access to
+   interprocess tokens and to the sensitive data which they contain.
+
+
+
+
+
+Wray                        Standards Track                    [Page 82]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   Appendix A. GSS-API C header file gssapi.h
+
+   C-language GSS-API implementations should include a copy of the
+   following header-file.
+
+   #ifndef GSSAPI_H_
+   #define GSSAPI_H_
+
+
+
+   /*
+    * First, include stddef.h to get size_t defined.
+    */
+   #include <stddef.h>
+
+   /*
+    * If the platform supports the xom.h header file, it should be
+    * included here.
+    */
+   #include <xom.h>
+
+
+   /*
+    * Now define the three implementation-dependent types.
+    */
+   typedef <platform-specific> gss_ctx_id_t;
+   typedef <platform-specific> gss_cred_id_t;
+   typedef <platform-specific> gss_name_t;
+
+   /*
+    * The following type must be defined as the smallest natural
+    * unsigned integer supported by the platform that has at least
+    * 32 bits of precision.
+    */
+   typedef <platform-specific> gss_uint32;
+
+
+   #ifdef OM_STRING
+   /*
+    * We have included the xom.h header file.  Verify that OM_uint32
+    * is defined correctly.
+    */
+
+   #if sizeof(gss_uint32) != sizeof(OM_uint32)
+   #error Incompatible definition of OM_uint32 from xom.h
+   #endif
+
+   typedef OM_object_identifier gss_OID_desc, *gss_OID;
+
+
+
+Wray                        Standards Track                    [Page 83]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   #else
+
+   /*
+    * We can't use X/Open definitions, so roll our own.
+    */
+
+   typedef gss_uint32 OM_uint32;
+
+   typedef struct gss_OID_desc_struct {
+     OM_uint32 length;
+     void      *elements;
+   } gss_OID_desc, *gss_OID;
+
+   #endif
+
+   typedef struct gss_OID_set_desc_struct  {
+     size_t     count;
+     gss_OID    elements;
+   } gss_OID_set_desc, *gss_OID_set;
+
+   typedef struct gss_buffer_desc_struct {
+     size_t length;
+     void *value;
+   } gss_buffer_desc, *gss_buffer_t;
+
+   typedef struct gss_channel_bindings_struct {
+     OM_uint32 initiator_addrtype;
+     gss_buffer_desc initiator_address;
+     OM_uint32 acceptor_addrtype;
+     gss_buffer_desc acceptor_address;
+     gss_buffer_desc application_data;
+   } *gss_channel_bindings_t;
+
+   /*
+    * For now, define a QOP-type as an OM_uint32
+    */
+   typedef OM_uint32 gss_qop_t;
+
+   typedef int gss_cred_usage_t;
+
+   /*
+    * Flag bits for context-level services.
+    */
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 84]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   #define GSS_C_DELEG_FLAG      1
+   #define GSS_C_MUTUAL_FLAG     2
+   #define GSS_C_REPLAY_FLAG     4
+   #define GSS_C_SEQUENCE_FLAG   8
+   #define GSS_C_CONF_FLAG       16
+   #define GSS_C_INTEG_FLAG      32
+   #define GSS_C_ANON_FLAG       64
+   #define GSS_C_PROT_READY_FLAG 128
+   #define GSS_C_TRANS_FLAG      256
+
+   /*
+    * Credential usage options
+    */
+   #define GSS_C_BOTH     0
+   #define GSS_C_INITIATE 1
+   #define GSS_C_ACCEPT   2
+
+   /*
+    * Status code types for gss_display_status
+    */
+   #define GSS_C_GSS_CODE  1
+   #define GSS_C_MECH_CODE 2
+
+   /*
+    * The constant definitions for channel-bindings address families
+    */
+   #define GSS_C_AF_UNSPEC     0
+   #define GSS_C_AF_LOCAL      1
+   #define GSS_C_AF_INET       2
+   #define GSS_C_AF_IMPLINK    3
+   #define GSS_C_AF_PUP        4
+   #define GSS_C_AF_CHAOS      5
+   #define GSS_C_AF_NS         6
+   #define GSS_C_AF_NBS        7
+   #define GSS_C_AF_ECMA       8
+   #define GSS_C_AF_DATAKIT    9
+   #define GSS_C_AF_CCITT      10
+   #define GSS_C_AF_SNA        11
+   #define GSS_C_AF_DECnet     12
+   #define GSS_C_AF_DLI        13
+   #define GSS_C_AF_LAT        14
+   #define GSS_C_AF_HYLINK     15
+   #define GSS_C_AF_APPLETALK  16
+   #define GSS_C_AF_BSC        17
+   #define GSS_C_AF_DSS        18
+   #define GSS_C_AF_OSI        19
+   #define GSS_C_AF_X25        21
+
+
+
+
+Wray                        Standards Track                    [Page 85]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   #define GSS_C_AF_NULLADDR   255
+
+   /*
+    * Various Null values
+    */
+   #define GSS_C_NO_NAME ((gss_name_t) 0)
+   #define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
+   #define GSS_C_NO_OID ((gss_OID) 0)
+   #define GSS_C_NO_OID_SET ((gss_OID_set) 0)
+   #define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
+   #define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
+   #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
+   #define GSS_C_EMPTY_BUFFER {0, NULL}
+
+   /*
+    * Some alternate names for a couple of the above
+    * values.  These are defined for V1 compatibility.
+    */
+   #define GSS_C_NULL_OID GSS_C_NO_OID
+   #define GSS_C_NULL_OID_SET GSS_C_NO_OID_SET
+
+   /*
+    * Define the default Quality of Protection for per-message
+    * services.  Note that an implementation that offers multiple
+    * levels of QOP may define GSS_C_QOP_DEFAULT to be either zero
+    * (as done here) to mean "default protection", or to a specific
+    * explicit QOP value.  However, a value of 0 should always be
+    * interpreted by a GSS-API implementation as a request for the
+    * default protection level.
+    */
+   #define GSS_C_QOP_DEFAULT 0
+
+   /*
+    * Expiration time of 2^32-1 seconds means infinite lifetime for a
+    * credential or security context
+    */
+   #define GSS_C_INDEFINITE 0xfffffffful
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
+    * "\x01\x02\x01\x01"},
+    * corresponding to an object-identifier value of
+    * {iso(1) member-body(2) United States(840) mit(113554)
+    * infosys(1) gssapi(2) generic(1) user_name(1)}.  The constant
+    * GSS_C_NT_USER_NAME should be initialized to point
+    * to that gss_OID_desc.
+
+
+
+Wray                        Standards Track                    [Page 86]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+    */
+   extern gss_OID GSS_C_NT_USER_NAME;
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
+    *              "\x01\x02\x01\x02"},
+    * corresponding to an object-identifier value of
+    * {iso(1) member-body(2) United States(840) mit(113554)
+    * infosys(1) gssapi(2) generic(1) machine_uid_name(2)}.
+    * The constant GSS_C_NT_MACHINE_UID_NAME should be
+    * initialized to point to that gss_OID_desc.
+    */
+   extern gss_OID GSS_C_NT_MACHINE_UID_NAME;
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
+    *              "\x01\x02\x01\x03"},
+    * corresponding to an object-identifier value of
+    * {iso(1) member-body(2) United States(840) mit(113554)
+    * infosys(1) gssapi(2) generic(1) string_uid_name(3)}.
+    * The constant GSS_C_NT_STRING_UID_NAME should be
+    * initialized to point to that gss_OID_desc.
+    */
+   extern gss_OID GSS_C_NT_STRING_UID_NAME;
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {6, (void *)"\x2b\x06\x01\x05\x06\x02"},
+    * corresponding to an object-identifier value of
+    * {iso(1) org(3) dod(6) internet(1) security(5)
+    * nametypes(6) gss-host-based-services(2)).  The constant
+    * GSS_C_NT_HOSTBASED_SERVICE_X should be initialized to point
+    * to that gss_OID_desc.  This is a deprecated OID value, and
+    * implementations wishing to support hostbased-service names
+    * should instead use the GSS_C_NT_HOSTBASED_SERVICE OID,
+    * defined below, to identify such names;
+    * GSS_C_NT_HOSTBASED_SERVICE_X should be accepted a synonym
+    * for GSS_C_NT_HOSTBASED_SERVICE when presented as an input
+    * parameter, but should not be emitted by GSS-API
+    * implementations
+    */
+   extern gss_OID GSS_C_NT_HOSTBASED_SERVICE_X;
+
+
+
+
+Wray                        Standards Track                    [Page 87]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
+    *              "\x01\x02\x01\x04"}, corresponding to an
+    * object-identifier value of {iso(1) member-body(2)
+    * Unites States(840) mit(113554) infosys(1) gssapi(2)
+    * generic(1) service_name(4)}.  The constant
+    * GSS_C_NT_HOSTBASED_SERVICE should be initialized
+    * to point to that gss_OID_desc.
+    */
+   extern gss_OID GSS_C_NT_HOSTBASED_SERVICE;
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {6, (void *)"\x2b\x06\01\x05\x06\x03"},
+    * corresponding to an object identifier value of
+    * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
+    * 6(nametypes), 3(gss-anonymous-name)}.  The constant
+    * and GSS_C_NT_ANONYMOUS should be initialized to point
+    * to that gss_OID_desc.
+    */
+   extern gss_OID GSS_C_NT_ANONYMOUS;
+
+
+   /*
+    * The implementation must reserve static storage for a
+    * gss_OID_desc object containing the value
+    * {6, (void *)"\x2b\x06\x01\x05\x06\x04"},
+    * corresponding to an object-identifier value of
+    * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
+    * 6(nametypes), 4(gss-api-exported-name)}.  The constant
+    * GSS_C_NT_EXPORT_NAME should be initialized to point
+    * to that gss_OID_desc.
+    */
+   extern gss_OID GSS_C_NT_EXPORT_NAME;
+
+
+   /* Major status codes */
+
+   #define GSS_S_COMPLETE 0
+
+   /*
+    * Some "helper" definitions to make the status code macros obvious.
+    */
+   #define GSS_C_CALLING_ERROR_OFFSET 24
+   #define GSS_C_ROUTINE_ERROR_OFFSET 16
+
+
+
+Wray                        Standards Track                    [Page 88]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   #define GSS_C_SUPPLEMENTARY_OFFSET 0
+   #define GSS_C_CALLING_ERROR_MASK 0377ul
+   #define GSS_C_ROUTINE_ERROR_MASK 0377ul
+   #define GSS_C_SUPPLEMENTARY_MASK 0177777ul
+
+   /*
+    * The macros that test status codes for error conditions.
+    * Note that the GSS_ERROR() macro has changed slightly from
+    * the V1 GSS-API so that it now evaluates its argument
+    * only once.
+    */
+   #define GSS_CALLING_ERROR(x) \
+    (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
+   #define GSS_ROUTINE_ERROR(x) \
+    (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
+   #define GSS_SUPPLEMENTARY_INFO(x) \
+    (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
+   #define GSS_ERROR(x) \
+    (x & ((GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET) | \
+          (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET)))
+
+   /*
+    * Now the actual status code definitions
+    */
+
+   /*
+    * Calling errors:
+
+    */
+   #define GSS_S_CALL_INACCESSIBLE_READ \
+   (1ul << GSS_C_CALLING_ERROR_OFFSET)
+   #define GSS_S_CALL_INACCESSIBLE_WRITE \
+   (2ul << GSS_C_CALLING_ERROR_OFFSET)
+   #define GSS_S_CALL_BAD_STRUCTURE \
+   (3ul << GSS_C_CALLING_ERROR_OFFSET)
+
+   /*
+    * Routine errors:
+    */
+   #define GSS_S_BAD_MECH             (1ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_NAME             (2ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_NAMETYPE         (3ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_BINDINGS         (4ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_STATUS           (5ul <<
+
+
+
+Wray                        Standards Track                    [Page 89]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_SIG              (6ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_MIC GSS_S_BAD_SIG
+   #define GSS_S_NO_CRED              (7ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_NO_CONTEXT           (8ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_DEFECTIVE_TOKEN      (9ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_DEFECTIVE_CREDENTIAL (10ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_CREDENTIALS_EXPIRED  (11ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_CONTEXT_EXPIRED      (12ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_FAILURE              (13ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_BAD_QOP              (14ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_UNAUTHORIZED         (15ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_UNAVAILABLE          (16ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_DUPLICATE_ELEMENT    (17ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+   #define GSS_S_NAME_NOT_MN          (18ul <<
+   GSS_C_ROUTINE_ERROR_OFFSET)
+
+   /*
+    * Supplementary info bits:
+    */
+   #define GSS_S_CONTINUE_NEEDED \
+            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
+   #define GSS_S_DUPLICATE_TOKEN \
+            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
+   #define GSS_S_OLD_TOKEN \
+            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
+   #define GSS_S_UNSEQ_TOKEN \
+            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
+   #define GSS_S_GAP_TOKEN \
+            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 4))
+
+   /*
+    * Finally, function prototypes for the GSS-API routines.
+    */
+
+
+
+
+
+Wray                        Standards Track                    [Page 90]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   OM_uint32 gss_acquire_cred
+                 (OM_uint32 ,             /*  minor_status */
+                  const gss_name_t,       /* desired_name */
+                  OM_uint32,              /* time_req */
+                  const gss_OID_set,      /* desired_mechs */
+                  gss_cred_usage_t,       /* cred_usage */
+                  gss_cred_id_t ,         /* output_cred_handle */
+                  gss_OID_set ,           /* actual_mechs */
+                  OM_uint32 *             /* time_rec */
+                 );
+
+   OM_uint32 gss_release_cred
+                 (OM_uint32 ,             /* minor_status */
+                  gss_cred_id_t *         /* cred_handle */
+                 );
+
+   OM_uint32 gss_init_sec_context
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_cred_id_t,    /* initiator_cred_handle */
+                  gss_ctx_id_t ,          /* context_handle */
+                  const gss_name_t,       /* target_name */
+                  const gss_OID,          /* mech_type */
+                  OM_uint32,              /* req_flags */
+                  OM_uint32,              /* time_req */
+                  const gss_channel_bindings_t,
+                                          /* input_chan_bindings */
+                  const gss_buffer_t,     /* input_token */
+                  gss_OID ,               /* actual_mech_type */
+                  gss_buffer_t,           /* output_token */
+                  OM_uint32 ,             /* ret_flags */
+                  OM_uint32 *             /* time_rec */
+                 );
+
+   OM_uint32 gss_accept_sec_context
+                 (OM_uint32 ,             /* minor_status */
+                  gss_ctx_id_t ,          /* context_handle */
+                  const gss_cred_id_t,    /* acceptor_cred_handle */
+                  const gss_buffer_t,     /* input_token_buffer */
+                  const gss_channel_bindings_t,
+                                          /* input_chan_bindings */
+                  gss_name_t ,            /* src_name */
+                  gss_OID ,               /* mech_type */
+                  gss_buffer_t,           /* output_token */
+                  OM_uint32 ,             /* ret_flags */
+                  OM_uint32 ,             /* time_rec */
+                  gss_cred_id_t *         /* delegated_cred_handle */
+                 );
+
+
+
+
+Wray                        Standards Track                    [Page 91]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   OM_uint32 gss_process_context_token
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  const gss_buffer_t      /* token_buffer */
+                 );
+
+   OM_uint32 gss_delete_sec_context
+                 (OM_uint32 ,             /* minor_status */
+                  gss_ctx_id_t ,          /* context_handle */
+                  gss_buffer_t            /* output_token */
+                 );
+
+   OM_uint32 gss_context_time
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  OM_uint32 *             /* time_rec */
+                 );
+
+   OM_uint32 gss_get_mic
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  gss_qop_t,              /* qop_req */
+                  const gss_buffer_t,     /* message_buffer */
+                  gss_buffer_t            /* message_token */
+                 );
+
+   OM_uint32 gss_verify_mic
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  const gss_buffer_t,     /* message_buffer */
+                  const gss_buffer_t,     /* token_buffer */
+                  gss_qop_t *             /* qop_state */
+                 );
+
+   OM_uint32 gss_wrap
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  int,                    /* conf_req_flag */
+                  gss_qop_t,              /* qop_req */
+                  const gss_buffer_t,     /* input_message_buffer */
+                  int ,                   /* conf_state */
+                  gss_buffer_t            /* output_message_buffer */
+                 );
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 92]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   OM_uint32 gss_unwrap
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  const gss_buffer_t,     /* input_message_buffer */
+                  gss_buffer_t,           /* output_message_buffer */
+                  int ,                   /* conf_state */
+                  gss_qop_t *             /* qop_state */
+                 );
+
+
+
+   OM_uint32 gss_display_status
+                 (OM_uint32 ,             /* minor_status */
+                  OM_uint32,              /* status_value */
+                  int,                    /* status_type */
+                  const gss_OID,          /* mech_type */
+                  OM_uint32 ,             /* message_context */
+                  gss_buffer_t            /* status_string */
+                 );
+
+   OM_uint32 gss_indicate_mechs
+                 (OM_uint32 ,             /* minor_status */
+                  gss_OID_set *           /* mech_set */
+                 );
+
+   OM_uint32 gss_compare_name
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_name_t,       /* name1 */
+                  const gss_name_t,       /* name2 */
+                  int *                   /* name_equal */
+                 );
+
+   OM_uint32 gss_display_name
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_name_t,       /* input_name */
+                  gss_buffer_t,           /* output_name_buffer */
+                  gss_OID *               /* output_name_type */
+                 );
+
+   OM_uint32 gss_import_name
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_buffer_t,     /* input_name_buffer */
+                  const gss_OID,          /* input_name_type */
+                  gss_name_t *            /* output_name */
+                 );
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 93]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   OM_uint32 gss_export_name
+                 (OM_uint32,              /* minor_status */
+                  const gss_name_t,       /* input_name */
+                  gss_buffer_t            /* exported_name */
+                 );
+
+   OM_uint32 gss_release_name
+                 (OM_uint32 *,            /* minor_status */
+                  gss_name_t *            /* input_name */
+                 );
+
+   OM_uint32 gss_release_buffer
+                 (OM_uint32 ,             /* minor_status */
+                  gss_buffer_t            /* buffer */
+                 );
+
+   OM_uint32 gss_release_oid_set
+                 (OM_uint32 ,             /* minor_status */
+                  gss_OID_set *           /* set */
+                 );
+
+   OM_uint32 gss_inquire_cred
+                 (OM_uint32 ,             /* minor_status */
+                  const gss_cred_id_t,    /* cred_handle */
+                  gss_name_t ,            /* name */
+                  OM_uint32 ,             /* lifetime */
+                  gss_cred_usage_t ,      /* cred_usage */
+                  gss_OID_set *           /* mechanisms */
+                 );
+
+   OM_uint32 gss_inquire_context (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  gss_name_t ,            /* src_name */
+                  gss_name_t ,            /* targ_name */
+                  OM_uint32 ,             /* lifetime_rec */
+                  gss_OID ,               /* mech_type */
+                  OM_uint32 ,             /* ctx_flags */
+                  int ,                   /* locally_initiated */
+                  int *                   /* open */
+                 );
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 94]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   OM_uint32 gss_wrap_size_limit (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_ctx_id_t,     /* context_handle */
+                  int,                    /* conf_req_flag */
+                  gss_qop_t,              /* qop_req */
+                  OM_uint32,              /* req_output_size */
+                  OM_uint32 *             /* max_input_size */
+                 );
+
+   OM_uint32 gss_add_cred (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_cred_id_t,    /* input_cred_handle */
+                  const gss_name_t,       /* desired_name */
+                  const gss_OID,          /* desired_mech */
+                  gss_cred_usage_t,       /* cred_usage */
+                  OM_uint32,              /* initiator_time_req */
+                  OM_uint32,              /* acceptor_time_req */
+                  gss_cred_id_t ,         /* output_cred_handle */
+                  gss_OID_set ,           /* actual_mechs */
+                  OM_uint32 ,             /* initiator_time_rec */
+                  OM_uint32 *             /* acceptor_time_rec */
+                 );
+
+   OM_uint32 gss_inquire_cred_by_mech (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_cred_id_t,    /* cred_handle */
+                  const gss_OID,          /* mech_type */
+                  gss_name_t ,            /* name */
+                  OM_uint32 ,             /* initiator_lifetime */
+                  OM_uint32 ,             /* acceptor_lifetime */
+                  gss_cred_usage_t *      /* cred_usage */
+                 );
+
+   OM_uint32 gss_export_sec_context (
+                  OM_uint32 ,             /* minor_status */
+                  gss_ctx_id_t ,          /* context_handle */
+                  gss_buffer_t            /* interprocess_token */
+                 );
+
+   OM_uint32 gss_import_sec_context (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_buffer_t,     /* interprocess_token */
+                  gss_ctx_id_t *          /* context_handle */
+                 );
+
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 95]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   OM_uint32 gss_create_empty_oid_set (
+                  OM_uint32 ,             /* minor_status */
+                  gss_OID_set *           /* oid_set */
+                 );
+
+   OM_uint32 gss_add_oid_set_member (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_OID,          /* member_oid */
+                  gss_OID_set *           /* oid_set */
+                 );
+
+   OM_uint32 gss_test_oid_set_member (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_OID,          /* member */
+                  const gss_OID_set,      /* set */
+                  int *                   /* present */
+                 );
+
+   OM_uint32 gss_inquire_names_for_mech (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_OID,          /* mechanism */
+                  gss_OID_set *           /* name_types */
+                 );
+
+   OM_uint32 gss_inquire_mechs_for_name (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_name_t,       /* input_name */
+                  gss_OID_set *           /* mech_types */
+                 );
+
+   OM_uint32 gss_canonicalize_name (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_name_t,       /* input_name */
+                  const gss_OID,          /* mech_type */
+                  gss_name_t *            /* output_name */
+                 );
+
+   OM_uint32 gss_duplicate_name (
+                  OM_uint32 ,             /* minor_status */
+                  const gss_name_t,       /* src_name */
+                  gss_name_t *            /* dest_name */
+                 );
+
+   /*
+    * The following routines are obsolete variants of gss_get_mic,
+    * gss_verify_mic, gss_wrap and gss_unwrap.  They should be
+    * provided by GSS-API V2 implementations for backwards
+    * compatibility with V1 applications.  Distinct entrypoints
+
+
+
+Wray                        Standards Track                    [Page 96]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+    * (as opposed to #defines) should be provided, both to allow
+    * GSS-API V1 applications to link against GSS-API V2
+      implementations,
+    * and to retain the slight parameter type differences between the
+    * obsolete versions of these routines and their current forms.
+    */
+
+   OM_uint32 gss_sign
+                 (OM_uint32 ,        /* minor_status */
+                  gss_ctx_id_t,      /* context_handle */
+                  int,               /* qop_req */
+                  gss_buffer_t,      /* message_buffer */
+                  gss_buffer_t       /* message_token */
+                 );
+
+
+   OM_uint32 gss_verify
+                 (OM_uint32 ,        /* minor_status */
+                  gss_ctx_id_t,      /* context_handle */
+                  gss_buffer_t,      /* message_buffer */
+                  gss_buffer_t,      /* token_buffer */
+                  int *              /* qop_state */
+                 );
+
+   OM_uint32 gss_seal
+                 (OM_uint32 ,        /* minor_status */
+                  gss_ctx_id_t,      /* context_handle */
+                  int,               /* conf_req_flag */
+                  int,               /* qop_req */
+                  gss_buffer_t,      /* input_message_buffer */
+                  int ,              /* conf_state */
+                  gss_buffer_t       /* output_message_buffer */
+                 );
+
+
+   OM_uint32 gss_unseal
+                 (OM_uint32 ,        /* minor_status */
+                  gss_ctx_id_t,      /* context_handle */
+                  gss_buffer_t,      /* input_message_buffer */
+                  gss_buffer_t,      /* output_message_buffer */
+                  int ,              /* conf_state */
+                  int *              /* qop_state */
+                 );
+
+   #endif /* GSSAPI_H_ */
+
+
+
+
+
+
+Wray                        Standards Track                    [Page 97]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+Appendix B. Additional constraints for application binary portability
+
+   The purpose of this C-bindings document is to encourage source-level
+   portability of applications across GSS-API implementations on
+   different platforms and atop different mechanisms.  Additional goals
+   that have not been explicitly addressed by this document are link-
+   time and run-time portability.
+
+   Link-time portability provides the ability to compile an application
+   against one implementation of GSS-API, and then link it against a
+   different implementation on the same platform.  It is a stricter
+   requirement than source-level portability.
+
+   Run-time portability differs from link-time portability only on those
+   platforms that implement dynamically loadable GSS-API
+   implementations, but do not offer load-time symbol resolution. On
+   such platforms, run-time portability is a stricter requirement than
+   link-time portability, and will typically include the precise
+   placement of the various GSS-API routines within library entrypoint
+   vectors.
+
+   Individual platforms will impose their own rules that must be
+   followed to achieve link-time (and run-time, if different)
+   portability.  In order to ensure either form of binary portability,
+   an ABI specification must be written for GSS-API implementations on
+   that platform.  However, it is recognized that there are some issues
+   that are likely to be common to all such ABI specifications. This
+   appendix is intended to be a repository for such common issues, and
+   contains some suggestions that individual ABI specifications may
+   choose to reference. Since machine architectures vary greatly, it may
+   not be possible or desirable to follow these suggestions on all
+   platforms.
+
+B.1. Pointers
+
+   While ANSI-C provides a single pointer type for each declared type,
+   plus a single (void *) type, some platforms (notably those using
+   segmented memory architectures) augment this with various modified
+   pointer types (e.g. far pointers, near pointers). These language
+   bindings assume ANSI-C, and thus do not address such non-standard
+   implementations.  GSS-API implementations for such platforms must
+   choose an appropriate memory model, and should use it consistently
+   throughout.  For example, if a memory model is chosen that requires
+   the use of far pointers when passing routine parameters, then far
+   pointers should also be used within the structures defined by GSS-
+   API.
+
+
+
+
+
+Wray                        Standards Track                    [Page 98]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+B.2. Internal structure alignment
+
+   GSS-API defines several data-structures containing differently-sized
+   fields.  An ABI specification should include a detailed description
+   of how the fields of such structures are aligned, and if there is any
+   internal padding in these data structures.  The use of compiler
+   defaults for the platform is recommended.
+
+B.3. Handle types
+
+   The C bindings specify that the gss_cred_id_t and gss_ctx_id_t types
+   should be implemented as either pointer or arithmetic types, and that
+   if pointer types are used, care should be taken to ensure that two
+   handles may be compared with the == operator. Note that ANSI-C does
+   not guarantee that two pointer values may be compared with the ==
+   operator unless either the two pointers point to members of a single
+   array, or at least one of the pointers contains a NULL value.
+
+   For binary portability, additional constraints are required. The
+   following is an attempt at defining platform-independent constraints.
+
+   The size of the handle type must be the same as sizeof(void *), using
+   the appropriate memory model.
+
+   The == operator for the chosen type must be a simple bit-wise
+   comparison.  That is, for two in-memory handle objects h1 and h2, the
+   boolean value of the expression
+
+      (h1 == h2)
+
+   should always be the same as the boolean value of the expression
+
+      (memcmp(&h1, &h2, sizeof(h1)) == 0)
+
+   The actual use of the type (void *) for handle types is discouraged,
+   not for binary portability reasons, but since it effectively disables
+   much of the compile-time type-checking that the compiler can
+   otherwise perform, and is therefore not "programmer-friendly".  If a
+   pointer implementation is desired, and if the platform's
+   implementation of pointers permits, the handles should be implemented
+   as pointers to distinct implementation-defined types.
+
+B.4. The gss_name_t type
+
+   The gss_name_t type, representing the internal name object, should be
+   implemented as a pointer type.  The use of the (void *) type is
+   discouraged as it does not allow the compiler to perform strong
+   type-checking.  However, the pointer type chosen should be of the
+
+
+
+Wray                        Standards Track                    [Page 99]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+   same size as the (void *) type.  Provided this rule is obeyed, ABI
+   specifications need not further constrain the implementation of
+   gss_name_t objects.
+
+B.5. The int and size_t types
+
+   Some platforms may support differently sized implementations of the
+   "int" and "size_t" types, perhaps chosen through compiler switches,
+   and perhaps dependent on memory model.  An ABI specification for such
+   a platform should include required implementations for these types.
+   It is recommended that the default implementation (for the chosen
+   memory model, if appropriate) is chosen.
+
+B.6. Procedure-calling conventions
+
+   Some platforms support a variety of different binary conventions for
+   calling procedures.  Such conventions cover things like the format of
+   the stack frame, the order in which the routine parameters are pushed
+   onto the stack, whether or not a parameter count is pushed onto the
+   stack, whether some argument(s) or return values are to be passed in
+   registers, and whether the called routine or the caller is
+   responsible for removing the stack frame on return.  For such
+   platforms, an ABI specification should specify which calling
+   convention is to be used for GSS-API implementations.
+
+References
+
+   [GSSAPI]    Linn, J., "Generic Security Service Application Program
+               Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [XOM]       OSI Object Management API Specification, Version 2.0 t",
+               X.400 API Association & X/Open Company Limited, August
+               24, 1990 Specification of datatypes and routines for
+               manipulating information objects.
+
+Author's Address
+
+   John Wray
+   Iris Associates
+   5 Technology Park Drive,
+   Westford, MA  01886
+   USA
+
+   Phone: +1-978-392-6689
+   EMail: John_Wray@Iris.com
+
+
+
+
+
+
+Wray                        Standards Track                   [Page 100]
+
+RFC 2744                 GSS-API V2: C-bindings             January 2000
+
+
+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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wray                        Standards Track                   [Page 101]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3079.txt b/third_party/heimdal/doc/standardisation/rfc3079.txt
new file mode 100644
index 00000000000..4d7ba0de1c3
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3079.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                            G. Zorn
+Request for Comments: 3079                                 cisco Systems
+Category: Informational                                       March 2001
+
+
+ Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+
+   The PPP Compression Control Protocol provides a method to negotiate
+   and utilize compression protocols over PPP encapsulated links.
+
+   Microsoft Point to Point Encryption (MPPE) is a means of representing
+   PPP packets in an encrypted form.  MPPE uses the RSA RC4 algorithm to
+   provide data confidentiality.  The length of the session key to be
+   used for initializing encryption tables can be negotiated.  MPPE
+   currently supports 40-bit, 56-bit and 128-bit session keys.  MPPE
+   session keys are changed frequently; the exact frequency depends upon
+   the options negotiated, but may be every packet.  MPPE is negotiated
+   within option 18 in the Compression Control Protocol.
+
+   This document describes the method used to derive initial MPPE
+   session keys from a variety of credential types.  It is expected that
+   this memo will be updated whenever Microsoft defines a new key
+   derivation method for MPPE, since its primary purpose is to provide
+   an open, easily accessible reference for third-parties wishing to
+   interoperate with Microsoft products.
+
+   MPPE itself (including the protocol used to negotiate its use, the
+   details of the encryption method used and the algorithm used to
+   change session keys during a session) is described in RFC 3078.
+
+
+
+
+
+
+
+Zorn                         Informational                      [Page 1]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+Table of Contents
+
+   1.  Specification of Requirements ............................... 2
+   2.  Deriving Session Keys from MS-CHAP Credentials .............. 2
+   2.1.  Generating 40-bit Session Keys ............................ 3
+   2.2.  Generating 56-bit Session Keys ............................ 3
+   2.3.  Generating 128-bit Session Keys ........................... 4
+   2.4.  Key Derivation Functions .................................. 5
+   2.5.  Sample Key Derivations .................................... 6
+   2.5.1.  Sample 40-bit Key Derivation ............................ 6
+   2.5.2.  Sample 56-bit Key Derivation ............................ 6
+   2.5.3.  Sample 128-bit Key Derivation ........................... 7
+   3.  Deriving Session Keys from MS-CHAP-2 Credentials ............ 7
+   3.1.  Generating 40-bit Session Keys ............................ 8
+   3.2.  Generating 56-bit Session Keys ............................ 9
+   3.3.  Generating 128-bit Session Keys ...........................10
+   3.4.  Key Derivation Functions ..................................11
+   3.5.  Sample Key Derivations ....................................13
+   3.5.1.  Sample 40-bit Key Derivation ............................13
+   3.5.2.  Sample 56-bit Key Derivation ............................14
+   3.5.3.  Sample 128-bit Key Derivation ...........................15
+   4.  Deriving MPPE Session Keys from TLS Session Keys ............16
+   4.1.  Generating 40-bit Session Keys ............................16
+   4.2.  Generating 56-bit Session Keys ............................17
+   4.3.  Generating 128-bit Session Keys ...........................17
+   5.  Security Considerations .....................................18
+   5.1.  MS-CHAP Credentials .......................................18
+   5.2.  EAP-TLS Credentials .......................................19
+   6.  References ..................................................19
+   7.  Acknowledgements ............................................20
+   8.  Author's Address ............................................20
+   9.  Full Copyright Statement ....................................21
+
+1.  Specification of Requirements
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+   described in [6].
+
+2.  Deriving Session Keys from MS-CHAP Credentials
+
+   The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1)
+   [2] is a Microsoft-proprietary PPP [1] authentication protocol,
+   providing the functionality to which LAN-based users are accustomed
+   while integrating the encryption and hashing algorithms used on
+   Windows networks.
+
+
+
+
+
+Zorn                         Informational                      [Page 2]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+   The following sections detail the methods used to derive initial
+   session keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials.
+
+   Implementation Note
+
+      The initial session key in both directions is derived from the
+      credentials of the peer that initiated the call and the challenge
+      used (if any) is the challenge from the first authentication.
+      This is true for both unilateral and bilateral authentication, as
+      well as for each link in a multilink bundle.  In the multi-chassis
+      multilink case, implementations are responsible for ensuring that
+      the correct keys are generated on all participating machines.
+
+2.1.  Generating 40-bit Session Keys
+
+   MPPE uses a derivative of the peer's LAN Manager password as the 40-
+   bit session key used for initializing the RC4 encryption tables.
+
+   The first step is to obfuscate the peer's password using the
+   LmPasswordHash() function (described in [2]).  The first 8 octets of
+   the result are used as the basis for the session key generated in the
+   following way:
+
+/*
+* PasswordHash is the basis for the session key
+* SessionKey is a copy of PasswordHash and is the generative session key
+* 8 is the length (in octets) of the key to be generated.
+*
+*/
+Get_Key(PasswordHash, SessionKey, 8)
+
+/*
+* The effective length of the key is reduced to 40 bits by
+* replacing the first three bytes as follows:
+*/
+SessionKey[0] = 0xd1 ;
+SessionKey[1] = 0x26 ;
+SessionKey[2] = 0x9e ;
+
+2.2.  Generating 56-bit Session Keys
+
+   MPPE uses a derivative of the peer's LAN Manager password as the 56-
+   bit session key used for initializing the RC4 encryption tables.
+
+   The first step is to obfuscate the peer's password using the
+   LmPasswordHash() function (described in [2]).  The first 8 octets of
+   the result are used as the basis for the session key generated in the
+   following way:
+
+
+
+Zorn                         Informational                      [Page 3]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+/*
+* PasswordHash is the basis for the session key
+* SessionKey is a copy of PasswordHash and is the generative session key
+* 8 is the length (in octets) of the key to be generated.
+*
+*/
+Get_Key(PasswordHash, SessionKey, 8)
+
+/*
+* The effective length of the key is reduced to 56 bits by
+* replacing the first byte as follows:
+*/
+SessionKey[0] = 0xd1 ;
+
+2.3.  Generating 128-bit Session Keys
+
+   MPPE uses a derivative of the peer's Windows NT password as the 128-
+   bit session key used for initializing encryption tables.
+
+   The first step is to obfuscate the peer's password using
+   NtPasswordHash() function as described in [2].  The first 16 octets
+   of the result are then hashed again using the MD4 algorithm.  The
+   first 16 octets of the second hash are used as the basis for the
+   session key generated in the following way:
+
+/*
+* Challenge (as described in [9]) is sent by the PPP authenticator
+* during authentication and is 8 octets long.
+* NtPasswordHashHash is the basis for the session key.
+* On return, InitialSessionKey contains the initial session
+* key to be used.
+*/
+Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey)
+
+/*
+* CurrentSessionKey is a copy of InitialSessionKey
+* and is the generative session key.
+* Length (in octets) of the key to generate is 16.
+*
+*/
+Get_Key(InitialSessionKey, CurrentSessionKey, 16)
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                      [Page 4]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+2.4.  Key Derivation Functions
+
+   The following procedures are used to derive the session key.
+
+/*
+ * Pads used in key derivation
+ */
+
+SHApad1[40] =
+   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+SHApad2[40] =
+   {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
+
+/*
+ * SHAInit(), SHAUpdate() and SHAFinal() functions are an
+ * implementation of Secure Hash Algorithm (SHA-1) [7]. These are
+ * available in public domain or can be licensed from
+ * RSA Data Security, Inc.
+ *
+ * 1) InitialSessionKey is 8 octets long for 56- and 40-bit
+ *    session keys, 16 octets long for 128 bit session keys.
+ * 2) CurrentSessionKey is same as InitialSessionKey when this
+ *    routine is called for the first time for the session.
+ */
+
+Get_Key(
+IN     InitialSessionKey,
+IN/OUT CurrentSessionKey
+IN     LengthOfDesiredKey )
+{
+   SHAInit(Context)
+   SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey)
+   SHAUpdate(Context, SHAPad1, 40)
+   SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey)
+   SHAUpdate(Context, SHAPad2, 40)
+   SHAFinal(Context, Digest)
+   memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey)
+}
+
+Get_Start_Key(
+IN  Challenge,
+
+
+
+Zorn                         Informational                      [Page 5]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+IN  NtPasswordHashHash,
+OUT InitialSessionKey)
+{
+   SHAInit(Context)
+   SHAUpdate(Context, NtPasswordHashHash, 16)
+   SHAUpdate(Context, NtPasswordHashHash, 16)
+   SHAUpdate(Context, Challenge, 8)
+   SHAFinal(Context, Digest)
+   memcpy(InitialSessionKey, Digest, 16)
+}
+
+2.5.  Sample Key Derivations
+
+   The following sections illustrate 40-, 56- and 128-bit key
+   derivations.  All intermediate values are in hexadecimal.
+
+2.5.1.  Sample 40-bit Key Derivation
+
+
+   Initial Values
+      Password = "clientPass"
+
+   Step 1: LmPasswordHash(Password, PasswordHash)
+      PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+   Step 2: Copy PasswordHash to SessionKey
+      SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+   Step 3: GetKey(PasswordHash, SessionKey, 8)
+      SessionKey = d8 08 01 53 8c ec 4a 08
+
+   Step 4: Reduce the effective key length to 40 bits
+      SessionKey = d1 26 9e 53 8c ec 4a 08
+
+2.5.2.  Sample 56-bit Key Derivation
+
+   Initial Values
+      Password = "clientPass"
+
+   Step 1: LmPasswordHash(Password, PasswordHash)
+      PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+   Step 2: Copy PasswordHash to SessionKey
+      SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
+
+   Step 3: GetKey(PasswordHash, SessionKey, 8)
+      SessionKey = d8 08 01 53 8c ec 4a 08
+
+
+
+
+Zorn                         Informational                      [Page 6]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+   Step 4: Reduce the effective key length to 56 bits
+      SessionKey = d1 08 01 53 8c ec 4a 08
+
+2.5.3.  Sample 128-bit Key Derivation
+
+Initial Values
+   Password = "clientPass"
+   Challenge = 10 2d b5 df 08 5d 30 41
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+   PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+   PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f
+
+Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey)
+   InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0
+
+Step 4: Copy InitialSessionKey to CurrentSessionKey
+   CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0
+
+Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16)
+   CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e
+
+3.  Deriving Session Keys from MS-CHAP-2 Credentials
+
+   Version 2 of the Microsoft Challenge-Handshake Authentication
+   Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP
+   authentication protocol, providing the functionality to which LAN-
+   based users are accustomed while integrating the encryption and
+   hashing algorithms used on Windows networks.
+
+   The following sections detail the methods used to derive initial
+   session keys from MS-CHAP-2 credentials.  40-, 56- and 128-bit keys
+   are all derived using the same algorithm from the authenticating
+   peer's Windows NT password.  The only difference is in the length of
+   the keys and their effective strength: 40- and 56-bit keys are 8
+   octets in length, while 128-bit keys are 16 octets long.  Separate
+   keys are derived for the send and receive directions of the session.
+
+   Implementation Note
+
+      The initial session keys in both directions are derived from the
+      credentials of the peer that initiated the call and the challenges
+      used are those from the first authentication.  This is true as
+      well for each link in a multilink bundle.  In the multi-chassis
+      multilink case, implementations are responsible for ensuring that
+      the correct keys are generated on all participating machines.
+
+
+
+Zorn                         Informational                      [Page 7]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+3.1.  Generating 40-bit Session Keys
+
+   When used in conjunction with MS-CHAP-2 authentication, the initial
+   MPPE session keys are derived from the peer's Windows NT password.
+
+   The first step is to obfuscate the peer's password using
+   NtPasswordHash() function as described in [8].
+
+      NtPasswordHash(Password, PasswordHash)
+
+   The first 16 octets of the result are then hashed again using the MD4
+   algorithm.
+
+      PasswordHashHash = md4(PasswordHash)
+
+   The first 16 octets of this second hash are used together with the
+   NT- Response field from the MS-CHAP-2 Response packet [8] as the
+   basis for the master session key:
+
+      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
+
+   Once the master key has been generated, it is used to derive two 40-
+   bit session keys, one for sending and one for receiving:
+
+      GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
+      GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
+
+   The master session keys are never used to encrypt or decrypt data;
+   they are only used in the derivation of transient session keys.  The
+   initial transient session keys are obtained by calling the function
+   GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+                                               ReceiveSessionKey)
+
+   Next, the effective strength of both keys is reduced by setting the
+   first three octets to known constants:
+
+      SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
+      SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
+      SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e
+
+   Finally, the RC4 tables are initialized using the new session keys:
+
+      rc4_key(SendRC4key, 8, SendSessionKey)
+      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+
+
+
+Zorn                         Informational                      [Page 8]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+3.2.  Generating 56-bit Session Keys
+
+   When used in conjunction with MS-CHAP-2 authentication, the initial
+   MPPE session keys are derived from the peer's Windows NT password.
+
+   The first step is to obfuscate the peer's password using
+   NtPasswordHash() function as described in [8].
+
+      NtPasswordHash(Password, PasswordHash)
+
+   The first 16 octets of the result are then hashed again using the MD4
+   algorithm.
+
+      PasswordHashHash = md4(PasswordHash)
+
+   The first 16 octets of this second hash are used together with the
+   NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
+   for the master session key:
+
+      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
+
+   Once the master key has been generated, it is used to derive two
+   56-bit session keys, one for sending and one for receiving:
+
+      GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
+      GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
+
+   The master session keys are never used to encrypt or decrypt data;
+   they are only used in the derivation of transient session keys.  The
+   initial transient session keys are obtained by calling the function
+   GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+                                               ReceiveSessionKey)
+
+   Next, the effective strength of both keys is reduced by setting the
+   first octet to a known constant:
+
+      SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
+
+   Finally, the RC4 tables are initialized using the new session keys:
+
+      rc4_key(SendRC4key, 8, SendSessionKey)
+      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+
+
+
+
+
+Zorn                         Informational                      [Page 9]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+3.3.  Generating 128-bit Session Keys
+
+   When used in conjunction with MS-CHAP-2 authentication, the initial
+   MPPE session keys are derived from the peer's Windows NT password.
+
+   The first step is to obfuscate the peer's password using
+   NtPasswordHash() function as described in [8].
+
+      NtPasswordHash(Password, PasswordHash)
+
+   The first 16 octets of the result are then hashed again using the MD4
+   algorithm.
+
+      PasswordHashHash = md4(PasswordHash)
+
+   The first 16 octets of this second hash are used together with the
+   NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
+   for the master session key:
+
+      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
+
+   Once the master key has been generated, it is used to derive two
+   128-bit master session keys, one for sending and one for receiving:
+
+GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE)
+GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE)
+
+   The master session keys are never used to encrypt or decrypt data;
+   they are only used in the derivation of transient session keys.  The
+   initial transient session keys are obtained by calling the function
+   GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
+                                                ReceiveSessionKey)
+
+   Finally, the RC4 tables are initialized using the new session keys:
+
+      rc4_key(SendRC4key, 16, SendSessionKey)
+      rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 10]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+3.4.  Key Derivation Functions
+
+   The following procedures are used to derive the session key.
+
+/*
+ * Pads used in key derivation
+ */
+
+SHSpad1[40] =
+   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+SHSpad2[40] =
+   {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
+    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
+
+/*
+ * "Magic" constants used in key derivations
+ */
+
+Magic1[27] =
+   {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74,
+    0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d,
+    0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79};
+
+Magic2[84] =
+   {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
+    0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
+    0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
+    0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79,
+    0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73,
+    0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65,
+    0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
+    0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
+    0x6b, 0x65, 0x79, 0x2e};
+
+Magic3[84] =
+   {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
+    0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
+    0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
+    0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
+    0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68,
+    0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73,
+    0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73,
+
+
+
+Zorn                         Informational                     [Page 11]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+    0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20,
+    0x6b, 0x65, 0x79, 0x2e};
+
+
+   GetMasterKey(
+   IN  16-octet  PasswordHashHash,
+   IN  24-octet  NTResponse,
+   OUT 16-octet  MasterKey )
+   {
+      20-octet Digest
+
+      ZeroMemory(Digest, sizeof(Digest));
+
+      /*
+       * SHSInit(), SHSUpdate() and SHSFinal()
+       * are an implementation of the Secure Hash Standard [7].
+       */
+
+      SHSInit(Context);
+      SHSUpdate(Context, PasswordHashHash, 16);
+      SHSUpdate(Context, NTResponse, 24);
+      SHSUpdate(Context, Magic1, 27);
+      SHSFinal(Context, Digest);
+
+      MoveMemory(MasterKey, Digest, 16);
+   }
+
+   VOID
+   GetAsymetricStartKey(
+   IN   16-octet      MasterKey,
+   OUT  8-to-16 octet SessionKey,
+   IN   INTEGER       SessionKeyLength,
+   IN   BOOLEAN       IsSend,
+   IN   BOOLEAN       IsServer )
+   {
+
+      20-octet Digest;
+
+      ZeroMemory(Digest, 20);
+
+      if (IsSend) {
+         if (IsServer) {
+            s = Magic3
+         } else {
+            s = Magic2
+         }
+      } else {
+         if (IsServer) {
+
+
+
+Zorn                         Informational                     [Page 12]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+            s = Magic2
+         } else {
+            s = Magic3
+         }
+      }
+
+      /*
+       * SHSInit(), SHSUpdate() and SHSFinal()
+       * are an implementation of the Secure Hash Standard [7].
+       */
+
+      SHSInit(Context);
+      SHSUpdate(Context, MasterKey, 16);
+      SHSUpdate(Context, SHSpad1, 40);
+      SHSUpdate(Context, s, 84);
+      SHSUpdate(Context, SHSpad2, 40);
+      SHSFinal(Context, Digest);
+
+      MoveMemory(SessionKey, Digest, SessionKeyLength);
+   }
+
+3.5.  Sample Key Derivations
+
+   The following sections illustrate 40-, 56- and 128-bit key
+   derivations. All intermediate values are in hexadecimal.
+
+3.5.1.  Sample 40-bit Key Derivation
+
+Initial Values
+   UserName = "User"
+            =  55 73 65 72
+
+   Password = "clientPass"
+            = 63 00 6C 00 69 00 65 00 6E 00
+              74 00 50 00 61 00 73 00 73 00
+
+   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
+                            60 21 32 26 26 28
+   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+   Challenge = D0 2E 43 86 BC E9 12 26
+
+   NT-Response =
+   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
+   11 4A 3D 85 D6 DF
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+
+
+Zorn                         Informational                     [Page 13]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+Step 3: Derive the master key (GetMasterKey())
+   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
+
+Step 4: Derive the master send session key (GetAsymmetricStartKey())
+   SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B
+
+Step 5: Derive the initial send session key (GetNewKeyFromSHA())
+   SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E
+
+Sample Encrypted Message
+   rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6
+                                           68 D7 58 98
+
+3.5.2.  Sample 56-bit Key Derivation
+
+Initial Values
+   UserName = "User"
+            =  55 73 65 72
+
+   Password = "clientPass"
+            = 63 00 6C 00 69 00 65 00 6E 00 74 00 50
+              00 61 00 73 00 73 00
+
+   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
+                            60 21 32 26 26 28
+   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+   Challenge = D0 2E 43 86 BC E9 12 26
+
+   NT-Response =
+   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
+   11 4A 3D 85 D6 DF
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+Step 3: Derive the master key (GetMasterKey())
+   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
+
+Step 4: Derive the master send session key (GetAsymmetricStartKey())
+   SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B
+
+
+
+
+Zorn                         Informational                     [Page 14]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+Step 5: Derive the initial send session key (GetNewKeyFromSHA())
+   SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E
+
+Sample Encrypted Message
+   rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D
+                                           A8 42 BC 57 58
+
+3.5.3.  Sample 128-bit Key Derivation
+
+Initial Values
+   UserName = "User"
+            =  55 73 65 72
+
+   Password = "clientPass"
+            = 63 00 6C 00 69 00 65 00 6E 00
+              74 00 50 00 61 00 73 00 73 00
+
+   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
+                            60 21 32 26 26 28
+
+   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+   Challenge = D0 2E 43 86 BC E9 12 26
+
+   NT-Response =
+   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
+   11 4A 3D 85 D6 DF
+
+Step 1: NtPasswordHash(Password, PasswordHash)
+   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+Step 2: PasswordHashHash = MD4(PasswordHash)
+   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+Step 2: Derive the master key (GetMasterKey())
+   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
+
+Step 3: Derive the send master session key (GetAsymmetricStartKey())
+
+   SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB
+
+Step 4: Derive the initial send session key (GetNewKeyFromSHA())
+   SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4
+
+Sample Encrypted Message
+  rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68
+                                           84 62 72 FB 5A BE
+
+
+
+
+Zorn                         Informational                     [Page 15]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+4.  Deriving MPPE Session Keys from TLS Session Keys
+
+   The Extensible Authentication Protocol (EAP) [10] is a PPP extension
+   that provides support  for  additional  authentication methods within
+   PPP.  Transport  Level  Security  (TLS) [11] provides for mutual
+   authentication, integrity-protected ciphersuite negotiation and key
+   exchange between two  endpoints.  EAP-TLS [12] is an EAP
+   authentication type which allows the use of TLS within the PPP
+   authentication framework.  The following sections describe the
+   methods used to derive initial session keys from TLS session keys.
+   56-, 40- and 128-bit keys are derived using the same algorithm.  The
+   only difference is in the length of the keys and their effective
+   strength: 56- and 40-bit keys are 8 octets in length, while 128-bit
+   keys are 16 octets long.  Separate keys are derived for the send and
+   receive directions of the session.
+
+4.1.  Generating 40-bit Session Keys
+
+   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
+   master secret is used as the master session key.
+
+   The algorithm used to derive asymmetrical master session keys from
+   the TLS master secret is described in [12].  The master session keys
+   are never used to encrypt or decrypt data; they are only used in the
+   derivation of transient session keys.
+
+   Implementation Note
+
+      If the asymmetrical master keys are less than 8 octets in length,
+      they MUST be padded on the left with zeroes before being used to
+      derive the initial transient session keys.  Conversely, if the
+      asymmetrical master keys are more than 8 octets in length, they
+      must be truncated to 8 octets before being used to derive the
+      initial transient session keys.
+
+   The initial transient session keys are obtained by calling the
+   function GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+ReceiveSessionKey)
+
+   Next, the effective strength of both keys is reduced by setting the
+   first three octets to known constants:
+
+      SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
+      SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
+      SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E
+
+
+
+Zorn                         Informational                     [Page 16]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+   Finally, the RC4 tables are initialized using the new session keys:
+
+      rc4_key(SendRC4key, 8, SendSessionKey)
+      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+4.2.  Generating 56-bit Session Keys
+
+   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
+   master secret is used as the master session key.
+
+   The algorithm used to derive asymmetrical master session keys from
+   the TLS master secret is described in [12].  The master session keys
+   are never used to encrypt or decrypt data; they are only used in the
+   derivation of transient session keys.
+
+   Implementation Note
+
+      If the asymmetrical master keys are less than 8 octets in length,
+      they MUST be padded on the left with zeroes before being used to
+      derive the initial transient session keys.  Conversely, if the
+      asymmetrical master keys are more than 8 octets in length, they
+      must be truncated to 8 octets before being used to derive the
+      initial transient session keys.
+
+   The initial transient session keys are obtained by calling the
+   function GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
+ReceiveSessionKey)
+
+   Next, the effective strength of both keys is reduced by setting the
+   initial octet to a known constant:
+
+      SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
+
+   Finally, the RC4 tables are initialized using the new session keys:
+
+      rc4_key(SendRC4key, 8, SendSessionKey)
+      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
+
+4.3.  Generating 128-bit Session Keys
+
+   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
+   master secret is used as the master session key.
+
+
+
+
+
+
+Zorn                         Informational                     [Page 17]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+   The algorithm used to derive asymmetrical master session keys from
+   the TLS master secret is described in [12].  Note that the send key
+   on one side is the receive key on the other.
+
+   The master session keys are never used to encrypt or decrypt data;
+   they are only used in the derivation of transient session keys.
+
+   Implementation Note
+
+      If the asymmetrical master keys are less than 16 octets in length,
+      they MUST be padded on the left with zeroes before being used to
+      derive the initial transient session keys.  Conversely, if the
+      asymmetrical master keys are more than 16 octets in length, they
+      must be truncated to 16 octets before being used to derive the
+      initial transient session keys.
+
+   The initial transient session keys are obtained by calling the
+   function GetNewKeyFromSHA() (described in [3]):
+
+GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
+GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
+ReceiveSessionKey)
+
+   Finally, the RC4 tables are initialized using the new session keys:
+
+      rc4_key(SendRC4key, 16, SendSessionKey)
+      rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
+
+5.  Security Considerations
+
+5.1.  MS-CHAP Credentials
+
+   Because of the way in which 40-bit keys are derived from MS-CHAP-1
+   credentials, the initial 40-bit session key will be identical in all
+   sessions established under the same peer credentials.  For this
+   reason, and because RC4 with a 40-bit key length is believed to be a
+   relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from
+   the LAN Manager password hash (as described above) if it can be
+   avoided.
+
+   Since the MPPE session keys are derived from user passwords (in the
+   MS- CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the
+   selection of strong passwords and passwords should be changed
+   frequently.
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 18]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+5.2.  EAP-TLS Credentials
+
+   The strength of the session keys is dependent upon the security of
+   the TLS protocol.
+
+   The EAP server may be on a separate machine from the PPP
+   authenticator; if this is the case, adequate care must be taken in
+   the transmission of the EAP-TLS master keys to the authenticator.
+
+6.  References
+
+   [1]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+        1661, July 1994.
+
+   [2]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
+        October 1998.
+
+   [3]  Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption
+        (MPPE) RFC 3078, March 2001.
+
+   [4]  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
+
+   [5]  Pall, G., "Microsoft Point-to-Point Compression (MPPC)
+        Protocol", RFC 2118, March 1997.
+
+   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [7]  "Secure Hash Standard", Federal Information Processing Standards
+        Publication 180-1, National Institute of Standards and
+        Technology, April 1995.
+
+   [8]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759,
+        January 2000.
+
+   [9]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
+        (CHAP)", RFC 1994, August 1996.
+
+   [10] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+        Protocol (EAP)", RFC 2284, March 1998.
+
+
+
+
+
+
+Zorn                         Informational                     [Page 19]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+   [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+        2246, January 1999.
+
+   [12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
+        RFC 2716, October 1999.
+
+7.  Acknowledgements
+
+   Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all
+   of Microsoft Corporation, significantly contributed to the design and
+   development of MPPE.
+
+   Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie
+   Cobbs, Mark Deuser, Vijay Baliga, Brad Robel-Forrest and Jeff Haag
+   for useful feedback.
+
+   The technical portions of this memo were completed while the author
+   was employed by Microsoft Corporation.
+
+8.  Author's Address
+
+   Questions about this memo can also be directed to:
+
+   Glen Zorn
+   cisco Systems
+   500 108th Avenue N.E.
+   Suite 500
+   Bellevue, Washington 98004
+   USA
+
+   Phone: +1 425 438 8218
+   FAX:   +1 425 438 1848
+   EMail: gwz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 20]
+
+RFC 3079                  MPPE Key Derivation                 March 2001
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 21]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3244.txt b/third_party/heimdal/doc/standardisation/rfc3244.txt
new file mode 100644
index 00000000000..0ba07ba8e11
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3244.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           M. Swift
+Request for Comments: 3244                      University of Washington
+Category: Informational                                       J. Trostle
+                                                           Cisco Systems
+                                                               J. Brezak
+                                                               Microsoft
+                                                           February 2002
+
+
+            Microsoft Windows 2000 Kerberos Change Password
+                       and Set Password Protocols
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo specifies Microsoft's Windows 2000 Kerberos change password
+   and set password protocols.  The Windows 2000 Kerberos change
+   password protocol interoperates with the original Kerberos change
+   password protocol.  Change password is a request reply protocol that
+   includes a KRB_PRIV message that contains the new password for the
+   user.
+
+1. Introduction
+
+   Microsoft's Windows 2000 Kerberos change password protocol
+   interoperates with the original Kerberos change password protocol.
+   Change password is a request reply protocol that includes a KRB_PRIV
+   message that contains the new password for the user.  The original
+   change password protocol does not allow an administrator to set a
+   password for a new user.  This functionality is useful in some
+   environments, and this proposal extends the change password protocol
+   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.
+
+
+
+
+
+
+Swift, et al.                Informational                      [Page 1]
+
+RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
+
+
+2.  The Protocol
+
+   The service accepts 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
+   that precedes the message and specifies the length of the message.
+
+   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 authenticator in the AP-
+   REQ must include a subsession key.  (NOTE: The subsession key must be
+   pseudo-randomly generated and must never be reused for multiple
+   authenticators.)  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 user-data field in the KRB-PRIV
+   message is encrypted using the subkey from the authenticator in the
+   AP-REQ data.  The usec and seq-number fields of the KRB_PRIV message
+   are present and have the same value as the seq-number field in the
+
+
+
+
+
+Swift, et al.                Informational                      [Page 2]
+
+RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
+
+
+   authenticator from the AP_REQ message (the seq-number in the
+   authenticator will be present).  The server ignores the optional
+   r-address field in the KRB_PRIV message, if it is present.
+
+   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[1]    PrincipalName OPTIONAL,
+                          targrealm[2]   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
+   will 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.
+
+
+
+
+
+
+Swift, et al.                Informational                      [Page 3]
+
+RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
+
+
+   protocol version number: contains the hex constant 0x0001 (big-endian
+   integer). (The reply message has the same format as the original
+   change password protocol.)
+
+   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 message: This KRB-PRIV message must be encrypted with the
+   subsession key from 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, consists 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 the original change
+   password protocol):
+
+      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)
+
+
+
+Swift, et al.                Informational                      [Page 4]
+
+RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
+
+
+      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 is returned 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:
+
+      This field contains information which might be useful to the user,
+      such as feedback about policy failures.  The string is encoded in
+      UTF-8.  It may be omitted if the server does not wish to include
+      it.  If it is present, the client will display the string to the
+      user.
+
+3. Security Considerations
+
+   Password policies should be enforced to make sure that users do not
+   pick passwords (for change password) that are vulnerable to brute
+   force password guessing attacks.  An administrator who is authorized
+   to set other principal's passwords is highly trusted and must also
+   carefully protect his/her own credentials.
+
+4.  References
+
+   [1]   Kohl, J. and C. Neuman, "The Kerberos Network Authentication
+         Service (V5)", RFC 1510, September 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swift, et al.                Informational                      [Page 5]
+
+RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
+
+
+5. Authors' Addresses
+
+   Mike Swift
+   University of Washington
+   Seattle, WA
+
+   EMail: mikesw@cs.washington.edu
+
+
+   Jonathan Trostle
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+
+   EMail: john3725@world.std.com
+
+
+   John Brezak
+   Microsoft
+   1 Microsoft Way
+   Redmond, WA 98052
+
+   EMail: jbrezak@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swift, et al.                Informational                      [Page 6]
+
+RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
+
+
+6.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swift, et al.                Informational                      [Page 7]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3280.txt b/third_party/heimdal/doc/standardisation/rfc3280.txt
new file mode 100644
index 00000000000..433908bb750
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3280.txt
@@ -0,0 +1,7227 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 3280                              RSA Laboratories
+Obsoletes: 2459                                                  W. Polk
+Category: Standards Track                                           NIST
+                                                                 W. Ford
+                                                                VeriSign
+                                                                 D. Solo
+                                                               Citigroup
+                                                              April 2002
+
+                Internet X.509 Public Key Infrastructure
+       Certificate and Certificate Revocation List (CRL) Profile
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
+   Revocation List (CRL) for use in the Internet.  An overview of this
+   approach and model are provided as an introduction.  The X.509 v3
+   certificate format is described in detail, with additional
+   information regarding the format and semantics of Internet name
+   forms.  Standard certificate extensions are described and two
+   Internet-specific extensions are defined.  A set of required
+   certificate extensions is specified.  The X.509 v2 CRL format is
+   described in detail, and required extensions are defined.  An
+   algorithm for X.509 certification path validation is described.  An
+   ASN.1 module and examples are provided in the appendices.
+
+Table of Contents
+
+   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   4
+   2  Requirements and Assumptions  . . . . . . . . . . . . . .   5
+   2.1  Communication and Topology  . . . . . . . . . . . . . .   6
+   2.2  Acceptability Criteria  . . . . . . . . . . . . . . . .   6
+   2.3  User Expectations . . . . . . . . . . . . . . . . . . .   7
+   2.4  Administrator Expectations  . . . . . . . . . . . . . .   7
+   3  Overview of Approach  . . . . . . . . . . . . . . . . . .   7
+
+
+
+Housley, et. al.            Standards Track                     [Page 1]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   3.1  X.509 Version 3 Certificate . . . . . . . . . . . . . .   8
+   3.2  Certification Paths and Trust . . . . . . . . . . . . .   9
+   3.3  Revocation  . . . . . . . . . . . . . . . . . . . . . .  11
+   3.4  Operational Protocols . . . . . . . . . . . . . . . . .  13
+   3.5  Management Protocols  . . . . . . . . . . . . . . . . .  13
+   4  Certificate and Certificate Extensions Profile  . . . . .  14
+   4.1  Basic Certificate Fields  . . . . . . . . . . . . . . .  15
+   4.1.1  Certificate Fields  . . . . . . . . . . . . . . . . .  16
+   4.1.1.1  tbsCertificate  . . . . . . . . . . . . . . . . . .  16
+   4.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  16
+   4.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  16
+   4.1.2  TBSCertificate  . . . . . . . . . . . . . . . . . . .  17
+   4.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  17
+   4.1.2.2  Serial number . . . . . . . . . . . . . . . . . . .  17
+   4.1.2.3  Signature . . . . . . . . . . . . . . . . . . . . .  18
+   4.1.2.4  Issuer  . . . . . . . . . . . . . . . . . . . . . .  18
+   4.1.2.5  Validity  . . . . . . . . . . . . . . . . . . . . .  22
+   4.1.2.5.1  UTCTime . . . . . . . . . . . . . . . . . . . . .  22
+   4.1.2.5.2  GeneralizedTime . . . . . . . . . . . . . . . . .  22
+   4.1.2.6  Subject . . . . . . . . . . . . . . . . . . . . . .  23
+   4.1.2.7  Subject Public Key Info . . . . . . . . . . . . . .  24
+   4.1.2.8  Unique Identifiers  . . . . . . . . . . . . . . . .  24
+   4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . .  24
+   4.2  Certificate Extensions  . . . . . . . . . . . . . . . .  24
+   4.2.1  Standard Extensions . . . . . . . . . . . . . . . . .  25
+   4.2.1.1  Authority Key Identifier  . . . . . . . . . . . . .  26
+   4.2.1.2  Subject Key Identifier  . . . . . . . . . . . . . .  27
+   4.2.1.3  Key Usage . . . . . . . . . . . . . . . . . . . . .  28
+   4.2.1.4  Private Key Usage Period  . . . . . . . . . . . . .  29
+   4.2.1.5  Certificate Policies  . . . . . . . . . . . . . . .  30
+   4.2.1.6  Policy Mappings . . . . . . . . . . . . . . . . . .  33
+   4.2.1.7  Subject Alternative Name  . . . . . . . . . . . . .  33
+   4.2.1.8  Issuer Alternative Name . . . . . . . . . . . . . .  36
+   4.2.1.9  Subject Directory Attributes  . . . . . . . . . . .  36
+   4.2.1.10  Basic Constraints  . . . . . . . . . . . . . . . .  36
+   4.2.1.11  Name Constraints . . . . . . . . . . . . . . . . .  37
+   4.2.1.12  Policy Constraints . . . . . . . . . . . . . . . .  40
+   4.2.1.13  Extended Key Usage . . . . . . . . . . . . . . . .  40
+   4.2.1.14  CRL Distribution Points  . . . . . . . . . . . . .  42
+   4.2.1.15  Inhibit Any-Policy . . . . . . . . . . . . . . . .  44
+   4.2.1.16  Freshest CRL . . . . . . . . . . . . . . . . . . .  44
+   4.2.2  Internet Certificate Extensions . . . . . . . . . . .  45
+   4.2.2.1  Authority Information Access  . . . . . . . . . . .  45
+   4.2.2.2  Subject Information Access  . . . . . . . . . . . .  46
+   5  CRL and CRL Extensions Profile  . . . . . . . . . . . . .  48
+   5.1  CRL Fields  . . . . . . . . . . . . . . . . . . . . . .  49
+   5.1.1  CertificateList Fields  . . . . . . . . . . . . . . .  50
+   5.1.1.1  tbsCertList . . . . . . . . . . . . . . . . . . . .  50
+
+
+
+Housley, et. al.            Standards Track                     [Page 2]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   5.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  50
+   5.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  51
+   5.1.2  Certificate List "To Be Signed" . . . . . . . . . . .  51
+   5.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  52
+   5.1.2.2  Signature . . . . . . . . . . . . . . . . . . . . .  52
+   5.1.2.3  Issuer Name . . . . . . . . . . . . . . . . . . . .  52
+   5.1.2.4  This Update . . . . . . . . . . . . . . . . . . . .  52
+   5.1.2.5  Next Update . . . . . . . . . . . . . . . . . . . .  53
+   5.1.2.6  Revoked Certificates  . . . . . . . . . . . . . . .  53
+   5.1.2.7  Extensions  . . . . . . . . . . . . . . . . . . . .  53
+   5.2  CRL Extensions  . . . . . . . . . . . . . . . . . . . .  53
+   5.2.1  Authority Key Identifier  . . . . . . . . . . . . . .  54
+   5.2.2  Issuer Alternative Name . . . . . . . . . . . . . . .  54
+   5.2.3  CRL Number  . . . . . . . . . . . . . . . . . . . . .  55
+   5.2.4  Delta CRL Indicator . . . . . . . . . . . . . . . . .  55
+   5.2.5  Issuing Distribution Point  . . . . . . . . . . . . .  58
+   5.2.6  Freshest CRL  . . . . . . . . . . . . . . . . . . . .  59
+   5.3  CRL Entry Extensions  . . . . . . . . . . . . . . . . .  60
+   5.3.1  Reason Code . . . . . . . . . . . . . . . . . . . . .  60
+   5.3.2  Hold Instruction Code . . . . . . . . . . . . . . . .  61
+   5.3.3  Invalidity Date . . . . . . . . . . . . . . . . . . .  62
+   5.3.4  Certificate Issuer  . . . . . . . . . . . . . . . . .  62
+   6  Certificate Path Validation . . . . . . . . . . . . . . .  62
+   6.1  Basic Path Validation . . . . . . . . . . . . . . . . .  63
+   6.1.1  Inputs  . . . . . . . . . . . . . . . . . . . . . . .  66
+   6.1.2  Initialization  . . . . . . . . . . . . . . . . . . .  67
+   6.1.3  Basic Certificate Processing  . . . . . . . . . . . .  70
+   6.1.4  Preparation for Certificate i+1 . . . . . . . . . . .  75
+   6.1.5  Wrap-up procedure . . . . . . . . . . . . . . . . . .  78
+   6.1.6  Outputs . . . . . . . . . . . . . . . . . . . . . . .  80
+   6.2  Extending Path Validation . . . . . . . . . . . . . . .  80
+   6.3  CRL Validation  . . . . . . . . . . . . . . . . . . . .  81
+   6.3.1  Revocation Inputs . . . . . . . . . . . . . . . . . .  82
+   6.3.2  Initialization and Revocation State Variables . . . .  82
+   6.3.3  CRL Processing  . . . . . . . . . . . . . . . . . . .  83
+   7  References  . . . . . . . . . . . . . . . . . . . . . . .  86
+   8  Intellectual Property Rights  . . . . . . . . . . . . . .  88
+   9  Security Considerations . . . . . . . . . . . . . . . . .  89
+   Appendix A.  ASN.1 Structures and OIDs . . . . . . . . . . .  92
+   A.1 Explicitly Tagged Module, 1988 Syntax  . . . . . . . . .  92
+   A.2 Implicitly Tagged Module, 1988 Syntax  . . . . . . . . . 105
+   Appendix B.  ASN.1 Notes . . . . . . . . . . . . . . . . . . 112
+   Appendix C.  Examples  . . . . . . . . . . . . . . . . . . . 115
+   C.1  DSA Self-Signed Certificate . . . . . . . . . . . . . . 115
+   C.2  End Entity Certificate Using DSA  . . . . . . . . . . . 119
+   C.3  End Entity Certificate Using RSA  . . . . . . . . . . . 122
+   C.4  Certificate Revocation List . . . . . . . . . . . . . . 126
+   Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128
+
+
+
+Housley, et. al.            Standards Track                     [Page 3]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . 129
+
+1  Introduction
+
+   This specification is one part of a family of standards for the X.509
+   Public Key Infrastructure (PKI) for the Internet.
+
+   This specification profiles the format and semantics of certificates
+   and certificate revocation lists (CRLs) for the Internet PKI.
+   Procedures are described for processing of certification paths in the
+   Internet environment.  Finally, ASN.1 modules are provided in the
+   appendices for all data structures defined or referenced.
+
+   Section 2 describes Internet PKI requirements, and the assumptions
+   which affect the scope of this document.  Section 3 presents an
+   architectural model and describes its relationship to previous IETF
+   and ISO/IEC/ITU-T standards.  In particular, this document's
+   relationship with the IETF PEM specifications and the ISO/IEC/ITU-T
+   X.509 documents are described.
+
+   Section 4 profiles the X.509 version 3 certificate, and section 5
+   profiles the X.509 version 2 CRL.  The profiles include the
+   identification of ISO/IEC/ITU-T and ANSI extensions which may be
+   useful in the Internet PKI.  The profiles are presented in the 1988
+   Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1
+   syntax used in the most recent ISO/IEC/ITU-T standards.
+
+   Section 6 includes certification path validation procedures.  These
+   procedures are based upon the ISO/IEC/ITU-T definition.
+   Implementations are REQUIRED to derive the same results but are not
+   required to use the specified procedures.
+
+   Procedures for identification and encoding of public key materials
+   and digital signatures are defined in [PKIXALGS].  Implementations of
+   this specification are not required to use any particular
+   cryptographic algorithms.  However, conforming implementations which
+   use the algorithms identified in [PKIXALGS] MUST identify and encode
+   the public key materials and digital signatures as described in that
+   specification.
+
+   Finally, three appendices are provided to aid implementers.  Appendix
+   A contains all ASN.1 structures defined or referenced within this
+   specification.  As above, the material is presented in the 1988
+   ASN.1.  Appendix B contains notes on less familiar features of the
+   ASN.1 notation used within this specification.  Appendix C contains
+   examples of a conforming certificate and a conforming CRL.
+
+
+
+
+
+Housley, et. al.            Standards Track                     [Page 4]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   This specification obsoletes RFC 2459.  This specification differs
+   from RFC 2459 in five basic areas:
+
+      * To promote interoperable implementations, a detailed algorithm
+      for certification path validation is included in section 6.1 of
+      this specification; RFC 2459 provided only a high-level
+      description of path validation.
+
+      * An algorithm for determining the status of a certificate using
+      CRLs is provided in section 6.3 of this specification.  This
+      material was not present in RFC 2459.
+
+      * To accommodate new usage models, detailed information describing
+      the use of delta CRLs is provided in Section 5 of this
+      specification.
+
+      * Identification and encoding of public key materials and digital
+      signatures are not included in this specification, but are now
+      described in a companion specification [PKIXALGS].
+
+      * Four additional extensions are specified: three certificate
+      extensions and one CRL extension.  The certificate extensions are
+      subject info access, inhibit any-policy, and freshest CRL.  The
+      freshest CRL extension is also defined as a CRL extension.
+
+      * Throughout the specification, clarifications have been
+      introduced to enhance consistency with the ITU-T X.509
+      specification.  X.509 defines the certificate and CRL format as
+      well as many of the extensions that appear in this specification.
+      These changes were introduced to improve the likelihood of
+      interoperability between implementations based on this
+      specification with implementations based on the ITU-T
+      specification.
+
+   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  Requirements and Assumptions
+
+   The goal of this specification is to develop a profile to facilitate
+   the use of X.509 certificates within Internet applications for those
+   communities wishing to make use of X.509 technology.  Such
+   applications may include WWW, electronic mail, user authentication,
+   and IPsec.  In order to relieve some of the obstacles to using X.509
+
+
+
+
+
+
+Housley, et. al.            Standards Track                     [Page 5]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   certificates, this document defines a profile to promote the
+   development of certificate management systems; development of
+   application tools; and interoperability determined by policy.
+
+   Some communities will need to supplement, or possibly replace, this
+   profile in order to meet the requirements of specialized application
+   domains or environments with additional authorization, assurance, or
+   operational requirements.  However, for basic applications, common
+   representations of frequently used attributes are defined so that
+   application developers can obtain necessary information without
+   regard to the issuer of a particular certificate or certificate
+   revocation list (CRL).
+
+   A certificate user should review the certificate policy generated by
+   the certification authority (CA) before relying on the authentication
+   or non-repudiation services associated with the public key in a
+   particular certificate.  To this end, this standard does not
+   prescribe legally binding rules or duties.
+
+   As supplemental authorization and attribute management tools emerge,
+   such as attribute certificates, it may be appropriate to limit the
+   authenticated attributes that are included in a certificate.  These
+   other management tools may provide more appropriate methods of
+   conveying many authenticated attributes.
+
+2.1  Communication and Topology
+
+   The users of certificates will operate in a wide range of
+   environments with respect to their communication topology, especially
+   users of secure electronic mail.  This profile supports users without
+   high bandwidth, real-time IP connectivity, or high connection
+   availability.  In addition, the profile allows for the presence of
+   firewall or other filtered communication.
+
+   This profile does not assume the deployment of an X.500 Directory
+   system or a LDAP directory system.  The profile does not prohibit the
+   use of an X.500 Directory or a LDAP directory; however, any means of
+   distributing certificates and certificate revocation lists (CRLs) may
+   be used.
+
+2.2  Acceptability Criteria
+
+   The goal of the Internet Public Key Infrastructure (PKI) is to meet
+   the needs of deterministic, automated identification, authentication,
+   access control, and authorization functions.  Support for these
+   services determines the attributes contained in the certificate as
+   well as the ancillary control information in the certificate such as
+   policy data and certification path constraints.
+
+
+
+Housley, et. al.            Standards Track                     [Page 6]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+2.3  User Expectations
+
+   Users of the Internet PKI are people and processes who use client
+   software and are the subjects named in certificates.  These uses
+   include readers and writers of electronic mail, the clients for WWW
+   browsers, WWW servers, and the key manager for IPsec within a router.
+   This profile recognizes the limitations of the platforms these users
+   employ and the limitations in sophistication and attentiveness of the
+   users themselves.  This manifests itself in minimal user
+   configuration responsibility (e.g., trusted CA keys, rules), explicit
+   platform usage constraints within the certificate, certification path
+   constraints which shield the user from many malicious actions, and
+   applications which sensibly automate validation functions.
+
+2.4  Administrator Expectations
+
+   As with user expectations, the Internet PKI profile is structured to
+   support the individuals who generally operate CAs.  Providing
+   administrators with unbounded choices increases the chances that a
+   subtle CA administrator mistake will result in broad compromise.
+   Also, unbounded choices greatly complicate the software that process
+   and validate the certificates created by the CA.
+
+3  Overview of Approach
+
+   Following is a simplified view of the architectural model assumed by
+   the PKIX specifications.
+
+   The components in this model are:
+
+   end entity: user of PKI certificates and/or end user system that is
+               the subject of a certificate;
+   CA:         certification authority;
+   RA:         registration authority, i.e., an optional system to which
+               a CA delegates certain management functions;
+   CRL issuer: an optional system to which a CA delegates the
+               publication of certificate revocation lists;
+   repository: a system or collection of distributed systems that stores
+               certificates and CRLs and serves as a means of
+               distributing these certificates and CRLs to end entities.
+
+   Note that an Attribute Authority (AA) might also choose to delegate
+   the publication of CRLs to a CRL issuer.
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                     [Page 7]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   +---+
+   | C |                       +------------+
+   | e | <-------------------->| End entity |
+   | r |       Operational     +------------+
+   | t |       transactions          ^
+   | i |      and management         |  Management
+   | f |       transactions          |  transactions        PKI
+   | i |                             |                     users
+   | c |                             v
+   | a | =======================  +--+------------+  ==============
+   | t |                          ^               ^
+   | e |                          |               |         PKI
+   |   |                          v               |      management
+   | & |                       +------+           |       entities
+   |   | <---------------------|  RA  |<----+     |
+   | C |  Publish certificate  +------+     |     |
+   | R |                                    |     |
+   | L |                                    |     |
+   |   |                                    v     v
+   | R |                                +------------+
+   | e | <------------------------------|     CA     |
+   | p |   Publish certificate          +------------+
+   | o |   Publish CRL                     ^      ^
+   | s |                                   |      |  Management
+   | i |                +------------+     |      |  transactions
+   | t | <--------------| CRL Issuer |<----+      |
+   | o |   Publish CRL  +------------+            v
+   | r |                                      +------+
+   | y |                                      |  CA  |
+   +---+                                      +------+
+
+                      Figure 1 - PKI Entities
+
+3.1  X.509 Version 3 Certificate
+
+   Users of a public key require confidence that the associated private
+   key is owned by the correct remote subject (person or system) with
+   which an encryption or digital signature mechanism will be used.
+   This confidence is obtained through the use of public key
+   certificates, which are data structures that bind public key values
+   to subjects.  The binding is asserted by having a trusted CA
+   digitally sign each certificate.  The CA may base this assertion upon
+   technical means (a.k.a., proof of possession through a challenge-
+   response protocol), presentation of the private key, or on an
+   assertion by the subject.  A certificate has a limited valid lifetime
+   which is indicated in its signed contents.  Because a certificate's
+   signature and timeliness can be independently checked by a
+   certificate-using client, certificates can be distributed via
+
+
+
+Housley, et. al.            Standards Track                     [Page 8]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   untrusted communications and server systems, and can be cached in
+   unsecured storage in certificate-using systems.
+
+   ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first
+   published in 1988 as part of the X.500 Directory recommendations,
+   defines a standard certificate format [X.509].  The certificate
+   format in the 1988 standard is called the version 1 (v1) format.
+   When X.500 was revised in 1993, two more fields were added, resulting
+   in the version 2 (v2) format.
+
+   The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
+   include specifications for a public key infrastructure based on X.509
+   v1 certificates [RFC 1422].  The experience gained in attempts to
+   deploy RFC 1422 made it clear that the v1 and v2 certificate formats
+   are deficient in several respects.  Most importantly, more fields
+   were needed to carry information which PEM design and implementation
+   experience had proven necessary.  In response to these new
+   requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version
+   3 (v3) certificate format.  The v3 format extends the v2 format by
+   adding provision for additional extension fields.  Particular
+   extension field types may be specified in standards or may be defined
+   and registered by any organization or community.  In June 1996,
+   standardization of the basic v3 format was completed [X.509].
+
+   ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions
+   for use in the v3 extensions field [X.509][X9.55].  These extensions
+   can convey such data as additional subject identification
+   information, key attribute information, policy information, and
+   certification path constraints.
+
+   However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very
+   broad in their applicability.  In order to develop interoperable
+   implementations of X.509 v3 systems for Internet use, it is necessary
+   to specify a profile for use of the X.509 v3 extensions tailored for
+   the Internet.  It is one goal of this document to specify a profile
+   for Internet WWW, electronic mail, and IPsec applications.
+   Environments with additional requirements may build on this profile
+   or may replace it.
+
+3.2  Certification Paths and Trust
+
+   A user of a security service requiring knowledge of a public key
+   generally needs to obtain and validate a certificate containing the
+   required public key.  If the public key user does not already hold an
+   assured copy of the public key of the CA that signed the certificate,
+   the CA's name, and related information (such as the validity period
+   or name constraints), then it might need an additional certificate to
+   obtain that public key.  In general, a chain of multiple certificates
+
+
+
+Housley, et. al.            Standards Track                     [Page 9]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   may be needed, comprising a certificate of the public key owner (the
+   end entity) signed by one CA, and zero or more additional
+   certificates of CAs signed by other CAs.  Such chains, called
+   certification paths, are required because a public key user is only
+   initialized with a limited number of assured CA public keys.
+
+   There are different ways in which CAs might be configured in order
+   for public key users to be able to find certification paths.  For
+   PEM, RFC 1422 defined a rigid hierarchical structure of CAs.  There
+   are three types of PEM certification authority:
+
+      (a)  Internet Policy Registration Authority (IPRA):  This
+      authority, operated under the auspices of the Internet Society,
+      acts as the root of the PEM certification hierarchy at level 1.
+      It issues certificates only for the next level of authorities,
+      PCAs.  All certification paths start with the IPRA.
+
+      (b)  Policy Certification Authorities (PCAs):  PCAs are at level 2
+      of the hierarchy, each PCA being certified by the IPRA.  A PCA
+      shall establish and publish a statement of its policy with respect
+      to certifying users or subordinate certification authorities.
+      Distinct PCAs aim to satisfy different user needs.  For example,
+      one PCA (an organizational PCA) might support the general
+      electronic mail needs of commercial organizations, and another PCA
+      (a high-assurance PCA) might have a more stringent policy designed
+      for satisfying legally binding digital signature requirements.
+
+      (c)  Certification Authorities (CAs):  CAs are at level 3 of the
+      hierarchy and can also be at lower levels.  Those at level 3 are
+      certified by PCAs.  CAs represent, for example, particular
+      organizations, particular organizational units (e.g., departments,
+      groups, sections), or particular geographical areas.
+
+   RFC 1422 furthermore has a name subordination rule which requires
+   that a CA can only issue certificates for entities whose names are
+   subordinate (in the X.500 naming tree) to the name of the CA itself.
+   The trust associated with a PEM certification path is implied by the
+   PCA name.  The name subordination rule ensures that CAs below the PCA
+   are sensibly constrained as to the set of subordinate entities they
+   can certify (e.g., a CA for an organization can only certify entities
+   in that organization's name tree).  Certificate user systems are able
+   to mechanically check that the name subordination rule has been
+   followed.
+
+   The RFC 1422 uses the X.509 v1 certificate formats.  The limitations
+   of X.509 v1 required imposition of several structural restrictions to
+   clearly associate policy information or restrict the utility of
+   certificates.  These restrictions included:
+
+
+
+Housley, et. al.            Standards Track                    [Page 10]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (a)  a pure top-down hierarchy, with all certification paths
+      starting from IPRA;
+
+      (b)  a naming subordination rule restricting the names of a CA's
+      subjects; and
+
+      (c)  use of the PCA concept, which requires knowledge of
+      individual PCAs to be built into certificate chain verification
+      logic.  Knowledge of individual PCAs was required to determine if
+      a chain could be accepted.
+
+   With X.509 v3, most of the requirements addressed by RFC 1422 can be
+   addressed using certificate extensions, without a need to restrict
+   the CA structures used.  In particular, the certificate extensions
+   relating to certificate policies obviate the need for PCAs and the
+   constraint extensions obviate the need for the name subordination
+   rule.  As a result, this document supports a more flexible
+   architecture, including:
+
+      (a)  Certification paths start with a public key of a CA in a
+      user's own domain, or with the public key of the top of a
+      hierarchy.  Starting with the public key of a CA in a user's own
+      domain has certain advantages.  In some environments, the local
+      domain is the most trusted.
+
+      (b)  Name constraints may be imposed through explicit inclusion of
+      a name constraints extension in a certificate, but are not
+      required.
+
+      (c)  Policy extensions and policy mappings replace the PCA
+      concept, which permits a greater degree of automation.  The
+      application can determine if the certification path is acceptable
+      based on the contents of the certificates instead of a priori
+      knowledge of PCAs.  This permits automation of certification path
+      processing.
+
+3.3  Revocation
+
+   When a certificate is issued, it is expected to be in use for its
+   entire validity period.  However, various circumstances may cause a
+   certificate to become invalid prior to the expiration of the validity
+   period.  Such circumstances include change of name, change of
+   association between subject and CA (e.g., an employee terminates
+   employment with an organization), and compromise or suspected
+   compromise of the corresponding private key.  Under such
+   circumstances, the CA needs to revoke the certificate.
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 11]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   X.509 defines one method of certificate revocation.  This method
+   involves each CA periodically issuing a signed data structure called
+   a certificate revocation list (CRL).  A CRL is a time stamped list
+   identifying revoked certificates which is signed by a CA or CRL
+   issuer and made freely available in a public repository.  Each
+   revoked certificate is identified in a CRL by its certificate serial
+   number.  When a certificate-using system uses a certificate (e.g.,
+   for verifying a remote user's digital signature), that system not
+   only checks the certificate signature and validity but also acquires
+   a suitably-recent CRL and checks that the certificate serial number
+   is not on that CRL.  The meaning of "suitably-recent" may vary with
+   local policy, but it usually means the most recently-issued CRL.  A
+   new CRL is issued on a regular periodic basis (e.g., hourly, daily,
+   or weekly).  An entry is added to the CRL as part of the next update
+   following notification of revocation.  An entry MUST NOT be removed
+   from the CRL until it appears on one regularly scheduled CRL issued
+   beyond the revoked certificate's validity period.
+
+   An advantage of this revocation method is that CRLs may be
+   distributed by exactly the same means as certificates themselves,
+   namely, via untrusted servers and untrusted communications.
+
+   One limitation of the CRL revocation method, using untrusted
+   communications and servers, is that the time granularity of
+   revocation is limited to the CRL issue period.  For example, if a
+   revocation is reported now, that revocation will not be reliably
+   notified to certificate-using systems until all currently issued CRLs
+   are updated -- this may be up to one hour, one day, or one week
+   depending on the frequency that CRLs are issued.
+
+   As with the X.509 v3 certificate format, in order to facilitate
+   interoperable implementations from multiple vendors, the X.509 v2 CRL
+   format needs to be profiled for Internet use.  It is one goal of this
+   document to specify that profile.  However, this profile does not
+   require the issuance of CRLs.  Message formats and protocols
+   supporting on-line revocation notification are defined in other PKIX
+   specifications.  On-line methods of revocation notification may be
+   applicable in some environments as an alternative to the X.509 CRL.
+   On-line revocation checking may significantly reduce the latency
+   between a revocation report and the distribution of the information
+   to relying parties.  Once the CA accepts a revocation report as
+   authentic and valid, any query to the on-line service will correctly
+   reflect the certificate validation impacts of the revocation.
+   However, these methods impose new security requirements: the
+   certificate validator needs to trust the on-line validation service
+   while the repository does not need to be trusted.
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 12]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+3.4  Operational Protocols
+
+   Operational protocols are required to deliver certificates and CRLs
+   (or status information) to certificate using client systems.
+   Provisions are needed for a variety of different means of certificate
+   and CRL delivery, including distribution procedures based on LDAP,
+   HTTP, FTP, and X.500.  Operational protocols supporting these
+   functions are defined in other PKIX specifications.  These
+   specifications may include definitions of message formats and
+   procedures for supporting all of the above operational environments,
+   including definitions of or references to appropriate MIME content
+   types.
+
+3.5  Management Protocols
+
+   Management protocols are required to support on-line interactions
+   between PKI user and management entities.  For example, a management
+   protocol might be used between a CA and a client system with which a
+   key pair is associated, or between two CAs which cross-certify each
+   other.  The set of functions which potentially need to be supported
+   by management protocols include:
+
+      (a)  registration:  This is the process whereby a user first makes
+      itself known to a CA (directly, or through an RA), prior to that
+      CA issuing  a certificate or certificates for that user.
+
+      (b)  initialization:  Before a client system can operate securely
+      it is necessary to install key materials which have the
+      appropriate relationship with keys stored elsewhere in the
+      infrastructure.  For example, the client needs to be securely
+      initialized with the public key and other assured information of
+      the trusted CA(s), to be used in validating certificate paths.
+
+      Furthermore, a client typically needs to be initialized with its
+      own key pair(s).
+
+      (c)  certification:  This is the process in which a CA issues a
+      certificate for a user's public key, and returns that certificate
+      to the user's client system and/or posts that certificate in a
+      repository.
+
+      (d)  key pair recovery:  As an option, user client key materials
+      (e.g., a user's private key used for encryption purposes) may be
+      backed up by a CA or a key backup system.  If a user needs to
+      recover these backed up key materials (e.g., as a result of a
+      forgotten password or a lost key chain file), an on-line protocol
+      exchange may be needed to support such recovery.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 13]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (e)  key pair update:  All key pairs need to be updated regularly,
+      i.e., replaced with a new key pair, and new certificates issued.
+
+      (f)  revocation request:  An authorized person advises a CA of an
+      abnormal situation requiring certificate revocation.
+
+      (g)  cross-certification:  Two CAs exchange information used in
+      establishing a cross-certificate.  A cross-certificate is a
+      certificate issued by one CA to another CA which contains a CA
+      signature key used for issuing certificates.
+
+   Note that on-line protocols are not the only way of implementing the
+   above functions.  For all functions there are off-line methods of
+   achieving the same result, and this specification does not mandate
+   use of on-line protocols.  For example, when hardware tokens are
+   used, many of the functions may be achieved as part of the physical
+   token delivery.  Furthermore, some of the above functions may be
+   combined into one protocol exchange.  In particular, two or more of
+   the registration, initialization, and certification functions can be
+   combined into one protocol exchange.
+
+   The PKIX series of specifications defines a set of standard message
+   formats supporting the above functions.  The protocols for conveying
+   these messages in different environments (e.g., e-mail, file
+   transfer, and WWW) are described in those specifications.
+
+4  Certificate and Certificate Extensions Profile
+
+   This section presents a profile for public key certificates that will
+   foster interoperability and a reusable PKI.  This section is based
+   upon the X.509 v3 certificate format and the standard certificate
+   extensions defined in [X.509].  The ISO/IEC and ITU-T documents use
+   the 1997 version of ASN.1; while this document uses the 1988 ASN.1
+   syntax, the encoded certificate and standard extensions are
+   equivalent.  This section also defines private extensions required to
+   support a PKI for the Internet community.
+
+   Certificates may be used in a wide range of applications and
+   environments covering a broad spectrum of interoperability goals and
+   a broader spectrum of operational and assurance requirements.  The
+   goal of this document is to establish a common baseline for generic
+   applications requiring broad interoperability and limited special
+   purpose requirements.  In particular, the emphasis will be on
+   supporting the use of X.509 v3 certificates for informal Internet
+   electronic mail, IPsec, and WWW applications.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 14]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.1  Basic Certificate Fields
+
+   The X.509 v3 certificate basic syntax is as follows.  For signature
+   calculation, the data that is to be signed is encoded using the ASN.1
+   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
+   tag, length, value encoding system for each element.
+
+   Certificate  ::=  SEQUENCE  {
+        tbsCertificate       TBSCertificate,
+        signatureAlgorithm   AlgorithmIdentifier,
+        signatureValue       BIT STRING  }
+
+   TBSCertificate  ::=  SEQUENCE  {
+        version         [0]  EXPLICIT Version DEFAULT v1,
+        serialNumber         CertificateSerialNumber,
+        signature            AlgorithmIdentifier,
+        issuer               Name,
+        validity             Validity,
+        subject              Name,
+        subjectPublicKeyInfo SubjectPublicKeyInfo,
+        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
+                             -- If present, version MUST be v2 or v3
+        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
+                             -- If present, version MUST be v2 or v3
+        extensions      [3]  EXPLICIT Extensions OPTIONAL
+                             -- If present, version MUST be v3
+        }
+
+   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
+
+   CertificateSerialNumber  ::=  INTEGER
+
+   Validity ::= SEQUENCE {
+        notBefore      Time,
+        notAfter       Time }
+
+   Time ::= CHOICE {
+        utcTime        UTCTime,
+        generalTime    GeneralizedTime }
+
+   UniqueIdentifier  ::=  BIT STRING
+
+   SubjectPublicKeyInfo  ::=  SEQUENCE  {
+        algorithm            AlgorithmIdentifier,
+        subjectPublicKey     BIT STRING  }
+
+   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 15]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   Extension  ::=  SEQUENCE  {
+        extnID      OBJECT IDENTIFIER,
+        critical    BOOLEAN DEFAULT FALSE,
+        extnValue   OCTET STRING  }
+
+   The following items describe the X.509 v3 certificate for use in the
+   Internet.
+
+4.1.1  Certificate Fields
+
+   The Certificate is a SEQUENCE of three required fields.  The fields
+   are described in detail in the following subsections.
+
+4.1.1.1  tbsCertificate
+
+   The field contains the names of the subject and issuer, a public key
+   associated with the subject, a validity period, and other associated
+   information.  The fields are described in detail in section 4.1.2;
+   the tbsCertificate usually includes extensions which are described in
+   section 4.2.
+
+4.1.1.2  signatureAlgorithm
+
+   The signatureAlgorithm field contains the identifier for the
+   cryptographic algorithm used by the CA to sign this certificate.
+   [PKIXALGS] lists supported signature algorithms, but other signature
+   algorithms MAY also be supported.
+
+   An algorithm identifier is defined by the following ASN.1 structure:
+
+   AlgorithmIdentifier  ::=  SEQUENCE  {
+        algorithm               OBJECT IDENTIFIER,
+        parameters              ANY DEFINED BY algorithm OPTIONAL  }
+
+   The algorithm identifier is used to identify a cryptographic
+   algorithm.  The OBJECT IDENTIFIER component identifies the algorithm
+   (such as DSA with SHA-1).  The contents of the optional parameters
+   field will vary according to the algorithm identified.
+
+   This field MUST contain the same algorithm identifier as the
+   signature field in the sequence tbsCertificate (section 4.1.2.3).
+
+4.1.1.3  signatureValue
+
+   The signatureValue field contains a digital signature computed upon
+   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
+   tbsCertificate is used as the input to the signature function.  This
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 16]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   signature value is encoded as a BIT STRING and included in the
+   signature field.  The details of this process are specified for each
+   of algorithms listed in [PKIXALGS].
+
+   By generating this signature, a CA certifies the validity of the
+   information in the tbsCertificate field.  In particular, the CA
+   certifies the binding between the public key material and the subject
+   of the certificate.
+
+4.1.2  TBSCertificate
+
+   The sequence TBSCertificate contains information associated with the
+   subject of the certificate and the CA who issued it.  Every
+   TBSCertificate contains the names of the subject and issuer, a public
+   key associated with the subject, a validity period, a version number,
+   and a serial number; some MAY contain optional unique identifier
+   fields.  The remainder of this section describes the syntax and
+   semantics of these fields.  A TBSCertificate usually includes
+   extensions.  Extensions for the Internet PKI are described in Section
+   4.2.
+
+4.1.2.1  Version
+
+   This field describes the version of the encoded certificate.  When
+   extensions are used, as expected in this profile, version MUST be 3
+   (value is 2).  If no extensions are present, but a UniqueIdentifier
+   is present, the version SHOULD be 2 (value is 1); however version MAY
+   be 3.  If only basic fields are present, the version SHOULD be 1 (the
+   value is omitted from the certificate as the default value); however
+   the version MAY be 2 or 3.
+
+   Implementations SHOULD be prepared to accept any version certificate.
+   At a minimum, conforming implementations MUST recognize version 3
+   certificates.
+
+   Generation of version 2 certificates is not expected by
+   implementations based on this profile.
+
+4.1.2.2  Serial number
+
+   The serial number MUST be a positive integer assigned by the CA to
+   each certificate.  It MUST be unique for each certificate issued by a
+   given CA (i.e., the issuer name and serial number identify a unique
+   certificate).  CAs MUST force the serialNumber to be a non-negative
+   integer.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 17]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   Given the uniqueness requirements above, serial numbers can be
+   expected to contain long integers.  Certificate users MUST be able to
+   handle serialNumber values up to 20 octets.  Conformant CAs MUST NOT
+   use serialNumber values longer than 20 octets.
+
+   Note: Non-conforming CAs may issue certificates with serial numbers
+   that are negative, or zero.  Certificate users SHOULD be prepared to
+   gracefully handle such certificates.
+
+4.1.2.3  Signature
+
+   This field contains the algorithm identifier for the algorithm used
+   by the CA to sign the certificate.
+
+   This field MUST contain the same algorithm identifier as the
+   signatureAlgorithm field in the sequence Certificate (section
+   4.1.1.2).  The contents of the optional parameters field will vary
+   according to the algorithm identified.  [PKIXALGS] lists the
+   supported signature algorithms, but other signature algorithms MAY
+   also be supported.
+
+4.1.2.4  Issuer
+
+   The issuer field identifies the entity who has signed and issued the
+   certificate.  The issuer field MUST contain a non-empty distinguished
+   name (DN).  The issuer field is defined as the X.501 type Name
+   [X.501].  Name is defined by the following ASN.1 structures:
+
+   Name ::= CHOICE {
+     RDNSequence }
+
+   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+   RelativeDistinguishedName ::=
+     SET OF AttributeTypeAndValue
+
+   AttributeTypeAndValue ::= SEQUENCE {
+     type     AttributeType,
+     value    AttributeValue }
+
+   AttributeType ::= OBJECT IDENTIFIER
+
+   AttributeValue ::= ANY DEFINED BY AttributeType
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 18]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   DirectoryString ::= CHOICE {
+         teletexString           TeletexString (SIZE (1..MAX)),
+         printableString         PrintableString (SIZE (1..MAX)),
+         universalString         UniversalString (SIZE (1..MAX)),
+         utf8String              UTF8String (SIZE (1..MAX)),
+         bmpString               BMPString (SIZE (1..MAX)) }
+
+   The Name describes a hierarchical name composed of attributes, such
+   as country name, and corresponding values, such as US.  The type of
+   the component AttributeValue is determined by the AttributeType; in
+   general it will be a DirectoryString.
+
+   The DirectoryString type is defined as a choice of PrintableString,
+   TeletexString, BMPString, UTF8String, and UniversalString.  The
+   UTF8String encoding [RFC 2279] is the preferred encoding, and all
+   certificates issued after December 31, 2003 MUST use the UTF8String
+   encoding of DirectoryString (except as noted below).  Until that
+   date, conforming CAs MUST choose from the following options when
+   creating a distinguished name, including their own:
+
+      (a)  if the character set is sufficient, the string MAY be
+      represented as a PrintableString;
+
+      (b)  failing (a), if the BMPString character set is sufficient the
+      string MAY be represented as a BMPString; and
+
+      (c)  failing (a) and (b), the string MUST be represented as a
+      UTF8String.  If (a) or (b) is satisfied, the CA MAY still choose
+      to represent the string as a UTF8String.
+
+   Exceptions to the December 31, 2003 UTF8 encoding requirements are as
+   follows:
+
+      (a)  CAs MAY issue "name rollover" certificates to support an
+      orderly migration to UTF8String encoding.  Such certificates would
+      include the CA's UTF8String encoded name as issuer and and the old
+      name encoding as subject, or vice-versa.
+
+      (b)  As stated in section 4.1.2.6, the subject field MUST be
+      populated with a non-empty distinguished name matching the
+      contents of the issuer field in all certificates issued by the
+      subject CA regardless of encoding.
+
+   The TeletexString and UniversalString are included for backward
+   compatibility, and SHOULD NOT be used for certificates for new
+   subjects.  However, these types MAY be used in certificates where the
+   name was previously established.  Certificate users SHOULD be
+   prepared to receive certificates with these types.
+
+
+
+Housley, et. al.            Standards Track                    [Page 19]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   In addition, many legacy implementations support names encoded in the
+   ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
+   TeletexString.  TeletexString encodes a larger character set than ISO
+   8859-1, but it encodes some characters differently.  Implementations
+   SHOULD be prepared to handle both encodings.
+
+   As noted above, distinguished names are composed of attributes.  This
+   specification does not restrict the set of attribute types that may
+   appear in names.  However, conforming implementations MUST be
+   prepared to receive certificates with issuer names containing the set
+   of attribute types defined below.  This specification RECOMMENDS
+   support for additional attribute types.
+
+   Standard sets of attributes have been defined in the X.500 series of
+   specifications [X.520].  Implementations of this specification MUST
+   be prepared to receive the following standard attribute types in
+   issuer and subject (section 4.1.2.6) names:
+
+      * country,
+      * organization,
+      * organizational-unit,
+      * distinguished name qualifier,
+      * state or province name,
+      * common name (e.g., "Susan Housley"), and
+      * serial number.
+
+   In addition, implementations of this specification SHOULD be prepared
+   to receive the following standard attribute types in issuer and
+   subject names:
+
+      * locality,
+      * title,
+      * surname,
+      * given name,
+      * initials,
+      * pseudonym, and
+      * generation qualifier (e.g., "Jr.", "3rd", or "IV").
+
+   The syntax and associated object identifiers (OIDs) for these
+   attribute types are provided in the ASN.1 modules in Appendix A.
+
+   In addition, implementations of this specification MUST be prepared
+   to receive the domainComponent attribute, as defined in [RFC 2247].
+   The Domain Name System (DNS) provides a hierarchical resource
+   labeling system.  This attribute provides a convenient mechanism for
+   organizations that wish to use DNs that parallel their DNS names.
+   This is not a replacement for the dNSName component of the
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 20]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   alternative name field.  Implementations are not required to convert
+   such names into DNS names.  The syntax and associated OID for this
+   attribute type is provided in the ASN.1 modules in Appendix A.
+
+   Certificate users MUST be prepared to process the issuer
+   distinguished name and subject distinguished name (section 4.1.2.6)
+   fields to perform name chaining for certification path validation
+   (section 6).  Name chaining is performed by matching the issuer
+   distinguished name in one certificate with the subject name in a CA
+   certificate.
+
+   This specification requires only a subset of the name comparison
+   functionality specified in the X.500 series of specifications.
+   Conforming implementations are REQUIRED to implement the following
+   name comparison rules:
+
+      (a)  attribute values encoded in different types (e.g.,
+      PrintableString and BMPString) MAY be assumed to represent
+      different strings;
+
+      (b) attribute values in types other than PrintableString are case
+      sensitive (this permits matching of attribute values as binary
+      objects);
+
+      (c)  attribute values in PrintableString are not case sensitive
+      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
+
+      (d)  attribute values in PrintableString are compared after
+      removing leading and trailing white space and converting internal
+      substrings of one or more consecutive white space characters to a
+      single space.
+
+   These name comparison rules permit a certificate user to validate
+   certificates issued using languages or encodings unfamiliar to the
+   certificate user.
+
+   In addition, implementations of this specification MAY use these
+   comparison rules to process unfamiliar attribute types for name
+   chaining.  This allows implementations to process certificates with
+   unfamiliar attributes in the issuer name.
+
+   Note that the comparison rules defined in the X.500 series of
+   specifications indicate that the character sets used to encode data
+   in distinguished names are irrelevant.  The characters themselves are
+   compared without regard to encoding.  Implementations of this profile
+   are permitted to use the comparison algorithm defined in the X.500
+   series.  Such an implementation will recognize a superset of name
+   matches recognized by the algorithm specified above.
+
+
+
+Housley, et. al.            Standards Track                    [Page 21]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.1.2.5  Validity
+
+   The certificate validity period is the time interval during which the
+   CA warrants that it will maintain information about the status of the
+   certificate.  The field is represented as a SEQUENCE of two dates:
+   the date on which the certificate validity period begins (notBefore)
+   and the date on which the certificate validity period ends
+   (notAfter).  Both notBefore and notAfter may be encoded as UTCTime or
+   GeneralizedTime.
+
+   CAs conforming to this profile MUST always encode certificate
+   validity dates through the year 2049 as UTCTime; certificate validity
+   dates in 2050 or later MUST be encoded as GeneralizedTime.
+
+   The validity period for a certificate is the period of time from
+   notBefore through notAfter, inclusive.
+
+4.1.2.5.1  UTCTime
+
+   The universal time type, UTCTime, is a standard ASN.1 type intended
+   for representation of dates and time.  UTCTime specifies the year
+   through the two low order digits and time is specified to the
+   precision of one minute or one second.  UTCTime includes either Z
+   (for Zulu, or Greenwich Mean Time) or a time differential.
+
+   For the purposes of this profile, UTCTime values MUST be expressed
+   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
+   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
+   systems MUST interpret the year field (YY) as follows:
+
+      Where YY is greater than or equal to 50, the year SHALL be
+      interpreted as 19YY; and
+
+      Where YY is less than 50, the year SHALL be interpreted as 20YY.
+
+4.1.2.5.2  GeneralizedTime
+
+   The generalized time type, GeneralizedTime, is a standard ASN.1 type
+   for variable precision representation of time.  Optionally, the
+   GeneralizedTime field can include a representation of the time
+   differential between local and Greenwich Mean Time.
+
+   For the purposes of this profile, GeneralizedTime values MUST be
+   expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
+   times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
+   GeneralizedTime values MUST NOT include fractional seconds.
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 22]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.1.2.6  Subject
+
+   The subject field identifies the entity associated with the public
+   key stored in the subject public key field.  The subject name MAY be
+   carried in the subject field and/or the subjectAltName extension.  If
+   the subject is a CA (e.g., the basic constraints extension, as
+   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
+   the subject field MUST be populated with a non-empty distinguished
+   name matching the contents of the issuer field (section 4.1.2.4) in
+   all certificates issued by the subject CA.  If the subject is a CRL
+   issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
+   present and the value of cRLSign is TRUE) then the subject field MUST
+   be populated with a non-empty distinguished name matching the
+   contents of the issuer field (section 4.1.2.4) in all CRLs issued by
+   the subject CRL issuer.  If subject naming information is present
+   only in the subjectAltName extension (e.g., a key bound only to an
+   email address or URI), then the subject name MUST be an empty
+   sequence and the subjectAltName extension MUST be critical.
+
+   Where it is non-empty, the subject field MUST contain an X.500
+   distinguished name (DN).  The DN MUST be unique for each subject
+   entity certified by the one CA as defined by the issuer name field.
+   A CA MAY issue more than one certificate with the same DN to the same
+   subject entity.
+
+   The subject name field is defined as the X.501 type Name.
+   Implementation requirements for this field are those defined for the
+   issuer field (section 4.1.2.4).  When encoding attribute values of
+   type DirectoryString, the encoding rules for the issuer field MUST be
+   implemented.  Implementations of this specification MUST be prepared
+   to receive subject names containing the attribute types required for
+   the issuer field.  Implementations of this specification SHOULD be
+   prepared to receive subject names containing the recommended
+   attribute types for the issuer field.  The syntax and associated
+   object identifiers (OIDs) for these attribute types are provided in
+   the ASN.1 modules in Appendix A.  Implementations of this
+   specification MAY use these comparison rules to process unfamiliar
+   attribute types (i.e., for name chaining).  This allows
+   implementations to process certificates with unfamiliar attributes in
+   the subject name.
+
+   In addition, legacy implementations exist where an RFC 822 name is
+   embedded in the subject distinguished name as an EmailAddress
+   attribute.  The attribute value for EmailAddress is of type IA5String
+   to permit inclusion of the character '@', which is not part of the
+   PrintableString character set.  EmailAddress attribute values are not
+   case sensitive (e.g., "fanfeedback@redsox.com" is the same as
+   "FANFEEDBACK@REDSOX.COM").
+
+
+
+Housley, et. al.            Standards Track                    [Page 23]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   Conforming implementations generating new certificates with
+   electronic mail addresses MUST use the rfc822Name in the subject
+   alternative name field (section 4.2.1.7) to describe such identities.
+   Simultaneous inclusion of the EmailAddress attribute in the subject
+   distinguished name to support legacy implementations is deprecated
+   but permitted.
+
+4.1.2.7  Subject Public Key Info
+
+   This field is used to carry the public key and identify the algorithm
+   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
+   algorithm is identified using the AlgorithmIdentifier structure
+   specified in section 4.1.1.2.  The object identifiers for the
+   supported algorithms and the methods for encoding the public key
+   materials (public key and parameters) are specified in [PKIXALGS].
+
+4.1.2.8  Unique Identifiers
+
+   These fields MUST only appear if the version is 2 or 3 (section
+   4.1.2.1).  These fields MUST NOT appear if the version is 1.  The
+   subject and issuer unique identifiers are present in the certificate
+   to handle the possibility of reuse of subject and/or issuer names
+   over time.  This profile RECOMMENDS that names not be reused for
+   different entities and that Internet certificates not make use of
+   unique identifiers.  CAs conforming to this profile SHOULD NOT
+   generate certificates with unique identifiers.  Applications
+   conforming to this profile SHOULD be capable of parsing unique
+   identifiers.
+
+4.1.2.9  Extensions
+
+   This field MUST only appear if the version is 3 (section 4.1.2.1).
+   If present, this field is a SEQUENCE of one or more certificate
+   extensions.  The format and content of certificate extensions in the
+   Internet PKI is defined in section 4.2.
+
+4.2  Certificate Extensions
+
+   The extensions defined for X.509 v3 certificates provide methods for
+   associating additional attributes with users or public keys and for
+   managing a certification hierarchy.  The X.509 v3 certificate format
+   also allows communities to define private extensions to carry
+   information unique to those communities.  Each extension in a
+   certificate is designated as either critical or non-critical.  A
+   certificate using system MUST reject the certificate if it encounters
+   a critical extension it does not recognize; however, a non-critical
+   extension MAY be ignored if it is not recognized.  The following
+   sections present recommended extensions used within Internet
+
+
+
+Housley, et. al.            Standards Track                    [Page 24]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   certificates and standard locations for information.  Communities may
+   elect to use additional extensions; however, caution ought to be
+   exercised in adopting any critical extensions in certificates which
+   might prevent use in a general context.
+
+   Each extension includes an OID and an ASN.1 structure.  When an
+   extension appears in a certificate, the OID appears as the field
+   extnID and the corresponding ASN.1 encoded structure is the value of
+   the octet string extnValue.  A certificate MUST NOT include more than
+   one instance of a particular extension.  For example, a certificate
+   may contain only one authority key identifier extension (section
+   4.2.1.1).  An extension includes the boolean critical, with a default
+   value of FALSE.  The text for each extension specifies the acceptable
+   values for the critical field.
+
+   Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
+   4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
+   4.2.1.3), and certificate policies (section 4.2.1.5) extensions.  If
+   the CA issues certificates with an empty sequence for the subject
+   field, the CA MUST support the subject alternative name extension
+   (section 4.2.1.7).  Support for the remaining extensions is OPTIONAL.
+   Conforming CAs MAY support extensions that are not identified within
+   this specification; certificate issuers are cautioned that marking
+   such extensions as critical may inhibit interoperability.
+
+   At a minimum, applications conforming to this profile MUST recognize
+   the following extensions: key usage (section 4.2.1.3), certificate
+   policies (section 4.2.1.5), the subject alternative name (section
+   4.2.1.7), basic constraints (section 4.2.1.10), name constraints
+   (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
+   key usage (section 4.2.1.13), and inhibit any-policy (section
+   4.2.1.15).
+
+   In addition, applications conforming to this profile SHOULD recognize
+   the authority and subject key identifier (sections 4.2.1.1 and
+   4.2.1.2), and policy mapping (section 4.2.1.6) extensions.
+
+4.2.1  Standard Extensions
+
+   This section identifies standard certificate extensions defined in
+   [X.509] for use in the Internet PKI.  Each extension is associated
+   with an OID defined in [X.509].  These OIDs are members of the id-ce
+   arc, which is defined by the following:
+
+   id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 25]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.2.1.1  Authority Key Identifier
+
+   The authority key identifier extension provides a means of
+   identifying the public key corresponding to the private key used to
+   sign a certificate.  This extension is used where an issuer has
+   multiple signing keys (either due to multiple concurrent key pairs or
+   due to changeover).  The identification MAY be based on either the
+   key identifier (the subject key identifier in the issuer's
+   certificate) or on the issuer name and serial number.
+
+   The keyIdentifier field of the authorityKeyIdentifier extension MUST
+   be included in all certificates generated by conforming CAs to
+   facilitate certification path construction.  There is one exception;
+   where a CA distributes its public key in the form of a "self-signed"
+   certificate, the authority key identifier MAY be omitted.  The
+   signature on a self-signed certificate is generated with the private
+   key associated with the certificate's subject public key.  (This
+   proves that the issuer possesses both the public and private keys.)
+   In this case, the subject and authority key identifiers would be
+   identical, but only the subject key identifier is needed for
+   certification path building.
+
+   The value of the keyIdentifier field SHOULD be derived from the
+   public key used to verify the certificate's signature or a method
+   that generates unique values.  Two common methods for generating key
+   identifiers from the public key, and one common method for generating
+   unique values, are described in section 4.2.1.2.  Where a key
+   identifier has not been previously established, this specification
+   RECOMMENDS use of one of these methods for generating keyIdentifiers.
+   Where a key identifier has been previously established, the CA SHOULD
+   use the previously established identifier.
+
+   This profile RECOMMENDS support for the key identifier method by all
+   certificate users.
+
+   This extension MUST NOT be marked critical.
+
+   id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
+
+   AuthorityKeyIdentifier ::= SEQUENCE {
+      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
+      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
+      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
+
+   KeyIdentifier ::= OCTET STRING
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 26]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.2.1.2  Subject Key Identifier
+
+   The subject key identifier extension provides a means of identifying
+   certificates that contain a particular public key.
+
+   To facilitate certification path construction, this extension MUST
+   appear in all conforming CA certificates, that is, all certificates
+   including the basic constraints extension (section 4.2.1.10) where
+   the value of cA is TRUE.  The value of the subject key identifier
+   MUST be the value placed in the key identifier field of the Authority
+   Key Identifier extension (section 4.2.1.1) of certificates issued by
+   the subject of this certificate.
+
+   For CA certificates, subject key identifiers SHOULD be derived from
+   the public key or a method that generates unique values.  Two common
+   methods for generating key identifiers from the public key are:
+
+      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
+      value of the BIT STRING subjectPublicKey (excluding the tag,
+      length, and number of unused bits).
+
+      (2) The keyIdentifier is composed of a four bit type field with
+      the value 0100 followed by the least significant 60 bits of the
+      SHA-1 hash of the value of the BIT STRING subjectPublicKey
+      (excluding the tag, length, and number of unused bit string bits).
+
+   One common method for generating unique values is a monotonically
+   increasing sequence of integers.
+
+   For end entity certificates, the subject key identifier extension
+   provides a means for identifying certificates containing the
+   particular public key used in an application.  Where an end entity
+   has obtained multiple certificates, especially from multiple CAs, the
+   subject key identifier provides a means to quickly identify the set
+   of certificates containing a particular public key.  To assist
+   applications in identifying the appropriate end entity certificate,
+   this extension SHOULD be included in all end entity certificates.
+
+   For end entity certificates, subject key identifiers SHOULD be
+   derived from the public key.  Two common methods for generating key
+   identifiers from the public key are identified above.
+
+   Where a key identifier has not been previously established, this
+   specification RECOMMENDS use of one of these methods for generating
+   keyIdentifiers.  Where a key identifier has been previously
+   established, the CA SHOULD use the previously established identifier.
+
+   This extension MUST NOT be marked critical.
+
+
+
+Housley, et. al.            Standards Track                    [Page 27]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
+
+   SubjectKeyIdentifier ::= KeyIdentifier
+
+4.2.1.3  Key Usage
+
+   The key usage extension defines the purpose (e.g., encipherment,
+   signature, certificate signing) of the key contained in the
+   certificate.  The usage restriction might be employed when a key that
+   could be used for more than one operation is to be restricted.  For
+   example, when an RSA key should be used only to verify signatures on
+   objects other than public key certificates and CRLs, the
+   digitalSignature and/or nonRepudiation bits would be asserted.
+   Likewise, when an RSA key should be used only for key management, the
+   keyEncipherment bit would be asserted.
+
+   This extension MUST appear in certificates that contain public keys
+   that are used to validate digital signatures on other public key
+   certificates or CRLs.  When this extension appears, it SHOULD be
+   marked critical.
+
+      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
+
+      KeyUsage ::= BIT STRING {
+           digitalSignature        (0),
+           nonRepudiation          (1),
+           keyEncipherment         (2),
+           dataEncipherment        (3),
+           keyAgreement            (4),
+           keyCertSign             (5),
+           cRLSign                 (6),
+           encipherOnly            (7),
+           decipherOnly            (8) }
+
+   Bits in the KeyUsage type are used as follows:
+
+      The digitalSignature bit is asserted when the subject public key
+      is used with a digital signature mechanism to support security
+      services other than certificate signing (bit 5), or CRL signing
+      (bit 6).  Digital signature mechanisms are often used for entity
+      authentication and data origin authentication with integrity.
+
+      The nonRepudiation bit is asserted when the subject public key is
+      used to verify digital signatures used to provide a non-
+      repudiation service which protects against the signing entity
+      falsely denying some action, excluding certificate or CRL signing.
+      In the case of later conflict, a reliable third party may
+      determine the authenticity of the signed data.
+
+
+
+Housley, et. al.            Standards Track                    [Page 28]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      Further distinctions between the digitalSignature and
+      nonRepudiation bits may be provided in specific certificate
+      policies.
+
+      The keyEncipherment bit is asserted when the subject public key is
+      used for key transport.  For example, when an RSA key is to be
+      used for key management, then this bit is set.
+
+      The dataEncipherment bit is asserted when the subject public key
+      is used for enciphering user data, other than cryptographic keys.
+
+      The keyAgreement bit is asserted when the subject public key is
+      used for key agreement.  For example, when a Diffie-Hellman key is
+      to be used for key management, then this bit is set.
+
+      The keyCertSign bit is asserted when the subject public key is
+      used for verifying a signature on public key certificates.  If the
+      keyCertSign bit is asserted, then the cA bit in the basic
+      constraints extension (section 4.2.1.10) MUST also be asserted.
+
+      The cRLSign bit is asserted when the subject public key is used
+      for verifying a signature on certificate revocation list (e.g., a
+      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
+      certificates that are used to verify signatures on CRLs.
+
+      The meaning of the encipherOnly bit is undefined in the absence of
+      the keyAgreement bit.  When the encipherOnly bit is asserted and
+      the keyAgreement bit is also set, the subject public key may be
+      used only for enciphering data while performing key agreement.
+
+      The meaning of the decipherOnly bit is undefined in the absence of
+      the keyAgreement bit.  When the decipherOnly bit is asserted and
+      the keyAgreement bit is also set, the subject public key may be
+      used only for deciphering data while performing key agreement.
+
+   This profile does not restrict the combinations of bits that may be
+   set in an instantiation of the keyUsage extension.  However,
+   appropriate values for keyUsage extensions for particular algorithms
+   are specified in [PKIXALGS].
+
+4.2.1.4  Private Key Usage Period
+
+   This extension SHOULD NOT be used within the Internet PKI.  CAs
+   conforming to this profile MUST NOT generate certificates that
+   include a critical private key usage period extension.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 29]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The private key usage period extension allows the certificate issuer
+   to specify a different validity period for the private key than the
+   certificate.  This extension is intended for use with digital
+   signature keys.  This extension consists of two optional components,
+   notBefore and notAfter.  The private key associated with the
+   certificate SHOULD NOT be used to sign objects before or after the
+   times specified by the two components, respectively.  CAs conforming
+   to this profile MUST NOT generate certificates with private key usage
+   period extensions unless at least one of the two components is
+   present and the extension is non-critical.
+
+   Where used, notBefore and notAfter are represented as GeneralizedTime
+   and MUST be specified and interpreted as defined in section
+   4.1.2.5.2.
+
+   id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }
+
+   PrivateKeyUsagePeriod ::= SEQUENCE {
+        notBefore       [0]     GeneralizedTime OPTIONAL,
+        notAfter        [1]     GeneralizedTime OPTIONAL }
+
+4.2.1.5  Certificate Policies
+
+   The certificate policies extension contains a sequence of one or more
+   policy information terms, each of which consists of an object
+   identifier (OID) and optional qualifiers.  Optional qualifiers, which
+   MAY be present, are not expected to change the definition of the
+   policy.
+
+   In an end entity certificate, these policy information terms indicate
+   the policy under which the certificate has been issued and the
+   purposes for which the certificate may be used.  In a CA certificate,
+   these policy information terms limit the set of policies for
+   certification paths which include this certificate.  When a CA does
+   not wish to limit the set of policies for certification paths which
+   include this certificate, it MAY assert the special policy anyPolicy,
+   with a value of { 2 5 29 32 0 }.
+
+   Applications with specific policy requirements are expected to have a
+   list of those policies which they will accept and to compare the
+   policy OIDs in the certificate to that list.  If this extension is
+   critical, the path validation software MUST be able to interpret this
+   extension (including the optional qualifier), or MUST reject the
+   certificate.
+
+   To promote interoperability, this profile RECOMMENDS that policy
+   information terms consist of only an OID.  Where an OID alone is
+   insufficient, this profile strongly recommends that use of qualifiers
+
+
+
+Housley, et. al.            Standards Track                    [Page 30]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   be limited to those identified in this section.  When qualifiers are
+   used with the special policy anyPolicy, they MUST be limited to the
+   qualifiers identified in this section.
+
+   This specification defines two policy qualifier types for use by
+   certificate policy writers and certificate issuers.  The qualifier
+   types are the CPS Pointer and User Notice qualifiers.
+
+   The CPS Pointer qualifier contains a pointer to a Certification
+   Practice Statement (CPS) published by the CA.  The pointer is in the
+   form of a URI.  Processing requirements for this qualifier are a
+   local matter.  No action is mandated by this specification regardless
+   of the criticality value asserted for the extension.
+
+   User notice is intended for display to a relying party when a
+   certificate is used.  The application software SHOULD display all
+   user notices in all certificates of the certification path used,
+   except that if a notice is duplicated only one copy need be
+   displayed.  To prevent such duplication, this qualifier SHOULD only
+   be present in end entity certificates and CA certificates issued to
+   other organizations.
+
+   The user notice has two optional fields: the noticeRef field and the
+   explicitText field.
+
+      The noticeRef field, if used, names an organization and
+      identifies, by number, a particular textual statement prepared by
+      that organization.  For example, it might identify the
+      organization "CertsRUs" and notice number 1.  In a typical
+      implementation, the application software will have a notice file
+      containing the current set of notices for CertsRUs; the
+      application will extract the notice text from the file and display
+      it.  Messages MAY be multilingual, allowing the software to select
+      the particular language message for its own environment.
+
+      An explicitText field includes the textual statement directly in
+      the certificate.  The explicitText field is a string with a
+      maximum size of 200 characters.
+
+   If both the noticeRef and explicitText options are included in the
+   one qualifier and if the application software can locate the notice
+   text indicated by the noticeRef option, then that text SHOULD be
+   displayed; otherwise, the explicitText string SHOULD be displayed.
+
+   Note: While the explicitText has a maximum size of 200 characters,
+   some non-conforming CAs exceed this limit.  Therefore, certificate
+   users SHOULD gracefully handle explicitText with more than 200
+   characters.
+
+
+
+Housley, et. al.            Standards Track                    [Page 31]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
+
+   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
+
+   certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
+
+   PolicyInformation ::= SEQUENCE {
+        policyIdentifier   CertPolicyId,
+        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
+                                PolicyQualifierInfo OPTIONAL }
+
+   CertPolicyId ::= OBJECT IDENTIFIER
+
+   PolicyQualifierInfo ::= SEQUENCE {
+        policyQualifierId  PolicyQualifierId,
+        qualifier          ANY DEFINED BY policyQualifierId }
+
+   -- policyQualifierIds for Internet policy qualifiers
+
+   id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
+   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
+   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
+
+   PolicyQualifierId ::=
+        OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
+
+   Qualifier ::= CHOICE {
+        cPSuri           CPSuri,
+        userNotice       UserNotice }
+
+   CPSuri ::= IA5String
+
+   UserNotice ::= SEQUENCE {
+        noticeRef        NoticeReference OPTIONAL,
+        explicitText     DisplayText OPTIONAL}
+
+   NoticeReference ::= SEQUENCE {
+        organization     DisplayText,
+        noticeNumbers    SEQUENCE OF INTEGER }
+
+   DisplayText ::= CHOICE {
+        ia5String        IA5String      (SIZE (1..200)),
+        visibleString    VisibleString  (SIZE (1..200)),
+        bmpString        BMPString      (SIZE (1..200)),
+        utf8String       UTF8String     (SIZE (1..200)) }
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 32]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.2.1.6  Policy Mappings
+
+   This extension is used in CA certificates.  It lists one or more
+   pairs of OIDs; each pair includes an issuerDomainPolicy and a
+   subjectDomainPolicy.  The pairing indicates the issuing CA considers
+   its issuerDomainPolicy equivalent to the subject CA's
+   subjectDomainPolicy.
+
+   The issuing CA's users might accept an issuerDomainPolicy for certain
+   applications.  The policy mapping defines the list of policies
+   associated with the subject CA that may be accepted as comparable to
+   the issuerDomainPolicy.
+
+   Each issuerDomainPolicy named in the policy mapping extension SHOULD
+   also be asserted in a certificate policies extension in the same
+   certificate.  Policies SHOULD NOT be mapped either to or from the
+   special value anyPolicy (section 4.2.1.5).
+
+   This extension MAY be supported by CAs and/or applications, and it
+   MUST be non-critical.
+
+   id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
+
+   PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+        issuerDomainPolicy      CertPolicyId,
+        subjectDomainPolicy     CertPolicyId }
+
+4.2.1.7  Subject Alternative Name
+
+   The subject alternative names extension allows additional identities
+   to be bound to the subject of the certificate.  Defined options
+   include an Internet electronic mail address, a DNS name, an IP
+   address, and a uniform resource identifier (URI).  Other options
+   exist, including completely local definitions.  Multiple name forms,
+   and multiple instances of each name form, MAY be included.  Whenever
+   such identities are to be bound into a certificate, the subject
+   alternative name (or issuer alternative name) extension MUST be used;
+   however, a DNS name MAY be represented in the subject field using the
+   domainComponent attribute as described in section 4.1.2.4.
+
+   Because the subject alternative name is considered to be definitively
+   bound to the public key, all parts of the subject alternative name
+   MUST be verified by the CA.
+
+   Further, if the only subject identity included in the certificate is
+   an alternative name form (e.g., an electronic mail address), then the
+   subject distinguished name MUST be empty (an empty sequence), and the
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 33]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   subjectAltName extension MUST be present.  If the subject field
+   contains an empty sequence, the subjectAltName extension MUST be
+   marked critical.
+
+   When the subjectAltName extension contains an Internet mail address,
+   the address MUST be included as an rfc822Name.  The format of an
+   rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822].  An
+   addr-spec has the form "local-part@domain".  Note that an addr-spec
+   has no phrase (such as a common name) before it, has no comment (text
+   surrounded in parentheses) after it, and is not surrounded by "<" and
+   ">".  Note that while upper and lower case letters are allowed in an
+   RFC 822 addr-spec, no significance is attached to the case.
+
+   When the subjectAltName extension contains a iPAddress, the address
+   MUST be stored in the octet string in "network byte order," as
+   specified in RFC 791 [RFC 791].  The least significant bit (LSB) of
+   each octet is the LSB of the corresponding byte in the network
+   address.  For IP Version 4, as specified in RFC 791, the octet string
+   MUST contain exactly four octets.  For IP Version 6, as specified in
+   RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
+   1883].
+
+   When the subjectAltName extension contains a domain name system
+   label, the domain name MUST be stored in the dNSName (an IA5String).
+   The name MUST be in the "preferred name syntax," as specified by RFC
+   1034 [RFC 1034].  Note that while upper and lower case letters are
+   allowed in domain names, no signifigance is attached to the case.  In
+   addition, while the string " " is a legal domain name, subjectAltName
+   extensions with a dNSName of " " MUST NOT be used.  Finally, the use
+   of the DNS representation for Internet mail addresses (wpolk.nist.gov
+   instead of wpolk@nist.gov) MUST NOT be used; such identities are to
+   be encoded as rfc822Name.
+
+   Note: work is currently underway to specify domain names in
+   international character sets.  Such names will likely not be
+   accommodated by IA5String.  Once this work is complete, this profile
+   will be revisited and the appropriate functionality will be added.
+
+   When the subjectAltName extension contains a URI, the name MUST be
+   stored in the uniformResourceIdentifier (an IA5String).  The name
+   MUST NOT be a relative URL, and it MUST follow the URL syntax and
+   encoding rules specified in [RFC 1738].  The name MUST include both a
+   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
+   scheme-specific-part MUST include a fully qualified domain name or IP
+   address as the host.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 34]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   As specified in [RFC 1738], the scheme name is not case-sensitive
+   (e.g., "http" is equivalent to "HTTP").  The host part is also not
+   case-sensitive, but other components of the scheme-specific-part may
+   be case-sensitive.  When comparing URIs, conforming implementations
+   MUST compare the scheme and host without regard to case, but assume
+   the remainder of the scheme-specific-part is case sensitive.
+
+   When the subjectAltName extension contains a DN in the directoryName,
+   the DN MUST be unique for each subject entity certified by the one CA
+   as defined by the issuer name field.  A CA MAY issue more than one
+   certificate with the same DN to the same subject entity.
+
+   The subjectAltName MAY carry additional name types through the use of
+   the otherName field.  The format and semantics of the name are
+   indicated through the OBJECT IDENTIFIER in the type-id field.  The
+   name itself is conveyed as value field in otherName.  For example,
+   Kerberos [RFC 1510] format names can be encoded into the otherName,
+   using using a Kerberos 5 principal name OID and a SEQUENCE of the
+   Realm and the PrincipalName.
+
+   Subject alternative names MAY be constrained in the same manner as
+   subject distinguished names using the name constraints extension as
+   described in section 4.2.1.11.
+
+   If the subjectAltName extension is present, the sequence MUST contain
+   at least one entry.  Unlike the subject field, conforming CAs MUST
+   NOT issue certificates with subjectAltNames containing empty
+   GeneralName fields.  For example, an rfc822Name is represented as an
+   IA5String.  While an empty string is a valid IA5String, such an
+   rfc822Name is not permitted by this profile.  The behavior of clients
+   that encounter such a certificate when processing a certificication
+   path is not defined by this profile.
+
+   Finally, the semantics of subject alternative names that include
+   wildcard characters (e.g., as a placeholder for a set of names) are
+   not addressed by this specification.  Applications with specific
+   requirements MAY use such names, but they must define the semantics.
+
+   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
+
+   SubjectAltName ::= GeneralNames
+
+   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 35]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   GeneralName ::= CHOICE {
+        otherName                       [0]     OtherName,
+        rfc822Name                      [1]     IA5String,
+        dNSName                         [2]     IA5String,
+        x400Address                     [3]     ORAddress,
+        directoryName                   [4]     Name,
+        ediPartyName                    [5]     EDIPartyName,
+        uniformResourceIdentifier       [6]     IA5String,
+        iPAddress                       [7]     OCTET STRING,
+        registeredID                    [8]     OBJECT IDENTIFIER }
+
+   OtherName ::= SEQUENCE {
+        type-id    OBJECT IDENTIFIER,
+        value      [0] EXPLICIT ANY DEFINED BY type-id }
+
+   EDIPartyName ::= SEQUENCE {
+        nameAssigner            [0]     DirectoryString OPTIONAL,
+        partyName               [1]     DirectoryString }
+
+4.2.1.8  Issuer Alternative Names
+
+   As with 4.2.1.7, this extension is used to associate Internet style
+   identities with the certificate issuer.  Issuer alternative names
+   MUST be encoded as in 4.2.1.7.
+
+   Where present, this extension SHOULD NOT be marked critical.
+
+   id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
+
+   IssuerAltName ::= GeneralNames
+
+4.2.1.9  Subject Directory Attributes
+
+   The subject directory attributes extension is used to convey
+   identification attributes (e.g., nationality) of the subject.  The
+   extension is defined as a sequence of one or more attributes.  This
+   extension MUST be non-critical.
+
+   id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
+
+   SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
+
+4.2.1.10  Basic Constraints
+
+   The basic constraints extension identifies whether the subject of the
+   certificate is a CA and the maximum depth of valid certification
+   paths that include this certificate.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 36]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The cA boolean indicates whether the certified public key belongs to
+   a CA.  If the cA boolean is not asserted, then the keyCertSign bit in
+   the key usage extension MUST NOT be asserted.
+
+   The pathLenConstraint field is meaningful only if the cA boolean is
+   asserted and the key usage extension asserts the keyCertSign bit
+   (section 4.2.1.3).  In this case, it gives the maximum number of non-
+   self-issued intermediate certificates that may follow this
+   certificate in a valid certification path.  A certificate is self-
+   issued if the DNs that appear in the subject and issuer fields are
+   identical and are not empty.  (Note: The last certificate in the
+   certification path is not an intermediate certificate, and is not
+   included in this limit.  Usually, the last certificate is an end
+   entity certificate, but it can be a CA certificate.)  A
+   pathLenConstraint of zero indicates that only one more certificate
+   may follow in a valid certification path.  Where it appears, the
+   pathLenConstraint field MUST be greater than or equal to zero.  Where
+   pathLenConstraint does not appear, no limit is imposed.
+
+   This extension MUST appear as a critical extension in all CA
+   certificates that contain public keys used to validate digital
+   signatures on certificates.  This extension MAY appear as a critical
+   or non-critical extension in CA certificates that contain public keys
+   used exclusively for purposes other than validating digital
+   signatures on certificates.  Such CA certificates include ones that
+   contain public keys used exclusively for validating digital
+   signatures on CRLs and ones that contain key management public keys
+   used with certificate enrollment protocols.  This extension MAY
+   appear as a critical or non-critical extension in end entity
+   certificates.
+
+   CAs MUST NOT include the pathLenConstraint field unless the cA
+   boolean is asserted and the key usage extension asserts the
+   keyCertSign bit.
+
+   id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
+
+   BasicConstraints ::= SEQUENCE {
+        cA                      BOOLEAN DEFAULT FALSE,
+        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
+
+4.2.1.11  Name Constraints
+
+   The name constraints extension, which MUST be used only in a CA
+   certificate, indicates a name space within which all subject names in
+   subsequent certificates in a certification path MUST be located.
+   Restrictions apply to the subject distinguished name and apply to
+   subject alternative names.  Restrictions apply only when the
+
+
+
+Housley, et. al.            Standards Track                    [Page 37]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   specified name form is present.  If no name of the type is in the
+   certificate, the certificate is acceptable.
+
+   Name constraints are not applied to certificates whose issuer and
+   subject are identical (unless the certificate is the final
+   certificate in the path).  (This could prevent CAs that use name
+   constraints from employing self-issued certificates to implement key
+   rollover.)
+
+   Restrictions are defined in terms of permitted or excluded name
+   subtrees.  Any name matching a restriction in the excludedSubtrees
+   field is invalid regardless of information appearing in the
+   permittedSubtrees.  This extension MUST be critical.
+
+   Within this profile, the minimum and maximum fields are not used with
+   any name forms, thus minimum MUST be zero, and maximum MUST be
+   absent.
+
+   For URIs, the constraint applies to the host part of the name.  The
+   constraint MAY specify a host or a domain.  Examples would be
+   "foo.bar.com";  and ".xyz.com".  When the the constraint begins with
+   a period, it MAY be expanded with one or more subdomains.  That is,
+   the constraint ".xyz.com" is satisfied by both abc.xyz.com and
+   abc.def.xyz.com.  However, the constraint ".xyz.com" is not satisfied
+   by "xyz.com".  When the constraint does not begin with a period, it
+   specifies a host.
+
+   A name constraint for Internet mail addresses MAY specify a
+   particular mailbox, all addresses at a particular host, or all
+   mailboxes in a domain.  To indicate a particular mailbox, the
+   constraint is the complete mail address.  For example, "root@xyz.com"
+   indicates the root mailbox on the host "xyz.com".  To indicate all
+   Internet mail addresses on a particular host, the constraint is
+   specified as the host name.  For example, the constraint "xyz.com" is
+   satisfied by any mail address at the host "xyz.com".  To specify any
+   address within a domain, the constraint is specified with a leading
+   period (as with URIs).  For example, ".xyz.com" indicates all the
+   Internet mail addresses in the domain "xyz.com", but not Internet
+   mail addresses on the host "xyz.com".
+
+   DNS name restrictions are expressed as foo.bar.com.  Any DNS name
+   that can be constructed by simply adding to the left hand side of the
+   name satisfies the name constraint.  For example, www.foo.bar.com
+   would satisfy the constraint but foo1.bar.com would not.
+
+   Legacy implementations exist where an RFC 822 name is embedded in the
+   subject distinguished name in an attribute of type EmailAddress
+   (section 4.1.2.6).  When rfc822 names are constrained, but the
+
+
+
+Housley, et. al.            Standards Track                    [Page 38]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   certificate does not include a subject alternative name, the rfc822
+   name constraint MUST be applied to the attribute of type EmailAddress
+   in the subject distinguished name.  The ASN.1 syntax for EmailAddress
+   and the corresponding OID are supplied in Appendix A.
+
+   Restrictions of the form directoryName MUST be applied to the subject
+   field in the certificate and to the subjectAltName extensions of type
+   directoryName.  Restrictions of the form x400Address MUST be applied
+   to subjectAltName extensions of type x400Address.
+
+   When applying restrictions of the form directoryName, an
+   implementation MUST compare DN attributes.  At a minimum,
+   implementations MUST perform the DN comparison rules specified in
+   Section 4.1.2.4.  CAs issuing certificates with a restriction of the
+   form directoryName SHOULD NOT rely on implementation of the full ISO
+   DN name comparison algorithm.  This implies name restrictions MUST be
+   stated identically to the encoding used in the subject field or
+   subjectAltName extension.
+
+   The syntax of iPAddress MUST be as described in section 4.2.1.7 with
+   the following additions specifically for Name Constraints.  For IPv4
+   addresses, the ipAddress field of generalName MUST contain eight (8)
+   octets, encoded in the style of RFC 1519 (CIDR) to represent an
+   address range [RFC 1519].  For IPv6 addresses, the ipAddress field
+   MUST contain 32 octets similarly encoded.  For example, a name
+   constraint for "class C" subnet 10.9.8.0 is represented as the octets
+   0A 09 08 00 FF FF FF 00, representing the CIDR notation
+   10.9.8.0/255.255.255.0.
+
+   The syntax and semantics for name constraints for otherName,
+   ediPartyName, and registeredID are not defined by this specification.
+
+      id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
+
+      NameConstraints ::= SEQUENCE {
+           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
+           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
+
+      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
+
+      GeneralSubtree ::= SEQUENCE {
+           base                    GeneralName,
+           minimum         [0]     BaseDistance DEFAULT 0,
+           maximum         [1]     BaseDistance OPTIONAL }
+
+      BaseDistance ::= INTEGER (0..MAX)
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 39]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.2.1.12  Policy Constraints
+
+   The policy constraints extension can be used in certificates issued
+   to CAs.  The policy constraints extension constrains path validation
+   in two ways.  It can be used to prohibit policy mapping or require
+   that each certificate in a path contain an acceptable policy
+   identifier.
+
+   If the inhibitPolicyMapping field is present, the value indicates the
+   number of additional certificates that may appear in the path before
+   policy mapping is no longer permitted.  For example, a value of one
+   indicates that policy mapping may be processed in certificates issued
+   by the subject of this certificate, but not in additional
+   certificates in the path.
+
+   If the requireExplicitPolicy field is present, the value of
+   requireExplicitPolicy indicates the number of additional certificates
+   that may appear in the path before an explicit policy is required for
+   the entire path.  When an explicit policy is required, it is
+   necessary for all certificates in the path to contain an acceptable
+   policy identifier in the certificate policies extension.  An
+   acceptable policy identifier is the identifier of a policy required
+   by the user of the certification path or the identifier of a policy
+   which has been declared equivalent through policy mapping.
+
+   Conforming CAs MUST NOT issue certificates where policy constraints
+   is a empty sequence.  That is, at least one of the
+   inhibitPolicyMapping field or the requireExplicitPolicy field MUST be
+   present.  The behavior of clients that encounter a empty policy
+   constraints field is not addressed in this profile.
+
+   This extension MAY be critical or non-critical.
+
+   id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
+
+   PolicyConstraints ::= SEQUENCE {
+        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
+        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }
+
+   SkipCerts ::= INTEGER (0..MAX)
+
+4.2.1.13  Extended Key Usage
+
+   This extension indicates one or more purposes for which the certified
+   public key may be used, in addition to or in place of the basic
+   purposes indicated in the key usage extension.  In general, this
+   extension will appear only in end entity certificates.  This
+   extension is defined as follows:
+
+
+
+Housley, et. al.            Standards Track                    [Page 40]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
+
+   ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+   KeyPurposeId ::= OBJECT IDENTIFIER
+
+   Key purposes may be defined by any organization with a need.  Object
+   identifiers used to identify key purposes MUST be assigned in
+   accordance with IANA or ITU-T Recommendation X.660 [X.660].
+
+   This extension MAY, at the option of the certificate issuer, be
+   either critical or non-critical.
+
+   If the extension is present, then the certificate MUST only be used
+   for one of the purposes indicated.  If multiple purposes are
+   indicated the application need not recognize all purposes indicated,
+   as long as the intended purpose is present.  Certificate using
+   applications MAY require that a particular purpose be indicated in
+   order for the certificate to be acceptable to that application.
+
+   If a CA includes extended key usages to satisfy such applications,
+   but does not wish to restrict usages of the key, the CA can include
+   the special keyPurposeID anyExtendedKeyUsage.  If the
+   anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
+   be critical.
+
+   If a certificate contains both a key usage extension and an extended
+   key usage extension, then both extensions MUST be processed
+   independently and the certificate MUST only be used for a purpose
+   consistent with both extensions.  If there is no purpose consistent
+   with both extensions, then the certificate MUST NOT be used for any
+   purpose.
+
+   The following key usage purposes are defined:
+
+   anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
+
+   id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
+
+   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
+   -- TLS WWW server authentication
+   -- Key usage bits that may be consistent: digitalSignature,
+   -- keyEncipherment or keyAgreement
+
+   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
+   -- TLS WWW client authentication
+   -- Key usage bits that may be consistent: digitalSignature
+   -- and/or keyAgreement
+
+
+
+Housley, et. al.            Standards Track                    [Page 41]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
+   -- Signing of downloadable executable code
+   -- Key usage bits that may be consistent: digitalSignature
+
+   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
+   -- E-mail protection
+   -- Key usage bits that may be consistent: digitalSignature,
+   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
+
+   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
+   -- Binding the hash of an object to a time
+   -- Key usage bits that may be consistent: digitalSignature
+   -- and/or nonRepudiation
+
+   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
+   -- Signing OCSP responses
+   -- Key usage bits that may be consistent: digitalSignature
+   -- and/or nonRepudiation
+
+4.2.1.14  CRL Distribution Points
+
+   The CRL distribution points extension identifies how CRL information
+   is obtained.  The extension SHOULD be non-critical, but this profile
+   RECOMMENDS support for this extension by CAs and applications.
+   Further discussion of CRL management is contained in section 5.
+
+   The cRLDistributionPoints extension is a SEQUENCE of
+   DistributionPoint.  A DistributionPoint consists of three fields,
+   each of which is optional: distributionPoint, reasons, and cRLIssuer.
+   While each of these fields is optional, a DistributionPoint MUST NOT
+   consist of only the reasons field; either distributionPoint or
+   cRLIssuer MUST be present.  If the certificate issuer is not the CRL
+   issuer, then the cRLIssuer field MUST be present and contain the Name
+   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
+   then the cRLIssuer field MUST be omitted and the distributionPoint
+   field MUST be present.  If the distributionPoint field is omitted,
+   cRLIssuer MUST be present and include a Name corresponding to an
+   X.500 or LDAP directory entry where the CRL is located.
+
+   When the distributionPoint field is present, it contains either a
+   SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
+   If the cRLDistributionPoints extension contains a general name of
+   type URI, the following semantics MUST be assumed: the URI is a
+   pointer to the current CRL for the associated reasons and will be
+   issued by the associated cRLIssuer.  The expected values for the URI
+   are those defined in 4.2.1.7.  Processing rules for other values are
+   not defined by this specification.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 42]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   If the DistributionPointName contains multiple values, each name
+   describes a different mechanism to obtain the same CRL.  For example,
+   the same CRL could be available for retrieval through both LDAP and
+   HTTP.
+
+   If the DistributionPointName contains the single value
+   nameRelativeToCRLIssuer, the value provides a distinguished name
+   fragment.  The fragment is appended to the X.500 distinguished name
+   of the CRL issuer to obtain the distribution point name.  If the
+   cRLIssuer field in the DistributionPoint is present, then the name
+   fragment is appended to the distinguished name that it contains;
+   otherwise, the name fragment is appended to the certificate issuer
+   distinguished name.  The DistributionPointName MUST NOT use the
+   nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than
+   one distinguished name.
+
+   If the DistributionPoint omits the reasons field, the CRL MUST
+   include revocation information for all reasons.
+
+   The cRLIssuer identifies the entity who signs and issues the CRL.  If
+   present, the cRLIssuer MUST contain at least one an X.500
+   distinguished name (DN), and MAY also contain other name forms.
+   Since the cRLIssuer is compared to the CRL issuer name, the X.501
+   type Name MUST follow the encoding rules for the issuer name field in
+   the certificate (section 4.1.2.4).
+
+   id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }
+
+   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
+
+   DistributionPoint ::= SEQUENCE {
+        distributionPoint       [0]     DistributionPointName OPTIONAL,
+        reasons                 [1]     ReasonFlags OPTIONAL,
+        cRLIssuer               [2]     GeneralNames OPTIONAL }
+
+   DistributionPointName ::= CHOICE {
+        fullName                [0]     GeneralNames,
+        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 43]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   ReasonFlags ::= BIT STRING {
+        unused                  (0),
+        keyCompromise           (1),
+        cACompromise            (2),
+        affiliationChanged      (3),
+        superseded              (4),
+        cessationOfOperation    (5),
+        certificateHold         (6),
+        privilegeWithdrawn      (7),
+        aACompromise            (8) }
+
+4.2.1.15  Inhibit Any-Policy
+
+   The inhibit any-policy extension can be used in certificates issued
+   to CAs.  The inhibit any-policy indicates that the special anyPolicy
+   OID, with the value { 2 5 29 32 0 }, is not considered an explicit
+   match for other certificate policies.  The value indicates the number
+   of additional certificates that may appear in the path before
+   anyPolicy is no longer permitted.  For example, a value of one
+   indicates that anyPolicy may be processed in certificates issued by
+   the subject of this certificate, but not in additional certificates
+   in the path.
+
+   This extension MUST be critical.
+
+   id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
+
+   InhibitAnyPolicy ::= SkipCerts
+
+   SkipCerts ::= INTEGER (0..MAX)
+
+4.2.1.16  Freshest CRL (a.k.a. Delta CRL Distribution Point)
+
+   The freshest CRL extension identifies how delta CRL information is
+   obtained.  The extension MUST be non-critical.  Further discussion of
+   CRL management is contained in section 5.
+
+   The same syntax is used for this extension and the
+   cRLDistributionPoints extension, and is described in section
+   4.2.1.14.  The same conventions apply to both extensions.
+
+   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
+
+   FreshestCRL ::= CRLDistributionPoints
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 44]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+4.2.2  Private Internet Extensions
+
+   This section defines two extensions for use in the Internet Public
+   Key Infrastructure.  These extensions may be used to direct
+   applications to on-line information about the issuing CA or the
+   subject.  As the information may be available in multiple forms, each
+   extension is a sequence of IA5String values, each of which represents
+   a URI.  The URI implicitly specifies the location and format of the
+   information and the method for obtaining the information.
+
+   An object identifier is defined for the private extension.  The
+   object identifier associated with the private extension is defined
+   under the arc id-pe within the arc id-pkix.  Any future extensions
+   defined for the Internet PKI are also expected to be defined under
+   the arc id-pe.
+
+      id-pkix  OBJECT IDENTIFIER  ::=
+               { iso(1) identified-organization(3) dod(6) internet(1)
+                       security(5) mechanisms(5) pkix(7) }
+
+      id-pe  OBJECT IDENTIFIER  ::=  { id-pkix 1 }
+
+4.2.2.1  Authority Information Access
+
+   The authority information access extension indicates how to access CA
+   information and services for the issuer of the certificate in which
+   the extension appears.  Information and services may include on-line
+   validation services and CA policy data.  (The location of CRLs is not
+   specified in this extension; that information is provided by the
+   cRLDistributionPoints extension.)  This extension may be included in
+   end entity or CA certificates, and it MUST be non-critical.
+
+   id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
+
+   AuthorityInfoAccessSyntax  ::=
+           SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+   AccessDescription  ::=  SEQUENCE {
+           accessMethod          OBJECT IDENTIFIER,
+           accessLocation        GeneralName  }
+
+   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+
+   id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
+
+   id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 45]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   Each entry in the sequence AuthorityInfoAccessSyntax describes the
+   format and location of additional information provided by the CA that
+   issued the certificate in which this extension appears.  The type and
+   format of the information is specified by the accessMethod field; the
+   accessLocation field specifies the location of the information.  The
+   retrieval mechanism may be implied by the accessMethod or specified
+   by accessLocation.
+
+   This profile defines two accessMethod OIDs: id-ad-caIssuers and
+   id-ad-ocsp.
+
+   The id-ad-caIssuers OID is used when the additional information lists
+   CAs that have issued certificates superior to the CA that issued the
+   certificate containing this extension.  The referenced CA issuers
+   description is intended to aid certificate users in the selection of
+   a certification path that terminates at a point trusted by the
+   certificate user.
+
+   When id-ad-caIssuers appears as accessMethod, the accessLocation
+   field describes the referenced description server and the access
+   protocol to obtain the referenced description.  The accessLocation
+   field is defined as a GeneralName, which can take several forms.
+   Where the information is available via http, ftp, or ldap,
+   accessLocation MUST be a uniformResourceIdentifier.  Where the
+   information is available via the Directory Access Protocol (DAP),
+   accessLocation MUST be a directoryName.  The entry for that
+   directoryName contains CA certificates in the crossCertificatePair
+   attribute.  When the information is available via electronic mail,
+   accessLocation MUST be an rfc822Name.  The semantics of other
+   id-ad-caIssuers accessLocation name forms are not defined.
+
+   The id-ad-ocsp OID is used when revocation information for the
+   certificate containing this extension is available using the Online
+   Certificate Status Protocol (OCSP) [RFC 2560].
+
+   When id-ad-ocsp appears as accessMethod, the accessLocation field is
+   the location of the OCSP responder, using the conventions defined in
+   [RFC 2560].
+
+   Additional access descriptors may be defined in other PKIX
+   specifications.
+
+4.2.2.2  Subject Information Access
+
+   The subject information access extension indicates how to access
+   information and services for the subject of the certificate in which
+   the extension appears.  When the subject is a CA, information and
+   services may include certificate validation services and CA policy
+
+
+
+Housley, et. al.            Standards Track                    [Page 46]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   data.  When the subject is an end entity, the information describes
+   the type of services offered and how to access them.  In this case,
+   the contents of this extension are defined in the protocol
+   specifications for the suported services.  This extension may be
+   included in subject or CA certificates, and it MUST be non-critical.
+
+   id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
+
+   SubjectInfoAccessSyntax  ::=
+           SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+   AccessDescription  ::=  SEQUENCE {
+           accessMethod          OBJECT IDENTIFIER,
+           accessLocation        GeneralName  }
+
+   Each entry in the sequence SubjectInfoAccessSyntax describes the
+   format and location of additional information provided by the subject
+   of the certificate in which this extension appears.  The type and
+   format of the information is specified by the accessMethod field; the
+   accessLocation field specifies the location of the information.  The
+   retrieval mechanism may be implied by the accessMethod or specified
+   by accessLocation.
+
+   This profile defines one access method to be used when the subject is
+   a CA, and one access method to be used when the subject is an end
+   entity.  Additional access methods may be defined in the future in
+   the protocol specifications for other services.
+
+   The id-ad-caRepository OID is used when the subject is a CA, and
+   publishes its certificates and CRLs (if issued) in a repository.  The
+   accessLocation field is defined as a GeneralName, which can take
+   several forms.  Where the information is available via http, ftp, or
+   ldap, accessLocation MUST be a uniformResourceIdentifier.  Where the
+   information is available via the directory access protocol (dap),
+   accessLocation MUST be a directoryName.  When the information is
+   available via electronic mail, accessLocation MUST be an rfc822Name.
+   The semantics of other name forms of of accessLocation (when
+   accessMethod is id-ad-caRepository) are not defined by this
+   specification.
+
+   The id-ad-timeStamping OID is used when the subject offers
+   timestamping services using the Time Stamp Protocol defined in
+   [PKIXTSA].  Where the timestamping services are available via http or
+   ftp, accessLocation MUST be a uniformResourceIdentifier.  Where the
+   timestamping services are available via electronic mail,
+   accessLocation MUST be an rfc822Name.  Where timestamping services
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 47]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   are available using TCP/IP, the dNSName or ipAddress name forms may
+   be used.  The semantics of other name forms of accessLocation (when
+   accessMethod is id-ad-timeStamping) are not defined by this
+   specification.
+
+   Additional access descriptors may be defined in other PKIX
+   specifications.
+
+   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+
+   id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
+
+   id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
+
+5  CRL and CRL Extensions Profile
+
+   As discussed above, one goal of this X.509 v2 CRL profile is to
+   foster the creation of an interoperable and reusable Internet PKI.
+   To achieve this goal, guidelines for the use of extensions are
+   specified, and some assumptions are made about the nature of
+   information included in the CRL.
+
+   CRLs may be used in a wide range of applications and environments
+   covering a broad spectrum of interoperability goals and an even
+   broader spectrum of operational and assurance requirements.  This
+   profile establishes a common baseline for generic applications
+   requiring broad interoperability.  The profile defines a set of
+   information that can be expected in every CRL.  Also, the profile
+   defines common locations within the CRL for frequently used
+   attributes as well as common representations for these attributes.
+
+   CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
+   publish CRLs to provide status information about the certificates
+   they issued.  However, a CA may delegate this responsibility to
+   another trusted authority.  Whenever the CRL issuer is not the CA
+   that issued the certificates, the CRL is referred to as an indirect
+   CRL.
+
+   Each CRL has a particular scope.  The CRL scope is the set of
+   certificates that could appear on a given CRL.  For example, the
+   scope could be "all certificates issued by CA X", "all CA
+   certificates issued by CA X", "all certificates issued by CA X that
+   have been revoked for reasons of key compromise and CA compromise",
+   or could be a set of certificates based on arbitrary local
+   information, such as "all certificates issued to the NIST employees
+   located in Boulder".
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 48]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   A complete CRL lists all unexpired certificates, within its scope,
+   that have been revoked for one of the revocation reasons covered by
+   the CRL scope.  The CRL issuer MAY also generate delta CRLs.  A delta
+   CRL only lists those certificates, within its scope, whose revocation
+   status has changed since the issuance of a referenced complete CRL.
+   The referenced complete CRL is referred to as a base CRL.  The scope
+   of a delta CRL MUST be the same as the base CRL that it references.
+
+   This profile does not define any private Internet CRL extensions or
+   CRL entry extensions.
+
+   Environments with additional or special purpose requirements may
+   build on this profile or may replace it.
+
+   Conforming CAs are not required to issue CRLs if other revocation or
+   certificate status mechanisms are provided.  When CRLs are issued,
+   the CRLs MUST be version 2 CRLs, include the date by which the next
+   CRL will be issued in the nextUpdate field (section 5.1.2.5), include
+   the CRL number extension (section 5.2.3), and include the authority
+   key identifier extension (section 5.2.1).  Conforming applications
+   that support CRLs are REQUIRED to process both version 1 and version
+   2 complete CRLs that provide revocation information for all
+   certificates issued by one CA.  Conforming applications are NOT
+   REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
+   with a scope other than all certificates issued by one CA.
+
+5.1  CRL Fields
+
+   The X.509 v2 CRL syntax is as follows.  For signature calculation,
+   the data that is to be signed is ASN.1 DER encoded.  ASN.1 DER
+   encoding is a tag, length, value encoding system for each element.
+
+   CertificateList  ::=  SEQUENCE  {
+        tbsCertList          TBSCertList,
+        signatureAlgorithm   AlgorithmIdentifier,
+        signatureValue       BIT STRING  }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 49]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   TBSCertList  ::=  SEQUENCE  {
+        version                 Version OPTIONAL,
+                                     -- if present, MUST be v2
+        signature               AlgorithmIdentifier,
+        issuer                  Name,
+        thisUpdate              Time,
+        nextUpdate              Time OPTIONAL,
+        revokedCertificates     SEQUENCE OF SEQUENCE  {
+             userCertificate         CertificateSerialNumber,
+             revocationDate          Time,
+             crlEntryExtensions      Extensions OPTIONAL
+                                           -- if present, MUST be v2
+                                  }  OPTIONAL,
+        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
+                                           -- if present, MUST be v2
+                                  }
+
+   -- Version, Time, CertificateSerialNumber, and Extensions
+   -- are all defined in the ASN.1 in section 4.1
+
+   -- AlgorithmIdentifier is defined in section 4.1.1.2
+
+   The following items describe the use of the X.509 v2 CRL in the
+   Internet PKI.
+
+5.1.1  CertificateList Fields
+
+   The CertificateList is a SEQUENCE of three required fields.  The
+   fields are described in detail in the following subsections.
+
+5.1.1.1  tbsCertList
+
+   The first field in the sequence is the tbsCertList.  This field is
+   itself a sequence containing the name of the issuer, issue date,
+   issue date of the next list, the optional list of revoked
+   certificates, and optional CRL extensions.  When there are no revoked
+   certificates, the revoked certificates list is absent.  When one or
+   more certificates are revoked, each entry on the revoked certificate
+   list is defined by a sequence of user certificate serial number,
+   revocation date, and optional CRL entry extensions.
+
+5.1.1.2  signatureAlgorithm
+
+   The signatureAlgorithm field contains the algorithm identifier for
+   the algorithm used by the CRL issuer to sign the CertificateList.
+   The field is of type AlgorithmIdentifier, which is defined in section
+   4.1.1.2.  [PKIXALGS] lists the supported algorithms for this
+   specification, but other signature algorithms MAY also be supported.
+
+
+
+Housley, et. al.            Standards Track                    [Page 50]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   This field MUST contain the same algorithm identifier as the
+   signature field in the sequence tbsCertList (section 5.1.2.2).
+
+5.1.1.3  signatureValue
+
+   The signatureValue field contains a digital signature computed upon
+   the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
+   is used as the input to the signature function.  This signature value
+   is encoded as a BIT STRING and included in the CRL signatureValue
+   field.  The details of this process are specified for each of the
+   supported algorithms in [PKIXALGS].
+
+   CAs that are also CRL issuers MAY use one private key to digitally
+   sign certificates and CRLs, or MAY use separate private keys to
+   digitally sign certificates and CRLs.  When separate private keys are
+   employed, each of the public keys associated with these private keys
+   is placed in a separate certificate, one with the keyCertSign bit set
+   in the key usage extension, and one with the cRLSign bit set in the
+   key usage extension (section 4.2.1.3).  When separate private keys
+   are employed, certificates issued by the CA contain one authority key
+   identifier, and the corresponding CRLs contain a different authority
+   key identifier.  The use of separate CA certificates for validation
+   of certificate signatures and CRL signatures can offer improved
+   security characteristics; however, it imposes a burden on
+   applications, and it might limit interoperability.  Many applications
+   construct a certification path, and then validate the certification
+   path (section 6).  CRL checking in turn requires a separate
+   certification path to be constructed and validated for the CA's CRL
+   signature validation certificate.  Applications that perform CRL
+   checking MUST support certification path validation when certificates
+   and CRLs are digitally signed with the same CA private key.  These
+   applications SHOULD support certification path validation when
+   certificates and CRLs are digitally signed with different CA private
+   keys.
+
+5.1.2  Certificate List "To Be Signed"
+
+   The certificate list to be signed, or TBSCertList, is a sequence of
+   required and optional fields.  The required fields identify the CRL
+   issuer, the algorithm used to sign the CRL, the date and time the CRL
+   was issued, and the date and time by which the CRL issuer will issue
+   the next CRL.
+
+   Optional fields include lists of revoked certificates and CRL
+   extensions.  The revoked certificate list is optional to support the
+   case where a CA has not revoked any unexpired certificates that it
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 51]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   has issued.  The profile requires conforming CRL issuers to use the
+   CRL number and authority key identifier CRL extensions in all CRLs
+   issued.
+
+5.1.2.1  Version
+
+   This optional field describes the version of the encoded CRL.  When
+   extensions are used, as required by this profile, this field MUST be
+   present and MUST specify version 2 (the integer value is 1).
+
+5.1.2.2  Signature
+
+   This field contains the algorithm identifier for the algorithm used
+   to sign the CRL.  [PKIXALGS] lists OIDs for the most popular
+   signature algorithms used in the Internet PKI.
+
+   This field MUST contain the same algorithm identifier as the
+   signatureAlgorithm field in the sequence CertificateList (section
+   5.1.1.2).
+
+5.1.2.3  Issuer Name
+
+   The issuer name identifies the entity who has signed and issued the
+   CRL.  The issuer identity is carried in the issuer name field.
+   Alternative name forms may also appear in the issuerAltName extension
+   (section 5.2.2).  The issuer name field MUST contain an X.500
+   distinguished name (DN).  The issuer name field is defined as the
+   X.501 type Name, and MUST follow the encoding rules for the issuer
+   name field in the certificate (section 4.1.2.4).
+
+5.1.2.4  This Update
+
+   This field indicates the issue date of this CRL.  ThisUpdate may be
+   encoded as UTCTime or GeneralizedTime.
+
+   CRL issuers conforming to this profile MUST encode thisUpdate as
+   UTCTime for dates through the year 2049.  CRL issuers conforming to
+   this profile MUST encode thisUpdate as GeneralizedTime for dates in
+   the year 2050 or later.
+
+   Where encoded as UTCTime, thisUpdate MUST be specified and
+   interpreted as defined in section 4.1.2.5.1.  Where encoded as
+   GeneralizedTime, thisUpdate MUST be specified and interpreted as
+   defined in section 4.1.2.5.2.
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 52]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+5.1.2.5  Next Update
+
+   This field indicates the date by which the next CRL will be issued.
+   The next CRL could be issued before the indicated date, but it will
+   not be issued any later than the indicated date.  CRL issuers SHOULD
+   issue CRLs with a nextUpdate time equal to or later than all previous
+   CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.
+
+   This profile requires inclusion of nextUpdate in all CRLs issued by
+   conforming CRL issuers.  Note that the ASN.1 syntax of TBSCertList
+   describes this field as OPTIONAL, which is consistent with the ASN.1
+   structure defined in [X.509].  The behavior of clients processing
+   CRLs which omit nextUpdate is not specified by this profile.
+
+   CRL issuers conforming to this profile MUST encode nextUpdate as
+   UTCTime for dates through the year 2049.  CRL issuers conforming to
+   this profile MUST encode nextUpdate as GeneralizedTime for dates in
+   the year 2050 or later.
+
+   Where encoded as UTCTime, nextUpdate MUST be specified and
+   interpreted as defined in section 4.1.2.5.1.  Where encoded as
+   GeneralizedTime, nextUpdate MUST be specified and interpreted as
+   defined in section 4.1.2.5.2.
+
+5.1.2.6  Revoked Certificates
+
+   When there are no revoked certificates, the revoked certificates list
+   MUST be absent.  Otherwise, revoked certificates are listed by their
+   serial numbers.  Certificates revoked by the CA are uniquely
+   identified by the certificate serial number.  The date on which the
+   revocation occurred is specified.  The time for revocationDate MUST
+   be expressed as described in section 5.1.2.4. Additional information
+   may be supplied in CRL entry extensions; CRL entry extensions are
+   discussed in section 5.3.
+
+5.1.2.7  Extensions
+
+   This field may only appear if the version is 2 (section 5.1.2.1).  If
+   present, this field is a sequence of one or more CRL extensions.  CRL
+   extensions are discussed in section 5.2.
+
+5.2  CRL Extensions
+
+   The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2
+   CRLs [X.509] [X9.55] provide methods for associating additional
+   attributes with CRLs.  The X.509 v2 CRL format also allows
+   communities to define private extensions to carry information unique
+   to those communities.  Each extension in a CRL may be designated as
+
+
+
+Housley, et. al.            Standards Track                    [Page 53]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   critical or non-critical.  A CRL validation MUST fail if it
+   encounters a critical extension which it does not know how to
+   process.  However, an unrecognized non-critical extension may be
+   ignored.  The following subsections present those extensions used
+   within Internet CRLs.  Communities may elect to include extensions in
+   CRLs which are not defined in this specification.  However, caution
+   should be exercised in adopting any critical extensions in CRLs which
+   might be used in a general context.
+
+   Conforming CRL issuers are REQUIRED to include the authority key
+   identifier (section 5.2.1) and the CRL number (section 5.2.3)
+   extensions in all CRLs issued.
+
+5.2.1  Authority Key Identifier
+
+   The authority key identifier extension provides a means of
+   identifying the public key corresponding to the private key used to
+   sign a CRL.  The identification can be based on either the key
+   identifier (the subject key identifier in the CRL signer's
+   certificate) or on the issuer name and serial number.  This extension
+   is especially useful where an issuer has more than one signing key,
+   either due to multiple concurrent key pairs or due to changeover.
+
+   Conforming CRL issuers MUST use the key identifier method, and MUST
+   include this extension in all CRLs issued.
+
+   The syntax for this CRL extension is defined in section 4.2.1.1.
+
+5.2.2  Issuer Alternative Name
+
+   The issuer alternative names extension allows additional identities
+   to be associated with the issuer of the CRL.  Defined options include
+   an rfc822 name (electronic mail address), a DNS name, an IP address,
+   and a URI.  Multiple instances of a name and multiple name forms may
+   be included.  Whenever such identities are used, the issuer
+   alternative name extension MUST be used; however, a DNS name MAY be
+   represented in the issuer field using the domainComponent attribute
+   as described in section 4.1.2.4.
+
+   The issuerAltName extension SHOULD NOT be marked critical.
+
+   The OID and syntax for this CRL extension are defined in section
+   4.2.1.8.
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 54]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+5.2.3  CRL Number
+
+   The CRL number is a non-critical CRL extension which conveys a
+   monotonically increasing sequence number for a given CRL scope and
+   CRL issuer.  This extension allows users to easily determine when a
+   particular CRL supersedes another CRL.  CRL numbers also support the
+   identification of complementary complete CRLs and delta CRLs.  CRL
+   issuers conforming to this profile MUST include this extension in all
+   CRLs.
+
+   If a CRL issuer generates delta CRLs in addition to complete CRLs for
+   a given scope, the complete CRLs and delta CRLs MUST share one
+   numbering sequence.  If a delta CRL and a complete CRL that cover the
+   same scope are issued at the same time, they MUST have the same CRL
+   number and provide the same revocation information.  That is, the
+   combination of the delta CRL and an acceptable complete CRL MUST
+   provide the same revocation information as the simultaneously issued
+   complete CRL.
+
+   If a CRL issuer generates two CRLs (two complete CRLs, two delta
+   CRLs, or a complete CRL and a delta CRL) for the same scope at
+   different times, the two CRLs MUST NOT have the same CRL number.
+   That is, if the this update field (section 5.1.2.4) in the two CRLs
+   are not identical, the CRL numbers MUST be different.
+
+   Given the requirements above, CRL numbers can be expected to contain
+   long integers.  CRL verifiers MUST be able to handle CRLNumber values
+   up to 20 octets.  Conformant CRL issuers MUST NOT use CRLNumber
+   values longer than 20 octets.
+
+   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
+
+   CRLNumber ::= INTEGER (0..MAX)
+
+5.2.4  Delta CRL Indicator
+
+   The delta CRL indicator is a critical CRL extension that identifies a
+   CRL as being a delta CRL.  Delta CRLs contain updates to revocation
+   information previously distributed, rather than all the information
+   that would appear in a complete CRL.  The use of delta CRLs can
+   significantly reduce network load and processing time in some
+   environments.  Delta CRLs are generally smaller than the CRLs they
+   update, so applications that obtain delta CRLs consume less network
+   bandwidth than applications that obtain the corresponding complete
+   CRLs.  Applications which store revocation information in a format
+   other than the CRL structure can add new revocation information to
+   the local database without reprocessing information.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 55]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The delta CRL indicator extension contains the single value of type
+   BaseCRLNumber.  The CRL number identifies the CRL, complete for a
+   given scope, that was used as the starting point in the generation of
+   this delta CRL.  A conforming CRL issuer MUST publish the referenced
+   base CRL as a complete CRL.  The delta CRL contains all updates to
+   the revocation status for that same scope.  The combination of a
+   delta CRL plus the referenced base CRL is equivalent to a complete
+   CRL, for the applicable scope, at the time of publication of the
+   delta CRL.
+
+   When a conforming CRL issuer generates a delta CRL, the delta CRL
+   MUST include a critical delta CRL indicator extension.
+
+   When a delta CRL is issued, it MUST cover the same set of reasons and
+   the same set of certificates that were covered by the base CRL it
+   references.  That is, the scope of the delta CRL MUST be the same as
+   the scope of the complete CRL referenced as the base.  The referenced
+   base CRL and the delta CRL MUST omit the issuing distribution point
+   extension or contain identical issuing distribution point extensions.
+   Further, the CRL issuer MUST use the same private key to sign the
+   delta CRL and any complete CRL that it can be used to update.
+
+   An application that supports delta CRLs can construct a CRL that is
+   complete for a given scope by combining a delta CRL for that scope
+   with either an issued CRL that is complete for that scope or a
+   locally constructed CRL that is complete for that scope.
+
+   When a delta CRL is combined with a complete CRL or a locally
+   constructed CRL, the resulting locally constructed CRL has the CRL
+   number specified in the CRL number extension found in the delta CRL
+   used in its construction.  In addition, the resulting locally
+   constructed CRL has the thisUpdate and nextUpdate times specified in
+   the corresponding fields of the delta CRL used in its construction.
+   In addition, the locally constructed CRL inherits the issuing
+   distribution point from the delta CRL.
+
+   A complete CRL and a delta CRL MAY be combined if the following four
+   conditions are satisfied:
+
+      (a)  The complete CRL and delta CRL have the same issuer.
+
+      (b)  The complete CRL and delta CRL have the same scope.  The two
+      CRLs have the same scope if either of the following conditions are
+      met:
+
+         (1)  The issuingDistributionPoint extension is omitted from
+         both the complete CRL and the delta CRL.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 56]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+         (2)  The issuingDistributionPoint extension is present in both
+         the complete CRL and the delta CRL, and the values for each of
+         the fields in the extensions are the same in both CRLs.
+
+      (c)  The CRL number of the complete CRL is equal to or greater
+      than the BaseCRLNumber specified in the delta CRL.  That is, the
+      complete CRL contains (at a minimum) all the revocation
+      information held by the referenced base CRL.
+
+      (d)  The CRL number of the complete CRL is less than the CRL
+      number of the delta CRL.  That is, the delta CRL follows the
+      complete CRL in the numbering sequence.
+
+   CRL issuers MUST ensure that the combination of a delta CRL and any
+   appropriate complete CRL accurately reflects the current revocation
+   status.  The CRL issuer MUST include an entry in the delta CRL for
+   each certificate within the scope of the delta CRL whose status has
+   changed since the generation of the referenced base CRL:
+
+      (a)  If the certificate is revoked for a reason included in the
+      scope of the CRL, list the certificate as revoked.
+
+      (b)  If the certificate is valid and was listed on the referenced
+      base CRL or any subsequent CRL with reason code certificateHold,
+      and the reason code certificateHold is included in the scope of
+      the CRL, list the certificate with the reason code removeFromCRL.
+
+      (c)  If the certificate is revoked for a reason outside the scope
+      of the CRL, but the certificate was listed on the referenced base
+      CRL or any subsequent CRL with a reason code included in the scope
+      of this CRL, list the certificate as revoked but omit the reason
+      code.
+
+      (d)  If the certificate is revoked for a reason outside the scope
+      of the CRL and the certificate was neither listed on the
+      referenced base CRL nor any subsequent CRL with a reason code
+      included in the scope of this CRL, do not list the certificate on
+      this CRL.
+
+   The status of a certificate is considered to have changed if it is
+   revoked, placed on hold, released from hold, or if its revocation
+   reason changes.
+
+   It is appropriate to list a certificate with reason code
+   removeFromCRL on a delta CRL even if the certificate was not on hold
+   in the referenced base CRL.  If the certificate was placed on hold in
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 57]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   any CRL issued after the base but before this delta CRL and then
+   released from hold, it MUST be listed on the delta CRL with
+   revocation reason removeFromCRL.
+
+   A CRL issuer MAY optionally list a certificate on a delta CRL with
+   reason code removeFromCRL if the notAfter time specified in the
+   certificate precedes the thisUpdate time specified in the delta CRL
+   and the certificate was listed on the referenced base CRL or in any
+   CRL issued after the base but before this delta CRL.
+
+   If a certificate revocation notice first appears on a delta CRL, then
+   it is possible for the certificate validity period to expire before
+   the next complete CRL for the same scope is issued.  In this case,
+   the revocation notice MUST be included in all subsequent delta CRLs
+   until the revocation notice is included on at least one explicitly
+   issued complete CRL for this scope.
+
+   An application that supports delta CRLs MUST be able to construct a
+   current complete CRL by combining a previously issued complete CRL
+   and the most current delta CRL.  An application that supports delta
+   CRLs MAY also be able to construct a current complete CRL by
+   combining a previously locally constructed complete CRL and the
+   current delta CRL.  A delta CRL is considered to be the current one
+   if the current time is between the times contained in the thisUpdate
+   and nextUpdate fields.  Under some circumstances, the CRL issuer may
+   publish one or more delta CRLs before indicated by the nextUpdate
+   field.  If more than one current delta CRL for a given scope is
+   encountered, the application SHOULD consider the one with the latest
+   value in thisUpdate to be the most current one.
+
+   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
+
+   BaseCRLNumber ::= CRLNumber
+
+5.2.5  Issuing Distribution Point
+
+   The issuing distribution point is a critical CRL extension that
+   identifies the CRL distribution point and scope for a particular CRL,
+   and it indicates whether the CRL covers revocation for end entity
+   certificates only, CA certificates only, attribute certificates only,
+
+   or a limited set of reason codes.  Although the extension is
+   critical, conforming implementations are not required to support this
+   extension.
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 58]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The CRL is signed using the CRL issuer's private key.  CRL
+   Distribution Points do not have their own key pairs.  If the CRL is
+   stored in the X.500 Directory, it is stored in the Directory entry
+   corresponding to the CRL distribution point, which may be different
+   than the Directory entry of the CRL issuer.
+
+   The reason codes associated with a distribution point MUST be
+   specified in onlySomeReasons.  If onlySomeReasons does not appear,
+   the distribution point MUST contain revocations for all reason codes.
+   CAs may use CRL distribution points to partition the CRL on the basis
+   of compromise and routine revocation.  In this case, the revocations
+   with reason code keyCompromise (1), cACompromise (2), and
+   aACompromise (8) appear in one distribution point, and the
+   revocations with other reason codes appear in another distribution
+   point.
+
+   If the distributionPoint field is present and contains a URI, the
+   following semantics MUST be assumed: the object is a pointer to the
+   most current CRL issued by this CRL issuer.  The URI schemes ftp,
+   http, mailto [RFC1738] and ldap [RFC1778] are defined for this
+   purpose.  The URI MUST be an absolute pathname, not a relative
+   pathname, and MUST specify the host.
+
+   If the distributionPoint field is absent, the CRL MUST contain
+   entries for all revoked unexpired certificates issued by the CRL
+   issuer, if any, within the scope of the CRL.
+
+   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
+   the CRL includes certificates issued by authorities other than the
+   CRL issuer.  The authority responsible for each entry is indicated by
+   the certificate issuer CRL entry extension (section 5.3.4).
+
+   id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
+
+   issuingDistributionPoint ::= SEQUENCE {
+        distributionPoint          [0] DistributionPointName OPTIONAL,
+        onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
+        onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
+        onlySomeReasons            [3] ReasonFlags OPTIONAL,
+        indirectCRL                [4] BOOLEAN DEFAULT FALSE,
+        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
+
+5.2.6  Freshest CRL (a.k.a. Delta CRL Distribution Point)
+
+   The freshest CRL extension identifies how delta CRL information for
+   this complete CRL is obtained.  The extension MUST be non-critical.
+   This extension MUST NOT appear in delta CRLs.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 59]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The same syntax is used for this extension as the
+   cRLDistributionPoints certificate extension, and is described in
+   section 4.2.1.14.  However, only the distribution point field is
+   meaningful in this context.  The reasons and CRLIssuer fields MUST be
+   omitted from this CRL extension.
+
+   Each distribution point name provides the location at which a delta
+   CRL for this complete CRL can be found.  The scope of these delta
+   CRLs MUST be the same as the scope of this complete CRL.  The
+   contents of this CRL extension are only used to locate delta CRLs;
+   the contents are not used to validate the CRL or the referenced delta
+   CRLs.  The encoding conventions defined for distribution points in
+   section 4.2.1.14 apply to this extension.
+
+   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
+
+   FreshestCRL ::= CRLDistributionPoints
+
+5.3  CRL Entry Extensions
+
+   The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for
+   X.509 v2 CRLs provide methods for associating additional attributes
+   with CRL entries [X.509] [X9.55].  The X.509 v2 CRL format also
+   allows communities to define private CRL entry extensions to carry
+   information unique to those communities.  Each extension in a CRL
+   entry may be designated as critical or non-critical.  A CRL
+   validation MUST fail if it encounters a critical CRL entry extension
+   which it does not know how to process.  However, an unrecognized non-
+   critical CRL entry extension may be ignored.  The following
+   subsections present recommended extensions used within Internet CRL
+   entries and standard locations for information.  Communities may
+   elect to use additional CRL entry extensions; however, caution should
+   be exercised in adopting any critical extensions in CRL entries which
+   might be used in a general context.
+
+   All CRL entry extensions used in this specification are non-critical.
+   Support for these extensions is optional for conforming CRL issuers
+   and applications.  However, CRL issuers SHOULD include reason codes
+   (section 5.3.1) and invalidity dates (section 5.3.3) whenever this
+   information is available.
+
+5.3.1  Reason Code
+
+   The reasonCode is a non-critical CRL entry extension that identifies
+   the reason for the certificate revocation.  CRL issuers are strongly
+   encouraged to include meaningful reason codes in CRL entries;
+   however, the reason code CRL entry extension SHOULD be absent instead
+   of using the unspecified (0) reasonCode value.
+
+
+
+Housley, et. al.            Standards Track                    [Page 60]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
+
+   -- reasonCode ::= { CRLReason }
+
+   CRLReason ::= ENUMERATED {
+        unspecified             (0),
+        keyCompromise           (1),
+        cACompromise            (2),
+        affiliationChanged      (3),
+        superseded              (4),
+        cessationOfOperation    (5),
+        certificateHold         (6),
+        removeFromCRL           (8),
+        privilegeWithdrawn      (9),
+        aACompromise           (10) }
+
+5.3.2  Hold Instruction Code
+
+   The hold instruction code is a non-critical CRL entry extension that
+   provides a registered instruction identifier which indicates the
+   action to be taken after encountering a certificate that has been
+   placed on hold.
+
+   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
+
+   holdInstructionCode ::= OBJECT IDENTIFIER
+
+   The following instruction codes have been defined.  Conforming
+   applications that process this extension MUST recognize the following
+   instruction codes.
+
+   holdInstruction    OBJECT IDENTIFIER ::=
+                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }
+
+   id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
+   id-holdinstruction-callissuer
+                             OBJECT IDENTIFIER ::= {holdInstruction 2}
+   id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
+
+   Conforming applications which encounter an id-holdinstruction-
+   callissuer MUST call the certificate issuer or reject the
+   certificate.  Conforming applications which encounter an id-
+   holdinstruction-reject MUST reject the certificate.  The hold
+   instruction id-holdinstruction-none is semantically equivalent to the
+   absence of a holdInstructionCode, and its use is strongly deprecated
+   for the Internet PKI.
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 61]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+5.3.3  Invalidity Date
+
+   The invalidity date is a non-critical CRL entry extension that
+   provides the date on which it is known or suspected that the private
+   key was compromised or that the certificate otherwise became invalid.
+   This date may be earlier than the revocation date in the CRL entry,
+   which is the date at which the CA processed the revocation.  When a
+   revocation is first posted by a CRL issuer in a CRL, the invalidity
+   date may precede the date of issue of earlier CRLs, but the
+   revocation date SHOULD NOT precede the date of issue of earlier CRLs.
+   Whenever this information is available, CRL issuers are strongly
+   encouraged to share it with CRL users.
+
+   The GeneralizedTime values included in this field MUST be expressed
+   in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
+   as defined in section 4.1.2.5.2.
+
+   id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
+
+   invalidityDate ::=  GeneralizedTime
+
+5.3.4  Certificate Issuer
+
+   This CRL entry extension identifies the certificate issuer associated
+   with an entry in an indirect CRL, that is, a CRL that has the
+   indirectCRL indicator set in its issuing distribution point
+   extension.  If this extension is not present on the first entry in an
+   indirect CRL, the certificate issuer defaults to the CRL issuer.  On
+   subsequent entries in an indirect CRL, if this extension is not
+   present, the certificate issuer for the entry is the same as that for
+   the preceding entry.  This field is defined as follows:
+
+   id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }
+
+   certificateIssuer ::=     GeneralNames
+
+   If used by conforming CRL issuers, this extension MUST always be
+   critical.  If an implementation ignored this extension it could not
+   correctly attribute CRL entries to certificates.  This specification
+   RECOMMENDS that implementations recognize this extension.
+
+6  Certification Path Validation
+
+   Certification path validation procedures for the Internet PKI are
+   based on the algorithm supplied in [X.509].  Certification path
+   processing verifies the binding between the subject distinguished
+   name and/or subject alternative name and subject public key.  The
+   binding is limited by constraints which are specified in the
+
+
+
+Housley, et. al.            Standards Track                    [Page 62]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   certificates which comprise the path and inputs which are specified
+   by the relying party.  The basic constraints and policy constraints
+   extensions allow the certification path processing logic to automate
+   the decision making process.
+
+   This section describes an algorithm for validating certification
+   paths.  Conforming implementations of this specification are not
+   required to implement this algorithm, but MUST provide functionality
+   equivalent to the external behavior resulting from this procedure.
+   Any algorithm may be used by a particular implementation so long as
+   it derives the correct result.
+
+   In section 6.1, the text describes basic path validation.  Valid
+   paths begin with certificates issued by a trust anchor.  The
+   algorithm requires the public key of the CA, the CA's name, and any
+   constraints upon the set of paths which may be validated using this
+   key.
+
+   The selection of a trust anchor is a matter of policy: it could be
+   the top CA in a hierarchical PKI; the CA that issued the verifier's
+   own certificate(s); or any other CA in a network PKI.  The path
+   validation procedure is the same regardless of the choice of trust
+   anchor.  In addition, different applications may rely on different
+   trust anchor, or may accept paths that begin with any of a set of
+   trust anchor.
+
+   Section 6.2 describes methods for using the path validation algorithm
+   in specific implementations.  Two specific cases are discussed: the
+   case where paths may begin with one of several trusted CAs; and where
+   compatibility with the PEM architecture is required.
+
+   Section 6.3 describes the steps necessary to determine if a
+   certificate is revoked or on hold status when CRLs are the revocation
+   mechanism used by the certificate issuer.
+
+6.1  Basic Path Validation
+
+   This text describes an algorithm for X.509 path processing.  A
+   conformant implementation MUST include an X.509 path processing
+   procedure that is functionally equivalent to the external behavior of
+   this algorithm.  However, support for some of the certificate
+   extensions processed in this algorithm are OPTIONAL for compliant
+   implementations.  Clients that do not support these extensions MAY
+   omit the corresponding steps in the path validation algorithm.
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 63]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   For example, clients are NOT REQUIRED to support the policy mapping
+   extension.  Clients that do not support this extension MAY omit the
+   path validation steps where policy mappings are processed.  Note that
+   clients MUST reject the certificate if it contains an unsupported
+   critical extension.
+
+   The algorithm presented in this section validates the certificate
+   with respect to the current date and time.  A conformant
+   implementation MAY also support validation with respect to some point
+   in the past.  Note that mechanisms are not available for validating a
+   certificate with respect to a time outside the certificate validity
+   period.
+
+   The trust anchor is an input to the algorithm.  There is no
+   requirement that the same trust anchor be used to validate all
+   certification paths.  Different trust anchors MAY be used to validate
+   different paths, as discussed further in Section 6.2.
+
+   The primary goal of path validation is to verify the binding between
+   a subject distinguished name or a subject alternative name and
+   subject public key, as represented in the end entity certificate,
+   based on the public key of the trust anchor.  This requires obtaining
+   a sequence of certificates that support that binding.  The procedure
+   performed to obtain this sequence of certificates is outside the
+   scope of this specification.
+
+   To meet this goal, the path validation process verifies, among other
+   things, that a prospective certification path (a sequence of n
+   certificates) satisfies the following conditions:
+
+      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
+      the issuer of certificate x+1;
+
+      (b)  certificate 1 is issued by the trust anchor;
+
+      (c)  certificate n is the certificate to be validated; and
+
+      (d)  for all x in {1, ..., n}, the certificate was valid at the
+      time in question.
+
+   When the trust anchor is provided in the form of a self-signed
+   certificate, this self-signed certificate is not included as part of
+   the prospective certification path.  Information about trust anchors
+   are provided as inputs to the certification path validation algorithm
+   (section 6.1.1).
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 64]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   A particular certification path may not, however, be appropriate for
+   all applications.  Therefore, an application MAY augment this
+   algorithm to further limit the set of valid paths.  The path
+   validation process also determines the set of certificate policies
+   that are valid for this path, based on the certificate policies
+   extension, policy mapping extension, policy constraints extension,
+   and inhibit any-policy extension.  To achieve this, the path
+   validation algorithm constructs a valid policy tree.  If the set of
+   certificate policies that are valid for this path is not empty, then
+   the result will be a valid policy tree of depth n, otherwise the
+   result will be a null valid policy tree.
+
+   A certificate is self-issued if the DNs that appear in the subject
+   and issuer fields are identical and are not empty.  In general, the
+   issuer and subject of the certificates that make up a path are
+   different for each certificate.  However, a CA may issue a
+   certificate to itself to support key rollover or changes in
+   certificate policies.  These self-issued certificates are not counted
+   when evaluating path length or name constraints.
+
+   This section presents the algorithm in four basic steps: (1)
+   initialization, (2) basic certificate processing, (3) preparation for
+   the next certificate, and (4) wrap-up.  Steps (1) and (4) are
+   performed exactly once.  Step (2) is performed for all certificates
+   in the path.  Step (3) is performed for all certificates in the path
+   except the final certificate.  Figure 2 provides a high-level
+   flowchart of this algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 65]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+                           +-------+
+                           | START |
+                           +-------+
+                               |
+                               V
+                       +----------------+
+                       | Initialization |
+                       +----------------+
+                               |
+                               +<--------------------+
+                               |                     |
+                               V                     |
+                       +----------------+            |
+                       |  Process Cert  |            |
+                       +----------------+            |
+                               |                     |
+                               V                     |
+                       +================+            |
+                       |  IF Last Cert  |            |
+                       |    in Path     |            |
+                       +================+            |
+                         |            |              |
+                    THEN |            | ELSE         |
+                         V            V              |
+              +----------------+ +----------------+  |
+              |    Wrap up     | |  Prepare for   |  |
+              +----------------+ |   Next Cert    |  |
+                      |          +----------------+  |
+                      V               |              |
+                  +-------+           +--------------+
+                  | STOP  |
+                  +-------+
+
+
+         Figure 2.  Certification Path Processing Flowchart
+
+6.1.1  Inputs
+
+   This algorithm assumes the following seven inputs are provided to the
+   path processing logic:
+
+      (a)  a prospective certification path of length n.
+
+      (b)  the current date/time.
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 66]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (c)  user-initial-policy-set:  A set of certificate policy
+      identifiers naming the policies that are acceptable to the
+      certificate user.  The user-initial-policy-set contains the
+      special value any-policy if the user is not concerned about
+      certificate policy.
+
+      (d)  trust anchor information, describing a CA that serves as a
+      trust anchor for the certification path.  The trust anchor
+      information includes:
+
+         (1)  the trusted issuer name,
+
+         (2)  the trusted public key algorithm,
+
+         (3)  the trusted public key, and
+
+         (4)  optionally, the trusted public key parameters associated
+         with the public key.
+
+      The trust anchor information may be provided to the path
+      processing procedure in the form of a self-signed certificate.
+      The trusted anchor information is trusted because it was delivered
+      to the path processing procedure by some trustworthy out-of-band
+      procedure.  If the trusted public key algorithm requires
+      parameters, then the parameters are provided along with the
+      trusted public key.
+
+      (e) initial-policy-mapping-inhibit, which indicates if policy
+      mapping is allowed in the certification path.
+
+      (f) initial-explicit-policy, which indicates if the path must be
+      valid for at least one of the certificate policies in the user-
+      initial-policy-set.
+
+      (g) initial-any-policy-inhibit, which indicates whether the
+      anyPolicy OID should be processed if it is included in a
+      certificate.
+
+6.1.2  Initialization
+
+   This initialization phase establishes eleven state variables based
+   upon the seven inputs:
+
+      (a)  valid_policy_tree:  A tree of certificate policies with their
+      optional qualifiers; each of the leaves of the tree represents a
+      valid policy at this stage in the certification path validation.
+      If valid policies exist at this stage in the certification path
+      validation, the depth of the tree is equal to the number of
+
+
+
+Housley, et. al.            Standards Track                    [Page 67]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      certificates in the chain that have been processed.  If valid
+      policies do not exist at this stage in the certification path
+      validation, the tree is set to NULL.  Once the tree is set to
+      NULL, policy processing ceases.
+
+      Each node in the valid_policy_tree includes four data objects: the
+      valid policy, a set of associated policy qualifiers, a set of one
+      or more expected policy values, and a criticality indicator.  If
+      the node is at depth x, the components of the node have the
+      following semantics:
+
+         (1)  The valid_policy is a single policy OID representing a
+         valid policy for the path of length x.
+
+         (2)  The qualifier_set is a set of policy qualifiers associated
+         with the valid policy in certificate x.
+
+         (3)  The criticality_indicator indicates whether the
+         certificate policy extension in certificate x was marked as
+         critical.
+
+         (4)  The expected_policy_set contains one or more policy OIDs
+         that would satisfy this policy in the certificate x+1.
+
+      The initial value of the valid_policy_tree is a single node with
+      valid_policy anyPolicy, an empty qualifier_set, an
+      expected_policy_set with the single value anyPolicy, and a
+      criticality_indicator of FALSE.  This node is considered to be at
+      depth zero.
+
+      Figure 3 is a graphic representation of the initial state of the
+      valid_policy_tree.  Additional figures will use this format to
+      describe changes in the valid_policy_tree during path processing.
+
+              +----------------+
+              |   anyPolicy    |   <---- valid_policy
+              +----------------+
+              |       {}       |   <---- qualifier_set
+              +----------------+
+              |     FALSE      |   <---- criticality_indicator
+              +----------------+
+              |  {anyPolicy}   |   <---- expected_policy_set
+              +----------------+
+
+      Figure 3.  Initial value of the valid_policy_tree state variable
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 68]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (b) permitted_subtrees:  A set of root names for each name type
+      (e.g., X.500 distinguished names, email addresses, or ip
+      addresses) defining a set of subtrees within which all subject
+      names in subsequent certificates in the certification path MUST
+      fall.  This variable includes a set for each name type: the
+      initial value for the set for Distinguished Names is the set of
+      all Distinguished names; the initial value for the set of RFC822
+      names is the set of all RFC822 names, etc.
+
+      (c) excluded_subtrees:  A set of root names for each name type
+      (e.g., X.500 distinguished names, email addresses, or ip
+      addresses) defining a set of subtrees within which no subject name
+      in subsequent certificates in the certification path may fall.
+      This variable includes a set for each name type, and the initial
+      value for each set is empty.
+
+      (d) explicit_policy: an integer which indicates if a non-NULL
+      valid_policy_tree is required. The integer indicates the number of
+      non-self-issued certificates to be processed before this
+      requirement is imposed.  Once set, this variable may be decreased,
+      but may not be increased. That is, if a certificate in the path
+      requires a non-NULL valid_policy_tree, a later certificate can not
+      remove this requirement. If initial-explicit-policy is set, then
+      the initial value is 0, otherwise the initial value is n+1.
+
+      (e) inhibit_any-policy: an integer which indicates whether the
+      anyPolicy policy identifier is considered a match. The integer
+      indicates the number of non-self-issued certificates to be
+      processed before the anyPolicy OID, if asserted in a certificate,
+      is ignored. Once set, this variable may be decreased, but may not
+      be increased. That is, if a certificate in the path inhibits
+      processing of anyPolicy, a later certificate can not permit it.
+      If initial-any-policy-inhibit is set, then the initial value is 0,
+      otherwise the initial value is n+1.
+
+      (f) policy_mapping: an integer which indicates if policy mapping
+      is permitted.  The integer indicates the number of non-self-issued
+      certificates to be processed before policy mapping is inhibited.
+      Once set, this variable may be decreased, but may not be
+      increased. That is, if a certificate in the path specifies policy
+      mapping is not permitted, it can not be overridden by a later
+      certificate. If initial-policy-mapping-inhibit is set, then the
+      initial value is 0, otherwise the initial value is n+1.
+
+      (g) working_public_key_algorithm: the digital signature algorithm
+      used to verify the signature of a certificate.  The
+      working_public_key_algorithm is initialized from the trusted
+      public key algorithm provided in the trust anchor information.
+
+
+
+Housley, et. al.            Standards Track                    [Page 69]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (h) working_public_key: the public key used to verify the
+      signature of a certificate.  The working_public_key is initialized
+      from the trusted public key provided in the trust anchor
+      information.
+
+      (i) working_public_key_parameters:  parameters associated with the
+      current public key, that may be required to verify a signature
+      (depending upon the algorithm).  The working_public_key_parameters
+      variable is initialized from the trusted public key parameters
+      provided in the trust anchor information.
+
+      (j) working_issuer_name:  the issuer distinguished name expected
+      in the next certificate in the chain.  The working_issuer_name is
+      initialized to the trusted issuer provided in the trust anchor
+      information.
+
+      (k) max_path_length:  this integer is initialized to n, is
+      decremented for each non-self-issued certificate in the path, and
+      may be reduced to the value in the path length constraint field
+      within the basic constraints extension of a CA certificate.
+
+   Upon completion of the initialization steps, perform the basic
+   certificate processing steps specified in 6.1.3.
+
+6.1.3  Basic Certificate Processing
+
+   The basic path processing actions to be performed for certificate i
+   (for all i in [1..n]) are listed below.
+
+      (a)  Verify the basic certificate information.  The certificate
+      MUST satisfy each of the following:
+
+         (1)  The certificate was signed with the
+         working_public_key_algorithm using the working_public_key and
+         the working_public_key_parameters.
+
+         (2)  The certificate validity period includes the current time.
+
+         (3)  At the current time, the certificate is not revoked and is
+         not on hold status.  This may be determined by obtaining the
+         appropriate CRL (section 6.3), status information, or by out-
+         of-band mechanisms.
+
+         (4)  The certificate issuer name is the working_issuer_name.
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 70]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (b)  If certificate i is self-issued and it is not the final
+      certificate in the path, skip this step for certificate i.
+      Otherwise, verify that the subject name is within one of the
+      permitted_subtrees for X.500 distinguished names, and verify that
+      each of the alternative names in the subjectAltName extension
+      (critical or non-critical) is within one of the permitted_subtrees
+      for that name type.
+
+      (c)  If certificate i is self-issued and it is not the final
+      certificate in the path, skip this step for certificate i.
+      Otherwise, verify that the subject name is not within one of the
+      excluded_subtrees for X.500 distinguished names, and verify that
+      each of the alternative names in the subjectAltName extension
+      (critical or non-critical) is not within one of the
+      excluded_subtrees for that name type.
+
+      (d)  If the certificate policies extension is present in the
+      certificate and the valid_policy_tree is not NULL, process the
+      policy information by performing the following steps in order:
+
+         (1)  For each policy P not equal to anyPolicy in the
+         certificate policies extension, let P-OID denote the OID in
+         policy P and P-Q denote the qualifier set for policy P.
+         Perform the following steps in order:
+
+            (i)  If the valid_policy_tree includes a node of depth i-1
+            where P-OID is in the expected_policy_set, create a child
+            node as follows: set the valid_policy to OID-P; set the
+            qualifier_set to P-Q, and set the expected_policy_set to
+            {P-OID}.
+
+            For example, consider a valid_policy_tree with a node of
+            depth i-1 where the expected_policy_set is {Gold, White}.
+            Assume the certificate policies Gold and Silver appear in
+            the certificate policies extension of certificate i.  The
+            Gold policy is matched but the Silver policy is not.  This
+            rule will generate a child node of depth i for the Gold
+            policy. The result is shown as Figure 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 71]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+                             +-----------------+
+                             |       Red       |
+                             +-----------------+
+                             |       {}        |
+                             +-----------------+   node of depth i-1
+                             |      FALSE      |
+                             +-----------------+
+                             |  {Gold, White}  |
+                             +-----------------+
+                                      |
+                                      |
+                                      |
+                                      V
+                             +-----------------+
+                             |      Gold       |
+                             +-----------------+
+                             |       {}        |
+                             +-----------------+ node of depth i
+                             |  uninitialized  |
+                             +-----------------+
+                             |     {Gold}      |
+                             +-----------------+
+
+                    Figure 4.  Processing an exact match
+
+            (ii)  If there was no match in step (i) and the
+            valid_policy_tree includes a node of depth i-1 with the
+            valid policy anyPolicy, generate a child node with the
+            following values: set the valid_policy to P-OID; set the
+            qualifier_set to P-Q, and set the expected_policy_set to
+            {P-OID}.
+
+            For example, consider a valid_policy_tree with a node of
+            depth i-1 where the valid_policy is anyPolicy.  Assume the
+            certificate policies Gold and Silver appear in the
+            certificate policies extension of certificate i.  The Gold
+            policy does not have a qualifier, but the Silver policy has
+            the qualifier Q-Silver.  If Gold and Silver were not matched
+            in (i) above, this rule will generate two child nodes of
+            depth i, one for each policy.  The result is shown as Figure
+            5.
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 72]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+                             +-----------------+
+                             |    anyPolicy    |
+                             +-----------------+
+                             |       {}        |
+                             +-----------------+ node of depth i-1
+                             |      FALSE      |
+                             +-----------------+
+                             |   {anyPolicy}   |
+                             +-----------------+
+                                /           \
+                               /             \
+                              /               \
+                             /                 \
+               +-----------------+          +-----------------+
+               |      Gold       |          |     Silver      |
+               +-----------------+          +-----------------+
+               |       {}        |          |   {Q-Silver}    |
+               +-----------------+ nodes of +-----------------+
+               | uninitialized   | depth i  | uninitialized   |
+               +-----------------+          +-----------------+
+               |     {Gold}      |          |    {Silver}     |
+               +-----------------+          +-----------------+
+
+               Figure 5.  Processing unmatched policies when a leaf node
+               specifies anyPolicy
+
+         (2)  If the certificate policies extension includes the policy
+         anyPolicy with the qualifier set AP-Q and either (a)
+         inhibit_any-policy is greater than 0 or (b) i<n and the
+         certificate is self-issued, then:
+
+         For each node in the valid_policy_tree of depth i-1, for each
+         value in the expected_policy_set (including anyPolicy) that
+         does not appear in a child node, create a child node with the
+         following values: set the valid_policy to the value from the
+         expected_policy_set in the parent node; set the qualifier_set
+         to AP-Q, and set the expected_policy_set to the value in the
+         valid_policy from this node.
+
+         For example, consider a valid_policy_tree with a node of depth
+         i-1 where the expected_policy_set is {Gold, Silver}.  Assume
+         anyPolicy appears in the certificate policies extension of
+         certificate i, but Gold and Silver do not.  This rule will
+         generate two child nodes of depth i, one for each policy.  The
+         result is shown below as Figure 6.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 73]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+                          +-----------------+
+                          |      Red        |
+                          +-----------------+
+                          |       {}        |
+                          +-----------------+ node of depth i-1
+                          |      FALSE      |
+                          +-----------------+
+                          |  {Gold, Silver} |
+                          +-----------------+
+                             /           \
+                            /             \
+                           /               \
+                          /                 \
+            +-----------------+          +-----------------+
+            |      Gold       |          |     Silver      |
+            +-----------------+          +-----------------+
+            |       {}        |          |       {}        |
+            +-----------------+ nodes of +-----------------+
+            |  uninitialized  | depth i  |  uninitialized  |
+            +-----------------+          +-----------------+
+            |     {Gold}      |          |    {Silver}     |
+            +-----------------+          +-----------------+
+
+         Figure 6.  Processing unmatched policies when the certificate
+         policies extension specifies anyPolicy
+
+         (3)  If there is a node in the valid_policy_tree of depth i-1
+         or less without any child nodes, delete that node.  Repeat this
+         step until there are no nodes of depth i-1 or less without
+         children.
+
+         For example, consider the valid_policy_tree shown in Figure 7
+         below.  The two nodes at depth i-1 that are marked with an 'X'
+         have no children, and are deleted.  Applying this rule to the
+         resulting tree will cause the node at depth i-2 that is marked
+         with an 'Y' to be deleted.  The following application of the
+         rule does not cause any nodes to be deleted, and this step is
+         complete.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 74]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+                              +-----------+
+                              |           | node of depth i-3
+                              +-----------+
+                              /     |     \
+                             /      |      \
+                            /       |       \
+                +-----------+ +-----------+ +-----------+
+                |           | |           | |     Y     | nodes of
+                +-----------+ +-----------+ +-----------+ depth i-2
+                /   \               |             |
+               /     \              |             |
+              /       \             |             |
+   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
+   |           | |     X     | |           | |    X      |  depth
+   +-----------+ +-----------+ +-----------+ +-----------+   i-1
+         |                      /    |    \
+         |                     /     |     \
+         |                    /      |      \
+   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
+   |           | |           | |           | |           |  depth
+   +-----------+ +-----------+ +-----------+ +-----------+   i
+
+          Figure 7.  Pruning the valid_policy_tree
+
+         (4)  If the certificate policies extension was marked as
+         critical, set the criticality_indicator in all nodes of depth i
+         to TRUE.  If the certificate policies extension was not marked
+         critical, set the criticality_indicator in all nodes of depth i
+         to FALSE.
+
+      (e)  If the certificate policies extension is not present, set the
+      valid_policy_tree to NULL.
+
+      (f)  Verify that either explicit_policy is greater than 0 or the
+      valid_policy_tree is not equal to NULL;
+
+   If any of steps (a), (b), (c), or (f) fails, the procedure
+   terminates, returning a failure indication and an appropriate reason.
+
+   If i is not equal to n, continue by performing the preparatory steps
+   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
+   listed in 6.1.5.
+
+6.1.4  Preparation for Certificate i+1
+
+   To prepare for processing of certificate i+1, perform the following
+   steps for certificate i:
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 75]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (a)  If a policy mapping extension is present, verify that the
+      special value anyPolicy does not appear as an issuerDomainPolicy
+      or a subjectDomainPolicy.
+
+      (b)  If a policy mapping extension is present, then for each
+      issuerDomainPolicy ID-P in the policy mapping extension:
+
+         (1)  If the policy_mapping variable is greater than 0, for each
+         node in the valid_policy_tree of depth i where ID-P is the
+         valid_policy, set expected_policy_set to the set of
+         subjectDomainPolicy values that are specified as equivalent to
+         ID-P by the policy mapping extension.
+
+         If no node of depth i in the valid_policy_tree has a
+         valid_policy of ID-P but there is a node of depth i with a
+         valid_policy of anyPolicy, then generate a child node of the
+         node of depth i-1 that has a valid_policy of anyPolicy as
+         follows:
+
+            (i)  set the valid_policy to ID-P;
+
+            (ii)  set the qualifier_set to the qualifier set of the
+            policy anyPolicy in the certificate policies extension of
+            certificate i;
+
+            (iii)  set the criticality_indicator to the criticality of
+            the certificate policies extension of certificate i;
+
+            (iv)  and set the expected_policy_set to the set of
+            subjectDomainPolicy values that are specified as equivalent
+            to ID-P by the policy mappings extension.
+
+         (2)  If the policy_mapping variable is equal to 0:
+
+            (i)  delete each node of depth i in the valid_policy_tree
+            where ID-P is the valid_policy.
+
+            (ii)  If there is a node in the valid_policy_tree of depth
+            i-1 or less without any child nodes, delete that node.
+            Repeat this step until there are no nodes of depth i-1 or
+            less without children.
+
+      (c)  Assign the certificate subject name to working_issuer_name.
+
+      (d)  Assign the certificate subjectPublicKey to
+      working_public_key.
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 76]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (e)  If the subjectPublicKeyInfo field of the certificate contains
+      an algorithm field with non-null parameters, assign the parameters
+      to the working_public_key_parameters variable.
+
+      If the subjectPublicKeyInfo field of the certificate contains an
+      algorithm field with null parameters or parameters are omitted,
+      compare the certificate subjectPublicKey algorithm to the
+      working_public_key_algorithm.  If the certificate subjectPublicKey
+      algorithm and the working_public_key_algorithm are different, set
+      the working_public_key_parameters to null.
+
+      (f)  Assign the certificate subjectPublicKey algorithm to the
+      working_public_key_algorithm variable.
+
+      (g)  If a name constraints extension is included in the
+      certificate, modify the permitted_subtrees and excluded_subtrees
+      state variables as follows:
+
+         (1)  If permittedSubtrees is present in the certificate, set
+         the permitted_subtrees state variable to the intersection of
+         its previous value and the value indicated in the extension
+         field.  If permittedSubtrees does not include a particular name
+         type, the permitted_subtrees state variable is unchanged for
+         that name type.  For example, the intersection of nist.gov and
+         csrc.nist.gov is csrc.nist.gov.  And, the intersection of
+         nist.gov and rsasecurity.com is the empty set.
+
+         (2)  If excludedSubtrees is present in the certificate, set the
+         excluded_subtrees state variable to the union of its previous
+         value and the value indicated in the extension field.  If
+         excludedSubtrees does not include a particular name type, the
+         excluded_subtrees state variable is unchanged for that name
+         type.  For example, the union of the name spaces nist.gov and
+         csrc.nist.gov is nist.gov.  And, the union of nist.gov and
+         rsasecurity.com is both name spaces.
+
+      (h)  If the issuer and subject names are not identical:
+
+         (1)  If explicit_policy is not 0, decrement explicit_policy by
+         1.
+
+         (2)  If policy_mapping is not 0, decrement policy_mapping by 1.
+
+         (3)  If inhibit_any-policy is not 0, decrement inhibit_any-
+         policy by 1.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 77]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (i)  If a policy constraints extension is included in the
+      certificate, modify the explicit_policy and policy_mapping state
+      variables as follows:
+
+         (1)  If requireExplicitPolicy is present and is less than
+         explicit_policy, set explicit_policy to the value of
+         requireExplicitPolicy.
+
+         (2)  If inhibitPolicyMapping is present and is less than
+         policy_mapping, set policy_mapping to the value of
+         inhibitPolicyMapping.
+
+      (j)  If the inhibitAnyPolicy extension is included in the
+      certificate and is less than inhibit_any-policy, set inhibit_any-
+      policy to the value of inhibitAnyPolicy.
+
+      (k)  Verify that the certificate is a CA certificate (as specified
+      in a basicConstraints extension or as verified out-of-band).
+
+      (l)  If the certificate was not self-issued, verify that
+      max_path_length is greater than zero and decrement max_path_length
+      by 1.
+
+      (m)  If pathLengthConstraint is present in the certificate and is
+      less than max_path_length, set max_path_length to the value of
+      pathLengthConstraint.
+
+      (n)  If a key usage extension is present, verify that the
+      keyCertSign bit is set.
+
+      (o)  Recognize and process any other critical extension present in
+      the certificate.  Process any other recognized non-critical
+      extension present in the certificate.
+
+   If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
+   returning a failure indication and an appropriate reason.
+
+   If (a), (k), (l), (n) and (o) have completed successfully, increment
+   i and perform the basic certificate processing specified in 6.1.3.
+
+6.1.5  Wrap-up procedure
+
+   To complete the processing of the end entity certificate, perform the
+   following steps for certificate n:
+
+      (a)  If certificate n was not self-issued and explicit_policy is
+      not 0, decrement explicit_policy by 1.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 78]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (b)  If a policy constraints extension is included in the
+      certificate and requireExplicitPolicy is present and has a value
+      of 0, set the explicit_policy state variable to 0.
+
+      (c)  Assign the certificate subjectPublicKey to
+      working_public_key.
+
+      (d)  If the subjectPublicKeyInfo field of the certificate contains
+      an algorithm field with non-null parameters, assign the parameters
+      to the working_public_key_parameters variable.
+
+      If the subjectPublicKeyInfo field of the certificate contains an
+      algorithm field with null parameters or parameters are omitted,
+      compare the certificate subjectPublicKey algorithm to the
+      working_public_key_algorithm.  If the certificate subjectPublicKey
+      algorithm and the working_public_key_algorithm are different, set
+      the working_public_key_parameters to null.
+
+      (e)  Assign the certificate subjectPublicKey algorithm to the
+      working_public_key_algorithm variable.
+
+      (f)  Recognize and process any other critical extension present in
+      the certificate n.  Process any other recognized non-critical
+      extension present in certificate n.
+
+      (g)  Calculate the intersection of the valid_policy_tree and the
+      user-initial-policy-set, as follows:
+
+         (i)  If the valid_policy_tree is NULL, the intersection is
+         NULL.
+
+         (ii)  If the valid_policy_tree is not NULL and the user-
+         initial-policy-set is any-policy, the intersection is the
+         entire valid_policy_tree.
+
+         (iii)  If the valid_policy_tree is not NULL and the user-
+         initial-policy-set is not any-policy, calculate the
+         intersection of the valid_policy_tree and the user-initial-
+         policy-set as follows:
+
+            1.  Determine the set of policy nodes whose parent nodes
+            have a valid_policy of anyPolicy.  This is the
+            valid_policy_node_set.
+
+            2.  If the valid_policy of any node in the
+            valid_policy_node_set is not in the user-initial-policy-set
+            and is not anyPolicy, delete this node and all its children.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 79]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+            3.  If the valid_policy_tree includes a node of depth n with
+            the valid_policy anyPolicy and the user-initial-policy-set
+            is not any-policy perform the following steps:
+
+               a. Set P-Q to the qualifier_set in the node of depth n
+               with valid_policy anyPolicy.
+
+               b. For each P-OID in the user-initial-policy-set that is
+               not the valid_policy of a node in the
+               valid_policy_node_set, create a child node whose parent
+               is the node of depth n-1 with the valid_policy anyPolicy.
+               Set the values in the child node as follows: set the
+               valid_policy to P-OID; set the qualifier_set to P-Q; copy
+               the criticality_indicator from the node of depth n with
+               the valid_policy anyPolicy; and set the
+               expected_policy_set to {P-OID}.
+
+               c.  Delete the node of depth n with the valid_policy
+               anyPolicy.
+
+            4.  If there is a node in the valid_policy_tree of depth n-1
+            or less without any child nodes, delete that node.  Repeat
+            this step until there are no nodes of depth n-1 or less
+            without children.
+
+   If either (1) the value of explicit_policy variable is greater than
+   zero, or (2) the valid_policy_tree is not NULL, then path processing
+   has succeeded.
+
+6.1.6  Outputs
+
+   If path processing succeeds, the procedure terminates, returning a
+   success indication together with final value of the
+   valid_policy_tree, the working_public_key, the
+   working_public_key_algorithm, and the working_public_key_parameters.
+
+6.2  Using the Path Validation Algorithm
+
+   The path validation algorithm describes the process of validating a
+   single certification path.  While each certification path begins with
+   a specific trust anchor, there is no requirement that all
+   certification paths validated by a particular system share a single
+   trust anchor.  An implementation that supports multiple trust anchors
+   MAY augment the algorithm presented in section 6.1 to further limit
+   the set of valid certification paths which begin with a particular
+   trust anchor.  For example, an implementation MAY modify the
+   algorithm to apply name constraints to a specific trust anchor during
+   the initialization phase, or the application MAY require the presence
+
+
+
+Housley, et. al.            Standards Track                    [Page 80]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   of a particular alternative name form in the end entity certificate,
+   or the application MAY impose requirements on application-specific
+   extensions.  Thus, the path validation algorithm presented in section
+   6.1 defines the minimum conditions for a path to be considered valid.
+
+   The selection of one or more trusted CAs is a local decision.  A
+   system may provide any one of its trusted CAs as the trust anchor for
+   a particular path.  The inputs to the path validation algorithm may
+   be different for each path.  The inputs used to process a path may
+   reflect application-specific requirements or limitations in the trust
+   accorded a particular trust anchor.  For example, a trusted CA may
+   only be trusted for a particular certificate policy.  This
+   restriction can be expressed through the inputs to the path
+   validation procedure.
+
+   It is also possible to specify an extended version of the above
+   certification path processing procedure which results in default
+   behavior identical to the rules of PEM [RFC 1422].  In this extended
+   version, additional inputs to the procedure are a list of one or more
+   Policy Certification Authority (PCA) names and an indicator of the
+   position in the certification path where the PCA is expected.  At the
+   nominated PCA position, the CA name is compared against this list.
+   If a recognized PCA name is found, then a constraint of
+   SubordinateToCA is implicitly assumed for the remainder of the
+   certification path and processing continues.  If no valid PCA name is
+   found, and if the certification path cannot be validated on the basis
+   of identified policies, then the certification path is considered
+   invalid.
+
+6.3  CRL Validation
+
+   This section describes the steps necessary to determine if a
+   certificate is revoked or on hold status when CRLs are the revocation
+   mechanism used by the certificate issuer.  Conforming implementations
+   that support CRLs are not required to implement this algorithm, but
+   they MUST be functionally equivalent to the external behavior
+   resulting from this procedure.  Any algorithm may be used by a
+   particular implementation so long as it derives the correct result.
+
+   This algorithm assumes that all of the needed CRLs are available in a
+   local cache.  Further, if the next update time of a CRL has passed,
+   the algorithm assumes a mechanism to fetch a current CRL and place it
+   in the local CRL cache.
+
+   This algorithm defines a set of inputs, a set of state variables, and
+   processing steps that are performed for each certificate in the path.
+   The algorithm output is the revocation status of the certificate.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 81]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+6.3.1  Revocation Inputs
+
+   To support revocation processing, the algorithm requires two inputs:
+
+      (a)  certificate:  The algorithm requires the certificate serial
+      number and issuer name to determine whether a certificate is on a
+      particular CRL.  The basicConstraints extension is used to
+      determine whether the supplied certificate is associated with a CA
+      or an end entity.  If present, the algorithm uses the
+      cRLDistributionsPoint and freshestCRL extensions to determine
+      revocation status.
+
+      (b)  use-deltas:  This boolean input determines whether delta CRLs
+      are applied to CRLs.
+
+      Note that implementations supporting legacy PKIs, such as RFC 1422
+      and X.509 version 1, will need an additional input indicating
+      whether the supplied certificate is associated with a CA or an end
+      entity.
+
+6.3.2  Initialization and Revocation State Variables
+
+   To support CRL processing, the algorithm requires the following state
+   variables:
+
+      (a)  reasons_mask:  This variable contains the set of revocation
+      reasons supported by the CRLs and delta CRLs processed so far.
+      The legal members of the set are the possible revocation reason
+      values: unspecified, keyCompromise, caCompromise,
+      affiliationChanged, superseded, cessationOfOperation,
+      certificateHold, privilegeWithdrawn, and aACompromise.  The
+      special value all-reasons is used to denote the set of all legal
+      members.  This variable is initialized to the empty set.
+
+      (b)  cert_status:  This variable contains the status of the
+      certificate.  This variable may be assigned one of the following
+      values: unspecified, keyCompromise, caCompromise,
+      affiliationChanged, superseded, cessationOfOperation,
+      certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
+      the special value UNREVOKED, or the special value UNDETERMINED.
+      This variable is initialized to the special value UNREVOKED.
+
+      (c)  interim_reasons_mask:  This contains the set of revocation
+      reasons supported by the CRL or delta CRL currently being
+      processed.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 82]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   Note: In some environments, it is not necessary to check all reason
+   codes.  For example, some environments are only concerned with
+   caCompromise and keyCompromise for CA certificates.  This algorithm
+   checks all reason codes.  Additional processing and state variables
+   may be necessary to limit the checking to a subset of the reason
+   codes.
+
+6.3.3  CRL Processing
+
+   This algorithm begins by assuming the certificate is not revoked.
+   The algorithm checks one or more CRLs until either the certificate
+   status is determined to be revoked or sufficient CRLs have been
+   checked to cover all reason codes.
+
+   For each distribution point (DP) in the certificate CRL distribution
+   points extension, for each corresponding CRL in the local CRL cache,
+   while ((reasons_mask is not all-reasons) and (cert_status is
+   UNREVOKED)) perform the following:
+
+      (a)  Update the local CRL cache by obtaining a complete CRL, a
+      delta CRL, or both, as required:
+
+         (1)  If the current time is after the value of the CRL next
+         update field, then do one of the following:
+
+            (i)  If use-deltas is set and either the certificate or the
+            CRL contains the freshest CRL extension, obtain a delta CRL
+            with the a next update value that is after the current time
+            and can be used to update the locally cached CRL as
+            specified in section 5.2.4.
+
+            (ii)  Update the local CRL cache with a current complete
+            CRL, verify that the current time is before the next update
+            value in the new CRL, and continue processing with the new
+            CRL.  If use-deltas is set, then obtain the current delta
+            CRL that can be used to update the new locally cached
+            complete CRL as specified in section 5.2.4.
+
+         (2)  If the current time is before the value of the next update
+         field and use-deltas is set, then obtain the current delta CRL
+         that can be used to update the locally cached complete CRL as
+         specified in section 5.2.4.
+
+      (b)  Verify the issuer and scope of the complete CRL as follows:
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 83]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+         (1)  If the DP includes cRLIssuer, then verify that the issuer
+         field in the complete CRL matches cRLIssuer in the DP and that
+         the complete CRL contains an issuing distribution point
+         extension with the indrectCRL boolean asserted.  Otherwise,
+         verify that the CRL issuer matches the certificate issuer.
+
+         (2)  If the complete CRL includes an issuing distribution point
+         (IDP) CRL extension check the following:
+
+            (i)  If the distribution point name is present in the IDP
+            CRL extension and the distribution field is present in the
+            DP, then verify that one of the names in the IDP matches one
+            of the names in the DP.  If the distribution point name is
+            present in the IDP CRL extension and the distribution field
+            is omitted from the DP, then verify that one of the names in
+            the IDP matches one of the names in the cRLIssuer field of
+            the DP.
+
+            (ii)  If the onlyContainsUserCerts boolean is asserted in
+            the IDP CRL extension, verify that the certificate does not
+            include the basic constraints extension with the cA boolean
+            asserted.
+
+            (iii)  If the onlyContainsCACerts boolean is asserted in the
+            IDP CRL extension, verify that the certificate includes the
+            basic constraints extension with the cA boolean asserted.
+
+            (iv)  Verify that the onlyContainsAttributeCerts boolean is
+            not asserted.
+
+      (c)  If use-deltas is set, verify the issuer and scope of the
+      delta CRL as follows:
+
+         (1)  Verify that the delta CRL issuer matches complete CRL
+         issuer.
+
+         (2)  If the complete CRL includes an issuing distribution point
+         (IDP) CRL extension, verify that the delta CRL contains a
+         matching IDP CRL extension.  If the complete CRL omits an IDP
+         CRL extension, verify that the delta CRL also omits an IDP CRL
+         extension.
+
+         (3)  Verify that the delta CRL authority key identifier
+         extension matches complete CRL authority key identifier
+         extension.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 84]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   (d)  Compute the interim_reasons_mask for this CRL as follows:
+
+         (1)  If the issuing distribution point (IDP) CRL extension is
+         present and includes onlySomeReasons and the DP includes
+         reasons, then set interim_reasons_mask to the intersection of
+         reasons in the DP and onlySomeReasons in IDP CRL extension.
+
+         (2)  If the IDP CRL extension includes onlySomeReasons but the
+         DP omits reasons, then set interim_reasons_mask to the value of
+         onlySomeReasons in IDP CRL extension.
+
+         (3)  If the IDP CRL extension is not present or omits
+         onlySomeReasons but the DP includes reasons, then set
+         interim_reasons_mask to the value of DP reasons.
+
+         (4)  If the IDP CRL extension is not present or omits
+         onlySomeReasons and the DP omits reasons, then set
+         interim_reasons_mask to the special value all-reasons.
+
+   (e)  Verify that interim_reasons_mask includes one or more reasons
+   that is not included in the reasons_mask.
+
+   (f)  Obtain and validate the certification path for the complete CRL
+   issuer.  If a key usage extension is present in the CRL issuer's
+   certificate, verify that the cRLSign bit is set.
+
+   (g)  Validate the signature on the complete CRL using the public key
+   validated in step (f).
+
+   (h)  If use-deltas is set, then validate the signature on the delta
+   CRL using the public key validated in step (f).
+
+   (i)  If use-deltas is set, then search for the certificate on the
+   delta CRL.  If an entry is found that matches the certificate issuer
+   and serial number as described in section 5.3.4, then set the
+   cert_status variable to the indicated reason as follows:
+
+         (1)  If the reason code CRL entry extension is present, set the
+         cert_status variable to the value of the reason code CRL entry
+         extension.
+
+         (2)  If the reason code CRL entry extension is not present, set
+         the cert_status variable to the value unspecified.
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 85]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (j)  If (cert_status is UNREVOKED), then search for the
+      certificate on the complete CRL.  If an entry is found that
+      matches the certificate issuer and serial number as described in
+      section 5.3.4, then set the cert_status variable to the indicated
+      reason as described in step (i).
+
+      (k)  If (cert_status is removeFromCRL), then set cert_status to
+      UNREVOKED.
+
+   If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
+   then the revocation status has been determined, so return
+   cert_status.
+
+   If the revocation status has not been determined, repeat the process
+   above with any available CRLs not specified in a distribution point
+   but issued by the certificate issuer.  For the processing of such a
+   CRL, assume a DP with both the reasons and the cRLIssuer fields
+   omitted and a distribution point name of the certificate issuer.
+   That is, the sequence of names in fullName is generated from the
+   certificate issuer field as well as the certificate issuerAltName
+   extension.  If the revocation status remains undetermined, then
+   return the cert_status UNDETERMINED.
+
+7  References
+
+   [ISO 10646] ISO/IEC 10646-1:1993.  International Standard --
+               Information technology -- Universal Multiple-Octet Coded
+               Character Set (UCS) -- Part 1: Architecture and Basic
+               Multilingual Plane.
+
+   [RFC 791]   Postel, J.,  "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC 822]   Crocker, D., "Standard for the format of ARPA Internet
+               text messages", STD 11, RFC 822, August 1982.
+
+   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1422]  Kent, S., "Privacy Enhancement for Internet Electronic
+               Mail: Part II: Certificate-Based Key Management," RFC
+               1422, February 1993.
+
+   [RFC 1423]  Balenson, D., "Privacy Enhancement for Internet
+               Electronic Mail: Part III: Algorithms, Modes, and
+               Identifiers," RFC 1423, February 1993.
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 86]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   [RFC 1510]  Kohl, J. and C. Neuman, "The Kerberos Network
+               Authentication Service (V5)," RFC 1510, September 1993.
+
+   [RFC 1519]  Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless
+               Inter-Domain Routing (CIDR): An Address Assignment and
+               Aggregation Strategy", RFC 1519, September 1993.
+
+   [RFC 1738]  Berners-Lee, T., L. Masinter and M. McCahill, "Uniform
+               Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC 1778]  Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
+               Representation of Standard Attribute Syntaxes," RFC 1778,
+               March 1995.
+
+   [RFC 1883]  Deering, S. and R. Hinden.  "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 1883, December 1995.
+
+   [RFC 2044]  F. Yergeau, F., "UTF-8, a transformation format of
+               Unicode and ISO 10646", RFC 2044, October 1996.
+
+   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2247]  Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
+               Sataluri, "Using Domains in LDAP/X.500 Distinguished
+               Names", RFC 2247, January 1998.
+
+   [RFC 2252]  Wahl, M., A. Coulbeck, T. Howes and S. Kille,
+               "Lightweight Directory Access Protocol (v3):  Attribute
+               Syntax Definitions", RFC 2252, December 1997.
+
+   [RFC 2277]  Alvestrand, H., "IETF Policy on Character Sets and
+               Languages", BCP 18, RFC 2277, January 1998.
+
+   [RFC 2279]  Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+   [RFC 2459]  Housley, R., W. Ford, W. Polk and D. Solo, "Internet
+               X.509 Public Key Infrastructure: Certificate and CRL
+               Profile", RFC 2459, January 1999.
+
+   [RFC 2560]  Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
+               Adams, "Online Certificate Status Protocal - OCSP", June
+               1999.
+
+   [SDN.701]   SDN.701, "Message Security Protocol 4.0", Revision A,
+               1997-02-06.
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 87]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   [X.501]     ITU-T Recommendation X.501: Information Technology - Open
+               Systems Interconnection - The Directory: Models, 1993.
+
+   [X.509]     ITU-T Recommendation X.509 (1997 E): Information
+               Technology - Open Systems Interconnection - The
+               Directory: Authentication Framework, June 1997.
+
+   [X.520]     ITU-T Recommendation X.520: Information Technology - Open
+               Systems Interconnection - The Directory: Selected
+               Attribute Types, 1993.
+
+   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
+               encoding rules: Specification of Basic Encoding Rules
+               (BER), Canonical Encoding Rules (CER) and Distinguished
+               Encoding Rules (DER), 1997.
+
+   [X.690]     ITU-T Recommendation X.690 Information Technology - Open
+               Systems Interconnection - Procedures for the operation of
+               OSI Registration Authorities: General procedures, 1992.
+
+   [X9.55]     ANSI X9.55-1995, Public Key Cryptography For The
+               Financial Services Industry: Extensions To Public Key
+               Certificates And Certificate Revocation Lists, 8
+               December, 1995.
+
+   [PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
+               Identifiers for the Internet X.509 Public Key
+               Infrastructure Certificate and Certificate Revocation
+               Lists (CRL) Profile", RFC 3279, April 2002.
+
+   [PKIXTSA]   Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
+               "Internet X.509 Public Key Infrastructure Time-Stamp
+               Protocol (TSP)", RFC 3161, August 2001.
+
+8  Intellectual Property Rights
+
+   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 (see http://www.ietf.org/ipr.html).
+
+   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
+
+
+
+Housley, et. al.            Standards Track                    [Page 88]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+9  Security Considerations
+
+   The majority of this specification is devoted to the format and
+   content of certificates and CRLs.  Since certificates and CRLs are
+   digitally signed, no additional integrity service is necessary.
+   Neither certificates nor CRLs need be kept secret, and unrestricted
+   and anonymous access to certificates and CRLs has no security
+   implications.
+
+   However, security factors outside the scope of this specification
+   will affect the assurance provided to certificate users.  This
+   section highlights critical issues to be considered by implementers,
+   administrators, and users.
+
+   The procedures performed by CAs and RAs to validate the binding of
+   the subject's identity to their public key greatly affect the
+   assurance that ought to be placed in the certificate.  Relying
+   parties might wish to review the CA's certificate practice statement.
+   This is particularly important when issuing certificates to other
+   CAs.
+
+   The use of a single key pair for both signature and other purposes is
+   strongly discouraged.  Use of separate key pairs for signature and
+   key management provides several benefits to the users.  The
+   ramifications associated with loss or disclosure of a signature key
+   are different from loss or disclosure of a key management key.  Using
+   separate key pairs permits a balanced and flexible response.
+   Similarly, different validity periods or key lengths for each key
+   pair may be appropriate in some application environments.
+   Unfortunately, some legacy applications (e.g., SSL) use a single key
+   pair for signature and key management.
+
+   The protection afforded private keys is a critical security factor.
+   On a small scale, failure of users to protect their private keys will
+   permit an attacker to masquerade as them, or decrypt their personal
+   information.  On a larger scale, compromise of a CA's private signing
+   key may have a catastrophic effect.  If an attacker obtains the
+   private key unnoticed, the attacker may issue bogus certificates and
+   CRLs.  Existence of bogus certificates and CRLs will undermine
+   confidence in the system.  If such a compromise is detected, all
+   certificates issued to the compromised CA MUST be revoked, preventing
+
+
+
+Housley, et. al.            Standards Track                    [Page 89]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   services between its users and users of other CAs.  Rebuilding after
+   such a compromise will be problematic, so CAs are advised to
+   implement a combination of strong technical measures (e.g., tamper-
+   resistant cryptographic modules) and appropriate management
+   procedures (e.g., separation of duties) to avoid such an incident.
+
+   Loss of a CA's private signing key may also be problematic.  The CA
+   would not be able to produce CRLs or perform normal key rollover.
+   CAs SHOULD maintain secure backup for signing keys.  The security of
+   the key backup procedures is a critical factor in avoiding key
+   compromise.
+
+   The availability and freshness of revocation information affects the
+   degree of assurance that ought to be placed in a certificate.  While
+   certificates expire naturally, events may occur during its natural
+   lifetime which negate the binding between the subject and public key.
+   If revocation information is untimely or unavailable, the assurance
+   associated with the binding is clearly reduced.  Relying parties
+   might not be able to process every critical extension that can appear
+   in a CRL.  CAs SHOULD take extra care when making revocation
+   information available only through CRLs that contain critical
+   extensions, particularly if support for those extensions is not
+   mandated by this profile.  For example, if revocation information is
+   supplied using a combination of delta CRLs and full CRLs, and the
+   delta CRLs are issued more frequently than the full CRLs, then
+   relying parties that cannot handle the critical extensions related to
+   delta CRL processing will not be able to obtain the most recent
+   revocation information.  Alternatively, if a full CRL is issued
+   whenever a delta CRL is issued, then timely revocation information
+   will be available to all relying parties.  Similarly, implementations
+   of the certification path validation mechanism described in section 6
+   that omit revocation checking provide less assurance than those that
+   support it.
+
+   The certification path validation algorithm depends on the certain
+   knowledge of the public keys (and other information) about one or
+   more trusted CAs.  The decision to trust a CA is an important
+   decision as it ultimately determines the trust afforded a
+   certificate.  The authenticated distribution of trusted CA public
+   keys (usually in the form of a "self-signed" certificate) is a
+   security critical out-of-band process that is beyond the scope of
+   this specification.
+
+   In addition, where a key compromise or CA failure occurs for a
+   trusted CA, the user will need to modify the information provided to
+   the path validation routine.  Selection of too many trusted CAs makes
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 90]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   the trusted CA information difficult to maintain.  On the other hand,
+   selection of only one trusted CA could limit users to a closed
+   community of users.
+
+   The quality of implementations that process certificates also affects
+   the degree of assurance provided.  The path validation algorithm
+   described in section 6 relies upon the integrity of the trusted CA
+   information, and especially the integrity of the public keys
+   associated with the trusted CAs.  By substituting public keys for
+   which an attacker has the private key, an attacker could trick the
+   user into accepting false certificates.
+
+   The binding between a key and certificate subject cannot be stronger
+   than the cryptographic module implementation and algorithms used to
+   generate the signature.  Short key lengths or weak hash algorithms
+   will limit the utility of a certificate.  CAs are encouraged to note
+   advances in cryptology so they can employ strong cryptographic
+   techniques.  In addition, CAs SHOULD decline to issue certificates to
+   CAs or end entities that generate weak signatures.
+
+   Inconsistent application of name comparison rules can result in
+   acceptance of invalid X.509 certification paths, or rejection of
+   valid ones.  The X.500 series of specifications defines rules for
+   comparing distinguished names that require comparison of strings
+   without regard to case, character set, multi-character white space
+   substring, or leading and trailing white space.  This specification
+   relaxes these requirements, requiring support for binary comparison
+   at a minimum.
+
+   CAs MUST encode the distinguished name in the subject field of a CA
+   certificate identically to the distinguished name in the issuer field
+   in certificates issued by that CA.  If CAs use different encodings,
+   implementations might fail to recognize name chains for paths that
+   include this certificate.  As a consequence, valid paths could be
+   rejected.
+
+   In addition, name constraints for distinguished names MUST be stated
+   identically to the encoding used in the subject field or
+   subjectAltName extension.  If not, then name constraints stated as
+   excludedSubTrees will not match and invalid paths will be accepted
+   and name constraints expressed as permittedSubtrees will not match
+   and valid paths will be rejected.  To avoid acceptance of invalid
+   paths, CAs SHOULD state name constraints for distinguished names as
+   permittedSubtrees wherever possible.
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 91]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+Appendix A.  Psuedo-ASN.1 Structures and OIDs
+
+   This section describes data objects used by conforming PKI components
+   in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
+   1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
+   UNIVERSAL Types UniversalString, BMPString and UTF8String.
+
+   The ASN.1 syntax does not permit the inclusion of type statements in
+   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
+   the new UNIVERSAL types in modules using the 1988 syntax.  As a
+   result, this module does not conform to either version of the ASN.1
+   standard.
+
+   This appendix may be converted into 1988 ASN.1 by replacing the
+   definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
+
+A.1 Explicitly Tagged Module, 1988 Syntax
+
+PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
+  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
+
+DEFINITIONS EXPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+-- IMPORTS NONE --
+
+-- UNIVERSAL Types defined in 1993 and 1998 ASN.1
+-- and required by this specification
+
+UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
+        -- UniversalString is defined in ASN.1:1993
+
+BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
+      -- BMPString is the subtype of UniversalString and models
+      -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
+
+UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
+      -- The content of this type conforms to RFC 2279.
+
+-- PKIX specific OIDs
+
+id-pkix  OBJECT IDENTIFIER  ::=
+         { iso(1) identified-organization(3) dod(6) internet(1)
+                    security(5) mechanisms(5) pkix(7) }
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 92]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+-- PKIX arcs
+
+id-pe OBJECT IDENTIFIER  ::=  { id-pkix 1 }
+        -- arc for private certificate extensions
+id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
+        -- arc for policy qualifier types
+id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
+        -- arc for extended key purpose OIDS
+id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
+        -- arc for access descriptors
+
+-- policyQualifierIds for Internet policy qualifiers
+
+id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
+      -- OID for CPS qualifier
+id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
+      -- OID for user notice qualifier
+
+-- access descriptor definitions
+
+id-ad-ocsp         OBJECT IDENTIFIER ::= { id-ad 1 }
+id-ad-caIssuers    OBJECT IDENTIFIER ::= { id-ad 2 }
+id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
+id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
+
+-- attribute data types
+
+Attribute       ::=     SEQUENCE {
+      type              AttributeType,
+      values    SET OF AttributeValue }
+            -- at least one value is required
+
+AttributeType           ::=  OBJECT IDENTIFIER
+
+AttributeValue          ::=  ANY
+
+AttributeTypeAndValue           ::=     SEQUENCE {
+        type    AttributeType,
+        value   AttributeValue }
+
+-- suggested naming attributes: Definition of the following
+--   information object set may be augmented to meet local
+--   requirements.  Note that deleting members of the set may
+--   prevent interoperability with conforming implementations.
+-- presented in pairs: the AttributeType followed by the
+--   type definition for the corresponding AttributeValue
+--Arc for standard naming attributes
+id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
+
+
+
+Housley, et. al.            Standards Track                    [Page 93]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+-- Naming attributes of type X520name
+
+id-at-name              AttributeType ::= { id-at 41 }
+id-at-surname           AttributeType ::= { id-at 4 }
+id-at-givenName         AttributeType ::= { id-at 42 }
+id-at-initials          AttributeType ::= { id-at 43 }
+id-at-generationQualifier AttributeType ::= { id-at 44 }
+
+X520name ::= CHOICE {
+      teletexString     TeletexString   (SIZE (1..ub-name)),
+      printableString   PrintableString (SIZE (1..ub-name)),
+      universalString   UniversalString (SIZE (1..ub-name)),
+      utf8String        UTF8String      (SIZE (1..ub-name)),
+      bmpString         BMPString       (SIZE (1..ub-name)) }
+
+-- Naming attributes of type X520CommonName
+
+id-at-commonName        AttributeType ::= { id-at 3 }
+
+X520CommonName ::= CHOICE {
+      teletexString     TeletexString   (SIZE (1..ub-common-name)),
+      printableString   PrintableString (SIZE (1..ub-common-name)),
+      universalString   UniversalString (SIZE (1..ub-common-name)),
+      utf8String        UTF8String      (SIZE (1..ub-common-name)),
+      bmpString         BMPString       (SIZE (1..ub-common-name)) }
+
+-- Naming attributes of type X520LocalityName
+
+id-at-localityName      AttributeType ::= { id-at 7 }
+
+X520LocalityName ::= CHOICE {
+      teletexString     TeletexString   (SIZE (1..ub-locality-name)),
+      printableString   PrintableString (SIZE (1..ub-locality-name)),
+      universalString   UniversalString (SIZE (1..ub-locality-name)),
+      utf8String        UTF8String      (SIZE (1..ub-locality-name)),
+      bmpString         BMPString       (SIZE (1..ub-locality-name)) }
+
+-- Naming attributes of type X520StateOrProvinceName
+
+id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
+
+X520StateOrProvinceName ::= CHOICE {
+      teletexString     TeletexString   (SIZE (1..ub-state-name)),
+      printableString   PrintableString (SIZE (1..ub-state-name)),
+      universalString   UniversalString (SIZE (1..ub-state-name)),
+      utf8String        UTF8String      (SIZE (1..ub-state-name)),
+      bmpString         BMPString       (SIZE(1..ub-state-name)) }
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 94]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+-- Naming attributes of type X520OrganizationName
+
+id-at-organizationName  AttributeType ::= { id-at 10 }
+
+X520OrganizationName ::= CHOICE {
+      teletexString     TeletexString
+                          (SIZE (1..ub-organization-name)),
+      printableString   PrintableString
+                          (SIZE (1..ub-organization-name)),
+      universalString   UniversalString
+                          (SIZE (1..ub-organization-name)),
+      utf8String        UTF8String
+                          (SIZE (1..ub-organization-name)),
+      bmpString         BMPString
+                          (SIZE (1..ub-organization-name))  }
+
+-- Naming attributes of type X520OrganizationalUnitName
+
+id-at-organizationalUnitName AttributeType ::= { id-at 11 }
+
+X520OrganizationalUnitName ::= CHOICE {
+      teletexString     TeletexString
+                          (SIZE (1..ub-organizational-unit-name)),
+      printableString   PrintableString
+                          (SIZE (1..ub-organizational-unit-name)),
+      universalString   UniversalString
+                          (SIZE (1..ub-organizational-unit-name)),
+      utf8String        UTF8String
+                          (SIZE (1..ub-organizational-unit-name)),
+      bmpString         BMPString
+                          (SIZE (1..ub-organizational-unit-name)) }
+
+-- Naming attributes of type X520Title
+
+id-at-title             AttributeType ::= { id-at 12 }
+
+X520Title ::= CHOICE {
+      teletexString     TeletexString   (SIZE (1..ub-title)),
+      printableString   PrintableString (SIZE (1..ub-title)),
+      universalString   UniversalString (SIZE (1..ub-title)),
+      utf8String        UTF8String      (SIZE (1..ub-title)),
+      bmpString         BMPString       (SIZE (1..ub-title)) }
+
+-- Naming attributes of type X520dnQualifier
+
+id-at-dnQualifier       AttributeType ::= { id-at 46 }
+
+X520dnQualifier ::=     PrintableString
+
+
+
+Housley, et. al.            Standards Track                    [Page 95]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+-- Naming attributes of type X520countryName (digraph from IS 3166)
+
+id-at-countryName       AttributeType ::= { id-at 6 }
+
+X520countryName ::=     PrintableString (SIZE (2))
+
+-- Naming attributes of type X520SerialNumber
+
+id-at-serialNumber      AttributeType ::= { id-at 5 }
+
+X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))
+
+-- Naming attributes of type X520Pseudonym
+
+id-at-pseudonym         AttributeType ::= { id-at 65 }
+
+X520Pseudonym ::= CHOICE {
+   teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
+   printableString   PrintableString (SIZE (1..ub-pseudonym)),
+   universalString   UniversalString (SIZE (1..ub-pseudonym)),
+   utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
+   bmpString         BMPString       (SIZE (1..ub-pseudonym)) }
+
+-- Naming attributes of type DomainComponent (from RFC 2247)
+
+id-domainComponent      AttributeType ::=
+                          { 0 9 2342 19200300 100 1 25 }
+
+DomainComponent ::=     IA5String
+
+-- Legacy attributes
+
+pkcs-9 OBJECT IDENTIFIER ::=
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
+
+id-emailAddress          AttributeType ::= { pkcs-9 1 }
+
+EmailAddress ::=         IA5String (SIZE (1..ub-emailaddress-length))
+
+-- naming data types --
+
+Name ::= CHOICE { -- only one possibility for now --
+      rdnSequence  RDNSequence }
+
+RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+DistinguishedName ::=   RDNSequence
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 96]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+RelativeDistinguishedName  ::=
+                    SET SIZE (1 .. MAX) OF AttributeTypeAndValue
+
+-- Directory string type --
+
+DirectoryString ::= CHOICE {
+      teletexString             TeletexString   (SIZE (1..MAX)),
+      printableString           PrintableString (SIZE (1..MAX)),
+      universalString           UniversalString (SIZE (1..MAX)),
+      utf8String              UTF8String      (SIZE (1..MAX)),
+      bmpString               BMPString       (SIZE (1..MAX)) }
+
+-- certificate and CRL specific structures begin here
+
+Certificate  ::=  SEQUENCE  {
+     tbsCertificate       TBSCertificate,
+     signatureAlgorithm   AlgorithmIdentifier,
+     signature            BIT STRING  }
+
+TBSCertificate  ::=  SEQUENCE  {
+     version         [0]  Version DEFAULT v1,
+     serialNumber         CertificateSerialNumber,
+     signature            AlgorithmIdentifier,
+     issuer               Name,
+     validity             Validity,
+     subject              Name,
+     subjectPublicKeyInfo SubjectPublicKeyInfo,
+     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
+                          -- If present, version MUST be v2 or v3
+     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
+                          -- If present, version MUST be v2 or v3
+     extensions      [3]  Extensions OPTIONAL
+                          -- If present, version MUST be v3 --  }
+
+Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
+
+CertificateSerialNumber  ::=  INTEGER
+
+Validity ::= SEQUENCE {
+     notBefore      Time,
+     notAfter       Time  }
+
+Time ::= CHOICE {
+     utcTime        UTCTime,
+     generalTime    GeneralizedTime }
+
+UniqueIdentifier  ::=  BIT STRING
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 97]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+SubjectPublicKeyInfo  ::=  SEQUENCE  {
+     algorithm            AlgorithmIdentifier,
+     subjectPublicKey     BIT STRING  }
+
+Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
+
+Extension  ::=  SEQUENCE  {
+     extnID      OBJECT IDENTIFIER,
+     critical    BOOLEAN DEFAULT FALSE,
+     extnValue   OCTET STRING  }
+
+-- CRL structures
+
+CertificateList  ::=  SEQUENCE  {
+     tbsCertList          TBSCertList,
+     signatureAlgorithm   AlgorithmIdentifier,
+     signature            BIT STRING  }
+
+TBSCertList  ::=  SEQUENCE  {
+     version                 Version OPTIONAL,
+                                  -- if present, MUST be v2
+     signature               AlgorithmIdentifier,
+     issuer                  Name,
+     thisUpdate              Time,
+     nextUpdate              Time OPTIONAL,
+     revokedCertificates     SEQUENCE OF SEQUENCE  {
+          userCertificate         CertificateSerialNumber,
+          revocationDate          Time,
+          crlEntryExtensions      Extensions OPTIONAL
+                                         -- if present, MUST be v2
+                               }  OPTIONAL,
+     crlExtensions           [0] Extensions OPTIONAL }
+                                         -- if present, MUST be v2
+
+-- Version, Time, CertificateSerialNumber, and Extensions were
+-- defined earlier for use in the certificate structure
+
+AlgorithmIdentifier  ::=  SEQUENCE  {
+     algorithm               OBJECT IDENTIFIER,
+     parameters              ANY DEFINED BY algorithm OPTIONAL  }
+                                -- contains a value of the type
+                                -- registered for use with the
+                                -- algorithm object identifier value
+
+-- X.400 address syntax starts here
+
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 98]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+ORAddress ::= SEQUENCE {
+   built-in-standard-attributes BuiltInStandardAttributes,
+   built-in-domain-defined-attributes
+                   BuiltInDomainDefinedAttributes OPTIONAL,
+   -- see also teletex-domain-defined-attributes
+   extension-attributes ExtensionAttributes OPTIONAL }
+
+-- Built-in Standard Attributes
+
+BuiltInStandardAttributes ::= SEQUENCE {
+   country-name                  CountryName OPTIONAL,
+   administration-domain-name    AdministrationDomainName OPTIONAL,
+   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
+     -- see also extended-network-address
+   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
+   private-domain-name       [2] PrivateDomainName OPTIONAL,
+   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
+     -- see also teletex-organization-name
+   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
+                                 OPTIONAL,
+   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
+     -- see also teletex-personal-name
+   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
+                                 OPTIONAL }
+     -- see also teletex-organizational-unit-names
+
+CountryName ::= [APPLICATION 1] CHOICE {
+   x121-dcc-code         NumericString
+                           (SIZE (ub-country-name-numeric-length)),
+   iso-3166-alpha2-code  PrintableString
+                           (SIZE (ub-country-name-alpha-length)) }
+
+AdministrationDomainName ::= [APPLICATION 2] CHOICE {
+   numeric   NumericString   (SIZE (0..ub-domain-name-length)),
+   printable PrintableString (SIZE (0..ub-domain-name-length)) }
+
+NetworkAddress ::= X121Address  -- see also extended-network-address
+
+X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
+
+TerminalIdentifier ::= PrintableString (SIZE
+(1..ub-terminal-id-length))
+
+PrivateDomainName ::= CHOICE {
+   numeric   NumericString   (SIZE (1..ub-domain-name-length)),
+   printable PrintableString (SIZE (1..ub-domain-name-length)) }
+
+
+
+
+
+Housley, et. al.            Standards Track                    [Page 99]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+OrganizationName ::= PrintableString
+                            (SIZE (1..ub-organization-name-length))
+  -- see also teletex-organization-name
+
+NumericUserIdentifier ::= NumericString
+                            (SIZE (1..ub-numeric-user-id-length))
+
+PersonalName ::= SET {
+   surname     [0] IMPLICIT PrintableString
+                    (SIZE (1..ub-surname-length)),
+   given-name  [1] IMPLICIT PrintableString
+                    (SIZE (1..ub-given-name-length)) OPTIONAL,
+   initials    [2] IMPLICIT PrintableString
+                    (SIZE (1..ub-initials-length)) OPTIONAL,
+   generation-qualifier [3] IMPLICIT PrintableString
+                    (SIZE (1..ub-generation-qualifier-length))
+                    OPTIONAL }
+  -- see also teletex-personal-name
+
+OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
+                             OF OrganizationalUnitName
+  -- see also teletex-organizational-unit-names
+
+OrganizationalUnitName ::= PrintableString (SIZE
+                    (1..ub-organizational-unit-name-length))
+
+-- Built-in Domain-defined Attributes
+
+BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
+                    (1..ub-domain-defined-attributes) OF
+                    BuiltInDomainDefinedAttribute
+
+BuiltInDomainDefinedAttribute ::= SEQUENCE {
+   type PrintableString (SIZE
+                   (1..ub-domain-defined-attribute-type-length)),
+   value PrintableString (SIZE
+                   (1..ub-domain-defined-attribute-value-length)) }
+
+-- Extension Attributes
+
+ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
+               ExtensionAttribute
+
+ExtensionAttribute ::=  SEQUENCE {
+   extension-attribute-type [0] IMPLICIT INTEGER
+                   (0..ub-extension-attributes),
+   extension-attribute-value [1]
+                   ANY DEFINED BY extension-attribute-type }
+
+
+
+Housley, et. al.            Standards Track                   [Page 100]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+-- Extension types and attribute values
+
+common-name INTEGER ::= 1
+
+CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
+
+teletex-common-name INTEGER ::= 2
+
+TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
+
+teletex-organization-name INTEGER ::= 3
+
+TeletexOrganizationName ::=
+                TeletexString (SIZE (1..ub-organization-name-length))
+
+teletex-personal-name INTEGER ::= 4
+
+TeletexPersonalName ::= SET {
+   surname     [0] IMPLICIT TeletexString
+                    (SIZE (1..ub-surname-length)),
+   given-name  [1] IMPLICIT TeletexString
+                    (SIZE (1..ub-given-name-length)) OPTIONAL,
+   initials    [2] IMPLICIT TeletexString
+                    (SIZE (1..ub-initials-length)) OPTIONAL,
+   generation-qualifier [3] IMPLICIT TeletexString
+                    (SIZE (1..ub-generation-qualifier-length))
+                    OPTIONAL }
+
+teletex-organizational-unit-names INTEGER ::= 5
+
+TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
+      (1..ub-organizational-units) OF TeletexOrganizationalUnitName
+
+TeletexOrganizationalUnitName ::= TeletexString
+                  (SIZE (1..ub-organizational-unit-name-length))
+
+pds-name INTEGER ::= 7
+
+PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
+
+physical-delivery-country-name INTEGER ::= 8
+
+PhysicalDeliveryCountryName ::= CHOICE {
+   x121-dcc-code NumericString (SIZE
+(ub-country-name-numeric-length)),
+   iso-3166-alpha2-code PrintableString
+                  (SIZE (ub-country-name-alpha-length)) }
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 101]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+postal-code INTEGER ::= 9
+
+PostalCode ::= CHOICE {
+   numeric-code NumericString (SIZE (1..ub-postal-code-length)),
+   printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
+
+physical-delivery-office-name INTEGER ::= 10
+
+PhysicalDeliveryOfficeName ::= PDSParameter
+
+physical-delivery-office-number INTEGER ::= 11
+
+PhysicalDeliveryOfficeNumber ::= PDSParameter
+
+extension-OR-address-components INTEGER ::= 12
+
+ExtensionORAddressComponents ::= PDSParameter
+
+physical-delivery-personal-name INTEGER ::= 13
+
+PhysicalDeliveryPersonalName ::= PDSParameter
+
+physical-delivery-organization-name INTEGER ::= 14
+
+PhysicalDeliveryOrganizationName ::= PDSParameter
+
+extension-physical-delivery-address-components INTEGER ::= 15
+
+ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
+
+unformatted-postal-address INTEGER ::= 16
+
+UnformattedPostalAddress ::= SET {
+   printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
+         OF PrintableString (SIZE (1..ub-pds-parameter-length))
+         OPTIONAL,
+   teletex-string TeletexString
+         (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
+
+street-address INTEGER ::= 17
+
+StreetAddress ::= PDSParameter
+
+post-office-box-address INTEGER ::= 18
+
+PostOfficeBoxAddress ::= PDSParameter
+
+poste-restante-address INTEGER ::= 19
+
+
+
+Housley, et. al.            Standards Track                   [Page 102]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+PosteRestanteAddress ::= PDSParameter
+
+unique-postal-name INTEGER ::= 20
+
+UniquePostalName ::= PDSParameter
+
+local-postal-attributes INTEGER ::= 21
+
+LocalPostalAttributes ::= PDSParameter
+
+PDSParameter ::= SET {
+   printable-string PrintableString
+                (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
+   teletex-string TeletexString
+                (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
+
+extended-network-address INTEGER ::= 22
+
+ExtendedNetworkAddress ::= CHOICE {
+   e163-4-address SEQUENCE {
+      number      [0] IMPLICIT NumericString
+                       (SIZE (1..ub-e163-4-number-length)),
+      sub-address [1] IMPLICIT NumericString
+                       (SIZE (1..ub-e163-4-sub-address-length))
+                       OPTIONAL },
+   psap-address [0] IMPLICIT PresentationAddress }
+
+PresentationAddress ::= SEQUENCE {
+    pSelector     [0] EXPLICIT OCTET STRING OPTIONAL,
+    sSelector     [1] EXPLICIT OCTET STRING OPTIONAL,
+    tSelector     [2] EXPLICIT OCTET STRING OPTIONAL,
+    nAddresses    [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
+
+terminal-type  INTEGER ::= 23
+
+TerminalType ::= INTEGER {
+   telex (3),
+   teletex (4),
+   g3-facsimile (5),
+   g4-facsimile (6),
+   ia5-terminal (7),
+   videotex (8) } (0..ub-integer-options)
+
+-- Extension Domain-defined Attributes
+
+teletex-domain-defined-attributes INTEGER ::= 6
+
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 103]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
+   (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
+
+TeletexDomainDefinedAttribute ::= SEQUENCE {
+        type TeletexString
+               (SIZE (1..ub-domain-defined-attribute-type-length)),
+        value TeletexString
+               (SIZE (1..ub-domain-defined-attribute-value-length)) }
+
+--  specifications of Upper Bounds MUST be regarded as mandatory
+--  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
+--  Upper Bounds
+
+-- Upper Bounds
+ub-name INTEGER ::= 32768
+ub-common-name INTEGER ::= 64
+ub-locality-name INTEGER ::= 128
+ub-state-name INTEGER ::= 128
+ub-organization-name INTEGER ::= 64
+ub-organizational-unit-name INTEGER ::= 64
+ub-title INTEGER ::= 64
+ub-serial-number INTEGER ::= 64
+ub-match INTEGER ::= 128
+ub-emailaddress-length INTEGER ::= 128
+ub-common-name-length INTEGER ::= 64
+ub-country-name-alpha-length INTEGER ::= 2
+ub-country-name-numeric-length INTEGER ::= 3
+ub-domain-defined-attributes INTEGER ::= 4
+ub-domain-defined-attribute-type-length INTEGER ::= 8
+ub-domain-defined-attribute-value-length INTEGER ::= 128
+ub-domain-name-length INTEGER ::= 16
+ub-extension-attributes INTEGER ::= 256
+ub-e163-4-number-length INTEGER ::= 15
+ub-e163-4-sub-address-length INTEGER ::= 40
+ub-generation-qualifier-length INTEGER ::= 3
+ub-given-name-length INTEGER ::= 16
+ub-initials-length INTEGER ::= 5
+ub-integer-options INTEGER ::= 256
+ub-numeric-user-id-length INTEGER ::= 32
+ub-organization-name-length INTEGER ::= 64
+ub-organizational-unit-name-length INTEGER ::= 32
+ub-organizational-units INTEGER ::= 4
+ub-pds-name-length INTEGER ::= 16
+ub-pds-parameter-length INTEGER ::= 30
+ub-pds-physical-address-lines INTEGER ::= 6
+ub-postal-code-length INTEGER ::= 16
+ub-pseudonym INTEGER ::= 128
+ub-surname-length INTEGER ::= 40
+
+
+
+Housley, et. al.            Standards Track                   [Page 104]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+ub-terminal-id-length INTEGER ::= 24
+ub-unformatted-address-length INTEGER ::= 180
+ub-x121-address-length INTEGER ::= 16
+
+-- Note - upper bounds on string types, such as TeletexString, are
+-- measured in characters.  Excepting PrintableString or IA5String, a
+-- significantly greater number of octets will be required to hold
+-- such a value.  As a minimum, 16 octets, or twice the specified
+-- upper bound, whichever is the larger, should be allowed for
+-- TeletexString.  For UTF8String or UniversalString at least four
+-- times the upper bound should be allowed.
+
+END
+
+A.2 Implicitly Tagged Module, 1988 Syntax
+
+PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
+  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+
+BEGIN
+
+-- EXPORTS ALL --
+
+IMPORTS
+      id-pe, id-kp, id-qt-unotice, id-qt-cps,
+      -- delete following line if "new" types are supported --
+      BMPString, UTF8String,  -- end "new" types --
+      ORAddress, Name, RelativeDistinguishedName,
+      CertificateSerialNumber, Attribute, DirectoryString
+      FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+            dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+            id-mod(0) id-pkix1-explicit(18) };
+
+
+-- ISO arc for standard certificate and CRL extensions
+
+id-ce OBJECT IDENTIFIER  ::=  {joint-iso-ccitt(2) ds(5) 29}
+
+-- authority key identifier OID and syntax
+
+id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 105]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+AuthorityKeyIdentifier ::= SEQUENCE {
+    keyIdentifier             [0] KeyIdentifier            OPTIONAL,
+    authorityCertIssuer       [1] GeneralNames             OPTIONAL,
+    authorityCertSerialNumber [2] CertificateSerialNumber  OPTIONAL }
+    -- authorityCertIssuer and authorityCertSerialNumber MUST both
+    -- be present or both be absent
+
+KeyIdentifier ::= OCTET STRING
+
+-- subject key identifier OID and syntax
+
+id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
+
+SubjectKeyIdentifier ::= KeyIdentifier
+
+-- key usage extension OID and syntax
+
+id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
+
+KeyUsage ::= BIT STRING {
+     digitalSignature        (0),
+     nonRepudiation          (1),
+     keyEncipherment         (2),
+     dataEncipherment        (3),
+     keyAgreement            (4),
+     keyCertSign             (5),
+     cRLSign                 (6),
+     encipherOnly            (7),
+     decipherOnly            (8) }
+
+-- private key usage period extension OID and syntax
+
+id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }
+
+PrivateKeyUsagePeriod ::= SEQUENCE {
+     notBefore       [0]     GeneralizedTime OPTIONAL,
+     notAfter        [1]     GeneralizedTime OPTIONAL }
+     -- either notBefore or notAfter MUST be present
+
+-- certificate policies extension OID and syntax
+
+id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
+
+anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
+
+CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
+
+PolicyInformation ::= SEQUENCE {
+
+
+
+Housley, et. al.            Standards Track                   [Page 106]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+     policyIdentifier   CertPolicyId,
+     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
+             PolicyQualifierInfo OPTIONAL }
+
+CertPolicyId ::= OBJECT IDENTIFIER
+
+PolicyQualifierInfo ::= SEQUENCE {
+       policyQualifierId  PolicyQualifierId,
+       qualifier        ANY DEFINED BY policyQualifierId }
+
+-- Implementations that recognize additional policy qualifiers MUST
+-- augment the following definition for PolicyQualifierId
+
+PolicyQualifierId ::=
+    OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
+
+-- CPS pointer qualifier
+
+CPSuri ::= IA5String
+
+-- user notice qualifier
+
+UserNotice ::= SEQUENCE {
+     noticeRef        NoticeReference OPTIONAL,
+     explicitText     DisplayText OPTIONAL}
+
+NoticeReference ::= SEQUENCE {
+     organization     DisplayText,
+     noticeNumbers    SEQUENCE OF INTEGER }
+
+DisplayText ::= CHOICE {
+     ia5String        IA5String      (SIZE (1..200)),
+     visibleString    VisibleString  (SIZE (1..200)),
+     bmpString        BMPString      (SIZE (1..200)),
+     utf8String       UTF8String     (SIZE (1..200)) }
+
+-- policy mapping extension OID and syntax
+
+id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
+
+PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+     issuerDomainPolicy      CertPolicyId,
+     subjectDomainPolicy     CertPolicyId }
+
+-- subject alternative name extension OID and syntax
+
+id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 107]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+SubjectAltName ::= GeneralNames
+
+GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
+
+GeneralName ::= CHOICE {
+     otherName                       [0]     AnotherName,
+     rfc822Name                      [1]     IA5String,
+     dNSName                         [2]     IA5String,
+     x400Address                     [3]     ORAddress,
+     directoryName                   [4]     Name,
+     ediPartyName                    [5]     EDIPartyName,
+     uniformResourceIdentifier       [6]     IA5String,
+     iPAddress                       [7]     OCTET STRING,
+     registeredID                    [8]     OBJECT IDENTIFIER }
+
+-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
+-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
+
+AnotherName ::= SEQUENCE {
+     type-id    OBJECT IDENTIFIER,
+     value      [0] EXPLICIT ANY DEFINED BY type-id }
+
+EDIPartyName ::= SEQUENCE {
+     nameAssigner            [0]     DirectoryString OPTIONAL,
+     partyName               [1]     DirectoryString }
+
+-- issuer alternative name extension OID and syntax
+
+id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
+
+IssuerAltName ::= GeneralNames
+
+id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
+
+SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
+
+-- basic constraints extension OID and syntax
+
+id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
+
+BasicConstraints ::= SEQUENCE {
+     cA                      BOOLEAN DEFAULT FALSE,
+     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
+
+-- name constraints extension OID and syntax
+
+id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 108]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+NameConstraints ::= SEQUENCE {
+     permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
+     excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
+
+GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
+
+GeneralSubtree ::= SEQUENCE {
+     base                    GeneralName,
+     minimum         [0]     BaseDistance DEFAULT 0,
+     maximum         [1]     BaseDistance OPTIONAL }
+
+BaseDistance ::= INTEGER (0..MAX)
+
+-- policy constraints extension OID and syntax
+
+id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
+
+PolicyConstraints ::= SEQUENCE {
+     requireExplicitPolicy           [0] SkipCerts OPTIONAL,
+     inhibitPolicyMapping            [1] SkipCerts OPTIONAL }
+
+SkipCerts ::= INTEGER (0..MAX)
+
+-- CRL distribution points extension OID and syntax
+
+id-ce-cRLDistributionPoints     OBJECT IDENTIFIER  ::=  {id-ce 31}
+
+CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
+
+DistributionPoint ::= SEQUENCE {
+     distributionPoint       [0]     DistributionPointName OPTIONAL,
+     reasons                 [1]     ReasonFlags OPTIONAL,
+     cRLIssuer               [2]     GeneralNames OPTIONAL }
+
+DistributionPointName ::= CHOICE {
+     fullName                [0]     GeneralNames,
+     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
+
+ReasonFlags ::= BIT STRING {
+     unused                  (0),
+     keyCompromise           (1),
+     cACompromise            (2),
+     affiliationChanged      (3),
+     superseded              (4),
+     cessationOfOperation    (5),
+     certificateHold         (6),
+     privilegeWithdrawn      (7),
+     aACompromise            (8) }
+
+
+
+Housley, et. al.            Standards Track                   [Page 109]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+-- extended key usage extension OID and syntax
+
+id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
+
+ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+
+KeyPurposeId ::= OBJECT IDENTIFIER
+
+-- permit unspecified key uses
+
+anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
+
+-- extended key purpose OIDs
+
+id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
+id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
+id-kp-codeSigning            OBJECT IDENTIFIER ::= { id-kp 3 }
+id-kp-emailProtection        OBJECT IDENTIFIER ::= { id-kp 4 }
+id-kp-timeStamping           OBJECT IDENTIFIER ::= { id-kp 8 }
+id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
+
+-- inhibit any policy OID and syntax
+
+id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
+
+InhibitAnyPolicy ::= SkipCerts
+
+-- freshest (delta)CRL extension OID and syntax
+
+id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
+
+FreshestCRL ::= CRLDistributionPoints
+
+-- authority info access
+
+id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
+
+AuthorityInfoAccessSyntax  ::=
+        SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+AccessDescription  ::=  SEQUENCE {
+        accessMethod          OBJECT IDENTIFIER,
+        accessLocation        GeneralName  }
+
+-- subject info access
+
+id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
+
+
+
+Housley, et. al.            Standards Track                   [Page 110]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+SubjectInfoAccessSyntax  ::=
+        SEQUENCE SIZE (1..MAX) OF AccessDescription
+
+-- CRL number extension OID and syntax
+
+id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
+
+CRLNumber ::= INTEGER (0..MAX)
+
+-- issuing distribution point extension OID and syntax
+
+id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
+
+IssuingDistributionPoint ::= SEQUENCE {
+     distributionPoint          [0] DistributionPointName OPTIONAL,
+     onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
+     onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
+     onlySomeReasons            [3] ReasonFlags OPTIONAL,
+     indirectCRL                [4] BOOLEAN DEFAULT FALSE,
+     onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
+
+id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
+
+BaseCRLNumber ::= CRLNumber
+
+-- CRL reasons extension OID and syntax
+
+id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
+
+CRLReason ::= ENUMERATED {
+     unspecified             (0),
+     keyCompromise           (1),
+     cACompromise            (2),
+     affiliationChanged      (3),
+     superseded              (4),
+     cessationOfOperation    (5),
+     certificateHold         (6),
+     removeFromCRL           (8),
+     privilegeWithdrawn      (9),
+     aACompromise           (10) }
+
+-- certificate issuer CRL entry extension OID and syntax
+
+id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
+
+CertificateIssuer ::= GeneralNames
+
+-- hold instruction extension OID and syntax
+
+
+
+Housley, et. al.            Standards Track                   [Page 111]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
+
+HoldInstructionCode ::= OBJECT IDENTIFIER
+
+-- ANSI x9 holdinstructions
+
+-- ANSI x9 arc holdinstruction arc
+
+holdInstruction OBJECT IDENTIFIER ::=
+          {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
+
+-- ANSI X9 holdinstructions referenced by this standard
+
+id-holdinstruction-none OBJECT IDENTIFIER  ::=
+                {holdInstruction 1} -- deprecated
+
+id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
+                {holdInstruction 2}
+
+id-holdinstruction-reject OBJECT IDENTIFIER ::=
+                {holdInstruction 3}
+
+-- invalidity date CRL entry extension OID and syntax
+
+id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
+
+InvalidityDate ::=  GeneralizedTime
+
+END
+
+Appendix B.  ASN.1 Notes
+
+   CAs MUST force the serialNumber to be a non-negative integer, that
+   is, the sign bit in the DER encoding of the INTEGER value MUST be
+   zero - this can be done by adding a leading (leftmost) `00'H octet if
+   necessary.  This removes a potential ambiguity in mapping between a
+   string of octets and an integer value.
+
+   As noted in section 4.1.2.2, serial numbers can be expected to
+   contain long integers.  Certificate users MUST be able to handle
+   serialNumber values up to 20 octets in length.  Conformant CAs MUST
+   NOT use serialNumber values longer than 20 octets.
+
+   As noted in section 5.2.3, CRL numbers can be expected to contain
+   long integers.  CRL validators MUST be able to handle cRLNumber
+   values up to 20 octets in length.  Conformant CRL issuers MUST NOT
+   use cRLNumber values longer than 20 octets.
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 112]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
+   constructs.  A valid ASN.1 sequence will have zero or more entries.
+   The SIZE (1..MAX) construct constrains the sequence to have at least
+   one entry.  MAX indicates the upper bound is unspecified.
+   Implementations are free to choose an upper bound that suits their
+   environment.
+
+   The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
+   as a subtype of INTEGER containing integers greater than or equal to
+   zero.  The upper bound is unspecified.  Implementations are free to
+   select an upper bound that suits their environment.
+
+   The character string type PrintableString supports a very basic Latin
+   character set: the lower case letters 'a' through 'z', upper case
+   letters 'A' through 'Z', the digits '0' through '9', eleven special
+   characters ' = ( ) + , - . / : ? and space.
+
+   Implementers should note that the at sign ('@') and underscore ('_')
+   characters are not supported by the ASN.1 type PrintableString.
+   These characters often appear in internet addresses.  Such addresses
+   MUST be encoded using an ASN.1 type that supports them.  They are
+   usually encoded as IA5String in either the emailAddress attribute
+   within a distinguished name or the rfc822Name field of GeneralName.
+   Conforming implementations MUST NOT encode strings which include
+   either the at sign or underscore character as PrintableString.
+
+   The character string type TeletexString is a superset of
+   PrintableString.  TeletexString supports a fairly standard (ASCII-
+   like) Latin character set, Latin characters with non-spacing accents
+   and Japanese characters.
+
+   Named bit lists are BIT STRINGs where the values have been assigned
+   names.  This specification makes use of named bit lists in the
+   definitions for the key usage, CRL distribution points and freshest
+   CRL certificate extensions, as well as the freshest CRL and issuing
+   distribution point CRL extensions.  When DER encoding a named bit
+   list, trailing zeroes MUST be omitted.  That is, the encoded value
+   ends with the last named bit that is set to one.
+
+   The character string type UniversalString supports any of the
+   characters allowed by ISO 10646-1 [ISO 10646].  ISO 10646-1 is the
+   Universal multiple-octet coded Character Set (UCS).  ISO 10646-1
+   specifies the architecture and the "basic multilingual plane" -- a
+   large standard character set which includes all major world character
+   standards.
+
+
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 113]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   The character string type UTF8String was introduced in the 1997
+   version of ASN.1, and UTF8String was added to the list of choices for
+   DirectoryString in the 2001 version of X.520 [X.520].  UTF8String is
+   a universal type and has been assigned tag number 12.  The content of
+   UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279
+   [RFC 2279].
+
+   In anticipation of these changes, and in conformance with IETF Best
+   Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character
+   Sets and Languages, this document includes UTF8String as a choice in
+   DirectoryString and the CPS qualifier extensions.
+
+   Implementers should note that the DER encoding of the SET OF values
+   requires ordering of the encodings of the values.  In particular,
+   this issue arises with respect to distinguished names.
+
+   Implementers should note that the DER encoding of SET or SEQUENCE
+   components whose value is the DEFAULT omit the component from the
+   encoded certificate or CRL.  For example, a BasicConstraints
+   extension whose cA value is FALSE would omit the cA boolean from the
+   encoded certificate.
+
+   Object Identifiers (OIDs) are used throughout this specification to
+   identify certificate policies, public key and signature algorithms,
+   certificate extensions, etc.  There is no maximum size for OIDs.
+   This specification mandates support for OIDs which have arc elements
+   with values that are less than 2^28, that is, they MUST be between 0
+   and 268,435,455, inclusive.  This allows each arc element to be
+   represented within a single 32 bit word.  Implementations MUST also
+   support OIDs where the length of the dotted decimal (see [RFC 2252],
+   section 4.1) string representation can be up to 100 bytes
+   (inclusive).  Implementations MUST be able to handle OIDs with up to
+   20 elements (inclusive).  CAs SHOULD NOT issue certificates which
+   contain OIDs that exceed these requirements.  Likewise, CRL issuers
+   SHOULD NOT issue CRLs which contain OIDs that exceed these
+   requirements.
+
+   Implementors are warned that the X.500 standards community has
+   developed a series of extensibility rules.  These rules determine
+   when an ASN.1 definition can be changed without assigning a new
+   object identifier (OID).  For example, at least two extension
+   definitions included in RFC 2459 [RFC 2459], the predecessor to this
+   profile document, have different ASN.1 definitions in this
+   specification, but the same OID is used.  If unknown elements appear
+   within an extension, and the extension is not marked critical, those
+   unknown elements ought to be ignored, as follows:
+
+      (a)  ignore all unknown bit name assignments within a bit string;
+
+
+
+Housley, et. al.            Standards Track                   [Page 114]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+      (b)  ignore all unknown named numbers in an ENUMERATED type or
+      INTEGER type that is being used in the enumerated style, provided
+      the number occurs as an optional element of a SET or SEQUENCE; and
+
+      (c)  ignore all unknown elements in SETs, at the end of SEQUENCEs,
+      or in CHOICEs where the CHOICE is itself an optional element of a
+      SET or SEQUENCE.
+
+   If an extension containing unexpected values is marked critical, the
+   implementation MUST reject the certificate or CRL containing the
+   unrecognized extension.
+
+Appendix C.  Examples
+
+   This section contains four examples: three certificates and a CRL.
+   The first two certificates and the CRL comprise a minimal
+   certification path.
+
+   Section C.1 contains an annotated hex dump of a "self-signed"
+   certificate issued by a CA whose distinguished name is
+   cn=us,o=gov,ou=nist.  The certificate contains a DSA public key with
+   parameters, and is signed by the corresponding DSA private key.
+
+   Section C.2 contains an annotated hex dump of an end entity
+   certificate.  The end entity certificate contains a DSA public key,
+   and is signed by the private key corresponding to the "self-signed"
+   certificate in section C.1.
+
+   Section C.3 contains a dump of an end entity certificate which
+   contains an RSA public key and is signed with RSA and MD5.  This
+   certificate is not part of the minimal certification path.
+
+   Section C.4 contains an annotated hex dump of a CRL.  The CRL is
+   issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and
+   the list of revoked certificates includes the end entity certificate
+   presented in C.2.
+
+   The certificates were processed using Peter Gutman's dumpasn1 utility
+   to generate the output.  The source for the dumpasn1 utility is
+   available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>.  The
+   binaries for the certificates and CRLs are available at
+   <http://csrc.nist.gov/pki/pkixtools>.
+
+C.1  Certificate
+
+   This section contains an annotated hex dump of a 699 byte version 3
+   certificate.  The certificate contains the following information:
+   (a)  the serial number is 23 (17 hex);
+
+
+
+Housley, et. al.            Standards Track                   [Page 115]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   (b)  the certificate is signed with DSA and the SHA-1 hash algorithm;
+   (c)  the issuer's distinguished name is OU=NIST; O=gov; C=US
+   (d)  and the subject's distinguished name is OU=NIST; O=gov; C=US
+   (e)  the certificate was issued on June 30, 1997 and will expire on
+   December 31, 1997;
+   (f)  the certificate contains a 1024 bit DSA public key with
+   parameters;
+   (g)  the certificate contains a subject key identifier extension
+   generated using method (1) of section 4.2.1.2; and
+   (h)  the certificate is a CA certificate (as indicated through the
+   basic constraints extension.)
+
+  0 30  699: SEQUENCE {
+  4 30  635:   SEQUENCE {
+  8 A0    3:     [0] {
+ 10 02    1:       INTEGER 2
+          :       }
+ 13 02    1:     INTEGER 17
+ 16 30    9:     SEQUENCE {
+ 18 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+          :       }
+ 27 30   42:     SEQUENCE {
+ 29 31   11:       SET {
+ 31 30    9:         SEQUENCE {
+ 33 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+ 38 13    2:           PrintableString 'US'
+          :           }
+          :         }
+ 42 31   12:       SET {
+ 44 30   10:         SEQUENCE {
+ 46 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 51 13    3:           PrintableString 'gov'
+          :           }
+          :         }
+ 56 31   13:       SET {
+ 58 30   11:         SEQUENCE {
+ 60 06    3:           OBJECT IDENTIFIER
+          :             organizationalUnitName (2 5 4 11)
+ 65 13    4:           PrintableString 'NIST'
+           :           }
+           :         }
+           :       }
+ 71 30   30:     SEQUENCE {
+ 73 17   13:       UTCTime '970630000000Z'
+ 88 17   13:       UTCTime '971231000000Z'
+           :       }
+103 30   42:     SEQUENCE {
+105 31   11:       SET {
+
+
+
+Housley, et. al.            Standards Track                   [Page 116]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+107 30    9:         SEQUENCE {
+109 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+114 13    2:           PrintableString 'US'
+           :           }
+           :         }
+118 31   12:       SET {
+120 30   10:         SEQUENCE {
+122 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+127 13    3:           PrintableString 'gov'
+           :           }
+           :         }
+132 31   13:       SET {
+134 30   11:         SEQUENCE {
+136 06    3:           OBJECT IDENTIFIER
+           :             organizationalUnitName (2 5 4 11)
+141 13    4:           PrintableString 'NIST'
+           :           }
+           :         }
+           :       }
+147 30  440:     SEQUENCE {
+151 30  300:       SEQUENCE {
+155 06    7:         OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
+164 30  287:         SEQUENCE {
+168 02  129:           INTEGER
+           :             00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
+           :             FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
+           :             48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
+           :             22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
+           :             3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
+           :             C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
+           :             35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
+           :             5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
+           :             FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
+           :             63 FE 43
+300 02   21:           INTEGER
+           :             00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
+           :             55 F7 7D 57 74 81 E5
+323 02  129:           INTEGER
+           :             00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
+           :             C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
+           :             81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
+           :             A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
+           :             46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
+           :             5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
+           :             92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
+           :             62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
+           :             F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
+           :             1E 57 18
+
+
+
+Housley, et. al.            Standards Track                   [Page 117]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+           :           }
+           :         }
+455 03  133:       BIT STRING 0 unused bits, encapsulates {
+459 02  129:           INTEGER
+           :             00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
+           :             75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
+           :             03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
+           :             2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
+           :             FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
+           :             28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
+           :             2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
+           :             B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
+           :             68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
+           :             7B C9 55
+           :           }
+           :       }
+591 A3   50:     [3] {
+593 30   48:       SEQUENCE {
+595 30   29:         SEQUENCE {
+597 06    3:           OBJECT IDENTIFIER
+           :             subjectKeyIdentifier (2 5 29 14)
+602 04   22:           OCTET STRING, encapsulates {
+604 04   20:               OCTET STRING
+           :                 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
+           :                 2C 29 49 F4 86 56
+           :               }
+           :           }
+626 30   15:         SEQUENCE {
+628 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
+633 01    1:           BOOLEAN TRUE
+636 04    5:           OCTET STRING, encapsulates {
+638 30    3:               SEQUENCE {
+640 01    1:                 BOOLEAN TRUE
+           :                 }
+           :               }
+           :           }
+           :         }
+           :       }
+           :     }
+643 30    9:   SEQUENCE {
+645 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+           :     }
+654 03   47:   BIT STRING 0 unused bits, encapsulates {
+657 30   44:       SEQUENCE {
+659 02   20:         INTEGER
+           :           43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
+           :           66 4C 83 CF 2D 77
+681 02   20:         INTEGER
+
+
+
+Housley, et. al.            Standards Track                   [Page 118]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+           :           0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
+           :           E1 8D A5 CC 3A D4
+           :         }
+           :       }
+           :   }
+
+C.2  Certificate
+
+   This section contains an annotated hex dump of a 730 byte version 3
+   certificate.  The certificate contains the following information:
+   (a)  the serial number is 18 (12 hex);
+   (b)  the certificate is signed with DSA and the SHA-1 hash algorithm;
+   (c)  the issuer's distinguished name is OU=nist; O=gov; C=US
+   (d)  and the subject's distinguished name is CN=Tim Polk; OU=nist;
+   O=gov; C=US
+   (e)  the certificate was valid from July 30, 1997 through December 1,
+   1997;
+   (f)  the certificate contains a 1024 bit DSA public key;
+   (g)  the certificate is an end entity certificate, as the basic
+   constraints extension is not present;
+   (h)  the certificate contains an authority key identifier extension
+   matching the subject key identifier of the certificate in Appendix
+   C.1; and
+   (i)  the certificate includes one alternative name - an RFC 822
+   address of "wpolk@nist.gov".
+
+     0 30  730: SEQUENCE {
+     4 30  665:   SEQUENCE {
+     8 A0    3:     [0] {
+    10 02    1:       INTEGER 2
+              :       }
+    13 02    1:     INTEGER 18
+    16 30    9:     SEQUENCE {
+    18 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+              :       }
+    27 30   42:     SEQUENCE {
+    29 31   11:       SET {
+    31 30    9:         SEQUENCE {
+    33 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+    38 13    2:           PrintableString 'US'
+              :           }
+              :         }
+    42 31   12:       SET {
+    44 30   10:         SEQUENCE {
+    46 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+    51 13    3:           PrintableString 'gov'
+              :           }
+              :         }
+
+
+
+Housley, et. al.            Standards Track                   [Page 119]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+    56 31   13:       SET {
+    58 30   11:         SEQUENCE {
+    60 06    3:           OBJECT IDENTIFIER
+              :             organizationalUnitName (2 5 4 11)
+    65 13    4:           PrintableString 'NIST'
+              :           }
+              :         }
+              :       }
+    71 30   30:     SEQUENCE {
+    73 17   13:       UTCTime '970730000000Z'
+    88 17   13:       UTCTime '971201000000Z'
+              :       }
+   103 30   61:     SEQUENCE {
+   105 31   11:       SET {
+   107 30    9:         SEQUENCE {
+   109 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+   114 13    2:           PrintableString 'US'
+              :           }
+              :         }
+   118 31   12:       SET {
+   120 30   10:         SEQUENCE {
+   122 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+   127 13    3:           PrintableString 'gov'
+              :           }
+              :         }
+   132 31   13:       SET {
+   134 30   11:         SEQUENCE {
+   136 06    3:           OBJECT IDENTIFIER
+              :             organizationalUnitName (2 5 4 11)
+   141 13    4:           PrintableString 'NIST'
+              :           }
+              :         }
+   147 31   17:       SET {
+   149 30   15:         SEQUENCE {
+   151 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
+   156 13    8:           PrintableString 'Tim Polk'
+              :           }
+              :         }
+              :       }
+   166 30  439:     SEQUENCE {
+   170 30  300:       SEQUENCE {
+   174 06    7:         OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
+   183 30  287:         SEQUENCE {
+   187 02  129:           INTEGER
+              :             00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
+              :             FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
+              :             48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
+              :             22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
+
+
+
+Housley, et. al.            Standards Track                   [Page 120]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+              :             3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
+              :             C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
+              :             35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
+              :             5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
+              :             FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
+              :             63 FE 43
+   319 02   21:           INTEGER
+              :             00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
+              :             55 F7 7D 57 74 81 E5
+   342 02  129:           INTEGER
+              :             00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
+              :             C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
+              :             81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
+              :             A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
+              :             46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
+              :             5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
+              :             92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
+              :             62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
+              :             F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
+              :             1E 57 18
+              :           }
+              :         }
+   474 03  132:       BIT STRING 0 unused bits, encapsulates {
+   478 02  128:           INTEGER
+              :             30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
+              :             A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
+              :             B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
+              :             37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
+              :             9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
+              :             2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
+              :             35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
+              :             1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
+              :             46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
+              :             95 BE
+              :           }
+              :       }
+   609 A3   62:     [3] {
+   611 30   60:       SEQUENCE {
+   613 30   25:         SEQUENCE {
+   615 06    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+   620 04   18:           OCTET STRING, encapsulates {
+   622 30   16:               SEQUENCE {
+   624 81   14:                 [1] 'wpolk@nist.gov'
+              :                 }
+              :               }
+              :           }
+   640 30   31:         SEQUENCE {
+   642 06    3:           OBJECT IDENTIFIER
+
+
+
+Housley, et. al.            Standards Track                   [Page 121]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+              :             authorityKeyIdentifier (2 5 29 35)
+   647 04   24:           OCTET STRING, encapsulates {
+   649 30   22:               SEQUENCE {
+   651 80   20:                 [0]
+              :                   86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
+              :                   41 2C 29 49 F4 86 56
+              :                 }
+              :               }
+              :           }
+              :         }
+              :       }
+              :     }
+   673 30    9:   SEQUENCE {
+   675 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+              :     }
+   684 03   48:   BIT STRING 0 unused bits, encapsulates {
+   687 30   45:       SEQUENCE {
+   689 02   20:         INTEGER
+              :           36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
+              :           22 92 9F F4 F5 87
+   711 02   21:         INTEGER
+              :           00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
+              :           B4 A0 2E FF 22 5A 73
+              :         }
+              :       }
+              :   }
+
+C.3  End Entity Certificate Using RSA
+
+   This section contains an annotated hex dump of a 654 byte version 3
+   certificate.  The certificate contains the following information:
+   (a)  the serial number is 256;
+   (b)  the certificate is signed with RSA and the SHA-1 hash algorithm;
+   (c)  the issuer's distinguished name is OU=NIST; O=gov; C=US
+   (d)  and the subject's distinguished name is CN=Tim Polk; OU=NIST;
+   O=gov; C=US
+   (e)  the certificate was issued on May 21, 1996 at 09:58:26 and
+   expired on May 21, 1997 at 09:58:26;
+   (f)  the certificate contains a 1024 bit RSA public key;
+   (g)  the certificate is an end entity certificate (not a CA
+   certificate);
+   (h)  the certificate includes an alternative subject name of
+   "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an
+   alternative issuer name of "<http://www.nist.gov/>" - both are URLs;
+   (i)  the certificate include an authority key identifier extension
+   and a certificate policies extension specifying the policy OID
+   2.16.840.1.101.3.2.1.48.9; and
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 122]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+   (j)  the certificate includes a critical key usage extension
+   specifying that the public key is intended for verification of
+   digital signatures.
+
+  0 30  654: SEQUENCE {
+  4 30  503:   SEQUENCE {
+  8 A0    3:     [0] {
+ 10 02    1:       INTEGER 2
+           :       }
+ 13 02    2:     INTEGER 256
+ 17 30   13:     SEQUENCE {
+ 19 06    9:       OBJECT IDENTIFIER
+           :         sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 30 05    0:       NULL
+           :       }
+ 32 30   42:     SEQUENCE {
+ 34 31   11:       SET {
+ 36 30    9:         SEQUENCE {
+ 38 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+ 43 13    2:           PrintableString 'US'
+           :           }
+           :         }
+ 47 31   12:       SET {
+ 49 30   10:         SEQUENCE {
+ 51 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 56 13    3:           PrintableString 'gov'
+           :           }
+           :         }
+ 61 31   13:       SET {
+ 63 30   11:         SEQUENCE {
+ 65 06    3:           OBJECT IDENTIFIER
+           :             organizationalUnitName (2 5 4 11)
+ 70 13    4:           PrintableString 'NIST'
+           :           }
+           :         }
+           :       }
+ 76 30   30:     SEQUENCE {
+ 78 17   13:       UTCTime '960521095826Z'
+ 93 17   13:       UTCTime '970521095826Z'
+           :       }
+108 30   61:     SEQUENCE {
+110 31   11:       SET {
+112 30    9:         SEQUENCE {
+114 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+119 13    2:           PrintableString 'US'
+           :           }
+           :         }
+123 31   12:       SET {
+
+
+
+Housley, et. al.            Standards Track                   [Page 123]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+125 30   10:         SEQUENCE {
+127 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+132 13    3:           PrintableString 'gov'
+           :           }
+           :         }
+137 31   13:       SET {
+139 30   11:         SEQUENCE {
+141 06    3:           OBJECT IDENTIFIER
+           :             organizationalUnitName (2 5 4 11)
+146 13    4:           PrintableString 'NIST'
+           :           }
+           :         }
+152 31   17:       SET {
+154 30   15:         SEQUENCE {
+156 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
+161 13    8:           PrintableString 'Tim Polk'
+           :           }
+           :         }
+           :       }
+171 30  159:     SEQUENCE {
+174 30   13:       SEQUENCE {
+176 06    9:         OBJECT IDENTIFIER
+           :           rsaEncryption (1 2 840 113549 1 1 1)
+187 05    0:         NULL
+           :         }
+189 03  141:       BIT STRING 0 unused bits, encapsulates {
+193 30  137:           SEQUENCE {
+196 02  129:             INTEGER
+           :               00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
+           :               4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
+           :               EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
+           :               87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
+           :               7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
+           :               49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
+           :               1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
+           :               7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
+           :               2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
+           :               95 FF 23
+328 02    3:             INTEGER 65537
+           :             }
+           :           }
+           :       }
+333 A3  175:     [3] {
+336 30  172:       SEQUENCE {
+339 30   63:         SEQUENCE {
+341 06    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+346 04   56:           OCTET STRING, encapsulates {
+348 30   54:               SEQUENCE {
+
+
+
+Housley, et. al.            Standards Track                   [Page 124]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+350 86   52:                 [6]
+           :                   'http://www.itl.nist.gov/div893/staff/'
+           :                   'polk/index.html'
+           :                 }
+           :               }
+           :           }
+404 30   31:         SEQUENCE {
+406 06    3:           OBJECT IDENTIFIER issuerAltName (2 5 29 18)
+411 04   24:           OCTET STRING, encapsulates {
+413 30   22:               SEQUENCE {
+415 86   20:                 [6] 'http://www.nist.gov/'
+           :                 }
+           :               }
+           :           }
+437 30   31:         SEQUENCE {
+439 06    3:           OBJECT IDENTIFIER
+           :             authorityKeyIdentifier (2 5 29 35)
+444 04   24:           OCTET STRING, encapsulates {
+446 30   22:               SEQUENCE {
+448 80   20:                 [0]
+           :                   08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
+           :                   70 6A 4A 20 84 2C 32
+           :                 }
+           :               }
+           :           }
+470 30   23:         SEQUENCE {
+472 06    3:           OBJECT IDENTIFIER
+           :             certificatePolicies (2 5 29 32)
+477 04   16:           OCTET STRING, encapsulates {
+479 30   14:               SEQUENCE {
+481 30   12:                 SEQUENCE {
+483 06   10:                   OBJECT IDENTIFIER
+           :                            '2 16 840 1 101 3 2 1 48 9'
+           :                   }
+           :                 }
+           :               }
+           :           }
+495 30   14:         SEQUENCE {
+497 06    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
+502 01    1:           BOOLEAN TRUE
+505 04    4:           OCTET STRING, encapsulates {
+507 03    2:               BIT STRING 7 unused bits
+           :                 '1'B (bit 0)
+           :               }
+           :           }
+           :         }
+           :       }
+           :     }
+
+
+
+Housley, et. al.            Standards Track                   [Page 125]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+511 30   13:   SEQUENCE {
+513 06    9:     OBJECT IDENTIFIER
+           :       sha1withRSAEncryption (1 2 840 113549 1 1 5)
+524 05    0:     NULL
+           :     }
+526 03  129:   BIT STRING 0 unused bits
+           :     1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
+           :     6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
+           :     82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
+           :     F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
+           :     07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
+           :     40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
+           :     E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
+           :     BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
+           :     8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
+           :     77 F3
+           :   }
+
+C.4  Certificate Revocation List
+
+   This section contains an annotated hex dump of a version 2 CRL with
+   one extension (cRLNumber).  The CRL was issued by OU=NIST; O=gov;
+   C=US on August 7, 1997; the next scheduled issuance was September 7,
+   1997.  The CRL includes one revoked certificates: serial number 18
+   (12 hex), which was revoked on July 31, 1997 due to keyCompromise.
+   The CRL itself is number 18, and it was signed with DSA and SHA-1.
+
+  0 30  203: SEQUENCE {
+  3 30  140:   SEQUENCE {
+  6 02    1:     INTEGER 1
+  9 30    9:     SEQUENCE {
+ 11 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+           :       }
+ 20 30   42:     SEQUENCE {
+ 22 31   11:       SET {
+ 24 30    9:         SEQUENCE {
+ 26 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+ 31 13    2:           PrintableString 'US'
+           :           }
+           :         }
+ 35 31   12:       SET {
+ 37 30   10:         SEQUENCE {
+ 39 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 44 13    3:           PrintableString 'gov'
+           :           }
+           :         }
+ 49 31   13:       SET {
+ 51 30   11:         SEQUENCE {
+
+
+
+Housley, et. al.            Standards Track                   [Page 126]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+ 53 06    3:           OBJECT IDENTIFIER
+           :             organizationalUnitName (2 5 4 11)
+ 58 13    4:           PrintableString 'NIST'
+           :           }
+           :         }
+           :       }
+ 64 17   13:     UTCTime '970807000000Z'
+ 79 17   13:     UTCTime '970907000000Z'
+ 94 30   34:     SEQUENCE {
+ 96 30   32:       SEQUENCE {
+ 98 02    1:         INTEGER 18
+101 17   13:         UTCTime '970731000000Z'
+116 30   12:         SEQUENCE {
+118 30   10:           SEQUENCE {
+120 06    3:             OBJECT IDENTIFIER cRLReason (2 5 29 21)
+125 04    3:             OCTET STRING, encapsulates {
+127 0A    1:                 ENUMERATED 1
+           :                 }
+           :             }
+           :           }
+           :         }
+           :       }
+130 A0   14:     [0] {
+132 30   12:       SEQUENCE {
+134 30   10:         SEQUENCE {
+136 06    3:           OBJECT IDENTIFIER cRLNumber (2 5 29 20)
+141 04    3:           OCTET STRING, encapsulates {
+143 02    1:               INTEGER 12
+           :               }
+           :           }
+           :         }
+           :       }
+           :     }
+146 30    9:   SEQUENCE {
+148 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
+           :     }
+157 03   47:   BIT STRING 0 unused bits, encapsulates {
+160 30   44:       SEQUENCE {
+162 02   20:         INTEGER
+           :           22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
+           :           80 05 C0 3A 29 47
+184 02   20:         INTEGER
+           :           59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
+           :           96 16 B1 1F 46 5A
+           :         }
+           :       }
+           :   }
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 127]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+Author Addresses
+
+   Russell Housley
+   RSA Laboratories
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail:  rhousley@rsasecurity.com
+
+   Warwick Ford
+   VeriSign, Inc.
+   401 Edgewater Place
+   Wakefield, MA 01880
+   USA
+
+   EMail:  wford@verisign.com
+
+   Tim Polk
+   NIST
+   Building 820, Room 426
+   Gaithersburg, MD 20899
+   USA
+
+   EMail:  wpolk@nist.gov
+
+   David Solo
+   Citigroup
+   909 Third Ave, 16th Floor
+   New York, NY 10043
+   USA
+
+   EMail:  dsolo@alum.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 128]
+
+RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et. al.            Standards Track                   [Page 129]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3281.txt b/third_party/heimdal/doc/standardisation/rfc3281.txt
new file mode 100644
index 00000000000..91266ee9855
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3281.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Network Working Group                                         S. Farrell
+Request for Comments: 3281                        Baltimore Technologies
+Category: Standards Track                                     R. Housley
+                                                        RSA Laboratories
+                                                              April 2002
+
+
+                   An Internet Attribute Certificate
+                       Profile for Authorization
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This specification defines a profile for the use of X.509 Attribute
+   Certificates in Internet Protocols.  Attribute certificates may be
+   used in a wide range of applications and environments covering a
+   broad spectrum of interoperability goals and a broader spectrum of
+   operational and assurance requirements.  The goal of this document is
+   to establish a common baseline for generic applications requiring
+   broad interoperability as well as limited special purpose
+   requirements.  The profile places emphasis on attribute certificate
+   support for Internet electronic mail, IPSec, and WWW security
+   applications.
+
+Table of Contents
+
+   1. Introduction.................................................  2
+       1.1  Delegation and AC chains...............................  4
+       1.2  Attribute Certificate Distribution ("push" vs. "pull").  4
+       1.3  Document Structure.....................................  6
+   2. Terminology..................................................  6
+   3. Requirements.................................................  7
+   4. Attribute Certificate Profile................................  7
+       4.1  X.509 Attribute Certificate Definition.................  8
+       4.2  Profile of Standard Fields............................. 10
+           4.2.1  Version.......................................... 10
+           4.2.2  Holder........................................... 11
+
+
+
+Farrell & Housley           Standards Track                     [Page 1]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+           4.2.3  Issuer........................................... 12
+           4.2.4  Signature........................................ 12
+           4.2.5  Serial Number.................................... 12
+           4.2.6  Validity Period.................................. 13
+           4.2.7  Attributes....................................... 13
+           4.2.8  Issuer Unique Identifier......................... 14
+           4.2.9  Extensions....................................... 14
+       4.3  Extensions............................................. 14
+           4.3.1  Audit Identity................................... 14
+           4.3.2  AC Targeting..................................... 15
+           4.3.3  Authority Key Identifier......................... 17
+           4.3.4  Authority Information Access..................... 17
+           4.3.5  CRL Distribution Points.......................... 17
+           4.3.6  No Revocation Available.......................... 18
+       4.4  Attribute Types........................................ 18
+           4.4.1  Service Authentication Information............... 19
+           4.4.2  Access Identity.................................. 19
+           4.4.3  Charging Identity................................ 20
+           4.4.4  Group............................................ 20
+           4.4.5  Role............................................. 20
+           4.4.6  Clearance........................................ 21
+       4.5  Profile of AC issuer's PKC............................. 22
+   5. Attribute Certificate Validation............................. 23
+   6. Revocation................................................... 24
+   7. Optional Features............................................ 25
+       7.1  Attribute Encryption................................... 25
+       7.2  Proxying............................................... 27
+       7.3  Use of ObjectDigestInfo................................ 28
+       7.4  AA Controls............................................ 29
+   8. Security Considerations...................................... 30
+   9. IANA Considerations.......................................... 32
+   10. References.................................................. 32
+   Appendix A: Object Identifiers.................................. 34
+   Appendix B: ASN.1 Module........................................ 35
+   Author's Addresses.............................................. 39
+   Acknowledgements................................................ 39
+   Full Copyright Statement........................................ 40
+
+1. Introduction
+
+   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 BCP 14, RFC 2119.
+
+   X.509 public key certificates (PKCs) [X.509-1997, X.509-2000,
+   PKIXPROF] bind an identity and a public key.  An attribute
+   certificate (AC) is a structure similar to a PKC; the main difference
+   being that the AC contains no public key.  An AC may contain
+
+
+
+Farrell & Housley           Standards Track                     [Page 2]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   attributes that specify group membership, role, security clearance,
+   or other authorization information associated with the AC holder.
+   The syntax for the AC is defined in Recommendation X.509, making the
+   term "X.509 certificate" ambiguous.
+
+   Some people constantly confuse PKCs and ACs.  An analogy may make the
+   distinction clear.  A PKC can be considered to be like a passport: it
+   identifies the holder, tends to last for a long time, and should not
+   be trivial to obtain.  An AC is more like an entry visa: it is
+   typically issued by a different authority and does not last for as
+   long a time.  As acquiring an entry visa typically requires
+   presenting a passport, getting a visa can be a simpler process.
+
+   Authorization information may be placed in a PKC extension or placed
+   in a separate attribute certificate (AC).  The placement of
+   authorization information in PKCs is usually undesirable for two
+   reasons.  First, authorization information often does not have the
+   same lifetime as the binding of the identity and the public key.
+   When authorization information is placed in a PKC extension, the
+   general result is the shortening of the PKC useful lifetime.  Second,
+   the PKC issuer is not usually authoritative for the authorization
+   information.  This results in additional steps for the PKC issuer to
+   obtain authorization information from the authoritative source.
+
+   For these reasons, it is often better to separate authorization
+   information from the PKC.  Yet, authorization information also needs
+   to be bound to an identity.  An AC provides this binding; it is
+   simply a digitally signed (or certified) identity and set of
+   attributes.
+
+   An AC may be used with various security services, including access
+   control, data origin authentication, and non-repudiation.
+
+   PKCs can provide an identity to access control decision functions.
+   However, in many contexts the identity is not the criterion that is
+   used for access control decisions, rather the role or group-
+   membership of the accessor is the criterion used.  Such access
+   control schemes are called role-based access control.
+
+   When making an access control decision based on an AC, an access
+   control decision function may need to ensure that the appropriate AC
+   holder is the entity that has requested access.  One way in which the
+   linkage between the request or identity and the AC can be achieved is
+   the inclusion of a reference to a PKC within the AC and the use of
+   the private key corresponding to the PKC for authentication within
+   the access request.
+
+
+
+
+
+Farrell & Housley           Standards Track                     [Page 3]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   ACs may also be used in the context of a data origin authentication
+   service and a non-repudiation service.  In these contexts, the
+   attributes contained in the AC provide additional information about
+   the signing entity.  This information can be used to make sure that
+   the entity is authorized to sign the data.  This kind of checking
+   depends either on the context in which the data is exchanged or on
+   the data that has been digitally signed.
+
+1.1 Delegation and AC chains
+
+   The X.509 standard [X.509-2000] defines authorization as the
+   "conveyance of privilege from one entity that holds such privilege,
+   to another entity".  An AC is one authorization mechanism.
+
+   An ordered sequence of ACs could be used to verify the authenticity
+   of a privilege asserter's privilege.  In this way, chains or paths of
+   ACs could be employed to delegate authorization.
+
+   Since the administration and processing associated with such AC
+   chains is complex and the use of ACs in the Internet today is quite
+   limited, this specification does NOT RECOMMEND the use of AC chains.
+   Other (future) specifications may address the use of AC chains.  This
+   specification deals with the simple cases, where one authority issues
+   all of the ACs for a particular set of attributes.  However, this
+   simplification does not preclude the use of several different
+   authorities, each of which manages a different set of attributes.
+   For example, group membership may be included in one AC issued by one
+   authority, and security clearance may be included in another AC
+   issued by another authority.
+
+   This means that conformant implementations are only REQUIRED to be
+   able to process a single AC at a time.  Processing of more than one
+   AC, one after another, may be necessary.  Note however, that
+   validation of an AC MAY require validation of a chain of PKCs, as
+   specified in [PKIXPROF].
+
+1.2 Attribute Certificate Distribution ("push" vs. "pull")
+
+   As discussed above, ACs provide a mechanism to securely provide
+   authorization information to, for example, access control decision
+   functions.  However, there are a number of possible communication
+   paths for ACs.
+
+   In some environments, it is suitable for a client to "push" an AC to
+   a server.  This means that no new connections between the client and
+   server are required.  It also means that no search burden is imposed
+   on servers, which improves performance and that the AC verifier is
+
+
+
+
+Farrell & Housley           Standards Track                     [Page 4]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   only presented with what it "needs to know."  The "push" model is
+   especially suitable in inter-domain cases where the client's rights
+   should be assigned within the client's "home" domain.
+
+   In other cases, it is more suitable for a client to simply
+   authenticate to the server and for the server to request or "pull"
+   the client's AC from an AC issuer or a repository.  A major benefit
+   of the "pull" model is that it can be implemented without changes to
+   the client or to the client-server protocol.  The "pull" model is
+   especially suitable for inter-domain cases where the client's rights
+   should be assigned within the server's domain, rather than within the
+   client's domain.
+
+   There are a number of possible exchanges involving three entities:
+   the client, the server, and the AC issuer.  In addition, a directory
+   service or other repository for AC retrieval MAY be supported.
+
+   Figure 1 shows an abstract view of the exchanges that may involve
+   ACs.  This profile does not specify a protocol for these exchanges.
+
+      +--------------+
+      |              |        Server Acquisition
+      |  AC issuer   +----------------------------+
+      |              |                            |
+      +--+-----------+                            |
+         |                                        |
+         | Client                                 |
+         | Acquisition                            |
+         |                                        |
+      +--+-----------+                         +--+------------+
+      |              |       AC "push"         |               |
+      |   Client     +-------------------------+    Server     |
+      |              | (part of app. protocol) |               |
+      +--+-----------+                         +--+------------+
+         |                                        |
+         | Client                                 | Server
+         | Lookup        +--------------+         | Lookup
+         |               |              |         |
+         +---------------+  Repository  +---------+
+                         |              |
+                         +--------------+
+
+                     Figure 1: AC Exchanges
+
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                     [Page 5]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+1.3 Document Structure
+
+   Section 2 defines some terminology.  Section 3 specifies the
+   requirements that this profile is intended to meet.  Section 4
+   contains the profile of the X.509 AC.  Section 5 specifies rules for
+   AC validation.  Section 6 specifies rules for AC revocation checks.
+   Section 7 specifies optional features which MAY be supported;
+   however, support for these features is not required for conformance
+   to this profile.  Finally, appendices contain the list of OIDs
+   required to support this specification and an ASN.1 module.
+
+2. Terminology
+
+   For simplicity, we use the terms client and server in this
+   specification.  This is not intended to indicate that ACs are only to
+   be used in client-server environments.  For example, ACs may be used
+   in the S/MIME v3 context, where the mail user agent would be both a
+   "client" and a "server" in the sense the terms are used here.
+
+   Term          Meaning
+
+   AA            Attribute Authority, the entity that issues the
+                 AC, synonymous in this specification with "AC
+                 issuer"
+   AC            Attribute Certificate
+   AC user       any entity that parses or processes an AC
+   AC verifier   any entity that checks the validity of an AC and
+                 then makes use of the result
+   AC issuer     the entity which signs the AC, synonymous in this
+                 specification with "AA"
+   AC holder     the entity indicated (perhaps indirectly) in the
+                 holder field of the AC
+   Client        the entity which is requesting the action for
+                 which authorization checks are to be made
+   Proxying      In this specification, Proxying is used to mean
+                 the situation where an application server acts as
+                 an application client on behalf of a user.
+                 Proxying here does not mean granting of authority.
+   PKC           Public Key Certificate - uses the type ASN.1
+                 Certificate defined in X.509 and profiled in RFC
+                 2459.  This (non-standard) acronym is used in order
+                 to avoid confusion about the term "X.509
+                 certificate".
+   Server        the entity which requires that the authorization
+                 checks are made
+
+
+
+
+
+
+Farrell & Housley           Standards Track                     [Page 6]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+3. Requirements
+
+   This AC profile meets the following requirements.
+
+   Time/Validity requirements:
+
+   1. Support for short-lived as well as long-lived ACs.  Typical
+      short-lived validity periods might be measured in hours, as
+      opposed to months for PKCs.  Short validity periods allow ACs to
+      be useful without a revocation mechanism.
+
+   Attribute Types:
+
+   2. Issuers of ACs should be able to define their own attribute types
+      for use within closed domains.
+
+   3. Some standard attribute types, which can be contained within ACs,
+      should be defined.  Examples include "access identity," "group,"
+      "role," "clearance," "audit identity," and "charging identity."
+
+   4. Standard attribute types should be defined in a manner that
+      permits an AC verifier to distinguish between uses of the same
+      attribute in different domains.  For example, the "Administrators
+      group" as defined by Baltimore and the "Administrators group" as
+      defined by SPYRUS should be easily distinguished.
+
+   Targeting of ACs:
+
+   5. It should be possible to "target" an AC at one, or a small number
+      of, servers.  This means that a trustworthy non-target server will
+      reject the AC for authorization decisions.
+
+   Push vs. Pull
+
+   6. ACs should be defined so that they can either be "pushed" by the
+      client to the server, or "pulled" by the server from a repository
+      or other network service, including an online AC issuer.
+
+4. Attribute Certificate Profile
+
+   ACs may be used in a wide range of applications and environments
+   covering a broad spectrum of interoperability goals and a broader
+   spectrum of operational and assurance requirements.  The goal of this
+   document is to establish a common baseline for generic applications
+   requiring broad interoperability and limited special purpose
+
+
+
+
+
+
+Farrell & Housley           Standards Track                     [Page 7]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   requirements.  In particular, the emphasis will be on supporting the
+   use of attribute certificates for informal Internet electronic mail,
+   IPSec, and WWW applications.
+
+   This section presents a profile for ACs that will foster
+   interoperability.  This section also defines some private extensions
+   for the Internet community.
+
+   While the ISO/IEC/ITU documents use the 1993 (or later) version of
+   ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for
+   PKCs [PKIXPROF].  The encoded certificates and extensions from either
+   ASN.1 version are bit-wise identical.
+
+   Where maximum lengths for fields are specified, these lengths refer
+   to the DER encoding and do not include the ASN.1 tag or length
+   fields.
+
+   Conforming implementations MUST support the profile specified in this
+   section.
+
+4.1 X.509 Attribute Certificate Definition
+
+   X.509 contains the definition of an AC given below.  All types that
+   are not defined in this document can be found in [PKIXPROF].
+
+            AttributeCertificate ::= SEQUENCE {
+                 acinfo               AttributeCertificateInfo,
+                 signatureAlgorithm   AlgorithmIdentifier,
+                 signatureValue       BIT STRING
+            }
+
+            AttributeCertificateInfo ::= SEQUENCE {
+                 version              AttCertVersion -- version is v2,
+                 holder               Holder,
+                 issuer               AttCertIssuer,
+                 signature            AlgorithmIdentifier,
+                 serialNumber         CertificateSerialNumber,
+                 attrCertValidityPeriod   AttCertValidityPeriod,
+                 attributes           SEQUENCE OF Attribute,
+                 issuerUniqueID       UniqueIdentifier OPTIONAL,
+                 extensions           Extensions OPTIONAL
+            }
+
+            AttCertVersion ::= INTEGER { v2(1) }
+            Holder ::= SEQUENCE {
+                  baseCertificateID   [0] IssuerSerial OPTIONAL,
+                           -- the issuer and serial number of
+                           -- the holder's Public Key Certificate
+
+
+
+Farrell & Housley           Standards Track                     [Page 8]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+                  entityName          [1] GeneralNames OPTIONAL,
+                           -- the name of the claimant or role
+                  objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
+                           -- used to directly authenticate the holder,
+                           -- for example, an executable
+            }
+
+            ObjectDigestInfo ::= SEQUENCE {
+                 digestedObjectType  ENUMERATED {
+                         publicKey            (0),
+                         publicKeyCert        (1),
+                         otherObjectTypes     (2) },
+                                 -- otherObjectTypes MUST NOT
+                                 -- be used in this profile
+                 otherObjectTypeID   OBJECT IDENTIFIER OPTIONAL,
+                 digestAlgorithm     AlgorithmIdentifier,
+                 objectDigest        BIT STRING
+            }
+
+            AttCertIssuer ::= CHOICE {
+                 v1Form   GeneralNames,  -- MUST NOT be used in this
+                                         -- profile
+                 v2Form   [0] V2Form     -- v2 only
+            }
+
+            V2Form ::= SEQUENCE {
+                 issuerName            GeneralNames  OPTIONAL,
+                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
+                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
+                   -- issuerName MUST be present in this profile
+                   -- baseCertificateID and objectDigestInfo MUST NOT
+                   -- be present in this profile
+            }
+
+            IssuerSerial  ::=  SEQUENCE {
+                 issuer         GeneralNames,
+                 serial         CertificateSerialNumber,
+                 issuerUID      UniqueIdentifier OPTIONAL
+            }
+
+            AttCertValidityPeriod  ::= SEQUENCE {
+                 notBeforeTime  GeneralizedTime,
+                 notAfterTime   GeneralizedTime
+            }
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                     [Page 9]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Although the Attribute syntax is defined in [PKIXPROF], we repeat
+   the definition here for convenience.
+
+            Attribute ::= SEQUENCE {
+                  type      AttributeType,
+                  values    SET OF AttributeValue
+                    -- at least one value is required
+            }
+
+            AttributeType ::= OBJECT IDENTIFIER
+
+            AttributeValue ::= ANY DEFINED BY AttributeType
+
+   Implementers should note that the DER encoding (see [X.509-
+   1988],[X.208-1988]) of the SET OF values requires ordering of the
+   encodings of the values.  Though this issue arises with respect to
+   distinguished names, and has to be handled by [PKIXPROF]
+   implementations, it is much more significant in this context, since
+   the inclusion of multiple values is much more common in ACs.
+
+4.2 Profile of Standard Fields
+
+   GeneralName offers great flexibility.  To achieve interoperability,
+   in spite of this flexibility, this profile imposes constraints on the
+   use of GeneralName.
+
+   Conforming implementations MUST be able to support the dNSName,
+   directoryName, uniformResourceIdentifier, and iPAddress options.
+   This is compatible with the GeneralName requirements in [PKIXPROF]
+   (mainly in section 4.2.1.7).
+
+   Conforming implementations MUST NOT use the x400Address,
+   ediPartyName, or registeredID options.
+
+   Conforming implementations MAY use the otherName option to convey
+   name forms defined in Internet Standards.  For example, Kerberos
+   [KRB] format names can be encoded into the otherName, using a
+   Kerberos 5 principal name OID and a SEQUENCE of the Realm and the
+   PrincipalName.
+
+4.2.1   Version
+
+   The version field MUST have the value of v2.  That is, the version
+   field is present in the DER encoding.
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 10]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Note: This version (v2) is not backwards compatible with the previous
+   attribute certificate definition (v1) from the 1997 X.509 standard
+   [X.509-1997], but is compatible with the v2 definition from X.509
+   (2000) [X.509-2000].
+
+4.2.2   Holder
+
+   The Holder field is a SEQUENCE allowing three different (optional)
+   syntaxes: baseCertificateID, entityName and objectDigestInfo.  Where
+   only one option is present, the meaning of the Holder field is clear.
+   However, where more than one option is used, there is a potential for
+   confusion as to which option is "normative", which is a "hint" etc.
+   Since the correct position is not clear from [X.509-2000], this
+   specification RECOMMENDS that only one of the options be used in any
+   given AC.
+
+   For any environment where the AC is passed in an authenticated
+   message or session and where the authentication is based on the use
+   of an X.509 PKC, the holder field SHOULD use the baseCertificateID.
+
+   With the baseCertificateID option, the holder's PKC serialNumber and
+   issuer MUST be identical to the AC holder field.  The PKC issuer MUST
+   have a non-empty distinguished name which is to be present as the
+   single value of the holder.baseCertificateID.issuer construct in the
+   directoryName field.  The AC holder.baseCertificateID.issuerUID field
+   MUST only be used if the holder's PKC contains an issuerUniqueID
+   field.  If both the AC holder.baseCertificateID.issuerUID and the PKC
+   issuerUniqueID fields are present, the same value MUST be present in
+   both fields.  Thus, the baseCertificateID is only usable with PKC
+   profiles (like [PKIXPROF]) which mandate that the PKC issuer field
+   contain a non-empty distinguished name value.
+
+   Note: An empty distinguished name is a distinguished name where the
+   SEQUENCE OF relative distinguished names is of zero length.  In a DER
+   encoding, this has the value '3000'H.
+
+   If the holder field uses the entityName option and the underlying
+   authentication is based on a PKC, the entityName MUST be the same as
+   the PKC subject field or one of the values of the PKC subjectAltName
+   field extension (if present).  Note that [PKIXPROF] mandates that the
+   subjectAltName extension be present if the PKC subject is an empty
+   distinguished name.  See the security considerations section which
+   mentions some name collision problems that may arise when using the
+   entityName option.
+
+   In any other case where the holder field uses the entityName option,
+   only one name SHOULD be present.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 11]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Implementations conforming to this profile are not required to
+   support the use of the objectDigest field.  However, section 7.3
+   specifies how this optional feature MAY be used.
+
+   Any protocol conforming to this profile SHOULD specify which AC
+   holder option is to be used and how this fits with the supported
+   authentication schemes defined in that protocol.
+
+4.2.3   Issuer
+
+   ACs conforming to this profile MUST use the v2Form choice, which MUST
+   contain one and only one GeneralName in the issuerName, which MUST
+   contain a non-empty distinguished name in the directoryName field.
+   This means that all AC issuers MUST have non-empty distinguished
+   names.  ACs conforming to this profile MUST omit the
+   baseCertificateID and objectDigestInfo fields.
+
+   Part of the reason for the use of the v2Form containing only an
+   issuerName is that it means that the AC issuer does not have to know
+   which PKC the AC verifier will use for it (the AC issuer).  Using the
+   baseCertificateID field to reference the AC issuer would mean that
+   the AC verifier would have to trust the PKC that the AC issuer chose
+   (for itself) at AC creation time.
+
+4.2.4   Signature
+
+   Contains the algorithm identifier used to validate the AC signature.
+
+   This MUST be one of the signing algorithms defined in [PKIXALGS].
+   Conforming implementations MUST honor all MUST/SHOULD/MAY signing
+   algorithm statements specified in [PKIXALGS].
+
+4.2.5   Serial Number
+
+   For any conforming AC, the issuer/serialNumber pair MUST form a
+   unique combination, even if ACs are very short-lived.
+
+   AC issuers MUST force the serialNumber to be a positive integer, that
+   is, the sign bit in the DER encoding of the INTEGER value MUST be
+   zero - this can be done by adding a leading (leftmost) '00'H octet if
+   necessary.  This removes a potential ambiguity in mapping between a
+   string of octets and an integer value.
+
+   Given the uniqueness and timing requirements above, serial numbers
+   can be expected to contain long integers.  AC users MUST be able to
+   handle serialNumber values longer than 4 octets.  Conformant ACs MUST
+   NOT contain serialNumber values longer than 20 octets.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 12]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   There is no requirement that the serial numbers used by any AC issuer
+   follow any particular ordering.  In particular, they need not be
+   monotonically increasing with time.  Each AC issuer MUST ensure that
+   each AC that it issues contains a unique serial number.
+
+4.2.6   Validity Period
+
+   The attrCertValidityPeriod (a.k.a. validity) field specifies the
+   period for which the AC issuer certifies that the binding between the
+   holder and the attributes fields will be valid.
+
+   The generalized time type, GeneralizedTime, is a standard ASN.1 type
+   for variable precision representation of time.  The GeneralizedTime
+   field can optionally include a representation of the time
+   differential between the local time zone and Greenwich Mean Time.
+
+   For the purposes of this profile, GeneralizedTime values MUST be
+   expressed in Coordinated universal time (UTC) (also known as
+   Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
+   are YYYYMMDDHHMMSSZ), even when the number of seconds is zero.
+   GeneralizedTime values MUST NOT include fractional seconds.
+
+   (Note: this is the same as specified in [PKIXPROF], section
+   4.1.2.5.2.)
+
+   AC users MUST be able to handle an AC which, at the time of
+   processing, has parts of its validity period or all its validity
+   period in the past or in the future (a post-dated AC).  This is valid
+   for some applications, such as backup.
+
+4.2.7   Attributes
+
+   The attributes field gives information about the AC holder.  When the
+   AC is used for authorization, this will often contain a set of
+   privileges.
+
+   The attributes field contains a SEQUENCE OF Attribute.  Each
+   Attribute MAY contain a SET OF values.  For a given AC, each
+   AttributeType OBJECT IDENTIFIER in the sequence MUST be unique.  That
+   is, only one instance of each attribute can occur in a single AC, but
+   each instance can be multi-valued.
+
+   AC users MUST be able to handle multiple values for all attribute
+   types.
+
+   An AC MUST contain at least one attribute.  That is, the SEQUENCE OF
+   Attributes MUST NOT be of zero length.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 13]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Some standard attribute types are defined in section 4.4.
+
+4.2.8   Issuer Unique Identifier
+
+   This field MUST NOT be used unless it is also used in the AC issuer's
+   PKC, in which case it MUST be used.  Note that [PKIXPROF] states that
+   this field SHOULD NOT be used by conforming CAs, but that
+   applications SHOULD be able to parse PKCs containing the field.
+
+4.2.9   Extensions
+
+   The extensions field generally gives information about the AC as
+   opposed to information about the AC holder.
+
+   An AC that has no extensions conforms to the profile; however,
+   section 4.3 defines the extensions that MAY be used with this
+   profile, and whether or not they may be marked critical.  If any
+   other critical extension is used, the AC does not conform to this
+   profile.  However, if any other non-critical extension is used, the
+   AC does conform to this profile.
+
+   The extensions defined for ACs provide methods for associating
+   additional attributes with holders.  This profile also allows
+   communities to define private extensions to carry information unique
+   to those communities.  Each extension in an AC may be designated as
+   critical or non-critical.  An AC using system MUST reject an AC if it
+   encounters a critical extension it does not recognize; however, a
+   non-critical extension may be ignored if it is not recognized.
+   Section 4.3 presents recommended extensions used within Internet ACs
+   and standard locations for information.  Communities may elect to use
+   additional extensions; however, caution should be exercised in
+   adopting any critical extensions in ACs which might prevent use in a
+   general context.
+
+4.3 Extensions
+
+4.3.1   Audit Identity
+
+   In some circumstances, it is required (e.g. by data protection/data
+   privacy legislation) that audit trails not contain records which
+   directly identify individuals.  This circumstance may make the use of
+   the AC holder field unsuitable for use in audit trails.
+
+   To allow for such cases, an AC MAY contain an audit identity
+   extension.  Ideally it SHOULD be infeasible to derive the AC holder's
+   identity from the audit identity value without the cooperation of the
+   AC issuer.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 14]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   The value of the audit identity, along with the AC issuer/serial,
+   SHOULD then be used for audit/logging purposes.  If the value of the
+   audit identity is suitably chosen, a server/service administrator can
+   use audit trails to track the behavior of an AC holder without being
+   able to identify the AC holder.
+
+   The server/service administrator in combination with the AC issuer
+   MUST be able to identify the AC holder in cases where misbehavior is
+   detected.  This means that the AC issuer MUST be able to determine
+   the actual identity of the AC holder from the audit identity.
+
+   Of course, auditing could be based on the AC issuer/serial pair;
+   however, this method does not allow tracking of the same AC holder
+   with multiple ACs.  Thus, an audit identity is only useful if it
+   lasts for longer than the typical AC lifetime.  Auditing could also
+   be based on the AC holder's PKC issuer/serial; however, this will
+   often allow the server/service administrator to identify the AC
+   holder.
+
+   As the AC verifier might otherwise use the AC holder or some other
+   identifying value for audit purposes, this extension MUST be critical
+   when used.
+
+   Protocols that use ACs will often expose the identity of the AC
+   holder in the bits on-the-wire.  In such cases, an opaque audit
+   identity does not make use of the AC anonymous; it simply ensures
+   that the ensuing audit trails do not contain identifying information.
+
+   The value of an audit identity MUST be longer than zero octets.  The
+   value of an audit identity MUST NOT be longer than 20 octets.
+
+      name           id-pe-ac-auditIdentity
+      OID            { id-pe 4 }
+      syntax         OCTET STRING
+      criticality    MUST be TRUE
+
+4.3.2   AC Targeting
+
+   To target an AC, the target information extension, imported from
+   [X.509-2000], MAY be used to specify a number of servers/services.
+   The intent is that the AC SHOULD only be usable at the specified
+   servers/services.  An (honest) AC verifier who is not amongst the
+   named servers/services MUST reject the AC.
+
+   If this extension is not present, the AC is not targeted and may be
+   accepted by any server.
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 15]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   In this profile, the targeting information simply consists of a list
+   of named targets or groups.
+
+   The following syntax is used to represent the targeting information:
+
+            Targets ::= SEQUENCE OF Target
+
+            Target  ::= CHOICE {
+              targetName          [0] GeneralName,
+              targetGroup         [1] GeneralName,
+              targetCert          [2] TargetCert
+            }
+
+            TargetCert  ::= SEQUENCE {
+              targetCertificate    IssuerSerial,
+              targetName           GeneralName OPTIONAL,
+              certDigestInfo       ObjectDigestInfo OPTIONAL
+            }
+
+   The targetCert CHOICE within the Target structure is only present to
+   allow future compatibility with [X.509-2000] and MUST NOT be used.
+
+   The targets check passes if the current server (recipient) is one of
+   the targetName fields in the Targets SEQUENCE, or if the current
+   server is a member of one of the targetGroup fields in the Targets
+   SEQUENCE.  In this case, the current server is said to "match" the
+   targeting extension.
+
+   How the membership of a target within a targetGroup is determined is
+   not defined here.  It is assumed that any given target "knows" the
+   names of the targetGroups to which it belongs or can otherwise
+   determine its membership.  For example, the targetGroup specifies a
+   DNS domain, and the AC verifier knows the DNS domain to which it
+   belongs.  For another example, the targetGroup specifies "PRINTERS,"
+   and the AC verifier knows whether or not it is a printer or print
+   server.
+
+   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
+   Targets".  Conforming AC issuer implementations MUST only produce one
+   "Targets" element.  Confirming AC users MUST be able to accept a
+   "SEQUENCE OF Targets".  If more than one Targets element is found in
+   an AC, the extension MUST be treated as if all Target elements had
+   been found within one Targets element.
+
+      name           id-ce-targetInformation
+      OID            { id-ce 55 }
+      syntax         SEQUENCE OF Targets
+      criticality    MUST be TRUE
+
+
+
+Farrell & Housley           Standards Track                    [Page 16]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+4.3.3   Authority Key Identifier
+
+   The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
+   be used to assist the AC verifier in checking the signature of the
+   AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
+   issuer."  As with PKCs, this extension SHOULD be included in ACs.
+
+   Note: An AC, where the issuer field used the baseCertificateID
+   CHOICE, would not need an authorityKeyIdentifier extension, as it is
+   explicitly linked to the key in the referred certificate.  However,
+   as this profile states (in section 4.2.3), ACs MUST use the v2Form
+   with issuerName CHOICE, this duplication does not arise.
+
+      name           id-ce-authorityKeyIdentifier
+      OID            { id-ce 35 }
+      syntax         AuthorityKeyIdentifier
+      criticality    MUST be FALSE
+
+4.3.4   Authority Information Access
+
+   The authorityInformationAccess extension, as defined in [PKIXPROF],
+   MAY be used to assist the AC verifier in checking the revocation
+   status of the AC.  Support for the id-ad-caIssuers accessMethod is
+   NOT REQUIRED by this profile since AC chains are not expected.
+
+   The following accessMethod is used to indicate that revocation status
+   checking is provided for this AC, using the OCSP protocol defined in
+   [OCSP]:
+
+      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
+
+   The accessLocation MUST contain a URI, and the URI MUST contain an
+   HTTP URL [URL] that specifies the location of an OCSP responder.  The
+   AC issuer MUST, of course, maintain an OCSP responder at this
+   location.
+
+      name           id-ce-authorityInfoAccess
+      OID            { id-pe 1 }
+      syntax         AuthorityInfoAccessSyntax
+      criticality    MUST be FALSE
+
+4.3.5   CRL Distribution Points
+
+   The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY
+   be used to assist the AC verifier in checking the revocation status
+   of the AC.  See section 6 for details on revocation.
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 17]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   If the crlDistributionPoints extension is present, then exactly one
+   distribution point MUST be present.  The crlDistributionPoints
+   extension MUST use the DistributionPointName option, which MUST
+   contain a fullName, which MUST contain a single name form.  That name
+   MUST contain either a distinguished name or a URI.  The URI MUST be
+   either an HTTP URL or an LDAP URL [URL].
+
+      name           id-ce-cRLDistributionPoints
+      OID            { id-ce 31 }
+      syntax         CRLDistPointsSyntax
+      criticality    MUST be FALSE
+
+4.3.6   No Revocation Available
+
+   The noRevAvail extension, defined in [X.509-2000], allows an AC
+   issuer to indicate that no revocation information will be made
+   available for this AC.
+
+   This extension MUST be non-critical.  An AC verifier that does not
+   understand this extension might be able to find a revocation list
+   from the AC issuer, but the revocation list will never include an
+   entry for the AC.
+
+      name           id-ce-noRevAvail
+      OID            { id-ce 56 }
+      syntax         NULL (i.e. '0500'H is the DER encoding)
+      criticality    MUST be FALSE
+
+4.4 Attribute Types
+
+   Some of the attribute types defined below make use of the
+   IetfAttrSyntax type, also defined below.  The reasons for using this
+   type are:
+
+   1. It allows a separation between the AC issuer and the attribute
+      policy authority.  This is useful for situations where a single
+      policy authority (e.g. an organization) allocates attribute
+      values, but where multiple AC issuers are deployed for performance
+      or other reasons.
+
+   2. The syntaxes allowed for values are restricted to OCTET STRING,
+      OBJECT IDENTIFIER, and UTF8String, which significantly reduces the
+      complexity associated with matching more general syntaxes.  All
+      multi-valued attributes using this syntax are restricted so that
+      each value MUST use the same choice of value syntax.  For example,
+      AC issuers must not use one value with an oid and a second value
+      with a string.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 18]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+               IetfAttrSyntax ::= SEQUENCE {
+                    policyAuthority [0] GeneralNames    OPTIONAL,
+                    values          SEQUENCE OF CHOICE {
+                                  octets    OCTET STRING,
+                                  oid       OBJECT IDENTIFIER,
+                                  string    UTF8String
+                   }
+               }
+
+   In the descriptions below, each attribute type is either tagged
+   "Multiple Allowed" or "One Attribute value only; multiple values
+   within the IetfAttrSyntax".  This refers to the SET OF
+   AttributeValues; the AttributeType still only occurs once, as
+   specified in section 4.2.7.
+
+4.4.1   Service Authentication Information
+
+   The SvceAuthInfo attribute identifies the AC holder to the
+   server/service by a name, and the attribute MAY include optional
+   service specific authentication information.  Typically this will
+   contain a username/password pair for a "legacy" application.
+
+   This attribute provides information that can be presented by the AC
+   verifier to be interpreted and authenticated by a separate
+   application within the target system.  Note that this is a different
+   use to that intended for the accessIdentity attribute in 4.4.2 below.
+
+   This attribute type will typically be encrypted when the authInfo
+   field contains sensitive information, such as a password.
+
+      name      id-aca-authenticationInfo
+      OID       { id-aca 1 }
+      Syntax    SvceAuthInfo
+      values:   Multiple allowed
+
+           SvceAuthInfo ::=    SEQUENCE {
+                service   GeneralName,
+                ident     GeneralName,
+                authInfo  OCTET STRING OPTIONAL
+           }
+
+4.4.2   Access Identity
+
+   The accessIdentity attribute identifies the AC holder to the
+   server/service.  For this attribute the authInfo field MUST NOT be
+   present.
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 19]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   This attribute is intended to be used to provide information about
+   the AC holder, that can be used by the AC verifier (or a larger
+   system of which the AC verifier is a component) to authorize the
+   actions of the AC holder within the AC verifier's system.  Note that
+   this is a different use to that intended for the svceAuthInfo
+   attribute described in 4.4.1 above.
+
+      name      id-aca-accessIdentity
+      OID       { id-aca 2 }
+      syntax    SvceAuthInfo
+      values:   Multiple allowed
+
+4.4.3   Charging Identity
+
+   The chargingIdentity attribute identifies the AC holder for charging
+   purposes.  In general, the charging identity will be different from
+   other identities of the holder.  For example, the holder's company
+   may be charged for service.
+
+      name      id-aca-chargingIdentity
+      OID       { id-aca 3 }
+      syntax    IetfAttrSyntax
+      values:   One Attribute value only; multiple values within the
+                IetfAttrSyntax
+
+4.4.4   Group
+
+   The group attribute carries information about group memberships of
+   the AC holder.
+
+      name      id-aca-group
+      OID       { id-aca 4 }
+      syntax    IetfAttrSyntax
+      values:   One Attribute value only; multiple values within the
+                IetfAttrSyntax
+
+4.4.5   Role
+
+   The role attribute, specified in [X.509-2000], carries information
+   about role allocations of the AC holder.
+
+   The syntax used for this attribute is:
+
+         RoleSyntax ::= SEQUENCE {
+                 roleAuthority   [0] GeneralNames OPTIONAL,
+                 roleName        [1] GeneralName
+         }
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 20]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   The roleAuthority field MAY be used to specify the issuing authority
+   for the role specification certificate.  There is no requirement that
+   a role specification certificate necessarily exists for the
+   roleAuthority.  This differs from [X.500-2000], where the
+   roleAuthority field is assumed to name the issuer of a role
+   specification certificate.  For example, to distinguish the
+   administrator role as defined by "Baltimore" from that defined by
+   "SPYRUS", one could put the value "urn:administrator" in the roleName
+   field and the value "Baltimore" or "SPYRUS" in the roleAuthority
+   field.
+
+   The roleName field MUST be present, and roleName MUST use the
+   uniformResourceIdentifier CHOICE of the GeneralName.
+
+      name      id-at-role
+      OID       { id-at 72 }
+      syntax    RoleSyntax
+      values:   Multiple allowed
+
+4.4.6   Clearance
+
+   The clearance attribute, specified in [X.501-1993], carries clearance
+   (associated with security labeling) information about the AC holder.
+
+   The policyId field is used to identify the security policy to which
+   the clearance relates.  The policyId indicates the semantics of the
+   classList and securityCategories fields.
+
+   This specification includes the classList field exactly as it is
+   specified in [X.501-1993].  Additional security classification
+   values, and their position in the classification hierarchy, may be
+   defined by a security policy as a local matter or by bilateral
+   agreement.  The basic security classification hierarchy is, in
+   ascending order: unmarked, unclassified, restricted, confidential,
+   secret, and top-secret.
+
+   An organization can develop its own security policy that defines
+   security classification values and their meanings.  However, the BIT
+   STRING positions 0 through 5 are reserved for the basic security
+   classification hierarchy.
+
+   If present, the SecurityCategory field provides further authorization
+   information.  The security policy identified by the policyId field
+   indicates the syntaxes that are allowed to be present in the
+   securityCategories SET.  An OBJECT IDENTIFIER identifies each of the
+   allowed syntaxes.  When one of these syntaxes is present in the
+   securityCategories SET, the OBJECT IDENTIFIER associated with that
+   syntax is carried in the SecurityCategory.type field.
+
+
+
+Farrell & Housley           Standards Track                    [Page 21]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+            Clearance  ::=  SEQUENCE {
+                 policyId  [0] OBJECT IDENTIFIER,
+                 classList [1] ClassList DEFAULT {unclassified},
+                 securityCategories
+                           [2] SET OF SecurityCategory OPTIONAL
+            }
+
+            ClassList  ::=  BIT STRING {
+                 unmarked       (0),
+                 unclassified   (1),
+                 restricted     (2)
+                 confidential   (3),
+                 secret         (4),
+                 topSecret      (5)
+            }
+
+            SecurityCategory ::= SEQUENCE {
+                 type      [0]  IMPLICIT OBJECT IDENTIFIER,
+                 value     [1]  ANY DEFINED BY type
+            }
+
+            -- This is the same as the original syntax which was defined
+            -- using the MACRO construct, as follows:
+            -- SecurityCategory ::= SEQUENCE {
+            --      type      [0]  IMPLICIT SECURITY-CATEGORY,
+            --      value     [1]  ANY DEFINED BY type
+            -- }
+            --
+            -- SECURITY-CATEGORY MACRO  ::=
+            -- BEGIN
+            -- TYPE NOTATION ::= type | empty
+            -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
+            -- END
+
+
+
+       name      { id-at-clearance }
+       OID       { joint-iso-ccitt(2) ds(5) module(1)
+                   selected-attribute-types(5) clearance (55) }
+       syntax    Clearance - imported from [X.501-1993]
+       values    Multiple allowed
+
+4.5 Profile of AC issuer's PKC
+
+   The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
+   extension in the PKC MUST NOT explicitly indicate that the AC
+   issuer's public key cannot be used to validate a digital signature.
+   In order to avoid confusion regarding serial numbers and revocations,
+
+
+
+Farrell & Housley           Standards Track                    [Page 22]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   an AC issuer MUST NOT also be a PKC Issuer.  That is, an AC issuer
+   cannot be a CA as well.  So, the AC issuer's PKC MUST NOT have a
+   basicConstraints extension with the cA BOOLEAN set to TRUE.
+
+5. Attribute Certificate Validation
+
+   This section describes a basic set of rules that all valid ACs MUST
+   satisfy.  Some additional checks are also described which AC
+   verifiers MAY choose to implement.
+
+   To be valid an AC MUST satisfy all of the following:
+
+   1. Where the holder uses a PKC to authenticate to the AC verifier,
+      the AC holder's PKC MUST be found, and the entire certification
+      path of that PKC MUST be verified in accordance with [PKIXPROF].
+      As noted in the security considerations section, if some other
+      authentication scheme is used, AC verifiers need to be very
+      careful mapping the identities (authenticated identity, holder
+      field) involved.
+
+   2. The AC signature must be cryptographically correct, and the AC
+      issuer's entire PKC certification path MUST be verified in
+      accordance with [PKIXPROF].
+
+   3. The AC issuer's PKC MUST also conform to the profile specified in
+      section 4.5 above.
+
+   4. The AC issuer MUST be directly trusted as an AC issuer (by
+      configuration or otherwise).
+
+   5. The time for which the AC is being evaluated MUST be within the AC
+      validity.  If the evaluation time is equal to either notBeforeTime
+      or notAfterTime, then the AC is timely and this check succeeds.
+      Note that in some applications, the evaluation time MAY not be the
+      same as the current time.
+
+   6. The AC targeting check MUST pass as specified in section 4.3.2.
+
+   7. If the AC contains an unsupported critical extension, the AC MUST
+      be rejected.
+
+   Support for an extension in this context means:
+
+   1. The AC verifier MUST be able to parse the extension value.
+
+   2. Where the extension value SHOULD cause the AC to be rejected, the
+      AC verifier MUST reject the AC.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 23]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Additional Checks:
+
+   1. The AC MAY be rejected on the basis of further AC verifier
+      configuration.  For example, an AC verifier may be configured to
+      reject ACs which contain or lack certain attributes.
+
+   2. If the AC verifier provides an interface that allows applications
+      to query the contents of the AC, then the AC verifier MAY filter
+      the attributes from the AC on the basis of configured information.
+      For example, an AC verifier might be configured not to return
+      certain attributes to certain servers.
+
+6. Revocation
+
+   In many environments, the validity period of an AC is less than the
+   time required to issue and distribute revocation information.
+   Therefore, short-lived ACs typically do not require revocation
+   support.  However, long-lived ACs and environments where ACs enable
+   high value transactions MAY require revocation support.
+
+   Two revocation schemes are defined, and the AC issuer should elect
+   the one that is best suited to the environment in which the AC will
+   be employed.
+
+   "Never revoke" scheme:
+
+      ACs may be marked so that the relying party understands that no
+      revocation status information will be made available.  The
+      noRevAvail extension is defined in section 4.3.6, and the
+      noRevAvail extension MUST be present in the AC to indicate use of
+      this scheme.
+
+      Where no noRevAvail is present, the AC issuer is implicitly
+      stating that revocation status checks are supported, and some
+      revocation method MUST be provided to allow AC verifiers to
+      establish the revocation status of the AC.
+
+   "Pointer in AC" scheme:
+
+      ACs may "point" to sources of revocation status information, using
+      either an authorityInfoAccess extension or a crlDistributionPoints
+      extension within the AC.
+
+   For AC users, the "never revoke" scheme MUST be supported, and the
+   "pointer in AC" scheme SHOULD be supported.  If only the "never
+   revoke" scheme is supported, then all ACs that do not contain a
+   noRevAvail extension, MUST be rejected.
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 24]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   For AC issuers, the "never revoke" scheme MUST be supported.  If all
+   ACs that will ever be issued by that AC issuer, contains a noRevAvail
+   extension, the "pointer in AC" scheme need not be supported.  If any
+   AC can be issued that does not contain the noRevAvail extension, the
+   "pointer in AC" scheme MUST be supported.
+
+   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".
+
+   An AC verifier MAY use any source for AC revocation status
+   information.
+
+7. Optional Features
+
+   This section specifies features that MAY be implemented.  Conformance
+   to this profile does NOT require support for these features; however,
+   if these features are offered, they MUST be offered as described
+   below.
+
+7.1 Attribute Encryption
+
+   Where an AC will be carried in clear within an application protocol
+   or where an AC contains some sensitive information like a legacy
+   application username/password, then encryption of AC attributes MAY
+   be needed.
+
+   When a set of attributes are to be encrypted within an AC, the
+   Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
+   to carry the ciphertext and associated per-recipient keying
+   information.
+
+   This type of attribute encryption is targeted.  Before the AC is
+   signed, the attributes are encrypted for a set of predetermined
+   recipients.
+
+   The AC then contains the ciphertext inside its signed data.  The
+   EnvelopedData (id-envelopedData) ContentType is used, and the content
+   field will contain the EnvelopedData type.
+
+   The ciphertext is included in the AC as the value of an encAttrs
+   attribute.  Only one encAttrs attribute can be present in an AC;
+   however, the encAttrs attribute MAY be multi-valued, and each of its
+   values will contain an independent EnvelopedData.
+
+   Each value can contain a set of attributes (each possibly a multi-
+   valued attribute) encrypted for a set of predetermined recipients.
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 25]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   The cleartext that is encrypted has the type:
+
+      ACClearAttrs ::= SEQUENCE {
+           acIssuer  GeneralName,
+           acSerial  INTEGER,
+           attrs     SEQUENCE OF Attribute
+      }
+
+   The DER encoding of the ACClearAttrs structure is used as the
+   encryptedContent field of the EnvelopedData.  The DER encoding MUST
+   be embedded in an OCTET STRING.
+
+   The acIssuer and acSerial fields are present to prevent ciphertext
+   stealing.  When an AC verifier has successfully decrypted an
+   encrypted attribute, it MUST then check that the AC issuer and
+   serialNumber fields contain the same values.  This prevents a
+   malicious AC issuer from copying ciphertext from another AC (without
+   knowing its corresponding plaintext).
+
+   The procedure for an AC issuer when encrypting attributes is
+   illustrated by the following (any other procedure that gives the same
+   result MAY be used):
+
+      1.   Identify the sets of attributes that are to be encrypted for
+           each set of recipients.
+      2.   For each attribute set which is to be encrypted:
+         2.1. Create an EnvelopedData structure for the data for this
+              set of recipients.
+         2.2. Encode the ContentInfo containing the EnvelopedData as a
+              value of the encAttrs attribute.
+         2.3. Ensure the cleartext attributes are not present in the
+              to-be-signed AC.
+      3.   Add the encAttrs (with its multiple values) to the AC.
+
+   Note that there may be more than one attribute of the same type (the
+   same OBJECT IDENTIFIER) after decryption.  That is, an AC MAY contain
+   the same attribute type both in clear and in encrypted form (and
+   indeed several times if the same recipient is associated with more
+   than one EnvelopedData).  One approach implementers may choose, would
+   be to merge attribute values following decryption in order to re-
+   establish the "once only" constraint.
+
+      name      id-aca-encAttrs
+      OID       { id-aca 6}
+      Syntax    ContentInfo
+      values    Multiple Allowed
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 26]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   If an AC contains attributes, apparently encrypted for the AC
+   verifier, the decryption process MUST not fail.  If decryption does
+   fail, the AC MUST be rejected.
+
+7.2 Proxying
+
+   When a server acts as a client for another server on behalf of the AC
+   holder, the server MAY need to proxy an AC.  Such proxying MAY have
+   to be done under the AC issuer's control, so that not every AC is
+   proxiable and so that a given proxiable AC can be proxied in a
+   targeted fashion.  Support for chains of proxies (with more than one
+   intermediate server) MAY also be required.  Note that this does not
+   involve a chain of ACs.
+
+   In order to meet this requirement we define another extension,
+   ProxyInfo, similar to the targeting extension.
+
+   When this extension is present, the AC verifier must check that the
+   entity from which the AC was received was allowed to send it and that
+   the AC is allowed to be used by this verifier.
+
+   The proxying information consists of a set of proxy information, each
+   of which is a set of targeting information.  If the verifier and the
+   sender of the AC are both named in the same proxy set, the AC can
+   then be accepted (the exact rule is given below).
+
+   The effect is that the AC holder can send the AC to any valid target
+   which can then only proxy to targets which are in one of the same
+   proxy sets as itself.
+
+   The following data structure is used to represent the
+   targeting/proxying information.
+
+         ProxyInfo ::= SEQUENCE OF Targets
+
+   As in the case of targeting, the targetCert CHOICE MUST NOT be used.
+
+   A proxy check succeeds if either one of the conditions below is met:
+
+   1. The identity of the sender, as established by the underlying
+      authentication service, matches the holder field of the AC, and
+      the current server "matches" any one of the proxy sets.  Recall
+      that "matches" is as defined section 4.3.2.
+
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 27]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   2. The identity of the sender, as established by the underlying
+      authentication service, "matches" one of the proxy sets (call it
+      set "A"), and the current server is one of the targetName fields
+      in the set "A", or the current server is a member of one of the
+      targetGroup fields in set "A".
+
+   When an AC is proxied more than once, a number of targets will be on
+   the path from the original client, which is normally, but not always,
+   the AC holder.  In such cases, prevention of AC "stealing" requires
+   that the AC verifier MUST check that all targets on the path are
+   members of the same proxy set.  It is the responsibility of the AC-
+   using protocol to ensure that a trustworthy list of targets on the
+   path is available to the AC verifier.
+
+      name           id-pe-ac-proxying
+      OID            { id-pe 10 }
+      syntax         ProxyInfo
+      criticality    MUST be TRUE
+
+7.3 Use of ObjectDigestInfo
+
+   In some environments, it may be required that the AC is not linked
+   either to an identity (via entityName) or to a PKC (via
+   baseCertificateID).  The objectDigestInfo CHOICE in the holder field
+   allows support for this requirement.
+
+   If the holder is identified with the objectDigestInfo field, then the
+   AC version field MUST contain v2 (the integer 1).
+
+   The idea is to link the AC to an object by placing a hash of that
+   object into the holder field of the AC.  For example, this allows
+   production of ACs that are linked to public keys rather than names.
+   It also allows production of ACs which contain privileges associated
+   with an executable object such as a Java class.  However, this
+   profile only specifies how to use a hash over a public key or PKC.
+   That is, conformant ACs MUST NOT use the otherObjectTypes value for
+   the digestedObjectType.
+
+   To link an AC to a public key, the hash must be calculated over the
+   representation of that public key which would be present in a PKC,
+   specifically, the input for the hash algorithm MUST be the DER
+   encoding of a SubjectPublicKeyInfo representation of the key.  Note:
+   This includes the AlgorithmIdentifier as well as the BIT STRING.  The
+   rules given in [PKIXPROF] for encoding keys MUST be followed.  In
+   this case, the digestedObjectType MUST be publicKey and the
+   otherObjectTypeID field MUST NOT be present.
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 28]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Note that if the public key value used as input to the hash function
+   has been extracted from a PKC, it is possible that the
+   SubjectPublicKeyInfo from that PKC is NOT the value which should be
+   hashed.  This can occur if DSA Dss-parms are inherited as described
+   in section 7.3.3 of [PKIXPROF].  The correct input for hashing in
+   this context will include the value of the parameters inherited from
+   the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
+   present in the PKC.
+
+   Implementations which support this feature MUST be able to handle the
+   representations of public keys for the algorithms specified in
+   section 7.3 of [PKIXPROF].  In this case, the digestedObjectType MUST
+   be publicKey and the otherObjectTypeID field MUST NOT be present.
+
+   In order to link an AC to a PKC via a digest, the digest MUST be
+   calculated over the DER encoding of the entire PKC, including the
+   signature value.  In this case the digestedObjectType MUST be
+   publicKeyCert and the otherObjectTypeID field MUST NOT be present.
+
+7.4 AA Controls
+
+   During AC validation a relying party has to answer the question: is
+   this AC issuer trusted to issue ACs containing this attribute?  The
+   AAControls PKC extension MAY be used to help answer the question.
+   The AAControls extension is intended to be used in CA and AC issuer
+   PKCs.
+
+         id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
+
+         AAControls ::= SEQUENCE {
+            pathLenConstraint   INTEGER (0..MAX) OPTIONAL,
+            permittedAttrs      [0] AttrSpec OPTIONAL,
+            excludedAttrs       [1] AttrSpec OPTIONAL,
+            permitUnSpecified   BOOLEAN DEFAULT TRUE
+         }
+
+         AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
+
+   The AAControls extension is used as follows:
+
+   The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
+   It restricts the allowed distance between the AA CA (a CA directly
+   trusted to include AAControls in its PKCs), and the AC issuer.
+
+   The permittedAttrs field specifies a set of attribute types that any
+   AC issuer below this AA CA is allowed to include in ACs.  If this
+   field is not present, it means that no attribute types are explicitly
+   allowed.
+
+
+
+Farrell & Housley           Standards Track                    [Page 29]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   The excludedAttrs field specifies a set of attribute types that no AC
+   issuer is allowed to include in ACs.  If this field is not present,
+   it means that no attribute types are explicitly disallowed.
+
+   The permitUnSpecified field specifies how to handle attribute types
+   which are not present in either the permittedAttrs or excludedAttrs
+   fields.  TRUE (the default) means that any unspecified attribute type
+   is allowed in ACs; FALSE means that no unspecified attribute type is
+   allowed.
+
+   When AAControls are used, the following additional checks on an AA's
+   PKC chain MUST all succeed for the AC to be valid:
+
+   1. Some CA on the ACs certificate path MUST be directly trusted to
+      issue PKCs which precede the AC issuer in the certification path;
+      call this CA the "AA CA".
+
+   2. All PKCs on the path from the AA CA, down to and including the AC
+      issuer's PKC, MUST contain an AAControls extension; however, the
+      AA CA's PKC need not contain this extension.
+
+   3. Only those attributes in the AC which are allowed, according to
+      all of the AAControls extension values in all of the PKCs from the
+      AA CA to the AC issuer, may be used for authorization decisions;
+      all other attributes MUST be ignored.  This check MUST be applied
+      to the set of attributes following attribute decryption, and the
+      id-aca-encAttrs type MUST also be checked.
+
+      name           id-pe-aaControls
+      OID            { id-pe 6 }
+      syntax         AAControls
+      criticality    MAY be TRUE
+
+8. Security Considerations
+
+   The protection afforded for private keys is a critical factor in
+   maintaining security.  Failure of AC issuers to protect their private
+   keys will permit an attacker to masquerade as them, potentially
+   generating false ACs or revocation status.  Existence of bogus ACs
+   and revocation status will undermine confidence in the system.  If
+   the compromise is detected, all ACs issued by the AC issuer MUST be
+   revoked.  Rebuilding after such a compromise will be problematic, so
+   AC issuers are advised to implement a combination of strong technical
+   measures (e.g., tamper-resistant cryptographic modules) and
+   appropriate management procedures (e.g., separation of duties) to
+   avoid such an incident.
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 30]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Loss of an AC issuer's private signing key may also be problematic.
+   The AC issuer would not be able to produce revocation status or
+   perform AC renewal.  AC issuers are advised to maintain secure backup
+   for signing keys.  The security of the key backup procedures is a
+   critical factor in avoiding key compromise.
+
+   The availability and freshness of revocation status will affect the
+   degree of assurance that should be placed in a long-lived AC.  While
+   long-lived ACs expire naturally, events may occur during its natural
+   lifetime which negate the binding between the AC holder and the
+   attributes.  If revocation status is untimely or unavailable, the
+   assurance associated with the binding is clearly reduced.
+
+   The binding between an AC holder and attributes cannot be stronger
+   than the cryptographic module implementation and algorithms used to
+   generate the signature.  Short key lengths or weak hash algorithms
+   will limit the utility of an AC.  AC issuers are encouraged to note
+   advances in cryptology so they can employ strong cryptographic
+   techniques.
+
+   Inconsistent application of name comparison rules may result in
+   acceptance of invalid targeted or proxied ACs, or rejection of valid
+   ones.  The X.500 series of specifications defines rules for comparing
+   distinguished names.  These rules require comparison of strings
+   without regard to case, character set, multi-character white space
+   substrings, or leading and trailing white space.  This specification
+   and [PKIXPROF] relaxes these requirements, requiring support for
+   binary comparison at a minimum.
+
+   AC issuers MUST encode the distinguished name in the AC
+   holder.entityName field identically to the distinguished name in the
+   holder's PKC.  If different encodings are used, implementations of
+   this specification may fail to recognize that the AC and PKC belong
+   to the same entity.
+
+   If an attribute certificate is tied to the holder's PKC using the
+   baseCertificateID component of the Holder field and the PKI in use
+   includes a rogue CA with the same issuer name specified in the
+   baseCertificateID component, this rogue CA could issue a PKC to a
+   malicious party, using the same issuer name and serial number as the
+   proper holder's PKC.  Then the malicious party could use this PKC in
+   conjunction with the AC.  This scenario SHOULD be avoided by properly
+   managing and configuring the PKI so that there cannot be two CAs with
+   the same name.  Another alternative is to tie ACs to PKCs using the
+   publicKeyCert type in the ObjectDigestInfo field.  Failing this, AC
+   verifiers have to establish (using other means) that the potential
+   collisions cannot actually occur, for example, the CPSs of the CAs
+   involved may make it clear that no such name collisions can occur.
+
+
+
+Farrell & Housley           Standards Track                    [Page 31]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   Implementers MUST ensure that following validation of an AC, only
+   attributes that the issuer is trusted to issue are used in
+   authorization decisions.  Other attributes, which MAY be present MUST
+   be ignored.  Given that the AA controls PKC extension is optional to
+   implement, AC verifiers MUST be provided with this information by
+   other means.  Configuration information is a likely alternative
+   means.  This becomes very important if an AC verifier trusts more
+   than one AC issuer.
+
+   There is often a requirement to map between the authentication
+   supplied by a particular security protocol (e.g. TLS, S/MIME) and the
+   AC holder's identity.  If the authentication uses PKCs, then this
+   mapping is straightforward.  However, it is envisaged that ACs will
+   also be used in environments where the holder may be authenticated
+   using other means.  Implementers SHOULD be very careful in mapping
+   the authenticated identity to the AC holder.
+
+9. IANA Considerations
+
+   Attributes and attribute certificate extensions are identified by
+   object identifiers (OIDs).  Many of the OIDs used in this document
+   are copied from X.509 [X.509-2000].  Other OIDs were assigned from an
+   arc delegated by the IANA.  No further action by the IANA is
+   necessary for this document or any anticipated updates.
+
+10. References
+
+   [CMC]        Myers, M., Liu, X., Schaad, J. and J. Weinstein,
+                "Certificate Management Messages over CMS", RFC 2797,
+                April 2000.
+
+   [CMP]        Adams, C. and S. Farrell, "Internet X.509 Public Key
+                Infrastructure - Certificate Management Protocols", RFC
+                2510, March 1999.
+
+   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
+                June 1999.
+
+   [ESS]        Hoffman, P., "Enhanced Security Services for S/MIME",
+                RFC 2634, June 1999.
+
+   [KRB]        Kohl, J. and C. Neuman, "The Kerberos Network
+                Authentication Service (V5)", RFC 1510, September 1993.
+
+   [LDAP]       Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+                Access Protocol (v3)", RFC 2251, December 1997.
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 32]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   [OCSP]       Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
+                Adams, "X.509 Internet Public Key Infrastructure -
+                Online Certificate Status Protocol - OCSP", RFC 2560,
+                June 1999.
+
+   [PKIXALGS]   Bassham, L., Polk, W. and R. Housley, "Algorithms and
+                Identifiers for the Internet X.509 Public Key
+                Infrastructure Certificate and Certificate Revocation
+                Lists CRL Profile", RFC 3279, April 2002.
+
+   [PKIXPROF]   Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
+                X.509 Public Key Infrastructure Certificate and
+                Certificate Revocation List (CRL) Profile", RFC 3280,
+                April 2002.
+
+   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
+                3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [URL]        Berners-Lee, T., Masinter L. and M. McCahill, "Uniform
+                Resource Locators (URL)", RFC 1738, December 1994.
+
+   [X.208-1988] CCITT Recommendation X.208: Specification of Abstract
+                Syntax Notation One (ASN.1). 1988.
+
+   [X.209-88]   CCITT Recommendation X.209: Specification of Basic
+                Encoding Rules for Abstract Syntax Notation One (ASN.1).
+                1988.
+
+   [X.501-88]   CCITT Recommendation X.501: The Directory - Models.
+                1988.
+
+   [X.501-1993] ITU-T Recommendation X.501 : Information Technology -
+                Open Systems Interconnection - The Directory: Models,
+                1993.
+
+   [X.509-1988] CCITT Recommendation X.509: The Directory -
+                Authentication Framework.  1988.
+
+   [X.509-1997] ITU-T Recommendation X.509: The Directory -
+                Authentication Framework.  1997.
+
+   [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key
+                and Attribute Certificate Frameworks.  2000
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 33]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+Appendix A: Object Identifiers
+
+   This (normative) appendix lists the new object identifiers which are
+   defined in this specification.  Some of these are required only for
+   support of optional features and are not required for conformance to
+   this profile.  This specification mandates support for OIDs which
+   have arc elements with values that are less than 2^32, (i.e. they
+   MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
+   than 2^31 (i.e. less than or equal to 2,147,483,647).  This allows
+   each arc element to be represented within a single 32 bit word.
+   Implementations MUST also support OIDs where the length of the dotted
+   decimal (see [LDAP], section 4.1.2) string representation can be up
+   to 100 bytes (inclusive).  Implementations MUST be able to handle
+   OIDs with up to 20 elements (inclusive).  AA's SHOULD NOT issue ACs
+   which contain OIDs that breach these requirements.
+
+   The following OIDs are imported from [PKIXPROF]:
+
+      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+      id-mod  OBJECT IDENTIFIER ::= { id-pkix 0 }
+      id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
+      id-ad   OBJECT IDENTIFIER ::= { id-pkix 48 }
+      id-at   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
+      id-ce   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
+
+   The following new ASN.1 module OID is defined:
+
+      id-mod-attribute-cert        OBJECT IDENTIFIER ::= { id-mod 12 }
+
+   The following AC extension OIDs are defined:
+
+      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
+      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
+      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }
+
+   The following PKC extension OIDs are defined:
+
+      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 34]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+   The following attribute OIDs are defined:
+
+      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
+      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
+      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
+      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
+      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
+      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
+      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72 }
+      id-at-clearance              OBJECT IDENTIFIER ::=
+                  { joint-iso-ccitt(2) ds(5) module(1)
+                    selected-attribute-types(5) clearance (55) }
+
+Appendix B: ASN.1 Module
+
+   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
+                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                id-mod-attribute-cert(12)}
+
+      DEFINITIONS IMPLICIT TAGS ::=
+
+      BEGIN
+
+      -- EXPORTS ALL --
+
+      IMPORTS
+
+            -- IMPORTed module OIDs MAY change if [PKIXPROF] changes
+            -- PKIX Certificate Extensions
+               Attribute, AlgorithmIdentifier, CertificateSerialNumber,
+               Extensions, UniqueIdentifier,
+               id-pkix, id-pe, id-kp, id-ad, id-at
+               FROM PKIX1Explicit88 {iso(1) identified-organization(3)
+                        dod(6) internet(1) security(5) mechanisms(5)
+                        pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
+
+               GeneralName, GeneralNames, id-ce
+               FROM PKIX1Implicit88 {iso(1) identified-organization(3)
+                        dod(6) internet(1) security(5) mechanisms(5)
+                        pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
+
+      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
+      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
+      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
+      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }
+
+      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 35]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
+      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
+      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
+      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
+      -- { id-aca 5 } is reserved
+      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
+
+      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72}
+      id-at-clearance              OBJECT IDENTIFIER ::=
+                  { joint-iso-ccitt(2) ds(5) module(1)
+                    selected-attribute-types(5) clearance (55) }
+
+             -- Uncomment this if using a 1988 level ASN.1 compiler
+             -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
+
+             AttributeCertificate ::= SEQUENCE {
+                   acinfo               AttributeCertificateInfo,
+                   signatureAlgorithm   AlgorithmIdentifier,
+                   signatureValue       BIT STRING
+             }
+
+             AttributeCertificateInfo ::= SEQUENCE {
+                version        AttCertVersion  -- version is v2,
+                holder         Holder,
+                issuer         AttCertIssuer,
+                signature      AlgorithmIdentifier,
+                serialNumber   CertificateSerialNumber,
+                attrCertValidityPeriod   AttCertValidityPeriod,
+                attributes     SEQUENCE OF Attribute,
+                issuerUniqueID UniqueIdentifier OPTIONAL,
+                extensions     Extensions     OPTIONAL
+             }
+
+             AttCertVersion ::= INTEGER { v2(1) }
+
+             Holder ::= SEQUENCE {
+                   baseCertificateID   [0] IssuerSerial OPTIONAL,
+                             -- the issuer and serial number of
+                             -- the holder's Public Key Certificate
+                   entityName          [1] GeneralNames OPTIONAL,
+                             -- the name of the claimant or role
+                   objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
+                             -- used to directly authenticate the
+                             -- holder, for example, an executable
+             }
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 36]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+             ObjectDigestInfo    ::= SEQUENCE {
+                   digestedObjectType  ENUMERATED {
+                        publicKey            (0),
+                        publicKeyCert        (1),
+                        otherObjectTypes     (2) },
+                                -- otherObjectTypes MUST NOT
+                                -- MUST NOT be used in this profile
+                   otherObjectTypeID   OBJECT IDENTIFIER  OPTIONAL,
+                   digestAlgorithm     AlgorithmIdentifier,
+                   objectDigest        BIT STRING
+             }
+
+             AttCertIssuer ::= CHOICE {
+                   v1Form   GeneralNames,  -- MUST NOT be used in this
+                                           -- profile
+                   v2Form   [0] V2Form     -- v2 only
+             }
+
+             V2Form ::= SEQUENCE {
+                   issuerName            GeneralNames  OPTIONAL,
+                   baseCertificateID     [0] IssuerSerial  OPTIONAL,
+                   objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
+                      -- issuerName MUST be present in this profile
+                      -- baseCertificateID and objectDigestInfo MUST
+                      -- NOT be present in this profile
+             }
+
+             IssuerSerial  ::=  SEQUENCE {
+                   issuer         GeneralNames,
+                   serial         CertificateSerialNumber,
+                   issuerUID      UniqueIdentifier OPTIONAL
+             }
+
+             AttCertValidityPeriod  ::= SEQUENCE {
+                   notBeforeTime  GeneralizedTime,
+                   notAfterTime   GeneralizedTime
+             }
+
+             Targets ::= SEQUENCE OF Target
+
+             Target  ::= CHOICE {
+                   targetName     [0] GeneralName,
+                   targetGroup    [1] GeneralName,
+                   targetCert     [2] TargetCert
+             }
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 37]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+             TargetCert  ::= SEQUENCE {
+                   targetCertificate  IssuerSerial,
+                   targetName         GeneralName OPTIONAL,
+                   certDigestInfo     ObjectDigestInfo OPTIONAL
+             }
+
+             IetfAttrSyntax ::= SEQUENCE {
+                  policyAuthority[0] GeneralNames    OPTIONAL,
+                  values         SEQUENCE OF CHOICE {
+                                 octets    OCTET STRING,
+                                 oid       OBJECT IDENTIFIER,
+                                 string    UTF8String
+                 }
+             }
+
+             SvceAuthInfo ::=    SEQUENCE {
+                   service       GeneralName,
+                   ident         GeneralName,
+                   authInfo      OCTET STRING OPTIONAL
+             }
+
+             RoleSyntax ::= SEQUENCE {
+                   roleAuthority  [0] GeneralNames OPTIONAL,
+                   roleName       [1] GeneralName
+             }
+
+             Clearance  ::=  SEQUENCE {
+                   policyId       [0] OBJECT IDENTIFIER,
+                   classList      [1] ClassList DEFAULT {unclassified},
+                   securityCategories
+                                  [2] SET OF SecurityCategory  OPTIONAL
+             }
+
+             ClassList  ::=  BIT STRING {
+                   unmarked       (0),
+                   unclassified   (1),
+                   restricted     (2),
+                   confidential   (3),
+                   secret         (4),
+                   topSecret      (5)
+             }
+
+             SecurityCategory ::= SEQUENCE {
+                   type      [0]  IMPLICIT OBJECT IDENTIFIER,
+                   value     [1]  ANY DEFINED BY type
+             }
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 38]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+             AAControls ::= SEQUENCE {
+                   pathLenConstraint INTEGER (0..MAX) OPTIONAL,
+                   permittedAttrs    [0] AttrSpec OPTIONAL,
+                   excludedAttrs     [1] AttrSpec OPTIONAL,
+                   permitUnSpecified BOOLEAN DEFAULT TRUE
+             }
+
+             AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
+
+             ACClearAttrs ::= SEQUENCE {
+                   acIssuer          GeneralName,
+                   acSerial          INTEGER,
+                   attrs             SEQUENCE OF Attribute
+             }
+
+             ProxyInfo ::= SEQUENCE OF Targets
+
+      END
+
+Author's Addresses
+
+   Stephen Farrell
+   Baltimore Technologies
+   39/41 Parkgate Street
+   Dublin 8
+   IRELAND
+
+   EMail: stephen.farrell@baltimore.ie
+
+   Russell Housley
+   RSA Laboratories
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail: rhousley@rsasecurity.com
+
+Acknowledgements
+
+   Russ Housley thanks the management at SPYRUS, who supported the
+   development of this specification while he was employed at SPYRUS.
+   Russ Housley also thanks the management at RSA Laboratories, who
+   supported the completion of the specification after a job change.
+
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 39]
+
+RFC 3281           An Internet Attribute Certificate          April 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell & Housley           Standards Track                    [Page 40]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3820.txt b/third_party/heimdal/doc/standardisation/rfc3820.txt
new file mode 100644
index 00000000000..f4e60737f1e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3820.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Network Working Group                                          S. Tuecke
+Request for Comments: 3820                                           ANL
+Category: Standards Track                                       V. Welch
+                                                                    NCSA
+                                                               D. Engert
+                                                                     ANL
+                                                             L. Pearlman
+                                                                 USC/ISI
+                                                             M. Thompson
+                                                                    LBNL
+                                                               June 2004
+
+
+            Internet X.509 Public Key Infrastructure (PKI)
+                       Proxy Certificate Profile
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document forms a certificate profile for Proxy Certificates,
+   based on X.509 Public Key Infrastructure (PKI) certificates as
+   defined in RFC 3280, for use in the Internet.  The term Proxy
+   Certificate is used to describe a certificate that is derived from,
+   and signed by, a normal X.509 Public Key End Entity Certificate or by
+   another Proxy Certificate for the purpose of providing restricted
+   proxying and delegation within a PKI based authentication system.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                     [Page 1]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Overview of Approach . . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  4
+       2.2.  Background . . . . . . . . . . . . . . . . . . . . . . .  5
+       2.3.  Motivation for Proxying. . . . . . . . . . . . . . . . .  5
+       2.4.  Motivation for Restricted Proxies. . . . . . . . . . . .  7
+       2.5.  Motivation for Unique Proxy Name . . . . . . . . . . . .  8
+       2.6.  Description Of Approach. . . . . . . . . . . . . . . . .  9
+       2.7.  Features Of This Approach. . . . . . . . . . . . . . . . 10
+   3.  Certificate and Certificate Extensions Profile . . . . . . . . 12
+       3.1.  Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
+       3.2.  Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
+       3.3.  Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
+       3.4.  Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
+       3.5.  Subject Alternative Name . . . . . . . . . . . . . . . . 13
+       3.6.  Key Usage and Extended Key Usage . . . . . . . . . . . . 13
+       3.7.  Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
+       3.8.  The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
+   4.  Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
+       4.1.  Basic Proxy Certificate Path Validation. . . . . . . . . 19
+       4.2.  Using the Path Validation Algorithm. . . . . . . . . . . 23
+   5.  Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+       5.1.  Relationship to Attribute Certificates . . . . . . . . . 24
+       5.2.  Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
+       5.3.  Examples of usage of Proxy Restrictions. . . . . . . . . 28
+       5.4.  Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
+   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 30
+       6.1.  Compromise of a Proxy Certificate. . . . . . . . . . . . 30
+       6.2.  Restricting Proxy Certificates . . . . . . . . . . . . . 31
+       6.3.  Relying Party Trust of Proxy Certificates. . . . . . . . 31
+       6.4.  Protecting Against Denial of Service with Key Generation 32
+       6.5.  Use of Proxy Certificates in a Central Repository. . . . 32
+   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
+       8.1.  Normative References . . . . . . . . . . . . . . . . . . 33
+       8.2.  Informative References . . . . . . . . . . . . . . . . . 33
+   9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
+   Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
+   Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37
+
+
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                     [Page 2]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+1.  Introduction
+
+   Use of a proxy credential [i7] is a common technique used in security
+   systems to allow entity A to grant to another entity B the right for
+   B to be authorized with others as if it were A.  In other words,
+   entity B is acting as a proxy on behalf of entity A.  This document
+   forms a certificate profile for Proxy Certificates, based on the RFC
+   3280, "Internet X.509 Public Key Infrastructure Certificate and CRL
+   Profile" [n2].
+
+   In addition to simple, unrestricted proxying, this profile defines:
+
+   *  A framework for carrying policies in Proxy Certificates that
+      allows proxying to be limited (perhaps completely disallowed)
+      through either restrictions or enumeration of rights.
+
+   *  Proxy Certificates with unique names, derived from the name of the
+      end entity certificate name.  This allows the Proxy Certificates
+      to be used in conjunction with attribute assertion approaches such
+      as Attribute Certificates [i3] and have their own rights
+      independent of their issuer.
+
+   Section 2 provides a non-normative overview of the approach.  It
+   begins by defining terminology, motivating Proxy Certificates, and
+   giving a brief overview of the approach.  It then introduces the
+   notion of a Proxy Issuer, as distinct from a Certificate Authority,
+   to describe how end entity signing of a Proxy Certificate is
+   different from end entity signing of another end entity certificate,
+   and therefore why this approach does not violate the end entity
+   signing restrictions contained in the X.509 keyCertSign field of the
+   keyUsage extension.  It then continues with discussions of how
+   subject names are used by this proxying approach, and features of
+   this approach.
+
+   Section 3 defines requirements on information content in Proxy
+   Certificates.  This profile addresses two fields in the basic
+   certificate as well as five certificate extensions.  The certificate
+   fields are the subject and issuer fields.  The certificate extensions
+   are subject alternative name, issuer alternative name, key usage,
+   basic constraints, and extended key usage.  A new certificate
+   extension, Proxy Certificate Information, is introduced.
+
+   Section 4 defines path validation rules for Proxy Certificates.
+
+   Section 5 provides non-normative commentary on Proxy Certificates.
+
+   Section 6 discusses security considerations relating to Proxy
+   Certificates.
+
+
+
+Tuecke, et al.              Standards Track                     [Page 3]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   References, listed in Section 8, are sorted into normative and
+   information references.  Normative references, listed in Section 8.1,
+   are in the form [nXX].  Informative references, listed in Section
+   8.2, are in the form [iXX].
+
+   Section 9 contains acknowledgements.
+
+   Following Section 9, contains the Appendix, the contact information
+   for the authors, the intellectual property information, and the
+   copyright information for 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 BCP 14, RFC 2119 [n1].
+
+2.  Overview of Approach
+
+   This section provides non-normative commentary on Proxy Certificates.
+
+   The goal of this specification is to develop a X.509 Proxy
+   Certificate profile and to facilitate their use within Internet
+   applications for those communities wishing to make use of restricted
+   proxying and delegation within an X.509 Public Key Infrastructure
+   (PKI) authentication based system.
+
+   This section provides relevant background, motivation, an overview of
+   the approach, and related work.
+
+2.1.  Terminology
+
+   This document uses the following terms:
+
+   *  CA: A "Certification Authority", as defined by X.509 [n2]
+
+   *  EEC: An "End Entity Certificate", as defined by X.509.  That is,
+      it is an X.509 Public Key Certificate issued to an end entity,
+      such as a user or a service, by a CA.
+
+   *  PKC: An end entity "Public Key Certificate".  This is synonymous
+      with an EEC.
+
+   *  PC: A "Proxy Certificate", the profile of which is defined by this
+      document.
+
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                     [Page 4]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   *  PI: A "Proxy Issuer" is an entity with an End Entity Certificate
+      or Proxy Certificate that issues a Proxy Certificate.  The Proxy
+      Certificate is signed using the private key associated with the
+      public key in the Proxy Issuer's certificate.
+
+   *  AC: An "Attribute Certificate", as defined by "An Internet
+      Attribute Certificate Profile for Authorization" [i3].
+
+   *  AA: An "Attribute Authority", as defined in [i3].
+
+2.2.  Background
+
+   Computational and Data "Grids" have emerged as a common approach to
+   constructing dynamic, inter-domain, distributed computing
+   environments.  As explained in [i5], large research and development
+   efforts starting around 1995 have focused on the question of what
+   protocols, services, and APIs are required for effective, coordinated
+   use of resources in these Grid environments.
+
+   In 1997, the Globus Project (www.globus.org) introduced the Grid
+   Security Infrastructure (GSI) [i4].  This library provides for public
+   key based authentication and message protection, based on standard
+   X.509 certificates and public key infrastructure, the SSL/TLS
+   protocol [i2], and delegation using proxy certificates similar to
+   those profiled in this document.  GSI has been used, in turn, to
+   build numerous middleware libraries and applications, which have been
+   deployed in large-scale production and experimental Grids [i1].  GSI
+   has emerged as the dominant security solution used by Grid efforts
+   worldwide.
+
+   This experience with GSI has proven the viability of restricted
+   proxying as a basis for authorization within Grids, and has further
+   proven the viability of using X.509 Proxy Certificates, as defined in
+   this document, as the basis for that proxying.  This document is one
+   part of an effort to migrate this experience with GSI into standards,
+   and in the process clean up the approach and better reconcile it with
+   existing and recent standards.
+
+2.3.  Motivation for Proxying
+
+   A motivating example will assist in understanding the role proxying
+   can play in building Internet based applications.
+
+   Steve is an engineer who wants to use a reliable file transfer
+   service to manage the movement of a number of large files around
+   between various hosts on his company's Intranet-based Grid.  From his
+   laptop he wants to submit a number of transfer requests to the
+   service and have the files transferred while he is doing other
+
+
+
+Tuecke, et al.              Standards Track                     [Page 5]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   things, including being offline.  The transfer service may queue the
+   requests for some time (e.g., until after hours or a period of low
+   resource usage) before initiating the transfers.  The transfer
+   service will then, for each file, connect to each of the source and
+   destination hosts, and instruct them to initiate a data connection
+   directly from the source to the destination in order to transfer the
+   file.  Steve will leave an agent running on his laptop that will
+   periodically check on progress of the transfer by contacting the
+   transfer service.  Of course, he wants all of this to happen securely
+   on his company's resources, which requires that he initiate all of
+   this using his PKI smartcard.
+
+   This scenario requires authentication and delegation in a variety of
+   places:
+
+   *  Steve needs to be able to mutually authenticate with the reliable
+      file transfer service to submit the transfer request.
+
+   *  Since the storage hosts know nothing about the file transfer
+      service, the file transfer service needs to be delegated the
+      rights to mutually authenticate with the various storage hosts
+      involved directly in the file transfer, in order to initiate the
+      file transfer.
+
+   *  The source and destination hosts of a particular transfer must be
+      able to mutual authenticate with each other, to ensure the file is
+      being transferred to and from the proper parties.
+
+   *  The agent running on Steve's laptop must mutually authenticate
+      with the file transfer service in order to check the result of the
+      transfers.
+
+   Proxying is a viable approach to solving two (related) problems in
+   this scenario:
+
+   *  Single sign-on: Steve wants to enter his smartcard password (or
+      pin) once, and then run a program that will submit all the file
+      transfer requests to the transfer service, and then periodically
+      check on the status of the transfer.  This program needs to be
+      given the rights to be able to perform all of these operations
+      securely, without requiring repeated access to the smartcard or
+      Steve's password.
+
+   *  Delegation: Various remote processes in this scenario need to
+      perform secure operations on Steve's behalf, and therefore must be
+      delegated the necessary rights.  For example, the file transfer
+
+
+
+
+
+Tuecke, et al.              Standards Track                     [Page 6]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+      service needs to be able to authenticate on Steve's behalf with
+      the source and destination hosts, and must in turn delegate rights
+      to those hosts so that they can authenticate with each other.
+
+   Proxying can be used to secure all of these interactions:
+
+   *  Proxying allows for the private key stored on the smartcard to be
+      accessed just once, in order to create the necessary proxy
+      credential, which allows the client/agent program to be authorized
+      as Steve when submitting the requests to the transfer service.
+      Access to the smartcard and Steve's password is not required after
+      the initial creation of the proxy credential.
+
+   *  The client program on the laptop can delegate to the file transfer
+      service the right to act on Steve's behalf.  This, in turn, allows
+      the service to authenticate to the storage hosts and inherit
+      Steve's privileges in order to start the file transfers.
+
+   *  When the transfer service authenticates to hosts to start the file
+      transfer, the service can delegate to the hosts the right to act
+      on Steve's behalf so that each pair of hosts involved in a file
+      transfer can mutually authenticate to ensure the file is securely
+      transferred.
+
+   *  When the agent on the laptop reconnects to the file transfer
+      service to check on the status of the transfer, it can perform
+      mutual authentication.  The laptop may use a newly generated proxy
+      credential, which is just created anew using the smartcard.
+
+   This scenario, and others similar to it, is being built today within
+   the Grid community.  The Grid Security Infrastructure's single sign-
+   on and delegation capabilities, built on X.509 Proxy Certificates,
+   are being employed to provide authentication services to these
+   applications.
+
+2.4.  Motivation for Restricted Proxies
+
+   One concern that arises is what happens if a machine that has been
+   delegated the right to inherit Steve's privileges has been
+   compromised?  For example, in the above scenario, what if the machine
+   running the file transfer service is compromised, such that the
+   attacker can gain access to the credential that Steve delegated to
+   that service?  Can the attacker now do everything that Steve is
+   allowed to do?
+
+   A solution to this problem is to allow for restrictions to be placed
+   on the proxy by means of policies on the proxy certificates. For
+   example, the machine running the reliable file transfer service in
+
+
+
+Tuecke, et al.              Standards Track                     [Page 7]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   the above example might only be given Steve's right for the purpose
+   of reading the source files and writing the destination files.
+   Therefore, if that file transfer service is compromised, the attacker
+   cannot modify source files, cannot create or modify other files to
+   which Steve has access, cannot start jobs on behalf of Steve, etc.
+   All that an attacker would be able to do is read the specific files
+   to which the file transfer service has been delegated read access,
+   and write bogus files in place of those that the file transfer
+   service has been delegated write access. Further, by limiting the
+   lifetime of the credential that is delegated to the file transfer
+   service, the effects of a compromise can be further mitigated.
+
+   Other potential uses for restricted proxy credentials are discussed
+   in [i7].
+
+2.5.  Motivation for Unique Proxy Name
+
+   The dynamic creation of entities (e.g., processes and services) is an
+   essential part of Grid computing.  These entities will require rights
+   in order to securely perform their function.  While it is possible to
+   obtain rights solely through proxying as described in previous
+   sections, this has limitations.  For example what if an entity should
+   have rights that are granted not just from the proxy issuer but from
+   a third party as well?  While it is possible in this case for the
+   entity to obtain and hold two proxy certifications, in practice it is
+   simpler for subsequent credentials to take the form of attribute
+   certificates.
+
+   It is also desirable for these entities to have a unique identity so
+   that they can be explicitly discussed in policy statements.  For
+   example, a user initiating a third-party FTP transfer could grant
+   each FTP server a PC with a unique identity and inform each server of
+   the identity of the other, then when the two servers connected they
+   could authenticate themselves and know they are connected to the
+   proper party.
+
+   In order for a party to have rights of it's own it requires a unique
+   identity.  Possible options for obtaining an unique identity are:
+
+   1) Obtain an identity from a traditional Certification Authority
+      (CA).
+
+   2) Obtain a new identity independently - for example by using the
+      generated public key and a self-signed certificate.
+
+   3) Derive the new identity from an existing identity.
+
+
+
+
+
+Tuecke, et al.              Standards Track                     [Page 8]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   In this document we describe an approach to option #3, because:
+
+      *  It is reasonably light-weight, as it can be done without
+         interacting with a third party.  This is important when
+         creating identities dynamically.
+
+      *  As described in the previous section, a common use for PCs is
+         for restricted proxying, so deriving their identity from the
+         identity of the EEC makes this straightforward.  Nonetheless
+         there are circumstances where the creator does not wish to
+         delegate all or any of its rights to a new entity.  Since the
+         name is unique, this is easily accomplished by #3 as well, by
+         allowing the application of a policy to limit proxying.
+
+2.6.  Description Of Approach
+
+   This document defines an X.509 "Proxy Certificate" or "PC" as a means
+   of providing for restricted proxying within an (extended) X.509 PKI
+   based authentication system.
+
+   A Proxy Certificate is an X.509 public key certificate with the
+   following properties:
+
+   1) It is signed by either an X.509 End Entity Certificate (EEC), or
+      by another PC.  This EEC or PC is referred to as the Proxy Issuer
+      (PI).
+
+   2) It can sign only another PC.  It cannot sign an EEC.
+
+   3) It has its own public and private key pair, distinct from any
+      other EEC or PC.
+
+   4) It has an identity derived from the identity of the EEC that
+      signed the PC.  When a PC is used for authentication, in may
+      inherit rights of the EEC that signed the PC, subject to the
+      restrictions that are placed on that PC by the EEC.
+
+   5) Although its identity is derived from the EEC's identity, it is
+      also unique.  This allows this identity to be used for
+      authorization as an independent identity from the identity of the
+      issuing EEC, for example in conjunction with attribute assertions
+      as defined in [i3].
+
+   6) It contains a new X.509 extension to identify it as a PC and to
+      place policies on the use of the PC.  This new extension, along
+      with other X.509 fields and extensions, are used to enable proper
+      path validation and use of the PC.
+
+
+
+
+Tuecke, et al.              Standards Track                     [Page 9]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   The process of creating a PC is as follows:
+
+   1) A new public and private key pair is generated.
+
+   2) That key pair is used to create a request for a Proxy Certificate
+      that conforms to the profile described in this document.
+
+   3) A Proxy Certificate, signed by the private key of the EEC or by
+      another PC, is created in response to the request.  During this
+      process, the PC request is verified to ensure that the requested
+      PC is valid (e.g., it is not an EEC, the PC fields are
+      appropriately set, etc).
+
+   When a PC is created as part of a delegation from entity A to entity
+   B, this process is modified by performing steps #1 and #2 within
+   entity B, then passing the PC request from entity B to entity A over
+   an authenticated, integrity checked channel, then entity A performs
+   step #3 and passes the PC back to entity B.
+
+   Path validation of a PC is very similar to normal path validation,
+   with a few additional checks to ensure, for example, proper PC
+   signing constraints.
+
+2.7.  Features Of This Approach
+
+   Using Proxy Certificates to perform delegation has several features
+   that make it attractive:
+
+   *  Ease of integration
+
+      o  Because a PC requires only a minimal change to path validation,
+         it is very easy to incorporate support for Proxy Certificates
+         into existing X.509 based software.  For example, SSL/TLS
+         requires no protocol changes to support authentication using a
+         PC.  Further, an SSL/TLS implementation requires only minor
+         changes to support PC path validation, and to retrieve the
+         authenticated subject of the signing EEC instead of the subject
+         of the PC for authorization purposes.
+
+      o  Many existing authorization systems use the X.509 subject name
+         as the basis for access control.  Proxy Certificates can be
+         used with such authorization systems without modification,
+         since such a PC inherits its name and rights from the EEC that
+         signed it and the EEC name can be used in place of the PC name
+         for authorization decisions.
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 10]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   *  Ease of use
+
+      o  Using PC for single sign-on helps make X.509 PKI authentication
+         easier to use, by allowing users to "login" once and then
+         perform various operations securely.
+
+      o  For many users, properly managing their own EEC private key is
+         a nuisance at best, and a security risk at worst.  One option
+         easily enabled with a PC is to manage the EEC private keys and
+         certificates in a centrally managed repository. When a user
+         needs a PKI credential, the user can login to the repository
+         using name/password, one time password, etc.  Then the
+         repository can delegate a PC to the user with proxy rights, but
+         continue to protect the EEC private key in the repository.
+
+   *  Protection of private keys
+
+      o  By using the remote delegation approach outlined above, entity
+         A can delegate a PC to entity B, without entity B ever seeing
+         the private key of entity A, and without entity A ever seeing
+         the private key of the newly delegated PC held by entity B.  In
+         other words, private keys never need to be shared or
+         communicated by the entities participating in a delegation of a
+         PC.
+
+      o  When implementing single sign-on, using a PC helps protect the
+         private key of the EEC, because it minimizes the exposure and
+         use of that private key.  For example, when an EEC private key
+         is password protected on disk, the password and unencrypted
+         private key need only be available during the creation of the
+         PC.  That PC can then be used for the remainder of its valid
+         lifetime, without requiring access to the EEC password or
+         private key.  Similarly, when the EEC private key lives on a
+         smartcard, the smartcard need only be present in the machine
+         during the creation of the PC.
+
+   *  Limiting consequences of a compromised key
+
+      o  When creating a PC, the PI can limit the validity period of the
+         PC, the depth of the PC path that can be created by that PC,
+         and key usage of the PC and its descendents.  Further, fine-
+         grained policies can be carried by a PC to even further
+         restrict the operations that can be performed using the PC.
+         These restrictions permit the PI to limit damage that could be
+         done by the bearer of the PC, either accidentally or
+         maliciously.
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 11]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+      o  A compromised PC private key does NOT compromise the EEC
+         private key.  This makes a short term, or an otherwise
+         restricted PC attractive for day-to-day use, since a
+         compromised PC does not require the user to go through the
+         usually cumbersome and time consuming process of having the EEC
+         with a new private key reissued by the CA.
+
+   See Section 5 below for more discussion on how Proxy Certificates
+   relate to Attribute Certificates.
+
+3.  Certificate and Certificate Extensions Profile
+
+   This section defines the usage of X.509 certificate fields and
+   extensions in Proxy Certificates, and defines one new extension for
+   Proxy Certificate Information.
+
+   All Proxy Certificates MUST include the Proxy Certificate Information
+   (ProxyCertInfo) extension defined in this section and the extension
+   MUST be critical.
+
+3.1.  Issuer
+
+   The Proxy Issuer of a Proxy Certificate MUST be either an End Entity
+   Certificate, or another Proxy Certificate.
+
+   The Proxy Issuer MUST NOT have an empty subject field.
+
+   The issuer field of a Proxy Certificate MUST contain the subject
+   field of its Proxy Issuer.
+
+   If the Proxy Issuer certificate has the KeyUsage extension, the
+   Digital Signature bit MUST be asserted.
+
+3.2.  Issuer Alternative Name
+
+   The issuerAltName extension MUST NOT be present in a Proxy
+   Certificate.
+
+3.3.  Serial Number
+
+   The serial number of a Proxy Certificate (PC) SHOULD be unique
+   amongst all Proxy Certificates issued by a particular Proxy Issuer.
+   However, a Proxy Issuer MAY use an approach to assigning serial
+   numbers that merely ensures a high probability of uniqueness.
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 12]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   For example, a Proxy Issuer MAY use a sequentially assigned integer
+   or a UUID to assign a unique serial number to a PC it issues.  Or a
+   Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a
+   serial number with a high probability of uniqueness.
+
+3.4.  Subject
+
+   The subject field of a Proxy Certificate MUST be the issuer field
+   (that is the subject of the Proxy Issuer) appended with a single
+   Common Name component.
+
+   The value of the Common Name SHOULD be unique to each Proxy
+   Certificate bearer amongst all Proxy Certificates with the same
+   issuer.
+
+   If a Proxy Issuer issues two proxy certificates to the same bearer,
+   the Proxy Issuer MAY choose to use the same Common Name for both.
+   Examples of this include Proxy Certificates for different uses (e.g.,
+   signing vs encryption) or the re-issuance of an expired Proxy
+   Certificate.
+
+   The Proxy Issuer MAY use an approach to assigning Common Name values
+   that merely ensures a high probability of uniqueness.  This value MAY
+   be the same value used for the serial number.
+
+   The result of this approach is that all subject names of Proxy
+   Certificates are derived from the name of the issuing EEC (it will be
+   the first part of the subject name appended with one or more CN
+   components) and are unique to each bearer.
+
+3.5.  Subject Alternative Name
+
+   The subjectAltName extension MUST NOT be present in a Proxy
+   Certificate.
+
+3.6.  Key Usage and Extended Key Usage
+
+   If the Proxy Issuer certificate has a Key Usage extension, the
+   Digital Signature bit MUST be asserted.
+
+   This document places no constraints on the presence or contents of
+   the key usage and extended key usage extension.  However, section 4.2
+   explains what functions should be allowed a proxy certificate by a
+   relying party.
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 13]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+3.7.  Basic Constraints
+
+   The cA field in the basic constraints extension MUST NOT be TRUE.
+
+3.8.  The ProxyCertInfo Extension
+
+   A new extension, ProxyCertInfo, is defined in this subsection.
+   Presence of the ProxyCertInfo extension indicates that a certificate
+   is a Proxy Certificate and whether or not the issuer of the
+   certificate has placed any restrictions on its use.
+
+   id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+            dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+   id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
+
+   id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
+
+   ProxyCertInfo ::= SEQUENCE {
+        pCPathLenConstraint   INTEGER (0..MAX) OPTIONAL,
+        proxyPolicy           ProxyPolicy }
+
+
+   ProxyPolicy ::= SEQUENCE {
+        policyLanguage        OBJECT IDENTIFIER,
+        policy          OCTET STRING OPTIONAL }
+
+   If a certificate is a Proxy Certificate, then the proxyCertInfo
+   extension MUST be present, and this extension MUST be marked as
+   critical.
+
+   If a certificate is not a Proxy Certificate, then the proxyCertInfo
+   extension MUST be absent.
+
+   The ProxyCertInfo extension consists of one required and two optional
+   fields, which are described in detail in the following subsections.
+
+3.8.1.  pCPathLenConstraint
+
+   The pCPathLenConstraint field, if present, specifies the maximum
+   depth of the path of Proxy Certificates that can be signed by this
+   Proxy Certificate.  A pCPathLenConstraint of 0 means that this
+   certificate MUST NOT be used to sign a Proxy Certificate.  If the
+   pCPathLenConstraint field is not present then the maximum proxy path
+   length is unlimited.  End entity certificates have unlimited maximum
+   proxy path lengths.
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 14]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+3.8.2.  proxyPolicy
+
+   The proxyPolicy field specifies a policy on the use of this
+   certificate for the purposes of authorization.  Within the
+   proxyPolicy, the policy field is an expression of policy, and the
+   policyLanguage field indicates the language in which the policy is
+   expressed.
+
+   The proxyPolicy field in the proxyCertInfo extension does not define
+   a policy language to be used for proxy restrictions; rather, it
+   places the burden on those parties using that extension to define an
+   appropriate language, and to acquire an OID for that language (or to
+   select an appropriate previously-defined language/OID).  Because it
+   is essential for the PI that issues a certificate with a proxyPolicy
+   field and the relying party that interprets that field to agree on
+   its meaning, the policy language OID must correspond to a policy
+   language (including semantics), not just a policy grammar.
+
+   The policyLanguage field has two values of special importance,
+   defined in Appendix A, that MUST be understood by all parties
+   accepting Proxy Certificates:
+
+   *  id-ppl-inheritAll indicates that this is an unrestricted proxy
+      that inherits all rights from the issuing PI.  An unrestricted
+      proxy is a statement that the Proxy Issuer wishes to delegate all
+      of its authority to the bearer (i.e., to anyone who has that proxy
+      certificate and can prove possession of the associated private
+      key).  For purposes of authorization, this an unrestricted proxy
+      effectively impersonates the issuing PI.
+
+   *  id-ppl-independent indicates that this is an independent proxy
+      that inherits no rights from the issuing PI.  This PC MUST be
+      treated as an independent identity by relying parties.  The only
+      rights this PC has are those granted explicitly to it.
+
+   For either of the policyLanguage values listed above, the policy
+   field MUST NOT be present.
+
+   Other values for the policyLanguage field indicates that this is a
+   restricted proxy certification and have some other policy limiting
+   its ability to do proxying.  In this case the policy field MAY be
+   present and it MUST contain information expressing the policy.  If
+   the policy field is not present the policy MUST be implicit in the
+   value of the policyLanguage field itself.  Authors of additional
+   policy languages are encouraged to publicly document their policy
+   language and list it in the IANA registry (see Section 7).
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 15]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   Proxy policies are used to limit the amount of authority delegated,
+   for example to assert that the proxy certificate may be used only to
+   make requests to a specific server, or only to authorize specific
+   operations on specific resources.  This document is agnostic to the
+   policies that can be placed in the policy field.
+
+   Proxy policies impose additional requirements on the relying party,
+   because only the relying party is in a position to ensure that those
+   policies are enforced.  When making an authorization decision based
+   on a proxy certificate based on rights that proxy certificate
+   inherited from its issuer, it is the relying party's responsibility
+   to verify that the requested authority is compatible with all
+   policies in the PC's certificate path.  In other words, the relying
+   party MUST verify that the following three conditions are all met:
+
+   1) The relying party MUST know how to interpret the proxy policy and
+      the request is allowed under that policy.
+
+   2) If the Proxy Issuer is an EEC then the relying party's local
+      policies MUST authorize the request for the entity named in the
+      EEC.
+
+   3) If the Proxy Issuer is another PC, then one of the following MUST
+      be true:
+
+      a. The relying party's local policies authorize the Proxy Issuer
+         to perform the request.
+
+      b. The Proxy Issuer inherits the right to perform the request from
+         its issuer by means of its proxy policy.  This must be verified
+         by verifying these three conditions on the Proxy Issuer in a
+         recursive manner.
+
+   If these conditions are not met, the relying party MUST either deny
+   authorization, or ignore the PC and the whole certificate chain
+   including the EEC entirely when making its authorization decision
+   (i.e., make the same decision that it would have made had the PC and
+   it's certificate chain never been presented).
+
+   The relying party MAY impose additional restrictions as to which
+   proxy certificates it accepts.  For example, a relying party MAY
+   choose to reject all proxy certificates, or MAY choose to accept
+   proxy certificates only for certain operations, etc.
+
+   Note that since a proxy certificate has a unique identity it MAY also
+   have rights granted to it by means other than inheritance from it's
+   issuer via its proxy policy.  The rights granted to the bearer of a
+   PC are the union of the rights granted to the PC identity and the
+
+
+
+Tuecke, et al.              Standards Track                    [Page 16]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   inherited rights.  The inherited rights consist of the intersection
+   of the rights granted to the PI identity intersected with the proxy
+   policy in the PC.
+
+   For example, imagine that Steve is authorized to read and write files
+   A and B on a file server, and that he uses his EEC to create a PC
+   that includes the policy that it can be used only to read or write
+   files A and C.  Then a trusted attribute authority grants an
+   Attribute Certificate granting the PC the right to read file D. This
+   would make the rights of the PC equal to the union of the rights
+   granted to the PC identity (right to read file D) with the
+   intersection of the rights granted to Steve, the PI, (right to read
+   files A and B) with the policy in the PC (can only read files A and
+   C).  This would mean the PC would have the following rights:
+
+   *  Right to read file A: Steve has this right and he issued the PC
+      and his policy grants this right to the PC.
+
+   *  Right to read file D: This right is granted explicitly to the PC
+      by a trusted authority.
+
+   The PC would NOT have the following rights:
+
+   *  Right to read file B: Although Steve has this right, it is
+      excluded by his policy on the PC.
+
+   *  Right to read file C: Although Steve's policy grants this right,
+      he does not have this right himself.
+
+   In many cases, the relying party will not have enough information to
+   evaluate the above criteria at the time that the certificate path is
+   validated.  For example, if a certificate is used to authenticate a
+   connection to some server, that certificate is typically validated
+   during that authentication step, before any requests have been made
+   of the server.  In that case, the relying party MUST either have some
+   authorization mechanism in place that will check the proxy policies,
+   or reject any certificate that contains proxy policies (or that has a
+   parent certificate that contains proxy policies).
+
+4.  Proxy Certificate Path Validation
+
+   Proxy Certification path processing verifies the binding between the
+   proxy certificate distinguished name and proxy certificate public
+   key.  The binding is limited by constraints which are specified in
+   the certificates which comprise the path and inputs which are
+   specified by the relying party.
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 17]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   This section describes an algorithm for validating proxy
+   certification paths.  Conforming implementations of this
+   specification are not required to implement this algorithm, but MUST
+   provide functionality equivalent to the external behavior resulting
+   from this procedure.  Any algorithm may be used by a particular
+   implementation so long as it derives the correct result.
+
+   The algorithm presented in this section validates the proxy
+   certificate with respect to the current date and time.  A conformant
+   implementation MAY also support validation with respect to some point
+   in the past.  Note that mechanisms are not available for validating a
+   proxy certificate with respect to a time outside the certificate
+   validity period.
+
+   Valid paths begin with the end entity certificate (EEC) that has
+   already been validated by public key certificate validation
+   procedures in RFC 3280 [n2].  The algorithm requires the public key
+   of the EEC and the EEC's subject distinguished name.
+
+   To meet the goal of verifying the proxy certificate, the proxy
+   certificate path validation process verifies, among other things,
+   that a prospective certification path (a sequence of n certificates)
+   satisfies the following conditions:
+
+   (a) for all x in {1, ..., n-1}, the subject of certificate x is the
+       issuer of proxy certificate x+1 and the subject distinguished
+       name of certificate x+1 is a legal subject distinguished name to
+       have been issued by certificate x;
+
+   (b) certificate 1 is valid proxy certificate issued by the end entity
+       certificate whose information is given as input to the proxy
+       certificate path validation process;
+
+   (c) certificate n is the proxy certificate to be validated;
+
+   (d) for all x in {1, ..., n}, the certificate was valid at the time
+       in question; and
+
+   (e) for all certificates in the path with a pCPathLenConstraint
+       field, the number of certificates in the path following that
+       certificate does not exceed the length specified in that field.
+
+   At this point there is no mechanism defined for revoking proxy
+   certificates.
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 18]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+4.1.  Basic Proxy Certificate Path Validation
+
+   This section presents the algorithm in four basic steps to mirror the
+   description of public key certificate path validation in RFC 3280:
+   (1) initialization, (2) basic proxy certificate processing, (3)
+   preparation for the next proxy certificate, and (4) wrap-up. Steps
+   (1) and (4) are performed exactly once.  Step (2) is performed for
+   all proxy certificates in the path.  Step (3) is performed for all
+   proxy certificates in the path except the final proxy certificate.
+
+   Certificate path validation as described in RFC 3280 MUST have been
+   done prior to using this algorithm to validate the end entity
+   certificate.  This algorithm then processes the proxy certificate
+   chain using the end entity certificate information produced by RFC
+   3280 path validation.
+
+4.1.1.  Inputs
+
+   This algorithm assumes the following inputs are provided to the path
+   processing logic:
+
+   (a) information about the entity certificate already verified using
+       RFC 3280 path validation.  This information includes:
+
+      (1) the end entity name,
+
+      (2) the working_public_key output from RFC 3280 path validation,
+
+      (3) the working_public_key_algorithm output from RFC 3280,
+
+      (4) and the working_public_key_parameters output from RFC 3280
+          path validation.
+
+   (b) prospective proxy certificate path of length n.
+
+   (c) acceptable-pc-policy-language-set: A set of proxy certificate
+       policy languages understood by the policy evaluation code.  The
+       acceptable-pc-policy-language-set MAY contain the special value
+       id-ppl-anyLanguage (as defined in Appendix A) if the path
+       validation code should not check the proxy certificate policy
+       languages (typically because the set of known policy languages is
+       not known yet and will be checked later in the authorization
+       process).
+
+   (d) the current date and time.
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 19]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+4.1.2.  Initialization
+
+   This initialization phase establishes the following state variables
+   based upon the inputs:
+
+   (a) working_public_key_algorithm: the digital signature algorithm
+       used to verify the signature of a proxy certificate. The
+       working_public_key_algorithm is initialized from the input
+       information provided from RFC 3280 path validation.
+
+   (b) working_public_key: the public key used to verify the signature
+       of a proxy certificate.  The working_public_key is initialized
+       from the input information provided from RFC 3280 path
+       validation.
+
+   (c) working_public_key_parameters: parameters associated with the
+       current public key, that may be required to verify a signature
+       (depending upon the algorithm).  The
+       proxy_issuer_public_key_parameters variable is initialized from
+       the input information provided from RFC 3280 path validation.
+
+   (d) working_issuer_name: the issuer distinguished name expected in
+       the next proxy certificate in the chain.  The working_issuer_name
+       is initialized to the distinguished name in the end entity
+       certificate validated by RFC 3280 path validation.
+
+   (e) max_path_length: this integer is initialized to n, is decremented
+       for each proxy certificate in the path.  This value may also be
+       reduced by the pcPathLenConstraint value of any proxy certificate
+       in the chain.
+
+   (f) proxy_policy_list: this list is empty to start and will be filled
+       in with the key usage extensions, extended key usage extensions
+       and proxy policies in the chain.
+
+   Upon completion of the initialization steps, perform the basic
+   certificate processing steps specified in 4.1.3.
+
+4.1.3.  Basic Proxy Certificate Processing
+
+   The basic path processing actions to be performed for proxy
+   certificate i (for all i in [1..n]) are listed below.
+
+   (a) Verify the basic certificate information.  The certificate MUST
+       satisfy each of the following:
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 20]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+      (1) The certificate was signed with the
+          working_public_key_algorithm using the working_public_key and
+          the working_public_key_parameters.
+
+      (2) The certificate validity period includes the current time.
+
+      (3) The certificate issuer name is the working_issuer_name.
+
+      (4) The certificate subject name is the working_issuer_name with a
+          CN component appended.
+
+   (b) The proxy certificate MUST have a ProxyCertInfo extension.
+       Process the extension as follows:
+
+      (1) If the pCPathLenConstraint field is present in the
+          ProxyCertInfo field and the value it contains is less than
+          max_path_length, set max_path_length to its value.
+
+      (2) If acceptable-pc-policy-language-set is not id-ppl-
+          anyLanguage, the OID in the policyLanguage field MUST be
+          present in acceptable-pc-policy-language-set.
+
+   (c) The tuple containing the certificate subject name, policyPolicy,
+       key usage extension (if present) and extended key usage extension
+       (if present) must be appended to proxy_policy_list.
+
+   (d) Process other certificate extensions, as described in [n2]:
+
+      (1) Recognize and process any other critical extensions present in
+          the proxy certificate.
+
+      (2) Process any recognized non-critical extension present in the
+          proxy certificate.
+
+   If either step (a), (b) or (d) fails, the procedure terminates,
+   returning a failure indication and an appropriate reason.
+
+   If i is not equal to n, continue by performing the preparatory steps
+   listed in 4.1.4.  If i is equal to n, perform the wrap-up steps
+   listed in 4.1.5.
+
+4.1.4.  Preparation for next Proxy Certificate
+
+   (a) Verify max_path_length is greater than zero and decrement
+       max_path_length.
+
+   (b) Assign the certificate subject name to working_issuer_name.
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 21]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   (c) Assign the certificate subjectPublicKey to working_public_key.
+
+   (d) If the subjectPublicKeyInfo field of the certificate contains an
+       algorithm field with non-null parameters, assign the parameters
+       to the working_public_key_parameters variable.
+
+       If the subjectPublicKeyInfo field of the certificate contains an
+       algorithm field with null parameters or parameters are omitted,
+       compare the certificate subjectPublicKey algorithm to the
+       working_public_key_algorithm.  If the certificate
+       subjectPublicKey algorithm and the working_public_key_algorithm
+       are different, set the working_public_key_parameters to null.
+
+   (e) Assign the certificate subjectPublicKey algorithm to the
+       working_public_key_algorithm variable.
+
+   (f) If a key usage extension is present, verify that the
+       digitalSignature bit is set.
+
+   If either check (a) or (f) fails, the procedure terminates, returning
+   a failure indication and an appropriate reason.
+
+   If (a) and (f) complete successfully, increment i and perform the
+   basic certificate processing specified in 4.1.3.
+
+4.1.5.  Wrap-up Procedures
+
+   (a) Assign the certificate subject name to working_issuer_name.
+
+   (b) Assign the certificate subjectPublicKey to working_public_key.
+
+   (c) If the subjectPublicKeyInfo field of the certificate contains an
+       algorithm field with non-null parameters, assign the parameters
+       to the proxy_issuer_public_key_parameters variable.
+
+       If the subjectPublicKeyInfo field of the certificate contains an
+       algorithm field with null parameters or parameters are omitted,
+       compare the certificate subjectPublicKey algorithm to the
+       proxy_issuer_public_key_algorithm.  If the certificate
+       subjectPublicKey algorithm and the
+       proxy_issuer_public_key_algorithm are different, set the
+       proxy_issuer_public_key_parameters to null.
+
+   (d) Assign the certificate subjectPublicKey algorithm to the
+       proxy_issuer_public_key_algorithm variable.
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 22]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+4.1.6.  Outputs
+
+   If path processing succeeds, the procedure terminates, returning a
+   success indication together with final value of the
+   working_public_key, the working_public_key_algorithm, the
+   working_public_key_parameters, and the proxy_policy_list.
+
+4.2.  Using the Path Validation Algorithm
+
+   Each Proxy Certificate contains a ProxyCertInfo extension, which
+   always contains a policy language OID, and may also contain a policy
+   OCTET STRING.  These policies serve to indicate the desire of each
+   issuer in the proxy certificate chain, starting with the EEC, to
+   delegate some subset of their rights to the issued proxy certificate.
+   This chain of policies is returned by the algorithm to the
+   application.
+
+   The application MAY make authorization decisions based on the subject
+   distinguished name of the proxy certificate or on one of the proxy
+   certificates in it's issuing chain or on the EEC that serves as the
+   root of the chain.  If an application chooses to use the subject
+   distinguished name of a proxy certificate in the issuing chain or the
+   EEC it MUST use the returned policies to restrict the rights it
+   grants to the proxy certificate.  If the application does not know
+   how to parse any policy in the policy chain it MUST not use, for the
+   purposes of making authorization decisions, the subject distinguished
+   name of any certificate in the chain prior to the certificate in
+   which the unrecognized policy appears.
+
+   Application making authorization decisions based on the contents of
+   the proxy certificate key usage or extended key usage extensions MUST
+   examine the list of key usage, extended key usage and proxy policies
+   resulting from proxy certificate path validation and determine the
+   effective key usage functions of the proxy certificate as follows:
+
+   *  If a certificate is a proxy certificate with a proxy policy of
+      id-ppl-independent or an end entity certificate, the effective key
+      usage functions of that certificate is as defined by the key usage
+      and extended key usage extensions in that certificate.  The key
+      usage functionality of the issuer has no bearing on the effective
+      key usage functionality.
+
+   *  If a certificate is a proxy certificate with a policy other than
+      id-ppl-independent, the effective key usage and extended key usage
+      functionality of the proxy certificate is the intersection of the
+      functionality of those extensions in the proxy certificate and the
+      effective key usage functionality of the proxy issuer.
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 23]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+5.  Commentary
+
+   This section provides non-normative commentary on Proxy Certificates.
+
+5.1.  Relationship to Attribute Certificates
+
+   An Attribute Certificate [i3] can be used to grant to one identity,
+   the holder, some attribute such as a role, clearance level, or
+   alternative identity such as "charging identity" or "audit identity".
+   This is accomplished by way of a trusted Attribute Authority (AA),
+   which issues signed Attribute Certificates (AC), each of which binds
+   an identity to a particular set of attributes. Authorization
+   decisions can then be made by combining information from the
+   authenticated End Entity Certificate providing the identity, with the
+   signed Attribute Certificates providing binding of that identity to
+   attributes.
+
+   There is clearly some overlap between the capabilities provided by
+   Proxy Certificates and Attribute Certificates.  However, the
+   combination of the two approaches together provides a broader
+   spectrum of solutions to authorization in X.509 based systems, than
+   either solution alone.  This section seeks to clarify some of the
+   overlaps, differences, and synergies between Proxy Certificate and
+   Attribute Certificates.
+
+5.1.1.  Types of Attribute Authorities
+
+   For the purposes of this discussion, Attribute Authorities, and the
+   uses of the Attribute Certificates that they produce, can be broken
+   down into two broad classes:
+
+   1) End entity AA: An End Entity Certificate may be used to sign an
+      AC.  This can be used, for example, to allow an end entity to
+      delegate some of its privileges to another entity.
+
+   2) Third party AA: A separate entity, aside from the end entity
+      involved in an authenticated interaction, may sign ACs in order to
+      bind the authenticated identity with additional attributes, such
+      as role, group, etc.  For example, when a client authenticates
+      with a server, the third party AA may provide an AC that binds the
+      client identity to a particular group, which the server then uses
+      for authorization purposes.
+
+   This second type of Attribute Authority, the third party AA, works
+   equally well with an EEC or a PC.  For example, unrestricted Proxy
+   Certificates can be used to delegate the EEC's identity to various
+   other parties.  Then when one of those other parties uses the PC to
+   authenticate with a service, that service will receive the EEC's
+
+
+
+Tuecke, et al.              Standards Track                    [Page 24]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   identity via the PC, and can apply any ACs that bind that identity to
+   attributes in order to determine authorization rights. Additionally
+   PC with policies could be used to selectively deny the binding of ACs
+   to a particular proxy.  An AC could also be bound to a particular PC
+   using the subject or issuer and serial number of the proxy
+   certificate.  There would appear to be great synergies between the
+   use of Proxy Certificates and Attribute Certificates produced by
+   third party Attribute Authorities.
+
+   However, the uses of Attribute Certificates that are granted by the
+   first type of Attribute Authority, the end entity AA, overlap
+   considerably with the uses of Proxy Certificates as described in the
+   previous sections.  Such Attribute Certificates are generally used
+   for delegation of rights from one end entity to others, which clearly
+   overlaps with the stated purpose of Proxy Certificates, namely single
+   sign-on and delegation.
+
+5.1.2.  Delegation Using Attribute Certificates
+
+   In the motivating example in Section 2, PCs are used to delegate
+   Steve's identity to the various other jobs and entities that need to
+   act on Steve's behalf.  This allows those other entities to
+   authenticate as if they were Steve, for example to the mass storage
+   system.
+
+   A solution to this example could also be cast using Attribute
+   Certificates that are signed by Steve's EEC, which grant to the other
+   entities in this example the right to perform various operations on
+   Steve's behalf.  In this example, the reliable file transfer service
+   and all the hosts involved in file transfers, the starter program,
+   the agent, the simulation jobs, and the post-processing job would
+   each have their own EECs.  Steve's EEC would therefore issue ACs to
+   bind each of those other EEC identities to attributes that grant the
+   necessary privileges allow them to, for example, access the mass
+   storage system.
+
+   However, this AC based solution to delegation has some disadvantages
+   as compared to the PC based solution:
+
+   *  All protocols, authentication code, and identity based
+      authorization services must be modified to understand ACs.  With
+      the PC solution, protocols (e.g., TLS) likely need no
+      modification, authentication code needs minimal modification
+      (e.g., to perform PC aware path validation), and identity based
+      authorization services need minimal modification (e.g., possibly
+      to find the EEC name and to check for any proxy policies).
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 25]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   *  ACs need to be created by Steve's EEC, which bind attributes to
+      each of the other identities involved in the distributed
+      application (i.e., the agent, simulation jobs, and post-processing
+      job the file transfer service, the hosts transferring files).
+      This implies that Steve must know in advance which other
+      identities may be involved in this distributed application, in
+      order to generate the appropriate ACs which are signed by Steve's
+      ECC.  On the other hand, the PC solution allows for much more
+      flexibility, since parties can further delegate a PC without a
+      priori knowledge by the originating EEC.
+
+   There are many unexplored tradeoffs and implications in this
+   discussion of delegation.  However, reasonable arguments can be made
+   in favor of either an AC based solution to delegation or a PC based
+   solution to delegation.  The choice of which approach should be taken
+   in a given instance may depend on factors such as the software that
+   it needs to be integrated into, the type of delegation required, and
+   other factors.
+
+5.1.3.  Propagation of Authorization Information
+
+   One possible use of Proxy Certificates is to carry authorization
+   information associated with a particular identity.
+
+   The merits of placing authorization information into End Entity
+   Certificates (also called a Public Key Certificate or PKC) have been
+   widely debated.  For example, Section 1 of "An Internet Attribute
+   Certificate Profile for Authorization" [i3] states:
+
+      "Authorization information may be placed in a PKC extension or
+      placed in a separate attribute certificate (AC).  The placement of
+      authorization information in PKCs is usually undesirable for two
+      reasons.  First, authorization information often does not have the
+      same lifetime as the binding of the identity and the public key.
+      When authorization information is placed in a PKC extension, the
+      general result is the shortening of the PKC useful lifetime.
+      Second, the PKC issuer is not usually authoritative for the
+      authorization information.  This results in additional steps for
+      the PKC issuer to obtain authorization information from the
+      authoritative source.
+
+      For these reasons, it is often better to separate authorization
+      information from the PKC.  Yet, authorization information also
+      needs to be bound to an identity.  An AC provides this binding; it
+      is simply a digitally signed (or certified) identity and set of
+      attributes."
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 26]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   Placing authorization information in a PC mitigates the first
+   undesirable property cited above.  Since a PC has a lifetime that is
+   mostly independent of (always shorter than) its signing EEC, a PC
+   becomes a viable approach for carrying authorization information for
+   the purpose of delegation.
+
+   The second undesirable property cited above is true.  If a third
+   party AA is authoritative, then using ACs issued by that third party
+   AA is a natural approach to disseminating authorization information.
+   However, this is true whether the identity being bound by these ACs
+   comes from an EEC (PKC), or from a PC.
+
+   There is one case, however, that the above text does not consider.
+   When performing delegation, it is usually the EEC itself that is
+   authoritative (not the EEC issuer, or any third party AA).  That is,
+   it is up to the EEC to decide what authorization rights it is willing
+   to grant to another party.  In this situation, including such
+   authorization information into PCs that are generated by the EEC
+   seems a reasonable approach to disseminating such information.
+
+5.1.4.  Proxy Certificate as Attribute Certificate Holder
+
+   In a system that employs both PCs and ACs, one can imagine the
+   utility of allowing a PC to be the holder of an AC.  This would allow
+   for a particular delegated instance of an identity to be given an
+   attribute, rather than all delegated instances of that identity being
+   given the attribute.
+
+   However, the issue of how to specify a PC as the holder of an AC
+   remains open.  An AC could be bound to a particular instance of a PC
+   using the unique subject name of the PC, or it's issuer and serial
+   number combination.
+
+   Unrestricted PCs issued by that PC would then inherit those ACs and
+   independent PCs would not.  PCs issued with a policy would depend on
+   the policy as to whether or not they inherit the issuing PC's ACs
+   (and potentially which ACs they inherit).
+
+   While an AC can be bound to one PC by the AA, how can the AA restrict
+   that PC from passing it on to a subsequently delegated PC? One
+   possible solution would be to define an extension to attribute
+   certificates that allows the attribute authority to state whether an
+   issued AC is to apply only to the particular entity to which it is
+   bound, or if it may apply to PCs issued by that entity.
+
+   One issue that an AA in this circumstance would need to be aware of
+   is that the PI of the PC that the AA bound the AC to, could issue
+   another PC with the same name as the original PC to a different
+
+
+
+Tuecke, et al.              Standards Track                    [Page 27]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   entity, effectively stealing the AC.  This implies that an AA issuing
+   an AC to a PC need to not only trust the entity holding the PC, but
+   the entity holding the PC's issuer as well.
+
+5.2.  Kerberos 5 Tickets
+
+   The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a
+   widely used authentication system based on conventional (shared
+   secret key) cryptography.  It provides support for single sign-on via
+   creation of "Ticket Granting Tickets" or "TGT", and support for
+   delegation of rights via "forwardable tickets".
+
+   Kerberos 5 tickets have informed many of the ideas surrounding X.509
+   Proxy Certificates.  For example, the local creation of a short-lived
+   PC can be used to provide single sign-on in an X.509 PKI based
+   system, just as creation of short-lived TGT allows for single sign-on
+   in a Kerberos based system.  And just as a TGT can be forwarded
+   (i.e., delegated) to another entity to allow for proxying in a
+   Kerberos based system, so can a PC can be delegated to allow for
+   proxying in an X.509 PKI based system.
+
+   A major difference between a Kerberos TGT and an X.509 PC is that
+   while creation and delegation of a TGT requires the involvement of a
+   third party (Key Distribution Center), a PC can be unilaterally
+   created without the active involvement of a third party.  That is, a
+   user can directly create a PC from an EEC for single sign-on
+   capability, without requiring communication with a third party.  And
+   an entity with a PC can delegate the PC to another entity (i.e., by
+   creating a new PC, signed by the first) without requiring
+   communication with a third party.
+
+   The method used by Kerberos implementations to protect a TGT can also
+   be used to protect the private key of a PC.  For example, some Unix
+   implementations of Kerberos use standard Unix file system security to
+   protect a user's TGT from compromise.  Similarly, the Globus
+   Toolkit's Grid Security Infrastructure implementation of Proxy
+   Certificates protects a user's PC private key using this same
+   approach.
+
+5.3.  Examples of usage of Proxy Restrictions
+
+   This section gives some examples of Proxy Certificate usage and some
+   examples of how the Proxy policy can be used to restrict Proxy
+   Certificates.
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 28]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+5.3.1.  Example use of proxies without Restrictions
+
+   Steve wishes to perform a third-party FTP transfer between two FTP
+   servers.  Steve would use an existing PC to authenticate to both
+   servers and delegate a PC to both hosts.  He would inform each host
+   of the unique subject name of the PC given to the other host.  When
+   the servers establish the data channel connection to each other, they
+   use these delegated credentials to perform authentication and verify
+   they are talking to the correct entity by checking the result of the
+   authentication matches the name as provided by Steve.
+
+5.3.2.  Example use of proxies with Restrictions
+
+   Steve wishes to delegate to a process the right to perform a transfer
+   of a file from host H1 to host H2 on his behalf.  Steve would
+   delegate a PC to the process and he would use Proxy Policy to
+   restrict the delegated PC to two rights - the right to read file F1
+   on host H1 and the right to write file F2 on host H2.
+
+   The process then uses this restricted PC to authenticate to servers
+   H1 and H2.  The process would also delegate a PC to both servers.
+   Note that these delegated PCs would inherit the restrictions of their
+   parents, though this is not relevant to this example.  As in the
+   example in the previous Section, each host would be provided with the
+   unique name of the PC given to the other server.
+
+   Now when the process issues the command to transfer the file F1 on H1
+   and to F2 on H2, these two servers perform an authorization check
+   based on the restrictions in the PC that the process used to
+   authenticate with them (in addition to any local policy they have).
+   Namely H1 checks that the PC gives the user the right to read F1 and
+   H2 checks that the PC gives the user the right to write F2. When
+   setting up the data channel the servers would again verify the names
+   resulting from the authentication match the names provided by Steve
+   as in the example in the previous Section.
+
+   The extra security provided by these restrictions is that now if the
+   PC delegated to the process by Steve is stolen, its use is greatly
+   limited.
+
+5.4.  Delegation Tracing
+
+   A relying party accepting a Proxy Certificate may have an interest in
+   knowing which parties issued earlier Proxy Certificates in the
+   certificate chain and to whom they delegated them.  For example it
+   may know that a particular service or resource is known to have been
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 29]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   compromised and if any part of a Proxy Certificate's chain was issued
+   to the compromised service a relying party may wish to disregard the
+   chain.
+
+   A delegation tracing mechanism was considered by the authors as
+   additional information to be carried in the ProxyCertInfo extension.
+   However at this time agreement has not been reached as to what this
+   information should include so it was left out of this document, and
+   will instead be considered in future revisions.  The debate mainly
+   centers on whether the tracing information should simply contain the
+   identity of the issuer and receiver or it should also contain all the
+   details of the delegated proxy and a signed statement from the
+   receiver that the proxy was actually acceptable to it.
+
+5.4.1.  Site Information in Delegation Tracing
+
+   In some cases, it may be desirable to know the hosts involved in a
+   delegation transaction (for example, a relying party may wish to
+   reject proxy certificates that were created on a specific host or
+   domain).  An extension could be modified to include the PA's and
+   Acceptor's IP addresses; however, IP addresses are typically easy to
+   spoof, and in some cases the two parties to a transaction may not
+   agree on the IP addresses being used (e.g., if the Acceptor is on a
+   host that uses NAT, the Acceptor and the PA may disagree about the
+   Acceptor's IP address).
+
+   Another suggestion was, in those cases where domain information is
+   needed, to require that the subject names of all End Entities
+   involved (the Acceptor(s) and the End Entity that appears in a PC's
+   certificate path) include domain information.
+
+6.  Security Considerations
+
+   In this Section we discuss security considerations related to the use
+   of Proxy Certificates.
+
+6.1.  Compromise of a Proxy Certificate
+
+   A Proxy Certificate is generally less secure than the EEC that issued
+   it.  This is due to the fact that the private key of a PC is
+   generally not protected as rigorously as that of the EEC.  For
+   example, the private key of a PC is often protected using only file
+   system security, in order to allow that PC to be used for single
+   sign-on purposes.  This makes the PC more susceptible to compromise.
+
+   However, the risk of a compromised PC is only the misuse of a single
+   user's privileges.  Due to the PC path validation checks, a PC cannot
+   be used to sign an EEC or PC for another user.
+
+
+
+Tuecke, et al.              Standards Track                    [Page 30]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   Further, a compromised PC can only be misused for the lifetime of the
+   PC, and within the bound of the restriction policy carried by the PC.
+   Therefore, one common way to limit the misuse of a compromised PC is
+   to limit its validity period to no longer than is needed, and/or to
+   include a restriction policy in the PC that limits the use of the
+   (compromised) PC.
+
+   In addition, if a PC is compromised, it does NOT compromise the EEC
+   that created the PC.  This property is of great utility in protecting
+   the highly valuable, and hard to replace, public key of the EEC.  In
+   other words, the use of Proxy Certificates to provide single sign-on
+   capabilities in an X.509 PKI environment can actually increase the
+   security of the end entity certificates, because creation and use of
+   the PCs for user authentication limits the exposure of the EEC
+   private key to only the creation of the first level PC.
+
+6.2.  Restricting Proxy Certificates
+
+   The pCPathLenConstraint field of the proxyCertInfo extension can be
+   used by an EEC to limit subsequent delegation of the PC.  A service
+   may choose to only authorize a request if a valid PC can be delegated
+   to it.  An example of such as service is a job starter, which may
+   choose to reject a job start request if a valid PC cannot be
+   delegated to it.  By limiting the pCPathLenConstraint, an EEC can
+   ensure that a compromised PC of one job cannot be used to start
+   additional jobs elsewhere.
+
+   An EEC or PC can limit what a new PC can be used for by turning off
+   bits in the Key Usage and Extended Key Usage extensions.  Once a key
+   usage or extended key usage has been removed, the path validation
+   algorithm ensures that it cannot be added back in a subsequent PC.
+   In other words, key usage can only be decreased in PC chains.
+
+   The EEC could use the CRL Distribution Points extension and/or OCSP
+   to take on the responsibility of revoking PCs that it had issued, if
+   it felt that they were being misused.
+
+6.3.  Relying Party Trust of Proxy Certificates
+
+   The relying party that is going to authorize some actions on the
+   basis of a PC will be aware that it has been presented with a PC, and
+   can determine the depth of the delegation and the time that the
+   delegation took place.  It may want to use this information in
+   addition to the information from the signing EEC.  Thus a highly
+   secure resource might refuse to accept a PC at all, or maybe only a
+   single level of delegation, etc.
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 31]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   The relying party should also be aware that since the policy
+   restricting the rights of a PC is the intersection of the policy of
+   all the PCs in it's certificate chain, this means any change in the
+   certificate chain can effect the policy of the PC.  Since there is no
+   mechanism in place to enforce unique subject names of PCs, if an
+   issuer were to issue two PCs with identical names and keys, but
+   different rights, this could allow the two PCs to be substituted for
+   each other in path validation and effect the rights of a PC down the
+   chain.  Ultimately, this means the relying party places trust in the
+   entities that are acting as Proxy Issuers in the chain to behave
+   properly.
+
+6.4.  Protecting Against Denial of Service with Key Generation
+
+   As discussed in Section 2.3, one of the motivations for Proxy
+   Certificates is to allow for dynamic delegation between parties. This
+   delegation potentially requires, by the party receiving the
+   delegation, the generation of a new key pair which is a potentially
+   computationally expensive operation.  Care should be taken by such
+   parties to prevent another entity from performing a denial of service
+   attack by causing them to consume large amount of resource doing key
+   generation.
+
+   A general guideline would always to perform authentication of the
+   delegating party to prevent such attacks from being performed
+   anonymously.  Another guideline would be to maintain some state to
+   detect and prevent such attacks.
+
+6.5.  Use of Proxy Certificates with a Central Repository
+
+   As discussed in Section 2.7, one potential use of Proxy Certificates
+   is to ease certificate management for end users by storing the EEC
+   private keys and certificates in a centrally managed repository.
+   When a user needs a PKI credential, the user can login to the
+   repository using name/password, one time password, etc. and the
+   repository would then delegate a PC to the user with proxy rights,
+   but continue to protect the EEC private key in the repository.
+
+   Care must be taken with this approach since compromise of the
+   repository will potentially give the attacker access to the long-term
+   private keys stored in the repository.  It is strongly suggested that
+   some form of hardware module be used to store the long-term private
+   keys, which will serve to help prevent their direct threat though it
+   may still allow a successful attacker to use the keys while the
+   repository is compromised to sign arbitrary objects (including Proxy
+   Certificates).
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 32]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+7.  IANA Considerations
+
+   IANA has established a registry for policy languages.  Registration
+   under IETF space is by IETF standards action as described in [i8].
+   Private policy languages should be under organizational OIDs; policy
+   language authors are encouraged to list such languages in the IANA
+   registry, along with a pointer to a specification.
+
+   OID                      Description
+   ---                      -----------
+   1.3.6.1.5.5.7.21.1       id-ppl-inheritALL
+   1.3.6.1.5.5.7.21.2       id-ppl-independent
+
+8.  References
+
+8.1.  Normative References
+
+   [n1]    Bradner, S., "Key words for use in RFCs to Indicate
+           Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [n2]    Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
+           Public Key Infrastructure Certificate and Certificate
+           Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+8.2.  Informative References
+
+   [i1]    Butler, R., Engert, D., Foster, I., Kesselman, C., and S.
+           Tuecke, "A National-Scale Authentication Infrastructure",
+           IEEE Computer, vol. 33, pp. 60-66, 2000.
+
+   [i2]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+           2246, January 1999.
+
+   [i3]    Farrell, S. and R. Housley, "An Internet Attribute
+           Certificate Profile for Authorization", RFC 3281, April 2002.
+
+   [i4]    Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A
+           Security Architecture for Computational Grids", presented at
+           Proceedings of the 5th ACM Conference on Computer and
+           Communications Security, 1998.
+
+   [i5]    Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the
+           Grid: Enabling Scalable Virtual Organizations", International
+           Journal of Supercomputer Applications, 2001.
+
+   [i6]    Kohl, J. and C. Neuman, "The Kerberos Network Authentication
+           Service (V5)", RFC 1510, September 1993.
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 33]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+   [i7]    Neuman, B. Clifford, "Proxy-Based Authorization and
+           Accounting for Distributed Systems", In Proceedings of the
+           13th International Conference on Distributed Computing
+           Systems, pages 283-291, May 1993.
+
+   [i8]    Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA
+           Considerations Section in RFC", RFC 2434, October 1998.
+
+9.  Acknowledgments
+
+   We are pleased to acknowledge significant contributions to this
+   document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman,
+   Sam Meder, Jim Schaad, and Frank Siebenlist.
+
+   We are grateful to numerous colleagues for discussions on the topics
+   covered in this paper, in particular (in alphabetical order, with
+   apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy
+   Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill
+   Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman,
+   Gene Tsudik.
+
+   We are also grateful to members of the Global Grid Forum (GGF) Grid
+   Security Infrastructure working group (GSI-WG), and the Internet
+   Engineering Task Force (IETF) Public-Key Infrastructure (X.509)
+   working group (PKIX) for feedback on this document.
+
+   This work was supported in part by the Mathematical, Information, and
+   Computational Sciences Division subprogram of the Office of Advanced
+   Scientific Computing Research, U.S. Department of Energy, under
+   Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense
+   Advanced Research Projects Agency under contract N66001-96-C-8523; by
+   the National Science Foundation; and by the NASA Information Power
+   Grid project.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 34]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+Appendix A. 1988 ASN.1 Module
+
+   PKIXproxy88 { iso(1) identified-organization(3) dod(6)
+       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+       proxy-cert-extns(25) }
+
+   DEFINITIONS EXPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL --
+
+   -- IMPORTS NONE --
+
+   -- PKIX specific OIDs
+
+   id-pkix OBJECT IDENTIFIER ::=
+           { iso(1) identified-organization(3)
+                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+   -- private certificate extensions
+   id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
+
+   -- Locally defined OIDs
+
+   -- The proxy certificate extension
+   id-pe-proxyCertInfo    OBJECT IDENTIFIER ::= { id-pe 14 }
+
+   -- Proxy certificate policy languages
+   id-ppl  OBJECT IDENTIFIER ::= { id-pkix 21 }
+
+   -- Proxy certificate policies languages defined in
+   id-ppl-anyLanguage     OBJECT IDENTIFIER ::= { id-ppl 0 }
+   id-ppl-inheritAll      OBJECT IDENTIFIER ::= { id-ppl 1 }
+   id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 }
+
+   -- The ProxyCertInfo Extension
+   ProxyCertInfoExtension  ::= SEQUENCE {
+         pCPathLenConstraint     ProxyCertPathLengthConstraint
+                                       OPTIONAL,
+         proxyPolicy             ProxyPolicy }
+
+   ProxyCertPathLengthConstraint  ::= INTEGER
+   ProxyPolicy  ::= SEQUENCE {
+         policyLanguage          OBJECT IDENTIFIER,
+         policy                  OCTET STRING OPTIONAL }
+
+   END
+
+
+
+Tuecke, et al.              Standards Track                    [Page 35]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+Authors' Addresses
+
+   Steven Tuecke
+   Distributed Systems Laboratory
+   Mathematics and Computer Science Division
+   Argonne National Laboratory
+   Argonne, IL 60439
+
+   Phone: 630-252-8711
+   EMail: tuecke@mcs.anl.gov
+
+
+   Von Welch
+   National Center for Supercomputing Applications
+   University of Illinois
+
+   EMail: vwelch@ncsa.uiuc.edu
+
+
+   Doug Engert
+   Argonne National Laboratory
+
+   EMail: deengert@anl.gov
+
+
+   Laura Pearlman
+   University of Southern California, Information Sciences Institute
+
+   EMail: laura@isi.edu
+
+
+   Mary Thompson
+   Lawrence Berkeley National Laboratory
+
+   EMail: mrthompson@lbl.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 36]
+
+RFC 3820            X.509 Proxy Certificate Profile            June 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Tuecke, et al.              Standards Track                    [Page 37]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3961.txt b/third_party/heimdal/doc/standardisation/rfc3961.txt
new file mode 100644
index 00000000000..0ac50b9590d
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3961.txt
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Network Working Group                                         K. Raeburn
+Request for Comments: 3961                                           MIT
+Category: Standards Track                                  February 2005
+
+
+                 Encryption and Checksum Specifications
+                             for Kerberos 5
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes a framework for defining encryption and
+   checksum mechanisms for use with the Kerberos protocol, defining an
+   abstraction layer between the Kerberos protocol and related
+   protocols, and the actual mechanisms themselves.  The document also
+   defines several mechanisms.  Some are taken from RFC 1510, modified
+   in form to fit this new framework and occasionally modified in
+   content when the old specification was incorrect.  New mechanisms are
+   presented here as well.  This document does NOT indicate which
+   mechanisms may be considered "required to implement".
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Encryption Algorithm Profile  . . . . . . . . . . . . . . . .  4
+   4.  Checksum Algorithm Profile  . . . . . . . . . . . . . . . . .  9
+   5.  Simplified Profile for CBC Ciphers with Key Derivation  . . . 10
+       5.1.  A Key Derivation Function . . . . . . . . . . . . . . . 10
+       5.2.  Simplified Profile Parameters . . . . . . . . . . . . . 12
+       5.3.  Cryptosystem Profile Based on Simplified Profile  . . . 13
+       5.4.  Checksum Profiles Based on Simplified Profile . . . . . 16
+   6.  Profiles for Kerberos Encryption and Checksum Algorithms  . . 16
+       6.1.  Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
+       6.2.  DES-based Encryption and Checksum Types . . . . . . . . 18
+       6.3.  Triple-DES Based Encryption and Checksum Types  . . . . 28
+   7.  Use of Kerberos Encryption Outside This Specification . . . . 30
+
+
+
+Raeburn                     Standards Track                     [Page 1]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   8.  Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . 31
+   9.  Implementation Notes  . . . . . . . . . . . . . . . . . . . . 32
+   10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
+   12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
+   A.  Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . 38
+       A.1.  n-fold  . . . . . . . . . . . . . . . . . . . . . . . . 38
+       A.2.  mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
+       A.3.  DES3 DR and DK  . . . . . . . . . . . . . . . . . . . . 43
+       A.4.  DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
+       A.5.  Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
+   B.  Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
+   Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
+   Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
+   Informative References. . . . . . . . . . . . . . . . . . . . . . 48
+   Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
+   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
+
+1.  Introduction
+
+   The Kerberos protocols [Kerb] are designed to encrypt messages of
+   arbitrary sizes, using block encryption ciphers or, less commonly,
+   stream encryption ciphers.  Encryption is used to prove the
+   identities of the network entities participating in message
+   exchanges.  However, nothing in the Kerberos protocol requires that
+   any specific encryption algorithm be used, as long as the algorithm
+   includes certain operations.
+
+   The following sections specify the encryption and checksum mechanisms
+   currently defined for Kerberos, as well as a framework for defining
+   future mechanisms.  The encoding, chaining, padding, and other
+   requirements for each are described.  Appendix A gives test vectors
+   for several functions.
+
+2.  Concepts
+
+   Both encryption and checksum mechanisms are profiled in later
+   sections.  Each profile specifies a collection of operations and
+   attributes that must be defined for a mechanism.  A Kerberos
+   encryption or checksum mechanism specification is not complete if it
+   does not define all of these operations and attributes.
+
+   An encryption mechanism must provide for confidentiality and
+   integrity of the original plaintext.  (Incorporating a checksum may
+   permit integrity checking, if the encryption mode does not provide an
+   integrity check itself.)  It must also provide non-malleability
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 2]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   [Bellare98] [Dolev91].  Use of a random confounder prepended to the
+   plaintext is recommended.  It should not be possible to determine if
+   two ciphertexts correspond to the same plaintext without the key.
+
+   A checksum mechanism [1] must provide proof of the integrity of the
+   associated message and must preserve the confidentiality of the
+   message in case it is not sent in the clear.  Finding two plaintexts
+   with the same checksum should be infeasible.  It is NOT required that
+   an eavesdropper be unable to determine whether two checksums are for
+   the same message, as the messages themselves would presumably be
+   visible to any such eavesdropper.
+
+   Due to advances in cryptography, some cryptographers consider using
+   the same key for multiple purposes unwise.  Since keys are used in
+   performing a number of different functions in Kerberos, it is
+   desirable to use different keys for each of these purposes, even
+   though we start with a single long-term or session key.
+
+   We do this by enumerating the different uses of keys within Kerberos
+   and by making the "usage number" an input to the encryption or
+   checksum mechanisms; such enumeration is outside the scope of this
+   document.  Later sections define simplified profile templates for
+   encryption and checksum mechanisms that use a key derivation function
+   applied to a CBC mode (or similar) cipher and a checksum or hash
+   algorithm.
+
+   We distinguish the "base key" specified by other documents from the
+   "specific key" for a specific encryption or checksum operation.  It
+   is expected but not required that the specific key be one or more
+   separate keys derived from the original protocol key and the key
+   usage number.  The specific key should not be explicitly referenced
+   outside of this document.  The typical language used in other
+   documents should be something like, "encrypt this octet string using
+   this key and this usage number"; generation of the specific key and
+   cipher state (described in the next section) are implicit.  The
+   creation of a new cipher-state object, or the re-use of one from a
+   previous encryption operation, may also be explicit.
+
+   New protocols defined in terms of the Kerberos encryption and
+   checksum types should use their own key usage values.  Key usages are
+   unsigned 32-bit integers; zero is not permitted.
+
+   All data is assumed to be in the form of strings of octets or eight-
+   bit bytes.  Environments with other byte sizes will have to emulate
+   this behavior in order to get correct results.
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 3]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   Each algorithm is assigned an encryption type (or "etype") or
+   checksum type number, for algorithm identification within the
+   Kerberos protocol.  The full list of current type number assignments
+   is given in section 8.
+
+3.  Encryption Algorithm Profile
+
+   An encryption mechanism profile must define the following attributes
+   and operations.  The operations must be defined as functions in the
+   mathematical sense.  No additional or implicit inputs (such as
+   Kerberos principal names or message sequence numbers) are permitted.
+
+   protocol key format
+      This describes which octet string values represent valid keys.
+      For encryption mechanisms that don't have perfectly dense key
+      spaces, this will describe the representation used for encoding
+      keys.  It need not describe invalid specific values; all key
+      generation routines should avoid such values.
+
+   specific key structure
+      This is not a protocol format at all, but a description of the
+      keying material derived from the chosen key and used to encrypt or
+      decrypt data or compute or verify a checksum.  It may, for
+      example, be a single key, a set of keys, or a combination of the
+      original key with additional data.  The authors recommend using
+      one or more keys derived from the original key via one-way key
+      derivation functions.
+
+   required checksum mechanism
+      This indicates a checksum mechanism that must be available when
+      this encryption mechanism is used.  Since Kerberos has no built in
+      mechanism for negotiating checksum mechanisms, once an encryption
+      mechanism is decided, the corresponding checksum mechanism can be
+      used.
+
+   key-generation seed length, K
+      This is the length of the random bitstring needed to generate a
+      key with the encryption scheme's random-to-key function (described
+      below).  This must be a fixed value so that various techniques for
+      producing a random bitstring of a given length may be used with
+      key generation functions.
+
+   key generation functions
+      Keys must be generated in a number of cases, from different types
+      of inputs.  All function specifications must indicate how to
+      generate keys in the proper wire format and must avoid generating
+      keys that significantly compromise the confidentiality of
+      encrypted data, if the cryptosystem has such.  Entropy from each
+
+
+
+Raeburn                     Standards Track                     [Page 4]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+      source should be preserved as much as possible.  Many of the
+      inputs, although unknown, may be at least partly predictable
+      (e.g., a password string is likely to be entirely in the ASCII
+      subset and of fairly short length in many environments; a semi-
+      random string may include time stamps).  The benefit of such
+      predictability to an attacker must be minimized.
+
+   string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
+      This function generates a key from two UTF-8 strings and an opaque
+      octet string.  One of the strings is usually the principal's pass
+      phrase, but generally it is merely a secret string.  The other
+      string is a "salt" string intended to produce different keys from
+      the same password for different users or realms.  Although the
+      strings provided will use UTF-8 encoding, no specific version of
+      Unicode should be assumed; all valid UTF-8 strings should be
+      allowed.  Strings provided in other encodings MUST first be
+      converted to UTF-8 before applying this function.
+
+      The third argument, the octet string, may be used to pass
+      mechanism-specific parameters into this function.  Since doing so
+      implies knowledge of the specific encryption system, generating
+      non-default parameter values should be an uncommon operation, and
+      normal Kerberos applications should be able to treat this
+      parameter block as an opaque object supplied by the Key
+      Distribution Center or defaulted to some mechanism-specific
+      constant value.
+
+      The string-to-key function should be a one-way function so that
+      compromising a user's key in one realm does not compromise it in
+      another, even if the same password (but a different salt) is used.
+
+   random-to-key (bitstring[K])->(protocol-key)
+      This function generates a key from a random bitstring of a
+      specific size.  All the bits of the input string are assumed to be
+      equally random, even though the entropy present in the random
+      source may be limited.
+
+   key-derivation (protocol-key, integer)->(specific-key)
+      In this function, the integer input is the key usage value, as
+      described above.  An attacker is assumed to know the usage values.
+      The specific-key output value was described in section 2.
+
+   string-to-key parameter format
+      This describes the format of the block of data that can be passed
+      to the string-to-key function above to configure additional
+      parameters for that function.  Along with the mechanism of
+      encoding parameter values, bounds on the allowed parameters should
+      also be described to avoid allowing a spoofed KDC to compromise
+
+
+
+Raeburn                     Standards Track                     [Page 5]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+      the user's password.  If practical it may be desirable to
+      construct the encoding so that values unacceptably weakening the
+      resulting key cannot be encoded.
+
+      Local security policy might permit tighter bounds to avoid excess
+      resource consumption.  If so, the specification should recommended
+      defaults for these bounds.  The description should also outline
+      possible weaknesses if bounds checks or other validations are not
+      applied to a parameter string received from the network.
+
+      As mentioned above, this should be considered opaque to most
+      normal applications.
+
+   default string-to-key parameters (octet string)
+      This default value for the "params" argument to the string-to-key
+      function should be used when the application protocol (Kerberos or
+      other) does not explicitly set the parameter value.  As indicated
+      above, in most cases this parameter block should be treated as an
+      opaque object.
+
+   cipher state
+      This describes any information that can be carried over from one
+      encryption or decryption operation to the next, for use with a
+      given specific key.  For example, a block cipher used in CBC mode
+      may put an initial vector of one block in the cipher state.  Other
+      encryption modes may track nonces or other data.
+
+      This state must be non-empty and must influence encryption so that
+      messages are decrypted in the same order they were a encrypted, if
+      the cipher state is carried over from one encryption to the next.
+      Distinguishing out-of-order or missing messages from corrupted
+      messages is not required.  If desired, this can be done at a
+      higher level by including sequence numbers and not "chaining" the
+      cipher state between encryption operations.
+
+      The cipher state may not be reused in multiple encryption or
+      decryption operations.  These operations all generate a new cipher
+      state that may be used for following operations using the same key
+      and operation.
+
+      The contents of the cipher state must be treated as opaque outside
+      of encryption system specifications.
+
+   initial cipher state (specific-key, direction)->(state)
+      This describes the generation of the initial value for the cipher
+      state if it is not being carried over from a previous encryption
+      or decryption operation.
+
+
+
+
+Raeburn                     Standards Track                     [Page 6]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+      This describes any initial state setup needed before encrypting
+      arbitrary amounts of data with a given specific key.  The specific
+      key and the direction of operations to be performed (encrypt
+      versus decrypt) must be the only input needed for this
+      initialization.
+
+      This state should be treated as opaque in any uses outside of an
+      encryption algorithm definition.
+
+      IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
+      degree an application protocol could exercise control over the
+      initial vector used in DES CBC operations.  Some existing
+      implementations permit setting the initial vector.  This framework
+      does not provide for application control of the cipher state
+      (beyond "initialize" and "carry over from previous encryption"),
+      as the form and content of the initial cipher state can vary
+      between encryption systems and may not always be a single block of
+      random data.
+
+      New Kerberos application protocols should not assume control over
+      the initial vector, or that one even exists.  However, a general-
+      purpose implementation may wish to provide the capability, in case
+      applications explicitly setting it are encountered.
+
+   encrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and a non-
+      empty plaintext string as input and generates ciphertext and a new
+      cipher state as outputs.  If the basic encryption algorithm itself
+      does not provide for integrity protection (e.g., DES in CBC mode),
+      then some form of verifiable MAC or checksum must be included.
+      Some random factor such as a confounder should be included so that
+      an observer cannot know if two messages contain the same
+      plaintext, even if the cipher state and specific keys are the
+      same.  The exact length of the plaintext need not be encoded, but
+      if it is not and if padding is required, the padding must be added
+      at the end of the string so that the decrypted version may be
+      parsed from the beginning.
+
+      The specification of the encryption function must indicate not
+      only the precise contents of the output octet string, but also the
+      output cipher state.  The application protocol may carry the
+      output cipher state forward from one encryption with a given
+      specific key to another; the effect of this "chaining" must be
+      defined [2].
+
+      Assuming that values for the specific key and cipher state are
+      correctly-produced, no input octet string may result in an error
+      indication.
+
+
+
+Raeburn                     Standards Track                     [Page 7]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   decrypt (specific-key, state, octet string)->(state, octet string)
+      This function takes the specific key, cipher state, and ciphertext
+      as inputs and verifies the integrity of the supplied ciphertext.
+      If the ciphertext's integrity is intact, this function produces
+      the plaintext and a new cipher state as outputs; otherwise, an
+      error indication must be returned, and the data discarded.
+
+      The result of the decryption may be longer than the original
+      plaintext, as, for example, when the encryption mode adds padding
+      to reach a multiple of a block size.  If this is the case, any
+      extra octets must come after the decoded plaintext.  An
+      application protocol that needs to know the exact length of the
+      message must encode a length or recognizable "end of message"
+      marker within the plaintext [3].
+
+      As with the encryption function, a correct specification for this
+      function must indicate not only the contents of the output octet
+      string, but also the resulting cipher state.
+
+   pseudo-random (protocol-key, octet-string)->(octet-string)
+      This pseudo-random function should generate an octet string of
+      some size that is independent of the octet string input.  The PRF
+      output string should be suitable for use in key generation, even
+      if the octet string input is public.  It should not reveal the
+      input key, even if the output is made public.
+
+   These operations and attributes are all that is required to support
+   Kerberos and various proposed preauthentication schemes.
+
+   For convenience of certain application protocols that may wish to use
+   the encryption profile, we add the constraint that, for any given
+   plaintext input size, a message size must exist between that given
+   size and that size plus 65,535 such that the length of the decrypted
+   version of the ciphertext will never have extra octets at the end.
+
+   Expressed mathematically, for every message length L1, there exists a
+   message size L2 such that
+
+      L2 >= L1
+      L2 < L1 + 65,536
+      for every message M with |M| = L2, decrypt(encrypt(M)) = M
+
+   A document defining a new encryption type should also describe known
+   weaknesses or attacks, so that its security may be fairly assessed,
+   and should include test vectors or other validation procedures for
+   the operations defined.  Specific references to information that is
+   readily available elsewhere are sufficient.
+
+
+
+
+Raeburn                     Standards Track                     [Page 8]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+4.  Checksum Algorithm Profile
+
+   A checksum mechanism profile must define the following attributes and
+   operations:
+
+   associated encryption algorithm(s)
+      This indicates the types of encryption keys this checksum
+      mechanism can be used with.
+
+      A keyed checksum mechanism may have more than one associated
+      encryption algorithm if they share the same wire-key format,
+      string-to-key function, default string-to-key-parameters, and key
+      derivation function.  (This combination means that, for example, a
+      checksum type, key usage value, and password are adequate to get
+      the specific key used to compute a checksum.)
+
+      An unkeyed checksum mechanism can be used with any encryption
+      type, as the key is ignored, but its use must be limited to cases
+      where the checksum itself is protected, to avoid trivial attacks.
+
+   get_mic function
+      This function generates a MIC token for a given specific key (see
+      section 3) and message (represented as an octet string) that may
+      be used to verify the integrity of the associated message.  This
+      function is not required to return the same deterministic result
+      for each use; it need only generate a token that the verify_mic
+      routine can check.
+
+      The output of this function will also dictate the size of the
+      checksum.  It must be no larger than 65,535 octets.
+
+   verify_mic function
+      Given a specific key, message, and MIC token, this function
+      ascertains whether the message integrity has been compromised.
+      For a deterministic get_mic routine, the corresponding verify_mic
+      may simply generate another checksum and compare the two.
+
+   The get_mic and verify_mic operations must allow inputs of arbitrary
+   length; if any padding is needed, the padding scheme must be
+   specified as part of these functions.
+
+   These operations and attributes are all that should be required to
+   support Kerberos and various proposed preauthentication schemes.
+
+   As with encryption mechanism definition documents, documents defining
+   new checksum mechanisms should indicate validation processes and
+   known weaknesses.
+
+
+
+
+Raeburn                     Standards Track                     [Page 9]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+5.  Simplified Profile for CBC Ciphers with Key Derivation
+
+   The profile outlined in sections 3 and 4 describes a large number of
+   operations that must be defined for encryption and checksum
+   algorithms to be used with Kerberos.  Here we describe a simpler
+   profile that can generate both encryption and checksum mechanism
+   definitions, filling in uses of key derivation in appropriate places,
+   providing integrity protection, and defining multiple operations for
+   the cryptosystem profile based on a smaller set of operations.  Not
+   all of the existing cryptosystems for Kerberos fit into this
+   simplified profile, but we recommend that future cryptosystems use it
+   or something based on it [4].
+
+   Not all the operations in the complete profiles are defined through
+   this mechanism; several must still be defined for each new algorithm
+   pair.
+
+5.1.  A Key Derivation Function
+
+   Rather than define some scheme by which a "protocol key" is composed
+   of a large number of encryption keys, we use keys derived from a base
+   key to perform cryptographic operations.  The base key must be used
+   only for generating the derived keys, and this derivation must be
+   non-invertible and entropy preserving.  Given these restrictions,
+   compromise of one derived key does not compromise others.  Attack of
+   the base key is limited, as it is only used for derivation and is not
+   exposed to any user data.
+
+   To generate a derived key from a base key, we generate a pseudorandom
+   octet string by using an algorithm DR, described below, and generate
+   a key from that octet string by using a function dependent on the
+   encryption algorithm.  The input length needed for that function,
+   which is also dependent on the encryption algorithm, dictates the
+   length of the string to be generated by the DR algorithm (the value
+   "k" below).  These procedures are based on the key derivation in
+   [Blumenthal96].
+
+      Derived Key = DK(Base Key, Well-Known Constant)
+
+      DK(Key, Constant) = random-to-key(DR(Key, Constant))
+
+      DR(Key, Constant) = k-truncate(E(Key, Constant,
+                                       initial-cipher-state))
+
+   Here DR is the random-octet generation function described below, and
+   DK is the key-derivation function produced from it.  In this
+   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
+   a well-known constant determined by the specific usage of this
+
+
+
+Raeburn                     Standards Track                    [Page 10]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   function, and k-truncate truncates its argument by taking the first k
+   bits.  Here, k is the key generation seed length needed for the
+   encryption system.
+
+   The output of the DR function is a string of bits; the actual key is
+   produced by applying the cryptosystem's random-to-key operation on
+   this bitstring.
+
+   If the Constant is smaller than the cipher block size of E, then it
+   must be expanded with n-fold() so it can be encrypted.  If the output
+   of E is shorter than k bits, it is fed back into the encryption as
+   many times as necessary.  The construct is as follows (where |
+   indicates concatentation):
+
+      K1 = E(Key, n-fold(Constant), initial-cipher-state)
+      K2 = E(Key, K1, initial-cipher-state)
+      K3 = E(Key, K2, initial-cipher-state)
+      K4 = ...
+
+      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
+
+   n-fold is an algorithm that takes m input bits and "stretches" them
+   to form n output bits with equal contribution from each input bit to
+   the output, as described in [Blumenthal96]:
+
+      We first define a primitive called n-folding, which takes a
+      variable-length input block and produces a fixed-length output
+      sequence.  The intent is to give each input bit approximately
+      equal weight in determining the value of each output bit.  Note
+      that whenever we need to treat a string of octets as a number, the
+      assumed representation is Big-Endian -- Most Significant Byte
+      first.
+
+      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, with end-around carry) to yield
+      a n-bit result....
+
+   Test vectors for n-fold are supplied in appendix A [5].
+
+   In this section, n-fold is always used to produce c bits of output,
+   where c is the cipher block size of E.
+
+   The size of the Constant must not be larger than c, because reducing
+   the length of the Constant by n-folding can cause collisions.
+
+
+
+
+Raeburn                     Standards Track                    [Page 11]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   If the size of the Constant is smaller than c, then the Constant must
+   be n-folded to length c.  This string is used as input to E.  If the
+   block size of E is less than the random-to-key input size, then the
+   output from E is taken as input to a second invocation of E.  This
+   process is repeated until the number of bits accumulated is greater
+   than or equal to the random-to-key input size.  When enough bits have
+   been computed, the first k are taken as the random data used to
+   create the key with the algorithm-dependent random-to-key function.
+
+   As the derived key is the result of one or more encryptions in the
+   base key, deriving the base key from the derived key is equivalent to
+   determining the key from a very small number of plaintext/ciphertext
+   pairs.  Thus, this construction is as strong as the cryptosystem
+   itself.
+
+5.2.  Simplified Profile Parameters
+
+   These are the operations and attributes that must be defined:
+
+   protocol key format
+   string-to-key function
+   default string-to-key parameters
+   key-generation seed length, k
+   random-to-key function
+      As above for the normal encryption mechanism profile.
+
+   unkeyed hash algorithm, H
+      This should be a collision-resistant hash algorithm with fixed-
+      size output, suitable for use in an HMAC [HMAC].  It must support
+      inputs of arbitrary length.  Its output must be at least the
+      message block size (below).
+
+   HMAC output size, h
+      This indicates the size of the leading substring output by the
+      HMAC function that should be used in transmitted messages.  It
+      should be at least half the output size of the hash function H,
+      and at least 80 bits; it need not match the output size.
+
+   message block size, m
+      This is the size of the smallest units the cipher can handle in
+      the mode in which it is being used.  Messages will be padded to a
+      multiple of this size.  If a block cipher is used in a mode that
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 12]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+      can handle messages that are not multiples of the cipher block
+      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
+      this value would be one octet.  For traditional CBC mode with
+      padding, it would be the underlying cipher's block size.
+
+      This value must be a multiple of eight bits (one octet).
+
+   encryption/decryption functions, E and D
+      These are basic encryption and decryption functions for messages
+      of sizes that are multiples of the message block size.  No
+      integrity checking or confounder should be included here.  For
+      inputs these functions take the IV or similar data, a protocol-
+      format key, and an octet string, returning a new IV and octet
+      string.
+
+      The encryption function is not required to use CBC mode but is
+      assumed to be using something with similar properties.  In
+      particular, prepending a cipher block-size confounder to the
+      plaintext should alter the entire ciphertext (comparable to
+      choosing and including a random initial vector for CBC mode).
+
+      The result of encrypting one cipher block (of size c, above) must
+      be deterministic for the random octet generation function DR in
+      the previous section to work.  For best security, it should also
+      be no larger than c.
+
+   cipher block size, c
+      This is the block size of the block cipher underlying the
+      encryption and decryption functions indicated above, used for key
+      derivation and for the size of the message confounder and initial
+      vector.  (If a block cipher is not in use, some comparable
+      parameter should be determined.)  It must be at least 5 octets.
+
+      This is not actually an independent parameter; rather, it is a
+      property of the functions E and D.  It is listed here to clarify
+      the distinction between it and the message block size, m.
+
+   Although there are still a number of properties to specify, they are
+   fewer and simpler than in the full profile.
+
+5.3.  Cryptosystem Profile Based on Simplified Profile
+
+   The above key derivation function is used to produce three
+   intermediate keys.  One is used for computing checksums of
+   unencrypted data.  The other two are used for encrypting and
+   checksumming plaintext to be sent encrypted.
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 13]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   The ciphertext output is the concatenation of the output of the basic
+   encryption function E and a (possibly truncated) HMAC using the
+   specified hash function H, both applied to the plaintext with a
+   random confounder prefix and sufficient padding to bring it to a
+   multiple of the message block size.  When the HMAC is computed, the
+   key is used in the protocol key form.
+
+   Decryption is performed by removing the (partial) HMAC, decrypting
+   the remainder, and verifying the HMAC.  The cipher state is an
+   initial vector, initialized to zero.
+
+   The substring notation "[1..h]" in the following table should be read
+   as using 1-based indexing; leading substrings are used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 14]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                   Cryptosystem from Simplified Profile
+------------------------------------------------------------------------
+protocol key format       As given.
+
+specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
+
+key-generation seed       As given.
+length
+
+required checksum         As defined below in section 5.4.
+mechanism
+
+cipher state              Initial vector (usually of length c)
+
+initial cipher state      All bits zero
+
+encryption function       conf = Random string of length c
+                          pad  = Shortest string to bring confounder
+                                 and plaintext to a length that's a
+                                 multiple of m.
+                          (C1, newIV) = E(Ke, conf | plaintext | pad,
+                                          oldstate.ivec)
+                          H1 = HMAC(Ki, conf | plaintext | pad)
+                          ciphertext =  C1 | H1[1..h]
+                          newstate.ivec = newIV
+
+decryption function       (C1,H1) = ciphertext
+                          (P1, newIV) = D(Ke, C1, oldstate.ivec)
+                          if (H1 != HMAC(Ki, P1)[1..h])
+                             report error
+                          newstate.ivec = newIV
+
+default string-to-key     As given.
+params
+
+pseudo-random function    tmp1 = H(octet-string)
+                          tmp2 = truncate tmp1 to multiple of m
+                          PRF = E(DK(protocol-key, prfconstant),
+                                  tmp2, initial-cipher-state)
+
+   The "prfconstant" used in the PRF operation is the three-octet string
+   "prf".
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 15]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                   Cryptosystem from Simplified Profile
+------------------------------------------------------------------------
+key generation functions:
+
+string-to-key function    As given.
+
+random-to-key function    As given.
+
+key-derivation function   The "well-known constant" used for the DK
+                          function is the key usage number, expressed as
+                          four octets in big-endian order, followed by
+                          one octet indicated below.
+
+                          Kc = DK(base-key, usage | 0x99);
+                          Ke = DK(base-key, usage | 0xAA);
+                          Ki = DK(base-key, usage | 0x55);
+
+5.4.  Checksum Profiles Based on Simplified Profile
+
+   When an encryption system is defined with the simplified profile
+   given in section 5.2, a checksum algorithm may be defined for it as
+   follows:
+
+                Checksum Mechanism from Simplified Profile
+             --------------------------------------------------
+             associated cryptosystem   As defined above.
+
+             get_mic                   HMAC(Kc, message)[1..h]
+
+             verify_mic                get_mic and compare
+
+   The HMAC function and key Kc are as described in section 5.3.
+
+6.  Profiles for Kerberos Encryption and Checksum Algorithms
+
+   These profiles describe the encryption and checksum systems defined
+   for Kerberos.  The astute reader will notice that some of them do not
+   fulfill all the requirements outlined in previous sections.  These
+   systems are defined for backward compatibility; newer implementations
+   should (whenever possible) attempt to utilize encryption systems that
+   satisfy all the profile requirements.
+
+   The full list of current encryption and checksum type number
+   assignments, including values currently reserved but not defined in
+   this document, is given in section 8.
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 16]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+6.1.  Unkeyed Checksums
+
+   These checksum types use no encryption keys and thus can be used in
+   combination with any encryption type, but they may only be used with
+   caution, in limited circumstances where the lack of a key does not
+   provide a window for an attack, preferably as part of an encrypted
+   message [6].  Keyed checksum algorithms are recommended.
+
+6.1.1.  The RSA MD5 Checksum
+
+   The RSA-MD5 checksum calculates a checksum by 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 (sixteen octet)
+   checksum.
+
+                                  rsa-md5
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   rsa-md5(msg)
+
+               verify_mic                get_mic and compare
+
+   The rsa-md5 checksum algorithm is assigned a checksum type number of
+   seven (7).
+
+6.1.2.  The RSA MD4 Checksum
+
+   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 (sixteen octet)
+   checksum.
+
+                                  rsa-md4
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   md4(msg)
+
+               verify_mic                get_mic and compare
+
+   The rsa-md4 checksum algorithm is assigned a checksum type number of
+   two (2).
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 17]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+6.1.3.  CRC-32 Checksum
+
+   This CRC-32 checksum calculates a checksum based on a cyclic
+   redundancy check as described in ISO 3309 [CRC] but modified as
+   described below.  The resulting checksum is four (4) octets in
+   length.  The CRC-32 is neither keyed nor collision-proof; thus, 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 CRC-32 checksum used in the des-cbc-crc encryption mode is
+   identical to the 32-bit FCS described in ISO 3309 with two
+   exceptions: The sum with the all-ones polynomial times x**k is
+   omitted, and the final remainder is not ones-complemented.  ISO 3309
+   describes the FCS in terms of bits, whereas this document describes
+   the Kerberos protocol in terms of octets.  To clarify the ISO 3309
+   definition for the purpose of computing the CRC-32 in the des-cbc-crc
+   encryption mode, the ordering of bits in each octet shall be assumed
+   to be LSB first.  Given this assumed ordering of bits within an
+   octet, the mapping of bits to polynomial coefficients shall be
+   identical to that specified in ISO 3309.
+
+   Test values for this modified CRC function are included in appendix
+   A.5.
+
+                                   crc32
+               ----------------------------------------------
+               associated cryptosystem   any
+
+               get_mic                   crc32(msg)
+
+               verify_mic                get_mic and compare
+
+   The crc32 checksum algorithm is assigned a checksum type number of
+   one (1).
+
+6.2.  DES-Based Encryption and Checksum Types
+
+   These encryption systems encrypt information under the Data
+   Encryption Standard [DES77] by using the cipher block chaining mode
+   [DESM80].  A checksum is computed as described below and placed in
+   the cksum field.  DES blocks are eight bytes.  As a result, the data
+   to be encrypted (the concatenation of confounder, checksum, and
+   message) must be padded to an eight byte boundary before encryption.
+   The values of the padding bytes are unspecified.
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 18]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   Plaintext and DES ciphertext are encoded as blocks of eight octets,
+   which are concatenated to make the 64-bit inputs for the DES
+   algorithms.  The first octet supplies the eight most significant bits
+   (with the octet's MSB used as the DES input block's MSB, etc.), the
+   second octet the next eight bits, and so on.  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; this vector
+   is specified below for each encryption system.
+
+   The DES specifications [DESI81] identify four 'weak' and twelve
+   'semi-weak' keys; these keys SHALL NOT be used for encrypting
+   messages for use in Kerberos.  The "variant keys" generated for the
+   RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an
+   eXclusive-OR of a DES key with a constant are not checked for this
+   property.
+
+   A DES key is eight octets of data.  This consists of 56 bits of
+   actual key data, and eight parity bits, one per octet.  The key is
+   encoded as a series of eight 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 most significant bit).  See the [DESM80] introduction
+   for reference.
+
+   Encryption Data Format
+
+   The format for the data to be encrypted includes a one-block
+   confounder, a checksum, the encoded plaintext, and any necessary
+   padding, as described in the following diagram.  The msg-seq field
+   contains the part of the protocol message to be encrypted.
+
+                  +-----------+----------+---------+-----+
+                  |confounder | checksum | msg-seq | pad |
+                  +-----------+----------+---------+-----+
+
+   One generates a random confounder of one block, placing it in
+   'confounder'; zeros out the 'checksum' field (of length appropriate
+   to exactly hold the checksum to be computed); adds the necessary
+   padding; calculates the appropriate checksum over the whole sequence,
+   placing the result in 'checksum'; and then encrypts using the
+   specified encryption type and the appropriate key.
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 19]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   String or Random-Data to Key Transformation
+
+   To generate a DES key from two UTF-8 text strings (password and
+   salt), the two strings are concatenated, password first, and the
+   result is then padded with zero-valued octets to a multiple of eight
+   octets.
+
+   The top bit of each octet (always zero if the password is plain
+   ASCII, as was assumed when the original specification was written) is
+   discarded, and the remaining seven bits of each octet form a
+   bitstring.  This is then fan-folded and eXclusive-ORed with itself to
+   produce a 56-bit string.  An eight-octet key is formed from this
+   string, each octet using seven bits from the bitstring, leaving the
+   least significant bit unassigned.  The key is then "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 0x00000000000000F0.  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 then
+   "corrected" as described above to form the result, which is returned
+   as the key.
+
+   For purposes of the string-to-key function, the DES CBC checksum is
+   calculated by CBC encrypting a string using the key as IV and the
+   final eight byte block as the checksum.
+
+   Pseudocode follows:
+
+        removeMSBits(8byteblock) {
+          /* Treats a 64 bit block as 8 octets and removes the MSB in
+             each octet (in big endian mode) and concatenates the
+             result.  E.g., the input octet string:
+                01110000 01100001 11110011  01110011 11110111 01101111
+                11110010 01100100
+             results in the output bitstring:
+                1110000 1100001 1110011  1110011 1110111 1101111
+                1110010 1100100  */
+        }
+
+        reverse(56bitblock) {
+          /* Treats a 56-bit block as a binary string and reverses it.
+             E.g., the input string:
+                1000001 1010100 1001000  1000101 1001110 1000001
+                0101110 1001101
+             results in the output string:
+                1011001 0111010 1000001  0111001 1010001 0001001
+                0010101 1000001  */
+        }
+
+
+
+Raeburn                     Standards Track                    [Page 20]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+        add_parity_bits(56bitblock) {
+          /* Copies a 56-bit block into a 64-bit block, left shifts
+             content in each octet, and add DES parity bit.
+             E.g., the input string:
+                1100000 0001111 0011100  0110100 1000101 1100100
+                0110110 0010111
+             results in the output string:
+                11000001 00011111 00111000  01101000 10001010 11001000
+                01101101 00101111  */
+        }
+
+        key_correction(key) {
+             fixparity(key);
+             if (is_weak_key(key))
+                  key = key XOR 0xF0;
+             return(key);
+        }
+
+        mit_des_string_to_key(string,salt) {
+             odd = 1;
+             s = string | salt;
+             tempstring = 0; /* 56-bit string */
+             pad(s); /* with nulls to 8 byte boundary */
+             for (8byteblock in s) {
+                  56bitstring = removeMSBits(8byteblock);
+                  if (odd == 0) reverse(56bitstring);
+                  odd = ! odd;
+                  tempstring = tempstring XOR 56bitstring;
+             }
+             tempkey = key_correction(add_parity_bits(tempstring));
+             key = key_correction(DES-CBC-check(s,tempkey));
+             return(key);
+        }
+
+        des_string_to_key(string,salt,params) {
+             if (length(params) == 0)
+                  type = 0;
+             else if (length(params) == 1)
+                  type = params[0];
+             else
+                  error("invalid params");
+             if (type == 0)
+                  mit_des_string_to_key(string,salt);
+             else
+                  error("invalid params");
+        }
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 21]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   One common extension is to support the "AFS string-to-key" algorithm,
+   which is not defined here, if the type value above is one (1).
+
+   For generation of a key from a random bitstring, we start with a 56-
+   bit string and, as with the string-to-key operation above, insert
+   parity bits.  If the result is a weak or semi-weak key, we modify it
+   by eXclusive-OR with the constant 0x00000000000000F0:
+
+        des_random_to_key(bitstring) {
+             return key_correction(add_parity_bits(bitstring));
+        }
+
+6.2.1.  DES with MD5
+
+   The des-cbc-md5 encryption mode encrypts information under DES in CBC
+   mode with an all-zero initial vector and with an MD5 checksum
+   (described in [MD5-92]) computed and placed in the checksum field.
+
+   The encryption system parameters for des-cbc-md5 are as follows:
+
+                               des-cbc-md5
+   --------------------------------------------------------------------
+   protocol key format      8 bytes, parity in low bit of each
+
+   specific key structure   copy of original key
+
+   required checksum        rsa-md5-des
+   mechanism
+
+   key-generation seed      8 bytes
+   length
+
+   cipher state             8 bytes (CBC initial vector)
+
+   initial cipher state     all-zero
+
+   encryption function      des-cbc(confounder | checksum | msg | pad,
+                                    ivec=oldstate)
+                            where
+                            checksum = md5(confounder | 0000...
+                                           | msg | pad)
+
+                            newstate = last block of des-cbc output
+
+   decryption function      decrypt encrypted text and verify checksum
+
+                            newstate = last block of ciphertext
+
+
+
+
+Raeburn                     Standards Track                    [Page 22]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                               des-cbc-md5
+   --------------------------------------------------------------------
+   default string-to-key    empty string
+   params
+
+   pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+   key generation functions:
+
+   string-to-key            des_string_to_key
+
+   random-to-key            des_random_to_key
+
+   key-derivation           identity
+
+   The des-cbc-md5 encryption type is assigned the etype value three
+   (3).
+
+6.2.2.  DES with MD4
+
+   The des-cbc-md4 encryption mode also encrypts information under DES
+   in CBC mode, with an all-zero initial vector.  An MD4 checksum
+   (described in [MD4-92]) is computed and placed in the checksum field.
+
+                               des-cbc-md4
+   --------------------------------------------------------------------
+   protocol key format      8 bytes, parity in low bit of each
+
+   specific key structure   copy of original key
+
+   required checksum        rsa-md4-des
+   mechanism
+
+   key-generation seed      8 bytes
+   length
+
+   cipher state             8 bytes (CBC initial vector)
+
+   initial cipher state     all-zero
+
+   encryption function      des-cbc(confounder | checksum | msg | pad,
+                                    ivec=oldstate)
+                            where
+                            checksum = md4(confounder | 0000...
+                                           | msg | pad)
+
+                            newstate = last block of des-cbc output
+
+
+
+
+Raeburn                     Standards Track                    [Page 23]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                               des-cbc-md4
+   --------------------------------------------------------------------
+
+   decryption function      decrypt encrypted text and verify checksum
+
+                            newstate = last block of ciphertext
+
+   default string-to-key    empty string
+   params
+
+   pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+   key generation functions:
+
+   string-to-key            des_string_to_key
+
+   random-to-key            copy input, then fix parity bits
+
+   key-derivation           identity
+
+   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
+
+   The des-cbc-md4 encryption algorithm is assigned the etype value two
+   (2).
+
+6.2.3.  DES with CRC
+
+   The des-cbc-crc encryption type uses DES in CBC mode with the key
+   used as the initialization vector, with a four-octet CRC-based
+   checksum computed as described in section 6.1.3.  Note that this is
+   not a standard CRC-32 checksum, but a slightly modified one.
+
+                               des-cbc-crc
+   --------------------------------------------------------------------
+   protocol key format      8 bytes, parity in low bit of each
+
+   specific key structure   copy of original key
+
+   required checksum        rsa-md5-des
+   mechanism
+
+   key-generation seed      8 bytes
+   length
+
+   cipher state             8 bytes (CBC initial vector)
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 24]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                               des-cbc-crc
+   --------------------------------------------------------------------
+   initial cipher state     copy of original key
+
+   encryption function      des-cbc(confounder | checksum | msg | pad,
+                                    ivec=oldstate)
+                            where
+                            checksum = crc(confounder | 00000000
+                                           | msg | pad)
+
+                            newstate = last block of des-cbc output
+
+   decryption function      decrypt encrypted text and verify checksum
+
+                            newstate = last block of ciphertext
+
+   default string-to-key    empty string
+   params
+
+   pseudo-random function   des-cbc(md5(input-string), ivec=0)
+
+   key generation functions:
+
+   string-to-key            des_string_to_key
+
+   random-to-key            copy input, then fix parity bits
+
+   key-derivation           identity
+
+   The des-cbc-crc encryption algorithm is assigned the etype value one
+   (1).
+
+6.2.4.  RSA MD5 Cryptographic Checksum Using DES
+
+   The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
+   by prepending an eight octet confounder before the text, applying the
+   RSA MD5 checksum algorithm, and encrypting the confounder and the
+   checksum by using DES in cipher-block-chaining (CBC) mode with a
+   variant of the key, where the variant is computed by eXclusive-ORing
+   the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0.  The
+   initialization vector should be zero.  The resulting checksum is 24
+   octets long.
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 25]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                                rsa-md5-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md5(conf | msg))
+
+      verify_mic                decrypt and verify rsa-md5 checksum
+
+   The rsa-md5-des checksum algorithm is assigned a checksum type number
+   of eight (8).
+
+6.2.5.  RSA MD4 Cryptographic Checksum Using DES
+
+   The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
+   by prepending an eight octet confounder before the text, applying the
+   RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder
+   and the checksum using DES in cipher-block-chaining (CBC) mode with a
+   variant of the key, where the variant is computed by eXclusive-ORing
+   the key with the constant 0xF0F0F0F0F0F0F0F0 [7].  The initialization
+   vector should be zero.  The resulting checksum is 24 octets long.
+
+                                rsa-md4-des
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                                        conf | rsa-md4(conf | msg),
+                                        ivec=0)
+
+      verify_mic                decrypt and verify rsa-md4 checksum
+
+   The rsa-md4-des checksum algorithm is assigned a checksum type number
+   of three (3).
+
+6.2.6.  RSA MD4 Cryptographic Checksum Using DES Alternative
+
+   The RSA-MD4-DES-K checksum calculates a keyed collision-proof
+   checksum by applying the RSA MD4 checksum algorithm and encrypting
+   the results by using DES in cipher block chaining (CBC) mode with 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; it is no longer
+   recommended.
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 26]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                               rsa-md4-des-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-cbc(key, md4(msg), ivec=key)
+
+      verify_mic                decrypt, compute checksum and compare
+
+   The rsa-md4-des-k checksum algorithm is assigned a checksum type
+   number of six (6).
+
+6.2.7.  DES CBC Checksum
+
+   The DES-MAC checksum is computed by prepending an eight octet
+   confounder to the plaintext, padding with zero-valued octets if
+   necessary to bring the length to a multiple of eight octets,
+   performing a DES CBC-mode encryption on the result by using the key
+   and an initialization vector of zero, taking the last block of the
+   ciphertext, prepending the same confounder, and encrypting the pair
+   by using DES in cipher-block-chaining (CBC) mode with a variant of
+   the key, where the variant is computed by eXclusive-ORing the key
+   with the constant 0xF0F0F0F0F0F0F0F0.  The initialization vector
+   should be zero.  The resulting checksum is 128 bits (sixteen octets)
+   long, 64 bits of which are redundant.  This checksum is tamper-proof
+   and collision-proof.
+
+                                  des-mac
+   ---------------------------------------------------------------------
+   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
+   cryptosystem
+
+   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
+                          conf | des-mac(key, conf | msg | pad, ivec=0),
+                          ivec=0)
+
+   verify_mic     decrypt, compute DES MAC using confounder, compare
+
+   The des-mac checksum algorithm is assigned a checksum type number of
+   four (4).
+
+6.2.8.  DES CBC Checksum Alternative
+
+   The DES-MAC-K checksum is computed by performing a DES CBC-mode
+   encryption of the plaintext, with zero-valued padding bytes if
+   necessary to bring the length to a multiple of eight octets, and by
+   using the last block of the ciphertext as the checksum value.  It is
+   keyed with an encryption key that is also used as the initialization
+   vector.  The resulting checksum is 64 bits (eight octets) long.  This
+
+
+
+Raeburn                     Standards Track                    [Page 27]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   checksum is tamper-proof and collision-proof.  Note that this
+   checksum type is the old method for encoding the DESMAC checksum; it
+   is no longer recommended.
+
+                                 des-mac-k
+      ----------------------------------------------------------------
+      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
+
+      get_mic                   des-mac(key, msg | pad, ivec=key)
+
+      verify_mic                compute MAC and compare
+
+   The des-mac-k checksum algorithm is assigned a checksum type number
+   of five (5).
+
+6.3.  Triple-DES Based Encryption and Checksum Types
+
+   This encryption and checksum type pair is based on the Triple DES
+   cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message
+   authentication algorithm.
+
+   A Triple DES key is the concatenation of three DES keys as described
+   above for des-cbc-md5.  A Triple DES key is generated from random
+   data by creating three DES keys from separate sequences of random
+   data.
+
+   Encrypted data using this type must be generated as described in
+   section 5.3.  If the length of the input data is not a multiple of
+   the block size, zero-valued octets must be used to pad the plaintext
+   to the next eight-octet boundary.  The confounder must be eight
+   random octets (one block).
+
+   The simplified profile for Triple DES, with key derivation as defined
+   in section 5, is as follows:
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              protocol key format     24 bytes, parity in low
+                                      bit of each
+
+              key-generation seed     21 bytes
+              length
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 28]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
+              ------------------------------------------------
+              hash function           SHA-1
+
+              HMAC output size        160 bits
+
+              message block size      8 bytes
+
+              default string-to-key   empty string
+              params
+
+              encryption and          triple-DES encrypt and
+              decryption functions    decrypt, in outer-CBC
+                                      mode (cipher block size
+                                      8 octets)
+
+              key generation functions:
+
+              random-to-key           DES3random-to-key (see
+                                      below)
+
+              string-to-key           DES3string-to-key (see
+                                      below)
+
+   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
+   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
+   checksum type number of twelve (12).
+
+6.3.1.  Triple DES Key Production (random-to-key, string-to-key)
+
+   The 168 bits of random key data are converted to a protocol key value
+   as follows.  First, the 168 bits are divided into three groups of 56
+   bits, which are expanded individually into 64 bits as follows:
+
+   DES3random-to-key:
+         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, each corrected to avoid "weak" and "semi-
+   weak" keys as in section 6.2, are concatenated to form the protocol
+   key value.
+
+
+
+Raeburn                     Standards Track                    [Page 29]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   The string-to-key function is used to transform UTF-8 passwords into
+   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
+   algorithm and DK function, described in section 5.
+
+   The n-fold algorithm is applied to the password string concatenated
+   with a salt value.  For 3-key triple DES, the operation will involve
+   a 168-fold of the input password string, to generate an intermediate
+   key, from which the user's long-term key will be derived with the DK
+   function.  The DES3 string-to-key function is shown here in
+   pseudocode:
+
+         DES3string-to-key(passwordString, salt, params)
+             if (params != emptyString)
+              error("invalid params");
+             s = passwordString + salt
+             tmpKey = random-to-key(168-fold(s))
+             key = DK (tmpKey, KerberosConstant)
+
+   Weak key checking is performed in the random-to-key and DK
+   operations.  The KerberosConstant value is the byte string {0x6b 0x65
+   0x72 0x62 0x65 0x72 0x6f 0x73}.  These values correspond to the ASCII
+   encoding for the string "kerberos".
+
+7.  Use of Kerberos Encryption Outside This Specification
+
+   Several Kerberos-based application protocols and preauthentication
+   systems have been designed and deployed that perform encryption and
+   message integrity checks in various ways.  Although in some cases
+   there may be good reason for specifying these protocols in terms of
+   specific encryption or checksum algorithms, we anticipate that in
+   many cases this will not be true, and more generic approaches
+   independent of particular algorithms will be desirable.  Rather than
+   have each protocol designer reinvent schemes for protecting data,
+   using multiple keys, etc., we have attempted to present in this
+   section a general framework that should be sufficient not only for
+   the Kerberos protocol itself but also for many preauthentication
+   systems and application protocols, while trying to avoid some of the
+   assumptions that can work their way into such protocol designs.
+
+   Some problematic assumptions we've seen (and sometimes made) include
+   the following: a random bitstring is always valid as a key (not true
+   for DES keys with parity); the basic block encryption chaining mode
+   provides no integrity checking, or can easily be separated from such
+   checking (not true for many modes in development that do both
+   simultaneously); a checksum for a message always results in the same
+   value (not true if a confounder is incorporated); an initial vector
+   is used (may not be true if a block cipher in CBC mode is not in
+   use).
+
+
+
+Raeburn                     Standards Track                    [Page 30]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   Although such assumptions the may hold for any given set of
+   encryption and checksum algorithms, they may not be true of the next
+   algorithms to be defined, leaving the application protocol unable to
+   make use of those algorithms without updates to its specification.
+
+   The Kerberos protocol uses only the attributes and operations
+   described in sections 3 and 4.  Preauthentication systems and
+   application protocols making use of Kerberos are encouraged to use
+   them as well.  The specific key and string-to-key parameters should
+   generally be treated as opaque.  Although the string-to-key
+   parameters are manipulated as an octet string, the representation for
+   the specific key structure is implementation defined; it may not even
+   be a single object.
+
+   We don't recommend doing so, but some application protocols will
+   undoubtedly continue to use the key data directly, even if only in
+   some of the currently existing protocol specifications.  An
+   implementation intended to support general Kerberos applications may
+   therefore need to make the key data available, as well as the
+   attributes and operations described in sections 3 and 4 [8].
+
+8.  Assigned Numbers
+
+   The following encryption-type numbers are already assigned or
+   reserved for use in Kerberos and related protocols.
+
+      encryption type                etype      section or comment
+      -----------------------------------------------------------------
+      des-cbc-crc                        1             6.2.3
+      des-cbc-md4                        2             6.2.2
+      des-cbc-md5                        3             6.2.1
+      [reserved]                         4
+      des3-cbc-md5                       5
+      [reserved]                         6
+      des3-cbc-sha1                      7
+      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              6.3
+      aes128-cts-hmac-sha1-96           17          [KRB5-AES]
+      aes256-cts-hmac-sha1-96           18          [KRB5-AES]
+      rc4-hmac                          23          (Microsoft)
+      rc4-hmac-exp                      24          (Microsoft)
+      subkey-keymaterial                65     (opaque; PacketCable)
+
+
+
+Raeburn                     Standards Track                    [Page 31]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   (The "des3-cbc-sha1" assignment is a deprecated version using no key
+   derivation.  It should not be confused with des3-cbc-sha1-kd.)
+
+   Several numbers have been reserved for use in encryption systems not
+   defined here.  Encryption-type numbers have unfortunately been
+   overloaded on occasion in Kerberos-related protocols, so some of the
+   reserved numbers do not and will not correspond to encryption systems
+   fitting the profile presented here.
+
+   The following checksum-type numbers are assigned or reserved.  As
+   with encryption-type numbers, some overloading of checksum numbers
+   has occurred.
+
+   Checksum type              sumtype        checksum         section or
+                                value            size         reference
+   ---------------------------------------------------------------------
+   CRC32                            1               4           6.1.3
+   rsa-md4                          2              16           6.1.2
+   rsa-md4-des                      3              24           6.2.5
+   des-mac                          4              16           6.2.7
+   des-mac-k                        5               8           6.2.8
+   rsa-md4-des-k                    6              16           6.2.6
+   rsa-md5                          7              16           6.1.1
+   rsa-md5-des                      8              24           6.2.4
+   rsa-md5-des3                     9              24             ??
+   sha1 (unkeyed)                  10              20             ??
+   hmac-sha1-des3-kd               12              20            6.3
+   hmac-sha1-des3                  13              20             ??
+   sha1 (unkeyed)                  14              20             ??
+   hmac-sha1-96-aes128             15              20         [KRB5-AES]
+   hmac-sha1-96-aes256             16              20         [KRB5-AES]
+   [reserved]                  0x8003               ?         [GSS-KRB5]
+
+   Encryption and checksum-type numbers are signed 32-bit values.  Zero
+   is invalid, and negative numbers are reserved for local use.  All
+   standardized values must be positive.
+
+9.  Implementation Notes
+
+   The "interface" described here is the minimal information that must
+   be defined to make a cryptosystem useful within Kerberos in an
+   interoperable fashion.  The use of functional notation used in some
+   places is not an attempt to define an API for cryptographic
+   functionality within Kerberos.  Actual implementations providing
+   clean APIs will probably make additional information available, that
+   could be derived from a specification written to the framework given
+   here.  For example, an application designer may wish to determine the
+   largest number of bytes that can be encrypted without overflowing a
+
+
+
+Raeburn                     Standards Track                    [Page 32]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   certain size output buffer or conversely, the maximum number of bytes
+   that might be obtained by decrypting a ciphertext message of a given
+   size.  (In fact, an implementation of the GSS-API Kerberos mechanism
+   [GSS-KRB5] will require some of these.)
+
+   The presence of a mechanism in this document should not be taken to
+   indicate that it must be implemented for compliance with any
+   specification; required mechanisms will be specified elsewhere.
+   Indeed, some of the mechanisms described here for backward
+   compatibility are now considered rather weak for protecting critical
+   data.
+
+10.  Security Considerations
+
+   Recent years have brought so many advancements in large-scale attacks
+   capability against DES that it is no longer considered a strong
+   encryption mechanism.  Triple-DES is generally preferred in its
+   place, despite its poorer performance.  See [ESP-DES] for a summary
+   of some of the potential attacks and [EFF-DES] for a detailed
+   discussion of the implementation of particular attacks.  However,
+   most Kerberos implementations still have DES as their primary
+   interoperable encryption type.
+
+   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
+   single-DES here avoids them.  However, DES also has 48 'possibly-
+   weak' keys [Schneier96] (note that the tables in many editions of the
+   reference contains errors) that are not avoided.
+
+   DES weak keys have the property that E1(E1(P)) = P (where E1 denotes
+   encryption of a single block with key 1).  DES semi-weak keys, or
+   "dual" keys, are pairs of keys with the property that E1(P) = D2(P),
+   and thus E2(E1(P)) = P.  Because of the use of CBC mode and the
+   leading random confounder, however, these properties are unlikely to
+   present a security problem.
+
+   Many of the choices concerning when to perform weak-key corrections
+   relate more to compatibility with existing implementations than to
+   any risk analysis.
+
+   Although checks are also done for the component DES keys in a
+   triple-DES key, the nature of the weak keys make it extremely
+   unlikely that they will weaken the triple-DES encryption.  It is only
+   slightly more likely than having the middle of the three sub-keys
+   match one of the other two, which effectively converts the encryption
+   to single-DES - a case we make no effort to avoid.
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 33]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   The true 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 of course recommended for environments where such
+   attacks represent a significant threat.  The "simplifications" (read:
+   bugs) introduced when CRC-32 was implemented for Kerberos cause
+   leading zeros effectively to be ignored, so messages differing only
+   in leading zero bits will have the same checksum.
+
+   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
+   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
+   the suggested truncation of the HMAC output.  As pointed out in
+   [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash
+   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
+   vectors for HMAC-SHA-1.
+
+   The mit_des_string_to_key function was originally constructed with
+   the assumption that all input would be ASCII; it ignores the top bit
+   of each input byte.  Folding with XOR is also not an especially good
+   mixing mechanism for preserving randomness.
+
+   The n-fold function used in the string-to-key operation for des3-
+   cbc-hmac-sha1-kd was designed to cause each bit of input to
+   contribute equally to the output.  It was not designed to maximize or
+   equally distribute randomness in the input, and conceivably
+   randomness may be lost in cases of partially structured input.  This
+   should only be an issue for highly structured passwords, however.
+
+   [RFC1851] discusses the relative strength of triple-DES encryption.
+   The relatively slow speed of triple-DES encryption may also be an
+   issue for some applications.
+
+   [Bellovin91] suggests that analyses of encryption schemes include a
+   model of an attacker capable of submitting known plaintexts to be
+   encrypted with an unknown key, as well as be able to perform many
+   types of operations on known protocol messages.  Recent experiences
+   with the chosen-plaintext attacks on Kerberos version 4 bear out the
+   value of this suggestion.
+
+   The use of unkeyed encrypted checksums, such as those used in the
+   single-DES cryptosystems specified in [Kerb1510], allows for cut-
+   and-paste attacks, especially if a confounder is not used.  In
+   addition, unkeyed encrypted checksums are vulnerable to chosen-
+   plaintext attacks: An attacker with access to an encryption oracle
+   can easily encrypt the required unkeyed checksum along with the
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 34]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   chosen plaintext. [Bellovin99]  These weaknesses, combined with a
+   common implementation design choice described below, allow for a
+   cross-protocol attack from version 4 to version 5.
+
+   The use of a random confounder is an important means to prevent an
+   attacker from making effective use of protocol exchanges as an
+   encryption oracle.  In Kerberos version 4, the encryption of constant
+   plaintext to constant ciphertext makes an effective encryption oracle
+   for an attacker.  The use of random confounders in [Kerb1510]
+   frustrates this sort of chosen-plaintext attack.
+
+   Using the same key for multiple purposes can enable or increase the
+   scope of chosen-plaintext attacks.  Some software that implements
+   both versions 4 and 5 of the Kerberos protocol uses the same keys for
+   both versions.  This enables the encryption oracle of version 4 to be
+   used to attack version 5.  Vulnerabilities to attacks such as this
+   cross-protocol attack make it unwise to use a key for multiple
+   purposes.
+
+   This document, like the Kerberos protocol, does not address limiting
+   the amount of data a key may be used with to a quantity based on the
+   robustness of the algorithm or size of the key.  It is assumed that
+   any defined algorithms and key sizes will be strong enough to support
+   very large amounts of data, or they will be deprecated once
+   significant attacks are known.
+
+   This document also places no bounds on the amount of data that can be
+   handled in various operations.  To avoid denial of service attacks,
+   implementations will probably seek to restrict message sizes at some
+   higher level.
+
+11.  IANA Considerations
+
+   Two registries for numeric values have been created: Kerberos
+   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
+   are signed values ranging from -2147483648 to 2147483647.  Positive
+   values should be assigned only for algorithms specified in accordance
+   with this specification for use with Kerberos or related protocols.
+   Negative values are for private use; local and experimental
+   algorithms should use these values.  Zero is reserved and may not be
+   assigned.
+
+   Positive encryption- and checksum-type numbers may be assigned
+   following either of two policies described in [BCP26].
+
+   Standards-track specifications may be assigned values under the
+   Standards Action policy.
+
+
+
+
+Raeburn                     Standards Track                    [Page 35]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   Specifications in non-standards track RFCs may be assigned values
+   after Expert Review.  A non-IETF specification may be assigned values
+   by publishing an Informational or standards-track RFC referencing the
+   external specification; that specification must be public and
+   published in some permanent record, much like the IETF RFCs.  It is
+   highly desirable, though not required, that the full specification be
+   published as an IETF RFC.
+
+   Smaller encryption type values should be used for IETF standards-
+   track mechanisms, and much higher values (16777216 and above) for
+   other mechanisms.  (Rationale: In the Kerberos ASN.1 encoding,
+   smaller numbers encode to smaller octet sequences, so this favors
+   standards-track mechanisms with slightly smaller messages.)  Aside
+   from that guideline, IANA may choose numbers as it sees fit.
+
+   Internet-Draft specifications should not include values for
+   encryption- and checksum-type numbers.  Instead, they should indicate
+   that values would be assigned by IANA when the document is approved
+   as an RFC.  For development and interoperability testing, values in
+   the private-use range (negative values) may be used but should not be
+   included in the draft specification.
+
+   Each registered value should have an associated unique reference
+   name.  The lists given in section 8 were used to create the initial
+   registry; they include reservations for specifications in progress in
+   parallel with this document, and certain other values believed to
+   already be in use.
+
+12.  Acknowledgements
+
+   This document is an extension of the encryption specification
+   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
+   of the text of the background, concepts, and DES specifications is
+   drawn directly from that document.
+
+   The abstract framework presented in this document was put together by
+   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
+   and Tom Yu, and the details were refined several times based on
+   comments from John Brezak and others.
+
+   Marc Horowitz wrote the original specification of triple-DES and key
+   derivation in a pair of Internet-Drafts (under the names draft-
+   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that
+   were later folded into a draft revision of [Kerb1510], from which
+   this document was later split off.
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 36]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   Tom Yu provided the text describing the modifications to the standard
+   CRC algorithm as Kerberos implementations actually use it, and some
+   of the text in the Security Considerations section.
+
+   Miroslav Jurisic provided information for one of the UTF-8 test cases
+   for the string-to-key functions.
+
+   Marcus Watts noticed some errors in earlier versions and pointed out
+   that the simplified profile could easily be modified to support
+   cipher text stealing modes.
+
+   Simon Josefsson contributed some clarifications to the DES "CBC
+   checksum" and string-to-key and weak key descriptions, and some test
+   vectors.
+
+   Simon Josefsson, Louis LeVay, and others also caught some errors in
+   earlier versions of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 37]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+A.  Test Vectors
+
+   This section provides test vectors for various functions defined or
+   described in this document.  For convenience, most inputs are ASCII
+   strings, though some UTF-8 samples are provided for string-to-key
+   functions.  Keys and other binary data are specified as hexadecimal
+   strings.
+
+A.1.  n-fold
+
+   The n-fold function is defined in section 5.1.  As noted there, the
+   sample vector in the original paper defining the algorithm appears to
+   be incorrect.  Here are some test cases provided by Marc Horowitz and
+   Simon Josefsson:
+
+      64-fold("012345") =
+      64-fold(303132333435) = be072631276b1955
+
+      56-fold("password") =
+      56-fold(70617373776f7264) = 78a07b6caf85fa
+
+      64-fold("Rough Consensus, and Running Code") =
+      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
+              6e696e6720436f6465) = bb6ed30870b7f0e0
+
+      168-fold("password") =
+      168-fold(70617373776f7264) =
+               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
+
+      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
+      192-fold(4d41535341434856534554545320494e5354495456544520
+               4f4620544543484e4f4c4f4759) =
+               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
+
+      168-fold("Q") =
+      168-fold(51) =
+               518a54a2 15a8452a 518a54a2 15a8452a
+               518a54a2 15
+
+      168-fold("ba") =
+      168-fold(6261) =
+               fb25d531 ae897449 9f52fd92 ea9857c4
+               ba24cf29 7e
+
+   Here are some additional values corresponding to folded values of the
+   string "kerberos"; the 64-bit form is used in the des3 string-to-key
+   (section 6.3.1).
+
+
+
+
+Raeburn                     Standards Track                    [Page 38]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+      64-fold("kerberos") =
+               6b657262 65726f73
+      128-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+      168-fold("kerberos") =
+               8372c236 344e5f15 50cd0747 e15d62ca
+               7a5a3bce a4
+      256-fold("kerberos") =
+               6b657262 65726f73 7b9b5b2b 93132b93
+               5c9bdcda d95c9899 c4cae4de e6d6cae4
+
+   Note that the initial octets exactly match the input string when the
+   output length is a multiple of the input length.
+
+A.2.  mit_des_string_to_key
+
+   The function mit_des_string_to_key is defined in section 6.2.  We
+   present here several test values, with some of the intermediate
+   results.  The fourth test demonstrates the use of UTF-8 with three
+   characters.  The last two tests are specifically constructed so as to
+   trigger the weak-key fixups for the intermediate key produced by
+   fan-folding; we have no test cases that cause such fixups for the
+   final key.
+
+UTF-8 encodings used in test vector:
+eszett    U+00DF   C3 9F   s-caron   U+0161    C5 A1
+c-acute   U+0107   C4 87   g-clef    U+1011E   F0 9D 84 9E
+
+Test vector:
+
+salt:        "ATHENA.MIT.EDUraeburn"
+                           415448454e412e4d49542e4544557261656275726e
+password:    "password"    70617373776f7264
+fan-fold result:           c01e38688ac86c2e
+intermediate key:          c11f38688ac86d2f
+DES key:                   cbc22fae235298e3
+
+salt:       "WHITEHOUSE.GOVdanny"
+                        5748495445484f5553452e474f5664616e6e79
+password:   "potatoe"   706f7461746f65
+fan-fold result:        a028944ee63c0416
+intermediate key:       a129944fe63d0416
+DES key:                df3d32a74fd92a01
+
+salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
+password:  g-clef (U+1011E)      f09d849e
+fan-fold result:                 3c4a262c18fab090
+intermediate key:                3d4a262c19fbb091
+
+
+
+Raeburn                     Standards Track                    [Page 39]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+DES key:                         4ffb26bab0cd9413
+
+salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
+                         415448454e412e4d49542e4544554a757269c5a169c487
+password:       eszett(U+00DF)
+                                c39f
+fan-fold result:b8f6c40e305afc9e
+intermediate key:               b9f7c40e315bfd9e
+DES key:                        62c81a5232b5e69d
+
+salt:       "AAAAAAAA"   4141414141414141
+password:   "11119999"   3131313139393939
+fan-fold result:         e0e0e0e0f0f0f0f0
+intermediate key:        e0e0e0e0f1f1f101
+DES key:                 984054d0f1a73e31
+
+salt:       "FFFFAAAA"   4646464641414141
+password:   "NNNN6666"   4e4e4e4e36363636
+fan-fold result:         1e1e1e1e0e0e0e0e
+intermediate key:        1f1f1f1f0e0e0efe
+DES key:                 c4bf6b25adf7a4f8
+
+   This trace provided by Simon Josefsson shows the intermediate
+   processing stages of one of the test inputs:
+
+      string_to_key (des-cbc-md5, string, salt)
+             ;; string:
+             ;; `password' (length 8 bytes)
+             ;; 70 61 73 73 77 6f 72 64
+             ;; salt:
+             ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+             ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+             ;; 65 62 75 72 6e
+      des_string_to_key (string, salt)
+             ;; String:
+             ;; `password' (length 8 bytes)
+             ;; 70 61 73 73 77 6f 72 64
+             ;; Salt:
+             ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
+             ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
+             ;; 65 62 75 72 6e
+      odd = 1;
+      s = string | salt;
+      tempstring = 0; /* 56-bit string */
+      pad(s); /* with nulls to 8 byte boundary */
+             ;; s = pad(string|salt):
+             ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
+             ;; (length 32 bytes)
+
+
+
+Raeburn                     Standards Track                    [Page 40]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+             ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
+             ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
+      for (8byteblock in s) {
+             ;; loop iteration 0
+             ;; 8byteblock:
+             ;; `password' (length 8 bytes)
+             ;; 70 61 73 73 77 6f 72 64
+             ;; 01110000 01100001 01110011  01110011 01110111 01101111
+             ;; 01110010 01100100
+      56bitstring = removeMSBits(8byteblock);
+             ;; 56bitstring:
+             ;; 1110000 1100001 1110011  1110011 1110111 1101111
+             ;; 1110010 1100100
+      if (odd == 0) reverse(56bitstring);    ;; odd=1
+      odd = ! odd
+      tempstring = tempstring XOR 56bitstring;
+             ;; tempstring
+             ;; 1110000 1100001 1110011  1110011 1110111 1101111
+             ;; 1110010 1100100
+
+      for (8byteblock in s) {
+             ;; loop iteration 1
+             ;; 8byteblock:
+             ;; `ATHENA.M' (length 8 bytes)
+             ;; 41 54 48 45 4e 41 2e 4d
+             ;; 01000001 01010100 01001000  01000101 01001110 01000001
+             ;; 00101110 01001101
+      56bitstring = removeMSBits(8byteblock);
+             ;; 56bitstring:
+             ;; 1000001 1010100 1001000  1000101 1001110 1000001
+             ;; 0101110 1001101
+      if (odd == 0) reverse(56bitstring);    ;; odd=0
+      reverse(56bitstring)
+             ;; 56bitstring after reverse
+             ;; 1011001 0111010 1000001  0111001 1010001 0001001
+             ;; 0010101 1000001
+      odd = ! odd
+      tempstring = tempstring XOR 56bitstring;
+             ;; tempstring
+             ;; 0101001 1011011 0110010  1001010 0100110 1100110
+             ;; 1100111 0100101
+
+      for (8byteblock in s) {
+             ;; loop iteration 2
+             ;; 8byteblock:
+             ;; `IT.EDUra' (length 8 bytes)
+             ;; 49 54 2e 45 44 55 72 61
+             ;; 01001001 01010100 00101110  01000101 01000100 01010101
+
+
+
+Raeburn                     Standards Track                    [Page 41]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+             ;; 01110010 01100001
+      56bitstring = removeMSBits(8byteblock);
+             ;; 56bitstring:
+             ;; 1001001 1010100 0101110  1000101 1000100 1010101
+             ;; 1110010 1100001
+      if (odd == 0) reverse(56bitstring);    ;; odd=1
+      odd = ! odd
+      tempstring = tempstring XOR 56bitstring;
+             ;; tempstring
+             ;; 1100000 0001111 0011100  0001111 1100010 0110011
+             ;; 0010101 1000100
+
+      for (8byteblock in s) {
+             ;; loop iteration 3
+             ;; 8byteblock:
+             ;; `eburn\x00\x00\x00' (length 8 bytes)
+             ;; 65 62 75 72 6e 00 00 00
+             ;; 01100101 01100010 01110101  01110010 01101110 00000000
+             ;; 00000000 00000000
+      56bitstring = removeMSBits(8byteblock);
+             ;; 56bitstring:
+             ;; 1100101 1100010 1110101  1110010 1101110 0000000
+             ;; 0000000 0000000
+      if (odd == 0) reverse(56bitstring);    ;; odd=0
+      reverse(56bitstring)
+             ;; 56bitstring after reverse
+             ;; 0000000 0000000 0000000  0111011 0100111 1010111
+             ;; 0100011 1010011
+      odd = ! odd
+      tempstring = tempstring XOR 56bitstring;
+             ;; tempstring
+             ;; 1100000 0001111 0011100  0110100 1000101 1100100
+             ;; 0110110 0010111
+
+      for (8byteblock in s) {
+      }
+             ;; for loop terminated
+
+      tempkey = key_correction(add_parity_bits(tempstring));
+             ;; tempkey
+             ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
+             ;; c1 1f 38 68 8a c8 6d 2f
+             ;; 11000001 00011111 00111000  01101000 10001010 11001000
+             ;; 01101101 00101111
+
+      key = key_correction(DES-CBC-check(s,tempkey));
+             ;; key
+             ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+
+
+
+Raeburn                     Standards Track                    [Page 42]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+             ;; cb c2 2f ae 23 52 98 e3
+             ;; 11001011 11000010 00101111  10101110 00100011 01010010
+             ;; 10011000 11100011
+
+             ;; string_to_key key:
+             ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
+             ;; cb c2 2f ae 23 52 98 e3
+
+A.3.  DES3 DR and DK
+
+   These tests show the derived-random and derived-key values for the
+   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
+   defined in section 6.3.1.  The input keys were randomly generated;
+   the usage values are from this specification.
+
+   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
+   usage:               0000000155
+   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
+   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
+
+   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
+   usage:               00000001aa
+   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
+   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
+
+   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
+   usage:               0000000155
+   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
+   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
+
+   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
+   usage:               00000001aa
+   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
+   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
+
+   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
+   usage:               6b65726265726f73 ("kerberos")
+   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
+   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
+
+   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
+   usage:               0000000155
+   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
+   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
+
+   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
+   usage:               00000001aa
+   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
+
+
+
+Raeburn                     Standards Track                    [Page 43]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
+
+   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
+   usage:               0000000155
+   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
+   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
+
+   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
+   usage:               00000001aa
+   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
+   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
+
+A.4.  DES3string_to_key
+
+   These are the keys generated for some of the above input strings for
+   triple-DES with key derivation as defined in section 6.3.1.
+
+   salt:   "ATHENA.MIT.EDUraeburn"
+   passwd: "password"
+   key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
+
+   salt:   "WHITEHOUSE.GOVdanny"
+   passwd: "potatoe"
+   key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
+
+   salt:   "EXAMPLE.COMbuckaroo"
+   passwd: "penny"
+   key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
+
+   salt:   "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
+            + c-acute(U+0107)
+   passwd: eszett(U+00DF)
+   key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
+
+   salt:   "EXAMPLE.COMpianist"
+   passwd: g-clef(U+1011E)
+   key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
+
+A.5.  Modified CRC-32
+
+   Below are modified-CRC32 values for various ASCII and octet strings.
+   Only the printable ASCII characters are checksummed, without a C-
+   style trailing zero-valued octet.  The 32-bit modified CRC and the
+   sequence of output bytes as used in Kerberos are shown.  (The octet
+   values are separated here to emphasize that they are octet values and
+   not 32-bit numbers, which will be the most convenient form for
+   manipulation in some implementations.  The bit and byte order used
+
+
+
+
+Raeburn                     Standards Track                    [Page 44]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   internally for such a number is irrelevant; the octet sequence
+   generated is what is important.)
+
+   mod-crc-32("foo") =                                     33 bc 32 73
+   mod-crc-32("test0123456789") =                          d6 88 3e b8
+   mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
+   mod-crc-32(8000) =                                      4b 98 83 3b
+   mod-crc-32(0008) =                                      32 88 db 0e
+   mod-crc-32(0080) =                                      20 83 b8 ed
+   mod-crc-32(80) =                                        20 83 b8 ed
+   mod-crc-32(80000000) =                                  3b b6 59 ed
+   mod-crc-32(00000001) =                                  96 30 07 77
+
+B.  Significant Changes from RFC 1510
+
+   The encryption and checksum mechanism profiles are new.  The old
+   specification defined a few operations for various mechanisms but
+   didn't outline what abstract properties should be required of new
+   mechanisms, or how to ensure that a mechanism specification is
+   complete enough for interoperability between implementations.  The
+   new profiles differ from the old specification in a few ways:
+
+      Some message definitions in [Kerb1510] could be read as permitting
+      the initial vector to be specified by the application; the text
+      was too vague.  It is explicitly not permitted in this
+      specification.  Some encryption algorithms may not use
+      initialization vectors, so relying on chosen, secret
+      initialization vectors for security is unwise.  Also, the
+      prepended confounder in the existing algorithms is roughly
+      equivalent to a per-message initialization vector that is revealed
+      in encrypted form.  However, carrying state across from one
+      encryption to another is explicitly permitted through the opaque
+      "cipher state" object.
+
+      The use of key derivation is new.
+
+      Several new methods are introduced, including generation of a key
+      in wire-protocol format from random input data.
+
+      The means for influencing the string-to-key algorithm are laid out
+      more clearly.
+
+   Triple-DES support is new.
+
+   The pseudo-random function is new.
+
+   The des-cbc-crc, DES string-to-key and CRC descriptions have been
+   updated to align them with existing implementations.
+
+
+
+Raeburn                     Standards Track                    [Page 45]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   [Kerb1510] did not indicate what character set or encoding might be
+   used for pass phrases and salts.
+
+   In [Kerb1510], key types, encryption algorithms, and checksum
+   algorithms were only loosely associated, and the association was not
+   well described.  In this specification, key types and encryption
+   algorithms have a one-to-one correspondence, and associations between
+   encryption and checksum algorithms are described so that checksums
+   can be computed given negotiated keys, without requiring further
+   negotiation for checksum types.
+
+Notes
+
+   [1] Although Message Authentication Code (MAC) or Message Integrity
+       Check (MIC) would be more appropriate terms for many of the uses
+       in this document, we continue to use the term checksum for
+       historical reasons.
+
+   [2] Extending CBC mode across messages would be one obvious example
+       of this chaining.  Another might be the use of counter mode, with
+       a counter randomly initialized and attached to the ciphertext; a
+       second message could continue incrementing the counter when
+       chaining the cipher state, thus avoiding having to transmit
+       another counter value.  However, this chaining is only useful for
+       uninterrupted, ordered sequences of messages.
+
+   [3] In the case of Kerberos, the encrypted objects will generally be
+       ASN.1 DER encodings, which contain indications of their length in
+       the first few octets.
+
+   [4] As of the time of this writing, new modes of operation have been
+       proposed, some of which may permit encryption and integrity
+       protection simultaneously.  After some of these proposals have
+       been subjected to adequate analysis, we may wish to formulate a
+       new simplified profile based on one of them.
+
+   [5] It should be noted that the sample vector in appendix B.2 of the
+       original paper appears to be incorrect.  Two independent
+       implementations from the specification (one in C by Marc
+       Horowitz, and another in Scheme by Bill Sommerfeld) agree on a
+       value different from that in [Blumenthal96].
+
+   [6] For example, in MIT's implementation of [Kerb1510], the rsa-md5
+       unkeyed checksum of application data may be included in an
+       authenticator encrypted in a service's key.
+
+   [7] Using a variant of the key limits the use of a key to a
+       particular function, separating the functions of generating a
+
+
+
+Raeburn                     Standards Track                    [Page 46]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+       checksum from other encryption performed using the session key.
+       The constant 0xF0F0F0F0F0F0F0F0 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.
+
+   [8] Perhaps one of the more common reasons for directly performing
+       encryption is direct control over the negotiation and to select a
+       "sufficiently strong" encryption algorithm (whatever that means
+       in the context of a given application).  Although Kerberos
+       directly provides no direct facility for negotiating encryption
+       types between the application client and server, there are other
+       means to accomplish similar goals (for example, requesting only
+       "strong" session key types from the KDC, and assuming that the
+       type actually returned by the KDC will be understood and
+       supported by the application server).
+
+Normative References
+
+   [BCP26]        Narten, T. and H. Alvestrand, "Guidelines for Writing
+                  an IANA Considerations Section in RFCs", BCP 26, RFC
+                  2434, October 1998.
+
+   [Bellare98]    Bellare, M., Desai, A., Pointcheval, D., and P.
+                  Rogaway, "Relations Among Notions of Security for
+                  Public-Key Encryption Schemes".  Extended abstract
+                  published in Advances in Cryptology-Crypto 98
+                  Proceedings, Lecture Notes in Computer Science Vol.
+                  1462, H. Krawcyzk ed., Springer-Verlag, 1998.
+
+   [Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule
+                  for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96,
+                  1996.
+
+   [CRC]          International Organization for Standardization, "ISO
+                  Information Processing Systems - Data Communication -
+                  High-Level Data Link Control Procedure - Frame
+                  Structure," IS 3309, 3rd Edition, October 1984.
+
+   [DES77]        National Bureau of Standards, U.S. Department of
+                  Commerce, "Data Encryption Standard," Federal
+                  Information Processing Standards Publication 46,
+                  Washington, DC, 1977.
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 47]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   [DESI81]       National Bureau of Standards, U.S. Department of
+                  Commerce, "Guidelines for implementing and using NBS
+                  Data Encryption Standard," Federal Information
+                  Processing Standards Publication 74, Washington, DC,
+                  1981.
+
+   [DESM80]       National Bureau of Standards, U.S. Department of
+                  Commerce, "DES Modes of Operation," Federal
+                  Information Processing Standards Publication 81,
+                  Springfield, VA, December 1980.
+
+   [Dolev91]      Dolev, D., Dwork, C., and M. Naor, "Non-malleable
+                  cryptography", Proceedings of the 23rd Annual
+                  Symposium on Theory of Computing, ACM, 1991.
+
+   [HMAC]         Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+   [KRB5-AES]     Raeburn, K., "Advanced Encryption Standard (AES)
+                  Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [MD4-92]       Rivest, R., "The MD4 Message-Digest Algorithm", RFC
+                  1320, April 1992.
+
+   [MD5-92]       Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+                  1321, April 1992.
+
+   [SG92]         Stubblebine, S. and V. D. Gligor, "On Message
+                  Integrity in Cryptographic Protocols," in Proceedings
+                  of the IEEE Symposium on Research in Security and
+                  Privacy, Oakland, California, May 1992.
+
+Informative References
+
+   [Bellovin91]   Bellovin, S. M. and M. Merrit, "Limitations of the
+                  Kerberos Authentication System", in Proceedings of the
+                  Winter 1991 Usenix Security Conference, January, 1991.
+
+   [Bellovin99]   Bellovin, S. M. and D. Atkins, private communications,
+                  1999.
+
+   [EFF-DES]      Electronic Frontier Foundation, "Cracking DES: Secrets
+                  of Encryption Research, Wiretap Politics, and Chip
+                  Design", O'Reilly & Associates, Inc., May 1998.
+
+   [ESP-DES]      Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
+                  Algorithm With Explicit IV", RFC 2405, November 1998.
+
+
+
+Raeburn                     Standards Track                    [Page 48]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+   [GSS-KRB5]     Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+                  RFC 1964, June 1996.
+
+   [HMAC-TEST]    Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
+                  HMAC-SHA-1", RFC 2202, September 1997.
+
+   [IPSEC-HMAC]   Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
+                  within ESP and AH", RFC 2404, November 1998.
+
+   [Kerb]         Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                  Kerberos Network Authentication Service (V5)", Work in
+                  Progress, September 2004.
+
+   [Kerb1510]     Kohl, J. and C. Neuman, "The Kerberos Network
+                  Authentication Service (V5)", RFC 1510, September
+                  1993.
+
+   [RC5]          Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-
+                  CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October
+                  1996.
+
+   [RFC1851]      Karn, P., Metzger, P., and W. Simpson, "The ESP Triple
+                  DES Transform", RFC 1851, September 1995.
+
+   [Schneier96]   Schneier, B., "Applied Cryptography Second Edition",
+                  John Wiley & Sons, New York, NY, 1996.  ISBN 0-471-
+                  12845-7.
+
+Editor's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   EMail: raeburn@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 49]
+
+RFC 3961         Encryption and Checksum Specifications    February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 50]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc3962.txt b/third_party/heimdal/doc/standardisation/rfc3962.txt
new file mode 100644
index 00000000000..762beedbdbc
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc3962.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                         K. Raeburn
+Request for Comments: 3962                                           MIT
+Category: Standards Track                                  February 2005
+
+
+      Advanced Encryption Standard (AES) Encryption for Kerberos 5
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The United States National Institute of Standards and Technology
+   (NIST) has chosen a new Advanced Encryption Standard (AES), which is
+   significantly faster and (it is believed) more secure than the old
+   Data Encryption Standard (DES) algorithm.  This document is a
+   specification for the addition of this algorithm to the Kerberos
+   cryptosystem suite.
+
+1.  Introduction
+
+   This document defines encryption key and checksum types for Kerberos
+   5 using the AES algorithm recently chosen by NIST.  These new types
+   support 128-bit block encryption and key sizes of 128 or 256 bits.
+
+   Using the "simplified profile" of [KCRYPTO], we can define a pair of
+   encryption and checksum schemes.  AES is used with ciphertext
+   stealing to avoid message expansion, and SHA-1 [SHA1] is the
+   associated checksum function.
+
+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 BCP 14, RFC 2119
+   [KEYWORDS].
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 1]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+3.  Protocol Key Representation
+
+   The profile in [KCRYPTO] treats keys and random octet strings as
+   conceptually different.  But since the AES key space is dense, we can
+   use any bit string of appropriate length as a key.  We use the byte
+   representation for the key described in [AES], where the first bit of
+   the bit string is the high bit of the first byte of the byte string
+   (octet string) representation.
+
+4.  Key Generation from Pass Phrases or Random Data
+
+   Given the above format for keys, we can generate keys from the
+   appropriate amounts of random data (128 or 256 bits) by simply
+   copying the input string.
+
+   To generate an encryption key from a pass phrase and salt string, we
+   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
+   indicated below, to generate an intermediate key (of the same length
+   as the desired final key), which is then passed into the DK function
+   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
+   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
+   produces a "random octet string", hence the application of the
+   random-to-key function even though it's effectively a simple identity
+   operation.)  The resulting key is the user's long-term key for use
+   with the encryption algorithm in question.
+
+   tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
+   key = DK(tkey, "kerberos")
+
+   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
+   passphrase and salt, as described in Appendix B.1 to PKCS#5.
+
+   The number of iterations is specified by the string-to-key parameters
+   supplied.  The parameter string is four octets indicating an unsigned
+   number in big-endian order.  This is the number of iterations to be
+   performed.  If the value is 00 00 00 00, the number of iterations to
+   be performed is 4,294,967,296 (2**32).  (Thus the minimum expressible
+   iteration count is 1.)
+
+   For environments where slower hardware is the norm, implementations
+   of protocols such as Kerberos may wish to limit the number of
+   iterations to prevent a spoofed response supplied by an attacker from
+   consuming lots of client-side CPU time; if such a limit is
+   implemented, it SHOULD be no less than 50,000.  Even for environments
+   with fast hardware, 4 billion iterations is likely to take a fairly
+   long time; much larger bounds might still be enforced, and it might
+   be wise for implementations to permit interruption of this operation
+   by the user if the environment allows for it.
+
+
+
+Raeburn                     Standards Track                     [Page 2]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   If the string-to-key parameters are not supplied, the value used is
+   00 00 10 00 (decimal 4,096, indicating 4,096 iterations).
+
+   Note that this is not a requirement, nor even a recommendation, for
+   this value to be used in "optimistic preauthentication" (e.g.,
+   attempting timestamp-based preauthentication using the user's long-
+   term key without having first communicated with the KDC) in the
+   absence of additional information, or as a default value for sites to
+   use for their principals' long-term keys in their Kerberos database.
+   It is simply the interpretation of the absence of the string-to-key
+   parameter field when the KDC has had an opportunity to provide it.
+
+   Sample test vectors are given in Appendix B.
+
+5.  Ciphertext Stealing
+
+   Cipher block chaining is used to encrypt messages, with the initial
+   vector stored in the cipher state.  Unlike previous Kerberos
+   cryptosystems, we use ciphertext stealing to handle the possibly
+   partial final block of the message.
+
+   Ciphertext stealing is described on pages 195-196 of [AC], and
+   section 8 of [RC5]; it has the advantage that no message expansion is
+   done during encryption of messages of arbitrary sizes as is typically
+   done in CBC mode with padding.  Some errata for [RC5] are listed in
+   Appendix A and are considered part of the ciphertext stealing
+   technique as used here.
+
+   Ciphertext stealing, as defined in [RC5], assumes that more than one
+   block of plain text is available.  If exactly one block is to be
+   encrypted, that block is simply encrypted with AES (also known as ECB
+   mode).  Input smaller than one block is padded at the end to one
+   block; the values of the padding bits are unspecified.
+   (Implementations MAY use all-zero padding, but protocols MUST NOT
+   rely on the result being deterministic.  Implementations MAY use
+   random padding, but protocols MUST NOT rely on the result not being
+   deterministic.  Note that in most cases, the Kerberos encryption
+   profile will add a random confounder independent of this padding.)
+
+   For consistency, ciphertext stealing is always used for the last two
+   blocks of the data to be encrypted, as in [RC5].  If the data length
+   is a multiple of the block size, this is equivalent to plain CBC mode
+   with the last two ciphertext blocks swapped.
+
+   A test vector is given in Appendix B.
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 3]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   The initial vector carried out from one encryption for use in a
+   subsequent encryption is the next-to-last block of the encryption
+   output; this is the encrypted form of the last plaintext block.  When
+   decrypting, the next-to-last block of the supplied ciphertext is
+   carried forward as the next initial vector.  If only one ciphertext
+   block is available (decrypting one block, or encrypting one block or
+   less), then that one block is carried out instead.
+
+6.  Kerberos Algorithm Profile Parameters
+
+   This is a summary of the parameters to be used with the simplified
+   algorithm profile described in [KCRYPTO]:
+
+  +--------------------------------------------------------------------+
+  |               protocol key format        128- or 256-bit string    |
+  |                                                                    |
+  |            string-to-key function        PBKDF2+DK with variable   |
+  |                                          iteration count (see      |
+  |                                          above)                    |
+  |                                                                    |
+  |  default string-to-key parameters        00 00 10 00               |
+  |                                                                    |
+  |        key-generation seed length        key size                  |
+  |                                                                    |
+  |            random-to-key function        identity function         |
+  |                                                                    |
+  |                  hash function, H        SHA-1                     |
+  |                                                                    |
+  |               HMAC output size, h        12 octets (96 bits)       |
+  |                                                                    |
+  |             message block size, m        1 octet                   |
+  |                                                                    |
+  |  encryption/decryption functions,        AES in CBC-CTS mode       |
+  |  E and D                                 (cipher block size 16     |
+  |                                          octets), with next-to-    |
+  |                                          last block (last block    |
+  |                                          if only one) as CBC-style |
+  |                                          ivec                      |
+  +--------------------------------------------------------------------+
+
+   Using this profile with each key size gives us two each of encryption
+   and checksum algorithm definitions.
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 4]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+7.  Assigned Numbers
+
+   The following encryption type numbers are assigned:
+
+  +--------------------------------------------------------------------+
+  |                         encryption types                           |
+  +--------------------------------------------------------------------+
+  |         type name                  etype value          key size   |
+  +--------------------------------------------------------------------+
+  |   aes128-cts-hmac-sha1-96              17                 128      |
+  |   aes256-cts-hmac-sha1-96              18                 256      |
+  +--------------------------------------------------------------------+
+
+   The following checksum type numbers are assigned:
+
+  +--------------------------------------------------------------------+
+  |                          checksum types                            |
+  +--------------------------------------------------------------------+
+  |        type name                 sumtype value           length    |
+  +--------------------------------------------------------------------+
+  |    hmac-sha1-96-aes128                15                   96      |
+  |    hmac-sha1-96-aes256                16                   96      |
+  +--------------------------------------------------------------------+
+
+   These checksum types will be used with the corresponding encryption
+   types defined above.
+
+8.  Security Considerations
+
+   This new algorithm has not been around long enough to receive the
+   decades of intense analysis that DES has received.  It is possible
+   that some weakness exists that has not been found by the
+   cryptographers analyzing these algorithms before and during the AES
+   selection process.
+
+   The use of the HMAC function has drawbacks for certain pass phrase
+   lengths.  For example, a pass phrase longer than the hash function
+   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
+   bytes) before applying the main HMAC algorithm.  However, entropy is
+   generally sparse in pass phrases, especially in long ones, so this
+   may not be a problem in the rare cases of users with long pass
+   phrases.
+
+   Also, generating a 256-bit key from a pass phrase of any length may
+   be deceptive, as the effective entropy in pass-phrase-derived key
+   cannot be nearly that large given the properties of the string-to-key
+   function described here.
+
+
+
+
+Raeburn                     Standards Track                     [Page 5]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   The iteration count in PBKDF2 appears to be useful primarily as a
+   constant multiplier for the amount of work required for an attacker
+   using brute-force methods.  Unfortunately, it also multiplies, by the
+   same amount, the work needed by a legitimate user with a valid
+   password.  Thus the work factor imposed on an attacker (who may have
+   many powerful workstations at his disposal) must be balanced against
+   the work factor imposed on the legitimate user (who may have a PDA or
+   cell phone); the available computing power on either side increases
+   as time goes on, as well.  A better way to deal with the brute-force
+   attack is through preauthentication mechanisms that provide better
+   protection of the user's long-term key.  Use of such mechanisms is
+   out of the scope of this document.
+
+   If a site does wish to use this means of protection against a brute-
+   force attack, the iteration count should be chosen based on the
+   facilities available to both attacker and legitimate user, and the
+   amount of work the attacker should be required to perform to acquire
+   the key or password.
+
+   As an example:
+
+      The author's tests on a 2GHz Pentium 4 system indicated that in
+      one second, nearly 90,000 iterations could be done, producing a
+      256-bit key.  This was using the SHA-1 assembly implementation
+      from OpenSSL, and a pre-release version of the PBKDF2 code for
+      MIT's Kerberos package, on a single system.  No attempt was made
+      to do multiple hashes in parallel, so we assume an attacker doing
+      so can probably do at least 100,000 iterations per second --
+      rounded up to 2**17, for ease of calculation.  For simplicity, we
+      also assume the final AES encryption step costs nothing.
+
+      Paul Leach estimates [LEACH] that a password-cracking dictionary
+      may have on the order of 2**21 entries, with capitalization,
+      punctuation, and other variations contributing perhaps a factor of
+      2**11, giving a ballpark estimate of 2**32.
+
+      Thus, for a known iteration count N and a known salt string, an
+      attacker with some number of computers comparable to the author's
+      would need roughly N*2**15 CPU seconds to convert the entire
+      dictionary plus variations into keys.
+
+      An attacker using a dozen such computers for a month would have
+      roughly 2**25 CPU seconds available.  So using 2**12 (4,096)
+      iterations would mean an attacker with a dozen such computers
+      dedicated to a brute-force attack against a single key (actually,
+      any password-derived keys sharing the same salt and iteration
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 6]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+      count) would process all the variations of the dictionary entries
+      in four months and, on average, would likely find the user's
+      password in two months.
+
+      Thus, if this form of attack is of concern, users should be
+      required to change their passwords every few months, and an
+      iteration count a few orders of magnitude higher should be chosen.
+      Perhaps several orders of magnitude, as many users will tend to
+      use the shorter and simpler passwords (to the extent they can,
+      given a site's password quality checks) that the attacker would
+      likely try first.
+
+      Since this estimate is based on currently available CPU power, the
+      iteration counts used for this mode of defense should be increased
+      over time, at perhaps 40%-60% each year or so.
+
+      Note that if the attacker has a large amount of storage available,
+      intermediate results could be cached, saving a lot of work for the
+      next attack with the same salt and a greater number of iterations
+      than had been run at the point where the intermediate results were
+      saved.  Thus, it would be wise to generate a new random salt
+      string when passwords are changed.  The default salt string,
+      derived from the principal name, only protects against the use of
+      one dictionary of keys against multiple users.
+
+   If the PBKDF2 iteration count can be spoofed by an intruder on the
+   network, and the limit on the accepted iteration count is very high,
+   the intruder may be able to introduce a form of denial of service
+   attack against the client by sending a very high iteration count,
+   causing the client to spend a great deal of CPU time computing an
+   incorrect key.
+
+   An intruder spoofing the KDC reply, providing a low iteration count
+   and reading the client's reply from the network, may be able to
+   reduce the work needed in the brute-force attack outlined above.
+   Thus, implementations may seek to enforce lower bounds on the number
+   of iterations that will be used.
+
+   Since threat models and typical end-user equipment will vary widely
+   from site to site, allowing site-specific configuration of such
+   bounds is recommended.
+
+   Any benefit against other attacks specific to the HMAC or SHA-1
+   algorithms is probably achieved with a fairly small number of
+   iterations.
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 7]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   In the "optimistic preauthentication" case mentioned in section 3,
+   the client may attempt to produce a key without first communicating
+   with the KDC.  If the client has no additional information, it can
+   only guess as to the iteration count to be used.  Even such
+   heuristics as "iteration count X was used to acquire tickets for the
+   same principal only N hours ago" can be wrong.  Given the
+   recommendation above for increasing the iteration counts used over
+   time, it is impossible to recommend any specific default value for
+   this case; allowing site-local configuration is recommended.  (If the
+   lower and upper bound checks described above are implemented, the
+   default count for optimistic preauthentication should be between
+   those bounds.)
+
+   Ciphertext stealing mode, as it requires no additional padding in
+   most cases, will reveal the exact length of each message being
+   encrypted rather than merely bounding it to a small range of possible
+   lengths as in CBC mode.  Such obfuscation should not be relied upon
+   at higher levels in any case; if the length must be obscured from an
+   outside observer, this should be done by intentionally varying the
+   length of the message to be encrypted.
+
+9.  IANA Considerations
+
+   Kerberos encryption and checksum type values used in section 7 were
+   previously reserved in [KCRYPTO] for the mechanisms defined in this
+   document.  The registries have been updated to list this document as
+   the reference.
+
+10.  Acknowledgements
+
+   Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
+   Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier
+   versions of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 8]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+A.  Errata for RFC 2040 Section 8
+
+   (Copied from the RFC Editor's errata web site on July 8, 2004.)
+
+   Reported By: Bob Baldwin; baldwin@plusfive.com
+   Date: Fri, 26 Mar 2004 06:49:02 -0800
+
+   In Section 8, Description of RC5-CTS, of the encryption method,
+   it says:
+
+       1. Exclusive-or Pn-1 with the previous ciphertext
+          block, Cn-2, to create Xn-1.
+
+   It should say:
+
+       1. Exclusive-or Pn-1 with the previous ciphertext
+          block, Cn-2, to create Xn-1.  For short messages where
+          Cn-2 does not exist, use IV.
+
+   Reported By: Bob Baldwin; baldwin@plusfive.com
+   Date: Mon, 22 Mar 2004 20:26:40 -0800
+
+   In Section 8, first paragraph, second sentence says:
+
+       This mode handles any length of plaintext and produces ciphertext
+       whose length matches the plaintext length.
+
+   In Section 8, first paragraph, second sentence should read:
+
+       This mode handles any length of plaintext longer than one
+       block and produces ciphertext whose length matches the
+       plaintext length.
+
+   In Section 8, step 6 of the decryption method says:
+
+       6. Decrypt En to create Pn-1.
+
+   In Section 8, step 6 of the decryption method should read:
+
+       6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
+          For short messages where Cn-2 does not exist, use the IV.
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                     [Page 9]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+B.  Sample Test Vectors
+
+   Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
+   included below.
+
+   Iteration count = 1
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+   128-bit AES key:
+       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
+   256-bit PBKDF2 output:
+       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
+       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
+   256-bit AES key:
+       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
+       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
+
+   Iteration count = 2
+   Pass phrase = "password"
+   Salt="ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+   128-bit AES key:
+       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
+   256-bit PBKDF2 output:
+       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
+       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
+   256-bit AES key:
+       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
+       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
+
+   Iteration count = 1200
+   Pass phrase = "password"
+   Salt = "ATHENA.MIT.EDUraeburn"
+   128-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+   128-bit AES key:
+       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
+   256-bit PBKDF2 output:
+       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
+       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
+   256-bit AES key:
+       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
+       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 10]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   Iteration count = 5
+   Pass phrase = "password"
+   Salt=0x1234567878563412
+   128-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+   128-bit AES key:
+       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
+   256-bit PBKDF2 output:
+       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
+       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
+   256-bit AES key:
+       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
+       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
+   (This test is based on values given in [PECMS].)
+
+   Iteration count = 1200
+   Pass phrase = (64 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt="pass phrase equals block size"
+   128-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+   128-bit AES key:
+       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
+   256-bit PBKDF2 output:
+       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
+       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
+   256-bit AES key:
+       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
+       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
+
+   Iteration count = 1200
+   Pass phrase = (65 characters)
+     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
+   Salt = "pass phrase exceeds block size"
+   128-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+   128-bit AES key:
+       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
+   256-bit PBKDF2 output:
+       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
+       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
+   256-bit AES key:
+       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
+       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 11]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   Iteration count = 50
+   Pass phrase = g-clef (0xf09d849e)
+   Salt = "EXAMPLE.COMpianist"
+   128-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+   128-bit AES key:
+       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
+   256-bit PBKDF2 output:
+       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
+       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
+   256-bit AES key:
+       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
+       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
+
+   Some test vectors for CBC with ciphertext stealing, using an initial
+   vector of all-zero.
+
+   AES 128-bit key:
+     0000:  63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20
+   Output:
+     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+     0010:  97
+   Next IV:
+     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
+   Output:
+     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
+   Next IV:
+     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 12]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+   Output:
+     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+   Next IV:
+     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
+   Output:
+     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+     0010:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
+   Next IV:
+     0000:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+   Output:
+     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+     0010:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+   Next IV:
+     0000:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 13]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+   IV:
+     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   Input:
+     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
+     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
+     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
+     0030:  61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
+   Output:
+     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
+     0010:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
+     0020:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+     0030:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
+   Next IV:
+     0000:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
+
+Normative References
+
+   [AC]       Schneier, B., "Applied Cryptography", second edition, John
+              Wiley and Sons, New York, 1996.
+
+   [AES]      National Institute of Standards and Technology, U.S.
+              Department of Commerce, "Advanced Encryption Standard",
+              Federal Information Processing Standards Publication 197,
+              Washington, DC, November 2001.
+
+   [KCRYPTO]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [PKCS5]    Kaliski, B., "PKCS #5: Password-Based Cryptography
+              Specification Version 2.0", RFC 2898, September 2000.
+
+   [RC5]      Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad,
+              and RC5-CTS Algorithms", RFC 2040, October 1996.
+
+   [SHA1]     National Institute of Standards and Technology, U.S.
+              Department of Commerce, "Secure Hash Standard", Federal
+              Information Processing Standards Publication 180-1,
+              Washington, DC, April 1995.
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 14]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+Informative References
+
+   [LEACH]    Leach, P., email to IETF Kerberos working group mailing
+              list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail-
+              archive/krb-wg/2003-05.mail.
+
+   [PECMS]    Gutmann, P., "Password-based Encryption for CMS", RFC
+              3211, December 2001.
+
+Author's Address
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   EMail: raeburn@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 15]
+
+RFC 3962             AES Encryption for Kerberos 5         February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Raeburn                     Standards Track                    [Page 16]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4043.txt b/third_party/heimdal/doc/standardisation/rfc4043.txt
new file mode 100644
index 00000000000..c31b30d8805
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4043.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          D. Pinkas
+Request for Comments: 4043                                          Bull
+Category: Standards Track                                      T. Gindin
+                                                                     IBM
+                                                                May 2005
+
+
+                Internet X.509 Public Key Infrastructure
+                          Permanent Identifier
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines a new form of name, called permanent
+   identifier, that may be included in the subjectAltName extension of a
+   public key certificate issued to an entity.
+
+   The permanent identifier is an optional feature that may be used by a
+   CA to indicate that two or more certificates relate to the same
+   entity, even if they contain different subject name (DNs) or
+   different names in the subjectAltName extension, or if the name or
+   the affiliation of that entity stored in the subject or another name
+   form in the subjectAltName extension has changed.
+
+   The subject name, carried in the subject field, is only unique for
+   each subject entity certified by the one CA as defined by the issuer
+   name field.  However, the new name form can carry a name that is
+   unique for each subject entity certified by a CA.
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 1]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Table of Contents
+
+   1.  Introduction..................................................  2
+   2.  Definition of a Permanent Identifier..........................  3
+   3.  IANA Considerations...........................................  6
+   4.  Security Considerations.......................................  6
+   5.  References....................................................  7
+       5.1.  Normative References....................................  7
+       5.2.  Informative References..................................  8
+   Appendix A. ASN.1 Syntax..........................................  9
+       A.1.  1988 ASN.1 Module.......................................  9
+       A.2.  1993 ASN.1 Module....................................... 10
+   Appendix B. OID's for organizations............................... 11
+       B.1.  Using IANA (Internet Assigned Numbers Authority)........ 11
+       B.2.  Using an ISO Member Body................................ 12
+       B.3.  Using an ICD (International Code Designator) From
+             British Standards Institution to Specify a New or
+             an Existing Identification Scheme....................... 12
+   Authors' Addresses................................................ 14
+   Full Copyright Statement.......................................... 15
+
+1.  Introduction
+
+   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 [RFC2119].
+
+   This specification is based on [RFC3280], which defines underlying
+   certificate formats and semantics needed for a full implementation of
+   this standard.
+
+   The subject field of a public key certificate identifies the entity
+   associated with the public key stored in the subject public key
+   field.  Names and identities of a subject may be carried in the
+   subject field and/or the subjectAltName extension.  Where subject
+   field is non-empty, it MUST contain an X.500 distinguished name (DN).
+   The DN MUST be unique for each subject entity certified by a single
+   CA as defined by the issuer name field.
+
+   The subject name changes whenever any of the components of that name
+   gets changed.  There are several reasons for such a change to happen.
+
+      For employees of a company or organization, the person may get a
+      different position within the same company and thus will move from
+      one organization unit to another one.  Including the organization
+      unit in the name may however be very useful to allow the relying
+      parties (RP's) using that certificate to identify the right
+      individual.
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 2]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+      For citizens, an individual may change their name by legal
+      processes, especially as a result of marriage.
+
+      Any certificate subject identified by geographical location may
+      relocate and change at least some of the location attributes
+      (e.g., country name, state or province, locality, or street).
+
+   A permanent identifier consists of an identifier value assigned
+   within a given naming space by the organization which is
+   authoritative for that naming space.  The organization assigning the
+   identifier value may be the CA that has issued the certificate or a
+   different organization called an Assigner Authority.
+
+   An Assigner Authority may be a government, a government agency, a
+   corporation, or any other sort of organization.  It MUST have a
+   unique identifier to distinguish it from any other such authority.
+   In this standard, that identifier MUST be an object identifier.
+
+   A permanent identifier may be useful in three contexts: access
+   control, non-repudiation and audit records.
+
+      For access control, the permanent identifier may be used in an ACL
+      (Access Control List) instead of the DN or any other form of name
+      and would not need to be changed, even if the subject name of the
+      entity changes.  For non-repudiation, the permanent identifier may
+      be used to link different transactions to the same entity, even
+      when the subject name of the entity changes.
+
+      For audit records, the permanent identifier may be used to link
+      different audit records to the same entity, even when the subject
+      name of the entity changes.
+
+   For two certificates which have been both verified to be valid
+   according to a given validation policy and which contain a permanent
+   identifier, those certificates relate to the same entity if their
+   permanent identifiers match, whatever the content of the DN or other
+   subjectAltName components may be.
+
+   Since the use of permanent identifiers may conflict with privacy, CAs
+   SHOULD advertise to purchasers of certificates the use of permanent
+   identifiers in certificates.
+
+2.  Definition of a Permanent Identifier
+
+   This Permanent Identifier is a name defined as a form of otherName
+   from the GeneralName structure in SubjectAltName, as defined in
+   [X.509] and [RFC3280].
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 3]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   A CA which includes a permanent identifier in a certificate is
+   certifying that any public key certificate containing the same values
+   for that identifier refers to the same entity.
+
+   The use of a permanent identifier is OPTIONAL.  The permanent
+   identifier is defined as follows:
+
+      id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+        PermanentIdentifier ::=     SEQUENCE {
+           identifierValue    UTF8String             OPTIONAL,
+                           -- if absent, use a serialNumber attribute,
+                           -- if there is such an attribute present
+                           -- in the subject DN
+           assigner           OBJECT IDENTIFIER      OPTIONAL
+                           -- if absent, the assigner is
+                           -- the certificate issuer
+   }
+
+   The identifierValue field is optional.
+
+      When the identifierValue field is present, then the
+      identifierValue supports one syntax: UTF8String.
+
+      When the identifierValue field is absent, then the value of the
+      serialNumber attribute (as defined in section 5.2.9 of [X.520])
+      from the deepest RDN of the subject DN is the value to be taken
+      for the identifierValue.  In such a case, there MUST be at least
+      one serialNumber attribute in the subject DN, otherwise the
+      PermanentIdentifier SHALL NOT be used.
+
+   The assigner field is optional.
+
+      When the assigner field is present, then it is an OID which
+      identifies a naming space, i.e., both an Assigner Authority and
+      the type of that field.  Characteristically, the prefix of the OID
+      identifies the Assigner Authority, and a suffix is used to
+      identify the type of permanent identifier.
+
+      When the assigner field is absent, then the permanent identifier
+      is locally unique to the CA.
+
+   The various combinations are detailed below:
+
+   1. Both the assigner and the identifierValue fields are present:
+
+      The identifierValue is the value for that type of identifier.  The
+      assigner field identifies the Assigner Authority and the type of
+      permanent identifier being identified.
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 4]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+      The permanent identifier is globally unique among all CAs.  In
+      such a case, two permanent identifiers of this type match if and
+      only if their assigner fields match and the contents of the
+      identifierValue field in the two permanent identifiers consist of
+      the same Unicode code points presented in the same order.
+
+   2. The assigner field is absent and the identifierValue field is
+      present:
+
+      The Assigner Authority is the CA that has issued the certificate.
+      The identifierValue is given by the CA and the permanent
+      identifier is only local to the CA that has issued the
+      certificate.
+
+      In such a case, two permanent identifiers of this type match if
+      and only if the issuer DN's in the certificates which contain them
+      match using the distinguishedNameMatch rule, as defined in X.501,
+      and the two values of the identifierValue field consist of the
+      same Unicode code points presented in the same order.
+
+   3. Both the assigner and the identifierValue fields are absent:
+
+      If there are one or more RDNs containing a serialNumber attribute
+      (alone or accompanied by other attributes), then the value
+      contained in the serialNumber of the deepest such RDN SHALL be
+      used as the identifierValue; otherwise, the Permanent Identifier
+      definition is invalid and the Permanent Identifier SHALL NOT be
+      used.
+
+      The permanent identifier is only local to the CA that has issued
+      the certificate.  In such a case, two permanent identifiers of
+      this type match if and only if the issuer DN's in the certificates
+      which contain them match and the serialNumber attributes within
+      the subject DN's of those same certificates also match using the
+      caseIgnoreMatch rule.
+
+   4. The assigner field is present and the identifierValue field is
+      absent:
+
+      If there are one or more RDNs containing a serialNumber attribute
+      (alone or accompanied by other attributes), then the value
+      contained in the serialNumber of the deepest such RDN SHALL be
+      used as the identifierValue; otherwise, the Permanent Identifier
+      definition is invalid and the Permanent Identifier SHALL NOT be
+      used.
+
+      The assigner field identifies the Assigner Authority and the type
+      of permanent identifier being identified.
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 5]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+      The permanent identifier is globally unique among all CAs.  In
+      such a case, two permanent identifiers of this type match if and
+      only if their assigner fields match and the contents of the
+      serialNumber attributes within the subject DN's of those same
+      certificates match using the caseIgnoreMatch rule.
+
+   Note: The full arc of the object identifier used to identify the
+         permanent identifier name form is derived using:
+
+      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+         dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+      id-on OBJECT IDENTIFIER ::= { id-pkix 8 }   -- other name forms
+
+3.  IANA Considerations
+
+   No IANA actions are necessary.  However, a Private Enterprise Number
+   may be used to construct an OID for the assigner field (see Annex
+   B.1.).
+
+4.  Security Considerations
+
+   A given entity may have at an instant of time or at different
+   instants of time multiple forms of identities.  If the permanent
+   identifier is locally unique to the CA (i.e., the assigner field is
+   not present), then two certificates from the same CA can be compared.
+
+   When two certificates contain identical permanent identifiers, then a
+   relying party may determine that they refer to the same entity.
+
+   If the permanent identifier is globally unique among all CAs (i.e.,
+   the assigner field is present), then two certificates from different
+   CAs can be compared.  When they contain two identical permanent
+   identifiers, then a relying party may determine that they refer to
+   the same entity.  It is the responsibility of the CA to verify that
+   the permanent identifier being included in the certificate refers to
+   the subject being certified.
+
+   The permanent identifier identifies the entity, irrespective of any
+   attribute extension.  When a public key certificate contains
+   attribute extensions, the permanent identifier, if present, should
+   not be used for access control purposes but only for audit purposes.
+   The reason is that since these attributes may change, access could be
+   granted on attributes that were originally present in a certificate
+   issued to that entity but are no longer present in the current
+   certificate.
+
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 6]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   Subject names in certificates are chosen by the issuing CA and are
+   mandated to be unique for each CA; so there can be no name collision
+   between subject names from the same CA.  Such a name may be an end-
+   entity name when the certificate is a leaf certificate, or a CA name,
+   when it is a CA certificate.
+
+   Since a name is only unique towards its superior CA, unless some
+   naming constraints are being used, a name would only be guaranteed to
+   be globally unique when considered to include a sequence of all the
+   names of the superior CAs.  Thus, two certificates that are issued
+   under the same issuer DN and which contain the same permanent
+   identifier extension without an assigner field do not necessarily
+   refer to the same entity.
+
+   Additional checks need to be done, e.g., to check if the public key
+   values of the two CAs which have issued the certificates to be
+   compared are identical or if the sequence of CA names in the
+   certification path from the trust anchor to the CA are identical.
+
+   When the above checks fail, the permanent identifiers may still match
+   if there has been a CA key rollover.  In such a case the checking is
+   more complicated.
+
+   The certification of different CAs with the same DN by different CAs
+   has other negative consequences in various parts of the PKI, notably
+   rendering the IssuerAndSerialNumber structure in [RFC3852] section
+   10.2.4 ambiguous.
+
+   The permanent identifier allows organizations to create links between
+   different certificates associated with an entity issued with or
+   without overlapping validity periods.  This ability to link different
+   certificates may conflict with privacy.  It is therefore important
+   that a CA clearly disclose any plans to issue certificates which
+   include a permanent identifier to potential subjects of those
+   certificates.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 7]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [X.501]    ITU-T Rec X.501 | ISO 9594-2: 2001: Information technology
+              - Open Systems Interconnection - The Directory: Models,
+              February 2001.
+
+5.2.  Informative References
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+              3852, July 2004.
+
+   [X.509]    ITU-T Recommendation X.509 (1997 E): Information
+              Technology - Open Systems Interconnection - The Directory:
+              Authentication Framework, June 1997.
+
+   [X.520]    ITU-T Recommendation X.520: Information Technology - Open
+              Systems Interconnection - The Directory: Selected
+              Attribute Types, June 1997.
+
+   [X.660]    ITU-T Recommendation X.660: Information Technology - Open
+              Systems Interconnection - Procedures for the Operation of
+              OSI Registration Authorities: General Procedures, 1992.
+
+   [X.680]    ITU-T Recommendation X.680: Information Technology -
+              Abstract Syntax Notation One, 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 8]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Appendix A.  ASN.1 Syntax
+
+   As in RFC 2459, ASN.1 modules are supplied in two different variants
+   of the ASN.1 syntax.
+
+   This section describes data objects used by conforming PKI components
+   in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
+   1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
+   the UNIVERSAL Type UTF8String.
+
+   The ASN.1 syntax does not permit the inclusion of type statements in
+   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
+   the new UNIVERSAL types in modules using the 1988 syntax.  As a
+   result, this module does not conform to either version of the ASN.1
+   standard.
+
+   Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the
+   definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
+
+   Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 parser.
+
+   In case of discrepancies between these modules, the 1988 module is
+   the normative one.
+
+Appendix A.1.  1988 ASN.1 Module
+
+  PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6)
+         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+         id-mod-perm-id-88(28) }
+
+  DEFINITIONS EXPLICIT TAGS ::=
+
+     BEGIN
+
+     -- EXPORTS ALL --
+
+     IMPORTS
+
+  -- UTF8String, / move hyphens before slash if UTF8String does not
+  -- resolve with your compiler
+  -- The content of this type conforms to [UTF-8].
+
+          id-pkix
+                FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+                dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+                id-mod(0) id-pkix1-explicit(18) } ;
+                -- from [RFC3280]
+
+
+
+
+Pinkas & Gindin             Standards Track                     [Page 9]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+     -- Permanent identifier Object Identifier and Syntax
+
+     id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }
+
+     id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+
+     PermanentIdentifier ::= SEQUENCE {
+          identifierValue    UTF8String             OPTIONAL,
+                          -- if absent, use the serialNumber attribute
+                          -- if there is a single such attribute present
+                          -- in the subject DN
+          assigner           OBJECT IDENTIFIER      OPTIONAL
+                          -- if absent, the assigner is
+                          -- the certificate issuer
+  }
+
+  END
+
+Appendix A.2.  1993 ASN.1 Module
+
+PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
+       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+       id-mod-perm-id-93(29) }
+
+   DEFINITIONS EXPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+
+        id-pkix
+              FROM PKIX1Explicit88 { iso(1) identified-organization(3)
+              dod(6) internet(1) security(5) mechanisms(5) pkix(7)
+              id-mod(0) id-pkix1-explicit(18) }
+               -- from [RFC3280]
+
+        ATTRIBUTE
+              FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
+              informationFramework(1) 4};
+               -- from [X.501]
+
+   -- Permanent identifier Object Identifiers
+
+   id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }
+
+   id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 10]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   -- Permanent Identifier
+
+   permanentIdentifier ATTRIBUTE ::= {
+          WITH SYNTAX     PermanentIdentifier
+          ID              id-on-permanentIdentifier }
+
+   PermanentIdentifier ::= SEQUENCE {
+        identifierValue    UTF8String             OPTIONAL,
+                        -- if absent, use the serialNumber attribute
+                        -- if there is a single such attribute present
+                        -- in the subject DN
+        assigner           OBJECT IDENTIFIER      OPTIONAL
+                        -- if absent, the assigner is
+                        -- the certificate issuer
+}
+
+END
+
+Appendix B.  OID's for Organizations
+
+   In order to construct an OID for the assigner field, organizations
+   need first to have a registered OID for themselves.  Such an OID must
+   be obtained from a registration authority following [X.660].  In some
+   cases, OID's are provided for free.  In other cases a one-time fee is
+   required.  The main difference lies in the nature of the information
+   that is collected at the time of registration and how this
+   information is verified for its accuracy.
+
+Appendix B.1.  Using IANA (Internet Assigned Numbers Authority)
+
+   The application form for a Private Enterprise Number in the IANA's
+   OID list is: http://www.iana.org/cgi-bin/enterprise.pl.
+
+   Currently, IANA assigns numbers for free.  The IANA-registered
+   Private Enterprises prefix is:
+   iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)
+
+   These numbers are used, among other things, for defining private SNMP
+   MIBs.
+
+   The official assignments under this OID are stored in the IANA file
+   "enterprise-numbers" available at:
+   http://www.iana.org/assignments/enterprise-numbers
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 11]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Appendix B.2.  Using an ISO Member Body
+
+   ISO has defined the OID structure in a such a way so that every ISO
+   member-body has its own unique OID.  Then every ISO member-body is
+   free to allocate its own arc space below.
+
+   Organizations and enterprises may contact the ISO member-body where
+   their organization or enterprise is established to obtain an
+   organization/enterprise OID.
+
+   Currently, ISO members do not assign organization/enterprise OID's
+   for free.
+
+   Most of them do not publish registries of such OID's which they have
+   assigned, sometimes restricting the access to registered
+   organizations or preferring to charge inquirers for the assignee of
+   an OID on a per-inquiry basis.  The use of OID's from an ISO member
+   organization which does not publish such a registry may impose extra
+   costs on the CA that needs to make sure that the OID corresponds to
+   the registered organization.
+
+   As an example, AFNOR (Association Francaise de Normalisation - the
+   French organization that is a member of ISO) has defined an arc to
+   allocate OID's for companies:
+
+   {iso (1) member-body (2) fr (250) type-org (1) organisation (n)}
+
+Appendix B.3.  Using an ICD (International Code Designator) From British
+               Standards Institution to Specify a New or an Existing
+               Identification Scheme
+
+   The International Code Designator (ICD) is used to uniquely identify
+   an ISO 6523 compliant organization identification scheme.  ISO 6523
+   is a standard that defines the proper structure of an identifier and
+   the registration procedure for an ICD.  The conjunction of the ICD
+   with an identifier issued by the registration authority is worldwide
+   unique.
+
+   The basic structure of the code contains the following components:
+
+   -  the ICD value: The International Code Designator issued to the
+      identification scheme makes the identifier worldwide unique (up to
+      4 digits),
+
+   -  the Organization, usually a company or governmental body (up to 35
+      characters),
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 12]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+   -  an Organization Part (OPI - Organization Part Identifier).  An
+      identifier allocated to a particular Organization Part (optional,
+      up to 35 characters)
+
+   The ICD is also equivalent to an object identifier (OID) under the
+   arc {1(iso).  3(identified organization)}.
+
+   On behalf of ISO, British Standards Institution (BSI) is the
+   Registration Authority for organizations under the arc {iso (1)
+   org(3)}.  This means BSI registers code issuing authorities
+   (organizations) by ICD values which are equivalent to OIDs of the
+   form {iso (1) org(3) icd(xxxx)}.  The corresponding IdentifierValue
+   is the code value of the scheme identified by icd(xxxx).
+
+   As an example, the ICD 0012 was allocated to European Computer
+   Manufacturers Association: ECMA.  Thus the OID for ECMA is {iso(1)
+   org(3) ecma(12)}.
+
+   For registration with BSI, a "Sponsoring Authority" has to vouch for
+   the Applying organization.  Registration is not free.  Recognized
+   "Sponsoring Authorities" are: ISO Technical Committees or
+   (Sub)Committees, Member Bodies of ISO or International Organizations
+   having a liaison status with ISO or with any of its Technical
+   (Sub)Committees.
+
+   An example of a Sponsoring Authority is the EDIRA Association (EDI/EC
+   Registration Authority, web: http://www.edira.org,
+   email:info@edira.org).
+
+   The numerical list of all ICDs that have been issued is posted on its
+   webpage: http://www.edira.org/documents.htm#icd-List
+
+   Note: IANA owns ICD code 0090, but (presumably) it isn't intending to
+   use it for the present purpose.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 13]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Authors' Addresses
+
+   Denis Pinkas
+   Bull
+   Rue Jean-Jaures BP 68
+   78340 Les Clayes-sous-Bois
+   FRANCE
+
+   EMail: Denis.Pinkas@bull.net
+
+
+   Thomas Gindin
+   IBM Corporation
+   6710 Rockledge Drive
+   Bethesda, MD 20817
+   USA
+
+   EMail: tgindin@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 14]
+
+RFC 4043                  Permanent Identifier                  May 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Pinkas & Gindin             Standards Track                    [Page 15]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4108.txt b/third_party/heimdal/doc/standardisation/rfc4108.txt
new file mode 100644
index 00000000000..8119548a92c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4108.txt
@@ -0,0 +1,3419 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 4108                                Vigil Security
+Category: Standards Track                                    August 2005
+
+
+ Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes the use of the Cryptographic Message Syntax
+   (CMS) to protect firmware packages, which provide object code for one
+   or more hardware module components.  CMS is specified in RFC 3852.  A
+   digital signature is used to protect the firmware package from
+   undetected modification and to provide data origin authentication.
+   Encryption is optionally used to protect the firmware package from
+   disclosure, and compression is optionally used to reduce the size of
+   the protected firmware package.  A firmware package loading receipt
+   can optionally be generated to acknowledge the successful loading of
+   a firmware package.  Similarly, a firmware package load error report
+   can optionally be generated to convey the failure to load a firmware
+   package.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 1]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................5
+      1.2. Architectural Elements .....................................5
+           1.2.1. Hardware Module Requirements ........................7
+           1.2.2. Firmware Package Requirements .......................8
+           1.2.3. Bootstrap Loader Requirements .......................9
+                  1.2.3.1. Legacy Stale Version Processing ...........11
+                  1.2.3.2. Preferred Stale Version Processing ........12
+           1.2.4. Trust Anchors ......................................12
+           1.2.5. Cryptographic and Compression Algorithm
+                  Requirements .......................................13
+      1.3. Hardware Module Security Architecture .....................14
+      1.4. ASN.1 Encoding ............................................14
+      1.5. Protected Firmware Package Loading ........................15
+   2. Firmware Package Protection ....................................15
+      2.1. Firmware Package Protection CMS Content Type Profile ......18
+           2.1.1. ContentInfo ........................................18
+           2.1.2. SignedData .........................................18
+                  2.1.2.1. SignerInfo ................................19
+                  2.1.2.2. EncapsulatedContentInfo ...................20
+           2.1.3. EncryptedData ......................................20
+                  2.1.3.1. EncryptedContentInfo ......................21
+           2.1.4. CompressedData .....................................21
+                  2.1.4.1. EncapsulatedContentInfo ...................22
+           2.1.5. FirmwarePkgData ....................................22
+      2.2. Signed Attributes .........................................22
+           2.2.1. Content Type .......................................23
+           2.2.2. Message Digest .....................................24
+           2.2.3. Firmware Package Identifier ........................24
+           2.2.4. Target Hardware Module Identifiers .................25
+           2.2.5. Decrypt Key Identifier .............................26
+           2.2.6. Implemented Crypto Algorithms ......................26
+           2.2.7. Implemented Compression Algorithms .................27
+           2.2.8. Community Identifiers ..............................27
+           2.2.9. Firmware Package Information .......................29
+           2.2.10. Firmware Package Message Digest ...................30
+           2.2.11. Signing Time ......................................30
+           2.2.12. Content Hints .....................................31
+           2.2.13. Signing Certificate ...............................31
+      2.3. Unsigned Attributes .......................................32
+           2.3.1. Wrapped Firmware Decryption Key ....................33
+   3. Firmware Package Load Receipt ..................................34
+      3.1. Firmware Package Load Receipt CMS Content Type Profile ....36
+           3.1.1. ContentInfo ........................................36
+
+
+
+
+
+Housley                     Standards Track                     [Page 2]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+           3.1.2. SignedData .........................................36
+                  3.1.2.1. SignerInfo ................................37
+                  3.1.2.2. EncapsulatedContentInfo ...................38
+           3.1.3. FirmwarePackageLoadReceipt .........................38
+      3.2. Signed Attributes .........................................40
+           3.2.1. Content Type .......................................40
+           3.2.2. Message Digest .....................................40
+           3.2.3. Signing Time .......................................40
+   4. Firmware Package Load Error ....................................41
+      4.1. Firmware Package Load Error CMS Content Type Profile ......42
+           4.1.1. ContentInfo ........................................42
+           4.1.2. SignedData .........................................43
+                  4.1.2.1. SignerInfo ................................43
+                  4.1.2.2. EncapsulatedContentInfo ...................43
+           4.1.3. FirmwarePackageLoadError ...........................43
+      4.2. Signed Attributes .........................................49
+           4.2.1. Content Type .......................................49
+           4.2.2. Message Digest .....................................49
+           4.2.3. Signing Time .......................................50
+   5. Hardware Module Name ...........................................50
+   6. Security Considerations ........................................51
+      6.1. Cryptographic Keys and Algorithms .........................51
+      6.2. Random Number Generation ..................................51
+      6.3. Stale Firmware Package Version Number .....................52
+      6.4. Community Identifiers .....................................53
+   7. References .....................................................54
+      7.1. Normative References ......................................54
+      7.2. Informative References ....................................54
+   Appendix A: ASN.1 Module ..........................................56
+
+1.  Introduction
+
+   This document describes the use of the Cryptographic Message Syntax
+   (CMS) [CMS] to protect firmware packages.  This document also
+   describes the use of CMS for receipts and error reports for firmware
+   package loading.  The CMS is a data protection encapsulation syntax
+   that makes use of ASN.1 [X.208-88, X.209-88].  The protected firmware
+   package can be associated with any particular hardware module;
+   however, this specification was written with the requirements of
+   cryptographic hardware modules in mind, as these modules have strong
+   security requirements.
+
+   The firmware package contains object code for one or more
+   programmable components that make up the hardware module.  The
+   firmware package, which is treated as an opaque binary object, is
+   digitally signed.  Optional encryption and compression are also
+   supported.  When all three are used, the firmware package is
+   compressed, then encrypted, and then signed.  Compression simply
+
+
+
+Housley                     Standards Track                     [Page 3]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   reduces the size of the firmware package, allowing more efficient
+   processing and transmission.  Encryption protects the firmware
+   package from disclosure, which allows transmission of sensitive
+   firmware packages over insecure links.  The encryption algorithm and
+   mode employed may also provide integrity, protecting the firmware
+   package from undetected modification.  The encryption protects
+   proprietary algorithms, classified algorithms, trade secrets, and
+   implementation techniques.  The digital signature protects the
+   firmware package from undetected modification and provides data
+   origin authentication.  The digital signature allows the hardware
+   module to confirm that the firmware package comes from an acceptable
+   source.
+
+   If encryption is used, the firmware-decryption key must be made
+   available to the hardware module via a secure path.  The key might be
+   delivered via physical media or via an independent electronic path.
+   One optional mechanism for distributing the firmware-decryption key
+   is specified in Section 2.3.1, but any secure key distribution
+   mechanism is acceptable.
+
+   The signature verification public key must be made available to the
+   hardware module in a manner that preserves its integrity and confirms
+   its source.  CMS supports the transfer of certificates, and this
+   facility can be used to transfer a certificate that contains the
+   signature verification public key (a firmware-signing certificate).
+   However, use of this facility introduces a level of indirection.
+   Ultimately, a trust anchor public key must be made available to the
+   hardware module.  Section 1.2 establishes a requirement that the
+   hardware module store one or more trust anchors.
+
+   Hardware modules may not be capable of accessing certificate
+   repositories or delegated path discovery (DPD) servers [DPD&DPV] to
+   acquire certificates needed to complete a certification path.  Thus,
+   it is the responsibility of the firmware package signer to include
+   sufficient certificates to enable each module to validate the
+   firmware-signer certificate (see Section 2.1.2).  Similarly, hardware
+   modules may not be capable of accessing a certificate revocation list
+   (CRL) repository, an OCSP responder [OCSP], or a delegated path
+   validation (DPV) server [DPD&DPV] to acquire revocation status
+   information.  Thus, if the firmware package signature cannot be
+   validated solely with the trust anchor public key and the hardware
+   module is not capable of performing full certification path
+   validation, then it is the responsibility of the entity loading a
+   package into a hardware module to validate the firmware-signer
+   certification path prior to loading the package into a hardware
+   module.  The means by which this external certificate revocation
+   status checking is performed is beyond the scope of this
+   specification.
+
+
+
+Housley                     Standards Track                     [Page 4]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Hardware modules will only accept firmware packages with a valid
+   digital signature.  The signature is either validated directly using
+   the trust anchor public key or using a firmware-signer certification
+   path that is validated to the trust anchor public key.  Thus, the
+   trust anchors define the set of entities that can create firmware
+   packages for the hardware module.
+
+   The disposition of a previously loaded firmware package after the
+   successful validation of another firmware package is beyond the scope
+   of this specification.  The amount of memory available to the
+   hardware module will determine the range of alternatives.
+
+   In some cases, hardware modules can generate receipts to acknowledge
+   the loading of a particular firmware package.  Such receipts can be
+   used to determine which hardware modules need to receive an updated
+   firmware package whenever a flaw in an earlier firmware package is
+   discovered.  Hardware modules can also generate error reports to
+   indicate the unsuccessful firmware package loading.  To implement
+   either receipt or error report generation, the hardware module is
+   required to have a unique permanent serial number.  Receipts and
+   error reports can be either signed or unsigned.  To generate
+   digitally signed receipts or error reports, a hardware module MUST be
+   issued its own private signature key and a certificate that contains
+   the corresponding signature validation public key.  In order to save
+   memory with the hardware module, the hardware module might store a
+   certificate designator instead of the certificate itself.  The
+   private signature key requires secure storage.
+
+1.1.  Terminology
+
+   In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
+   described in [STDWORDS].
+
+1.2.  Architectural Elements
+
+   The architecture includes the hardware module, the firmware package,
+   and a bootstrap loader.  The bootstrap loader MUST have access to one
+   or more trusted public keys, called trust anchors, to validate the
+   signature on the firmware package.  If a signed firmware package load
+   receipt or error report is created on behalf of the hardware module,
+   then the bootstrap loader MUST have access to a private signature key
+   to generate the signature and the signer identifier for the
+   corresponding signature validation certificate or its designator.  A
+   signature validation certificate MAY be included to aid signature
+   validation.  To implement this optional capability, the hardware
+   module MUST have a unique serial number and a private signature key;
+   the hardware module MAY also include a certificate that contains the
+
+
+
+Housley                     Standards Track                     [Page 5]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   corresponding signature validation public key.  These items MUST be
+   installed in the hardware module before it is deployed.  The private
+   key and certificate can be generated and installed as part of the
+   hardware module manufacture process.  Figure 1 illustrates these
+   architectural elements.
+
+   ASN.1 object identifiers are the preferred means of naming the
+   architectural elements.
+
+   Details of managing the trust anchors are beyond the scope of this
+   specification.  However, one or more trust anchors MUST be installed
+   in the hardware module using a secure process before it is deployed.
+   These trust anchors provide a means of controlling the acceptable
+   sources of firmware packages.  The hardware module vendor can include
+   provisions for secure, remote management of trust anchors.  One
+   approach is to include trust anchors in the firmware packages
+   themselves.  This approach is analogous to the optional capability
+   described later for updating the bootstrap loader.
+
+   In a cryptographic hardware module, the firmware package might
+   implement many different cryptographic algorithms.
+
+   When the firmware package is encrypted, the firmware-decryption key
+   and the firmware package MUST both be provided to the hardware
+   module.  The firmware-decryption key is necessary to use the
+   associated firmware package.  Generally, separate distribution
+   mechanisms will be employed for the firmware-decryption key and the
+   firmware package.  An optional mechanism for securely distributing
+   the firmware-decryption key with the firmware package is specified in
+   Section 2.3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 6]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+            +------------------------------------------------------+
+            |  Hardware Module                                     |
+            |                                                      |
+            |   +---------------+   +--------------------------+   |
+            |   |  Bootstrap    |   |  Firmware Package        |   |
+            |   |  Loader       |   |                          |   |
+            |   +---------------+   |   +------------------+   |   |
+            |                       |   : Firmware Package :   |   |
+            |   +---------------+   |   : Identifier and   :   |   |
+            |   |  Trust        |   |   : Version Number   :   |   |
+            |   |  Anchor(s)    |   |   +------------------+   |   |
+            |   +---------------+   |                          |   |
+            |                       |   +-------------+        |   |
+            |   +---------------+   |   : Algorithm 1 :        |   |
+            |   |  Serial Num.  |   |   +-+-----------+-+      |   |
+            |   +---------------+   |     : Algorithm 2 :      |   |
+            |                       |     +-+-----------+-+    |   |
+            |   +---------------+   |       : Algorithm n :    |   |
+            |   |  Hardware     |   |       +-------------+    |   |
+            |   |  Module Type  |   |                          |   |
+            |   +---------------+   +--------------------------+   |
+            |                                                      |
+            |        +------------------------------------+        |
+            |        |  Optional Private Signature Key &  |        |
+            |        |  Signature Validation Certificate  |        |
+            |        |  or the Certificate Designator     |        |
+            |        +------------------------------------+        |
+            |                                                      |
+            +------------------------------------------------------+
+
+                     Figure 1.  Architectural Elements
+
+1.2.1.  Hardware Module Requirements
+
+   Many different vendors develop hardware modules, and each vendor
+   typically identifies its modules by product type (family) and
+   revision level.  A unique object identifier MUST name each hardware
+   module type and revision.
+
+   Each hardware module within a hardware module family SHOULD have a
+   unique permanent serial number.  However, if the optional receipt or
+   error report generation capability is implemented, then the hardware
+   module MUST have a unique permanent serial number.  If the optional
+   receipt or error report signature capability is implemented, then the
+   hardware module MUST have a private signature key and a certificate
+   containing the corresponding public signature validation key or its
+   designator.  If a serial number is present, the bootstrap loader uses
+
+
+
+
+Housley                     Standards Track                     [Page 7]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   it for authorization decisions (see Section 2.2.8), receipt
+   generation (see Section 3), and error report generation (see
+   Section 4).
+
+   When the hardware module includes more than one firmware-programmable
+   component, the bootstrap loader distributes components of the package
+   to the appropriate components within the hardware module after the
+   firmware package is validated.  The bootstrap loader is discussed
+   further in Section 1.2.3.
+
+1.2.2.  Firmware Package Requirements
+
+   Two approaches to naming firmware packages are supported: legacy and
+   preferred.  Firmware package names are placed in a CMS signed
+   attribute, not in the firmware package itself.
+
+   Legacy firmware package names are simply octet strings, and no
+   structure is assumed.  This firmware package name form is supported
+   in order to facilitate existing configuration management systems.  We
+   assume that the firmware signer and the bootstrap loader will
+   understand any internal structure to the octet string.  In
+   particular, given two legacy firmware package names, we assume that
+   the firmware signer and the bootstrap loader will be able to
+   determine which one represents the newer version of the firmware
+   package.  This capability is necessary to implement the stale version
+   feature.  If a firmware package with a disastrous flaw is released,
+   subsequent firmware package versions MAY designate a stale legacy
+   firmware package name in order to prevent subsequent rollback to the
+   stale version or versions earlier than the stale version.
+
+   Preferred firmware package names are a combination of the firmware
+   package object identifier and a version number.  A unique object
+   identifier MUST identify the collection of features that characterize
+   the firmware package.  For example, firmware packages for a cable
+   modem and a wireless LAN network interface card warrant distinct
+   object identifiers.  Similarly, firmware packages that implement
+   distinct suites of cryptographic algorithms and modes of operation,
+   or that emulate different (non-programmable) cryptographic devices
+   warrant distinct object identifiers.  The version number MUST
+   identify a particular build or release of the firmware package.  The
+   version number MUST be a monotonically increasing non-negative
+   integer.  Generally, an earlier version is replaced with a later one.
+   If a firmware package with a disastrous flaw is released, subsequent
+   firmware package versions MAY designate a stale version number to
+   prevent subsequent rollback to the stale version or versions earlier
+   than the stale version.
+
+
+
+
+
+Housley                     Standards Track                     [Page 8]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Firmware packages are developed to run on one or more hardware module
+   type.  The firmware package digital signature MUST bind the list of
+   supported hardware module object identifiers to the firmware package.
+
+   In many cases, the firmware package signature will be validated
+   directly with the trust anchor public key, avoiding the need to
+   construct certification paths.  Alternatively, the trust anchor can
+   delegate firmware package signing to another public key through a
+   certification path.  In the latter case, the firmware package SHOULD
+   contain the certificates needed to construct the certification path
+   that begins with a certificate issued by the trust anchors and ends
+   with a certificate issued to the firmware package signer.
+
+   The firmware package MAY contain a list of community identifiers.
+   These identifiers name the hardware modules that are authorized to
+   load the firmware package.  If the firmware package contains a list
+   of community identifiers, then the bootstrap loader MUST reject the
+   firmware package if the hardware module is not a member of one of the
+   identified communities.
+
+   When a hardware module includes multiple programmable components, the
+   firmware package SHOULD contain executable code for all of the
+   components.  Internal tagging within the firmware package MUST tell
+   the bootstrap loader which portion of the overall firmware package is
+   intended for each component; however, this tagging is expected to be
+   specific to each hardware module.  Because this specification treats
+   the firmware package as an opaque binary object, the format of the
+   firmware package is beyond the scope of this specification.
+
+1.2.3.  Bootstrap Loader Requirements
+
+   The bootstrap loader MUST have access to a physical interface and any
+   related driver or protocol software necessary to obtain a firmware
+   package.  The same interface SHOULD be used to deliver receipts and
+   error reports.  Details of the physical interface as well as the
+   driver or protocol software are beyond the scope of this
+   specification.
+
+   The bootstrap loader can be a permanent part of the hardware module,
+   or it can be replaced by loading a firmware package.  In Figure 1,
+   the bootstrap loader is implemented as separate logic within the
+   hardware module.  Not all hardware modules will include the ability
+   to replace or update the bootstrap loader, and this specification
+   does not mandate such support.
+
+   If the bootstrap loader can be loaded by a firmware package, an
+   initial bootstrap loader MUST be installed in non-volatile memory
+   prior to deployment.  All bootstrap loaders, including an initial
+
+
+
+Housley                     Standards Track                     [Page 9]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   bootstrap loader if one is employed, MUST meet the requirements in
+   this section.  However, the firmware package containing the bootstrap
+   loader MAY also contain other routines.
+
+   The bootstrap loader requires access to cryptographic routines.
+   These routines can be implemented specifically for the bootstrap
+   loader, or they can be shared with other hardware module features.
+   The bootstrap loader MUST have access to a one-way hash function and
+   digital signature verification routines to validate the digital
+   signature on the firmware package and to validate the certification
+   path for the firmware-signing certificate.
+
+   If firmware packages are encrypted, the bootstrap loader MUST have
+   access to a decryption routine.  Access to a corresponding encryption
+   function is not required, since hardware modules need not be capable
+   of generating firmware packages.  Because some symmetric encryption
+   algorithm implementations (such as AES [AES]) employ separate logic
+   for encryption and decryption, some hardware module savings might
+   result.
+
+   If firmware packages are compressed, the bootstrap loader MUST also
+   have access to a decompression function.  This function can be
+   implemented specifically for the bootstrap loader, or it can be
+   shared with other hardware module features.  Access to a
+   corresponding compression function is not required, since hardware
+   modules need not be capable of generating firmware packages.
+
+   If the optional receipt generation or error report capability is
+   supported, the bootstrap loader MUST have access to the hardware
+   module serial number and the object identifier for the hardware
+   module type.  If the optional signed receipt generation or signed
+   error report capability is supported, the bootstrap loader MUST also
+   have access to a one-way hash function and digital signature
+   routines, the hardware module private signing key, and the
+   corresponding signature validation certificate or its designator.
+
+   The bootstrap loader requires access to one or more trusted public
+   keys, called trust anchors, to validate the firmware package digital
+   signature.  One or more trust anchors MUST be installed in non-
+   volatile memory prior to deployment.  The bootstrap loader MUST
+   reject a firmware package if it cannot validate the signature, which
+   MAY require the construction of a valid certification path from the
+   firmware-signing certificate to one of the trust anchors [PROFILE].
+   However, in many cases, the firmware package signature will be
+   validated directly with the trust anchor public key, avoiding the
+   need to construct certification paths.
+
+
+
+
+
+Housley                     Standards Track                    [Page 10]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The bootstrap loader MUST reject a firmware package if the list of
+   supported hardware module type identifiers within the firmware
+   package does not include the object identifier of the hardware
+   module.
+
+   The bootstrap loader MUST reject a firmware package if the firmware
+   package includes a list of community identifiers and the hardware
+   module is not a member of one of the listed communities.  The means
+   of determining community membership is beyond the scope of this
+   specification.
+
+   The bootstrap loader MUST reject a firmware package if it cannot
+   successfully decrypt the firmware package using the firmware-
+   decryption key available to the hardware module.  The firmware
+   package contains an identifier of the firmware-decryption key needed
+   for decryption.
+
+   When an earlier version of a firmware package is replacing a later
+   one, the bootstrap loader SHOULD generate a warning.  The manner in
+   which a warning is generated is highly dependent on the hardware
+   module and the environment in which it is being used.  If a firmware
+   package with a disastrous flaw is released and subsequent firmware
+   package versions designate a stale version, the bootstrap loader
+   SHOULD prevent loading of the stale version and versions earlier than
+   the stale version.
+
+1.2.3.1.  Legacy Stale Version Processing
+
+   In case a firmware package with a disastrous flaw is released,
+   subsequent firmware package versions that employ the legacy firmware
+   package name form MAY include a stale legacy firmware package name to
+   prevent subsequent rollback to the stale version or versions earlier
+   than the stale version.  As described in the Security Considerations
+   section of this document, the inclusion of a stale legacy firmware
+   package name in a firmware package cannot completely prevent
+   subsequent use of the stale firmware package.  However, many hardware
+   modules are expected to have very few firmware packages written for
+   them, allowing the stale firmware package version feature to provide
+   important protections.
+
+   Non-volatile storage for stale version numbers is needed.  The number
+   of stale legacy firmware package names that can be stored depends on
+   the amount of storage that is available.  When a firmware package is
+   loaded and it contains a stale legacy firmware package name, then it
+   SHOULD be added to a list kept in non-volatile storage.  When
+   subsequent firmware packages are loaded, the legacy firmware package
+
+
+
+
+
+Housley                     Standards Track                    [Page 11]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   name of the new package is compared to the list in non-volatile
+   storage.  If the legacy firmware package name represents the same
+   version or an older version of a member of the list, then the new
+   firmware packages SHOULD be rejected.
+
+   The amount of non-volatile storage that needs to be dedicated to
+   saving legacy firmware package names and stale legacy firmware
+   packages names depends on the number of firmware packages that are
+   likely to be developed for the hardware module.
+
+1.2.3.2.  Preferred Stale Version Processing
+
+   If a firmware package with a disastrous flaw is released, subsequent
+   firmware package versions that employ preferred firmware package name
+   form MAY include a stale version number to prevent subsequent
+   rollback to the stale version or versions earlier than the stale
+   version.  As described in the Security Considerations section of this
+   document, the inclusion of a stale version number in a firmware
+   package cannot completely prevent subsequent use of the stale
+   firmware package.  However, many hardware modules are expected to
+   have very few firmware packages written for them, allowing the stale
+   firmware package version feature to provide important protections.
+
+   Non-volatile storage for stale version numbers is needed.  The number
+   of stale version numbers that can be stored depends on the amount of
+   storage that is available.  When a firmware package is loaded and it
+   contains a stale version number, then the object identifier of the
+   firmware package and the stale version number SHOULD be added to a
+   list that is kept in non-volatile storage.  When subsequent firmware
+   packages are loaded, the object identifier and version number of the
+   new package are compared to the list in non-volatile storage.  If the
+   object identifier matches and the version number is less than or
+   equal to the stale version number, then the new firmware packages
+   SHOULD be rejected.
+
+   The amount of non-volatile storage that needs to be dedicated to
+   saving firmware package identifiers and stale version numbers depends
+   on the number of firmware packages that are likely to be developed
+   for the hardware module.
+
+1.2.4.  Trust Anchors
+
+   A trust anchor MUST consist of a public key signature algorithm and
+   an associated public key, which MAY optionally include parameters.  A
+   trust anchor MUST also include a public key identifier.  A trust
+   anchor MAY also include an X.500 distinguished name.
+
+
+
+
+
+Housley                     Standards Track                    [Page 12]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The trust anchor public key is used in conjunction with the signature
+   validation algorithm in two different ways.  First, the trust anchor
+   public key is used directly to validate the firmware package
+   signature.  Second, the trust anchor public key is used to validate
+   an X.509 certification path, and then the subject public key in the
+   final certificate in the certification path is used to validate the
+   firmware package signature.
+
+   The public key names the trust anchor, and each public key has a
+   public key identifier.  The public key identifier identifies the
+   trust anchor as the signer when it is used directly to validate
+   firmware package signatures.  This key identifier can be stored with
+   the trust anchor, or it can be computed from the public key whenever
+   needed.
+
+   The optional trusted X.500 distinguished name MUST be present in
+   order for the trust anchor public key to be used to validate an X.509
+   certification path.  Without an X.500 distinguished name,
+   certification path construction cannot use the trust anchor.
+
+1.2.5.  Cryptographic and Compression Algorithm Requirements
+
+   A firmware package for a cryptographic hardware module includes
+   cryptographic algorithm implementations.  In addition, a firmware
+   package for a non-cryptographic hardware module will likely include
+   cryptographic algorithm implementations to support the bootstrap
+   loader in the validation of firmware packages.
+
+   A unique algorithm object identifier MUST be assigned for each
+   cryptographic algorithm and mode implemented by a firmware package.
+   A unique algorithm object identifier MUST also be assigned for each
+   compression algorithm implemented by a firmware package.  The
+   algorithm object identifiers can be used to determine whether a
+   particular firmware package satisfies the needs of a particular
+   application.  To facilitate the development of algorithm-agile
+   applications, the cryptographic module interface SHOULD allow
+   applications to query the cryptographic module for the object
+   identifiers associated with each cryptographic algorithm contained in
+   the currently loaded firmware package.  Applications SHOULD also be
+   able to query the cryptographic module to determine attributes
+   associated with each algorithm.  Such attributes might include the
+   algorithm type (symmetric encryption, asymmetric encryption, key
+   agreement, one-way hash function, digital signature, and so on), the
+   algorithm block size or modulus size, and parameters for asymmetric
+   algorithms.  This specification does not establish the conventions
+   for the retrieval of algorithm identifiers or algorithm attributes.
+
+
+
+
+
+Housley                     Standards Track                    [Page 13]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+1.3.  Hardware Module Security Architecture
+
+   The bootstrap loader MAY be permanently stored in read-only memory or
+   separately loaded into non-volatile memory as discussed above.
+
+   In most hardware module designs, the firmware package execution
+   environment offers a single address space.  If it does, the firmware
+   package SHOULD contain a complete firmware package load for the
+   hardware module.  In this situation, the firmware package does not
+   contain a partial or incremental set of functions.  A complete
+   firmware package load will minimize complexity and avoid potential
+   security problems.  From a complexity perspective, the incremental
+   loading of packages makes it necessary for each package to identify
+   any other packages that are required (its dependencies), and the
+   bootstrap loader needs to verify that all of the dependencies are
+   satisfied before attempting to execute the firmware package.  When a
+   hardware module is based on a general purpose processor or a digital
+   signal processor, it is dangerous to allow arbitrary packages to be
+   loaded simultaneously unless there is a reference monitor to ensure
+   that independent portions of the code cannot interfere with one
+   another.  Also, it is difficult to evaluate arbitrary combinations of
+   software modules [SECREQMTS].  For these reasons, a complete firmware
+   package load is RECOMMENDED; however, this specification allows the
+   firmware signer to identify dependencies between firmware packages in
+   order to handle all situations.
+
+   The firmware packages MAY have dependencies on routines provided by
+   other firmware packages.  To minimize the security evaluation
+   complexity of a hardware module employing such a design, the firmware
+   package MUST identify the package identifiers (and the minimum
+   version numbers when the preferred firmware package name form is
+   used) of the packages upon which it depends.  The bootstrap loader
+   MUST reject a firmware package load if it contains a dependency on a
+   firmware package that is not available.
+
+   Loading a firmware package can impact the satisfactory resolution of
+   dependencies of other firmware packages that are already part of the
+   hardware module configuration.  For this reason, the bootstrap loader
+   MUST reject the loading of a firmware package if the dependencies of
+   any firmware package in the resulting configurations will be
+   unsatisfied.
+
+1.4.  ASN.1 Encoding
+
+   The CMS uses Abstract Syntax Notation One (ASN.1) [X.208-88,
+   X.209-88].  ASN.1 is a formal notation used for describing data
+   protocols, regardless of the programming language used by the
+   implementation.  Encoding rules describe how the values defined in
+
+
+
+Housley                     Standards Track                    [Page 14]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   ASN.1 will be represented for transmission.  The Basic Encoding Rules
+   (BER) are the most widely employed rule set, but they offer more than
+   one way to represent data structures.  For example, definite length
+   encoding and indefinite length encoding are supported.  This
+   flexibility is not desirable when digital signatures are used.  As a
+   result, the Distinguished Encoding Rules (DER) [X.509-88] were
+   invented.  DER is a subset of BER that ensures a single way to
+   represent a given value.  For example, DER always employs definite
+   length encoding.
+
+   In this specification, digitally signed structures MUST be encoded
+   with DER.  Other structures do not require DER, but the use of
+   definite length encoding is strongly RECOMMENDED.  By always using
+   definite length encoding, the bootstrap loader will have fewer
+   options to implement.  In situations where there is very high
+   confidence that only definite length encoding will be used, support
+   for indefinite length decoding MAY be omitted.
+
+1.5.  Protected Firmware Package Loading
+
+   This document does not attempt to specify a physical interface, any
+   related driver software, or a protocol necessary for loading firmware
+   packages.  Many different delivery mechanisms are envisioned,
+   including portable memory devices, file transfer, and web pages.
+   Section 2 of this specification defines the format that MUST be
+   presented to the hardware module regardless of the interface that is
+   used.  This specification also specifies the format of the response
+   that MAY be generated by the hardware module.  Section 3 of this
+   specification defines the format that MAY be returned by the hardware
+   module when a firmware package loads successfully.  Section 4 of this
+   specification defines the format that MAY be returned by the hardware
+   module when a firmware package load is unsuccessful.  The firmware
+   package load receipts and firmware package load error reports can be
+   either signed or unsigned.
+
+2.  Firmware Package Protection
+
+   The Cryptographic Message Syntax (CMS) is used to protect a firmware
+   package, which is treated as an opaque binary object.  A digital
+   signature is used to protect the firmware package from undetected
+   modification and to provide data origin authentication.  Encryption
+   is optionally used to protect the firmware package from disclosure,
+   and compression is optionally used to reduce the size of the
+   protected firmware package.  The CMS ContentInfo content type MUST
+   always be present, and it MUST encapsulate the CMS SignedData content
+   type.  If the firmware package is encrypted, then the CMS SignedData
+   content type MUST encapsulate the CMS EncryptedData content type.  If
+   the firmware package is compressed, then either the CMS SignedData
+
+
+
+Housley                     Standards Track                    [Page 15]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   content type (when encryption is not used) or the CMS EncryptedData
+   content type (when encryption is used) MUST encapsulate the CMS
+   CompressedData content type.  Finally, (1) the CMS SignedData content
+   type (when neither encryption nor compression is used), (2) the CMS
+   EncryptedData content type (when encryption is used, but compression
+   is not), or (3) the CMS CompressedData content type (when compression
+   is used) MUST encapsulate the simple firmware package using the
+   FirmwarePkgData content type defined in this specification (see
+   Section 2.1.5).
+
+   The firmware package protection is summarized as follows (see [CMS]
+   for the full syntax):
+
+      ContentInfo {
+        contentType          id-signedData, -- (1.2.840.113549.1.7.2)
+        content              SignedData
+      }
+
+      SignedData {
+        version              CMSVersion, -- always set to 3
+        digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
+        encapContentInfo     EncapsulatedContentInfo,
+        certificates         CertificateSet, -- Signer cert. path
+        crls                 CertificateRevocationLists, -- Optional
+        signerInfos          SET OF SignerInfo -- Only one
+      }
+
+      SignerInfo {
+        version              CMSVersion, -- always set to 3
+        sid                  SignerIdentifier,
+        digestAlgorithm      DigestAlgorithmIdentifier,
+        signedAttrs          SignedAttributes, -- Required
+        signatureAlgorithm   SignatureAlgorithmIdentifier,
+        signature            SignatureValue,
+        unsignedAttrs        UnsignedAttributes -- Optional
+      }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 16]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      EncapsulatedContentInfo {
+        eContentType         id-encryptedData, -- (1.2.840.113549.1.7.6)
+                             -- OR --
+                             id-ct-compressedData,
+                                       -- (1.2.840.113549.1.9.16.1.9)
+                             -- OR --
+                             id-ct-firmwarePackage,
+                                       -- (1.2.840.113549.1.9.16.1.16)
+        eContent             OCTET STRING
+      }                            -- Contains EncryptedData OR
+                                   -- CompressedData OR
+                                   -- FirmwarePkgData
+
+      EncryptedData {
+        version              CMSVersion, -- Always set to 0
+        encryptedContentInfo EncryptedContentInfo,
+        unprotectedAttrs     UnprotectedAttributes -- Omit
+      }
+
+      EncryptedContentInfo {
+        contentType          id-ct-compressedData,
+                                       -- (1.2.840.113549.1.9.16.1.9)
+                             -- OR --
+                             id-ct-firmwarePackage,
+                                       -- (1.2.840.113549.1.9.16.1.16)
+        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
+        encryptedContent OCTET STRING
+      }                                -- Contains CompressedData OR
+                                       -- FirmwarePkgData
+
+      CompressedData {
+        version              CMSVersion, -- Always set to 0
+        compressionAlgorithm CompressionAlgorithmIdentifier,
+        encapContentInfo     EncapsulatedContentInfo
+      }
+
+      EncapsulatedContentInfo {
+        eContentType         id-ct-firmwarePackage,
+                                         -- (1.2.840.113549.1.9.16.1.16)
+        eContent             OCTET STRING -- Contains FirmwarePkgData
+      }
+
+      FirmwarePkgData         OCTET STRING -- Contains firmware package
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 17]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.1.  Firmware Package Protection CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo,
+   SignedData, EncryptedData, and CompressedData content types.  It also
+   defines the FirmwarePkgData content type.
+
+2.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+      contentType indicates the type of the associated content, and in
+         this case, the encapsulated type is always SignedData.  The
+         id-signedData (1.2.840.113549.1.7.2) object identifier MUST be
+         present in this field.
+
+      content holds the associated content, and in this case, the
+         content field MUST contain SignedData.
+
+2.1.2.  SignedData
+
+   The SignedData content type [CMS] contains the signed firmware
+   package (which might be compressed, encrypted, or compressed and then
+   encrypted prior to signature), the certificates needed to validate
+   the signature, and one digital signature value.  The fields of
+   SignedData are used as follows:
+
+   version is the syntax version number, and in this case, it MUST be
+      set to 3.
+
+   digestAlgorithms is a collection of message digest algorithm
+      identifiers, and in this case, it MUST contain a single message
+      digest algorithm identifier.  The message digest algorithm
+      employed by the firmware package signer MUST be present.
+
+   encapContentInfo contains the signed content, consisting of a content
+      type identifier and the content itself.  The use of the
+      EncapsulatedContentInfo type is discussed further in Section
+      2.1.2.2.
+
+   certificates is an optional collection of certificates.  If the trust
+      anchor signed the firmware package directly, then certificates
+      SHOULD be omitted.  If it did not, then certificates SHOULD
+      include the X.509 certificate of the firmware package signer.  The
+      set of certificates SHOULD be sufficient for the bootstrap loader
+      to construct a certification path from the trust anchor to the
+      firmware-signer's certificate.  PKCS#6 extended certificates
+
+
+
+
+Housley                     Standards Track                    [Page 18]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      [PKCS#6] and attribute certificates (either version 1 or
+      version 2) [X.509-97, X.509-00, ACPROFILE] MUST NOT be included in
+      the set of certificates.
+
+   crls is an optional collection of certificate revocation lists
+      (CRLs), and in this case, CRLs SHOULD NOT be included by the
+      firmware package signer.  It is anticipated that firmware packages
+      may be generated, signed, and made available in repositories for
+      downloading into hardware modules.  In such contexts, it would be
+      difficult for the firmware package signer to include timely CRLs
+      in the firmware package.  However, because the CRLs are not
+      covered by the signature, timely CRLs MAY be inserted by some
+      other party before the firmware package is delivered to the
+      hardware module.
+
+   signerInfos is a collection of per-signer information, and in this
+      case, the collection MUST contain exactly one SignerInfo.  The use
+      of the SignerInfo type is discussed further in Section 2.1.2.1.
+
+2.1.2.1.  SignerInfo
+
+   The firmware package signer is represented in the SignerInfo type.
+   The fields of SignerInfo are used as follows:
+
+   version is the syntax version number, and it MUST be 3.
+
+   sid identifies the signer's public key.  CMS supports two
+      alternatives: issuerAndSerialNumber and subjectKeyIdentifier.
+      However, the bootstrap loader MUST support the
+      subjectKeyIdentifier alternative, which identifies the signer's
+      public key directly.  When this public key is contained in a
+      certificate, this identifier SHOULD appear in the X.509
+      subjectKeyIdentifier extension.
+
+   digestAlgorithm identifies the message digest algorithm, and any
+      associated parameters, used by the firmware package signer.  It
+      MUST contain the message digest algorithms employed by the
+      firmware package signer.  (Note that this message digest algorithm
+      identifier MUST be the same as the one carried in the
+      digestAlgorithms value in SignedData.)
+
+   signedAttrs is an optional collection of attributes that are signed
+      along with the content.  The signedAttrs are optional in the CMS,
+      but in this specification, signedAttrs are REQUIRED for the
+      firmware package; however, implementations MUST ignore
+      unrecognized signed attributes.  The SET OF attributes MUST be DER
+
+
+
+
+
+Housley                     Standards Track                    [Page 19]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      encoded [X.509-88].  Section 2.2 of this document lists the
+      attributes that MUST be included in the collection; other
+      attributes MAY be included as well.
+
+   signatureAlgorithm identifies the signature algorithm, and any
+      associated parameters, used by the firmware package signer to
+      generate the digital signature.
+
+   signature is the digital signature value.
+
+   unsignedAttrs is an optional SET of attributes that are not signed.
+      As described in Section 2.3, this set can only contain a single
+      instance of the wrapped-firmware-decryption-key attribute and no
+      others.
+
+2.1.2.2.  EncapsulatedContentInfo
+
+   The EncapsulatedContentInfo content type encapsulates the firmware
+   package, which might be compressed, encrypted, or compressed and then
+   encrypted prior to signature.  The firmware package, in any of these
+   formats, is carried within the EncapsulatedContentInfo type.  The
+   fields of EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, the value MUST be id-encryptedData
+      (1.2.840.113549.1.7.6), id-ct-compressedData
+      (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
+      (1.2.840.113549.1.9.16.1.16).  When eContentType contains id-
+      encryptedData, the firmware package was encrypted prior to
+      signing, and may also have been compressed prior to encryption.
+      When it contains id-ct-compressedData, the firmware package was
+      compressed prior to signing, but was not encrypted.  When it
+      contains id-ct-firmwarePackage, the firmware package was not
+      compressed or encrypted prior to signing.
+
+   eContent contains the signed firmware package, which might also be
+      encrypted, compressed, or compressed and then encrypted, prior to
+      signing.  The content is encoded as an octet string.  The eContent
+      octet string need not be DER encoded.
+
+2.1.3.  EncryptedData
+
+   The EncryptedData content type [CMS] contains the encrypted firmware
+   package (which might be compressed prior to encryption).  However, if
+   the firmware package was not encrypted, the EncryptedData content
+   type is not present.  The fields of EncryptedData are used as
+   follows:
+
+
+
+
+Housley                     Standards Track                    [Page 20]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   version is the syntax version number, and in this case, version MUST
+      be 0.
+
+   encryptedContentInfo is the encrypted content information.  The use
+      of the EncryptedContentInfo type is discussed further in Section
+      2.1.3.1.
+
+   unprotectedAttrs is an optional collection of unencrypted attributes,
+      and in this case, unprotectedAttrs MUST NOT be present.
+
+2.1.3.1.  EncryptedContentInfo
+
+   The encrypted firmware package, which might be compressed prior to
+   encryption, is encapsulated in the EncryptedContentInfo type.  The
+   fields of EncryptedContentInfo are used as follows:
+
+   contentType indicates the type of content, and in this case, it MUST
+      contain either id-ct-compressedData (1.2.840.113549.1.9.16.1.9) or
+      id-ct-firmwarePackage (1.2.840.113549.1.9.16.1.16).  When it
+      contains id-ct-compressedData, then the firmware package was
+      compressed prior to encryption.  When it contains id-ct-
+      firmwarePackage, then the firmware package was not compressed
+      prior to encryption.
+
+   contentEncryptionAlgorithm identifies the firmware-encryption
+      algorithm, and any associated parameters, used to encrypt the
+      firmware package.
+
+   encryptedContent is the result of encrypting the firmware package.
+      The field is optional; however, in this case, it MUST be present.
+
+2.1.4.  CompressedData
+
+   The CompressedData content type [COMPRESS] contains the compressed
+   firmware package.  If the firmware package was not compressed, then
+   the CompressedData content type is not present.  The fields of
+   CompressedData are used as follows:
+
+   version is the syntax version number; in this case, it MUST be 0.
+
+   compressionAlgorithm identifies the compression algorithm, and any
+      associated parameters, used to compress the firmware package.
+
+   encapContentInfo is the compressed content, consisting of a content
+      type identifier and the content itself.  The use of the
+      EncapsulatedContentInfo type is discussed further in Section
+      2.1.4.1.
+
+
+
+
+Housley                     Standards Track                    [Page 21]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.1.4.1.  EncapsulatedContentInfo
+
+   The CompressedData content type encapsulates the compressed firmware
+   package, and it is carried within the EncapsulatedContentInfo type.
+   The fields of EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, it MUST be the value of id-ct-
+      firmwarePackage (1.2.840.113549.1.9.16.1.16).
+
+   eContent is the compressed firmware package, encoded as an octet
+      string.  The eContent octet string need not be DER encoded.
+
+2.1.5.  FirmwarePkgData
+
+   The FirmwarePkgData content type contains the firmware package.  It
+   is a straightforward encapsulation in an octet string, and it need
+   not be DER encoded.
+
+   The FirmwarePkgData content type is identified by the id-ct-
+   firmwarePackage object identifier:
+
+      id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) ct(1) 16 }
+
+   The FirmwarePkgData content type is a simple octet string:
+
+      FirmwarePkgData ::= OCTET STRING
+
+2.2.  Signed Attributes
+
+   The firmware package signer MUST digitally sign a collection of
+   attributes along with the firmware package.  Each attribute in the
+   collection MUST be DER encoded [X.509-88].  The syntax for attributes
+   is defined in [CMS], but it is repeated here for convenience:
+
+      Attribute ::= SEQUENCE {
+        attrType OBJECT IDENTIFIER,
+        attrValues SET OF AttributeValue }
+
+      AttributeValue ::= ANY
+
+   Each of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+
+
+
+
+Housley                     Standards Track                    [Page 22]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attribute.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   The firmware package signer MUST include the following four
+   attributes: content-type, message-digest, firmware-package-
+   identifier, and target-hardware-module-identifiers.
+
+   If the firmware package is encrypted, then the firmware package
+   signer MUST also include the decrypt-key-identifier attribute.
+
+   If the firmware package implements cryptographic algorithms, then the
+   firmware package signer MAY also include the implemented-crypto-
+   algorithms attribute.  Similarly, if the firmware package implements
+   compression algorithms, then the firmware package signer MAY also
+   include the implemented-compress-algorithms attribute.
+
+   If the firmware package is intended for use only by specific
+   communities, then the firmware package signer MUST also include the
+   community-identifiers attribute.
+
+   If the firmware package depends on the presence of one or more other
+   firmware packages to operate properly, then the firmware package
+   signer SHOULD also include the firmware-package-info attribute.  For
+   example, the firmware-package-info attribute dependencies field might
+   indicate that the firmware package contains a dependency on a
+   particular bootstrap loader or separation kernel.
+
+   The firmware package signer SHOULD also include the three following
+   attributes: firmware-package-message-digest, signing-time, and
+   content-hints.  Additionally, if the firmware package signer has a
+   certificate (meaning that the firmware package signer is not always
+   configured as a trust anchor), then the firmware package signer
+   SHOULD also include the signing-certificate attribute.
+
+   The firmware package signer MAY include any other attribute that it
+   deems appropriate.
+
+2.2.1.  Content Type
+
+   The firmware package signer MUST include a content-type attribute
+   with the value of id-encryptedData (1.2.840.113549.1.7.6), id-ct-
+   compressedData (1.2.840.113549.1.9.16.1.9), or id-ct-firmwarePackage
+   (1.2.840.113549.1.9.16.1.16).  When it contains id-encryptedData, the
+   firmware package was encrypted prior to signing.  When it contains
+   id-ct-compressedData, the firmware package was compressed prior to
+   signing, but was not encrypted.  When it contains
+
+
+
+
+Housley                     Standards Track                    [Page 23]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   id-ct-firmwarePackage, the firmware package was not compressed or
+   encrypted prior to signing.  Section 11.1 of [CMS] defines the
+   content-type attribute.
+
+2.2.2.  Message Digest
+
+   The firmware package signer MUST include a message-digest attribute,
+   having as its value the message digest computed on the
+   encapContentInfo eContent octet string, as defined in Section
+   2.1.2.2.  This octet string contains the firmware package, and it MAY
+   be compressed, encrypted, or both compressed and encrypted.  Section
+   11.2 of [CMS] defines the message-digest attribute.
+
+2.2.3.  Firmware Package Identifier
+
+   The firmware-package-identifier attribute names the protected
+   firmware package.  Two approaches to naming firmware packages are
+   supported:  legacy and preferred.  The firmware package signer MUST
+   include a firmware-package-identifier attribute using one of these
+   name forms.
+
+   A legacy firmware package name is an octet string, and no structure
+   within the octet string is assumed.
+
+   A preferred firmware package name is a combination of an object
+   identifier and a version number.  The object identifier names a
+   collection of functions implemented by the firmware package, and the
+   version number is a non-negative integer that identifies a particular
+   build or release of the firmware package.
+
+   If a firmware package with a disastrous flaw is released, the
+   firmware package that repairs the previously distributed flaw MAY
+   designate a stale firmware package version to prevent the reloading
+   of the flawed version.  The hardware module bootstrap loader SHOULD
+   prevent subsequent rollback to the stale version or versions earlier
+   than the stale version.  When the legacy firmware package name form
+   is used, the stale version is indicated by a stale legacy firmware
+   package name, which is an octet string.  We assume that the firmware
+   package signer and the bootstrap loader can determine whether a given
+   legacy firmware package name represents a version that is more recent
+   than the stale one.  When the preferred firmware package name form is
+   used, the stale version is indicated by a stale version number, which
+   is an integer.
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 24]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The following object identifier identifies the firmware-package-
+   identifier attribute:
+
+      id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 35 }
+
+   The firmware-package-identifier attribute values have ASN.1 type
+   FirmwarePackageIdentifier:
+
+      FirmwarePackageIdentifier ::= SEQUENCE {
+        name PreferredOrLegacyPackageIdentifier,
+        stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
+
+      PreferredOrLegacyPackageIdentifier ::= CHOICE {
+        preferred PreferredPackageIdentifier,
+        legacy OCTET STRING }
+
+      PreferredPackageIdentifier ::= SEQUENCE {
+        fwPkgID OBJECT IDENTIFIER,
+        verNum INTEGER (0..MAX) }
+
+      PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
+        preferredStaleVerNum INTEGER (0..MAX),
+        legacyStaleVersion OCTET STRING }
+
+2.2.4.  Target Hardware Module Identifiers
+
+   The target-hardware-module-identifiers attribute names the types of
+   hardware modules that the firmware package supports.  A unique object
+   identifier names each supported hardware model type and revision.
+
+   The bootstrap loader MUST reject the firmware package if its own
+   hardware module type identifier is not listed in the target-
+   hardware-module-identifiers attribute.
+
+   The following object identifier identifies the target-hardware-
+   module-identifiers attribute:
+
+      id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 36 }
+
+   The target-hardware-module-identifiers attribute values have ASN.1
+   type TargetHardwareIdentifiers:
+
+      TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+
+
+Housley                     Standards Track                    [Page 25]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.5.  Decrypt Key Identifier
+
+   The decrypt-key-identifier attribute names the symmetric key needed
+   to decrypt the encapsulated firmware package.  The CMS EncryptedData
+   content type is used when the firmware package is encrypted.  The
+   decrypt-key-identifier signed attribute is carried in the SignedData
+   content type that encapsulates EncryptedData content type, naming the
+   symmetric key needed to decrypt the firmware package.  No particular
+   structure is imposed on the key identifier.  The means by which the
+   firmware-decryption key is securely distributed to all modules that
+   are authorized to use the associated firmware package is beyond the
+   scope of this specification; however, an optional mechanism for
+   securely distributing the firmware-decryption key with the firmware
+   package is specified in Section 2.3.1.
+
+   The following object identifier identifies the decrypt-key-identifier
+   attribute:
+
+      id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 37 }
+
+   The decrypt-key-identifier attribute values have ASN.1 type
+   DecryptKeyIdentifier:
+
+      DecryptKeyIdentifier ::= OCTET STRING
+
+2.2.6.  Implemented Crypto Algorithms
+
+   The implemented-crypto-algorithms attribute MAY be present in the
+   SignedAttributes, and it names the cryptographic algorithms that are
+   implemented by the firmware package and available to applications.
+   Only those algorithms that are made available at the interface of the
+   cryptographic module are listed.  Any cryptographic algorithm that is
+   used internally and is not accessible via the cryptographic module
+   interface MUST NOT be listed.  For example, if the firmware package
+   implements the decryption algorithm for future firmware package
+   installations and this algorithm is not made available for other
+   uses, then the firmware-decryption algorithm would not be listed.
+
+   The object identifier portion of AlgorithmIdentifier identifies an
+   algorithm and its mode of use.  No algorithm parameters are included.
+   Cryptographic algorithms include traffic-encryption algorithms, key-
+   encryption algorithms, key transport algorithms, key agreement
+   algorithms, one-way hash algorithms, and digital signature
+   algorithms.  Cryptographic algorithms do not include compression
+   algorithms.
+
+
+
+
+Housley                     Standards Track                    [Page 26]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The following object identifier identifies the implemented-crypto-
+   algorithms attribute:
+
+      id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 38 }
+
+   The implemented-crypto-algorithms attribute values have ASN.1 type
+   ImplementedCryptoAlgorithms:
+
+      ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+2.2.7.  Implemented Compression Algorithms
+
+   The implemented-compress-algorithms attribute MAY be present in the
+   SignedAttributes, and it names the compression algorithms that are
+   implemented by the firmware package and available to applications.
+   Only those algorithms that are made available at the interface of the
+   hardware module are listed.  Any compression algorithm that is used
+   internally and is not accessible via the hardware module interface
+   MUST NOT be listed.  For example, if the firmware package implements
+   a decompression algorithm for future firmware package installations
+   and this algorithm is not made available for other uses, then the
+   firmware-decompression algorithm would not be listed.
+
+   The object identifier portion of AlgorithmIdentifier identifies a
+   compression algorithm.  No algorithm parameters are included.
+
+   The following object identifier identifies the implemented-compress-
+   algorithms attribute:
+
+      id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 43 }
+
+   The implemented-compress-algorithms attribute values have ASN.1 type
+   ImplementedCompressAlgorithms:
+
+      ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+2.2.8.  Community Identifiers
+
+   If present in the SignedAttributes, the community-identifiers
+   attribute names the communities that are permitted to execute the
+   firmware package.  The bootstrap loader MUST reject the firmware
+   package if the hardware module is not a member of one of the
+   identified communities.  The means of assigning community membership
+   is beyond the scope of this specification.
+
+
+
+Housley                     Standards Track                    [Page 27]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The community-identifiers attributes names the authorized communities
+   by a list of community object identifiers, by a list of specific
+   hardware modules, or by a combination of the two lists.  A specific
+   hardware module is specified by the combination of the hardware
+   module identifier (as defined in Section 2.2.4) and a serial number.
+   To facilitate compact representation of serial numbers, a contiguous
+   block can be specified by the lowest authorized serial number and the
+   highest authorized serial number.  Alternatively, all of the serial
+   numbers associated with a hardware module family identifier can be
+   specified with the NULL value.
+
+   If the bootstrap loader does not have a mechanism for obtaining a
+   list of object identifiers that identify the communities to which the
+   hardware module is a member, then the bootstrap loader MUST behave as
+   though the list is empty.  Similarly, if the bootstrap loader does
+   not have access to the hardware module serial number, then the
+   bootstrap loader MUST behave as though the hardware module is not
+   included on the list of authorized hardware modules.
+
+   The following object identifier identifies the community-identifiers
+   attribute:
+
+      id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 40 }
+
+   The community-identifiers attribute values have ASN.1 type
+   CommunityIdentifiers:
+
+      CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+      CommunityIdentifier ::= CHOICE {
+        communityOID OBJECT IDENTIFIER,
+        hwModuleList HardwareModules }
+
+      HardwareModules ::= SEQUENCE {
+        hwType OBJECT IDENTIFIER,
+        hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+      HardwareSerialEntry ::= CHOICE {
+        all NULL,
+        single OCTET STRING,
+        block SEQUENCE {
+          low OCTET STRING,
+          high OCTET STRING } }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 28]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.9.  Firmware Package Information
+
+   If a hardware module supports more than one type of firmware package,
+   then the firmware package signer SHOULD include the firmware-
+   package-info attribute with a populated fwPkgType field to identify
+   the firmware package type.  This value can aid the bootstrap loader
+   in the correct placement of the firmware package within the hardware
+   module.  The firmware package type is an INTEGER, and the meaning of
+   the integer value is specific to each hardware module.  For example,
+   a hardware module could assign different integer values for a
+   bootstrap loader, a separation kernel, and an application.
+
+   Some hardware module architectures permit one firmware package to use
+   routines provided by another.  If the firmware package contains a
+   dependency on another, then the firmware package signer SHOULD also
+   include the firmware-package-info attribute with a populated
+   dependencies field.  If the firmware package does not depend on any
+   other firmware packages, then the firmware package signer MUST NOT
+   include the firmware-package-info attribute with a populated
+   dependencies field.
+
+   Firmware package dependencies are identified by the firmware package
+   identifier or by information contained in the firmware package
+   itself, and in either case the bootstrap loader ensures that the
+   dependencies are met.  The bootstrap loader MUST reject a firmware
+   package load if it identifies a dependency on a firmware package that
+   is not already loaded.  Also, the bootstrap loader MUST reject a
+   firmware package load if the action will result in a configuration
+   where the dependencies of an already loaded firmware package will no
+   longer be satisfied.  As described in Section 2.2.3, two approaches
+   to naming firmware packages are supported: legacy and preferred.
+   When the legacy firmware package name form is used, the dependency is
+   indicated by a legacy firmware package name.  We assume that the
+   firmware package signer and the bootstrap loader can determine
+   whether a given legacy firmware package name represents the named
+   version of an acceptable newer version.  When the preferred firmware
+   package name form is used, an object identifier and an integer are
+   provided.  The object identifier MUST exactly match the object
+   identifier portion of a preferred firmware package name associated
+   with a firmware package that is already loaded, and the integer MUST
+   be less than or equal to the integer portion of the preferred
+   firmware package name associated with the same firmware package.
+   That is, the dependency specifies the minimum value of the version
+   that is acceptable.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 29]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The following object identifier identifies the firmware-package-info
+   attribute:
+
+      id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 42 }
+
+   The firmware-package-info attribute values have ASN.1 type
+   FirmwarePackageInfo:
+
+      FirmwarePackageInfo ::= SEQUENCE {
+        fwPkgType INTEGER OPTIONAL,
+        dependencies SEQUENCE OF
+          PreferredOrLegacyPackageIdentifier OPTIONAL }
+
+2.2.10.  Firmware Package Message Digest
+
+   The firmware package signer SHOULD include a firmware-package-
+   message-digest attribute, which provides the message digest algorithm
+   and the message digest value computed on the firmware package.  The
+   message digest is computed on the firmware package prior to any
+   compression, encryption, or signature processing.  The bootstrap
+   loader MAY use this message digest to confirm that the intended
+   firmware package has been recovered after all of the layers of
+   encapsulation are removed.
+
+   The following object identifier identifies the firmware-package-
+   message-digest attribute:
+
+      id-aa-fwPkgMessageDigest OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 41 }
+
+   The firmware-package-message-digest attribute values have ASN.1 type
+   FirmwarePackageMessageDigest:
+
+      FirmwarePackageMessageDigest ::= SEQUENCE {
+        algorithm AlgorithmIdentifier,
+        msgDigest OCTET STRING }
+
+2.2.11.  Signing Time
+
+   The firmware package signer SHOULD include a signing-time attribute,
+   specifying the time at which the signature was applied to the
+   firmware package.  Section 11.3 of [CMS] defines the signing-time
+   attribute.
+
+
+
+
+
+Housley                     Standards Track                    [Page 30]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+2.2.12.  Content Hints
+
+   The firmware package signer SHOULD include a content-hints attribute,
+   including a brief text description of the firmware package.  The text
+   is encoded in UTF-8, which supports most of the world's writing
+   systems [UTF-8].  Section 2.9 of [ESS] defines the content-hints
+   attribute.
+
+   When multiple layers of encapsulation are employed, the content-hints
+   attribute is included in the outermost SignedData to provide
+   information about the innermost content.  In this case, the content-
+   hints attribute provides a brief text description of the firmware
+   package, which can help a person select the correct firmware package
+   when more than one is available.
+
+   When the preferred firmware package name forms are used, the
+   content-hints attribute can provide a linkage to a legacy firmware
+   package name.  This is especially helpful when an existing
+   configuration management system is in use, but the features
+   associated with the preferred firmware package name are deemed
+   useful.  A firmware package name associated with such a configuration
+   management system might look something like
+   "R1234.C0(AJ11).D62.A02.11(b)."  Including these firmware package
+   names in the text description may be helpful to developers by
+   providing a clear linkage between the two name forms.
+
+   The content-hints attribute contains two fields, and in this case,
+   both fields MUST be present.  The fields of ContentHints are used as
+   follows:
+
+   contentDescription provides a brief text description of the firmware
+      package.
+
+   contentType provides the content type of the inner most content type,
+      and in this case, it MUST be id-ct-firmwarePackage
+      (1.2.840.113549.1.9.16.1.16).
+
+2.2.13.  Signing Certificate
+
+   When the firmware-signer's public key is contained in a certificate,
+   the firmware package signer SHOULD include a signing-certificate
+   attribute to identify the certificate that was employed.  However, if
+   the firmware package signature does not have a certificate (meaning
+   that the signature will only be validated with the trust anchor
+   public key), then the firmware package signer is unable to include a
+   signing-certificate attribute.  Section 5.4 of [ESS] defines this
+   attribute.
+
+
+
+
+Housley                     Standards Track                    [Page 31]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The signing-certificate attribute contains two fields: certs and
+   policies.  The certs field MUST be present, and the policies field
+   MAY be present.  The fields of SigningCertificate are used as
+   follows:
+
+   certs contains a sequence of certificate identifiers.  In this case,
+      sequence of certificate identifiers contains a single entry.  The
+      certs field MUST contain only the certificate identifier of the
+      certificate that contains the public key used to verify the
+      firmware package signature.  The certs field uses the ESSCertID
+      syntax specified in Section 5.4 of [ESS], and it is comprised of
+      the SHA-1 hash [SHA1] of the entire ASN.1 DER encoded certificate
+      and, optionally, the certificate issuer and the certificate serial
+      number.  The SHA-1 hash value MUST be present.  The certificate
+      issuer and the certificate serial number SHOULD be present.
+
+   policies is optional; when it is present, it contains a sequence of
+      policy information.  The policies field, when present, MUST
+      contain only one entry, and that entry MUST match one of the
+      certificate policies in the certificate policies extension of the
+      certificate that contains the public key used to verify the
+      firmware package signature.  The policies field uses the
+      PolicyInformation syntax specified in Section 4.2.1.5 of
+      [PROFILE], and it is comprised of the certificate policy object
+      identifier and, optionally, certificate policy qualifiers.  The
+      certificate policy object identifier MUST be present.  The
+      certificate policy qualifiers SHOULD NOT be present.
+
+2.3.  Unsigned Attributes
+
+   CMS allows a SET of unsigned attributes to be included; however, in
+   this specification, the set MUST be absent or include a single
+   instance of the wrapped-firmware-decryption-key attribute.  Because
+   the digital signature does not cover this attribute, it can be
+   altered at any point in the delivery path from the firmware package
+   signer to the hardware module.  This property can be employed to
+   distribute the firmware-decryption key along with an encrypted and
+   signed firmware package, allowing the firmware-decryption key to be
+   wrapped with a different key-encryption key for each link in the
+   distribution chain.
+
+   The syntax for attributes is defined in [CMS], and it is repeated at
+   the beginning of Section 2.2 of this document for convenience.  Each
+   of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+
+
+
+
+Housley                     Standards Track                    [Page 32]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The UnsignedAttributes syntax within signerInfo is defined as a SET
+   OF Attribute.  The UnsignedAttributes MUST include only one instance
+   of any particular attribute.
+
+2.3.1.  Wrapped Firmware Decryption Key
+
+   The firmware package signer, or any other party in the distribution
+   chain, MAY include a wrapped-firmware-decryption-key attribute.
+
+   The following object identifier identifies the wrapped-firmware-
+   decryption-key attribute:
+
+      id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) aa(2) 39 }
+
+   The wrapped-firmware-decryption-key attribute values have ASN.1 type
+   of EnvelopedData.  Section 6 of [CMS] defines the EnvelopedData
+   content type, which is used to construct the value of the attribute.
+   EnvelopedData permits the firmware-decryption key to be protected
+   using symmetric or asymmetric techniques.  The EnvelopedData does not
+   include an encrypted content; rather, the EnvelopedData feature of
+   having the encrypted content in another location is employed.  The
+   encrypted content is found in the eContent field of the EncryptedData
+   structure.  The firmware-decryption key is contained in the
+   recipientInfos field.  Section 6 of [CMS] refers to this key as the
+   content-encryption key.
+
+   The EnvelopedData syntax supports many different key management
+   algorithms.  Four general techniques are supported: key transport,
+   key agreement, symmetric key-encryption keys, and passwords.
+
+   The EnvelopedData content type is profiled for the wrapped-firmware-
+   decryption-key attribute.  The EnvelopedData fields are described
+   fully in Section 6 of [CMS].  Additional rules apply when
+   EnvelopedData is used as a wrapped-firmware-decryption-key attribute.
+
+   Within the EnvelopedData structure, the following apply:
+
+   -  The set of certificates included in OriginatorInfo MUST NOT
+      include certificates with a type of extendedCertificate,
+      v1AttrCert, or v2AttrCert [X.509-97, X.509-00, ACPROFILE].  The
+      optional crls field MAY be present.
+
+   -  The optional unprotectedAttrs field MUST NOT be present.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 33]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   Within the EncryptedContentInfo structure, the following apply:
+
+   -  contentType MUST match the content type object identifier carried
+      in the contentType field within the EncryptedContentInfo structure
+      of EncryptedData as described in Section 2.1.3.1.
+
+   -  contentEncryptionAlgorithm identifies the firmware-encryption
+      algorithm, and any associated parameters, used to encrypt the
+      firmware package carried in the encryptedContent field of the
+      EncryptedContentInfo structure of EncryptedData.  Therefore, it
+      MUST exactly match the value of the EncryptedContentInfo structure
+      of EncryptedData as described in Section 2.1.3.1.
+
+   -  encryptedContent is optional, and in this case, it MUST NOT be
+      present.
+
+3.  Firmware Package Load Receipt
+
+   The Cryptographic Message Syntax (CMS) is used to indicate that a
+   firmware package loaded successfully.  Support for firmware package
+   load receipts is OPTIONAL.  However, those hardware modules that
+   choose to generate such receipts MUST follow the conventions
+   specified in this section.  Because not all hardware modules will
+   have private signature keys, the firmware package load receipt can be
+   either signed or unsigned.  Use of the signed firmware package load
+   receipt is RECOMMENDED.
+
+   Hardware modules that support receipt generation MUST have a unique
+   serial number.  Hardware modules that support signed receipt
+   generation MUST have a private signature key to sign the receipt and
+   the corresponding signature validation certificate or its designator.
+   The designator is the certificate issuer name and the certificate
+   serial number, or it is the public key identifier.  Memory-
+   constrained hardware modules will generally store the public key
+   identifier since it requires less storage.
+
+   The unsigned firmware package load receipt is encapsulated by
+   ContentInfo.  Alternatively, the signed firmware package load receipt
+   is encapsulated by SignedData, which is in turn encapsulated by
+   ContentInfo.
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 34]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load receipt is summarized as follows (see [CMS]
+   for the full syntax):
+
+   ContentInfo {
+     contentType          id-signedData, -- (1.2.840.113549.1.7.2)
+                          -- OR --
+                          id-ct-firmwareLoadReceipt,
+                               -- (1.2.840.113549.1.9.16.1.17)
+     content              SignedData
+                          -- OR --
+                          FirmwarePackageLoadReceipt
+   }
+
+   SignedData {
+     version              CMSVersion, -- always set to 3
+     digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
+     encapContentInfo     EncapsulatedContentInfo,
+     certificates         CertificateSet, -- Optional Module certificate
+     crls                 CertificateRevocationLists, -- Optional
+     signerInfos          SET OF SignerInfo -- Only one
+   }
+
+   SignerInfo {
+     version              CMSVersion, -- either set to 1 or 3
+     sid                  SignerIdentifier,
+     digestAlgorithm      DigestAlgorithmIdentifier,
+     signedAttrs          SignedAttributes, -- Required
+     signatureAlgorithm   SignatureAlgorithmIdentifier,
+     signature            SignatureValue,
+     unsignedAttrs        UnsignedAttributes -- Omit
+   }
+
+   EncapsulatedContentInfo {
+     eContentType         id-ct-firmwareLoadReceipt,
+                               -- (1.2.840.113549.1.9.16.1.17)
+     eContent             OCTET STRING -- Contains receipt
+   }
+
+   FirmwarePackageLoadReceipt {
+     version              INTEGER, -- The DEFAULT is always used
+     hwType               OBJECT IDENTIFIER, -- Hardware module type
+     hwSerialNum          OCTET STRING, -- H/W module serial number
+     fwPkgName            PreferredOrLegacyPackageIdentifier,
+     trustAnchorKeyID     OCTET STRING, -- Optional
+     decryptKeyID         OCTET STRING -- Optional
+   }
+
+
+
+
+
+Housley                     Standards Track                    [Page 35]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+3.1.  Firmware Package Load Receipt CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo
+   and SignedData content types for firmware package load receipts.  It
+   also defines the firmware package load receipt content type.
+
+3.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+   contentType indicates the type of the associated content.  If the
+      firmware package load receipt is signed, then the encapsulated
+      type MUST be SignedData, and the id-signedData
+      (1.2.840.113549.1.7.2) object identifier MUST be present in this
+      field.  If the receipt is not signed, then the encapsulated type
+      MUST be FirmwarePackageLoadReceipt, and the id-ct-
+      firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17) object identifier
+      MUST be present in this field.
+
+   content holds the associated content.  If the firmware package load
+      receipt is signed, then this field MUST contain the SignedData.
+      If the receipt is not signed, then this field MUST contain the
+      FirmwarePackageLoadReceipt.
+
+3.1.2.  SignedData
+
+   The SignedData content type contains the firmware package load
+   receipt and one digital signature.  If the hardware module locally
+   stores its certificate, then the certificate can be included as well.
+   The fields of SignedData are used as follows:
+
+   version is the syntax version number, and in this case, it MUST be
+      set to 3.
+
+   digestAlgorithms is a collection of message digest algorithm
+      identifiers, and in this case, it MUST contain a single message
+      digest algorithm identifier.  The message digest algorithms
+      employed by the hardware module MUST be present.
+
+   encapContentInfo is the signed content, consisting of a content type
+      identifier and the content itself.  The use of the
+      EncapsulatedContentInfo type is discussed further in Section
+      3.1.2.2.
+
+   certificates is an optional collection of certificates.  If the
+      hardware module locally stores its certificate, then the X.509
+      certificate of the hardware module SHOULD be included.  If the
+
+
+
+Housley                     Standards Track                    [Page 36]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      hardware module does not, then the certificates field is omitted.
+      PKCS#6 extended certificates [PKCS#6] and attribute certificates
+      (either version 1 or version 2) [X.509-97, X.509-00, ACPROFILE]
+      MUST NOT be included in the set of certificates.
+
+   crls is an optional collection of certificate revocation lists
+      (CRLs).  CRLs MAY be included, but they will normally be omitted
+      since hardware modules will not generally have access to the most
+      recent CRL.  Signed receipt recipients SHOULD be able to handle
+      the presence of the optional crls field.
+
+   signerInfos is a collection of per-signer information, and in this
+      case, the collection MUST contain exactly one SignerInfo.  The use
+      of the SignerInfo type is discussed further in Section 3.1.2.1.
+
+3.1.2.1.  SignerInfo
+
+   The hardware module is represented in the SignerInfo type.  The
+   fields of SignerInfo are used as follows:
+
+   version is the syntax version number, and it MUST be either 1 or 3,
+      depending on the method used to identify the hardware module's
+      public key.  The use of the subjectKeyIdentifier is RECOMMENDED,
+      which results in the use of version 3.
+
+   sid specifies the hardware module's certificate (and thereby the
+      hardware module's public key).  CMS supports two alternatives:
+      issuerAndSerialNumber and subjectKeyIdentifier.  The hardware
+      module MUST support one or both of the alternatives for receipt
+      generation; however, the support of subjectKeyIdentifier is
+      RECOMMENDED.  The issuerAndSerialNumber alternative identifies the
+      hardware module's certificate by the issuer's distinguished name
+      and the certificate serial number.  The identified certificate, in
+      turn, contains the hardware module's public key.  The
+      subjectKeyIdentifier alternative identifies the hardware module's
+      public key directly.  When this public key is contained in a
+      certificate, this identifier SHOULD appear in the X.509
+      subjectKeyIdentifier extension.
+
+   digestAlgorithm identifies the message digest algorithm, and any
+      associated parameters, used by the hardware module.  It MUST
+      contain the message digest algorithms employed to sign the
+      receipt.  (Note that this message digest algorithm identifier MUST
+      be the same as the one carried in the digestAlgorithms value in
+      SignedData.)
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 37]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   signedAttrs is an optional collection of attributes that are signed
+      along with the content.  The signedAttrs are optional in the CMS,
+      but in this specification, signedAttrs are REQUIRED for use with
+      the firmware package load receipt content.  The SET OF attributes
+      MUST be DER encoded [X.509-88].  Section 3.2 of this document
+      lists the attributes that MUST be included in the collection.
+      Other attributes MAY be included, but the recipient will ignore
+      any unrecognized signed attributes.
+
+   signatureAlgorithm identifies the signature algorithm, and any
+      associated parameters, used to sign the receipt.
+
+   signature is the digital signature.
+
+   unsignedAttrs is an optional collection of attributes that are not
+      signed, and in this case, there MUST NOT be any unsigned
+      attributes present.
+
+3.1.2.2.  EncapsulatedContentInfo
+
+   The FirmwarePackageLoadReceipt is encapsulated in an OCTET STRING,
+   and it is carried within the EncapsulatedContentInfo type.  The
+   fields of EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, it MUST be the value of id-ct-
+      firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
+
+   eContent is the firmware package load receipt, encapsulated in an
+      OCTET STRING.  The eContent octet string need not be DER encoded.
+
+3.1.3.  FirmwarePackageLoadReceipt
+
+   The following object identifier identifies the firmware package load
+   receipt content type:
+
+      id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) ct(1) 17 }
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 38]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load receipt content type has the ASN.1 type
+   FirmwarePackageLoadReceipt:
+
+      FirmwarePackageLoadReceipt ::= SEQUENCE {
+        version FWReceiptVersion DEFAULT v1,
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING,
+        fwPkgName PreferredOrLegacyPackageIdentifier,
+        trustAnchorKeyID OCTET STRING OPTIONAL,
+        decryptKeyID [1] OCTET STRING OPTIONAL }
+
+      FWReceiptVersion ::= INTEGER { v1(1) }
+
+   The fields of the FirmwarePackageLoadReceipt type have the following
+   meanings:
+
+   version is an integer that provides the syntax version number for
+      compatibility with future revisions of this specification.
+      Implementations that conform to this specification MUST set the
+      version to the default value, which is v1.
+
+   hwType is an object identifier that identifies the type of hardware
+      module on which the firmware package was loaded.
+
+   hwSerialNum is the serial number of the hardware module on which the
+      firmware package was loaded.  No particular structure is imposed
+      on the serial number; it need not be an integer.  However, the
+      combination of the hwType and hwSerialNum uniquely identifies the
+      hardware module.
+
+   fwPkgName identifies the firmware package that was loaded.  As
+      described in Section 2.2.3, two approaches to naming firmware
+      packages are supported: legacy and preferred.  A legacy firmware
+      package name is an octet string.  A preferred firmware package
+      name is a combination of the firmware package object identifier
+      and an integer version number.
+
+   trustAnchorKeyID is optional, and when it is present, it identifies
+      the trust anchor that was used to validate the firmware package
+      signature.
+
+   decryptKeyID is optional, and when it is present, it identifies the
+      firmware-decryption key that was used to decrypt the firmware
+      package.
+
+   The firmware package load receipt MUST include the version, hwType,
+   hwSerialNum, and fwPkgName fields, and it SHOULD include the
+   trustAnchorKeyID field.  The firmware package load receipt MUST NOT
+
+
+
+Housley                     Standards Track                    [Page 39]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   include the decryptKeyID, unless the firmware package associated with
+   the receipt is encrypted, the firmware-decryption key is available to
+   the hardware module, and the firmware package was successfully
+   decrypted.
+
+3.2.  Signed Attributes
+
+   The hardware module MUST digitally sign a collection of attributes
+   along with the firmware package load receipt.  Each attribute in the
+   collection MUST be DER encoded [X.509-88].  The syntax for attributes
+   is defined in [CMS], and it was repeated in Section 2.2 for
+   convenience.
+
+   Each of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attributes.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   The hardware module MUST include the content-type and message-digest
+   attributes.  If the hardware module includes a real-time clock, then
+   the hardware module SHOULD also include the signing-time attribute.
+   The hardware module MAY include any other attribute that it deems
+   appropriate.
+
+3.2.1.  Content Type
+
+   The hardware module MUST include a content-type attribute with the
+   value of id-ct-firmwareLoadReceipt (1.2.840.113549.1.9.16.1.17).
+   Section 11.1 of [CMS] defines the content-type attribute.
+
+3.2.2.  Message Digest
+
+   The hardware module MUST include a message-digest attribute, having
+   as its value the message digest of the FirmwarePackageLoadReceipt
+   content.  Section 11.2 of [CMS] defines the message-digest attribute.
+
+3.2.3.  Signing Time
+
+   If the hardware module includes a real-time clock, then the hardware
+   module SHOULD include a signing-time attribute, specifying the time
+   at which the receipt was generated.  Section 11.3 of [CMS] defines
+   the signing-time attribute.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 40]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+4.  Firmware Package Load Error
+
+   The Cryptographic Message Syntax (CMS) is used to indicate that an
+   error has occurred while attempting to load a protected firmware
+   package.  Support for firmware package load error reports is
+   OPTIONAL.  However, those hardware modules that choose to generate
+   such error reports MUST follow the conventions specified in this
+   section.  Not all hardware modules have private signature keys;
+   therefore the firmware package load error report can be either signed
+   or unsigned.  Use of the signed firmware package error report is
+   RECOMMENDED.
+
+   Hardware modules that support error report generation MUST have a
+   unique serial number.  Hardware modules that support signed error
+   report generation MUST also have a private signature key to sign the
+   error report and the corresponding signature validation certificate
+   or its designator.  The designator is the certificate issuer name and
+   the certificate serial number, or it is the public key identifier.
+   Memory-constrained hardware modules will generally store the public
+   key identifier since it requires less storage.
+
+   The unsigned firmware package load error report is encapsulated by
+   ContentInfo.  Alternatively, the signed firmware package load error
+   report is encapsulated by SignedData, which is in turn encapsulated
+   by ContentInfo.
+
+   The firmware package load error report is summarized as follows (see
+   [CMS] for the full syntax):
+
+   ContentInfo {
+     contentType          id-signedData, -- (1.2.840.113549.1.7.2)
+                          -- OR --
+                          id-ct-firmwareLoadError,
+                               -- (1.2.840.113549.1.9.16.1.18)
+     content              SignedData
+                          -- OR --
+                          FirmwarePackageLoadError
+   }
+
+   SignedData {
+     version              CMSVersion, -- Always set to 3
+     digestAlgorithms     DigestAlgorithmIdentifiers, -- Only one
+     encapContentInfo     EncapsulatedContentInfo,
+     certificates         CertificateSet, -- Optional Module certificate
+     crls                 CertificateRevocationLists, -- Optional
+     signerInfos          SET OF SignerInfo -- Only one
+   }
+
+
+
+
+Housley                     Standards Track                    [Page 41]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   SignerInfo {
+     version              CMSVersion, -- either set to 1 or 3
+     sid                  SignerIdentifier,
+     digestAlgorithm      DigestAlgorithmIdentifier,
+     signedAttrs          SignedAttributes, -- Required
+     signatureAlgorithm   SignatureAlgorithmIdentifier,
+     signature            SignatureValue,
+     unsignedAttrs        UnsignedAttributes -- Omit
+   }
+
+   EncapsulatedContentInfo {
+     eContentType         id-ct-firmwareLoadError,
+                               -- (1.2.840.113549.1.9.16.1.18)
+     eContent             OCTET STRING -- Contains error report
+   }
+
+   FirmwarePackageLoadError {
+     version            INTEGER, -- The DEFAULT is always used
+     hwType             OBJECT IDENTIFIER, -- Hardware module type
+     hwSerialNum        OCTET STRING, -- H/W module serial number
+     errorCode          FirmwarePackageLoadErrorCode -- Error identifier
+     vendorErrorCode    VendorErrorCode, -- Optional
+     fwPkgName          PreferredOrLegacyPackageIdentifier, -- Optional
+     config             SEQUENCE OF CurrentFWConfig, -- Optional
+   }
+
+   CurrentFWConfig {      -- Repeated for each package in configuration
+     fwPkgType            INTEGER, -- Firmware package type; Optional
+     fwPkgName            PreferredOrLegacyPackageIdentifier
+   }
+
+4.1.  Firmware Package Load Error CMS Content Type Profile
+
+   This section specifies the conventions for using the CMS ContentInfo
+   and SignedData content types for firmware package load error reports.
+   It also defines the firmware package load error content type.
+
+4.1.1.  ContentInfo
+
+   The CMS requires that the outermost encapsulation be ContentInfo
+   [CMS].  The fields of ContentInfo are used as follows:
+
+   contentType indicates the type of the associated content.  If the
+      firmware package load error report is signed, then the
+      encapsulated type MUST be SignedData, and the id-signedData
+      (1.2.840.113549.1.7.2) object identifier MUST be present in this
+      field.  If the report is not signed, then the encapsulated type
+
+
+
+
+Housley                     Standards Track                    [Page 42]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+      MUST be FirmwarePackageLoadError, and the id-ct-firmwareLoadError
+      (1.2.840.113549.1.9.16.1.18) object identifier MUST be present in
+      this field.
+
+   content holds the associated content.  If the firmware package load
+      error report is signed, then this field MUST contain the
+      SignedData.  If the report is not signed, then this field MUST
+      contain the FirmwarePackageLoadError.
+
+4.1.2.  SignedData
+
+   The SignedData content type contains the firmware package load error
+   report and one digital signature.  If the hardware module locally
+   stores its certificate, then the certificate can be included as well.
+   The fields of SignedData are used exactly as described in Section
+   3.1.2.
+
+4.1.2.1.  SignerInfo
+
+   The hardware module is represented in the SignerInfo type.  The
+   fields of SignerInfo are used exactly as described in Section
+   3.1.2.1.
+
+4.1.2.2.  EncapsulatedContentInfo
+
+   The FirmwarePackageLoadError is encapsulated in an OCTET STRING, and
+   it is carried within the EncapsulatedContentInfo type.  The fields of
+   EncapsulatedContentInfo are used as follows:
+
+   eContentType is an object identifier that uniquely specifies the
+      content type, and in this case, it MUST be the value of id-ct-
+      firmwareLoadError (1.2.840.113549.1.9.16.1.18).
+
+   eContent is the firmware package load error report, encapsulated in
+      an OCTET STRING.  The eContent octet string need not be DER
+      encoded.
+
+4.1.3.  FirmwarePackageLoadError
+
+   The following object identifier identifies the firmware package load
+   error report content type:
+
+      id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+        smime(16) ct(1) 18 }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 43]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The firmware package load error report content type has the ASN.1
+   type FirmwarePackageLoadError:
+
+      FirmwarePackageLoadError ::= SEQUENCE {
+        version FWErrorVersion DEFAULT v1,
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING,
+        errorCode FirmwarePackageLoadErrorCode,
+        vendorErrorCode VendorLoadErrorCode OPTIONAL,
+        fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
+        config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
+
+      FWErrorVersion ::= INTEGER { v1(1) }
+
+      CurrentFWConfig ::= SEQUENCE {
+        fwPkgType INTEGER OPTIONAL,
+        fwPkgName PreferredOrLegacyPackageIdentifier }
+
+      FirmwarePackageLoadErrorCode ::= ENUMERATED {
+        decodeFailure                (1),
+        badContentInfo               (2),
+        badSignedData                (3),
+        badEncapContent              (4),
+        badCertificate               (5),
+        badSignerInfo                (6),
+        badSignedAttrs               (7),
+        badUnsignedAttrs             (8),
+        missingContent               (9),
+        noTrustAnchor               (10),
+        notAuthorized               (11),
+        badDigestAlgorithm          (12),
+        badSignatureAlgorithm       (13),
+        unsupportedKeySize          (14),
+        signatureFailure            (15),
+        contentTypeMismatch         (16),
+        badEncryptedData            (17),
+        unprotectedAttrsPresent     (18),
+        badEncryptContent           (19),
+        badEncryptAlgorithm         (20),
+        missingCiphertext           (21),
+        noDecryptKey                (22),
+        decryptFailure              (23),
+        badCompressAlgorithm        (24),
+        missingCompressedContent    (25),
+        decompressFailure           (26),
+        wrongHardware               (27),
+        stalePackage                (28),
+        notInCommunity              (29),
+
+
+
+Housley                     Standards Track                    [Page 44]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+        unsupportedPackageType      (30),
+        missingDependency           (31),
+        wrongDependencyVersion      (32),
+        insufficientMemory          (33),
+        badFirmware                 (34),
+        unsupportedParameters       (35),
+        breaksDependency            (36),
+        otherError                  (99) }
+
+      VendorLoadErrorCode ::= INTEGER
+
+   The fields of the FirmwarePackageLoadError type have the following
+   meanings:
+
+   version is an integer, and it provides the syntax version number for
+      compatibility with future revisions of this specification.
+      Implementations that conform to this specification MUST set the
+      version to the default value, which is v1.
+
+   hwType is an object identifier that identifies the type of hardware
+      module on which the firmware package load was attempted.
+
+   hwSerialNum is the serial number of the hardware module on which the
+      firmware package load was attempted.  No particular structure is
+      imposed on the serial number; it need not be an integer.  However,
+      the combination of the hwType and hwSerialNum uniquely identifies
+      the hardware module.
+
+   errorCode identifies the error that occurred.
+
+   vendorErrorCode is optional; however, it MUST be present if the
+      errorCode contains a value of otherError.  When errorCode contains
+      a value other than otherError, the vendorErrorCode can provide
+      vendor-specific supplemental information.
+
+   fwPkgName is optional.  When it is present, it identifies the
+      firmware package that was being loaded when the error occurred.
+      As described in Section 2.2.3, two approaches to naming firmware
+      packages are supported: legacy and preferred.  A legacy firmware
+      package name is an octet string.  A preferred firmware package
+      name is a combination of the firmware package object identifier
+      and an integer version number.
+
+   config identifies the current firmware configuration.  The field is
+      OPTIONAL, but support for this field is RECOMMENDED for hardware
+      modules that permit the loading of more than one firmware package.
+      One instance of CurrentFWConfig is used to provide information
+      about each firmware package in hardware module.
+
+
+
+Housley                     Standards Track                    [Page 45]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   The fields of the CurrentFWConfig type have the following meanings:
+
+   fwPkgType identifies the firmware package type.  The firmware package
+      type is an INTEGER, and the meaning of the integer value is
+      specific to each hardware module.
+
+   fwPkgName identifies the firmware package.  As described in Section
+      2.2.3, two approaches to naming firmware packages are supported:
+      legacy and preferred.  A legacy firmware package name is an octet
+      string.  A preferred firmware package name is a combination of the
+      firmware package object identifier and an integer version number.
+
+   The errorCode values have the following meanings:
+
+   decodeFailure: The ASN.1 decode of the firmware package load failed.
+      The provided input did not conform to BER, or it was not ASN.1 at
+      all.
+
+   badContentInfo: Invalid ContentInfo syntax, or the contentType
+      carried within the ContentInfo is unknown or unsupported.
+
+   badSignedData: Invalid SignedData syntax, the version is unknown or
+      unsupported, or more than one entry is present in
+      digestAlgorithms.
+
+   badEncapContent: Invalid EncapsulatedContentInfo syntax, or the
+      contentType carried within the eContentType is unknown or
+      unsupported.  This error can be generated due to problems located
+      in SignedData or CompressedData.
+
+   badCertificate: Invalid syntax for one or more certificates in
+      CertificateSet.
+
+   badSignerInfo: Invalid SignerInfo syntax, or the version is unknown
+      or unsupported.
+
+   badSignedAttrs: Invalid signedAttrs syntax within SignerInfo.
+
+   badUnsignedAttrs: The unsignedAttrs within SignerInfo contains an
+      attribute other than the wrapped-firmware-decryption-key
+      attribute, which is the only unsigned attribute supported by this
+      specification.
+
+   missingContent: The optional eContent is missing in
+      EncapsulatedContentInfo, which is required in this specification.
+      This error can be generated due to problems located in SignedData
+      or CompressedData.
+
+
+
+
+Housley                     Standards Track                    [Page 46]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   noTrustAnchor: Two situations can lead to this error.  In one case,
+      the subjectKeyIdentifier does not identify the public key of a
+      trust anchor or a certification path that terminates with an
+      installed trust anchor.  In the other case, the
+      issuerAndSerialNumber does not identify the public key of a trust
+      anchor or a certification path that terminates with an installed
+      trust anchor.
+
+   notAuthorized: The sid within SignerInfo leads to an installed trust
+      anchor, but that trust anchor is not an authorized firmware
+      package signer.
+
+   badDigestAlgorithm: The digestAlgorithm in either SignerInfo or
+      SignedData is unknown or unsupported.
+
+   badSignatureAlgorithm: The signatureAlgorithm in SignerInfo is
+      unknown or unsupported.
+
+   unsupportedKeySize: The signatureAlgorithm in SignerInfo is known and
+      supported, but the firmware package signature could not be
+      validated because an unsupported key size was employed by the
+      signer.
+
+   signatureFailure: The signatureAlgorithm in SignerInfo is known and
+      supported, but the signature in signature in SignerInfo could not
+      be validated.
+
+   contentTypeMismatch: The contentType carried within the eContentType
+      does not match the content type carried in the signed attribute.
+
+   badEncryptedData: Invalid EncryptedData syntax; the version is
+      unknown or unsupported.
+
+   unprotectedAttrsPresent: EncryptedData contains unprotectedAttrs,
+      which are not permitted in this specification.
+
+   badEncryptContent: Invalid EncryptedContentInfo syntax, or the
+      contentType carried within the contentType is unknown or
+      unsupported.
+
+   badEncryptAlgorithm: The firmware-encryption algorithm identified by
+      contentEncryptionAlgorithm in EncryptedContentInfo is unknown or
+      unsupported.
+
+   missingCiphertext: The optional encryptedContent is missing in
+      EncryptedContentInfo, which is required in this specification.
+
+
+
+
+
+Housley                     Standards Track                    [Page 47]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   noDecryptKey: The hardware module does not have the firmware-
+      decryption key named in the decrypt key identifier signed
+      attribute.
+
+   decryptFailure: The firmware package did not decrypt properly.
+
+   badCompressAlgorithm: The compression algorithm identified by
+      compressionAlgorithm in CompressedData is unknown or unsupported.
+
+   missingCompressedContent: The optional eContent is missing in
+      EncapsulatedContentInfo, which is required in this specification.
+
+   decompressFailure: The firmware package did not decompress properly.
+
+   wrongHardware: The processing hardware module is not listed in the
+      target hardware module identifiers signed attribute.
+
+   stalePackage: The firmware package is rejected because it is stale.
+
+   notInCommunity: The hardware module is not a member of the community
+      described in the community identifiers signed attribute.
+
+   unsupportedPackageType: The firmware package type identified in the
+      firmware package information signed attribute is not supported by
+      the combination of the hardware module and the bootstrap loader.
+
+   missingDependency: The firmware package being loaded depends on
+      routines that are part of another firmware package, but that
+      firmware package is not available.
+
+   wrongDependencyVersion: The firmware package being loaded depends on
+      routines that are part of the another firmware package, and the
+      available version of that package has an older version number than
+      is required.  The available firmware package does not fulfill the
+      dependencies.
+
+   insufficientMemory: The firmware package could not be loaded because
+      the hardware module did not have sufficient memory.
+
+   badFirmware: The signature on the firmware package was validated, but
+      the firmware package itself was not in an acceptable format.  The
+      details will be specific to each hardware module.  For example, a
+      hardware module that is composed of multiple firmware-programmable
+      components could not find the internal tagging within the firmware
+      package to distribute executable code to each of the components.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 48]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   unsupportedParameters: The signature on the firmware package could
+      not be validated because the signer used signature algorithm
+      parameters that are not supported by the hardware module signature
+      verification routines.
+
+   breaksDependency: Another firmware package has a dependency that can
+      no longer be satisfied if the firmware package being loaded is
+      accepted.
+
+   otherError: An error occurred that does not fit any of the previous
+      error codes.
+
+4.2.  Signed Attributes
+
+   The hardware module MUST digitally sign a collection of attributes
+   along with the firmware package load error report.  Each attribute in
+   the collection MUST be DER encoded [X.509-88].  The syntax for
+   attributes is defined in [CMS], and it was repeated in Section 2.2
+   for convenience.
+
+   Each of the attributes used with this profile has a single attribute
+   value, even though the syntax is defined as a SET OF AttributeValue.
+   There MUST be exactly one instance of AttributeValue present.
+
+   The SignedAttributes syntax within signerInfo is defined as a SET OF
+   Attributes.  The SignedAttributes MUST include only one instance of
+   any particular attribute.
+
+   The hardware module MUST include the content-type and message-digest
+   attributes.  If the hardware module includes a real-time clock, then
+   the hardware module SHOULD also include the signing-time attribute.
+   The hardware module MAY include any other attribute that it deems
+   appropriate.
+
+4.2.1.  Content Type
+
+   The hardware module MUST include a content-type attribute with the
+   value of id-ct-firmwareLoadError (1.2.840.113549.1.9.16.1.18).
+   Section 11.1 of [CMS] defines the content-type attribute.
+
+4.2.2.  Message Digest
+
+   The hardware module MUST include a message-digest attribute, having
+   as its value the message digest of the FirmwarePackageLoadError
+   content.  Section 11.2 of [CMS] defines the message-digest attribute.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 49]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+4.2.3.  Signing Time
+
+   If the hardware module includes a real-time clock, then hardware
+   module SHOULD include a signing-time attribute, specifying the time
+   at which the firmware package load error report was generated.
+   Section 11.3 of [CMS] defines the signing-time attribute.
+
+5.  Hardware Module Name
+
+   Support for firmware package load receipts, as discussed in Section
+   3, is OPTIONAL, and support for the firmware package load error
+   reports, as discussed in Section 4, is OPTIONAL.  Hardware modules
+   that support receipt or error report generation MUST have unique
+   serial numbers.  Further, hardware modules that support signed
+   receipt or error report generation MUST have private signature keys
+   and corresponding signature validation certificates [PROFILE] or
+   their designators.  The conventions for hardware module naming in the
+   signature validation certificates are specified in this section.
+
+   The hardware module vendor or a trusted third party MUST issue the
+   signature validation certificate prior to deployment of the hardware
+   module.  The certificate is likely to be issued at the time of
+   manufacture.  The subject alternative name in this certificate
+   identifies the hardware module.  The subject distinguished name is
+   empty, but a critical subject alternative name extension contains the
+   hardware module name, using the otherName choice within the
+   GeneralName structure.
+
+   The hardware module name form is identified by the id-on-
+   hardwareModuleName object identifier:
+
+      id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
+        iso(1) identified-organization(3) dod(6) internet(1) security(5)
+        mechanisms(5) pkix(7) on(8) 4 }
+
+   A HardwareModuleName is composed of an object identifier and an octet
+   string:
+
+      HardwareModuleName ::= SEQUENCE {
+        hwType OBJECT IDENTIFIER,
+        hwSerialNum OCTET STRING }
+
+   The fields of the HardwareModuleName type have the following
+   meanings:
+
+   hwType is an object identifier that identifies the type of hardware
+      module.  A unique object identifier names a hardware model and
+      revision.
+
+
+
+Housley                     Standards Track                    [Page 50]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   hwSerialNum is the serial number of the hardware module.  No
+      particular structure is imposed on the serial number; it need not
+      be an integer.  However, the combination of the hwType and
+      hwSerialNum uniquely identifies the hardware module.
+
+6.  Security Considerations
+
+   This document describes the use of the Cryptographic Message Syntax
+   (CMS) to protect firmware packages; therefore, the security
+   considerations discussed in [CMS] apply to this specification as
+   well.
+
+   The conventions specified in this document raise a few security
+   considerations of their own.
+
+6.1.  Cryptographic Keys and Algorithms
+
+   Private signature keys must be protected.  Compromise of the private
+   key used to sign firmware packages permits unauthorized parties to
+   generate firmware packages that are acceptable to hardware modules.
+   Compromise of the hardware module private key allows unauthorized
+   parties to generate signed firmware package load receipts and error
+   reports.
+
+   The firmware-decryption key must be protected.  Compromise of the key
+   may result in the disclosure of the firmware package to unauthorized
+   parties.
+
+   Cryptographic algorithms become weaker with time.  As new
+   cryptanalysis techniques are developed and computing performance
+   improves, the work factor to break a particular cryptographic
+   algorithm will be reduced.  The ability to change the firmware
+   package provides an opportunity to update or replace cryptographic
+   algorithms.  Although this capability is desirable, cryptographic
+   algorithm replacement can lead to interoperability failures.
+   Therefore, the rollout of new cryptographic algorithms must be
+   managed.  Generally, the previous generation of cryptographic
+   algorithms and their replacements need to be supported at the same
+   time in order to facilitate an orderly transition.
+
+6.2.  Random Number Generation
+
+   When firmware packages are encrypted, the source of the firmware
+   package must randomly generate firmware-encryption keys.  Also, the
+   generation of public/private signature key pairs relies on a random
+   numbers.  The use of inadequate pseudo-random number generators
+   (PRNGs) to generate cryptographic keys can result in little or no
+   security.  An attacker may find it much easier to reproduce the PRNG
+
+
+
+Housley                     Standards Track                    [Page 51]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   environment that produced the keys, searching the resulting small set
+   of possibilities, rather than brute-force searching the whole key
+   space.  The generation of quality random numbers is difficult.  RFC
+   4086 [RANDOM] offers important guidance in this area.
+
+6.3.  Stale Firmware Package Version Number
+
+   The firmware signer determines whether a stale version number is
+   included.  The policy of the firmware signer needs to consider many
+   factors.  Consider the flaw found by Ian Goldberg and David Wagner in
+   the random number generator of the Netscape browser in 1996 [DDJ].
+   This flaw completely undermines confidentiality protection.  A
+   firmware signer might use the stale version number to ensure that
+   upgraded hardware modules do not resume use of the flawed firmware.
+   However, another firmware signer may not consider this an appropriate
+   situation to employ the stale version number, preferring to delegate
+   this decision to someone closer to the operation of the hardware
+   module.  Such a person is likely to be in a better position to
+   evaluate whether other bugs introduced in the newer firmware package
+   impose worse operational concerns than the confidentiality concern
+   caused by the flawed random number generator.  For example, a user
+   who never uses the encryption feature of the flawed Netscape browser
+   will determine the most appropriate version to use without
+   considering the random number flaw or its fix.
+
+   The stale version number is especially useful when the security
+   interests of the person choosing which firmware package version to
+   load into a particular hardware module do not align with the security
+   interests of the firmware package signer.  For example, stale version
+   numbers may be useful in hardware modules that provide digital rights
+   management (DRM).  Also, stale version numbers will be useful when
+   the deployment organization (as opposed to the firmware package
+   vendor) is the firmware signer.  Further, stale version numbers will
+   be useful for firmware packages that need to be trusted to implement
+   organizational (as opposed to the deployment organization) security
+   policy, regardless of whether the firmware signer is the deployment
+   organization or the vendor.  For example, hardware devices employed
+   by the military will probably make use of stale version numbers.
+
+   The use of a stale version number in a firmware package that employs
+   the preferred firmware package name form cannot completely prevent
+   subsequent use of the stale firmware package.  Despite this
+   shortcoming, the feature is included since it is useful in some
+   important situations.  By loading different types of firmware
+   packages, each with its own stale firmware package version number
+   until the internal storage for the stale version number is exceeded,
+   the user can circumvent the mechanism.  Consider a hardware module
+
+
+
+
+Housley                     Standards Track                    [Page 52]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   that has storage for two stale version numbers.  Suppose that FWPKG-A
+   version 3 is loaded, indicating that FWPKG-A version 2 is stale.  The
+   user can sequentially load the following:
+
+      - FWPKG-B version 8, indicating that FWPKG-B version 4 is stale.
+          (Note: The internal storage indicates that FWPKG-A version 2
+           and FWPKG-B version 4 are stale.)
+
+      - FWPKG-C version 5, indicating that FWPKG-C version 3 is stale.
+          (Note: The internal storage indicates that FWPKG-B version 4
+           and FWPKG-C version 3 are stale.)
+
+      - FWPKG-A version 2.
+
+   Because many hardware modules are expected to have very few firmware
+   packages written for them, the stale firmware package version feature
+   provides important protections.  The amount of non-volatile storage
+   that needs to be dedicated to saving firmware package identifiers and
+   version numbers depends on the number of firmware packages that are
+   likely to be developed for the hardware module.
+
+   The use of legacy firmware package name form does not improve this
+   situation.  In fact, the legacy firmware package names are usually
+   larger than an object identifier.  Thus, comparable stale version
+   protection requires more memory.
+
+   A firmware signer can ensure that stale version numbers are honored
+   by limiting the number of different types of firmware packages that
+   are signed.  If all of the hardware modules are able to store a stale
+   version number for each of the different types of firmware package,
+   then the hardware module will be able to provide the desired
+   protection.  This requires the firmware signer to have a deep
+   understanding of all of the hardware modules that might accept the
+   firmware package.
+
+6.4.  Community Identifiers
+
+   When a firmware package includes a community identifier, the
+   confidence that the package is only used by the intended community
+   depends on the mechanism used to configure community membership.
+   This document does not specify a mechanism for the assignment of
+   community membership to hardware modules, and the various
+   alternatives have different security properties.  Also, the authority
+   that makes community identifier assignments to hardware modules might
+   be different than the authority that generates firmware packages.
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 53]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [COMPRESS]   Gutmann, P., "Compressed Data Content Type for
+                Cryptographic Message Syntax (CMS)", RFC 3274, June
+                2002.
+
+   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                3852, July 2004.
+
+   [ESS]        Hoffman, P., "Enhanced Security Services for S/MIME",
+                RFC 2634, June 1999.
+
+   [PROFILE]    Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+                X.509 Public Key Infrastructure Certificate and
+                Certificate Revocation List (CRL) Profile", RFC 3280,
+                April 2002.
+
+   [SHA1]       National Institute of Standards and Technology.  FIPS
+                Pub 180-1: Secure Hash Standard.  17 April 1995.
+
+   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [X.208-88]   CCITT.  Recommendation X.208: Specification of Abstract
+                Syntax Notation One (ASN.1).  1988.
+
+   [X.209-88]   CCITT.  Recommendation X.209: Specification of Basic
+                Encoding Rules for Abstract Syntax Notation One (ASN.1).
+                1988.
+
+   [X.509-88]   CCITT.  Recommendation X.509: The Directory -
+                Authentication Framework.  1988.
+
+7.2.  Informative References
+
+   [ACPROFILE]  Farrell, S. and R. Housley, "An Internet Attribute
+                Certificate Profile for Authorization", RFC 3281, April
+                2002.
+
+   [AES]        National Institute of Standards and Technology.  FIPS
+                Pub 197:  Advanced Encryption Standard (AES).  26
+                November 2001.
+
+
+
+
+Housley                     Standards Track                    [Page 54]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   [DDJ]        Goldberg, I. and D. Wagner.  "Randomness and the
+                Netscape Browser."  Dr. Dobb's Journal, January 1996.
+
+   [DPD&DPV]    Pinkas, D. and R. Housley, "Delegated Path Validation
+                and Delegated Path Discovery Protocol Requirements", RFC
+                3379, September 2002.
+
+   [OCSP]       Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+                Adams, "X.509 Internet Public Key Infrastructure Online
+                Certificate Status Protocol - OCSP", RFC 2560, June
+                1999.
+
+   [PKCS#6]     RSA Laboratories.  PKCS #6: Extended-Certificate Syntax
+                Standard, Version 1.5.  November 1993.
+
+   [RANDOM]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                "Randomness Requirements for Security", BCP 106, RFC
+                4086, June 2005.
+
+   [SECREQMTS]  National Institute of Standards and Technology.  FIPS
+                Pub 140-2: Security Requirements for Cryptographic
+                Modules.  25 May 2001.
+
+   [X.509-97]   ITU-T.  Recommendation X.509: The Directory -
+                Authentication Framework.  1997.
+
+   [X.509-00]   ITU-T.  Recommendation X.509: The Directory -
+                Authentication Framework.  2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 55]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Appendix A: ASN.1 Module
+
+   The ASN.1 module contained in this appendix defines the structures
+   that are needed to implement the CMS-based firmware package wrapper.
+   It is expected to be used in conjunction with the ASN.1 modules in
+   [CMS], [COMPRESS], and [PROFILE].
+
+
+   CMSFirmwareWrapper
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+         pkcs-9(9) smime(16) modules(0) cms-firmware-wrap(22) }
+
+   DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+   IMPORTS
+       EnvelopedData
+       FROM CryptographicMessageSyntax -- [CMS]
+            { iso(1) member-body(2) us(840) rsadsi(113549)
+              pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) };
+
+
+   -- Firmware Package Content Type and Object Identifier
+
+   id-ct-firmwarePackage OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) ct(1) 16 }
+
+   FirmwarePkgData ::= OCTET STRING
+
+
+   -- Firmware Package Signed Attributes and Object Identifiers
+
+   id-aa-firmwarePackageID OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 35 }
+
+   FirmwarePackageIdentifier ::= SEQUENCE {
+     name PreferredOrLegacyPackageIdentifier,
+     stale PreferredOrLegacyStalePackageIdentifier OPTIONAL }
+
+   PreferredOrLegacyPackageIdentifier ::= CHOICE {
+     preferred PreferredPackageIdentifier,
+     legacy OCTET STRING }
+
+   PreferredPackageIdentifier ::= SEQUENCE {
+     fwPkgID OBJECT IDENTIFIER,
+     verNum INTEGER (0..MAX) }
+
+
+
+
+Housley                     Standards Track                    [Page 56]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   PreferredOrLegacyStalePackageIdentifier ::= CHOICE {
+     preferredStaleVerNum INTEGER (0..MAX),
+     legacyStaleVersion OCTET STRING }
+
+
+   id-aa-targetHardwareIDs OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 36 }
+
+   TargetHardwareIdentifiers ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+   id-aa-decryptKeyID OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 37 }
+
+   DecryptKeyIdentifier ::= OCTET STRING
+
+
+   id-aa-implCryptoAlgs OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 38 }
+
+   ImplementedCryptoAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+   id-aa-implCompressAlgs OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 43 }
+
+   ImplementedCompressAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
+
+
+   id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 40 }
+
+   CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier
+
+   CommunityIdentifier ::= CHOICE {
+     communityOID OBJECT IDENTIFIER,
+     hwModuleList HardwareModules }
+
+   HardwareModules ::= SEQUENCE {
+     hwType OBJECT IDENTIFIER,
+     hwSerialEntries SEQUENCE OF HardwareSerialEntry }
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 57]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   HardwareSerialEntry ::= CHOICE {
+     all NULL,
+     single OCTET STRING,
+     block SEQUENCE {
+       low OCTET STRING,
+       high OCTET STRING } }
+
+
+   id-aa-firmwarePackageInfo OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 42 }
+
+   FirmwarePackageInfo ::= SEQUENCE {
+     fwPkgType INTEGER OPTIONAL,
+     dependencies SEQUENCE OF
+       PreferredOrLegacyPackageIdentifier OPTIONAL }
+
+
+   -- Firmware Package Unsigned Attributes and Object Identifiers
+
+   id-aa-wrappedFirmwareKey OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) aa(2) 39 }
+
+   WrappedFirmwareKey ::= EnvelopedData
+
+
+   -- Firmware Package Load Receipt Content Type and Object Identifier
+
+   id-ct-firmwareLoadReceipt OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) ct(1) 17 }
+
+   FirmwarePackageLoadReceipt ::= SEQUENCE {
+     version FWReceiptVersion DEFAULT v1,
+     hwType OBJECT IDENTIFIER,
+     hwSerialNum OCTET STRING,
+     fwPkgName PreferredOrLegacyPackageIdentifier,
+     trustAnchorKeyID OCTET STRING OPTIONAL,
+     decryptKeyID [1] OCTET STRING OPTIONAL }
+
+   FWReceiptVersion ::= INTEGER { v1(1) }
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 58]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+   -- Firmware Package Load Error Report Content Type
+   -- and Object Identifier
+
+   id-ct-firmwareLoadError OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+     smime(16) ct(1) 18 }
+
+   FirmwarePackageLoadError ::= SEQUENCE {
+     version FWErrorVersion DEFAULT v1,
+     hwType OBJECT IDENTIFIER,
+     hwSerialNum OCTET STRING,
+     errorCode FirmwarePackageLoadErrorCode,
+     vendorErrorCode VendorLoadErrorCode OPTIONAL,
+     fwPkgName PreferredOrLegacyPackageIdentifier OPTIONAL,
+     config [1] SEQUENCE OF CurrentFWConfig OPTIONAL }
+
+   FWErrorVersion ::= INTEGER { v1(1) }
+
+   CurrentFWConfig ::= SEQUENCE {
+     fwPkgType INTEGER OPTIONAL,
+     fwPkgName PreferredOrLegacyPackageIdentifier }
+
+   FirmwarePackageLoadErrorCode ::= ENUMERATED {
+     decodeFailure                (1),
+     badContentInfo               (2),
+     badSignedData                (3),
+     badEncapContent              (4),
+     badCertificate               (5),
+     badSignerInfo                (6),
+     badSignedAttrs               (7),
+     badUnsignedAttrs             (8),
+     missingContent               (9),
+     noTrustAnchor               (10),
+     notAuthorized               (11),
+     badDigestAlgorithm          (12),
+     badSignatureAlgorithm       (13),
+     unsupportedKeySize          (14),
+     signatureFailure            (15),
+     contentTypeMismatch         (16),
+     badEncryptedData            (17),
+     unprotectedAttrsPresent     (18),
+     badEncryptContent           (19),
+     badEncryptAlgorithm         (20),
+     missingCiphertext           (21),
+     noDecryptKey                (22),
+     decryptFailure              (23),
+     badCompressAlgorithm        (24),
+     missingCompressedContent    (25),
+
+
+
+Housley                     Standards Track                    [Page 59]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+     decompressFailure           (26),
+     wrongHardware               (27),
+     stalePackage                (28),
+     notInCommunity              (29),
+     unsupportedPackageType      (30),
+     missingDependency           (31),
+     wrongDependencyVersion      (32),
+     insufficientMemory          (33),
+     badFirmware                 (34),
+     unsupportedParameters       (35),
+     breaksDependency            (36),
+     otherError                  (99) }
+
+   VendorLoadErrorCode ::= INTEGER
+
+
+   -- Other Name syntax for Hardware Module Name
+
+   id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
+     iso(1) identified-organization(3) dod(6) internet(1) security(5)
+     mechanisms(5) pkix(7) on(8) 4 }
+
+   HardwareModuleName ::= SEQUENCE {
+     hwType OBJECT IDENTIFIER,
+     hwSerialNum OCTET STRING }
+
+
+   END
+
+Author's Address
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 60]
+
+RFC 4108         Using CMS to Protect Firmware Packages      August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 61]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4120.txt b/third_party/heimdal/doc/standardisation/rfc4120.txt
new file mode 100644
index 00000000000..e2816aff214
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4120.txt
@@ -0,0 +1,7731 @@
+
+
+
+
+
+
+Network Working Group                                          C. Neuman
+Request for Comments: 4120                                       USC-ISI
+Obsoletes: 1510                                                    T. Yu
+Category: Standards Track                                     S. Hartman
+                                                              K. Raeburn
+                                                                     MIT
+                                                               July 2005
+
+
+            The Kerberos Network Authentication Service (V5)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document provides an overview and specification of Version 5 of
+   the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects
+   of the protocol and its intended use that require more detailed or
+   clearer explanation than was provided in RFC 1510.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                     [Page 1]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................5
+      1.1. The Kerberos Protocol ......................................6
+      1.2. Cross-Realm Operation ......................................8
+      1.3. Choosing a Principal with Which to Communicate .............9
+      1.4. Authorization .............................................10
+      1.5. Extending Kerberos without Breaking Interoperability ......11
+           1.5.1. Compatibility with RFC 1510 ........................11
+           1.5.2. Sending Extensible Messages ........................12
+      1.6. Environmental Assumptions .................................12
+      1.7. Glossary of Terms .........................................13
+   2. Ticket Flag Uses and Requests ..................................16
+      2.1. Initial, Pre-authenticated, and
+           Hardware-Authenticated Tickets ............................17
+      2.2. Invalid Tickets ...........................................17
+      2.3. Renewable Tickets .........................................17
+      2.4. Postdated Tickets .........................................18
+      2.5. Proxiable and Proxy Tickets ...............................19
+      2.6. Forwardable Tickets .......................................19
+      2.7. Transited Policy Checking .................................20
+      2.8. OK as Delegate ............................................21
+      2.9. Other KDC Options .........................................21
+           2.9.1. Renewable-OK .......................................21
+           2.9.2. ENC-TKT-IN-SKEY ....................................22
+           2.9.3. Passwordless Hardware Authentication ...............22
+   3. Message Exchanges ..............................................22
+      3.1. The Authentication Service Exchange .......................22
+           3.1.1. Generation of KRB_AS_REQ Message ...................24
+           3.1.2. Receipt of KRB_AS_REQ Message ......................24
+           3.1.3. Generation of KRB_AS_REP Message ...................24
+           3.1.4. Generation of KRB_ERROR Message ....................27
+           3.1.5. Receipt of KRB_AS_REP Message ......................27
+           3.1.6. Receipt of KRB_ERROR Message .......................28
+      3.2. The Client/Server Authentication Exchange .................29
+           3.2.1. The KRB_AP_REQ Message .............................29
+           3.2.2. Generation of a KRB_AP_REQ Message .................29
+           3.2.3. Receipt of KRB_AP_REQ Message ......................30
+           3.2.4. Generation of a KRB_AP_REP Message .................33
+           3.2.5. Receipt of KRB_AP_REP Message ......................33
+           3.2.6. Using the Encryption Key ...........................33
+      3.3. The Ticket-Granting Service (TGS) Exchange ................34
+           3.3.1. Generation of KRB_TGS_REQ Message ..................35
+           3.3.2. Receipt of KRB_TGS_REQ Message .....................37
+           3.3.3. Generation of KRB_TGS_REP Message ..................38
+           3.3.4. Receipt of KRB_TGS_REP Message .....................42
+
+
+
+
+
+Neuman, et al.              Standards Track                     [Page 2]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      3.4. The KRB_SAFE Exchange .....................................42
+           3.4.1. Generation of a KRB_SAFE Message ...................42
+           3.4.2. Receipt of KRB_SAFE Message ........................43
+      3.5. The KRB_PRIV Exchange .....................................44
+           3.5.1. Generation of a KRB_PRIV Message ...................44
+           3.5.2. Receipt of KRB_PRIV Message ........................44
+      3.6. The KRB_CRED Exchange .....................................45
+           3.6.1. Generation of a KRB_CRED Message ...................45
+           3.6.2. Receipt of KRB_CRED Message ........................46
+      3.7. User-to-User Authentication Exchanges .....................47
+   4. Encryption and Checksum Specifications .........................48
+   5. Message Specifications .........................................50
+      5.1. Specific Compatibility Notes on ASN.1 .....................51
+           5.1.1. ASN.1 Distinguished Encoding Rules .................51
+           5.1.2. Optional Integer Fields ............................52
+           5.1.3. Empty SEQUENCE OF Types ............................52
+           5.1.4. Unrecognized Tag Numbers ...........................52
+           5.1.5. Tag Numbers Greater Than 30 ........................53
+      5.2. Basic Kerberos Types ......................................53
+           5.2.1. KerberosString .....................................53
+           5.2.2. Realm and PrincipalName ............................55
+           5.2.3. KerberosTime .......................................55
+           5.2.4. Constrained Integer Types ..........................55
+           5.2.5. HostAddress and HostAddresses ......................56
+           5.2.6. AuthorizationData ..................................57
+           5.2.7. PA-DATA ............................................60
+           5.2.8. KerberosFlags ......................................64
+           5.2.9. Cryptosystem-Related Types .........................65
+      5.3. Tickets ...................................................66
+      5.4. Specifications for the AS and TGS Exchanges ...............73
+           5.4.1. KRB_KDC_REQ Definition .............................73
+           5.4.2. KRB_KDC_REP Definition .............................81
+      5.5. Client/Server (CS) Message Specifications .................84
+           5.5.1. KRB_AP_REQ Definition ..............................84
+           5.5.2. KRB_AP_REP Definition ..............................88
+           5.5.3. Error Message Reply ................................89
+      5.6. KRB_SAFE Message Specification ............................89
+           5.6.1. KRB_SAFE definition ................................89
+      5.7. KRB_PRIV Message Specification ............................91
+           5.7.1. KRB_PRIV Definition ................................91
+      5.8. KRB_CRED Message Specification ............................92
+           5.8.1. KRB_CRED Definition ................................92
+      5.9. Error Message Specification ...............................94
+           5.9.1. KRB_ERROR Definition ...............................94
+      5.10. Application Tag Numbers ..................................96
+
+
+
+
+
+
+Neuman, et al.              Standards Track                     [Page 3]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   6. Naming Constraints .............................................97
+      6.1. Realm Names ...............................................97
+      6.2. Principal Names .......................................... 99
+           6.2.1. Name of Server Principals .........................100
+   7. Constants and Other Defined Values ............................101
+      7.1. Host Address Types .......................................101
+      7.2. KDC Messaging: IP Transports .............................102
+           7.2.1. UDP/IP transport ..................................102
+           7.2.2. TCP/IP Transport ..................................103
+           7.2.3. KDC Discovery on IP Networks ......................104
+      7.3. Name of the TGS ..........................................105
+      7.4. OID Arc for KerberosV5 ...................................106
+      7.5. Protocol Constants and Associated Values .................106
+           7.5.1. Key Usage Numbers .................................106
+           7.5.2. PreAuthentication Data Types ......................108
+           7.5.3. Address Types .....................................109
+           7.5.4. Authorization Data Types ..........................109
+           7.5.5. Transited Encoding Types ..........................109
+           7.5.6. Protocol Version Number ...........................109
+           7.5.7. Kerberos Message Types ............................110
+           7.5.8. Name Types ........................................110
+           7.5.9. Error Codes .......................................110
+   8. Interoperability Requirements .................................113
+      8.1. Specification 2 ..........................................113
+      8.2. Recommended KDC Values ...................................116
+   9. IANA Considerations ...........................................116
+   10. Security Considerations ......................................117
+   11. Acknowledgements .............................................121
+   A. ASN.1 Module ..................................................123
+   B. Changes since RFC 1510 ........................................131
+   Normative References .............................................134
+   Informative References ...........................................135
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                     [Page 4]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+1.  Introduction
+
+   This document 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].
+
+   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.
+
+   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 because of new requirements and desires for features not
+   available in Version 4.  The design of Version 5 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 Ts'o, with help and contributed code from many
+   others.  Since RFC 1510 was issued, many individuals have proposed
+   extensions and revisions to the protocol.  This document reflects
+   some of these proposals.  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
+   Versions 4 and 5 can be found in [KNT94].
+
+   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 [RFC2119].
+
+
+
+
+
+Neuman, et al.              Standards Track                     [Page 5]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+1.1.  The Kerberos Protocol
+
+   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.  Kerberos
+   performs authentication under these conditions as a trusted third-
+   party authentication service by using conventional (shared secret
+   key) cryptography.  Extensions to Kerberos (outside the scope of this
+   document) can provide for the use of public key cryptography during
+   certain phases of the authentication protocol.  Such extensions
+   support Kerberos authentication for users registered with public key
+   certification authorities and 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) for
+   "credentials" for a given server.  The AS responds with these
+   credentials, encrypted in the client's key.  The credentials consist
+   of a "ticket" for the server and 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.  Note that many applications use Kerberos' functions
+   only upon the initiation of a stream-based network connection.
+   Unless an application performs encryption or integrity protection for
+   the data stream, the identity verification applies only to the
+   initiation of the connection, and it does not guarantee that
+   subsequent messages on the connection originate from the same
+   principal.
+
+   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 calls to the Kerberos library directly or through the Generic
+   Security Services Application Programming Interface (GSS-API)
+   described in a separate document [RFC4121].  These calls result in
+   the transmission of the messages necessary to achieve authentication.
+
+
+
+Neuman, et al.              Standards Track                     [Page 6]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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, in practice they are implemented 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.  Because 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 by using the session key (passed in the ticket and
+   contained in the credentials).  This approach provides detection of
+   both replay attacks and message stream modification attacks.  It is
+   accomplished by generating and transmitting a collision-proof
+   checksum (elsewhere called a hash or digest function) of the client's
+   message, keyed with the session key.  Privacy and integrity of the
+   messages exchanged between principals can be secured by encrypting
+   the data to be passed by using the session key contained in the
+   ticket or the sub-session key found in the authenticator.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                     [Page 7]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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.2.  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.  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 TGT for the remote realm's
+   ticket-granting service from its local realm.  When that TGT is used,
+   the remote ticket-granting service uses the inter-realm key (which
+   usually differs from its own normal TGS key) to decrypt the TGT; thus
+   it is certain that the ticket 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.
+
+   Without cross-realm operation, and with appropriate permission, the
+   client can arrange registration of a separately-named principal 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.
+
+   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 may be 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.
+
+
+
+Neuman, et al.              Standards Track                     [Page 8]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 Key Distribution Center
+   (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 KDCs for
+   intermediate realms may also check the transited field as they issue
+   TGTs for other realms, but they are encouraged not to do so.  A
+   client may request that the KDCs not check the transited field by
+   setting the DISABLE-TRANSITED-CHECK flag.  KDCs SHOULD honor this
+   flag.
+
+1.3.  Choosing a Principal with Which to Communicate
+
+   The Kerberos protocol provides the means for verifying (subject to
+   the assumptions in Section 1.6) that the entity with which one
+   communicates is the same entity that was registered with the KDC
+   using the claimed identity (principal name).  It is still necessary
+   to determine whether that identity corresponds to the entity with
+   which one intends to communicate.
+
+   When appropriate data has been exchanged in advance, the application
+   may perform this determination syntactically based on the application
+   protocol specification, information provided by the user, and
+   configuration files.  For example, the server principal name
+   (including realm) for a telnet server might be derived from the
+   user-specified host name (from the telnet command line), the "host/"
+   prefix specified in the application protocol specification, and a
+   mapping to a Kerberos realm derived syntactically from the domain
+   part of the specified hostname and information from the local
+   Kerberos realms database.
+
+   One can also rely on trusted third parties to make this
+   determination, but only when the data obtained from the third party
+   is suitably integrity-protected while resident on the third-party
+
+
+
+Neuman, et al.              Standards Track                     [Page 9]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   server and when transmitted.  Thus, for example, one should not rely
+   on an unprotected DNS record to map a host alias to the primary name
+   of a server, accepting the primary name as the party that one intends
+   to contact, since an attacker can modify the mapping and impersonate
+   the party.
+
+   Implementations of Kerberos and protocols based on Kerberos MUST NOT
+   use insecure DNS queries to canonicalize the hostname components of
+   the service principal names (i.e., they MUST NOT use insecure DNS
+   queries to map one name to another to determine the host part of the
+   principal name with which one is to communicate).  In an environment
+   without secure name service, application authors MAY append a
+   statically configured domain name to unqualified hostnames before
+   passing the name to the security mechanisms, but they should do no
+   more than that.  Secure name service facilities, if available, might
+   be trusted for hostname canonicalization, but such canonicalization
+   by the client SHOULD NOT be required by KDC implementations.
+
+   Implementation note: Many current implementations do some degree of
+   canonicalization of the provided service name, often using DNS even
+   though it creates security problems.  However, there is no
+   consistency among implementations as to whether the service name is
+   case folded to lowercase or whether reverse resolution is used.  To
+   maximize interoperability and security, applications SHOULD provide
+   security mechanisms with names that result from folding the user-
+   entered name to lowercase without performing any other modifications
+   or canonicalization.
+
+1.4.  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, an application should not consider it to
+   authorize the use of that service.
+
+   Separate authorization methods MAY be implemented as application-
+   specific access control functions and may utilize files on the
+   application server, 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 ticket's authorization data when encapsulated by the
+   KDC-issued authorization data element.
+
+
+
+Neuman, et al.              Standards Track                    [Page 10]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Applications should not 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 where other options for application authentication are
+   provided, or if they interoperate with other KDCs.
+
+1.5.  Extending Kerberos without Breaking Interoperability
+
+   As the deployed base of Kerberos implementations grows, extending
+   Kerberos becomes more important.  Unfortunately, some extensions to
+   the existing Kerberos protocol create interoperability issues because
+   of uncertainty regarding the treatment of certain extensibility
+   options by some implementations.  This section includes guidelines
+   that will enable future implementations to maintain interoperability.
+
+   Kerberos provides a general mechanism for protocol extensibility.
+   Some protocol messages contain typed holes -- sub-messages that
+   contain an octet-string along with an integer that defines how to
+   interpret the octet-string.  The integer types are registered
+   centrally, but they can be used both for vendor extensions and for
+   extensions standardized through the IETF.
+
+   In this document, the word "extension" refers to extension by
+   defining a new type to insert into an existing typed hole in a
+   protocol message.  It does not refer to extension by addition of new
+   fields to ASN.1 types, unless the text explicitly indicates
+   otherwise.
+
+1.5.1.  Compatibility with RFC 1510
+
+   Note that existing Kerberos message formats cannot readily be
+   extended by adding fields to the ASN.1 types.  Sending additional
+   fields often results in the entire message being discarded without an
+   error indication.  Future versions of this specification will provide
+   guidelines to ensure that ASN.1 fields can be added without creating
+   an interoperability problem.
+
+   In the meantime, all new or modified implementations of Kerberos that
+   receive an unknown message extension SHOULD preserve the encoding of
+   the extension but otherwise ignore its presence.  Recipients MUST NOT
+   decline a request simply because an extension is present.
+
+   There is one exception to this rule.  If an unknown authorization
+   data element type is received by a server other than the ticket-
+   granting service either in an AP-REQ or in a ticket contained in an
+   AP-REQ, then authentication MUST fail.  One of the primary uses of
+   authorization data is to restrict the use of the ticket.  If the
+
+
+
+Neuman, et al.              Standards Track                    [Page 11]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   service cannot determine whether the restriction applies to that
+   service, then a security weakness may result if the ticket can be
+   used for that service.  Authorization elements that are optional
+   SHOULD be enclosed in the AD-IF-RELEVANT element.
+
+   The ticket-granting service MUST ignore but propagate to derivative
+   tickets any unknown authorization data types, unless those data types
+   are embedded in a MANDATORY-FOR-KDC element, in which case the
+   request will be rejected.  This behavior is appropriate because
+   requiring that the ticket-granting service understand unknown
+   authorization data types would require that KDC software be upgraded
+   to understand new application-level restrictions before applications
+   used these restrictions, decreasing the utility of authorization data
+   as a mechanism for restricting the use of tickets.  No security
+   problem is created because services to which the tickets are issued
+   will verify the authorization data.
+
+   Implementation note: Many RFC 1510 implementations ignore unknown
+   authorization data elements.  Depending on these implementations to
+   honor authorization data restrictions may create a security weakness.
+
+1.5.2.  Sending Extensible Messages
+
+   Care must be taken to ensure that old implementations can understand
+   messages sent to them, even if they do not understand an extension
+   that is used.  Unless the sender knows that an extension is
+   supported, the extension cannot change the semantics of the core
+   message or previously defined extensions.
+
+   For example, an extension including key information necessary to
+   decrypt the encrypted part of a KDC-REP could only be used in
+   situations where the recipient was known to support the extension.
+   Thus when designing such extensions it is important to provide a way
+   for the recipient to notify the sender of support for the extension.
+   For example in the case of an extension that changes the KDC-REP
+   reply key, the client could indicate support for the extension by
+   including a padata element in the AS-REQ sequence.  The KDC should
+   only use the extension if this padata element is present in the
+   AS-REQ.  Even if policy requires the use of the extension, it is
+   better to return an error indicating that the extension is required
+   than to use the extension when the recipient may not support it.
+   Debugging implementations that do not interoperate is easier when
+   errors are returned.
+
+1.6.  Environmental Assumptions
+
+   Kerberos imposes a few assumptions on the environment in which it can
+   properly function, including the following:
+
+
+
+Neuman, et al.              Standards Track                    [Page 12]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   *  "Denial of service" attacks are not solved with Kerberos.  There
+      are places in the 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 not-uncommon "normal" failure modes for the system) are
+      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 to 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 per-server basis, but it 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.7.  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.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 13]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 use that ticket
+      successfully in an authentication exchange.
+
+   Encryption Type (etype)
+      When associated with encrypted data, an encryption type identifies
+      the algorithm used to encrypt the data and is used to select the
+      appropriate algorithm for decrypting the data.  Encryption type
+      tags are communicated in other messages to enumerate algorithms
+      that are desired, supported, preferred, or allowed to be used for
+      encryption of data between parties.  This preference is combined
+      with local information and policy to select an algorithm to be
+      used.
+
+   KDC
+      Key Distribution Center.  A network service that supplies tickets
+      and temporary session keys; or an instance of that service or the
+
+
+
+Neuman, et al.              Standards Track                    [Page 14]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      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
+      The name given to the Project Athena's authentication service, the
+      protocol used by that service, or the code used to implement the
+      authentication service.  The name is adopted from the three-headed
+      dog that guards Hades.
+
+   Key Version Number (kvno)
+      A tag associated with encrypted data identifies which key was used
+      for encryption when a long-lived key associated with a principal
+      changes over time.  It is used during the transition to a new key
+      so that the party decrypting a message can tell whether the data
+      was encrypted with the old or the new key.
+
+   Plaintext
+      The input to an encryption function or the output of a decryption
+      function.  Decryption transforms ciphertext into plaintext.
+
+   Principal
+      A named client or server entity that participates in a network
+      communication, with one name that is considered canonical.
+
+   Principal identifier
+      The canonical name used to identify each different principal
+      uniquely.
+
+   Seal
+      To encipher a record containing several fields in such a way that
+      the fields cannot be individually replaced without 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 MAY be derived
+      from a password.
+
+   Server
+      A particular Principal that provides a resource to network
+      clients.  The server is sometimes referred to as the Application
+      Server.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 15]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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".  In
+      the Kerberos system, a session key is generated by the KDC.  The
+      session key is distinct from the sub-session key, described next.
+
+   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.  The
+      sub-session key is also referred to as the subkey.
+
+   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 that are used to
+   indicate 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 give examples of reasons to
+   use them.  With the exception of the INVALID flag, clients MUST
+   ignore ticket flags that are not recognized.  KDCs MUST ignore KDC
+   options that are not recognized.  Some implementations of RFC 1510
+   are known to reject unknown KDC options, so clients may need to
+   resend a request without new KDC options if the request was rejected
+   when sent with options added since RFC 1510.  Because new KDCs will
+   ignore unknown options, clients MUST confirm that the ticket returned
+   by the KDC meets their needs.
+
+   Note that it is not, in general, possible to determine whether an
+   option was not honored because it was not understood or because it
+   was rejected through either configuration or policy.  When adding a
+   new option to the Kerberos protocol, designers should consider
+   whether the distinction is important for their option.  If it is, a
+   mechanism for the KDC to return an indication that the option was
+   understood but rejected needs to be provided in the specification of
+   the option.  Often in such cases, the mechanism needs to be broad
+   enough to permit an error or reason to be returned.
+
+
+
+Neuman, et al.              Standards Track                    [Page 16]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+2.1.  Initial, Pre-authenticated, and Hardware-Authenticated Tickets
+
+   The INITIAL flag indicates that a ticket was issued using the AS
+   protocol, rather than issued based on a TGT.  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 can thus be assured that the
+   client's key was recently presented to the authentication server.
+
+   The PRE-AUTHENT and HW-AUTHENT flags provide additional 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 TGT (in which case the INITIAL flag is
+   clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward
+   from the TGT).
+
+2.2.  Invalid Tickets
+
+   The INVALID flag indicates that a ticket is invalid.  Application
+   servers MUST reject tickets that have this flag set.  A postdated
+   ticket will be issued in this form.  Invalid tickets MUST be
+   validated by the KDC before use, by being presented 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 that 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 that 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 whether the ticket had been reported stolen since its
+
+
+
+Neuman, et al.              Standards Track                    [Page 17]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   last renewal; it will refuse to renew 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 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 TGT in order to issue a postdated ticket
+   based on the presented ticket.  It is reset by default; a client MAY
+   request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ
+   message.  This flag does not allow a client to obtain a postdated
+   TGT; postdated TGTs can only be 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 TGT 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 TGT.  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
+
+
+
+Neuman, et al.              Standards Track                    [Page 18]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 do this by granting it a proxy.
+
+   The process of granting a proxy by using the proxy and proxiable
+   flags is used to provide credentials for use with specific services.
+   Though conceptually also a proxy, users wishing to delegate their
+   identity in a form usable for all purposes MUST use the ticket
+   forwarding mechanism described in the next section to forward a TGT.
+
+   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 TGT) 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 TGT, and that it be 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 often valid only from those network addresses
+   specifically included in the ticket, but it is permissible as a
+   policy option to allow requests and to issue tickets with no network
+   addresses specified.  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
+   that is granted is complete use of the client's identity.  An example
+   of where it might be used is when a user logs in to a remote system
+
+
+
+Neuman, et al.              Standards Track                    [Page 19]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 TGTs 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 TGT.
+
+   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, specifies
+   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.
+
+   If addressless tickets are forwarded from one system to another,
+   clients SHOULD still use this option to obtain a new TGT in order to
+   have different session keys on the different systems.
+
+2.7.  Transited Policy Checking
+
+   In Kerberos, the application server is ultimately responsible for
+   accepting or rejecting authentication, and it SHOULD check that only
+   suitably trusted KDCs are relied upon to authenticate a principal.
+   The transited field in the ticket identifies which realms (and thus
+   which KDCs) were involved in the authentication process, and an
+   application server would normally check this field.  If any of these
+   are untrusted to authenticate the indicated client principal
+   (probably determined by a realm-based policy), the authentication
+   attempt MUST be rejected.  The presence of trusted KDCs in this list
+   does not provide any guarantee; an untrusted KDC may have fabricated
+   the list.
+
+   Although the end server ultimately decides whether authentication is
+   valid, the KDC for the end server's realm MAY apply a realm-specific
+   policy for validating the transited field and accepting credentials
+   for cross-realm authentication.  When the KDC applies such checks and
+   accepts such cross-realm authentication, it will set the
+   TRANSITED-POLICY-CHECKED flag in the service tickets it issues based
+
+
+
+Neuman, et al.              Standards Track                    [Page 20]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   on the cross-realm TGT.  A client MAY request that the KDCs not check
+   the transited field by setting the DISABLE-TRANSITED-CHECK flag.
+   KDCs are encouraged but not required to honor this flag.
+
+   Application servers MUST either do the transited-realm checks
+   themselves or reject cross-realm tickets without
+   TRANSITED-POLICY-CHECKED set.
+
+2.8.  OK as Delegate
+
+   For some applications, a client may need to delegate authority to a
+   server to act on its behalf in contacting other services.  This
+   requires that the client forward credentials to an intermediate
+   server.  The ability for a client to obtain a service ticket to a
+   server conveys no information to the client about whether the server
+   should be trusted to accept delegated credentials.  The
+   OK-AS-DELEGATE provides a way for a KDC to communicate local realm
+   policy to a client regarding whether an intermediate server is
+   trusted to accept such credentials.
+
+   The copy of the ticket flags in the encrypted part of the KDC reply
+   may have the OK-AS-DELEGATE flag set to indicate to the client that
+   the server specified in the ticket has been determined by the policy
+   of the realm to be a suitable recipient of delegation.  A client can
+   use the presence of this flag to help it decide whether to delegate
+   credentials (grant either a proxy or a forwarded TGT) to this server.
+   It is acceptable 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.
+
+2.9.  Other KDC Options
+
+   There are three additional options that MAY be set in a client's
+   request of the KDC.
+
+2.9.1.  Renewable-OK
+
+   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 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.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 21]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+2.9.2.  ENC-TKT-IN-SKEY
+
+   In its basic form, the Kerberos protocol supports authentication in a
+   client-server setting and is not well suited to authentication in a
+   peer-to-peer environment because the long-term key of the user does
+   not remain on the workstation after initial login.  Authentication of
+   such peers may be supported by Kerberos in its user-to-user variant.
+   The ENC-TKT-IN-SKEY option supports user-to-user authentication by
+   allowing the KDC to issue a service ticket encrypted using the
+   session key from another TGT issued to another user.  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 additional
+   second TGT provided with the request.  See Section 3.3.3 for specific
+   details.
+
+2.9.3.  Passwordless Hardware Authentication
+
+   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
+   some form of hardware authentication instead of or in addition to the
+   client's password or other long-lived encryption key.
+   OPT-HARDWARE-AUTH is honored only by the authentication service.  If
+   supported and allowed by policy, the KDC will return an error code of
+   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
+   perform such authentication.
+
+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)
+
+
+
+Neuman, et al.              Standards Track                    [Page 22]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   without requiring further use of the client's secret key.  This
+   exchange is also used to request credentials for services that must
+   not be mediated through the Ticket-Granting Service, but rather
+   require knowledge of a principal's secret key, such as the password-
+   changing service (the password-changing service denies requests
+   unless the requester can demonstrate knowledge of the user's old
+   password; requiring this knowledge prevents unauthorized password
+   changes by someone walking up to an unattended session).
+
+   This exchange does not by itself provide any assurance of the
+   identity of the user.  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.
+
+   The AS 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,
+   other information about the credentials it is requesting, and a
+   randomly generated nonce, which can be used to detect replays and to
+   associate replies with the matching requests.  This nonce MUST be
+   generated randomly by the client and remembered for checking against
+   the nonce in the expected reply.  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 encrypted part of the KRB_AS_REP message also contains the nonce
+   that MUST be matched with the nonce from the KRB_AS_REQ message.
+
+   Without pre-authentication, 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.  However,
+   an attacker can send a KRB_AS_REQ message to get known plaintext in
+   order to attack the principal's key.  Especially if the key is based
+   on a password, this may create a security exposure.  So 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 SHOULD be used for pre-authentication as described in
+   sections 3.1.1 and 5.2.7.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 23]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 that can
+   be used to associate it with the message to which it replies.  The
+   contents of the KRB_ERROR message are not integrity-protected.  As
+   such, the client cannot detect replays, fabrications, or
+   modifications.  A solution to this problem will be included in a
+   future version of the protocol.
+
+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).
+
+   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.
+
+   Because Kerberos can run over unreliable transports such as UDP, the
+   KDC MUST be prepared to retransmit responses in case they are lost.
+   If a KDC receives a request identical to one it has recently
+   processed successfully, the KDC MUST respond with a KRB_AS_REP
+   message rather than a replay error.  In order to reduce ciphertext
+   given to a potential attacker, KDCs MAY send the same response
+   generated when the request was first handled.  KDCs MUST obey this
+   replay behavior even if the actual transport in use is reliable.
+
+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
+   unknown because it doesn't exist in the KDC's principal database,
+   then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
+
+   If required to do so, 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 pre-authentication is
+
+
+
+Neuman, et al.              Standards Track                    [Page 24]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   required, but was not present in the request, an error message with
+   the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA
+   object will be stored in the e-data field of the KRB-ERROR message to
+   specify which pre-authentication mechanisms are acceptable.  Usually
+   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
+   described below.  If the server cannot accommodate any encryption
+   type requested by the client, an error message with code
+   KDC_ERR_ETYPE_NOSUPP is returned.  Otherwise, the KDC generates a
+   'random' session key, meaning that, among other things, it should be
+   impossible to guess the next session key based on knowledge of past
+   session keys.  Although this can 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.  See [RFC4086]
+   for an in-depth discussion of randomness.
+
+   In response to an AS request, if there are multiple encryption keys
+   registered for a client in the Kerberos database, then the etype
+   field from the AS request is used by the KDC to select the encryption
+   method to be used to protect the encrypted part of the KRB_AS_REP
+   message that is sent to the client.  If there is more than one
+   supported strong encryption type in the etype list, the KDC SHOULD
+   use the first valid strong etype for which an encryption key is
+   available.
+
+   When the user's key is generated from a password or pass phrase, the
+   string-to-key function for the particular encryption key type is
+   used, as specified in [RFC3961].  The salt value and additional
+   parameters for the string-to-key function have default values
+   (specified by Section 4 and by the encryption mechanism
+   specification, respectively) that may be overridden by
+   pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO,
+   PA-ETYPE-INFO2, etc).  Since the KDC is presumed to store a copy of
+   the resulting key only, these values should not be changed for
+   password-based keys except when changing the principal's key.
+
+   When the AS server is to include pre-authentication data in a
+   KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
+   INFO, if the etype field of the client's AS-REQ lists at least one
+   "newer" encryption type.  Otherwise (when the etype field of the
+   client's AS-REQ does not list any "newer" encryption types), it MUST
+   send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for
+   each enctype).  A "newer" enctype is any enctype first officially
+   specified concurrently with or subsequent to the issue of this RFC.
+   The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
+   "newer" enctypes.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 25]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   It is not possible to generate a user's key reliably given a pass
+   phrase without contacting the KDC, since it will not be known whether
+   alternate salt or parameter values are required.
+
+   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 and 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 starttime 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 starttime 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
+   starttime is checked against the policy of the local realm (the
+   administrator might decide to prohibit certain types or ranges of
+   postdated tickets), and if the ticket's starttime is acceptable, it
+   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 starttime has been reached.
+
+   The expiration time of the ticket will be set to the earlier of the
+   requested endtime and a time determined by local policy, possibly by
+   using realm- or principal-specific factors.  For example, the
+   expiration time MAY be set to the earliest of the following:
+
+      *  The expiration time (endtime) requested in the KRB_AS_REQ
+         message.
+
+      *  The ticket's starttime plus the maximum allowable lifetime
+         associated with the client principal from the authentication
+         server's database.
+
+      *  The ticket's starttime plus the maximum allowable lifetime
+         associated with the server principal.
+
+      *  The ticket's starttime plus the maximum lifetime set by the
+         policy of the local realm.
+
+   If the requested expiration time minus the starttime (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'
+
+
+
+Neuman, et al.              Standards Track                    [Page 26]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 MAY be set to the earliest of:
+
+      *  Its requested value.
+
+      *  The starttime of the ticket plus the minimum of the two maximum
+         renewable lifetimes associated with the principals' database
+         entries.
+
+      *  The starttime 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 postdated (the starttime is in the future), its
+   INVALID flag will also be set.
+
+   If all of the above succeed, the server will encrypt the ciphertext
+   part of the ticket using the encryption key extracted from the server
+   principal's record in the Kerberos database using the encryption type
+   associated with the server principal's key.  (This choice is NOT
+   affected by the etype field in the request.)  It then 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 an acceptable encryption
+   method requested in the etype field of the request, or in some key
+   specified by pre-authentication mechanisms being used.
+
+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
+
+
+
+Neuman, et al.              Standards Track                    [Page 27]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   message.  The client decrypts the encrypted part of the response
+   using its secret key and 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 last-req field (and the deprecated
+   key-expiration field) from the encrypted part of the response MAY be
+   checked to notify the user of impending key expiration.  This enables
+   the client program to suggest remedial action, such as a password
+   change.
+
+   Upon validation of the KRB_AS_REP message (by checking the returned
+   nonce against that sent in the KRB_AS_REQ message), the client knows
+   that the current time on the KDC is that read from the authtime field
+   of the encrypted part of the reply.  The client can optionally use
+   this value for clock synchronization in subsequent messages by
+   recording with the ticket the difference (offset) between the
+   authtime value and the local clock.  This offset can then be used by
+   the same user to adjust the time read from the system clock when
+   generating messages [DGT96].
+
+   This technique MUST be used when adjusting for clock skew instead of
+   directly changing the system clock, because the KDC reply is only
+   authenticated to the user whose secret key was used, but not to the
+   system or workstation.  If the clock were adjusted, an attacker
+   colluding with a user logging into a workstation could agree on a
+   password, resulting in a KDC reply that would be correctly validated
+   even though it did not originate from a KDC trusted by the
+   workstation.
+
+   Proper decryption of the KRB_AS_REP message is not sufficient for the
+   host to verify the identity of the user; the user and an attacker
+   could cooperate to generate a KRB_AS_REP format message that 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 that 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 for recovery.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 28]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+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 that 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 (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).  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 system
+   time and its name, and optionally from 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
+   MUST NOT be re-used and SHOULD be rejected if replayed to a server.
+   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.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 29]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 (for user-to-user authentication,
+   see section 3.7) 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.
+
+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 user-to-user authentication is in use, and that the
+   ticket is encrypted in the session key from the server's TGT rather
+   than in the server's secret key.  See Section 3.7 for a more complete
+   description of the effect of user-to-user authentication on all
+   messages in the Kerberos protocol.
+
+   Because 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), the
+
+
+
+Neuman, et al.              Standards Track                    [Page 30]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 that is has 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; normally this is caused by a client error or an
+   attempted attack.  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.
+
+   Unless the application server provides its own suitable means to
+   protect against replay (for example, a challenge-response sequence
+   initiated by the server after authentication, or use of a server-
+   generated encryption subkey), the server MUST utilize a replay cache
+   to remember any authenticator presented within the allowable clock
+   skew.  Careful analysis of the application protocol and
+   implementation is recommended before eliminating this cache.  The
+   replay cache will store at least the server name, along with the
+   client name, time, and microsecond fields from the recently-seen
+   authenticators, and if a matching tuple is found, the
+   KRB_AP_ERR_REPEAT error is returned.  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 have their authenticators rejected if the time
+   and microsecond fields happen to match some other client's
+   authenticator.
+
+   If a server loses track of authenticators presented within the
+   allowable clock skew, it MUST reject all requests until the clock
+   skew interval has passed, providing assurance that any lost or
+   replayed authenticators will fall outside the allowable clock skew
+   and can no longer be successfully replayed.  If this were not done,
+   an attacker could subvert the authentication by recording the ticket
+   and authenticator sent over the network to a server and replaying
+   them following an event that caused the server to lose track of
+   recently seen authenticators.
+
+   Implementation note: If a client generates multiple requests to the
+   KDC with the same timestamp, including the microsecond field, all but
+   the first of the requests received will be rejected as replays.  This
+
+
+
+Neuman, et al.              Standards Track                    [Page 31]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   might happen, for example, if the resolution of the client's clock is
+   too coarse.  Client implementations SHOULD ensure that the timestamps
+   are not reused, possibly by incrementing the microseconds field in
+   the time stamp when the clock returns the same time for multiple
+   requests.
+
+   If multiple servers (for example, different services on one machine,
+   or a single service implemented on multiple machines) share a service
+   principal (a practice that we do not recommend in general, but that
+   we acknowledge will be used in some cases), either they MUST share
+   this replay cache, or the application protocol MUST be designed so as
+   to eliminate the need for it.  Note that this applies to all of the
+   services.  If any of the application protocols does not have replay
+   protection built in, an authenticator used with such a service could
+   later be replayed to a different service with the same service
+   principal but no replay protection, if the former doesn't record the
+   authenticator information in the common replay cache.
+
+   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 starttime inside the Ticket.  If the starttime 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, that the client has been authenticated to the
+   server.
+
+   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 decision based upon
+   the authenticated name of the user, the requested operation, local
+   access control information such as that contained in a .k5login or
+   .k5users file, and possibly a separate distributed authorization
+   service.
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 32]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+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 (authenticating not only 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).  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.
+
+   Note that 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.
+
+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 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.  (Note that for
+   encrypting the KRB_AP_REP message, the sub-session key is not used,
+   even if it is present in the Authentication.)
+
+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 that can be used by the application.
+   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.  The application MAY choose the actual encryption key
+   to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses
+   based on the session key from the ticket and subkeys in the
+   KRB_AP_REP message and the authenticator.  Implementations of the
+   protocol MAY provide routines to choose subkeys based on session keys
+
+
+
+Neuman, et al.              Standards Track                    [Page 33]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   and random numbers and to generate a negotiated key to be returned in
+   the KRB_AP_REP message.
+
+   To mitigate the effect of failures in random number generation on the
+   client, it is strongly encouraged that any key derived by an
+   application for subsequent use include the full key entropy derived
+   from the KDC-generated session key carried in the ticket.  We leave
+   the protocol negotiations of how to use the key (e.g., for 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 subsequent 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 key proposed by 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.
+
+   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 the 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 ensure 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 TGS is initiated
+   by a client when it seeks to obtain authentication credentials for a
+   given server (which might be registered in a remote realm), when it
+   seeks to renew or validate an existing ticket, or when it seeks 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 TGT 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
+
+
+
+Neuman, et al.              Standards Track                    [Page 34]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   key.  Instead, the session key from the TGT 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 TGT 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 TGT and proxy
+   cases, the request MAY include one or more of the following: 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 TGT 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 that can be
+   used to detect replays, and to associate it with the message to which
+   it replies.  The KRB_ERROR message also contains information that can
+   be used to associate it with the message to which it replies.  The
+   same comments about integrity protection of KRB_ERROR messages
+   mentioned in Section 3.1 apply to the TGS exchange.
+
+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 believed to
+   be registered.  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 configuration 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 authenticated.  This
+   might result in the use of a realm that has been compromised, which
+   would result in an attacker's ability to compromise the
+   authentication of the application server to the client.
+
+   If the client knows the service principal name and realm and it does
+   not already possess a TGT for the appropriate realm, then one must be
+   obtained.  This is first attempted by requesting a TGT for the
+   destination realm from a Kerberos server for which the client
+   possesses a TGT (by using the KRB_TGS_REQ message recursively).  The
+
+
+
+Neuman, et al.              Standards Track                    [Page 35]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 that is 'closer' to the desired realm (further along the
+   standard hierarchical path between the client's realm and the
+   requested realm server's realm).  Note that in this case
+   misconfiguration of the Kerberos servers may cause loops in the
+   resulting authentication path, which the client should be careful to
+   detect and avoid.
+
+   If the Kerberos server returns a TGT for a realm 'closer' than the
+   desired realm, the client MAY use local policy configuration to
+   verify that the authentication path used is an acceptable one.
+   Alternatively, a client MAY choose its own authentication path,
+   rather than rely on the Kerberos server to select one.  In either
+   case, any policy or configuration information used to choose or
+   validate authentication paths, whether by the Kerberos server or by
+   the client, MUST be obtained from a trusted source.
+
+   When a client obtains a TGT that is 'closer' to the destination
+   realm, the client MAY cache this ticket and reuse it in future
+   KRB-TGS exchanges with services in the 'closer' realm.  However, if
+   the client were to obtain a TGT for the 'closer' realm by starting at
+   the initial KDC rather than as part of obtaining another ticket, then
+   a shorter path to the 'closer' realm might be used.  This shorter
+   path may be desirable because fewer intermediate KDCs would know the
+   session key of the ticket involved.  For this reason, clients SHOULD
+   evaluate whether they trust the realms transited in obtaining the
+   'closer' ticket when making a decision to use the ticket in future.
+
+   Once the client obtains a TGT for the appropriate realm, it
+   determines which Kerberos servers serve that realm and contacts one
+   of them.  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.  One of these options is the ENC-TKT-IN-SKEY
+   option used for user-to-user authentication.  An overview of user-
+   to-user authentication can be found in Section 3.7.  When generating
+   the KRB_TGS_REQ message, this option indicates that the client is
+   including a TGT obtained from the application server in the
+   additional tickets field of the request and that the KDC SHOULD
+   encrypt the ticket for the application server using the session key
+   from this additional ticket, instead of a server key from the
+   principal database.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 36]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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-authorizatfion-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.  If the client selects a sub-session key, care must be
+   taken to ensure the randomness of the selected sub-session key.
+
+   If the sub-session key is not specified, the session key from the TGT
+   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, by using
+   the session key from the TGT.
+
+   Once prepared, the message is sent to a Kerberos server for the
+   destination realm.
+
+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 (a) the accompanying ticket is not a TGT for the
+   current realm, but is for an application server in the current realm,
+   (b) the RENEW, VALIDATE, or PROXY options are specified in the
+   request, and (c) 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 MUST be rejected if the checksums do
+   not match (with an error code of KRB_AP_ERR_MODIFIED) or if the
+   checksum is 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.
+
+
+
+Neuman, et al.              Standards Track                    [Page 37]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   If any of the decryptions indicate failed integrity checks, the
+   KRB_AP_ERR_BAD_INTEGRITY error is returned.
+
+   As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
+   message if it receives a KRB_TGS_REQ message identical to one it has
+   recently processed.  However, if the authenticator is a replay, but
+   the rest of the request is not identical, then the KDC SHOULD return
+   KRB_AP_ERR_REPEAT.
+
+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 or for a
+   ticket granting server of an intermediate KDC to be contacted to
+   obtain the requested ticket.  The Kerberos database is queried to
+   retrieve the record for the appropriate server (including the key
+   with which the ticket will be encrypted).  If the request is for a
+   TGT 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 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 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
+
+
+
+Neuman, et al.              Standards Track                    [Page 38]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 TGTs.
+
+   If the requested starttime 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 starttime 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 TGT 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 starttime 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 TGT.
+
+   If the ENC-TKT-IN-SKEY option has been specified and an additional
+   ticket has been included in the request, it indicates that the client
+   is using user-to-user authentication to prove its identity to a
+   server that does not have access to a persistent key.  Section 3.7
+   describes the effect of this option on the entire Kerberos protocol.
+   When generating the KRB_TGS_REP message, this option in the
+   KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
+   using the key for the server to which the additional ticket was
+   issued and to verify that it is a TGT.  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.  If it is 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.
+
+   If (a) 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 TGS
+   itself, (b) the server is registered in the realm of the KDC, and (c)
+   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 requested, the KDC will check that the
+   starttime has passed and that the INVALID flag is set.  If the PROXY
+   option is requested, then the KDC will check that the PROXIABLE flag
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 39]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   is set in the ticket.  If the tests succeed and the ticket passes the
+   hotlist check described in the next section, the KDC will issue the
+   appropriate new ticket.
+
+   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 in the session key from the TGT.  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 TGT.
+
+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
+   that 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 TGT or renewable ticket cannot be used to gain
+   additional tickets (renewals or otherwise) once the theft has been
+   reported to the KDC for the realm in which the server resides.  Any
+   normal ticket obtained before it was reported stolen will still be
+   valid (because tickets require no interaction with the KDC), but only
+   until its normal expiration time.  If TGTs have been issued for
+   cross-realm authentication, use of the cross-realm TGT will not be
+   affected unless the hot-list is propagated to the KDCs for the realms
+   for which such cross-realm tickets were issued.
+
+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 TGT.  The name of the realm that issued the
+   TGT, if it is not the realm of the client principal, will be added to
+   the transited field of the ticket to be issued.  This is accomplished
+   by reading the transited field from the TGT (which is treated as an
+   unordered set of realm names), adding the new realm to the set, and
+   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
+
+
+
+Neuman, et al.              Standards Track                    [Page 40]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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.  Because the endpoints are not included, both local and
+   single-hop inter-realm authentication result in a transited field
+   that is empty.
+
+   Because this field has the name of each transited realm added to it,
+   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 preceding 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 either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were
+   endpoints, 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.  For the purpose of appending, the realm
+   preceding the first listed realm is considered the null realm ("").
+   If a realm name beginning with a "/" 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".
+
+   As in the example above, if /COM/HP/APOLLO and /COM/DEC were
+   endpoints, they would not be included in this field, and we would
+   have:
+
+
+
+Neuman, et al.              Standards Track                    [Page 41]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      "/COM,/HP"
+
+   A null subfield preceding or following a "," indicates that all
+   realms between the previous realm and the next realm have been
+   traversed.  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.  Thus, "," means
+   that all realms along the path between the client and the server have
+   been traversed.  ",EDU, /COM," means 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 sub-session key from the Authenticator, if it
+   was specified in the request, or the session key from the TGT, rather
+   than the client's secret key.  The server name returned in the reply
+   is the true principal name of the service.
+
+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 occurred).
+
+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 the keyed
+   checksum mandated to be implemented along with the crypto system used
+   for the sub-session or session key.  The checksum is generated using
+   the sub-session key, if present, or the session key.  Some
+   implementations use a different checksum algorithm for the KRB_SAFE
+   messages, but doing so in an interoperable manner is not always
+   possible.
+
+   The control information for the KRB_SAFE message includes both a
+   timestamp and a sequence number.  The designer of an application
+
+
+
+Neuman, et al.              Standards Track                    [Page 42]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 their being resent, the use of the timestamp is the
+   appropriate replay detection mechanism.  Using timestamps is also the
+   appropriate mechanism for multi-cast protocols in which 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 that uses keys compatible with the
+   sub-session or session key as appropriate (or with the application
+   key derived from the session or sub-session keys).  If it is not, a
+   KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address MUST
+   be 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.  To work with network address translation, senders MAY use
+   the directional address type specified in Section 8.1 for the sender
+   address and not include recipient addresses.  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 if they are present but not
+   current, the KRB_AP_ERR_SKEW error is generated.  Timestamps are not
+   required to be strictly ordered; they are only required to be in the
+   skew window.  If the server name, along with the client name, time,
+
+
+
+Neuman, et al.              Standards Track                    [Page 43]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   and microsecond fields from the Authenticator match any recently-seen
+   (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is
+   generated.  If an incorrect sequence number is included, or if a
+   sequence number is expected but not present, the KRB_AP_ERR_BADORDER
+   error is generated.  If neither a time-stamp and usec nor 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 modified in transit.
+
+   Implementations SHOULD accept any checksum algorithm they implement
+   that has both adequate security and keys compatible with the sub-
+   session or session key.  Unkeyed or non-collision-proof checksums are
+   not suitable for this use.
+
+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 occurred).  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
+
+
+
+Neuman, et al.              Standards Track                    [Page 44]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   the resultant plaintext.  If decryption shows that the data has been
+   modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
+
+   The sender's address MUST be 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.  If a recipient
+   address is specified or the recipient requires an address, then one
+   of the recipient's addresses MUST also appear as the recipient's
+   address in the message.  Where a sender's or receiver's address might
+   not otherwise match the address in a message because of network
+   address translation, an application MAY be written to use addresses
+   of the directional address type in place of the actual network
+   address.
+
+   A failed match for either case generates a KRB_AP_ERR_BADADDR error.
+   To work with network address translation, implementations MAY use the
+   directional address type defined in Section 7.1 for the sender
+   address and include no recipient address.
+
+   Next the timestamp and usec and/or the sequence number fields are
+   checked.  If timestamp and usec are expected and not present, or if
+   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 such recently-
+   seen tuples, the KRB_AP_ERR_REPEAT error is generated.  If an
+   incorrect sequence number is included, or if a sequence number is
+   expected but not present, the KRB_AP_ERR_BADORDER error is generated.
+   If neither a time-stamp and usec nor 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
+   seeing 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
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 45]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   ticket in the key field of the corresponding KrbCredInfo sequence of
+   the encrypted part of 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 they are 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 previously exchanged in the KRB_AP exchange (usually
+   the last key negotiated via subkeys, or the session key if no
+   negotiation has occurred).
+
+   Implementation note: When constructing a KRB_CRED message for
+   inclusion in a GSSAPI initial context token, the MIT implementation
+   of Kerberos will not encrypt the KRB_CRED message if the session key
+   is a DES or triple DES key.  For interoperability with MIT, the
+   Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
+   token if it is using a DES session key.  Starting at version 1.2.5,
+   MIT Kerberos can receive and decode either encrypted or unencrypted
+   KRB_CRED tokens in the GSSAPI exchange.  The Heimdal implementation
+   of Kerberos can also accept either encrypted or unencrypted KRB_CRED
+   messages.  Since the KRB_CRED message in a GSSAPI token is encrypted
+   in the authenticator, the MIT behavior does not present a security
+   problem, although it is a violation of the Kerberos specification.
+
+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 MAY verify 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.  The address check does not
+   provide any added security, since the address, if present, has
+   already been checked in the KRB_AP_REQ message and there is not any
+   benefit to be gained by an attacker in reflecting a KRB_CRED message
+   back to its originator.  Thus, the recipient MAY ignore the address
+   even if it is present in order to work better in Network Address
+   Translation (NAT) environments.  A failed match for either case
+
+
+
+Neuman, et al.              Standards Track                    [Page 46]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   generates a KRB_AP_ERR_BADADDR error.  Recipients MAY skip the
+   address check, as the KRB_CRED message cannot generally be reflected
+   back to the originator.  The timestamp and usec fields (and the nonce
+   field, if required) are checked next.  If the timestamp and usec are
+   not present, or if 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 credentials cache together with the session key and
+   other information in the corresponding KrbCredInfo sequence from the
+   encrypted part of the KRB_CRED message.
+
+3.7.  User-to-User Authentication Exchanges
+
+   User-to-User authentication provides a method to perform
+   authentication when the verifier does not have a access to long-term
+   service key.  This might be the case when running a server (for
+   example, a window server) as a user on a workstation.  In such cases,
+   the server may have access to the TGT obtained when the user logged
+   in to the workstation, but because the server is running as an
+   unprivileged user, it might not have access to system keys.  Similar
+   situations may arise when running peer-to-peer applications.
+
+                             Summary
+
+       Message direction                    Message type     Sections
+       0. Message from application server   Not specified
+       1. Client to Kerberos                KRB_TGS_REQ      3.3 & 5.4.1
+       2. Kerberos to client                KRB_TGS_REP or   3.3 & 5.4.2
+                                            KRB_ERROR        5.9.1
+       3. Client to application server      KRB_AP_REQ       3.2 & 5.5.1
+
+   To address this problem, the Kerberos protocol allows the client to
+   request that the ticket issued by the KDC be encrypted using a
+   session key from a TGT issued to the party that will verify the
+   authentication.  This TGT must be obtained from the verifier by means
+   of an exchange external to the Kerberos protocol, usually as part of
+   the application protocol.  This message is shown in the summary above
+   as message 0.  Note that because the TGT is encrypted in the KDC's
+   secret key, it cannot be used for authentication without possession
+   of the corresponding secret key.  Furthermore, because the verifier
+   does not reveal the corresponding secret key, providing a copy of the
+   verifier's TGT does not allow impersonation of the verifier.
+
+   Message 0 in the table above represents an application-specific
+   negotiation between the client and server, at the end of which both
+   have determined that they will use user-to-user authentication, and
+   the client has obtained the server's TGT.
+
+
+
+Neuman, et al.              Standards Track                    [Page 47]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Next, the client includes the server's TGT as an additional ticket in
+   its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
+   specifies the ENC-TKT-IN-SKEY option in its request.
+
+   If validated according to the instructions in Section 3.3.3, the
+   application ticket returned to the client (message 2 in the table
+   above) will be encrypted using the session key from the additional
+   ticket and the client will note this when it uses or stores the
+   application ticket.
+
+   When contacting the server using a ticket obtained for user-to-user
+   authentication (message 3 in the table above), the client MUST
+   specify the USE-SESSION-KEY flag in the ap-options field.  This tells
+   the application server to use the session key associated with its TGT
+   to decrypt the server ticket provided in the application request.
+
+4.  Encryption and Checksum Specifications
+
+   The Kerberos protocols described in this document are designed to
+   encrypt messages of arbitrary sizes, using stream or block encryption
+   ciphers.  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 to
+   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 to prove its knowledge
+   thereof in a response verifies the identity of the service.
+
+   [RFC3961] defines a framework for defining encryption and checksum
+   mechanisms for use with Kerberos.  It also defines several such
+   mechanisms, and more may be added in future updates to that document.
+
+   The string-to-key operation provided by [RFC3961] is used to produce
+   a long-term key for a principal (generally for a user).  The default
+   salt string, if none is provided via pre-authentication data, is the
+   concatenation of the principal's realm and name components, in order,
+   with no separators.  Unless it is indicated otherwise, the default
+   string-to-key opaque parameter set as defined in [RFC3961] is used.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 48]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Encrypted data, keys, and checksums are transmitted using the
+   EncryptedData, EncryptionKey, and Checksum data objects defined in
+   Section 5.2.9.  The encryption, decryption, and checksum operations
+   described in this document use the corresponding encryption,
+   decryption, and get_mic operations described in [RFC3961], with
+   implicit "specific key" generation using the "key usage" values
+   specified in the description of each EncryptedData or Checksum object
+   to vary the key for each operation.  Note that in some cases, the
+   value to be used is dependent on the method of choosing the key or
+   the context of the message.
+
+   Key usages are unsigned 32-bit integers; zero is not permitted.  The
+   key usage values for encrypting or checksumming Kerberos messages are
+   indicated in Section 5 along with the message definitions.  The key
+   usage values 512-1023 are reserved for uses internal to a Kerberos
+   implementation.  (For example, seeding a pseudo-random number
+   generator with a value produced by encrypting something with a
+   session key and a key usage value not used for any other purpose.)
+   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.  Key usage values are
+   also summarized in a table in Section 7.5.1.
+
+   There might exist other documents that define protocols in terms of
+   the RFC 1510 encryption types or checksum types.  These documents
+   would not know about key usages.  In order that these specifications
+   continue to be meaningful until they are updated, if no key usage
+   values are specified, then key usages 1024 and 1025 must be used to
+   derive keys for encryption and checksums, respectively.  (This does
+   not apply to protocols that do their own encryption independent of
+   this framework, by directly using the key resulting from the Kerberos
+   authentication exchange.)  New protocols defined in terms of the
+   Kerberos encryption and checksum types SHOULD use their own key usage
+   values.
+
+   Unless it is indicated otherwise, no cipher state chaining is done
+   from one encryption operation to another.
+
+   Implementation note: Although it is not recommended, some application
+   protocols will continue to use the key data directly, even if only in
+   currently existing protocol specifications.  An implementation
+   intended to support general Kerberos applications may therefore need
+   to make key data available, as well as the attributes and operations
+   described in [RFC3961].  One of the more common reasons for directly
+   performing encryption is direct control over negotiation and
+   selection of a "sufficiently strong" encryption algorithm (in the
+   context of a given application).  Although Kerberos does not directly
+   provide a facility for negotiating encryption types between the
+
+
+
+Neuman, et al.              Standards Track                    [Page 49]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   application client and server, there are approaches for using
+   Kerberos to facilitate this negotiation.  For example, a client may
+   request only "sufficiently strong" session key types from the KDC and
+   expect that any type returned by the KDC will be understood and
+   supported by the application server.
+
+5.  Message Specifications
+
+   The ASN.1 collected here should be identical to the contents of
+   Appendix A.  In the case of a conflict, the contents of Appendix A
+   shall take precedence.
+
+   The Kerberos protocol is defined here in terms of Abstract Syntax
+   Notation One (ASN.1) [X680], which provides a syntax for specifying
+   both the abstract layout of protocol messages as well as their
+   encodings.  Implementors not utilizing an existing ASN.1 compiler or
+   support library are cautioned to understand the actual ASN.1
+   specification thoroughly in order to ensure correct implementation
+   behavior.  There is more complexity in the notation than is
+   immediately obvious, and some tutorials and guides to ASN.1 are
+   misleading or erroneous.
+
+   Note that in several places, changes to abstract types from RFC 1510
+   have been made.  This is in part to address widespread assumptions
+   that various implementors have made, in some cases resulting in
+   unintentional violations of the ASN.1 standard.  These are clearly
+   flagged where they occur.  The differences between the abstract types
+   in RFC 1510 and abstract types in this document can cause
+   incompatible encodings to be emitted when certain encoding rules,
+   e.g., the Packed Encoding Rules (PER), are used.  This theoretical
+   incompatibility should not be relevant for Kerberos, since Kerberos
+   explicitly specifies the use of the Distinguished Encoding Rules
+   (DER).  It might be an issue for protocols seeking to use Kerberos
+   types with other encoding rules.  (This practice is not recommended.)
+   With very few exceptions (most notably the usages of BIT STRING), the
+   encodings resulting from using the DER remain identical between the
+   types defined in RFC 1510 and the types defined in this document.
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+
+
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 50]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   KerberosV5Spec2 {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2) modules(4) krb5spec2(2)
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   -- rest of definitions here
+
+   END
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   Note that in some other publications (such as [RFC1510] and
+   [RFC1964]), the "dod" portion of the object identifier is erroneously
+   specified as having the value "5".  In the case of RFC 1964, use of
+   the "correct" OID value would result in a change in the wire
+   protocol; therefore, it remains unchanged for now.
+
+   Note that elsewhere in this document, nomenclature for various
+   message types is inconsistent, but it largely follows C language
+   conventions, including use of underscore (_) characters and all-caps
+   spelling of names intended to be numeric constants.  Also, in some
+   places, identifiers (especially those referring to constants) are
+   written in all-caps in order to distinguish them from surrounding
+   explanatory text.
+
+   The ASN.1 notation does not permit underscores in identifiers, so in
+   actual ASN.1 definitions, underscores are replaced with hyphens (-).
+   Additionally, structure member names and defined values in ASN.1 MUST
+   begin with a lowercase letter, whereas type names MUST begin with an
+   uppercase letter.
+
+5.1.  Specific Compatibility Notes on ASN.1
+
+   For compatibility purposes, implementors should heed the following
+   specific notes regarding the use of ASN.1 in Kerberos.  These notes
+   do not describe deviations from standard usage of ASN.1.  The purpose
+   of these notes is instead to describe some historical quirks and
+   non-compliance of various implementations, as well as historical
+   ambiguities, which, although they are valid ASN.1, can lead to
+   confusion during implementation.
+
+5.1.1.  ASN.1 Distinguished Encoding Rules
+
+   The encoding of Kerberos protocol messages shall obey the
+   Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
+   Some implementations (believed primarily to be those derived from DCE
+   1.1 and earlier) are known to use the more general Basic Encoding
+
+
+
+Neuman, et al.              Standards Track                    [Page 51]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Rules (BER); in particular, these implementations send indefinite
+   encodings of lengths.  Implementations MAY accept such encodings in
+   the interest of backward compatibility, though implementors are
+   warned that decoding fully-general BER is fraught with peril.
+
+5.1.2.  Optional Integer Fields
+
+   Some implementations do not internally distinguish between an omitted
+   optional integer value and a transmitted value of zero.  The places
+   in the protocol where this is relevant include various microseconds
+   fields, nonces, and sequence numbers.  Implementations SHOULD treat
+   omitted optional integer values as having been transmitted with a
+   value of zero, if the application is expecting this.
+
+5.1.3.  Empty SEQUENCE OF Types
+
+   There are places in the protocol where a message contains a SEQUENCE
+   OF type as an optional member.  This can result in an encoding that
+   contains an empty SEQUENCE OF encoding.  The Kerberos protocol does
+   not semantically distinguish between an absent optional SEQUENCE OF
+   type and a present optional but empty SEQUENCE OF type.
+   Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
+   marked OPTIONAL, but SHOULD accept them as being equivalent to an
+   omitted OPTIONAL type.  In the ASN.1 syntax describing Kerberos
+   messages, instances of these problematic optional SEQUENCE OF types
+   are indicated with a comment.
+
+5.1.4.  Unrecognized Tag Numbers
+
+   Future revisions to this protocol may include new message types with
+   different APPLICATION class tag numbers.  Such revisions should
+   protect older implementations by only sending the message types to
+   parties that are known to understand them; e.g., by means of a flag
+   bit set by the receiver in a preceding request.  In the interest of
+   robust error handling, implementations SHOULD gracefully handle
+   receiving a message with an unrecognized tag anyway, and return an
+   error message, if appropriate.
+
+   In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
+   incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
+   respond to messages received with an unknown tag over UDP transport
+   in order to avoid denial of service attacks.  For non-KDC
+   applications, the Kerberos implementation typically indicates an
+   error to the application which takes appropriate steps based on the
+   application protocol.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 52]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+5.1.5.  Tag Numbers Greater Than 30
+
+   A naive implementation of a DER ASN.1 decoder may experience problems
+   with ASN.1 tag numbers greater than 30, due to such tag numbers being
+   encoded using more than one byte.  Future revisions of this protocol
+   may utilize tag numbers greater than 30, and implementations SHOULD
+   be prepared to gracefully return an error, if appropriate, when they
+   do not recognize the tag.
+
+5.2.  Basic Kerberos Types
+
+   This section defines a number of basic types that are potentially
+   used in multiple Kerberos protocol messages.
+
+5.2.1.  KerberosString
+
+   The original specification of the Kerberos protocol in RFC 1510 uses
+   GeneralString in numerous places for human-readable string data.
+   Historical implementations of Kerberos cannot utilize the full power
+   of GeneralString.  This ASN.1 type requires the use of designation
+   and invocation escape sequences as specified in ISO-2022/ECMA-35
+   [ISO-2022/ECMA-35] to switch character sets, and the default
+   character set that is designated as G0 is the ISO-646/ECMA-6
+   [ISO-646/ECMA-6] International Reference Version (IRV) (a.k.a. U.S.
+   ASCII), which mostly works.
+
+   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
+   and two Control-function code elements (C0..C1).  DER prohibits the
+   designation of character sets as any but the G0 and C0 sets.
+   Unfortunately, this seems to have the side effect of prohibiting the
+   use of ISO-8859 (ISO Latin) [ISO-8859] character sets or any other
+   character sets that utilize a 96-character set, as ISO-2022/ECMA-35
+   prohibits designating them as the G0 code element.  This side effect
+   is being investigated in the ASN.1 standards community.
+
+   In practice, many implementations treat GeneralStrings as if they
+   were 8-bit strings of whichever character set the implementation
+   defaults to, without regard to correct usage of character-set
+   designation escape sequences.  The default character set is often
+   determined by the current user's operating system-dependent locale.
+   At least one major implementation places unescaped UTF-8 encoded
+   Unicode characters in the GeneralString.  This failure to adhere to
+   the GeneralString specifications results in interoperability issues
+   when conflicting character encodings are utilized by the Kerberos
+   clients, services, and KDC.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 53]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   This unfortunate situation is the result of improper documentation of
+   the restrictions of the ASN.1 GeneralString type in prior Kerberos
+   specifications.
+
+   The new (post-RFC 1510) type KerberosString, defined below, is a
+   GeneralString that is constrained to contain only characters in
+   IA5String.
+
+      KerberosString  ::= GeneralString (IA5String)
+
+   In general, US-ASCII control characters should not be used in
+   KerberosString.  Control characters SHOULD NOT be used in principal
+   names or realm names.
+
+   For compatibility, implementations MAY choose to accept GeneralString
+   values that contain characters other than those permitted by
+   IA5String, but they should be aware that character set designation
+   codes will likely be absent, and that the encoding should probably be
+   treated as locale-specific in almost every way.  Implementations MAY
+   also choose to emit GeneralString values that are beyond those
+   permitted by IA5String, but they should be aware that doing so is
+   extraordinarily risky from an interoperability perspective.
+
+   Some existing implementations use GeneralString to encode unescaped
+   locale-specific characters.  This is a violation of the ASN.1
+   standard.  Most of these implementations encode US-ASCII in the
+   left-hand half, so as long as the implementation transmits only
+   US-ASCII, the ASN.1 standard is not violated in this regard.  As soon
+   as such an implementation encodes unescaped locale-specific
+   characters with the high bit set, it violates the ASN.1 standard.
+
+   Other implementations have been known to use GeneralString to contain
+   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
+   is a different encoding, not a 94 or 96 character "G" set as defined
+   by ISO 2022.  It is believed that these implementations do not even
+   use the ISO 2022 escape sequence to change the character encoding.
+   Even if implementations were to announce the encoding change by using
+   that escape sequence, the ASN.1 standard prohibits the use of any
+   escape sequences other than those used to designate/invoke "G" or "C"
+   sets allowed by GeneralString.
+
+   Future revisions to this protocol will almost certainly allow for a
+   more interoperable representation of principal names, probably
+   including UTF8String.
+
+   Note that applying a new constraint to a previously unconstrained
+   type constitutes creation of a new ASN.1 type.  In this particular
+   case, the change does not result in a changed encoding under DER.
+
+
+
+Neuman, et al.              Standards Track                    [Page 54]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+5.2.2.  Realm and PrincipalName
+
+   Realm           ::= KerberosString
+
+   PrincipalName   ::= SEQUENCE {
+           name-type       [0] Int32,
+           name-string     [1] SEQUENCE OF KerberosString
+   }
+
+   Kerberos realm names are encoded as KerberosStrings.  Realms shall
+   not contain a character with the code 0 (the US-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 6.1.  A PrincipalName is a typed
+   sequence of components consisting of the following subfields:
+
+   name-type
+      This field specifies the type of name that follows.  Pre-defined
+      values for this field are specified in Section 6.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).
+
+   name-string
+      This field encodes a sequence of components that form a name, each
+      component encoded as a KerberosString.  Taken together, a
+      PrincipalName and a Realm form a principal identifier.  Most
+      PrincipalNames will have only a few components (typically one or
+      two).
+
+5.2.3.  KerberosTime
+
+   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
+   KerberosTime value shall not include any fractional portions of the
+   seconds.  As required by the DER, it further shall not include any
+   separators, and it shall specify the UTC time zone (Z).  Example: The
+   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
+   November 1985 is 19851106210627Z.
+
+5.2.4.  Constrained Integer Types
+
+   Some integer members of types SHOULD be constrained to values
+   representable in 32 bits, for compatibility with reasonable
+   implementation limits.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 55]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Int32           ::= INTEGER (-2147483648..2147483647)
+                       -- signed values representable in 32 bits
+
+   UInt32          ::= INTEGER (0..4294967295)
+                       -- unsigned 32 bit values
+
+   Microseconds    ::= INTEGER (0..999999)
+                       -- microseconds
+
+   Although this results in changes to the abstract types from the RFC
+   1510 version, the encoding in DER should be unaltered.  Historical
+   implementations were typically limited to 32-bit integer values
+   anyway, and assigned numbers SHOULD fall in the space of integer
+   values representable in 32 bits in order to promote interoperability
+   anyway.
+
+   Several integer fields in messages are constrained to fixed values.
+
+   pvno
+      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
+      the constant integer 5.  There is no easy way to make this field
+      into a useful protocol version number, so its value is fixed.
+
+   msg-type
+      this integer field is usually identical to the application tag
+      number of the containing message type.
+
+5.2.5.  HostAddress and HostAddresses
+
+   HostAddress     ::= SEQUENCE  {
+           addr-type       [0] Int32,
+           address         [1] OCTET STRING
+   }
+
+   -- NOTE: HostAddresses is always used as an OPTIONAL field and
+   -- should not be empty.
+   HostAddresses   -- NOTE: subtly different from rfc1510,
+                   -- but has a value mapping and encodes the same
+           ::= SEQUENCE OF HostAddress
+
+   The host address encodings consist of two fields:
+
+   addr-type
+      This field specifies the type of address that follows.  Pre-
+      defined values for this field are specified in Section 7.5.3.
+
+   address
+      This field encodes a single address of type addr-type.
+
+
+
+Neuman, et al.              Standards Track                    [Page 56]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+5.2.6.  AuthorizationData
+
+      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
+      -- should not be empty.
+      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+              ad-type         [0] Int32,
+              ad-data         [1] OCTET STRING
+      }
+
+   ad-data
+      This field contains authorization data to be interpreted according
+      to the value of the corresponding ad-type field.
+
+   ad-type
+      This field specifies the format for the ad-data subfield.  All
+      negative values are reserved for local use.  Non-negative values
+      are reserved for registered use.
+
+   Each sequence of type and data is referred 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.
+
+   These common authorization data elements are recursively defined,
+   meaning that 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 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 that they affect.
+
+   Authorization data elements are considered critical if present in a
+   ticket or authenticator.  If an unknown authorization data element
+   type is received by a server either in an AP-REQ or in a ticket
+   contained in an AP-REQ, then, unless it is encapsulated in a known
+   authorization data element amending the criticality of the elements
+   it contains, authentication MUST fail.  Authorization data is
+   intended to restrict the use of a ticket.  If the service cannot
+   determine whether the restriction applies to that service, then a
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 57]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   security weakness may result if the ticket can be used for that
+   service.  Authorization elements that are optional can be enclosed in
+   an AD-IF-RELEVANT element.
+
+   In the definitions that follow, the value of the ad-type for the
+   element will be specified as the least significant part of the
+   subsection number, and the value of the ad-data will be as shown in
+   the ASN.1 structure that follows the subsection heading.
+
+   Contents of ad-data                ad-type
+
+   DER encoding of AD-IF-RELEVANT        1
+
+   DER encoding of AD-KDCIssued          4
+
+   DER encoding of AD-AND-OR             5
+
+   DER encoding of AD-MANDATORY-FOR-KDC  8
+
+5.2.6.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 that may
+   have local extensions for authorization.  The ad-type for
+   AD-IF-RELEVANT is (1).
+
+5.2.6.2.  KDCIssued
+
+   AD-KDCIssued            ::= SEQUENCE {
+           ad-checksum     [0] Checksum,
+           i-realm         [1] Realm OPTIONAL,
+           i-sname         [2] PrincipalName OPTIONAL,
+           elements        [3] AuthorizationData
+   }
+
+   ad-checksum
+      A cryptographic checksum computed over the DER encoding of the
+      AuthorizationData in the "elements" field, keyed with the session
+      key.  Its checksumtype is the mandatory checksum type for the
+      encryption type of the session key, and its key usage value is 19.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 58]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   i-realm, i-sname
+      The name of the issuing principal if different from that of 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 privileges of the principal beyond what can be done
+   using credentials without such an a-data element.
+
+   The above means cannot 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 when 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 MUST be ignored by the application server if this "signature"
+   is not present.  Further, elements encapsulated within this element
+   from a TGT 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 encapsulates MAY safely be ignored
+   by applications, application servers, and KDCs that do not implement
+   this element.
+
+   The ad-type for AD-KDC-ISSUED is (4).
+
+5.2.6.3.  AND-OR
+
+   AD-AND-OR               ::= SEQUENCE {
+           condition-count [0] Int32,
+           elements        [1] AuthorizationData
+   }
+
+
+
+Neuman, et al.              Standards Track                    [Page 59]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   When restrictive AD elements are encapsulated within the and-or
+   element, the and-or element is considered satisfied if and only if at
+   least the number of encapsulated elements specified in condition-
+   count are satisfied.  Therefore, 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.
+
+   The ad-type for AD-AND-OR is (5).
+
+5.2.6.4.  MANDATORY-FOR-KDC
+
+   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+   AD elements encapsulated within the mandatory-for-kdc element are to
+   be interpreted by the KDC.  KDCs that do not understand the type of
+   an element embedded within the mandatory-for-kdc element MUST reject
+   the request.
+
+   The ad-type for AD-MANDATORY-FOR-KDC is (8).
+
+5.2.7.  PA-DATA
+
+   Historically, PA-DATA have been known as "pre-authentication data",
+   meaning that they were used to augment the initial authentication
+   with the KDC.  Since that time, they have also been used as a typed
+   hole with which to extend protocol exchanges with the KDC.
+
+   PA-DATA         ::= SEQUENCE {
+           -- NOTE: first tag is [1], not [0]
+           padata-type     [1] Int32,
+           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+   }
+
+   padata-type
+      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.
+
+   padata-value
+      Usually contains the DER encoding of another type; the padata-type
+      field identifies which type is encoded here.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 60]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      padata-type  Name             Contents of padata-value
+
+      1            pa-tgs-req       DER encoding of AP-REQ
+
+      2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
+
+      3            pa-pw-salt       salt (not ASN.1 encoded)
+
+      11           pa-etype-info    DER encoding of ETYPE-INFO
+
+      19           pa-etype-info2   DER encoding of ETYPE-INFO2
+
+      This field MAY also contain information needed by certain
+      extensions to the Kerberos protocol.  For example, it might be
+      used to verify the identity of a client initially before any
+      response is returned.
+
+      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.
+
+5.2.7.1.  PA-TGS-REQ
+
+   In the case of requests for additional tickets (KRB_TGS_REQ),
+   padata-value will contain an encoded AP-REQ.  The checksum in the
+   authenticator (which MUST be collision-proof) is to be computed over
+   the KDC-REQ-BODY encoding.
+
+5.2.7.2.  Encrypted Timestamp Pre-authentication
+
+   There are pre-authentication types that may be used to pre-
+   authenticate a client by means of an encrypted timestamp.
+
+   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+   PA-ENC-TS-ENC           ::= SEQUENCE {
+           patimestamp     [0] KerberosTime -- client's time --,
+           pausec          [1] Microseconds OPTIONAL
+   }
+
+   Patimestamp contains the client's time, and pausec contains 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 encoding, encrypted using the client's secret
+   key and a key usage value of 1.
+
+
+
+Neuman, et al.              Standards Track                    [Page 61]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations support it.
+
+5.2.7.3.  PA-PW-SALT
+
+   The padata-value for this pre-authentication type contains the salt
+   for the string-to-key to be used by the client to obtain the key for
+   decrypting the encrypted part of an AS-REP message.  Unfortunately,
+   for historical reasons, the character set to be used is unspecified
+   and probably locale-specific.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations support it.  It is necessary in any case where the
+   salt for the string-to-key algorithm is not the default.
+
+   In the trivial example, a zero-length salt string is very commonplace
+   for realms that have converted their principal databases from
+   Kerberos Version 4.
+
+   A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
+   that requests additional pre-authentication.  Implementation note:
+   Some KDC implementations issue an erroneous PA-PW-SALT when issuing a
+   KRB-ERROR message that requests additional pre-authentication.
+   Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a
+   KRB-ERROR message that requests additional pre-authentication.  As
+   noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the
+   client's AS-REQ includes at least one "newer" etype.
+
+5.2.7.4.  PA-ETYPE-INFO
+
+   The ETYPE-INFO pre-authentication type is sent by the KDC in a
+   KRB-ERROR indicating a requirement for additional pre-authentication.
+   It is usually used to notify a client of which key to use for the
+   encryption of an encrypted timestamp for the purposes of sending a
+   PA-ENC-TIMESTAMP pre-authentication value.  It MAY also be sent in an
+   AS-REP to provide information to the client about which key salt to
+   use for the string-to-key to be used by the client to obtain the key
+   for decrypting the encrypted part the AS-REP.
+
+   ETYPE-INFO-ENTRY        ::= SEQUENCE {
+           etype           [0] Int32,
+           salt            [1] OCTET STRING OPTIONAL
+   }
+
+   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+   The salt, like that of PA-PW-SALT, is also completely unspecified
+   with respect to character set and is probably locale-specific.
+
+
+
+Neuman, et al.              Standards Track                    [Page 62]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   If ETYPE-INFO is sent in an AS-REP, there shall be exactly one
+   ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in
+   the AS-REP.
+
+   This pre-authentication type was not present in RFC 1510, but many
+   implementations that support encrypted timestamps for pre-
+   authentication need to support ETYPE-INFO as well.  As noted in
+   Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
+   AS-REQ includes at least one "newer" etype.
+
+5.2.7.5.  PA-ETYPE-INFO2
+
+   The ETYPE-INFO2 pre-authentication type is sent by the KDC in a
+   KRB-ERROR indicating a requirement for additional pre-authentication.
+   It is usually used to notify a client of which key to use for the
+   encryption of an encrypted timestamp for the purposes of sending a
+   PA-ENC-TIMESTAMP pre-authentication value.  It MAY also be sent in an
+   AS-REP to provide information to the client about which key salt to
+   use for the string-to-key to be used by the client to obtain the key
+   for decrypting the encrypted part the AS-REP.
+
+ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+        etype           [0] Int32,
+        salt            [1] KerberosString OPTIONAL,
+        s2kparams       [2] OCTET STRING OPTIONAL
+}
+
+ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
+
+   The type of the salt is KerberosString, but existing installations
+   might have locale-specific characters stored in salt strings, and
+   implementors MAY choose to handle them.
+
+   The interpretation of s2kparams is specified in the cryptosystem
+   description associated with the etype.  Each cryptosystem has a
+   default interpretation of s2kparams that will hold if that element is
+   omitted from the encoding of ETYPE-INFO2-ENTRY.
+
+   If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
+   ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
+   the AS-REP.
+
+   The preferred ordering of the "hint" pre-authentication data that
+   affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO,
+   followed by PW-SALT.  As noted in Section 3.1.3, a KDC MUST NOT send
+   ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one
+   "newer" etype.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 63]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
+
+5.2.8.  KerberosFlags
+
+   For several message types, a specific constrained bit string type,
+   KerberosFlags, is used.
+
+   KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
+                       -- minimum number of bits shall be sent,
+                       -- but no fewer than 32
+
+   Compatibility note: The following paragraphs describe a change from
+   the RFC 1510 description of bit strings that would result in
+   incompatility in the case of an implementation that strictly
+   conformed to ASN.1 DER and RFC 1510.
+
+   ASN.1 bit strings have multiple uses.  The simplest use of a bit
+   string is to contain a vector of bits, with no particular meaning
+   attached to individual bits.  This vector of bits is not necessarily
+   a multiple of eight bits long.  The use in Kerberos of a bit string
+   as a compact boolean vector wherein each element has a distinct
+   meaning poses some problems.  The natural notation for a compact
+   boolean vector is the ASN.1 "NamedBit" notation, and the DER require
+   that encodings of a bit string using "NamedBit" notation exclude any
+   trailing zero bits.  This truncation is easy to neglect, especially
+   given C language implementations that naturally choose to store
+   boolean vectors as 32-bit integers.
+
+   For example, if the notation for KDCOptions were to include the
+   "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
+   encoded had only the "forwardable" (bit number one) bit set, the DER
+   encoding MUST include only two bits: the first reserved bit
+   ("reserved", bit number zero, value zero) and the one-valued bit (bit
+   number one) for "forwardable".
+
+   Most existing implementations of Kerberos unconditionally send 32
+   bits on the wire when encoding bit strings used as boolean vectors.
+   This behavior violates the ASN.1 syntax used for flag values in RFC
+   1510, but it occurs on such a widely installed base that the protocol
+   description is being modified to accommodate it.
+
+   Consequently, this document removes the "NamedBit" notations for
+   individual bits, relegating them to comments.  The size constraint on
+   the KerberosFlags type requires that at least 32 bits be encoded at
+   all times, though a lenient implementation MAY choose to accept fewer
+   than 32 bits and to treat the missing bits as set to zero.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 64]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Currently, no uses of KerberosFlags specify more than 32 bits' worth
+   of flags, although future revisions of this document may do so.  When
+   more than 32 bits are to be transmitted in a KerberosFlags value,
+   future revisions to this document will likely specify that the
+   smallest number of bits needed to encode the highest-numbered one-
+   valued bit should be sent.  This is somewhat similar to the DER
+   encoding of a bit string that is declared with the "NamedBit"
+   notation.
+
+5.2.9.  Cryptosystem-Related Types
+
+   Many Kerberos protocol messages contain an EncryptedData as a
+   container for arbitrary encrypted data, which is often the encrypted
+   encoding of another data type.  Fields within EncryptedData assist
+   the recipient in selecting a key with which to decrypt the enclosed
+   data.
+
+   EncryptedData   ::= SEQUENCE {
+           etype   [0] Int32 -- EncryptionType --,
+           kvno    [1] UInt32 OPTIONAL,
+           cipher  [2] OCTET STRING -- ciphertext
+   }
+
+   etype
+      This field identifies which encryption algorithm was used to
+      encipher the cipher.
+
+   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.  (Note that the encryption mechanisms defined in [RFC3961]
+      MUST incorporate integrity protection as well, so no additional
+      checksum is required.)
+
+   The EncryptionKey type is the means by which cryptographic keys used
+   for encryption are transferred.
+
+   EncryptionKey   ::= SEQUENCE {
+           keytype         [0] Int32 -- actually encryption type --,
+           keyvalue        [1] OCTET STRING
+   }
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 65]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   keytype
+      This field specifies the encryption type of the encryption key
+      that follows in the keyvalue field.  Although its name is
+      "keytype", it actually specifies an encryption type.  Previously,
+      multiple cryptosystems that performed encryption differently but
+      were capable of using keys with the same characteristics were
+      permitted to share an assigned number to designate the type of
+      key; this usage is now deprecated.
+
+   keyvalue
+      This field contains the key itself, encoded as an octet string.
+
+   Messages containing cleartext data to be authenticated will usually
+   do so by using a member of type Checksum.  Most instances of Checksum
+   use a keyed hash, though exceptions will be noted.
+
+   Checksum        ::= SEQUENCE {
+           cksumtype       [0] Int32,
+           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.
+
+   See Section 4 for a brief description of the use of encryption and
+   checksums in Kerberos.
+
+5.3.  Tickets
+
+   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.  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 (5),
+           realm           [1] Realm,
+           sname           [2] PrincipalName,
+           enc-part        [3] EncryptedData -- EncTicketPart
+   }
+
+   -- Encrypted part of ticket
+
+
+
+Neuman, et al.              Standards Track                    [Page 66]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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] Int32 -- must be registered --,
+           contents        [1] OCTET STRING
+   }
+
+   TicketFlags     ::= KerberosFlags
+           -- 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),
+   -- the following are new since 1510
+           -- transited-policy-checked(12),
+           -- ok-as-delegate(13)
+
+   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.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 67]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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.  It is encrypted in the key shared by Kerberos and the
+      end server (the server's secret key), using a key usage value of
+      2.
+
+   flags
+      This field indicates which of various options were used or
+      requested when the ticket was issued.  The meanings of the flags
+      are as follows:
+
+   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 TGT 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 TGT.
+
+   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-TGTs 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
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 68]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+                            ticket-granting server that a post-dated
+                            ticket MAY be issued based on this TGT.
+
+   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 particularly
+                            careful servers MAY disallow renewable
+                            tickets).  A renewable ticket can be used to
+                            obtain a replacement 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 TGT.
+
+   10      pre-authent      This flag indicates that during initial
+                            authentication, the client was authenticated
+                            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
+           policy-checked   the 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
+
+
+
+Neuman, et al.              Standards Track                    [Page 69]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+                            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.
+
+                            This flag is new since RFC 1510.
+
+   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
+                            decide whether to delegate credentials
+                            (either grant a proxy or a forwarded TGT) 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.
+
+                            This flag is new since RFC 1510.
+
+   14-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.
+
+   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 CAs are to be embedded in the
+      transited field (as specified for some extensions to the
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 70]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      protocol), the X.500 names of the CAs SHOULD be mapped into items
+      in the transited field using the mapping defined by RFC 2253.
+
+   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 it is
+      returned as part of the response to initial authentication
+      (KRB_AS_REP), this is the current time on the Kerberos server.  It
+      is NOT recommended that this time value be used to adjust the
+      workstation's clock, as the workstation cannot reliably determine
+      that such a KRB_AS_REP actually came from the proper KDC in a
+      timely manner.
+
+   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 the starttime field is absent from the ticket,
+      then the authtime field SHOULD be used in its place to determine
+      the life of the ticket.
+
+   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 addressless tickets is a policy decision
+      and is left to the Kerberos and end-service administrators; they
+      MAY refuse to issue or accept such tickets.  Because of the wide
+
+
+
+Neuman, et al.              Standards Track                    [Page 71]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      deployment of network address translation, it is recommended that
+      policy allow the issue and acceptance of such tickets.
+
+      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.
+
+      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 to 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 would be
+      "restrictions".  Unfortunately, it is not possible to change the
+      name 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 possession 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
+      encapsulation 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 privileges 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
+
+
+
+Neuman, et al.              Standards Track                    [Page 72]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      in Section 5.2.6.  Although Kerberos is not concerned with the
+      format of the contents of the subfields, 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 privilege 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 5.2.6.2).
+
+      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.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 application tag number of its own.
+   Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ,
+   each of which has an application tag, 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 KDC to request
+   credentials for a service.
+
+
+
+Neuman, et al.              Standards Track                    [Page 73]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   The message fields are as follows:
+
+AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+KDC-REQ         ::= SEQUENCE {
+        -- NOTE: first tag is [1], not [0]
+        pvno            [1] INTEGER (5) ,
+        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+        padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                            -- NOTE: not empty --,
+        req-body        [4] KDC-REQ-BODY
+}
+
+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,
+        rtime                   [6] KerberosTime OPTIONAL,
+        nonce                   [7] UInt32,
+        etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                    -- in preference order --,
+        addresses               [9] HostAddresses OPTIONAL,
+        enc-authorization-data  [10] EncryptedData OPTIONAL
+                                    -- AuthorizationData --,
+        additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                       -- NOTE: not empty
+}
+
+KDCOptions      ::= KerberosFlags
+        -- reserved(0),
+        -- forwardable(1),
+        -- forwarded(2),
+        -- proxiable(3),
+        -- proxy(4),
+        -- allow-postdate(5),
+        -- postdated(6),
+        -- unused7(7),
+        -- renewable(8),
+        -- unused9(9),
+        -- unused10(10),
+
+
+
+Neuman, et al.              Standards Track                    [Page 74]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        -- opt-hardware-auth(11),
+        -- unused12(12),
+        -- unused13(13),
+-- 15 is reserved for canonicalize
+        -- unused15(15),
+-- 26 was unused in 1510
+        -- disable-transited-check(26),
+--
+        -- renewable-ok(27),
+        -- enc-tkt-in-skey(28),
+        -- renew(30),
+        -- validate(31)
+
+   The fields in this message are as follows:
+
+   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
+      Contains pre-authentication data.  Requests for additional tickets
+      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
+
+      The padata (pre-authentication data) field contains a sequence of
+      authentication information that may be needed before credentials
+      can be issued or decrypted.
+
+   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 cases, the bit in the options field will be the same as that
+      in the flags field, this is not guaranteed, so it is not
+
+
+
+Neuman, et al.              Standards Track                    [Page 75]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      acceptable simply to copy the options field to the flags field.
+      There are various checks that must be made before an option is
+      honored 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 as
+      follows:
+
+   Bits    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 subsequent request
+                                    if the TGT on which it is based is
+                                    also forwardable.
+
+   2       FORWARDED                The FORWARDED option is only
+                                    specified in a request to the
+                                    ticket-granting server and will only
+                                    be honored if the TGT 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 proxiable flag set.  It may only
+                                    be set on the initial request, or a
+                                    subsequent request if the TGT 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
+                                    TGT in the request has its PROXIABLE
+                                    bit set.  The address(es) of the
+
+
+
+Neuman, et al.              Standards Track                    [Page 76]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+                                    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 subsequent request
+                                    if the TGT 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 TGT 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       RESERVED                 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 TGT 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      RESERVED                 Reserved for future use.
+
+   11      RESERVED                 Reserved for opt-hardware-auth.
+
+   12-25   RESERVED                 Reserved for future use.
+
+   26      DISABLE-TRANSITED-CHECK  By default the KDC will check the
+                                    transited field of a TGT against the
+                                    policy of the local realm before it
+                                    will issue derivative tickets based
+
+
+
+Neuman, et al.              Standards Track                    [Page 77]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+                                    on the TGT.  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 transited field must be
+                                    checked locally.  KDCs are
+                                    encouraged but not required to honor
+                                    the DISABLE-TRANSITED-CHECK option.
+
+                                    This flag is new since RFC 1510.
+
+   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, in which case a renewable
+                                    ticket may be issued with a renew-
+                                    till equal to 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 TGT 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
+
+
+
+Neuman, et al.              Standards Track                    [Page 78]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+                                    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 validate a postdated
+                                    ticket.  It will only be honored if
+                                    the ticket presented is postdated,
+                                    presently has its INVALID flag set,
+                                    and would otherwise be usable at
+                                    this time.  A ticket cannot be
+                                    validated 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.  The sname may only be absent when the ENC-TKT-IN-
+      SKEY option is specified.  If the sname is 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
+      TGT (both the Authenticator and TGT come from the padata field in
+      the KRB_TGS_REQ).  The key usage value used when encrypting is 5
+      if a sub-session key is used, or 4 if the session key is used.
+
+   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 starttime for the requested ticket.  If this
+      field is omitted, then the KDC SHOULD use the current time
+      instead.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 79]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   till
+      This field contains the expiration date requested by the client in
+      a ticket request.  It is not optional, but if the requested
+      endtime is "19700101000000Z", the requested ticket is to have the
+      maximum endtime permitted according to KDC policy.  Implementation
+      note: This special timestamp corresponds to a UNIX time_t value of
+      zero on most systems.
+
+   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 is
+      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 reused.
+
+   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 it
+      is 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
+      the ENC-TKT-IN-SKEY option is used for user-to-user
+      authentication, this additional 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 that 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).
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 80]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   The application tag number 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.
+
+   Note 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; if it is absent, the
+   ciphertext is encrypted in the session key from the TGT 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 (5),
+           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                   -- NOTE: not empty --,
+           crealm          [3] Realm,
+           cname           [4] PrincipalName,
+           ticket          [5] Ticket,
+           enc-part        [6] EncryptedData
+                                   -- EncASRepPart or EncTGSRepPart,
+                                   -- as appropriate
+   }
+
+   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+
+
+Neuman, et al.              Standards Track                    [Page 81]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+   EncKDCRepPart   ::= SEQUENCE {
+           key             [0] EncryptionKey,
+           last-req        [1] LastReq,
+           nonce           [2] UInt32,
+           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
+   }
+
+   LastReq         ::=     SEQUENCE OF SEQUENCE {
+           lr-type         [0] Int32,
+           lr-value        [1] KerberosTime
+   }
+
+   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 it is to encode an alternate "salt" string to be used with
+      a string-to-key algorithm.  This ability is useful for easing
+      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 salt
+      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.
+
+   ticket
+      The newly-issued ticket, from Section 5.3.
+
+   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.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 82]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      The key usage value for encrypting this field is 3 in an AS-REP
+      message, using the client's long-term key or another key selected
+      via pre-authentication mechanisms.  In a TGS-REP message, the key
+      usage value is 8 if the TGS session key is used, or 9 if a TGS
+      authenticator subkey is used.
+
+      Compatibility note: Some implementations unconditionally send an
+      encrypted EncTGSRepPart (application tag number 26) in this field
+      regardless of whether the reply is a AS-REP or a TGS-REP.  In the
+      interest of compatibility, implementors MAY relax the check on the
+      tag number of the decrypted ENC-PART.
+
+   key
+      This field is the same as described for the ticket in Section 5.3.
+
+   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 TGT
+      was made, or the last time that a request based on a TGT 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 in to timesharing systems.
+
+   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 TGT
+      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.  If it is (7), then the lr-value subfield is the time when
+      the account will expire.
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 83]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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.
+
+   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.  If present, it SHOULD be set to the earlier of the
+      user's key expiration and account expiration.  The use of this
+      field is deprecated, and the last-req field SHOULD be used to
+      convey this information instead.  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 has to 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), provided so the
+      client MAY verify that they match the intended request and in
+      order 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 TGT.  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 TGT.
+
+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".
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 84]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (14),
+           ap-options      [2] APOptions,
+           ticket          [3] Ticket,
+           authenticator   [4] EncryptedData -- Authenticator
+   }
+
+   APOptions       ::= KerberosFlags
+           -- 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 by being reset (0).
+      The encoding of the bits is specified in Section 5.2.  The
+      meanings of the options are as follows:
+
+   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 TGT.  When this option is not
+                            specified, 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.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 85]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   authenticator
+      This contains the encrypted authenticator, which includes the
+      client's choice of a subkey.
+
+   The encrypted authenticator is included in the AP-REQ; it certifies
+   to a server that the sender has recent knowledge of the encryption
+   key in the accompanying ticket, to help the server detect replays.
+   It also assists in the selection of a "true session key" to use with
+   the particular session.  The DER encoding of the following is
+   encrypted in the ticket's session key, with a key usage value of 11
+   in normal application exchanges, or 7 when used as the PA-TGS-REQ
+   PA-DATA field of a TGS-REQ exchange (see Section 5.4.1):
+
+   -- Unencrypted authenticator
+   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+           authenticator-vno       [0] INTEGER (5),
+           crealm                  [1] Realm,
+           cname                   [2] PrincipalName,
+           cksum                   [3] Checksum OPTIONAL,
+           cusec                   [4] Microseconds,
+           ctime                   [5] KerberosTime,
+           subkey                  [6] EncryptionKey OPTIONAL,
+           seq-number              [7] UInt32 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.
+
+   cksum
+      This field contains a checksum of the application data that
+      accompanies the KRB_AP_REQ, computed using a key usage value of 10
+      in normal application exchanges, or 6 when used in the TGS-REQ
+      PA-TGS-REQ AP-DATA field.
+
+   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.
+
+
+
+Neuman, et al.              Standards Track                    [Page 86]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   subkey
+      This field contains the client's choice for an encryption key 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 0 through 2^32 - 1 and wrap to zero following
+      the value 2^32 - 1.
+
+      For sequence numbers to support the detection of replays
+      adequately, 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.  In the event that more than 2^32 messages are to be
+      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
+      SHOULD be performed before sequence numbers are reused with the
+      same encryption key.
+
+      Implmentation note: Historically, some implementations transmit
+      signed twos-complement numbers for sequence numbers.  In the
+      interests of compatibility, implementations MAY accept the
+      equivalent negative number where a positive number greater than
+      2^31 - 1 is expected.
+
+      Implementation note: As noted before, some implementations omit
+      the optional sequence number when its value would be zero.
+      Implementations MAY accept an omitted sequence number when
+      expecting a value of zero, and SHOULD NOT transmit an
+      Authenticator with a initial sequence number of zero.
+
+   authorization-data
+      This field is the same as described for the ticket in Section 5.3.
+      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.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 87]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+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 response to an application request (KRB_AP_REQ) for which the
+   mutual authentication option has been selected in the ap-options
+   field.
+
+   AP-REP          ::= [APPLICATION 15] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (15),
+           enc-part        [2] EncryptedData -- EncAPRepPart
+   }
+
+   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+           ctime           [0] KerberosTime,
+           cusec           [1] Microseconds,
+           subkey          [2] EncryptionKey OPTIONAL,
+           seq-number      [3] UInt32 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.  It is computed
+      with a key usage value of 12.
+
+   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 that 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 the latter is also
+      left out, the session key from the ticket will be used.
+
+
+
+Neuman, et al.              Standards Track                    [Page 88]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   seq-number
+      This field is described above in Section 5.3.2.
+
+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 with the session key if no negotiation has occurred.  The message
+   fields are as follows:
+
+   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (20),
+           safe-body       [2] KRB-SAFE-BODY,
+           cksum           [3] Checksum
+   }
+
+   KRB-SAFE-BODY   ::= SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress,
+           r-address       [5] HostAddress OPTIONAL
+   }
+
+   pvno and msg-type
+      These fields are described above in Section 5.4.1.  msg-type is
+      KRB_SAFE.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 89]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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, computed
+      with a key usage value of 15.
+
+      The checksum is computed over the encoding of the KRB-SAFE
+      sequence.  First, the cksum is set to a type zero, zero-length
+      value, and the checksum is computed over the encoding of the KRB-
+      SAFE sequence.  Then the checksum is set to the result of that
+      computation.  Finally, the KRB-SAFE sequence is encoded again.
+      This method, although different than the one specified in RFC
+      1510, corresponds to existing practice.
+
+   user-data
+      This field is part of the KRB_SAFE and KRB_PRIV messages, and
+      contains 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
+      Sender's address.
+
+      This field specifies the address in use by the sender of the
+      message.
+
+   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 that have been incorrectly or maliciously
+      delivered to the wrong recipient.
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 90]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+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 send a message to
+   its peer securely and privately.  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 as follows:
+
+   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (21),
+                           -- NOTE: there is no [2] tag
+           enc-part        [3] EncryptedData -- EncKrbPrivPart
+   }
+
+   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+           user-data       [0] OCTET STRING,
+           timestamp       [1] KerberosTime OPTIONAL,
+           usec            [2] Microseconds OPTIONAL,
+           seq-number      [3] UInt32 OPTIONAL,
+           s-address       [4] HostAddress -- 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, with a key usage value of 13.
+      This encrypted encoding is used for the enc-part field of the
+      KRB-PRIV message.
+
+   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.
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 91]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+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 as follows:
+
+   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
+           pvno            [0] INTEGER (5),
+           msg-type        [1] INTEGER (22),
+           tickets         [2] SEQUENCE OF Ticket,
+           enc-part        [3] EncryptedData -- EncKrbCredPart
+   }
+
+   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+           ticket-info     [0] SEQUENCE OF KrbCredInfo,
+           nonce           [1] UInt32 OPTIONAL,
+           timestamp       [2] KerberosTime OPTIONAL,
+           usec            [3] Microseconds 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
+   }
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 92]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 by the sender and the
+      intended recipient, with a key usage value of 14.  This encrypted
+      encoding is used for the enc-part field of the KRB-CRED message.
+
+      Implementation note: Implementations of certain applications, most
+      notably certain implementations of the Kerberos GSS-API mechanism,
+      do not separately encrypt the contents of the EncKrbCredPart of
+      the KRB-CRED message when sending it.  In the case of those GSS-
+      API mechanisms, this is not a security vulnerability, as the
+      entire KRB-CRED message is itself embedded in an encrypted
+      message.
+
+   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 reused.
+
+   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 5.2.9.
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 93]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 values.
+
+   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 corresponding 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 because the KRB_ERROR message is not integrity protected,
+   it is quite possible for an intruder to synthesize or modify it.  In
+   particular, this means that 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 (5),
+           msg-type        [1] INTEGER (30),
+           ctime           [2] KerberosTime OPTIONAL,
+           cusec           [3] Microseconds OPTIONAL,
+           stime           [4] KerberosTime,
+           susec           [5] Microseconds,
+           error-code      [6] Int32,
+           crealm          [7] Realm OPTIONAL,
+           cname           [8] PrincipalName OPTIONAL,
+           realm           [9] Realm -- service realm --,
+           sname           [10] PrincipalName -- service name --,
+           e-text          [11] KerberosString OPTIONAL,
+
+
+
+Neuman, et al.              Standards Track                    [Page 94]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+           e-data          [12] OCTET STRING OPTIONAL
+   }
+
+   pvno and msg-type
+      These fields are described above in Section 5.4.1.  msg-type is
+      KRB_ERROR.
+
+   ctime and cusec
+      These fields are described above in Section 5.5.2.  If the values
+      for these fields are known to the entity generating the error (as
+      they would be if the KRB-ERROR is generated in reply to, e.g., a
+      failed authentication service request), they should be populated
+      in the KRB-ERROR.  If the values are not available, these fields
+      can be omitted.
+
+   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 7.5.9.  Implementations are
+      encouraged to provide for national language support in the display
+      of error messages.
+
+   crealm, and cname
+      These fields are described above in Section 5.3.  When the entity
+      generating the error knows these values, they should be populated
+      in the KRB-ERROR.  If the values are not known, the crealm and
+      cname fields SHOULD be omitted.
+
+   realm and sname
+      These fields are described above in Section 5.3.
+
+   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).
+
+
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 95]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 the
+      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
+      contain an encoding of a sequence of padata fields, each
+      corresponding to an acceptable pre-authentication method and
+      optionally containing data for the method:
+
+      METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+   For error codes defined in this document other than
+   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
+   are implementation-defined.  Similarly, for future error codes, the
+   format and contents of the e-data field are implementation-defined
+   unless specified otherwise.  Whether defined by the implementation or
+   in a future document, the e-data field MAY take the form of TYPED-
+   DATA:
+
+   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+           data-type       [0] Int32,
+           data-value      [1] OCTET STRING OPTIONAL
+   }
+
+5.10.  Application Tag Numbers
+
+   The following table lists the application class tag numbers used by
+   various data types defined in this section.
+
+   Tag Number(s)  Type Name      Comments
+
+   0                             unused
+
+   1              Ticket         PDU
+
+   2              Authenticator  non-PDU
+
+   3              EncTicketPart  non-PDU
+
+   4-9                           unused
+
+   10             AS-REQ         PDU
+
+   11             AS-REP         PDU
+
+   12             TGS-REQ        PDU
+
+   13             TGS-REP        PDU
+
+
+
+
+Neuman, et al.              Standards Track                    [Page 96]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   14             AP-REQ         PDU
+
+   15             AP-REP         PDU
+
+   16             RESERVED16     TGT-REQ (for user-to-user)
+
+   17             RESERVED17     TGT-REP (for user-to-user)
+
+   18-19                         unused
+
+   20             KRB-SAFE       PDU
+
+   21             KRB-PRIV       PDU
+
+   22             KRB-CRED       PDU
+
+   23-24                         unused
+
+   25             EncASRepPart   non-PDU
+
+   26             EncTGSRepPart  non-PDU
+
+   27             EncApRepPart   non-PDU
+
+   28             EncKrbPrivPart non-PDU
+
+   29             EncKrbCredPart non-PDU
+
+   30             KRB-ERROR      PDU
+
+   The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the
+   only ASN.1 types intended as top-level types of the Kerberos
+   protocol, and are the only types that may be used as elements in
+   another protocol that makes use of Kerberos.
+
+6.  Naming Constraints
+
+6.1.  Realm Names
+
+   Although realm names are encoded as GeneralStrings and technically a
+   realm can 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.
+
+
+
+Neuman, et al.              Standards Track                    [Page 97]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Kerberos realm names are case sensitive.  Realm names that differ
+   only in the case of the characters are not equivalent.  There are
+   presently three styles of realm names: domain, X500, and other.
+   Examples of each style follow:
+
+        domain:   ATHENA.MIT.EDU
+          X500:   C=US/O=OSF
+         other:   NAMETYPE:rest/of.name=without-restrictions
+
+   Domain style realm 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 uppercase.
+
+   X.500 names contain an equals sign (=) and cannot contain a colon (:)
+   before the equals sign.  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.  Note
+   that the slash separator is consistent with Kerberos implementations
+   based on RFC 1510, but it is different from the separator recommended
+   in RFC 2253.
+
+   Names that fall into the other category MUST begin with a prefix that
+   contains no equals sign (=) or period (.), and the prefix MUST be
+   followed by a colon (:) and the rest of the name.  All prefixes
+   expect those beginning with used.  Presently none are assigned.
+
+   The reserved category includes strings that 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:
+   either the name of a realm for the domain or X.500 formats must 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
+
+
+
+Neuman, et al.              Standards Track                    [Page 98]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 in the future there will not exist a name identical to the
+   realm name of the child unless it is assigned to the same entity as
+   the realm name.
+
+6.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 only as a hint to interpreting the meaning of a name.  It is
+   not significant when checking for equivalence.  Principal names that
+   differ only in the name-type identify the same principal.  The name
+   type does not partition the name space.  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    Just the name of the principal as in DCE,
+                            or for users
+   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 host as remaining components
+   NT-UID            5    Unique ID
+   NT-X500-PRINCIPAL 6    Encoded X.509 Distinguished name [RFC2253]
+   NT-SMTP-NAME      7    Name in form of SMTP email name
+                            (e.g., user@example.com)
+   NT-ENTERPRISE    10    Enterprise name - may be mapped to principal
+                            name
+
+   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
+
+
+
+Neuman, et al.              Standards Track                    [Page 99]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 the first component of a name identifies a service and there is a
+   single component following the service name identifying the instance
+   as 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 certificate 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 an
+   SMTP email name.  This name, including an "@" and a domain name, is
+   used as the one component of the principal name.
+
+   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 7.3 for the
+   form of such names.
+
+6.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 lowercase.  If specified by the application
+   protocol for services such as telnet and the Berkeley R commands that
+   run with system privileges, the first component MAY be the string
+   'host' instead of a service-specific identifier.
+
+
+
+Neuman, et al.              Standards Track                   [Page 100]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+7.  Constants and Other Defined Values
+
+7.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.
+
+   Internet (IPv4) Addresses
+
+      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
+      in MSB order (most significant byte first).  The IPv4 loopback
+      address SHOULD NOT appear in a Kerberos PDU.  The type of IPv4
+      addresses is two (2).
+
+   Internet (IPv6) Addresses
+
+      IPv6 addresses [RFC3513] are 128-bit (16-octet) quantities,
+      encoded in MSB order (most significant byte first).  The type of
+      IPv6 addresses is twenty-four (24).  The following addresses MUST
+      NOT appear in any Kerberos PDU:
+
+         *  the Unspecified Address
+         *  the Loopback Address
+         *  Link-Local addresses
+
+      This restriction applies to the inclusion in the address fields of
+      Kerberos PDUs, but not to the address fields of packets that might
+      carry such PDUs.  The restriction is necessary because the use of
+      an address with non-global scope could allow the acceptance of a
+      message sent from a node that may have the same address, but which
+      is not the host intended by the entity that added the restriction.
+      If the link-local address type needs to be used for communication,
+      then the address restriction in tickets must not be used (i.e.,
+      addressless tickets must be used).
+
+      IPv4-mapped IPv6 addresses MUST be represented as addresses of
+      type 2.
+
+   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).
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 101]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Netbios Addresses
+
+      Netbios addresses are 16-octet addresses typically composed of 1
+      to 15 alphanumeric characters and padded with the US-ASCII SPC
+      character (code 32).  The 16th octet MUST be the US-ASCII NUL
+      character (code 0).  The type of Netbios addresses is twenty (20).
+
+   Directional Addresses
+
+      Including the sender address in KRB_SAFE and KRB_PRIV messages is
+      undesirable in many environments because the addresses may be
+      changed in transport by network address translators.  However, if
+      these addresses are removed, the messages may be subject to a
+      reflection attack in which a message is reflected back to its
+      originator.  The directional address type provides a way to avoid
+      transport addresses and reflection attacks.  Directional addresses
+      are encoded as four-byte unsigned integers in network byte order.
+      If the message is originated by the party sending the original
+      KRB_AP_REQ message, then an address of 0 SHOULD be used.  If the
+      message is originated by the party to whom that KRB_AP_REQ was
+      sent, then the address 1 SHOULD be used.  Applications involving
+      multiple parties can specify the use of other addresses.
+
+      Directional addresses MUST only be used for the sender address
+      field in the KRB_SAFE or KRB_PRIV messages.  They MUST NOT be used
+      as a ticket address or in a KRB_AP_REQ message.  This address type
+      SHOULD only be used in situations where the sending party knows
+      that the receiving party supports the address type.  This
+      generally means that directional addresses may only be used when
+      the application protocol requires their support.  Directional
+      addresses are type (3).
+
+7.2.  KDC Messaging: IP Transports
+
+   Kerberos defines two IP transport mechanisms for communication
+   between clients and servers: UDP/IP and TCP/IP.
+
+7.2.1.  UDP/IP transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
+   requests and SHOULD listen for them on port 88 (decimal) unless
+   specifically configured to listen on an alternative UDP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 102]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Kerberos clients supporting IP transports SHOULD support the sending
+   of UDP requests.  Clients SHOULD use KDC discovery [7.2.3] to
+   identify the IP address and port to which they will send their
+   request.
+
+   When contacting a 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 the KDC.  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.  The response to a request made through UDP/IP
+   transport MUST also use UDP/IP transport.  If the response cannot be
+   handled using UDP (for example, because it is too large), the KDC
+   MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the
+   request using the TCP transport.
+
+7.2.2.  TCP/IP Transport
+
+   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
+   requests and SHOULD listen for them on port 88 (decimal) unless
+   specifically configured to listen on an alternate TCP port.
+   Alternate ports MAY be used when running multiple KDCs for multiple
+   realms on the same host.
+
+   Clients MUST support the sending of TCP requests, but MAY choose to
+   try a request initially using the UDP transport.  Clients SHOULD use
+   KDC discovery [7.2.3] to identify the IP address and port to which
+   they will send their request.
+
+   Implementation note: Some extensions to the Kerberos protocol will
+   not succeed if any client or KDC not supporting the TCP transport is
+   involved.  Implementations of RFC 1510 were not required to support
+   TCP/IP transports.
+
+   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
+   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
+   the client on the same TCP stream that was established for the
+   request.  The KDC MAY close the TCP stream after sending a response,
+   but MAY leave the stream open for a reasonable period of time if it
+   expects a follow-up.  Care must be taken in managing TCP/IP
+   connections on the KDC to prevent denial of service attacks based on
+   the number of open TCP/IP connections.
+
+   The client MUST be prepared to have the stream closed by the KDC at
+   any time after the receipt of a response.  A stream closure SHOULD
+   NOT be treated as a fatal error.  Instead, if multiple exchanges are
+   required (e.g., certain forms of pre-authentication), the client may
+   need to establish a new connection when it is ready to send
+
+
+
+Neuman, et al.              Standards Track                   [Page 103]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   subsequent messages.  A client MAY close the stream after receiving a
+   response, and SHOULD close the stream if it does not expect to send
+   follow-up messages.
+
+   A client MAY send multiple requests before receiving responses,
+   though it must be prepared to handle the connection being closed
+   after the first response.
+
+   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
+   sent over the TCP stream is preceded by the length of the request as
+   4 octets in network byte order.  The high bit of the length is
+   reserved for future expansion and MUST currently be set to zero.  If
+   a KDC that does not understand how to interpret a set high bit of the
+   length encoding receives a request with the high order bit of the
+   length set, it MUST return a KRB-ERROR message with the error
+   KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
+
+   If multiple requests are sent over a single TCP connection and the
+   KDC sends multiple responses, the KDC is not required to send the
+   responses in the order of the corresponding requests.  This may
+   permit some implementations to send each response as soon as it is
+   ready, even if earlier requests are still being processed (for
+   example, waiting for a response from an external device or database).
+
+7.2.3.  KDC Discovery on IP Networks
+
+   Kerberos client implementations MUST provide a means for the client
+   to determine the location of the Kerberos Key Distribution Centers
+   (KDCs).  Traditionally, Kerberos implementations have stored such
+   configuration information in a file on each client machine.
+   Experience has shown that this method of storing configuration
+   information presents problems with out-of-date information and
+   scaling, especially when using cross-realm authentication.  This
+   section describes a method for using the Domain Name System [RFC1035]
+   for storing KDC location information.
+
+7.2.3.1.  DNS vs. Kerberos: Case Sensitivity of Realm Names
+
+   In Kerberos, realm names are case sensitive.  Although it is strongly
+   encouraged that all realm names be all uppercase, this recommendation
+   has not been adopted by all sites.  Some sites use all lowercase
+   names and other use mixed case.  DNS, on the other hand, is case
+   insensitive for queries.  Because the realm names "MYREALM",
+   "myrealm", and "MyRealm" are all different, but resolve the same in
+   the domain name system, it is necessary that only one of the possible
+   combinations of upper- and lowercase characters be used in realm
+   names.
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 104]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+7.2.3.2.  Specifying KDC Location Information with DNS SRV records
+
+   KDC location information is to be stored using the DNS SRV RR
+   [RFC2782].  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 SRV records are to
+   be used, both "udp" and "tcp" records MUST be specified for all KDC
+   deployments.
+
+   The Realm is the Kerberos realm that this record corresponds to.  The
+   realm MUST be a domain-style realm name.
+
+   TTL, Class, SRV, Priority, Weight, and Target have the standard
+   meaning as defined in RFC 2782.
+
+   As per RFC 2782, the Port number used for "_udp" and "_tcp" SRV
+   records SHOULD be the value assigned to "kerberos" by the Internet
+   Assigned Number Authority: 88 (decimal), unless the KDC is configured
+   to listen on an alternate TCP port.
+
+   Implementation note: Many existing client implementations do not
+   support KDC Discovery and are configured to send requests to the IANA
+   assigned port (88 decimal), so it is strongly recommended that KDCs
+   be configured to listen on that port.
+
+7.2.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
+
+   These are DNS records for a Kerberos realm EXAMPLE.COM.  It has two
+   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
+   should be directed to kdc1.example.com first as per the specified
+   priority.  Weights are not used in these sample records.
+
+     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
+     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
+
+7.3.  Name of the TGS
+
+   The principal identifier of the ticket-granting service shall be
+   composed of three parts: the realm of the KDC issuing the TGS ticket,
+   and a two-part name of type NT-SRV-INST, with the first part "krbtgt"
+   and the second part the name of the realm that will accept the TGT.
+   For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to
+
+
+
+Neuman, et al.              Standards Track                   [Page 105]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of
+   "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name).  A TGT
+   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).
+
+7.4.  OID Arc for KerberosV5
+
+   This OID MAY be used to identify Kerberos protocol messages
+   encapsulated in other protocols.  It also designates the OID arc for
+   KerberosV5-related OIDs assigned by future IETF action.
+   Implementation note: RFC 1510 had an incorrect value (5) for "dod" in
+   its OID.
+
+   id-krb5         OBJECT IDENTIFIER ::= {
+           iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosV5(2)
+   }
+
+   Assignment of OIDs beneath the id-krb5 arc must be obtained by
+   contacting the registrar for the id-krb5 arc, or its designee.  At
+   the time of the issuance of this RFC, such registrations can be
+   obtained by contacting krb5-oid-registrar@mit.edu.
+
+7.5.  Protocol Constants and Associated Values
+
+   The following tables list constants used in the protocol and define
+   their meanings.  In the "specification" section, ranges are specified
+   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.  Implementations
+   receiving values outside the range specified in the "specification"
+   section MAY reject the request, but they MUST recover cleanly.
+
+7.5.1.  Key Usage Numbers
+
+   The encryption and checksum specifications in [RFC3961] require as
+   input a "key usage number", to alter the encryption key used in any
+   specific message in order to make certain types of cryptographic
+   attack more difficult.  These are the key usage values assigned in
+   this document:
+
+           1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
+               the client key (Section 5.2.7.2)
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 106]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+           2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session
+               key or application session key), encrypted with the
+               service key (Section 5.3)
+           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 (Section 5.5.1)
+           7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
+               TGS authenticator subkey), encrypted with the TGS session
+               key (Section 5.5.1)
+           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.5.1)
+          11.  AP-REQ Authenticator (includes application authenticator
+               subkey), encrypted with the application session key
+               (Section 5.5.1)
+          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.8.1)
+          15.  KRB-SAFE cksum, keyed with a key chosen by the
+               application (Section 5.6.1)
+       16-18.  Reserved for future use in Kerberos and related
+               protocols.
+          19.  AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
+       20-21.  Reserved for future use in Kerberos and related
+               protocols.
+       22-25.  Reserved for use in the Kerberos Version 5 GSS-API
+               mechanisms [RFC4121].
+      26-511.  Reserved for future use in Kerberos and related
+               protocols.
+    512-1023.  Reserved for uses internal to a Kerberos implementation.
+        1024.  Encryption for application use in protocols that do not
+               specify key usage values
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 107]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        1025.  Checksums for application use in protocols that do not
+               specify key usage values
+   1026-2047.  Reserved for application use.
+
+7.5.2.  PreAuthentication Data Types
+
+   Padata and Data Type    Padata-type   Comment
+                            Value
+
+   PA-TGS-REQ                  1
+   PA-ENC-TIMESTAMP            2
+   PA-PW-SALT                  3
+   [reserved]                  4
+   PA-ENC-UNIX-TIME            5        (deprecated)
+   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_OLD            14       (pkinit)
+   PA-PK-AS-REP_OLD            15       (pkinit)
+   PA-PK-AS-REQ                16       (pkinit)
+   PA-PK-AS-REP                17       (pkinit)
+   PA-ETYPE-INFO2              19       (replaces pa-etype-info)
+   PA-USE-SPECIFIED-KVNO       20
+   PA-SAM-REDIRECT             21       (sam/otp)
+   PA-GET-FROM-TYPED-DATA      22       (embedded in typed data)
+   TD-PADATA                   22       (embeds padata)
+   PA-SAM-ETYPE-INFO           23       (sam/otp)
+   PA-ALT-PRINC                24       (crawdad@fnal.gov)
+   PA-SAM-CHALLENGE2           30       (kenh@pobox.com)
+   PA-SAM-RESPONSE2            31       (kenh@pobox.com)
+   PA-EXTRA-TGT                41       Reserved extra TGT
+   TD-PKINIT-CMS-CERTIFICATES  101      CertificateSet from CMS
+   TD-KRB-PRINCIPAL            102      PrincipalName
+   TD-KRB-REALM                103      Realm
+   TD-TRUSTED-CERTIFIERS       104      from PKINIT
+   TD-CERTIFICATE-INDEX        105      from PKINIT
+   TD-APP-DEFINED-ERROR        106      application specific
+   TD-REQ-NONCE                107      INTEGER
+   TD-REQ-SEQ                  108      INTEGER
+   PA-PAC-REQUEST              128      (jbrezak@exchange.microsoft.com)
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 108]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+7.5.3.  Address Types
+
+   Address Type                   Value
+
+   IPv4                             2
+   Directional                      3
+   ChaosNet                         5
+   XNS                              6
+   ISO                              7
+   DECNET Phase IV                 12
+   AppleTalk DDP                   16
+   NetBios                         20
+   IPv6                            24
+
+7.5.4.  Authorization Data Types
+
+   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-AND-OR                          5
+   AD-MANDATORY-TICKET-EXTENSIONS     6
+   AD-IN-TICKET-EXTENSIONS            7
+   AD-MANDATORY-FOR-KDC               8
+   Reserved values                 9-63
+   OSF-DCE                           64
+   SESAME                            65
+   AD-OSF-DCE-PKI-CERTID             66 (hemsath@us.ibm.com)
+   AD-WIN2K-PAC                     128 (jbrezak@exchange.microsoft.com)
+   AD-ETYPE-NEGOTIATION             129  (lzhu@windows.microsoft.com)
+
+7.5.5.  Transited Encoding Types
+
+   Transited Encoding Type         Tr-type Value
+
+   DOMAIN-X500-COMPRESS            1
+   Reserved values                 All others
+
+7.5.6.  Protocol Version Number
+
+   Label               Value   Meaning or MIT Code
+
+   pvno                  5     Current Kerberos protocol version number
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 109]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+7.5.7.  Kerberos Message Types
+
+   Message Type   Value  Meaning
+
+   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_RESERVED16  16    Reserved for user-to-user krb_tgt_request
+   KRB_RESERVED17  17    Reserved for user-to-user krb_tgt_reply
+   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
+
+7.5.8.  Name Types
+
+   Name Type           Value  Meaning
+
+   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 Distinguished name [RFC2253]
+   KRB_NT_SMTP_NAME      7    Name in form of SMTP email name
+                                (e.g., user@example.com)
+   KRB_NT_ENTERPRISE    10    Enterprise name; may be mapped to
+                                principal name
+
+7.5.9.  Error Codes
+
+   Error Code                         Value  Meaning
+
+   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
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 110]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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 starttime 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-
+                                               authentication required
+   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_ACCEPTED             28  KDC Policy rejects
+                                               transited path
+
+
+
+Neuman, et al.              Standards Track                   [Page 111]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   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  Reserved for PKINIT
+   KDC_ERROR_KDC_NOT_TRUSTED             63  Reserved for PKINIT
+   KDC_ERROR_INVALID_SIG                 64  Reserved for PKINIT
+   KDC_ERR_KEY_TOO_WEAK                  65  Reserved for PKINIT
+   KDC_ERR_CERTIFICATE_MISMATCH          66  Reserved for PKINIT
+   KRB_AP_ERR_NO_TGT                     67  No TGT available to
+                                               validate USER-TO-USER
+   KDC_ERR_WRONG_REALM                   68  Reserved for future use
+   KRB_AP_ERR_USER_TO_USER_REQUIRED      69  Ticket must be for
+                                               USER-TO-USER
+   KDC_ERR_CANT_VERIFY_CERTIFICATE       70  Reserved for PKINIT
+   KDC_ERR_INVALID_CERTIFICATE           71  Reserved for PKINIT
+   KDC_ERR_REVOKED_CERTIFICATE           72  Reserved for PKINIT
+
+
+
+Neuman, et al.              Standards Track                   [Page 112]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   KDC_ERR_REVOCATION_STATUS_UNKNOWN     73  Reserved for PKINIT
+   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74  Reserved for PKINIT
+   KDC_ERR_CLIENT_NAME_MISMATCH          75  Reserved for PKINIT
+   KDC_ERR_KDC_NAME_MISMATCH             76  Reserved for PKINIT
+
+8.  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; the format of realm names; the handling of
+   authorization data; and forwarding, postdating, and renewing tickets.
+
+   In order to ensure the interoperability of realms, it is necessary to
+   define a minimal configuration that 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.
+
+8.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.2).  Specification 1
+   (deprecated) may be found in RFC 1510.
+
+   Transport
+
+      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
+      claiming conformance to specification 2.
+
+   Encryption and Checksum Methods
+
+      The following encryption and checksum mechanisms MUST be
+      supported:
+
+      Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
+      Checksums: HMAC-SHA1-96-AES256 [RFC3962]
+
+      Implementations SHOULD support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to also support them.  The following mechanisms
+      from [RFC3961] and [RFC3962] SHOULD be supported:
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 113]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
+      Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128
+
+      Implementations MAY support other mechanisms as well, but the
+      additional mechanisms may only be used when communicating with
+      principals known to support them also.
+
+      Implementation note: Earlier implementations of Kerberos generate
+      messages using the CRC-32 and RSA-MD5 checksum methods.  For
+      interoperability with these earlier releases, implementors MAY
+      consider supporting these checksum methods but should carefully
+      analyze the security implications to limit the situations within
+      which these methods are accepted.
+
+   Realm Names
+
+      All implementations MUST understand hierarchical realms in both
+      the Internet Domain and the X.500 style.  When a TGT for an
+      unknown realm is requested, the KDC MUST be able to determine the
+      names of the intermediate realms between the KDCs realm and the
+      requested realm.
+
+   Transited Field Encoding
+
+      DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be
+      supported.  Alternative encodings MAY be supported, but they may
+      only be used when that encoding is supported by ALL intermediate
+      realms.
+
+   Pre-authentication Methods
+
+      The TGS-REQ method MUST be supported.  It 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 the method is 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 pre-
+      authentication method.  Servers need not support the PA-ENC-
+      TIMESTAMP method, but if it is not supported the server SHOULD
+      ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
+      request.
+
+      The ETYPE-INFO2 method MUST be supported; this method is used to
+      communicate the set of supported encryption types, and
+      corresponding salt and string to key parameters.  The ETYPE-INFO
+      method SHOULD be supported for interoperability with older
+      implementation.
+
+
+
+Neuman, et al.              Standards Track                   [Page 114]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Mutual Authentication
+
+      Mutual authentication (via the KRB_AP_REP message) MUST be
+      supported.
+
+   Ticket Addresses and Flags
+
+      All KDCs MUST pass through tickets that carry no addresses (i.e.,
+      if a TGT contains no addresses, the KDC will return derivative
+      tickets).  Implementations SHOULD default to requesting
+      addressless tickets, as this significantly increases
+      interoperability with network address translation.  In some cases,
+      realms or application servers MAY require that tickets have an
+      address.
+
+      Implementations SHOULD accept directional address type for the
+      KRB_SAFE and KRB_PRIV message and SHOULD include directional
+      addresses in these messages when other address types are not
+      available.
+
+      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 they 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
+      TGTs to any derivative tickets unless they are 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, et al.              Standards Track                   [Page 115]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+      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.
+      Implementations receiving values outside this range MAY reject the
+      request, but they MUST recover cleanly.
+
+8.2.  Recommended KDC Values
+
+   Following is a list of recommended values for a KDC configuration.
+
+      Minimum lifetime              5 minutes
+      Maximum renewable lifetime    1 week
+      Maximum ticket lifetime       1 day
+      Acceptable clock skew         5 minutes
+      Empty addresses               Allowed
+      Proxiable, etc.               Allowed
+
+9.  IANA Considerations
+
+   Section 7 of this document specifies protocol constants and other
+   defined values required for the interoperability of multiple
+   implementations.  Until a subsequent RFC specifies otherwise, or the
+   Kerberos working group is shut down, allocations of additional
+   protocol constants and other defined values required for extensions
+   to the Kerberos protocol will be administered by the Kerberos working
+   group.  Following the recommendations outlined in [RFC2434], guidance
+   is provided to the IANA as follows:
+
+   "reserved" realm name types in Section 6.1 and "other" realm types
+   except those beginning with "X-" or "x-" will not be registered
+   without IETF standards action, at which point guidelines for further
+   assignment will be specified.  Realm name types beginning with "X-"
+   or "x-" are for private use.
+
+   For host address types described in Section 7.1, negative values are
+   for private use.  Assignment of additional positive numbers is
+   subject to review by the Kerberos working group or other expert
+   review.
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 116]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Additional key usage numbers, as defined in Section 7.5.1, will be
+   assigned subject to review by the Kerberos working group or other
+   expert review.
+
+   Additional preauthentication data type values, as defined in section
+   7.5.2, will be assigned subject to review by the Kerberos working
+   group or other expert review.
+
+   Additional authorization data types as defined in Section 7.5.4, will
+   be assigned subject to review by the Kerberos working group or other
+   expert review.  Although it is anticipated that there may be
+   significant demand for private use types, provision is intentionally
+   not made for a private use portion of the namespace because conflicts
+   between privately assigned values could have detrimental security
+   implications.
+
+   Additional transited encoding types, as defined in Section 7.5.5,
+   present special concerns for interoperability with existing
+   implementations.  As such, such assignments will only be made by
+   standards action, except that the Kerberos working group or another
+   other working group with competent jurisdiction may make preliminary
+   assignments for documents that are moving through the standards
+   process.
+
+   Additional Kerberos message types, as described in Section 7.5.7,
+   will be assigned subject to review by the Kerberos working group or
+   other expert review.
+
+   Additional name types, as described in Section 7.5.8, will be
+   assigned subject to review by the Kerberos working group or other
+   expert review.
+
+   Additional error codes described in Section 7.5.9 will be assigned
+   subject to review by the Kerberos working group or other expert
+   review.
+
+10.  Security Considerations
+
+   As an authentication service, Kerberos provides a means of verifying
+   the identity of principals on a network.  By itself, Kerberos does
+   not provide authorization.  Applications should not accept the
+   issuance of a service ticket by the 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 where they inter-operate with other KDCs or where other
+   options for application authentication are provided.
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 117]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Denial of service attacks are not solved with Kerberos.  There are
+   places in the protocols where an intruder can prevent an application
+   from participating in the proper authentication steps.  Because
+   authentication is a required step for the use of many services,
+   successful denial of service attacks on a Kerberos server might
+   result in the denial of other network services that rely on Kerberos
+   for authentication.  Kerberos is vulnerable to many kinds of denial
+   of service attacks: those on the network, which would prevent clients
+   from contacting the KDC; those on the domain name system, which could
+   prevent a client from finding the IP address of the Kerberos server;
+   and those by overloading the Kerberos KDC itself with repeated
+   requests.
+
+   Interoperability conflicts caused by incompatible character-set usage
+   (see 5.2.1) can result in denial of service for clients that utilize
+   character-sets in Kerberos strings other than those stored in the KDC
+   database.
+
+   Authentication servers maintain a database of principals (i.e., users
+   and servers) and their secret keys.  The security of the
+   authentication server machines is critical.  The breach of security
+   of an authentication server will compromise the security of all
+   servers that rely upon the compromised KDC, and will compromise the
+   authentication of any principals registered in the realm of the
+   compromised KDC.
+
+   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 off-line dictionary attack by repeatedly
+   attempting to decrypt, with successive entries from a dictionary,
+   messages obtained that are encrypted under a key derived from the
+   user's password.
+
+   Unless pre-authentication options are required by the policy of a
+   realm, the KDC will not know whether a request for authentication
+   succeeds.  An attacker can request a reply with credentials for any
+   principal.  These credentials will likely not be of much use to the
+   attacker unless it knows the client's secret key, but the
+   availability of the response encrypted in the client's secret key
+   provides the attacker with ciphertext that may be used to mount brute
+   force or dictionary attacks to decrypt the credentials, by guessing
+   the user's password.  For this reason it is strongly encouraged that
+   Kerberos realms require the use of pre-authentication.  Even with
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 118]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   pre-authentication, attackers may try brute force or dictionary
+   attacks against credentials that are observed by eavesdropping on the
+   network.
+
+   Because a client can request a ticket for any server principal and
+   can attempt a brute force or dictionary attack against the server
+   principal's key using that ticket, it is strongly encouraged that
+   keys be randomly generated (rather than generated from passwords) for
+   any principals that are usable as the target principal for a
+   KRB_TGS_REQ or KRB_AS_REQ messages.  [RFC4086]
+
+   Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
+   methods are listed as SHOULD be implemented for backward
+   compatibility, the single DES encryption algorithm on which these are
+   based is weak, and stronger algorithms should be used whenever
+   possible.
+
+   Each host on the network must have a clock that 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 it 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 must 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 reusing principal identifiers, the danger of
+   inadvertent access is removed.
+
+   Proper decryption of an KRB_AS_REP message from the KDC is not
+   sufficient for the host to verify the identity of the user; the user
+   and an attacker could cooperate to generate a KRB_AS_REP format
+   message that decrypts properly but is not from the proper KDC.  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.
+
+   Many RFC 1510-compliant implementations ignore unknown authorization
+   data elements.  Depending on these implementations to honor
+   authorization data restrictions may create a security weakness.
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 119]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Kerberos credentials contain clear-text information identifying the
+   principals to which they apply.  If privacy of this information is
+   needed, this exchange should itself be encapsulated in a protocol
+   providing for confidentiality on the exchange of these credentials.
+
+   Applications must take care to protect communications subsequent to
+   authentication, either by using the KRB_PRIV or KRB_SAFE messages as
+   appropriate, or by applying their own confidentiality or integrity
+   mechanisms on such communications.  Completion of the KRB_AP_REQ and
+   KRB_AP_REP exchange without subsequent use of confidentiality and
+   integrity mechanisms provides only for authentication of the parties
+   to the communication and not confidentiality and integrity of the
+   subsequent communication.  Applications applying confidentiality and
+   integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must
+   make sure that the authentication step is appropriately linked with
+   the protected communication channel that is established by the
+   application.
+
+   Unless the application server provides its own suitable means to
+   protect against replay (for example, a challenge-response sequence
+   initiated by the server after authentication, or use of a server-
+   generated encryption subkey), the server must utilize a replay cache
+   to remember any authenticator presented within the allowable clock
+   skew.  All services sharing a key need to use the same replay cache.
+   If separate replay caches are used, then an authenticator used with
+   one such service could later be replayed to a different service with
+   the same service principal.
+
+   If a server loses track of authenticators presented within the
+   allowable clock skew, it must reject all requests until the clock
+   skew interval has passed, providing assurance that any lost or
+   replayed authenticators will fall outside the allowable clock skew
+   and can no longer be successfully replayed.
+
+   Implementations of Kerberos should not use untrusted directory
+   servers to determine the realm of a host.  To allow this would allow
+   the compromise of the directory server to enable an attacker to
+   direct the client to accept authentication with the wrong principal
+   (i.e., one with a similar name, but in a realm with which the
+   legitimate host was not registered).
+
+   Implementations of Kerberos must not use DNS to map one name to
+   another (canonicalize) in order to determine the host part of the
+   principal name with which one is to communicate.  To allow this
+   canonicalization would allow a compromise of the DNS to result in a
+   client obtaining credentials and correctly authenticating to the
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 120]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   wrong principal.  Though the client will know who it is communicating
+   with, it will not be the principal with which it intended to
+   communicate.
+
+   If the Kerberos server returns a TGT for a realm 'closer' than the
+   desired realm, the client may use local policy configuration to
+   verify that the authentication path used is an acceptable one.
+   Alternatively, a client may choose its own authentication path rather
+   than rely on the Kerberos server to select one.  In either case, any
+   policy or configuration information used to choose or validate
+   authentication paths, whether by the Kerberos server or client, must
+   be obtained from a trusted source.
+
+   The Kerberos protocol in its basic form does not provide perfect
+   forward secrecy for communications.  If traffic has been recorded by
+   an eavesdropper, then messages encrypted using the KRB_PRIV message,
+   or messages encrypted using application-specific encryption under
+   keys exchanged using Kerberos can be decrypted if the user's,
+   application server's, or KDC's key is subsequently discovered.  This
+   is because the session key used to encrypt such messages, when
+   transmitted over the network, is encrypted in the key of the
+   application server.  It is also encrypted under the session key from
+   the user's TGT when it is returned to the user in the KRB_TGS_REP
+   message.  The session key from the TGT is sent to the user in the
+   KRB_AS_REP message encrypted in the user's secret key and embedded in
+   the TGT, which was encrypted in the key of the KDC.  Applications
+   requiring perfect forward secrecy must exchange keys through
+   mechanisms that provide such assurance, but may use Kerberos for
+   authentication of the encrypted channel established through such
+   other means.
+
+11.  Acknowledgements
+
+   This document is a revision to RFC 1510 which was co-authored with
+   John Kohl.  The specification of the Kerberos protocol described in
+   this document is the result of many years of effort.  Over this
+   period, many individuals have contributed to the definition of the
+   protocol and to the writing of the specification.  Unfortunately, it
+   is not possible to list all contributors as authors of this document,
+   though there are many not listed who are authors in spirit, including
+   those who contributed text for parts of some sections, who
+   contributed to the design of parts of the protocol, and who
+   contributed significantly to the discussion of the protocol in the
+   IETF common authentication technology (CAT) and Kerberos working
+   groups.
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 121]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   Among those contributing to the development and specification of
+   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
+   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
+   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
+   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
+   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
+   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
+   Westerlund, and Nicolas Williams.  Many other members of MIT Project
+   Athena, the MIT networking group, and the Kerberos and CAT working
+   groups of the IETF contributed but are not listed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 122]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+A.  ASN.1 module
+
+KerberosV5Spec2 {
+        iso(1) identified-organization(3) dod(6) internet(1)
+        security(5) kerberosV5(2) modules(4) krb5spec2(2)
+} DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+-- OID arc for KerberosV5
+--
+-- This OID may be used to identify Kerberos protocol messages
+-- encapsulated in other protocols.
+--
+-- This OID also designates the OID arc for KerberosV5-related OIDs.
+--
+-- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
+id-krb5         OBJECT IDENTIFIER ::= {
+        iso(1) identified-organization(3) dod(6) internet(1)
+        security(5) kerberosV5(2)
+}
+
+Int32           ::= INTEGER (-2147483648..2147483647)
+                    -- signed values representable in 32 bits
+
+UInt32          ::= INTEGER (0..4294967295)
+                    -- unsigned 32 bit values
+
+Microseconds    ::= INTEGER (0..999999)
+                    -- microseconds
+
+KerberosString  ::= GeneralString (IA5String)
+
+Realm           ::= KerberosString
+
+PrincipalName   ::= SEQUENCE {
+        name-type       [0] Int32,
+        name-string     [1] SEQUENCE OF KerberosString
+}
+
+KerberosTime    ::= GeneralizedTime -- with no fractional seconds
+
+HostAddress     ::= SEQUENCE  {
+        addr-type       [0] Int32,
+        address         [1] OCTET STRING
+}
+
+-- NOTE: HostAddresses is always used as an OPTIONAL field and
+-- should not be empty.
+HostAddresses   -- NOTE: subtly different from rfc1510,
+
+
+
+Neuman, et al.              Standards Track                   [Page 123]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+                -- but has a value mapping and encodes the same
+        ::= SEQUENCE OF HostAddress
+
+-- NOTE: AuthorizationData is always used as an OPTIONAL field and
+-- should not be empty.
+AuthorizationData       ::= SEQUENCE OF SEQUENCE {
+        ad-type         [0] Int32,
+        ad-data         [1] OCTET STRING
+}
+
+PA-DATA         ::= SEQUENCE {
+        -- NOTE: first tag is [1], not [0]
+        padata-type     [1] Int32,
+        padata-value    [2] OCTET STRING -- might be encoded AP-REQ
+}
+
+KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
+                    -- minimum number of bits shall be sent,
+                    -- but no fewer than 32
+
+EncryptedData   ::= SEQUENCE {
+        etype   [0] Int32 -- EncryptionType --,
+        kvno    [1] UInt32 OPTIONAL,
+        cipher  [2] OCTET STRING -- ciphertext
+}
+
+EncryptionKey   ::= SEQUENCE {
+        keytype         [0] Int32 -- actually encryption type --,
+        keyvalue        [1] OCTET STRING
+}
+
+Checksum        ::= SEQUENCE {
+        cksumtype       [0] Int32,
+        checksum        [1] OCTET STRING
+}
+
+Ticket          ::= [APPLICATION 1] SEQUENCE {
+        tkt-vno         [0] INTEGER (5),
+        realm           [1] Realm,
+        sname           [2] PrincipalName,
+        enc-part        [3] EncryptedData -- EncTicketPart
+}
+
+-- Encrypted part of ticket
+EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
+        flags                   [0] TicketFlags,
+        key                     [1] EncryptionKey,
+        crealm                  [2] Realm,
+
+
+
+Neuman, et al.              Standards Track                   [Page 124]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        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] Int32 -- must be registered --,
+        contents        [1] OCTET STRING
+}
+
+TicketFlags     ::= KerberosFlags
+        -- 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),
+-- the following are new since 1510
+        -- transited-policy-checked(12),
+        -- ok-as-delegate(13)
+
+AS-REQ          ::= [APPLICATION 10] KDC-REQ
+
+TGS-REQ         ::= [APPLICATION 12] KDC-REQ
+
+KDC-REQ         ::= SEQUENCE {
+        -- NOTE: first tag is [1], not [0]
+        pvno            [1] INTEGER (5) ,
+        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
+        padata          [3] SEQUENCE OF PA-DATA OPTIONAL
+                            -- NOTE: not empty --,
+        req-body        [4] KDC-REQ-BODY
+}
+
+KDC-REQ-BODY    ::= SEQUENCE {
+        kdc-options             [0] KDCOptions,
+
+
+
+Neuman, et al.              Standards Track                   [Page 125]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        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,
+        rtime                   [6] KerberosTime OPTIONAL,
+        nonce                   [7] UInt32,
+        etype                   [8] SEQUENCE OF Int32 -- EncryptionType
+                                    -- in preference order --,
+        addresses               [9] HostAddresses OPTIONAL,
+        enc-authorization-data  [10] EncryptedData OPTIONAL
+                                    -- AuthorizationData --,
+        additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
+                                        -- NOTE: not empty
+}
+
+KDCOptions      ::= KerberosFlags
+        -- reserved(0),
+        -- forwardable(1),
+        -- forwarded(2),
+        -- proxiable(3),
+        -- proxy(4),
+        -- allow-postdate(5),
+        -- postdated(6),
+        -- unused7(7),
+        -- renewable(8),
+        -- unused9(9),
+        -- unused10(10),
+        -- opt-hardware-auth(11),
+        -- unused12(12),
+        -- unused13(13),
+-- 15 is reserved for canonicalize
+        -- unused15(15),
+-- 26 was unused in 1510
+        -- disable-transited-check(26),
+--
+        -- renewable-ok(27),
+        -- enc-tkt-in-skey(28),
+        -- renew(30),
+        -- validate(31)
+
+AS-REP          ::= [APPLICATION 11] KDC-REP
+
+TGS-REP         ::= [APPLICATION 13] KDC-REP
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 126]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+KDC-REP         ::= SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
+        padata          [2] SEQUENCE OF PA-DATA OPTIONAL
+                                -- NOTE: not empty --,
+        crealm          [3] Realm,
+        cname           [4] PrincipalName,
+        ticket          [5] Ticket,
+        enc-part        [6] EncryptedData
+                                -- EncASRepPart or EncTGSRepPart,
+                                -- as appropriate
+}
+
+EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
+
+EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
+
+EncKDCRepPart   ::= SEQUENCE {
+        key             [0] EncryptionKey,
+        last-req        [1] LastReq,
+        nonce           [2] UInt32,
+        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
+}
+
+LastReq         ::=     SEQUENCE OF SEQUENCE {
+        lr-type         [0] Int32,
+        lr-value        [1] KerberosTime
+}
+
+AP-REQ          ::= [APPLICATION 14] SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (14),
+        ap-options      [2] APOptions,
+        ticket          [3] Ticket,
+        authenticator   [4] EncryptedData -- Authenticator
+}
+
+APOptions       ::= KerberosFlags
+        -- reserved(0),
+        -- use-session-key(1),
+
+
+
+Neuman, et al.              Standards Track                   [Page 127]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        -- mutual-required(2)
+
+-- Unencrypted authenticator
+Authenticator   ::= [APPLICATION 2] SEQUENCE  {
+        authenticator-vno       [0] INTEGER (5),
+        crealm                  [1] Realm,
+        cname                   [2] PrincipalName,
+        cksum                   [3] Checksum OPTIONAL,
+        cusec                   [4] Microseconds,
+        ctime                   [5] KerberosTime,
+        subkey                  [6] EncryptionKey OPTIONAL,
+        seq-number              [7] UInt32 OPTIONAL,
+        authorization-data      [8] AuthorizationData OPTIONAL
+}
+
+AP-REP          ::= [APPLICATION 15] SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (15),
+        enc-part        [2] EncryptedData -- EncAPRepPart
+}
+
+EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
+        ctime           [0] KerberosTime,
+        cusec           [1] Microseconds,
+        subkey          [2] EncryptionKey OPTIONAL,
+        seq-number      [3] UInt32 OPTIONAL
+}
+
+KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (20),
+        safe-body       [2] KRB-SAFE-BODY,
+        cksum           [3] Checksum
+}
+
+KRB-SAFE-BODY   ::= SEQUENCE {
+        user-data       [0] OCTET STRING,
+        timestamp       [1] KerberosTime OPTIONAL,
+        usec            [2] Microseconds OPTIONAL,
+        seq-number      [3] UInt32 OPTIONAL,
+        s-address       [4] HostAddress,
+        r-address       [5] HostAddress OPTIONAL
+}
+
+KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (21),
+                        -- NOTE: there is no [2] tag
+
+
+
+Neuman, et al.              Standards Track                   [Page 128]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        enc-part        [3] EncryptedData -- EncKrbPrivPart
+}
+
+EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
+        user-data       [0] OCTET STRING,
+        timestamp       [1] KerberosTime OPTIONAL,
+        usec            [2] Microseconds OPTIONAL,
+        seq-number      [3] UInt32 OPTIONAL,
+        s-address       [4] HostAddress -- sender's addr --,
+        r-address       [5] HostAddress OPTIONAL -- recip's addr
+}
+
+KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (22),
+        tickets         [2] SEQUENCE OF Ticket,
+        enc-part        [3] EncryptedData -- EncKrbCredPart
+}
+
+EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
+        ticket-info     [0] SEQUENCE OF KrbCredInfo,
+        nonce           [1] UInt32 OPTIONAL,
+        timestamp       [2] KerberosTime OPTIONAL,
+        usec            [3] Microseconds 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
+}
+
+KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
+        pvno            [0] INTEGER (5),
+        msg-type        [1] INTEGER (30),
+        ctime           [2] KerberosTime OPTIONAL,
+        cusec           [3] Microseconds OPTIONAL,
+        stime           [4] KerberosTime,
+
+
+
+Neuman, et al.              Standards Track                   [Page 129]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+        susec           [5] Microseconds,
+        error-code      [6] Int32,
+        crealm          [7] Realm OPTIONAL,
+        cname           [8] PrincipalName OPTIONAL,
+        realm           [9] Realm -- service realm --,
+        sname           [10] PrincipalName -- service name --,
+        e-text          [11] KerberosString OPTIONAL,
+        e-data          [12] OCTET STRING OPTIONAL
+}
+
+METHOD-DATA     ::= SEQUENCE OF PA-DATA
+
+TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
+        data-type       [0] Int32,
+        data-value      [1] OCTET STRING OPTIONAL
+}
+
+-- preauth stuff follows
+
+PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
+
+PA-ENC-TS-ENC           ::= SEQUENCE {
+        patimestamp     [0] KerberosTime -- client's time --,
+        pausec          [1] Microseconds OPTIONAL
+}
+
+ETYPE-INFO-ENTRY        ::= SEQUENCE {
+        etype           [0] Int32,
+        salt            [1] OCTET STRING OPTIONAL
+}
+
+ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
+
+ETYPE-INFO2-ENTRY       ::= SEQUENCE {
+        etype           [0] Int32,
+        salt            [1] KerberosString OPTIONAL,
+        s2kparams       [2] OCTET STRING OPTIONAL
+}
+
+ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
+
+AD-IF-RELEVANT          ::= AuthorizationData
+
+AD-KDCIssued            ::= SEQUENCE {
+        ad-checksum     [0] Checksum,
+        i-realm         [1] Realm OPTIONAL,
+        i-sname         [2] PrincipalName OPTIONAL,
+        elements        [3] AuthorizationData
+
+
+
+Neuman, et al.              Standards Track                   [Page 130]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+}
+
+AD-AND-OR               ::= SEQUENCE {
+        condition-count [0] Int32,
+        elements        [1] AuthorizationData
+}
+
+AD-MANDATORY-FOR-KDC    ::= AuthorizationData
+
+END
+
+B.  Changes since RFC 1510
+
+   This document replaces RFC 1510 and clarifies specification of items
+   that were not completely specified.  Where changes to recommended
+   implementation choices were made, or where new options were added,
+   those changes are described within the document and listed in this
+   section.  More significantly, "Specification 2" in Section 8 changes
+   the required encryption and checksum methods to bring them in line
+   with the best current practices and to deprecate methods that are no
+   longer considered sufficiently strong.
+
+   Discussion was added to Section 1 regarding the ability to rely on
+   the KDC to check the transited field, and on the inclusion of a flag
+   in a ticket indicating that this check has occurred.  This is a new
+   capability not present in RFC 1510.  Pre-existing implementations may
+   ignore or not set this flag without negative security implications.
+
+   The definition of the secret key says that in the case of a user the
+   key may be derived from a password.  In RFC 1510, it said that the
+   key was derived from the password.  This change was made to
+   accommodate situations where the user key might be stored on a
+   smart-card, or otherwise obtained independently of a password.
+
+   The introduction mentions the use of public key cryptography for
+   initial authentication in Kerberos by reference.  RFC 1510 did not
+   include such a reference.
+
+   Section 1.3 was added to explain that while Kerberos provides
+   authentication of a named principal, it is still the responsibility
+   of the application to ensure that the authenticated name is the
+   entity with which the application wishes to communicate.
+
+   Discussion of extensibility has been added to the introduction.
+
+   Discussion of how extensibility affects ticket flags and KDC options
+   was added to the introduction of Section 2.  No changes were made to
+   existing options and flags specified in RFC 1510, though some of the
+
+
+
+Neuman, et al.              Standards Track                   [Page 131]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   sections in the specification were renumbered, and text was revised
+   to make the description and intent of existing options clearer,
+   especially with respect to the ENC-TKT-IN-SKEY option (now section
+   2.9.2) which is used for user-to-user authentication.  The new option
+   and ticket flag transited policy checking (Section 2.7) was added.
+
+   A warning regarding generation of session keys for application use
+   was added to Section 3, urging the inclusion of key entropy from the
+   KDC generated session key in the ticket.  An example regarding use of
+   the sub-session key was added to Section 3.2.6.  Descriptions of the
+   pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
+   items were added.  The recommendation for use of pre-authentication
+   was changed from "MAY" to "SHOULD" and a note was added regarding
+   known plaintext attacks.
+
+   In RFC 1510, Section 4 described the database in the KDC.  This
+   discussion was not necessary for interoperability and unnecessarily
+   constrained implementation.  The old Section 4 was removed.
+
+   The current Section 4 was formerly Section 6 on encryption and
+   checksum specifications.  The major part of this section was brought
+   up to date to support new encryption methods, and moved to a separate
+   document.  Those few remaining aspects of the encryption and checksum
+   specification specific to Kerberos are now specified in Section 4.
+
+   Significant changes were made to the layout of Section 5 to clarify
+   the correct behavior for optional fields.  Many of these changes were
+   made necessary because of improper ASN.1 description in the original
+   Kerberos specification which left the correct behavior
+   underspecified.  Additionally, the wording in this section was
+   tightened wherever possible to ensure that implementations conforming
+   to this specification will be extensible with the addition of new
+   fields in future specifications.
+
+   Text was added describing time_t=0 issues in the ASN.1.  Text was
+   also added, clarifying issues with implementations treating omitted
+   optional integers as zero.  Text was added clarifying behavior for
+   optional SEQUENCE or SEQUENCE OF that may be empty.  Discussion was
+   added regarding sequence numbers and behavior of some
+   implementations, including "zero" behavior and negative numbers.  A
+   compatibility note was added regarding the unconditional sending of
+   EncTGSRepPart regardless of the enclosing reply type.  Minor changes
+   were made to the description of the HostAddresses type.  Integer
+   types were constrained.  KerberosString was defined as a
+   (significantly) constrained GeneralString.  KerberosFlags was defined
+   to reflect existing implementation behavior that departs from the
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 132]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   definition in RFC 1510.  The transited-policy-checked(12) and the
+   ok-as-delegate(13) ticket flags were added.  The disable-transited-
+   check(26) KDC option was added.
+
+   Descriptions of commonly implemented PA-DATA were added to Section 5.
+   The description of KRB-SAFE has been updated to note the existing
+   implementation behavior of double-encoding.
+
+   There were two definitions of METHOD-DATA in RFC 1510.  The second
+   one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
+   SEQUENCE OF PA-DATA definition.
+
+   Section 7, naming constraints, from RFC 1510 was moved to Section 6.
+
+   Words were added describing the convention that domain-based realm
+   names for newly-created realms should be specified as uppercase.
+   This recommendation does not make lowercase realm names illegal.
+   Words were added highlighting that the slash-separated components in
+   the X.500 style of realm names is consistent with existing RFC 1510
+   based implementations, but that it conflicts with the general
+   recommendation of X.500 name representation specified in RFC 2253.
+
+   Section 8, network transport, constants and defined values, from RFC
+   1510 was moved to Section 7.  Since RFC 1510, the definition of the
+   TCP transport for Kerberos messages was added, and the encryption and
+   checksum number assignments have been moved into a separate document.
+
+   "Specification 2" in Section 8 of the current document changes the
+   required encryption and checksum methods to bring them in line with
+   the best current practices and to deprecate methods that are no
+   longer considered sufficiently strong.
+
+   Two new sections, on IANA considerations and security considerations
+   were added.
+
+   The pseudo-code has been removed from the appendix.  The pseudo-code
+   was sometimes misinterpreted to limit implementation choices and in
+   RFC 1510, it was not always consistent with the words in the
+   specification.  Effort was made to clear up any ambiguities in the
+   specification, rather than to rely on the pseudo-code.
+
+   An appendix was added containing the complete ASN.1 module drawn from
+   the discussion in Section 5 of the current document.
+
+END NOTES
+
+   (*TM) Project Athena, Athena, and Kerberos are trademarks of the
+   Massachusetts Institute of Technology (MIT).
+
+
+
+Neuman, et al.              Standards Track                   [Page 133]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+Normative References
+
+   [RFC3961]          Raeburn, K., "Encryption and Checksum
+                      Specifications for Kerberos 5", RFC 3961, February
+                      2005.
+
+   [RFC3962]          Raeburn, K., "Advanced Encryption Standard (AES)
+                      Encryption for Kerberos 5", RFC 3962, February
+                      2005.
+
+   [ISO-646/ECMA-6]   International Organization for Standardization,
+                      "7-bit Coded Character Set for Information
+                      Interchange", ISO/IEC 646:1991.
+
+   [ISO-2022/ECMA-35] International Organization for Standardization,
+                      "Character code structure and extension
+                      techniques", ISO/IEC 2022:1994.
+
+   [RFC1035]          Mockapetris, P., "Domain names - implementation
+                      and specification", STD 13, RFC 1035, November
+                      1987.
+
+   [RFC2119]          Bradner, S., "Key words for use in RFCs to
+                      Indicate Requirement Levels", BCP 14, RFC 2119,
+                      March 1997.
+
+   [RFC2434]          Narten, T. and H. Alvestrand, "Guidelines for
+                      Writing an IANA Considerations Section in RFCs",
+                      BCP 26, RFC 2434, October 1998.
+
+   [RFC2782]          Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
+                      RR for specifying the location of services (DNS
+                      SRV)", RFC 2782, February 2000.
+
+   [RFC2253]          Wahl, M., Kille, S., and T. Howes, "Lightweight
+                      Directory Access Protocol (v3): UTF-8 String
+                      Representation of Distinguished Names", RFC 2253,
+                      December 1997.
+
+   [RFC3513]          Hinden, R. and S. Deering, "Internet Protocol
+                      Version 6 (IPv6) Addressing Architecture", RFC
+                      3513, April 2003.
+
+   [X680]             Abstract Syntax Notation One (ASN.1):
+                      Specification of Basic Notation, ITU-T
+                      Recommendation X.680 (1997) | ISO/IEC
+                      International Standard 8824-1:1998.
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 134]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   [X690]             ASN.1 encoding rules: Specification of Basic
+                      Encoding Rules (BER), Canonical Encoding Rules
+                      (CER) and Distinguished Encoding Rules (DER),
+                      ITU-T Recommendation X.690 (1997)| ISO/IEC
+                      International Standard 8825-1:1998.
+
+Informative References
+
+   [ISO-8859]         International Organization for Standardization,
+                      "8-bit Single-byte Coded Graphic Character Sets --
+                      Latin Alphabet", ISO/IEC 8859.
+
+   [RFC1964]          Linn, J., "The Kerberos Version 5 GSS-API
+                      Mechanism", RFC 1964, June 1996.
+
+   [DGT96]            Don Davis, Daniel Geer, and Theodore Ts'o,
+                      "Kerberos With Clocks Adrift: History, Protocols,
+                      and Implementation", USENIX Computing Systems 9:1,
+                      January 1996.
+
+   [DS81]             Dorothy E. Denning and Giovanni Maria Sacco,
+                      "Time-stamps in Key Distribution Protocols,"
+                      Communications of the ACM, Vol. 24 (8), p. 533-
+                      536, August 1981.
+
+   [KNT94]            John T. Kohl, B. Clifford Neuman, and Theodore Y.
+                      Ts'o, "The Evolution of the Kerberos
+                      Authentication System". In Distributed Open
+                      Systems, pages 78-94. IEEE Computer Society Press,
+                      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.
+
+   [NS78]             Roger M. Needham and Michael D. Schroeder, "Using
+                      Encryption for Authentication in Large Networks of
+                      Computers," Communications of the ACM, Vol. 21
+                      (12), pp. 993-999, December 1978.
+
+   [Neu93]            B. Clifford Neuman, "Proxy-Based Authorization and
+                      Accounting for Distributed Systems," in
+                      Proceedings of the 13th International Conference
+                      on Distributed Computing Systems, Pittsburgh, PA,
+                      May 1993.
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 135]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+   [NT94]             B. Clifford Neuman and Theodore Y. Ts'o, "An
+                      Authentication Service for Computer Networks,"
+                      IEEE Communications Magazine, Vol. 32 (9), p. 33-
+                      38, September 1994.
+
+   [Pat92]            J. Pato, Using Pre-Authentication to Avoid
+                      Password Guessing Attacks, Open Software
+                      Foundation DCE Request for Comments 26 (December
+                      1992.
+
+   [RFC1510]          Kohl, J. and C. Neuman, "The Kerberos Network
+                      Authentication Service (V5)", RFC 1510, September
+                      1993.
+
+   [RFC4086]          Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                      "Randomness Requirements for Security", BCP 106,
+                      RFC 4086, June 2005.
+
+   [SNS88]            J. G. Steiner, B. C. Neuman, and J. I. Schiller,
+                      "Kerberos: An Authentication Service for Open
+                      Network Systems," p. 191-202, Usenix Conference
+                      Proceedings, Dallas, Texas, February 1988.
+
+   [RFC4121]          Zhu, L., Jaganathan, K., and S. Hartman, "The
+                      Kerberos Version 5 Generic Security Service
+                      Application Program Interface (GSS-API) Mechanism:
+                      Version 2", RFC 4121, July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 136]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+Authors' Addresses
+
+   Clifford Neuman
+   Information Sciences Institute
+   University of Southern California
+   4676 Admiralty Way
+   Marina del Rey, CA 90292, USA
+
+   EMail: bcn@isi.edu
+
+
+   Tom Yu
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139, USA
+
+   EMail: tlyu@mit.edu
+
+
+   Sam Hartman
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139, USA
+
+   EMail: hartmans-ietf@mit.edu
+
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139, USA
+
+   EMail: raeburn@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 137]
+
+RFC 4120                      Kerberos V5                      July 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Neuman, et al.              Standards Track                   [Page 138]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4121.txt b/third_party/heimdal/doc/standardisation/rfc4121.txt
new file mode 100644
index 00000000000..b4115143f50
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4121.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                             L. Zhu
+Request for Comments: 4121                                 K. Jaganathan
+Updates: 1964                                                  Microsoft
+Category: Standards Track                                     S. Hartman
+                                                                     MIT
+                                                               July 2005
+
+
+                        The Kerberos Version 5
+   Generic Security Service Application Program Interface (GSS-API)
+                         Mechanism: Version 2
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines protocols, procedures, and conventions to be
+   employed by peers implementing the Generic Security Service
+   Application Program Interface (GSS-API) when using the Kerberos
+   Version 5 mechanism.
+
+   RFC 1964 is updated and incremental changes are proposed in response
+   to recent developments such as the introduction of Kerberos
+   cryptosystem framework.  These changes support the inclusion of new
+   cryptosystems, by defining new per-message tokens along with their
+   encryption and checksum algorithms based on the cryptosystem
+   profiles.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 1]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Key Derivation for Per-Message Tokens ...........................4
+   3. Quality of Protection ...........................................4
+   4. Definitions and Token Formats ...................................5
+      4.1. Context Establishment Tokens ...............................5
+           4.1.1. Authenticator Checksum ..............................6
+      4.2. Per-Message Tokens .........................................9
+           4.2.1. Sequence Number .....................................9
+           4.2.2. Flags Field .........................................9
+           4.2.3. EC Field ...........................................10
+           4.2.4. Encryption and Checksum Operations .................10
+           4.2.5. RRC Field ..........................................11
+           4.2.6. Message Layouts ....................................12
+      4.3. Context Deletion Tokens ...................................13
+      4.4. Token Identifier Assignment Considerations ................13
+   5. Parameter Definitions ..........................................14
+      5.1. Minor Status Codes ........................................14
+           5.1.1. Non-Kerberos-specific Codes ........................14
+           5.1.2. Kerberos-specific Codes ............................15
+      5.2. Buffer Sizes ..............................................15
+   6. Backwards Compatibility Considerations .........................15
+   7. Security Considerations ........................................16
+   8. Acknowledgements................................................17
+   9. References .....................................................18
+      9.1. Normative References ......................................18
+      9.2. Informative References ....................................18
+
+1.  Introduction
+
+   [RFC3961] defines a generic framework for describing encryption and
+   checksum types to be used with the Kerberos protocol and associated
+   protocols.
+
+   [RFC1964] describes the GSS-API mechanism for Kerberos Version 5.  It
+   defines the format of context establishment, per-message and context
+   deletion tokens, and uses algorithm identifiers for each cryptosystem
+   in per-message and context deletion tokens.
+
+   The approach taken in this document obviates the need for algorithm
+   identifiers.  This is accomplished by using the same encryption
+   algorithm, specified by the crypto profile [RFC3961] for the session
+   key or subkey that is created during context negotiation, and its
+   required checksum algorithm.  Message layouts of the per-message
+   tokens are therefore revised to remove algorithm indicators and to
+   add extra information to support the generic crypto framework
+   [RFC3961].
+
+
+
+Zhu, et al.                 Standards Track                     [Page 2]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   Tokens transferred between GSS-API peers for security context
+   establishment are also described in this document.  The data elements
+   exchanged between a GSS-API endpoint implementation and the Kerberos
+   Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API
+   usage and are therefore defined within [RFC4120] rather than this
+   specification.
+
+   The new token formats specified in this document MUST be used with
+   all "newer" encryption types [RFC4120] and MAY be used with
+   encryption types that are not "newer", provided that the initiator
+   and acceptor know from the context establishment that they can both
+   process these new token formats.
+
+   "Newer" encryption types are those which have been specified along
+   with or since the new Kerberos cryptosystem specification [RFC3961],
+   as defined in section 3.1.3 of [RFC4120].  The list of not-newer
+   encryption types is as follows [RFC3961]:
+
+           Encryption Type             Assigned Number
+         ----------------------------------------------
+          des-cbc-crc                        1
+          des-cbc-md4                        2
+          des-cbc-md5                        3
+          des3-cbc-md5                       5
+          des3-cbc-sha1                      7
+          dsaWithSHA1-CmsOID                 9
+          md5WithRSAEncryption-CmsOID       10
+          sha1WithRSAEncryption-CmsOID      11
+          rc2CBC-EnvOID                     12
+          rsaEncryption-EnvOID              13
+          rsaES-OAEP-ENV-OID                14
+          des-ede3-cbc-Env-OID              15
+          des3-cbc-sha1-kd                  16
+          rc4-hmac                          23
+
+   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 [RFC2119].
+
+   The term "little-endian order" is used for brevity to refer to the
+   least-significant-octet-first encoding, while the term "big-endian
+   order" is for the most-significant-octet-first encoding.
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 3]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+2.  Key Derivation for Per-Message Tokens
+
+   To limit the exposure of a given key, [RFC3961] adopted "one-way"
+   "entropy-preserving" derived keys, from a base key or protocol key,
+   for different purposes or key usages.
+
+   This document defines four key usage values below that are used to
+   derive a specific key for signing and sealing messages from the
+   session key or subkey [RFC4120] created during the context
+   establishment.
+
+           Name                         Value
+         -------------------------------------
+          KG-USAGE-ACCEPTOR-SEAL         22
+          KG-USAGE-ACCEPTOR-SIGN         23
+          KG-USAGE-INITIATOR-SEAL        24
+          KG-USAGE-INITIATOR-SIGN        25
+
+   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
+   used as the usage number in the key derivation function for deriving
+   keys to be used in MIC tokens (as defined in section 4.2.6.1).
+   KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section
+   4.2.6.2).  Similarly, when the sender is the context initiator,
+   KG-USAGE-INITIATOR-SIGN is used as the usage number in the key
+   derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is
+   used for Wrap tokens.  Even if the Wrap token does not provide for
+   confidentiality, the same usage values specified above are used.
+
+   During the context initiation and acceptance sequence, the acceptor
+   MAY assert a subkey in the AP-REP message.  If the acceptor asserts a
+   subkey, the base key is the acceptor-asserted subkey and subsequent
+   per-message tokens MUST be flagged with "AcceptorSubkey", as
+   described in section 4.2.2.  Otherwise, if the initiator asserts a
+   subkey in the AP-REQ message, the base key is this subkey;  if the
+   initiator does not assert a subkey, the base key is the session key
+   in the service ticket.
+
+3.  Quality of Protection
+
+   The GSS-API specification [RFC2743] provides Quality of Protection
+   (QOP) values that can be used by applications to request a certain
+   type of encryption or signing.  A zero QOP value is used to indicate
+   the "default" protection; applications that do not use the default
+   QOP are not guaranteed to be portable across implementations, or even
+   to inter-operate with different deployment configurations of the same
+   implementation.  Using a different algorithm than the one for which
+   the key is defined may not be appropriate.  Therefore, when the new
+   method in this document is used, the QOP value is ignored.
+
+
+
+Zhu, et al.                 Standards Track                     [Page 4]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   The encryption and checksum algorithms in per-message tokens are now
+   implicitly defined by the algorithms associated with the session key
+   or subkey.  Therefore, algorithm identifiers as described in
+   [RFC1964] are no longer needed and are removed from the new token
+   headers.
+
+4.  Definitions and Token Formats
+
+   This section provides terms and definitions, as well as descriptions
+   for tokens specific to the Kerberos Version 5 GSS-API mechanism.
+
+4.1.  Context Establishment Tokens
+
+   All context establishment tokens emitted by the Kerberos Version 5
+   GSS-API mechanism SHALL have the framing described in section 3.1 of
+   [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
+
+         GSS-API DEFINITIONS ::=
+
+         BEGIN
+
+         MechType ::= OBJECT IDENTIFIER
+         -- representing Kerberos V5 mechanism
+
+         GSSAPI-Token ::=
+         -- option indication (delegation, etc.) indicated within
+         -- mechanism-specific token
+         [APPLICATION 0] IMPLICIT SEQUENCE {
+                 thisMech MechType,
+                 innerToken ANY DEFINED BY thisMech
+                    -- contents mechanism-specific
+                    -- ASN.1 structure not required
+                 }
+
+         END
+
+   The innerToken field starts with a two-octet token-identifier
+   (TOK_ID) expressed in big-endian order, followed by a Kerberos
+   message.
+
+   Following are the TOK_ID values used in the context establishment
+   tokens:
+
+          Token               TOK_ID Value in Hex
+         -----------------------------------------
+          KRB_AP_REQ            01 00
+          KRB_AP_REP            02 00
+          KRB_ERROR             03 00
+
+
+
+Zhu, et al.                 Standards Track                     [Page 5]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR
+   are defined in [RFC4120].
+
+   If an unknown token identifier (TOK_ID) is received in the initial
+   context establishment token, the receiver MUST return
+   GSS_S_CONTINUE_NEEDED major status, and the returned output token
+   MUST contain a KRB_ERROR message with the error code
+   KRB_AP_ERR_MSG_TYPE [RFC4120].
+
+4.1.1.  Authenticator Checksum
+
+   The authenticator in the KRB_AP_REQ message MUST include the optional
+   sequence number and the checksum field.  The checksum field is used
+   to convey service flags, channel bindings, and optional delegation
+   information.
+
+   The checksum type MUST be 0x8003.  When delegation is used, a
+   ticket-granting ticket will be transferred in a KRB_CRED message.
+   This ticket SHOULD have its forwardable flag set.  The EncryptedData
+   field of the KRB_CRED message [RFC4120] MUST be encrypted in the
+   session key of the ticket used to authenticate the context.
+
+   The authenticator checksum field SHALL have the following format:
+
+       Octet        Name      Description
+      -----------------------------------------------------------------
+       0..3         Lgth    Number of octets in Bnd field;  Represented
+                            in little-endian order;  Currently contains
+                            hex value 10 00 00 00 (16).
+       4..19        Bnd     Channel binding information, as described in
+                            section 4.1.1.2.
+       20..23       Flags   Four-octet context-establishment flags in
+                            little-endian order as described in section
+                            4.1.1.1.
+       24..25       DlgOpt  The delegation option identifier (=1) in
+                            little-endian order [optional].  This field
+                            and the next two fields are present if and
+                            only if GSS_C_DELEG_FLAG is set as described
+                            in section 4.1.1.1.
+       26..27       Dlgth   The length of the Deleg field in
+                            little-endian order [optional].
+       28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)
+                            [optional].
+       n..last      Exts    Extensions [optional].
+
+   The length of the checksum field MUST be at least 24 octets when
+   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at
+   least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  When
+
+
+
+Zhu, et al.                 Standards Track                     [Page 6]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the
+   checksum data MUST immediately follow the Flags field.  The optional
+   trailing octets (namely the "Exts" field) facilitate future
+   extensions to this mechanism.  When delegation is not used, but the
+   Exts field is present, the Exts field starts at octet 24 (DlgOpt,
+   Dlgth and Deleg are absent).
+
+   Initiators that do not support the extensions MUST NOT include more
+   than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not
+   set) or more than 28 octets plus the KRB_CRED in the Deleg field
+   (when GSS_C_DELEG_FLAG is set).  Acceptors that do not understand the
+
+   Extensions MUST ignore any octets past the Deleg field of the
+   checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field
+   of the checksum data (when GSS_C_DELEG_FLAG is not set).
+
+4.1.1.1.  Checksum Flags Field
+
+   The checksum "Flags" field is used to convey service options or
+   extension negotiation information.
+
+   The following context establishment flags are defined in [RFC2744].
+
+           Flag Name              Value
+         ---------------------------------
+          GSS_C_DELEG_FLAG           1
+          GSS_C_MUTUAL_FLAG          2
+          GSS_C_REPLAY_FLAG          4
+          GSS_C_SEQUENCE_FLAG        8
+          GSS_C_CONF_FLAG           16
+          GSS_C_INTEG_FLAG          32
+
+   Context establishment flags are exposed to the calling application.
+   If the calling application desires a particular service option, then
+   it requests that option via GSS_Init_sec_context() [RFC2743].  If the
+   corresponding return state values [RFC2743] indicate that any of the
+   above optional context level services will be active on the context,
+   the corresponding flag values in the table above MUST be set in the
+   checksum Flags field.
+
+   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use
+   with legacy vendor-specific extensions to this mechanism.
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 7]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   All other flag values not specified herein are reserved for future
+   use.  Future revisions of this mechanism may use these reserved flags
+   and may rely on implementations of this version to not use such flags
+   in order to properly negotiate mechanism versions.  Undefined flag
+   values MUST be cleared by the sender, and unknown flags MUST be
+   ignored by the receiver.
+
+4.1.1.2.  Channel Binding Information
+
+   These tags are intended to be used to identify the particular
+   communications channel for which the GSS-API security context
+   establishment tokens are intended, thus limiting the scope within
+   which an intercepted context establishment token can be reused by an
+   attacker (see [RFC2743], section 1.1.6).
+
+   When using C language bindings, channel bindings are communicated to
+   the GSS-API using the following structure [RFC2744]:
+
+         typedef struct gss_channel_bindings_struct {
+            OM_uint32       initiator_addrtype;
+            gss_buffer_desc initiator_address;
+            OM_uint32       acceptor_addrtype;
+            gss_buffer_desc acceptor_address;
+            gss_buffer_desc application_data;
+         } *gss_channel_bindings_t;
+
+   The member fields and constants used for different address types are
+   defined in [RFC2744].
+
+   The "Bnd" field contains the MD5 hash of channel bindings, taken over
+   all non-null components of bindings, in order of declaration.
+   Integer fields within channel bindings are represented in little-
+   endian order for the purposes of the MD5 calculation.
+
+   In computing the contents of the Bnd field, the following detailed
+   points apply:
+
+   (1) For purposes of MD5 hash computation, each integer field and
+       input length field SHALL be formatted into four octets, using
+       little-endian octet ordering.
+
+   (2) All input length fields within gss_buffer_desc elements of a
+       gss_channel_bindings_struct even those which are zero-valued,
+       SHALL be included in the hash calculation.  The value elements of
+       gss_buffer_desc elements SHALL be dereferenced, and the resulting
+       data SHALL be included within the hash computation, only for the
+       case of gss_buffer_desc elements having non-zero length
+       specifiers.
+
+
+
+Zhu, et al.                 Standards Track                     [Page 8]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
+       valid channel binding structure, the Bnd field SHALL be set to 16
+       zero-valued octets.
+
+   If the caller to GSS_Accept_sec_context [RFC2743] passes in
+   GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the
+   acceptor MAY ignore any channel bindings supplied by the initiator,
+   returning success even if the initiator did pass in channel bindings.
+
+   If the application supplies, in the channel bindings, a buffer with a
+   length field larger than 4294967295 (2^32 - 1), the implementation of
+   this mechanism MAY choose to reject the channel bindings altogether,
+   using major status GSS_S_BAD_BINDINGS [RFC2743].  In any case, the
+   size of channel-binding data buffers that can be used (interoperable,
+   without extensions) with this specification is limited to 4294967295
+   octets.
+
+4.2.  Per-Message Tokens
+
+   Two classes of tokens are defined in this section: (1) "MIC" tokens,
+   emitted by calls to GSS_GetMIC() and consumed by calls to
+   GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to
+   GSS_Wrap() and consumed by calls to GSS_Unwrap().
+
+   These new per-message tokens do not include the generic GSS-API token
+   framing used by the context establishment tokens.  These new tokens
+   are designed to be used with newer crypto systems that can have
+   variable-size checksums.
+
+4.2.1.  Sequence Number
+
+   To distinguish intentionally-repeated messages from maliciously-
+   replayed ones, per-message tokens contain a sequence number field,
+   which is a 64 bit integer expressed in big-endian order.  After
+   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence
+   numbers SHALL be incremented by one.
+
+4.2.2.  Flags Field
+
+   The "Flags" field is a one-octet integer used to indicate a set of
+   attributes for the protected message.  For example, one flag is
+   allocated as the direction-indicator, thus preventing the acceptance
+   of the same message sent back in the reverse direction by an
+   adversary.
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 9]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   The meanings of bits in this field (the least significant bit is bit
+   0) are as follows:
+
+          Bit    Name             Description
+         --------------------------------------------------------------
+          0   SentByAcceptor   When set, this flag indicates the sender
+                               is the context acceptor.  When not set,
+                               it indicates the sender is the context
+                               initiator.
+          1   Sealed           When set in Wrap tokens, this flag
+                               indicates confidentiality is provided
+                               for.  It SHALL NOT be set in MIC tokens.
+          2   AcceptorSubkey   A subkey asserted by the context acceptor
+                               is used to protect the message.
+
+   The rest of available bits are reserved for future use and MUST be
+   cleared.  The receiver MUST ignore unknown flags.
+
+4.2.3.  EC Field
+
+   The "EC" (Extra Count) field is a two-octet integer field expressed
+   in big-endian order.
+
+   In Wrap tokens with confidentiality, the EC field SHALL be used to
+   encode the number of octets in the filler, as described in section
+   4.2.4.
+
+   In Wrap tokens without confidentiality, the EC field SHALL be used to
+   encode the number of octets in the trailing checksum, as described in
+   section 4.2.4.
+
+4.2.4.  Encryption and Checksum Operations
+
+   The encryption algorithms defined by the crypto profiles provide for
+   integrity protection [RFC3961].  Therefore, no separate checksum is
+   needed.
+
+   The result of decryption can be longer than the original plaintext
+   [RFC3961] and the extra trailing octets are called "crypto-system
+   residue" in this document.  However, given the size of any plaintext
+   data, one can always find a (possibly larger) size, such that when
+   padding the to-be-encrypted text to that size, there will be no
+   crypto-system residue added [RFC3961].
+
+   In Wrap tokens that provide for confidentiality, the first 16 octets
+   of the Wrap token (the "header", as defined in section 4.2.6), SHALL
+   be appended to the plaintext data before encryption.  Filler octets
+   MAY be inserted between the plaintext data and the "header."  The
+
+
+
+Zhu, et al.                 Standards Track                    [Page 10]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   values and size of the filler octets are chosen by implementations,
+   such that there SHALL be no crypto-system residue present after the
+   decryption.  The resulting Wrap token is {"header" |
+   encrypt(plaintext-data | filler | "header")}, where encrypt() is the
+   encryption operation (which provides for integrity protection)
+   defined in the crypto profile [RFC3961], and the RRC field (as
+   defined in section 4.2.5) in the to-be-encrypted header contains the
+   hex value 00 00.
+
+   In Wrap tokens that do not provide for confidentiality, the checksum
+   SHALL be calculated first over the to-be-signed plaintext data, and
+   then over the first 16 octets of the Wrap token (the "header", as
+   defined in section 4.2.6).  Both the EC field and the RRC field in
+   the token header SHALL be filled with zeroes for the purpose of
+   calculating the checksum.  The resulting Wrap token is {"header" |
+   plaintext-data | get_mic(plaintext-data | "header")}, where get_mic()
+   is the checksum operation for the required checksum mechanism of the
+   chosen encryption mechanism defined in the crypto profile [RFC3961].
+
+   The parameters for the key and the cipher-state in the encrypt() and
+   get_mic() operations have been omitted for brevity.
+
+   For MIC tokens, the checksum SHALL be calculated as follows: the
+   checksum operation is calculated first over the to-be-signed
+   plaintext data, and then over the first 16 octets of the MIC token,
+   where the checksum mechanism is the required checksum mechanism of
+   the chosen encryption mechanism defined in the crypto profile
+   [RFC3961].
+
+   The resulting Wrap and MIC tokens bind the data to the token header,
+   including the sequence number and the direction indicator.
+
+4.2.5.  RRC Field
+
+   The "RRC" (Right Rotation Count) field in Wrap tokens is added to
+   allow the data to be encrypted in-place by existing SSPI (Security
+   Service Provider Interface) [SSPI] applications that do not provide
+   an additional buffer for the trailer (the cipher text after the in-
+   place-encrypted data) in addition to the buffer for the header (the
+   cipher text before the in-place-encrypted data).  Excluding the first
+   16 octets of the token header, the resulting Wrap token in the
+   previous section is rotated to the right by "RRC" octets.  The net
+   result is that "RRC" octets of trailing octets are moved toward the
+   header.
+
+   Consider the following as an example of this rotation operation:
+   Assume that the RRC value is 3 and the token before the rotation is
+   {"header" | aa | bb | cc | dd | ee | ff | gg | hh}.  The token after
+
+
+
+Zhu, et al.                 Standards Track                    [Page 11]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee
+   }, where {aa | bb | cc |...| hh} would be used to indicate the octet
+   sequence.
+
+   The RRC field is expressed as a two-octet integer in big-endian
+   order.
+
+   The rotation count value is chosen by the sender based on
+   implementation details.  The receiver MUST be able to interpret all
+   possible rotation count values, including rotation counts greater
+   than the length of the token.
+
+4.2.6.  Message Layouts
+
+   Per-message tokens start with a two-octet token identifier (TOK_ID)
+   field, expressed in big-endian order.  These tokens are defined
+   separately in the following sub-sections.
+
+4.2.6.1.  MIC Tokens
+
+   Use of the GSS_GetMIC() call yields a token (referred as the MIC
+   token in this document), separate from the user data being protected,
+   which can be used to verify the integrity of that data as received.
+   The token has the following format:
+
+         Octet no   Name        Description
+         --------------------------------------------------------------
+         0..1     TOK_ID     Identification field.  Tokens emitted by
+                             GSS_GetMIC() contain the hex value 04 04
+                             expressed in big-endian order in this
+                             field.
+         2        Flags      Attributes field, as described in section
+                             4.2.2.
+         3..7     Filler     Contains five octets of hex value FF.
+         8..15    SND_SEQ    Sequence number field in clear text,
+                             expressed in big-endian order.
+         16..last SGN_CKSUM  Checksum of the "to-be-signed" data and
+                             octet 0..15, as described in section 4.2.4.
+
+   The Filler field is included in the checksum calculation for
+   simplicity.
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 12]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+4.2.6.2.  Wrap Tokens
+
+   Use of the GSS_Wrap() call yields a token (referred as the Wrap token
+   in this document), which consists of a descriptive header, followed
+   by a body portion that contains either the input user data in
+   plaintext concatenated with the checksum, or the input user data
+   encrypted.  The GSS_Wrap() token SHALL have the following format:
+
+         Octet no   Name        Description
+         --------------------------------------------------------------
+          0..1     TOK_ID    Identification field.  Tokens emitted by
+                             GSS_Wrap() contain the hex value 05 04
+                             expressed in big-endian order in this
+                             field.
+          2        Flags     Attributes field, as described in section
+                             4.2.2.
+          3        Filler    Contains the hex value FF.
+          4..5     EC        Contains the "extra count" field, in big-
+                             endian order as described in section 4.2.3.
+          6..7     RRC       Contains the "right rotation count" in big-
+                             endian order, as described in section
+                             4.2.5.
+          8..15    SND_SEQ   Sequence number field in clear text,
+                             expressed in big-endian order.
+          16..last Data      Encrypted data for Wrap tokens with
+                             confidentiality, or plaintext data followed
+                             by the checksum for Wrap tokens without
+                             confidentiality, as described in section
+                             4.2.4.
+
+4.3.  Context Deletion Tokens
+
+   Context deletion tokens are empty in this mechanism.  Both peers to a
+   security context invoke GSS_Delete_sec_context() [RFC2743]
+   independently, passing a null output_context_token buffer to indicate
+   that no context_token is required.  Implementations of
+   GSS_Delete_sec_context() should delete relevant locally-stored
+   context information.
+
+4.4.  Token Identifier Assignment Considerations
+
+   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive
+   are reserved and SHALL NOT be assigned.  Thus, by examining the first
+   two octets of a token, one can tell unambiguously if it is wrapped
+   with the generic GSS-API token framing.
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 13]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+5.  Parameter Definitions
+
+   This section defines parameter values used by the Kerberos V5 GSS-API
+   mechanism.  It defines interface elements that support portability,
+   and assumes use of C language bindings per [RFC2744].
+
+5.1.  Minor Status Codes
+
+   This section recommends common symbolic names for minor_status values
+   to be returned by the Kerberos V5 GSS-API mechanism.  Use of these
+   definitions will enable independent implementers 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 that a particular GSS-API implementation uses to represent the
+   minor_status values specified in this section.
+
+   This list may grow over time and the need for additional minor_status
+   codes, specific to particular implementations, may arise.  However,
+   it is recommended that implementations should return a minor_status
+   value as defined on a mechanism-wide basis within this section when
+   that code accurately represents reportable status rather than using a
+   separate, implementation-defined code.
+
+5.1.1.  Non-Kerberos-specific Codes
+
+         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" */
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 14]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+5.1.2.  Kerberos-specific Codes
+
+         GSS_KRB5_S_KG_CCACHE_NOMATCH
+                 /* "Client principal in credentials does not match
+                    specified name" */
+         GSS_KRB5_S_KG_KEYTAB_NOMATCH
+                 /* "No key available for specified service
+                    principal" */
+         GSS_KRB5_S_KG_TGT_MISSING
+                 /* "No Kerberos ticket-granting ticket available" */
+         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" */
+
+5.2.  Buffer Sizes
+
+   All implementations of this specification MUST be capable of
+   accepting buffers of at least 16K octets as input to GSS_GetMIC(),
+   GSS_VerifyMIC(), and GSS_Wrap().  They MUST also be capable of
+   accepting the output_token generated by GSS_Wrap() for a 16K octet
+   input buffer as input to GSS_Unwrap().  Implementations SHOULD
+   support 64K octet input buffers, and MAY support even larger input
+   buffer sizes.
+
+6.  Backwards Compatibility Considerations
+
+   The new token formats defined in this document will only be
+   recognized by new implementations.  To address this, implementations
+   can always use the explicit sign or seal algorithm in [RFC1964] when
+   the key type corresponds to not "newer" enctypes.  As an alternative,
+   one might retry sending the message with the sign or seal algorithm
+   explicitly defined as in [RFC1964].  However, this would require
+   either the use of a mechanism such as [RFC2478] to securely negotiate
+   the method, or the use of an out-of-band mechanism to choose the
+   appropriate mechanism.  For this reason, it is RECOMMENDED that the
+   new token formats defined in this document SHOULD be used only if
+   both peers are known to support the new mechanism during context
+   negotiation because of, for example, the use of "new" enctypes.
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 15]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+   GSS_Unwrap() or GSS_VerifyMIC() can process a message token as
+   follows: it can look at the first octet of the token header, and if
+   it is 0x60, then the token must carry the generic GSS-API pseudo
+   ASN.1 framing.  Otherwise, the first two octets of the token contain
+   the TOK_ID that uniquely identify the token message format.
+
+7.  Security Considerations
+
+   Channel bindings are validated by the acceptor.  The acceptor can
+   ignore the channel bindings restriction supplied by the initiator and
+   carried in the authenticator checksum, if (1) channel bindings are
+   not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor
+   does not prove to the initiator that it has the same channel bindings
+   as the initiator (even if the client requested mutual
+   authentication).  This limitation should be considered by designers
+   of applications that would use channel bindings, whether to limit the
+   use of GSS-API contexts to nodes with specific network addresses, to
+   authenticate other established, secure channels using Kerberos
+   Version 5, or for any other purpose.
+
+   Session key types are selected by the KDC.  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,
+   administrators can control what enctypes can be used for session keys
+   for this mechanism by controlling the set of the ticket session key
+   enctypes which the KDC is willing to use in tickets for a given
+   acceptor principal.  Therefore, the KDC could be given the task of
+   limiting session keys for a given service to types actually supported
+   by the Kerberos and GSSAPI software on the server.  This has a
+   drawback for cases in which a service principal name is used for both
+   GSSAPI-based and non-GSSAPI-based communication (most notably the
+   "host" service key), if the GSSAPI implementation does not understand
+   (for example) AES [RFC3962], but the Kerberos implementation does.
+   This means that AES session keys cannot be issued for that service
+   principal, which keeps the protection of non-GSSAPI services weaker
+   than necessary.  KDC administrators desiring to limit the session key
+   types to support interoperability with such GSSAPI implementations
+   should carefully weigh the reduction in protection offered by such
+   mechanisms against the benefits of interoperability.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 16]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+8.  Acknowledgements
+
+   Ken Raeburn and Nicolas Williams corrected many of our errors in the
+   use of generic profiles and were instrumental in the creation of this
+   document.
+
+   The text for security considerations was contributed by Nicolas
+   Williams and Ken Raeburn.
+
+   Sam Hartman and Ken Raeburn suggested the "floating trailer" idea,
+   namely the encoding of the RRC field.
+
+   Sam Hartman and Nicolas Williams recommended the replacing our
+   earlier key derivation function for directional keys with different
+   key usage numbers for each direction as well as retaining the
+   directional bit for maximum compatibility.
+
+   Paul Leach provided numerous suggestions and comments.
+
+   Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon
+   Josefsson also provided valuable inputs on this document.
+
+   Jeffrey Hutzelman provided comments and clarifications for the text
+   related to the channel bindings.
+
+   Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
+
+   Luke Howard provided implementations of this document for the Heimdal
+   code base, and helped inter-operability testing with the Microsoft
+   code base, together with Love Hornquist Astrand.  These experiments
+   formed the basis of this document.
+
+   Martin Rex provided suggestions of TOK_ID assignment recommendations,
+   thus the token tagging in this document is unambiguous if the token
+   is wrapped with the pseudo ASN.1 header.
+
+   John Linn wrote the original Kerberos Version 5 mechanism
+   specification [RFC1964], of which some text has been retained.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 17]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2:
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+9.2.  Informative References
+
+   [SSPI]     Leach, P., "Security Service Provider Interface",
+              Microsoft Developer Network (MSDN), April 2003.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+              Negotiation Mechanism", RFC 2478, December 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 18]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+Authors' Addresses
+
+   Larry Zhu
+   One Microsoft Way
+   Redmond, WA 98052 - USA
+
+   EMail: LZhu@microsoft.com
+
+
+   Karthik Jaganathan
+   One Microsoft Way
+   Redmond, WA 98052 - USA
+
+   EMail: karthikj@microsoft.com
+
+
+   Sam Hartman
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139 - USA
+
+   EMail: hartmans-ietf@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 19]
+
+RFC 4121               Kerberos Version 5 GSS-API              July 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 20]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4178.txt b/third_party/heimdal/doc/standardisation/rfc4178.txt
new file mode 100644
index 00000000000..5c71d9ed81c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4178.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                             L. Zhu
+Request for Comments: 4178                                      P. Leach
+Obsoletes: 2478                                            K. Jaganathan
+Category: Standards Track                          Microsoft Corporation
+                                                            W. Ingersoll
+                                                        Sun Microsystems
+                                                            October 2005
+
+
+                       The Simple and Protected
+    Generic Security Service Application Program Interface (GSS-API)
+                         Negotiation Mechanism
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+
+Abstract
+
+   This document specifies a negotiation mechanism for the Generic
+   Security Service Application Program Interface (GSS-API), which is
+   described in RFC 2743.  GSS-API peers can use this negotiation
+   mechanism to choose from a common set of security mechanisms.  If
+   per-message integrity services are available on the established
+   mechanism context, then the negotiation is protected against an
+   attacker that forces the selection of a mechanism not desired by the
+   peers.
+
+   This mechanism replaces RFC 2478 in order to fix defects in that
+   specification and to describe how to inter-operate with
+   implementations of that specification that are commonly deployed on
+   the Internet.
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 1]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. Negotiation Protocol ............................................3
+      3.1. Negotiation Description ....................................4
+      3.2. Negotiation Procedure ......................................5
+   4. Token Definitions ...............................................7
+      4.1. Mechanism Types ............................................7
+      4.2. Negotiation Tokens .........................................7
+           4.2.1. negTokenInit ........................................8
+           4.2.2. negTokenResp ........................................9
+   5. Processing of mechListMIC ......................................10
+   6. Extensibility ..................................................13
+   7. Security Considerations ........................................13
+   8. Acknowledgments ................................................14
+   9. References .....................................................14
+      9.1. Normative References ......................................14
+      9.2. Informative References ....................................15
+   Appendix A.  SPNEGO ASN.1 Module ..................................16
+   Appendix B.  GSS-API Negotiation Support API ......................17
+      B.1.  GSS_Set_neg_mechs Call ...................................17
+      B.2.  GSS_Get_neg_mechs Call ...................................18
+   Appendix C.  Changes since RFC 2478 ...............................18
+   Appendix D.  mechListMIC Computation Example ......................20
+
+1.  Introduction
+
+   The GSS-API [RFC2743] provides a generic interface that can be
+   layered atop different security mechanisms such that, if
+   communicating peers acquire GSS-API credentials for the same security
+   mechanism, then a security context may be established between them
+   (subject to policy).  However, GSS-API does not prescribe the method
+   by which GSS-API peers can establish whether they have a common
+   security mechanism.
+
+   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
+   defined here is a pseudo security mechanism that enables GSS-API
+   peers to determine in-band whether their credentials support a common
+   set of one or more GSS-API security mechanisms; if so, it invokes the
+   normal security context establishment for a selected common security
+   mechanism.  This is most useful for applications that depend on GSS-
+   API implementations and share multiple mechanisms between the peers.
+
+   The SPNEGO mechanism negotiation is based on the following model: the
+   initiator proposes a list of security mechanism(s), in decreasing
+   preference order (favorite choice first), the acceptor (also known as
+   the target) either accepts the initiator's preferred security
+
+
+
+Zhu, et al.                 Standards Track                     [Page 2]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   mechanism (the first in the list) or chooses one of the available
+   mechanisms from the offered list; if neither is acceptable, the
+   acceptor rejects the proposed value(s).  The target then informs the
+   initiator of its choice.
+
+   Once a common security mechanism is chosen, mechanism-specific
+   options MAY be negotiated as part of the selected mechanism's context
+   establishment.  These negotiations (if any) are internal to the
+   mechanism and opaque to the SPNEGO protocol.  As such, they are
+   outside the scope of this document.
+
+   If per-message integrity services [RFC2743] are available on the
+   established mechanism security context, then the negotiation is
+   protected to ensure that the mechanism list has not been modified.
+   In cases where an attacker could have materially influenced the
+   negotiation, peers exchange message integrity code (MIC) tokens to
+   confirm that the mechanism list has not been modified.  If no action
+   of an attacker could have materially modified the outcome of the
+   negotiation, the exchange of MIC tokens is optional (see Section 5).
+   Allowing MIC tokens to be optional in this case provides
+   interoperability with existing implementations while still protecting
+   the negotiation.  This interoperability comes at the cost of
+   increased complexity.
+
+   SPNEGO relies on the concepts developed in the GSS-API specification
+   [RFC2743].  The negotiation data is encapsulated in context-level
+   tokens.  Therefore, callers of the GSS-API do not need to be aware of
+   the existence of the negotiation tokens, but only of the new pseudo-
+   security mechanism.  A failure in the negotiation phase causes a
+   major status code to be returned: GSS_S_BAD_MECH.
+
+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 [RFC2119].
+
+3.  Negotiation Protocol
+
+   When the established mechanism context provides integrity protection,
+   the mechanism negotiation can be protected.  When acquiring
+   negotiated security mechanism tokens, per-message integrity services
+   are always requested by the SPNEGO mechanism.
+
+   When the established mechanism context supports per-message integrity
+   services, SPNEGO guarantees that the selected mechanism is mutually
+   preferred.
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 3]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   This section describes the negotiation process of this protocol.
+
+3.1.  Negotiation Description
+
+   The first negotiation token sent by the initiator contains an ordered
+   list of mechanisms in decreasing preference order (favorite mechanism
+   first), and optionally the initial mechanism token for the preferred
+   mechanism of the initiator (i.e., the first in the list).  (Note that
+   the list MUST NOT contain this SPNEGO mechanism itself or any
+   mechanism for which the client does not have appropriate
+   credentials.)
+
+   The target then processes the token from the initiator.  This will
+   result in one of four possible states (as defined in Section 4.2.2)
+   being returned in the reply message: accept-completed, accept-
+   incomplete, reject, or request-mic.  A reject state will terminate
+   the negotiation; an accept-completed state indicates that the
+   initiator-selected mechanism was acceptable to the target, and that
+   the security mechanism token embedded in the first negotiation
+   message was sufficient to complete the authentication; an accept-
+   incomplete state indicates that further message exchange is needed
+   but the MIC token exchange (as described in Section 5) is OPTIONAL; a
+   request-mic state (this state can only be present in the first reply
+   message from the target) indicates that the MIC token exchange is
+   REQUIRED if per-message integrity services are available.
+
+   Unless the preference order is specified by the application, the
+   policy by which the target chooses a mechanism is an implementation-
+   specific, local matter.  In the absence of an application-specified
+   preference order or other policy, the target SHALL choose the first
+   mechanism in the initiator proposed list for which it has valid
+   credentials.
+
+   In case of a successful negotiation, the security mechanism in the
+   first reply message represents the value suitable for the target that
+   was chosen from the list offered by the initiator.
+
+   In case of an unsuccessful negotiation, the reject state is returned,
+   and the generation of a context-level negotiation token is OPTIONAL.
+
+   Once a mechanism has been selected, context establishment tokens
+   specific to the selected mechanism are carried within the negotiation
+   tokens.
+
+   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
+   mechanism list received by the target.
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 4]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   To avoid conflicts with the use of MIC tokens by SPNEGO, partially-
+   established contexts MUST NOT be used for per-message calls.  To
+   guarantee this, the prot_ready_state [RFC2743] MUST be set to false
+   on return from GSS_Init_sec_context() and GSS_Accept_sec_context(),
+   even if the underlying mechanism returned true.
+
+   Note that in order to avoid an extra round trip, the first context
+   establishment token of the initiator's preferred mechanism SHOULD be
+   embedded in the initial negotiation message (as defined in Section
+   4.2).  (This mechanism token is referred to as the optimistic
+   mechanism token in this document.)  In addition, using the optimistic
+   mechanism token allows the initiator to recover from non-fatal errors
+   encountered when trying to produce the first mechanism token before a
+   mechanism can be selected.  In cases where the initiator's preferred
+   mechanism is not likely to be selected by the acceptor because of the
+   significant cost of its generation, implementations MAY omit the
+   optimistic mechanism token.
+
+3.2.  Negotiation Procedure
+
+   The basic form of the procedure assumes that per-message integrity
+   services are available on the established mechanism context, and it
+   is summarized as follows:
+
+   a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
+      but requests that SPNEGO be used.  SPNEGO can either be explicitly
+      requested or accepted as the default mechanism.
+
+   b) The initiator GSS-API implementation generates a negotiation token
+      containing a list of one or more security mechanisms that are
+      available based on the credentials used for this context
+      establishment, and optionally on the initial mechanism token for
+      the first mechanism in the list.
+
+   c) The GSS-API initiator application sends the token to the target
+      application.  The GSS-API target application passes the token by
+      invoking GSS_Accept_sec_context().  The acceptor will do one of
+      the following:
+
+        I) If none of the proposed mechanisms are acceptable, the
+           negotiation SHALL be terminated.  GSS_Accept_sec_context
+           indicates GSS_S_BAD_MECH.  The acceptor MAY output a
+           negotiation token containing a reject state.
+
+       II) If either the initiator's preferred mechanism is not accepted
+           by the target or this mechanism is accepted but is not the
+           acceptor's most preferred mechanism (i.e., the MIC token
+           exchange as described in Section 5 is required),
+
+
+
+Zhu, et al.                 Standards Track                     [Page 5]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+           GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
+           The acceptor MUST output a negotiation token containing a
+           request-mic state.
+
+      III) Otherwise, if at least one additional negotiation token from
+           the initiator is needed to establish this context,
+           GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
+           outputs a negotiation token containing an accept-incomplete
+           state.
+
+       IV) Otherwise, no additional negotiation token from the initiator
+           is needed to establish this context, GSS_Accept_sec_context()
+           indicates GSS_S_COMPLETE and outputs a negotiation token
+           containing an accept_complete state.
+
+      If the initiator's preferred mechanism is accepted, and an
+      optimistic mechanism token was included, this mechanism token MUST
+      be passed to the selected mechanism by invoking
+      GSS_Accept_sec_context().  If a response mechanism token is
+      returned, it MUST be included in the response negotiation token.
+      Otherwise, the target will not generate a response mechanism token
+      in the first reply.
+
+   d) The GSS-API target application returns the negotiation token to
+      the initiator application.  The GSS-API initiator application
+      passes the token by invoking GSS_Init_sec_context().  The security
+      context initialization is then continued according to the standard
+      GSS-API conventions for the selected mechanism, where the tokens
+      of the selected mechanism are encapsulated in negotiation messages
+      (see Section 4) until GSS_S_COMPLETE is returned for both the
+      initiator and the target by the selected security mechanism.
+
+   e) MIC tokens are then either skipped or exchanged according to
+      Section 5.
+
+   Note that the *_req_flag input parameters for context establishment
+   are relative to the selected mechanism, as are the *_state output
+   parameters.  That is, these parameters are not applicable to the
+   negotiation process per se.
+
+   On receipt of a negotiation token on the target side, a GSS-API
+   implementation that does not support negotiation would indicate the
+   GSS_S_BAD_MECH status as though a particular basic security mechanism
+   had been requested and was not supported.
+
+   When a GSS-API credential is acquired for the SPNEGO mechanism, the
+   implementation SHOULD produce a credential element for the SPNEGO
+   mechanism that internally contains GSS-API credential elements for
+
+
+
+Zhu, et al.                 Standards Track                     [Page 6]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   all mechanisms for which the principal has credentials available,
+   except for any mechanisms that are not to be negotiated, per
+   implementation-, site-, or application-specific policy.  See Appendix
+   B for interfaces for expressing application policy.
+
+4.  Token Definitions
+
+   The type definitions in this section assume an ASN.1 module
+   definition of the following form:
+
+      SPNEGOASNOneSpec {
+         iso(1) identified-organization(3) dod(6) internet(1)
+         security(5) mechanism(5) snego (2) modules(4) spec2(2)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      -- rest of definitions here
+
+      END
+
+   This specifies that the tagging context for the module will be
+   explicit and non-automatic.
+
+   The encoding of the SPNEGO protocol messages shall obey the
+   Distinguished Encoding Rules (DER) of ASN.1, as described in [X690].
+
+4.1.  Mechanism Types
+
+   In this negotiation model, each OID represents one GSS-API mechanism
+   or one variant (see Section 6) of it, according to [RFC2743].
+
+      MechType ::= OBJECT IDENTIFIER
+          -- OID represents each security mechanism as suggested by
+          -- [RFC2743]
+
+      MechTypeList ::= SEQUENCE OF MechType
+
+4.2.  Negotiation Tokens
+
+   The syntax of the initial negotiation tokens follows the
+   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
+   SPNEGO pseudo mechanism is identified by the Object Identifier
+   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
+   Subsequent tokens MUST NOT be encapsulated in this GSS-API generic
+   token framing.
+
+   This section specifies the syntax of the inner token for the initial
+   message and the syntax of subsequent context establishment tokens.
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 7]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+      NegotiationToken ::= CHOICE {
+          negTokenInit    [0] NegTokenInit,
+          negTokenResp    [1] NegTokenResp
+      }
+
+4.2.1.  negTokenInit
+
+      NegTokenInit ::= SEQUENCE {
+          mechTypes       [0] MechTypeList,
+          reqFlags        [1] ContextFlags  OPTIONAL,
+            -- inherited from RFC 2478 for backward compatibility,
+            -- RECOMMENDED to be left out
+          mechToken       [2] OCTET STRING  OPTIONAL,
+          mechListMIC     [3] OCTET STRING  OPTIONAL,
+          ...
+      }
+      ContextFlags ::= BIT STRING {
+          delegFlag       (0),
+          mutualFlag      (1),
+          replayFlag      (2),
+          sequenceFlag    (3),
+          anonFlag        (4),
+          confFlag        (5),
+          integFlag       (6)
+      } (SIZE (32))
+
+   This is the syntax for the inner token of the initial negotiation
+   message.
+
+   mechTypes
+
+      This field contains one or more security mechanisms available for
+      the initiator, in decreasing preference order (favorite choice
+      first).
+
+   reqFlags
+
+      This field, if present, contains the service options that are
+      requested to establish the context (the req_flags parameter of
+      GSS_Init_sec_context()).  This field is inherited from RFC 2478
+      and is not integrity protected.  For implementations of this
+      specification, the initiator SHOULD omit this reqFlags field and
+      the acceptor MUST ignore this reqFlags field.
+
+      The size constraint on the ContextFlags ASN.1 type only applies to
+      the abstract type.  The ASN.1 DER requires that all trailing zero
+      bits be truncated from the encoding of a bit string type whose
+      abstract definition includes named bits.  Implementations should
+
+
+
+Zhu, et al.                 Standards Track                     [Page 8]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+      not expect to receive exactly 32 bits in an encoding of
+      ContextFlags.
+
+   mechToken
+
+      This field, if present, contains the optimistic mechanism token.
+
+   mechlistMIC
+
+      This field, if present, contains an MIC token for the mechanism
+      list in the initial negotiation message.  This MIC token is
+      computed according to Section 5.
+
+4.2.2.  negTokenResp
+
+      NegTokenResp ::= SEQUENCE {
+          negState       [0] ENUMERATED {
+              accept-completed    (0),
+              accept-incomplete   (1),
+              reject              (2),
+              request-mic         (3)
+          }                                 OPTIONAL,
+            -- REQUIRED in the first reply from the target
+          supportedMech   [1] MechType      OPTIONAL,
+            -- present only in the first reply from the target
+          responseToken   [2] OCTET STRING  OPTIONAL,
+          mechListMIC     [3] OCTET STRING  OPTIONAL,
+          ...
+      }
+
+   This is the syntax for all subsequent negotiation messages.
+
+   negState
+
+      This field, if present, contains the state of the negotiation.
+      This can be:
+
+      accept-completed
+
+         No further negotiation message from the peer is expected, and
+         the security context is established for the sender.
+
+      accept-incomplete
+
+         At least one additional negotiation message from the peer is
+         needed to establish the security context.
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 9]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+      reject
+
+         The sender terminates the negotiation.
+
+      request-mic
+
+         The sender indicates that the exchange of MIC tokens, as
+         described in Section 5, will be REQUIRED if per-message
+         integrity services are available on the mechanism context to be
+         established.  This value SHALL only be present in the first
+         reply from the target.
+
+      This field is REQUIRED in the first reply from the target, and is
+      OPTIONAL thereafter.  When negState is absent, the actual state
+      should be inferred from the state of the negotiated mechanism
+      context.
+
+   supportedMech
+
+      This field SHALL only be present in the first reply from the
+      target.  It MUST be one of the mechanism(s) offered by the
+      initiator.
+
+   ResponseToken
+
+      This field, if present, contains tokens specific to the mechanism
+      selected.
+
+   mechlistMIC
+
+      This field, if present, contains an MIC token for the mechanism
+      list in the initial negotiation message.  This MIC token is
+      computed according to Section 5.
+
+5.  Processing of mechListMIC
+
+   If the mechanism selected by the negotiation does not support
+   integrity protection, then no mechlistMIC token is used.
+
+   Otherwise, if the accepted mechanism is the most preferred mechanism
+   of both the initiator and the acceptor, then the MIC token exchange,
+   as described later in this section, is OPTIONAL.  A mechanism is the
+   acceptor's most preferred mechanism if there is no other mechanism
+   that the acceptor would have preferred over the accepted mechanism
+   had it been present in the mechanism list.
+
+   In all other cases, MIC tokens MUST be exchanged after the mechanism
+   context is fully established.
+
+
+
+Zhu, et al.                 Standards Track                    [Page 10]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   a) The mechlistMIC token (or simply the MIC token) is computed over
+      the mechanism list in the initial negotiation message by invoking
+      GSS_GetMIC() as follows: the input context_handle is the
+      established mechanism context, the input qop_req is 0, and the
+      input message is the DER encoding of the value of type
+      MechTypeList, which is contained in the "mechTypes" field of the
+      NegTokenInit.  The input message is NOT the DER encoding of the
+      type "[0] MechTypeList".
+
+   b) If the selected mechanism exchanges an even number of mechanism
+      tokens (i.e., the acceptor sends the last mechanism token), the
+      acceptor does the following when generating the negotiation
+      message containing the last mechanism token: if the MIC token
+      exchange is optional, GSS_Accept_sec_context() either indicates
+      GSS_S_COMPLETE and does not include a mechlistMIC token, or
+      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
+      and an accept-incomplete state; if the MIC token exchange is
+      required, GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED
+      and includes a mechlistMIC token.  Acceptors that wish to be
+      compatible with legacy Windows SPNEGO implementations, as
+      described in Appendix C, should not generate a mechlistMIC token
+      when the MIC token exchange is not required.  The initiator then
+      processes the last mechanism token, and does one of the following:
+
+        I) If a mechlistMIC token was included and is correctly
+           verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.
+           The output negotiation message contains a mechlistMIC token
+           and an accept_complete state.  The acceptor MUST then verify
+           this mechlistMIC token.
+
+       II) If a mechlistMIC token was included but is incorrect, the
+           negotiation SHALL be terminated.  GSS_Init_sec_context()
+           indicates GSS_S_DEFECTIVE_TOKEN.
+
+      III) If no mechlistMIC token was included and the MIC token
+           exchange is not required, GSS_Init_sec_context() indicates
+           GSS_S_COMPLETE with no output token.
+
+       IV) If no mechlistMIC token was included but the MIC token
+           exchange is required, the negotiation SHALL be terminated.
+           GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+   c) In the case that the chosen mechanism exchanges an odd number of
+      mechanism tokens (i.e., the initiator sends the last mechanism
+      token), the initiator does the following when generating the
+      negotiation message containing the last mechanism token: if the
+      negState was request-mic in the first reply from the target, a
+      mechlistMIC token MUST be included; otherwise, the mechlistMIC
+
+
+
+Zhu, et al.                 Standards Track                    [Page 11]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+      token is OPTIONAL.  (Note that the MIC token exchange is required
+      if a mechanism other than the initiator's first choice is chosen.)
+      In the case that the optimistic mechanism token is the only
+      mechanism token for the initiator's preferred mechanism, the
+      mechlistMIC token is OPTIONAL.  Whether the mechlistMIC token is
+      included, GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
+      Initiators that wish to be compatible with legacy Windows SPNEGO
+      implementations, as described in Appendix C, should not generate a
+      mechlistMIC token when the MIC token exchange is not required.
+      The acceptor then processes the last mechanism token and does one
+      of the following:
+
+        I) If a mechlistMIC token was included and is correctly
+           verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
+           The output negotiation message contains a mechlistMIC token
+           and an accept_complete state.  The initiator MUST then verify
+           this mechlistMIC token.
+
+       II) If a mechlistMIC token was included but is incorrect, the
+           negotiation SHALL be terminated.  GSS_Accept_sec_context()
+           indicates GSS_S_DEFECTIVE_TOKEN.
+
+      III) If no mechlistMIC token was included and the mechlistMIC
+           token exchange is not required, GSS_Accept_sec_context()
+           indicates GSS_S_COMPLETE.  The output negotiation message
+           contains an accept_complete state.
+
+       IV) In the case that the optimistic mechanism token is also the
+           last mechanism token (when the initiator's preferred
+           mechanism is accepted by the target) and the target sends a
+           request-mic state but the initiator did not send a
+           mechlistMIC token, the target then MUST include a mechlistMIC
+           token in that first reply.  GSS_Accept_sec_context()
+           indicates GSS_S_CONTINUE_NEEDED.  The initiator MUST verify
+           the received mechlistMIC token and generate a mechlistMIC
+           token to send back to the target.  The target SHALL, in turn,
+           verify the returned mechlistMIC token and complete the
+           negotiation.
+
+        V) If no mechlistMIC token was included and the acceptor sent a
+           request-mic state in the first reply message (the exchange of
+           MIC tokens is required), the negotiation SHALL be terminated.
+           GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 12]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+6.  Extensibility
+
+   Two mechanisms are provided for extensibility.  First, the ASN.1
+   structures in this specification MAY be expanded by IETF standards
+   action.  Implementations receiving unknown fields MUST ignore these
+   fields.
+
+   Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
+   mechanism variants) may be included in the set of preferred
+   mechanisms by an initiator.  The acceptor can choose to honor this
+   request by preferring mechanisms that have the included attributes.
+   Future work within the Kitten working group is expected to
+   standardize common attributes that SPNEGO mechanisms may wish to
+   support.  At this time, it is sufficient to say that initiators MAY
+   include OIDs that do not correspond to mechanisms.  Such OIDs MAY
+   influence the acceptor's choice of mechanism.  As discussed in
+   Section 5, if there are mechanisms that, if present in the
+   initiator's list of mechanisms, might be preferred by the acceptor
+   instead of the initiator's preferred mechanism, the acceptor MUST
+   demand the MIC token exchange.  As the consequence, acceptors MUST
+   demand the MIC token exchange if they support negotiation of
+   attributes not available in the initiator's preferred mechanism,
+   regardless of whether the initiator actually requested these
+   attributes.
+
+7.  Security Considerations
+
+   In order to produce the MIC token for the mechanism list, the
+   mechanism must provide integrity protection.  When the selected
+   mechanism does not support integrity protection, the negotiation is
+   vulnerable: an active attacker can force it to use a security
+   mechanism that is not mutually preferred but is acceptable to the
+   target.
+
+   This protocol provides the following guarantees when per-message
+   integrity services are available on the established mechanism
+   context, and the mechanism list was altered by an adversary such that
+   a mechanism that is not mutually preferred could be selected:
+
+   a) If the last mechanism token is sent by the initiator, both peers
+      shall fail;
+
+   b) If the last mechanism token is sent by the acceptor, the acceptor
+      shall not complete and the initiator, at worst, shall complete
+      with its preferred mechanism being selected.
+
+   The negotiation may not be terminated if an alteration was made but
+   had no material impact.
+
+
+
+Zhu, et al.                 Standards Track                    [Page 13]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   The protection of the negotiation depends on the strength of the
+   integrity protection.  In particular, the strength of SPNEGO is no
+   stronger than the integrity protection of the weakest mechanism
+   acceptable to GSS-API peers.
+
+   Note that where there exist multiple mechanisms with similar context
+   tokens, but different semantics, such that some or all of the
+   mechanisms' context tokens can be easily altered so that one
+   mechanism's context tokens may pass for another of the similar
+   mechanism's context tokens, then there may exist a downgrade or
+   similar attacks.  For example, if a given family of mechanisms uses
+   the same context token syntax for two or more variants and depends on
+   the OID in the initial token's pseudo-ASN.1/DER wrapper, but does not
+   provide integrity protection for that OID, then there may exist an
+   attack against those mechanisms.  SPNEGO does not generally defeat
+   such attacks.
+
+   In all cases, the communicating peers are exposed to the denial of
+   service threat.
+
+8.  Acknowledgments
+
+   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
+   Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero, and Bill
+   Sommerfeld for their comments and suggestions during the development
+   of this document.
+
+   Luke Howard provided a prototype of this protocol in Heimdal and
+   resolved several issues in the initial version of this document.
+
+   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
+   [RFC2478] of which some of the text has been retained in this
+   document.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743] Linn, J., "Generic Security Service Application Program
+             Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [X690]    ASN.1 encoding rules: Specification of Basic Encoding Rules
+             (BER), Canonical Encoding Rules (CER) and Distinguished
+             Encoding Rules (DER), ITU-T Recommendation X.690 (1997) |
+             ISO/IEC International Standard 8825-1:1998.
+
+
+
+Zhu, et al.                 Standards Track                    [Page 14]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+9.2.  Informative References
+
+   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+             Negotiation Mechanism", RFC 2478, December 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 15]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+Appendix A.  SPNEGO ASN.1 Module
+
+   SPNEGOASNOneSpec {
+      iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanism(5) snego (2) modules(4) spec2(2)
+   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   MechType ::= OBJECT IDENTIFIER
+       -- OID represents each security mechanism as suggested by
+       -- [RFC2743]
+
+   MechTypeList ::= SEQUENCE OF MechType
+
+   NegotiationToken ::= CHOICE {
+       negTokenInit    [0] NegTokenInit,
+       negTokenResp    [1] NegTokenResp
+   }
+
+   NegTokenInit ::= SEQUENCE {
+       mechTypes       [0] MechTypeList,
+       reqFlags        [1] ContextFlags  OPTIONAL,
+         -- inherited from RFC 2478 for backward compatibility,
+         -- RECOMMENDED to be left out
+       mechToken       [2] OCTET STRING  OPTIONAL,
+       mechListMIC     [3] OCTET STRING  OPTIONAL,
+       ...
+   }
+   NegTokenResp ::= SEQUENCE {
+       negState       [0] ENUMERATED {
+           accept-completed    (0),
+           accept-incomplete   (1),
+           reject              (2),
+           request-mic         (3)
+       }                                 OPTIONAL,
+         -- REQUIRED in the first reply from the target
+       supportedMech   [1] MechType      OPTIONAL,
+         -- present only in the first reply from the target
+       responseToken   [2] OCTET STRING  OPTIONAL,
+       mechListMIC     [3] OCTET STRING  OPTIONAL,
+       ...
+   }
+
+   ContextFlags ::= BIT STRING {
+       delegFlag       (0),
+       mutualFlag      (1),
+       replayFlag      (2),
+       sequenceFlag    (3),
+       anonFlag        (4),
+
+
+
+Zhu, et al.                 Standards Track                    [Page 16]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+       confFlag        (5),
+       integFlag       (6)
+   } (SIZE (32))
+
+   END
+
+Appendix B.  GSS-API Negotiation Support API
+
+   In order to provide to a GSS-API caller (the initiator or the target
+   or both) with the ability to choose among the set of supported
+   mechanisms, a reduced set of mechanisms for negotiation and two
+   additional APIs are defined:
+
+   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
+      available on the local system to the caller for negotiation, for
+      which appropriate credentials are available.
+
+   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
+      used on the local system by the caller for negotiation, for the
+      given credentials.
+
+B.1.  GSS_Set_neg_mechs Call
+
+   Inputs:
+
+   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
+       -- credentials
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been set to mech_set.
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   This allows callers to specify the set of security mechanisms that
+   may be negotiated with the credential identified by cred_handle.
+   This call is intended to support specialized callers who need to
+   restrict the set of negotiable security mechanisms from the set of
+   all security mechanisms available to the caller (based on available
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 17]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   credentials).  Note that if more than one mechanism is specified in
+   mech_set, the order in which those mechanisms are specified implies a
+   relative preference.
+
+B.2.  GSS_Get_neg_mechs Call
+
+   Input:
+
+   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default --
+      credentials
+
+   Outputs:
+
+   o  major_status INTEGER,
+   o  minor_status INTEGER,
+   o  mech_set SET OF OBJECT IDENTIFIER
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the set of security mechanisms
+      available for negotiation has been returned in mech_set.
+
+   o  GSS_S_FAILURE indicates that the requested operation could not be
+      performed for reasons unspecified at the GSS-API level.
+
+   This allows callers to determine the set of security mechanisms
+   available for negotiation with the credential identified by
+   cred_handle.  This call is intended to support specialized callers
+   who need to reduce the set of negotiable security mechanisms from the
+   set of supported security mechanisms available to the caller (based
+   on available credentials).
+
+   Note: The GSS_Indicate_mechs() function indicates the full set of
+   mechanism types available on the local system.  Since this call has
+   no input parameter, the returned set is not necessarily available for
+   all credentials.
+
+Appendix C.  Changes since RFC 2478
+
+   SPNEGO implementations in Microsoft Windows 2000/Windows XP/Windows
+   Server 2003 have the following behavior: no mechlistMIC is produced
+   and mechlistMIC is not processed if one is provided; if the initiator
+   sends the last mechanism token, the acceptor will send back a
+   negotiation token with an accept_complete state and no mechlistMIC
+   token.  In addition, an incorrect OID (1.2.840.48018.1.2.2) can be
+   used to identify the GSS-API Kerberos Version 5 mechanism.
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 18]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   The following changes have been made to be compatible with these
+   legacy implementations.
+
+   *  NegTokenTarg is changed to negTokenResp and is the message format
+      for all subsequent negotiation tokens.
+
+   *  NegTokenInit is the message for the initial negotiation message,
+      and only that message.
+
+   *  mechTypes in negTokenInit is not optional.
+
+   *  If the selected mechanism is also the most preferred mechanism for
+      both peers, it is safe to omit the MIC tokens.
+
+   If at least one of the two peers implements the updated pseudo
+   mechanism in this document, the negotiation is protected.
+
+   The following changes are to address problems in RFC 2478.
+
+   *  reqFlags is not protected, therefore it should not impact the
+      negotiation.
+
+   *  DER encoding is required.
+
+   *  GSS_GetMIC() input is clarified.
+
+   *  Per-message integrity services are requested for the negotiated
+      mechanism.
+
+   *  Two MIC tokens are exchanged, one in each direction.
+
+   An implementation that conforms to this specification will not
+   inter-operate with a strict RFC 2748 implementation.  Even if the new
+   implementation always sends a mechlistMIC token, it will still fail
+   to inter-operate.  If it is a server, it will fail because it
+   requests a mechlistMIC token using an option that older
+   implementations do not support.  Clients will tend to fail as well.
+
+   As an alternative to the approach chosen in this specification, we
+   could have documented a correct behavior that is fully backward
+   compatible with RFC 2478 and included an appendix on how to inter-
+   operate with existing incorrect implementations of RFC 2478.
+
+   As a practical matter, the SPNEGO implementers within the IETF have
+   valued interoperability with the Microsoft implementations.  We were
+   unable to choose to maintain reasonable security guarantees, to
+   maintain interoperability with the Microsoft implementations, and to
+   maintain interoperability with correct implementations of RFC 2478.
+
+
+
+Zhu, et al.                 Standards Track                    [Page 19]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   The working group was not aware of any RFC 2478 implementations
+   deployed on the Internet.  Even if there are such implementations, it
+   is unlikely that they will inter-operate because of a critical flaw
+   in the description of the encoding of the mechanism list in RFC 2478.
+
+   With the approach taken in this specification, security is ensured
+   between new implementations all the time while maintaining
+   interoperability with the implementations deployed within the IETF
+   community.  The working group believes that this justifies breaking
+   compatibility with a correct implementation of RFC 2478.
+
+Appendix D.  mechListMIC Computation Example
+
+   The following is an example to illustrate how the mechListMIC field
+   would be computed.
+
+   The initial part of the DER encoding of NegTokenInit is constructed
+   as follows (the "nn" are length encodings, possibly longer than one
+   octet):
+
+      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
+      nn -- length
+
+         -- contents octets of the SEQUENCE begin with
+         -- DER encoding of "[0] MechTypeList":
+         A0 -- identifier octet for constructed [0]
+         nn -- length
+
+             -- contents of the constructed [0] are DER encoding
+             -- of MechTypeList (which is a SEQUENCE):
+             30 -- identifier octet for constructed SEQUENCE
+             nn -- length
+
+                -- contents octets of the SEQUENCE begin with
+                -- DER encoding of OBJECT IDENTIFIER:
+                06 -- identifier octet for primitive OBJECT IDENTIFIER
+                09 -- length
+                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
+                                           -- {1 2 840 113554 1 2 2}
+
+   If a mechlistMIC needs to be generated (according to the rules in
+   Section 5), it is computed by using the DER encoding of the type
+   MechTypeList data from the initiator's NegTokenInit token as input to
+   the GSS_GetMIC() function.  In this case, the MIC would be computed
+   over the following octets:
+
+      DER encoding of MechTypeList:
+      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
+
+
+
+Zhu, et al.                 Standards Track                    [Page 20]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+   Note that the identifier octet and length octet(s) for constructed
+   [0] (A0 nn) are not included in the MIC computation.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Wyllys Ingersoll
+   Sun Microsystems
+   1775 Wiehle Avenue, 2nd Floor
+   Reston, VA  20190
+   US
+
+   EMail: wyllys.ingersoll@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 21]
+
+RFC 4178           The GSS-API Negotiation Mechanism        October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                    [Page 22]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4401.txt b/third_party/heimdal/doc/standardisation/rfc4401.txt
new file mode 100644
index 00000000000..339b58aa601
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4401.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        N. Williams
+Request for Comments: 4401                              Sun Microsystems
+Category: Standards Track                                  February 2006
+
+
+         A Pseudo-Random Function (PRF) API Extension for the
+    Generic Security Service Application Program Interface (GSS-API)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a Pseudo-Random Function (PRF) extension to the
+   Generic Security Service Application Program Interface (GSS-API) for
+   keying application protocols given an established GSS-API security
+   context.  The primary intended use of this function is to key secure
+   session layers that do not or cannot use GSS-API per-message message
+   integrity check (MIC) and wrap tokens for session protection.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................2
+   2. GSS_Pseudo_random() .............................................2
+      2.1. C-Bindings .................................................5
+   3. IANA Considerations .............................................5
+   4. Security Considerations .........................................5
+   5. References ......................................................7
+      5.1. Normative References .......................................7
+      5.2. Informative References .....................................7
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 1]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+1.  Introduction
+
+   A need has arisen for users of the GSS-API to key applications'
+   cryptographic protocols using established GSS-API security contexts.
+   Such applications can use the GSS-API [RFC2743] for authentication,
+   but not for transport security (for whatever reasons), and since the
+   GSS-API does not provide a method for obtaining keying material from
+   established security contexts, such applications cannot make
+   effective use of the GSS-API.
+
+   To address this need, we define a pseudo-random function (PRF)
+   extension to the GSS-API.
+
+   Though this document specifies an abstract API as an extension to the
+   GSS-API version 2, update 1, and though it specifies the bindings of
+   this extension for the C programming language, it does not specify a
+   revision of the GSS-API and so does not address the matter of how
+   portable applications detect support for and ensure access to this
+   extension.  We defer this matter to an expected, comprehensive update
+   to the GSS-API.
+
+1.1.  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 [RFC2119].
+
+2.  GSS_Pseudo_random()
+
+   Inputs:
+
+   o  context CONTEXT handle,
+
+   o  prf_key INTEGER,
+
+   o  prf_in OCTET STRING,
+
+   o  desired_output_len INTEGER
+
+
+   Outputs:
+
+   o  major_status INTEGER,
+
+   o  minor_status INTEGER,
+
+   o  prf_out OCTET STRING
+
+
+
+
+Williams                    Standards Track                     [Page 2]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates no error.
+
+   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
+      as input.
+
+   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
+      provided as input.
+
+   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
+      this function or, if the security context is not fully
+      established, that the context is not ready to compute the PRF with
+      the given prf_key, or that the given prf_key is not available.
+
+   o  GSS_S_FAILURE indicates general failure, possibly due to the given
+      input data being too large or of zero length, or due to the
+      desired_output_len being zero; the minor status code may provide
+      additional information.
+
+   This function applies the established context's mechanism's keyed
+   pseudo-random function (PRF) to the input data ('prf_in'), keyed with
+   key material associated with the given security context and
+   identified by 'prf_key', and outputs the resulting octet string
+   ('prf_out') of desired_output_len length.
+
+   The minimum input data length is one octet.
+
+   Mechanisms MUST be able to consume all the provided prf_in input data
+   that is 2^14 or fewer octets.
+
+   If a mechanism cannot consume as much input data as provided by the
+   caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
+
+   The minimum desired_output_len is one.
+
+   Mechanisms MUST be able to output at least up to 2^14 octets.
+
+   If the implementation cannot produce the desired output due to lack
+   of resources, then it MUST return GSS_S_FAILURE and MUST set a
+   suitable minor status code.
+
+   The prf_key can take on the following values: GSS_C_PRF_KEY_FULL,
+   GSS_C_PRF_KEY_PARTIAL, or mechanism-specific values, if any.  This
+   parameter is intended to distinguish between the best cryptographic
+   keys that may be available only after full security context
+   establishment and keys that may be available prior to full security
+   context establishment.  For some mechanisms, or contexts, those two
+
+
+
+Williams                    Standards Track                     [Page 3]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+   prf_key values MAY refer to the same cryptographic keys; for
+   mechanisms like the Kerberos V GSS-API mechanism [RFC1964] where one
+   peer may assert a key that may be considered better than the others
+   they MAY be different keys.
+
+   GSS_C_PRF_KEY_PARTIAL corresponds to a key that would have been used
+   while the security context was partially established, even if it is
+   fully established when GSS_Pseudo_random() is actually called.
+   Mechanism-specific prf_key values are intended to refer to any other
+   keys that may be available.
+
+   The GSS_C_PRF_KEY_FULL value corresponds to the best key available
+   for fully-established security contexts.
+
+   GSS_Pseudo_random() has the following properties:
+
+   o  its output string MUST be a pseudo-random function [GGM1] [GGM2]
+      of the input keyed with key material from the given security
+      context -- the chances of getting the same output given different
+      input parameters should be exponentially small.
+
+   o  when successfully applied to the same inputs by an initiator and
+      acceptor using the same security context, it MUST produce the
+      _same results_ for both, the initiator and acceptor, even if
+      called multiple times (as long as the security context is not
+      expired).
+
+   o  upon full establishment of a security context, all cryptographic
+      keys and/or negotiations used for computing the PRF with any
+      prf_key MUST be authenticated (mutually, if mutual authentication
+      is in effect for the given security context).
+
+   o  the outputs of the mechanism's GSS_Pseudo_random() (for different
+      inputs) and its per-message tokens for the given security context
+      MUST be "cryptographically separate"; in other words, it must not
+      be feasible to recover key material for one mechanism operation or
+      transform its tokens and PRF outputs from one to the other given
+      only said tokens and PRF outputs.  (This is a fancy way of saying
+      that key derivation and strong cryptographic operations and
+      constructions must be used.)
+
+   o  as implied by the above requirement, it MUST NOT be possible to
+      access any raw keys of a security context through
+      GSS_Pseudo_random(), no matter what inputs are given.
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 4]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+2.1.  C-Bindings
+
+   #define GSS_C_PRF_KEY_FULL 0
+   #define GSS_C_PRF_KEY_PARTIAL 1
+
+   OM_uint32 gss_pseudo_random(
+     OM_uint32                     *minor_status,
+     gss_ctx_id_t                  context,
+     int                           prf_key,
+     const gss_buffer_t            prf_in,
+     ssize_t                       desired_output_len,
+     gss_buffer_t                  prf_out
+   );
+
+   Additional major status codes for the C-bindings:
+
+   o  GSS_S_CALL_INACCESSIBLE_READ
+
+   o  GSS_S_CALL_INACCESSIBLE_WRITE
+
+   See [RFC2744].
+
+3.  IANA Considerations
+
+   This document has no IANA considerations currently.  If and when a
+   relevant IANA registry of GSS-API symbols is created, then the
+   generic and language-specific function names, constant names, and
+   constant values described above should be added to such a registry.
+
+4.  Security Considerations
+
+   Care should be taken in properly designing a mechanism's PRF
+   function.
+
+   GSS mechanisms' PRF functions should use a key derived from contexts'
+   authenticated session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+   Some mechanisms may support the GSS PRF function with security
+   contexts that are not fully established, but applications MUST assume
+   that authentication, mutual or otherwise, has not completed until the
+   security context is fully established.
+
+   Callers of GSS_Pseudo_random() should avoid accidentally calling it
+   with the same inputs.  One useful technique is to prepend to the
+   prf_in input string, by convention, a string indicating the intended
+   purpose of the PRF output in such a way that unique contexts in which
+   the function is called yield unique inputs to it.
+
+
+
+Williams                    Standards Track                     [Page 5]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+   Pseudo-random functions are, by their nature, capable of producing
+   only limited amounts of cryptographically secure output.  The exact
+   amount of output that one can safely use, unfortunately, varies from
+   one PRF to another (which prevents us from recommending specific
+   numbers).  Because of this, we recommend that unless you really know
+   what you are doing (i.e., you are a cryptographer and are qualified
+   to pass judgement on cryptographic functions in areas of period,
+   presence of short cycles, etc.), you limit the amount of the PRF
+   output used to the necessary minimum.  See [RFC4086] for more
+   information about "Randomness Requirements for Security".
+
+   For some mechanisms, the computational cost of computing
+   GSS_Pseudo_random() may increase significantly as the length of the
+   prf_in data and/or the desired_output_length increase.  This means
+   that if an application can be tricked into providing very large input
+   octet strings and requesting very long output octet strings, then
+   that may constitute a denial of service attack on the application;
+   therefore, applications SHOULD place appropriate limits on the size
+   of any input octet strings received from their peers without
+   integrity protection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 6]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+5.  References
+
+5.1.  Normative References
+
+   [GGM1]     Goldreich, O., Goldwasser, S., and S. Micali, "How to
+              Construct Random Functions", Journal of the ACM, October
+              1986.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+5.2.  Informative References
+
+   [GGM2]     Goldreich, O., Goldwasser, S., and S. Micali, "On the
+              Cryptographic Applications of Random Functions",
+              Proceedings of CRYPTO 84 on Advances in cryptology, 1985.
+
+   [RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              June 2005.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+              1964, June 1996.
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 7]
+
+RFC 4401            A PRF Extension for the GSS-API        February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 8]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4402.txt b/third_party/heimdal/doc/standardisation/rfc4402.txt
new file mode 100644
index 00000000000..c6f1d871c64
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4402.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        N. Williams
+Request for Comments: 4402                                           Sun
+Category: Standards Track                                  February 2006
+
+
+   A Pseudo-Random Function (PRF) for the Kerberos V Generic Security
+       Service Application Program Interface (GSS-API) Mechanism
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines the Pseudo-Random Function (PRF) for the
+   Kerberos V mechanism for the Generic Security Service Application
+   Program Interface (GSS-API), based on the PRF defined for the
+   Kerberos V cryptographic framework, for keying application protocols
+   given an established Kerberos V GSS-API security context.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................2
+   2. Kerberos V GSS Mechanism PRF ....................................2
+   3. IANA Considerations .............................................3
+   4. Security Considerations .........................................3
+   5. Normative References ............................................4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 1]
+
+RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
+
+
+1.  Introduction
+
+   This document specifies the Kerberos V GSS-API mechanism's [RFC4121]
+   pseudo-random function corresponding to [RFC4401].  The function is a
+   "PRF+" style construction.  For more information see [RFC4401],
+   [RFC2743], [RFC2744], and [RFC4121].
+
+1.1.  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 [RFC2119].
+
+2.  Kerberos V GSS Mechanism PRF
+
+   The GSS-API PRF [RFC4401] function for the Kerberos V mechanism
+   [RFC4121] shall be the output of a PRF+ function based on the
+   encryption type's PRF function keyed with the negotiated session key
+   of the security context corresponding to the 'prf_key' input
+   parameter of GSS_Pseudo_random().
+
+   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
+   parameter as follows:
+
+   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
+      acceptor, if any, or the sub-session asserted by the initiator, if
+      any, or the Ticket's session key
+
+   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
+      initiator, if any, or the Ticket's session key
+
+   The PRF+ function is a simple counter-based extension of the Kerberos
+   V pseudo-random function [RFC3961] for the encryption type of the
+   security context's keys:
+
+         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
+
+         Tn = pseudo-random(K, n || S)
+
+   where '||' is the concatenation operator, 'n' is encoded as a network
+   byte order 32-bit unsigned binary number, truncate(L, S) truncates
+   the input octet string S to length L, and pseudo-random() is the
+   Kerberos V pseudo-random function [RFC3961].
+
+   The maximum output size of the Kerberos V mechanism's GSS-API PRF
+   then is, necessarily, 2^32 times the output size of the pseudo-
+   random() function for the encryption type of the given key.
+
+
+
+
+Williams                    Standards Track                     [Page 2]
+
+RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
+
+
+   When the input size is longer than 2^14 octets as per [RFC4401] and
+   exceeds an implementation's resources, then the mechanism MUST return
+   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
+   code.
+
+3.  IANA Considerations
+
+   This document has no IANA considerations currently.  If and when a
+   relevant IANA registry of GSS-API symbols and constants is created,
+   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
+   added to such a registry.
+
+4.  Security Considerations
+
+   Kerberos V encryption types' PRF functions use a key derived from
+   contexts' session keys and should preserve the forward security
+   properties of the mechanisms' key exchanges.
+
+   Legacy Kerberos V encryption types may be weak, particularly the
+   single-DES encryption types.
+
+   See also [RFC4401] for generic security considerations of
+   GSS_Pseudo_random().
+
+   See also [RFC3961] for generic security considerations of the
+   Kerberos V cryptographic framework.
+
+   Use of Ticket session keys, rather than sub-session keys, when
+   initiators and acceptors fail to assert sub-session keys, is
+   dangerous as ticket reuse can lead to key reuse; therefore,
+   initiators should assert sub-session keys always, and acceptors
+   should assert sub-session keys at least when initiators fail to do
+   so.
+
+   The computational cost of computing this PRF+ may vary depending on
+   the Kerberos V encryption types being used, but generally the
+   computation of this PRF+ gets more expensive as the input and output
+   octet string lengths grow (note that the use of a counter in the PRF+
+   construction allows for parallelization).  This means that if an
+   application can be tricked into providing very large input octet
+   strings and requesting very long output octet strings, then that may
+   constitute a denial of service attack on the application; therefore,
+   applications SHOULD place appropriate limits on the size of any input
+   octet strings received from their peers without integrity protection.
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 3]
+
+RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
+
+
+5.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
+
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 4]
+
+RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 5]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4506.txt b/third_party/heimdal/doc/standardisation/rfc4506.txt
new file mode 100644
index 00000000000..9bd6a8905e4
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4506.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                     M. Eisler, Ed.
+Request for Comments: 4506                       Network Appliance, Inc.
+STD: 67                                                         May 2006
+Obsoletes: 1832
+Category: Standards Track
+
+
+               XDR: External Data Representation Standard
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the External Data Representation Standard
+   (XDR) protocol as it is currently deployed and accepted.  This
+   document obsoletes RFC 1832.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler                      Standards Track                     [Page 1]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Changes from RFC 1832 ...........................................3
+   3. Basic Block Size ................................................3
+   4. XDR Data Types ..................................................4
+      4.1. Integer ....................................................4
+      4.2. Unsigned Integer ...........................................4
+      4.3. Enumeration ................................................5
+      4.4. Boolean ....................................................5
+      4.5. Hyper Integer and Unsigned Hyper Integer ...................5
+      4.6. Floating-Point .............................................6
+      4.7. Double-Precision Floating-Point ............................7
+      4.8. Quadruple-Precision Floating-Point .........................8
+      4.9. Fixed-Length Opaque Data ...................................9
+      4.10. Variable-Length Opaque Data ...............................9
+      4.11. String ...................................................10
+      4.12. Fixed-Length Array .......................................11
+      4.13. Variable-Length Array ....................................11
+      4.14. Structure ................................................12
+      4.15. Discriminated Union ......................................12
+      4.16. Void .....................................................13
+      4.17. Constant .................................................13
+      4.18. Typedef ..................................................13
+      4.19. Optional-Data ............................................14
+      4.20. Areas for Future Enhancement .............................16
+   5. Discussion .....................................................16
+   6. The XDR Language Specification .................................17
+      6.1. Notational Conventions ....................................17
+      6.2. Lexical Notes .............................................18
+      6.3. Syntax Information ........................................18
+      6.4. Syntax Notes ..............................................20
+   7. An Example of an XDR Data Description ..........................21
+   8. Security Considerations ........................................22
+   9. IANA Considerations ............................................23
+   10. Trademarks and Owners .........................................23
+   11. ANSI/IEEE Standard 754-1985 ...................................24
+   12. Normative References ..........................................25
+   13. Informative References ........................................25
+   14. Acknowledgements ..............................................26
+
+
+
+
+
+
+
+
+
+
+
+Eisler                      Standards Track                     [Page 2]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+1.  Introduction
+
+   XDR is a standard for the description and encoding of data.  It is
+   useful for transferring data between different computer
+   architectures, and it has been used to communicate data between such
+   diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
+   XDR fits into the ISO presentation layer and is roughly analogous in
+   purpose to X.409, ISO Abstract Syntax Notation.  The major difference
+   between these two is that XDR uses implicit typing, while X.409 uses
+   explicit typing.
+
+   XDR uses a language to describe data formats.  The language can be
+   used only to describe data; it is not a programming language.  This
+   language allows one to describe intricate data formats in a concise
+   manner.  The alternative of using graphical representations (itself
+   an informal language) quickly becomes incomprehensible when faced
+   with complexity.  The XDR language itself is similar to the C
+   language [KERN], just as Courier [COUR] is similar to Mesa.
+   Protocols such as ONC RPC (Remote Procedure Call) and the NFS*
+   (Network File System) use XDR to describe the format of their data.
+
+   The XDR standard makes the following assumption: that bytes (or
+   octets) are portable, where a byte is defined as 8 bits of data.  A
+   given hardware device should encode the bytes onto the various media
+   in such a way that other hardware devices may decode the bytes
+   without loss of meaning.  For example, the Ethernet* standard
+   suggests that bytes be encoded in "little-endian" style [COHE], or
+   least significant bit first.
+
+2.  Changes from RFC 1832
+
+   This document makes no technical changes to RFC 1832 and is published
+   for the purposes of noting IANA considerations, augmenting security
+   considerations, and distinguishing normative from informative
+   references.
+
+3.  Basic Block Size
+
+   The representation of all items requires a multiple of four bytes (or
+   32 bits) of data.  The bytes are numbered 0 through n-1.  The bytes
+   are read or written to some byte stream such that byte m always
+   precedes byte m+1.  If the n bytes needed to contain the data are not
+   a multiple of four, then the n bytes are followed by enough (0 to 3)
+   residual zero bytes, r, to make the total byte count a multiple of 4.
+
+   We include the familiar graphic box notation for illustration and
+   comparison.  In most illustrations, each box (delimited by a plus
+   sign at the 4 corners and vertical bars and dashes) depicts a byte.
+
+
+
+Eisler                      Standards Track                     [Page 3]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   Ellipses (...) between boxes show zero or more additional bytes where
+   required.
+
+        +--------+--------+...+--------+--------+...+--------+
+        | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |   BLOCK
+        +--------+--------+...+--------+--------+...+--------+
+        |<-----------n bytes---------->|<------r bytes------>|
+        |<-----------n+r (where (n+r) mod 4 = 0)>----------->|
+
+4.   XDR Data Types
+
+   Each of the sections that follow describes a data type defined in the
+   XDR standard, shows how it is declared in the language, and includes
+   a graphic illustration of its encoding.
+
+   For each data type in the language we show a general paradigm
+   declaration.  Note that angle brackets (< and >) denote variable-
+   length sequences of data and that square brackets ([ and ]) denote
+   fixed-length sequences of data.  "n", "m", and "r" denote integers.
+   For the full language specification and more formal definitions of
+   terms such as "identifier" and "declaration", refer to Section 6,
+   "The XDR Language Specification".
+
+   For some data types, more specific examples are included.  A more
+   extensive example of a data description is in Section 7, "An Example
+   of an XDR Data Description".
+
+4.1.  Integer
+
+   An XDR signed integer is a 32-bit datum that encodes an integer in
+   the range [-2147483648,2147483647].  The integer is represented in
+   two's complement notation.  The most and least significant bytes are
+   0 and 3, respectively.  Integers are declared as follows:
+
+         int identifier;
+
+           (MSB)                   (LSB)
+         +-------+-------+-------+-------+
+         |byte 0 |byte 1 |byte 2 |byte 3 |                      INTEGER
+         +-------+-------+-------+-------+
+         <------------32 bits------------>
+
+4.2.  Unsigned Integer
+
+   An XDR unsigned integer is a 32-bit datum that encodes a non-negative
+   integer in the range [0,4294967295].  It is represented by an
+   unsigned binary number whose most and least significant bytes are 0
+   and 3, respectively.  An unsigned integer is declared as follows:
+
+
+
+Eisler                      Standards Track                     [Page 4]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+         unsigned int identifier;
+
+           (MSB)                   (LSB)
+            +-------+-------+-------+-------+
+            |byte 0 |byte 1 |byte 2 |byte 3 |           UNSIGNED INTEGER
+            +-------+-------+-------+-------+
+            <------------32 bits------------>
+
+4.3.  Enumeration
+
+   Enumerations have the same representation as signed integers.
+   Enumerations are handy for describing subsets of the integers.
+   Enumerated data is declared as follows:
+
+         enum { name-identifier = constant, ... } identifier;
+
+   For example, the three colors red, yellow, and blue could be
+   described by an enumerated type:
+
+         enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
+
+   It is an error to encode as an enum any integer other than those that
+   have been given assignments in the enum declaration.
+
+4.4.  Boolean
+
+   Booleans are important enough and occur frequently enough to warrant
+   their own explicit type in the standard.  Booleans are declared as
+   follows:
+
+         bool identifier;
+
+   This is equivalent to:
+
+         enum { FALSE = 0, TRUE = 1 } identifier;
+
+4.5.  Hyper Integer and Unsigned Hyper Integer
+
+   The standard also defines 64-bit (8-byte) numbers called hyper
+   integers and unsigned hyper integers.  Their representations are the
+   obvious extensions of integer and unsigned integer defined above.
+   They are represented in two's complement notation.  The most and
+   least significant bytes are 0 and 7, respectively.  Their
+   declarations:
+
+   hyper identifier; unsigned hyper identifier;
+
+
+
+
+
+Eisler                      Standards Track                     [Page 5]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+        (MSB)                                                   (LSB)
+      +-------+-------+-------+-------+-------+-------+-------+-------+
+      |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
+      +-------+-------+-------+-------+-------+-------+-------+-------+
+      <----------------------------64 bits---------------------------->
+                                                 HYPER INTEGER
+                                                 UNSIGNED HYPER INTEGER
+
+4.6.  Floating-Point
+
+   The standard defines the floating-point data type "float" (32 bits or
+   4 bytes).  The encoding used is the IEEE standard for normalized
+   single-precision floating-point numbers [IEEE].  The following three
+   fields describe the single-precision floating-point number:
+
+      S: The sign of the number.  Values 0 and 1 represent positive and
+         negative, respectively.  One bit.
+
+      E: The exponent of the number, base 2.  8 bits are devoted to this
+         field.  The exponent is biased by 127.
+
+      F: The fractional part of the number's mantissa, base 2.  23 bits
+         are devoted to this field.
+
+   Therefore, the floating-point number is described by:
+
+         (-1)**S * 2**(E-Bias) * 1.F
+
+   It is declared as follows:
+
+         float identifier;
+
+         +-------+-------+-------+-------+
+         |byte 0 |byte 1 |byte 2 |byte 3 |              SINGLE-PRECISION
+         S|   E   |           F          |         FLOATING-POINT NUMBER
+         +-------+-------+-------+-------+
+         1|<- 8 ->|<-------23 bits------>|
+         <------------32 bits------------>
+
+   Just as the most and least significant bytes of a number are 0 and 3,
+   the most and least significant bits of a single-precision floating-
+   point number are 0 and 31.  The beginning bit (and most significant
+   bit) offsets of S, E, and F are 0, 1, and 9, respectively.  Note that
+   these numbers refer to the mathematical positions of the bits, and
+   NOT to their actual physical locations (which vary from medium to
+   medium).
+
+
+
+
+
+Eisler                      Standards Track                     [Page 6]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   The IEEE specifications should be consulted concerning the encoding
+   for signed zero, signed infinity (overflow), and denormalized numbers
+   (underflow) [IEEE].  According to IEEE specifications, the "NaN" (not
+   a number) is system dependent and should not be interpreted within
+   XDR as anything other than "NaN".
+
+4.7.  Double-Precision Floating-Point
+
+   The standard defines the encoding for the double-precision floating-
+   point data type "double" (64 bits or 8 bytes).  The encoding used is
+   the IEEE standard for normalized double-precision floating-point
+   numbers [IEEE].  The standard encodes the following three fields,
+   which describe the double-precision floating-point number:
+
+      S: The sign of the number.  Values 0 and 1 represent positive and
+            negative, respectively.  One bit.
+
+      E: The exponent of the number, base 2.  11 bits are devoted to
+            this field.  The exponent is biased by 1023.
+
+      F: The fractional part of the number's mantissa, base 2.  52 bits
+            are devoted to this field.
+
+   Therefore, the floating-point number is described by:
+
+         (-1)**S * 2**(E-Bias) * 1.F
+
+   It is declared as follows:
+
+         double identifier;
+
+         +------+------+------+------+------+------+------+------+
+         |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
+         S|    E   |                    F                        |
+         +------+------+------+------+------+------+------+------+
+         1|<--11-->|<-----------------52 bits------------------->|
+         <-----------------------64 bits------------------------->
+                                        DOUBLE-PRECISION FLOATING-POINT
+
+   Just as the most and least significant bytes of a number are 0 and 3,
+   the most and least significant bits of a double-precision floating-
+   point number are 0 and 63.  The beginning bit (and most significant
+   bit) offsets of S, E, and F are 0, 1, and 12, respectively.  Note
+   that these numbers refer to the mathematical positions of the bits,
+   and NOT to their actual physical locations (which vary from medium to
+   medium).
+
+
+
+
+
+Eisler                      Standards Track                     [Page 7]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   The IEEE specifications should be consulted concerning the encoding
+   for signed zero, signed infinity (overflow), and denormalized numbers
+   (underflow) [IEEE].  According to IEEE specifications, the "NaN" (not
+   a number) is system dependent and should not be interpreted within
+   XDR as anything other than "NaN".
+
+4.8.  Quadruple-Precision Floating-Point
+
+   The standard defines the encoding for the quadruple-precision
+   floating-point data type "quadruple" (128 bits or 16 bytes).  The
+   encoding used is designed to be a simple analog of the encoding used
+   for single- and double-precision floating-point numbers using one
+   form of IEEE double extended precision.  The standard encodes the
+   following three fields, which describe the quadruple-precision
+   floating-point number:
+
+      S: The sign of the number.  Values 0 and 1 represent positive and
+         negative, respectively.  One bit.
+
+      E: The exponent of the number, base 2.  15 bits are devoted to
+         this field.  The exponent is biased by 16383.
+
+      F: The fractional part of the number's mantissa, base 2.  112 bits
+         are devoted to this field.
+
+   Therefore, the floating-point number is described by:
+
+         (-1)**S * 2**(E-Bias) * 1.F
+
+   It is declared as follows:
+
+         quadruple identifier;
+
+         +------+------+------+------+------+------+-...--+------+
+         |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ...  |byte15|
+         S|    E       |                  F                      |
+         +------+------+------+------+------+------+-...--+------+
+         1|<----15---->|<-------------112 bits------------------>|
+         <-----------------------128 bits------------------------>
+                                      QUADRUPLE-PRECISION FLOATING-POINT
+
+   Just as the most and least significant bytes of a number are 0 and 3,
+   the most and least significant bits of a quadruple-precision
+   floating-point number are 0 and 127.  The beginning bit (and most
+   significant bit) offsets of S, E , and F are 0, 1, and 16,
+   respectively.  Note that these numbers refer to the mathematical
+   positions of the bits, and NOT to their actual physical locations
+   (which vary from medium to medium).
+
+
+
+Eisler                      Standards Track                     [Page 8]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   The encoding for signed zero, signed infinity (overflow), and
+   denormalized numbers are analogs of the corresponding encodings for
+   single and double-precision floating-point numbers [SPAR], [HPRE].
+   The "NaN" encoding as it applies to quadruple-precision floating-
+   point numbers is system dependent and should not be interpreted
+   within XDR as anything other than "NaN".
+
+4.9.  Fixed-Length Opaque Data
+
+   At times, fixed-length uninterpreted data needs to be passed among
+   machines.  This data is called "opaque" and is declared as follows:
+
+         opaque identifier[n];
+
+   where the constant n is the (static) number of bytes necessary to
+   contain the opaque data.  If n is not a multiple of four, then the n
+   bytes are followed by enough (0 to 3) residual zero bytes, r, to make
+   the total byte count of the opaque object a multiple of four.
+
+          0        1     ...
+      +--------+--------+...+--------+--------+...+--------+
+      | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |
+      +--------+--------+...+--------+--------+...+--------+
+      |<-----------n bytes---------->|<------r bytes------>|
+      |<-----------n+r (where (n+r) mod 4 = 0)------------>|
+                                                   FIXED-LENGTH OPAQUE
+
+4.10.  Variable-Length Opaque Data
+
+   The standard also provides for variable-length (counted) opaque data,
+   defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
+   to be the number n encoded as an unsigned integer (as described
+   below), and followed by the n bytes of the sequence.
+
+   Byte m of the sequence always precedes byte m+1 of the sequence, and
+   byte 0 of the sequence always follows the sequence's length (count).
+   If n is not a multiple of four, then the n bytes are followed by
+   enough (0 to 3) residual zero bytes, r, to make the total byte count
+   a multiple of four.  Variable-length opaque data is declared in the
+   following way:
+
+         opaque identifier<m>;
+      or
+         opaque identifier<>;
+
+   The constant m denotes an upper bound of the number of bytes that the
+   sequence may contain.  If m is not specified, as in the second
+   declaration, it is assumed to be (2**32) - 1, the maximum length.
+
+
+
+Eisler                      Standards Track                     [Page 9]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   The constant m would normally be found in a protocol specification.
+   For example, a filing protocol may state that the maximum data
+   transfer size is 8192 bytes, as follows:
+
+         opaque filedata<8192>;
+
+            0     1     2     3     4     5   ...
+         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
+         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
+         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
+         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
+                                 |<----n+r (where (n+r) mod 4 = 0)---->|
+                                                  VARIABLE-LENGTH OPAQUE
+
+   It is an error to encode a length greater than the maximum described
+   in the specification.
+
+4.11.  String
+
+   The standard defines a string of n (numbered 0 through n-1) ASCII
+   bytes to be the number n encoded as an unsigned integer (as described
+   above), and followed by the n bytes of the string.  Byte m of the
+   string always precedes byte m+1 of the string, and byte 0 of the
+   string always follows the string's length.  If n is not a multiple of
+   four, then the n bytes are followed by enough (0 to 3) residual zero
+   bytes, r, to make the total byte count a multiple of four.  Counted
+   byte strings are declared as follows:
+
+         string object<m>;
+      or
+         string object<>;
+
+   The constant m denotes an upper bound of the number of bytes that a
+   string may contain.  If m is not specified, as in the second
+   declaration, it is assumed to be (2**32) - 1, the maximum length.
+   The constant m would normally be found in a protocol specification.
+   For example, a filing protocol may state that a file name can be no
+   longer than 255 bytes, as follows:
+
+         string filename<255>;
+
+            0     1     2     3     4     5   ...
+         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
+         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
+         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
+         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
+                                 |<----n+r (where (n+r) mod 4 = 0)---->|
+                                                                  STRING
+
+
+
+Eisler                      Standards Track                    [Page 10]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   It is an error to encode a length greater than the maximum described
+   in the specification.
+
+4.12.  Fixed-Length Array
+
+   Declarations for fixed-length arrays of homogeneous elements are in
+   the following form:
+
+         type-name identifier[n];
+
+   Fixed-length arrays of elements numbered 0 through n-1 are encoded by
+   individually encoding the elements of the array in their natural
+   order, 0 through n-1.  Each element's size is a multiple of four
+   bytes.  Though all elements are of the same type, the elements may
+   have different sizes.  For example, in a fixed-length array of
+   strings, all elements are of type "string", yet each element will
+   vary in its length.
+
+         +---+---+---+---+---+---+---+---+...+---+---+---+---+
+         |   element 0   |   element 1   |...|  element n-1  |
+         +---+---+---+---+---+---+---+---+...+---+---+---+---+
+         |<--------------------n elements------------------->|
+
+                                               FIXED-LENGTH ARRAY
+
+4.13.  Variable-Length Array
+
+   Counted arrays provide the ability to encode variable-length arrays
+   of homogeneous elements.  The array is encoded as the element count n
+   (an unsigned integer) followed by the encoding of each of the array's
+   elements, starting with element 0 and progressing through element
+   n-1.  The declaration for variable-length arrays follows this form:
+
+         type-name identifier<m>;
+      or
+         type-name identifier<>;
+
+   The constant m specifies the maximum acceptable element count of an
+   array; if m is not specified, as in the second declaration, it is
+   assumed to be (2**32) - 1.
+
+           0  1  2  3
+         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
+         |     n     | element 0 | element 1 |...|element n-1|
+         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
+         |<-4 bytes->|<--------------n elements------------->|
+                                                         COUNTED ARRAY
+
+
+
+
+Eisler                      Standards Track                    [Page 11]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   It is an error to encode a value of n that is greater than the
+   maximum described in the specification.
+
+4.14.  Structure
+
+   Structures are declared as follows:
+
+         struct {
+            component-declaration-A;
+            component-declaration-B;
+            ...
+         } identifier;
+
+   The components of the structure are encoded in the order of their
+   declaration in the structure.  Each component's size is a multiple of
+   four bytes, though the components may be different sizes.
+
+         +-------------+-------------+...
+         | component A | component B |...                      STRUCTURE
+         +-------------+-------------+...
+
+4.15.  Discriminated Union
+
+   A discriminated union is a type composed of a discriminant followed
+   by a type selected from a set of prearranged types according to the
+   value of the discriminant.  The type of discriminant is either "int",
+   "unsigned int", or an enumerated type, such as "bool".  The component
+   types are called "arms" of the union and are preceded by the value of
+   the discriminant that implies their encoding.  Discriminated unions
+   are declared as follows:
+
+         union switch (discriminant-declaration) {
+         case discriminant-value-A:
+            arm-declaration-A;
+         case discriminant-value-B:
+            arm-declaration-B;
+         ...
+         default: default-declaration;
+         } identifier;
+
+   Each "case" keyword is followed by a legal value of the discriminant.
+   The default arm is optional.  If it is not specified, then a valid
+   encoding of the union cannot take on unspecified discriminant values.
+   The size of the implied arm is always a multiple of four bytes.
+
+   The discriminated union is encoded as its discriminant followed by
+   the encoding of the implied arm.
+
+
+
+
+Eisler                      Standards Track                    [Page 12]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+           0   1   2   3
+         +---+---+---+---+---+---+---+---+
+         |  discriminant |  implied arm  |          DISCRIMINATED UNION
+         +---+---+---+---+---+---+---+---+
+         |<---4 bytes--->|
+
+4.16.  Void
+
+   An XDR void is a 0-byte quantity.  Voids are useful for describing
+   operations that take no data as input or no data as output.  They are
+   also useful in unions, where some arms may contain data and others do
+   not.  The declaration is simply as follows:
+
+         void;
+
+   Voids are illustrated as follows:
+
+           ++
+           ||                                                     VOID
+           ++
+         --><-- 0 bytes
+
+4.17.  Constant
+
+   The data declaration for a constant follows this form:
+
+         const name-identifier = n;
+
+   "const" is used to define a symbolic name for a constant; it does not
+   declare any data.  The symbolic constant may be used anywhere a
+   regular constant may be used.  For example, the following defines a
+   symbolic constant DOZEN, equal to 12.
+
+         const DOZEN = 12;
+
+4.18.  Typedef
+
+   "typedef" does not declare any data either, but serves to define new
+   identifiers for declaring data.  The syntax is:
+
+         typedef declaration;
+
+   The new type name is actually the variable name in the declaration
+   part of the typedef.  For example, the following defines a new type
+   called "eggbox" using an existing type called "egg":
+
+         typedef egg eggbox[DOZEN];
+
+
+
+
+Eisler                      Standards Track                    [Page 13]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   Variables declared using the new type name have the same type as the
+   new type name would have in the typedef, if it were considered a
+   variable.  For example, the following two declarations are equivalent
+   in declaring the variable "fresheggs":
+
+         eggbox  fresheggs; egg     fresheggs[DOZEN];
+
+   When a typedef involves a struct, enum, or union definition, there is
+   another (preferred) syntax that may be used to define the same type.
+   In general, a typedef of the following form:
+
+         typedef <<struct, union, or enum definition>> identifier;
+
+   may be converted to the alternative form by removing the "typedef"
+   part and placing the identifier after the "struct", "union", or
+   "enum" keyword, instead of at the end.  For example, here are the two
+   ways to define the type "bool":
+
+         typedef enum {    /* using typedef */
+            FALSE = 0,
+            TRUE = 1
+         } bool;
+
+         enum bool {       /* preferred alternative */
+            FALSE = 0,
+            TRUE = 1
+         };
+
+   This syntax is preferred because one does not have to wait until the
+   end of a declaration to figure out the name of the new type.
+
+4.19.  Optional-Data
+
+   Optional-data is one kind of union that occurs so frequently that we
+   give it a special syntax of its own for declaring it.  It is declared
+   as follows:
+
+         type-name *identifier;
+
+   This is equivalent to the following union:
+
+         union switch (bool opted) {
+         case TRUE:
+            type-name element;
+         case FALSE:
+            void;
+         } identifier;
+
+
+
+
+Eisler                      Standards Track                    [Page 14]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   It is also equivalent to the following variable-length array
+   declaration, since the boolean "opted" can be interpreted as the
+   length of the array:
+
+         type-name identifier<1>;
+
+   Optional-data is not so interesting in itself, but it is very useful
+   for describing recursive data-structures such as linked-lists and
+   trees.  For example, the following defines a type "stringlist" that
+   encodes lists of zero or more arbitrary length strings:
+
+        struct stringentry {
+           string item<>;
+           stringentry *next;
+        };
+
+        typedef stringentry *stringlist;
+
+   It could have been equivalently declared as the following union:
+
+         union stringlist switch (bool opted) {
+         case TRUE:
+            struct {
+               string item<>;
+               stringlist next;
+            } element;
+         case FALSE:
+            void;
+         };
+
+   or as a variable-length array:
+
+        struct stringentry {
+           string item<>;
+           stringentry next<1>;
+        };
+
+        typedef stringentry stringlist<1>;
+
+   Both of these declarations obscure the intention of the stringlist
+   type, so the optional-data declaration is preferred over both of
+   them.  The optional-data type also has a close correlation to how
+   recursive data structures are represented in high-level languages
+   such as Pascal or C by use of pointers.  In fact, the syntax is the
+   same as that of the C language for pointers.
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 15]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+4.20.  Areas for Future Enhancement
+
+   The XDR standard lacks representations for bit fields and bitmaps,
+   since the standard is based on bytes.  Also missing are packed (or
+   binary-coded) decimals.
+
+   The intent of the XDR standard was not to describe every kind of data
+   that people have ever sent or will ever want to send from machine to
+   machine.  Rather, it only describes the most commonly used data-types
+   of high-level languages such as Pascal or C so that applications
+   written in these languages will be able to communicate easily over
+   some medium.
+
+   One could imagine extensions to XDR that would let it describe almost
+   any existing protocol, such as TCP.  The minimum necessary for this
+   is support for different block sizes and byte-orders.  The XDR
+   discussed here could then be considered the 4-byte big-endian member
+   of a larger XDR family.
+
+5.  Discussion
+
+   (1) Why use a language for describing data?  What's wrong with
+       diagrams?
+
+   There are many advantages in using a data-description language such
+   as XDR versus using diagrams.  Languages are more formal than
+   diagrams and lead to less ambiguous descriptions of data.  Languages
+   are also easier to understand and allow one to think of other issues
+   instead of the low-level details of bit encoding.  Also, there is a
+   close analogy between the types of XDR and a high-level language such
+   as C or Pascal.  This makes the implementation of XDR encoding and
+   decoding modules an easier task.  Finally, the language specification
+   itself is an ASCII string that can be passed from machine to machine
+   to perform on-the-fly data interpretation.
+
+   (2) Why is there only one byte-order for an XDR unit?
+
+   Supporting two byte-orderings requires a higher-level protocol for
+   determining in which byte-order the data is encoded.  Since XDR is
+   not a protocol, this can't be done.  The advantage of this, though,
+   is that data in XDR format can be written to a magnetic tape, for
+   example, and any machine will be able to interpret it, since no
+   higher-level protocol is necessary for determining the byte-order.
+
+   (3) Why is the XDR byte-order big-endian instead of little-endian?
+       Isn't this unfair to little-endian machines such as the VAX(r),
+       which has to convert from one form to the other?
+
+
+
+
+Eisler                      Standards Track                    [Page 16]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   Yes, it is unfair, but having only one byte-order means you have to
+   be unfair to somebody.  Many architectures, such as the Motorola
+   68000* and IBM 370*, support the big-endian byte-order.
+
+   (4) Why is the XDR unit four bytes wide?
+
+   There is a tradeoff in choosing the XDR unit size.  Choosing a small
+   size, such as two, makes the encoded data small, but causes alignment
+   problems for machines that aren't aligned on these boundaries.  A
+   large size, such as eight, means the data will be aligned on
+   virtually every machine, but causes the encoded data to grow too big.
+   We chose four as a compromise.  Four is big enough to support most
+   architectures efficiently, except for rare machines such as the
+   eight-byte-aligned Cray*.  Four is also small enough to keep the
+   encoded data restricted to a reasonable size.
+
+   (5) Why must variable-length data be padded with zeros?
+
+   It is desirable that the same data encode into the same thing on all
+   machines, so that encoded data can be meaningfully compared or
+   checksummed.  Forcing the padded bytes to be zero ensures this.
+
+   (6) Why is there no explicit data-typing?
+
+   Data-typing has a relatively high cost for what small advantages it
+   may have.  One cost is the expansion of data due to the inserted type
+   fields.  Another is the added cost of interpreting these type fields
+   and acting accordingly.  And most protocols already know what type
+   they expect, so data-typing supplies only redundant information.
+   However, one can still get the benefits of data-typing using XDR.
+   One way is to encode two things: first, a string that is the XDR data
+   description of the encoded data, and then the encoded data itself.
+   Another way is to assign a value to all the types in XDR, and then
+   define a universal type that takes this value as its discriminant and
+   for each value, describes the corresponding data type.
+
+6.  The XDR Language Specification
+
+6.1.  Notational Conventions
+
+   This specification uses an extended Back-Naur Form notation for
+   describing the XDR language.  Here is a brief description of the
+   notation:
+
+   (1) The characters '|', '(', ')', '[', ']', '"', and '*' are special.
+   (2) Terminal symbols are strings of any characters surrounded by
+   double quotes.  (3) Non-terminal symbols are strings of non-special
+   characters.  (4) Alternative items are separated by a vertical bar
+
+
+
+Eisler                      Standards Track                    [Page 17]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   ("|").  (5) Optional items are enclosed in brackets.  (6) Items are
+   grouped together by enclosing them in parentheses.  (7) A '*'
+   following an item means 0 or more occurrences of that item.
+
+   For example, consider the following pattern:
+
+         "a " "very" (", " "very")* [" cold " "and "]  " rainy "
+         ("day" | "night")
+
+   An infinite number of strings match this pattern.  A few of them are:
+
+         "a very rainy day"
+         "a very, very rainy day"
+         "a very cold and  rainy day"
+         "a very, very, very cold and  rainy night"
+
+6.2.  Lexical Notes
+
+   (1) Comments begin with '/*' and terminate with '*/'.  (2) White
+   space serves to separate items and is otherwise ignored.  (3) An
+   identifier is a letter followed by an optional sequence of letters,
+   digits, or underbar ('_').  The case of identifiers is not ignored.
+   (4) A decimal constant expresses a number in base 10 and is a
+   sequence of one or more decimal digits, where the first digit is not
+   a zero, and is optionally preceded by a minus-sign ('-').  (5) A
+   hexadecimal constant expresses a number in base 16, and must be
+   preceded by '0x', followed by one or hexadecimal digits ('A', 'B',
+   'C', 'D', E', 'F', 'a', 'b', 'c', 'd', 'e', 'f', '0', '1', '2', '3',
+   '4', '5', '6', '7', '8', '9').  (6) An octal constant expresses a
+   number in base 8, always leads with digit 0, and is a sequence of one
+   or more octal digits ('0', '1', '2', '3', '4', '5', '6', '7').
+
+6.3.  Syntax Information
+
+      declaration:
+           type-specifier identifier
+         | type-specifier identifier "[" value "]"
+         | type-specifier identifier "<" [ value ] ">"
+         | "opaque" identifier "[" value "]"
+         | "opaque" identifier "<" [ value ] ">"
+         | "string" identifier "<" [ value ] ">"
+         | type-specifier "*" identifier
+         | "void"
+
+      value:
+           constant
+         | identifier
+
+
+
+
+Eisler                      Standards Track                    [Page 18]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+      constant:
+         decimal-constant | hexadecimal-constant | octal-constant
+
+      type-specifier:
+           [ "unsigned" ] "int"
+         | [ "unsigned" ] "hyper"
+         | "float"
+         | "double"
+         | "quadruple"
+         | "bool"
+         | enum-type-spec
+         | struct-type-spec
+         | union-type-spec
+         | identifier
+
+      enum-type-spec:
+         "enum" enum-body
+
+      enum-body:
+         "{"
+            ( identifier "=" value )
+            ( "," identifier "=" value )*
+         "}"
+
+      struct-type-spec:
+         "struct" struct-body
+
+      struct-body:
+         "{"
+            ( declaration ";" )
+            ( declaration ";" )*
+         "}"
+
+      union-type-spec:
+         "union" union-body
+
+      union-body:
+         "switch" "(" declaration ")" "{"
+            case-spec
+            case-spec *
+            [ "default" ":" declaration ";" ]
+         "}"
+
+      case-spec:
+        ( "case" value ":")
+        ( "case" value ":") *
+        declaration ";"
+
+
+
+
+Eisler                      Standards Track                    [Page 19]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+      constant-def:
+         "const" identifier "=" constant ";"
+
+      type-def:
+           "typedef" declaration ";"
+         | "enum" identifier enum-body ";"
+         | "struct" identifier struct-body ";"
+         | "union" identifier union-body ";"
+
+      definition:
+           type-def
+         | constant-def
+
+      specification:
+           definition *
+
+6.4.  Syntax Notes
+
+   (1) The following are keywords and cannot be used as identifiers:
+   "bool", "case", "const", "default", "double", "quadruple", "enum",
+   "float", "hyper", "int", "opaque", "string", "struct", "switch",
+   "typedef", "union", "unsigned", and "void".
+
+   (2) Only unsigned constants may be used as size specifications for
+   arrays.  If an identifier is used, it must have been declared
+   previously as an unsigned constant in a "const" definition.
+
+   (3) Constant and type identifiers within the scope of a specification
+   are in the same name space and must be declared uniquely within this
+   scope.
+
+   (4) Similarly, variable names must be unique within the scope of
+   struct and union declarations.  Nested struct and union declarations
+   create new scopes.
+
+   (5) The discriminant of a union must be of a type that evaluates to
+   an integer.  That is, "int", "unsigned int", "bool", an enumerated
+   type, or any typedefed type that evaluates to one of these is legal.
+   Also, the case values must be one of the legal values of the
+   discriminant.  Finally, a case value may not be specified more than
+   once within the scope of a union declaration.
+
+
+
+
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 20]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+7.  An Example of an XDR Data Description
+
+   Here is a short XDR data description of a thing called a "file",
+   which might be used to transfer files from one machine to another.
+
+         const MAXUSERNAME = 32;     /* max length of a user name */
+         const MAXFILELEN = 65535;   /* max length of a file      */
+         const MAXNAMELEN = 255;     /* max length of a file name */
+
+         /*
+          * Types of files:
+          */
+         enum filekind {
+            TEXT = 0,       /* ascii data */
+            DATA = 1,       /* raw data   */
+            EXEC = 2        /* executable */
+         };
+
+         /*
+          * File information, per kind of file:
+          */
+         union filetype switch (filekind kind) {
+         case TEXT:
+            void;                           /* no extra information */
+         case DATA:
+            string creator<MAXNAMELEN>;     /* data creator         */
+         case EXEC:
+            string interpretor<MAXNAMELEN>; /* program interpretor  */
+         };
+
+         /*
+          * A complete file:
+          */
+         struct file {
+            string filename<MAXNAMELEN>; /* name of file    */
+            filetype type;               /* info about file */
+            string owner<MAXUSERNAME>;   /* owner of file   */
+            opaque data<MAXFILELEN>;     /* file data       */
+         };
+
+   Suppose now that there is a user named "john" who wants to store his
+   lisp program "sillyprog" that contains just the data "(quit)".  His
+   file would be encoded as follows:
+
+
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 21]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+       OFFSET  HEX BYTES       ASCII    COMMENTS
+       ------  ---------       -----    --------
+        0      00 00 00 09     ....     -- length of filename = 9
+        4      73 69 6c 6c     sill     -- filename characters
+        8      79 70 72 6f     ypro     -- ... and more characters ...
+       12      67 00 00 00     g...     -- ... and 3 zero-bytes of fill
+       16      00 00 00 02     ....     -- filekind is EXEC = 2
+       20      00 00 00 04     ....     -- length of interpretor = 4
+       24      6c 69 73 70     lisp     -- interpretor characters
+       28      00 00 00 04     ....     -- length of owner = 4
+       32      6a 6f 68 6e     john     -- owner characters
+       36      00 00 00 06     ....     -- length of file data = 6
+       40      28 71 75 69     (qui     -- file data bytes ...
+       44      74 29 00 00     t)..     -- ... and 2 zero-bytes of fill
+
+8.  Security Considerations
+
+   XDR is a data description language, not a protocol, and hence it does
+   not inherently give rise to any particular security considerations.
+   Protocols that carry XDR-formatted data, such as NFSv4, are
+   responsible for providing any necessary security services to secure
+   the data they transport.
+
+   Care must be take to properly encode and decode data to avoid
+   attacks.  Known and avoidable risks include:
+
+   *    Buffer overflow attacks.  Where feasible, protocols should be
+        defined with explicit limits (via the "<" [ value ] ">" notation
+        instead of "<" ">") on elements with variable-length data types.
+        Regardless of the feasibility of an explicit limit on the
+        variable length of an element of a given protocol, decoders need
+        to ensure the incoming size does not exceed the length of any
+        provisioned receiver buffers.
+
+   *    Nul octets embedded in an encoded value of type string.  If the
+        decoder's native string format uses nul-terminated strings, then
+        the apparent size of the decoded object will be less than the
+        amount of memory allocated for the string.  Some memory
+        deallocation interfaces take a size argument.  The caller of the
+        deallocation interface would likely determine the size of the
+        string by counting to the location of the nul octet and adding
+        one.  This discrepancy can cause memory leakage (because less
+        memory is actually returned to the free pool than allocated),
+        leading to system failure and a denial of service attack.
+
+   *    Decoding of characters in strings that are legal ASCII
+        characters but nonetheless are illegal for the intended
+        application.  For example, some operating systems treat the '/'
+
+
+
+Eisler                      Standards Track                    [Page 22]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+        character as a component separator in path names.  For a
+        protocol that encodes a string in the argument to a file
+        creation operation, the decoder needs to ensure that '/' is not
+        inside the component name.  Otherwise, a file with an illegal
+        '/' in its name will be created, making it difficult to remove,
+        and is therefore a denial of service attack.
+
+   *    Denial of service caused by recursive decoder or encoder
+        subroutines.  A recursive decoder or encoder might process data
+        that has a structured type with a member of type optional data
+        that directly or indirectly refers to the structured type (i.e.,
+        a linked list).  For example,
+
+              struct m {
+                int x;
+                struct m *next;
+              };
+
+        An encoder or decoder subroutine might be written to recursively
+        call itself each time another element of type "struct m" is
+        found.  An attacker could construct a long linked list of
+        "struct m" elements in the request or response, which then
+        causes a stack overflow on the decoder or encoder.  Decoders and
+        encoders should be written non-recursively or impose a limit on
+        list length.
+
+9.  IANA Considerations
+
+   It is possible, if not likely, that new data types will be added to
+   XDR in the future.  The process for adding new types is via a
+   standards track RFC and not registration of new types with IANA.
+   Standards track RFCs that update or replace this document should be
+   documented as such in the RFC Editor's database of RFCs.
+
+10.  Trademarks and Owners
+
+   SUN WORKSTATION  Sun Microsystems, Inc.
+   VAX              Hewlett-Packard Company
+   IBM-PC           International Business Machines Corporation
+   Cray             Cray Inc.
+   NFS              Sun Microsystems, Inc.
+   Ethernet         Xerox Corporation.
+   Motorola 68000   Motorola, Inc.
+   IBM 370          International Business Machines Corporation
+
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 23]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+11.  ANSI/IEEE Standard 754-1985
+
+   The definition of NaNs, signed zero and infinity, and denormalized
+   numbers from [IEEE] is reproduced here for convenience.  The
+   definitions for quadruple-precision floating point numbers are
+   analogs of those for single and double-precision floating point
+   numbers and are defined in [IEEE].
+
+   In the following, 'S' stands for the sign bit, 'E' for the exponent,
+   and 'F' for the fractional part.  The symbol 'u' stands for an
+   undefined bit (0 or 1).
+
+   For single-precision floating point numbers:
+
+    Type                  S (1 bit)   E (8 bits)    F (23 bits)
+    ----                  ---------   ----------    -----------
+    signalling NaN        u           255 (max)     .0uuuuu---u
+                                                    (with at least
+                                                     one 1 bit)
+    quiet NaN             u           255 (max)     .1uuuuu---u
+
+    negative infinity     1           255 (max)     .000000---0
+
+    positive infinity     0           255 (max)     .000000---0
+
+    negative zero         1           0             .000000---0
+
+    positive zero         0           0             .000000---0
+
+   For double-precision floating point numbers:
+
+    Type                  S (1 bit)   E (11 bits)   F (52 bits)
+    ----                  ---------   -----------   -----------
+    signalling NaN        u           2047 (max)    .0uuuuu---u
+                                                    (with at least
+                                                     one 1 bit)
+    quiet NaN             u           2047 (max)    .1uuuuu---u
+
+    negative infinity     1           2047 (max)    .000000---0
+
+    positive infinity     0           2047 (max)    .000000---0
+
+    negative zero         1           0             .000000---0
+
+    positive zero         0           0             .000000---0
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 24]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+   For quadruple-precision floating point numbers:
+
+    Type                  S (1 bit)   E (15 bits)   F (112 bits)
+    ----                  ---------   -----------   ------------
+    signalling NaN        u           32767 (max)   .0uuuuu---u
+                                                    (with at least
+                                                     one 1 bit)
+    quiet NaN             u           32767 (max)   .1uuuuu---u
+
+    negative infinity     1           32767 (max)   .000000---0
+
+    positive infinity     0           32767 (max)   .000000---0
+
+    negative zero         1           0             .000000---0
+
+    positive zero         0           0             .000000---0
+
+   Subnormal numbers are represented as follows:
+
+    Precision            Exponent       Value
+    ---------            --------       -----
+    Single               0              (-1)**S * 2**(-126) * 0.F
+
+    Double               0              (-1)**S * 2**(-1022) * 0.F
+
+    Quadruple            0              (-1)**S * 2**(-16382) * 0.F
+
+12.  Normative References
+
+   [IEEE]  "IEEE Standard for Binary Floating-Point Arithmetic",
+           ANSI/IEEE Standard 754-1985, Institute of Electrical and
+           Electronics Engineers, August 1985.
+
+13.  Informative References
+
+   [KERN]  Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
+           Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
+
+   [COHE]  Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE
+           Computer, October 1981.
+
+   [COUR]  "Courier: The Remote Procedure Call Protocol", XEROX
+           Corporation, XSIS 038112, December 1981.
+
+   [SPAR]  "The SPARC Architecture Manual: Version 8", Prentice Hall,
+           ISBN 0-13-825001-4.
+
+   [HPRE]  "HP Precision Architecture Handbook", June 1987, 5954-9906.
+
+
+
+Eisler                      Standards Track                    [Page 25]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+14.  Acknowledgements
+
+   Bob Lyon was Sun's visible force behind ONC RPC in the 1980s.  Sun
+   Microsystems, Inc., is listed as the author of RFC 1014.  Raj
+   Srinivasan and the rest of the old ONC RPC working group edited RFC
+   1014 into RFC 1832, from which this document is derived.  Mike Eisler
+   and Bill Janssen submitted the implementation reports for this
+   standard.  Kevin Coffman, Benny Halevy, and Jon Peterson reviewed
+   this document and gave feedback.  Peter Astrand and Bryan Olson
+   pointed out several errors in RFC 1832 which are corrected in this
+   document.
+
+Editor's Address
+
+   Mike Eisler
+   5765 Chase Point Circle
+   Colorado Springs, CO 80919
+   USA
+
+   Phone: 719-599-9026
+   EMail: email2mre-rfc4506@yahoo.com
+
+   Please address comments to: nfsv4@ietf.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 26]
+
+RFC 4506       XDR: External Data Representation Standard       May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eisler                      Standards Track                    [Page 27]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4556.txt b/third_party/heimdal/doc/standardisation/rfc4556.txt
new file mode 100644
index 00000000000..2ff94392897
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4556.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                             L. Zhu
+Request for Comments: 4556                         Microsoft Corporation
+Category: Standards Track                                        B. Tung
+                                                   Aerospace Corporation
+                                                               June 2006
+
+
+                      Public Key Cryptography for
+              Initial Authentication in Kerberos (PKINIT)
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes protocol extensions (hereafter called PKINIT)
+   to the Kerberos protocol specification.  These extensions provide a
+   method for integrating public key cryptography into the initial
+   authentication exchange, by using asymmetric-key signature and/or
+   encryption algorithms in pre-authentication data fields.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................4
+   3. Extensions ......................................................5
+      3.1. Definitions, Requirements, and Constants ...................6
+           3.1.1. Required Algorithms .................................6
+           3.1.2. Recommended Algorithms ..............................6
+           3.1.3. Defined Message and Encryption Types ................7
+           3.1.4. Kerberos Encryption Types Defined for CMS
+                  Algorithm Identifiers ...............................8
+      3.2. PKINIT Pre-authentication Syntax and Use ...................9
+           3.2.1. Generation of Client Request ........................9
+           3.2.2. Receipt of Client Request ..........................14
+           3.2.3. Generation of KDC Reply ............................18
+                  3.2.3.1. Using Diffie-Hellman Key Exchange .........21
+                  3.2.3.2. Using Public Key Encryption ...............23
+
+
+
+Zhu & Tung                  Standards Track                     [Page 1]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+           3.2.4. Receipt of KDC Reply ...............................25
+      3.3. Interoperability Requirements .............................26
+      3.4. KDC Indication of PKINIT Support ..........................27
+   4. Security Considerations ........................................27
+   5. Acknowledgements ...............................................30
+   6. References .....................................................30
+      6.1. Normative References ......................................30
+      6.2. Informative References ....................................32
+   Appendix A.  PKINIT ASN.1 Module ..................................33
+   Appendix B.  Test Vectors .........................................38
+   Appendix C.  Miscellaneous Information about Microsoft Windows
+                PKINIT Implementations ...............................40
+
+1.  Introduction
+
+   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
+   party known as the Key Distribution Center (KDC) to negotiate shared
+   session keys between clients and services and provide mutual
+   authentication between them.
+
+   The corner-stones of Kerberos V5 are the Ticket and the
+   Authenticator.  A Ticket encapsulates a symmetric key (the ticket
+   session key) in an envelope (a public message) intended for a
+   specific service.  The contents of the Ticket are encrypted with a
+   symmetric key shared between the service principal and the issuing
+   KDC.  The encrypted part of the Ticket contains the client principal
+   name, among other items.  An Authenticator is a record that can be
+   shown to have been recently generated using the ticket session key in
+   the associated Ticket.  The ticket session key is known by the client
+   who requested the ticket.  The contents of the Authenticator are
+   encrypted with the associated ticket session key.  The encrypted part
+   of an Authenticator contains a timestamp and the client principal
+   name, among other items.
+
+   As shown in Figure 1, below, the Kerberos V5 protocol consists of the
+   following message exchanges between the client and the KDC, and the
+   client and the application service:
+
+    - The Authentication Service (AS) Exchange
+
+      The client obtains an "initial" ticket from the Kerberos
+      authentication server (AS), typically a Ticket Granting Ticket
+      (TGT).  The AS-REQ message and the AS-REP message are the request
+      and the reply message, respectively, between the client and the
+      AS.
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 2]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+    - The Ticket Granting Service (TGS) Exchange
+
+      The client subsequently uses the TGT to authenticate and request a
+      service ticket for a particular service, from the Kerberos
+      ticket-granting server (TGS).  The TGS-REQ message and the TGS-REP
+      message are the request and the reply message respectively between
+      the client and the TGS.
+
+    - The Client/Server Authentication Protocol (AP) Exchange
+
+      The client then makes a request with an AP-REQ message, consisting
+      of a service ticket and an authenticator that certifies the
+      client's possession of the ticket session key.  The server may
+      optionally reply with an AP-REP message.  AP exchanges typically
+      negotiate session-specific symmetric keys.
+
+   Usually, the AS and TGS are integrated in a single device also known
+   as the KDC.
+
+                          +--------------+
+               +--------->|  KDC         |
+       AS-REQ /   +-------|              |
+             /   /        +--------------+
+            /   /          ^           |
+           /    |AS-REP   /            |
+          |     |        / TGS-REQ     + TGS-REP
+          |     |       /             /
+          |     |      /             /
+          |     |     /   +---------+
+          |     |    /   /
+          |     |   /   /
+          |     |  /   /
+          |     v /   v
+         ++-------+------+             +-----------------+
+         |  Client       +------------>|  Application    |
+         |               |    AP-REQ   |  Server         |
+         |               |<------------|                 |
+         +---------------+    AP-REP   +-----------------+
+
+       Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
+
+   In the AS exchange, the KDC reply contains the ticket session key,
+   among other items, that is encrypted using a key (the AS reply key)
+   shared between the client and the KDC.  The AS reply key is typically
+   derived from the client's password for human users.  Therefore, for
+   human users, the attack resistance strength of the Kerberos protocol
+   is no stronger than the strength of their passwords.
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 3]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   The use of asymmetric cryptography in the form of X.509 certificates
+   [RFC3280] is popular for facilitating data origin authentication and
+   perfect secrecy.  An established Public Key Infrastructure (PKI)
+   provides key management and key distribution mechanisms that can be
+   used to establish authentication and secure communication.  Adding
+   public-key cryptography to Kerberos provides a nice congruence to
+   public-key protocols, obviates the human users' burden to manage
+   strong passwords, and allows Kerberized applications to take
+   advantage of existing key services and identity management.
+
+   The advantage afforded by the Kerberos TGT is that the client exposes
+   his long-term secrets only once.  The TGT and its associated session
+   key can then be used for any subsequent service ticket requests.  One
+   result of this is that all further authentication is independent of
+   the method by which the initial authentication was performed.
+   Consequently, initial authentication provides a convenient place to
+   integrate public-key cryptography into Kerberos authentication.  In
+   addition, the use of symmetric cryptography after the initial
+   exchange is preferred for performance.
+
+   This document describes the methods and data formats using which the
+   client and the KDC can use public and private key pairs to mutually
+   authenticate in the AS exchange and negotiate the AS reply key, known
+   only by the client and the KDC, to encrypt the AS-REP sent by the
+   KDC.
+
+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 [RFC2119].
+
+   In this protocol, both the client and the KDC have a public-private
+   key pair in order to prove their identities to each other over the
+   open network.  The term "signature key" is used to refer to the
+   private key of the key pair being used.
+
+   The encryption key used to encrypt the enc-part field of the KDC-REP
+   in the AS-REP [RFC4120] is referred to as the AS reply key.
+
+   An empty sequence in an optional field can be either included or
+   omitted: both encodings are permitted and considered equivalent.
+
+   The term "Modular Exponential Diffie-Hellman" is used to refer to the
+   Diffie-Hellman key exchange, as described in [RFC2631], in order to
+   differentiate it from other equivalent representations of the same
+   key agreement algorithm.
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 4]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+3.  Extensions
+
+   This section describes extensions to [RFC4120] for supporting the use
+   of public-key cryptography in the initial request for a ticket.
+
+   Briefly, this document defines the following extensions to [RFC4120]:
+
+   1. The client indicates the use of public-key authentication by
+      including a special preauthenticator in the initial request.  This
+      preauthenticator contains the client's public-key data and a
+      signature.
+
+   2. The KDC tests the client's request against its authentication
+      policy and trusted Certification Authorities (CAs).
+
+   3. If the request passes the verification tests, the KDC replies as
+      usual, but the reply is encrypted using either:
+
+      a. a key generated through a Diffie-Hellman (DH) key exchange
+         [RFC2631] [IEEE1363] with the client, signed using the KDC's
+         signature key; or
+
+      b. a symmetric encryption key, signed using the KDC's signature
+         key and encrypted using the client's public key.
+
+      Any keying material required by the client to obtain the
+      encryption key for decrypting the KDC reply is returned in a pre-
+      authentication field accompanying the usual reply.
+
+   4. The client validates the KDC's signature, obtains the encryption
+      key, decrypts the reply, and then proceeds as usual.
+
+   Section 3.1 of this document enumerates the required algorithms and
+   necessary extension message types.  Section 3.2 describes the
+   extension messages in greater detail.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 5]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+3.1.  Definitions, Requirements, and Constants
+
+3.1.1.  Required Algorithms
+
+   All PKINIT implementations MUST support the following algorithms:
+
+   o  AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts-
+      hmac-sha1-96 [RFC3962].
+
+   o  Signature algorithm: sha-1WithRSAEncryption [RFC3370].
+
+   o  AS reply key delivery method: the Diffie-Hellman key delivery
+      method, as described in Section 3.2.3.1.
+
+   In addition, implementations of this specification MUST be capable of
+   processing the Extended Key Usage (EKU) extension and the id-pkinit-
+   san (as defined in Section 3.2.2) otherName of the Subject
+   Alternative Name (SAN) extension in X.509 certificates [RFC3280].
+
+3.1.2.  Recommended Algorithms
+
+   All PKINIT implementations SHOULD support the following algorithm:
+
+   o  AS reply key delivery method: the public key encryption key
+      delivery method, as described in Section 3.2.3.2.
+
+   For implementations that support the public key encryption key
+   delivery method, the following algorithms MUST be supported:
+
+   a) Key transport algorithms identified in the keyEncryptionAlgorithm
+      field of the type KeyTransRecipientInfo [RFC3852] for encrypting
+      the temporary key in the encryptedKey field [RFC3852] with a
+      public key, as described in Section 3.2.3.2: rsaEncryption (this
+      is the RSAES-PKCS1-v1_5 encryption scheme) [RFC3370] [RFC3447].
+
+   b) Content encryption algorithms identified in the
+      contentEncryptionAlgorithm field of the type EncryptedContentInfo
+      [RFC3852] for encrypting the AS reply key with the temporary key
+      contained in the encryptedKey field of the type
+      KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
+      des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 6]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+3.1.3.  Defined Message and Encryption Types
+
+   PKINIT makes use of the following new pre-authentication types:
+
+       PA_PK_AS_REQ                                 16
+       PA_PK_AS_REP                                 17
+
+   PKINIT also makes use of the following new authorization data type:
+
+       AD_INITIAL_VERIFIED_CAS                       9
+
+   PKINIT introduces the following new error codes:
+
+       KDC_ERR_CLIENT_NOT_TRUSTED                   62
+       KDC_ERR_INVALID_SIG                          64
+       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
+       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
+       KDC_ERR_INVALID_CERTIFICATE                  71
+       KDC_ERR_REVOKED_CERTIFICATE                  72
+       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
+       KDC_ERR_CLIENT_NAME_MISMATCH                 75
+       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
+       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
+       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
+       KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED  81
+
+   PKINIT uses the following typed data types for errors:
+
+       TD_TRUSTED_CERTIFIERS                       104
+       TD_INVALID_CERTIFICATES                     105
+       TD_DH_PARAMETERS                            109
+
+   The ASN.1 module for all structures defined in this document (plus
+   IMPORT statements for all imported structures) is given in Appendix
+   A.
+
+   All structures defined in or imported into this document MUST be
+   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
+   (unless otherwise noted).  All data structures carried in OCTET
+   STRINGs MUST be encoded according to the rules specified in the
+   specifications defining each data structure; a reference to the
+   appropriate specification is provided for each data structure.
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 7]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   Interoperability note: Some implementations may not be able to decode
+   wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
+   with BER; specifically, they may not be able to decode indefinite-
+   length encodings.  To maximize interoperability, implementers SHOULD
+   encode CMS objects used in PKINIT with DER.
+
+3.1.4.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers
+
+   PKINIT defines the following Kerberos encryption type numbers
+   [RFC3961], which can be used in the etype field of the AS-REQ
+   [RFC4120] message to indicate to the KDC the client's acceptance of
+   the corresponding algorithms (including key transport algorithms
+   [RFC3370], content encryption algorithms [RFC3370], and signature
+   algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
+   [RFC3370].
+
+   Per [RFC4120], the encryption types in the etype field are in the
+   decreasing preference order of the client.  Note that there is no
+   significance in the relative order between any two of different types
+   of algorithms: key transport algorithms, content encryption
+   algorithms, and signature algorithms.
+
+   The presence of each of these encryption types in the etype field is
+   equivalent to the presence of the corresponding algorithm Object
+   Identifier (OID) in the supportedCMSTypes field as described in
+   Section 3.2.1.  And the preference order expressed in the
+   supportedCMSTypes field would override the preference order listed in
+   the etype field.
+
+    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
+    ============================== === ===============================
+    id-dsa-with-sha1-CmsOID         9  id-dsa-with-sha1 [RFC3370]
+    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3370]
+    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3370]
+    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
+    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3370]
+    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3560]
+    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                     [Page 8]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   The above encryption type numbers are used only to indicate support
+   for the use of the corresponding algorithms in PKINIT; they do not
+   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
+   be used in the etype field of the Kerberos EncryptedData type
+   [RFC4120].  The practice of assigning Kerberos encryption type
+   numbers to indicate support for CMS algorithms is considered
+   deprecated, and new numbers should not be assigned for this purpose.
+   Instead, the supportedCMSTypes field should be used to identify the
+   algorithms supported by the client and the preference order of the
+   client.
+
+   For maximum interoperability, however, PKINIT clients wishing to
+   indicate to the KDC the support for one or more of the algorithms
+   listed above SHOULD include the corresponding encryption type
+   number(s) in the etype field of the AS-REQ.
+
+3.2.  PKINIT Pre-authentication Syntax and Use
+
+   This section defines the syntax and use of the various pre-
+   authentication fields employed by PKINIT.
+
+3.2.1.  Generation of Client Request
+
+   The initial authentication request (AS-REQ) is sent as per [RFC4120];
+   in addition, a pre-authentication data element, whose padata-type is
+   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
+   type PA-PK-AS-REQ, is included.
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+
+
+
+Zhu & Tung                  Standards Track                     [Page 9]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+
+
+
+Zhu & Tung                  Standards Track                    [Page 10]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS algorithm [RFC3370] identifiers
+                   -- that identify key transport algorithms, or
+                   -- content encryption algorithms, or signature
+                   -- algorithms supported by the client in order of
+                   -- (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so (see Section 3.2.3.1).
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly;  this nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+   The ContentInfo [RFC3852] structure contained in the signedAuthPack
+   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
+   is filled out as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 11]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   2.  The eContentType field for the type SignedData is id-pkinit-
+       authData: { iso(1) org(3) dod(6) internet(1) security(5)
+       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance, and its value is id-pkinit-authData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type AuthPack.
+
+   4.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type AuthPack.
+
+   5.  The AuthPack structure contains a PKAuthenticator, the client
+       public key information, the CMS encryption types supported by the
+       client, and a DHNonce.  The pkAuthenticator field certifies to
+       the KDC that the client has recent knowledge of the signing key
+       that authenticates the client.  The clientPublicValue field
+       specifies Diffie-Hellman domain parameters and the client's
+       public key value.  The DH public key value is encoded as a BIT
+       STRING according to [RFC3279].  The clientPublicValue field is
+       present only if the client wishes to use the Diffie-Hellman key
+       agreement method.  The supportedCMSTypes field specifies the list
+       of CMS algorithm identifiers that are supported by the client in
+       order of (decreasing) preference, and can be used to identify a
+       signature algorithm or a key transport algorithm [RFC3370] in the
+       keyEncryptionAlgorithm field of the type KeyTransRecipientInfo,
+       or a content encryption algorithm [RFC3370] in the
+       contentEncryptionAlgorithm field of the type EncryptedContentInfo
+       [RFC3852] when encrypting the AS reply key as described in
+       Section 3.2.3.2.  However, there is no significance in the
+       relative order between any two of different types of algorithms:
+       key transport algorithms, content encryption algorithms, and
+       signature algorithms.  The clientDHNonce field is described later
+       in this section.
+
+   6.  The ctime field in the PKAuthenticator structure contains the
+       current time on the client's host, and the cusec field contains
+       the microsecond part of the client's timestamp.  The ctime and
+       cusec fields are used together to specify a reasonably accurate
+       timestamp [RFC4120].  The nonce field is chosen randomly.  The
+       paChecksum field MUST be present and it contains a SHA1 checksum
+       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
+       ease future migration from the use of SHA1, the paChecksum field
+       is made optional syntactically: when the request is extended to
+       negotiate hash algorithms, the new client wishing not to use SHA1
+       will send the request in the extended message syntax without the
+       paChecksum field.  The KDC conforming to this specification MUST
+
+
+
+Zhu & Tung                  Standards Track                    [Page 12]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+       return a KRB-ERROR [RFC4120] message with the code
+       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
+       will allow a new client to retry with SHA1 if allowed by the
+       local policy.
+
+   7.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the KDC can verify the signature over the
+       type AuthPack.  For path validation, these certificates SHOULD be
+       sufficient to construct at least one certification path from the
+       client certificate to one trust anchor acceptable by the KDC
+       [RFC4158].  The client MUST be capable of including such a set of
+       certificates if configured to do so.  The certificates field MUST
+       NOT contain "root" CA certificates.
+
+   8.  The client's Diffie-Hellman public value (clientPublicValue) is
+       included if and only if the client wishes to use the Diffie-
+       Hellman key agreement method.  The Diffie-Hellman domain
+       parameters [IEEE1363] for the client's public key are specified
+       in the algorithm field of the type SubjectPublicKeyInfo
+       [RFC3279], and the client's Diffie-Hellman public key value is
+       mapped to a subjectPublicKey (a BIT STRING) according to
+       [RFC3279].  When using the Diffie-Hellman key agreement method,
+       implementations MUST support Oakley 1024-bit Modular Exponential
+       (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
+       well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
+       MODP well-known group 16 [RFC3526].
+
+       The Diffie-Hellman field size should be chosen so as to provide
+       sufficient cryptographic security [RFC3766].
+
+       When MODP Diffie-Hellman is used, the exponents should have at
+       least twice as many bits as the symmetric keys that will be
+       derived from them [ODL99].
+
+   9.  The client may wish to reuse DH keys or to allow the KDC to do so
+       (see Section 3.2.3.1).  If so, then the client includes the
+       clientDHNonce field.  This nonce string MUST be as long as the
+       longest key length of the symmetric key types that the client
+       supports.  This nonce MUST be chosen randomly.
+
+   The ExternalPrincipalIdentifier structure is used in this document to
+   identify the subject's public key thereby the subject principal.
+   This structure is filled out as follows:
+
+   1.  The subjectName field contains a PKIX type Name encoded according
+       to [RFC3280].  This field identifies the certificate subject by
+       the distinguished subject name.  This field is REQUIRED when
+
+
+
+Zhu & Tung                  Standards Track                    [Page 13]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+       there is a distinguished subject name present in the certificate
+       being used.
+
+   2.  The issuerAndSerialNumber field contains a CMS type
+       IssuerAndSerialNumber encoded according to [RFC3852].  This field
+       identifies a certificate of the subject.  This field is REQUIRED
+       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
+       structures are defined in Section 3.2.2).
+
+   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
+       public key by a key identifier.  When an X.509 certificate is
+       referenced, this key identifier matches the X.509
+       subjectKeyIdentifier extension value.  When other certificate
+       formats are referenced, the documents that specify the
+       certificate format and their use with the CMS must include
+       details on matching the key identifier to the appropriate
+       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
+       CERTIFIERS (as defined in Section 3.2.2).
+
+   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
+   of CAs, trusted by the client, that can be used to certify the KDC.
+   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
+   (thereby its public key).
+
+   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
+   SignerIdentifier encoded according to [RFC3852].  This field
+   identifies, if present, a particular KDC public key that the client
+   already has.
+
+3.2.2.  Receipt of Client Request
+
+   Upon receiving the client's request, the KDC validates it.  This
+   section describes the steps that the KDC MUST (unless otherwise
+   noted) take in validating the request.
+
+   The KDC verifies the client's signature in the signedAuthPack field
+   according to [RFC3852].
+
+   If, while validating the client's X.509 certificate [RFC3280], the
+   KDC cannot build a certification path to validate the client's
+   certificate, it sends back a KRB-ERROR [RFC4120] message with the
+   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
+   this error message is a TYPED-DATA (as defined in [RFC4120]) that
+   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
+   whose data-value contains the DER encoding of the type TD-TRUSTED-
+   CERTIFIERS:
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 14]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
+   (thereby its public key) trusted by the KDC.
+
+   Upon receiving this error message, the client SHOULD retry only if it
+   has a different set of certificates (from those of the previous
+   requests) that form a certification path (or a partial path) from one
+   of the trust anchors acceptable by the KDC to its own certificate.
+
+   If, while processing the certification path, the KDC determines that
+   the signature on one of the certificates in the signedAuthPack field
+   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
+   message is a TYPED-DATA that contains an element whose data-type is
+   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
+   encoding of the type TD-INVALID-CERTIFICATES:
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
+   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
+   sent by the client) with an invalid signature.
+
+   If more than one X.509 certificate signature is invalid, the KDC MAY
+   include one IssuerAndSerialNumber per invalid signature within the
+   TD-INVALID-CERTIFICATES.
+
+   The client's X.509 certificate is validated according to [RFC3280].
+
+   Depending on local policy, the KDC may also check whether any X.509
+   certificates in the certification path validating the client's
+   certificate have been revoked.  If any of them have been revoked, the
+   KDC MUST return an error message with the code
+   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
+   revocation status but is unable to do so, it SHOULD return an error
+   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
+   certificate or certificates affected are identified exactly as for
+   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
+
+
+
+Zhu & Tung                  Standards Track                    [Page 15]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   Note that the TD_INVALID_CERTIFICATES error data is only used to
+   identify invalid certificates sent by the client in the request.
+
+   The client's public key is then used to verify the signature.  If the
+   signature fails to verify, the KDC MUST return an error message with
+   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
+   this error message.
+
+   In addition to validating the client's signature, the KDC MUST also
+   check that the client's public key used to verify the client's
+   signature is bound to the client principal name specified in the AS-
+   REQ as follows:
+
+   1. If the KDC has its own binding between either the client's
+      signature-verification public key or the client's certificate and
+      the client's Kerberos principal name, it uses that binding.
+
+   2. Otherwise, if the client's X.509 certificate contains a Subject
+      Alternative Name (SAN) extension carrying a KRB5PrincipalName
+      (defined below) in the otherName field of the type GeneralName
+      [RFC3280], it binds the client's X.509 certificate to that name.
+
+      The type of the otherName field is AnotherName.  The type-id field
+      of the type AnotherName is id-pkinit-san:
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+      And the value field of the type AnotherName is a
+      KRB5PrincipalName.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+   If the Kerberos client name in the AS-REQ does not match a name bound
+   by the KDC (the binding can be in the certificate, for example, as
+   described above), or if there is no binding found by the KDC, the KDC
+   MUST return an error message with the code
+   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
+   this error message.
+
+   Even if the certification path is validated and the certificate is
+   mapped to the client's principal name, the KDC may decide not to
+   accept the client's certificate, depending on local policy.
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 16]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   The KDC MAY require the presence of an Extended Key Usage (EKU)
+   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
+   of the client's X.509 certificate:
+
+       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeClientAuth(4) }
+              -- PKINIT client authentication.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the client's X.509 certificate is restricted
+   with the id-pkinit-KPClientAuth EKU.
+
+   If this EKU KeyPurposeId is required but it is not present, or if the
+   client certificate is restricted not to be used for PKINIT client
+   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
+   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
+   is no accompanying e-data for this error message.  KDCs implementing
+   this requirement SHOULD also accept the EKU KeyPurposeId
+   id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the
+   requirement, as there are a large number of X.509 client certificates
+   deployed for use with PKINIT that have this EKU.
+
+   As a matter of local policy, the KDC MAY decide to reject requests on
+   the basis of the absence or presence of other specific EKU OIDs.
+
+   If the digest algorithm used in generating the CA signature for the
+   public key in any certificate of the request is not acceptable by the
+   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
+   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
+   encoded in TYPED-DATA, although none is defined at this point.
+
+   If the client's public key is not accepted with reasons other than
+   those specified above, the KDC returns a KRB-ERROR [RFC4120] message
+   with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no accompanying
+   e-data currently defined for this error message.
+
+   The KDC MUST check the timestamp to ensure that the request is not a
+   replay, and that the time skew falls within acceptable limits.  The
+   recommendations for clock skew times in [RFC4120] apply here.  If the
+   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
+   KRB_AP_ERR_SKEW, respectively.
+
+   If the clientPublicValue is filled in, indicating that the client
+   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
+   check to see if the key parameters satisfy its policy.  If they do
+
+
+
+Zhu & Tung                  Standards Track                    [Page 17]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   not, it MUST return an error message with the code
+   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
+   TYPED-DATA that contains an element whose data-type is
+   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
+   the type TD-DH-PARAMETERS:
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+
+   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
+   that the KDC supports in decreasing preference order, from which the
+   client SHOULD pick one to retry the request.
+
+   The AlgorithmIdentifier structure is defined in [RFC3280] and is
+   filled in according to [RFC3279].  More specifically, Section 2.3.3
+   of [RFC3279] describes how to fill in the AlgorithmIdentifier
+   structure in the case where MODP Diffie-Hellman key exchange is used.
+
+   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
+   KDC does not possess the corresponding key, the KDC MUST ignore the
+   kdcPkId field as if the client did not include one.
+
+   If the digest algorithm used by the id-pkinit-authData is not
+   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
+   The accompanying e-data MUST be encoded in TYPED-DATA, although none
+   is defined at this point.
+
+3.2.3.  Generation of KDC Reply
+
+   If the paChecksum filed in the request is not present, the KDC
+   conforming to this specification MUST return a KRB-ERROR [RFC4120]
+   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
+   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
+   defined by this specification).
+
+   Assuming that the client's request has been properly validated, the
+   KDC proceeds as per [RFC4120], except as follows.
+
+   The KDC MUST set the initial flag and include an authorization data
+   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
+   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
+   type AD-INITIAL-VERIFIED-CAS:
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 18]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path with which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
+   path with which the client certificate was validated.  Each
+   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
+   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
+   (thereby its public key).
+
+   Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
+   data does permit empty SEQUENCEs to be encoded.  Such empty sequences
+   may only be used if the KDC itself vouches for the user's
+   certificate.
+
+   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
+   containers if the list of CAs satisfies the AS' realm's local policy
+   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
+   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
+   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
+   resulting ticket.  If the list of CAs satisfies the local KDC's
+   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
+   container; otherwise, it MAY unwrap the authorization data out of the
+   AD-IF-RELEVANT container.
+
+   Application servers that understand this authorization data type
+   SHOULD apply local policy to determine whether a given ticket bearing
+   such a type *not* contained within an AD-IF-RELEVANT container is
+   acceptable.  (This corresponds to the AP server's checking the
+   transited field when the TRANSITED-POLICY-CHECKED flag has not been
+   set [RFC4120].)  If such a data type is contained within an AD-IF-
+   RELEVANT container, AP servers MAY apply local policy to determine
+   whether the authorization data is acceptable.
+
+   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
+   and whose padata-value contains the DER encoding of the type PA-PK-
+   AS-REP (defined below), is included in the AS-REP [RFC4120].
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+
+
+
+Zhu & Tung                  Standards Track                    [Page 19]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined in Section 3.2.3.2.
+          ...
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present in the KDCDHKeyInfo.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+
+
+
+Zhu & Tung                  Standards Track                    [Page 20]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- field MUST also be omitted.
+          ...
+       }
+
+   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
+   KDC encrypts the reply as usual, but not with the client's long-term
+   key.  Instead, it encrypts it with either a shared key derived from a
+   Diffie-Hellman exchange or a generated encryption key.  The contents
+   of the PA-PK-AS-REP indicate which key delivery method is used.
+
+   If the client does not wish to use the Diffie-Hellman key delivery
+   method (the clientPublicValue field is not present in the request)
+   and the KDC does not support the public key encryption key delivery
+   method, the KDC MUST return an error message with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED.  There is no
+   accompanying e-data for this error message.
+
+   In addition, the lifetime of the ticket returned by the KDC MUST NOT
+   exceed that of the client's public-private key pair.  The ticket
+   lifetime, however, can be shorter than that of the client's public-
+   private key pair.  For the implementations of this specification, the
+   lifetime of the client's public-private key pair is the validity
+   period in X.509 certificates [RFC3280], unless configured otherwise.
+
+3.2.3.1.  Using Diffie-Hellman Key Exchange
+
+   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
+
+   The ContentInfo [RFC3852] structure for the dhSignedData field is
+   filled in as follows:
+
+   1.  The contentType field of the type ContentInfo is id-signedData
+       (as defined in [RFC3852]), and the content field is a SignedData
+       (as defined in [RFC3852]).
+
+   2.  The eContentType field for the type SignedData is the OID value
+       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
+       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
+       implementers: the signed attribute content-type MUST be present
+       in this SignedData instance, and its value is id-pkinit-DHKeyData
+       according to [RFC3852].
+
+   3.  The eContent field for the type SignedData contains the DER
+       encoding of the type KDCDHKeyInfo.
+
+   4.  The KDCDHKeyInfo structure contains the KDC's public key, a
+       nonce, and, optionally, the expiration time of the KDC's DH key
+       being reused.  The subjectPublicKey field of the type
+
+
+
+Zhu & Tung                  Standards Track                    [Page 21]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+       KDCDHKeyInfo field identifies KDC's DH public key.  This DH
+       public key value is encoded as a BIT STRING according to
+       [RFC3279].  The nonce field contains the nonce in the
+       pkAuthenticator field in the request if the DH keys are NOT
+       reused.  The value of this nonce field is 0 if the DH keys are
+       reused.  The dhKeyExpiration field is present if and only if the
+       DH keys are reused.  If the dhKeyExpiration field is present, the
+       KDC's public key in this KDCDHKeyInfo structure MUST NOT be used
+       past the point of this expiration time.  If this field is
+       omitted, then the serverDHNonce field MUST also be omitted.
+
+   5.  The signerInfos field of the type SignedData contains a single
+       signerInfo, which contains the signature over the type
+       KDCDHKeyInfo.
+
+   6.  The certificates field of the type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       over the type KDCDHKeyInfo.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  If the client included the clientDHNonce field, then the KDC may
+       choose to reuse its DH keys.  If the server reuses DH keys, then
+       it MUST include an expiration time in the dhKeyExpiration field.
+       Past the point of the expiration time, the signature over the
+       type DHRepInfo is considered expired/invalid.  When the server
+       reuses DH keys then, it MUST include a serverDHNonce at least as
+       long as the length of keys for the symmetric encryption system
+       used to encrypt the AS reply.  Note that including the
+       serverDHNonce changes how the client and server calculate the key
+       to use to encrypt the reply; see below for details.  The KDC
+       SHOULD NOT reuse DH keys unless the clientDHNonce field is
+       present in the request.
+
+   The AS reply key is derived as follows:
+
+   1. Both the KDC and the client calculate the shared secret value as
+      follows:
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 22]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+          a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
+          shared secret value.  DHSharedSecret is the value ZZ, as
+          described in Section 2.1.1 of [RFC2631].
+
+      DHSharedSecret is first padded with leading zeros such that the
+      size of DHSharedSecret in octets is the same as that of the
+      modulus, then represented as a string of octets in big-endian
+      order.
+
+      Implementation note: Both the client and the KDC can cache the
+      triple (ya, yb, DHSharedSecret), where ya is the client's public
+      key and yb is the KDC's public key.  If both ya and yb are the
+      same in a later exchange, the cached DHSharedSecret can be used.
+
+   2. Let K be the key-generation seed length [RFC3961] of the AS reply
+      key whose enctype is selected according to [RFC4120].
+
+   3. Define the function octetstring2key() as follows:
+
+           octetstring2key(x) == random-to-key(K-truncate(
+                                    SHA1(0x00 | x) |
+                                    SHA1(0x01 | x) |
+                                    SHA1(0x02 | x) |
+                                    ...
+                                    ))
+
+      where x is an octet string; | is the concatenation operator; 0x00,
+      0x01, 0x02, etc. are each represented as a single octet; random-
+      to-key() is an operation that generates a protocol key from a
+      bitstring of length K; and K-truncate truncates its input to the
+      first K bits.  Both K and random-to-key() are as defined in the
+      kcrypto profile [RFC3961] for the enctype of the AS reply key.
+
+   4. When DH keys are reused, let n_c be the clientDHNonce and n_k be
+      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
+      strings.
+
+   5. The AS reply key k is:
+              k = octetstring2key(DHSharedSecret | n_c | n_k)
+
+3.2.3.2.  Using Public Key Encryption
+
+   In this case, the PA-PK-AS-REP contains the encKeyPack field where
+   the AS reply key is encrypted.
+
+   The ContentInfo [RFC3852] structure for the encKeyPack field is
+   filled in as follows:
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 23]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   1.  The contentType field of the type ContentInfo is id-envelopedData
+       (as defined in [RFC3852]), and the content field is an
+       EnvelopedData (as defined in [RFC3852]).
+
+   2.  The contentType field for the type EnvelopedData is id-
+       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
+       pkcs (1) pkcs7 (7) signedData (2) }.
+
+   3.  The eContentType field for the inner type SignedData (when
+       decrypted from the encryptedContent field for the type
+       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
+       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
+       Notes to CMS implementers: the signed attribute content-type MUST
+       be present in this SignedData instance, and its value is id-
+       pkinit-rkeyData according to [RFC3852].
+
+   4.  The eContent field for the inner type SignedData contains the DER
+       encoding of the type ReplyKeyPack (as described below).
+
+   5.  The signerInfos field of the inner type SignedData contains a
+       single signerInfo, which contains the signature for the type
+       ReplyKeyPack.
+
+   6.  The certificates field of the inner type SignedData contains
+       certificates intended to facilitate certification path
+       construction, so that the client can verify the KDC's signature
+       for the type ReplyKeyPack.  The information contained in the
+       trustedCertifiers in the request SHOULD be used by the KDC as
+       hints to guide its selection of an appropriate certificate chain
+       to return to the client.  This field may be left empty if the KDC
+       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
+       used for signing.  Otherwise, for path validation, these
+       certificates SHOULD be sufficient to construct at least one
+       certification path from the KDC certificate to one trust anchor
+       acceptable by the client [RFC4158].  The KDC MUST be capable of
+       including such a set of certificates if configured to do so.  The
+       certificates field MUST NOT contain "root" CA certificates.
+
+   7.  The recipientInfos field of the type EnvelopedData is a SET that
+       MUST contain exactly one member of type KeyTransRecipientInfo.
+       The encryptedKey of this member contains the temporary key that
+       is encrypted using the client's public key.
+
+   8.  The unprotectedAttrs or originatorInfo fields of the type
+       EnvelopedData MAY be present.
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 24]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   If there is a supportedCMSTypes field in the AuthPack, the KDC must
+   check to see if it supports any of the listed types.  If it supports
+   more than one of the types, the KDC SHOULD use the one listed first.
+   If it does not support any of them, it MUST return an error message
+   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
+
+   Furthermore, the KDC computes the checksum of the AS-REQ in the
+   client request.  This checksum is performed over the type AS-REQ, and
+   the protocol key [RFC3961] of the checksum operation is the replyKey,
+   and the key usage number is 6.  If the replyKey's enctype is "newer"
+   [RFC4120] [RFC4121], the checksum operation is the required checksum
+   operation [RFC3961] of that enctype.
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e., the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+   Implementations of this RSA encryption key delivery method are
+   RECOMMENDED to support RSA keys at least 2048 bits in size.
+
+3.2.4.  Receipt of KDC Reply
+
+   Upon receipt of the KDC's reply, the client proceeds as follows.  If
+   the PA-PK-AS-REP contains the dhSignedData field, the client derives
+   the AS reply key using the same procedure used by the KDC, as defined
+   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
+   field, and the client decrypts and extracts the temporary key in the
+   encryptedKey field of the member KeyTransRecipientInfo and then uses
+   that as the AS reply key.
+
+   If the public key encryption method is used, the client MUST verify
+   the asChecksum contained in the ReplyKeyPack.
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 25]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   In either case, the client MUST verify the signature in the
+   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
+   be validated according to [RFC3280].  In addition, unless the client
+   can otherwise verify that the public key used to verify the KDC's
+   signature is bound to the KDC of the target realm, the KDC's X.509
+   certificate MUST contain a Subject Alternative Name extension
+   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
+   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
+   matches the name of the TGS of the target realm (as defined in
+   Section 7.3 of [RFC4120]).
+
+   Unless the client knows by some other means that the KDC certificate
+   is intended for a Kerberos KDC, the client MUST require that the KDC
+   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
+
+       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           pkinit(3) keyPurposeKdc(5) }
+              -- Signing KDC responses.
+              -- Key usage bits that MUST be consistent:
+              -- digitalSignature.
+
+   The digitalSignature key usage bit [RFC3280] MUST be asserted when
+   the intended purpose of the KDC's X.509 certificate is restricted
+   with the id-pkinit-KPKdc EKU.
+
+   If the KDC certificate contains the Kerberos TGS name encoded as an
+   id-pkinit-san SAN, this certificate is certified by the issuing CA as
+   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
+
+   If all applicable checks are satisfied, the client then decrypts the
+   enc-part field of the KDC-REP in the AS-REP, using the AS reply key,
+   and then proceeds as described in [RFC4120].
+
+3.3.  Interoperability Requirements
+
+   The client MUST be capable of sending a set of certificates
+   sufficient to allow the KDC to construct a certification path for the
+   client's certificate, if the correct set of certificates is provided
+   through configuration or policy.
+
+   If the client sends all the X.509 certificates on a certification
+   path to a trust anchor acceptable by the KDC, and if the KDC cannot
+   verify the client's public key otherwise, the KDC MUST be able to
+   process path validation for the client's certificate based on the
+   certificates in the request.
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 26]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   The KDC MUST be capable of sending a set of certificates sufficient
+   to allow the client to construct a certification path for the KDC's
+   certificate, if the correct set of certificates is provided through
+   configuration or policy.
+
+   If the KDC sends all the X.509 certificates on a certification path
+   to a trust anchor acceptable by the client, and the client can not
+   verify the KDC's public key otherwise, the client MUST be able to
+   process path validation for the KDC's certificate based on the
+   certificates in the reply.
+
+3.4.  KDC Indication of PKINIT Support
+
+   If pre-authentication is required but was not present in the request,
+   per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED
+   is returned, and a METHOD-DATA object will be stored in the e-data
+   field of the KRB-ERROR message to specify which pre-authentication
+   mechanisms are acceptable.  The KDC can then indicate the support of
+   PKINIT by including an empty element whose padata-type is
+   PA_PK_AS_REQ in that METHOD-DATA object.
+
+   Otherwise if it is required by the KDC's local policy that the client
+   must be pre-authenticated using the pre-authentication mechanism
+   specified in this document, but no PKINIT pre-authentication was
+   present in the request, an error message with the code
+   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
+
+   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
+   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
+   STRING), and clients MUST ignore this and any other value.  Future
+   extensions to this protocol may specify other data to send instead of
+   an empty OCTET STRING.
+
+4.  Security Considerations
+
+   The security of cryptographic algorithms is dependent on generating
+   secret quantities [RFC4086].  The number of truly random bits is
+   extremely important in determining the attack resistance strength of
+   the cryptosystem; for example, the secret Diffie-Hellman exponents
+   must be chosen based on n truly random bits (where n is the system
+   security requirement).  The security of the overall system is
+   significantly weakened by using insufficient random inputs: a
+   sophisticated attacker may find it easier to reproduce the
+   environment that produced the secret quantities and to search the
+   resulting small set of possibilities than to locate the quantities in
+   the whole of the potential number space.
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 27]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   Kerberos error messages are not integrity protected; as a result, the
+   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
+   with by an attacker so that the set of domain parameters selected
+   could be either weaker or not mutually preferred.  Local policy can
+   configure sets of domain parameters acceptable locally, or disallow
+   the negotiation of DH domain parameters.
+
+   The symmetric reply key size and Diffie-Hellman field size or RSA
+   modulus size should be chosen so as to provide sufficient
+   cryptographic security [RFC3766].
+
+   When MODP Diffie-Hellman is used, the exponents should have at least
+   twice as many bits as the symmetric keys that will be derived from
+   them [ODL99].
+
+   PKINIT raises certain security considerations beyond those that can
+   be regulated strictly in protocol definitions.  We will address them
+   in this section.
+
+   PKINIT extends the cross-realm model to the public-key
+   infrastructure.  Users of PKINIT must understand security policies
+   and procedures appropriate to the use of Public Key Infrastructures
+   [RFC3280].
+
+   In order to trust a KDC certificate that is certified by a CA as a
+   KDC certificate for a target realm (for example, by asserting the TGS
+   name of that Kerberos realm as an id-pkinit-san SAN and/or
+   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
+   as described in Section 3.2.4), the client MUST verify that the KDC
+   certificate's issuing CA is authorized to issue KDC certificates for
+   that target realm.  Otherwise, the binding between the KDC
+   certificate and the KDC of the target realm is not established.
+
+   How to validate this authorization is a matter of local policy.  A
+   way to achieve this is the configuration of specific sets of
+   intermediary CAs and trust anchors, one of which must be on the KDC
+   certificate's certification path [RFC3280], and, for each CA or trust
+   anchor, the realms for which it is allowed to issue certificates.
+
+   In addition, if any CA that is trusted to issue KDC certificates can
+   also issue other kinds of certificates, then local policy must be
+   able to distinguish between them; for example, it could require that
+   KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be
+   specified with the id-pkinit-san SAN.
+
+   It is the responsibility of the PKI administrators for an
+   organization to ensure that KDC certificates are only issued to KDCs,
+   and that clients can ascertain this using their local policy.
+
+
+
+Zhu & Tung                  Standards Track                    [Page 28]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   Standard Kerberos allows the possibility of interactions between
+   cryptosystems of varying strengths; this document adds interactions
+   with public-key cryptosystems to Kerberos.  Some administrative
+   policies may allow the use of relatively weak public keys.  When
+   using such weak asymmetric keys to protect/exchange stronger
+   symmetric Keys, the attack resistant strength of the overall system
+   is no better than that of these weak keys [RFC3766].
+
+   PKINIT requires that keys for symmetric cryptosystems be generated.
+   Some such systems contain "weak" keys.  For recommendations regarding
+   these weak keys, see [RFC4120].
+
+   PKINIT allows the use of the same RSA key pair for encryption and
+   signing when doing RSA encryption-based key delivery.  This is not
+   recommended usage of RSA keys [RFC3447]; by using DH-based key
+   delivery, this is avoided.
+
+   Care should be taken in how certificates are chosen for the purposes
+   of authentication using PKINIT.  Some local policies may require that
+   key escrow be used for certain certificate types.  Deployers of
+   PKINIT should be aware of the implications of using certificates that
+   have escrowed keys for the purposes of authentication.  Because
+   signing-only certificates are normally not escrowed, by using DH-
+   based key delivery this is avoided.
+
+   PKINIT does not provide for a "return routability" test to prevent
+   attackers from mounting a denial-of-service attack on the KDC by
+   causing it to perform unnecessary and expensive public-key
+   operations.  Strictly speaking, this is also true of standard
+   Kerberos, although the potential cost is not as great, because
+   standard Kerberos does not make use of public-key cryptography.  By
+   using DH-based key delivery and reusing DH keys, the necessary crypto
+   processing cost per request can be minimized.
+
+   When the Diffie-Hellman key exchange method is used, additional pre-
+   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ, as
+   defined in this specification) is not bound to the AS_REQ by the
+   mechanisms discussed in this specification (meaning it may be dropped
+   or added by attackers without being detected by either the client or
+   the KDC).  Designers of additional pre-authentication data should
+   take that into consideration if such additional pre-authentication
+   data can be used in conjunction with the PA_PK_AS_REQ.  The future
+   work of the Kerberos working group is expected to update the hash
+   algorithms specified in this document and provide a generic mechanism
+   to bind additional pre-authentication data with the accompanying
+   AS_REQ.
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 29]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   The key usage number 6 used by the asChecksum field is also used for
+   the authenticator checksum (cksum field of AP-REQ) contained in the
+   PA-TGS-REQ preauthentication data contained in a TGS-REQ [RFC4120].
+   This conflict is present for historical reasons; the reuse of key
+   usage numbers is strongly discouraged.
+
+5.  Acknowledgements
+
+   The following people have made significant contributions to this
+   document: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
+   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
+   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
+   Grundman, and Jeffrey Altman.
+
+   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay, and
+   Chris Walstad discovered a binding issue between the AS-REQ and AS-
+   REP in draft -26; the asChecksum field was added as the result.
+
+   Special thanks to Clifford Neuman, Matthew Hur, Ari Medvinsky, Sasha
+   Medvinsky, and Jonathan Trostle who wrote earlier versions of this
+   document.
+
+   The authors are indebted to the Kerberos working group chair, Jeffrey
+   Hutzelman, who kept track of various issues and was enormously
+   helpful during the creation of this document.
+
+   Some of the ideas on which this document 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
+   document approaches those goals primarily from the Kerberos
+   perspective.
+
+   Lastly, comments from groups working on similar ideas in DCE have
+   been invaluable.
+
+6.  References
+
+6.1.  Normative References
+
+   [IEEE1363] IEEE, "Standard Specifications for Public Key
+              Cryptography", IEEE 1363, 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 30]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
+              2412, November 1998.
+
+   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
+              2631, June 1999.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Algorithms", RFC 3370, August 2002.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 2003.
+
+   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
+              Algorithm in Cryptographic Message Syntax (CMS)", RFC
+              3560, July 2003.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
+   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+              3852, July 2004.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
+
+   [RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              June 2005.
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 31]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation.
+
+   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding Rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).
+
+6.2.  Informative References
+
+   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
+              future, Designs, Codes, and Cryptography (1999)".  April
+              1999.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
+              2005.
+
+   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
+              Nicholas, "Internet X.509 Public Key Infrastructure:
+              Certification Path Building", RFC 4158, September 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 32]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+Appendix A.  PKINIT ASN.1 Module
+
+       KerberosV5-PK-INIT-SPEC {
+               iso(1) identified-organization(3) dod(6) internet(1)
+               security(5) kerberosV5(2) modules(4) pkinit(5)
+       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+       IMPORTS
+
+           SubjectPublicKeyInfo, AlgorithmIdentifier
+               FROM PKIX1Explicit88 { iso (1)
+                 identified-organization (3) dod (6) internet (1)
+                 security (5) mechanisms (5) pkix (7) id-mod (0)
+                 id-pkix1-explicit (18) }
+                 -- As defined in RFC 3280.
+
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum
+               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                 dod(6) internet(1) security(5) kerberosV5(2)
+                 modules(4) krb5spec2(2) };
+                 -- as defined in RFC 4120.
+
+       id-pkinit OBJECT IDENTIFIER ::=
+         { iso(1) identified-organization(3) dod(6) internet(1)
+           security(5) kerberosv5(2) pkinit (3) }
+
+       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
+       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
+       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
+       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
+       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
+
+       id-pkinit-san OBJECT IDENTIFIER ::=
+         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
+           x509SanAN (2) }
+
+       pa-pk-as-req INTEGER ::=                  16
+       pa-pk-as-rep INTEGER ::=                  17
+
+       ad-initial-verified-cas INTEGER ::=        9
+
+       td-trusted-certifiers INTEGER ::=        104
+       td-invalid-certificates INTEGER ::=      105
+       td-dh-parameters INTEGER ::=             109
+
+       PA-PK-AS-REQ ::= SEQUENCE {
+          signedAuthPack          [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded
+
+
+
+Zhu & Tung                  Standards Track                    [Page 33]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo
+                   -- is id-signedData (1.2.840.113549.1.7.2),
+                   -- and the content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type AuthPack.
+                   -- AuthPack is defined below.
+          trustedCertifiers       [1] SEQUENCE OF
+                      ExternalPrincipalIdentifier OPTIONAL,
+                   -- Contains a list of CAs, trusted by the client,
+                   -- that can be used to certify the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+                   -- The information contained in the
+                   -- trustedCertifiers SHOULD be used by the KDC as
+                   -- hints to guide its selection of an appropriate
+                   -- certificate chain to return to the client.
+          kdcPkId                 [2] IMPLICIT OCTET STRING
+                                      OPTIONAL,
+                   -- Contains a CMS type SignerIdentifier encoded
+                   -- according to [RFC3852].
+                   -- Identifies, if present, a particular KDC
+                   -- public key that the client already has.
+          ...
+       }
+
+       DHNonce ::= OCTET STRING
+
+       ExternalPrincipalIdentifier ::= SEQUENCE {
+          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a PKIX type Name encoded according to
+                   -- [RFC3280].
+                   -- Identifies the certificate subject by the
+                   -- distinguished subject name.
+                   -- REQUIRED when there is a distinguished subject
+                   -- name present in the certificate.
+         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Contains a CMS type IssuerAndSerialNumber encoded
+                   -- according to [RFC3852].
+                   -- Identifies a certificate of the subject.
+                   -- REQUIRED for TD-INVALID-CERTIFICATES and
+                   -- TD-TRUSTED-CERTIFIERS.
+         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
+                   -- Identifies the subject's public key by a key
+                   -- identifier.  When an X.509 certificate is
+                   -- referenced, this key identifier matches the X.509
+
+
+
+Zhu & Tung                  Standards Track                    [Page 34]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- subjectKeyIdentifier extension value.  When other
+                   -- certificate formats are referenced, the documents
+                   -- that specify the certificate format and their use
+                   -- with the CMS must include details on matching the
+                   -- key identifier to the appropriate certificate
+                   -- field.
+                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
+          ...
+       }
+
+       AuthPack ::= SEQUENCE {
+          pkAuthenticator         [0] PKAuthenticator,
+          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
+                   -- Type SubjectPublicKeyInfo is defined in
+                   -- [RFC3280].
+                   -- Specifies Diffie-Hellman domain parameters
+                   -- and the client's public key value [IEEE1363].
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+                   -- This field is present only if the client wishes
+                   -- to use the Diffie-Hellman key agreement method.
+          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
+                                      OPTIONAL,
+                   -- Type AlgorithmIdentifier is defined in
+                   -- [RFC3280].
+                   -- List of CMS algorithm [RFC3370] identifiers
+                   -- that identify key transport algorithms, or
+                   -- content encryption algorithms, or signature
+                   -- algorithms supported by the client in order of
+                   -- (decreasing) preference.
+          clientDHNonce           [3] DHNonce OPTIONAL,
+                   -- Present only if the client indicates that it
+                   -- wishes to reuse DH keys or to allow the KDC to
+                   -- do so.
+          ...
+       }
+
+       PKAuthenticator ::= SEQUENCE {
+          cusec                   [0] INTEGER (0..999999),
+          ctime                   [1] KerberosTime,
+                   -- cusec and ctime are used as in [RFC4120], for
+                   -- replay prevention.
+          nonce                   [2] INTEGER (0..4294967295),
+                   -- Chosen randomly; this nonce does not need to
+                   -- match with the nonce in the KDC-REQ-BODY.
+          paChecksum              [3] OCTET STRING OPTIONAL,
+                   -- MUST be present.
+                   -- Contains the SHA1 checksum, performed over
+
+
+
+Zhu & Tung                  Standards Track                    [Page 35]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                   -- KDC-REQ-BODY.
+          ...
+       }
+
+       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies a list of CAs trusted by the KDC.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Each ExternalPrincipalIdentifier identifies a
+                   -- certificate (sent by the client) with an invalid
+                   -- signature.
+
+       KRB5PrincipalName ::= SEQUENCE {
+           realm                   [0] Realm,
+           principalName           [1] PrincipalName
+       }
+
+       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
+                      ExternalPrincipalIdentifier
+                   -- Identifies the certification path based on which
+                   -- the client certificate was validated.
+                   -- Each ExternalPrincipalIdentifier identifies a CA
+                   -- or a CA certificate (thereby its public key).
+
+       PA-PK-AS-REP ::= CHOICE {
+          dhInfo                  [0] DHRepInfo,
+                   -- Selected when Diffie-Hellman key exchange is
+                   -- used.
+          encKeyPack              [1] IMPLICIT OCTET STRING,
+                   -- Selected when public key encryption is used.
+                   -- Contains a CMS type ContentInfo encoded
+                   -- according to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-envelopedData (1.2.840.113549.1.7.3).
+                   -- The content field is an EnvelopedData.
+                   -- The contentType field for the type EnvelopedData
+                   -- is id-signedData (1.2.840.113549.1.7.2).
+                   -- The eContentType field for the inner type
+                   -- SignedData (when unencrypted) is
+                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
+                   -- eContent field contains the DER encoding of the
+                   -- type ReplyKeyPack.
+                   -- ReplyKeyPack is defined below.
+          ...
+
+
+
+Zhu & Tung                  Standards Track                    [Page 36]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+       }
+
+       DHRepInfo ::= SEQUENCE {
+          dhSignedData            [0] IMPLICIT OCTET STRING,
+                   -- Contains a CMS type ContentInfo encoded according
+                   -- to [RFC3852].
+                   -- The contentType field of the type ContentInfo is
+                   -- id-signedData (1.2.840.113549.1.7.2), and the
+                   -- content field is a SignedData.
+                   -- The eContentType field for the type SignedData is
+                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
+                   -- eContent field contains the DER encoding of the
+                   -- type KDCDHKeyInfo.
+                   -- KDCDHKeyInfo is defined below.
+          serverDHNonce           [1] DHNonce OPTIONAL,
+                   -- Present if and only if dhKeyExpiration is
+                   -- present.
+          ...
+       }
+
+       KDCDHKeyInfo ::= SEQUENCE {
+          subjectPublicKey        [0] BIT STRING,
+                   -- The KDC's DH public key.
+                   -- The DH public key value is encoded as a BIT
+                   -- STRING according to [RFC3279].
+          nonce                   [1] INTEGER (0..4294967295),
+                   -- Contains the nonce in the pkAuthenticator field
+                   -- in the request if the DH keys are NOT reused,
+                   -- 0 otherwise.
+          dhKeyExpiration         [2] KerberosTime OPTIONAL,
+                   -- Expiration time for KDC's key pair,
+                   -- present if and only if the DH keys are reused.
+                   -- If present, the KDC's DH public key MUST not be
+                   -- used past the point of this expiration time.
+                   -- If this field is omitted then the serverDHNonce
+                   -- field MUST also be omitted.
+          ...
+       }
+
+       ReplyKeyPack ::= SEQUENCE {
+          replyKey                [0] EncryptionKey,
+                   -- Contains the session key used to encrypt the
+                   -- enc-part field in the AS-REP, i.e., the
+                   -- AS reply key.
+          asChecksum              [1] Checksum,
+                  -- Contains the checksum of the AS-REQ
+                  -- corresponding to the containing AS-REP.
+                  -- The checksum is performed over the type AS-REQ.
+
+
+
+Zhu & Tung                  Standards Track                    [Page 37]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+                  -- The protocol key [RFC3961] of the checksum is the
+                  -- replyKey and the key usage number is 6.
+                  -- If the replyKey's enctype is "newer" [RFC4120]
+                  -- [RFC4121], the checksum is the required
+                  -- checksum operation [RFC3961] for that enctype.
+                  -- The client MUST verify this checksum upon receipt
+                  -- of the AS-REP.
+          ...
+       }
+
+       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
+                   -- Each AlgorithmIdentifier specifies a set of
+                   -- Diffie-Hellman domain parameters [IEEE1363].
+                   -- This list is in decreasing preference order.
+       END
+
+Appendix B.  Test Vectors
+
+   Function octetstring2key() is defined in Section 3.2.3.1.  This
+   section describes a few sets of test vectors that would be useful for
+   implementers of octetstring2key().
+
+   Set 1:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
+     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 38]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   Set 2:
+   =====
+   Input octet string x is:
+
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
+     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
+
+
+   Set 3:
+   ======
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
+     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
+     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
+     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
+     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
+
+
+   Set 4:
+   =====
+   Input octet string x is:
+
+     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
+     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
+     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
+     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
+     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 39]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+   Output of K-truncate() when the key size is 32 octets:
+
+     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
+     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
+
+Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
+             Implementations
+
+   Earlier revisions of the PKINIT I-D were implemented in various
+   releases of Microsoft Windows and deployed in fairly large numbers.
+   To enable the community to interoperate better with systems running
+   those releases, the following information may be useful.
+
+   KDC certificates issued by Windows 2000 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, and the
+   id-kp-serverAuth EKU [RFC3280].
+
+   KDC certificates issued by Windows 2003 Enterprise CAs contain a
+   dNSName SAN with the DNS name of the host running the KDC, the id-
+   kp-serverAuth EKU, and the id-ms-kp-sc-logon EKU.
+
+   It is anticipated that the next release of Windows is already too far
+   along to allow it to support the issuing KDC certificates with id-
+   pkinit-san SAN as specified in this RFC.  Instead, they will have a
+   dNSName SAN containing the domain name of the KDC, and the intended
+   purpose of these KDC certificates will be restricted by the presence
+   of the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
+
+   In addition to checking that the above are present in a KDC
+   certificate, Windows clients verify that the issuer of the KDC
+   certificate is one of a set of allowed issuers of such certificates,
+   so those wishing to issue KDC certificates need to configure their
+   Windows clients appropriately.
+
+   Client certificates accepted by Windows 2000 and Windows 2003 Server
+   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
+   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
+   contains a UTF8-encoded string whose value is that of the Directory
+   Service attribute UserPrincipalName of the client account object, and
+   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
+   certificate is to validate the client mapping (in other words, the
+   client's public key is bound to the account that has this
+   UserPrincipalName value).
+
+   It should be noted that all Microsoft Kerberos realm names are
+   domain-style realm names and strictly in uppercase.  In addition, the
+   UserPrincipalName attribute is globally unique in Windows 2000 and
+   Windows 2003.
+
+
+
+Zhu & Tung                  Standards Track                    [Page 40]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Brian Tung
+   Aerospace Corporation
+   2350 E. El Segundo Blvd.
+   El Segundo, CA  90245
+   US
+
+   EMail: brian@aero.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 41]
+
+RFC 4556                         PKINIT                        June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zhu & Tung                  Standards Track                    [Page 42]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4557.txt b/third_party/heimdal/doc/standardisation/rfc4557.txt
new file mode 100644
index 00000000000..fe9a8810df8
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4557.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                             L. Zhu
+Request for Comments: 4557                                 K. Jaganathan
+Category: Standards Track                          Microsoft Corporation
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                               June 2006
+
+
+         Online Certificate Status Protocol (OCSP) Support for
+                      Public Key Cryptography for
+              Initial Authentication in Kerberos (PKINIT)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a mechanism to enable in-band transmission of
+   Online Certificate Status Protocol (OCSP) responses in the Kerberos
+   network authentication protocol.  These responses are used to verify
+   the validity of the certificates used in Public Key Cryptography for
+   Initial Authentication in Kerberos (PKINIT), which is the Kerberos
+   Version 5 extension that provides for the use of public key
+   cryptography.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. Message Definition ..............................................2
+   4. Security Considerations .........................................3
+   5. Acknowledgements ................................................4
+   6. References ......................................................4
+      6.1. Normative References .......................................4
+      6.2. Informative References .....................................4
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 1]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+1.  Introduction
+
+   Online Certificate Status Protocol (OCSP) [RFC2560] enables
+   applications to obtain timely information regarding the revocation
+   status of a certificate.  Because OCSP responses are well bounded and
+   small in size, constrained clients may wish to use OCSP to check the
+   validity of the certificates for Kerberos Key Distribution Center
+   (KDC) in order to avoid transmission of large Certificate Revocation
+   Lists (CRLs) and therefore save bandwidth on constrained networks
+   [OCSP-PROFILE].
+
+   This document defines a pre-authentication type [RFC4120], where the
+   client and the KDC MAY piggyback OCSP responses for certificates used
+   in authentication exchanges, as defined in [RFC4556].
+
+   By using this OPTIONAL extension, PKINIT clients and the KDC can
+   maximize the reuse of cached OCSP responses.
+
+2.  Conventions Used in This Document
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+3.  Message Definition
+
+   A pre-authentication type identifier is defined for this mechanism:
+
+              PA-PK-OCSP-RESPONSE              18
+
+   The corresponding padata-value field [RFC4120] contains the DER [X60]
+   encoding of the following ASN.1 type:
+
+          PKOcspData ::= SEQUENCE OF OcspResponse
+                         -- If more than one OcspResponse is
+                         -- included, the first OcspResponse
+                         -- MUST contain the OCSP response
+                         -- for the signer's certificate.
+                         -- The signer refers to the client for
+                         -- AS-REQ, and the KDC for the AS-REP,
+                         -- respectively.
+
+          OcspResponse ::= OCTET STRING
+                         -- Contains a complete OCSP response,
+                         -- as defined in [RFC2560].
+
+   The client MAY send OCSP responses for certificates used in PA-PK-
+   AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
+
+
+
+Zhu, et al.                 Standards Track                     [Page 2]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+   The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK-
+   OCSP-RESPONSE containing OCSP responses for certificates used in the
+   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
+   using a PKOcspData containing an empty sequence.
+
+   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+   PA-PK-OCSP-RESPONSE from the client.
+
+   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+   certificates used in PA-PK-AS-REP [RFC4556].
+
+   Note the lack of integrity protection for the empty or missing OCSP
+   response; lack of an expected OCSP response from the KDC for the
+   KDC's certificates SHOULD be treated as an error by the client,
+   unless it is configured otherwise.
+
+   When using OCSP, the response is signed by the OCSP server, which is
+   trusted by the receiver.  Depending on local policy, further
+   verification of the validity of the OCSP servers may be needed
+
+   The client and the KDC SHOULD ignore invalid OCSP responses received
+   via this mechanism, and they MAY implement CRL processing logic as a
+   fall-back position, if the OCSP responses received via this mechanism
+   alone are not sufficient for the verification of certificate
+   validity.  The client and/or the KDC MAY ignore a valid OCSP response
+   and perform its own revocation status verification independently.
+
+4.  Security Considerations
+
+   The pre-authentication data in this document do not actually
+   authenticate any principals, but are designed to be used in
+   conjunction with PKINIT.
+
+   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
+   data and PKINIT pre-authentication data other than a given OCSP
+   response corresponding to a certificate used in a PKINIT pre-
+   authentication data element.  Attacks involving removal or
+   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
+   are, at worst, downgrade attacks, where a PKINIT client or KDC would
+   proceed without use of CRLs or OCSP for certificate validation, or
+   denial-of-service attacks, where a PKINIT client or KDC that cannot
+   validate the other's certificate without an accompanying OCSP
+   response might reject the AS exchange or might have to download very
+   large CRLs in order to continue.  Kerberos V does not protect against
+   denial-of-service attacks; therefore, the denial-of-service aspect of
+   these attacks is acceptable.
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 3]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+   If a PKINIT client or KDC cannot validate certificates without the
+   aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS
+   exchange, possibly according to local configuration.
+
+5.  Acknowledgements
+
+   This document was based on conversations among the authors, Jeffrey
+   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
+   working group.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]      Myers, M., Ankney, R., Malpani, A., Galperin, S., and
+                  C. Adams, "X.509 Internet Public Key Infrastructure
+                  Online Certificate Status Protocol - OCSP", RFC 2560,
+                  June 1999.
+
+   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                  Kerberos Network Authentication Service (V5)", RFC
+                  4120, July 2005.
+
+   [RFC4556]      Zhu, L. and B. Tung, "Public Key Cryptography for
+                  Initial Authentication in Kerberos (PKINIT)", RFC
+                  4556, June 2006.
+
+   [X690]         ASN.1 encoding rules: Specification of Basic Encoding
+                  Rules (BER), Canonical Encoding Rules (CER) and
+                  Distinguished Encoding Rules (DER), ITU-T
+                  Recommendation X.690 (1997) | ISO/IEC International
+                  Standard 8825-1:1998.
+
+6.2.  Informative References
+
+   [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
+                  High Volume Environments", Work in Progress, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 4]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 5]
+
+RFC 4557                OCSP Support for PKINIT                June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zhu, et al.                 Standards Track                     [Page 6]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc4559.txt b/third_party/heimdal/doc/standardisation/rfc4559.txt
new file mode 100644
index 00000000000..fa63f621e50
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc4559.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      K. Jaganathan
+Request for Comments: 4559                                        L. Zhu
+Category: Informational                                        J. Brezak
+                                                   Microsoft Corporation
+                                                               June 2006
+
+
+           SPNEGO-based Kerberos and NTLM HTTP Authentication
+                          in Microsoft Windows
+
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how the Microsoft Internet Explorer (MSIE)
+   and Internet Information Services (IIS) incorporated in Microsoft
+   Windows 2000 use Kerberos for security enhancements of web
+   transactions.  The Hypertext Transport Protocol (HTTP) auth-scheme of
+   "negotiate" is defined here; when the negotiation results in the
+   selection of Kerberos, the security services of authentication and,
+   optionally, impersonation (the IIS server assumes the windows
+   identity of the principal that has been authenticated) are performed.
+   This document explains how HTTP authentication utilizes the Simple
+   and Protected GSS-API Negotiation mechanism.  Details of Simple And
+   Protected Negotiate (SPNEGO) implementation are not provided in this
+   document.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. Access Authentication ...........................................2
+      3.1. Reliance on the HTTP/1.1 Specification .....................2
+   4. HTTP Negotiate Authentication Scheme ............................2
+      4.1. The WWW-Authenticate Response Header .......................2
+   5. Negotiate Operation Example .....................................4
+   6. Security Considerations .........................................5
+   7. Normative References ............................................6
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 1]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+1.  Introduction
+
+   Microsoft has provided support for Kerberos authentication in
+   Microsoft Internet Explorer (MSIE) and Internet Information Services
+   (IIS), in addition to other mechanisms.  This provides the benefits
+   of the Kerberos v5 protocol for Web applications.
+
+   Support for Kerberos authentication is based on other previously
+   defined mechanisms, such as SPNEGO Simple And Protected Negotiate
+   (SPNEGO) [RFC4178] and the Generic Security Services Application
+   Program Interface(GSSAPI).
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
+   be interpreted as described in [RFC2119].
+
+3.  Access Authentication
+
+3.1.  Reliance on the HTTP/1.1 Specification
+
+   This specification is a companion to the HTTP/1.1 specification
+   [RFC2616], and it builds on the authentication mechanisms defined in
+   [RFC2617].  It uses the augmented BNF section of that document (2.1),
+   and it relies on both the non-terminals defined in that document and
+   other aspects of the HTTP/1.1 specification.
+
+4.  HTTP Negotiate Authentication Scheme
+
+   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".
+   The auth-params exchanged use data formats defined for use with the
+   GSS-API [RFC2743].  In particular, they follow the formats set for
+   the SPNEGO [RFC4178] and Kerberos [RFC4121] mechanisms for GSSAPI.
+   The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens
+   that the specific mechanism type specifies.
+
+   The current implementation of this protocol is limited to the use of
+   SPNEGO with the Kerberos and Microsoft(NT Lan Manager) NTLM
+   protocols.
+
+4.1.  The WWW-Authenticate Response Header
+
+   If the server receives a request for an access-protected object, and
+   if an acceptable Authorization header has not been sent, the server
+   responds with a "401 Unauthorized" status code, and a "WWW-
+   Authenticate:" header as per the framework described in [RFC2616].
+   The initial WWW-Authenticate header will not carry any gssapi-data.
+
+
+
+Jaganathan, et al.           Informational                      [Page 2]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+   The negotiate scheme will operate as follows:
+
+           challenge       = "Negotiate" auth-data
+           auth-data       = 1#( [gssapi-data] )
+
+   The meanings of the values of the directives used above are as
+   follows:
+
+   gssapi-data
+
+   If the gss_accept_security_context returns a token for the client,
+   this directive contains the base64 encoding of an
+   initialContextToken, as defined in [RFC2743].  This is not present in
+   the initial response from the server.
+
+   A status code 200 status response can also carry a "WWW-Authenticate"
+   response header containing the final leg of an authentication.  In
+   this case, the gssapi-data will be present.  Before using the
+   contents of the response, the gssapi-data should be processed by
+   gss_init_security_context to determine the state of the security
+   context.  If this function indicates success, the response can be
+   used by the application.  Otherwise, an appropriate action, based on
+   the authentication status, should be taken.
+
+   For example, the authentication could have failed on the final leg if
+   mutual authentication was requested and the server was not able to
+   prove its identity.  In this case, the returned results are suspect.
+   It is not always possible to mutually authenticate the server before
+   the HTTP operation.  POST methods are in this category.
+
+   When the Kerberos Version 5 GSSAPI mechanism [RFC4121] is being used,
+   the HTTP server will be using a principal name of the form of
+   "HTTP/hostname".
+
+4.2.  The Authorization Request Header
+
+   Upon receipt of the response containing a "WWW-Authenticate" header
+   from the server, the client is expected to retry the HTTP request,
+   passing a HTTP "Authorization" header line.  This is defined
+   according to the framework described in [RFC2616] and is utilized as
+   follows:
+
+           credentials             = "Negotiate" auth-data2
+           auth-data2              = 1#( gssapi-data )
+
+   gssapi-data
+
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 3]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+   This directive contains the base64 encoding of an
+   InitialContextToken, as defined in [RFC2743].
+
+   Any returned code other than a success 2xx code represents an
+   authentication error.  If a 401 containing a "WWW-Authenticate"
+   header with "Negotiate" and gssapi-data is returned from the server,
+   it is a continuation of the authentication request.
+
+   A client may initiate a connection to the server with an
+   "Authorization" header containing the initial token for the server.
+   This form will bypass the initial 401 error from the server when the
+   client knows that the server will accept the Negotiate HTTP
+   authentication type.
+
+5.  Negotiate Operation Example
+
+   The client requests an access-protected document from server via a
+   GET method request.  The URI of the document is
+   "http://www.nowhere.org/dir/index.html".
+
+           C: GET dir/index.html
+
+   The first time the client requests the document, no Authorization
+   header is sent, so the server responds with
+
+           S: HTTP/1.1 401 Unauthorized
+           S: WWW-Authenticate: Negotiate
+
+   The client will obtain the user credentials using the SPNEGO GSSAPI
+   mechanism type to identify generate a GSSAPI message to be sent to
+   the server with a new request, including the following Authorization
+   header:
+
+           C: GET dir/index.html
+           C: Authorization: Negotiate a87421000492aa874209af8bc028
+
+   The server will decode the gssapi-data and pass this to the SPNEGO
+   GSSAPI mechanism in the gss_accept_security_context function.  If the
+   context is not complete, the server will respond with a 401 status
+   code with a WWW-Authenticate header containing the gssapi-data.
+
+           S: HTTP/1.1 401 Unauthorized
+           S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356
+
+   The client will decode the gssapi-data, pass this into
+   Gss_Init_security_context, and return the new gssapi-data to the
+   server.
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 4]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+           C: GET dir/index.html
+           C: Authorization: Negotiate 89a8742aa8729a8b028
+
+   This cycle can continue until the security context is complete.  When
+   the return value from the gss_accept_security_context function
+   indicates that the security context is complete, it may supply final
+   authentication data to be returned to the client.  If the server has
+   more gssapi data to send to the client to complete the context, it is
+   to be carried in a WWW-Authenticate header with the final response
+   containing the HTTP body.
+
+           S: HTTP/1.1 200 Success
+           S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca
+
+   The client will decode the gssapi-data and supply it to
+   gss_init_security_context using the context for this server.  If the
+   status is successful from the final gss_init_security_context, the
+   response can be used by the application.
+
+6.  Security Considerations
+
+   The SPNEGO HTTP authentication facility is only used to provide
+   authentication of a user to a server.  It provides no facilities for
+   protecting the HTTP headers or data including the Authorization and
+   WWW-Authenticate headers that are used to implement this mechanism.
+
+   Alternate mechanisms such as TLS can be used to provide
+   confidentiality.  Hashes of the TLS certificates can be used as
+   channel bindings to secure the channel.  In this case clients would
+   need to enforce that the channel binding information is valid.  Note
+   that Kerb-TLS [RFC2712] could be used to provide both authentication
+   and confidentiality, but this requires a change to the TLS provider.
+
+   This mechanism is not used for HTTP authentication to HTTP proxies.
+
+   If an HTTP proxy is used between the client and server, it must take
+   care to not share authenticated connections between different
+   authenticated clients to the same server.  If this is not honored,
+   then the server can easily lose track of security context
+   associations.  A proxy that correctly honors client to server
+   authentication integrity will supply the "Proxy-support:  Session-
+   Based-Authentication" HTTP header to the client in HTTP responses
+   from the proxy.  The client MUST NOT utilize the SPNEGO HTTP
+   authentication mechanism through a proxy unless the proxy supplies
+   this header with the "401 Unauthorized" response from the server.
+
+
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 5]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+   When using the SPNEGO HTTP authentication facility with client-
+   supplied data such as PUT and POST, the authentication should be
+   complete between the client and server before sending the user data.
+   The return status from the gss_init_security_context will indicate
+   that the security context is complete.  At this point, the data can
+   be sent to the server.
+
+7.  Normative References
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2", 2, Update 1", 2743, January 2000.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected GSS-API Generic Security Service
+              Application Program Interface (GSS-API) Negotiation
+              Mechanism", 4178, October 2005.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+              Leach, P., Luotonen, A., and L. Stewart, "HTTP
+              Authentication: Basic and Digest Access Authentication",
+              RFC 2617, June 1999.
+
+   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
+              Suites to Transport Layer Security (TLS)", RFC 2712,
+              October 1999.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
+              2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 6]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+Authors' Addresses
+
+   Karthik Jaganathan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: karthikj@microsoft.com
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+   John Brezak
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: jbrezak@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 7]
+
+RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Jaganathan, et al.           Informational                      [Page 8]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc5587.txt b/third_party/heimdal/doc/standardisation/rfc5587.txt
new file mode 100644
index 00000000000..1670bc58fb0
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc5587.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                        N. Williams
+Request for Comments: 5587                                           Sun
+Category: Standards Track                                      July 2009
+
+
+        Extended Generic Security Service Mechanism Inquiry APIs
+
+Abstract
+
+   This document introduces new application programming interfaces
+   (APIs) to the Generic Security Services API (GSS-API) for extended
+   mechanism attribute inquiry.  These interfaces are primarily intended
+   to reduce instances of hardcoding of mechanism identifiers in GSS
+   applications.
+
+   These interfaces include mechanism attributes and attribute sets, a
+   function for inquiring the attributes of a mechanism, a function for
+   indicating mechanisms that possess given attributes, and a function
+   for displaying mechanism attributes.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 1]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. New GSS-API Interfaces ..........................................3
+      3.1. Mechanism Attributes and Attribute Sets ....................3
+      3.2. List of Known Mechanism Attributes .........................4
+      3.3. Mechanism Attribute Sets of Existing Mechs .................6
+      3.4. New GSS-API Function Interfaces ............................8
+           3.4.1. Mechanism Attribute Criticality .....................8
+           3.4.2. GSS_Indicate_mechs_by_attrs() .......................9
+           3.4.3. GSS_Inquire_attrs_for_mech() .......................10
+           3.4.4. GSS_Display_mech_attr() ............................10
+           3.4.5. New Major Status Values ............................11
+           3.4.6. C-Bindings .........................................11
+   4. Requirements for Mechanism Designers ...........................13
+   5. IANA Considerations ............................................13
+   6. Security Considerations ........................................13
+   7. References .....................................................13
+      7.1. Normative References ......................................13
+      7.2. Informative References ....................................14
+Appendix A. Typedefs and C Bindings ..................................15
+
+1.  Introduction
+
+   GSS-API [RFC2743] mechanisms have a number of properties that may be
+   of interest to applications.  The lack of APIs for inquiring about
+   available mechanisms' properties has meant that many GSS-API
+   applications must hardcode mechanism Object Identifiers (OIDs).
+   Ongoing work may result in a variety of new GSS-API mechanisms.
+   Applications should not have to hardcode their OIDs.
+
+   For example, the Secure Shell version 2 (SSHv2) protocol [RFC4251]
+   supports the use of GSS-API mechanisms for authentication [RFC4462]
+   but explicitly prohibits the use of Simple and Protected GSS-API
+   Negotiation (SPNEGO) [RFC4178].  Future mechanisms that negotiate
+   mechanisms would have to be forbidden as well, but there is no way to
+   implement applications that inquire what mechanisms are available and
+   then programmatically exclude mechanisms "like SPNEGO".
+
+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 [RFC2119].
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 2]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+3.  New GSS-API Interfaces
+
+   We introduce a new concept -- that of mechanism attributes.  By
+   allowing applications to query the set of attributes associated with
+   individual mechanisms and to find out which mechanisms support a
+   given set of attributes, we allow applications to select mechanisms
+   based on their attributes without having to hardcode mechanism OIDs.
+
+   Section 3.1 describes the mechanism attributes concept.  Sections
+   3.4.2, 3.4.3, and 3.4.4 describe three new interfaces that deal in
+   mechanisms and attribute sets:
+
+   o  GSS_Indicate_mechs_by_attrs()
+
+   o  GSS_Inquire_attrs_for_mech()
+
+   o  GSS_Display_mech_attr()
+
+3.1.  Mechanism Attributes and Attribute Sets
+
+   An abstraction for the features provided by mechanisms and pseudo-
+   mechanisms is needed in order to facilitate the programmatic
+   selection of mechanisms.  Pseudo-mechanisms are mechanisms that make
+   reference to other mechanisms in order to provide their services.
+   For example, SPNEGO is a pseudo-mechanism, for without other
+   mechanisms SPNEGO is useless.
+
+   Two data types are needed: one for individual mechanism attributes
+   and one for mechanism attribute sets.  To simplify the mechanism
+   attribute interfaces, we reuse the 'OID' and 'OID set' data types and
+   model individual mechanism attribute types as OIDs.
+
+   To this end, we define an open namespace of mechanism attributes and
+   assign them arcs off of this OID:
+
+   <1.3.6.1.5.5.13>
+
+   Each mechanism has a set of mechanism attributes that it supports as
+   described in its specification.
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 3]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+3.2.  List of Known Mechanism Attributes
+
+      +-------------------------+---------+-------------------------+
+      | Mech Attr Name          | OID Arc | Arc Name                |
+      +-------------------------+---------+-------------------------+
+      | GSS_C_MA_MECH_CONCRETE  |     (1) | concrete-mech           |
+      | GSS_C_MA_MECH_PSEUDO    |     (2) | pseudo-mech             |
+      | GSS_C_MA_MECH_COMPOSITE |     (3) | composite-mech          |
+      | GSS_C_MA_MECH_NEGO      |     (4) | mech-negotiation-mech   |
+      | GSS_C_MA_MECH_GLUE      |     (5) | mech-glue               |
+      | GSS_C_MA_NOT_MECH       |     (6) | not-mech                |
+      | GSS_C_MA_DEPRECATED     |     (7) | mech-deprecated         |
+      | GSS_C_MA_NOT_DFLT_MECH  |     (8) | mech-not-default        |
+      | GSS_C_MA_ITOK_FRAMED    |     (9) | initial-is-framed       |
+      | GSS_C_MA_AUTH_INIT      |    (10) | auth-init-princ         |
+      | GSS_C_MA_AUTH_TARG      |    (11) | auth-targ-princ         |
+      | GSS_C_MA_AUTH_INIT_INIT |    (12) | auth-init-princ-initial |
+      | GSS_C_MA_AUTH_TARG_INIT |    (13) | auth-targ-princ-initial |
+      | GSS_C_MA_AUTH_INIT_ANON |    (14) | auth-init-princ-anon    |
+      | GSS_C_MA_AUTH_TARG_ANON |    (15) | auth-targ-princ-anon    |
+      | GSS_C_MA_DELEG_CRED     |    (16) | deleg-cred              |
+      | GSS_C_MA_INTEG_PROT     |    (17) | integ-prot              |
+      | GSS_C_MA_CONF_PROT      |    (18) | conf-prot               |
+      | GSS_C_MA_MIC            |    (19) | mic                     |
+      | GSS_C_MA_WRAP           |    (20) | wrap                    |
+      | GSS_C_MA_PROT_READY     |    (21) | prot-ready              |
+      | GSS_C_MA_REPLAY_DET     |    (22) | replay-detection        |
+      | GSS_C_MA_OOS_DET        |    (23) | oos-detection           |
+      | GSS_C_MA_CBINDINGS      |    (24) | channel-bindings        |
+      | GSS_C_MA_PFS            |    (25) | pfs                     |
+      | GSS_C_MA_COMPRESS       |    (26) | compress                |
+      | GSS_C_MA_CTX_TRANS      |    (27) | context-transfer        |
+      | <reserved>              | (28...) |                         |
+      +-------------------------+---------+-------------------------+
+
+                                  Table 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 4]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+   +-------------------------+-----------------------------------------+
+   | Mech Attr Name          | Purpose                                 |
+   +-------------------------+-----------------------------------------+
+   | GSS_C_MA_MECH_CONCRETE  | Indicates that a mech is neither a      |
+   |                         | pseudo-mechanism nor a composite        |
+   |                         | mechanism.                              |
+   | GSS_C_MA_MECH_PSEUDO    | Indicates that a mech is a              |
+   |                         | pseudo-mechanism.                       |
+   | GSS_C_MA_MECH_COMPOSITE | Indicates that a mech is a composite of |
+   |                         | other mechanisms.  This is reserved for |
+   |                         | a specification of "stackable"          |
+   |                         | pseudo-mechanisms.                      |
+   | GSS_C_MA_MECH_NEGO      | Indicates that a mech negotiates other  |
+   |                         | mechs (e.g., SPNEGO has this            |
+   |                         | attribute).                             |
+   | GSS_C_MA_MECH_GLUE      | Indicates that the OID is not for a     |
+   |                         | mechanism but for the GSS-API itself.   |
+   | GSS_C_MA_NOT_MECH       | Indicates that the OID is known, yet it |
+   |                         | is also known not to be the OID of any  |
+   |                         | GSS-API mechanism (or of the GSS-API    |
+   |                         | itself).                                |
+   | GSS_C_MA_DEPRECATED     | Indicates that a mech (or its OID) is   |
+   |                         | deprecated and MUST NOT be used as a    |
+   |                         | default mechanism.                      |
+   | GSS_C_MA_NOT_DFLT_MECH  | Indicates that a mech (or its OID) MUST |
+   |                         | NOT be used as a default mechanism.     |
+   | GSS_C_MA_ITOK_FRAMED    | Indicates that the given mechanism's    |
+   |                         | initial context tokens are properly     |
+   |                         | framed as per Section 3.1 of [RFC2743]. |
+   | GSS_C_MA_AUTH_INIT      | Indicates support for authentication of |
+   |                         | initiator to acceptor.                  |
+   | GSS_C_MA_AUTH_TARG      | Indicates support for authentication of |
+   |                         | acceptor to initiator.                  |
+   | GSS_C_MA_AUTH_INIT_INIT | Indicates support for "initial"         |
+   |                         | authentication of initiator to          |
+   |                         | acceptor.  "Initial authentication"     |
+   |                         | refers to the use of passwords, or keys |
+   |                         | stored on tokens, for authentication.   |
+   |                         | Whether a mechanism supports initial    |
+   |                         | authentication may depend on IETF       |
+   |                         | consensus (see Security                 |
+   |                         | Considerations).                        |
+   | GSS_C_MA_AUTH_TARG_INIT | Indicates support for initial           |
+   |                         | authentication of acceptor to           |
+   |                         | initiator.                              |
+   | GSS_C_MA_AUTH_INIT_ANON | Indicates support for                   |
+   |                         | GSS_C_NT_ANONYMOUS as an initiator      |
+   |                         | principal name.                         |
+
+
+
+Williams                    Standards Track                     [Page 5]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+   | GSS_C_MA_AUTH_TARG_ANON | Indicates support for                   |
+   |                         | GSS_C_NT_ANONYMOUS as a target          |
+   |                         | principal name.                         |
+   | GSS_C_MA_DELEG_CRED     | Indicates support for credential        |
+   |                         | delegation.                             |
+   | GSS_C_MA_INTEG_PROT     | Indicates support for per-message       |
+   |                         | integrity protection.                   |
+   | GSS_C_MA_CONF_PROT      | Indicates support for per-message       |
+   |                         | confidentiality protection.             |
+   | GSS_C_MA_MIC            | Indicates support for Message Integrity |
+   |                         | Code (MIC) tokens.                      |
+   | GSS_C_MA_WRAP           | Indicates support for WRAP tokens.      |
+   | GSS_C_MA_PROT_READY     | Indicates support for per-message       |
+   |                         | protection prior to full context        |
+   |                         | establishment.                          |
+   | GSS_C_MA_REPLAY_DET     | Indicates support for replay detection. |
+   | GSS_C_MA_OOS_DET        | Indicates support for out-of-sequence   |
+   |                         | detection.                              |
+   | GSS_C_MA_CBINDINGS      | Indicates support for channel bindings. |
+   | GSS_C_MA_PFS            | Indicates support for Perfect Forward   |
+   |                         | Security.                               |
+   | GSS_C_MA_COMPRESS       | Indicates support for compression of    |
+   |                         | data inputs to GSS_Wrap().              |
+   | GSS_C_MA_CTX_TRANS      | Indicates support for security context  |
+   |                         | export/import.                          |
+   +-------------------------+-----------------------------------------+
+
+                                  Table 2
+
+3.3.  Mechanism Attribute Sets of Existing Mechs
+
+   The Kerberos V mechanism [RFC1964] provides the following mechanism
+   attributes:
+
+   o  GSS_C_MA_MECH_CONCRETE
+
+   o  GSS_C_MA_ITOK_FRAMED
+
+   o  GSS_C_MA_AUTH_INIT
+
+   o  GSS_C_MA_AUTH_TARG
+
+   o  GSS_C_MA_DELEG_CRED
+
+   o  GSS_C_MA_INTEG_PROT
+
+   o  GSS_C_MA_CONF_PROT
+
+
+
+
+Williams                    Standards Track                     [Page 6]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+   o  GSS_C_MA_MIC
+
+   o  GSS_C_MA_WRAP
+
+   o  GSS_C_MA_PROT_READY
+
+   o  GSS_C_MA_REPLAY_DET
+
+   o  GSS_C_MA_OOS_DET
+
+   o  GSS_C_MA_CBINDINGS
+
+   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
+      specific exported context token formats)
+
+   The Kerberos V mechanism also has a deprecated OID that has the same
+   mechanism attributes as above as well as GSS_C_MA_DEPRECATED.
+
+   The mechanism attributes of the Simple Public-Key GSS-API Mechanism
+   (SPKM) [RFC2025] family of mechanisms will be provided in a separate
+   document, as SPKM is currently being reviewed for possibly
+   significant changes due to problems in its specifications.
+
+   The Low Infrastructure Public Key (LIPKEY) mechanism [RFC2847] offers
+   the following attributes:
+
+   o  GSS_C_MA_MECH_CONCRETE
+
+   o  GSS_C_MA_ITOK_FRAMED
+
+   o  GSS_C_MA_AUTH_INIT_INIT
+
+   o  GSS_C_MA_AUTH_TARG (from SPKM-3)
+
+   o  GSS_C_MA_AUTH_TARG_ANON (from SPKM-3)
+
+   o  GSS_C_MA_INTEG_PROT
+
+   o  GSS_C_MA_CONF_PROT
+
+   o  GSS_C_MA_REPLAY_DET
+
+   o  GSS_C_MA_OOS_DET
+
+   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
+      specific exported context token formats)
+
+
+
+
+
+Williams                    Standards Track                     [Page 7]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+      (LIPKEY should also provide GSS_C_MA_CBINDINGS, but SPKM-3
+      requires clarifications on this point.)
+
+   The SPNEGO mechanism [RFC4178] provides the following attributes:
+
+   o  GSS_C_MA_MECH_NEGO
+
+   o  GSS_C_MA_ITOK_FRAMED
+
+   All other mechanisms' attributes will be described elsewhere.
+
+3.4.  New GSS-API Function Interfaces
+
+   Several new interfaces are given by which, for example, GSS-API
+   applications may determine what features are provided by a given
+   mechanism and what mechanisms provide what features.
+
+   These new interfaces are all OPTIONAL.
+
+   Applications should use GSS_Indicate_mechs_by_attrs() instead of
+   GSS_Indicate_mechs() wherever possible.
+
+   Applications can use GSS_Indicate_mechs_by_attrs() to determine what,
+   if any, mechanisms provide a given set of features.
+
+   GSS_Indicate_mechs_by_attrs() can also be used to indicate (as in
+   GSS_Indicate_mechs()) the set of available mechanisms of each type
+   (concrete, mechanism negotiation pseudo-mechanism, etc.).
+
+3.4.1.  Mechanism Attribute Criticality
+
+   Mechanism attributes may be added at any time.  Not only may
+   attributes be added to the list of known mechanism attributes at any
+   time, but the set of mechanism attributes supported by a mechanism
+   can be changed at any time.
+
+   For example, new attributes might be added to reflect whether a
+   mechanism's initiator must contact an online infrastructure and/or
+   whether the acceptor must do so.  In this example, the Kerberos V
+   mechanism would gain a new attribute even though the mechanism itself
+   is not modified.
+
+   Applications making use of attributes not defined herein would then
+   have no way of knowing whether a GSS-API implementation and its
+   mechanisms know about new mechanism attributes.  To address this
+   problem, GSS_Indicate_mechs_by_attrs() and
+   GSS_Inquire_attrs_for_mech() support a notion of critical mechanism
+   attributes.  Applications can search for mechanisms that understand
+
+
+
+Williams                    Standards Track                     [Page 8]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+   mechanism attributes that are critical to the application, and the
+   application may ask what mechanism attributes are understood by a
+   given mechanism.
+
+3.4.2.  GSS_Indicate_mechs_by_attrs()
+
+   Inputs:
+
+   o  desired_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
+      OIDs that the mechanisms indicated in the mechs output parameter
+      MUST offer.
+
+   o  except_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
+      OIDs that the mechanisms indicated in the mechs output parameter
+      MUST NOT offer.
+
+   o  critical_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
+      OIDs that the mechanisms indicated in the mechs output parameter
+      MUST understand (i.e., mechs must know whether critical attributes
+      are or are not supported).
+
+   Outputs:
+
+   o  major_status INTEGER
+
+   o  minor_status INTEGER
+
+   o  mechs SET OF OBJECT IDENTIFIER -- set of mechanisms that support
+      the given desired_mech_attrs but not the except_mech_attrs, and
+      all of which understand the given critical_mech_attrs (the caller
+      must release this output with GSS_Release_oid_set()).
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
+      be the empty set (GSS_C_NO_OID_SET).
+
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   GSS_Indicate_mechs_by_attrs() returns the set of OIDs corresponding
+   to mechanisms that offer at least the desired_mech_attrs but none of
+   the except_mech_attrs, and that understand all of the attributes
+   listed in critical_mech_attrs.
+
+   When all three sets of OID input parameters are the empty set, this
+   function acts as a version of GSS_indicate_mechs() that outputs the
+   set of all supported mechanisms.
+
+
+
+Williams                    Standards Track                     [Page 9]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+3.4.3.  GSS_Inquire_attrs_for_mech()
+
+   Inputs:
+
+   o  mech OBJECT IDENTIFIER -- mechanism OID
+
+   Outputs:
+
+   o  major_status INTEGER
+
+   o  minor_status INTEGER
+
+   o  mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs OIDs
+      (GSS_C_MA_*) supported by the mechanism (the caller must release
+      this output with GSS_Release_oid_set()).
+
+   o  known_mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs
+      OIDs known to the mechanism implementation (the caller must
+      release this output with GSS_Release_oid_set()).
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates success; the output mech_attrs parameter
+      MAY be the empty set (GSS_C_NO_OID_SET).
+
+   o  GSS_S_BAD_MECH indicates that the mechanism named by the mech
+      parameter does not exist or that the mech is GSS_C_NO_OID and no
+      default mechanism could be determined.
+
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   GSS_Inquire_attrs_for_mech() indicates the set of mechanism
+   attributes supported by a given mechanism.
+
+3.4.4.  GSS_Display_mech_attr()
+
+   Inputs:
+
+   o  mech_attr OBJECT IDENTIFIER -- mechanism attribute OID
+
+   Outputs:
+
+   o  major_status INTEGER
+
+   o  minor_status INTEGER
+
+
+
+
+
+Williams                    Standards Track                    [Page 10]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+   o  name OCTET STRING, -- name of mechanism attribute (e.g.,
+      GSS_C_MA_*).
+
+   o  short_desc OCTET STRING, -- a short description of the mechanism
+      attribute (the caller must release this output with
+      GSS_Release_buffer()).
+
+   o  long_desc OCTET STRING -- a longer description of the mechanism
+      attribute (the caller must release this output with
+      GSS_Release_buffer()).
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates success.
+
+   o  GSS_S_BAD_MECH_ATTR indicates that the mechanism attribute
+      referenced by the mech_attr parameter is unknown to the
+      implementation.
+
+   o  GSS_S_FAILURE indicates that the request failed for some other
+      reason.
+
+   This function can be used to obtain human-readable descriptions of
+   GSS-API mechanism attributes.
+
+3.4.5.  New Major Status Values
+
+   A single, new, major status code is added for
+   GSS_Display_mech_attr():
+
+   o  GSS_S_BAD_MECH_ATTR,
+
+   roughly corresponding to GSS_S_BAD_MECH but applicable to mechanism
+   attribute OIDs rather than to mechanism OIDs.
+
+   For the C-bindings of the GSS-API [RFC2744], GSS_S_BAD_MECH_ATTR
+   shall have a routine error number of 19 (this is shifted to the left
+   by GSS_C_ROUTINE_ERROR_OFFSET).
+
+3.4.6.  C-Bindings
+
+   Note that there is a bug in the C bindings of the GSS-APIv2u1
+   [RFC2744] in that the C 'const' attribute is applied to types that
+   are pointer typedefs.  This is a bug because it declares that the
+   pointer argument is 'const' rather than that the object pointed by it
+   is const.  To avoid this error, we hereby define new typedefs, which
+   include const properly:
+
+
+
+
+Williams                    Standards Track                    [Page 11]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+      typedef const gss_buffer_desc * gss_const_buffer_t;
+      typedef const struct gss_channel_bindings_struct *
+         gss_const_channel_bindings_t;
+      typedef const <platform-specific> gss_const_ctx_id_t;
+      typedef const <platform-specific> gss_const_cred_id_t;
+      typedef const <platform-specific> gss_const_name_t;
+      typedef const gss_OID_desc * gss_const_OID;
+      typedef const gss_OID_set_desc * gss_const_OID_set;
+
+                         Figure 1: const typedefs
+
+   Note that only gss_const_OID and gss_const_OID_set are used below.
+   We include the other const typedefs for convenience since the C
+   bindings of the GSS-API do use const with pointer typedefs when it
+   should often instead use the above typedefs instead.
+
+      #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
+
+      OM_uint32 gss_indicate_mechs_by_attrs(
+         OM_uint32         *minor_status,
+         gss_const_OID_set  desired_mech_attrs,
+         gss_const_OID_set  except_mech_attrs,
+         gss_const_OID_set  critical_mech_attrs,
+         gss_OID_set       *mechs);
+
+      OM_uint32 gss_inquire_attrs_for_mech(
+         OM_uint32         *minor_status,
+         gss_const_OID      mech,
+         gss_OID_set       *mech_attrs,
+         gss_OID_set       *known_mech_attrs);
+
+      OM_uint32 gss_display_mech_attr(
+         OM_uint32         *minor_status,
+         gss_const_OID      mech_attr,
+         gss_buffer_t       name,
+         gss_buffer_t       short_desc,
+         gss_buffer_t       long_desc);
+
+                           Figure 2: C bindings
+
+   Note that output buffers must be released via gss_release_buffer().
+   Output OID sets must be released via gss_release_oid_set().
+
+   Please see Appendix A for a full set of typedef fragments defined in
+   this document and the necessary code license.
+
+
+
+
+
+
+Williams                    Standards Track                    [Page 12]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+4.  Requirements for Mechanism Designers
+
+   All future GSS-API mechanism specifications MUST:
+
+   o  list the set of GSS-API mechanism attributes associated with them.
+
+5.  IANA Considerations
+
+   The namespace of programming-language symbols with names beginning
+   with GSS_C_MA_* is reserved for allocation by IETF Consensus.  IANA
+   allocated a base OID, as an arc of 1.3.6.1.5.5, for the set of
+   GSS_C_MA_* described herein, and registered all of the GSS_C_MA_*
+   values described in Section 3.2.
+
+6.  Security Considerations
+
+   This document specifies extensions to a security-related API.  It
+   imposes new requirements on future GSS-API mechanisms, and the
+   specifications of future protocols that use the GSS-API should make
+   reference to this document where applicable.  The ability to inquire
+   about specific properties of mechanisms should improve security.
+
+   The semantics of each mechanism attribute may include a security
+   component.
+
+   Application developers must understand that mechanism attributes may
+   be added at any time -- both to the set of known mechanism attributes
+   as well as to existing mechanisms' sets of supported mechanism
+   attributes.  Therefore, application developers using the APIs
+   described herein must understand what mechanism attributes their
+   applications depend critically on, and must use the mechanism
+   attribute criticality features of these APIs.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+
+
+
+
+
+Williams                    Standards Track                    [Page 13]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+7.2.  Informative References
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
+              (SPKM)", RFC 2025, October 1996.
+
+   [RFC2847]  Eisler, M., "LIPKEY - A Low Infrastructure Public Key
+              Mechanism Using SPKM", RFC 2847, June 2000.
+
+   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+              Simple and Protected Generic Security Service Application
+              Program Interface (GSS-API) Negotiation Mechanism",
+              RFC 4178, October 2005.
+
+   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+              Protocol Architecture", RFC 4251, January 2006.
+
+   [RFC4462]  Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
+              "Generic Security Service Application Program Interface
+              (GSS-API) Authentication and Key Exchange for the Secure
+              Shell (SSH) Protocol", RFC 4462, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                    [Page 14]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+Appendix A.  Typedefs and C Bindings
+
+   This appendix contains the full set of code fragments defined in this
+   document.
+
+   Copyright (c) 2009 IETF Trust and the persons identified as authors
+   of the code.  All rights reserved.
+
+   Redistribution and use in source and binary forms, with or without
+   modification, are permitted provided that the following conditions
+   are met:
+
+   - Redistributions of source code must retain the above copyright
+     notice, this list of conditions and the following disclaimer.
+
+   - Redistributions in binary form must reproduce the above copyright
+     notice, this list of conditions and the following disclaimer in the
+     documentation and/or other materials provided with the
+     distribution.
+
+   - Neither the name of Internet Society, IETF or IETF Trust, nor the
+     names of specific contributors, may be used to endorse or promote
+     products derived from this software without specific prior written
+     permission.
+
+   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
+   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+   typedef const gss_buffer_desc * gss_const_buffer_t;
+   typedef const struct gss_channel_bindings_struct *
+      gss_const_channel_bindings_t;
+   typedef const <platform-specific> gss_const_ctx_id_t;
+   typedef const <platform-specific> gss_const_cred_id_t;
+   typedef const <platform-specific> gss_const_name_t;
+   typedef const gss_OID_desc * gss_const_OID;
+   typedef const gss_OID_set_desc * gss_const_OID_set;
+
+
+
+
+
+
+
+Williams                    Standards Track                    [Page 15]
+
+RFC 5587               Extended GSS Mech Inquiry               July 2009
+
+
+   #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
+
+   OM_uint32 gss_indicate_mechs_by_attrs(
+      OM_uint32         *minor_status,
+      gss_const_OID_set  desired_mech_attrs,
+      gss_const_OID_set  except_mech_attrs,
+      gss_const_OID_set  critical_mech_attrs,
+      gss_OID_set       *mechs);
+
+   OM_uint32 gss_inquire_attrs_for_mech(
+      OM_uint32         *minor_status,
+      gss_const_OID      mech,
+      gss_OID_set       *mech_attrs,
+      gss_OID_set       *known_mech_attrs);
+
+   OM_uint32 gss_display_mech_attr(
+      OM_uint32         *minor_status,
+      gss_const_OID      mech_attr,
+      gss_buffer_t       name,
+      gss_buffer_t       short_desc,
+      gss_buffer_t       long_desc);
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                    [Page 16]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc5588.txt b/third_party/heimdal/doc/standardisation/rfc5588.txt
new file mode 100644
index 00000000000..ee2a13ecf8e
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc5588.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        N. Williams
+Request for Comments: 5588                                           Sun
+Category: Standards Track                                      July 2009
+
+
+   Generic Security Service Application Program Interface (GSS-API)
+              Extension for Storing Delegated Credentials
+
+Abstract
+
+   This document defines a new function for the Generic Security Service
+   Application Program Interface (GSS-API), which allows applications to
+   store delegated (and other) credentials in the implicit GSS-API
+   credential store.  This is needed for GSS-API applications to use
+   delegated credentials as they would use other credentials.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. GSS_Store_cred() ................................................3
+   4. C-Bindings ......................................................5
+   5. Examples ........................................................6
+   6. Security Considerations .........................................6
+   7. Normative References ............................................7
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 1]
+
+RFC 5588                    GSS_Store_cred()                   July 2009
+
+
+1.  Introduction
+
+   The GSS-API [RFC2743] clearly assumes that credentials exist in an
+   implicit store whence they can be acquired using GSS_Acquire_cred()
+   and GSS_Add_cred() or through use of the default credential.
+   Multiple credential stores may exist on a given host, but only one
+   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
+   given time.
+
+   This assumption can be seen in Sections 1.1.1.2 and 1.1.1.3 of
+   [RFC2743] as well as in Section 3.5 of [RFC2744].
+
+   Applications may be able to change the credential store from which
+   credentials can be acquired, either by changing user contexts (where
+   the applications have the privilege to do so) or by other means
+   (where a user may have multiple credential stores).
+
+   Some GSS-API acceptor applications always change user contexts, after
+   accepting a GSS-API security context and making appropriate
+   authorization checks, to the user context corresponding to the
+   initiator principal name or to a context requested by the initiator.
+   The means by which credential stores are managed are generally beyond
+   the scope of the GSS-API.
+
+   In the case of delegated credential handles however, such credentials
+   do not exist in the acceptor's credential store or in the credential
+   stores of the user contexts to which the acceptor application might
+   change.  The GSS-API provides no mechanism by which delegated
+   credential handles can be made available for acquisition through
+   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
+   any credential import/export interfaces like the GSS-API context
+   import/export interfaces.
+
+   Thus, acceptors are limited to making only direct use of delegated
+   credential handles and only with GSS_Init_sec_context(),
+   GSS_Inquire_cred*(), and GSS_Release_cred().  This limitation is
+   particularly onerous on Unix systems where a call to exec() to
+   replace the process image obliterates any delegated credentials
+   handle that may exist in that process.
+
+   In order to make delegated credentials generally as useful as
+   credentials that can be acquired with GSS_Acquire_cred() and
+   GSS_Add_cred(), a primitive is needed that allows storing of
+   credentials in the implicit credential store.  We call this primitive
+   "GSS_Store_cred()".
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 2]
+
+RFC 5588                    GSS_Store_cred()                   July 2009
+
+
+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 [RFC2119].
+
+3.  GSS_Store_cred()
+
+   Inputs:
+
+   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
+      NOT be GSS_C_NO_CREDENTIAL.
+
+   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
+      2=ACCEPT-ONLY.
+
+   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID, then
+      store all the elements of the input_cred_handle, otherwise, store
+      only the element of the corresponding mechanism.
+
+   o  overwrite_cred BOOLEAN, -- if TRUE, replace any credential for the
+      same principal in the credential store.
+
+   o  default_cred BOOLEAN -- advisory input; if TRUE, make the stored
+      credential available as the default credential (for acquisition
+      with GSS_C_NO_NAME as the desired name or for use as
+      GSS_C_NO_CREDENTIAL).
+
+   Outputs:
+
+   o  major_status INTEGER.
+
+   o  minor_status INTEGER.
+
+   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
+      mechanism OIDs for which credential elements were successfully
+      stored.
+
+   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
+      kind of credential was stored (useful when the cred_usage input
+      parameter is set to INITIATE-AND-ACCEPT).
+
+   Return major_status codes:
+
+   o  GSS_S_COMPLETE indicates that the credentials were successfully
+      stored.
+
+
+
+
+
+Williams                    Standards Track                     [Page 3]
+
+RFC 5588                    GSS_Store_cred()                   July 2009
+
+
+   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
+      expired or expired before they could be stored.
+
+   o  GSS_S_NO_CRED indicates that no input credentials were given.
+
+   o  GSS_S_UNAVAILABLE indicates that the credential store is not
+      available.
+
+   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
+      credential could not be stored because a credential for the same
+      principal exists in the current credential store and the
+      overwrite_cred input argument was FALSE.
+
+   o  GSS_S_FAILURE indicates that the credential could not be stored
+      for some other reason.  The minor status code may provide more
+      information if a non-GSS_C_NULL_OID desired_mech_element was
+      given.
+
+   GSS_Store_cred() is used to store, in the current credential store, a
+   given credential that has either been acquired from a different
+   credential store or been accepted as a delegated credential.
+
+   Specific mechanism elements of a credential can be stored one at a
+   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
+   desired_mech_element input argument; in which case, the minor status
+   output SHOULD have a mechanism-specific value when the major status
+   is not GSS_S_COMPLETE.
+
+   The initiator, acceptor, or both usages of the input credential may
+   be stored as per the cred_usage input argument.
+
+   The credential elements that were actually stored, when the major
+   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
+   and mech_elements_stored function outputs.
+
+   If credentials already exist in the current store for the principal
+   of the input_cred_handle, then those credentials are not replaced
+   with the input credentials unless the overwrite_cred input argument
+   is TRUE.
+
+   In the GSS-API, the default credential can be used by using
+   GSS_C_NO_CREDENTIAL or a CREDENTIAL handle acquired by calling
+   GSS_Acquire_cred() or GSS_Add_cred() with the desired_name input set
+   to GSS_C_NO_NAME.
+
+   If the default_cred input argument is TRUE, and the input credential
+   can be successfully stored, then the input credential SHOULD be
+   stored as the default credential (see above).
+
+
+
+Williams                    Standards Track                     [Page 4]
+
+RFC 5588                    GSS_Store_cred()                   July 2009
+
+
+   If the current credential store has no default credential (see
+   above), then the implementation MAY make the stored credentials
+   available as the default credential regardless of the value of the
+   default_cred input argument.
+
+4.  C-Bindings
+
+   The C-Bindings for GSS_Store_cred() make use of types from and are
+   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
+
+         OM_uint32 gss_store_cred(
+            OM_uint32         *minor_status,
+            gss_cred_id_t     input_cred_handle,
+            gss_cred_usage_t  cred_usage,
+            const gss_OID     desired_mech,
+            OM_uint32         overwrite_cred,
+            OM_uint32         default_cred,
+            gss_OID_set       *elements_stored,
+            gss_cred_usage_t  *cred_usage_stored)
+
+                        Figure 1
+
+   The two boolean arguments, 'overwrite_cred' and 'default_cred', are
+   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
+   correspond to TRUE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 5]
+
+RFC 5588                    GSS_Store_cred()                   July 2009
+
+
+5.  Examples
+
+   The intended usage of GSS_Store_cred() is to make delegated
+   credentials available to child processes of GSS-API acceptor
+   applications.  Example pseudo-code:
+
+      /*
+       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
+       * an initiator name (hereafter, "src_name") and a delegated
+       * credential handle (hereafter "deleg_cred").>
+       *
+       * <"requested_username" is a username derived from the
+       * initiator name or explicitly requested by the initiator
+       * application.>
+       */
+      ...
+
+      if (authorize_gss_client(src_name, requested_username)) {
+         /*
+          * For Unix-type platforms this may mean calling setuid() and
+          * it may or may not also mean setting/unsetting such
+          * environment variables as KRB5CCNAME and what not -- all
+          * OS-specific details.
+          */
+         if (change_user_context(requested_username))
+            (void) gss_store_cred(&minor_status, deleg_cred,
+                                  GSS_C_INITIATE, actual_mech,
+                                  0, 1, NULL, NULL);
+         }
+         else ...
+      }
+      else ...
+
+6.  Security Considerations
+
+   Acceptor applications MUST only store delegated credentials into
+   appropriate credential stores and only after proper authorization of
+   the authenticated initiator principal to the requested service(s).
+
+   Acceptor applications that have no use for delegated credentials MUST
+   release them (such acceptor applications that use the GSS-API C-
+   Bindings may simply provide a NULL value for the
+   delegated_cred_handle argument to gss_accept_sec_context()).
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 6]
+
+RFC 5588                    GSS_Store_cred()                   July 2009
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
+              C-bindings", RFC 2744, January 2000.
+
+Author's Address
+
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   US
+
+   EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                    Standards Track                     [Page 7]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc6112.txt b/third_party/heimdal/doc/standardisation/rfc6112.txt
new file mode 100644
index 00000000000..b407759662c
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc6112.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            L. Zhu
+Request for Comments: 6112                                      P. Leach
+Updates: 4120, 4121, 4556                          Microsoft Corporation
+Category: Standards Track                                     S. Hartman
+ISSN: 2070-1721                                        Painless Security
+                                                              April 2011
+
+
+                     Anonymity Support for Kerberos
+
+Abstract
+
+   This document defines extensions to the Kerberos protocol to allow a
+   Kerberos client to securely communicate with a Kerberos application
+   service without revealing its identity, or without revealing more
+   than its Kerberos realm.  It also defines extensions that allow a
+   Kerberos client to obtain anonymous credentials without revealing its
+   identity to the Kerberos Key Distribution Center (KDC).  This
+   document updates RFCs 4120, 4121, and 4556.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6112.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Zhu, et al.                  Standards Track                    [Page 1]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Anonymity Support in AS Exchange . . . . . . . . . . . . .  5
+       4.1.1.  Anonymous PKINIT . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Anonymity Support in TGS Exchange  . . . . . . . . . . . .  7
+     4.3.  Subsequent Exchanges and Protocol Actions Common to AS
+           and TGS for Anonymity Support  . . . . . . . . . . . . . .  9
+   5.  Interoperability Requirements  . . . . . . . . . . . . . . . . 10
+   6.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10
+   7.  PKINIT Client Contribution to the Ticket Session Key . . . . . 11
+     7.1.  Combining Two Protocol Keys  . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 2]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+1.  Introduction
+
+   In certain situations, the Kerberos [RFC4120] client may wish to
+   authenticate a server and/or protect communications without revealing
+   the client's own identity.  For example, consider an application that
+   provides read access to a research database and that permits queries
+   by arbitrary requesters.  A client of such a service might wish to
+   authenticate the service, to establish trust in the information
+   received from it, but might not wish to disclose the client's
+   identity to the service for privacy reasons.
+
+   Extensions to Kerberos are specified in this document by which a
+   client can authenticate the Key Distribution Center (KDC) and request
+   an anonymous ticket.  The client can use the anonymous ticket to
+   authenticate the server and protect subsequent client-server
+   communications.
+
+   By using the extensions defined in this specification, the client can
+   request an anonymous ticket where the client may reveal the client's
+   identity to the client's own KDC, or the client can hide the client's
+   identity completely by using anonymous Public Key Cryptography for
+   Initial Authentication in Kerberos (PKINIT) as defined in
+   Section 4.1.  Using the returned anonymous ticket, the client remains
+   anonymous in subsequent Kerberos exchanges thereafter to KDCs on the
+   cross-realm authentication path and to the server with which it
+   communicates.
+
+   In this specification, the client realm in the anonymous ticket is
+   the anonymous realm name when anonymous PKINIT is used to obtain the
+   ticket.  The client realm is the client's real realm name if the
+   client is authenticated using the client's long-term keys.  Note that
+   the membership of a realm can imply a member of the community
+   represented by the realm.
+
+   The interaction with Generic Security Service Application Program
+   Interface (GSS-API) is described after the protocol description.
+
+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 [RFC2119].
+
+3.  Definitions
+
+   The anonymous Kerberos realm name is defined as a well-known realm
+   name based on [RFC6111], and the value of this well-known realm name
+   is the literal "WELLKNOWN:ANONYMOUS".
+
+
+
+Zhu, et al.                  Standards Track                    [Page 3]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   The anonymous Kerberos principal name is defined as a well-known
+   Kerberos principal name based on [RFC6111].  The value of the name-
+   type field is KRB_NT_WELLKNOWN [RFC6111], and the value of the name-
+   string field is a sequence of two KerberosString components:
+   "WELLKNOWN", "ANONYMOUS".
+
+   The anonymous ticket flag is defined as bit 16 (with the first bit
+   being bit 0) in the TicketFlags:
+
+           TicketFlags     ::= KerberosFlags
+             -- anonymous(16)
+             -- TicketFlags and KerberosFlags are defined in [RFC4120]
+
+   This is a new ticket flag that is used to indicate that a ticket is
+   an anonymous one.
+
+   An anonymous ticket is a ticket that has all of the following
+   properties:
+
+   o  The cname field contains the anonymous Kerberos principal name.
+
+   o  The crealm field contains the client's realm name or the anonymous
+      realm name.
+
+   o  The anonymous ticket contains no information that can reveal the
+      client's identity.  However, the ticket may contain the client
+      realm, intermediate realms on the client's authentication path,
+      and authorization data that may provide information related to the
+      client's identity.  For example, an anonymous principal that is
+      identifiable only within a particular group of users can be
+      implemented using authorization data and such authorization data,
+      if included in the anonymous ticket, would disclose the client's
+      membership of that group.
+
+   o  The anonymous ticket flag is set.
+
+   The anonymous KDC option is defined as bit 16 (with the first bit
+   being bit 0) in the KDCOptions:
+
+           KDCOptions      ::= KerberosFlags
+             -- anonymous(16)
+             -- KDCOptions and KerberosFlags are defined in [RFC4120]
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 4]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   As described in Section 4, the anonymous KDC option is set to request
+   an anonymous ticket in an Authentication Service (AS) request or a
+   Ticket Granting Service (TGS) request.
+
+4.  Protocol Description
+
+   In order to request an anonymous ticket, the client sets the
+   anonymous KDC option in an AS request or a TGS request.
+
+   The rest of this section is organized as follows: it first describes
+   protocol actions specific to AS exchanges, then it describes those of
+   TGS exchanges.  These are then followed by the description of
+   protocol actions common to both AS and TGS and those in subsequent
+   exchanges.
+
+4.1.  Anonymity Support in AS Exchange
+
+   The client requests an anonymous ticket by setting the anonymous KDC
+   option in an AS exchange.
+
+   The Kerberos client can use the client's long-term keys, the client's
+   X.509 certificates [RFC4556], or any other pre-authentication data,
+   to authenticate to the KDC and requests an anonymous ticket in an AS
+   exchange where the client's identity is known to the KDC.
+
+   If the client in the AS request is anonymous, the anonymous KDC
+   option MUST be set in the request.  Otherwise, the KDC MUST return a
+   KRB-ERROR message with the code KDC_ERR_BADOPTION.
+
+   If the client is anonymous and the KDC does not have a key to encrypt
+   the reply (this can happen when, for example, the KDC does not
+   support PKINIT [RFC4556]), the KDC MUST return an error message with
+   the code KDC_ERR_NULL_KEY [RFC4120].
+
+   When policy allows, the KDC issues an anonymous ticket.  If the
+   client name in the request is the anonymous principal, the client
+   realm (crealm) in the reply is the anonymous realm, otherwise, the
+   client realm is the realm of the AS.  According to [RFC4120], the
+   client name and the client realm in the EncTicketPart of the reply
+   MUST match with the corresponding client name and the client realm of
+   the KDC reply; the client MUST use the client name and the client
+   realm returned in the KDC-REP in subsequent message exchanges when
+   using the obtained anonymous ticket.
+
+   Care MUST be taken by the KDC not to reveal the client's identity in
+   the authorization data of the returned ticket when populating the
+   authorization data in a returned anonymous ticket.
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 5]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   The AD-INITIAL-VERIFIED-CAS authorization data, as defined in
+   [RFC4556], contains the issuer name of the client certificate.  This
+   authorization is not applicable and MUST NOT be present in the
+   returned anonymous ticket when anonymous PKINIT is used.  When the
+   client is authenticated (i.e., anonymous PKINIT is not used), if it
+   is undesirable to disclose such information about the client's
+   identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be
+   removed from the returned anonymous ticket.
+
+   The client can use the client keys to mutually authenticate with the
+   KDC and request an anonymous Ticket Granting Ticket (TGT) in the AS
+   request.  In that case, the reply key is selected as normal,
+   according to Section 3.1.3 of [RFC4120].
+
+4.1.1.  Anonymous PKINIT
+
+   This sub-section defines anonymous PKINIT.
+
+   As described earlier in this section, the client can request an
+   anonymous ticket by authenticating to the KDC using the client's
+   identity; alternatively, without revealing the client's identity to
+   the KDC, the Kerberos client can request an anonymous ticket as
+   follows: the client sets the client name as the anonymous principal
+   in the AS exchange and provides PA_PK_AS_REQ pre-authentication data
+   [RFC4556] where the signerInfos field of the SignedData [RFC5652] of
+   the PA_PK_AS_REQ is empty, and the certificates field is absent.
+   Because the anonymous client does not have an associated asymmetric
+   key pair, the client MUST choose the Diffie-Hellman key agreement
+   method by filling in the Diffie-Hellman domain parameters in the
+   clientPublicValue [RFC4556].  This use of the anonymous client name
+   in conjunction with PKINIT is referred to as anonymous PKINIT.  If
+   anonymous PKINIT is used, the realm name in the returned anonymous
+   ticket MUST be the anonymous realm.
+
+   Upon receiving the anonymous PKINIT request from the client, the KDC
+   processes the request, according to Section 3.1.2 of [RFC4120].  The
+   KDC skips the checks for the client's signature and the client's
+   public key (such as the verification of the binding between the
+   client's public key and the client name), but performs otherwise
+   applicable checks, and proceeds as normal, according to [RFC4556].
+   For example, the AS MUST check if the client's Diffie-Hellman domain
+   parameters are acceptable.  The Diffie-Hellman key agreement method
+   MUST be used and the reply key is derived according to Section
+   3.2.3.1 of [RFC4556].  If the clientPublicValue is not present in the
+   request, the KDC MUST return a KRB-ERROR with the code
+   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556].  If all goes
+   well, an anonymous ticket is generated, according to Section 3.1.3 of
+   [RFC4120], and PA_PK_AS_REP [RFC4556] pre-authentication data is
+
+
+
+Zhu, et al.                  Standards Track                    [Page 6]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   included in the KDC reply, according to [RFC4556].  If the KDC does
+   not have an asymmetric key pair, it MAY reply anonymously or reject
+   the authentication attempt.  If the KDC replies anonymously, the
+   signerInfos field of the SignedData [RFC5652] of PA_PK_AS_REP in the
+   reply is empty, and the certificates field is absent.  The server
+   name in the anonymous KDC reply contains the name of the TGS.
+
+   Upon receipt of the KDC reply that contains an anonymous ticket and
+   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
+   authenticate the KDC based on the KDC's signature in the
+   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
+   (the reply is anonymous), the client MUST reject the returned ticket
+   if it cannot authenticate the KDC otherwise.
+
+   A KDC that supports anonymous PKINIT MUST indicate the support of
+   PKINIT, according to Section 3.4 of [RFC4556].  In addition, such a
+   KDC MUST indicate support for anonymous PKINIT by including a padata
+   element of padata-type PA_PKINIT_KX and empty padata-value when
+   including PA-PK-AS-REQ in an error reply.
+
+   When included in a KDC error, PA_PKINIT_KX indicates support for
+   anonymous PKINIT.  As discussed in Section 7, when included in an AS-
+   REP, PA_PKINIT_KX proves that the KDC and client both contributed to
+   the session key for any use of Diffie-Hellman key agreement with
+   PKINIT.
+
+   Note that in order to obtain an anonymous ticket with the anonymous
+   realm name, the client MUST set the client name as the anonymous
+   principal in the request when requesting an anonymous ticket in an AS
+   exchange.  Anonymity PKINIT is the only way via which an anonymous
+   ticket with the anonymous realm as the client realm can be generated
+   in this specification.
+
+4.2.  Anonymity Support in TGS Exchange
+
+   The client requests an anonymous ticket by setting the anonymous KDC
+   option in a TGS exchange, and in that request the client can use a
+   normal Ticket Granting Ticket (TGT) with the client's identity, or an
+   anonymous TGT, or an anonymous cross-realm TGT.  If the client uses a
+   normal TGT, the client's identity is known to the TGS.
+
+   Note that the client can completely hide the client's identity in an
+   AS exchange using anonymous PKINIT, as described in the previous
+   section.
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 7]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   If the ticket in the PA-TGS-REQ of the TGS request is an anonymous
+   one, the anonymous KDC option MUST be set in the request.  Otherwise,
+   the KDC MUST return a KRB-ERROR message with the code
+   KDC_ERR_BADOPTION.
+
+   When policy allows, the KDC issues an anonymous ticket.  If the
+   ticket in the TGS request is an anonymous one, the client name and
+   the client realm are copied from that ticket; otherwise, the ticket
+   in the TGS request is a normal ticket, the returned anonymous ticket
+   contains the client name as the anonymous principal and the client
+   realm as the true realm of the client.  In all cases, according to
+   [RFC4120] the client name and the client realm in the EncTicketPart
+   of the reply MUST match with the corresponding client name and the
+   client realm of the anonymous ticket in the reply; the client MUST
+   use the client name and the client realm returned in the KDC-REP in
+   subsequent message exchanges when using the obtained anonymous
+   ticket.
+
+   Care MUST be taken by the TGS not to reveal the client's identity in
+   the authorization data of the returned ticket.  When propagating
+   authorization data in the ticket or in the enc-authorization-data
+   field of the request, the TGS MUST ensure that the client
+   confidentiality is not violated in the returned anonymous ticket.
+   The TGS MUST process the authorization data recursively, according to
+   Section 5.2.6 of [RFC4120], beyond the container levels such that all
+   embedded authorization elements are interpreted.  The TGS SHOULD NOT
+   populate identity-based authorization data into an anonymous ticket
+   in that such authorization data typically reveals the client's
+   identity.  The specification of a new authorization data type MUST
+   specify the processing rules of the authorization data when an
+   anonymous ticket is returned.  If there is no processing rule defined
+   for an authorization data element or the authorization data element
+   is unknown, the TGS MUST process it when an anonymous ticket is
+   returned as follows:
+
+   o  If the authorization data element may reveal the client's
+      identity, it MUST be removed unless otherwise specified.
+
+   o  If the authorization data element, that could reveal the client's
+      identity, is intended to restrict the use of the ticket or limit
+      the rights otherwise conveyed in the ticket, it cannot be removed
+      in order to hide the client's identity.  In this case, the
+      authentication attempt MUST be rejected, and the TGS MUST return
+      an error message with the code KDC_ERR_POLICY.  Note this is
+      applicable to both critical and optional authorization data.
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 8]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   o  If the authorization data element is unknown, the TGS MAY remove
+      it, or transfer it into the returned anonymous ticket, or reject
+      the authentication attempt, based on local policy for that
+      authorization data type unless otherwise specified.  If there is
+      no policy defined for a given unknown authorization data type, the
+      authentication MUST be rejected.  The error code is KDC_ERR_POLICY
+      when the authentication is rejected.
+
+   The AD-INITIAL-VERIFIED-CAS authorization data, as defined in
+   [RFC4556], contains the issuer name of the client certificate.  If it
+   is undesirable to disclose such information about the client's
+   identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be
+   removed from an anonymous ticket.
+
+   The TGS encodes the name of the previous realm into the transited
+   field, according to Section 3.3.3.2 of [RFC4120].  Based on local
+   policy, the TGS MAY omit the previous realm, if the cross realm TGT
+   is an anonymous one, in order to hide the authentication path of the
+   client.  The unordered set of realms in the transited field, if
+   present, can reveal which realm may potentially be the realm of the
+   client or the realm that issued the anonymous TGT.  The anonymous
+   Kerberos realm name MUST NOT be present in the transited field of a
+   ticket.  The true name of the realm that issued the anonymous ticket
+   MAY be present in the transited field of a ticket.
+
+4.3.  Subsequent Exchanges and Protocol Actions Common to AS and TGS for
+      Anonymity Support
+
+   In both AS and TGS exchanges, the realm field in the KDC request is
+   always the realm of the target KDC, not the anonymous realm when the
+   client requests an anonymous ticket.
+
+   Absent other information, the KDC MUST NOT include any identifier in
+   the returned anonymous ticket that could reveal the client's identity
+   to the server.
+
+   Unless anonymous PKINIT is used, if a client requires anonymous
+   communication, then the client MUST check to make sure that the
+   ticket in the reply is actually anonymous by checking the presence of
+   the anonymous ticket flag in the flags field of the EncKDCRepPart.
+   This is because KDCs ignore unknown KDC options.  A KDC that does not
+   understand the anonymous KDC option will not return an error, but
+   will instead return a normal ticket.
+
+   The subsequent client and server communications then proceed as
+   described in [RFC4120].
+
+
+
+
+
+Zhu, et al.                  Standards Track                    [Page 9]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   Note that the anonymous principal name and realm are only applicable
+   to the client in Kerberos messages, the server cannot be anonymous in
+   any Kerberos message per this specification.
+
+   A server accepting an anonymous service ticket may assume that
+   subsequent requests using the same ticket originate from the same
+   client.  Requests with different tickets are likely to originate from
+   different clients.
+
+   Upon receipt of an anonymous ticket, the transited policy check is
+   performed in the same way as that of a normal ticket if the client's
+   realm is not the anonymous realm; if the client realm is the
+   anonymous realm, absent other information any realm in the
+   authentication path is allowed by the cross-realm policy check.
+
+5.  Interoperability Requirements
+
+   Conforming implementations MUST support the anonymous principal with
+   a non-anonymous realm, and they MAY support the anonymous principal
+   with the anonymous realm using anonymous PKINIT.
+
+6.  GSS-API Implementation Notes
+
+   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
+   represent the anonymous identity.  In addition, Section 2.1.1 of
+   [RFC1964] defines the single string representation of a Kerberos
+   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  The
+   anonymous principal with the anonymous realm corresponds to the GSS-
+   API anonymous principal.  A principal with the anonymous principal
+   name and a non-anonymous realm is an authenticated principal; hence,
+   such a principal does not correspond to the anonymous principal in
+   GSS-API with the GSS_C_NT_ANONYMOUS name type.  The [RFC1964] name
+   syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the
+   anonymous principal name with a non-anonymous realm name and for
+   displaying and exporting these names.  In addition, this syntax must
+   be used along with the name type GSS_C_NT_ANONYMOUS for displaying
+   and exporting the anonymous principal with the anonymous realm.
+
+   At the GSS-API [RFC2743] level, an initiator/client requests the use
+   of an anonymous principal with the anonymous realm by asserting the
+   "anonymous" flag when calling GSS_Init_Sec_Context().  The GSS-API
+   implementation MAY provide implementation-specific means for
+   requesting the use of an anonymous principal with a non-anonymous
+   realm.
+
+   GSS-API does not know or define "anonymous credentials", so the
+   (printable) name of the anonymous principal will rarely be used by or
+   relevant for the initiator/client.  The printable name is relevant
+
+
+
+Zhu, et al.                  Standards Track                   [Page 10]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   for the acceptor/server when performing an authorization decision
+   based on the initiator name that is returned from the acceptor side
+   upon the successful security context establishment.
+
+   A GSS-API initiator MUST carefully check the resulting context
+   attributes from the initial call to GSS_Init_Sec_Context() when
+   requesting anonymity, because (as in the GSS-API tradition and for
+   backwards compatibility) anonymity is just another optional context
+   attribute.  It could be that the mechanism doesn't recognize the
+   attribute at all or that anonymity is not available for some other
+   reasons -- and in that case the initiator MUST NOT send the initial
+   security context token to the acceptor, because it will likely reveal
+   the initiators identity to the acceptor, something that can rarely be
+   "un-done".
+
+   Portable initiators are RECOMMENDED to use default credentials
+   whenever possible, and request anonymity only through the input
+   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
+
+7.  PKINIT Client Contribution to the Ticket Session Key
+
+   The definition in this section was motivated by protocol analysis of
+   anonymous PKINIT (defined in this document) in building tunneling
+   channels [RFC6113] and subsequent channel bindings.  In order to
+   enable applications of anonymous PKINIT to form channels, all
+   implementations of anonymous PKINIT need to meet the requirements of
+   this section.  There is otherwise no connection to the rest of this
+   document.
+
+   PKINIT is useful for constructing tunneling channels.  To ensure that
+   an attacker cannot create a channel with a given name, it is
+   desirable that neither the KDC nor the client unilaterally determine
+   the ticket session key.  To achieve that end, a KDC conforming to
+   this definition MUST encrypt a randomly generated key, called the KDC
+   contribution key, in the PA_PKINIT_KX padata (defined next in this
+   section).  The KDC contribution key is then combined with the reply
+   key to form the ticket session key of the returned ticket.  These two
+   keys are then combined using the KRB-FX-CF2 operation defined in
+   Section 7.1, where K1 is the KDC contribution key, K2 is the reply
+   key, the input pepper1 is American Standard Code for Information
+   Interchange (ASCII) [ASAX34] string "PKINIT", and the input pepper2
+   is ASCII string "KeyExchange".
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 11]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   PA_PKINIT_KX      147
+     -- padata for PKINIT that contains an encrypted
+     -- KDC contribution key.
+
+   PA-PKINIT-KX  ::= EncryptedData -- EncryptionKey
+     -- Contains an encrypted key randomly
+     -- generated by the KDC (known as the KDC contribution key).
+     -- Both EncryptedData and EncryptionKey are defined in [RFC4120]
+
+   The PA_PKINIT_KX padata MUST be included in the KDC reply when
+   anonymous PKINIT is used; it SHOULD be included if PKINIT is used
+   with the Diffie-Hellman key exchange but the client is not anonymous;
+   it MUST NOT be included otherwise (e.g., when PKINIT is used with the
+   public key encryption as the key exchange).
+
+   The padata-value field of the PA-PKINIT-KX type padata contains the
+   DER [X.680] [X.690] encoding of the Abstract Syntax Notation One
+   (ASN.1) type PA-PKINIT-KX.  The PA-PKINIT-KX structure is an
+   EncryptedData.  The cleartext data being encrypted is the DER-encoded
+   KDC contribution key randomly generated by the KDC.  The encryption
+   key is the reply key and the key usage number is
+   KEY_USAGE_PA_PKINIT_KX (44).
+
+   The client then decrypts the KDC contribution key and verifies the
+   ticket session key in the returned ticket is the combined key of the
+   KDC contribution key and the reply key as described above.  A
+   conforming client MUST reject anonymous PKINIT authentication if the
+   PA_PKINIT_KX padata is not present in the KDC reply or if the ticket
+   session key of the returned ticket is not the combined key of the KDC
+   contribution key and the reply key when PA-PKINIT-KX is present in
+   the KDC reply.
+
+7.1.  Combining Two Protocol Keys
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+    KRB-FX-CF2(protocol key, protocol key, octet string,
+              octet string)  ->  (protocol key)
+
+    PRF+(K1, pepper1) -> octet-string-1
+    PRF+(K2, pepper2) -> octet-string-2
+    KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
+           random-to-key(octet-string-1 ^ octet-string-2)
+
+
+
+Zhu, et al.                  Standards Track                   [Page 12]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+   PRF+(protocol key, octet string) -> (octet string)
+
+   PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
+                pseudo-random( key, 2 || shared-info ) ||
+                pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3, and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.
+
+8.  Security Considerations
+
+   Since KDCs ignore unknown options, a client requiring anonymous
+   communication needs to make sure that the returned ticket is actually
+   anonymous.  This is because a KDC that does not understand the
+   anonymous option would not return an anonymous ticket.
+
+   By using the mechanism defined in this specification, the client does
+   not reveal the client's identity to the server but the client
+   identity may be revealed to the KDC of the server principal (when the
+   server principal is in a different realm than that of the client),
+   and any KDC on the cross-realm authentication path.  The Kerberos
+   client MUST verify the ticket being used is indeed anonymous before
+   communicating with the server, otherwise, the client's identity may
+   be revealed unintentionally.
+
+   In cases where specific server principals must not have access to the
+   client's identity (for example, an anonymous poll service), the KDC
+   can define server-principal-specific policy that ensures any normal
+   service ticket can NEVER be issued to any of these server principals.
+
+   If the KDC that issued an anonymous ticket were to maintain records
+   of the association of identities to an anonymous ticket, then someone
+   obtaining such records could breach the anonymity.  Additionally, the
+   implementations of most (for now all) KDC's respond to requests at
+   the time that they are received.  Traffic analysis on the connection
+   to the KDC will allow an attacker to match client identities to
+   anonymous tickets issued.  Because there are plaintext parts of the
+   tickets that are exposed on the wire, such matching by a third-party
+   observer is relatively straightforward.  A service that is
+   authenticated by the anonymous principals may be able to infer the
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 13]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+   identity of the client by examining and linking quasi-static protocol
+   information such as the IP address from which a request is received,
+   or by linking multiple uses of the same anonymous ticket.
+
+   Two mechanisms, the FAST facility with the hide-client-names option
+   in [RFC6113] and the Kerberos5 starttls option [STARTTLS], protect
+   the client identity so that an attacker would never be able to
+   observe the client identity sent to the KDC.  Transport or network
+   layer security between the client and the server will help prevent
+   tracking of a particular ticket to link a ticket to a user.  In
+   addition, clients can limit how often a ticket is reused to minimize
+   ticket linking.
+
+   The client's real identity is not revealed when the client is
+   authenticated as the anonymous principal.  Application servers MAY
+   reject the authentication in order to, for example, prevent
+   information disclosure or as part of Denial of Service (DoS)
+   prevention.  Application servers MUST avoid accepting anonymous
+   credentials in situations where they must record the client's
+   identity; for example, when there must be an audit trail.
+
+9.  Acknowledgements
+
+   JK Jaganathan helped editing early revisions of this document.
+
+   Clifford Neuman contributed the core notions of this document.
+
+   Ken Raeburn reviewed the document and provided suggestions for
+   improvements.
+
+   Martin Rex wrote the text for GSS-API considerations.
+
+   Nicolas Williams reviewed the GSS-API considerations section and
+   suggested ideas for improvements.
+
+   Sam Hartman and Nicolas Williams were great champions of this work.
+
+   Miguel Garcia and Phillip Hallam-Baker reviewed the document and
+   provided helpful suggestions.
+
+   In addition, the following individuals made significant
+   contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love
+   Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 14]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+10.  IANA Considerations
+
+   This document defines a new 'anonymous' Kerberos well-known name and
+   a new 'anonymous' Kerberos well-known realm based on [RFC6111].  IANA
+   has added these two values to the Kerberos naming registries that are
+   created in [RFC6111].
+
+11.  References
+
+11.1.  Normative References
+
+   [ASAX34]    American Standards Institute, "American Standard Code for
+               Information Interchange", ASA X3.4-1963, June 1963.
+
+   [RFC1964]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+               RFC 1964, June 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2743]   Linn, J., "Generic Security Service Application Program
+               Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3961]   Raeburn, K., "Encryption and Checksum Specifications for
+               Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+               Kerberos Network Authentication Service (V5)", RFC 4120,
+               July 2005.
+
+   [RFC4556]   Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+               Authentication in Kerberos (PKINIT)", RFC 4556,
+               June 2006.
+
+   [RFC5652]   Housley, R., "Cryptographic Message Syntax (CMS)",
+               STD 70, RFC 5652, September 2009.
+
+   [RFC6111]   Zhu, L., "Additional Kerberos Naming Constraints",
+               RFC 6111, April 2011.
+
+   [X.680]     "Abstract Syntax Notation One (ASN.1): Specification of
+               Basic Notation", ITU-T Recommendation X.680: ISO/IEC
+               International Standard 8824-1:1998, 1997.
+
+   [X.690]     "ASN.1 encoding rules: Specification of Basic Encoding
+               Rules (BER), Canonical Encoding Rules (CER) and
+               Distinguished Encoding Rules (DER)", ITU-T Recommendation
+               X.690  ISO/IEC International Standard 8825-1:1998, 1997.
+
+
+
+Zhu, et al.                  Standards Track                   [Page 15]
+
+RFC 6112               Kerberos Anonymity Support             April 2011
+
+
+11.2.  Informative References
+
+   [RFC6113]   Hartman, S. and L. Zhu, "A Generalized Framework for
+               Kerberos Pre-Authentication", RFC 6113, April 2011.
+
+   [STARTTLS]  Josefsson, S., "Using Kerberos V5 over the Transport
+               Layer Security (TLS) protocol", Work in Progress,
+               August 2010.
+
+Authors' Addresses
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: larry.zhu@microsoft.com
+
+
+   Paul Leach
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: paulle@microsoft.com
+
+
+   Sam Hartman
+   Painless Security
+
+   EMail: hartmans-ietf@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al.                  Standards Track                   [Page 16]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc6113.txt b/third_party/heimdal/doc/standardisation/rfc6113.txt
new file mode 100644
index 00000000000..e0a579eab2b
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc6113.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        S. Hartman
+Request for Comments: 6113                             Painless Security
+Updates: 4120                                                     L. Zhu
+Category: Standards Track                          Microsoft Corporation
+ISSN: 2070-1721                                               April 2011
+
+
+        A Generalized Framework for Kerberos Pre-Authentication
+
+Abstract
+
+   Kerberos is a protocol for verifying the identity of principals
+   (e.g., a workstation user or a network server) on an open network.
+   The Kerberos protocol provides a facility called pre-authentication.
+   Pre-authentication mechanisms can use this facility to extend the
+   Kerberos protocol and prove the identity of a principal.
+
+   This document describes a more formal model for this facility.  The
+   model describes what state in the Kerberos request a pre-
+   authentication mechanism is likely to change.  It also describes how
+   multiple pre-authentication mechanisms used in the same request will
+   interact.
+
+   This document also provides common tools needed by multiple pre-
+   authentication mechanisms.  One of these tools is a secure channel
+   between the client and the key distribution center with a reply key
+   strengthening mechanism; this secure channel can be used to protect
+   the authentication exchange and thus eliminate offline dictionary
+   attacks.  With these tools, it is relatively straightforward to chain
+   multiple authentication mechanisms, utilize a different key
+   management system, or support a new key agreement algorithm.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6113.
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                    [Page 1]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                    [Page 2]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Conventions and Terminology Used in This Document ..........5
+      1.2. Conformance Requirements ...................................5
+   2. Model for Pre-Authentication ....................................6
+      2.1. Information Managed by the Pre-Authentication Model ........7
+      2.2. Initial Pre-Authentication Required Error ..................9
+      2.3. Client to KDC .............................................10
+      2.4. KDC to Client .............................................11
+   3. Pre-Authentication Facilities ..................................12
+      3.1. Client Authentication Facility ............................13
+      3.2. Strengthening Reply Key Facility ..........................13
+      3.3. Replace Reply Key Facility ................................14
+      3.4. KDC Authentication Facility ...............................15
+   4. Requirements for Pre-Authentication Mechanisms .................15
+      4.1. Protecting Requests/Responses .............................16
+   5. Tools for Use in Pre-Authentication Mechanisms .................17
+      5.1. Combining Keys ............................................17
+      5.2. Managing States for the KDC ...............................19
+      5.3. Pre-Authentication Set ....................................20
+      5.4. Definition of Kerberos FAST Padata ........................23
+           5.4.1. FAST Armors ........................................24
+           5.4.2. FAST Request .......................................26
+           5.4.3. FAST Response ......................................30
+           5.4.4. Authenticated Kerberos Error Messages Using
+                  Kerberos FAST ......................................33
+           5.4.5. Outer and Inner Requests ...........................34
+           5.4.6. The Encrypted Challenge FAST Factor ................34
+      5.5. Authentication Strength Indication ........................36
+   6. Assigned Constants .............................................37
+      6.1. New Errors ................................................37
+      6.2. Key Usage Numbers .........................................37
+      6.3. Authorization Data Elements ...............................37
+      6.4. New PA-DATA Types .........................................37
+   7. IANA Considerations ............................................38
+      7.1. Pre-Authentication and Typed Data .........................38
+      7.2. Fast Armor Types ..........................................40
+      7.3. FAST Options ..............................................40
+   8. Security Considerations ........................................41
+   9. Acknowledgements ...............................................42
+   10. References ....................................................43
+      10.1. Normative References .....................................43
+      10.2. Informative References ...................................43
+   Appendix A. Test Vectors for KRB-FX-CF2 ...........................45
+   Appendix B. ASN.1 Module ..........................................46
+
+
+
+
+
+Hartman & Zhu                Standards Track                    [Page 3]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+1.  Introduction
+
+   The core Kerberos specification [RFC4120] treats pre-authentication
+   data (padata) as an opaque typed hole in the messages to the key
+   distribution center (KDC) that may influence the reply key used to
+   encrypt the KDC reply.  This generality has been useful: pre-
+   authentication data is used for a variety of extensions to the
+   protocol, many outside the expectations of the initial designers.
+   However, this generality makes designing more common types of pre-
+   authentication mechanisms difficult.  Each mechanism needs to specify
+   how it interacts with other mechanisms.  Also, tasks such as
+   combining a key with the long-term secrets or proving the identity of
+   the user are common to multiple mechanisms.  Where there are
+   generally well-accepted solutions to these problems, it is desirable
+   to standardize one of these solutions so mechanisms can avoid
+   duplication of work.  In other cases, a modular approach to these
+   problems is appropriate.  The modular approach will allow new and
+   better solutions to common pre-authentication problems to be used by
+   existing mechanisms as they are developed.
+
+   This document specifies a framework for Kerberos pre-authentication
+   mechanisms.  It defines the common set of functions that pre-
+   authentication mechanisms perform as well as how these functions
+   affect the state of the request and reply.  In addition, several
+   common tools needed by pre-authentication mechanisms are provided.
+   Unlike [RFC3961], this framework is not complete -- it does not
+   describe all the inputs and outputs for the pre-authentication
+   mechanisms.  Pre-authentication mechanism designers should try to be
+   consistent with this framework because doing so will make their
+   mechanisms easier to implement.  Kerberos implementations are likely
+   to have plug-in architectures for pre-authentication; such
+   architectures are likely to support mechanisms that follow this
+   framework plus commonly used extensions.  This framework also
+   facilitates combining multiple pre-authentication mechanisms, each of
+   which may represent an authentication factor, into a single multi-
+   factor pre-authentication mechanism.
+
+   One of these common tools is the flexible authentication secure
+   tunneling (FAST) padata type.  FAST provides a protected channel
+   between the client and the key distribution center (KDC), and it can
+   optionally deliver key material used to strengthen the reply key
+   within the protected channel.  Based on FAST, pre-authentication
+   mechanisms can extend Kerberos with ease, to support, for example,
+   password-authenticated key exchange (PAKE) protocols with zero-
+   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
+   authentication mechanism can be encapsulated in the FAST messages as
+   defined in Section 5.4.  A pre-authentication type carried within
+   FAST is called a "FAST factor".  Creating a FAST factor is the
+
+
+
+Hartman & Zhu                Standards Track                    [Page 4]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   easiest path to create a new pre-authentication mechanism.  FAST
+   factors are significantly easier to analyze from a security
+   standpoint than other pre-authentication mechanisms.
+
+   Mechanism designers should design FAST factors, instead of new pre-
+   authentication mechanisms outside of FAST.
+
+1.1.  Conventions and Terminology 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 [RFC2119].
+
+   This document should be read only after reading the documents
+   describing the Kerberos cryptography framework [RFC3961] and the core
+   Kerberos protocol [RFC4120].  This document may freely use
+   terminology and notation from these documents without reference or
+   further explanation.
+
+   The word padata is used as a shorthand for pre-authentication data.
+
+   A conversation is the set of all authentication messages exchanged
+   between the client and the client's Authentication Service (AS) in
+   order to authenticate the client principal.  A conversation as
+   defined here consists of all messages that are necessary to complete
+   the authentication between the client and the client's AS.  In the
+   Ticket Granting Service (TGS) exchange, a conversation consists of
+   the request message and the reply message.  The term conversation is
+   defined here for both AS and TGS for convenience of discussion.  See
+   Section 5.2 for specific rules on the extent of a conversation in the
+   AS-REQ case.  Prior to this framework, implementations needed to use
+   implementation-specific heuristics to determine the extent of a
+   conversation.
+
+   If the KDC reply in an AS exchange is verified, the KDC is
+   authenticated by the client.  In this document, verification of the
+   KDC reply is used as a synonym of authentication of the KDC.
+
+1.2.  Conformance Requirements
+
+   This section summarizes the mandatory-to-implement subset of this
+   specification as a convenience to implementors.  The actual
+   requirements and their context are stated in the body of the
+   document.
+
+   Clients conforming to this specification MUST support the padata
+   defined in Section 5.2.
+
+
+
+
+Hartman & Zhu                Standards Track                    [Page 5]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   Conforming implementations MUST support Kerberos FAST padata
+   (Section 5.4).  Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor (Section 5.4.6).
+
+2.  Model for Pre-Authentication
+
+   When a Kerberos client wishes to obtain a ticket, it sends an initial
+   Authentication Service (AS) request to the KDC.  If pre-
+   authentication is required but not being used, then the KDC will
+   respond with a KDC_ERR_PREAUTH_REQUIRED error [RFC4120].
+   Alternatively, if the client knows what pre-authentication to use, it
+   MAY optimize away a round trip and send an initial request with
+   padata included in the initial request.  If the client includes the
+   padata computed using the wrong pre-authentication mechanism or
+   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+   indication of what padata should have been included.  In that case,
+   the client MUST retry with no padata and examine the error data of
+   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
+   authentication information in the accompanying error data of
+   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data and
+   then retry.
+
+   The conventional KDC maintains no state between two requests;
+   subsequent requests may even be processed by a different KDC.  On the
+   other hand, the client treats a series of exchanges with KDCs as a
+   single conversation.  Each exchange accumulates state and hopefully
+   brings the client closer to a successful authentication.
+
+   These models for state management are in apparent conflict.  For many
+   of the simpler pre-authentication scenarios, the client uses one
+   round trip to find out what mechanisms the KDC supports.  Then, the
+   next request contains sufficient pre-authentication for the KDC to be
+   able to return a successful reply.  For these simple scenarios, the
+   client only sends one request with pre-authentication data and so the
+   conversation is trivial.  For more complex conversations, the KDC
+   needs to provide the client with a cookie to include in future
+   requests to capture the current state of the authentication session.
+   Handling of multiple round-trip mechanisms is discussed in
+   Section 5.2.
+
+   This framework specifies the behavior of Kerberos pre-authentication
+   mechanisms used to identify users or to modify the reply key used to
+   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
+   extensions to Kerberos that have nothing to do with proving the
+
+
+
+
+Hartman & Zhu                Standards Track                    [Page 6]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   identity of the user or establishing a reply key.  Such extensions
+   are outside the scope of this framework.  However, mechanisms that do
+   accomplish these goals should follow this framework.
+
+   This framework specifies the minimum state that a Kerberos
+   implementation needs to maintain while handling a request in order to
+   process pre-authentication.  It also specifies how Kerberos
+   implementations process the padata at each step of the AS request
+   process.
+
+2.1.  Information Managed by the Pre-Authentication Model
+
+   The following information is maintained by the client and KDC as each
+   request is being processed:
+
+   o  The reply key used to encrypt the KDC reply
+
+   o  How strongly the identity of the client has been authenticated
+
+   o  Whether the reply key has been used in this conversation
+
+   o  Whether the reply key has been replaced in this conversation
+
+   o  Whether the origin of the KDC reply can be verified by the client
+      (i.e., whether the KDC is authenticated to the client)
+
+   Conceptually, the reply key is initially the long-term key of the
+   principal.  However, principals can have multiple long-term keys
+   because of support for multiple encryption types, salts, and
+   string2key parameters.  As described in Section 5.2.7.5 of the
+   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+   the client what types of keys are available.  Thus, in full
+   generality, the reply key in the pre-authentication model is actually
+   a set of keys.  At the beginning of a request, it is initialized to
+   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+   the KDC.  If multiple reply keys are available, the client chooses
+   which one to use.  Thus, the client does not need to treat the reply
+   key as a set.  At the beginning of a request, the client picks a key
+   to use.
+
+   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+   INFO2 element.  Since the KDC already knows the client's list of
+   supported enctypes from the request, no interoperability problems are
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                    [Page 7]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   created by choosing a single possible reply key.  This way, the KDC
+   implementation avoids the complexity of treating the reply key as a
+   set.
+
+   When the padata in the request are verified by the KDC, then the
+   client is known to have that key; therefore, the KDC SHOULD pick the
+   same key as the reply key.
+
+   At the beginning of handling a message on both the client and the
+   KDC, the client's identity is not authenticated.  A mechanism may
+   indicate that it has successfully authenticated the client's
+   identity.  It is useful to keep track of this information on the
+   client in order to know what pre-authentication mechanisms should be
+   used.  The KDC needs to keep track of whether the client is
+   authenticated because the primary purpose of pre-authentication is to
+   authenticate the client identity before issuing a ticket.  The
+   handling of authentication strength using various authentication
+   mechanisms is discussed in Section 5.5.
+
+   Initially, the reply key is not used.  A pre-authentication mechanism
+   that uses the reply key to encrypt or checksum some data in the
+   generation of new keys MUST indicate that the reply key is used.
+   This state is maintained by the client and the KDC to enforce the
+   security requirement stated in Section 3.3 that the reply key SHOULD
+   NOT be replaced after it is used.
+
+   Initially, the reply key is not replaced.  If a mechanism implements
+   the Replace Reply Key facility discussed in Section 3.3, then the
+   state MUST be updated to indicate that the reply key has been
+   replaced.  Once the reply key has been replaced, knowledge of the
+   reply key is insufficient to authenticate the client.  The reply key
+   is marked as replaced in exactly the same situations as the KDC reply
+   is marked as not being verified to the client principal.  However,
+   while mechanisms can verify the KDC reply to the client, once the
+   reply key is replaced, then the reply key remains replaced for the
+   remainder of the conversation.
+
+   Without pre-authentication, the client knows that the KDC reply is
+   authentic and has not been modified because it is encrypted in a
+   long-term key of the client.  Only the KDC and the client know that
+   key.  So, at the start of a conversation, the KDC reply is presumed
+   to be verified using the client's long-term key.  It should be noted
+   that in this document, verifying the KDC reply means authenticating
+   the KDC, and these phrases are used interchangeably.  Any pre-
+   authentication mechanism that sets a new reply key not based on the
+   principal's long-term secret MUST either verify the KDC reply some
+   other way or indicate that the reply is not verified.  If a mechanism
+   indicates that the reply is not verified, then the client
+
+
+
+Hartman & Zhu                Standards Track                    [Page 8]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   implementation MUST return an error unless a subsequent mechanism
+   verifies the reply.  The KDC needs to track this state so it can
+   avoid generating a reply that is not verified.
+
+   In this specification, KDC verification/authentication refers to the
+   level of authentication of the KDC to the client provided by RFC
+   4120.  There is a stronger form of KDC verification that, while
+   sometimes important in Kerberos deployments, is not addressed in this
+   specification: the typical Kerberos request does not provide a way
+   for the client machine to know that it is talking to the correct KDC.
+   Someone who can inject packets into the network between the client
+   machine and the KDC and who knows the password that the user will
+   give to the client machine can generate a KDC reply that will decrypt
+   properly.  So, if the client machine needs to authenticate that the
+   user is in fact the named principal, then the client machine needs to
+   do a TGS request for itself as a service.  Some pre-authentication
+   mechanisms may provide a way for the client machine to authenticate
+   the KDC.  Examples of this include signing the reply that can be
+   verified using a well-known public key or providing a ticket for the
+   client machine as a service.
+
+2.2.  Initial Pre-Authentication Required Error
+
+   Typically, a client starts a conversation by sending an initial
+   request with no pre-authentication.  If the KDC requires pre-
+   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
+   (defined in Section 5.2) for pre-authentication configurations that
+   use multi-round-trip mechanisms; see Section 2.4 for details of that
+   case.
+
+   The KDC needs to choose which mechanisms to offer the client.  The
+   client needs to be able to choose what mechanisms to use from the
+   first message.  For example, consider the KDC that will accept
+   mechanism A followed by mechanism B or alternatively the single
+   mechanism C.  A client that supports A and C needs to know that it
+   should not bother trying A.
+
+   Mechanisms can either be sufficient on their own or can be part of an
+   authentication set -- a group of mechanisms that all need to
+   successfully complete in order to authenticate a client.  Some
+   mechanisms may only be useful in authentication sets; others may be
+   useful alone or in authentication sets.  For the second group of
+   mechanisms, KDC policy dictates whether the mechanism will be part of
+   an authentication set, offered alone, or both.  For each mechanism
+   that is offered alone (even if it is also offered in an
+   authentication set), the KDC includes the pre-authentication type ID
+
+
+
+Hartman & Zhu                Standards Track                    [Page 9]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   of the mechanism in the padata sequence returned in the
+   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
+   part of an authentication set are not directly represented in the
+   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
+   although they are represented in the PA-AUTHENTICATION-SET sequence.
+
+   The KDC SHOULD NOT send data that is encrypted in the long-term
+   password-based key of the principal.  Doing so has the same security
+   exposures as the Kerberos protocol without pre-authentication.  There
+   are few situations where the KDC needs to expose cipher text
+   encrypted in a weak key before the client has proven knowledge of
+   that key, and where pre-authentication is desirable.
+
+2.3.  Client to KDC
+
+   This description assumes that a client has already received a
+   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
+   optimistic pre-authentication, then the client needs to guess values
+   for the information it would normally receive from that error
+   response or use cached information obtained in prior interactions
+   with the KDC.
+
+   The client starts by initializing the pre-authentication state as
+   specified.  It then processes the padata in the
+   KDC_ERR_PREAUTH_REQUIRED.
+
+   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+   client MAY ignore any padata it chooses unless doing so violates a
+   specification to which the client conforms.  Clients conforming to
+   this specification MUST NOT ignore the padata defined in Section 5.2.
+   Clients SHOULD choose one authentication set or mechanism that could
+   lead to authenticating the user and ignore other such mechanisms.
+   However, this rule does not affect the processing of padata unrelated
+   to this framework; clients SHOULD process such padata normally.
+   Since the list of mechanisms offered by the KDC is in the decreasing
+   preference order, clients typically choose the first mechanism or
+   authentication set that the client can usefully perform.  If a client
+   chooses to ignore padata, it MUST NOT process the padata, allow the
+   padata to affect the pre-authentication state, or respond to the
+   padata.
+
+   For each instance of padata the client chooses to process, the client
+   processes the padata and modifies the pre-authentication state as
+   required by that mechanism.
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 10]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   After processing the padata in the KDC error, the client generates a
+   new request.  It processes the pre-authentication mechanisms in the
+   order in which they will appear in the next request, updating the
+   state as appropriate.  The request is sent when it is complete.
+
+2.4.  KDC to Client
+
+   When a KDC receives an AS request from a client, it needs to
+   determine whether it will respond with an error or an AS reply.
+   There are many causes for an error to be generated that have nothing
+   to do with pre-authentication; they are discussed in the core
+   Kerberos specification.
+
+   From the standpoint of evaluating the pre-authentication, the KDC
+   first starts by initializing the pre-authentication state.  If a PA-
+   FX-COOKIE pre-authentication data item is present, it is processed
+   first; see Section 5.2 for a definition.  It then processes the
+   padata in the request.  As mentioned in Section 2.3, the KDC MAY
+   ignore padata that are inappropriate for the configuration and MUST
+   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
+   types used in previous messages.  For example, if a KDC issues a
+   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+   KDC cannot ignore padata of type x received in an AS-REQ message from
+   the client.
+
+   At this point, the KDC decides whether it will issue an error or a
+   reply.  Typically, a KDC will issue a reply if the client's identity
+   has been authenticated to a sufficient degree.
+
+   In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC
+   first starts by initializing the pre-authentication state.  Then, it
+   processes any padata in the client's request in the order provided by
+   the client.  Mechanisms that are not understood by the KDC are
+   ignored.  Next, it generates padata for the error response, modifying
+   the pre-authentication state appropriately as each mechanism is
+   processed.  The KDC chooses the order in which it will generate
+   padata (and thus the order of padata in the response), but it needs
+   to modify the pre-authentication state consistently with the choice
+   of order.  For example, if some mechanism establishes an
+   authenticated client identity, then the subsequent mechanisms in the
+   generated response receive this state as input.  After the padata are
+   generated, the error response is sent.  Typically, the errors with
+   the code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will
+   include KDC state, as discussed in Section 5.2.
+
+   To generate a final reply, the KDC generates the padata modifying the
+   pre-authentication state as necessary.  Then, it generates the final
+   response, encrypting it in the current pre-authentication reply key.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 11]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+3.  Pre-Authentication Facilities
+
+   Pre-authentication mechanisms can be thought of as providing various
+   conceptual facilities.  This serves two useful purposes.  First,
+   mechanism authors can choose only to solve one specific small
+   problem.  It is often useful for a mechanism designed to offer key
+   management not to directly provide client authentication but instead
+   to allow one or more other mechanisms to handle this need.  Secondly,
+   thinking about the abstract services that a mechanism provides yields
+   a minimum set of security requirements that all mechanisms providing
+   that facility must meet.  These security requirements are not
+   complete; mechanisms will have additional security requirements based
+   on the specific protocol they employ.
+
+   A mechanism is not constrained to only offering one of these
+   facilities.  While such mechanisms can be designed and are sometimes
+   useful, many pre-authentication mechanisms implement several
+   facilities.  It is often easier to construct a secure, simple
+   solution by combining multiple facilities in a single mechanism than
+   by solving the problem in full generality.  Even when mechanisms
+   provide multiple facilities, they need to meet the security
+   requirements for all the facilities they provide.  If the FAST factor
+   approach is used, it is likely that one or a small number of
+   facilities can be provided by a single mechanism without complicating
+   the security analysis.
+
+   According to Kerberos extensibility rules (Section 1.5 of the
+   Kerberos specification [RFC4120]), an extension MUST NOT change the
+   semantics of a message unless a recipient is known to understand that
+   extension.  Because a client does not know that the KDC supports a
+   particular pre-authentication mechanism when it sends an initial
+   request, a pre-authentication mechanism MUST NOT change the semantics
+   of the request in a way that will break a KDC that does not
+   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
+   clients that affect the core semantics unless the client has
+   indicated support for the message.
+
+   The only state in this model that would break the interpretation of a
+   message is changing the expected reply key.  If one mechanism changed
+   the reply key and a later mechanism used that reply key, then a KDC
+   that interpreted the second mechanism but not the first would fail to
+   interpret the request correctly.  In order to avoid this problem,
+   extensions that change core semantics are typically divided into two
+   parts.  The first part proposes a change to the core semantic -- for
+   example, proposes a new reply key.  The second part acknowledges that
+   the extension is understood and that the change takes effect.
+   Section 3.2 discusses how to design mechanisms that modify the reply
+   key to be split into a proposal and acceptance without requiring
+
+
+
+Hartman & Zhu                Standards Track                   [Page 12]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   additional round trips to use the new reply key in subsequent pre-
+   authentication.  Other changes in the state described in Section 2.1
+   can safely be ignored by a KDC that does not understand a mechanism.
+   Mechanisms that modify the behavior of the request outside the scope
+   of this framework need to carefully consider the Kerberos
+   extensibility rules to avoid similar problems.
+
+3.1.  Client Authentication Facility
+
+   The Client Authentication facility proves the identity of a user to
+   the KDC before a ticket is issued.  Examples of mechanisms
+   implementing this facility include the encrypted timestamp facility,
+   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+   Mechanisms that provide this facility are expected to mark the client
+   as authenticated.
+
+   Mechanisms implementing this facility SHOULD require the client to
+   prove knowledge of the reply key before transmitting a successful KDC
+   reply.  Otherwise, an attacker can intercept the pre-authentication
+   exchange and get a reply to attack.  One way of proving the client
+   knows the reply key is to implement the Replace Reply Key facility
+   along with this facility.  The Public Key Cryptography for Initial
+   Authentication in Kerberos (PKINIT) mechanism [RFC4556] implements
+   Client Authentication alongside Replace Reply Key.
+
+   If the reply key has been replaced, then mechanisms such as
+   encrypted-timestamp that rely on knowledge of the reply key to
+   authenticate the client MUST NOT be used.
+
+3.2.  Strengthening Reply Key Facility
+
+   Particularly when dealing with keys based on passwords, it is
+   desirable to increase the strength of the key by adding additional
+   secrets to it.  Examples of sources of additional secrets include the
+   results of a Diffie-Hellman key exchange or key bits from the output
+   of a smart card [KRB-WG.SAM].  Typically, these additional secrets
+   can be first combined with the existing reply key and then converted
+   to a protocol key using tools defined in Section 5.1.
+
+   Typically, a mechanism implementing this facility will know that the
+   other side of the exchange supports the facility before the reply key
+   is changed.  For example, a mechanism might need to learn the
+   certificate for a KDC before encrypting a new key in the public key
+   belonging to that certificate.  However, if a mechanism implementing
+   this facility wishes to modify the reply key before knowing that the
+   other party in the exchange supports the mechanism, it proposes
+   modifying the reply key.  The other party then includes a message
+   indicating that the proposal is accepted if it is understood and
+
+
+
+Hartman & Zhu                Standards Track                   [Page 13]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   meets policy.  In many cases, it is desirable to use the new reply
+   key for client authentication and for other facilities.  Waiting for
+   the other party to accept the proposal and actually modify the reply
+   key state would add an additional round trip to the exchange.
+   Instead, mechanism designers are encouraged to include a typed hole
+   for additional padata in the message that proposes the reply key
+   change.  The padata included in the typed hole are generated assuming
+   the new reply key.  If the other party accepts the proposal, then
+   these padata are considered as an inner level.  As with the outer
+   level, one authentication set or mechanism is typically chosen for
+   client authentication, along with auxiliary mechanisms such as KDC
+   cookies, and other mechanisms are ignored.  When mechanisms include
+   such a container, the hint provided for use in authentication sets
+   (as defined in Section 5.3) MUST contain a sequence of inner
+   mechanisms along with hints for those mechanisms.  The party
+   generating the proposal can determine whether the padata were
+   processed based on whether the proposal for the reply key is
+   accepted.
+
+   The specific formats of the proposal message, including where padata
+   are included, is a matter for the mechanism specification.
+   Similarly, the format of the message accepting the proposal is
+   mechanism specific.
+
+   Mechanisms implementing this facility and including a typed hole for
+   additional padata MUST checksum that padata using a keyed checksum or
+   encrypt the padata.  This requirement protects against modification
+   of the contents of the typed hole.  By modifying these contents, an
+   attacker might be able to choose which mechanism is used to
+   authenticate the client, or to convince a party to provide text
+   encrypted in a key that the attacker had manipulated.  It is
+   important that mechanisms strengthen the reply key enough that using
+   it to checksum padata is appropriate.
+
+3.3.  Replace Reply Key Facility
+
+   The Replace Reply Key facility replaces the key in which a successful
+   AS reply will be encrypted.  This facility can only be used in cases
+   where knowledge of the reply key is not used to authenticate the
+   client.  The new reply key MUST be communicated to the client and the
+   KDC in a secure manner.  This facility MUST NOT be used if there can
+   be a man-in-the-middle between the client and the KDC.  Mechanisms
+   implementing this facility MUST mark the reply key as replaced in the
+   pre-authentication state.  Mechanisms implementing this facility MUST
+   either provide a mechanism to verify the KDC reply to the client or
+   mark the reply as unverified in the pre-authentication state.
+   Mechanisms implementing this facility SHOULD NOT be used if a
+   previous mechanism has used the reply key.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 14]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   As with the Strengthening Reply Key facility, Kerberos extensibility
+   rules require that the reply key not be changed unless both sides of
+   the exchange understand the extension.  In the case of this facility,
+   it will likely be the case for both sides to know that the facility
+   is available by the time that the new key is available to be used.
+   However, mechanism designers can use a container for padata in a
+   proposal message, as discussed in Section 3.2, if appropriate.
+
+3.4.  KDC Authentication Facility
+
+   This facility verifies that the reply comes from the expected KDC.
+   In traditional Kerberos, the KDC and the client share a key, so if
+   the KDC reply can be decrypted, then the client knows that a trusted
+   KDC responded.  Note that the client machine cannot trust the client
+   unless the machine is presented with a service ticket for it
+   (typically, the machine can retrieve this ticket by itself).
+   However, if the reply key is replaced, some mechanism is required to
+   verify the KDC.  Pre-authentication mechanisms providing this
+   facility allow a client to determine that the expected KDC has
+   responded even after the reply key is replaced.  They mark the pre-
+   authentication state as having been verified.
+
+4.  Requirements for Pre-Authentication Mechanisms
+
+   This section lists requirements for specifications of pre-
+   authentication mechanisms.
+
+   For each message in the pre-authentication mechanism, the
+   specification describes the pa-type value to be used and the contents
+   of the message.  The processing of the message by the sender and
+   recipient is also specified.  This specification needs to include all
+   modifications to the pre-authentication state.
+
+   Generally, mechanisms have a message that can be sent in the error
+   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+   authentication set.  If the client needs information, such as trusted
+   certificate authorities, in order to determine if it can use the
+   mechanism, then this information should be in that message.  In
+   addition, such mechanisms should also define a pa-hint to be included
+   in authentication sets.  Often, the same information included in the
+   padata-value is appropriate to include in the pa-hint (as defined in
+   Section 5.3).
+
+   In order to ease security analysis, the mechanism specification
+   should describe what facilities from this document are offered by the
+   mechanism.  For each facility, the security considerations section of
+   the mechanism specification should show that the security
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 15]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   requirements of that facility are met.  This requirement is
+   applicable to any FAST factor that provides authentication
+   information.
+
+   Significant problems have resulted in the specification of Kerberos
+   protocols because much of the KDC exchange is not protected against
+   alteration.  The security considerations section should discuss
+   unauthenticated plaintext attacks.  It should either show that
+   plaintext is protected or discuss what harm an attacker could do by
+   modifying the plaintext.  It is generally acceptable for an attacker
+   to be able to cause the protocol negotiation to fail by modifying
+   plaintext.  More significant attacks should be evaluated carefully.
+
+   As discussed in Section 5.2, there is no guarantee that a client will
+   use the same KDCs for all messages in a conversation.  The mechanism
+   specification needs to show why the mechanism is secure in this
+   situation.  The hardest problem to deal with, especially for
+   challenge/response mechanisms is to make sure that the same response
+   cannot be replayed against two KDCs while allowing the client to talk
+   to any KDC.
+
+4.1.  Protecting Requests/Responses
+
+   Mechanism designers SHOULD protect cleartext portions of pre-
+   authentication data.  Various denial-of-service attacks and downgrade
+   attacks against Kerberos are possible unless plaintexts are somehow
+   protected against modification.  An early design goal of Kerberos
+   Version 5 [RFC4120] was to avoid encrypting more of the
+   authentication exchange than was required.  (Version 4 doubly-
+   encrypted the encrypted part of a ticket in a KDC reply, for
+   example).  This minimization of encryption reduces the load on the
+   KDC and busy servers.  Also, during the initial design of Version 5,
+   the existence of legal restrictions on the export of cryptography
+   made it desirable to minimize of the number of uses of encryption in
+   the protocol.  Unfortunately, performing this minimization created
+   numerous instances of unauthenticated security-relevant plaintext
+   fields.
+
+   Mechanisms MUST guarantee that by the end of a successful
+   authentication exchange, both the client and the KDC have verified
+   all the plaintext sent by the other party.  If there is more than one
+   round trip in the exchange, mechanisms MUST additionally guarantee
+   that no individual messages were reordered or replayed from a
+   previous exchange.  Strategies for accomplishing this include using
+   message authentication codes (MACs) to protect the plaintext as it is
+   sent including some form of nonce or cookie to allow for the chaining
+   of state from one message to the next or exchanging a MAC of the
+   entire conversation after a key is established.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 16]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   Mechanism designers need to provide a strategy for updating
+   cryptographic algorithms, such as defining a new pre-authentication
+   type for each algorithm or taking advantage of the client's list of
+   supported RFC 3961 encryption types to indicate the client's support
+   for cryptographic algorithms.
+
+   Primitives defined in [RFC3961] are RECOMMENDED for integrity
+   protection and confidentiality.  Mechanisms based on these primitives
+   are crypto-agile as the result of using [RFC3961] along with
+   [RFC4120].  The advantage afforded by crypto-agility is the ability
+   to incrementally deploy a fix specific to a particular algorithm thus
+   avoid a multi-year standardization and deployment cycle, when real
+   attacks do arise against that algorithm.
+
+   Note that data used by FAST factors (defined in Section 5.4) is
+   encrypted in a protected channel; thus, they do not share the un-
+   authenticated-text issues with mechanisms designed as full-blown pre-
+   authentication mechanisms.
+
+5.  Tools for Use in Pre-Authentication Mechanisms
+
+   This section describes common tools needed by multiple pre-
+   authentication mechanisms.  By using these tools, mechanism designers
+   can use a modular approach to specify mechanism details and ease
+   security analysis.
+
+5.1.  Combining Keys
+
+   Frequently, a weak key needs to be combined with a stronger key
+   before use.  For example, passwords are typically limited in size and
+   insufficiently random: therefore, it is desirable to increase the
+   strength of the keys based on passwords by adding additional secrets.
+   An additional source of secrecy may come from hardware tokens.
+
+   This section provides standard ways to combine two keys into one.
+
+   KRB-FX-CF1() is defined to combine two passphrases.
+
+       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+       KRB-FX-CF1(x, y) := x || y
+
+   Where || denotes concatenation.  The strength of the final key is
+   roughly the total strength of the individual keys being combined,
+   assuming that the string_to_key() function [RFC3961] uses all its
+   input evenly.
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 17]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   An example usage of KRB-FX-CF1() is when a device provides random but
+   short passwords, the password is often combined with a personal
+   identification number (PIN).  The password and the PIN can be
+   combined using KRB-FX-CF1().
+
+   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+   function defined in [RFC3961].
+
+   Given two input keys, K1 and K2, where K1 and K2 can be of two
+   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+   follows:
+
+       KRB-FX-CF2(protocol key, protocol key, octet string,
+                 octet string)  ->  (protocol key)
+
+       PRF+(K1, pepper1) -> octet-string-1
+       PRF+(K2, pepper2) -> octet-string-2
+       KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
+              random-to-key(octet-string-1 ^ octet-string-2)
+
+   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
+   follows:
+
+    PRF+(protocol key, octet string) -> (octet string)
+
+    PRF+(key, shared-info) := pseudo-random( key,  1 || shared-info ) ||
+                  pseudo-random( key, 2 || shared-info ) ||
+                  pseudo-random( key, 3 || shared-info ) || ...
+
+   Here the counter value 1, 2, 3, and so on are encoded as a one-octet
+   integer.  The pseudo-random() operation is specified by the enctype
+   of the protocol key.  PRF+() uses the counter to generate enough bits
+   as needed by the random-to-key() [RFC3961] function for the
+   encryption type specified for the resulting key; unneeded bits are
+   removed from the tail.  Unless otherwise specified, the resulting
+   enctype of KRB-FX-CF2 is the enctype of k1.  The pseudo-random()
+   operation is the RFC 3961 pseudo-random() operation for the
+   corresponding input key; the random-to-key() operation is the RFC
+   3961 random-to-key operation for the resulting key.
+
+   Mechanism designers MUST specify the values for the input parameter
+   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
+   pepper1 and pepper2 MUST be distinct so that if the two keys being
+   combined are the same, the resulting key is not a trivial key.
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 18]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+5.2.  Managing States for the KDC
+
+   Kerberos KDCs are stateless in that there is no requirement that
+   clients will choose the same KDC for the second request in a
+   conversation.  Proxies or other intermediate nodes may also influence
+   KDC selection.  So, each request from a client to a KDC must include
+   sufficient information that the KDC can regenerate any needed state.
+   This is accomplished by giving the client a potentially long opaque
+   cookie in responses to include in future requests in the same
+   conversation.  The KDC MAY respond that a conversation is too old and
+   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+       KDC_ERR_PREAUTH_EXPIRED            90
+
+   When a client receives this error, the client SHOULD abort the
+   existing conversation, and restart a new one.
+
+   An example, where more than one message from the client is needed, is
+   when the client is authenticated based on a challenge/response
+   scheme.  In that case, the KDC needs to keep track of the challenge
+   issued for a client authentication request.
+
+   The PA-FX-COOKIE padata type is defined in this section to facilitate
+   state management in the AS exchange.  These padata are sent by the
+   KDC when the KDC requires state for a future transaction.  The client
+   includes this opaque token in the next message in the conversation.
+   The token may be relatively large; clients MUST be prepared for
+   tokens somewhat larger than the size of all messages in a
+   conversation.
+
+       PA-FX-COOKIE                       133
+           -- Stateless cookie that is not tied to a specific KDC.
+
+   The corresponding padata-value field [RFC4120] contains an opaque
+   token that will be echoed by the client in its response to an error
+   from the KDC.
+
+   The cookie token is generated by the KDC and transmitted in a PA-FX-
+   COOKIE pre-authentication data item of a KRB-ERROR message.  The
+   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+   element into the next message of the same conversation.  The content
+   of the cookie field is a local matter of the KDC.  As a result, it is
+   not generally possible to mix KDC implementations from different
+   vendors in the same realm.  However, the KDC MUST construct the
+   cookie token in such a manner that a malicious client cannot subvert
+   the authentication process by manipulating the token.  The KDC
+   implementation needs to consider expiration of tokens, key rollover,
+   and other security issues in token design.  The content of the cookie
+
+
+
+Hartman & Zhu                Standards Track                   [Page 19]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   field is likely specific to the pre-authentication mechanisms used to
+   authenticate the client.  If a client authentication response can be
+   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+   expiration in the cookie is RECOMMENDED to prevent the response being
+   presented indefinitely.  Implementations need to consider replay both
+   of an entire conversation and of messages within a conversation when
+   designing what information is stored in a cookie and how pre-
+   authentication mechanisms are implemented.
+
+   If at least one more message for a mechanism or a mechanism set is
+   expected by the KDC, the KDC returns a
+   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to
+   identify the conversation with the client, according to Section 2.2.
+   The cookie is not expected to stay constant for a conversation: the
+   KDC is expected to generate a new cookie for each message.
+
+        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED   91
+
+   A client MAY throw away the state associated with a conversation and
+   begin a new conversation by discarding its state and not including a
+   cookie in the first message of a conversation.  KDCs that comply with
+   this specification MUST include a cookie in a response when the
+   client can continue the conversation.  In particular, a KDC MUST
+   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.  KDCs SHOULD include a cookie in
+   errors containing additional information allowing a client to retry.
+   One reasonable strategy for meeting these requirements is to always
+   include a cookie in KDC errors.
+
+   A KDC MAY indicate that it is terminating a conversation by not
+   including a cookie in a response.  When FAST is used, clients can
+   assume that the absence of a cookie means that the KDC is ending the
+   conversation.  Similarly, if a cookie is seen at all during a
+   conversation, clients MAY assume that the absence of a cookie in a
+   future message means that the KDC is ending the conversation.
+   Clients also need to deal with KDCs, prior to this specification,
+   that do not include cookies; if neither cookies nor FAST are used in
+   a conversation, the absence of a cookie is not a strong indication
+   that the KDC is terminating the conversation.
+
+5.3.  Pre-Authentication Set
+
+   If all mechanisms in a group need to successfully complete in order
+   to authenticate a client, the client and the KDC SHOULD use the PA-
+   AUTHENTICATION-SET padata element.
+
+        PA-AUTHENTICATION-SET              134
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 20]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+   encoding of the PA-AUTHENTICATION-SET structure:
+
+        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+            pa-type      [0] Int32,
+                -- same as padata-type.
+            pa-hint      [1] OCTET STRING OPTIONAL,
+            pa-value     [2] OCTET STRING OPTIONAL,
+            ...
+        }
+
+   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+   contains the corresponding value of padata-type in PA-DATA [RFC4120].
+   Associated with the pa-type is a pa-hint, which is an octet string
+   specified by the pre-authentication mechanism.  This hint may provide
+   information for the client that helps it determine whether the
+   mechanism can be used.  For example, a public-key mechanism might
+   include the certificate authorities it trusts in the hint info.  Most
+   mechanisms today do not specify hint info; if a mechanism does not
+   specify hint info, the KDC MUST NOT send a hint for that mechanism.
+   To allow future revisions of mechanism specifications to add hint
+   info, clients MUST ignore hint info received for mechanisms that the
+   client believes do not support hint info.  The pa-value element of
+   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+   first padata-value from the KDC to the client.  If the client chooses
+   this authentication set, then the client MUST process this pa-value.
+   The pa-value element MUST be absent for all but the first entry in
+   the authentication set.  Clients MUST ignore the pa-value for the
+   second and following entries in the authentication set.
+
+   If the client chooses an authentication set, then its first AS-REQ
+   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
+   element contains the encoding of the PA-AUTHENTICATION-SET sequence
+   received from the KDC corresponding to the authentication set that is
+   chosen.  The client MUST use the same octet values received from the
+   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
+   wise comparison to identify the selected authentication set.
+   Permitting bit-wise comparison may limit the ability to use certain
+   pre-authentication mechanisms that generate a dynamic challenge in an
+   authentication set with optimistic selection of an authentication
+   set.  As with other optimistic pre-authentication failures, the KDC
+   MAY return KDC_ERR_PREAUTH_FAILED with a new list of pre-
+   authentication mechanisms (including authentication sets) if
+   optimistic pre-authentication fails.  The PA-AUTH-SET-SELECTED padata
+   element MUST come before any padata elements from the authentication
+   set in the padata sequence in the AS-REQ message.  The client MAY
+
+
+
+Hartman & Zhu                Standards Track                   [Page 21]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   cache authentication sets from prior messages and use them to
+   construct an optimistic initial AS-REQ.  If the KDC receives a PA-
+   AUTH-SET-SELECTED padata element that does not correspond to an
+   authentication set that it would offer, then the KDC returns the
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data in this
+   error contains a sequence of padata just as for the
+   KDC_ERR_PREAUTH_REQUIRED error.
+
+         PA-AUTH-SET-SELECTED                   135
+         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+   The PA-AUTHENTICATION-SET appears only in the first message from the
+   KDC to the client.  In particular, the client MAY fail if the
+   authentication mechanism sets change as the conversation progresses.
+   Clients MAY assume that the hints provided in the authentication set
+   contain enough information that the client knows what user interface
+   elements need to be displayed during the entire authentication
+   conversation.  Exceptional circumstances, such as expired passwords
+   or expired accounts, may require that additional user interface be
+   displayed.  Mechanism designers need to carefully consider the design
+   of their hints so that the client has this information.  This way,
+   clients can construct necessary dialogue boxes or wizards based on
+   the authentication set and can present a coherent user interface.
+   Current standards for user interfaces do not provide an acceptable
+   experience when the client has to ask additional questions later in
+   the conversation.
+
+   When indicating which sets of pre-authentication mechanisms are
+   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+   for each pre-authentication mechanism set.
+
+   The client sends the padata-value for the first mechanism it picks in
+   the pre-authentication set, when the first mechanism completes, the
+   client and the KDC will proceed with the second mechanism, and so on
+   until all mechanisms complete successfully.  The PA-FX-COOKIE, as
+   defined in Section 5.2, MUST be sent by the KDC.  One reason for this
+   requirement is so that the conversation can continue if the
+   conversation involves multiple KDCs.  KDCs MUST support clients that
+   do not include a cookie because they optimistically choose an
+   authentication set, although they MAY always return a
+   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
+   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
+   FX-COOKIE.
+
+   Before the authentication succeeds and a ticket is returned, the
+   message that the client sends is an AS-REQ and the message that the
+   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
+   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
+
+
+
+Hartman & Zhu                Standards Track                   [Page 22]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   in Section 5.2 and the accompanying e-data contains the DER encoding
+   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
+   the METHOD-DATA.  If there are no padata, the e-data field is absent
+   in the KRB-ERROR message.
+
+   If the client sends the last message for a given mechanism, then the
+   KDC sends the first message for the next mechanism.  If the next
+   mechanism does not start with a KDC-side challenge, then the KDC
+   includes a padata item with the appropriate pa-type and an empty pa-
+   data.
+
+   If the KDC sends the last message for a particular mechanism, the KDC
+   also includes the first padata for the next mechanism.
+
+5.4.  Definition of Kerberos FAST Padata
+
+   As described in [RFC4120], Kerberos is vulnerable to offline
+   dictionary attacks.  An attacker can request an AS-REP and try
+   various passwords to see if they can decrypt the resulting ticket.
+   RFC 4120 provides the encrypted timestamp pre-authentication method
+   that ameliorates the situation somewhat by requiring that an attacker
+   observe a successful authentication.  However, stronger security is
+   desired in many environments.  The Kerberos FAST pre-authentication
+   padata defined in this section provides a tool to significantly
+   reduce vulnerability to offline dictionary attacks.  When combined
+   with encrypted challenge, FAST requires an attacker to mount a
+   successful man-in-the-middle attack to observe ciphertext.  When
+   combined with host keys, FAST can even protect against active
+   attacks.  FAST also provides solutions to common problems for pre-
+   authentication mechanisms such as binding of the request and the
+   reply and freshness guarantee of the authentication.  FAST itself,
+   however, does not authenticate the client or the KDC; instead, it
+   provides a typed hole to allow pre-authentication data be tunneled.
+   A pre-authentication data element used within FAST is called a "FAST
+   factor".  A FAST factor captures the minimal work required for
+   extending Kerberos to support a new pre-authentication scheme.
+
+   A FAST factor MUST NOT be used outside of FAST unless its
+   specification explicitly allows so.  The typed holes in FAST messages
+   can also be used as generic holes for other padata that are not
+   intended to prove the client's identity, or establish the reply key.
+
+   New pre-authentication mechanisms SHOULD be designed as FAST factors,
+   instead of full-blown pre-authentication mechanisms.
+
+   FAST factors that are pre-authentication mechanisms MUST meet the
+   requirements in Section 4.
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 23]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   FAST employs an armoring scheme.  The armor can be a Ticket Granting
+   Ticket (TGT) obtained by the client's machine using the host keys to
+   pre-authenticate with the KDC, or an anonymous TGT obtained based on
+   anonymous PKINIT [RFC6112] [RFC4556].
+
+   The rest of this section describes the types of armors and the syntax
+   of the messages used by FAST.  Conforming implementations MUST
+   support Kerberos FAST padata.
+
+   Any FAST armor scheme MUST provide a fresh armor key for each
+   conversation.  Clients and KDCs can assume that if a message is
+   encrypted and integrity protected with a given armor key, then it is
+   part of the conversation using that armor key.
+
+   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+   as a pre-authentication mechanism.
+
+5.4.1.  FAST Armors
+
+   An armor key is used to encrypt pre-authentication data in the FAST
+   request and the response.  The KrbFastArmor structure is defined to
+   identify the armor key.  This structure contains the following two
+   fields: the armor-type identifies the type of armors and the armor-
+   value is an OCTET STRING that contains the description of the armor
+   scheme and the armor key.
+
+        KrbFastArmor ::= SEQUENCE {
+            armor-type   [0] Int32,
+                -- Type of the armor.
+            armor-value  [1] OCTET STRING,
+                -- Value of the armor.
+            ...
+        }
+
+   The value of the armor key is a matter of the armor type
+   specification.  Only one armor type is defined in this document.
+
+        FX_FAST_ARMOR_AP_REQUEST           1
+
+   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+   Conforming implementations MUST implement the
+   FX_FAST_ARMOR_AP_REQUEST armor type.  If a FAST KDC receives an
+   unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
+
+   An armor type may be appropriate for use in armoring AS requests,
+   armoring TGS requests, or both.  TGS armor types MUST authenticate
+   the client to the KDC, typically by binding the TGT sub-session key
+
+
+
+Hartman & Zhu                Standards Track                   [Page 24]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   to the armor key.  As discussed below, it is desirable for AS armor
+   types to authenticate the KDC to the client, but this is not
+   required.
+
+   FAST implementations MUST maintain state about whether the armor
+   mechanism authenticates the KDC.  If it does not, then a FAST factor
+   that authenticates the KDC MUST be used if the reply key is replaced.
+
+5.4.1.1.  Ticket-Based Armors
+
+   This is a ticket-based armoring scheme.  The armor-type is
+   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
+   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
+   The armor key is defined by the following function:
+
+       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+                   "subkeyarmor", "ticketarmor" )
+
+   The 'ticket_session_key' is the session key from the ticket in the
+   ap-req.  The 'subkey' is the ap-req subkey.  This construction
+   guarantees that both the KDC (through the session key) and the client
+   (through the subkey) contribute to the armor key.
+
+   The server name field of the armor ticket MUST identify the TGS of
+   the target realm.  Here are three common ways in the decreasing
+   preference order how an armor TGT SHOULD be obtained:
+
+   1.  If the client is authenticating from a host machine whose
+       Kerberos realm has an authentication path to the client's realm,
+       the host machine obtains a TGT by using the host keys.  If the
+       client's realm is different than the realm of the local host, the
+       machine then obtains a cross-realm TGT to the client's realm as
+       the armor ticket.  Otherwise, the host's primary TGT is the armor
+       ticket.
+
+   2.  If the client's host machine cannot obtain a host ticket strictly
+       based on RFC 4120, but the KDC has an asymmetric signing key
+       whose binding with the expected KDC can be verified by the
+       client, the client can use anonymous PKINIT [RFC6112] [RFC4556]
+       to authenticate the KDC and obtain an anonymous TGT as the armor
+       ticket.  The armor ticket can also be a cross-realm TGT obtained
+       based on the initial primary TGT obtained using anonymous PKINIT
+       with KDC authentication.
+
+   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
+       TGT without KDC authentication and that TGT is the armor ticket.
+       Note that this mode of operation is vulnerable to man-in-the-
+
+
+
+Hartman & Zhu                Standards Track                   [Page 25]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+       middle attacks at the time of obtaining the initial anonymous
+       armor TGT.
+
+   If anonymous PKINIT is used to obtain the armor ticket, the KDC
+   cannot know whether its signing key can be verified by the client;
+   hence, the KDC MUST be marked as unverified from the KDC's point of
+   view while the client could be able to authenticate the KDC by
+   verifying the KDC's signing key is bound with the expected KDC.  The
+   client needs to carefully consider the risk and benefit tradeoffs
+   associated with active attacks before exposing cipher text encrypted
+   using the user's long-term secrets when the armor does not
+   authenticate the KDC.
+
+   The TGS MUST reject a request if there is an AD-fx-fast-armor (71)
+   element in the authenticator of the pa-tgs-req padata or if the
+   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+   armor authorization data element.  These tickets and authenticators
+   MAY be used as FAST armor tickets but not to obtain a ticket via the
+   TGS.  This authorization data is used in a system where the
+   encryption of the user's pre-authentication data is performed in an
+   unprivileged user process.  A privileged process can provide to the
+   user process a host ticket, an authenticator for use with that
+   ticket, and the sub-session key contained in the authenticator.  In
+   order for the host process to ensure that the host ticket is not
+   accidentally or intentionally misused, (i.e., the user process might
+   use the host ticket to authenticate as the host), it MUST include a
+   critical authorization data element of the type AD-fx-fast-armor when
+   providing the authenticator or in the enc-authorization-data field of
+   the TGS request used to obtain the TGT.  The corresponding ad-data
+   field of the AD-fx-fast-armor element is empty.
+
+   This armor type is only valid for AS requests; implicit armor,
+   described below in TGS processing, is the only supported way to
+   establish an armor key for the TGS at this time.
+
+5.4.2.  FAST Request
+
+   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+   authentication padata.  The corresponding padata-value field
+   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+   REQUEST.  As with all pre-authentication types, the KDC SHOULD
+   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
+   advertisement of PA-FX-FAST with an empty pa-value.  Clients MUST
+   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
+   error.  FAST is not expected to be used in an authentication set:
+   clients will typically use FAST padata if available and this decision
+   should not depend on what other pre-authentication methods are
+   available.  As such, no pa-hint is defined for FAST at this time.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 26]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+       PA-FX-FAST                         136
+           -- Padata type for Kerberos FAST
+
+       PA-FX-FAST-REQUEST ::= CHOICE {
+           armored-data [0] KrbFastArmoredReq,
+           ...
+       }
+
+       KrbFastArmoredReq ::= SEQUENCE {
+           armor        [0] KrbFastArmor OPTIONAL,
+               -- Contains the armor that identifies the armor key.
+               -- MUST be present in AS-REQ.
+           req-checksum [1] Checksum,
+               -- For AS, contains the checksum performed over the type
+               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+               -- structure;
+               -- For TGS, contains the checksum performed over the type
+               -- AP-REQ in the PA-TGS-REQ padata.
+               -- The checksum key is the armor key, the checksum
+               -- type is the required checksum type for the enctype of
+               -- the armor key, and the key usage number is
+               -- KEY_USAGE_FAST_REQ_CHKSUM.
+           enc-fast-req [2] EncryptedData, -- KrbFastReq --
+               -- The encryption key is the armor key, and the key usage
+               -- number is KEY_USAGE_FAST_ENC.
+           ...
+       }
+
+       KEY_USAGE_FAST_REQ_CHKSUM          50
+       KEY_USAGE_FAST_ENC                 51
+
+   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+   The KrbFastArmoredReq encapsulates the encrypted padata.
+
+   The enc-fast-req field contains an encrypted KrbFastReq structure.
+   The armor key is used to encrypt the KrbFastReq structure, and the
+   key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+   The armor key is selected as follows:
+
+   o  In an AS request, the armor field in the KrbFastArmoredReq
+      structure MUST be present and the armor key is identified
+      according to the specification of the armor type.
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 27]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   o  There are two possibilities for armor for a TGS request.  If the
+      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+      the client SHOULD NOT include the armor field in the Krbfastreq
+      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
+      this case, the armor key is the same armor key that would be
+      computed if the TGS-REQ authenticator was used in an
+      FX_FAST_ARMOR_AP_REQUEST armor.  Clients MAY present a non-TGT in
+      the PA-TGS-REQ authenticator and omit the armor field, in which
+      case the armor key is the same that would be computed if the
+      authenticator were used in an FX_FAST_ARMOR_AP_REQUEST armor.
+      This is the only case where a ticket other than a TGT can be used
+      to establish an armor key; even though the armor key is computed
+      the same as an FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used
+      as an armor ticket in FX_FAST_ARMOR_AP_REQUEST.  Alternatively, a
+      client MAY use an armor type defined in the future for use with
+      the TGS request.
+
+   The req-checksum field contains a checksum computed differently for
+   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
+   BODY for the req-body field of the KDC-REQ structure of the
+   containing message; for a TGS-REQ, it is performed over the type AP-
+   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
+   the armor key, and the checksum type is the required checksum type
+   for the enctype of the armor key per [RFC3961].  This checksum MUST
+   be a keyed checksum and it is included in order to bind the FAST
+   padata to the outer request.  A KDC that implements FAST will ignore
+   the outer request, but including a checksum is relatively cheap and
+   may prevent confusing behavior.
+
+   The KrbFastReq structure contains the following information:
+
+        KrbFastReq ::= SEQUENCE {
+            fast-options [0] FastOptions,
+                -- Additional options.
+            padata       [1] SEQUENCE OF PA-DATA,
+                -- padata typed holes.
+            req-body     [2] KDC-REQ-BODY,
+                -- Contains the KDC request body as defined in Section
+                -- 5.4.1 of [RFC4120].
+                -- This req-body field is preferred over the outer field
+                -- in the KDC request.
+             ...
+        }
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 28]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   The fast-options field indicates various options that are to modify
+   the behavior of the KDC.  The following options are defined:
+
+        FastOptions ::= KerberosFlags
+            -- reserved(0),
+            -- hide-client-names(1),
+
+       Bits    Name                    Description
+      -----------------------------------------------------------------
+       0     RESERVED              Reserved for future expansion of this
+                                   field.
+       1     hide-client-names     Requesting the KDC to hide client
+                                   names in the KDC response, as
+                                   described next in this section.
+       16    kdc-follow-referrals  reserved [REFERRALS].
+
+   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+   critical options.  If the KDC does not support a critical option, it
+   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+   there is no accompanying e-data defined in this document for this
+   error code.  Bit 16 and onward (with bit 16 included) are non-
+   critical options.  KDCs conforming to this specification ignore
+   unknown non-critical options.
+
+        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+   The hide-client-names Option
+
+      The Kerberos response defined in [RFC4120] contains the client
+      identity in cleartext.  This makes traffic analysis
+      straightforward.  The hide-client-names option is designed to
+      complicate traffic analysis.  If the hide-client-names option is
+      set, the KDC implementing PA-FX-FAST MUST identify the client as
+      the anonymous principal [RFC6112] in the KDC reply and the error
+      response.  Hence, this option is set by the client if it wishes to
+      conceal the client identity in the KDC response.  A conforming KDC
+      ignores the client principal name in the outer KDC-REQ-BODY field,
+      and identifies the client using the cname and crealm fields in the
+      req-body field of the KrbFastReq structure.
+
+   The kdc-follow-referrals Option
+
+      This option is reserved for [REFERRALS].
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 29]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   The padata field contains a list of PA-DATA structures as described
+   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
+   FAST factors.  They can also be used as generic typed-holes to
+   contain data not intended for proving the client's identity or
+   establishing a reply key, but for protocol extensibility.  If the KDC
+   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+   the client MUST place any padata that is otherwise in the outer KDC
+   request body into this field.  In a TGS request, PA-TGS-REQ padata is
+   not included in this field and it is present in the outer KDC request
+   body.
+
+   The KDC-REQ-BODY in the FAST structure is used in preference to the
+   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
+   REQ-BODY structure SHOULD be filled in for backwards compatibility
+   with KDCs that do not support FAST.  A conforming KDC ignores the
+   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
+   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
+   should checksum the KDC-REQ-BODY in the FAST structure.
+
+   In a TGS request, a client MAY include the AD-fx-fast-used authdata
+   either in the pa-tgs-req authenticator or in the authorization data
+   in the pa-tgs-req ticket.  If the KDC receives this authorization
+   data but does not find a FAST padata, then it MUST return
+   KRB_APP_ERR_MODIFIED.
+
+5.4.3.  FAST Response
+
+   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+   padata element in the KDC reply.  In the case of an error, the PA-FX-
+   FAST padata is included in the KDC responses according to
+   Section 5.4.4.
+
+   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+   FAST-REPLY.
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+      KEY_USAGE_FAST_REP                 52
+
+
+
+Hartman & Zhu                Standards Track                   [Page 30]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+   structure.  The KrbFastArmoredRep structure encapsulates the padata
+   in the KDC reply in the encrypted form.  The KrbFastResponse is
+   encrypted with the armor key used in the corresponding request, and
+   the key usage number is KEY_USAGE_FAST_REP.
+
+   The Kerberos client MUST support a local policy that rejects the
+   response if PA-FX-FAST-REPLY is not included in the response.
+   Clients MAY also support policies that fall back to other mechanisms
+   or that do not use pre-authentication when FAST is unavailable.  It
+   is important to consider the potential downgrade attacks when
+   deploying such a policy.
+
+   The KrbFastResponse structure contains the following information:
+
+       KrbFastResponse ::= SEQUENCE {
+           padata         [0] SEQUENCE OF PA-DATA,
+               -- padata typed holes.
+           strengthen-key [1] EncryptionKey OPTIONAL,
+               -- This, if present, strengthens the reply key for AS and
+               -- TGS. MUST be present for TGS.
+               -- MUST be absent in KRB-ERROR.
+           finished       [2] KrbFastFinished OPTIONAL,
+               -- Present in AS or TGS reply; absent otherwise.
+           nonce          [3] UInt32,
+               -- Nonce from the client request.
+           ...
+  }
+
+   The padata field in the KrbFastResponse structure contains a list of
+   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
+   PA-DATA structures are used to carry data advancing the exchange
+   specific for the FAST factors.  They can also be used as generic
+   typed-holes for protocol extensibility.  Unless otherwise specified,
+   the KDC MUST include any padata that are otherwise in the outer KDC-
+   REP or KDC-ERROR structure into this field.  The padata field in the
+   KDC reply structure outside of the PA-FX-FAST-REPLY structure
+   typically includes only the PA-FX-FAST-REPLY padata.
+
+   The strengthen-key field provides a mechanism for the KDC to
+   strengthen the reply key.  If set, the strengthen-key value MUST be
+   randomly generated to have the same etype as that of the reply key
+   before being strengthened, and then the reply key is strengthened
+   after all padata items are processed.  Let padata-reply-key be the
+   reply key after padata processing.
+
+   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
+                         "strengthenkey", "replykey")
+
+
+
+Hartman & Zhu                Standards Track                   [Page 31]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   The strengthen-key field MAY be set in an AS reply; it MUST be set in
+   a TGS reply; it must be absent in an error reply.  The strengthen key
+   is required in a TGS reply so that an attacker cannot remove the FAST
+   PADATA from a TGS reply, causing the KDC to appear not to support
+   FAST.
+
+   The finished field contains a KrbFastFinished structure.  It is
+   filled by the KDC in the final message in the conversation.  This
+   field is present in an AS-REP or a TGS-REP when a ticket is returned,
+   and it is not present in an error reply.
+
+   The KrbFastFinished structure contains the following information:
+
+        KrbFastFinished ::= SEQUENCE {
+            timestamp       [0] KerberosTime,
+            usec            [1] Microseconds,
+                -- timestamp and usec represent the time on the KDC when
+                -- the reply was generated.
+            crealm          [2] Realm,
+            cname           [3] PrincipalName,
+                -- Contains the client realm and the client name.
+            ticket-checksum [4] Checksum,
+                -- checksum of the ticket in the KDC-REP using the armor
+                -- and the key usage is KEY_USAGE_FAST_FINISH.
+                -- The checksum type is the required checksum type
+                -- of the armor key.
+            ...
+        }
+        KEY_USAGE_FAST_FINISHED            53
+
+   The timestamp and usec fields represent the time on the KDC when the
+   reply ticket was generated, these fields have the same semantics as
+   the corresponding identically named fields in Section 5.6.1 of
+   [RFC4120].  The client MUST use the KDC's time in these fields
+   thereafter when using the returned ticket.  The client need not
+   confirm that the timestamp returned is within allowable clock skew:
+   the armor key guarantees that the reply is fresh.  The client MAY
+   trust the timestamp returned.
+
+   The cname and crealm fields identify the authenticated client.  If
+   facilities described in [REFERRALS] are used, the authenticated
+   client may differ from the client in the FAST request.
+
+   The ticket-checksum is a checksum of the issued ticket.  The checksum
+   key is the armor key, and the checksum type is the required checksum
+   type of the enctype of that key, and the key usage number is
+   KEY_USAGE_FAST_FINISHED.
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 32]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   When FAST padata is included, the PA-FX-COOKIE padata as defined in
+   Section 5.2 MUST be included in the padata sequence in the
+   KrbFastResponse sequence if the KDC expects at least one more message
+   from the client in order to complete the authentication.
+
+   The nonce field in the KrbFastResponse contains the value of the
+   nonce field in the KDC-REQ of the corresponding client request and it
+   binds the KDC response with the client request.  The client MUST
+   verify that this nonce value in the reply matches with that of the
+   request and reject the KDC reply otherwise.  To prevent the response
+   from one message in a conversation from being replayed to a request
+   in another message, clients SHOULD use a new nonce for each message
+   in a conversation.
+
+5.4.4.  Authenticated Kerberos Error Messages Using Kerberos FAST
+
+   If the Kerberos FAST padata was included in the request, unless
+   otherwise specified, the e-data field of the KRB-ERROR message
+   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
+   MUST include all the padata elements such as PA-ETYPE-INFO2 and
+   padata elements that indicate acceptable pre-authentication
+   mechanisms [RFC4120] in the KrbFastResponse structure.
+
+   The KDC MUST also include a PA-FX-ERROR padata item in the
+   KRBFastResponse structure.  The padata-value element of this sequence
+   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
+   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
+   the same as the outer KRB-ERROR.  The client ignores the outer error
+   and uses the combination of the padata in the KRBFastResponse and the
+   error information in the PA-FX-ERROR.
+
+              PA-FX-ERROR                        137
+
+   If the Kerberos FAST padata is included in the request but not
+   included in the error reply, it is a matter of the local policy on
+   the client to accept the information in the error message without
+   integrity protection.  However, the client SHOULD process the KDC
+   errors as the result of the KDC's inability to accept the AP_REQ
+   armor and potentially retry another request with a different armor
+   when applicable.  The Kerberos client MAY process an error message
+   without a PA-FX-FAST-REPLY, if that is only intended to return better
+   error information to the application, typically for trouble-shooting
+   purposes.
+
+   In the cases where the e-data field of the KRB-ERROR message is
+   expected to carry a TYPED-DATA [RFC4120] element, that information
+   should be transmitted in a pa-data element within the KRBFastResponse
+
+
+
+Hartman & Zhu                Standards Track                   [Page 33]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   structure.  The padata-type is the same as the data-type would be in
+   the typed data element and the padata-value is the same as the data-
+   value.  As discussed in Section 7, data-types and padata-types are
+   drawn from the same namespace.  For example, the
+   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+   [RFC4556].
+
+5.4.5.  Outer and Inner Requests
+
+   Typically, a client will know that FAST is being used before a
+   request containing PA-FX-FAST is sent.  So, the outer AS request
+   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
+   include additional pa-data, but the KDC MUST ignore the outer request
+   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
+   processed.  In the case of the TGS request, the outer request should
+   include PA-FX-FAST and PA-TGS-REQ.
+
+   When an AS generates a response, all padata besides PA-FX-FAST should
+   be included in PA-FX-FAST.  The client MUST ignore other padata
+   outside of PA-FX-FAST.
+
+5.4.6.  The Encrypted Challenge FAST Factor
+
+   The encrypted challenge FAST factor authenticates a client using the
+   client's long-term key.  This factor works similarly to the encrypted
+   timestamp pre-authentication option described in [RFC4120].  The word
+   "challenge" is used instead of "timestamp" because while the
+   timestamp is used as an initial challenge, if the KDC and client do
+   not have synchronized time, then the KDC can provide updated time to
+   the client to use as a challenge.  The client encrypts a structure
+   containing a timestamp in the challenge key.  The challenge key used
+   by the client to send a message to the KDC is KRB-FX-
+   CF2(armor_key,long_term_key, "clientchallengearmor",
+   "challengelongterm").  The challenge key used by the KDC encrypting
+   to the client is KRB-FX-CF2(armor_key, long_term_key,
+   "kdcchallengearmor", "challengelongterm").  Because the armor key is
+   fresh and random, the challenge key is fresh and random.  The only
+   purpose of the timestamp is to limit the validity of the
+   authentication so that a request cannot be replayed.  A client MAY
+   base the timestamp on the KDC time in a KDC error and need not
+   maintain accurate time synchronization itself.  If a client bases its
+   time on an untrusted source, an attacker may trick the client into
+   producing an authentication request that is valid at some future
+   time.  The attacker may be able to use this authentication request to
+   make it appear that a client has authenticated at that future time.
+   If ticket-based armor is used, then the lifetime of the ticket will
+   limit the window in which an attacker can make the client appear to
+
+
+
+Hartman & Zhu                Standards Track                   [Page 34]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   have authenticated.  For many situations, the ability of an attacker
+   to cause a client to appear to have authenticated is not a
+   significant concern; the ability to avoid requiring time
+   synchronization on clients is more valuable.
+
+   The client sends a padata of type PA-ENCRYPTED-CHALLENGE.  The
+   corresponding padata-value contains the DER encoding of ASN.1 type
+   EncryptedChallenge.
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+      PA-ENCRYPTED-CHALLENGE          138
+      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
+      KEY_USAGE_ENC_CHALLENGE_KDC     55
+
+   The client includes some timestamp reasonably close to the KDC's
+   current time and encrypts it in the challenge key in a PA-ENC-TS-ENC
+   structure (see Section 5.2.7.2 in RFC 4120).  Clients MAY use the
+   current time; doing so prevents the exposure where an attacker can
+   cause a client to appear to authenticate in the future.  The client
+   sends the request including this factor.
+
+   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE FAST
+   factor, the KDC decrypts the timestamp.  If the decryption fails the
+   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+   the KRBFastResponse in the error.  The KDC confirms that the
+   timestamp falls within its current clock skew returning
+   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
+   encrypted challenge is a replay.  The KDC MUST NOT consider two
+   encrypted challenges replays simply because the timestamps are the
+   same; to be a replay, the ciphertext MUST be identical.  Allowing
+   clients to reuse timestamps avoids requiring that clients maintain
+   state about which timestamps have been used.
+
+   If the KDC accepts the encrypted challenge, it MUST include a padata
+   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
+   time in the challenge key.  The KDC MUST strengthen the reply key
+   before issuing a ticket.  The client MUST check that the timestamp
+   decrypts properly.  The client MAY check that the timestamp is within
+   the window of acceptable clock skew for the client.  The client MUST
+   NOT require that the timestamp be identical to the timestamp in the
+   issued credentials or the returned message.
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 35]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   The encrypted challenge FAST factor provides the following
+   facilities: Client Authentication and KDC Authentication.  This FAST
+   factor also takes advantage of the FAST facility to strengthen the
+   reply key.  It does not provide the Replace Reply Key facility.  The
+   Security Considerations section of this document provides an
+   explanation why the security requirements are met.
+
+   The encrypted challenge FAST factor can be useful in an
+   authentication set.  No pa-hint is defined because the only
+   information needed by this mechanism is information contained in the
+   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
+   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
+   INFO2 then that information would need to be part of a hint for
+   encrypted challenge.
+
+   Conforming implementations MUST support the encrypted challenge FAST
+   factor.
+
+5.5.  Authentication Strength Indication
+
+   Implementations that have pre-authentication mechanisms offering
+   significantly different strengths of client authentication MAY choose
+   to keep track of the strength of the authentication used as an input
+   into policy decisions.  For example, some principals might require
+   strong pre-authentication, while less sensitive principals can use
+   relatively weak forms of pre-authentication like encrypted timestamp.
+
+   An AuthorizationData data type AD-Authentication-Strength is defined
+   for this purpose.
+
+        AD-authentication-strength         70
+
+   The corresponding ad-data field contains the DER encoding of the pre-
+   authentication data set as defined in Section 5.3.  This set contains
+   all the pre-authentication mechanisms that were used to authenticate
+   the client.  If only one pre-authentication mechanism was used to
+   authenticate the client, the pre-authentication set contains one
+   element.  Unless otherwise specified, the hint and value fields of
+   the members of this sequence MUST be empty.  In order to permit
+   mechanisms to carry additional information about strength in these
+   fields in the future, clients and application servers MUST ignore
+   non-empty hint and value fields for mechanisms unless the
+   implementation is updated with the interpretation of these fields for
+   a given pre-authentication mechanism in this authorization element.
+
+   The AD-authentication-strength element MUST be included in the AD-
+   KDC-ISSUED container so that the KDC integrity protects its contents.
+   This element can be ignored if it is unknown to the receiver.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 36]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+6.  Assigned Constants
+
+   The pre-authentication framework and FAST involve using a number of
+   Kerberos protocol constants.  This section lists protocol constants
+   first introduced in this specification drawn from registries not
+   managed by IANA.  Many of these registries would best be managed by
+   IANA; that is a known issue that is out of scope for this document.
+   The constants described in this section have been accounted for and
+   will appear in the next revision of the Kerberos core specification
+   or in a document creating IANA registries.
+
+   Section 7 creates IANA registries for a different set of constants
+   used by the extensions described in this document.
+
+6.1.  New Errors
+
+           KDC_ERR_PREAUTH_EXPIRED                 90
+           KDC_ERR_MORE_PREAUTH_DATA_REQUIRED      91
+           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
+           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
+
+6.2.  Key Usage Numbers
+
+           KEY_USAGE_FAST_REQ_CHKSUM               50
+           KEY_USAGE_FAST_ENC                      51
+           KEY_USAGE_FAST_REP                      52
+           KEY_USAGE_FAST_FINISHED                 53
+           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
+           KEY_USAGE_ENC_CHALLENGE_KDC             55
+
+6.3.  Authorization Data Elements
+
+           AD-authentication-strength              70
+           AD-fx-fast-armor                        71
+           AD-fx-fast-used                         72
+
+6.4.  New PA-DATA Types
+
+           PA-FX-COOKIE                            133
+           PA-AUTHENTICATION-SET                   134
+           PA-AUTH-SET-SELECTED                    135
+           PA-FX-FAST                              136
+           PA-FX-ERROR                             137
+           PA-ENCRYPTED-CHALLENGE                  138
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 37]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+7.  IANA Considerations
+
+   This document creates a number of IANA registries.  These registries
+   are all located under Kerberos Parameters on http://www.iana.org.
+   See [RFC5226] for descriptions of the registration policies used in
+   this section.
+
+7.1.  Pre-Authentication and Typed Data
+
+   RFC 4120 defines pre-authentication data, which can be included in a
+   KDC request or response in order to authenticate the client or extend
+   the protocol.  In addition, it defines Typed-Data, which is an
+   extension mechanism for errors.  Both pre-authentication data and
+   typed data are carried as a 32-bit signed integer along with an octet
+   string.  The encoding of typed data and pre-authentication data is
+   slightly different.  However, the types for pre-authentication data
+   and typed-data are drawn from the same namespace.  By convention,
+   registrations starting with TD- are typed data and registrations
+   starting with PA- are pre-authentication data.  It is important that
+   these data types be drawn from the same namespace, because some
+   errors where it would be desirable to include typed data require the
+   e-data field to be formatted as pre-authentication data.
+
+   When Kerberos FAST is used, pre-authentication data encoding is
+   always used.
+
+   There is one apparently conflicting registration between typed data
+   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
+   are both assigned the value 22.  However, this registration is simply
+   a mechanism to include an element of the other encoding.  The use of
+   both should be deprecated.
+
+   This document creates a registry for pre-authentication and typed
+   data.  The registration procedures are as follows.  Expert review for
+   pre-authentication mechanisms designed to authenticate users, KDCs,
+   or establish the reply key.  The expert first determines that the
+   purpose of the method is to authenticate clients, KDCs, or to
+   establish the reply key.  If so, expert review is appropriate.  The
+   expert evaluates the security and interoperability of the
+   specification.
+
+   IETF review is required if the expert believes that the pre-
+   authentication method is broader than these three areas.  Pre-
+   authentication methods that change the Kerberos state machine or
+   otherwise make significant changes to the Kerberos protocol should be
+   Standards Track RFCs.  A concern that a particular method needs to be
+   a Standards Track RFC may be raised as an objection during IETF
+   review.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 38]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   Several of the registrations indicated below were made at a time when
+   the Kerberos protocol was less mature and do not meet the current
+   requirements for this registry.  These registrations are included in
+   order to accurately document what is known about the use of these
+   protocol code points and to avoid conflicts.
+
+     Type                Value    Reference
+ ----------------------------------------------------------------------
+ PA-TGS-REQ                 1    [RFC4120]
+ PA-ENC-TIMESTAMP           2    [RFC4120]
+ PA-PW-SALT                 3    [RFC4120]
+ [reserved]                 4    [RFC6113]
+ PA-ENC-UNIX-TIME           5    (deprecated) [RFC4120]
+ PA-SANDIA-SECUREID         6    [RFC4120]
+ PA-SESAME                  7    [RFC4120]
+ PA-OSF-DCE                 8    [RFC4120]
+ PA-CYBERSAFE-SECUREID      9    [RFC4120]
+ PA-AFS3-SALT               10   [RFC4120] [RFC3961]
+ PA-ETYPE-INFO              11   [RFC4120]
+ PA-SAM-CHALLENGE           12   [KRB-WG.SAM]
+ PA-SAM-RESPONSE            13   [KRB-WG.SAM]
+ PA-PK-AS-REQ_OLD           14   [PK-INIT-1999]
+ PA-PK-AS-REP_OLD           15   [PK-INIT-1999]
+ PA-PK-AS-REQ               16   [RFC4556]
+ PA-PK-AS-REP               17   [RFC4556]
+ PA-PK-OCSP-RESPONSE        18   [RFC4557]
+ PA-ETYPE-INFO2             19   [RFC4120]
+ PA-USE-SPECIFIED-KVNO      20   [RFC4120]
+ PA-SVR-REFERRAL-INFO       20   [REFERRALS]
+ PA-SAM-REDIRECT            21   [KRB-WG.SAM]
+ PA-GET-FROM-TYPED-DATA     22   (embedded in typed data) [RFC4120]
+ TD-PADATA                  22   (embeds padata) [RFC4120]
+ PA-SAM-ETYPE-INFO          23   (sam/otp) [KRB-WG.SAM]
+ PA-ALT-PRINC               24   (crawdad@fnal.gov) [HW-AUTH]
+ PA-SERVER-REFERRAL         25   [REFERRALS]
+ PA-SAM-CHALLENGE2          30   (kenh@pobox.com) [KRB-WG.SAM]
+ PA-SAM-RESPONSE2           31   (kenh@pobox.com) [KRB-WG.SAM]
+ PA-EXTRA-TGT               41   Reserved extra TGT [RFC6113]
+ TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
+ TD-KRB-PRINCIPAL           102  PrincipalName
+ TD-KRB-REALM               103  Realm
+ TD-TRUSTED-CERTIFIERS      104  [RFC4556]
+ TD-CERTIFICATE-INDEX       105  [RFC4556]
+ TD-APP-DEFINED-ERROR       106  Application specific [RFC6113]
+ TD-REQ-NONCE               107  INTEGER [RFC6113]
+ TD-REQ-SEQ                 108  INTEGER [RFC6113]
+ TD_DH_PARAMETERS           109  [RFC4556]
+ TD-CMS-DIGEST-ALGORITHMS   111  [ALG-AGILITY]
+
+
+
+Hartman & Zhu                Standards Track                   [Page 39]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+ TD-CERT-DIGEST-ALGORITHMS  112  [ALG-AGILITY]
+ PA-PAC-REQUEST             128  [MS-KILE]
+ PA-FOR_USER                129  [MS-KILE]
+ PA-FOR-X509-USER           130  [MS-KILE]
+ PA-FOR-CHECK_DUPS          131  [MS-KILE]
+ PA-AS-CHECKSUM             132  [MS-KILE]
+ PA-FX-COOKIE               133  [RFC6113]
+ PA-AUTHENTICATION-SET      134  [RFC6113]
+ PA-AUTH-SET-SELECTED       135  [RFC6113]
+ PA-FX-FAST                 136  [RFC6113]
+ PA-FX-ERROR                137  [RFC6113]
+ PA-ENCRYPTED-CHALLENGE     138  [RFC6113]
+ PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-OTP-REQUEST             142  (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-OTP-CONFIRM             143  (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-EPAK-AS-REQ             145  (sshock@gmail.com) [RFC6113]
+ PA-EPAK-AS-REP             146  (sshock@gmail.com) [RFC6113]
+ PA_PKINIT_KX               147  [RFC6112]
+ PA_PKU2U_NAME              148  [PKU2U]
+ PA-SUPPORTED-ETYPES        165  [MS-KILE]
+ PA-EXTENDED_ERROR          166  [MS-KILE]
+
+7.2.  Fast Armor Types
+
+   FAST armor types are defined in Section 5.4.1.  A FAST armor type is
+   a signed 32-bit integer.  FAST armor types are assigned by standards
+   action.
+
+          Type    Name                   Description
+        ------------------------------------------------------------
+          0                              Reserved.
+          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
+
+7.3.  FAST Options
+
+   A FAST request includes a set of bit flags to indicate additional
+   options.  Bits 0-15 are critical; other bits are non-critical.
+   Assigning bits greater than 31 may require special support in
+   implementations.  Assignment of FAST options requires standards
+   action.
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 40]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+      Type    Name                   Description
+     -------------------------------------------------------------------
+      0     RESERVED               Reserved for future expansion of this
+                                   field.
+      1     hide-client-names      Requesting the KDC to hide client
+                                   names in the KDC response
+      16    kdc-follow-referrals   Reserved.
+
+8.  Security Considerations
+
+   The kdc-referrals option in the Kerberos FAST padata requests the KDC
+   to act as the client to follow referrals.  This can overload the KDC.
+   To limit the damages of denial of service using this option, KDCs MAY
+   restrict the number of simultaneous active requests with this option
+   for any given client principal.
+
+   Regarding the facilities provided by the Encrypted Challenge FAST
+   factor, the challenge key is derived from the client secrets and
+   because the client secrets are known only to the client and the KDC,
+   the verification of the EncryptedChallenge structure proves the
+   client's identity, the verification of the EncryptedChallenge
+   structure in the KDC reply proves that the expected KDC responded.
+   Therefore, the Encrypted Challenge FAST factor as a pre-
+   authentication mechanism offers the following facilities: Client
+   Authentication and KDC Authentication.  There is no un-authenticated
+   cleartext introduced by the Encrypted Challenge FAST factor.
+
+   FAST provides an encrypted tunnel over which pre-authentication
+   conversations can take place.  In addition, FAST optionally
+   authenticates the KDC to the client.  It is the responsibility of
+   FAST factors to authenticate the client to the KDC.  Care MUST be
+   taken to design FAST factors such that they are bound to the
+   conversation.  If this is not done, a man-in-the-middle may be able
+   to cut&paste a FAST factor from one conversation to another.  The
+   easiest way to do this is to bind each FAST factor to the armor key
+   that is guaranteed to be unique for each conversation.
+
+   The anonymous PKINIT mode for obtaining an armor ticket does not
+   always authenticate the KDC to the client before the conversation
+   begins.  Tracking the KDC verified state guarantees that by the end
+   of the conversation, the client has authenticated the KDC.  However,
+   FAST factor designers need to consider the implications of using
+   their factor when the KDC has not yet been authenticated.  If this
+   proves problematic in an environment, then the particular FAST factor
+   should not be used with anonymous PKINIT.
+
+   Existing pre-authentication mechanisms are believed to be at least as
+   secure when used with FAST as they are when used outside of FAST.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 41]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   One part of this security is making sure that when pre-authentication
+   methods checksum the request, they checksum the inner request rather
+   than the outer request.  If the mechanism checksummed the outer
+   request, a man-in-the-middle could observe it outside a FAST tunnel
+   and then cut&paste it into a FAST exchange where the inner rather
+   than outer request would be used to select attributes of the issued
+   ticket.  Such attacks would typically invalidate auditing information
+   or create a situation where the client and KDC disagree about what
+   ticket is issued.  However, such attacks are unlikely to allow an
+   attacker who would not be able to authenticate as a principal to do
+   so.  Even so, FAST is believed to defend against these attacks in
+   existing legacy mechanism.  However, since there is no standard for
+   how legacy mechanisms bind the request to the pre-authentication or
+   provide integrity protection, security analysis can be difficult.  In
+   some cases, FAST may significantly improve the integrity protection
+   of legacy mechanisms.
+
+   The security of the TGS exchange depends on authenticating the client
+   to the KDC.  In the AS exchange, this is done using pre-
+   authentication data or FAST factors.  In the TGS exchange, this is
+   done by presenting a TGT and by using the session (or sub-session)
+   key in constructing the request.  Because FAST uses a request body in
+   the inner request, encrypted in the armor key, rather than the
+   request body in the outer request, it is critical that establishing
+   the armor key be tied to the authentication of the client to the KDC.
+   If this is not done, an attacker could manipulate the options
+   requested in the TGS request, for example, requesting a ticket with
+   different validity or addresses.  The easiest way to bind the armor
+   key to the authentication of the client to the KDC is for the armor
+   key to depend on the sub-session key of the TGT.  This is done with
+   the implicit TGS armor supported by this specification.  Future armor
+   types designed for use with the TGS MUST either bind their armor keys
+   to the TGT or provide another mechanism to authenticate the client to
+   the KDC.
+
+9.  Acknowledgements
+
+   Sam Hartman would like to thank the MIT Kerberos Consortium for its
+   funding of his time on this project.
+
+   Several suggestions from Jeffrey Hutzelman based on early revisions
+   of this documents led to significant improvements of this document.
+
+   The proposal to ask one KDC to chase down the referrals and return
+   the final ticket is based on requirements in [CROSS].
+
+   Joel Weber had a proposal for a mechanism similar to FAST that
+   created a protected tunnel for Kerberos pre-authentication.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 42]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   Srinivas Cheruku and Greg Hudson provided valuable review comments.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]       Raeburn, K., "Encryption and Checksum Specifications
+                   for Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]       Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                   Kerberos Network Authentication Service (V5)",
+                   RFC 4120, July 2005.
+
+   [RFC4556]       Zhu, L. and B. Tung, "Public Key Cryptography for
+                   Initial Authentication in Kerberos (PKINIT)",
+                   RFC 4556, June 2006.
+
+   [RFC5226]       Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26,
+                   RFC 5226, May 2008.
+
+   [RFC6112]       Zhu, L., Leach, P., and S. Hartman "Anonymity Support
+                   for Kerberos", RFC 6112, April 2011.
+
+10.2.  Informative References
+
+   [ALG-AGILITY]   Astrand, L. and L. Zhu, "PK-INIT algorithm agility",
+                   Work in Progress, August 2008.
+
+   [CROSS]         Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+                   statement on the cross-realm operation of Kerberos in
+                   a specific system", Work in Progress, July 2007.
+
+   [EKE]           Bellovin, S. and M. Merritt, "Augmented Encrypted Key
+                   Exchange: A Password-Based Protocol Secure Against
+                   Dictionary Attacks and Password File Compromise,
+                   Proceedings of the 1st ACM Conference on Computer and
+                   Communications Security, ACM Press.", November 1993.
+
+   [HW-AUTH]       Crawford, M., "Passwordless Initial Authentication to
+                   Kerberos by Hardware  Preauthentication", Work
+                   in Progress, October 2006.
+
+   [IEEE1363.2]    IEEE, "IEEE P1363.2: Password-Based Public-Key
+                   Cryptography", 2004.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 43]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+   [KRB-WG.SAM]    Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+                   "Integrating Single-use Authentication Mechanisms
+                   with Kerberos", Work in Progress, July 2004.
+
+   [MS-KILE]       Microsoft, "Kerberos Protocol Extensions", <http://
+                   msdn.microsoft.com/en-us/library/cc206927.aspx>.
+
+   [OTP-PREAUTH]   Richards, G., "OTP Pre-authentication", Work
+                   in Progress, February 2011.
+
+   [PK-INIT-1999]  Tung, B., Neuman, C., Hur, M., Medvinsky, A.,
+                   Medvinsky, S., Wray, J., and J. Trostle, "Public Key
+                   Cryptography for Initial Authentication in Kerberos",
+                   Work in Progress, July 1999.
+
+   [PKU2U]         Zhu, L., Altman, J., and N. Williams, "Public Key
+                   Cryptography Based User-to-User Authentication -
+                   (PKU2U)", Work in Progress, November 2008.
+
+   [REFERRALS]     Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
+                   Principal Name Canonicalization and KDC-Generated
+                   Cross-Realm Referrals", Work in Progress, March 2011.
+
+   [RFC4557]       Zhu, L., Jaganathan, K., and N. Williams, "Online
+                   Certificate Status Protocol (OCSP) Support for Public
+                   Key Cryptography for Initial Authentication in
+                   Kerberos (PKINIT)", RFC 4557, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 44]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+Appendix A.  Test Vectors for KRB-FX-CF2
+
+   This informative appendix presents test vectors for the KRB-FX-CF2
+   function.  Test vectors are presented for several encryption types.
+   In all cases, the first key (k1) is the result of string-to-
+   key("key1", "key1", default_parameters) and the second key (k2) is
+   the result of string-to-key("key2", "key2", default_parameters).
+   Both keys are of the same enctype.  The presented test vector is the
+   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
+   "b").  The peppers are one-octet ASCII strings.
+
+   In performing interoperability testing, there was significant
+   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
+   vectors assume that the AES pseudo-random operation is
+   aes-ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
+   128 bits.  The 3DES pseudo-random operation is assumed to be
+   des3-cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
+   assumed to be des-cbc(md5(input)).  As specified in RFC 4757, the RC4
+   pseudo-random operation is hmac-sha1(input).
+
+   Interoperability testing also demonstrated ambiguity surrounding the
+   DES random-to-key operation.  The random-to-key operation is assumed
+   to be distribute 56 bits into high-7-bits of 8 octets and generate
+   parity.
+
+   These test vectors were produced with revision 22359 of the MIT
+   Kerberos sources.  The AES 256 and AES 128 test vectors have been
+   confirmed by multiple other implementors.  The RC4 test vectors have
+   been confirmed by one other implementor.  The DES and triple DES test
+   vectors have not been confirmed.
+
+   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
+   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
+                        b9617ae3a96868c337cb93b5e72b1c7b
+   DES (enctype 1): 43bae3738c9467e6
+   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
+   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 45]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+Appendix B.  ASN.1 Module
+
+      KerberosPreauthFramework {
+            iso(1) identified-organization(3) dod(6) internet(1)
+            security(5) kerberosV5(2) modules(4) preauth-framework(3)
+      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+      IMPORTS
+           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+           Microseconds, KerberosFlags, UInt32
+                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+                  dod(6) internet(1) security(5) kerberosV5(2)
+                  modules(4) krb5spec2(2) };
+                  -- as defined in RFC 4120.
+
+      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+          pa-type      [0] Int32,
+              -- same as padata-type.
+          pa-hint      [1] OCTET STRING OPTIONAL,
+          pa-value     [2] OCTET STRING OPTIONAL,
+          ...
+      }
+
+      KrbFastArmor ::= SEQUENCE {
+          armor-type   [0] Int32,
+              -- Type of the armor.
+          armor-value  [1] OCTET STRING,
+              -- Value of the armor.
+          ...
+      }
+
+      PA-FX-FAST-REQUEST ::= CHOICE {
+          armored-data [0] KrbFastArmoredReq,
+          ...
+      }
+
+      KrbFastArmoredReq ::= SEQUENCE {
+          armor        [0] KrbFastArmor OPTIONAL,
+              -- Contains the armor that identifies the armor key.
+              -- MUST be present in AS-REQ.
+          req-checksum [1] Checksum,
+              -- For AS, contains the checksum performed over the type
+              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+              -- structure;
+              -- For TGS, contains the checksum performed over the type
+
+
+
+Hartman & Zhu                Standards Track                   [Page 46]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+              -- AP-REQ in the PA-TGS-REQ padata.
+              -- The checksum key is the armor key, the checksum
+              -- type is the required checksum type for the enctype of
+              -- the armor key, and the key usage number is
+              -- KEY_USAGE_FAST_REQ_CHKSUM.
+          enc-fast-req [2] EncryptedData, -- KrbFastReq --
+              -- The encryption key is the armor key, and the key usage
+              -- number is KEY_USAGE_FAST_ENC.
+          ...
+      }
+
+      KrbFastReq ::= SEQUENCE {
+          fast-options [0] FastOptions,
+              -- Additional options.
+          padata       [1] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          req-body     [2] KDC-REQ-BODY,
+              -- Contains the KDC request body as defined in Section
+              -- 5.4.1 of [RFC4120].
+              -- This req-body field is preferred over the outer field
+              -- in the KDC request.
+           ...
+      }
+
+      FastOptions ::= KerberosFlags
+          -- reserved(0),
+          -- hide-client-names(1),
+          -- kdc-follow-referrals(16)
+
+      PA-FX-FAST-REPLY ::= CHOICE {
+          armored-data [0] KrbFastArmoredRep,
+          ...
+      }
+
+      KrbFastArmoredRep ::= SEQUENCE {
+          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
+              -- The encryption key is the armor key in the request, and
+              -- the key usage number is KEY_USAGE_FAST_REP.
+          ...
+      }
+
+      KrbFastResponse ::= SEQUENCE {
+          padata         [0] SEQUENCE OF PA-DATA,
+              -- padata typed holes.
+          strengthen-key [1] EncryptionKey OPTIONAL,
+              -- This, if present, strengthens the reply key for AS and
+              -- TGS.  MUST be present for TGS
+              -- MUST be absent in KRB-ERROR.
+
+
+
+Hartman & Zhu                Standards Track                   [Page 47]
+
+RFC 6113               Kerberos Preauth Framework             April 2011
+
+
+          finished       [2] KrbFastFinished OPTIONAL,
+              -- Present in AS or TGS reply; absent otherwise.
+          nonce          [3] UInt32,
+              -- Nonce from the client request.
+          ...
+      }
+
+      KrbFastFinished ::= SEQUENCE {
+          timestamp       [0] KerberosTime,
+          usec            [1] Microseconds,
+              -- timestamp and usec represent the time on the KDC when
+              -- the reply was generated.
+          crealm          [2] Realm,
+          cname           [3] PrincipalName,
+              -- Contains the client realm and the client name.
+          ticket-checksum [4] Checksum,
+              -- checksum of the ticket in the KDC-REP  using the armor
+              -- and the key usage is KEY_USAGE_FAST_FINISH.
+              -- The checksum type is the required checksum type
+              -- of the armor key.
+          ...
+      }
+
+      EncryptedChallenge ::= EncryptedData
+              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+      END
+
+Authors' Addresses
+
+   Sam Hartman
+   Painless Security
+
+   EMail: hartmans-ietf@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: larry.zhu@microsoft.com
+
+
+
+
+
+
+
+Hartman & Zhu                Standards Track                   [Page 48]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc6717.txt b/third_party/heimdal/doc/standardisation/rfc6717.txt
new file mode 100644
index 00000000000..8bd72ffc317
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc6717.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Independent Submission                                           H. Hotz
+Request for Comments: 6717                   Jet Propulsion Lab, Caltech
+Category: Informational                                       R. Allbery
+ISSN: 2070-1721                                      Stanford University
+                                                             August 2012
+
+
+     kx509 Kerberized Certificate Issuance Protocol in Use in 2012
+
+Abstract
+
+   This document describes a protocol, called kx509, for using Kerberos
+   tickets to acquire X.509 certificates.  These certificates may be
+   used for many of the same purposes as X.509 certificates acquired by
+   other means, but if a Kerberos infrastructure already exists, then
+   the overhead of using kx509 may be much less.
+
+   While not standardized, this protocol is already in use at several
+   large organizations, and certificates issued with this protocol are
+   recognized by the International Grid Trust Federation.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6717.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+Hotz & Allbery                Informational                     [Page 1]
+
+RFC 6717                          kx509                      August 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirements Language ......................................3
+   2. Protocol Data ...................................................3
+     2.1.  Request Packet .............................................3
+     2.2.  Reply Packet ...............................................4
+   3. Protocol Operation ..............................................7
+   4. Acknowledgements ................................................8
+   5. IANA Considerations .............................................8
+   6. Security Considerations .........................................9
+   7. References .....................................................10
+      7.1. Normative References ......................................10
+      7.2. Informative References ....................................10
+   Appendix A.  Certificate Caching and Deployment Considerations ....12
+   Appendix B.  Historic Extensions ..................................12
+   Appendix C.  Example Exchange .....................................12
+
+1.  Introduction
+
+   The two primary ways of providing cryptographically secure
+   identification on the Internet are Kerberos tickets [RFC4120] and
+   X.509 [RFC5280] [X.509] certificates.
+
+   In practical IT infrastructure where both are in use, it's highly
+   desirable to deploy their support in a way that guarantees they both
+   authoritatively refer to the same entities.  There is already a
+   widely adopted standard for using X.509 certificates to acquire
+   corresponding Kerberos tickets called Public Key Cryptography for
+   Initial Authentication in Kerberos (PKINIT) [RFC4556].  This document
+   describes the kx509 protocol for supporting the symmetric operation
+   of acquiring X.509 certificates using Kerberos tickets.
+
+   Preparing and reviewing this document exposed a number of issues that
+   are discussed in the security considerations.  Unfortunately, some of
+   them can only be addressed with an incompatible upgrade to this
+   protocol.  The IETF's Kerberos working group has an expected work
+   item to address these issues.
+
+   The International Grid Trust Federation [IGTF] supports the use of
+   Short Lived Credential Services [SLCS] as a means to authenticate for
+   resource usage based on other, native identity stores that an
+   organization maintains.  X.509 certificates issued using the kx509
+   protocol based on a Kerberos identity is one of the recognized
+   credential services.  The certificate profile for that use is outside
+   the scope of this RFC but is described in [GRID-prof].
+
+
+
+
+
+Hotz & Allbery                Informational                     [Page 2]
+
+RFC 6717                          kx509                      August 2012
+
+
+   In normal operation, kx509 can be used after a Kerberos ticket-
+   granting-ticket (TGT) is acquired, which is most likely during user
+   login.  First, the client generates an RSA public/private key pair.
+   Next, using the Kerberos ticket-granting-ticket, it acquires a
+   Kerberos service ticket for the KCA (Kerberized Certificate
+   Authority) and uses this to send the public half of its key pair.
+   The KCA will decrypt the service ticket, verify the integrity of the
+   incoming packet, determine the identity of the user, and use the
+   session key to send back a corresponding X.509 certificate.
+
+1.1.  Requirements Language
+
+   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 [RFC2119].
+
+2.  Protocol Data
+
+   The protocol consists of a single request/reply exchange using UDP.
+
+   Both the request and the reply packet begin with four bytes of
+   version ID information, followed by a DER-encoded ASN.1 message.  The
+   first two bytes of the version ID are reserved.  They MUST be set to
+   zero when sent and SHOULD be ignored when received.  The third and
+   fourth bytes are the major and minor version numbers, respectively.
+   The version of the protocol described in this document is designated
+   2.0, so the first four bytes of the packet are 0, 0, 2, and 0.
+
+   Incompatible variations of this protocol MUST use a different major
+   version number.
+
+2.1.  Request Packet
+
+   The request consists of a version ID, followed by a DER-encoded ASN.1
+   message containing a Kerberos AP-REQ, integrity check data on the
+   request, and public key generated by the client.  The ASN.1 encoding
+   is:
+
+   KX509Request ::= SEQUENCE {
+           AP-REQ  OCTET STRING,
+           pk-hash OCTET STRING,
+           pk-key  OCTET STRING
+   }
+
+   The AP-REQ is as described in [RFC4120], Section 5.5.1.
+
+
+
+
+
+
+Hotz & Allbery                Informational                     [Page 3]
+
+RFC 6717                          kx509                      August 2012
+
+
+   The pk-hash is Hashed Message Authentication Code (HMAC) using SHA-1
+   as the underlying hash.  All 160 bits are sent.  The key used is the
+   Kerberos session key.  The data to be hashed is the concatenation of
+   the following:
+
+   o  4-byte version ID at the beginning of the packet.
+
+   o  OCTET STRING of the AP-REQ.
+
+   o  OCTET STRING of the pk-key.
+
+   The pk-key contains a public key.  This key and its corresponding
+   private key are generated by the client before contacting the server.
+   Implementations of this protocol MUST support RSA keys, in which case
+   the key is a DER-encoded RSAPublicKey as defined in [RFC3447],
+   Section A.1.1, and then it is stored in this octet string in the
+   request.  Its encoding as an OCTET STRING starts with the 0x30 byte
+   sequence at the beginning of a DER-encoded RSAPublicKey.  Use of
+   other public-key types is not defined.
+
+   Appendix C shows an example request packet.
+
+2.2.  Reply Packet
+
+   The reply consists of a version ID, followed by a DER-encoded ASN.1
+   message containing an error code, an optional authentication hash,
+   optional certificate, and optional error text.  The service SHOULD
+   return replies of the same version as the request where possible.
+
+   KX509Response ::= SEQUENCE {
+           error-code[0]  INTEGER DEFAULT 0,
+           hash[1]        OCTET STRING OPTIONAL,
+           certificate[2] OCTET STRING OPTIONAL,
+           e-text[3]      VisibleString OPTIONAL
+   }
+
+   Although the format of the reply contains independently optional
+   objects, the server MUST only generate replies with one of the
+   following allowed combinations.
+
+               +------------+------+-------------+--------+
+               |            | hash | certificate |        |
+               | error-code | hash |             | e-text |
+               | error-code |      |             | e-text |
+               +------------+------+-------------+--------+
+
+
+
+
+
+
+Hotz & Allbery                Informational                     [Page 4]
+
+RFC 6717                          kx509                      August 2012
+
+
+   The first case is returned when the server successfully generates a
+   certificate for the user.  The certificate is a DER-encoded
+   certificate as defined in [RFC5280], Appendix A, page 116.  Its
+   encoding as an OCTET STRING starts with the 0x30 byte sequence that
+   is at the beginning of a DER-encoded certificate.
+
+   The second case is returned when the server successfully
+   authenticates the user and their key, but is unable for some other
+   reason to generate a certificate.
+
+   The third case MAY be returned if the server is unable to
+   successfully authenticate the user and intends to return some
+   unauthenticated information to the client.
+
+   The hash on a response is computed using SHA-1 HMAC as for the
+   request.
+
+   The data that is hashed is the concatenation of the following things:
+
+   o  4-byte version ID at the beginning of the packet.
+
+   o  DER representation of the error-code exclusive of the tag and
+      length, if it is present.
+
+   o  OCTET STRING of the certificate, if it is present.
+
+   o  VisibleString representation of the e-text exclusive of the tag
+      and length, if it is present.
+
+   In other words, the hash is computed on the data in the fields that
+   are present, exclusive of the overall ASN.1 wrapping.
+
+   The e-text MAY be translated into other character sets for display
+   purposes, but the hash is computed on the e-text in its VisibleString
+   representation.  If the e-text contains NUL characters, the client
+   MAY ignore any part of the error message after the first NUL
+   character for display purposes.
+
+   As implied by the above table, if the reply does not contain a
+   certificate, it MUST contain an error message and a non-zero error
+   code.  Conversely, if a certificate is returned, then the error-code
+   MUST be zero.  The server SHOULD use the DEFAULT encoding for a zero
+   error-code value by omitting any explicit error-code from the reply.
+
+
+
+
+
+
+
+
+Hotz & Allbery                Informational                     [Page 5]
+
+RFC 6717                          kx509                      August 2012
+
+
+   The defined values for error-code are as follows:
+
+   +------------+-----------------------------+------------------------+
+   | error-code | Condition                   | Example                |
+   +------------+-----------------------------+------------------------+
+   | 1          | Permanent problem with      | Incompatible version   |
+   |            | client request              |                        |
+   | 2          | Solvable problem with       | Expired Kerberos       |
+   |            | client request              | credentials            |
+   | 3          | Temporary problem with      | Packet loss            |
+   |            | client request              |                        |
+   | 4          | Permanent problem with the  | Internal               |
+   |            | server                      | misconfiguration       |
+   | 5          | Temporary problem with the  | Server overloaded      |
+   |            | server                      |                        |
+   +------------+-----------------------------+------------------------+
+
+   If a client error is returned, the client SHOULD NOT retry the
+   request unless some remedial action is first taken, although if
+   error-code 3 is returned, the client MAY retry with other servers
+   before giving up.
+
+   If a server error is returned, it is RECOMMENDED that the client
+   retry the request with a different server if one is known.
+
+   Since all KCAs serving a Kerberos realm are intended to be
+   equivalent, in accordance with Section 4.1.2.2 of [RFC5280], the
+   certificates returned from different KCAs serving the same Kerberos
+   realm MUST NOT contain duplicate serial numbers.
+
+   This protocol and document do not address certificate verification or
+   path construction.  There are no provisions for returning any
+   additional certificates that might be needed.  Any application using
+   a returned certificate must be configured independently to address
+   these issues.  An incompatible upgrade to this protocol will provide
+   options to address this issue.
+
+   The returned certificate MUST identify the Kerberos client principal
+   from the AP-REQ in the original KX509Request in the subject of the
+   certificate or in a subjectAltName extension.  The identification
+   MUST be unique within the organization's deployed infrastructure.  It
+   is RECOMMENDED that a subjectAltName extension be included of type
+   id-pkinit-san as described in [RFC4556], Section 3.2.2.  Note that
+   the id-pkinit-san is simply a standard representation of a Kerberos
+   principal and has no other implications with respect to PKINIT.
+
+
+
+
+
+
+Hotz & Allbery                Informational                     [Page 6]
+
+RFC 6717                          kx509                      August 2012
+
+
+   Other extensions MAY be added according to local policy.
+
+   Appendix C shows an example reply packet.
+
+3.  Protocol Operation
+
+   Absent errors, the protocol consists of a single request, sent via
+   UDP, and a single reply, also sent via UDP.
+
+   There is no special provision for requests or replies that exceed the
+   allowable size of a UDP packet.  Also, some implementations have
+   imposed hard size limits that are smaller than a typical UDP MTU and
+   will limit the use of extensions and the supportable key size.  Even
+   without hard limits, if the request or reply exceeds the MTU size of
+   a UDP packet for the infrastructure in use, then the reliability of
+   the exchange will decrease significantly.
+
+   For "normal" Kerberos AP-REQ structures, and "normal" X.509
+   certificates, this is unlikely unless the Kerberos service ticket
+   contains large amounts of authorization data.  For this reason, it is
+   RECOMMENDED that service tickets for the KCA be issued without
+   authorization data.  If the KCA performs authorization, it should do
+   so by other means.
+
+   Before constructing the request, the client must know the canonical
+   name(s) and port(s) of the server(s) to contact.  It MAY determine
+   them by looking up the service's SRV record as described in
+   [RFC2782].  The entry to be used is _kca._udp._realm_, where _realm_
+   is the Kerberos realm, used as part of the DNS name.
+
+   The client has to acquire a service ticket in order to construct the
+   AP-REQ for the service.  Conventionally, the Kerberos service
+   principal name to use for this service has a first component of
+   "kca_service".  Absent local configuration or other external
+   knowledge of the correct principal to use, the second and final
+   component is conventionally the canonical name of the KCA server
+   being contacted, and the realm of the principal is determined
+   following normal Kerberos domain-to-realm mapping conventions, as
+   discussed in [RFC4120], Section 1.3.
+
+   When the server receives a request, it MUST verify the following
+   properties of the request before issuing a certificate:
+
+   o  The AP-REQ can be decoded and is not expired.
+
+   o  If the request uses cross-realm authentication, then it satisfies
+      the requirements of local policy and [RFC4120], Sections 1.2 and
+      2.7.
+
+
+
+Hotz & Allbery                Informational                     [Page 7]
+
+RFC 6717                          kx509                      August 2012
+
+
+   o  The request's hash is valid.
+
+   The server SHOULD make other sanity checks, such as a minimum public
+   key length, to the extent feasible.
+
+   The server MAY decline to respond to an erroneous request.  If it
+   does not receive a response, a client MAY retry its request, but the
+   client SHOULD wait at least one second before doing so.
+
+   The client MUST verify any hash in the reply and MUST NOT use any
+   certificate in a reply whose hash does not verify.  The client MAY
+   display the e-text if the hash is absent or does not verify but
+   SHOULD indicate the message is not authenticated.
+
+4.  Acknowledgements
+
+   The original version of kx509 was implemented using Kerberos 4 at the
+   University of Michigan and was nicely documented in [KX509].  Many
+   thanks to them for their original work, as well as the subsequent
+   updates.
+
+   While developing this document, important corrections and comments
+   were provided by Jeffrey Altman and Love Hornquist Astrand.  The
+   following people also provided many helpful comments and corrections:
+   Doug Engert, Jeffrey Hutzelman, Sam Hartman, Timothy J. Miller,
+   Chaskiel Grundman, and Jim Schaad.  Alan Sill provided the references
+   to the International Grid Trust Federation and its acceptable
+   credential services.  Example network traffic was provided by Doug
+   Engert, Marcus Watts, Matt Crawford, and Chaskiel Grundman from their
+   deployments and was extremely useful for verifying the reality of
+   this specification.
+
+5.  IANA Considerations
+
+   This service is conventionally run on UDP port 9878.  IANA has
+   registered that port in the Service Name and Transport Port Number
+   Registry as follows:
+
+     Service Name:       kca-service
+     Transport Protocol: UDP
+     Assignee:           IESG <iesg@ietf.org>
+     Contact:            IETF Chair <chair@ietf.org>
+     Description:        The kx509 Kerberized Certificate Issuance
+                         Protocol in Use in 2012
+     Reference:          RFC 6717
+     Port Number:        9878
+     Assignment Notes:   Historically, this service has been referred to
+                         as "kca_service", but this service name does
+
+
+
+Hotz & Allbery                Informational                     [Page 8]
+
+RFC 6717                          kx509                      August 2012
+
+
+                         not meet the registry requirements.
+
+   The Generic Security Service Application Program Interface (GSS-API)
+   / Kerberos / Simple Authentication and Security Layer (SASL) service
+   name currently in use for this protocol is "kca_service".  This does
+   not meet the naming requirements for IANA's GSS-API/Kerberos/SASL
+   service name registry, so no registration has been requested.  The
+   conflict between the conventional service name and the registry rules
+   is expected to be addressed in a future version of this protocol.
+   Appropriate registrations will be requested at that time.
+
+6.  Security Considerations
+
+   The only encrypted information in the protocol is that used by
+   Kerberos itself.  The considerations for any Kerberized service apply
+   here.
+
+   The public key in the request is sent in the clear and without any
+   guarantees that the requester actually possesses the corresponding
+   private key.  Therefore, the only appropriate uses of the returned
+   certificate are those where the identity of the requester is
+   unimportant or the subsequent use independently guarantees that the
+   user possesses the private key.  This issue is expected to be
+   addressed in a future version of this protocol.
+
+   For example, if the kx509-issued certificate is used for a digital
+   signature in a way that does not independently demonstrate proof-of-
+   possession of the private key, then an eavesdropper could request
+   their own valid certificate via kx509 and claim to have originated
+   material signed by the legitimate, original requester.  [RFC4211],
+   Appendix C, contains a more detailed discussion of why proof-of-
+   possession is important.
+
+   An example that should be safe is initial client authentication with
+   Transport Layer Security (TLS) [RFC5246] connections.  If a client
+   certificate is used, then a Certificate Verify message (Section 7.4.8
+   of [RFC5246]) is added to the handshake exchange.  It includes a
+   signature of the handshake messages to that point.  Those messages
+   depend on data known only to the client and server ends of the
+   specific connection, so computing the signature proves possession of
+   the private key.  This application was the original intended use case
+   for kx509.
+
+   Some information, such as the public key and certificate, is
+   transmitted in the clear but (as the name implies) is generally
+   intended to be publicly available.  However, its visibility could
+   still raise privacy concerns.  The hash is used to protect the
+   integrity of this information.
+
+
+
+Hotz & Allbery                Informational                     [Page 9]
+
+RFC 6717                          kx509                      August 2012
+
+
+   The policies for issuing Kerberos tickets and X.509 certificates are
+   usually expressed very differently.  An implementation of this
+   protocol should not provide a mechanism for bypassing ticket or
+   certificate policies.
+
+   In particular, if the issued certificate can be used with PKINIT,
+   this authentication loop SHOULD NOT bypass policy limits for either
+   X.509 certificates or Kerberos tickets.
+
+   X.509 certificates are usually issued with considerably longer
+   validity times than Kerberos tickets.  Care should be taken that the
+   issued certificate is not valid for longer than the intended policy
+   should allow.  Note that Section 3.2.3 of [RFC4556] REQUIRES that the
+   lifetime of an issued ticket not exceed the lifetime of the
+   predecessor certificate.  By analogy, it is RECOMMENDED that the
+   lifetime of an issued certificate not exceed the lifetime of the
+   predecessor Kerberos ticket unless the implications with respect to
+   local policy and supporting infrastructure are clearly understood and
+   allow it.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3447]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+                Standards (PKCS) #1: RSA Cryptography Specifications
+                Version 2.1", RFC 3447, February 2003.
+
+   [RFC4120]    Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+                Kerberos Network Authentication Service (V5)", RFC 4120,
+                July 2005.
+
+   [RFC5280]    Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+                Housley, R., and W. Polk, "Internet X.509 Public Key
+                Infrastructure Certificate and Certificate Revocation
+                List (CRL) Profile", RFC 5280, May 2008.
+
+7.2.  Informative References
+
+   [GRID-prof]  "Grid Certificate Profile", March 2008,
+                <http://www.ogf.org/documents/GFD.125.pdf>.
+
+   [IGTF]       "The International Grid Trust Federation",
+                <http://www.igtf.net/>.
+
+
+
+
+Hotz & Allbery                Informational                    [Page 10]
+
+RFC 6717                          kx509                      August 2012
+
+
+   [KX509]      Doster, W., Watts, M., and D. Hyde, "The KX.509
+                Protocol", September 2001, <http://www.citi.umich.edu/
+                techreports/reports/citi-tr-01-2.pdf>.
+
+   [RFC2782]    Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+                specifying the location of services (DNS SRV)",
+                RFC 2782, February 2000.
+
+   [RFC4211]    Schaad, J., "Internet X.509 Public Key Infrastructure
+                Certificate Request Message Format (CRMF)", RFC 4211,
+                September 2005.
+
+   [RFC4556]    Zhu, L. and B. Tung, "Public Key Cryptography for
+                Initial Authentication in Kerberos (PKINIT)", RFC 4556,
+                June 2006.
+
+   [RFC5246]    Dierks, T. and E. Rescorla, "The Transport Layer
+                Security (TLS) Protocol Version 1.2", RFC 5246,
+                August 2008.
+
+   [SLCS]       "Short Lived Credential Services", February 2009,
+                <http://tagpma.org/authn_profiles/slcs>.
+
+   [X.509]      International Telecommunications Union, "Recommendation
+                X.509: The Directory: Public-key and attribute
+                certificate framework", November 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hotz & Allbery                Informational                    [Page 11]
+
+RFC 6717                          kx509                      August 2012
+
+
+Appendix A.  Certificate Caching and Deployment Considerations
+
+   As noted in the Security Considerations section, the functional
+   lifetime of the acquired X.509 certificate should usually match the
+   lifetime of its predecessor Kerberos ticket.  Therefore, it is likely
+   that X.509 certificates issued with this protocol should be deleted
+   when the supporting Kerberos tickets are deleted.  That makes the
+   Kerberos ticket cache a reasonable location to store the certificate
+   (and its private key).
+
+   On the other hand, applications, such as web browsers, probably
+   expect certificates in different stores.
+
+   A widely used solution to this dichotomy is to implement a PKCS11
+   library that supports the kx509-acquired credentials.  The
+   credentials remain stored in the Kerberos credentials cache, but full
+   PKI functionality is still available via a standard interface for PKI
+   credentials.
+
+Appendix B.  Historic Extensions
+
+   This appendix documents extensions to the kx509 protocol that are
+   either no longer in use or are expected to be dropped.
+
+   A subjectAltName othername extension of type kcaAuthRealm (OID value
+   1.3.6.1.4.1.250.42.1) is frequently used to include the client's
+   realm as an ASN.1 octet string.
+
+   The Microsoft-defined userPrincipalName has frequently been used for
+   the same purpose as the id-pkinit-san.
+
+   The historic implementations of this protocol included provisions for
+   DSA keys in place of RSA.  DSA does not appear to be in use.  A
+   future version of this protocol will use a standard certificate
+   request structure that will provide algorithm agility.
+
+   The historic implementations of this protocol allowed an optional
+   client-version field (at the end of the request) of type
+   VisibleString.  If present, the KCA copied it into the issued
+   certificate as an extension with the OID 1.3.6.1.4.1.250.42.2.  This
+   feature does not appear to be in use.
+
+Appendix C.  Example Exchange
+
+   The request and reply are from the same exchange.  The Ethernet, IP,
+   and UDP headers, and the 4-byte version string at the beginning of
+   the request and reply packets are all omitted.  Only the ASN.1-
+   encoded portions are shown.
+
+
+
+Hotz & Allbery                Informational                    [Page 12]
+
+RFC 6717                          kx509                      August 2012
+
+
+      0:d=0  hl=4 l= 678 cons: SEQUENCE
+      4:d=1  hl=4 l= 509 prim:  OCTET STRING
+                           [HEX DUMP]:6E8201F9308201F5A003... (AP-REQ)
+    517:d=1  hl=2 l=  20 prim:  OCTET STRING
+                           [HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash)
+    539:d=1  hl=3 l= 140 prim:  OCTET STRING
+                           [HEX DUMP]:30818902818100B70F46... (pk-key)
+
+                        Request Packet ASN.1 Decode
+
+     0:d=0  hl=4 l= 870 cons: SEQUENCE
+     4:d=1  hl=2 l=  22 cons:  cont [ 1 ]
+     6:d=2  hl=2 l=  20 prim:   OCTET STRING
+                        [HEX DUMP]:F3A844834C26D843B6FD... (hash)
+    28:d=1  hl=4 l= 842 cons:  cont [ 2 ]
+    32:d=2  hl=4 l= 838 prim:   OCTET STRING
+                        [HEX DUMP]:308203423082022AA003... (certificate)
+
+                         Reply Packet ASN.1 Decode
+
+Authors' Addresses
+
+   Henry B. Hotz
+   Jet Propulsion Laboratory, California Institute of Technology
+   4800 Oak Grove Dr.
+   Pasadena, CA  91109
+   USA
+
+   Phone: +01 818 354-4880
+   EMail: hotz@jpl.nasa.gov
+
+
+   Russ Allbery
+   Stanford University
+   P.O. Box 20066
+   Stanford, CA  94309
+   USA
+
+   EMail: rra@stanford.edu
+   URI:   http://www.eyrie.org/~eagle/
+
+
+
+
+
+
+
+
+
+
+
+Hotz & Allbery                Informational                    [Page 13]
+
diff --git a/third_party/heimdal/doc/standardisation/rfc6806.txt b/third_party/heimdal/doc/standardisation/rfc6806.txt
new file mode 100644
index 00000000000..b4b292e5692
--- /dev/null
+++ b/third_party/heimdal/doc/standardisation/rfc6806.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   S. Hartman, Ed.
+Request for Comments: 6806                             Painless Security
+Updates: 4120                                                 K. Raeburn
+Category: Standards Track                                            MIT
+ISSN: 2070-1721                                                   L. Zhu
+                                                   Microsoft Corporation
+                                                           November 2012
+
+
+   Kerberos Principal Name Canonicalization and Cross-Realm Referrals
+
+Abstract
+
+   This memo documents a method for a Kerberos Key Distribution Center
+   (KDC) to respond to client requests for Kerberos tickets when the
+   client does not have detailed configuration information on the realms
+   of users or services.  The KDC will handle requests for principals in
+   other realms by returning either a referral error or a cross-realm
+   Ticket-Granting Ticket (TGT) to another realm on the referral path.
+   The clients will use this referral information to reach the realm of
+   the target principal and then receive the ticket.  This memo also
+   provides a mechanism for verifying that a request has not been
+   tampered with in transit.  This memo updates RFC 4120.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6806.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+
+
+
+Hartman, et al.              Standards Track                    [Page 1]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
+   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Trust Assumptions  . . . . . . . . . . . . . . . . . . . .  5
+   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  6
+   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  7
+   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
+   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Cross-Realm Routing  . . . . . . . . . . . . . . . . . . . . . 11
+   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
+   11. Negotiation of FAST and Detecting Modified Requests  . . . . . 12
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+     13.1. Shared-Password Case . . . . . . . . . . . . . . . . . . . 16
+     13.2. Pre-Authentication Data  . . . . . . . . . . . . . . . . . 16
+   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
+   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+     15.2. Informative References . . . . . . . . . . . . . . . . . . 17
+   Appendix A.  Compatibility with Earlier Implementations of
+                Name Canonicalization . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 2]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+1.  Introduction
+
+   Current implementations of the Kerberos Authentication Service (AS)
+   and Ticket-Granting Service (TGS) protocols, as defined in [RFC4120],
+   use principal names constructed from a known user or service name and
+   realm.  A service name is typically constructed from a name of the
+   service and the DNS host name of the computer that is providing the
+   service.  Many existing deployments of Kerberos use a single Kerberos
+   realm where all users and services would be using the same realm.
+   However, in an environment where there are multiple Kerberos realms,
+   the client needs to be able to determine what realm a particular user
+   or service is in before making an AS or TGS request.  Traditionally,
+   this requires client configuration to make this possible.
+
+   When having to deal with multiple realms, users are forced to know
+   what realm they are in before they can obtain a Ticket-Granting
+   Ticket (TGT) with an AS request.  However, in many cases, the user
+   would like to use a more familiar name that is not directly related
+   to the realm of their Kerberos principal name.  A good example of
+   this is an email name in the style described in [RFC5322].  This
+   document describes a mechanism that would allow a user to specify a
+   user principal name that is an alias for the user's Kerberos
+   principal name.  In practice, this would be the name that the user
+   specifies to obtain a TGT from a Kerberos KDC.  The user principal
+   name no longer has a direct relationship with the Kerberos principal
+   or realm.  Thus, the administrator is able to move the user's
+   principal to other realms without the user having to know that it
+   happened.
+
+   Once a TGT has been obtained, the user would like to be able to
+   access services in any Kerberos realm for which there is an
+   authentication path from the realm of their principal.  To do this
+   requires that the client be able to determine what realm the target
+   service principal is in before making the TGS request.  Current
+   implementations of Kerberos typically have a table that maps DNS host
+   names to corresponding Kerberos realms.  The user-supplied host name
+   or its domain component is looked up in this table (often using the
+   result of some form of host name lookup performed with insecure DNS
+   queries, in violation of [RFC4120]).  The corresponding realm is then
+   used to complete the target service principal name.  Even if insecure
+   DNS queries were not used, managing this table is problematic.
+
+   This traditional mechanism requires that each client have very
+   detailed configuration information about the hosts that are providing
+   services and their corresponding realms.  Having client-side
+   configuration information can be very costly from an administration
+   point of view -- especially if there are many realms and computers in
+   the environment.
+
+
+
+Hartman, et al.              Standards Track                    [Page 3]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   This memo proposes a solution for these problems and simplifies
+   administration by minimizing the configuration information needed on
+   each computer using Kerberos.  Specifically, it describes a mechanism
+   to allow the KDC to handle canonicalization of names, provide for
+   principal aliases for users and services, and allow the KDC to
+   determine the trusted realm authentication path by being able to
+   generate referrals to other realms in order to locate principals.
+
+   Two kinds of KDC referrals are introduced in this memo:
+
+   1. Client referrals, in which the client doesn't know which realm
+      contains a user account.
+
+   2. Server referrals, in which the client doesn't know which realm
+      contains a server account.
+
+   These two types of referrals introduce new opportunities for an
+   attacker.  In order to avoid these attacks, a mechanism is provided
+   to protect the integrity of the request between the client and KDC.
+   This mechanism complements the Flexible Authentication Secure Tunnels
+   (FAST) facility provided in [RFC6113].  A mechanism is provided to
+   negotiate the availability of FAST.  Among other benefits, this can
+   be used to protect errors generated by the referral process.
+
+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 [RFC2119].
+
+3.  Requesting a Referral
+
+   In order to request referrals as defined in later sections, the
+   Kerberos client MUST explicitly request the "canonicalize" KDC option
+   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
+   the KDC that the client is prepared to receive a reply that contains
+   a principal name other than the one requested.
+
+          KDCOptions ::= KerberosFlags
+                   -- canonicalize (15)
+                   -- other KDCOptions values omitted
+
+   When sending names with the "canonicalize" KDC option, the client
+   should expect that names in the KDC's reply MAY be different than the
+   name in the request.  A referral TGT is a cross-realm TGT that is
+   returned with the server name of the ticket being different from the
+   server name in the request [RFC4120].
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 4]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+4.  Realm Organization Model
+
+   This memo assumes that the world of principals is arranged on
+   multiple levels: the realm, the enterprise, and the world.  A KDC may
+   issue tickets for any principal in its realm or cross-realm tickets
+   for realms with which it has a direct cross-realm relationship.  The
+   KDC also has access to a trusted name service that can resolve any
+   name from within its enterprise into a realm closer along the
+   authentication path to the service.  This trusted name service
+   removes the need to use an untrusted DNS lookup for name resolution.
+
+   For example, consider the following configuration, where lines
+   indicate cross-realm relationships:
+
+                      EXAMPLE.COM
+                      /        \
+                     /          \
+          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
+
+   In this configuration, all users in the EXAMPLE.COM enterprise could
+   have principal names, such as alice@EXAMPLE.COM, with the same realm
+   portion.  In addition, servers at EXAMPLE.COM should be able to have
+   DNS host names from any DNS domain independent of what Kerberos realm
+   their principals reside in.
+
+4.1.  Trust Assumptions
+
+   Two realms participate in any cross-realm relationship: an issuing
+   realm issues a cross-realm ticket, and a consuming realm uses this
+   ticket.  There is a degree of trust of the issuing realm by the
+   consuming realm implied by this relationship.  Whenever a service in
+   the consuming realm permits an authentication path containing the
+   issuing realm, that service trusts the issuing realm to accurately
+   represent the identity of the authenticated principal and any
+   information about the transited path.  If the consuming realm's KDC
+   sets the transited policy checked flag, the KDC is making the same
+   trust assumption that a service would.
+
+   This trust is transitive across a multi-hop authentication path.  The
+   service's realm trusts each hop along the authentication path closer
+   to the client to accurately represent the authenticated identity and
+   to accurately represent transited information.  Any KDC along this
+   path could impersonate the client.
+
+   KDC-signed or -issued authorization data often implies additional
+   trust.  The implications of such trust from a security and
+   operational standpoint is an ongoing topic of discussion during the
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 5]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   development of this specification.  As such, such discussion is out
+   of scope for this memo.
+
+   Administrators have several tools to limit trust caused by cross-
+   realm relationships.  A service or KDC can control what
+   authentication paths are acceptable.  For example, if a given realm
+   is not permitted on the authentication path for a particular client,
+   then that realm cannot affect trust placed in that client principal.
+   Consuming realms can exercise significant control by deciding what
+   principals to place on an access-control list.  If no client using a
+   given issuing realm in authentication paths is permitted to access a
+   resource, then that issuing realm is not trusted in access decisions
+   regarding that resource.
+
+   Creating a cross-realm relationship implies relatively little
+   inherent trust in the issuing realm.  Significant trust only applies
+   as principals dependent on that issuing realm are given access to
+   resources.  However, two deployment characteristics may increase the
+   trust implied by the initial cross-realm relationship.  First, a
+   number of realms provide access to any principal to some resources.
+   Access decisions involving these resources involve a degree of trust
+   in all issuing realms in the transited graph.  Secondly, many realms
+   do not constrain the set of principals to which users of that realm
+   may grant access.  In these realms, creating a cross-realm
+   relationship delegates the decision to trust that realm to users of
+   the consuming realm.  In this situation, creating the cross-realm
+   relationship is the primary trust decision point under the
+   administrator's control.
+
+5.  Enterprise Principal Name Type
+
+   The NT-ENTERPRISE type principal name contains one component, a
+   string of realm-defined content, which is intended to be used as an
+   alias for another principal name in some realm in the enterprise.  It
+   is used for conveying the alias name, not for the real principal
+   names within the realms, and thus is only useful when name
+   canonicalization is requested.
+
+   The intent is to allow unification of email and security principal
+   names.  For example, all users at EXAMPLE.COM may have a client
+   principal name of the form "joe@EXAMPLE.COM", even though the
+   principals are contained in multiple realms.  This global name is
+   again an alias for the true client principal name, which indicates
+   what realm contains the principal.  Thus, accounts "alice" in the
+   realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as
+   "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
+
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 6]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   This utilizes a new principal name type, as the KDC-REQ message only
+   contains a single client realm (crealm) field, and the realm portion
+   of this name corresponds to the Kerberos realm with which the request
+   is made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as
+   a single component in the client name field of the AS-REQ message,
+   with a name type of NT-ENTERPRISE [RFC4120] (and the local realm
+   name).  The KDC will recognize this name type and then transform the
+   requested name into the true principal name if the client account
+   resides in the local realm.  The true principal name can have a name
+   type different from the requested name type.  Typically, the true
+   principal name will be an NT-PRINCIPAL [RFC4120].
+
+6.  Name Canonicalization
+
+   A service or account may have multiple principal names.  For example,
+   if a host is known by multiple names, host-based services on it may
+   be known by multiple names in order to prevent the client from
+   needing a secure directory service to determine the correct host name
+   to use.  In order to avoid the need to update the host whenever a new
+   alias is created, the KDC may provide the mapping information to the
+   client in the credential acquisition process.
+
+   If the "canonicalize" KDC option is set, then the KDC MAY change the
+   client and server principal names and types in the AS response and
+   ticket returned from those in the request.  Names MUST NOT be changed
+   in the response to a TGS request, although it is common for KDCs to
+   maintain a set of aliases for service principals.  Regardless of
+   which alias a client requests, the same service key is used.
+   However, in the TGS request, the client receives a ticket for the
+   alias requested.  Services MUST NOT make distinctions based on which
+   alias is in the issued ticket, because the service name in a ticket
+   is not cryptographically protected and can be changed by parties
+   other than the KDC.
+
+   For example, the AS request may specify a client name of "bob@
+   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
+   option set, and the KDC will return with a client name of "104567" as
+   an NT-UID [RFC4120].
+
+   (It is assumed that the client discovers whether the KDC supports the
+   NT-ENTERPRISE name type via out-of-band mechanisms.)
+
+   See Section 11 for a mechanism to detect modification of the request
+   between the client and KDC.  However, for the best protection,
+   Flexible Authentication Secure Tunneling (FAST) [RFC6113] or another
+   mechanism that protects the entire KDC exchange SHOULD be used.
+   Clients MAY reject responses from a KDC where the client or server
+   name is changed if the KDC does not support such a mechanism.
+
+
+
+Hartman, et al.              Standards Track                    [Page 7]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   Clients SHOULD reject an AS response that changes the server name
+   unless the response is protected by such a mechanism or the new
+   server name is one explicitly expected by the client.  For example,
+   many clients permit the realm name to be changed in an AS response,
+   even if the response is not protected.  See Section 13 for a
+   discussion of the tradeoffs in allowing unprotected responses.
+
+   In order to permit authorization decisions to be made based on
+   aliases as well as the canonicalized form of a principal name, the
+   KDC MAY include the following authorization data element, wrapped in
+   AD-KDC-ISSUED, in the initial credentials and copy it from a ticket-
+   granting ticket into additional credentials:
+
+   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
+     login-aliases  [0] SEQUENCE (SIZE (1..MAX)) OF PrincipalName,
+     ...
+   }
+
+   The login-aliases field lists one or more of the aliases the
+   principal is known by.
+
+   In addition to permitting authorization based on aliases, this
+   permits user-to-user exchanges where the party receiving the
+   authenticator knows the other party only by an alias.  The recipient
+   of such an authenticator SHOULD check the AD-LOGIN-ALIAS names, if
+   present, in addition to the normal client name field, against the
+   identity of the party with which it wishes to authenticate; either
+   should be allowed to match.  (Note that this is not backwards
+   compatible with [RFC4120]; if the server side of the user-to-user
+   exchange does not support this extension and does not know the true
+   principal name, authentication may fail if the alias is sought in the
+   client name field.)
+
+   The use of AD-KDC-ISSUED authorization data elements in cross-realm
+   cases has not been well explored at this writing; hence, we will only
+   specify the inclusion of this data in the one-realm case.  The AD-
+   LOGIN-ALIAS information SHOULD be dropped in the general cross-realm
+   case.  However, a realm MAY implement a policy of accepting and
+   re-signing (wrapping in a new AD-KDC-ISSUED element) alias
+   information provided by certain trusted realms in the cross-realm
+   ticket-granting service.
+
+   The canonical principal name for an alias MUST NOT be in the form of
+   a ticket-granting service name, as (in a case of server name
+   canonicalization) that would be construed as a case of cross-realm
+   referral, described below.
+
+
+
+
+
+Hartman, et al.              Standards Track                    [Page 8]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+7.  Client Referrals
+
+   The simplest form of ticket referral is for a user requesting a
+   ticket using an AS-REQ.  In this case, the client machine will send
+   the AS-REQ to a convenient realm trusted to map principals, for
+   example, the realm of the client machine.  In the case of the name
+   alice@EXAMPLE.COM, the client MAY optimistically choose to send the
+   request to EXAMPLE.COM.  The realm in the AS-REQ is always the name
+   of the realm that the request is for, as specified in [RFC4120].
+
+   The KDC will try to lookup the name in its local account database.
+   If the account is present in the realm of the request, it SHOULD
+   return a KDC reply with the appropriate ticket.
+
+   If the account is not present in the realm specified in the request
+   and the "canonicalize" KDC option is set, the KDC may look up the
+   client principal name using some kind of name service or directory
+   service.  If this lookup is unsuccessful, it MUST return the error
+   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
+   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120]; in the error
+   message, the crealm field will contain either the true realm of the
+   client or another realm that MAY have better information about the
+   client's true realm.  The client MUST NOT use the cname returned in
+   this error message.
+
+   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
+   new AS request with the same client principal name used to generate
+   the first AS request to the realm specified by the realm field of the
+   Kerberos error message corresponding to the first request.  (The
+   client realm name will be updated in the new request to refer to this
+   new realm.)  The client SHOULD repeat these steps until it finds the
+   true realm of the client.  To avoid infinite referral loops, an
+   implementation should limit the number of referrals.  A suggested
+   limit is 5 referrals before giving up.
+
+   Since the same client name is sent to the referring and referred-to
+   realms, both realms must recognize the same client names.  In
+   particular, the referring realm cannot (usefully) define principal
+   name aliases that the referred-to realm will not know.
+
+   The true principal name of the client, returned in AS-REP, can be
+   validated in a subsequent TGS message exchange where its value is
+   communicated back to the KDC via the authenticator in the PA-TGS-REQ
+   padata [RFC4120].  However, this requires trusting the referred-to
+   realm's KDCs.  Clients should limit the referral mappings they will
+   accept to realms trusted via some local policy.  Some possible
+   factors that might be taken into consideration for such a policy
+   might include:
+
+
+
+Hartman, et al.              Standards Track                    [Page 9]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   o  Any realm indicated by the local KDC if the returned KRB-ERROR
+      message is protected by some additional means, for example, FAST
+
+   o  A list of realms configured by an administrator
+
+   o  Any realm accepted by the user when explicitly prompted
+
+   One common approach for limiting the realms from which referrals are
+   accepted is to limit referrals to realms that can construct an
+   authentication path back to the service principal of the local
+   machine.  This tends to work well when realms are generally within an
+   organization and all realms that can form an authentication path back
+   to the local machine have some reasonable level of mapping trust.
+   Deployments involving more complex trust, for example, high
+   probability of malicious realms, are likely to need more complex
+   policy and MAY need to prompt the user before accepting some
+   referrals.
+
+   There is currently no provision for changing the client name in a
+   client referral response.
+
+8.  Server Referrals
+
+   The primary difference in server referrals is that the KDC returns a
+   referral TGT rather than an error message as is done in the client
+   referrals.
+
+   If the "canonicalize" flag in the KDC options is set and the KDC
+   doesn't find the principal locally, either as a regular principal or
+   as an alias for another local principal, the KDC MAY return a cross-
+   realm ticket-granting ticket to the next hop on the trust path
+   towards a realm that may be able to resolve the principal name.
+
+   The client will use this referral information to request a chain of
+   cross-realm ticket-granting tickets until it reaches the realm of the
+   server, and can then expect to receive a valid service ticket.
+
+   However, an implementation should limit the number of referrals that
+   it processes to avoid infinite referral loops.  A suggested limit is
+   5 referrals before giving up.
+
+   The client may cache the mapping of the requested name to the name of
+   the next realm to use and the principal name to ask for (see
+   Section 10).
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 10]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   Here is an example of a client requesting a service ticket for a
+   service in realm DEV.EXAMPLE.COM where the client is in
+   ADMIN.EXAMPLE.COM.
+
+      +NC = Canonicalize KDCOption set
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
+      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM
+      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
+      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
+
+   Note that any referral or alias processing of the server name in
+   user-to-user authentication should use the same data as client name
+   canonicalization or referral.  Otherwise, the name used by one user
+   to log in may not be useable by another for user-to-user
+   authentication to the first.
+
+9.  Cross-Realm Routing
+
+   RFC 4120 permits a KDC to return a closer referral ticket when a
+   cross-realm TGT is requested.  This specification extends this
+   behavior when the canonicalize flag is set.  When this flag is set, a
+   KDC MAY return a TGT for a realm closer to the service for any
+   service as discussed in the previous section.  When a client follows
+   such a referral, it includes the realm of the referred-to realm in
+   the generated request.
+
+   When the canonicalize flag is not set, the rules defined in RFC 4120
+   apply.
+
+10.  Caching Information
+
+   It is possible that the client may wish to get additional credentials
+   for the same service principal, perhaps with different authorization-
+   data restrictions or other changed attributes.  The return of a
+   server referral from a KDC can be taken as an indication that the
+   requested principal does not currently exist in the local realm.
+   Clearly, it would reduce network traffic if the clients could cache
+   that information and use it when acquiring the second set of
+   credentials for a service, rather than always having to recheck with
+   the local KDC to see if the name has been created locally.
+
+   When the TGT expires, the previously returned referral from the local
+   KDC should be considered invalid, and the local KDC must be asked
+   again for information for the desired service principal name.  (Note
+   that the client may get back multiple referral TGTs from the local
+   KDC to the same remote realm, with different lifetimes.  The lifetime
+
+
+
+Hartman, et al.              Standards Track                   [Page 11]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   information SHOULD be properly associated with the requested service
+   principal names.  Simply having another TGT for the same remote realm
+   does not extend the validity of previously acquired information about
+   one service principal name.)
+
+   Accordingly, KDC authors and maintainers should consider what factors
+   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
+   into credential expiration times in cases of referrals.
+
+11.  Negotiation of FAST and Detecting Modified Requests
+
+   Implementations of this specification MUST support the FAST
+   negotiation mechanism described in this section.  This mechanism
+   provides detection of KDC requests modified by an attacker when those
+   requests result in a reply instead of an error.  In addition, this
+   mechanism provides a secure way to detect if a KDC supports FAST.
+
+   Clients conforming to this specification MUST send new pre-
+   authentication data of type PA-REQ-ENC-PA-REP (149) in all AS
+   requests and MAY send this padata type in TGS requests.  The value of
+   this padata item SHOULD be empty and its value MUST be ignored by a
+   receiving KDC.  Sending this padata item indicates support for this
+   negotiation mechanism.  KDCs conforming to this specification must
+   always set the ticket flag enc-pa-rep (15) in all the issued tickets.
+   This ticket flag indicates KDC support for the mechanism.
+
+   The KDC response [RFC4120] is extended to support an additional field
+   containing encrypted pre-authentication data.
+
+          EncKDCRepPart   ::= SEQUENCE {
+                 key                [0] EncryptionKey,
+                 last-req           [1] LastReq,
+                 nonce              [2] UInt32,
+                 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,
+                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
+         }
+
+   The encrypted-pa-data element MUST be absent unless either the
+   "canonicalize" KDC option is set or the PA-REQ-ENC-PA-REP padata item
+   is sent.
+
+
+
+Hartman, et al.              Standards Track                   [Page 12]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the
+   KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa-
+   data item of any generated KDC reply.  The PA-REQ-ENC-PA-REP pa-data
+   value contains the checksum computed over the type AS-REQ or TGS-REQ
+   in the request.  The checksum key is the reply key and the checksum
+   type is the required checksum type for the encryption type of the
+   reply key, and the key usage number is KEY_USAGE_AS_REQ (56).  If the
+   KDC supports FAST, then the KDC MUST include a padata of type PA-FX-
+   FAST in any encrypted-pa-data sequence it generates.  The padata item
+   MUST be empty on sending, and the contents of the padata item MUST be
+   ignored on receiving.
+
+   A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP
+   if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata
+   item is absent or the checksum is not successfully verified.
+
+12.  IANA Considerations
+
+   PA-REQ-ENC-PA-REP has been registered in the Kerveros "Pre-
+   authentication and Typed Data" registry
+   <http://www.iana.org/assignments/kerberos-parameters>.
+
+13.  Security Considerations
+
+   For the AS exchange case, it is important that the logon mechanism
+   not trust a name that has not been used to authenticate the user.
+   For example, the name that the user enters as part of a logon
+   exchange may not be the name that the user authenticates as, given
+   that the KDC_ERR_WRONG_REALM error may have been returned.  The
+   relevant Kerberos naming information for logon (if any) is the client
+   name and client realm in the service ticket targeted at the
+   workstation obtained using the user's initial TGT.  That is, rather
+   than trusting the client name in the AS response, a workstation
+   SHOULD perform an AP-REQ authentication against itself as a service
+   and use the client name in the ticket issued for its service by the
+   KDC.
+
+   How the client name and client realm are mapped into a local account
+   for logon is a local matter, but the client logon mechanism MUST use
+   additional information such as the client realm and/or authorization
+   attributes from the service ticket presented to the workstation by
+   the user when mapping the logon credentials to a local account on the
+   workstation.
+
+   Not all fields in a KDC reply defined by RFC 4120 are protected.
+   None of the fields defined in RFC 4120 for AS request are protected,
+   and some information in a TGS request may not be protected.  The
+   referrals mechanism creates several opportunities for attack because
+
+
+
+Hartman, et al.              Standards Track                   [Page 13]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   of these unprotected fields.  FAST [RFC6113] can be used to
+   completely mitigate these issues by protecting both the KDC request
+   and response.  However, FAST requires that a client obtain an armor
+   ticket before authenticating.  Not all realms permit all clients to
+   obtain armor tickets.  Also, while it is expected to be uncommon, a
+   client might wish to use name canonicalization while obtaining an
+   armor ticket.  The mechanism described in Section 11 detects
+   modification of the request between the KDC and client, mitigating
+   some attacks.
+
+   There is a widely deployed base of implementations that use name
+   canonicalization or server referrals that use neither the negotiation
+   mechanism nor FAST.  So, implementations may be faced with only the
+   limited protection afforded by RFC 4120, by the negotiation mechanism
+   discussed in this document, or by FAST.  All three situations are
+   important to consider from a security standpoint.
+
+   An attacker cannot mount a downgrade attack against a client.  The
+   negotiation mechanism described in this document is securely
+   indicated by the presence of a ticket flag.  So, a client will detect
+   if the facility was available but not used.  It is possible for an
+   attacker to strip the indication that a client supports the
+   negotiation facility.  The client will learn from the response that
+   this happened, but the KDC will not learn that the client is
+   attacked.  So, for a single round-trip Kerberos exchange, the KDC may
+   believe the exchange was successful when the client detects an
+   attack.  Packet loss or client failure can produce a similar result;
+   this is not a significant vulnerability.  The negotiation facility
+   described in this document securely indicates the presence of FAST.
+   So, if a client wishes to use FAST when it is available, an attacker
+   cannot force the client to downgrade away from FAST.  An attacker MAY
+   be able to prevent a client from obtaining an armor ticket, for
+   example, by responding to a request for anonymous Public Key
+   Cryptography for Initial Authentication in Kerberos (PKINIT) with an
+   error response.
+
+   If FAST is used, then the communications between the client and KDC
+   are protected.  However, name canonicalization places a new
+   responsibility for mapping principals onto the KDC.  This can
+   increase the number of KDCs involved in an authentication, which adds
+   additional trusted third parties to the exchange.
+
+   If only the negotiation mechanism is used, then the request from the
+   client to the KDC is protected, but not all of the response is
+   protected.  In particular, the client name is not protected; the
+   ticket is also not protected.  An attacker can potentially modify
+   these fields.  Modification of the client name will result in a
+   denial of service.  When the client attempts to authenticate to a
+
+
+
+Hartman, et al.              Standards Track                   [Page 14]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+   service (including the TGS), it constructs an AP-REQ message.  This
+   message includes a client name that MUST match the client name in the
+   ticket according to RFC 4120.  Thus, if the client name is changed,
+   the resulting ticket will fail when used.  This is undesirable
+   because the authentication is separated from the later failure, which
+   may confuse problem determination.  If the ticket is replaced with
+   another ticket, then later authentication to a service will fail
+   because the client will not know the session key for the other
+   ticket.  If the ticket is simply modified, then authentication to a
+   service will fail as with RFC 4120.  More significant attacks are
+   possible if a KDC violates the requirements of RFC 4120 and issues
+   two tickets with the same session key, or if a service violates the
+   requirements of RFC 4120 and does not check the client name against
+   that in the ticket.
+
+   There is an additional attack possible when FAST is not used against
+   KDC_ERR_WRONG_REALM.  Since this is an error response, not an AS
+   response, it is not protected by the negotiation mechanism.  Thus, an
+   attacker may be able to convince a client to authenticate to a realm
+   other than the one intended.  If an attacker is off-path, this may
+   give the attacker an advantage in attacking the client's credentials.
+   Also, see the discussion of shared passwords below.
+
+   More serious attacks are possible if no protection beyond RFC 4120 is
+   used.  In this case, neither the client name nor the service name is
+   protected between the client and KDC.  In the general case, if an
+   attacker changes the client name, then authentication will fail
+   because the client will not have the right credentials (password,
+   certificate, or other) to authenticate as the user selected by the
+   attacker.  However, see the discussion of shared passwords below.
+   Changing the server name can be a very significant attack.  For
+   example, if a user is authenticating in order to send some
+   confidential information, then the attacker could gain this
+   information by directing the user to a server under the attacker's
+   control.  The server name in the response is protected by RFC 4120,
+   but not the one in the request.  Fortunately, users are typically
+   authenticating to the "krbtgt" service in an AS exchange.  Clients
+   that permit changes to the server name when no protection beyond RFC
+   4120 is in use SHOULD carefully restrict what service names are
+   acceptable.  One critical case to consider is the password-changing
+   service.  When a user authenticates to change their password, they
+   use an AS authentication directly to the password-changing service.
+   Clients MUST restrict service name changes sufficiently that the
+   client ends up talking to the correct password-changing service.
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 15]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+13.1.  Shared-Password Case
+
+   A special case to examine is when the user is known (or correctly
+   suspected) to use the same password for multiple accounts.  A man-in-
+   the-middle attacker can either alter the request on its way to the
+   KDC, changing the client principal name, or reply to the client with
+   a response previously sent by the KDC in response to a request from
+   the attacker.  The response received by the client can then be
+   decrypted by the user, though if the default "salt" generated from
+   the principal name is used to produce the user's key, a PA-ETYPE-INFO
+   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
+   the attacker to cause the client software to generate the key needed
+   for the message it will receive.  None of this requires the attacker
+   to know the user's password, and without further checking, this could
+   cause the user to unknowingly use the wrong credentials.
+
+   In normal operation as described in [RFC4120], a generated AP-REQ
+   message includes in the Authenticator field a copy of the client's
+   idea of its own principal name.  If this differs from the name in the
+   KDC-generated ticket, the application server will reject the message.
+
+   With client name canonicalization as described in this document, the
+   client may get its principal name from the response from the KDC.
+   Using the wrong credentials may provide an advantage to an attacker.
+   For example, if a client uses one principal for administrative
+   operations and one for less privileged operation, an attacker may
+   coerce a client into using the wrong privilege to either cause some
+   later operation to succeed or fail.
+
+13.2.  Pre-Authentication Data
+
+   In cases of credential renewal, forwarding, or validation, if
+   credentials are sent to the KDC that are not an initial ticket-
+   granting ticket for the client's home realm, the encryption key used
+   to protect the TGS exchange is one known to a third party (namely,
+   the service for which the credential was issued).  Consequently, in
+   such an exchange, the protection described earlier may be compromised
+   by the service.  This is not generally believed to be a problem.  If
+   it is, some form of explicit TGS armor could be added to FAST.
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 16]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+14.  Acknowledgments
+
+   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
+   version of this document.
+
+   Karthik Jaganathan contributed to earlier versions.
+
+   Sam Hartman's work on this document was funded by the MIT Kerberos
+   Consortium.
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC6113]  Hartman, S. and L. Zhu, "A Generalized Framework for
+              Kerberos Pre-Authentication", RFC 6113, April 2011.
+
+15.2.  Informative References
+
+   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
+              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
+              of Crossrealm Referral Handling in the MIT Kerberos
+              Client",  Network and Distributed System Security
+              Symposium, February 2001.
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 17]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+Appendix A.  Compatibility with Earlier Implementations of Name
+             Canonicalization
+
+   The Microsoft Windows 2000 and Windows 2003 releases included an
+   earlier form of name-canonicalization [XPR].  Here are the
+   differences:
+
+   1) Windows include an additional encrypted padata element.  The
+      preauth data type definition in the encrypted preauth data is as
+      follows:
+
+
+          PA-SVR-REFERRAL-INFO       20
+
+          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
+                 referred-name   [1] PrincipalName OPTIONAL,
+                 referred-realm  [0] Realm
+          }}
+
+         The referred-principal is never sent.  The referred-realm is
+         included in TGS replies and includes the realm name of the
+         realm to which the client is referred.  This information is
+         redundant with the realm in the second component of the
+         returned TGT.
+
+   2) When PKINIT [RFC4556] is used, the NT-ENTERPRISE client name is
+      encoded as a Subject Alternative Name (SAN) extension [RFC5280] in
+      the client's X.509 certificate.  The type of the otherName field
+      for this SAN extension is AnotherName [RFC5280].  The type-id
+      field of the type AnotherName is id-ms-sc-logon-upn
+      (1.3.6.1.4.1.311.20.2.3), and the value field of the type
+      AnotherName is a KerberosString [RFC4120].  The value of this
+      KerberosString type is the single component in the name-string
+      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
+
+   In Microsoft's current implementation through the use of global
+   catalogs, any domain in one forest is reachable from any other domain
+   in the same forest or another trusted forest with 3 or less
+   referrals.  A forest is a collection of realms with hierarchical
+   trust relationships: there can be multiple trust trees in a forest;
+   each child and parent realm pair and each root realm pair have
+   bidirectional transitive direct trust between them.
+
+   While we might want to permit multiple aliases to exist and even be
+   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
+   one NT-ENTERPRISE alias to exist, so this question had not previously
+   arisen.
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 18]
+
+RFC 6806                      KDC Referrals                November 2012
+
+
+Authors' Addresses
+
+   Sam Hartman (editor)
+   Painless Security
+
+   EMail: hartmans-ietf@mit.edu
+
+
+   Kenneth Raeburn
+   Massachusetts Institute of Technology
+
+   EMail: raeburn@mit.edu
+
+
+   Larry Zhu
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   US
+
+   EMail: lzhu@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman, et al.              Standards Track                   [Page 19]
+
diff --git a/third_party/heimdal/doc/vars.tin b/third_party/heimdal/doc/vars.tin
new file mode 100644
index 00000000000..0907397db91
--- /dev/null
+++ b/third_party/heimdal/doc/vars.tin
@@ -0,0 +1,8 @@
+
+@c
+@c Variables depending on installation
+@c
+
+@set dbdir @dbdir@
+@set dbtype @dbtype@
+@set PACKAGE_VERSION @PACKAGE_VERSION@
diff --git a/third_party/heimdal/doc/whatis.texi b/third_party/heimdal/doc/whatis.texi
new file mode 100644
index 00000000000..902344b0352
--- /dev/null
+++ b/third_party/heimdal/doc/whatis.texi
@@ -0,0 +1,214 @@
+@c $Id$
+
+@node What is Kerberos?, What is PKIX?, Introduction, Top
+@chapter What is Kerberos?
+
+@quotation
+@flushleft
+        Now this Cerberus had three heads of dogs,
+        the tail of a dragon, and on his back the
+        heads of all sorts of snakes.
+        --- Pseudo-Apollodorus Library 2.5.12
+@end flushleft
+@end quotation
+
+Kerberos is a system for authenticating users and services on a network.
+It is built upon the assumption that the network is ``unsafe''.  For
+example, data sent over the network can be eavesdropped and altered, and
+addresses can also be faked.  Therefore they cannot be used for
+authentication purposes.
+@cindex authentication
+
+Kerberos is a trusted third-party service.  That means that there is a
+third party (the kerberos server) that is trusted by all the entities on
+the network (users and services, usually called @dfn{principals}).  All
+principals share a secret password (or key) with the kerberos server and
+this enables principals to verify that the messages from the kerberos
+server are authentic.  Thus trusting the kerberos server, users and
+services can authenticate each other.
+
+@section Basic mechanism
+
+@ifinfo
+@macro sub{arg}
+<\arg\>
+@end macro
+@end ifinfo
+
+@iftex
+@macro sub{arg}
+@textsubscript{\arg\}
+@end macro
+@end iftex
+
+@ifhtml
+@macro sub{arg}
+
+@html
+<sub>\arg\</sub>
+@end html
+
+@end macro
+@end ifhtml
+
+@c ifdocbook
+@c macro sub{arg}
+@c docbook
+@c <subscript>\arg\</subscript>
+@c end docbook
+@c end macro
+@c end ifdocbook
+
+@quotation
+@strong{Note} This discussion is about Kerberos version 4, but version
+5 works similarly.
+@end quotation
+
+In Kerberos, principals use @dfn{tickets} to prove that they are who
+they claim to be. In the following example, @var{A} is the initiator of
+the authentication exchange, usually a user, and @var{B} is the service
+that @var{A} wishes to use.
+
+To obtain a ticket for a specific service, @var{A} sends a ticket
+request to the kerberos server. The request contains @var{A}'s and
+@var{B}'s names (along with some other fields). The kerberos server
+checks that both @var{A} and @var{B} are valid principals.
+
+Having verified the validity of the principals, it creates a packet
+containing @var{A}'s and @var{B}'s names, @var{A}'s network address
+(@var{A@sub{addr}}), the current time (@var{t@sub{issue}}), the lifetime
+of the ticket (@var{life}), and a secret @dfn{session key}
+@cindex session key
+(@var{K@sub{AB}}). This packet is encrypted with @var{B}'s secret key
+(@var{K@sub{B}}).  The actual ticket (@var{T@sub{AB}}) looks like this:
+(@{@var{A}, @var{B}, @var{A@sub{addr}}, @var{t@sub{issue}}, @var{life},
+@var{K@sub{AB}}@}@var{K@sub{B}}).
+
+The reply to @var{A} consists of the ticket (@var{T@sub{AB}}), @var{B}'s
+name, the current time, the lifetime of the ticket, and the session key, all
+encrypted in @var{A}'s secret key (@{@var{B}, @var{t@sub{issue}},
+@var{life}, @var{K@sub{AB}}, @var{T@sub{AB}}@}@var{K@sub{A}}). @var{A}
+decrypts the reply and retains it for later use.
+
+@sp 1
+
+Before sending a message to @var{B}, @var{A} creates an authenticator
+consisting of @var{A}'s name, @var{A}'s address, the current time, and a
+``checksum'' chosen by @var{A}, all encrypted with the secret session
+key (@{@var{A}, @var{A@sub{addr}}, @var{t@sub{current}},
+@var{checksum}@}@var{K@sub{AB}}). This is sent together with the ticket
+received from the kerberos server to @var{B}.  Upon reception, @var{B}
+decrypts the ticket using @var{B}'s secret key.  Since the ticket
+contains the session key that the authenticator was encrypted with,
+@var{B} can now also decrypt the authenticator. To verify that @var{A}
+really is @var{A}, @var{B} now has to compare the contents of the ticket
+with that of the authenticator. If everything matches, @var{B} now
+considers @var{A} as properly authenticated.
+
+@c (here we should have some more explanations)
+
+@section Different attacks
+
+@subheading Impersonating A
+
+An impostor, @var{C} could steal the authenticator and the ticket as it
+is transmitted across the network, and use them to impersonate
+@var{A}. The address in the ticket and the authenticator was added to
+make it more difficult to perform this attack.  To succeed @var{C} will
+have to either use the same machine as @var{A} or fake the source
+addresses of the packets. By including the time stamp in the
+authenticator, @var{C} does not have much time in which to mount the
+attack.
+
+@subheading Impersonating B
+
+@var{C} can hijack @var{B}'s network address, and when @var{A} sends
+her credentials, @var{C} just pretend to verify them. @var{C} can't
+be sure that she is talking to @var{A}.
+
+@section Defence strategies
+
+It would be possible to add a @dfn{replay cache}
+@cindex replay cache
+to the server side.  The idea is to save the authenticators sent during
+the last few minutes, so that @var{B} can detect when someone is trying
+to retransmit an already used message. This is somewhat impractical
+(mostly regarding efficiency), and is not part of Kerberos 4; MIT
+Kerberos 5 contains it.
+
+To authenticate @var{B}, @var{A} might request that @var{B} sends
+something back that proves that @var{B} has access to the session
+key. An example of this is the checksum that @var{A} sent as part of the
+authenticator. One typical procedure is to add one to the checksum,
+encrypt it with the session key and send it back to @var{A}.  This is
+called @dfn{mutual authentication}.
+
+The session key can also be used to add cryptographic checksums to the
+messages sent between @var{A} and @var{B} (known as @dfn{message
+integrity}).  Encryption can also be added (@dfn{message
+confidentiality}). This is probably the best approach in all cases.
+@cindex integrity
+@cindex confidentiality
+
+@section Further reading
+
+The original paper on Kerberos from 1988 is @cite{Kerberos: An
+Authentication Service for Open Network Systems}, by Jennifer Steiner,
+Clifford Neuman and Jeffrey I. Schiller.
+
+A less technical description can be found in @cite{Designing an
+Authentication System: a Dialogue in Four Scenes} by Bill Bryant, also
+from 1988.
+
+These documents can be found on our web-page at
+@url{http://www.pdc.kth.se/kth-krb/}.
+
+@node What is PKIX?, What is a Certification Authority (CA)?, What is Kerberos?, Top
+@chapter What is PKIX?
+
+PKIX is the set of Internet standards for Public Key Infrastructure (PKI),
+based on the ITU-T's x.509 standads.  PKI is an authentication mechanism based
+on public keys (the 'PK' in 'PKI').
+
+In PKIX we have public keys "certified" by certification authorities (CAs).  A
+"relying party" is software that validates an entity's certificate and, if
+valid, trusts the certified public key to "speak for" the entity identified by
+the certificate.
+
+In a PKI every entity has one (or more) certified public/private key pairs.
+
+@node What is a Certification Authority (CA)?, What is kx509?, What is PKIX?, Top
+@chapter What is a Certification Authority (CA)?
+
+A Certification Authority (CA) is an entity in a PKI that issues certificates
+to other entities -- a CA certifies that a public key speaks for a particular,
+named entity.
+
+There are two types of CAs: off-line and online.  Typically PKI hierarchies are
+organized such that the most security-critical private keys are only used by
+off-line CAs to certify the less security-critical public keys of online CAs.
+
+Heimdal has support for off-line CAs using its Hx509 library and hxtool
+command.
+
+Heimdal also has an online CA with a RESTful, HTTPS-based protocol.
+
+@node What is kx509?, What is bx509?, What is a Certification Authority (CA)?, Top
+@chapter What is kx509?
+
+kx509 is a kerberized certification authority (CA).  Heimdal implements this
+protocol in its KDC.  The protocol is specified by <a
+href="http://www.ietf.org/rfc/rfc6717.txt">RFC 6717</a>, though Heimdal has
+implemented a number of extensions as well.  A client is implemented by the
+heimtools command's kx509 sub-command.
+
+@node What is bx509?, Building and Installing, What is kx509?, Top
+@chapter What is kx509?
+
+bx509 is an online CA, like kx509, but the protocol is based on HTTPS.
+
+Heimdal's bx509d implementation of bx509 implements two authentication bridges:
+a "/bx509" end-point that allows clients to trade bearer tokens (including
+Negotiate/Kerberos) and CSRs for certificates, and a "/bnegotiate" end-point
+allowing clients to trade bearer tokens (including Negotiate/Kerberos) for
+Negotiate tokens to HTTP servers.
diff --git a/third_party/heimdal/doc/win2k.texi b/third_party/heimdal/doc/win2k.texi
new file mode 100644
index 00000000000..0fefeee3fdc
--- /dev/null
+++ b/third_party/heimdal/doc/win2k.texi
@@ -0,0 +1,315 @@
+@c $Id$
+
+
+@node Windows compatibility, Programming with Kerberos, Kerberos 4 issues, Top
+@comment  node-name,  next,  previous,  up
+@chapter Windows compatibility
+
+Microsoft Windows, starting from version 2000 (formerly known as Windows NT 5), implements Kerberos 5. Their implementation, however, has some quirks,
+peculiarities, and bugs. This chapter is a short summary of the compatibility
+issues between Heimdal and various Windows versions.
+
+The big problem with the Kerberos implementation in Windows
+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. It's of course subject to change all the time and
+mostly consists of our not so inspired guesses.  Hopefully it's still
+somewhat useful.
+
+@menu
+* Configuring Windows to use a Heimdal KDC::  
+* Inter-Realm keys (trust) between Windows and a Heimdal KDC::  
+* Create account mappings::     
+* Encryption types::            
+* Authorisation data::          
+* Quirks of Windows 2000 KDC::  
+* Useful links when reading about the Windows::  
+@end menu
+
+@node Configuring Windows to use a Heimdal KDC, Inter-Realm keys (trust) between Windows and a Heimdal KDC, Windows compatibility, Windows compatibility
+@comment node-name, next, precious, up
+@section Configuring Windows to use a Heimdal KDC
+
+You need the command line program called @command{ksetup.exe}. This program comes with the Windows Support Tools, available from either the installation CD-ROM (@file{SUPPORT/TOOLS/SUPPORT.CAB}), or from Microsoft web site. Starting from Windows 2008, it is already installed. This program is used to configure the Kerberos settings on a Workstation.
+
+@command{Ksetup} store the domain information under the registry key:
+@code{HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains}.
+
+Use the @command{kadmin} program in Heimdal to create a host principal in the
+Kerberos realm.
+
+@example
+unix% kadmin
+kadmin> ank --password=password host/datan.example.com
+@end example
+
+The name @samp{datan.example.com} should be replaced with DNS name of
+the workstation.
+
+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 EXAMPLE.COM
+C:> ksetup /addkdc EXAMPLE.COM kdc.example.com
+@end example
+
+Set the machine password, i.e.@: create the local keytab:
+@example
+C:> ksetup /SetComputerPassword password
+@end example
+
+The password used in @kbd{ksetup /setmachpassword} must be the same
+as the password used in the @kbd{kadmin ank} command.
+
+The workstation must now be rebooted.
+
+A mapping between local NT users and Kerberos principals must be specified.
+You have two choices. First:
+
+@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@enddots{})
+
+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 and a Heimdal KDC, Create account mappings, Configuring Windows to use a Heimdal KDC, Windows compatibility
+@comment node-name, next, precious, up
+@section Inter-Realm keys (trust) between Windows and a Heimdal KDC
+
+See also the Step-by-Step guide from Microsoft, referenced below.
+
+Install Windows, 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 @command{netdom.exe} tool. @command{netdom.exe} 
+can also be used to add the trust between two realms.
+
+You need to tell Windows on what hosts to find the KDCs for the
+non-Windows realm with @command{ksetup}, see @xref{Configuring Windows 
+to use a Heimdal KDC}.
+
+This needs to be done on all computers that want enable cross-realm
+login with @code{Mapped Names}. @c XXX probably shouldn't be @code
+
+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 (if that's what you want).
+
+If you want to use @command{netdom.exe} instead of the Domain Tree
+Management tool, you do it like this:
+
+@example
+netdom trust NT.REALM.EXAMPLE.COM /Domain:EXAMPLE.COM /add /realm /passwordt:TrustPassword
+@end example
+
+You also need to add the inter-realm keys to the Heimdal KDC. But take
+care to the encryption types and salting used for those keys. There should be
+no encryption type stronger than the one configured on Windows side for this
+relationship, itself limited to the ones supported by this specific version of
+Windows, nor any Kerberos 4 salted hashes, as Windows does not seem to
+understand them. Otherwise, the trust will not works.
+
+Here are the version-specific needed information:
+@enumerate
+@item Windows 2000: maximum encryption type is DES
+@item Windows 2003: maximum encryption type is DES
+@item Windows 2003RC2: maximum encryption type is RC4, relationship defaults to DES
+@item Windows 2008: maximum encryption type is AES, relationship defaults to RC4
+@end enumerate
+
+For Windows 2003RC2, to change the trust encryption type, you have to use the
+@command{ktpass}, from the Windows 2003 Resource kit *service pack2*, available
+from Microsoft web site.
+
+@example
+C:> ktpass /MITRealmName UNIX.EXAMPLE.COM /TrustEncryp RC4 
+@end example
+
+For Windows 2008, the same operation can be done with the @command{ksetup}, installed by default.
+
+@example
+C:> ksetup /SetEncTypeAttre EXAMPLE.COM AES256-SHA1 
+@end example
+
+Once the relationship is correctly configured, you can add the required
+inter-realm keys, using heimdal default encryption types:
+
+@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.
+
+And if needed, to remove unsupported encryptions, such as the following ones for a Windows 2003RC2 server.
+
+@example
+kadmin del_enctype krbtgt/REALM.EXAMPLE.COM@@NT.EXAMPLE.COM aes256-cts-hmac-sha1-96
+kadmin del_enctype krbtgt/REALM.EXAMPLE.COM@@NT.EXAMPLE.COM des3-cbc-sha1
+kadmin del_enctype krbtgt/NT.EXAMPLE.COM@@EXAMPLE.COM aes256-cts-hmac-sha1-96
+kadmin del_enctype krbtgt/NT.EXAMPLE.COM@@EXAMPLE.COM des3-cbc-sha1
+@end example
+
+Do not forget to reboot before trying the new realm-trust (after
+running @command{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 and a Heimdal KDC, Windows compatibility
+@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.
+
+@c XXX check entry name then I have network again
+This adds @samp{authorizationNames} entry to the users LDAP entry to
+the Active Directory LDAP catalog. When you create users by script you
+can add this entry instead.
+
+@node Encryption types, Authorisation data, Create account mappings, Windows compatibility
+@comment  node-name,  next,  previous,  up
+@section Encryption types
+
+Windows 2000 supports both the standard DES encryptions (@samp{des-cbc-crc} and
+@samp{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.
+
+@node Authorisation data, Quirks of Windows 2000 KDC, Encryption types, Windows compatibility
+@comment  node-name,  next,  previous,  up
+@section Authorisation data
+
+The Windows 2000 KDC also adds extra authorisation data in tickets.
+It is at this point unclear what triggers it to do this.  The format of
+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
+@item Find the client example on using the SSPI in the SDK documentation.
+@item Change ``AuthSamp'' in the source code to lowercase.
+@item Build the program.
+@item Add the ``authsamp'' principal with a known password to the
+database.  Make sure it has a DES key.
+@item Run @kbd{ktutil add} to add the key for that principal to a
+keytab.
+@item Run @kbd{appl/test/nt_gss_server -p 2000 -s authsamp
+@kbd{--dump-auth}=@var{file}} where @var{file} is an appropriate file.
+@item It should authenticate and dump for you the authorisation data in
+the file.
+@item The tool @kbd{lib/asn1/asn1_print} is somewhat useful for
+analysing the data.
+@end enumerate
+
+@node Quirks of Windows 2000 KDC, Useful links when reading about the Windows, Authorisation data, Windows compatibility
+@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 have fixed this issue post Windows 2003.
+
+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 @samp{des-cbc-md5} key
+is used. To make the KDC return only @samp{des-cbc-crc} you must delete
+the @samp{des-cbc-md5} key from the kdc using the @kbd{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,  , Quirks of Windows 2000 KDC, Windows compatibility
+@comment  node-name,  next,  previous,  up
+@section Useful links when reading about the Windows
+
+See also our paper presented at the 2001 Usenix Annual Technical
+Conference, available in the proceedings or at
+@uref{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/westerlund.html}.
+
+There are lots of texts 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:
+@uref{http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx}.
+Kerberos GSS-API (in Windows-eze SSPI), Windows as a client in a
+non-Windows KDC realm, adding unix clients to a Windows 2000 KDC, and
+adding cross-realm trust (@pxref{Inter-Realm keys (trust) between Windows
+and a Heimdal KDC}).
+
+@item Windows 2000 Kerberos Authentication:
+@uref{www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx}.
+White paper that describes how Kerberos is used in Windows 2000.
+
+@item Overview of Kerberos:
+@uref{http://support.microsoft.com/support/kb/articles/Q248/7/58.ASP}.
+Links to useful other links.
+
+@c @item Klist for Windows:
+@c @uref{http://msdn.microsoft.com/library/periodic/period00/security0500.htm}.
+@c Describes where to get a klist for Windows 2000.
+
+@item Event logging for Kerberos:
+@uref{http://support.microsoft.com/support/kb/articles/Q262/1/77.ASP}.
+Basically 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.
+
+@c @item Access to the Active Directory through LDAP:
+@c @uref{http://msdn.microsoft.com/library/techart/kerberossamp.htm}
+
+@end itemize
+
+Other useful programs include these:
+
+@itemize @bullet
+@item pwdump2
+@uref{http://www.bindview.com/Support/RAZOR/Utilities/Windows/pwdump2_readme.cfm}
+@end itemize
diff --git a/third_party/heimdal/doc/wind.din b/third_party/heimdal/doc/wind.din
new file mode 100644
index 00000000000..da36dd1b768
--- /dev/null
+++ b/third_party/heimdal/doc/wind.din
@@ -0,0 +1,15 @@
+# Doxyfile 1.5.3
+
+PROJECT_NAME           = Heimdal wind library
+PROJECT_NUMBER         = @PACKAGE_VERSION@
+OUTPUT_DIRECTORY       = @srcdir@/doxyout/wind
+INPUT                  = @srcdir@/../lib/wind
+
+WARN_IF_UNDOCUMENTED   = YES
+
+PERL_PATH              = /usr/bin/perl
+
+HTML_HEADER = "@srcdir@/header.html"
+HTML_FOOTER = "@srcdir@/footer.html"
+
+@INCLUDE = "@srcdir@/doxytmpl.dxy"